Being able to localize more complex Android apps in different languages isn’t a child’s play. In practice, you’d have to learn quite a few tricks before you get things rolling. In this guide, we’ll revisit the best practices for Android localization and go beyond the standard.
Why Is Android Localization Important?
We speak quite often about the importance of localization. No wonder! The statistics are quite clear. As reported by Statista, the number of mobile phone users globally has risen to 4.93 billion. According to a study by App Annie, an app market data and insights company, China and India surpass the US in terms of revenue generated by mobile apps. Non-English usage is even higher for Android-based applications. With regards to downloads and revenue in Google Play Store, the majority of the top five countries are non-English speaking countries.
It’s natural that people are more comfortable with using apps adapted to their own language. Therefore, supporting as many languages as possible can be a vital factor in staying ahead of your competitors.
What is the Difference between Localization (l10n) and Internationalization (i18n)?
Many people, including developers, often falsely use localization and internationalization as synonyms. Let’s get this thing clear before we go on. Internationalization is the process that prepares an app for localization. It will be much more difficult to localize your app after it has been completely built. Internationalization is a set of actions that you need to take at the development stage of your application, so it is easier to localize the app. In turn, localization is the process of customizing the content to make the app available in different languages.
This shows clearly that these two processes are inseparable so best practices for adapting software to multiple languages must be followed in both localization and Internationalization.
What are Best Practices and Why Do They Matter?
Best practices in the software development community are a set of informal rules that have been learned over time and can help improve the quality of software. It’s not all about writing time and space-efficient codes. Best practices include decisions that should be made over the entire development life cycle. By following best practices, you can reduce the cost and effort involved in the localizing process while making it scalable and easy to maintain.
Select Target Markets
The most important decision to be made in Android Localization is selecting the target markets. Localizing your application for a particular locale comes at a cost. Therefore, you shouldn’t try to localize your Android application for every language just because it’s possible.
Also, the cost of localizing your app is not the same for all languages. Localizing your app for French is usually easier than localizing for Chinese or Arabic. You should also carefully think about the return on investment. For example, if your app is only about American football, there is no point of localizing your app for India or China although they have the biggest market.
Design Layouts with Localization in Mind
Texts in different languages take different lengths. Let’s see how different languages communicate the same sentence.
- English: Let’s do Android localization to capture a bigger market
- German: Lassen Sie uns Android-Lokalisierung durchführen, um einen größeren Markt zu erschließen
- French: Faisons la localisation Android pour capturer un plus grand marché
- Chinese: 让我们做Android本地化来占领更大的市场
You can clearly see that each language requires a different amount of space for the same text. You need to account for the text expansion and contraction when creating Android UIs. The general rule is to add 30% extra space to UI elements to accommodate other languages.
There are three main design principles you should follow:
- You shouldn’t use fixed width/heights for UI elements (buttons, text fields menus, labels, images). Otherwise, texts could be displayed cropped or with excessive spaces when translated into other languages.
- Elements should be placed relative to each other. They should be placed on fixed coordinates. They have to be realigned according to translated languages.
- Containers and wrappers should be able to adjust their sizes according to the sizes of their contained elements.
Support both LTR and RTL
There are certain languages that read and write from right to left. Arabic and Hebrew are both good examples. You need to design layouts in such a way that they can flip entirely when necessary. This could be a bit of an expensive process and require many flows/procedures to follow. That’s why it is important to carefully select what languages you’re going to support before starting the development process. Usually, a modular design approach is considered the best approach for this situation.
Strings are the most important objects in a localization process. They’re at the center of this tutorial. Let’s see what practices we need to follow for string localization.
Do Not Hardcode Strings
You shouldn’t hardcode strings in layouts. This is very tempting for a novice. However, this could be a serious issue when it comes time to localize your Android app.
Luckily, Android Studio warns us about this. If you have already added hardcoded string, Android Studio has a nice way to add them to string.xml file:
- Highlight the text
- Press Alt+Enter
- Click “Extract string resource”
- You will then get a dialog box. You have to enter a preferred name to that string value.
- Now check in string.xml and layout page.
While simple applications only contain a few strings, larger applications may contain hundreds, even thousands of strings. You have to label them in a way that allows them to be easily differentiated. This is called providing context.
The first thing to remember when naming a string is to create a label with a meaning. For example,
Comments are often overlooked by many programmers. This is not a good practice.
You should add comments to every part of your code. The same theory applies to localization as well.
Add Attributes to Untranslatable Text
Not all strings need to be translated. For example, the name of a company does not need to be translated. You must clearly specify those strings it in the string.xml file. This can be done in two ways:
<xliff:g> tags to enclose the text
B. Use an
translatable="false" attribute with your text.
Placeholders in Strings
Another mistake many novices make is concatenating Strings in Java code. This is a really poor practice. Instead, you should use placeholders whenever possible. For example, let’s say you want to have a dialog to greet a user.
You should use…
Android can use
%s according to each language.
Sometimes you want to display a set of names with a separator. But separators like comma ‘,’ could vary from language to language. You should declare your separator in the string.xml file and then use it in your code.
Line Breakers and Word Wrappers
Another interesting difference between different languages is how they separate words. Although many western languages use a space to separate words, East Asian languages like Chinese and Japanese don’t use spaces to separate words.
Consider the previous example:
- English: Let’s do Android localization to capture a bigger market
- Chinese: 让我们做Android本地化来占领更大的市场
You can’t see spaces in Chinese text. The Chinese language relies on syllable boundaries. Hence, usual word-wrapping and line-breaking algorithms in your application can cause problems.
You have to find a better routing to parse words in your application. This is crucial for when wrapping texts for layouts. There are several word segmentation algorithms that you can use.
Using Fonts that Support Multiple Languages
To keep a consistent look and feel across different languages, you need to be careful when selecting font types for your texts. Font choice can seriously impact the readability of the text. There are a few things to keep in mind.
You can characterize fonts in many ways such as serif or sans-serif, proportional or monospace.
But the most important characteristic that matters for translation is whether fonts are Unicode or non-Unicode (such as ASCII). Unicode fonts are created from Universal Coded Character Set (UCS)—a comprehensive set of characters and glyphs from multiple languages—encoded in a way that ensures those characters appear the same across platforms and systems. On the other hand, ASCII is specific to a certain language. ASCII might look pretty in English, but they are very limited in terms of translation. Therefore, you should be careful to use a Unicode-compliant font. Be careful, some fonts claim to be Unicode, but only support certain code-points. This could lead to multilingual issues.
The same font size may have different readability in different languages. For example, although 12px is readable in English, the same size could be difficult to read when translated to Japanese.
You have to change font sizes dynamically for each language. For that, you have to maintain separate style sheets for different languages which will include specific styles for each language.
Let’s add a few words on translation teams: This aspect can influence the success of localization more than anything. Web developers can’t translate your app. You need to enlist translators if you want to achieve that goal. Don’t rely on Google Translate when adapting your application. It might provide incorrect or out of context translations. It’s always better to rely on a professional translator.
Localization is a substantial topic. We were able to cover a great deal of information here, but there is more. The text is not the only thing that needs to be localized. You have to localize images, dates, and numbers.
We will discuss the topics mentioned above in upcoming tutorials. Eventually, we will build an application with all these best practices. In the meantime, if you’re already looking for an Android app localization tool, make sure you give Phrase a try and sign up for a free 14-day trial to see how it can streamline your localization processes.