Localization of text strings on iPhone is certainly one of the easier things to handle when working on a game or application. Everything you need is already provided with the iPhone SDK.
However, as you have to use specific functions for localizable texts, you would be well inspired to learn about localization techniques for handling iPhone before even you get started with coding your application.
The process can be broken down in a few simple steps:
1. Use NSLocalizedString while coding
NSLocalizedString is a function that returns you an NSString containing, if possible, the translation of the text that you will give as the first argument, in the user’s default language, or the first language it can find a translation for according to the user’s preferences. If it can’t find any text at all, it will just return the text you provided by default.
Example: NSString * text = NSLocalizedString(@”Text to be translated”,@”Contextual comments”);
Put the string that you would like to see translated in the first NSString argument. You can use the second argument to (later) provide translators who will work on your files with comments
and useful contextual information. If you are using things such as ‘%d’, it’s probably a good idea to use the comments part to explain to translators what it is they are looking at, even if it appears particularly simple to you. Translators often tend to be confused when they see something that is not plain text.
2. Gather your strings
Now that you’ve finished coding your application, you will probably want to gather your strings that need translation and send these out to your translators. Fortunately, this can be done automatically, so you won’t need to fetch everything by yourself.
First, for each language you want to implement, create a corresponding folder under the name languagecode.lproj. For example en.lproj, fr.lproj, ja.lproj etc..
Then, open a Terminal window on your Mac and go to your project folder (if for some reason you’re completely unfamiliar with command lines, a cd Documents/projectname will do it in most cases). Now, let’s assume you used English for the NSLocalizedString arguments. All you have to do is to type the following command:
genstrings /en.lproj /Classes/*.m
The name of the command is pretty self-explanatory: genstrings will generate strings, checking all of the.m source files in your Classes folder, look for NSLocalizedString arguments, and put them together in a file inside the /en.lproj directory. That file is called Localizable.strings, a simple text file containing a succession of lines like this:
/* Comments you put in the second argument */
“String you want to see translated” = “Translated string”
Normally, the left and right strings should be identical for the language you formerly developed the game for. You may want to use to an ID code for your strings, but I would advise you to be careful as they will be displayed in case of problem. So this one is ready to go.
3. Get your files translated!
Now you can send that file to your translators, and ask them to translate ONLY THE RIGHT PART. I’m very serious about this. It’s really a huge unnecessary pain to get files with both columns translated, making the file unusable as it is and making you lose time. Make sure that the name of the files you get is still Localizable.strings and put them in their respective.lproj folders (fr.lproj for French, etc…). There are a couple of tricks to make the process a little smoother for translators, which helps out you, the programmer, in the end. I will offer some tips in a later article.
4. Test, and test a lot
A common mistake that developers make is to just copy the translated files, check a screen or two to make sure the correct language is displayed, and then just assume that the game is ready. It probably isn’t! Before releasing your game, ask a native speaker of each language to check your app thoroughly, and make sure that there are no problems such as:
– Mistranslations or missing translations
– Texts that don’t make sense in their context or that are misleading
– Text overflows (you would be surprised to see how long some short English words can become in, say, German)
– Crashes and over major displaying problems: it’s very easy to delete a ” or alter a %s, which can cause major problems in your app.
The last three reasons in particular can cause your game to be rejected during submission, so when you test your game, take the process seriously for ALL languages, while making sure to utilize native speakers.
Overall, the iPhone SDK comes with all you need to do simple, text localization. If you are unfamiliar to localization techniques and looking for an easy and approachable process, this option is about as perfect an option you could hope for.