The effects of software localisation cascade down to every aspect of development and post-development, from UX and interface design to the basic engineering and core functionality of your product, and to documentation, support and marketing. With this in mind, getting a good grounding in the repercussions that designing for different locales has for the development process is a great idea for any software developer.

We’ll start by explaining some basic concepts. Then, we’ll look at examples of strings from different languages and explore the requirements that different locales have. Throughout this post, we’ll refer to our fictional app “SuperApp” in our examples.

Locales vs language variants

It might be helpful to start by looking at what we mean by a locale. This is a term used both in the tech and translation industries to refer to a country-specific variant of a language. If you’re not from a multilingual background, you’d be forgiven for thinking that it’s sufficient to think about languages such as English, Spanish and Swedish. If we want to make SuperApp available in one of these languages, surely it’s enough to translate the strings and be done with it?

The thing is, “language” is a fuzzy term and nowhere near granular enough for our needs. Let’s start with English. It’s spoken natively by over 400 million people and is an official language in 55 sovereign states – a group of countries commonly referred to as the Anglosphere. The language isn’t uniform across the Anglosphere: there are dozens of national varieties, each with their own conventions for things like pronunciation, grammar and spelling standards, and even how dates and numbers are formatted.

You’re more than likely already familiar with the two biggest varieties: British English and American English. These national standards can be expressed with the en-GB and en-US, respectively. The story is similar (albeit on a much smaller scale) for languages like Swedish ­– which is an official language in both Sweden (����‑S��) and Finland (����‑F��).

But is this a locale? Well, not quite. The tags above refer to the language variant only and do not include the user’s selected region settings. Region settings affect things such as how the date and time is expressed (e.g. ‘31 December’ being written as 31/12 or 12/31, and whether to use 12- or 24-hour clock by default), how numbers are formatted (e.g. using a dot or a comma as the decimal separator) and where currency symbols are placed (e.g. before or after the amount, with or without a space). If we bundle these region settings up with the language variety, then we get our locale.

On most operating systems, users can independently select their interface language and preferred region settings, meaning they can end up with locales that don’t necessarily align with national language variants. For example, many Icelanders use their computers in English but with their region set to Iceland. This locale would be expressed as en_IS (note the use of an underscore as opposed to a hyphen).

Although it’s important to understand the distinction between language variants and locales, thankfully, the hard work of accounting for all the different date and number formats is done for you on most platforms. Apple, for example, provides a wide range of formatters that adjust things like the decimal indicator and date format automatically for the user’s selected region settings, even if those region settings don’t correspond to the interface language.

One final consideration is the aspect of hierarchy when it comes to language variants. Your app may only support one broad variety of English (en) or Spanish (es), for example, rather than country-specific variants. Even though you don’t support their local variant, most users will still prefer to use the broad international or regional variant of their language rather than a different language altogether.

Let’s take Spanish as an example. Most often, software is localised into Peninsular Spanish (the variety spoken in Spain) first. This national standard also acts as the ‘broad’ variety and would sit at the top of the hierarchy, designated es. Now that we’ve made SuperApp available in Spanish, we have decided to offer a more tailored experience for our Latin American users by supporting their regional language variant, which is designated ���‑419. Going further, we’ve decided to offer our Mexican users an even more localised experience and translate our strings into Mexican Spanish, meaning we end up with an ���′ѳ� variant as well. If a user’s preferred variant is not available, then they can cascade back up the list until they find their closest preferred language variant.

Things to consider when writing strings for software localisation

Now that we’ve got a firm grip on locales, we can take a look at the ramifications of software localisation when it comes to writing and concatenating (or segmenting) your software strings.

Numbers and dates

We’ve already briefly touched on the subject, so we should probably get this out of the way early. In almost all situations, there is essentially one golden rule to follow here: never hard-code date, time or number formats.

No matter what programming language and dev environment you’re using, there are fantastic date and number formatters available – either native or added through libraries such as – that take care of all the hard work for you, returning perfectly localised dates and numbers that respect your users’ region settings. The best advice here is to rely solidly on these and save yourself a world of trouble.

Word endings

