Sometimes it seems the deeper you dig, the more complex and the wider ranging the idea of localization becomes. An app localization tutorial to cover it all would be the size of a New York telephone directory. Moreover, it would be out of date before it was finished, because app localization needs are always changing.
Here’s another approach. This tutorial gives you an overview of the critical points and the principles of localizing an app. You may be a marketer, a product manager, or a developer, and as such, you may naturally feel more concerned by some aspects more than others. However, all the points we discuss will affect you, directly or indirectly. For example:
The sections below will take you through the essentials of app localization from one end to the other:
Everyone in your team and other stakeholders in your organization should understand why localization is being done. The following facts can help explain.
Clearly, limiting your app to just one language version, whether English or another, cuts you off from potentially large markets. Conversely, suitable app localization can seriously boost your app sales revenues.
Ideally, everything. For a given localization language, not only should the user interface and the functionality be localized, but also any resources the app makes available to the user, and any texts and graphics used to advertise or sell it. Ideally, native language speakers using a localized version of your app will assume the app was developed in their language from the ground up, because it looks so natural to them.
The devil is in the details. A localization defect like using a period instead of a comma as a numerical separator (for example, 1.000 in French instead of 1,000 in English to represent one thousand) may look small to non-native users. However, it will probably be glaring for native speaker app users. As another example, the meaning of images and colors can change radically from one country to another. Consider the following: in China, red stands for good fortune, in France, communism, and in South Africa, mourning. Even app or product names can trip you up. For instance, mobile phone vendor Nokia discovered late in the day that the name of its flagship phone “Lumia” meant prostitute in Spanish. A little thought and googling can go a long way to avoid this kind of mistake.
Even with app localization tools and automated processes, producing different language versions of an app takes time and effort for developers, product managers, and marketers alike. It also requires funds for the translations, advertising (possibly), and ongoing maintenance. Return on investment is typically a concern. Marketers must provide sales estimates, while developers and translators must evaluate the workload. The product manager then compares returns against costs to decide if a localization is viable.
There is no standard order of app localization either. App product teams must evaluate their app on its own merits and international sales potential. Yesterday’s stock choices of localizing into French, German, Italian, Japanese, and Spanish may no longer work. China and Brazil may offer higher potential revenues now. Also, it may make no commercial sense to localize for very small or very competitive markets.
Cost-cutting to try to shoehorn a localization into a budget is a delicate matter. There may be cases where reuse of localization effort is possible. For example, much of the French language in France and in Canada is the same. In general, everything a user sees or experiences with an app should be available in that user’s native language. Mixing languages (local and default) in a user interface often makes users doubt the overall quality of the app. Similarly, skimping on the quality of translations and on checks after localization are recipes for localized app market failure.
What many people loosely refer to as localization is in fact two activities: internationalization and then localization.
With good planning, internationalization costs of an app can be minimized by making the internationalization process part of the app design and development. Like bug fixes, the earlier internationalization is done in the app’s life cycle, the more cost-efficient it is. Operating systems like Android and iOS now make internationalization capability an integral part of their platform. One main language-independent version of the app can be managed with sets of resource files (text, graphics, etc.) corresponding to the default language (for example, English) and to each localization language. By comparison, internationalizing an existing app may have an incidence on costs (higher) and quality (lower). Back in the 1980s, Lotus 1-2-3 lost its market lead in Europe to Microsoft Multiplan, because it took Lotus 1-2-3 two years to disentangle user text strings from its application code.
Marketing takes the lead in identifying the markets in which your app is to be offered. The next step is for marketing to establish cultural and country factors that could affect localized versions, to make sure these are taken into account in the internationalization. For example, suppose your plan is to make localized versions that will only address Spanish-speaking market. You may then choose to exclude any time spent on right-to-left internationalization that would be otherwise required for languages like Arabic and Hebrew, but not Spanish. Other considerations include:
Within a given country or region, there may be several languages spoken. China, Belgium, and Switzerland are all examples. Alternatively, one language like English may be declined in several country variations: for instance, US English, UK English, Australian English, and so on. The combination of a language (English or “en”) and a country (US) gives the locale (en-US). Localization plans should refer specifically to locales, when they make a difference in the way the user interface is displayed (for example, when displaying dates in the case of US or UK English.)
The two most popular platforms for mobile apps, Android and iOS, are examples of how modern operating systems are building in capabilities to help developers create language-independent apps. They both offer:
Apart from differences in the way localized information is stored by each operating system, Android and iOS offer a similar approach overall to content separation and formatting functions.
As we mentioned above, while app localization typically involves translation, it may also go further. Country and culture specific aspects also to be managed may include:
Pseudo app localization is a further technique to test the quality and robustness work done prior to a localization. With this technique, the text string resources are replaced by a version with gibberish. The app is then run and its various screen displays checked. As long as the user-facing text is nonsensical, the viewer can be sure that the strings have been separated into the file for translation. If a “normal” word appears, it can only be because it was missed, and must now be separated and put into the file for localization with the others.
It is also possible to generate a text resource file with each text string repeated to make it twice as long. This helps to spot places in the display when longer translated texts might overrun. For example, the German word commonly used for “Redo” (as in “reverse an undo command”) is “Wiederherstellen” with four times as many characters, and might not fit on a button.
If translators work only on the separate files of content, outside the context of the app, it will often be important to provide them with additional information. For example, a button or a menu item labeled “Fly” in English could have different meanings (“fly” as a noun, “fly” as a verb.) Different meanings may mean different translations, so an explanation about context and meaning must be supplied to make sure the translator makes the right translation. It also makes sense to provide a creative brief for translators with information about your app, its purpose, and its target market. In parallel, this is the chance to specify how you want them to blend aspects like style and “voice” into the localized texts.
Automated translation of text is still not good enough to be used “as is” for most localizations. Problems in translating the meaning of text or grammatical errors will be painfully obvious to your native speaker end users. They may then make their opinions known via social networking or similar, denting the reputation of your app. Professional human translators will still be part of the process, for the moment.
On the other hand, automation of the process of translation can make localization more efficient and improve quality, especially as apps and localizations multiply.
Murphy’s Law says that any translation or localization errors that slip through will be the ones that end-users stumble on when running the localized app. Thorough testing of each localized version is therefore mandatory. A product manager will organize testing by people with native-speaker capability for the app localization concerned, and with sufficient knowledge of the culture of the prospective users or customers. The testing must also be done in realistic circumstances, running the app in the way that end-users will run it when it is released.
Remember that all errors, of whatever size or apparent gravity, are important when reporting test results. Even errors that look insignificant to non-native users can disrupt normal usage by native users. These errors can then tarnish the brand of the app and its success in the international market.
At this final stage in the localization process, it’s time for some more marketing. In particular, you want to know:
App store optimization to help drive customers towards your app, and to achieve higher ranking and visibility in an app store will depend on:
Other aspects, according to the app store in question, may include uploading information about availability of a localized version to a news section, and adding localized versions of screenshots of your app (otherwise your home market screenshots are likely to display by default.)
With this tutorial (“the only app localization overview tutorial you will ever need”), you now know how to go through the process from one end to the other. With your first successful localization underway, you can then apply the same steps again for the next one.
Some of the initial work can be reused or does not have to be redone, especially in the area of app internationalization. Life should be easier for developers, thanks to a good “internationalize once, localize many” strategy. Marketing and product management will still need to assess new opportunities for sales potential, competition, and any other relevant business factors. However, even here there may be chances to leverage work already done from one market to reduce efforts in another, for example, when only minor cultural differences exist between two countries or locales using the same base language.