Transolution is an open-source translation memory application written in the Python scripting language. It is highly modular, the core application being an XLIFF editor. Outside the XLIFF editor itself, it is heavily command-line oriented. It features an inline rather than a dual-window interface. These characteristics will be considered in turn below.

Transolution is (to my knowledge) the only translation memory application written entirely in Python, or for that matter any other scripting language. This is relevant for two reasons. Firstly, the most obvious alternatives — OmegaT, Sun's Open Language Tools, and Heartsome — all run on Java. Inevitably, they therefore have both advantages and drawbacks inherent to the Java platform, and at some stage the user is likely to find a knowledge of Java — by which I mean of configuration and operation rather than of programming — an advantage. The same is no doubt true of Transolution, but in this case the language is not Java, but Python. Since Python, unlike Java, is not only free but also open-source, it is more likely to meet with the approval of the politically more radical members of the open-source community for whom Java is beyond the pale.

transolution.jpg

Screenshot of Transolution, being used here to translate the Dutch Wikipedia entry for Norah Jones.

Transolution is modular. The XLIFF editor, translation memory database and XLIFF filters are discrete applications, and in fact are all launched separately from the command line. The intention is clearly to facilitate the use of different modules, i.e. a different database and different XLIFF filters. The modular arrangement and the command-line bias of the auxiliary modules is an open invitation to scripters (not necessarily using Python) to produce a common interface combining the different functions. For the ordinary user, however, it makes use of the application somewhat fiddly; just how fiddly can be seen from the basic process workflow which I have reproduced below.

The XLIFF editor concept is also shared with Heartsome and Sun's Open Language Tools. Conversion of input files to the XLIFF format in preparation for the translation process proper is therefore a familiar step to users of these applications. Transolution has its own filters for the HTML, OpenOffice.org and Docbook formats, plus a generic filter for user configuration. In theory, the filters from any of these applications could be used to prepare source files for translation in either of the other two; in practice, the three projects differ in the strictness of their adherence to the XLIFF standard, which makes the filters largely mutually incompatible. These differences are not fundamental, but simply reflect the different stages of development, and improvements may be expected in future.

Finally, the XLIFF Editor uses an inline interface. This means that instead of presenting the user with two windows, one containing the whole source text, the other the whole translation, it presents a combined window in which translated segments contain the translation, untranslated segments the original source texts, and only the active segment both. In this respect, it is similar to OmegaT or Wordfast. (Heartsome does not present the whole text at all, but offers a dual-window display through the "Preview" function.)

A simple workflow procedure for an MS Word source file is as follows:

  1. In OpenOffice.org, save the source file as an *.sxw file.
  2. Extract the file content.xml from the OpenOffice.org archive. (Unlike OpenOffice.org, Sun OLT and Heartsome, Transolution's filter is not able to extract the content.xml file from the archive automatically.)
  3. Convert the file content.xml to the XLIFF format using the separate XLIFF filter module. This must be done from the command line. In its simplest form, the command is python sgml2xliff.py <filter name> <source file name>.
  4. Launch the translation memory engine. Again, this has to be done from the command line. In its simplest form, the command for launching the translation memory database is python tm.py. If legacy translation memories are to be used, they must be specified as arguments in the launch command.
  5. The XLIFF editor can now be launched and the actual translation process started.
  6. Once translation is complete, follow the preparation procedure in reverse, i.e. convert the XLIFF file back to produce the translated content.xml. The basic command-line syntax for this is python xliff2sgml.py <source file name>.
  7. Re-insert the translated content.xml into the OpenOffice.org archive (*.sxw file).
  8. Finally, open the OpenOffice.org file in OpenOffice and save as MS Word.

This procedure is not intended to replace the documenation which can be found on the Transolution site, but to give some idea of the fiddly nature of file preparation and post-processing. This aspect could be improved considerably and probably quite easily, but efforts have clearly been focused on other aspects. The user interface of the XLIFF editor itself, for instance, is attractive and user-friendly, and in my subjective opinion even superior to that of Heartsome.

This brings me to the next point: further development. At the time of writing (January 2006), developer Fredrik Corneliusson has only just announced that he has taken up a full-time post and will not have time to devote to further work on the application. It is however already well beyond the stage of being usable, so I would be surprised if work were not taken up by other developers.

For the record: Transolution was formerly known as "EvilTrans" (the new name is certainly an improvement). It should not be confused with Translution, which is a machine translation application running on Windows.

Finally: the documentation is a little geeky, but no worse in this respect than that of a typical Linux command-line application, and reasonably comprehensive.

Link to the Transolution website

/div>