In English, there are relatively few word endings (inflections) to consider. The vast majority of nouns are made plural by adding an -s or -es. When it comes to most verbs, we have only two forms in the present tense, for example, �����Բ�����and sing. However, many languages have a greater variety of endings than English, and these can affect more classes of words than nouns and verbs; for example, many languages also inflect adjectives. The distribution can also vary by language: some languages, particularly Scandinavian ones, have less inflection than English on verbs but more on adjectives.

Let’s take this example from Norwegian:

��ä�� finns 1 rum ledigt på denne prisen.
There is 1 room available at this price.

��ä�� finns 10 rum lediga på denne prisen.
There are 10 rooms available at this price.

Here we can see that the verb finns is the same in both sentences, whereas in English we have two different forms, is and are. On the other hand, the adjective has changed: in the first sentence, it is singular (ledigt), and in the second, it is plural (lediga).

This affects how we concatenate our strings. As a general rule, it’s always best to avoid chopping strings up wherever you can. The translator will be able to offer a better-quality translation if we leave the string as intact as possible. Another reason for this, as we’ll see below, is that word order can vary hugely between languages, so we should never assume that, for example, numbers will occur in the same position in the sentence.

Plurals

In the Swedish example above, we saw how word endings can change between singular and plural forms. In the Scandinavian languages and Finnish, we only have to worry about a singular and non-singular form. For other languages, the situation is slightly more complex. Let’s take an example from Icelandic:

1 bíll fannst á þessu verði í nágrenninu.
1 car was found at this price nearby.

12 bílar fundust��á þessu virði í nágrenninu.
12 cars were found at this price nearby. 

21 bíll fannst��á þessu virði í nágrenninu.
21 cars were found at this price nearby.

The first two sentences in this example show the same singular–plural distinction we’ve seen so far: when the number is more than 1, there is a different ending for the word. The singular word is����í������“car”, and the plural word is ��í��������“cars”. However, Icelandic also requires numbers ending in -1 (with the exception of 11) to use the singular form, whereas other languages, including English, might have the plural form. This is because of the way the number is constructed in Icelandic: 21 expands to tuttugu og einn “twenty and one”, so we’re literally saying “twenty and one car”. This is something we need to take into consideration in our logic when deciding which form of a string to serve up in Icelandic.

In the Slavic languages, we have to consider a different, even more complex set of rules. In Polish, for example, there are three possible forms to choose from, depending on the number used:

1. A singular form (e.g. �������dz���ó�� “c����”);
2. A form used with 2, 3 and 4, and any numbers ending in -2, -3 or -4, except for 12, 13 and 14 (samochody);
3. A form used with all other numbers (�������dz���ǻ�ó��).

In JavaScript, we could express this rule as follows:

function returnPolishForm(i) {
�� var form = 'genPlural'; // Our default form
	var lastDigit = i.toString().slice(-1);
	if(i==1) {
		form = 'singular'; // If i is 1
	} else {
  	if (lastDigit >= 2 && lastDigit <=4) {
			form = 'plural'; // If i ends in -2, -3, -4 and is not 12, 13, 14
      if(i >= 12 && i <=14) {
        form = 'genPlural'; // If i is 12, 13, 14
      }
		} else {
�� �� 	form = 'genPlural'; // All other numbers
�� �� }
�� }
�� return form;
}

Let’s take the example we used for Icelandic from above and apply it to Polish:

W okolicy znaleziono 1 �������dz���ó�� w tej cenie.
1 car was found at this price nearby.

W okolicy znaleziono 2 samochody w tej cenie.
2 cars were found at this price nearby.

W okolicy znaleziono 5 �������dz���ǻ�ó�� w tej cenie.
5 cars were found at this price nearby.

W okolicy znaleziono 23 samochody w tej cenie.
23 cars were found at this price nearby.

W okolicy znaleziono 25 �������dz���ǻ�ó�� w tej cenie.
25 cars were found at this price nearby.

Note how the word for “car” changes with the number. To serve the correct form of the string to the user, we need to add some logic that is specific to Polish. If we don’t do this, then we’ll introduce a grammatical error that, in the best case, detracts from the user’s experience and, in the worst case, creates a severe misunderstanding.

Gender

