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