SDLX: The number of segments in the TTX and original ITD files does not match

The number of segments in the TTX and original ITD files does not match, is what kept haunting me today. I kept receiving this irritating error message while harvesting TagEditor files (TTX) back to SDLX files (ITD). Weeks ago, I was trying to convert a huge Excel file (XLS) to TTX format. TagEditor, however, did not give any errors and exited automatically without converting the file successfully. That's the reason why I chose SDLX to perform the conversion task instead.

After examining the TTX file, I suspect that error arises due to the segmentation settings used in the TagEditor file. For Excel's TagEditor file created by the SDLX Exchange, I guess we have to make sure that it is translated using the paragraph segmentation (column) instead of the regular sentence segmentation. So I did some testing and make sure that all the entries in the TTX file are paragraph segmented and use the SDLX exchange to perform the conversion again. This time it actually works.... *Sigh* it is actually sucks when I have to make sure that the segmentation is correct before I could get the conversion done properly without errors... Why can't SDLX exchange handle all that for me? :(

Okapi Framework... TXT to XLIFF

I came across Okapi Framework, when I was writing scripts to extract and convert plain text to XLIFF format. So far, I have only tried using the text extraction and text rewriting tools, and find that the application is quite versatile. It allows extracting of translatable text in various formats and form XLIFF files. Besides, it has a pretty easy-to-use interface which allow users to create and test the filters using regular expressions... These filters can be used to extract translatable text from some funny formats that you have never seen..



The goal of the Okapi Framework is to allow tools developers and localizers to build new localization processes or enhance existing ones to best meet their needs, while preserving a level of compatibility and interoperability. It also provides them with a way to share (and re-use) components across different solutions. The project uses and promotes open standards, where they exist. For the aspects where open standards are not defined yet, the framework offers its own. The ultimate goal is to adopt the industry standards when they are defined and useable.

Personally, I like Okapi because it uses a common file format, XLIFF, for localization. From my work experience, I often receive materials in different formats from various departments and the result of this caused the Translation Database messy. By using one common format, it makes life easier for the translators, reviewer and linguists, as they only need to learn to handle one type of file and for the engineers to convert the file back to their native formats is just a button click away..

At the point of this post is written, Okapi is still under development, and the support for the XLIFF specification is still quite limited. It only support some tags like , and etc. Furthermore, the support for some standard file types like *.doc is also not in place yet... I think it will be a great tool if these are all implemented..... I am looking forward to it..

Trados: The process cannot access the file because it is being used by another process

I kept receiving the same irritating error messages today, Error(32): The process cannot access the file because it is being used by another process, while processing files in Trados Workbench. Initially, I thought this was due to Microsoft Word or the process, winword.exe, running in the Windows background. Trados, however, still prompting the same error messages after I have restart Trados and ensured that those programs are not running...

After killing some processes from the task manager, I noticed that after the virus scanner was shut down, Trados does not prompt the error message anymore... Hence, to avoid the same error messages, I have decided to disable the scanner every time before I start using Trados.

I am wondering, are any other possibilities that give similar error messages? Like objects in the files that is externally linked to another programs? Hmmm... maybe I shall do some testing some day....

Trados: Analyze and process all files in the folder, as well as, sub-folders

One of the tools, I used very frequently to do analysis, pre- and post-engineering of files is Trados. Usually, to process files in Trados Workbench, I would use Windows Explorer to open the folder containing all the materials. I would, then drag and drop them into the Trados Workbench to analyze, pre- or post-process the files. Although this is one of the commonly used methods, it is not very efficient if the working folder contains sub-folders. Windows Explorer is unable to display all the files that reside in the sub-folders in one go; and it is very troublesome and "dangerous" to access each sub-folders at a time to add the files, especially when you missed out some files.

I start to explore and try some shortcuts that allow me to perform the same process in one go. One of the methods that I use very frequently now is to use the search command in the Windows Explorer. You have to point to the particular working folder that contains all the files to perform a search. The results of the search command will includes all the working files in the folder, as well as, the sub-folders. You can simply select and drag all the files into Trados Workbench to process the files. This will save up lots of time required for manually add and process the files.