This is ideally what I'd like to do:
Localizable.strings
and StoryboardsNSLocalizedString
, using keys of the form fooViewController.barLabel
, being diligent and adding proper context comments with every keyxliff
file (Click on Project, Editor/Export For Localization..., choose "Development Language Only")xliff
file in a tool like Counterparts or Xliffie or even something web basedfooViewController.barLabel
keys, and re-save the en.xliffnl.xliff
file from the original en.xliff
and add Dutch translationsxliff
files into Xcode and have it create the appropriate .strings
files for both Dutch and English, for both the keys defined in code and those in the Storyboard; commit the new .strings
files into my source repositoryen.xliff
again as the source of truthen.xliff
and nl.xliff
files with current translations, having a tool highlight which keys had been added or removedxliff
files back into Xcode which updates the .strings
files I can then check back in to my source repositoryDoes this make sense? Is this a reasonable thing to want to do? I think so, but it doesn't work.
Here are the problems I ran into:
xliff
format can mark a key as translate=no
, but there is no way to annotate that in Xcode (ideally, Xcode wouldn't export keys marked as placeholders at all.)en.xliff
file. There is a way to change the target language (or, at least, create a new file with the target language set to EN
) in Counterparts but I couldn't find any way to do this with Xliffie.en.xliff
file with updated keys, Xcode told me "Localization failed reading "[...]/Supporting Files/en.lproj/Localizable.strings, Please address the issue at file location 782"
at which character location I found... an apostrophe. Xcode can't export an xliff
file if the source .strings
file contains an apostrophe. What in the actual F...?!fooViewController.barLabel
keys with the English translations and looked like they were trying to tell me I had no English translations. Upon attempting to import the en.xliff
back into Xcode it told me I had no translations for all but the new keys and when I went ahead, it wiped the existing translations from the en.lproj/Localization.strings
file.This is a mess.
Translating labels in Storyboards without being able to manually set their keys, add translator comments or mark particular labels as placeholders not-for-translation just doesn't work. We've resorted to connecting every label to an @IBOutlet
and setting its translation in viewDidLoad()
with NSLocalizedString
.
Xcode choking when it attempts to export a .strings
file containing an apostrophe beggars belief.
It also seems there's an underlying assumption that if the "development language" in Xcode is English, then the developers are in charge of the English translation. I can imagine no context outside that of a single-person indie developer shop where this is true.
Finally, it also seems I'm missing something about how the tools I've attempted to use structure their workflows. If anyone could enlighten me I'd be quite grateful.
Has anyone managed to construct a workable localization workflow where the developers aren't charged with ultimate editing control over the "development language" and the .strings
files checked into the repository are the source of truth?
We've resorted to connecting every label to an @IBOutlet and setting its translation in viewDidLoad() with NSLocalizedString.
You are doing that right. Seriously. Wrap your development process around it and you'll get way better off than trying to adopt the mess that the Storyboard localization evolved into.
It solves pt.4 - you decide what you put in the Localizable.strings
It solves pt.5 - comments are there by default, for everything that you decide to be localizable. Now to be honest, XCode7 has added a possibility to add notes to resources. Don't use it. For some reason only known to Apple, it is not available for all types of resources. You can't annotate e.g. table headers and footers. More on that later.
I recommend making your own NSBundle.localizedStringForKey
wrapper (macro) which provides the value
. NSLocalizedString
sets value
to empty string, essentially forcing key
to be used as the fallback translation content. Of all the already existing questionable macros, NSLocalizedStringWithDefaultValue
takes the value
but also all other 4 required parameters - not something you would like to use often.
Step 10 is caused by you trying to import a Base localization - the fact that it's english does not make any difference. If you want to "translate english" (i.e. professional correcture), you must add english as another standalone localization on top of Base. Technically it boils down to the Base xliff missing <file target-language>
and <target xml:lang>
properties. Due to some strange xliff mess similar to yours, i had to add those once manually. You don't want to do that :)
Re apostrophe glitch: iOS localization is an unreal garden of wonders, but i'm prety sure it's not THAT unreal :) Try opening the file in some hexcode displaying editor - what XCode renders may be quite different from what the file really contains.
- ... even something web based
That's Crowdin for us and it nicely shows everything wrong with Apple's idea of Storyboard localization. Translators need 3 things to do their work professionally: context, context and context. Apple seems to think that translators will gladly install the app, play with it and ask questions to get the context. Because, by default, there is no human context in xliff export. Now with Xcode7, you can add notes, but weirdly not everywhere. Even where you can, your note is appended at the end of already long <note>
string with machine context - understandably needed for storyboard import matching, but useless and obstructive for the translator. Furthermore, in reality, the translator is a pro agency, or a language enthusiast. Even if you had a luck with properly equipped enthusiast, or you paid the agency premium for getting an extra customer care, you enter The Hostile Desert Of Beta Distribution Options. Apple's funny Testflight reincarnation will either need the translator to register as an Apple developer, or waiting for Apple's beta review - depending on how early in the app life you need the translation.
BTW i like your blog. Sometimes i feel like dumping my sourness and misfeature fatigue too, but never got as far as you :)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With