Broken Post-Processing of Java properties when @translate is set to "no" in XLIFF

[Former user]

Original issue 298 created by frank.kuh... on 2012-12-14T14:41:21.000Z:

What steps will reproduce the problem?
1. Create a project with a few pre-translated items (I used a pipeline consisting of ID-Based Copy and Translation Kit Creation to do so)
2. Make sure that any existing translations are set to translate="no" in the resulting XLIFF.
3. Run the Post-Processing step

What is the expected output? What do you see instead?
Of course I expected the original Java properties in the output. However, Rainbow threw errors and complained about IDs in the original file and in the translated file beeing out of sync.

What version of the product are you using? On what operating system?
I have tested this with 6.0.19 on Win XP. Previous versions of Rainbow show the same behaviour.

Please provide any additional information below.
It took me some time to find a workaround: Simply delete all @ translate attributes from the XLIFF files. When not translate="no" is present, conversion back to the original format works as expected.

[Former user]

Comment 1. originally posted by @ysavourel on 2012-12-14T16:48:24.000Z:

I think the issue is coming from the fact that the merge is done based on the extracted file. Since the extracted file didn't have those translate='no' things got de-synchronized. We'll try to reproduce and allow for this.