4 Tips for Effective Software Localization

Software localization — from mobile apps to desktop and cloud applications — is crucial to deliver a good customer experience in your target markets. But localizing your software presents particular challenges. These can quickly grow with more languages as your business expands globally, and it’s especially true when teams treat localization as an afterthought.

Architects and developers might not consider that localization could be as much about code as it is about content. For many, localizing their software consists of little more than creating individual files for their resources and a framework that supports different versions of these resources for each language. They don’t take into account the importance of internationalization, continuous localization, and localization workflows. Most project managers also see translation as something that happens at the end of the development process. As such, they might not realize that it needs testing on its own.

Meanwhile, content authors often don’t see the powerful impact their writing can have in improving the localization process. They can write without consideration for translation, not knowing how it can affect effort and cost further down the line. As for user experience (UX) designers, it’s all too easy to design user interfaces and user interaction once, for English, without bearing in mind their effectiveness in other locales.

To effectively create and roll out software applications on the global market, all teams need to be aware of the challenges that can occur. From there, they need to work together to find solutions and follow some best practices.

Best practices for localizing software

Here are four crucial elements to consider when localizing your software. Fine-tuning these elements will make a solid foundation for future language growth, both in the number and complexity of your target languages, and help you improve your UX (and increase your ROI) in your target markets. It will also help you accelerate your process and save you time and money.

1. Think localized UX

Translated text in languages like German can take as much as 40% more width space on your screen than the same phrase in English. Meanwhile, some Asian languages, like Chinese, may take up to 20% less width space, but the characters will be taller and use more vertical space.

Space is often more limited on mobile apps than on desktop or cloud applications. To deliver the customer experience you require in different languages, your UX team may need to design in flexibility for character expansion and reduction, and the software needs to be responsive enough to cater to this. On top of that, not all fonts support all languages — and if your content contains dates, numbers, and currencies in a specific format, or even just videos and images, you also need to decide if these should be localized. It can greatly improve the consistency across your software and your overall customer experience.

Setting character limits

If there is no more flexibility in the design, setting character restrictions for the translator makes sure the final text fits into the design. Similarly, text for drop-down menu items tends to be one or two words rather than short phrases — even if these could technically fit within the dimensions of the screen — and this context needs to be passed on to the translation service provider.

Linguistic testing

Testing your software helps flag any localization problems before you send the actual text for translation. Pseudo-localization can be used for testing and helps prepare your UX design. Pseudo-localization uses random text to test if your software is well internationalized. The text can be more tailored to your content by using machine-translated versions of your content. 

Ideally, it should be long samples of text, that contain characters with different heights, to test the flexibility in the design. Think back to our mobile app again: a CTA button in German would have more text than one in English, so the design needs to be flexible enough to fit both languages.

2. Expect complex languages

Many languages have intricate rules around genders, plurals, or declensions. Your software needs to be prepared to handle these multilingual complexities. It can be difficult for teams that only speak English to prepare for this, as English is a relatively straightforward language in this sense. Look at the simple example below for Spanish with how your code affects translations.

Example: Welcoming your users

In Spanish this can be translated as either:

or

The choice of word depends on the gender of {name}. If you don’t have the software (and the translation workflow) that can handle two or more options, you’ll be relying on your translator to do either of the following:

Work out a genderless alternative, such as:

or use a translation to accommodate both genders such as:

or choose just one of the genders, and perhaps distance half your users.

Script direction is another complexity to be aware of: Languages such as Hebrew and Arabic have scripts that travel right to left. If you translate, or plan to translate, into these languages, your software framework needs to be set up to handle the BiDirectionality (BiDi) of the text, and even images and page layout, e.g., bullet points.

In my experience, you don’t need to plan for all the potential problems that may occur across all languages. Rather, you need to recognize the specific challenges of your target market languages and prepare for them.

3. Adopt ‘Intentional Authoring’

It’s hard to translate figurative language and many other literary techniques. If you know your content is going to be translated, your content authors can make the process easier by practicing Intentional Authoring.

Intentional Authoring is the process of writing your content with simplicity and consistency for an international target audience. It means thinking beyond the source language, and it’s good practice for any work that might be translated.

Content authors who practice Intentional Authoring reduce many of the pain points associated with software localization. Plus, it helps reduce the overall cost of translation, makes it less time-consuming, and improves the quality of the final piece of translated content, especially when developing software products for a global audience.

Intentional Authoring also boosts the effectiveness of translation technologies, helping you scale up your translation process for more languages and content. Using your language assets to guide writing and practicing consistent Intentional Authoring is the best way to boost the translation technologies, namely:

• your Translation Memory (TM, a database of your previous translations) is triggered more often, improving translation consistency;

• your Machine Translation engines will work more efficiently, speeding up translations;

• your bilingual terminologies will be administered, so your key terms are translated as your SMEs need them to be translated;

• you avoid unnecessary questions about the text and spare your researchers from researching regionalisms or figures of speech that cannot be directly translated, saving time for everyone.

4. Keep context front and center

Context is very important when translating projects for software localization. In conventional language projects, translators get full texts to translate, and translators can understand the context from the text. In software localization, translators only receive software strings (short sentences or single words), which can be full of placeholders or joined end-to-end to form different sentences (string concatenation). Without context, strings from software localization can be challenging to translate, which can ultimately lead to quality issues. 

Example: Placeholders

In software development, a placeholder is a provisional character or word that takes the place of a final word or number. Placeholders are often introduced to reuse the content in different contexts or to inject different text using programming logic. For example, a developer may expect to add a value to a software string but doesn’t know the final value when they’re writing the source code.

Some placeholders can have multiple meanings. Without context, a human translator might not select the right word in the target language or be left uncertain about how to proceed. To combat this, your development teams need to share additional context with your translators (e.g., comments on strings or URLs of where the content will be published). This will help the translator understand the meaning of the word in the source text and give the best quality translation.

Example: String concatenation

String concatenation is used to join strings end-to-end, in this way it can form different sentences depending on the context. Take the following example:

string1 = You have

string2 = the test

string3 = started

string4 = passed

string5 = rejected

The logic of the program adds string3, string4, or string5 in between string1 and string2 to make a complete sentence as required. If the strings are passed on for translation as separate elements, the translators will translate word by word. They won’t see the complete sentence needed, and the overall meaning of the sentence will be lost.

Additionally, not all languages have the same language structure, and developers need to cater to these differences. In German, for example, the verb goes at the end of the sentence, so string3, string4, and string5 would need to go after string2.

Example: Translating the article ‘the’

The German language also highlights another potential challenge: Translating the article ‘the’ without context. It can be incredibly difficult to translate ‘the’ if the German translator cannot see how it fits in the full sentence. If, for example, it’s being used in multiple places of code. The tables below show the enormity of the challenge: