Software localization (or l10n) moves beyond basic translation to adjust a user interface 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 value your product will have. With more languages, you’ll be able to reach more users around the world.
What is software localization?
Software localization is different from internationalization (i18n). Internationalization refers specifically to the design and development of a product, application, or document content so that it can be localized for target audiences that vary in culture, region, or language. Rather than hardcode 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’re going to want to make sure you do any internationalization work first 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 the specific language, and usually occurs after internationalization. But it goes further from there. It can include cultural and country-specific aspects of languages, such as:
- Accounting standards
- Links and other resources
- Hand symbols, gestures, or signage
- Culturally appropriate images
- Dates and times
- Spelling and phrasing, such as the differences between Spanish phrases 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 shortcut 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 perspective.
Implementing software localization requires a repeatable, solid process you can use to ensure no matter how many languages you want to operate in, you’ll be able to do it easily and efficiently.
The Software Localization Process
The software localization process takes two common forms:
- 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 complete from the localization service provider, the software strings are manually uploaded back into the application for merging and publishing. This can delay the translation process.
- 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. This allows for more efficiency and flexibility when it comes to your localization workflow, but it can be more complex and require dedicated localization engineers.
Using a localization tool like Lokalise makes it easier to implement agile localization and also connect you to professional translators, making this process a snap.
7 Software Localization Best Practices
Software localization can be a tricky process, but if you keep these seven things in mind, you’ll be able to get up and running in no time:
1. Use separate resource files.
Any solid software localization starts with internationalization. Structure your application by including separate files for each language. This step is needed for larger or more unwieldy amounts of text, but if you’re running a smaller app, you can skip this. This means taking all of the text within an application and storing it outside of the actual code. In many cases, by default, the text is hard-coded within an application, but you’ll want to start by separating 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.
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, is important. (“Abc” is not going to be as helpful as “Primary CTA”) Create a naming convention that makes the most sense to your team.
Then, those translation files can be uploaded to a translation management system like Lokalise. File formats vary by technology — learn more about what that looks like here.
2. Manage your code to handle multiple languages.
Then, 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. These placeholders search across the translation files to serve up the correct language to the user.
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 code 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 like this:
Along with using these placeholders, you’ll also want to avoid concatenated strings because word order and syntax varies by language, and it can make it difficult to parse. Make sure, too, 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 it impacts the final meaning.
3. Build in space as language length will change.
Different languages take up different amounts of space on a page. 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 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 later.
At Lokalise, we integrate with tools like Figma and Sketch so you can easily see how your designs will change based on the target language and so you can design defensively. Translating the text first and then optimizing the UI based on all languages, rather than your source language, can help you release your pages more quickly and eliminate hacky code later.
Don’t forget to test your finished designs, both before and after development, in all of your target languages.
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.
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. Or, there may be multiple languages spoken within a given market, such as in Belgium, China, or Switzerland.
Similarly, different cultural cues can exist by region within a given market. In Russia, for example, the culture in Moscow looks completely different from those living in the Uralic mountains or Caucasia, and they may speak additional languages to Russian, like Tartar, 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 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.
For your messaging and brand to stay consistent across every market, you need to provide your translators context. Creating a style guide is a great way to add this consistency and can answer questions translators have quickly. In your style guide, make sure to include:
- Branding, like product names or terminology
- Tone, especially formality and voice
- Audience information, such as persona research or your value propositions
- Grammar, where applicable
7. Use a software localization tool.
Seems like a lot, doesn’t it? That’s because it is! But we’re here to help. Using a localization tool like Lokalise can help keep every project organized, on track, and successful and eliminate monotonous and manual tasks. Learn more about embracing automation, workflow transparency, and fast project delivery with Lokalise. // Learn more