A solid software localisation strategy will save you time and money. What’s more, the earlier you start planning, the easier you’ll find integrating other languages later on.
Of course, if you try localising your software on-the-fly at a later date, it might still be possible.
But it’s certain to be far more difficult, less effective – and far more costly – than having a proper plan for multi-language versions of your software or app in place from the very start.
In this article, we’ll take a look at the two “parts” of this process, namely software internationalisation and localisation. Because while these words sound like they could either be synonyms for the same thing or two completely different things…
They’re actually closely related parts of a very important process. They’re also intrinsically linked:
This means that without proper internationalisation, figuring out how to localise software is going to be a whole lot harder…
Start as you mean to go on – what is software internationalisation?
Software internationalisation is the framework of development and design practices which you’re going to use to make the later localisation of your software simple.
Sometimes shortened to “i18n” or referred to as globalisation, this process should be a part of your software development from the very start. If you have it in place, you’ll be able to add new language versions to your product with ease.
Internationalisation involves making sure:
- Your User Interface has been designed with localisation in mind – considering space usage, for example, which we’ll look at below.
- You standardise encoding between languages (using Unicode UTF-8)
- Your source code is separate from the strings which will need to be translated
- Creating an external file from those strings which require translation (resource files)
To do this, you will usually need to create:
Those external files containing all of the strings which are in need of localisation are generally referred to as resource files. Each language will usually have its own file. The actual format of the file will commonly depend on the type of software you’re localising.
The correct language resource file is then called depending on the user’s region.
In this context, resource bundles usually mean several resource files which target similar locales or related languages. These tend to be bundled together under a shared base name.
Plan where you’re going to release and your target regions
Properly targeting the regions in which you’re going to release your software is an essential part of the localisation process. You need to know that your new target market has sufficient demand for your product to justify the costs of localising for that region.
It seems like a common-sense step. But you might be surprised how many big brands waste money by not investigating this sort of thing first. Even if you have a large budget, you’ll no doubt want to maximise your Return On Investment by picking your target regions carefully.
You might start by:
- Proper analysis of your web traffic: you need to identify where you’re getting traffic from to begin to spot potential markets for your product. If the data doesn’t support the move, is it worth spending your money?
- Look at cultural differences and similarities: how relevant is your software going to be for people from this culture? In some cultures, your dating app might be wholly unsuitable, for example.
- Consider local legislation: when you’re releasing your software or app in a different part of the world, making sure you don’t fall afoul of local legal codes is a very important step. Having a local partner can help you overcome this. Laws may limit the types of images you can use, the language or even the very types of software that are permissible.
Consider space usage and your UI
The amount of space a certain amount of text will take up will vary between languages.
What will happen to your smart UI design when the Italian version of your English welcome message is translated into a phrase that’s 30% longer? Or when the multiple words of a certain segment of text in your English language version come back as a single succinct – yet very lengthy – German word?
Planning for changes in space usage is a critical part of your software design when you’re intending to have multiple language versions. Make sure you have a decent amount of extra space either way to allow for the shrinkage or expansion of text strings.
Hard-coded design elements are an absolute no from an internationalisation point of view. Instead, dynamic UI expansion should be your goal. You can use:
- Fragments: for Android apps.
- Auto Layout: for iOS apps.
Think about site and internet speeds
The amount of time that internet browsers in any part of the world are willing to wait for a site or app to load is getting shorter all the time. Plus, most search engines use site speed as a ranking factor. This means you need to make sure your site is as fast as it possibly can be.
It also means that if your software is web-based or requires the user to be online, you’ll need to plan for this in new regions.
For example, when considering web hosting in China you’ll want to look at the effects of the “Great Firewall”. This virtual edifice means that your site will often suffer significant speed penalties if you choose to host outside of China.
You may want to consider using a Content Delivery Network (CDN) in some parts of the world.
Decide on your Translation Management Software (TMS)
A TMS is one of the most time and effort-saving software localisation tools. Some basic functionality that you should make sure you get from your TMS might include:
- An easy collaborative workspace: having an effective shared workspace is arguably the main function of an TMS. This ensures you don’t need to be trawling through email chains or searching for comments made in that meeting last week.
- A built-in API (Application Programming Interface): an API lets you import local files with ease and build new products into the workflow. It’s an important part of any TMS.
- Translation Memories (TM): a TM will play a crucial role in both speeding up the translation of your project and in ensuring that certain words and phrases are translated consistently across this particular piece of software – and all future projects or other places (like your marcoms) where they might feature. TMs are essentially databases of already-translated phrases which can be automatically called up by professional translators using the right software.
If you’re not familiar with Translation Management Systems, your best bet is to request more information or a recommendation from your Language Service Provider.
Now it’s time for software localisation
By now you’ve put a lot of groundwork into ensuring that you’re set up for the actual task of translating your software. Let’s get down to it.
Some of the top software localisation best practices include:
If you haven’t prepared your resource files and separated them from your source code, or your preferred format isn’t quite right for your translation agency, their first step will be preparing it.
You’ll save time – and probably money – by making sure your files are all set up and ready to go.
Creation of glossaries and style guides
This is a sensible step to take before handing your project over to your Language Service Provider.
Giving your translation team a glossary or style guide to work from is the best way to make sure that your localised message stays on-brand and that any terminology or brand-specific phrasing is always translated in an identical way.
Translation and localisation
The actual localisation of your software is still a major task and will include:
- The fluent and accurate translation of your text.
- Making sure your UI is culturally appropriate (making sure that right-to-left languages are implemented correctly and so on).
- Checking that all images, icons and symbols you’ve used will be understood by your audience. Remember – even such seemingly universal icons as the settings “gear” can mean different things to different global audiences.
- Extensive Quality Assurance procedures.
As well as your software localisation strategy, you should remember not to slack off in other parts of your production where translation is called for. Wherever you’re aiming content at a foreign-language audience, you need to make sure you’re doing it with the highest possible level of accuracy and fluency.
This could mean:
- Your marketing communications
- Your website (website localisation strategy actually follows many similar steps to those listed here)
- Your product documentation
You’ll be all too familiar with the thoughts which run through your mind whenever you see a website, app or advert in poorly translated English…
Don’t let that be you when you launch in a new foreign region. Even massive brands like Coca Cola, HSBC and McDonald’s have encountered serious issues when trying to localise their content effectively for challenging regions like China.
Carry out your linguistic and UX testing (it’s vital)
Have you ever read an ad or glanced at a website, spotted an error and thought, “how have they missed that?”
Linguistic testing ensures that no one will think the same thing when looking at your software. You’ll need your linguistic testers to be native speakers from the actual target region. You should also have them check the User Experience and how it flows on every single platform you’ll be releasing on after localisation is complete.
Bug fixing and error checking to catch broken forms, links or code should also be built into your testing cycle for each language.
Start work on your website or software localisation strategy early The best time to get started on your software localisation strategy is before you start coding your app.
But, no matter when you start, making sure you do everything you can to prepare for internationalisation is going to stand you in good stead when the time comes to actually get started.
Do you need to find out more about software internationalisation and localisation?
Comment below to get a response – or contact us with a question at any time.