Many languages have a feature called grammatical gender. These are essentially classes of nouns that inflect in a similar way. While they may be labelled masculine, feminine or neuter, a word’s grammatical gender doesn’t always align with its natural gender. In German, for example, the word for “girl”, ��ä�峦����, is neuter. Gender doesn’t only affect nouns, though; it has knock-on effects on adjective endings and pronouns as well.

Pronouns

In English, we use the neuter pronoun it to refer to inanimate objects. A typical string in SuperApp might look something like this:

This document is over 50 MB in size. Would you like to send it anyway?

In Icelandic, this would be:

Þ��ٳٲ� skjal (n.) er yfir 50 MB að stærð. Viltu senda þ��ð (n.) samt?

The word for ‘document’, skjal, is grammatically neuter (n.). As a programmer, it may be tempting to split this message into two strings, as we have two sentences. Then, if we need to swap out the first string, say, to refer to a photo instead of a document, we can just concatenate them at runtime. However, if we change ‘document’ to ‘photo’ here, we get an ungrammatical construction in Icelandic (indicated by the asterisk):

Þ������� mynd��(f.) er yfir 50 MB að stærð. Viltu senda *þ��ð��(n.) samt?

The problem stems from the fact that mynd is feminine (f.), but þ��ð is neuter. This means that the gender doesn’t agree, making this pair of sentences ungrammatical. Instead of þ��ð, we should have the feminine pronoun hana (literally ‘she’), which refers back to mynd. The better solution then is to keep these sentences together in one string and allow the linguist to translate it as one block.

Adjectives

Gender also affects how we address users. In English, particularly in user interfaces, we tend to see a lot of structures like this:

Are you sure you want to delete this folder?
Are you ready to turn on your camera and microphone?

These kinds of sentences work great in English regardless of the gender and number of the people we’re addressing. However, in languages such as Spanish that mark gender on adjectives, we need to account for feminine and masculine forms in order to be inclusive:

¿������á�� seguro/segura que quieres eliminar esta carpeta? 
¿������á�� listo/lista para encender tu cámara y tu micrófono?

In the first example, the translator can solve the problem somewhat creatively by rephrasing it to ¿Seguro que quieres eliminar esta carpeta?, which can be translated as ‘Is it certain that you want to delete this folder?’. This construction avoids addressing the user directly with an adjective.

However, the second phrase is more challenging to rework without addressing the user directly, so here we need to include both the masculine listo and the feminine lista to avoid excluding female users.

When writing strings, it’s good practice to avoid addressing the user directly with adjectives if you can help it. While a good translator will always find a solution, sometimes it might not be as neat as in English, and it could use more characters and subsequently take up more space in the UI.��

Text expansion and contraction

As we’ve seen above, translation can drastically alter the length of software strings. Some languages require more words or characters to express the same meaning as in English, whereas others may require fewer. show the number of characters in a string may increase by up to 200%, and that this is most likely to happen in the shortest strings, typically those below 10 characters. French, Italian and Spanish are all languages that see character expansions in this range. For the Nordic languages, your strings may actually contract in certain contexts as well. For example:

Another thing to note from the example phrases here is how the word order can vary from language to language. Notice how in Spanish, the verb comes at the start of the sentence, and our photo count is pushed further down. In Finnish, the album name is pushed up to the top of the sentence, directly following albumista ‘from the album’.

Also, note how the punctuation varies from language to language. Each has slightly different conventions for things like speech marks. English uses “ ”, whereas Icelandic uses „ “ and French uses guillemets « » (with a space on either side of the enclosed word).

For this reason, we should avoid syntax like this:

var string = photoCount.' '
             .photosWereDeleteFromAlbumString
             .'“'.albumName.'”.';

The preferred syntax would contain placeholders that the linguist is free to move at will, which you can then replace with variables at runtime:

// English
'{photoCount} photos were deleted from the album “{albumName}”.'
// Finnish
'Albumista ”{albumName}” poistettiin��{photoCount} valokuvaa.'

Note that the above examples don’t account for singular–plural distinctions – further logic is required to accommodate for those.

Context is key for software localisation

The thing that perhaps best equips a linguist to be able to translate your strings successfully is adequate context. Knowing when and where a string appears enables the translator to make a whole range of linguistic decisions and ultimately provide a correct, high-quality and consistent localisation of your software.

