No bug, our XLIFF filter does support alternative translations!

An user recently tested our StaX filter for XLIFF and reported that alternative translations were not supported. After investigation it appears clearly that his test contained a mistake, but it is useful to explain why.

I perfectly admit that the bug report was correctly written and the user joined an example project to illustrate his report. But from the beginning I suspected what had happened, and a small look to the sample immediately confirmed my intuition.

Initial test

The user had provided a small XLIFF document, translated it using the Okapi filter with all translations registered as alternatives. He also provided some files in the auto/ folder, probably taken from project_save.tmx, in any case containing also alternative translations. Then he switched to StaX filter and complained that all alternative translations have disappeared.

Sorry, but this is perefctly logical. StaX filter supports alternative translations written by itself, but it never claimed support for alternative translations coming from another filter! The reason will be explained later in this document, this is not a bug (but not a feature as well), but an incompatibility between filters.

Try to do the contrary: do a translation of an XLIFF document using StaX filter, then switch to Okapi, the result will be the same. But will you then write to the maintainer of Okapi filter to tell him that alternative translations are not supported?

Each filter has own way to identify alternative translations. More generally, each filter has own way to analyse the entries contained in the source file and in project_save.tmx (another frequent difference between filters is how they manage tags), for that reason the compatibility between filters is not ensured by OmegaT. And I don't think it will change one day, because switching from one filter to another is not an operation users will do regularly.

Even worse, a filter can be incompatible with itself if you change its options. That is the reason why each change of options is immediately followed by a full reload of the project. For example if you activate "remove tags", then all segments containing tags will become orphans. If on the contrary you had activated this option and suddenly return to initial option with tags, all segments with tags will become orphans. In OmegaT's native XLIFF filter, you have an option to use as a key the previous or next segment: if you activate it after doing a translation in other mode, all alternatives will also disappear. Will you conclude that OmegaT does not support alternative translations? Probably not.

Second test

Finally I did the test I suggested in the previous section: starting with the same project, I removed project_save.tmx, switched to StaX filter, retranslated all. At this step, alternative translations were correctly supported. Then I switched to Okapi, and as I suspected, they disappeared as well.

So, I switched back to StaX filter, moved project_save.tmx to auto folder, and reloaded: auto entries were correctly imported, including also the in-context matches. But entries other auto folders, still referring to Okapi's key, are missing. What happens?

The reason is that the two filters use a different key to identify segments. Segments coming from Okapi filter would contain a key like this:

      <prop type="id">example_01_0</prop>

while entries from my filter will look like that:

      <prop type="id">example_01</prop>
      <prop type="path">/file.po</prop>

Not only you have this added _01 in the id, but the path, which in this example contains the name taken from <file> markup (it would also add the <group> name, if any) is a part of the key which identifies the segment.  If one of the two infos is missing, we are in an orphan entry, even if source matches.

So, if you consider as a bug the fact that entries from Okapi filter are not read by StaX filter, why shouldn't I consider as a bug the fact that entries from StaX filter are not supported by Okapi?