This blog post is outdated for swift. See this update for a worklow with swift. If you’re still using ObjC, the following workflow is still fine to use.
For a long time, it wasn’t clear to me how to deal with the localization of Xcode projects in an acceptable way. I’ve tried some different ways in different projects but each one of them was inconvenient and had serious drawbacks. While working on the localization of iZurvive. I’ve tried yet another workflow that turned out to be pretty applicable in practice.
What was the reason why I kept searching for other ways to do localizations? Here’s what I think is important:
In a discussion on stackoverflow, user nfred on posted a Python script for generating localizations, but it was lacking some essential features. Based on that I wrote my own script that supports the following features
You can get the script here: https://github.com/iv-mexx/update_localization
In the past it was necessary to duplicate storyboard and xib files in order to localize them. Although generating and runtime selection of these localized files was done automatically, you had to keep track of changes in the interface manually, just like with genstrings. I somehow have the feeling that one is supposed to finish the whole app first and then localize it completely rather than keeping localizations up to date, but what would you do when you deliver an update to the app?
Anyway, in a recent release of Xcode, Apple has added the possibility to localize interface files with a strings file as well using ‘base localization’. The tool ibtool generates all the strings from a nib. It even has the support for incremental localization somehow but since I already had my script, I’ve extended the script to work with for interface files as well. Keep in mind though that base localization is only supported in iOS 6 and above. (We’ve had a serious crash-bug in iZurvive on iOS 5.1 because of this)
One thing to keep in mind is that ibtool creates the comments automatically, they don’t provide any context. I’d suggest that you provide them by hand in the generated strings file. The update_localization script gives priority of already existent comments to new comments for interfaces in order to keep your comments.
Maybe there is another way to provide comments for interface files? If you know something about that please let me know in the comments!
Searching for best practice tips, I found threads like this discussion on StackOverflow. One Suggestion was to use short keys and use the comment as a default value. The author redefined the NSLocalizedStrings macro to automatically use the comment as value if the value equals the key which indicates that the values has not yet been translated. I liked how easy this was to use and tried it, but soon I’ve realized that a real comment describing the context of the string is crucial and a localization file without these comments is practically useless for an external translator.
My current workflow ist the following:
So far, this workflow has worked out quite well for me. What do you think, are there any improvements that could be made? Let me know in the comments!
Markus is a technical mastermind and one of the founders of Innovaptor. He studied Computer Engineering at Vienna University of Technology and contributes a valuable diversification to Innovaptor's qualifications. Markus is eager to find innovative solutions to complex problems in order to provide products that are tailored directly to the customers' needs