The Ultimate Guide To Mobile App Internationalization

Mobile app internationalization (i18n) is the process of customizing your code so that it’s ready for localization and able to be modified and released in multiple languages. Mobile app internationalization needs to come one step ahead of the mobile app localization process as your code needs to be ready to handle the localized content when it’s created. Think of localization as customizing the content and internationalization as customizing the code.

Below, we’ll take you through the mobile app internationalization journey and discuss the different steps and most important aspects that you need to focus on during the process.

‍

‍

‍

Plan ahead

While localization doesn’t necessarily need to be planned ahead of the development process, mobile app internationalization does because in most cases, it’s harder to modify the code for internationalization after it has been created.

‍

Not "one size fits all"

While the internationalization process helps you modify your code in a way to accommodate any future additions of new locales, you need to keep in mind that there are no standards for this. There's no one archetype that will perfectly adapt to every locale out there and you will have to make changes as you go along to suit the different needs of different locales.

‍

Don't over-internationalize

Believe it or not, over-internationalization is a thing. You might think that the more your code is adapted to more locales, the better it is. And while that might be true in some cases, you don't need to support languages and locales that you won't be using as this will just end up being a waste of your time, effort, and resources with no return whatsoever.

For example, if you're developing an app to be used internally in a company that requires all of its employees to speak English or Spanish, then you probably don't need to create support for other languages and locales.

‍

Legal considerations

When releasing your app in a different market, country, or even state, you need to make sure that your app complies with all of the local laws. Whether you're distributing your app through the App Store or Google Play, you'll still be the one held responsible and accountable for any legal issues that arise with your app.

You need to make sure that your app complies with local laws and regulations, and if it doesn't, you might have to change some parts or aspects of it to adapt to different markets. For example, gambling games are modified for different markets in terms of payment systems, in-game currency, and randomized gaming elements to comply with the gambling laws of each market.

You also need to keep in mind that legal issues might arise depending on how your app is actually being used and not just the intent of how it was supposed to be used. This might mean that you won't be able to release your app in certain countries. For example, gambling is illegal in countries like Korea and Taiwan. So releasing a gambling mobile game there would be illegal, no matter how hard you try to modify it.

‍

Data restrictions

Another thing to be mindful of when it comes to legal considerations is data restrictions. Different countries have different laws in terms of data storage, sharing, security, and more. These laws and legislations differ in terms of needing a permit to obtain users' data, what data you can obtain, and how you can use it, including personal information (e.g. name, email address, social security number, etc.) as well as any user activities or behaviors.

One way to solve this is by using Practical Law's Country Q&A Guide. Select the desired country and it'll give you a high-level overview of data protection rules and principles, including obligations of the data controller and the consent of data subjects, rights to access personal data or object to its collection, and security requirements.

‍

Code modifications

The whole point of mobile app internationalization is to modify your code to pave the way for localization. This means that the code is able to load content from multiple files representing the supported locales, toggle between different content and settings depending on which locale is chosen, as well as support and display content of different locales with different lengths and formats.

‍

‍

‍

Separate content from code

The first and most important thing that you need to do in terms of mobile app internationalization is separating your content from your code base. None of your app's content can be static within the code in order to allow you to create different versions of that content, which is dynamically loaded and adapted for each locale.

This is different from code forking because you won't be creating different copies of your code for each locale, instead, you'll be collecting and storing your content in a central repository to be able to easily create different versions of that content for any new locales that you want to add and have it loaded in your app without affecting your code. This makes it easier for the development team to work on developing the app while the translators or team members handling the localization process can work separately.

The content includes:

• Text
• Images
• Video
• Audio
• Date Format
• Numbers
• Currency

‍

Text

You might think that you need to separate all of the text in your code, but that's not the case. Not all text will need to be localized, just what appears in your app to your user.

There are many types of text in your code that never appears to your user and therefore doesn't need to be extracted or localized. The types of text that you'll need to add to your repository include:

• Static strings of texts within the code.
• Statically defined strings.
• Text appearing in user interface, menus, buttons, etc.
• Text loaded from external files (e.g. a Terms Of Service document or an End-User License Agreement).

‍

String interpolation

When you're creating a multilingual mobile app, you need to keep in mind that languages aren't just different words, and that the way sentences are structured can differ from one language to another and therefore mess up the sentences if you're doing word-by-word translations or concatenating different strings and text variables together.

A way to solve this and create natural language sentences is through string interpolation. String interpolation allows you to insert variables directly into a string without concatenating multiple strings together. This allows the translator to see the full sentence and adapt it as or if needed, changing the order of any of the strings or variables accordingly.

For example, this C# code below where the strings are concatenated will result in the translator receiving different pieces of the sentence and translating them separately, which would cause an issue in the way the full sentence is formed when it's put back together at the end.

‍

However, with string interpolation, the translator will receive the full sentence with the variables included in it, so they'll be able to change the order of the sentence as needed.

‍

Context matters

