Feature request: Rainbow: Set Byte Order Mark (BOM) when creating xliff files

[GoogleCodeExporter]

When I create a new translation kit, the xliff file (UTF-8 encoded) won't have 
a BOM, no matter if I select "Generic XLIFF" or "OmegaT Project".

There is one reason a BOM could really help: When working together with Trados 
users it turns out that they are perfectly able to import the xliff files 
(either created by Generic XLIFF or by OmegaT Project setting). However Trados 
seems to ignore the encoding information on the xliff header. It simply treats 
the file as ANSI encoded which ends up in defective letters on the target 
file(s) created by Trados.

However it works fine if I put a BOM on the xliff files before I import them to 
Trados. Trados will recognize the UTF-8 encoding and will produce target files 
with UTF-8 enconding (which afterwards can be handled e.g. in OmegaT and 
converted back to the original format with Rainbow).

OK, it's kind of a Trados bug. But it can be fixed by simply adding the BOM to 
the xliff files. It would make exchange much easier.

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?

What version of the product are you using? On what operating system?

Please provide any additional information below.

Original issue reported on code.google.com by m...@sebastianebert.com on 20 Jan 2015 at 9:54

[GoogleCodeExporter]

I also tried to fix this by using Rainbows BOM conversion step, but I did not 
find a way to run it automatically on the target xliff files (even not when 
sending the output of the Translation Kit Creation step to the BOM conversion 
afterwards). Any other workaround?

Original comment by m...@sebastianebert.com on 21 Jan 2015 at 8:14

[GoogleCodeExporter]

Original comment by tingley on 21 Feb 2015 at 11:59

• Added labels: Component-Rainbow
• Removed labels: Component-