XCode 9 localization export/import doesn't include NSLocalizedString() or comments

14
votes

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:

  1. 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.
  2. Comments that are added to the Localizable.strings development-language file seem to be non-existent in the export .xliff file.
  3. 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?

3
iosxcodelocalizationexportnslocalizedstring
Any headway on this problem? None of my localizations are exporting in Xcode 9. – Bill Burgess
No unfortunately not. I used the workaround I've described in the question (2nd point of 'What I've tried') every time I export now... Hopefully that works for you as a workaround too – Thermometer
That sucks. I've had ok luck exporting strings in other projects. I think the issue lies somewhere in the project settings relating to "Absolute Path" or "Relative to Group" for the individual files. I've tinkered with a few settings, but so far, nothing. But I've had issues with this project in the past, but the others are just fine. – Bill Burgess
Not an answer, but Xcode 9.3 seems to have resolved at least some of these issues - certainly importing now seems to have been fixed. – Ashley Mills
Exporting appears to still have issues in Xcode 9.3. Using the Xcode 10 beta exports into a completely different format, but does include strings that were missing in the 9.3 export. 🤬 – Isaac

3 Answers

1
votes

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.

0
votes

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.

0
votes

I finally found the reason of the issue.

enter image description here

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".

enter image description here

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.

  1. choose a source file.
  2. change it to another text encoding.
  3. in the alert window, choose convert
  4. in Xcode, right click the file and choose Show in Finder.
  5. quit Xcode.
  6. open the file with another text editor that can deal with text encoding, mine is BBEdit.
  7. in BBEdit, choose file -> save as
  8. 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.