I am attempting to export XLIFF files for my app. I currently have 2 .strings files one from a module and one in the app itself, and one .stringsdict file.
When I select the project file, and go to editor > Export for localization only the strings from the first file are included (the one from the other module) in the exported XLIFF file.
I was able to figure this out.
Just a simple oversight, needed to link these localization files to my project by tapping on this "Locaolize..." button in the right pain
Situation:
We use XCode exporting/importing tools to generate localizable files for our translators. This was going fine in XCode 8. Since we updated to XCode 9 we see a couple of problems.
Problems:
When exporting a localization via Editor-->Export for localization...-->Development language only, it doesn't include NSLocalizedString() key/values as it should according to this documentation: When you export localizations, Xcode searches your code for the macros and includes the strings files in the exported localization file for translation.
Comments that are added to the Localizable.strings development-language file seem to be non-existent in the export .xliff file.
When importing a translated .xliff file, XCode seems to delete all the comments that are in the file. It gets replaced by "(No Comment)"
Configuration:
XCode 9.0 (9A235)
Dev language: NL
Localized languages: Base, NL, DE, BE, LU
Objective-C & Swift hybrid project
What I've tried:
I have tried looking at XCode 9 documentation or changelog to see what has changed in Localization, though nothing I can find mentions this change
I can get my NSLocalizedString() strings to show up in the export when I first generate the development Localizable.strings file manually, by using the commandline command find ./ -name "*.m" -print0 | xargs -0 xcrun extractLocStrings -o . (I run it a second time for .swift files as my project is a swift/objc hybrid). Then combine the results, which let my strings show up in the export, however without comments, which are needed as guides for translators.
Question:
Is this an XCode 9 bug? Did I miss any documentation or new feature/option for localization exports/imports? Are there workarounds?
This is an older question, but I had this same issue with Xcode 10.
The solution is to simply place the strings files (e.g. InfoPlist.strings) in the same folder as plist.info. Only then are existing translations included in localization exports.
Previously I had them in a dedicated "Localizations" group. While this works for the localization itself (i.e. when running the app), localization exports seem to only include translations from existing strings files that are "near" plist.info.
What fixed both importing and exporting for me was turning off Base Internationalization by unchecking Use Base Internationalization under Project > Info > Localizations. I set all my translations in code, so I don't need it enabled for my .storyboard and .xib files.
Previously, when it was enabled, the "Localizable.strings (Base)" file didn't have anything in it, but Xcode 8 still seemed to work properly by using what was in my "Localizable (English)" file when exporting. For Xcode 9, if I had the source text in Localizable (Base) then exporting worked fine, but I still had problems with importing.
I am using Xcode 9.4.1.
I finally found the reason of the issue.
The issue exists because Xcode never saved files in the encoding it promised.
There are two places to set text encoding, one is "Default text encoding", which including a "convert existing files on save" checkbox.
There is also a file specified "Text Encoding" on each file when you open it. If you don't specify the text encoding on the file, the "Default text encoding" is used.
However, Xcode never saved the file as it promised. For example, if you choose a file specified text encoding, say to "UTF-16", an alert window shows with "Cancel", "Reinterpret", "Convert".
As the alert said, if you chose convert, Xcode would convert the file to the encoding. However, it didn't.
So when you exporting the translations, the file is opened with the encoding it never converted to and ignored.
You can verify that by these steps.
choose a source file.
change it to another text encoding.
in the alert window, choose convert
in Xcode, right click the file and choose Show in Finder.
quit Xcode.
open the file with another text editor that can deal with text encoding, mine is BBEdit.
in BBEdit, choose file -> save as
Now you can see, that the file is not saved in the encoding as it promised.
Solution
The solution is easy. For files that you specified the text encoding, keep it saved in the encoding that it specified. You can do that with other editors, like BBEdit, by save as and choose the right encoding.
For those files that are not specified text encoding. Be sure them are saved as "Default text encoding". If not, change the "Default text encoding" so you won't need to change each file.
My app is Base language English.
I have added German, and Xcode generated automatically a folder structure that doesn't correspond to what the documentation says. (cf screenshots from Xcode and Finder).
When I run genstrings, it only generates stuff for the english strings (the german remains empty).
I manually copy then the English strings into the German strings, but Export ignores the German strings in the cliff file
What am I missing?
Two things:
First, the de.lproj folder should be at the same level as the en.lproj folder, not a subdirectory of it. Second, you can choose when exporting to XLIFF if you want to export existing translations or the development language only. You may not be seeing that option since the folder layout is currently incorrect.
How to export a base development language XLIFF file from Xcode 6 and then re-import it to configure additional localizations. (E.g. export en.xliff file and use it to create fr.xliff file if you want to add French to an English development language project)
I am posting this as an "answer your own question" because I spent hours trying to figure this out and as far as I can tell Apple hasn't documented it.
The Apple documentation implies it should be sufficient to rename an exported base language XLIFF with a language prefix to be able to import. I.e. if the base localization is English, you should be able to create a file that you can import for French localization just by renaming it from en.xliff to fr.xliff.
Renaming the file is not enough. You also need to add a target-language attribute to every file element.
From this:
<file original="MyApp/MyApp-Info.plist" source-language="en" datatype="plaintext">
To this:
<file original="MyApp/MyApp-Info.plist" source-language="en" datatype="plaintext" target-language="fr">
Now you can import the file to Xcode and it will create the new localization
In Xcode 6 the XLIFF file format is now used for localization of strings. However, I need localise plurals and genders. How can I do this in Xcode 6?
As far as I understand, the XLIFF file now replaces the Localizable.strings file. In iOS 7/ OS X 10.9 we could localise plurals & genders by adding Localizable.stringsdict but this requires a Localizable.strings to exist. But since now there is no Localisable.strings file, how can I get the Localizable.stringsdict file to work?
As of Xcode 6, Apple uses XLIFF as the file format for exporting your project for localization. However, nothing has changed inside the project itself. You should continue using Localisable.strings and Localizable.stringsdict files to handle plurals per Apple's documentation on Handling Noun Plurals and Units of Measurement.
You can refer to this Objective-C project or this Swift project as examples of using strings dictionary files for plurals with Xcode 6.
A little more background on XLIFF and Xcode 6:
XLIFF (XML Localisation Interchange File Format) is an XML-based format created to standardize the way localizable data are passed between tools during a localization process. XLIFF was standardized by OASIS in 2002.
When you click on Editor -> Export for Localization in Xcode, it packages up all of your localizable assets into an XLIFF file that can be handled off to translators for localizing your application's strings. Since XLIFF is a standardized file format, this means translators and translation tools do not need to understand Apple's internal strings format.
Here's an example of the resulting XLIFF document produced by exporting the above referenced Swift project for localization. Now translators can use a translation platform or tool to translate your application's content and return to you a localized XLIFF file. You, as a developer, can then use Xcode's "Import Localizations" feature to import the translated XLIFF file into your project. This will cause Xcode to generate the necessary locale specific strings files from the imported XLIFF.
In short, nothing has changed in how you develop your project. What's been added in Xcode 6 is a new feature to simplify the localization process.
There's one caveat that I should mention though about plurals and exporting for localization. As of Xcode 6.1, Apple's export for localization feature still lacks a way to properly export plurals. This is most likely due to the current XLIFF spec having no standardized way of managing plural representations of a string. There's an open bug with Apple to address this issue.
XLIFF export has full support for plurals starting from Xcode 9
Xcode 9.0 Release Notes:
Added support to XLIFF for exporting and importing stringsdict files, including support for using the correct per-language plural variants. (16785521)