As a native of a relatively typical middle-American town, it’s easy to forget that most of the world doesn’t speak English. The iPhone is an international phenomenon though, and millions of its users either don’t speak English or don’t speak English as their first language. Even though language may separate de us, the intimate relationship that people have with their iPhone is universal. iPhones go everywhere with their owners and they contain incredible amounts of personal information. People feel a connection with their iPhone, so it makes sense that they want to operate it in their mother tongue.

With this in mind, I’m translating the next version of Action Lists into a Dlá?-kovica handful of languages. For those of you unfamiliar with the process, getting your iPhone app translated actually involves two separate processes. cheap NBA jerseys “Internationalization” is the process of tagging the strings in your program that you want to have translated. wholesale mlb jerseys “Localization” is the process of presenting translated versions of those strings to the user. I’m not going to go into great depth about the process of internationalizing and localizing your app (Apple has pretty good documentation on the subject), but I will share some of the tips I discovered while localizing Action Lists; things that I wish I had known when I started.

First of all, if you haven’t already, read Wil Shipley’s excellent blog post on his localization strategy. The main idea is to minimize the number of files that you have to maintain. In a typical app, that might be a .strings file for the app, another .strings file for the settings bundle (if you set application preferences through the Settings app), and then localized versions of each NIB file that was created in Interface Builder. As Wil points out, maintaining multiple versions of NIB files is no fun at all. Any change has to be replicated in each localized version of the NIB. His solution was to create scripts that pull out all the strings for localization. His scripts work well enough for him (as he points out, he’s localized some high profile Miami Dolphins Jerseys software using them), but it still seemed like a pretty fragile set up to me. My solution to localizing NIB files was to avoid the problem altogether. I simply didn’t rely on strings set in my NIB files. Instead, I explicitly initialized each string in the NIBs using an IBOutlet in the source code. That way the strings in my interface were internationalized in exactly the same way as other parts of my code.

While we’re on the topic of NIB files, keep in mind that when a string is translated to another language, it’s length is going to change. When you use Interface Builder to layout your labels, buttons, and other interface elements that contain text, make sure that you leave more room than you think is necessary. It’s not unusual for an English string to grow up to 150% of its original length when translated to a European language. By making your buttons and labels bigger than is needed for English, you’ll make your interface a little more flexible and spend less time fixing your interface layout later.

Now that we have the problem of NIBs out of the way, we can turn our attention to internationalizing the source code. Internationalizing strings in your source code is a pretty straightforward process. You need to identify every string that the user might encounter, and wrap it in the NSLocalizedString macro. NSLocalizedString takes two arguments. The first is the string that you want to internationalize. The second is a comment string that the translator can read in the .strings file. Although you can provide nil as the second argument, don’t do it! Making sure that each string has a comment is going to be a bit of pain right now, but it will be a huge help later. When you turn your strings over to the translator, he’s not going to have all of the context that you have. When he sees the word “Contact,” should he translate it as a new telephone number, or the state of two things touching? It might be obvious to you, but it won’t be to your translator. So comment the heck out of your strings. Give context for the string, note any length restrictions that exist, and give synonyms for any terms that might be ambiguous. Also, if some part of the string shouldn’t be translated (like the app name), note that too. Really, you might as well do all this up front, because if you don’t you’re going to spend even more time sorting it all out later.

There’s one last step to internationalizing your app, and that’s extracting the strings in your settings bundle if you set application preferences in the Settings app. Unfortunately, there’s no really good way to automatically extract all the strings from your settings bundle that the user might see. And you definitely don’t want to translate the text keys that are used to identify each setting in wholesale jerseys the source code. To make this process easier, and to reduce the chance of error, I ended up writing a perl script that extracts all the user-facing strings, avoids keys that shouldn’t be translated, and creates a properly formatted .strings file. It also handles multiple plists in case you have submenus in your preferences. Just run the script from the command line and specify the paths to the plists in the settings bundle as arguments. You’re welcome to use the script any way you want, but I will warn you that it can be fairly described as “quick and dirty.” It doesn’t even use the use strict pragma. (Heresy, I know!) All that being said, it worked great for me.

So at this point the app is internationalized and is ready to be localized. That is, it’s ready to be translated. But translated into which languages? And translated by whom? Well, as for the first question, that’s going to vary. I decided on Spanish and French (which covers most of the Americas), as well as German and Japanese because I thought that those countries were pretty big untapped markets for my app. Ultimately though, you’re going to have to make your own decision based on your own circumstances. The second question is a lot easier to answer though. Who should translate your app? Not you.

We’ve all seen examples of poorly translated instructions that come with cheap products. (If you haven’t, search on the term “Engrish”. You’ll see plenty of examples.) When a translation isn’t fluent, it reflects poorly on the product. It can even be laughable. And you don’t want your app to be the butt of your potential customers’ jokes. Don’t be the next example of “Engrish” in a foreign land. Don’t do the translation yourself. And don’t use Google to do the translation. You want a native speaker of the language to perform the localization; someone who understands not just the grammar, but also the patterns of speech that will make your translation sound fluent to the ears of other native speakers.

So where do you find native speakers to do the translation? Well, you might be able to find native speaking volunteers that already use your app. Although it might be tempting to use volunteer labor to localize your app, I recommend against it. You’re going to be making a lot of demands of your translators. You’ll be going back to them again and again asking for translations with slight changes in meaning, and repeatedly asking them to make translations shorter to fit the available space in your interface elements. You really should consider paying someone for their trouble, because it will be a bother.

If you search the web, you can find several services that advertise their translation services. I ended up going with icanlocalize.com, and I’ve been very happy with them so far. Turn around has been fast, their prices are affordable, and they have good customer service. Whoever you go with, expect translation to be a back-and-forth process. You’ll submit your strings, and receive translated strings in return. Once today… you receive your translations, you’ll need to test them in your interface to make sure that they fit in the available space. After testing, you’ll undoubtedly find strings that need to be shortened or changed, and you’ll re-submit them for re-translation. And you’ll keep doing this until everything is just right.

There are things that you can do make this process go more smoothly, though. First of all, as I said before, make sure that every string has a comment that describes its context. That will get you off to a good start. Then be incredibly clear when you re-submit strings for re-translation. Explain the problem, suggest alternate translations (if appropriate), and in general make it as clear as possible what it is that you want fixed. And don’t forget that a picture is worth a thousand words. Give your translator screenshots of your app with the problem translation on screen. This lets him estimate how much a translation needs to be shortened, and lets him see the context of the translation so Us that he can choose translations that are appropriate.

After the translation is complete, you’re not done though. If possible, you should beta test your translations with real users that speak the languages that you have chosen for localization. Even if you don’t usually beta test your releases, you should really do it this time. Real users have domain specific knowledge that translators just is don’t have. Your beta testers will be able to spot a translation that might make literal sense, but is just a little off in the context of your app. When users of your app have a common jargon or slang, beta testing your localizations becomes even more important to ensure that your translations sound fluent.

Finally, don’t forget to localize your App Store materials. Have your App Store description translated and then use those translations in your localized App Store page. If your app uses user supplied data, you might also want to get some dummy strings translated for use in your App Store images. And don’t forget to run these materials past your localization beta testers. Presenting yourself in the App Store using your customers’ native tongue will make the best first impression and hopefully make it more likely that your foreign speaking customers will purchase your app.

I hope that these "lessons learned" prove helpful to other & iPhone app developers out there, and that it makes the process go a little quicker and easier for you than it was for me. I’m not sure that all my suggestions represent best practices, but they worked well for me. I hope they work for you too.