Filter plugin v. 1.13-1.45 breaks backward compatibility for ID-bound alternative translations

[Manuel Souto Pico]

Background

When we use an Okapi filter in OmegaT, we can bind alternative/ICE matches to the segments key/id or resname, which is (supposed to be) more robust than relying on the actual co-text (previous and next segments).

We can bind the alternative translation of the second segment in the project attached to the tu2 unit's ID NFDBB2FA9-tu2_0.

NFDBB2FA9-tu2_0 is the ID this segment has with plugin versions okapiFiltersForOmegaT-1.11-1.43.0.jar or okapiFiltersForOmegaT-1.12-1.44.0.jar.

Steps to reproduce

1. Translate an XLIFF file in OmegaT using Okapi filter plugin version 1.11-1.43 or 1.12-1.44.
2. Upgrade plugin version: delete plugin v. 1.11-1.43 or 1.12-1.44 and install version 1.13-1.45 or 1.14-1.46
3. Restart OmegaT and open that project again

Sample OmegaT project package is attached.

Expected results

All segments that were translated still are translated and have the same translation, including segments which had an ID-bound alternative translation. Translation unit’s IDs have not changed, e.g. the tu in the example above has ID NFDBB2FA9-tu2_0.

Actual results

Translation unit have different IDs now.e.g. the tu in the example above has now ID P244D057-tu2_0.

Segments which had an ID-bound alternative translation become untranslated or have a different translation (e.g. a default translation without binding properties).

All ID-bound alternative translations become "orphan", which means that they are still in the working TM of the project but do not populate the segment because there's no ID binding.

Related

Ticket #272