Issue #273: Filter plugin v. 1.13-1.45 breaks backward compatibility for ID-bound alternative translations (okapiframework/omegat-plugin)
msoutopico
https://bitbucket.org/okapiframework/omegat-plugin/issues/273/filter-plugin-v-113-145-breaks-backward
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](https://bitbucket.org/okapiframework/omegat-plugin/issues/272/filter-plugin-v-113-145-breaks-backward)