How to Prepare an App for Localization

Alex Murauski
Published on Mar 09, 2020 in App Development

If you’re planning to grow incrementally with your new app, localization is only a matter of time. Localizing your app can be instrumental in exploring new markets and gaining more users. This is why it’s usually not long after release that many app developers start thinking about expanding horizons and entering new markets. This is where localization comes into play.

Just to give you a short intro to the topic, localizing an app means modifying it for a new country or region by translating the user interface and making it appropriate to cultural, social, and other local factors.

We’d like to underscore once again that localization implies translating the app interface and description, but not changing UI elements.

In order to better understand the concept of localization, let’s take a closer look at a few examples. Imagine that your app needs to be translated into Russian and contains English characters, jokes and names. So, in this example, a good localization will provide relevant Russian substitutions for English-specific names and quips. However, if the user interface lacks the space to fit the Russian text, which is almost always 30% longer than the corresponding English text, this problem is out of localization scope and requires some front-end handiwork.

Another case is numbers, dates, and units of measurement. Whereas localization can change the numbers from words to numerals and vice versa or match numbers with corresponding noun form, it can do nothing to hard-coded numbers or data on the static images.

These types of issues are legion — various non-localization bugs that show up only in the translation stage. They’re often cold internationalization, i18n, and pseudo-localization errors.

Note that internationalization implies developing an application so that it could be adapted to multiple languages without extra engineering efforts.

That’s why we’ve got it covered — Alconost has come up with a list of rules for product people. So, we believe that these guidelines will help you avoid many painful mistakes and thus, save up your time and effort.

1. To localize or not? Determine localization languages beforehand

Sometimes it’s extremely difficult to choose all future locales for an app before it’s actually released. And yes, the standard process looks like this — first, you test out the audience of your app with a single-language version, and then you expand with localization. It’s a smart approach, but it’s not perfect. And the reason why is that your app might have enough content that simply doesn’t fly in a certain regional market that it would never be welcomed without localization, even if you did profound market research.

So how do you go about selecting app languages?

  • Study competing for localization projects. As a general rule, if a similar app has had good fortunes in a target market, you have a good chance of success.
  • Research the most in-demand localization languages for apps. There are numerous studies and statistics for this. You might also want to refer to research by Alconost published in the article “Best Languages for App Localization”.

Whatever your localization goals, our best advice is, first, to make English your source language by all means. And second, develop your app for at least  two languages from the very beginning.

If you select English and the native language as your “default” locales, you’ll already be navigating all the hazards of a localization project. So, when you add 20 extra languages, you’ll hardly see any difference. Besides, you’ll make English a source language for further translations of your app, which helps keep all the translations consistent.

2. Build your interface around the selected languages

We usually recommend having some extra space (30% or even more) for other languages when designing the app interface. This rule applies above all for buttons, menu items, pop-ups, messages, and other UI elements.

But we have an even better tack. If you follow our Recommendation #1 and pre-select the locales in advance, you can build the interface for the least space-efficient language.

Just to provide an example, Russian and Arabic texts are 10% longer than English. And German versions are 30% longer. Meanwhile, traditional Chinese characters generally require  30% less space than English copies.

3. Do not hard-code your text strings

The thing is that when you need to extract resource files (used for localization) from your source code the hard-coded text will not be there since it’s not extractable. And consequently, this text won’t be translated.

So, here comes one more localization rule. Design your app in such a way that every localizable line of text can be edited and translated without changing the source code.

In addition, we advise avoiding compiling texts out of sets of one or several words. Let’s have a look at this string:

tos-text = Read further in
tos-link = Our Privacy Policy

Whereas many developers would consider this a good solution, it’s actually not. Because in some languages localization of this text will not produce a natural-sounding sentence. Here’s a more flexible alternative:

# LOCALIZATION NOTE(tos-text): {{link}} will be replaced with a link with anchor text when app is running
# String 'tos-link' contains the anchor text for this link
tos-text = By clicking you accept {{link}
tos-link = Our Terms of Services

Besides, the notes for localizers are essential to better understand the context and the order of strings. 

Finally, be ready to localize images within your app. What’s more, if the graphics within your app have some text, localization is a must. And if this text is hard-coded, you need to redesign the image from the very beginning.

In general, creating new images and other creative assets could be a good idea so as to choose proper colors and in-app characters for the new locale. Yet, doing this just to insert translated text alone is redundant and inefficient.

4. Placeholders and formatters are your everything

This follows logically from the previous rule. Placeholders and formatters often seem like a smart plan when you need to localize and edit the text within your app. However, you also need to provide access to placeholders.

Besides, it’s a good idea to make short notes describing placeholders, which help prevent ambiguity when a formatter or placeholder is wrongly connected or not connected to the previous text.

Finally, mind the numerical information. It also needs to be extractable and placed within the context. This recommendation applies to time, dates, numbers, currencies, and units of measurement, which formats can differ across the languages. The devil is in detail, and this is also undoubtedly valid for localization.

5. Mind encodings and fonts

Encoding problems occur if your input language has some special characters and fonts that do not have corresponding alternatives in the selected language. As a result, after localization, you can get some strange unreadable characters. And it takes a great deal of time and effort to correct these types of encoding errors.

Therefore, we recommend using Unicode whenever possible. In particular, UTF-8, which is widely-used and space-efficient encoding. And be sure to check for encoding mismatches in your resource files (input files for localization).

If you need more insights on encodings, you might want to have a look at our translated guest post on hunting for “mojibakes”.

6. Once ready for localization, try pseudo-translation

Finally, once you’re ready with all the technical stuff, try a trick with pseudo-translation. In fact, many great tools can change the app interface so that it looks like a target language.

This software normally triggers a script that imitates the selected language. And they assemble a build that could be consequently tested during the standard QA process.

Such QA-experiments help to check the text length within UI-elements, spotting encoding errors and revealing hard-coded texts. Whereas pre-localization is not a panacea, it’s still extremely helpful. And it’s a lot of fun to play with a mimicked interface.

7. Prepare an app glossary and provide the context

A localization glossary contains in-app terms, like names, menu texts, items, statuses, characters, and other concepts that need to be used consistently in the app. Remember, consistency with the glossary ensures better UX for your end-user. Besides, a glossary helps optimize and streamline the whole localization process.

A glossary, however,  isn’t the only input you submit to a localization team — the context is no less important. We are convinced that the best way to establish context is by arranging proper communication between app developers, copywriters, linguists, and localization project managers.

But the truth is that it’s hard if not impossible for the development team to always be in contact. That’s why we highly recommend designating a contact person. Because missing context can impede or affect the whole localization process and ultimate results. Besides, a proper localization platform can help to streamline communication in the cloud and on-the-go. And it’s worth your time since a well-done job ultimately pays off.

We hope you found this simple list of recommendations helpful for designing your apps. If you want to know more or need more help or advice with translation or localization, you can contact Alconost directly by visiting our website.

Looking for an app or software development company?

You can post a project on AppFutura for free and explain your needs for app or software development. You will receive quotes from qualified companies and will be able to hire the best candidate through a safe payment system.

Post a project

About the author
Alex Murauski

Alex is CEO of Alconost Inc., a global provider of localization services for apps, games, and websites into 70+ languages. Alconost can help app developers set up continuous localization and linguistic testing, and make videos and trailers for Google...

You might also like