Using Xcode 7's localization export workflow, I can export to Xliff, which can be provided to translators, who will give back a translated version, which we import again.
However, how do I generate one for the original development language?
I want to do this so that I don't have to maintain my development language strings files manually by hand.
Here is the scenario:
I start with no strings file in my project, just Swift code which uses the NSLocalizedString
static let something = NSLocalizedString("something.hello", tableName: "MyStuff", value: "Hello world!", comment: "some comment")
From the project settings, I choose Editor -> Export for Localization. Because I have no existing strings files, when I export, there are no options. Just a "save as" prompt.
This will perform an Xliff export from the original source code. (Same as when you choose "Include: Development Language only" from the prompt when other localizations already present). The Xliff looks like this, with only <source> tags, and no <target> tags.
<trans-unit id="something.hello">
<source>"Hello world!</source>
<note>some comment</note>
</trans-unit>
The Xliff file is modified by translators, and translated to simplified chinese
The translated Xliff file is re-imported into project via Xcode
This creates the MyStuff.strings file for simplified chinese
Problem - when I run the app, the app will use the chinese strings file, even when language is english, because an english file doesn't exist. It doesn't seem to use the default value anymore. This means I need an english strings file too.
How can I generate an english (the development language) version of the strings files through the import/export process? Xcode doesn't let me "export" in the original development language. So I can't re-import it to create the strings files.
Note on genstrings
In the documentation for Separating User-Facing Text from Your Code, it says "Alternatively, you can generate the development language strings files from NSLocalizedString macros directly, as described in Creating Strings Files for User-Facing Text in Your Code." , which tells you to use genstrings
However that genstrings no longer works for Swift when you specify the tableName.
It's my understanding from what I've seen on SO that multiple radars have been filed, but it seems Apple is no longer supporting it.
I've worked out the problem.
It's doesn't seem necessary to generate strings files in the development language. This must be why the capability doesn't exist in Xcode.
My problem was that the app didn't think that my development language (english) was supported, so it did further fallback, and ended up picking a language that my app was localized for (in this case, chinese).
By adding a file localized for english, and ensuring there is an en.lproj folder in the bundle, it infers my app is localized for english, and will correctly use the default values specified in the NSLocalizedString calls.
This means I don't need a seperate copy of the english strings files. Which is great, because I won't need to keep that up to date as the app changes. The source of truth is the Swift source code only.
This link was helpful:
How does iOS determine the language for my app
Related
Following Ray Wenderlich tutorial (https://www.raywenderlich.com/180356/ios-internationalization), the Localizable.strings is as following. Notice there is no Localizable.strings(Base)
But in some other tutorials, they would use Base instead of English, so did I in my project as follow.
My iPhone's preferred language order is English then Chinese and is currently set to English. But whenever I run the app, it goes to Chinese except when I explicitly edit scheme to ask Xcode to run it in English. Does that mean I should have Localizable.strings (English) instead of Localizable.strings (Base)?
Another question, I have Main.storyboard (Base) and Main.strings (Chinese (Simplified)) under Main.storyboard. But no matter what I do, the storyboard always shows up in Chinese version. What have I done wrong?
=== Update ===
I played around with it (simply remove and recreate, nothing changed), and then magically the localization works as expected: The app default to English, which is my system language, and switches to Chinese when I edit scheme. However, now my storyboard is stuck with (Base) version no matter what I do.
I am no expert on this, but as I understand the Base file is a fallback if your app doesn't have a Localizable.strings file for the user's device language.
So if you have English and Chinese as localization files, but your preferred languages are German and Japanese, the system will check the Base file for strings.
In your case you have Chinese and the base files. English is not found, so it takes the other preferred language (Chinese). Therefore the base strings are not used -- the app defaults to the Chinese localization.
To solve the problem, you need to make an English strings file in addition to your base strings.
I have a JSON file containing a dictionary with strings in an iOS app. Our dev team sends off our app to a localization team via an .xliff file. Is JSON compatible with localization in iOS? Or should I convert it to some other file type?
I would suggest using the Apple-provided file type of .strings
Localization in iOS is actually really great. You have a .lproj folder for each language that you are using, prefixed by the ISO 639-1 language codes.
Within each of those folders, you can provide a .strings file that would contain all of the localized strings for that language.
For example, your en.lproj could have a "Localizable.strings" file as follows:
"Hello" = "Hello";
"World = "World";
And your es.lproj (Spanish) could have a "Localizable.strings" file as follows:
"Hello" = "Hola";
"World" = "Mundo";
You would then start using NSLocalizedString for all of your user-facing strings throughout your app. It might take a bit of leg-work to get started, but it is a very helpful system that is already built-in. Take a look at NSHipster's NSLocalized String entry for a good read about how this works and how it might benefit you.
Links valid as of July 30, 2015
My app only supports english. I am using base internationalization (English- Development Language)
Steps I followed:
1. Separate out user-facing text using NSLocalizedString();
2. Using Genstrings command i have added Localizable.strings in base.lproj.
3. In Editor >> Export for Localization
4. Save en.xliff and provide to translator team for updating English content
5. While importing updated en.xliff file, i got below error.
Might be i doing in wrong way to export/import for English. Please suggest me the best approach for handling English content. (development language).
It is not obvious to me what you want to achieve: do you want to have your strings translated into some language other than English, or do you want to run your strings through an English linguistic review? For the first case the error message is pretty clear: check if the file element in your translated XLIFF file has a target-language attribute and add it if not. Details about this attribute can be found in the XLIFF spec here.
If adding this attribute is not enough you may also want to look at the answer to this previously asked question.
For the second case XLIFF is not really a good format.
I've looked through some internationalization documentation and videos on apple developer, but I never found an explicit answer to that question. In Apple's tutorials I see the Base.lproj folder alongside en.lproj and zh.lproj -- the example translation (localization) is from English to Chinese. But they tell me that there's a file en.lproj/myStoryboard.strings, and that is confusing. I can't see the point in creating an English localization for the storyboard (that is already in English).
So my questions are if the user will ever see the strings in the Base.lproj/myStoryboard.storyboard?
Do the strings in that file have to be the default strings that are shown to the user if the system cannot find the user's preferred language folder in my bundle?
Can I explicitly say "never use Base.lproj/myStoryboard.storyboard, always fall back on en.lproj/myStoryboard.strings"?
In other words:
Let's say I want my app to display in English whenever the user's language isn't available, but that my Base.lproj/myStoryboard.storyboard is in Swedish. Do I then have to localize the Base Storyboard to sv.lproj/myStoryboard.strings and translate all strings in the Base storyboard to English to accomplish this?
In my case, XCode 5 didn't create a en.lproj/myStoryboard.strings, there's only the original storyboard in the Base.lproj folder. Maybe it's an old XCode issue?
Try to remove that file and see if your app gets along with Base.lproj for default, English strings.
Your Info.plist file should have an entry Localization native development region, which points to the lproj folder to be used in case the required string doesn't exist in the preferred language.
I'm not sure about this, but I think you have to use en and UI with a Base.lproj would automatically fallback to Base.lproj.
Does that help you in any way?
So my questions are if the user will ever see the strings in the Base.lproj/myStoryboard.storyboard?
It is the default to use those strings for the development region localization, which is typically English. If there was a matching strings file for english, it would supersede the strings in the storyboard. This is typically redundant, so it isn't normally used. If you really want all of your languages to be handled identically, you can do this.
Do the strings in that file have to be the default strings that are shown to the user if the system cannot find the user's preferred language folder in my bundle?
These are unrelated concepts. The strings embedded in the storyboard are equivalent to having ones in en.lproj. After that, language fallback works the same as without Base.lproj.
Can I explicitly say "never use Base.lproj/myStoryboard.storyboard, always fall back on en.lproj/myStoryboard.strings"?
If you have en.lproj/myStoryboard.strings, and english is the development language, they will always superseded the strings embedded in Base.lproj/myStoryboard.storyboard for English. Including when English isn't the preferred language, but ends up being chosen as the fallback language.
I decided to merge several of my projects into one project using the same code base and use different targets for the different versions of my application.
My application is translated to 7 languages with English as default. The other languages are: Swedish, Dutch, German, French, Polish and Spanish. The translations worked like a charm before. I am using the NSLocalizedString and have my Localizable.strings which is translated.
However, now that I merged my projects together, and also added the InfoPlist.strings file, the application incists on using the default texts (English). When I start the application and get the "share location" question, I get the question in the localized language (So the OS does get the localization), but the rest of the application is still in English.
The files are correctly translation and have no errors. I have tested several languages, but all are in English.
If I set the CFBundleDevelopmentRegion to e.g. Swedish, the whole app is in Swedish instead. So the localizations work, but the app ignores the system setting.
Am I missing something?
I found the answer to my problem. I have several strings files, one for my app translation, and one for each target called InfoPlist.strings which contains just CFBundleDisplayName and CFBundleName for localized app name. These cannot be included into the Localizable.strings since these are different for each target.
I removed the InfoPlist.strings files from my project and now the app is localized again.