Successful app translation: It all starts with great code

Translating your app is a great way of reaching more users and increasing revenue. But in order to create beautiful language versions of your app, you need more than just a reliable translation partner, you need code that is fit for localisation. In this blog post, we want to highlight the three most common issues that we come across in app translation and show how writing great code can help save time, speed up the translation process and ultimately improve the user experience for your international customers.

1) The Problem: Lack of context

If you are writing app code, chances are you will be using variables or placeholders for any content that is dynamic, such as user names, prices, product names, social media names, etc. And here is the question our translators ask time and time again during the translation of apps: ‘What does the variable/placeholder stand for?’

The number one rule in presenting code for localisation is to provide as much context as you possibly can for each string and especially variables. Without knowing what a variable stands for, the string surrounding it can often not be properly translated.

Here is a typical example:

English string	German string
The selected {1}	Die ausgewählte {1} Das ausgewählte {1} Der ausgewählte {1}

The selected {1} … what does that mean? What is the context and what word will replace the variable? German nouns have ‘gender’ so the simple English ‘the’ can be translated as ‘der’, ‘die’ or ‘das’ into German, depending on the gender of the noun:

English string	German string
The selected file	Die ausgewählte Datei
The selected folder	Der ausgewählte Ordner
The selected directory	Das ausgewählte Verzeichnis

Whenever a variable is preceded by an article (the, a, this, etc), an adjective (selected, deleted, saved, etc) or a preposition (on, at, by, etc), chances are that the translators will need to know what the variable stands for in order to provide a correct translation.

The solution:  Providing context at string level

There are a number of ways to provide context for translators. If you are using a simple file with a source and target column, add a third column that lists all the variables and explains what they stand for.

English	German	Comment
The selected {1}	Die ausgewählte Datei	{1} = file

Could the variable be a number of different things? Let the translators know:

English	German	Comment
The selected {1}	Die/der ausgewählte {1}	{1} = could be file or folder

Naming your variables in a way that translators can understand is another way to provide context:

The selected {1}

The selected {$file}

Different coding languages will require different naming conventions, but if you have the opportunity to provide more info within your variable name, that’s a bonus.

Finally, one of the most efficient ways to provide context at string level is to use a translation management tool like Smartling. Smartling allows you to add context at string-level right within the platform so that the translator can see it above the translation. Even more importantly, you can upload screenshots alongside the string, so the translator can see where the string will sit within the app. If the translator still needs more info, they can ask a question at string level, again right within the platform. And you can answer right within the platform, too.

Providing your translation team with as much context as possible, right down to the string level, will save you time, (a) because you will have to answer a lot less questions during the translation process, and (b) because you will have fewer context errors to fix during QA.

2) The problem: Separating linguistic units across several strings

Presenting sentences for translation that have been separated across several strings, or variables that have been separated from the rest of their linguistic unit tends to cause translators a big headache. Due to the different word order and sentence structure in other languages, it’s often not possible to provide a grammatically correct, or well-formed sentence if the source has been separated across several strings. Here are some fairly typical examples we come across:

Linguistic unit	Presented strings	German translation
{1}’s file	String 1: {1} String  2: ‘s file	Die Datei von {1}

Most languages outside of English do not have the possessive ’s structure, so the word order of the sentence tends to be different from English. In the example above, the variable actually appears at the end of the sentence in German.

Linguistic unit	Presented strings	German translation
{1}’s file was downloaded by {2}	String 1: {1} String 2: ’s file was downloaded by String 3: {2}	Die Datei von {1} wurde von {2} heruntergeladen.Back translation: The file of {1} was from {2} downloaded. Or with a changed sentence structure:{2} lud die Datei von {1} herunter.Back translation: {2} loaded the file from {1} down.

Here again, the word order is different in German. Presenting this linguistic unit as three separate strings will likely result in some grammatically awkward constructions in other languages, if a translation is even possible at all. If you’re going through the trouble of localising your app into another language, you want it to sound as native and natural as possible.

The solution: Provide whole strings

The best way to ensure a beautiful translation is to present the entire linguistic unit within one string. A linguistic unit can be something really short like ‘{1}’s’ or a whole sentence.

But what about if you simply have to separate out linguistic units to allow for formatting, links, etc?  Here is where a translation management system like Smartling comes into play. Smartling will present whole linguistic units to the translators, but they are broken down into individual segments. The translators can re-order these segments so that they can create a grammatically correct translation while keeping all the formatting intact. They can even add an additional segment for the translation if their language requires it.

3) The problem: Too many options

Finally, we often come across strings that could be translated in a number of different ways depending on the context.

Nouns:

Coming back to the topic of gender in nouns, check out this example:

English	German
Your friend {1} has accepted your invite.	Friend is female: Deine Freundin {1} hat deine Einladung akzeptiert.Friend is male: Dein Freund {1} hat deine Einladung akzeptiert.Neutral translation: Dein/e Freund/in {1} hat deine Einladung akzeptiert.

 As you can see, the only way to provide a neutral translation is to use slashes to include both options, which tends to make the translation longer and harder to read for the user.

Verbs:

Verbs are translated differently depending on whether the subject is singular or plural, or which person it refers to. Here is a simple example:

English	German
I ran	Ich rannte
You ran	Du ranntest
He/She ran	Er/Sie rannte
We ran	Wir rannten
You ran	Ihr ranntet
They ran	Sie rannten

If you present the verb ‘ran’ as one global separate string to then produce phrases like ‘I ran’, ‘you ran’ and ‘they ran’ this won’t work, because as you can see in the example above, the translation will be different for each ‘scenario’.

The solution: Create separate strings for each scenario

The best way to get around this, is to present each scenario separately to the translator. For example:

English	German
Your friend {1} has accepted your invite. Context: friend = female	Deine Freundin {1} hat deine Einladung akzeptiert
Your friend {1} has accepted your invite. Context: friend = male	Dein Freund {1} hat deine Einladung akzeptiert
Your friend {1} has accepted your invite. Context: friend = gender not known	Dein/e Freund/in {1} hat deine Einladung akzeptiert.

If you would like to talk in more detail about best practices for code that is fit for localisation, or if you’d like to find out more about Smartling as a translation management tool for your app translation, please get in touch.

---

Image credit: Photo by KOBU Agency on Unsplash