Internationalisation and localisation - reasonably straight forward?
Often internationalisation and localisation are seen as reasonably straight forward tasks. Surely it’s just translations right? So, you can pay people to do that - problem solved!
Well actually, no. That’s the localisation bit and that comes after internationalisation. Unfortunately, as many experienced developers will know, internationalisation isn’t at all straightforward, especially when your software works across multiple platforms.
Below we've listed seven of the most difficult aspects of internationalisation and localisation.
1. Translation formats
We develop apps for Android and iOS and both of these have different formats for translation. Following the iOS8 release last year, iOS apps now use the .xliff format and Android continues to use the xml format.
The problem this creates is how to handle translating for the two formats. Obviously paying for the translations to be done twice is one way, but that can be expensive and certainly isn’t effective.
Of course you could also use an online service, such as; poeditor. But the drawback is the need to have the strings for the two platforms identical. This also isn’t a particularly effective solution as there will always be a manual entry task at the end to add/remove the platform specific strings, such as, error messages and other context related text.
You could also try and do the translations up front at the design stage, but that doesn’t fit well with iterative development, and the likelihood of every error message and UI text being identified at the design stage is unlikely.
In our experience there isn’t a clear answer to this, and so we use an amalgamation of all of the above. We do some strings at the design stage, some iteratively for the strings that are identical across the platforms and some at the end to tidy up the remaining parts. The worst bit of this is that the translations cannot be done in one go, the best bit being that the effort isn’t duplicated.
"Trawling through every string in your software to ensure that they wrap or truncate properly before you start localisation is really important "
The UI can be really difficult for internationalisation. We’ve seen and heard it said that German translations are often 30-40% longer than their English counterparts and that does seem about right.
Trawling through every single string in your software and ensuring that the strings wrap or truncate properly before you start localisation is really important and can make your life easier in the long run. Luckily, there are tools to help you do it, such as the Pseudolanguages tool from Apple in Xcode.
Also, don’t forget all those images with text in them!
The formats of prices can be completely different from country to country and the currencies & exchange rates obviously add another dimension.
It can seem pretty simple to begin with, so for an example let's see how we would display the price £2,000.00 to different users:
- An English speaker has the app in English and is viewing the currency in pounds sterling, they would see: £2,000.00
- A Swedish speaker who has the language of the app in Swedish and is viewing currencies in Krona would see: 24.034,91kr
- But, what if the Swedish user was buying the product from the UK and was being billed in sterling? What would they then see? £2,000.00 or 2.000,00£? See the confusion!
From our point of view we always advise (as do many others) that it is important to keep the price format readable for the user, so we would say that the format should be based on the language and the currency symbol inserted where they would expect to see it. For example:
- English - £2,000.00
- Swedish - 2.000,00 £
- French - 2 000,00 £
- Swiss - £ 2’000.00
- German - 2.000,00 £
Pretty much every country in the world has its own address format, so validation for internationalised apps can become a real headache.
Making sure that the English users definitely put in a valid postcode, but the American users put in a valid zip code and the Irish users don’t put in anything at all can cause many developers countless sleepless nights developing logic to handle each eventuality.
"Pretty much every country in the world has its own address format, so validation for internationalised apps can become a real headache."
5. Right to left
Hey, we’re lucky. We don’t have to do this too often, but we know the most important thing is to make the decision right at the very start of development - whether the software will ever be needed to be available for users that read right to left.
Luckily, there are lots of libraries, options and tools that help with this. However, almost all of them are difficult to implement retrospectively, so make that call early.
The test team’s efforts are going to be significantly bigger with internationalisation and localisation. Testing will have to be carried out for every language, and every locale.
If that wasn’t bad enough, there'll then have to be lots of regression testing to check upgrade paths with each language and locale. Migrating from one version to another in different languages can cause major bugs.
On top of all of that will be a big test effort to check the functionality in the different combinations of language and locale, as there will always be some non-straightforward edge cases.
7. Slowing of development
This is the big one. With the adding of translations and internationalisation development in software the ongoing development is going to slow right down. It’s logical that adding translations and test effort to every part of your app and new feature is going to need a whole lot more time, development and testing.
As a generalised rule, we would expect that test effort would increase by a good 30% for each translation added. Also, every development is probably going to take a similar amount more, and of course there is making sure that every new development is translated.
The only real way to reduce this is to wait... Wait until your software is as fully fledged as possible before deciding to support different countries.