App translation or software localization is not without its challenges. This guide will address the most common localization pain points that come with any process of taking your software global. More importantly, it intends to give you a clear direction on what to do in each case. Off we go!
Which Internationalization Library to Employ?
Inevitably, the software localization process is tricky, a challenge to get right, with lots of mistakes to be made. We have a variety of tools, libraries, and formats to choose from and each consists of useful solutions for specific problem areas.
Ultimately, we have to narrow our decisions to some technical choices. Each programming language domain has different strengths, and some tools work irrespective of a specific language. However, some industry-strength solutions have withstood the test of time. For example:
- gettext – a well-integrated set of tools and documentation for internationalization and localization,
- i18next – a complete-solution web application from mobile and desktop.
Nevertheless, over recent years, there have emerged SaaS platforms, such as Phrase, that work closely with overall business needs to provide a better solution in terms of integration and support.
Your requirements should include stability, reliability, convenience, and how directly it addresses each problem area. It is important to select the ideal technological choice to avoid any pains experienced by utilizing a tool that is not designed for the job.
Which Message Format to Use?
There are various formats to store translation messages. They include xml(XLIFF), JSON, PO/MO, CSV, and much more, each with different layouts and variants. Such a plethora of choices also is a major pain point. Which one should you be using? If you go for a library that uses a custom format, the chances it will integrate with other tools is minimal.
You can ease this pain by always choosing well-integrated message formats or figuring out a way to convert from one type to another. Everything has a tradeoff. In the future, you may need to migrate those messages in a different format so it’s best if you have that capability now.
For example, using Gettext PO files has good support and it can be easily parsed. Phrase understands a variety of formats and platforms. Nonetheless, choosing the right format at the very outset can have great consequences in the long run.
How to Reuse Message Strings?
Reusing segments of text that have been used previously is crucial for accelerating parts of the localization management process. It can take a significant amount of time and money to properly translate content and you should be reusing it whenever possible.
It’s not ideal to keep them in a file or a document. This would be easy to manage in the beginning, but later on, these changes can be very hard to manage and track, especially in multiple languages.
Ideally, you should have a database that stores sentences and paragraphs of text that have been translated before. This should be presented in a searchable form easily associated with the right context.
This is accomplished with databases called Translation Memories or ™for that kind of work. If you haven’t heard of this term before you can read about their functionality in this article.
The benefits of appropriate reusability should not be overlooked even in the translation process. Having this kind of support dramatically improves the quality, speed and consistency of your end product saving significant time and translation expense.
Can We Automate a Part of or the Whole Localization Process?
When dealing with localization, automation is critical. Determining what to automate, how, and when, are important technical decisions that need to be resolved as early as possible. Failure to deal with it now means you will likely spend your time on manual tasks later.
Today, there is an increased interest in what we call continuous localization, which in layman’s terms means the attempt to incorporate automation as part of the continuous integration/delivery pipeline. For example, the following flows:
- Collecting all of the software strings in one place,
- Checking what needs localization,
- Creating localization packages,
- Updating/Syncing the messages in production,
- Extend by adding quality controls.
All can be part of a module that can run on every commit, thus shortening the feedback time and improving the agility of the team.
How to Test Different Locales in the Ui and Adapt to Differences?
It’s really tricky and painful to cater to all different supported variants of locale elements in the UI. Translated text often requires more space than the same text in the source language. In addition, if you support LTR and RTL directions you have to make necessary adjustments.
It’s not very cost-effective to test many variants at the same time in an e2e testbed, so a different solution is preferred. Pseudo-localization is the way to simulate translation of UI strings that look like English text but allows for expansion in the code by configuring some parameters. For example here is the string Lorem Ipzum in Pseudo Format and 0% expansion:
Here is the same string with 30% expansion:
£ôřè₥ Ìƥƨƺú₥ ℓôř
The benefit of this approach is that it allows you to configure the expansion of the string on the fly, thus making locale text variation testing much simpler.
How to Provide Context to Translators?
When compiling messages to be transferred to translators, you should not neglect to provide an appropriate context. This may include related images, screenshots, or tickets that convey the translator the necessary information to be able to translate the strings the best way possible. If you don’t do that, the translator will most probably not offer the most accurate translation, or they may come back to you to ask you about the missing context. This could interrupt your current workflow more than you think. Phrase allows you to provide context screenshots for each key attached, which is an effective way of improving the quality of your translation workflows.
A more efficient approach is to be more proactive and propose to offer a checklist of localization deliverables together with the translatable strings – even if the messages represent isolated instances. That way you can collaborate more efficiently and save time in-between.
I hope I could offer you some useful advice on how to handle the biggest pain points of software localization with confidence.
If you want to get even more insights, make sure to check out the following articles: