Lucy Xu

4 Steps to Creating a Software Localization Roadmap

In today’s global business ecosystem, companies are more rapidly prioritizing localization as a business need. And the reason is simple: effectively localized software will enable your audience to connect with your company in a language that feels most native and comfortable to them, resulting in more users and customers. The process, however, can be a bit more complicated. 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 localization can be complex, learning about translation management and planning ahead can ensure you localize your product in the most efficient and cost-effective way. 

From a technical perspective, software localization (also known as “l10n”) is the process of adapting or translating software to the language, culture, and legal requirements of a specific locale. In many cases, localization requires modifying and translating the user-facing elements of your software and website (i.e., content, UI, images, documentation).

To get started, it is important to understand is that localization involves two key phases: Internationalization and localization. While 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. In this blog post, we take a deeper dive into internationalization to break down the key elements you’ll need to create and scale your software localization roadmap.  

For a software developer, the first step of localization is internationalization (also abbreviated as “i18n”). Internationalization is the process of designing a “localizable” user interface and abstracting all the elements that can be localized out of your software’s source code. These elements will range from user-facing content to locale-specific data (such as date, time, currency). From here, the localizable elements are then transformed into external files that are then available for translation.

Now, let’s break down each of the steps of the internationalization process. (And keep in mind: 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.)

Step 1: Review Application Framework

Your ability to internationalize your software will be dependent on your application framework. An application framework that adequately supports internationalization should contain the following elements:

Resources files: Resource files for 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. Resource files can be created in various formats depending on the type of software you are localizing.

Resource bundles: Resource bundle is a general term, but when used in regards to localization, it 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.

Unicode support, APIs, and additional features: All of which will support multiple locales. For more specific examples of each of these elements, check out our Localization 101 guide.

Step 2: Plan for Text in Other Languages

Translated text may take up more space, or in some cases, less space, than your source language 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 of text strings in translated languages.

To ensure that your content is viewed how you intended, we recommend programming dynamic UI expansion into your software. For example, if you are developing an iOS app, 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. For more specific examples of each of these elements, check out our Localization 101 guide.

Step 3: Code Strings with Global Expansion in Mind

During the internationalization phase, strings must be extracted, localized, and reinserted back into the code. As a specific recommendation, coding strings under Unicode/UTF-8 will generally be the best option, unless you are working with Asian languages that require UTF-16. Additionally, make sure that you externalize all of the strings that you have prepped for localization; meaning that you will have to save your strings to a translation file (also known as a resource file). In many cases, it’s quite common to create multiple versions of your resources files for every target language.

Step 4: Focus On Your Strings

The final thing you’ll need to do before the actual translation process revolves around your strings. Here are three best practices to follow as you go through the translation process:

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 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.

Ready, Set, Localize!

Now that you’ve learned the fundamentals of creating a software localization roadmap, you are well on your way to localization. Stay tuned for our next post, which will take a closer look at the second phase of localization. We’ve also broken down more specific examples of each step of the localization roadmap in our latest guide. Download our software localization guide to better understand the key elements of both phases of localization, and the steps for localizing your software from start to finish.

Download the free Transifex Software Localization 101 guide

Want to learn more about Transifex?

Give Transifex a try with our free 15 day trial, or connect with one of our team members for a personal demo.