We recommend sticking to these guiding principles:

1. Get your product into the hands of your translators

It’s crucial to loop translators into your development process early. Even if you’ve not yet delivered your first public release, it’s vital that linguists understand your app’s purpose and how your UI is laid out. Giving them access to pre-release versions means you save yourself from future headaches and endless rounds of feedback and feedback implementation.

2. Provide local context

Software strings can be as short as one word. They might consist of a single verb: ‘delete’, for example. But is this verb functioning as an imperative (giving a command) or just as an infinitive (the dictionary form of the verb)? In English, they look the same, but that’s not necessarily the case in other languages. To enable the translator to make the right choice, give them access to view surrounding strings even if they’ve already been translated, or even better, provide screenshots. Some tools can automate this process for you.

3. Give your translators access to other translations

If you’ve already localised into several languages or variants, giving translators access to those can make a world of difference, especially for closely related languages. For example, if you’ve already localised into Swedish and are now adding Danish and Norwegian, giving your translators access to the Swedish strings in a translation memory will help answer a lot of questions they’ll have and may even allow them to recycle some existing translation solutions.

4. Keep an open line of communication

Translators are used to surmising the meaning of a text from the context they have available, but sometimes they just don’t have the key information to hand that would allow them to choose the right translation. Be receptive to translator queries and respond with as much information and context as you can.

5. Be open to adapting your product

It’s impossible for any one developer to account for all of the nuances of every language variant they might want to localise into. Leverage the linguistic expertise of your translators to improve how you write, segment and concatenate your strings. For example, you might need to account for a different word order than you anticipated, or you might need to adapt your logic to account for different word endings. Linguists can advise you on what works and what doesn’t for their language.

We’ve covered a lot of ground in this post, but there’s always more that could be said. The main thing to take away is to approach software localisation with an open mind. Be prepared to give and receive feedback, adapt and iterate as you go, and take advantage of your translators’ linguistic expertise to deliver the best UX in your target locale.

Many developers are rightly wary about the software localisation process. After all, you’re essentially entrusting somebody else to deliver your core user experience in a specific market. You want to make sure that you deliver on tone of voice, brand values and naturalness, not just having a grammatically correct translation. The key to this is a collaborative partnership and close, regular communication.

If you and your translators are all aligned around the same end goal of delivering a fantastic experience, and they’re armed with the tools to make that happen, you’ll reap the many benefits that software localisation has to offer.

This article was initially published in 2020 by Max Naylor, a former Sandberg team member, and has since been revised with updated data.

The post The ultimate linguistic guide to software localisation for developers appeared first on sa���ʴ�ý.

The post How to localise marketing content for other markets appeared first on sa���ʴ�ý.

Unsurprisingly, even mild-mannered Scandinavians can be fiercely territorial when it comes to language. As a result, we now have four distinct written Scandinavian languages: Danish, Swedish, Norwegian bokmål and Norwegian nynorsk.

Yet, there is one thing that has the potential to overcome all cultural particularities in its single-minded drive to appeal to our wallets: commerce. Products to be sold in the Scandinavian countries need packaging, and they must have labels with lists of ingredients, information on calories and the exact level of they will produce. Printing separate labels for all the Nordic or Scandinavian markets would be rather expensive – this predicament has resulted in the concept of “Scandimix”.

Scandimix is a form of multi-language adaptation: a process where the final translation of a source text is a combination of two or more languages. For us at Sandberg, the usual combination is Danish/Norwegian/Swedish – and mostly in that order.

Here’s an example of Scandimix from a recent job:

Source: Gently shampoo and condition.

Translation: Vask håret nænsomt/forsiktig med shampoo efterfulgt af/av balsam.

The Danish translator has produced the first text (in green here), and the Norwegian translator has added any terms that the Norwegian audience might need to decipher the text (in orange��here).

From the Norwegian translator’s point of view, it can be both an advantage and a risk that Danish and Norwegian often use the same words for the same things. An advantage in that very little input may be needed. A risk in that there may be many false friends (the same words, but referring to different things).