While reusing strings in different parts of your app can save you time and effort when localizing, this might end up causing you more problems than it saves you if you overdo it. The same string can be translated differently in different languages depending on the context of the text, which is why it doesn't always make sense to just translate a string once and apply that translation to all of the different parts of your app.

You should only interpolate a string if you absolutely necessarily have to, but keep in mind that just because it makes sense in one language doesn't mean it automatically will in other ones, and you won't be able to predict the different contexts in those languages. Also, keep in mind that using a localization system with translation memory will eliminate your worries about inefficiency when you're not reusing strings.

For example, "The high building" in Spanish translates to "El edificio alto", while "The high tower" translates to "La torre alta". Which shows that you can't just translate the word "high" to either "alto" or "alta" because it will depend on the context of the text.

‍

Numbers and plural forms

When including numbers in your text, you might think that you'll always only have two cases of either singular or plural, but different languages have different numbering systems and different plural forms. Some languages have singular, dual, and plural nouns, while others have even more specific rules regarding few or many nouns and even the definitions of "few" and "many" differ.

Since this is a common issue, most systems nowadays offer support for localizing plurals across different languages. You can check out Localizely's Language Plural Rules for more information when doing research about your target locales.

‍

‍

Media localization

You might think that pictures and videos are universal, and in some cases they are, but in other cases, it would be preferred or sometimes even necessary to localize your media as well. For example, you have a taxi booking application that shows a picture of a yellow cab. Users in the US and other countries that have yellow cabs will recognize the reference, while others from countries like France and Italy that have white cabs might not, and they might even wonder what a yellow car has to do with your app.

You don't want people to feel like your app is targeted towards just one set of users. Instead, give them a feeling that the app is universal by customizing the media, which needs to be easily recognizable regardless of your app's different languages, locales, markets, and cultures.

‍

Media management

While some of your media might work perfectly internationally, once again, some just won't and will need to be tailored accordingly. Which is why you need to ensure that the process of swapping media won't be a hassle and that your localization system allows you to do so, just as easily as it would be with text translation.

For example, if you're showing a sequential comic in your app, you would have to change the order of the panels according to the locales depending on whether the users there are used to reading comics from left to right or from right to left. Otherwise, you'll leave the user confused or you might even send them a wrong message.

You can check out The Ultimate Guide To Mobile App Localization for a list of translation/localization management systems with media support.

‍

Keep original assets

Make sure to always keep your source files for all of your media as this will be extremely useful later on whenever you want to make any edits or adjustments to them during the localization process.

‍

Media context

The same way context matters in terms of text and how it changes from one country and one culture to another, the same applies to media. Make sure to do your research beforehand whenever you're entering a new market to avoid offending anyone or pushing anything that might be deemed inappropriate or unsuitable for your target market.

For example, in many countries, a pig's snorting sound is considered offensive. So you'll either have to modify that in your app or at least have the option to mute the sound to avoid putting the users in uncomfortable or embarrassing situations.

‍

Media layering

When creating media for your app, it doesn't make sense to make a hundred versions of each picture that contains text to translate that text to a different locale. Especially with mobile apps, this would be extremely inefficient and would drastically increase the size of your app. Instead, you need to separate your media in different layers.

Splitting your assets into different components can be a great approach if you have a lot of media to be localized. So you'd have the base image in one layer and then the text in another separate layer on top of that, which then would be loaded according to the selected locale.

‍

Video localization

When preparing for video localization, there are two main routes to go: either creating subtitles for the videos or dubbing them in a new language. Creating subtitles for videos is usually a lot faster and cheaper than creating new audio and redubbing your videos. And while it may be an okay option for some users, dubbing the videos in the locale's language is definitely a lot more preferred as it delivers the full experience to the user.

In case you choose to go with subtitles for your videos, make sure that your app supports them, otherwise, you'll have to create many different versions of the video with the subtitles hard coded into them, which would be inefficient and defeats the entire purpose.

‍

‍

‍

Text support

Unlike earlier text encoding standards, Unicode has the ability to represent all the different language out there. It's not mandatory to use Unicode for mobile app internationalization, but it is highly recommended as it will make the process a whole lot easier instead of having to worry about multiple possible encodings of your text. This also allows you to have multiple languages present within the same view or even line of text within your app.

So you need to make sure that everything you're using within your mobile app, including the inputs, functions, libraries, storage formats, and fonts, are all Unicode-compliant. Almost all high-level programming languages support Unicode by default, so this concern is only really raised if you're coding in a low-level language or an older language with no Unicode support.

‍

Font support

Let's establish something: There are 136,755 characters defined in Unicode 10.0, which was released in June 2017, and there's no font or font family out there that covers all of those characters. So you'll need to either use a font that supports all of the characters of the languages in your app or use multiple fonts.

However, Google has started an initiative to create a font family called Noto Fonts comprising of over a hundred individual fonts, which are together designed to cover all the scripts encoded in Unicode while achieving visual harmony across multiple languages and scripts. Even then, Noto Fonts as of now cover nearly 64,000 characters, which is under half of the total number of characters defined in Unicode, and collectively have a total size of 1.1 GB. So you need to be smart about which fonts to include in your app and to only include the ones you need.

