Change is inevitable. Growth is optional John Maxwell

While Maxwell’s quote may seem, either naively or intentionally, over-generalized, it is all but the law of the land when it comes to software development. If you have an in-demand app, someday you’ll find yourself on the fence, brooding over two options: expand into new markets or stay where you're at, which in the long run means giving up some of your market share. In reality, it’s a proverbial Hobson’s choice. It’s only a matter of time before a coveted app goes through app localization.

Carrying out a profitable localization project has never been a cushy job. There are a lot of pitfalls and success factors that contribute to the project workflow, which in the end, make up a high-quality product. That’s why we’ve asked our colleagues from Alconost, who for years have been dedicated to professional localization of apps, to share with us their experience.

Hopefully, these expert tips on localization challenges and ways of addressing them will save you some time and keep your pocket fuller. Read on, we’re about to take a deep dive.

1. Know the app market like the back of your hand

Not knowing your user well enough is the biggest danger when entering new locales with an app. First and foremost, you should make sure that your app will be well-received by the local market and will demonstrate a positive ROI (return-on-investment). Two simple questions will help your decision-making here:

is your app in-demand on the local market?

And is it something local users are willing to pay for?

Looking at the localized target audience for your app

Your research should provide various odds and ends about your user personas: demographic split, behavior, lifestyle, tech-habits, OS-preferences, cultural perceptions, social trends and many other characteristics.

Your findings might indicate that although the app you offer seems interesting for the target audience, you need to differentiate the paid features. So, it might be the case that some free perks instead of paid options bring added value to your users — be ready to adapt.

Analyzing app competitors in that language and region

At this point, another good idea might be to have a look at the in-market localization projects carried out by your competitors — which of them are prospering and which failed — and why? For example, if you’re trying to launch a mobile app for pets and owners in Korea, have a look at who's already there and how they’re doing.

Have customer support for your localized app ready to go

Finally, get ready to provide proper customer support in the local language and ensure communication with users. This process has proved to be essential, since timely feedback is a goldmine when entering a new market.

All in all, the better you get to know your market, the more chance for success your localization has.

2. Pay attention to cultural differences during app localization

You might study the market figures inside out, but that’s not all that’s needed.

You also have to get to the heart of your audience, understand their culture, values, lifestyle and taboos. What for? Because releasing localized versions of your app is pretty much the same as launching it for the first time. The difference between the launch of localized app and new ones is that the first one is not a one-off job, but instead, an ongoing one.

So, how do these cultural variations show up within a localized version of an app? Some flaws might appear when localizing names, jokes, colors, numbers, measures, or even entire images. It’s extremely complicated if not impossible to keep all these details under control. And what if you need to localize your app into 10 or 20 languages within just a few weeks?

That’s why our best advice is to engage professional localization specialists in your project, with native linguists taking care of all the cultural aspects within the translation.

A powerful illustration of how we handled such cultural differences was a localization project for the game Streets of Rogue. Localizing the rogue-like dialogs and humor into 7 languages within just 2 weeks was the most challenging part, involving a special approach to staffing proper linguists on the project. In the end though, it turned out awesome, in our humble opinion, and was loads of fun to boot — have a look for yourself!

Translation examples of some humorous dialogs in Streets of Rogue

3. Be ready to become a part of the app translation process

Of course, it’s a must to hire top-notch highly-rated translators, but that’s not the end of the job — actually, it’s only the beginning.

Creating an app localization glossary

In fact, before the very start there’s some homework to be done. This is preparing a glossary, a list of terms and names that should remain unchanged within the localization process. Once done, this asset ensures consistency, which is always a big challenge for a localized app.

Maintaining a translation memory

The other half of the battle is done by a localization team. Our localization team at Alconost creates and maintains a translation memory for each language — a database of all the translations ever submitted to the TMS. The translation memory leverages continuous localization to a great extent by spotting fuzzy matches (repeated and partially matching texts) and ensuring 100-percent consistency.

Stay in touch with your localization team

Finally, be ready to stay in touch with the localization team and provide good context. Context is essential for accurate and natural translation. This is a time investment that will pay off in the long run. After all, there’s a number of cloud-based localization management platforms that allow communication between all team members in real time.

4. Do your app localization in a technically savvy way — avoid repetitive manual tasks!

Do you best to keep up with advancing tech when it comes to your app localization project. This is not for the sake of following any hyped-up trend, but simply because it’s efficient. We can capture our localization mindset at Alconost in a single flowchart below.

Speaking from experience, the best piece of advice we have is to fit your continuous localization process within continuous delivery workflow wherever possible. By doing so, you ensure that both streams are working independently, localization of frequently updated strings is a continuous process, and is tested within the standard QA process.

When it comes to linguistic QA, you’re better off doing it simultaneously with functionality testing. While the client’s testers are checking a translated build for bugs, the localization crew is examining the translation and UI or errors.

Continuous Delivery Process carried out by Alconost in their app localization services

Translation Management Systems

Now let’s get down to the localization part of the diagram. There are various handy Translation Management Systems, and experience shows that the right system for a particular project is a function of the preferences of the product teams and app architecture.

For apps, we’ve been most frequently asked to use Crowdin, while for GitHub projects it’s mostly GitLocalize, fully integrated with the repository.

Translation Management Systems, as a rule, support various formats for resource files and incorporate translation memory and glossaries. However, this is not paramount. If your resource files are not hard-coded and supported by TMS, then you’re safe. If not, then you need to convert your files to a specific intermediate format for input into the TMS. Once translated, you convert them back again.

The whole endeavor ends up eating a lot of time and effort and bringing no result, which is why we’re often asked to develop tailored integrators, convertors and connectors to meet specific project requirements.

So, the first challenge is to keep resource files extractable and interchangeable. Let’s have a closer look at some other common bottlenecks — forewarned is forearmed!

A bottleneck factor: Encoding translations

So, the first thing to check is encoding. Sometimes, it takes a great deal of time and effort to remove those awful ��� characters in the target language after localization. Our recommendation is to use Unicode over ASCII whenever possible. UTF-8 is the most common and space-efficient encoding. So make sure your input files are encoded correctly.

A bottleneck factor: hard-coded strings

Another painful case is hard-coded strings or those strings that can only be extracted using a dedicated tool. The problem is that the text within these strings is not extracted when passing through regular converters, and, as a result, not localized.

Ultimately, when a localized build is tested, there are untranslated pieces of text within a target language. So our recommendation here is: use placeholders and formatters and make them part of the phrase, so they can be translated and inserted in context.

A bottleneck factor: numbers and units of measurement

Besides this, you need to pay attention to ensure that numbers and units of measurement are also inserted within extractable text. Here’s a little example of “to-do” and “not-to-do”:

No: “Mommy ate “ + %num + “ apples.”

Yes: “Mommy ate %num apples.”

Those technical errors are typically revealed during app testing, but can easily be avoided with a little up-front “homework” — internationalization.

A bottleneck factors: UI errors

And finally, the QA of a translated build might reveal some UI errors, namely mismatches between the size of UI elements (menu items, buttons, screens, etc.) and the text.

So, when building interface elements, it’s generally a good idea to plan for at least 30% extra space (or even more, if possible) for other languages. This is especially valid for short strings (menu items, forms, etc.).

Another piece of advice is to build your interface around your worst-case (in terms of possible text length) localization language. For example, the German text version is on average 30% longer than the English one, while Russian test is on average 10% longer. The same is usually valid for Arabic localization. On the other hand, traditional Chinese characters generally take up 30% less space than English letters.

To sum up, linguistic testing is all inside the TMS (translation memory system), and it’s completed before translated resource files are converted and sent to the source code/repository.

5. Build a team and arrange the app localization process

Now that we’ve navigated the most common app localization pitfalls, you see that there are marketing, linguistic, cultural, development, testing and management tasks within each project. This means that you need to assemble a team and set up the right processes from the get-go, so that your localization project runs like a well-oiled machine.

The options are many: build your in-house team or outsource localization, depending on your resources and goals. Just make sure you select a professional trusted solution and get prepared in advance.

We hope that these tips have been useful, and wish you all the best of luck with your localization projects!

This article was contributed by Alconost, a global provider of localization services.