There is also the dilemma of the many words that are the same, but spelt differently. At the Stockholm meeting Ibsen attended, one resolution was to start spelling words more like how they are sounded. In Norway, that policy led to various spelling reforms, so that the word that in Danish is written brug (“use”) is now spelt bruk in Norwegian, reflecting the harder sound at the end of the word.

If the word is essentially the same, would the Norwegian reader not still understand the Danish? The Danish word tjek (“check”) is pronounced similarly to the Norwegian sjekk (“check”), but the two spellings are so different that a consumer might well be thrown by only having one of them on their bottle of volumising leave-in lotion.

The Swedes like to be different. In most cases of Scandimix, it is Swedish that introduces the different word for the same thing, albeit often with a spelling closer to Norwegian:

Source: Do not use heat sources.

Translation: Brug/bruk ikke varmekilder/Använd inte värmekällor.

Danish and Norwegian use same words, but cannot agree on the spelling of one of them. Swedish (in pink��here) uses a different word for “use”, “not” and “heat sources” – in other words, the entire sentence has to be added in Swedish, too.

Another consideration is word order. Sometimes Danish syntax is so different from Norwegian or Swedish that just shoving in Norwegian or Swedish words as alternatives could seem random and make the sentence less, not more understandable.

Source: A preliminary test according to accompanying directions should be made before use.

Translation: Inden brug bør der laves en prøve ifølge den vedlagte vejledning/en forhåndstest i henhold til instruksjonene bør gjøres før bruk.

The problem here is both different vocabulary and words that are spelt differently. The translator gave up on trying to make the Norwegian fit in with the Danish and just added the whole sentence after it. The Swedish translator simply decided that, between them, the Danish and the Norwegian made enough sense for the Swedish market and added nothing.

In addition to the linguistic considerations, the Project Managers of a Scandimix project have some practical issues to solve. A Scandil, Nordil, Scandinavian or Nordic job – by any other word a Scanmix text smells as sweet – can be as fun to manage as it is challenging.

On the one hand it is fascinating to see that small tweaks can make a text mutually intelligible across three different nations, and make a product label accessible to all consumers in Norway, Sweden and Denmark. In this way, it is an extremely useful, efficient and unique workflow.

On the other hand, the Scandimix project introduces an unusual scheduling problem. The text needs to be done in the order Danish > Norwegian > Swedish. This means that the translators cannot work simultaneously in their respective languages.

Timing is everything: a slight delay to one linguist’s workload can mean that the whole project is late. The Norwegian or the Swedish language adaptation may need to be placed with someone else if a time slot is missed.

Delays are harder to avoid with Scandimix. The client may not be prepared for this: a shampoo bottle label is hardly an essay. But when up to six linguists are going to be looking at the same document one after another (especially if a revision step is included), a Scandimix project can easily take two or three days from start to finish. Add on to this feedback or updates from the client after the initial delivery, and another handful of words must again be scheduled in for 3–6 people.

For PMs and linguists, Scandimix projects require a different approach from the usual (source language is translated into a target language). If you happen to be learning one or all of the Scandinavian languages, the final multilingual label is always an interesting read (despite the mundane subject matter), as it gives you a little glimpse into how these languages are similar but different, together but apart, just as the peoples who speak them.

Scandimix adaptations are a microcosm of Scandinavia on a bottle of lavender-scented liquid handwash.

This article was written by Project Coordinator Daniel Field, Danish Account Linguist Didde Gaardsted and��Senior Norwegian Translator William Hagerup.

The post Scandimix: a language continuum on a label appeared first on sa���ʴ�ý.

The Nordic Languages

To understand the very basics of the Nordic languages, we first need to make an important linguistic distinction. On the one hand, we have the North Germanic languages, which include Norwegian, Swedish, Danish, Icelandic and Faroese. On the other hand, we have the rest of the Nordic languages: Finnish, Greenlandic and the ����� languages.

The Scandinavian Languages

The North Germanic Languages, especially Norwegian, Swedish and Danish, are also known as the Scandinavian languages (they are related to German and English). Around 20��million people use these languages in their everyday lives. They are part of the Indo-European language family (like the majority of European languages) and share numerous linguistic features that help many people understand each other and bring cultural unity to the region.

