Issue #274: Translated and final segments in XLIFF 2.0 (okapiframework/omegat-plugin)
msoutopico
https://bitbucket.org/okapiframework/omegat-plugin/issues/274/translated-and-final-segments-in-xliff-20
Manuel Souto Pico:
Given the following source XLIFF 2.0 file:
```xml
<?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.
* 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\)