Although you鈥檝e 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鈥檝e had our fair share of software localisation projects throughout the years and we鈥檝e 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鈥檛 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, 鈥渋t鈥檚 really important to have appropriate context when translating; it鈥檚 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 鈥淪ave for later鈥� that could be correctly translated into Finnish as Tallenna my枚hemp盲盲 k盲ytt枚盲 varten:

In this case, there鈥檚 no easy way to contract the string so it fits inside the button, although this is sometimes possible. Antti suggests that 鈥渢his could be translated simply as Tallenna 鈥楽ave鈥�, because in the end, that seems to encapsulate the essence of 鈥榮ave 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 鈥渢he 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鈥檛 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 鈥榝ugitives鈥�.

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鈥檙e 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鈥檛 get the answers right. Therefore, when launching your product, or localising it to expand to new markets, you should make sure that it鈥檚 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鈥檚 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鈥檝e gone this far and invested time and effort in your software product, then you鈥檇 better get your i鈥檚 dotted and your t鈥檚 crossed when it comes to money. If you still haven鈥檛 done that, then consider the points mentioned in this section.

Four of the five Nordic countries use a currency that literally means 鈥榗rown鈥� 鈥� the Danish/Norwegian krone, the Swedish krona and the Icelandic 办谤贸苍补 鈥� 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鈥檝e discussed the most common linguistic issues that you can encounter in the software localisation process. But often problems can鈥檛 be foreseen when localising, so let鈥檚 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: 鈥淎bbreviations 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鈥檚 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鈥檚 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:

Another cosmetic problem concerns text layout. Having a bad layout won鈥檛 lead to misunderstandings or misinterpretations, but it detracts from your product鈥檚 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 or hyphens, or automatically inserting in just the right place to avoid awkward line or word breaks. Think about text in a newspaper column: where there isn鈥檛 sufficient space, a hyphen is used to break the word across two lines. However, the hyphen can鈥檛 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鈥檚 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鈥檚 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鈥檛 take any chances with your product and go that extra mile to achieve total user delight!

The post 5 things to check when reviewing your software translation appeared first on sa国际传媒.