Many linguists agree that Danish, Norwegian and Swedish function as a Scandinavian dialect continuum because the languages (and their different dialects) are so similar and mutually intelligible to a great extent. However, each of them has numerous characteristics making them unique and complex. Here are a few:

1 – Danish and Norwegian share a lot of vocabulary and grammar features that standard Swedish doesn’t have. Norwegian speakers are the best at understanding Swedish and Danish, but the Swedish are not that good at deciphering Danish in general.

2 – Even if the various Swedish, Danish and Norwegian dialects are not always mutually intelligible in their spoken forms, these languages are rather similar when written.

3 – Danish also has plenty of dialects, but they are usually not present in the written form.

4 – Norwegian has two distinct written forms: Bokmål (“book language”), which is more influenced by standard Danish, and Nynorsk (“new Norwegian”), which is based on several rural dialects spoken in western Norway. Both are official and widely used, but neither is widely spoken, as Norwegians speak in their own dialect – even the Prime Minister.

The rest of the Nordic Languages

Icelandic��is a North Germanic language, and because Iceland was isolated from Scandinavia for a very long time, Icelandic remained, in many ways, closest to the dialects spoken in Scandinavia in the Middle Ages. But even if there are similarities, Icelandic is not commonly understood by people from Scandinavia.

Faroese is also a North Germanic language spoken by people mainly in the Faroe Islands, but also a small minority in Denmark. Faroese and Icelandic are close relatives but are not mutually intelligible in speech. However, the written forms of the languages are quite similar, largely owing to Faroese’s etymological orthography.

Finnish is completely unrelated to the Scandinavian languages, which are Germanic while Finnish is Uralic (or, more precisely, Finno-Ugric) like Estonian and Hungarian. Finnish is an agglutinative language, which means that one word may contain one or several units that carry meaning (morphemes) in addition to the root – this can make for long words! While Finnish is not part of the same language family as most European languages, it does have a large number of Indo-European loan words from centuries of close contact with these languages.

Greenlandic belongs to the Inuit branch of Eskimo-Aleut languages. It is a polysynthetic language, meaning that words are made up of a root and one or more suffixes. For this reason, Greenlandic words can be extremely long and can mean what corresponds to a whole sentence in other languages.

����� languages are indigenous languages spoken in the north of the Nordic Region, in Norway, Sweden and Finland (as well as in Russia). Even though many of the different ����� languages have official status in the Nordic countries where they are spoken, their speakers also typically speak the official language of the country. This is the reason why, unless specifically targeting ����� people, ����� languages are rarely used for commercial purposes.

Localising into Nordic Languages

Business-savvy executives know that breaking into a new market involves having to assess your marketing material and deciding how to best use it. Since the Nordic countries enjoy a high level of education and many people speak good English, it is often assumed that Nordic people are comfortable with making purchasing decisions in a foreign language. This is not the case. Like all people, they feel more confident using their mother tongue. If you want to make buying easy for Nordic people, you will present your information in their language. If you want to impress them, you localise your content into their way of thinking. In order to be heard on the global arena, these small nations spare no effort in constantly translating their own message to the world. They will appreciate you returning the favour.

When it comes to localisation into the Nordic languages, the service – like all services coming from the Nordic countries – tends to be a premium one. If this seems plush, remember that you are aiming at reaching a high-end target audience. Boasting the highest literacy levels in the world, Nordic people know what good language looks like. As in many other countries, translators up North have university qualifications – usually master’s degrees – and the pool of expert translators is smaller than in world languages. Localisation into the Nordic languages will cost more, so make sure you choose a reputable translation and localisation partner who brings you a ROI worthy of these flourishing economies.

sa���ʴ�ý

With over 20 years of experience in the Nordic-speaking market, STP is a world-class translation and localisation company specialising in the Nordic languages and English. With the use of CAT technology that creates translation memories and by making optimal use of terminology databases, STP ensures quality, consistency and optimisation in each localisation project. Its unique asset, a vast pool of talented language specialists and project managers, provides a professional service in all industry verticals and domains.

Talk to us about your next project!

The post Localisation insights: the Nordic market appeared first on sa���ʴ�ý.