Donnerstag, 8. Juli 2010

In a session on Verbatim, Pootle etc yesterday, Matjaz presented a Jetpack add-on, that allows one to use a translation memory (in a TMX form) during the  Verbatim process. The example showed nicely, how one can take an existing TMX file, list the candidates (100% match and some fuzzies as well) and then drop the selection into the target segment.

Verbatim does not use any translation memory mechanism (as far as I know, not even MO, the nonstandard Pootle's version of a translation memory) to propagate the translations which already exist through the material to be translated. Well, fine, but then the JetPack solution by Matjaz will fix it, will it not?

Please note first, the TMX, to be used in the JetPack, comes from outside. It is not an integral part of the Verbatim / Pootle solution. It is a deus ex machina, a translational band-aid - for now at least, if not for some time coming.


Matjaz showed during the demo of his Jetpack solution, how  "Australia" is translated into "Avstralija" with the help of an existing translation memory. Just before this example, however, there was a case of "Argentina" without any suggestion from TMX. Matjaz dropped in the copy of the source and then proceeded  on to the next entry. But hold on a second: where did the target entry for "Argentina" land?  Just in the PO? How adding the new stuff to TMX? After all  it would not hurt to adhere to the Mozilla spirit and expand the TMX with the working being done. I am pretty certain, however, that in the case of Matjaz' add-on TMX get short-changed. 

Here's the situation in a nutshell: external translational sources are tapped to (help Verbatim) help the localizer do the work. The Verbatim per se is not involved,  as it does not as yet have any ways and means to tap into the possibilities, offered by standardized translation memories. On the other hand, the external sources are on receiving end of the stick in the Jetpack proposal, as their initial investment and the use of their assets, as implemented in the Matjaz' proposal, is not  reciprocated by expanding the memory with new translations.

We all have open and free standards for everybody written all over our hearts, flags and banners. Standardized translation memory - free and open-sourced for all - must be among them.

Vito

PS:  one of the listeners, who was evidently new to the subject of translation memories and specifically to the subject of TMX, commented with visible relief "Oh, fine, it's just an XML file". Oh well... XML file is not much, if anything at all, without a corresponding DTD.

To see DTD for TMX files - and implicitely all the work and drive behind it - see
TMX specification by LISA

Jetpack add-on for Verbatim

at Mozilla Summit 2010, 8.july

In a session on Verbatim, Pootle etc yesterday, Matjaz presented a Jetpack add-on, that allows one to use a translation memory (in a TMX form) during the  Verbatim process. The example showed nicely, how one can take an existing TMX file, list the candidates (100% match and some fuzzies as well) and then drop the selection into the target segment.

Verbatim does not use any translation memory mechanism (as far as I know, not even MO, the nonstandard Pootle's version of a translation memory) to propagate the translations which already exist through the material to be translated. Well, fine, but then the JetPack solution by Matjaz will fix it, will it not?

Please note first, the TMX, to be used in the JetPack, comes from outside. It is not an integral part of the Verbatim / Pootle solution. It is a deus ex machina, a translational band-aid - for now at least, if not for some time coming.


Matjaz showed during the demo of his Jetpack solution, how  "Australia" is translated into "Avstralija" with the help of an existing translation memory. Just before this example, however, there was a case of "Argentina" without any suggestion from TMX. Matjaz dropped in the copy of the source and then proceeded  on to the next entry. But hold on a second: where did the target entry for "Argentina" land?  Just in the PO? How adding the new stuff to TMX? After all  it would not hurt to adhere to the Mozilla spirit and expand the TMX with the working being done. I am pretty certain, however, that in the case of Matjaz' add-on TMX get short-changed. 

Here's the situation in a nutshell: external translational sources are tapped to (help Verbatim) help the localizer do the work. The Verbatim per se is not involved,  as it does not as yet have any ways and means to tap into the possibilities, offered by standardized translation memories. On the other hand, the external sources are on receiving end of the stick in the Jetpack proposal, as their initial investment and the use of their assets, as implemented in the Matjaz' proposal, is not  reciprocated by expanding the memory with new translations.

We all have open and free standards for everybody written all over our hearts, flags and banners. Standardized translation memory - free and open-sourced for all - must be among them.

Vito

PS:  one of the listeners, who was evidently new to the subject of translation memories and specifically to the subject of TMX, commented with visible relief "Oh, fine, it's just an XML file". Oh well... XML file is not much, if anything at all, without a corresponding DTD.

To see DTD for TMX files - and implicitely all the work and drive behind it - see
TMX specification by LISA