PDF CHECKLIST: Mobile app localization best practices
Building a mobile app? It’s crucial to make sure that what you’re creating can be localized fairly quickly and easily.
We’ve compiled a list of 25 mobile app localization best practices to help you on your way. Following these guidelines will make your localization efforts more straightforward, so that you can provide a global experience to customers regardless of country or language.
- What is mobile app localization and why is it important for growth?
- Best practices for mobile app text localization
- 1. Assume that text will grow or shrink
- 2. Use a tool that supports right-to-left languages (Arabic, Hebrew, etc.)
- 3. Consider implementing a pseudolocalization step
- 4. Use locale, not just language (and use 4-letter ISO codes)
- 5. Provide context to linguists
- 6. Use a glossary to keep brand terms consistent
- Best practices for mobile app image localization
- Best practices for mobile app localization development
- 11. Use appropriate file formats
- 12. Train developers on internationalization best practices
- 13. Avoid hard coding currency, time, and date formats
- 14. Use a tool that supports import/export functionalities for various file formats
- 15. Use a translation management tool that offers a nice placeholder UI
- 16. Take plurals into account
- 17. Merge iOS and Android keys
- 18. If using native iOS & Android frameworks – consider implementing a mobile SDK for OTA updates
- Best practices for mobile app localization workflows & QA
- 19. Use a tool with automation capabilities
- 20. Use a tool that has design integrations (Figma, Sketch, Adobe XD)
- 21. Use a design-led workflow to get localized apps to market faster
- 22. Do localization (l10n) tests at the design stage
- 23. Perform pre-prod QA
- 24. A/B test the customer journey
- 25. Push screenshots – especially for short strings & use a screenshot workflow
- Bonus: How to add mobile app localization to the App Store
- Mobile app localization best practices checklist
What is mobile app localization and why is it important for growth?
If you’re familiar with mobile app localization, jump straight to the best practices. If not, continue reading for two illustrative anecdotes and a quick explanation.
In the fall of 2017, Ctrip acquired Trip.com. They began investing heavily in localization to provide unique value propositions to the local customer base. Their ‘super app’ (which has succeeded in becoming a one-stop shop for holiday-goers) is now available in 40+ languages.
But that doesn’t even scratch the surface of their localization efforts. In Singapore, for example, where a lot of travel is outbound, they began local marketing campaigns promoting ‘staycations.’ In Japan, they launched a co-branded credit card with a local bank.
In 2015, Airbnb grew their Chinese traveler user base by 700% by creating localized signup flows for Chinese users. The new flow offered options to sign up using WeChat or Weibo accounts, which are two of the most popular social media platforms in China.
This shows that the limits of localization are endless and that it extends far beyond translation. The term localization comes from the word locale, which refers to the language a customer speaks combined with where they are from.
Before we get into the best practices, a quick definition: Mobile app localization is the process of adapting your application to suit a different language and culture.
Localization involves adapting every aspect of your app to fit your target market’s preferences, including unit and currency conversion, date formats, cultural norms, legal regulations, and different technological standards.
Best practices for mobile app text localization
1. Assume that text will grow or shrink
Different languages require different amounts of space in the design. For example, translating from the English language into German can result in a 20-35% text expansion. Whereas translating from English to Swedish can result in a 20-35% text contraction.
Here’s an example from Slack (who used Lokalise to quickly localize into 10+ languages):
Plus, if you want to include Korean, Japanese, Chinese, and other non-Latin script languages, this can also result in vertical text expansion.
Pro tip: Build with flexibility in mind to ensure that your design can accommodate different translations. Check out how you can do that with Figma and similar design tools in Lokalise.
2. Use a tool that supports right-to-left languages (Arabic, Hebrew, etc.)
It’s important to remember that some languages (such as Hebrew and Arabic) are written from right to left. As you can imagine, this can, and most likely will, distort or break your design and lead to bugs if not taken into consideration from the beginning.
Moreover, as localization is not just about translating words, your design might not be suitable for other markets for cultural reasons, which can lead to low adoption. This means your app interface might have to be changed entirely for right-to-left languages to accommodate your user experience.
Pro tip: Use tools that support right-to-left languages. For example, Lokalise has integrations with dedicated design tools like Sketch, which renders right-to-left strings.
3. Consider implementing a pseudolocalization step
Pseudolocalization is a method used for testing the internationalization aspects of software. Instead of translating the text of your mobile app into a foreign language, as in the process of localization, the textual elements are replaced with an altered version of the original language.
With Lokalise, you can use pseudolocalization to pre-fill language with content before linguists start working on translations. If you assume that your translated text will grow or shrink, having a function which allows you to increase or decrease the length of text allows you to ensure that translations won’t break the design once you have them.
For example, in the case of German, you can account for the text length increasing in knowing that it will be roughly 30% longer than English. Here’s what a pseudo-localized string for German looks like in practice:
Pro tip: Use a tool that supports pseudolocalization or has features to prepopulate text with machine translated values. Use brackets or an identifier to easily spot pseudo-localized strings in your app.
4. Use locale, not just language (and use 4-letter ISO codes)
Thinking about language is a great first step, but as your international customer base grows, locale becomes more important.
Think about this scenario: you specify “fr” for French as your language code but don’t take into consideration regional differences between francophone countries. What if you want to display different (but culturally relevant) content to customers in Belgium and France?
Likewise, what if you want to display CAD as the currency for customers in Canada and EUR for customers in France? You can easily do this if you design for the locale.
Pro tip: Add 4-letter ISO codes for different locales like (fr_be) for Belgian French. Use the locale settings to display the right currency without any need to change the language.
5. Provide context to linguists
In the past, linguists might have been handed a spreadsheet with all the content to be translated. They would translate hundreds of keys in a vacuum, with zero context of where the text fits in the design.
With Lokalise, linguists can translate one page at a time with screenshots that provide context. Since it’s far easier to show than to describe, this allows linguists to move faster and produce higher quality work.
Plus, different stakeholders can preview what the translated text looks like in the app interface, allowing them to provide feedback for any necessary amendments. For example:
Pro tip: Build a screenshot workflow by filtering out the keys that appear on a screenshot so that it’s easier for your linguists to translate screen by screen.
6. Use a glossary to keep brand terms consistent
This is a final tip on text localization. You’re likely familiar with the term glossary—it’s simply a list of words relating to a specific subject that includes descriptions.
In mobile app localization, a glossary and style guide are key components of the language assets you will need to build whether working with a language partner or performing translations in-house. Using a glossary will help keep your translations and terminology consistent.
With Lokalise, you can set up a glossary for your projects to define and describe each. You can also set whether a term is translatable or case sensitive. Here’s an example showing a non-translatable, case sensitive term:
The best part? When a term is used in the source language translation, it will automatically show up in the editor’s line box to ensure that the linguist doesn’t miss it.
Pro tip: When localizing your mobile app, use a glossary from the very beginning and keep it up to date to ensure that terminology is kept consistent and that your linguists can work fast.
Best practices for mobile app image localization
7. Separate text from images
This means that you shouldn’t embed text into images whenever possible. If you can, create a translatable text layer using a translation management system (TMS) that has optical character recognition or connects with dedicated design tools like Figma.
When you go to localize your content into other languages, you don’t want your images to have source language text in them. Separating text from images will allow you to easily localize images, so that people can better relate to photographs, illustrations, and other visuals.
Pro tip: Create a translatable text layer with a TMS that has auto-key detection and integrations with the design tools you already use.
8. Use a tool with auto-key detection for screenshots & in-editor preview
We’ve covered how showing linguists exactly where the translated text is to be displayed is convenient. But specialist software like Lokalise takes this a step further by allowing you to upload screenshots and link them to translation keys for specific projects.
Plus, you can enable automatic key detection to link the portions of detected text to existing keys. Here’s what that looks like:
This is actually really important for two reasons:
- It breaks content into smaller chunks, allowing linguists to move faster and work in a screenshot workflow (which we will cover in the workflow best practices).
- It gives linguists context for the text they are translating as they can see exactly where it fits into the design.
Pro tip: To learn more about using screenshots to localize your mobile app, check out this guide.
9. Make image source files easy to access
If you’re creating visuals in a design tool, make sure you not only give your localization team or partners access to the final file in the image format, but the source files too.
In some instances, you may want to keep the layout of your mobile app consistent but swap or hide visuals depending on the locale. You don’t need to make that decision at the design or coding stage.
You’ll just want to keep in mind that if you’re putting in images where the text can’t be extracted, that you might later need to swap or hide, and design accordingly to enable that level of flexibility.
Pro tip: When it comes to mobile app localization, design to enable flexibility in your images.
10. Test cultural imagery
A last note on image localization: delightful customer experience largely hinges on how quickly and easily a customer can understand and interact with a given page or screen. The more context and cultural familiarity you’re able to provide, the higher the value of your product will be.
You’ve likely come across this statistic multiple times: 86% of buyers will pay more for a better customer experience.
This means you don’t want to confuse, or even worse, outright offend your customers with your localized content. The solution? Test cultural imagery.
Pro tip: Adjust your content and UI/UX on a cultural level. Test it with select customers, champions, and native speakers of the locale you’re targeting in Beta before fully releasing it.
Best practices for mobile app localization development
11. Use appropriate file formats
Most companies often skip a crucial step that allows their content to be quickly and easily localized further down the road. Ideally, strings should be stored in resource files as opposed to living inside your code base. If not, it can be incredibly time-consuming and costly to refactor the entire code base.
To prevent this, make it easy for developers to externalize their strings by using the right file formats, such as JSON, ARB, YAML, XLIFF, Android Resources, or Apple strings. There is usually a standard depending on the programming language or framework you use.
Pro tip: Store your strings in the appropriate file formats so that your content can be localized without the need to write additional code.
12. Train developers on internationalization best practices
Localization would not be possible without mobile app internationalization (i18n). Well, actually, it’s technically possible, but you don’t want to create multiple versions of your code. That results in plenty of time wasted updating every single one of them separately each time you make a minor change in your app.
So, internationalization is what allows localization to happen in the first place. It takes place at the coding and development stage. To ensure that your product can be localized, it first has to be internationalized.
Think about it like this: internationalization is creating global-ready code. Without it, your content can’t be localized without writing additional code.
Pro tip: Avoid hard-coded strings and build global-ready code from the very beginning.
13. Avoid hard coding currency, time, and date formats
We’ve just covered why internationalization is so important to getting your app ready for localization. This means not hard coding any text, and especially not currency, time, and date formats.
The world is a wildly inconsistent place when it comes to time and date formats. Some countries put the month first and others put the day first. Some use a 24-hour format while some use 12-hour splits. Some use AM and PM and others do not. Currency varies too. There are more than 20 different types of dollars around the world.
This is why you will need to make sure that your user interface and content are adaptable and able to handle these cases. In a nutshell, to avoid facing any issues in the future, avoid hard coding text and UI elements. Use standard formats that will convert to the right time and date formats.
- Standard formats: use ISO time, epoch time, or UTC to store them.
- Libraries: Date.js or Moment.js will format them for you for each locale and convert to the right time formats
14. Use a tool that supports import/export functionalities for various file formats
We’ve covered why using appropriate file formats is so important: it allows your content to be localized without the need to write additional code. In light of this, using a tool that supports import/export functionalities for various formats is key.
Fun fact: Over 2.5 million files are downloaded from Lokalise every month! By importing your language files containing strings to be translated into Lokalise, linguists can work on the translations while you have full visibility over progress.
Pro tip: Lokalise integrates with all the major code repositories, meaning you can push and pull language files and continuously update your localized content.
15. Use a translation management tool that offers a nice placeholder UI
Placeholders play a huge role in most digital text environments. A placeholder allows for the insertion of dynamic content, such as a character, word, or string of characters. It may indicate where a developer needs to add a specific piece of code, so they are likely to appear in the translated text.
However, when translating, the entire placeholder should be kept intact and untranslated. This means you need a TMS that allows you to insert placeholders and, where possible, that the linguist can ideally work around.
Here’s what Lokalise’s placeholder UI looks like:
Pro tip: Because each platform supports different placeholder formats (iOS, NET, ICU, etc.), you should use universal placeholders. This allows you to import/export your content in different file formats by converting the universal placeholders into the format you need.
16. Take plurals into account
While English requires its speakers to mark the difference between singular and plural whenever a noun is mentioned, there are languages that do not force such a distinction.
In Spanish, you’ll have to pluralize not only the noun, but also the article that appears before it. So, what can you do?
Make sure your app can handle different languages with different plural forms by creating the fixed part of the message with variable elements (placeholders) that you can populate using a plurals library.
- Write the message in a way that is less dependent on plurals or use dedicated design plugins that support plural formats, so designers can preview how different plural forms will look in the design.
- Format your strings to cater for a range of values to cover different plural forms.
- Use a specialized translation management system like Lokalise that supports plural forms.
17. Merge iOS and Android keys
A common situation when you are developing an app for two or more platforms: some key names and values are the same and some are different.
Different platforms have different naming schemas. For example, iOS developers would prefer LoginButton while Android coders are keen on using login_button. By merging similar keys into a single key entry, you can avoid repetitive translation work and keep your project clean.
Pro tip: If you work with multiple platforms, include all platform keys on export.
18. If using native iOS & Android frameworks – consider implementing a mobile SDK for OTA updates
When we spoke to Ed Cooper of Revolut, he said that “it probably takes longer for Apple to review the app than for us to roll out a language with Lokalise.”
The irony is that there’s a lot of truth to his comment. Revolut releases new language updates quickly using the mobile software development kit (SDK) for over-the-air (OTA) updates.
So, what exactly are OTA updates? Lokalise’s mobile SDK allows you to publish and update text strings in your iOS and Android apps over the air instantly. Here’s how it works:
No need to wait days for the next deployment and re-submit a new version for approval to the App Store or Google Play.
Best practices for mobile app localization workflows & QA
19. Use a tool with automation capabilities
Automation is a catalyst that can directly influence the efficiencies of your company’s localization efforts.
Manually handling resource files is one of the biggest blockers to automating routine tasks. The first step is simply standardizing and centralizing the method for receiving, reviewing, and implementing translation files (which we covered in #11).
Once you have this set up, on a macro level, you can start setting up semi-automated localization workflows by syncing your product’s source code (using GitHub, GitLab, Bitbucket, and Azure Repos) with Lokalise to start pushing and pulling translation files instead of manually sending them out and getting them back to place them in a build.
On a micro level, you can build automation into your workflows to trigger specific actions like:
- Applying pseudolocalization (covered in #3)
- Applying machine translation to populate translation entries
- Automatically receiving notification updates
… and a whole lot more
20. Use a tool that has design integrations (Figma, Sketch, Adobe XD)
Lokalise is the perfect fit for designer-led localization at tech-forward companies that are scaling up. Part of what makes it such an effective solution is its seamless integration with dedicated design tools like Figma, Sketch, and Adobe XD.
In fact, the Lokalise design integrations are the most popular across the board. And for good reason: design-led localization is emerging as the most effective method to quickly release localized mobile apps.
21. Use a design-led workflow to get localized apps to market faster
Design-led localization is a powerful way to continuously release fully localized products like mobile apps.
For instance, by pushing and pulling keys from GitHub and your design tool, designers and developers can dovetail their efforts for a localization flow that follows the continuous deployment of features for your mobile app. Here’s an overview of what that looks like in practice:
The main steps of this workflow are:
- The designers/content team create the design with key names on Figma (or any other design tool).
- The keys and base language are pushed to Lokalise.
- Developers get the keys from a duplicate page on Figma.
- Linguists work on Lokalise throughout the entire flow.
Pro tip: Read this case study to learn how Withings increased their localized feature rollout by 90% with design-led localization.
22. Do localization (l10n) tests at the design stage
As we covered in the design-led localization flow above, l10n tests can (and should) be done at the design stage. By bringing designers on board early in the localization process, you’ll be able to avoid the otherwise inevitable issues that arise when localizing after development.
Plus, you’ll be able to save resources by catching localization defects early and reduce the risk of providing your customers with a bad user experience. Resolving bugs at the design stage is 10x more cost-effective than making adjustments after release.
Pro tip: Integrating designers into the localization flow earlier allows teams to quickly and easily check whether the design functions correctly across all target languages.
23. Perform pre-prod QA
Similarly to doing l10n tests for design-related purposes, you can (and should) also perform pre-production quality assurance (QA) for builds. This means your internal stakeholders or QA team can test the app with translations pushed from your TMS.
For example, using the Lokalise Mobile SDK (which we covered in #18), you can push the latest translations to your pre-production environment and allow your team members to:
- Test the app for final feedback
- Update the strings (if any)
- Instantly push to production
Pro tip: Similarly to integrating designers earlier, bring localization closer to the development workflow to allow your localization stakeholders to dovetail their efforts and remove double work.
24. A/B test the customer journey
A/B testing has been used by direct response marketers for decades. Why not use it to test the customer journey for a localized experience?
While A/B testing is similar to pre-production QA, it’s all about optimizing with feedback from customers.
Start by figuring out what you want to test. It might be one piece of localized content like the context of a button in your mobile app or the label. Build a variation and test it on users or beta testers to see which changes in your customer journey are more effective at guiding your customers to the intended outcome.
With the right tools, you can do this with target market testers in a pre-production mobile app with variations in your localized content. Take this example from Withings, one of our customers:
Since they want to provide great, personalized customer experiences, they test their Japanese translations early using native beta testers and quickly iterate the content based on feedback.
Pro tip: Depending on the nature of your product, you might want to run A/B tests with every feature release.
25. Push screenshots – especially for short strings & use a screenshot workflow
Last tip! Short strings can be tricky to translate – especially without context. Take for example a button that says, “see all” or “incorrect.” If a linguist doesn’t have context for the purpose of that specific translation or where the translated text fits on the design, it can be difficult to accurately provide translations in multiple languages.
We already covered how the easiest and quickest way to provide linguists with context is by using screenshots. It helps them move faster and produce higher quality work. But how do you set up a screenshot workflow?
Aside from offering multiple ways to upload screenshots, Lokalise allows you to link screenshots to translation keys. Once you have this set up, you can organize your screenshots with filters and tags so that only the linked keys are displayed.
This means linguists only see relevant keys and you can manage them as needed. This is especially useful if you have a project on Figma with designs for multiple pages, like so:
As you can see, it’s essentially live translation editing because each screenshot represents a single page, and each translation key is highlighted on the screenshot.
Pro tip: Use a screenshot workflow in conjunction with your design tools for specific projects, like an onboarding flow or a checkout process.
Bonus: How to add mobile app localization to the App Store
When developers think of mobile app localization, they immediately think of the content within the app itself. In fact, an essential part of the process is localizing your app listing on the App Store.
Metadata and keyword localization is crucial for your app’s discoverability and should always come first, even before the in-app content localization. In most cases, users would not download an app if the App Store metadata was not localized to that same locale.
Start by localizing your App Store metadata into as many locales as you can, even if your in-app content has not been localized for those locales yet. Start with the keywords, followed by the app name, description, and screenshots. This will increase your app’s discoverability for new regions.
Pro tip: Using the Fastlane plugin, you can automate App Store and Google play metadata updates. Use the data on the locales that are downloading your app to determine which markets to expand in.
Mobile app localization best practices checklist
Finally, while this list includes 25 guidelines for localizing mobile apps, it’s by no means comprehensive—there are tons of variations on these guidelines specific to your scenario.
However, this list covers the items we think are the most important for those who are just setting up their app for localization as well as those who are more advanced.
Get the free checklist to help you and your team on your localization journey and create a free account to apply some of these guidelines today.
So, what can you do next? You can:
- Explore our case studies, which are mostly related to mobile app localization, and see how localization correlates with business growth
- You can sign up for a free trial of Lokalise to see the tool in action
- Even better – you can book a demo with one of our product specialists and get a tailored consultation that can guide you on your localization path