Localizing Apps: Getting Things Done

In the first two installments of this series we talked about what localization is and whether you should do it (the answer was a resounding yes if you're interested in profiting from your app). We also explored internationalization and recommended that you definitely internationalize, no matter whether you want to localize your app or not. 

Now let's talk about the actual components of your app that need to be localized. 

At this point, you've probably already decided which locales or languages you need to localize your app into, so it’s likely that you also have a general sense that the core message of your app is appropriate for those locales. Still, don't rule out the possibility that you'll need to make some tweaks to your app's overall story line. For example, the maker of the "Fairy Fashion Show" app discovered that she had to change her app to the "Angel Fashion Show" in Hindi (no fairies in India) and the "Elf Fashion Show" in several parts of Europe.* These kinds of considerations may be relevant for superficial aspects such as the title and the marketing or they could require reconfiguring the actual characters, themes, or other structural elements of your app.

Speaking of themes, we mentioned in an earlier article that most app development platforms make it possible to externalize the color scheme while preparing your app for localization ("internationalizing" your app). There's a good reason for that -- colors have various and often opposite meanings in different cultures. Many people know that white, which is considered a peaceful and pure color in many Western countries, represents mourning and death in Asian countries such as China, Japan, and India. But did you know that purple, which many regard as a royal color, represents mourning in Thailand and Brazil?** 

There's no reason to go overboard with adjusting color schemes or living in terror that you're doing something wrong by choosing a certain color, but you do want to perform a level-headed assessment and adjust where necessary.

These first two considerations had nothing to do with language translation. But that's not necessarily the case when it comes to the localization of multimedia assets such as sounds, video, and images.

Let's start with images. 

When designing images for your app, you need to ask yourself this question: Do I really need text on those graphics? Or better yet: How can I avoid having text on the graphics? Text on graphics looks like text, but it's really just a bunch of pixels pretending to be text. Of course, that's not apparent to the app user, but we can assure you that the person in charge of localizing that image feels the pain. Unfortunately, so will the app's owner when the next billing cycle comes around: It's a lot less (and cheaper) work to translate plain text than it is to recreate images with text!

If you do need text on your graphics, please be sure to keep the original, layered Photoshop .psd files and provide those to your localization provider. This will make it a lot easier to get to the text.

If your app contains videos, you also need to caution yourself against using textual elements that need to be translated. Replacing these might mean either redoing the whole video or using subtitles (more on subtitles in a minute). Considering either of those options, it might be wise to go the textless route.

Videos can contain (written) text as well as spoken language. If spoken language is necessary for your app -- and for many it is -- here's the range of options for translating (in order from least to most involvement): subtitling; dubbing (replacing the original spoken layer with a translated layer), which is how virtually all foreign shows and movies in countries such as Italy, France, Germany, Spain, Turkey, and Hungary are translated; or completely recreating the video. Your localization provider will help you to decide and carry out your best course of action, and it's entirely possible that you might find different solutions for different locales.

The takeaway: You'll save money if you’re able to avoid written or spoken text in videos, but all is not lost if you can't.

Finally, the actual text that goes into pretty much every app will need to be localized. Depending on the platform you developed your app for (ideally your app was of course developed for multiple platforms), the form of the text sent to the localization provider may be different, but each of these formats is easily manageable by qualified vendors. If you’ve internationalized your app properly and separated the text from the code, these are some of the different formats you'll send to your provider:

iOS: Two  *.strings files (one with the localizable text for the user interface and the InfoPlist.strings with the copyright information) or, if you're using the latest version of the Apple's development platform Xcode, one XLIFF (XML Localization Interchange File Format) file that contains the text of both .strings files.

Android: The strings.xml file that is located in the res/values/ directory. (The localized versions will go into appropriately named folders like res/values-fr/ for French or res/values-ja/ for Japanese.)

Windows: The localization will either be performed on .resw files (a similar format to .resx) or .resjson for the Metro interface (.resjson are essentially standard .json files).

It will come as no surprise to learn that these file formats are easily localizable. That’s because localization is no longer an afterthought -- not for the makers of development platforms and (hopefully) not for you.

* See http://lauratallardy.com/app-localization-made-easy/.

** You can find a comprehensive chart of colors and their different cultural connotations at http://blog.lingohub.com/translators/2012/08/meaning-of-colors/.