Translation registered as same as source not taken into account

[ysavourel]

From Manuel (https://groups.yahoo.com/neo/groups/okapitools/conversations/messages/5564):

"If I register an identical translation (which copies the source into the target), the target file looks alright, but if another reviewer imports the translated XLIFF file in OmegaT, the identically translated segment appears empty. Probably because the filter thinks it's new. Is there any way to overcome this behaviour other than assigning the approved=yes status to the segment?"

We need to check how such translation are passed on to the filter on its way back. This may also be an issue related to segmentation (different between the OmegaT one and the original XLIFF one).

[Manuel Souto Pico]

I can confirm I was not using segmentation in OmegaT. The XLIFF files were already segmented.

I can also confirm that the OmegaT default XLIFF filter does this (apparently) right: the target segment in the target file appears empty, e.g. <target></target>.

[Manuel Souto Pico]

I have re-tested this, four years later.

Given a segment translated with text that is identical to the source text,

a) The segment appears untranslated in OmegaT if if no state/status properties are used:

<trans-unit id="tu1" resname="foo">
    <source xml:lang="en">[some-untranslatable-code]</source>
    <target xml:lang="es">[some-untranslatable-code]</target>
</trans-unit>

However, b1) the translation will be loaded correctly if the segment has the translated state:

<trans-unit id="tu1" resname="foo">
    <source xml:lang="en">[some-untranslatable-code]</source>
    <target xml:lang="es" state="translated">[some-untranslatable-code]</target>
</trans-unit>

or b2) if it is approved:

<trans-unit id="tu1" resname="foo" approved="yes">
    <source xml:lang="en">[some-untranslatable-code]</source>
    <target xml:lang="es">[some-untranslatable-code]</target>
</trans-unit>

So, even though one would expect the translation to show up without any states/status, taking in considering the state="translated" property could be an acceptable workaround, as long as OmegaT adds that state in the translated segments of target XLIFF files.

It seems there’s been some work in that regard on the default OmegaT XLIFF filter: https://sourceforge.net/p/omegat/feature-requests/1506/

However, similar work on the Okapi XLIFF filter seems on hold: https://bitbucket.org/okapiframework/omegat-plugin/issues/18

I would say that resolution of issue 23 is contingent on resolution of those two issues (on both XLIFF filters).

‌

‌

[Kuro Kurosaka (BH Lab)]

It seems this is happening within AbstractOkapiFilter.processFile. This if condition includes the line that, if the target has the same content as the source, it regards there is no target.

https://bitbucket.org/okapiframework/omegat-plugin/src/23ab312148a3dc7cc3a9616534b085a3a8d2f740/filters/src/main/java/net/sf/okapi/lib/omegat/AbstractOkapiFilter.java?at=dev&fileviewer=file-view-default#lines-423

                            boolean hasTarget = (( trgSeg != null )
                                && !trgSeg.text.isEmpty()
                                && (( trgSeg.getContent().compareTo(srcSeg.getContent(), CompareMode.CODE_DATA_ONLY)!=0 )
                                    || approved || impliesXlation(state) ));

We could simply remove it but I’d like to know why this line was inserted to begin with. Git says @ysavourel inserted it. Do you remember why?

‌

‌

‌

[Kuro Kurosaka (BH Lab)]

I changed this line to force hasTarget to be true. But OmegaT UI still show these lines where target=source as untranslated. So I think there is a logic in OmegaT side that compares the target and the source, and consider the target not translated if it is same as the source, in absence of the state or approved attributes. I couldn’t spot the line that do that in OmegaT, however. Anyway I am not sure if this is an issue in Okapi/OmegaT filter.