How To Grow Your App’s Audience Using Localization: Small Steps to Giant Leaps
Clear-cut as it may seem, some app developers treat localization as an afterthought. However, being well prepared in advance and designing a suitable workflow within the rest of your business processes from the very beginning cuts out a huge amount of work.
If you have a cool app or game, you’d love it if everyone tried using it, meaning literally everyone in the world. Here’s where localization helps. For most mobile app developers, language localization and adaptation for cultural nuances is only a matter of time and it’s never in vain.
Localizing an app into ten, twenty, or sometimes even fifty languages is a thoroughly worthwhile undertaking. First of all, it helps improve the user experience, starting from the app’s store page itself, right through to a premium upgrade. As a result, app localization increases user loyalty, as well as the number of daily active users and their lifetime value, and it ultimately maximizes your return on investment.
Now that you’ve seen that the juice is worth the squeeze, let’s dive in and check out how to set up an optimal localization project.
Getting ready for localization
Let’s start from the very beginning. There’s no magic pill for instant localization, but proper routine processes will take you in the right direction.
1. Study the market inside out
Make sure that localizing your app is a worthwhile undertaking. You need to consider some important aspects:
Audience: Who are your target audience? Do they speak different languages? If so, which languages should be your starting point for localization? How are potential users segmented in the local market? What are their specific needs and preferences? Do they need your product at all, and how are they likely to benefit from it? How does your target audience differ from your current users? What cultural differences and local guidelines need to be considered? Should you localize your interface or subscription plans? Also, should the paid-for features for this market be the same as for your current one? What types of content should be localized and in what order?
Competitors: Is there a niche in the local market? Are there any competitors, and have they tried to localize their products? What lessons can be learned from their experience?
Market research will provide useful insights for adjusting your future localization workflow. First of all, you’ll get a list of countries vs. languages. Make sure you take into account both of them. For example, people in Canada speak French or English, depending on the region they’re in. Thus, your localization plan might cover Canadian English and French, which have some subtle differences by comparison with French (France) and English (Great Britain). Sometimes, it also makes sense to learn about the most popular languages for localization.
2. Make sure your app has internationalization
While many people use the two terms synonymously, they actually mean two different (though related) things. Both internationalization and localization are aimed at making a mobile app suitable for a specific locale. Internationalization, however, focuses more on the technical aspects of app development, while localization is more about understanding the specifics of a certain culture and adjusting the app’s content to it.
Localizing a mobile app is the process of making it look native to a certain target audience. It includes, for instance, translation of the text into the required language, conversion of all necessary metrics, inclusion of culturally specific visual elements, and consideration of local regulations.
Internationalization, in turn, focuses on the technical side of preparing an app for localization and covers the processes related to the app’s structure and architecture: multi-language options, different text formats, and extracting texts from the source code.
3. Prepare a localization kit
A localization kit is a set of all the files and documents needed for efficient localization. First and foremost, these are resource files that are transferred from the source files (the code) and that need to be translated.
Another must-have element is a glossary, which should contain the most important and high-volume words, phrases, and terms within an app or game (names of characters, statuses, in-game items, locations, etc.). A glossary helps maintain consistency within the whole translation and speeds up the localization process. Translators can make use of it without having to ask app developers directly. A glossary might be a separate document or a section within the interface of a translation platform (if the company has already chosen one). Here is an example of what a glossary looks like:
Screenshot of a glossary from the CrowdIn platform
From my experience, it’s also good practice to provide the localization team with a style guide brief. Style guides are a set of instructions that help translators uphold the brand message and ensure that the translation is accurate. It defines the tone of the translation, the brand voice, the usage of specific slang, correct forms, acronyms, etc.
In addition, the lockit (short for “localization kit”) may contain a translation memory (examples of previous translations) and files that provide context: gameplay videos, audio tracks, or even (on rare occasions) a product build.
4. Assemble a localization team and choose a platform
A localization team usually includes:
- a project manager responsible for monitoring work on the project and deadlines.
- a localization engineer, who is responsible for organizing and managing workflows.
- a QA manager, who is responsible for the quality of the localized product.
The localization process also involves assembling a team of translators, sometimes for as many as 50 languages, and even extending to specific dialects.
Though some developers resort to machine or crowdsourced translations, these methods can’t guarantee consistent quality by comparison with a professional translation.
Some companies have their own localization teams, while others prefer outsourcing the whole of the localization process. Even if you’re unable to assemble an entire team, it is worth having at least one or two responsible individuals.
This step is strictly related to selecting a localization platform. If localization takes place in the cloud, it’s easy to keep track of all updates and provide simultaneous access to as many team members as is necessary. Furthermore, this allows communication between managers, developers, translators, and editors to run smoothly.
Excel sheets are less advantageous—even if they are downloaded onto a localization platform, they don’t allow for real-time collaboration within a large team.
Localization case study of the inDriver app
inDriver is a transportation app that operates in 31 countries and supports 11 languages. It started out as a small local ride-sharing app. The biggest challenges that the inDriver team faced during the localization process were:
- Team decentralization and a lack of processes: translators were responsible only for their part of the work and had no idea what other team members were doing.
- The issue of volume vs. quality: some translations were performed by communities that appeared to be unwilling to translate small amounts of text while still delivering excellent quality.
- Rare languages and dialects: the community couldn’t provide a translation for these.
In the end, inDriver resorted to a cloud-based translation platform and transferred the whole project there. This helped synchronize the whole team and allowed the appropriate management processes to be established. The company also ordered professional translation for dialects, as well as extra proofreading and testing for the translation that was done by the community.
Localize your app
Returning to the topic of internationalization, as mentioned in the preparatory phase, developers should be able to extract the resource files needed for localization from the source code. Usually, localizable strings are in .xml, iOS .strings, .resx, .po, .json, or other convertible formats. If not internationalized properly, an app might need special integrations for extracting and translating texts.
Before we proceed to the localization process, here are the key components of app localization.
1. Localization of the app store page
The idea behind app store localization is to make an app more appealing to the local audience. Here’s what it entails:
- Selecting keywords is a must. Different countries have different frequently searched keywords, and a simple translation of these is not sufficient. Keyword localization means researching close terms and selecting the most popular ones for the locale using specialized ASO tools.
- App description localization means not only translating but also adjusting the description for the relevant user group by using culture-specific keywords, phrases, jargon, etc. Both Apple App Store and Google Play allow for multiple localized descriptions for an app. That means an app may have a default description (say, in English) and several localized descriptions that will be shown to users depending on their location. It’s also okay to highlight different app features in different descriptions depending on user preferences and localized app versions.
- The localization of screenshots is the last (but by no means the least important) step when it comes to app downloads.
If your app or game also has a video preview available on the store page, it would be a good idea to consider localizing a clip, too. Apart from full video localization, there are such options as dubbing and subtitling; consider them if you are on a tight budget.
The case of Full HP Ltd.
Both the app’s screenshots and its description were translated into Turkish, leading to an 18% growth in user visits. Statistics also showed that users were mostly attracted by screenshots and the text they contain—only a small number of users actually read the app description. Once the screenshots had been adapted for the local audience, the number of app downloads grew significantly, thereby boosting interest in the app.
It’s not enough to simply translate the text of a screenshot—some countries may require a different color palette, the addition or alteration of visual elements, etc.
Screenshots of TikTok, fully localized for Russia and Brazil. The color scheme, the people’s faces, and the design have all been adjusted accordingly.
2. Localization of in-app texts
Text localization is not just about translation—it’s about making the text look “native” for users. This means using specific phrases, words, and jargon that are common for a certain user group.
Once the localization is complete, developers assemble a localized build of an app and, whenever possible, test it for bugs and translation flaws. It’s a good idea to get a second pair of eyes to perform the testing and editing.
It’s also important to reach out to the user community on social media, the forums, or technical service messengers and ask them for feedback or to help you out where clarifications are needed (or maybe even to serve as beta testers for your app). Though the community cannot translate massive amounts of text quickly, it can provide valuable feedback about any issues with the translation, UX, or UI.
3. Adapting the UX/UI
There are many aspects of UX/UI localization that need to be considered. Different user groups may prefer different designs, color palettes, or visual elements in products. In addition, the text in images within apps or games also needs to be localized. If this is hardcoded, the images will need to be redesigned from scratch.
Sometimes, interface elements also need to be adjusted to suit the local language (in terms of length or word order). It is, however, good practice to allow for at least 30% more space than is necessary for texts in UI elements, especially menu items and buttons.
For the Korean UX/UI localization of MyCafe, the developers adjusted not only the buttons and dialog boxes but also the background design.
UX/UI localization usually involves graphic designers, UX/UI designers, and developers.
Agile: what it has to do with the localization process
The Agile methodology is rooted in product development and is a perfect fit for all product development cycles. In contrast to the waterfall approach, the non-linear Agile method allows several tasks to be performed simultaneously, without them interfering with each other.
An important requirement is that Agile localization happens on a cloud platform, where all team members, both internal and external, can collaborate.
Thus, this is what an Agile localization process might look like:
The diagram displays an overview of a typical app localization process at Alconost. Agile localization is advantageous because it facilitates a faster time-to-market, makes it easier to find and fix errors in a timely manner, meaning less manual and extra work, quicker localization testing, and, as a result, reduced project costs.
Agile is development-friendly and works in tandem with automation, which is another key element of an efficient localization process.
Finally, since Agile localization allows for iteration, it fits perfectly with the philosophy of product development cycles and makes releasing new features for several locales at once a clear and easily manageable task.
Continuous localization as an example of an Agile process
Thus, the Agile methodology makes it possible to constantly update apps, giving rise to other fundamental iterative processes: continuous delivery, continuous integration, continuous deployment, and continuous localization. Suffice it to say that continuous localization should ideally be an integral part of the continuous delivery process.
For continuous localization to be a possibility, automation is a must. As the diagram shows, resource files, a translation memory, and a glossary are all uploaded to a TMS (translation management system or platform), ideally a cloud-based one, where translators and other team members can collaborate.
The idea is that even small sections of localizable content, once ready, can be integrated back into the source code and come the whole way from build to deployment into a subsequent app release.
TikTok case study
TikTok, which operates in over 150 countries around the world and in more than 75 languages, chose the Agile methodology and continuous localization as the only acceptable localization option. The company needed localization into some rare languages, such as Afrikaans and Tagalog, and the app was updated on a weekly basis.
Those are extremely strict conditions, which sometimes even required a 24-hour turnaround time. The cloud-based localization workflow in CrowdIn, which the company had selected as its platform of choice, enabled them to meet all their deadlines, however, and to comply with the previous translation memory.
Bottlenecks in the localization process
Although it may seem perfect at first sight, this process can experience some bottlenecks. Let’s see what they are—forewarned means forearmed.
1. Lack of integration
As the adjusted diagram below shows, one of the most frequent bottlenecks in the process occurs when resource files containing texts for translation need to be obtained from the source code and then subsequently downloaded onto a translation platform. Two possible issues can arise here:
- The text is not extractable from the source code. As a result, the resource files do not contain the whole text.
- The text is extractable, but the format of the resource files is not compatible with a translation system. In this situation, tailored integrators or connectors are required in order to make translation on a platform possible.
These problems usually occur because of a lack of internationalization, the technical preparatory work that was described at the very beginning of this article. Let’s take a look at why texts can be partially or entirely lost when creating resource files.
- Hard-coded text
Texts in the code itself cannot be extracted with translation tools and are lost for translation purposes. For example, if you hard-code some texts in images or other design elements, these elements will remain unlocalized. Seamlessly, if only part of the text is hard-coded, the text will not be fully translated, or some of the context will be lost.
- String splitting
If sentences or phrases are split into several parts, or placeholders are included without any context, it’s easy either for them to be extracted for translation as separate content sections or for the context to be lost entirely.
This happens, for example, when numbers are placed separately from units or some terms within placeholders are outside a sentence. It is good practice to provide descriptions of the context for placeholders.
- Encoding issues
These can arise when a localized build is assembled. If you get some ��� spécîål” characters instead of text, this might have been caused by an encoding issue.
To avoid encoding mistakes, it’s better to use Unicode (UTF-8, most commonly) over other encodings.
The same thing applies to fonts. If certain fancy fonts don’t contain glyphs for all languages, it might be necessary to choose different fonts for different languages.
2. Lack of management and automation
Assembling a team of translators for dozens of languages can seem a nightmare if the process is not properly optimized. First and foremost, for complex projects, it’s better to have everything on an online translation management platform. A cloud-based platform allows everyone to see updates in real time, view comments without any delays, and synchronize the localization with a glossary or previously translated texts (a translation memory).
The second thing to do is to appoint a dedicated project manager to monitor deadlines and progress and act as an intermediary between other team members.
3. Lack of communication and context
Context is provided by the glossary, translation memory, comments for placeholders, translation comments on the platform, and timely communication. All these components are important for an accurate and quick translation.
For example, a lack of communication can cause such problems as the incorrect translation of metrics and stand-alone UI elements or the erroneous interpretation of terms that can have multiple meanings.
4. Lack of relevant translation experience
This rule is simple. Firstly, translators should play the game or use the app.
Secondly, whenever possible, translators should have experience of working on mobile apps. Otherwise, developers risk getting back inauthentic texts, full of incorrect or unusual terms. Even subtle nuances in meaning count towards the user experience.
5. Lack of user feedback
Once you have the localized build assembled, it’s not a bad idea to ask users to provide feedback on a beta version. An important prerequisite is that you should have the proper channels and processes for collecting feedback.
For example, your team members might engage in discussions within the user community on social media or check chatbots. A trial by fire of this nature is the last (but by no means the least important) step in the localization process.
Conclusion
In order to successfully localize your app, you need to know your audience and competitors, implement internationalization, assemble a team, strive to apply the Agile methodology in all your processes, and choose a localization team that will help you on this journey. Stay Agile and reach for the stars.
