Software localization (or l10n) refers to adapting a digital experience for users who speak other languages or live in other countries. It moves beyond basic translation to adjust user interfaces on a cultural level. It’s not just what you’re saying; it’s how you’re saying it.
Since great user experience depends on how quickly a user can understand and interact with a given page, window, or screen, the more context and cultural familiarity you’re able to provide, the better the value of your product.
We’ve compiled a list of 7 software localization best practices to help you on your way. Following these guidelines will make localization easier, so you can reach more people and provide a global experience to customers.
What is software localization?
Software localization is the process of adapting your software to the language and culture of your end user, as well as translation it includes things such as localizing date and time formats, currency symbols and potentially text direction.
Software localization is different to internationalization (i18n). Think about it like this: In localization, you’re adapting a customer experience. Internationalization requires you to adapt your code.
Internationalization refers specifically to the design and development of a product or application, so that it can be localized for target audiences that vary in culture, region, or language. In other words, internationalization is what allows localization to happen in the first place.
Rather than hard coding each language, internationalization replaces code with placeholders that automatically retrieve the correct language for the user without engineering changes. Internationalization is typically done by software developers, while localization is done by translators.
You’ll want to make sure you start with any internationalization work before completing localization projects. Software localization adapts the internationalized software into other languages and regions.
Localization instead refers to the translation of that separated content into a specific language, and usually occurs after internationalization. But it goes further than that. It can include the cultural and country-specific aspects of different languages, such as:
- Accounting standards
- Links and other resources
- Calendars
- Hand symbols, gestures, or signage
- Culturally appropriate images
- Dates and times
- Spelling and phrasing, such as the differences between the Spanish spoken in Argentina and Spain
- Right-to-left languages like Arabic or Hebrew
Here’s what localization looks like in action. Let’s take dates as an example. The United States signed the Declaration of Independence on July 4, 1776, or 07/04/1776. That’s how the abbreviation would be written in the U.S., anyway.
But in the U.K, you’d read: The United States signed the Declaration of Independence on 04/07/1776. We’re still talking about July 4 in this example, just from a different date formatting perspective.
Implementing software localization requires a repeatable, solid process you can use to ensure that no matter how many languages you want to operate in, you’ll be able to do it easily and efficiently.
About software localization processes
The software localization process takes three common forms:
1. Waterfall localization takes place at a specific time in the software development cycle, either at the very end (a post-release method) or during a specific period (the string freeze method). Once the translated text is completed by the localization service provider, the software strings are manually uploaded back into the application for merging and publishing.
Benefits:
- Fast time-to-market in your source language as localization starts after the product is launched
Downsides:
- Delays the translation process and slows rollout in multiple languages
- High risk of design breaks when product is translated
- High costs to fix localization bugs
- Risk of poor UX
2. Agile localization syncs the localization process with the development process so that they are both operating simultaneously. New and modified strings are automatically detected by the localization software and delivered whenever they are ready for merging and publishing.
Benefits:
- More efficiency and flexibility when it comes to your localization workflow
Downsides:
- More complex and can require dedicated localization engineers
3. Continuous localization is a step closer to making localization automated and seamless. While similar to agile localization, it fully integrates with the CI/CD method that companies use to frequently deliver software to customers. Here’s the main difference according to Miguel Sepulveda, Global Localization Manager at King:
“In continuous localization, the content is always ready for a release. In agile localization, the content is not always ready to be released; we need to wait until the sprint is completed.”
The easiest way to grasp continuous localization is by imagining your workflow as a never-ending cycle with five key steps:
- Developers create translation keys and store the code in a repository like GitHub (which connects with a TMS).
- The translation keys are supplied to project managers.
- Managers define the project scope, pre-translate, and assign tasks to linguists for translation.
- The translations are reviewed and verified by a QA team.
- The translated keys are pulled back into the repository by developers, and a semi-automated flow for continuous deployment of localized assets is achieved.
With Lokalise’s two-way integrations that sync content with code repositories, CMS, and design tools, you can start localizing at the design stage, which is complementary to continuous localization.
Benefits:
- Catch design breaks at an early stage of product development
- Get feedback from all stakeholders sooner
- Lower risk of localization errors
- Launch in multiple markets simultaneously
Downsides:
- Potentially longer time to launch as localization is integrated in the product development phase
7 Software localization best practices
Software localization can be a complex process but if you keep these seven things in mind, you’ll be able to set yourself up to ensure that what you’re building can be localized fairly easily and quickly.
Note: This list is by no means comprehensive—these guidelines cover the basics to help you get set up.
1. Use separate resource files
We already covered how any solid software localization starts with i18n. Think about it like this: Internationalization is creating global-ready code. Without it, your content can’t be localized unless you write additional code.
In many cases, by default, the text is hard coded within an application, but you’ll want to start by breaking down all of your text by language into separate files so that it’s easy to export and import them without harming the rest of the code.
This means you need to structure your application by including separate files for each language. Avoid hard coded strings and use appropriate 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).
For file formats, keep the content as clean as possible by nesting the strings to logically group each set of translations. Naming each string clearly, so you know exactly what it refers to and where it goes, is important. (“Abc” is not going to be as helpful as “Primary CTA”)
Pro tip: Create a naming convention that makes the most sense to your team. Then, use a tool like Lokalise (oh, hi! ????) that supports import/export functionalities for translation files in any format.
2. Manage your code to handle multiple languages
Once you’ve separated your files, take a look at your code. When coding a given user interface, use placeholders for the text that call back to your translation files.
A quick note on placeholders: 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.
Take a sign-up link, for example. Instead of literally typing in “Sign up” for that button, code in a placeholder that will display “Sign up” in the correct language instead.
The exact placeholder used varies based on the technology and coding language you’re using, but it will tell your application that it should show the correct translation for the chosen language rather than a specific word. It looks something like this:
Along with using these placeholders, you’ll also want to avoid concatenated strings because word order and syntax vary by language, and this can make parsing difficult.
Also, make sure that you’re providing comments and context wherever you can so that your translators can understand where in the UI a given string appears and how, since this impacts the final meaning.
Pro tip: Use universal placeholders. This allows you to import/export your content in different file formats by converting placeholders into the format you need. Also, use a TMS that allows you to insert placeholders and, where possible, that the linguist can ideally work around.
3. Build in space as language length will change.
Different languages take up different amounts of space on a page. So, you should always assume that text will grow or shrink.
For example, translating English to German can cause text to expand by up to 35%. English to Swedish, on the other hand, can contract text by up to 35%. If you’re translating into Asian languages like Chinese, Japanese, or Korean, you’ll also see vertical expansion from English.
This means any code you create must take changing text size and length into account. This is best done well before you ever sit down to code. Thinking through how different languages impact the design in the design phase will save you many headaches further down the road.
Translating the text first and then optimizing the UI in all languages will help you see how your designs will change based on the target language and make amendments pre-development.
As we covered in the section on continuous localization, this allows you to avoid design breaks, lower the risk of localization errors, and launch in multiple markets simultaneously.
Pro tip: Build with flexibility in mind to ensure that your design can accommodate different translations. Check out how you can do that with design tools like Figma, Sketch, and Adobe XD and Lokalise.
4. Verify your images and symbols make sense.
Similarly, in the design phase, you’ll want to make sure the images you’re choosing to include are inclusive and appropriate for each of your target markets.
In the U.S., for example, the waving hand emoji ???? is a common way to say hello or make your text appear friendly. But in Mainland China, that symbol means breaking off a friendship — the opposite of what you are intending!
You’ll want to check all of your images and illustrations not only for potential offensive trip-ups in other markets but also for meaningless or confusing symbols.
5. Be as precise as possible with the locale.
Thinking about language is a great first step, but as you expand into more international markets, locale becomes more important.
Some languages may be similar, but that doesn’t mean the culture is the same. Even in English, words, phrases, and spellings may be different if you’re in the United States, Canada, the U.K, and Australia.
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 content to customers in Canada and Belgium?
What if you want to display CAD for customers in Canada and EUR for customers in Belgium? You can easily do this if you plan with locale in mind.
Likewise, different cultural cues can exist by region within a given market. In Russia, for example, the culture in Moscow looks completely different to those who live in the Ural Mountains or Caucasia, and they may speak other languages in addition to Russian, like Tatar, Komi, or Chechen.
You’ll need to get specific about who you’re talking to in a given market, and what their culture is like, when figuring out your localization strategy.
When creating your language files and determining which languages to translate into, be as specific as possible with locale. Take French for example:
- fr-FR: French as spoken in France
- fr-CA: Canadian French
- fr-BE: Belgian French
- fr-CH: Swiss French
All of these locales will have slightly different ways of speaking, different cultural expressions, and different ways of approaching your product.
6. Create a style guide.
A glossary and style guide are key components of the language assets that you need to build to ensure your messaging and brand stay consistent across every market.
Ultimately, the consistency of your brand across different markets is critical to building trust with your customers. Creating a style guide and maintaining a glossary will allow your linguists to work fast while maintaining quality.
In your style guide, make sure to include:
- Branding, like product names or terminology
- Tone, especially formality and voice instructions
- Audience information, such as persona research or your value propositions
- Grammar, where applicable
Pro tip: If you’re working with an LSP or language partner, they should collaborate with you to create detailed glossaries and style guides to ensure consistency of terminology, style, and voice and incorporate target audience information.
7. Use a software localization tool.
You’ve seen how using a software localization tool or translation management system (TMS) can help you easily implement some of the important guidelines in this list.
Let’s take a step back to understand what a TMS is and what it can do for you. Broadly speaking, a TMS is designed to support management of the localization and translation process.
It helps to organize the localization workflow, track the progress of translation projects, and reduce manual tasks via automation. While each is best-suited to a specific use case, they generally include three main components:
- Computer-assisted translation (CAT) tools
- Workflow automation tools
- Project/team management and reporting
If you would like to better understand the main features a modern TMS should have in each of the above categories, take a look at this post.
Taking the next step in your localization journey
Finally, while this list includes 7 fundamental guidelines for software localization, there are a whole host of more advanced things you will need to keep in mind as your international expansion efforts progress.
So, what can you do next? You can:
- Explore our case studies, which are mostly related to software 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
Further reading
- Translation and localization: what’s the difference?
- Continuous localization 101: what it is and when it makes sense
- How to choose the best translation management system for your team and company
- Lokalise + Figma – start translating at the design stage and significantly shorten your time to market
- The complete guide to design-stage localization
