Rainbow: table to XLIFF to table results in empty target column.

[Former user]

I use Rainbow 6.0.28 on Windows, with Java 1.8.0_60. Steps to reproduce:

1. Add input_example.txt to input list 1. This is a simple csv file, containing 4 columns, with single tabs as delimiters.
2. Set [e-mail] as the filter configuration. This is an adaptation of the default csv filter, with columns 3 and 4 mapped to source and target, respectively.
3. Select Utilities > Translation Kit Creation.
4. Generate a Generic XLIFF package.
5. In the resulting XLIFF file, change some of the target text.
6. Add the manifest file to input list 1.
7. Select Utilities > Translation Kit Post-Processing.
8. Execute the pipeline.
9. Open the resulting translated file.
10. Notice that the 'target' column has disappeared completely.

If this is not a bug and I am simply doing something wrong, please let me know.

[YvesS]

I can reproduce the issue. Even when I fix the parameters file to set the source field of the target to 3 (instead of 1).

It seems to be related to empty targets, as when a target exists in the original file it gets saved (modified or not).

[Wouter Veeken]

Hi @ysavourel, I am the OP. Thanks for responding. Do you know if someone will be trying to fix this? Can you suggest a good workaround? I worry that just putting a dummy character in the target column will lead to problems in various CAT tools and TMs...

[YvesS]

I'd like to fix it. But I don't have any time. I'll try to find some time in the coming days. Yes, a dummy character would likely have some side effects.

[Wouter Veeken]

Hi @ysavourel, any news? :)

[YvesS]

I've managed to find the time to make a unit test that reproduce the issue and isolate where the problem is: Basically the TU is flagged a referent and the GenericSkeletonWriter from which the CSVSkeletonWriter is derived is (correctly) skipping over such entries. I haven't written this filter and it's a complicated one (lots of derived classes), so I'll have to dive more into the code to see if it can be fixed.

[Wouter Veeken]

Thanks for the update, @ysavourel! It would be really great if this can be fixed; I have some colleagues that will be helped tremendously. :)

[Emre Akkas]

Here is a working (though relatively ugly) workaround. I tested and it works.

1. Use your original tsv/csv to the do the conversion, translate your XLIFF
2. Under the project/original folder copy your source column to target
3. Run translation post processing

Obviously, if your original csv/tsv does not contain any translated text you could do step 2 at the very beginning,

[YvesS]

Yes, that will work as a work around. Thanks.

[YvesS]

Added a unit test for this (testTrgAtCol4_Issue511) in CommaSeparatedValuesFilterTest.java

[Fredrik L]

Allow empty targets (enclosed with quotes). Resolves Issue #511.

Note: It works if there are enclosing qualifiers without content but not when there are no qualifiers at all. That will take a lot more time to change.

→ <<cset 72a725175e62>>

[Wouter Veeken]

Thanks, @fliden! Does this mean the fix is in the current downloadable version or will I have to wait until a new release is issued?

[YvesS]

The latest development version is build every night. You can get it here: https://okapi.ci.cloudbees.com/job/okapi-snapshot/

[Wouter Veeken]

Great news @ysavourel, thanks!

[Chase Tingley]

Allow empty targets (enclosed with quotes). Resolves Issue #511.

→ <<cset fec2fe30c7ed>>

[Former user]

Hello guys,

Is there any update on empty targets with no qualifiers? If not, is there any workaround that would work without modifying the source document? ( without copying source into target etc. )

Thanks.

[Chase Tingley]

Hi @kaandemirel,

Can you open a new issue on this with complete steps to reproduce? This bug is a couple years old and I admit my memory of it is pretty fuzzy.

[Former user]

Okay, sure. Will do in a bit.