Table filter: Merge step does not keep edited translation

[Manuel Souto Pico]

I can create the translated XLIFF file from a 3-column CSV file including a source, target and comment.

After I edit the file, I create a new empty Rainbow project, I drag the manifest there and run the post-processing step.

I get no errors but when I look at the done CSV file, the translation seems to be fetched from the original CSV file and not from the translated *.csv.xlf file.

I am attaching a bundle containing the source file, the rainbow project, the filter and the translation kit.

‌

[jhargrave-straker]

Perhaps the same as this issue: https://bitbucket.org/okapiframework/okapi/issues/1153/csv-filter-in-post-processing-rainbow

[jhargrave-straker]

Duplicate of #1153.

[Chase Tingley]

I’m not sure this is a duplicate – I still see this bug, but #1153 has a PR attached to it that was merged a while ago @Jim Hargrave

[jhargrave-straker]

duplicate of #1153

[Chase Tingley]

Reopening - I don't think I was clear, but this does NOT seem to be fixed by #1153

[jhargrave-straker]

Strange, this is exactly the same problem as 1153. I am going to upgrade the integration tests so we can accept an xliff golden file so we will catch these going forward. Will debug and fix this issue asap.

[jhargrave-straker]

I have run these files using the translated string and a golden file (properly translated original). The test passes. I have pushed my testing updates to dev. Check out: net.sf.okapi.roundtrip.integration.RoundTripTableIT#debug

We now have a way to add tests that simulate a real translation. In the future I will use this method as much as possible to give us better coverage.

This looks to be a Rainbow issue - which means it’s probably a Tikal issue too. But AFAIK these clients use the same code to merge as our IT tests.

[jhargrave-straker]

Schedule fix for 1.46.0