You and your team have put hard work over countless hours into coding, testing and debugging your app. You’ve also thought of everything when it comes to localising your product and now you feel like you’re ready to launch it. But are you?
Although you’ve put great effort and thought into all aspects of your product, including the software localisation phase, there are some things that might have escaped your attention and that you need to consider before releasing your creation into the world.
At Sandberg, we’ve had our fair share of software localisation projects throughout the years and we’ve distilled that experience into a five-step live review phase that you should consider running before hitting that launch button.
1. Check for truncated strings
Nordic languages are different from English on many levels, one of which is the length of words. Often, words in the Nordic languages tend to be longer than their English equivalents. This shouldn’t pose a problem in most cases, but in software localisation, having an awareness of this is vital.
Text expansion varies from 5–10% for Norwegian, to a staggering 30–40% for Finnish. This may cause strings to be truncated in the user interface (UI) and lead to misunderstandings that can, well, cause serious problems.
According to our Lead Finnish translator, Antti Lamminen, “it’s really important to have appropriate context when translating; it’s good to know when something is supposed to fit into the space of a button!”.
A simple example would be a button with the English text “Save for later” that could be correctly translated into Finnish as Tallenna myöhempää käyttöä varten:
English
Finnish
In this case, there’s no easy way to contract the string so it fits inside the button, although this is sometimes possible. Antti suggests that “this could be translated simply as Tallenna ‘Save’, because in the end, that seems to encapsulate the essence of ‘save for later’; you save something so that you can use it later, right?”. This might not back-translate exactly into the original English text, but it still conveys the intended meaning and fits the space limitations.
Antti also advises against setting a character limit in the target languages based on the length of the current source segment. He adds that such a limitation would require “the translation of a string consisting of one four-letter English word to use no more than four characters. As can be expected, this sometimes creates completely silly super-abbreviations that no-one can understand sometimes not even the translator themselves, when they return to the work at a later stage.”
2. Check for missing translations
In our experience, one of the most common things that can slip through the cracks and find its way into your final product is untranslated strings. This doesn’t happen that often, but the bigger and more complex your software is, the bigger the chance is that something will go unchecked. This may well go unnoticed by your users too, but is this reason enough to overlook it and skip the double-checking?
The most common things that can be missed during the translation phase are warning/error messages or strings that are not externalised. This is why detailed testing of the entire app and its functionality is needed as it is the only way to catch any ‘fugitives’.
Depending on how you have engineered your software, the error messages might be in a different file than other strings. This might lead to English pop-up messages and errors in the localised version of the product.
String externalisation allows you to easily localise your software without the need to rebuild your software from the ground up for each and every language you decide to expand your product into. Externalisation can just as easily be described as translation. So, before you send your strings for translation you should make sure that everything that needs to be localised is externalised using the development platform you have selected to code your product on.
3. Incorrect locale settings (date formats, numbers etc.)
You’re planning a holiday? Great! But did you book your flight for Monday 5 April or Tuesday 4 May? Was it for 4:15 pm or am? What does this even mean if you are, like most of the world, using the 24-hour format?
These questions can have big impact and consequences if you don’t get the answers right. Therefore, when launching your product, or localising it to expand to new markets, you should make sure that it’s on point around-the-clock.
You should avoid hard-coding time and dates into your software product if you want to avoid serious problems. Even if you have missed this, live review can bring these issues to the fore, allowing you to easily fix them.
Different locales may use different decimal and thousand separators. For example, in Denmark and Iceland, dots are used for separating thousands, however in Finland, Norway and Sweden a space is used instead. Although they may have different preferences for separating thousands, when it comes to decimal separation the Nordic countries are on the same page and opt for the comma.
Often the user will set their language or locale at the operating system level and so you should make sure your app respects the user’s preferences when it comes to date and number formats (find out more about this topic in our guide to working with currency, number and date formats).
4. Currency and pricing
If you’ve gone this far and invested time and effort in your software product, then you’d better get your i’s dotted and your t’s crossed when it comes to money. If you still haven’t done that, then consider the points mentioned in this section.
Four of the five Nordic countries use a currency that literally means ‘crown’ – the Danish/Norwegian krone, the Swedish krona and the Icelandic króna – all of them are represented by the customary symbol kr. Finland on the other hand is in line with most of the European Union and has adopted the euro, represented as €.
As is the trend in many non-English speaking European countries, the Nordics agree that the amount should precede the currency symbol and that they should be separated by a space.
It might not be too big of a problem if your product costs kr. 999 or 999 kr. in Denmark, but the same cannot be said if the price is listed as 100.000 kr. instead of the intended 100,000 kr. This is why you should be extra careful when it comes to monetary amounts and leave no stone unturned – a thorough check by a native linguist of the areas of your website or application that deal with buying or selling should prevent any future headaches.
5. Aesthetics
So far, we’ve discussed the most common linguistic issues that you can encounter in the software localisation process. But often problems can’t be foreseen when localising, so let’s go through the looking glass and dive deeper into the product and all of its features.
This helps us discover any non-linguistic issues that may pop up in your software but that are still directly related to the language your software has been localised into.
As shown in the truncated strings example above, sometimes the translation can be substantially longer that the original and this can lead to an eyesore in the final product.
As Danish Translator Christina Bjerggaard explains, the translator has two options in cases like these: either to try and rephrase the translation to make it shorter or to use abbreviations: “Abbreviations are not always a good option, because there is a risk that the reader will not understand them. The problem with UI strings is that they are often rather standardised phrases, and it’s not really possible to paraphrase them, because there are no other options for conveying the same meaning.”
But there is another way the problem can be solved, and it’s in your hands entirely – it comes down to using a simple wrap attribute on your buttons! This way you can overcome most UI related problems. So, by just adding wrap to your button definition you get the more aesthetically pleasing:
English
Finnish
Another cosmetic problem concerns text layout. Having a bad layout won’t lead to misunderstandings or misinterpretations, but it detracts from your product’s aesthetics and overall user experience, and it may encourage people to stop using it.
You can improve the look of your software by keeping certain words together on the screen or across page breaks. This might require using non-breaking spaces or hyphens, or automatically inserting ‘soft’ hyphens in just the right place to avoid awkward line or word breaks. Think about text in a newspaper column: where there isn’t sufficient space, a hyphen is used to break the word across two lines. However, the hyphen can’t just be placed anywhere in the word, there are specific rules and conventions which vary by language. Which of these is easier to read?
in-for-ma-tion vs. i-nfo-rm-atio-n
The only way to deal with the text layout and different language’s rules related to that is through detailed review, carried out by a native speaker of the language in question.
Everything mentioned in this article, or other unforeseen issues, can be easily prevented by including a final live review in your product’s software localisation cycle. Taking the extra time to ensure your user experience is fantastic across different localisations increases overall user satisfaction and loyalty and can reduce the number of support requests you receive.
So don’t take any chances with your product and go that extra mile to achieve total user delight!
