skip to Main Content
Software Localization

Software Localization: 6 best practice tips for global scale

Software localization presents unique challenges. And these can easily multiply as you add more languages and scale your business internationally.

Our Head of Consulting, Juan Gil, explores why it’s vital that all of the teams involved in creating and rolling out your global software applications follow best practice.

As someone who has spent most of my career designing and developing software systems, and only recently joined the localization industry, I know that for most teams localization is just an afterthought.

At the end of the day it’s just a translation, right? What does that have to do with code?

At the end of the day it’s just a translation, right? What does that have to do with code?

For many architects and developers, localizing their software – from mobile apps to desktop and cloud applications – consists of little more than creating separate files for their resources and a framework that supports different versions of these resources for each target language. They might not consider that localization could be as much about code as it is about content.

For many project managers, translation happens at the end of the development process: they may not even consider testing it on its own.

Often, for content authors, the content is written without consideration for localization and how much it could impact the translation effort and cost farther down the line.

And for UX designers, the user interaction often tends to be designed once for English, rarely with regard to its effectiveness in other locales.

Defining your software localization process

Software localization is much simpler if you involve your teams throughout the process, rather than just simply passing files onto a translation partner at the end. There are many factors that make it much more complex than simply taking content from your source language and then translating it into multiple target languages.

When working across many languages, all teams involved in your software creation process need to come together to define how internationalization and localization fit within the localization process as an integrated part of their development practices.

 

Internationalization – Making your software “localization-ready” so that it is easily adapted to different locales without the need of costly remedial engineering or redesign.

Localization – The process of modifying products or services to adapt to your different target locales and markets e.g. A global dating app would probably change the ethnicity of the people shown in promotional images and graphics to resonate with different markets.

A solid internationalization stage will allow for smoother localization of your product into any market and locale.

Properly internationalizing your software, applying content authoring best practices, and considering UX decisions upstream in your software development life cycle are all critical. These will help you achieve a better UX (and thus a higher ROI) in your target markets.

Properly internationalizing your software, applying content authoring best practices, and considering UX decisions upstream in your software development life cycle are all critical.

Fine-tuning these elements will also accelerate your process, save you time and money, and provide a solid foundation as the number and complexity of your target languages grow.

Collaborating closely with our clients, to understand their organisation and raise awareness of the importance of localization within their teams, helps them take the relevant business and technical decisions that fit the context of their organisation.

We believe this is the best way to help global businesses define their own process for addressing the unique challenges of software localization.

Here are some tips to consider when localizing your software and creating your own best practice process:

1. Think localized UX

To handle the specific challenges that come with localizing software content, you need to put in place proper frameworks.

Example – Text expansion

When translated, some languages, like German, can take as much as 40% more width space on your screen than English. Others, like Chinese, can take up to 20% less width space but are generally taller and use more vertical space.

This is particularly important in multilingual mobile apps, where space can be more limited than on desktop or cloud applications. In this case, a UX team often needs to design in flexibility for character expansion and reduction, and the technology needs to be responsive enough to cater for this.

Your UX team often needs to design in flexibility for character expansion and reduction, and the technology needs to be responsive enough to cater for this.

In some cases, where there is no more flexibility in the design, you might need to set character restrictions for the translator, so the final text fits into the design. Likewise, you would normally prefer your menu items to use simple words as opposed to short phrases, even if these could technically fit within the dimensions of the screen.

Preparing for content expansion

  • Try testing your software using pseudo-localization practices to assess any potential problems.
  • Decide if you’re passing character restrictions on the translations to your translation partner. If so, have you thought of the content needing to change to comply with the character restriction?
  • Address whether dates, numbers, currencies and even videos and images also need to be localized and tested.
Pseudo-localization practices can use any random text to test if your software is correctly internationalized. Ideally, the text should contain characters with different heights, and samples of long text, to test if there is sufficient flexibility in the design.

For example, imagine our mobile app again: a CTA button in English would likely contain much shorter text than one in German, so the design must be flexible to fit.

At Lingo24, we use Machine Translated versions of your content so you can quickly pseudo-test your software in different locales and address any localization problems before actually sending the test for translation.

2. Consider complex languages

Software needs to be prepared for languages that have complex rules around genders, plurals, or declensions.

This can be difficult for teams that only speak English: as it’s a relatively simple language in this sense, so you might want to seek professional support.

I’ve chosen my native language, Spanish, to highlight the point below.

Example – Welcoming your users

Welcome {name}

in Spanish this can be translated as either:

Bienvenido {name}

or

Bienvenida {name}

Depending on the gender of {name}. If you don’t have software (and a translation workflow) that can handle two or more options, you’ll be relying on your translator to:

work out a genderless alternative, such as:

Hola {name}

or use a translation mixing both genders such as:

Bienvenido/a {name}

or decide to just go for one of the genders, and perhaps alienate half your users.

It’s equally important to plan and test for different script directions, with languages such as Hebrew and Arabic travelling right to left. Your software framework needs to be set up to handle the complexities around BiDirectionality (BiDi) of the text.

Plan for your languages

Consider the lean principle, ‘Just in time, just enough,’ this is not about planning for all possible issues that may occur in every language, but knowing what the specific challenges of your target market languages are and how to prepare for them.

3. Context is King

Context is vital for every translation project, and even more so in software localization projects.

Example – Placeholders

In traditional multilingual projects translators get full texts to translate. But, in software localization they only get software strings (short sentences or single words) with placeholders and very little context.

In software development a placeholder is a character, word, or string of characters that temporarily takes the place of a final word or number that’s yet to be entered.

Placeholders can be introduced to reuse content in different contexts or to inject different text using programming logic.

For example, a developer may know they need to add a certain number of values or variables to a software string, but doesn’t yet know what to input while they are writing the code.

Working with placeholders and little context can lead to quality issues. Some placeholders might have multiple meanings so, without context, the translators may be uncertain how to proceed.

An example we’ve seen, in a health and wellbeing app, is when steps was translated to mean ‘the steps in a process’, rather than ‘the number of steps’ that app users logged each day as part of their fitness challenge. Imagine how confusing this would be for users?

The word steps has multiple meanings in English, but in a different language the translation might not carry the same multiple meanings. So, the translation of steps in one context – ‘steps in a process’ – won’t apply in the other context – ‘the number of steps’. If ‘steps’ is translated without context in this example, it could mean guesswork for a translator.

Placeholders

Any additional context that your developers can share with your translators is invaluable to achieve higher translation quality (e.g Product ID, string names, comments on strings, URLs of where the content is/will be published, etc.).

Example – String concatenation

String concatenation, with lack of context, can pose similar issues to placeholders in software localization. It can be used to join strings to 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. The developers will know how this underlying logic works but, most likely, the translator won’t.

So, if the strings are passed on for translation as separate elements, rather than complete sentences, the translator won’t know the context.

See the problem here? Without context, translators will translate word by word, and the overall meaning of the sentence, once put together, will be lost.

Without context, translators will translate word by word, and the overall meaning of the sentence, once put together, will be lost.

Additionally, for languages like German where the verb goes at the end of the sentence, string3, string4, and string5 would need to go after string2, which the logic of the program won’t cater for.

Example – The German ‘The’

German brings me to one of my favourite examples: how difficult do you think it would be for a German translator to translate the article ‘the’ if they don’t have the full sentence to which it belongs, because part of it’s reused elsewhere in the code?

German
Case Masculine Feminine Neuter Plural
Nominative der die das die
Accusative den die das die
Dative dem der dem den
Genitive des der des der
English
Case Masculine Feminine Neuter Plural
Nominative the the the the
Accusative the the the the
Dative the the the the
Genitive the the the the

Duplicating content might feel counterintuitive to developers. Reusability is a key concept in programming practices. However, as the software development saying goes, “a little copying is better than a little dependency,” and reusability, by definition, leads to dependencies within the code.

While developers may be able to understand the dependencies within the code, translators won’t be aware there are dependencies. Being blind to these dependencies separates the translator from the content they need for a quality translation.

How difficult do you think it would be for a German translator to translate the article ‘the’ if they don’t have the full sentence to which it belongs?

Software development principles can pose problems in localization, but once you know what to look out for, you can be on your guard.

