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
Can't seem to find a fix for this.
Translators have completed the xliff file with Simplified Chinese. In Xcode I go to Editor --> Import Localizations and select the file which is zh-Hans.xliff. Xcode imports but then names it "(null)" in all areas of the project where it should be "(Chinese-Simplified)" (see screenshot)
When I change my iPhone language setting to Chinese-Simplified the app doesn't pick up any of the translations.
Any idea what I'm missing?
Thanks
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.
So I have a project that has been already localized in the past. But we created some new keys and we want to get them translated seperately.
Also in some languages some keys are missing, so I wanted to find those too. So what I did was to export the xliff files for translation using Xcode's export tool. I've using NSLocalizedString everywhere in my project, so theoretically that should have me covered.
But when I open an exported xliff file (let's say for Italian) I have the following problems:
The section in the xliff file for the localizable file is listed twice. The first time it's like this:
Translations for projectName/Localizable.strings
In this part of the xliff file ALL the translations are missing, even though the localizable file contains translated values for most of the keys.
Then the same localizable file is listed twice as:
Translations for projectName/en.lproj/Localizable.strings
In this case the keys all have their translated values, but if a key is missing from the English localizable file then it's also missing from here.
This is making it a huge pain for me because I'm just looking for the keys that are missing translations, and yet this way it means I have to go through the English list again to make sure no keys are missing.
This doesn't seem normal or practical to me. Anyone have any idea what I might be doing wrong?
The translated keys all work fine on the app itself by the way, tried it both on devices and the simulator.
Thank you for your help.
I do not use xliff exported files to manage my translations so I cannot give you an answer using this.
However, you may be able to solve your problem of finding missing localizations using Localization.strings files.
What you can do is use the genstrings command to generate a Localizable.strings file which will contain all the NSLocalizedString from your code.
To do this, you must pass all for your source files to genstrings.
For example, if you have a swift only project, you can just run this command at the root of your project:
find . -name "*.swift" | xargs genstrings
This will generate a Localizable.strings file you can then compare to your existing Localizable.strings file with a file compare tool like FileMerge. To make this effective, you may need to sort the keys in all the Localizable.strings files, I know a lot of editors can do this (SublimeText is one).
As you can see, the above solution is manual and will prove error prone if you need to do this more than once. In the past, I've automated this using a python script which did the following given the generated Localizable.strings and a localized strings file:
parse the Localizable.strings to get all the reference keys
parse a given localized strings file to get the localized keys
output the unused keys and the ones not translated
Hope this helps!
I'm using xcode 7.3 and this error comes up after xcode crashes during import of .xliff file for localization....I think the crash is an xcode bug but not sure about the error.
I haven't found much information on this exact error. I've checked the infoPlist.strings and it's the same as it's always been: IDELocalizationWork Temporary File
Can someone point me in the right direction? Thanks
I think this is failing because the .xliff import has failed and blown away your infoPlist.strings file - replacing it with that placeholder text.
The placeholder text is not valid as a infoPlist.strings file.
So I don't believe that the infoPlist.strings is "the same as it's always been"