Originally published on the Infopulse blog.
When targeting the global market, any business faces a burning issue to adapt a mobile application to the language of their potential consumers. In this case, internationalization becomes a necessary measure, which can significantly amplify the reach of an app.
In the following article, we will focus on the best practices and approaches to implementing mobile app internationalization and localization.
Explicating “-zation” Terms
For the businesses that serve globally or only aim to approach new global markets, the application development is closely connected to three “-zation” processes:
- Globalization is a complete cycle of planning and identifying global markets for the upcoming app without necessary customization. According to Localization Industry Standards Association (LISA), globalization comprises internationalization and localization processes illustrated in the LISA chart below.
- Internationalization (aka i18n) is usually referred to the development and design of a product application adaptable to a wide range of languages, regions, and cultures. After the application is internationalized, it can be localized to the specific region or culture. Internationalization prepares an application at the design level to the next phase, called localization.
- Localization (aka l10n) is the process of adapting an application to a certain language and cultural specifics. Localization involves translation of user interface textual elements and documents as well as an adaptation of non-textual app components, e.g. date and time formats, addresses and time numbers, currency use, icons, graphics, etc.
Hence, globalization is a process, incorporating both phases, and by means of internationalization and localization, the app will look native in different locales.
Reasons to Globalize Applications
Although implementation of internationalization and localization is resource demanding, the following figures reveal particular reasons and benefits of creating a world-ready application. For instance, Distimo says about the growth in a number of downloads by 128% and revenue by 26% after adaptation of 200 iOS apps to native languages of 12 countries. Another AdColony 2016 study confirms that localized creative content may result in an increase in install rates in several markets.
The majority of mobile application users are not from English-speaking countries as the recent research of StatCounter showed. The web analytics company reports that the largest number of mobile users are located in India, Indonesia, South Africa, Turkey, and China. Thus, relying on the most spoken language like English can become the main reason for application low rates among specific target audiences.
At the same time, a recent study by Statista demonstrates that APAC ($38 billion) region leads over Americas ($14 billion) and EMEA ($9 billion) regions in factual and projected expenditures on mobile apps via app stores. These figures confirm that a globalized application will be able to cover more regions with potential customers who are more willing to buy from brands that are able to adapt to their native language.
Another reason to implement i18n and l10n processes is buying preferences of consumers and, perhaps, emotional connection to the app that talks in their mother tongue. Thus, according to Common Sense Advisory 2014 survey, 75% of consumers are willing to make a purchase in their native languages. A large-scale study also reports that almost 60% of 3,000 surveyed consumers from 10 non-Anglophone countries hardly ever or never purchase from English-only websites whereas 70% of Japanese consumers buy products only at local-language websites.
Considering all the reasons and figures, the mobile app globalization seems a reasonable investment that can result in the growing amount of sold applications in the future.
How to Enable Internationalization and Localization
An application may have a built-in feature for multilingual support, otherwise, you’ll need to add it to the current design. In order to simplify the life of a localization team, developers must go through the following essential stages:
- Determine the elements requiring translation (text strings, pictograms, documents);
- Control the translation of user-visible content by a team of localizers;
- Implement a mechanism of reading localized elements;
- Apply lazy-loading of heavy elements (specific for mobile applications);
- Provide UI adaptation including RTL (Right-to-Left Language) support.
Some of the other specific functions would be defining the current country of the device or enabling a switch to a specific localization without an application restart.
Determining Elements to Translate
Translating titles and text strings is simply not enough to conduct localization since pictograms can also contain text elements. In this case, before a separate translation team can start their work on translation, developers need to separate the graphical parts from the textual ones as a part of the internationalization process. Such a task can turn out to be complicated, if the text is the part of the picture, e.g., overlay images. The solution would be to provide a separate set of localized images for each language.
Ideally, all the documents should be translated. Yet at the outset, you can focus on such key elements as Contact Information, Help, Terms of Use, and Privacy Statement.
The data generated by the server can be displayed in a mobile app as well. Unlike short literals that you can translate instantly, backend-generated long text messages must be processed only on the server side. In this case, you should also transmit the language/culture code to the server too.
Preparing for Translation
Naturally, any developer expects to receive all the translated elements in one package. However, to start efficient cooperation with professional translators, a developer should provide them with a structured document containing all the necessary text strings that require translation. Usually, these are tables with such essential fields as “key”– “original” — “translation”.
However, you can also build a table using the following example below:
Creating such a document is a required measure since translators have limited technical skills and most likely won’t be able to write a script for the database or edit a source file.
You can test digital translators, however, you will have to write a script and still engage a professional who could refine the textual part. Considering the translator’s comfort, developers should also export all the keys with the original text strings in Excel or its alternatives. The translation will be also imported from the same file.
Continue reading this post on the Infopulse blog where it’s been originally published
