#1070 Unexpected enforced translation (first match) in OmegaT 4.3

[msoutopico]

Steps to reproduce

1. Download and unpack the project attached.
2. Run OmegaT_4.3.2_Linux_64 in console mode on that project, using the java that comes with OmegaT:

/opt/omegat/OmegaT_4.3.2_Linux_64/jre/bin/java -jar /opt/omegat/OmegaT_4.3.2_Linux_64/OmegaT.jar EB-008_pt_OMT420 --mode=console-translate

Expected results

The last translation in the list of matches is used to pre-translate the segment: "Foo". This is the expected behaviour on OmegaT 4.x

Actual results

The segment is pre-translated as "Bar", using the first translation from the list of enforced matches (as is the case in OmegaT 5.x).

Reproduced in some machines but not in every machine. For example, reproduced on a server running version 9 (stretch) of debian, but not in another server running Ubuntu 20.4 LTS.

Note

Documented for the record.

[msoutopico]

Issue reproduced in Linux 5.4.0-88-generic / Ubuntu 20.04.3 LTS focal (running in a VM in VirtualBox).

[Hiroshi Miura]

It might be changed at a commit in Apr. 2020.

@briac_pilpre said in commit message

Fix import from tm/auto/ and tm/enforce/ matches
Only set enforced matches if the segment wasn't already translated or
if the current translation didn't come from an enforced match. It means
that only the first enforced match is taken into account.
Auto matches are only set if no previous translation is present.

[msoutopico]

As far as I know, Briac's changes only affected version 5.5.0 (which works perfectly now), not 4.x. Is that not the case?

[Hiroshi Miura]

As you can see on github commit information, it is affected on 5.5.0...5.3.0.

Are you requesting @briac_pilpre to backport the commit into 4.3.x?

[msoutopico]

Thanks, Hiroshi. That's what I thought (Briac's changes did not affect 4.3.x).

No, I'm not requesting backporting it, I don't know what the issue is in 4.3 or how it should be fixed, but the new functionality in 5.x should not be backported to version 4.x, since expected results are different in both versions and in my book should carry on being different.

The issue is that, regardless of what happens in 5.x, the behavior is not consistent in version 4.3.

[Aaron Madlon-Kay]

I'm not sure what you expect to be done to address it other than "backporting", which means "applying a fix from a later version to an older version".

To be clear, I will not be backporting the fix myself, but others are welcome to work on it.

[msoutopico]

For the record, this issue happened recently again in another project. The enforced match that the translator saw and the reviser approved was not the translation used in the target document (generated with OmegaT on console mode in the server). As we only revise in OmegaT, nobody noticed the discrepancy except the client looked at the target file after delivery. Probably this happens more often than we think but the problem just go unnoticed.

Backporting would entail changing the logic of how x-auto and x-enforce matches are sorted, which would break some of workflows and processes. These would change eventually when we upgrade to OmegaT 5.7^, which should happen soon, but unfortunately it was not possible since I reported this issue last year. In any case, since the issue reproduces randomly, I think it's probably worth not investigating further and just leave it behind when we upgrade to 5.7.x. Fingers crossed that no client complaints in any wrong translation slips through the net.

Thanks.