Mobile App Internationalization: Ways and Methods to Boost Revenue by 26%

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 the localized creative content may result in an increase of install rates in several markets.

The majority of mobile application users are not form 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 of 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 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 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 to Translation

Naturally, any developer expects to receive all the translated elements in one package. However, to start an 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:

Source

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.

Processing Mechanism of Localized Elements

Utilizing source files is a generally accepted way to present localized strings. By this principle, a separate file refers to one culture. At the same time, any table with such type of data as “Key” – “Translation” (including the host language) is transformed in the following way:

• The resource linked to an application (not uploaded in memory during the start) goes with the collection type “ID” – “Value”. The “Value” field contains the translated elements.
• Automatically generated class with the collection type “Key” – “ID” is shown in the next example:

Linked to public const int NotesLabel = 2130837620;

This example shows that an integer constant corresponds to a literal Help_Overlays_Menu functioning as a resource identifier.

Addressing the resource out of the code will have the following form:

myLabel.Text = AppResources.NotesLabel

Here “AppResources” refers to the name of a resource file.

The readability of a literal is essential for its convenient utilization and realization in a software code. At the same time, the resource ID is determined by the constant meaning that obviates the need for additional calculations.

Challenges and Solutions for Resource Files Usage

Using resource files has a number of unclear limitations and challenges. First off, such files cannot be added to an application after it is delivered to an end user. It will be also impossible to apply new language packages or modify resources without updating of an application.

Besides, constant literals are inconvenient to use for string manipulations. It means that it will be also complicated to address the resource with a calculation key.

Another limitation is forming of literals in compliance with the syntax resulting in missing spaces and other non-alphanumeric symbols.

In the case when resource files cannot be utilized by the traditional approach, it is possible to develop other solutions on their basis. Hence, if there are few strings in a resource file (less than 100 Kb), they can be stored in the program memory accompanied by a written reader (implementation examples are available online). However, when memory optimization is of the primary importance in case of heavy application, you should store the file in the local database. This solution benefits from flexibility and scalability and decreases the application load time.

By this approach, addressing the localized resources in the code will have the following form:

myLabel.Text = ResourceManager.Get(“NotesLabel”)

Here “ResourceManager” is a class that requires implementation.

Lazy Loading

Compared to desktop and web applications, mobile applications have specific data management. However, there are some tried and tested ways to enhance the functioning of a localized application.

A modern mobile device has enough memory and a powerful processor to function as a full-fledged computer. Still, a developer should consider some specifics in the process of localization.

One of such is the size of an application installation package, which is critical when a device operates on the relevantly slow 3G or Wi-Fi networks. The standard mobile app size may range from 1 to 20 Mb. Applications with more than 100 Mb in size are considered humongous and can be rejected by some app stores. Moreover, the missing network connection can even halt functioning of an oversized application.

In this case, the best solution is the lazy loading of necessary documents, images, and other resources after the installation. For instance, a program localization for 10 languages can be performed by using a multiplier effect that assembles overlay images with special captions for locating the elements of an application. The total size of images increases from 5Mb to 50Mb after the merge. This is an indication that the application architecture should be improved by applying lazy-loading.

However, an application should always support at least one basic localization (usually En-US) to display a homepage fully, in case lazy loading cannot be performed for some reasons.

In a diagram below, you can review a process model of lazy load implementation.

Initially, an application does not contain all localized resources instead it downloads them from the external server (Application Server) to the local repository of a mobile device (Local DB) when needed, right after an app installation or its updates. Then, localized packages are transformed in the convenient view for the app. After this, an application does not need to connect to the external server and the localized data is extracted from the local repository.

UI Adaptation

Throughout the history of human civilization, humanity invented a variety of unmatched writing systems. We still get impressed with the intricacy of knotted strings of North American Indians and Japanese ideographs (kanji).
Today we discern two writing systems known as left-to-right (LTR) and right-to-left (RTL) cultures. Surprisingly, the way people write created unique cultural discrepancies. This seemingly little detail frames exceptional traits of native speakers even influencing their mode of thinking.
Therefore, to implement internationalization a developer should regard the crucial differences between LTR and RTL cultures. For instance, for RTL languages such page management elements as an icon, an entry field, and a button should be rearranged in the reverse order “a button – enter filed – an icon”. At the same time, the scroll pane should be placed to the left and the hamburger menu to the right. The following images illustrate how to adapt User Interface regarding the contrasting LTR and RTL cultures:

Source

There are tools and technologies providing automatic RTL support. However, the complex front-end of the page should be re-imposed to guarantee an automatic transformation when switching to RTL culture.
In case an automatic function fails, it is recommended to write a UI loader, which will allow changing imposition, including the picture overturn and changing an arrow from left to right.
Apart from UI adaptation to RTL culture, the webpage imposition also depends on the length of the translated phrases. Since each language has its own unique system of forming meaningful sentences, including words that cannot be directly translated, the adaptive imposition becomes a necessary tool to apply the desired changes.

Conclusion

Internationalization and localization are complex processes that require a huge amount of work, time, efforts, and investments. However, a professional project team can successfully localize a mobile application when coming up with a well thought-out globalization strategy, and ensure the high quality of localized solutions.