Localizing your app to new languages can be a great way to grow your app installs, or become a leader in an underserved app market. One study found that with app localization you can see an average app install increase of 128% per country.

We are seeing incredible growth in app downloads and revenue from the developing parts of the world. China is projected to be the largest market in terms of app revenue, and India seeing the largest growth in app downloads. India’s number of internet users is projected to grow from 388 million in 2016 to 636 million by 2021.

The benefits to localization are huge, but Google Translate isn’t going to cut it, and hiring a firm for every localization can be expensive for an independent developer. While there are a lot of great tutorials out there on how to add Localizable.strings or strings.xml files to your projects, there isn’t as much practical advice on how to avoid all the things that can go wrong in a localization effort. I wanted to document some of the common things that I found myself tripping over.

Recently I was localizing a relatively simple poker game into a few different locales. Even though the app was relatively simple and didn’t contain many full sentences or use much grammar, there were still many avoidable errors.

Grammatical Number / Plural Nouns

My poker game had a simple score mechanic that would display strings like:

“0 Points”

“1 Point”

“6719 Points”

In English, the plural of Point is Points, and we use the plural form on all quantities of points that are not singular. It’s a big mistake to assume that all or most other languages follow a structure similar to English.

Checkout the unicode documentation if you want to experience the brutal truth of language pluralization:

Some languages have different plural forms for quantities of 2 (dual number), others have different terms for quantities of 3 (trial number), and some others have a distinction between a few and many (with varying definitions of each).

Slavic languages like Russian are especially strange in this regard, they have different plural terms for quantities of 1, 2 to 4, and 5+

So, in Russian:

1 Point = 1 очко

2 Points = 2 очка

3 Points = 3 очка

4 Points = 4 очка

5 Points = 5 очков

6 Points = 6 очков

7–9 follow the same pattern with the очков ending, and also:

0 Points = 0 очков

And it gets even stranger when dealing with numbers greater than 9. For big numbers, you need to take the least significant digit to figure out which plural term to use.

7281 Points = 7281 очко

8192 Points = 8192 очка

5477 Points = 5477 очков

Other Slavic languages like Polish, Czech, Slovene have symmetries to this rule, but some with different handlings of 2 and 3; furthermore, some words have specialized “count forms” with different spellings and grammar rules. Like any language words have synonyms, очко isn’t the only word for point, be careful not to assume the plural ending of different terms.

The point of this is not to become fluent in every language you localize, but you should be wary of any underlying assumptions you might be making. Be sure to communicate the context of strings to your localization team. Remember that decimal numbers, ordinal values (1st, 2nd, etc), and ranges may have rules you might not expect, always communicate the context of the app!

Android and iOS have some helpful features that can make some of the coding a bit easier, for iOS see “Handling Noun Plurals and Units of Measurement”, in “Localizing Your App”, for Android see “Quantity strings (plurals)”, in “String resources”. For React Native (or other JS cross platform frameworks), you can use i18next. The unity asset store has a popular localization tool you can buy. Not all frameworks and game engines have elegant localization support for multiple plurals, depending on your situation you may need to roll your own solution.

Cultural Context / The User’s Perspective

Localizing an app isn’t as simple as mere translation, you have to consider the cultural, technological, and economic lens the user will be viewing your app through. This is why it’s important to not only use the language specifier, but also include the locale when categorizing your app resources (ie. en-GB, en-US, en-CA). In the case of my poker game, we might ask:

"Do users from X know what poker is and how it is played?"

Or perhaps getting more granular:

“Are users from X familiar with the standard 52 playing card deck?”

We may also want to think about the history of poker in their region. Some regions have had poker in the culture for centuries, for others it may be a relatively new import from the English-speaking world. This may indicate that the name of the hands ("Full House", "Straight Flush") should be left in English rather than translated to the native language. A common localization mistake is to assume that every aspect of your app needs to be translated or changed.

German playing cards have different suits.

Playing cards can have a different name and graphical representation for suits and the face cards based on regional preferences. However, in the case of a poker, the expectation is to not localize this aspect and to keep the suits and face card names consistent with international etiquette. The same can be said about the Arabic number system found on playing cards, most users would prefer this number system and are familiar with it.

We should also consider the region's social view and legality of gambling, and if possible tone down any overt text or visual references to casinos and gambling.

In terms of regional economic norms, we may not want to use the same price tiers or monetization strategy that we use in the English-speaking world. Some of the normal IAP prices charged in the first world might be prohibitively expensive in the developing world. Another thing to consider is the cost of cellular bandwidth in the region, while being mindful of your binary size and the bandwidth of your API payloads is a good practice in general, you may want to audit both before launching in regions where bandwidth and device capabilities are limited. On the same note, make sure to test thoroughly on low end devices. You may also want to consider expanding and deepening the first-time user experience of the app in regions unfamiliar to your app’s content or in areas where a significant portion of the users are new to smartphones.

Most of the questions to ask yourself during localization will be contextual to your app. For this reason, it's good practice to find a localization partner, who in addition to speaking the language, lives in the locale you are targeting and can give you some cultural context. Cultural context is too broad for me to provide a comprehensive list of issues to consider, but here are a few common errors I see:

If your app displays time, does the region you are targeting prefer a 24-hour clock or an AM/PM clock?

If your app displays any units of measurement (km/miles, etc), what unit of measurement does the region expect?

If your app has a calendar or displays dates, what calendar do users in the region use?

If your app displays dates, are the dates formatted in a way the regional user expects?

If your app displays prices, are these prices being displayed in the local currency?

Do the name form fields in your app make cultural assumptions like everyone has a first and last name?

Do the address fields in your app make cultural assumptions about the locale?

Do your phone number fields make cultural assumptions about country codes and the number of digits?

Are you using the wrong regional dialect, terms, or slang for the target locale?

Are you using visual symbols that are not culturally universal?

Again the point is not to become an expert on every culture, just find localization help that is regionally knowledgeable. Also make sure to read your reviews and talk to your users.

The task of localizing may seem daunting and endless, but the goal of this post isn't to scare you away from doing it. Localization has big rewards, with some attention to detail and double checking your work, these goals are obtainable. Just like with accessibility features (localization is an accessibility feature 🤯), by localizing your app you can improve your code quality by removing hardcoded assumptions and magic numbers. Perfect is the enemy of done, don't be afraid to use some if clauses if you need to.

In the next parts of the series, I’ll look at word ordering, languages that do not read left to right, grammatical gender, and idioms.

Related Links: