Software Localisation: A Beginner’s Guide

As a software developer, you might be aware that software localisation can provide a huge return on investment for your product. You might have some idea that localisation involves translation to one degree or another.

But if you have suddenly been put in charge of an entire software localisation project, it’s a good idea to get a firm grounding in the basics.

In this beginners guide to software localisation, we’ll make sure you’ve got all of your bases covered.

What is the difference between localisation and translation?

Localisation is more than translation. When you translate, you replace words in one language with words in another that have equivalent meaning. When you localise your software, you adapt every single element of it so that it looks completely natural to someone from a completely different cultural background:

• User Interface
• Payment methods
• Images, imagery and icons (these can be culturally inappropriate, obviously intended for different regions or simply nonsensical to local audiences)
• Layout and display (especially to accommodate right-to-left languages likes Arabic but for reasons such as expected information density too)
• UX and navigational functionality
• Dates, times, currency and other units of measurement
• Cultural references
• Legal requirements

Perhaps the clearest example of non-localised software to a native British English speaker would be when you can obviously tell something is designed for an American audience. Units of measurement are clearly incorrect. References to cultural touchstones and concepts feel very out of place. When you try and enter your region into a drop-down box, the software offers you American states as options. The vice versa obviously holds true.

Instead of merely translating the text, localisation also means adapting both it and other elements of your design to your audience’s norms and expectations. Incorrect units will be replaced. Options will suit your local audience. Cultural reference points will be identified and the most suitable localised versions used instead.

What is the difference between localisation and internationalisation?

These two terms are often written as l10n (localisation, “l” then 10 letters, then “n”) and i18n (internationalisation, “i” then 18 letters, then “n”).

They are both a part of the localisation process. Internationalisation comes first. It is the process of designing software that is properly prepared for later localisation. This usually involves taking steps such as creating a User Interface that can easily be adapted – leaving plenty of open space, for instance – and abstracting elements out of your application source code into files that can be easily translated.

Instead of having text that is hard-coded into the software, software that has been through successful internationalisation will have code placeholders that will retrieve the correct language version for each user. The localisation process comes in to create the language files that the placeholders will reference.

Internationalisation is usually done by developers. Localisation is the job of specialist translators.

Why is software localisation worthwhile?

One of the best recent examples of the success that smart localisation can bring is fintech company Revolut. From little-known app to 8 million users in less than five years, Revolut grew by localising their app into more than 30 languages.

Revolut recognised that localising your product is a good way to:

1) Expand your reach globally

For most software developers, localisation into only a handful of other languages is enough to expand their reach – and the number of potential users of their software – many times over.

You need to take care to choose good potential audiences. But with proper research, any software localisation tends to have excellent rates of ROI as well as giving you a huge boost in user numbers.

2) Make an international impact

These days, it is very hard to make an impact on non-domestic audiences if you don’t speak their language.

Some users will accept that they must become fluent in a language that is more commonly spoken than their own native tongue – such as English, for example – if they want to use a product.

But many others will only use products that have versions available in their native tongue. Even those who can use and understand your product are far less likely to grow to love it if it’s not available in their preferred language.

3) Keep your reputation safe

A downside of failing to offer a properly localised version of your software is that users might be left with negative impressions of poorly translated or stop-gap measures you have left in place.

Small software creators and major brands alike have fallen afoul of local consumer opinion when they have failed to devote sufficient expertise and attention to their localisation efforts.

The subsequent losses of brand loyalty and reputation have cost companies heavily. They have also made products that were otherwise suitable for a given market fall flat, as local people continue to use poorer quality existing alternatives.

4) Make your product easy to recommend

Conversely, a properly localised product is easy for members of your target audience to use and thus is easy to recommend.

There is no need for your users to check whether the person they are recommending your product to is fluent in the languages you offer. Or for them not to recommend a product because they think it might be difficult for someone to get their head around using it, purely because it is not designed around local norms.

The localisation process smooths out all of these hurdles, making it appear as if your software has been designed for users from this specific target audience from day one.

Good targets for software localisation

While software localisation is well known for the reliably high Returns On Investment it offers, some pieces of software are better targets for localisation than others:

1. You want to grow your user base fast – like the example of Revolut above, many apps and software need to reach a certain scale of user base before major growth starts to happen. Achieving that critical mass is much easier when you are reaching out to audiences around the world.
2. You are still pre-release – if you are still in the development phase and you think there is a chance that one or more of the benefits of software localisation listed above might be useful for your software, following internationalisation practices during development is a sensible step. This will make later localisation much easier.
3. Non-region-specific software – the only type of software that might not be suitable for localisation is software that would only ever be needed by people in a certain region. Even software like this can be a good target for localisation if there are significant local communities with other language preferences. In the UK, this might make Welsh, Irish or Polish possible choices, for example.

Approaches to software localisation

There are broadly two different approaches to software localisation:

1. The Waterfall approach – this approach involves taking a set period out of the development cycle to handle localisation. A favourite time is just post-release. But any time during development is possible.
2. The Agile approach – during this approach, localisation and development happen concurrently. This makes the workflow much more flexible. Your team sends new code to the project database, your translation team is automatically notified and gets to work, translation QA happens, and then the translations are sent to the database.

Software localisation best practices

Enough software localisation theory. Let’s get onto the practice. There are several important things to bear in mind when localising software if you want to get the highest quality results as well as make the process easier for yourself:

1) Use internationalisation practices

It is possible to localise software that hasn’t been designed with localisation in mind. But you will find the process of creating multiple localised versions far, far easier if you develop with an eye on localisation from the very beginning.

Concrete steps to take as part of your internationalisation process include:

1. Have separate files for each language – most important for apps and software with larger volumes of text, you should always consider storing software text outside of the code. Separate language files are easy to export and import.
2. Use placeholders – instead of text hardcoded into your software, use placeholders to call for the correct localised version of text strings when needed.
3. Name and nest each string – use sensible naming practices to identify each string and nest them so that all sets of translations are grouped whenever possible. You should also use judicious comments to signpost what is going on.
4. Avoid concatenated strings – different languages have different word orders, grammar and syntax. Avoid concatenated strings as they can cause serious confusion.

2) Keep it simple

Everything you can do to keep your code straightforward and your UI ready for adaption to different norms will stand you in good stead when it becomes time to localise.

Unnecessary complexity is bad UX design in any case. But it really gets compounded when you then need to localise the functionality or design for someone from a completely different cultural background.

3) Separate text and graphics

Always try to avoid having text and images in the same graphic. Creating an entirely new graphic with the correct translated text takes much longer than being able to quickly – or even automatically – swap the text out for a localised version.

4) Remember that translated text can expand, contract and “reverse”

The same phrase or word can take different amounts of space in different languages. For example, translating text from English to German often results in it taking up around 30% more space.

You should also be aware that some languages are written from right-to-left instead of left-to-right. Other languages can be written from top to bottom. Users are used to scanning screens in different ways, meaning that your entire design may need to be flipped or otherwise altered.

Make sure that your GUI will be able to adapt to changes like this. Build in plenty of space to allow for this kind of expansion where necessary.

5) Use UTF-8 (or UTF-16) encoding

UTF-8 supports the largest range of languages, allowing characters to be translated automatically. It makes sense to use this encoding for most purposes. Only when it comes to some Asian languages is UTF-16 a better choice.

6) Focus on your graphic design too

Localisation does not stop at the words your users will read. It needs to include images, icons, graphics – even your colour scheme. Colour symbolism plays a role in most cultures, but it does so prominently in parts of East, South and South-East Asia.

Bear in mind that even some images that seem completely neutral – such as someone patting a child on the head – may be culturally inappropriate in some countries. Remember also that some icons that appear universal – the gear icon representing settings on a mobile app – also have different local versions.

What makes sense to one audience is not guaranteed to make sense to another. What is neutral or positive to one audience may offend another. Always pay attention to every aspect of your graphic design.

7) Even your UX needs to be localised

In fact, especially your UX needs to be localised. Keep your UX design as simple as possible if you want to keep the localisation process as simple as possible.

Always bear in mind what is “natural” in some cultures in terms of UX design may not be seen as a positive in others. For example, users in the UK or US might broadly prefer streamlined designs with clear options. However, Japanese users – on average – often prefer to have as much information and see as many of the available options as possible. This often means a large number of sidebars and hyperlinks.

UK or US users might be put into “analysis paralysis” by too much information. Japanese users might not feel confident unless they can see more information. It all depends on what is “normal” for this particular audience.

8) Do your research

But how do you find out what your – for instance – new Japanese audience really wants in terms of UX design or colour scheme?

User and market research is always an important part of effective software localisation. You can also analyse competitor platforms and other successful software used locally to see how much information they display to users, where they choose to place it, and if there are any identifiable best practices.

Localisation works best if you work with an experienced local partner. For instance, Kwintessential has extensive experience helping businesses in all industries localise their software in over 200 hundred languages and many specific regions. Using in-country specialists translating into their native language ensures that your localised software always looks “natural” to a native user.

9) Don’t generalise about cultures or regions

Your research should show you how much of a mistake it is to make sweeping generalisations about different cultures and regions. Remember that a single language can span cultures as different as the UK, US, Canada, Australia and New Zealand. Or as diverse as Spain, Mexico, Honduras, Panama and Argentina.

You should also remember that in some places – Belgium, Switzerland, Russia or Canada, for instance – multiple languages are spoken within the same country or region.

Again, good research and working with partners with deep experience in the region is the key to success.

10) Create a style guide

One of the major challenges for any brand when localising is to keep its brand image consistent across all languages.

You can help your chosen Language Service Provider do this by creating a style guide. The same guide can often be expanded in partnership with your LSP to provide a handy reference point for developers creating software for specific regions too.

Your style guide might include notes on brand voice and tone, agreed translations of product names or brand terms, as well as market research information like buyer personas where necessary.

Start as you mean to go on – test your localised software

One of the most important things to do, over and above following all of the software localisation tips listed above, is to heavily test your software on members of your target user base before release.

All the best practices and research in the world can often be equalled in terms of issue-spotting by simply sitting a few eager participants in front of your software and having them actually use it for a few minutes.

Looking to localise your software for a new international audience?

Let’s talk. Kwintessential makes software localisation simple for some of the biggest-name brands and smallest developers in the UK and around the world.