Also, just because a font supports the characters for the languages that you're using doesn't mean that it will look the same across all of the languages. So you also need to make sure that the font being used looks good in whichever script or language you're applying it on.

‍

Text direction

When preparing to translate your text into different languages, you need to consider how it'll be presented in those languages and how it would affect your mobile app and even your entire user experience. If you're localizing your app for languages that are written and read from right-to-left as opposed to the default left-to-right -- like Arabic, Hebrew, and Farsi -- you might have to adjust your user interface to accommodate for those languages. One of the best practices, in that case, is to mirror your mobile app views (e.g. moving the menus, buttons, tabs, etc. from the left to the right for those locales) so that it gives it a natural feel and provides the user with a seamless experience.

Another issue you might face is what's referred to as BiDi or bi-directional text, which is a problem you'll face when mixing between left-to-right and right-to-left scripts within the same text. In that case, you'll need to clearly define how you want the text to appear using Unicode. You can check out Unicode's control characters for more information about how to do so.

‍

Don't format programmatically

Believe it or not, formatting also differs from one language to another. Whether you're emphasizing a piece of text by making it italic, bold, or underlining it or you're adding punctuation, this can differ drastically across your different locales.

Some languages do not have the concept of bold or italic characters and have other ways of emphasizing the text, which is why you should also send the formatting to your translators instead of just sending them the text separately so that they can take the necessary action to format the translation when necessary based on their expertise.

Another thing is to never programmatically define your formatting, like creating a loop to add commas between a set of items that you're listing, because other languages might have different formatting standards (e.g. in Chinese, you don't separate words with spaces or commas). Also, punctuation marks (e.g. commas, quotation marks, semicolons, etc.) can look different and even be used differently from one language to another.

‍

Create a dynamic interface

Having a dynamic and responsive mobile app interface is a must when you're localizing your app. Some languages will have more characters than others when the text is translated, so your interface needs to adapt and accommodate such changes. Whether the text appears in a paragraph, menu, buttons, or any other UI objects, it needs to fit and to not look odd or disrupt the user experience.

If the translated text is still too long to accommodate for, one solution is to decrease the font size to fit the area it's in, while still maintaining consistency across all of the other elements in the app. Another option would be to enforce a limit on the allowed number of characters for the translations, but try to keep this as a last resort and only do it when it's extremely necessary, as you don't want to limit your translators and you want them to provide you with the best possible translations without being restricted.

‍

Numbers and dates

Number and date formats are other things that you'll have to customize based on the locale. For dates, some countries and regions use a month/date/year format, while others use a day/month/year format, so you'll need to tailor accordingly to avoid any confusion.

For numbers, it's mainly about the decimal and thousand separators, where some countries use the period and commas respectively, while others do it the other way around. Other countries, like India for example, use a unique separator system for numbers different from the international norm, where they group the numbers in a repeating pattern of 3,2,2 (from least significant digits). So instead of writing 121,212,123 or 67,890,000,000,000, it would be 12,12,12,123 and 67,89,000,00,00,000.

Luckily for developers, since these standards are set internationally and are always needed in the development process, almost all operating systems already have systems that take care of these things for different locales. Just make sure to double check that everything is working and appearing as it should be.

‍

‍

‍

Pseudolocalization

Pseduolocalization is the stage you should do right after you're done with mobile app internationalization as a testing method to make sure that everything has been set up properly and that your app is ready for localization. In this stage, you're making sure that everything that needs to be translated has been taken out of your code and has been replaced with dynamic variables that will be changed based on the locale.

You will need to create a localization file with placeholder values for both the text and media in the new locale you're introducing and test out how it will be displayed, making sure that all of the new locale or language's characters are being displayed correctly as well as any different media, GUI elements, or user interface changes. Also, make sure to try out different characters in different parts of the app as well as different lengths of strings to test out how your app and interface will adapt and respond to these changes.

‍

Localization

The entire point of mobile app internationalization is to prepare your app for localization. So once you're done with internationalization, you've tested your app, and everything seems to be fine, it's time to move on to an entirely new process, which is the localization process.

Localization (l10n) is the process of customizing your app to work in other languages other than the default. Mobile app localization allows you to go beyond your user base and access a global market. This helps you increase your downloads, have an edge over the competition, and expand sales. A study by Distomo showed that localizing apps resulted in 128% more downloads per country and a 26% increase in revenue for each country added via app localization. What’s even more incredible is that these results were achieved within just one week from the release of the localized app.

Check out 6 Things to Remember During Mobile App Localization as well as our Ultimate Guide To Mobile App Localization for a comprehensive deep dive into the localization process.

‍

‍

Internationalization isn't a one-time thing because as you update your app and it gets more modified with time, you will have to keep in mind how those modifications affect your different locales and make the necessary internationalization changes.