Compatibility with XCode xliff export about laurine HOT 3 CLOSED

Hey Donald,

I will look into it later this week, I have few things that I want to investigate and this is one of them. My understanding is that xliff files are only for interchange between you as developer and translator, but they should get decoded back to Localizable.strings once you actually import them, right (please correct me if I am wrong)? So that means that at the end (once you do round of export - translate - import), the input can still get processed from .strings and nothing changes internally?

I have not personally worked with them - I will try and see, if it presents some problem that would have to be solved on generator level.

I will keep you posted (and if you can give me more insight, that would be also great).

Have a very nice Xmas

Jiri

from laurine.

Hi Jiri,

Merry Xmas,
Your understanding of the xliff files is entirely correct. The only thing that makes Laurine hard to use with the built-in xliff system is that apple apparently does not allow you to export to xliff existing .strings files, and will only extract translations from storyboards or from NSLocalizedString calls in the code.
Because of this the only way to work with both systems is to keep the Laurine strings in a manually maintained .strings file (not named Localizable.strings, as that will get overwritten during import of xliff files), and then work with two separate translation files when uploading and downloading from translation management platforms, which is really quite cumbersome.

I haven't been able to figure out a good workaround for this problem, as it seems that the only way to get these tools to properly work together would be to modify the tool apple uses to generate the xliff files to include manually generated .strings files (or perhaps get the Laurine generator to create a source file with dummy NSLocalizedString entries just for the purpose of extraction to xliff).

Cheers,

D

from laurine.

Hey,

If you generate code that calls NSLocalizedString* macros directly instead of using the swift String extensions (like you're doing for ObjC) then Xcode will pick up those string when exporting to XLIff.

The Swift extensions do not bring any advantages anyway.

from laurine.