Step-by-Step Guide to Software Localization With Examples

If you’re a developer who’s been handed the responsibility of software localization and you’re unfamiliar with the process, the road ahead may seem daunting.

While software localization can be a challenging task, learning about localization in general and planning ahead can ensure the efficient and cost-effective localization of your product. In today’s article, we’ll share key information about software localization as well as steps for how to localize software from start to finish.

What is Software Localization?

Software localization (also referred to as l10n) is the process of adapting or translating software to a specific locale’s language, culture, and legal requirements. In many cases, localization will require modifications to the user-visible components of software such as the user interface, images, documentation, etc.

Effectively localized software will allow your users to connect with your software in a language and locale that feels native to them.

For a software developer, i18n means designing a localizable user interface and abstracting all localizable elements. Take for example elements such as user-visible strings, locale-specific data like date, time, and currency formats, keyboard usage, etc.

Taking these elements out of your application source code into external files that can be made available for translation is a necessity for internationalization, then localization.

What are the Best Practices for Software Localization?

There are no hard and fast rules or specific global standards governing software localization, but you’ll find that adhering to 4 best practices will result in a hassle-free localization process:

1. 1. View localization as an extension of product development. Rather than looking at software localization as an isolated task in the final stages of your product release, view localization-related tasks as things that arise during each step of the software development process, from release to maintenance. This mindset can ensure that you plan accordingly for software localization and that your software can be translated into other languages without causing you extra work or time.
   2. Keep your source language simple. Using industry-related or complicated words and phrases in your user interface and documentation may appeal to a select audience, failing to elicit positive responses in other languages or another culture. However, it also makes translation difficult or even impossible in some cases, so keep your source language as simple as possible.
   3. Focus on your strings. As a developer, much of your localization efforts will revolve around your strings. Along with externalizing all user-visible strings, localization best practices include never hard coding strings, avoiding concatenated strings, and always providing explanatory comments which will discuss later in this article.
   4. Find a comprehensive software localization platform. The localization process goes beyond software development, requiring a robust localization platform. Localization platforms designed specifically for developers often offer a higher level of customization and can include integrations with tools such as GitHub, Python, and Django. A handful of localization platforms also provide integrated translation providers so you don’t have to spend time creating and managing a team of translators.

How is Software Localization Done?

Localization involves two key phases; the first being internationalization and the second being the actual process of localization. The diagram below outlines the steps involved in both phases.

Phase 1: Internationalization

While software localization is the actual process of adapting your software to another language, internationalization includes design and development practices that enable a simple and straightforward localization. During the internationalization phase, you’ll need to:

Review Application Framework

Your ability to internationalize your software will be dependent on your application framework. The diagram below outlines the key features to look for to determine if your software can support internationalization efforts.

Plan for Text in Other Languages

Translated text may take up more space, or in some cases, less space, causing your neat and perfectly laid-out design to appear crowded or even indecipherable when translated. The design of your user interface must allow room for expansion and contraction in translated languages.

To ensure that your content is viewed how you intended, we recommend programming dynamic UI expansion into your software.

If you are developing an iOS app, for instance, you should use Auto Layout to ensure that your views realign suitably for every locale. For an Android app, you can build a dynamic UI with Fragments.

Make use of features supported by your application framework to program dynamic UI expansion.

Another point to consider: In languages such as Arabic, text is read from right-to-left (RTL) so your design will also need to supports RTL script.

Code Strings with Global Expansion in Mind

During the internationalization phase, strings must be extracted, localized, and reinserted back into the code. Coding string codes under Unicode/UTF-8 will generally be the best option, unless you are working with Asian languages that require UTF-16.

Externalize Your Locale Specific Data

Strings that have been prepped for localization must be externalized, meaning you will have to save your strings to a translation file. And we’ll get into resource files in more depth below, but know that it’s common to have multiple versions of your resources files for every target language.

Resource Files

Resource files in the use case of software localization contain resources specific to a given language. Recent application frameworks typically define a key-delimiter-value syntax for resource files, which will determine how you create pairs of keys and values for all user-visible strings in your application. Then, based on the user’s locale, appropriate values for these strings will be fetched and rendered in the user interface.

Examples

Example 1: Properties Files

Below, you can see how to make use of properties files to externalize your localizable strings. It is common to create multiple .properties files, one for each target language.

Example 2: Localizable.Strings files

For an iOS app, the files that contain localizable strings are referred to as the Strings file and you must make use of these and the NSLocalizedString macro. Your application should have specific locale directories and you must localize the Localizable.strings file in each language folder.

Example 3: Strings.xml files

For an Android app, all your localizable strings will go to the strings.xml file and into appropriate locale directories as shown below:

Resource Bundle

Resource bundle is a general term, but when used in regards to software localization, typically means a set of resource files sharing a common base name and having an additional language-specific component in its name to identify specific locales.

• • In example 1 above, messages_en.properties and messages_de.properties will be joined together into a Resource Bundle.

• • In example 2 above, en.lproj/Localizable.strings and de.lproj/Localizable.strings will be put together into an Application Bundle.
  • In example 3 above, res/values/strings.xml and res/values-de/strings.xml will be joined into a Resource Bundle.

