iPhone Localization TipsMost of the effort in localization involves changing words. You say "white;" Italians say "bianco." In localized apps like this one, Cocoa helps you pick the right word with a file called Localizable.strings. This file acts as a small database that maps keys to values. If you look up a string with the key White, it will return the value Bianco on phones that are configured to use Italian. If any other language is selected, "White" is returned.
Actually, it's a lie to say there's one Localizable.strings file—multiple copies exist, one for each language. If you open the Flashlight Pro project in the Finder, you see English.lproj and Italian.lproj in the Resources→Localizations folder. These folders contain the files used in each language.
NoteThe default language is defined as English in the Info.plist file.
When NSLocalizedString() is used, you performed the lookup. Here's a example:
NSLocalizedString(@"White", nil)Italians will be loading files from Italian.lproj, so this line in Localizable.strings will come up as a match:
"White" = "Bianco";Other users will have loaded the same file from English.lproj, so this will be the match:
"White" = "White";When you're doing localization, make sure that words don't creep into other parts of your application. A great example is images: If the source text for the graphic is buried in a Photoshop layer, you'll find that your graphic designer isn't a very good translator and that your translator isn't a very good artist. Keep the text separate and your life will be much easier.
You have two major hurdles when doing localization: finding a native speaker to do the translation and testing the final product. As you look through the Italian words in Localizable.strings, it looks great. There are plenty of accents and cool-looking foreign words. There's just one problem: A native speaker did not do this localization.
Don't use automated tools or get your second cousin's best friend who spent 6 months overseas to do the translation. A native speaker will be able to tell that it's wrong and you'll make a bad impression. For many users, a bad localization is harder to use than the original English.
NoteYour humble author spent several years living in Italy. This language perfect he has not, but good it is.
Once you've done the translation, you encounter the second problem. Unless you're an amazing polyglot, there's no way you can know if the localization is correct. You need to find someone who speaks the language and to get him or her to test it for accuracy.
You should, however, verify that the localization is functionally correct. You want to make sure that all the words have matches during the lookup phase.
The easiest way to do this is by using the Settings application in the Simulator. Tap the settings icon, and then pick the first item in the list (General). In the next menu, tap the third item from the top (International). Then pick the first item in the list (Language) to see a list of all available language settings. (Knowing the relative position of all these buttons is important: You need to know which buttons to push in order to switch back to English!)
While you're changing your language settings, try setting Italian and running the Safety Light application. Seeing the localization in action will give you a better feel for how it all works.
NoteWhy go through this hassle? About half of your revenue in iTunes will come from outside the United States. The more you cater to these users, the more you sell. No one ever promised that making money would be easy.
Sometimes differences in language cause view layouts to change. For example, the button width for "Tap to close" in English is going to be very different than its literal counterpart in German: "Zum Schließen antippen".
One approach your translator could take is to find a similar meaning that's shorter. For example, "Tap to close" could be shortened to the German word for close: "Schließen". The width of both phrases is similar, making the visual design easier without sacrificing comprehension.
Another approach to handling phrases with different lengths is to make views adapt to different sizes. The IFInfoView that drops down from the top of the screen is an example. It adjusts its height based upon the message you want to display. If it encounters a long phrase in German, it just displays multiple lines.
NoteApple uses this technique with some of its system controls. For example, "Entriegeln" is displayed instead of "slide to unlock" when you press the Power button on the device.
A final technique to aid in localization is to use symbols whenever possible. If you've ever traveled abroad, you know that it's much easier to encounter restroom doors with pictures of men and women rather than signs saying "Damen" and "Herren." Hope you guessed right!
This approach was taken with the settings view. The brightness and flasher speed use icons instead of words. No translation is required and users in all languages can understand the function of the sliders.
Despite all your efforts to just translate the words, sometimes localizations require a separate NIB file. For example, if you're doing a help screen for a game, you're going to have a lot of text that flows around images and controls. It's easier to change the layout for a whole screen than it is to adapt the text to a single layout.
The AboutView.xib file is an example. You'll see that the file appears in both the English.lproj and Italian.lproj folders. Cocoa loads the correct NIB based upon the user's language settings. You can change any part of the layout; just make sure that the actions and outlets are maintained. If the connection between a button and its action is broken, you have a bug that only users of that language will encounter.