As businesses continue to expand their global presence, software localization is increasingly important. But many product teams don’t know what software localization is or why they need it. If they do, they don’t know where to start.
In this blog post, we’ll dive into what software localization is and why it’s important, the top software localization processes, and the 10 best practices to help you localize your software with confidence.
What is software localization?
Software localization (or l10n) is the process of adapting your software 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.
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 software 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 software internationalization 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 use 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.
3 software localization processes
The software localization process can be approached in three different ways. Using the traditional waterfall model, the agile methodology, or the more modern continuous localization model. Each approach has its own advantages and challenges, and choosing the right one largely depends on your project’s specific requirements and goals.
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 of waterfall localization
- Fast time-to-market in your source language as localization starts after the product is launched
Challenges of waterfall localization
- 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
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 of agile localization
- More efficiency and flexibility when it comes to your localization workflow
Challenges of waterfall localization
- More complex and can require dedicated localization engineers
3. Continuous localization
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.”
Benefits of continuous localization
- 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
Challenges of continuous localization
- Potentially longer time to launch as localization is integrated in the product development phase
10 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
Files with hard-coded localizable elements are a nightmare to handle, so you’ll need to start by identifying all localizable text and creating a separate file for each language you need your software to be available in. This makes localization much easier to manage.
Use file formats like JSON, ARB, YAML, XLIFF, Android Resources, or Apple strings. The choice of format depends on the programming language or framework you use.
Keep your translation content clean by nesting strings to logically group each set of translations. Also, give each string a clear name that describes what it refers to and where it goes. For example, “Primary CTA” is more helpful than “Abc”.
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
After separating your files, you should start adding placeholders in your code.
A placeholder allows for the insertion of dynamic content, such as a character, word, or string of characters.
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.
Before you start to code, think through how different languages impact space during the design phase and save yourself headaches down the road.
Translating text first and then optimizing the UI in all languages will help you see how designs change based on the target language, helping you avoid design breaks and localization errors.
Pro tip: Build with flexibility in mind to ensure that your design can accommodate different translations. Check out how you can do that in Lokalise using the Figma, Sketch, and Adobe XD plugins.
4. Check that 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. Understand and accommodate design preferences
Understanding design preferences allows product teams to tailor their software to specific cultural and regional preferences.
Unsurprisingly, different markets have varying preferences for design styles and aesthetics.
For example, some markets may prefer minimalist designs that focus on white space and clean lines, while others may prefer more elaborate designs that incorporate more detailed information and visuals.
In Japan, consumers often prefer more detailed and cluttered designs (Starbucks website on the right) that provide a wealth of information upfront, as it helps them make more informed purchasing decisions. Western designs, on the other hand, tend to favor more minimalist and simplistic designs (Starbucks website on the left), which prioritize ease of use and readability.
“This difference is at the heart of why Western and Japanese websites look so different, and what makes it so difficult to unify your web design across both markets” — Jim Kersey, source
Knowing how design differs from one market to another helps software localization teams create designs that are more appealing to local users, helping them build stronger connections with their target audiences.
6. Plan with locale in mind
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.
7. 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. Check out how to build a glossary in Lokalise.
8. 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.
9. Provide context for localizable strings
Developers should make sure that all text is properly defined and labeled in a way that makes sense for translators. This means including information about where and how a string appears in the user interface, as well as what it does.
Providing this contextual information can help translators understand the nuances of each language more quickly and accurately, which leads to better translations.
For example, if you have a string that reads “cancel,” knowing whether this refers to canceling an order or canceling an appointment will make all the difference in terms of your translation accuracy.
Nuances in language may not be obvious from a single word alone.
10. Leverage translation memory
Translation memory is a database of translations that stores previous translations and can be used to save time and money. For example, if you have a string that reads “Thank you,” translation memory can detect if the same string has been previously translated and suggest the same translation. This can save time and money by eliminating the need to re-translate the same string.
Companies that have set the bar high for software localization
Google has a team of dedicated localization experts, whose mission is to create a diverse user experience that fits every language and every culture. Spread over more than 30 countries, they make sure that all Google products are fun and easy to use in 70+ languages—and sound natural to people everywhere, including in lesser-known languages such as Welsh and Basque. Localization goes beyond translation.
Airbnb
At Airbnb, localization is a key ingredient in championing their mission of belonging anywhere. Recently, they expanded their innovative translation technology to include reviews. Now guests can easily scroll automatically translated reviews in their preferred language without having to click on each individual translation, saving time and minimizing misinterpretations.
Dropbox
Dropbox’s localization team translates the Dropbox experience for everyone to enjoy—it now supports 20 languages across 180 countries worldwide. According to Localization Project Manager Melissa Wheeler, they do that by “translating everything user-facing at Dropbox into other languages”.
Software localization for beginners in 3 steps
Getting started with localization is like Pandora’s box. It can be a complex and multifaceted process, and lead to a slew of issues if it’s not set up properly. Unintentional oversights typically result in an unflattering flow that either makes or breaks a product’s launch in a global market.
So how can you achieve successful software localization in just 3 steps?
Step 1: Set up source files
Source text is usually stored in version control repositories like Azure Repos, GitHub, GitLab or Bitbucket. Below are three ways to set up your source files with Lokalise:
- Pull files from GitHub and create pull requests from Lokalise
- Pull files from Bitbucket and create pull requests from Lokalise
- Pull files from GitLab and create pull requests from Lokalise
Another common development method is CLI v2, which is used by engineers who prefer using the tool. CLI tool is a wrapper for the API and can be used to upload files with a single command line:
lokalise2 file download –token <token> –project-id <project_id> –format xml –dest PATH/TO/PROJECT/locale
Once the source repository, you’ll be able to automate key extraction and values, while mapping out relevant language translations for each key.
Step 2: Perform translation
Software localization depends on the quality of translations, so you’ll need to find the right solution for your project, which will depend on the complexity of your translations, your translation and localization budget, time, and quality expectations. Here are some options that Lokalise offers:
- Invite in-house translators to contribute
- Hire language service providers directly from Lokalise
- Use machine translations (Google Translate, Microsoft Translate, and DeepL)
- Translate with AI using context
If you have complex projects that require translation certifications for a specific industry or language subject-matter expertise, Lokalise can also introduce you to one of our reputable language service partners, like Acclaro or RWS.
Step 3: Deliver localized content
Now you need to transform your software project at a cultural level. Cultural adaptation tackles technical obstacles, such as the ability to remove the number 4 (which connotes death in Japan) from text and replace it with a bullet point representation.
To verify localization at a cultural level and streamline your workflow, there are heaps of tools in Lokalise that can help:
- Figma plugin to review translations in context
- Review center to invite local experts to review translations in context
- Project management tools to keep everyone on top of localization tasks
Taking the next step in your localization journey
- Explore our case studies, which are mostly related to software localization, and see how localization correlates with business growth
- Sign up for a free Lokalise trial
- Pressed for time? Check out the product tour
FAQs
What is software localization?
Software localization is the process of adapting software products to meet the language, cultural, and other specific needs of a particular country or region. It involves not only translating the text, but also adapting software functionality, user interfaces, and design elements to ensure the software feels natural and intuitive to users in different regions.
Why is software localization important?
Software localization is essential for businesses looking to expand their global reach and connect with international audiences. By localizing their software, businesses can create a more natural and engaging experience for users in different regions, improving user satisfaction and increasing the likelihood of adoption and retention.
What are some common challenges associated with software localization?
Some common challenges associated with software localization include cultural and linguistic differences, technical and logistical complexities, and the need for collaboration and communication across multiple stakeholders. Additionally, businesses may face challenges related to cost and time constraints, as well as maintaining consistency and quality across multiple language versions.
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
