Comments (5)

With the goal of avoiding to escape <![CDATA the fix looks fine. But I'm not sure it is the right solution for the issue.

This change would put a true CDATA section inside a chunk of data where all other XML constructs are escaped. If we extract the same file to XLIFF 1.2 (using ph, bpt, ept), the resulting XLIFF has no trouble to be parsed as XML, but that seems to be because it escapes ]> to ]&gt; not because it doesn't escape <![CDATA.
I have not tried, but when merging back, I'm not sure having true CDATA sections in the XLIFF will result in the expected ICML data.

I did a test and included this fix in our product. The CDATA section comes out fine after converting back from the translated XLIFF 2.0 to ICML. Also, I've created a local Rainbow build with the updated XLIFF toolkit and here is works ok, too. However, it could be that other tools are treating the CDATA section differently. So, if you think it's safe to escape the closing bracket instead of not escaping the opening bracken, then I can change it.

It looks like with the fix and using it in the RainbowKit steps we end up with a merged ICML where the CDATA sections markers are gone, but because the content in these sections were escaped in the XLIFF file, it ends up escaped in the merged ICML too. I guess InDesign (correctly) does not see a difference.

If you are OK with replacing a CDATA section with an escaped section too, then that should be fine.