Focus On Your Strings

The final thing you’ll need to do before the actual translation process revolves around your strings. Try to:

• • Avoid hard-coded strings. All user-visible strings must be externalized appropriately. Avoiding hard coded strings will make your life easier, and when unsure, perform pseudo localization to root out hard coded strings. Pseudo-localization is often performed in a separate localization testing branch, allowing you to replace your strings using a regular expression. Then, when you run your software, any hard-coded string will be clearly visible.

• • Avoid concatenation of strings. Two or more strings are sometimes concatenated by developers for the purpose of saving space. However, word order varies significantly in each language and string concatenation will most likely result in translation errors in the software localization process.
  • Provide self-explanatory comments. Providing explanatory comments for your strings to define context wherever possible will go a long way in assuring better translation accuracy with less back and forth communication efforts. This means time savings for you and fewer headaches.

Internationalization should not be treated as a separate step in your software development process, but rather a fundamental thought in every stage of your design and development process.

Phase 2: Software Localization

In the past, people often localized content using spreadsheets, requiring developers to copy and paste strings and source content into the spreadsheets before sending it off to a single or multiple translators.

Translators would then have to access the spreadsheet and put in their translations. And when it came to quality assurance, they would have to come up with a creative solution that would be implemented to ensure translations were correct before pushing the new strings back into the software.

While this is just one translation option, the remainder of our article will focus on using a software localization platform. This is most certainly a more commonly adopted way of localizing content that helps developers save time while ensuring the overall quality of translations.

Select a localization platform that provides a good editor, supports multiple source formats, allows your translation cycles to integrate well with your build cycles, and offers additional localization features designed for developers.

Extract Resource Files

To start the localization process, you’ll need to extract your resource files for translation. Software localization platforms like Transifex support a variety of source file formats and you’ll be able to directly upload your resource files.

In some cases, you’ll have to export your resource files into standard XLIFF (XML Localization Interchange File Format) files or other such localization file formats to make them suitable for translation into multiple languages.

If you are using Transifex, all you need to do is directly upload the resource files of your project in one of the supported resource file formats. In this case, the platform will automatically extract all your source strings and make them available for translation.

Translate

Content translation can be approached in multiple ways. You can rely on machine translation (MT) for fast, straightforward projects, AI-powered tools for more nuanced translations, or choose human linguists for more complex and business-sensitive content. Another option is a combination of the aforementioned methods, using MT or AI as a first pass followed by human review to ensure accuracy.

In Transifex, these processes are streamlined with Transifex AI, which offers AI-powered translations that learn from your content, resources and brand-specific context to produce human-quality translations. For specialized content, you can still collaborate with professional translators directly within the platform’s editor, maintaining consistency and context throughout the project.

Review

Translation reviews typically involve checking for accuracy, language quality, and adherence to terminology. This can be done manually by a reviewer or enhanced with automated quality checks. Depending on the level of translation accuracy, you might also consider back-translation as a QA framework, if you’re looking for the highest-quality results.

In Transifex, the Transifex Quality Index (TQI) helps automate the review process by evaluating translations in context and flagging content that needs human attention. For cases requiring manual review, the platform offers built-in tools to facilitate collaboration and feedback between translators and project managers.

Copy Translated Files into Code Structure

After completing your translation, you’ll have to copy the translated files into your code structure. Quality translation platforms will provide an option to pull the translated files that are ready for use with your application.

The next step is to import these translated files into your application and deploy your localized application with the new translations.

If you push content out on a regular basis, a localization platform will be most beneficial because it can make continuous localization a part of every release cycle. Then, when you add or modify strings in your source files or there is new content to be localized, you can push them for translation and merge the new translations back into the code.

Test Your Software for Every Translated Locale

You must test your software to ensure both functional and linguistic acceptability for every target locale and language and that translated content makes sense in the context of your product. In addition to translation accuracy, specifically look for layout issues, display errors, formatting issues, and locale-specific settings.

When is the Software Localization Process Complete?

Once you have made sure that your product is bug-free and sufficiently documented, announce a “string freeze” on your product. This means you can no longer change the code in a way that affects the source strings (except for specific improvements).

The string freeze will allow translators to work on a stable set of strings and ensure adequate time is available to translate and review. Thus, before the final release, you can obtain the translation for all your target languages, compile them into your product and release it.

But, if we are talking about a more advanced localization solution, such as Transifex Native. Native is a solution that you embed into your stack to automatically push and pull content, which is also great for continuous localization!

Have other questions about localization in general? Check our detailed blog here!

Also check out Transifex’s Webinar: Software Localization for Dummies

Don’t know how to get started with localization? Check out our on-demand webinar where we show you:

• Why localization is important
• Where to start regarding your first localization workflow
• How to prioritize your needs in terms of content and languages
• What is i18n and how it’s linked to L1on
• The traditional localization workflow vs the modern approach
• The best translation options for you (Translation Memory, Machine Translation, Crowdoursing VS Vendor VS in-house translators, etc
• How to monitor your progress and ROI
• How to gradually scale localization