Being aware of conflicting principles

Once your teams are aware of the trade-offs between Agile software development and localization principles, you’ll be better placed to make an informed decision and define your localization strategy.

4. Good localization starts with ‘Intentional Authoring’

Thinking beyond the source language and writing your content for a wider international audience is good practice for any work that might be translated. We call the process of writing your content with simplicity and consistency ‘Intentional Authoring’. It’s hard to overstate its impact when developing software for a global audience.

Intentional Authoring can really help reduce the overall cost of translation and also improve the quality of the final piece of content.

Practice Intentional Authoring

Intentional Authoring involves avoiding double-meanings, metaphors, acronyms, localisms, colloquialisms, idioms, and rhymes, etc. The foundation for good Intentional Authoring are your language assets (Terminologies and Style guides).

It’s hard to translate figurative language and the other literary techniques listed above. If you know your content is going to be translated, you can make the process easier by avoiding them entirely.

In our experience, when Content Authors adopt Intentional Authoring it can considerably reduce many of the pain points associated with software localization. It also creates an excellent starting point for scaling up your translation, in terms of languages and content volume.

This is because Intentional Authoring provides a good foundation for, and boosts effectiveness of, translation technologies. Translation technologies these days allow translators to translate millions of words using a fraction of the time and cost that it would have taken not many years ago, but the effectiveness of these technologies depends on the nature of your content and how it’s authored.

When Content Authors adopt Intentional Authoring it can considerably reduce many of the pain points associated with software localization.

Consistent Intentional Authoring and use of your language assets to guide writing helps the technologies underpinning the translation workflows:

  • your Translation Memory (TM – a database of your previous translations) kicks in more often, so translators can reuse past translations more consistently;
  • your Machine Translation engines will work more efficiently and speed up the translations;
  • your bilingual terminologies can be enforced in the Computer Assisted Translation (CAT) tool, to ensure your key terms are translated as your Subject Matter Experts (SMEs) want them to be translated;
  • you avoid answering too many questions regarding the meaning of the text, saving time for you and translators from researching regionalisms or figures of speech that might have no direct equivalent in the target language.

5. Automate your translation workflows

It won’t come as a surprise if I say that, as with everything else these days, you need digital solutions to support your translation workflows.

Translation processes that are supported by online tools and integrations accelerate your workflow, helping drive your global growth. These digital solutions let you easily select the required content, send it automatically for quoting and translation, then import it back. You can even add in a review stage by your native SMEs.

Translation processes that are supported by online tools and integrations accelerate your workflow, helping drive your global growth.

Having some manual steps may not seem like a big deal with the first drop of content and the first languages. But, as the number of languages grows and new content is created in each iteration of your software, manual steps can sap your team’s time and risk the translation quality.

Translation digital solutions

Bring Application Programming Interfaces (APIs) and digital solutions into your translation process to align it to your development practices. This will come naturally to your development teams, once they realise that the technologies are there to support this level of automation.

6. Make localization part of your development workflow

Today’s software development is run by Agile practices, automation of tasks, and Continuous Integration and Deployment.

But, when it comes to translation, none of the benefits of these development practices are realised, as translation usually happens “offline” once the development is complete. By making translation part of your automated development cycle, you can avoid deploying expensive code changes after the development of the feature is finished.

Adding translation to your Sprint

  1. Prep Content Authors to create your content for translation before each Sprint starts
  2. Coordinate your Continuous Integration software to pick up the content and send it to your translation partner
  3. Translated content is then ready by the time your sprint starts
  4. Test all the languages as part of the sprint

This method makes sure your software works to your required level of quality in all your target locales.

Takeaway

Software localization presents unique challenges for global enterprises. But, if you make sure all the teams involved are aware of the potential challenges, and best practices to address them, you’ll be well placed to deliver a great customer experience across all of your global markets.

Juan Gil, Head of Consulting, Lingo24

Juan has over 15 years of experience as an IT professional, previously holding positions as researcher, developer, architect and CTO across different environments and industries in Germany, Spain, France, and the UK, before joining Lingo24 and specialising in localization technologies and processes.

Back To Top
Search