search

remuslazar / osx-xliff-tool

OS X Application for editing XLIFF files generated by Xcode
77 stars 20 forks source link

Export and Import of Strings with \n #26

Closed lemkesoft closed 5 years ago

lemkesoft commented 7 years ago

I have here some issues with the import of the XLIFF file after the translation. The problem seems to be caused by \n written as real returns in the XLIFF file.

I checked the export from Xcode. It does already export the \n in the strings as real returns. So, can maybe the xliff tool convert them back to \n upon export?

Idomo commented 5 years ago

@remuslazar Have this problem too, please fix this and make it the beast xliff tool ever :)

remuslazar commented 5 years ago

Thanks for the bug-report!

I was able to address the issue (see linked PR) and there will be a new version available soon (including this fix and also other pending pull requests). I also did the Swift4.2 Migration changes, so the whole codebase is much more up-to-date now.

tl;dr

The issue is that newer Xcode versions do encode new-lines „\n“ characters as &#10; (only for XML attributes, in our context the "id" attribute of the <trans-unit> element), for example:

            <trans-unit id="Label 3 Line1&#10;Line2&#10;Line3">
                 <source>Label 3 Line1
                     Line2
                     Line3</source>
                 <note>My Label3 Text</note>
             </trans-unit>

xlifftool/XMLDocument class converts the entities to „real“ new lines characters and therefore the export looks like

<trans-unit id="Label 3 Line1
Line2
Line3“>

which confuses Xcode which behaves internally differently, unfortunately.

Because I was unable to find another more elegant way of telling the XMLDocument object not to convert the entities prior to the import/export, I did a workaround/hack, escaping all occurrences with some magic string sequence, doing the opposite after the export, so everything looks nice and dandy. There is also a unit test so catch potential regressions in future versions..

See https://github.com/remuslazar/osx-xliff-tool/pull/30

@lemkesoft , @Idomo to alleviate the issue (and also be able to use the current xliff-tool version), just use a „stable“ identifier for the trans units, I mean, instead of using

NSLocalizedString("my String\nwith new lines", comment: "...")

use instead

NSLocalizedString("my.identifier.without.newlines", value: "my String\nwith new lines", comment: "...")

Doing so, the first parameter will be the translation transUnit identifier and this will not cause any issues later on.

Having stable identifiers is a cool thing anyway, not only because of cosmetic reasons but because so the develop is able to change the "dev lang" labels without running into issues when existing translation being lost for the specific label..