Skip to content

Translated and final segments in XLIFF 2.0

Given the following source XLIFF 2.0 file:

<?xml version="1.0"?>
<xliff xmlns="urn:oasis:names:tc:xliff:document:2.0" version="2.0" srcLang="en" trgLang="es">
    <file id="12">
        <unit id="1">
            <segment state="translated">
                <source>Foo</source>
                <target>Bar</target>
            </segment>
        </unit>
        <unit id="2">
            <segment state="final">
                <source>Baz</source>
                <target>Qux</target>
            </segment>
        </unit>
    </file>
</xliff>

The result in OmegaT is this:

‌

In other words: A penalty of 40% is applied to the translation of a “translated” segment. It appears (see the segment properties pane) that the XLIFF 2.0 filter thinks the “translation is fuzzy” and that triggerse the penalty.

This behaviour is clearly a bug.

The expected behaviour should be:

  • Segments with state=”translated” should have the properties that currently segments with state=”final” have, namely (or e.g.)

    • the segment is populated with the target text that it has in the XLIFF file, including

      • when the target text is identical to the source text
      • when the target text is an alternative translation (i.e. 1 → many: different instances of a repeated segment have different translations)

  • Segments with state=”final” should have the same properties as state=”translated” and lock the translation

    • (at least if “Protect entries with state='final' (if not set: they can be edited)” is checked in the filter options)

  • If any translation needs to be considered “fuzzy”, it could be the one in segments with state="initial" or not state at all (as long as that can be activated or deactivated with an option in the figure configuration)

‌