Getting Your App World Ready

In a certain sense, "getting your app world-ready" sounds much more descriptive than "internationalizing your app," but they both refer to the same thing. 

Here is what it's about in a nutshell: Surely someone in your extended family is a passionate gardener. If you ask her what she does before she plants her flowers or vegetables, she'll give you a long (and most likely very passionate) dissertation on how she prepares the soil. That's what internationalization is. No matter what kind of seeds you plant, you'll have to make sure they can flourish. And no matter what kind of locale or language you want to localize in, you need to make sure that your app can flourish in those versions.

In the first part of this series of articles about app localization, we talked about the profitability of app localization, and successful farmers and gardeners the world over can attest to the fruitfulness and power of this metaphor.

But enough about metaphors. Let's discuss what actually needs to be done in internationalizing your app and why it's very helpful to take internationalization into consideration as you're designing your app.

A very important consideration is to separate user-facing text from your code so that it can be easily translated. Translation concerns aside, this will also help you keep the text coherent and consistent even in a monolingual version.

All app-development platforms allow this to happen seamlessly. In fact, Apple has made it the default setting in its new Xcode 6 development platform: *.strings files with translatable text are auto-generated, and translatable strings can be ex-/imported into the translation file exchange format XLIFF – and this makes us in the language industry very happy. 

It's not just that text has to be translated, though. There also has to be enough room for the translated text. Here is an interesting example from Flickr's interface translation. The English term "views" was translated into "조회" in Korean and "次檢視" in Traditional Chinese. Both of these are approximately the same length as the original, so the translations were easy to accommodate. However, the French "consultations" and the Italian "visualizzazioni" are about 300% the length of the English original.* Much harder to deal with.

And these are by no means extreme examples. That's why it's of critical importance when designing the interface of your app to take size expansion into consideration, either by adding additional room for expansion or by using auto-layout features. (Either way you'll want to test the final layout -- but more on that in a later article.)

You can also help localization efforts by using globally understood images rather than text.   is widely understood as an icon for Play; the term "Play," on the other hand, becomes "Wiedergabe" in German and will likely cause a number of pesky problems. (Be sure to remember the phrase "globally understood" when choosing this strategy, though.)

Finally, authoring content for your app in the source language in a brief and focused fashion will certainly pose fewer problems for your translators.

As we discussed in the first installment of these articles, however, localization is more than language translation, and this is true for internationalization as well. 

Here are some other things you need to consider as you develop your app with internationalization in mind:

1) Use the APIs that are available when choosing values that vary between different locales. 

Here are some examples:

• Dates ("April 1, 2014" in US English vs. "1. April 2014" in German. This example even uses the same Gregorian calendar, unlike Hebrew, Japanese, and Thai.)

• Names (John M. Smith -- first name, middle initial, family name -- in US English vs. 张艺谋-- family name (张), first name (艺谋)-- in Chinese)

• Addresses ("Portland, OR 97005" in the US vs. "08041 Barcelona" in Spain)

• Numbers (4,294,967,295.00 in the US vs. 4 294 967 295,00 in Canadian English)

• Sort order (XYZ in US English vs. XYZÅÄÖ in Swedish)

2) Just like text, you'll want to separate images, video, and sound files from the source code so they can easily be modified or swapped if need be. The same is true for color schemes. And while we are blessed to have Unicode, not all fonts support all languages, so you might need to make sure that you use a font that supports many languages and/or define the fonts in an accessible manner to be able to switch them if the original font does not work for a new locale.

3) Pay special attention to bi-directional languages that are written mostly from right to left, such as Hebrew and Arabic. The very layout of your app may have to be mirrored, and even images might have to be flipped. Controls and toolbars will definitely have to be mirrored, but there are also layout considerations for other languages where you might need to assign more screen real estate to text.

This all sounds like a lot to consider, but the good news is that you're not alone. There are good instructions for the main development platforms,**  As a localization provider PTIGlobal can assist you in your internationalization efforts. Even if it's internationalizing an app whose developers didn't originally follow the steps we've outlined here.

Just remember what your auntie always talked about as she chattered on and on about her gardening efforts: there's no good harvest without well-prepared soil.