App translation: It all starts with great code

App translation 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 app code that is fit for localisation. In this article, 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 users.

 

1) The problem: Lack of context

If you are localising an app for the first time and you’re not already using a sophisticated TMS (translation management system), chances are you will be sending your app strings to your translation partner in a file such as a json file, or even simply in a Google Sheet. This means that translators won’t be able to see where in the user interface a particular string will appear. Context is really important for translators, as often a single string can be translated in a number of ways.

 

Ambiguous words

Taken out of context, words can be ambiguous. For example, if a translator is presented with the string Home, does that refer to someone’s home, or the home page of the app? Innocuous words like Oldest and Newest might be translated in different ways, depending on whether they refer to a person or an object like a file or an article.

 

 

Working with variables

It’s likely that your app code will contain 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 for 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}
	Der ausgewählte {1}
	Das ausgewählte {1}

The selected {1} … what does that mean? What is the context and what word will replace the variable? In German, for example, nouns are gendered 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

 

Clarify ambiguous words

There are a number of ways to provide context for the linguists tasked with the translation of your app. If you are sending across an Excel file or Google Sheet, you could simply add an additional column with explanatory notes that will give the translators the much-needed context to provide a great translation:

String	Type	Notes
Home	Menu item	Refers to the home screen
Apply	CTA	Call-to-action to apply the selected filter to an image

And even better, you could add in-app screenshots to ambiguous strings so that the translators can see exactly where the string sits in the app.

If you are working with a sophisticated TMS to translate your app, you should be able to upload screenshots and comments at string level.

 

Clarify what variables stand for

If you are using numbers as the naming convention for your variables, this will make it tricky for translators to know what these variables relate to. So, the easiest thing to do is to add a comment explaining what the variable stands for:

English string	German string	Comment
The selected {1}	Die ausgewählte {1}	{1} = file, noun

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

English string	German string	Comment
The selected {1}	Die/der ausgewählte {1}	{1} = file or folder, noun

Careful though with creating strings that could be used with different kinds of variables: If the variables refer to nouns that might have different genders in other languages, it creates clunky translations since the translators need to include all possible options. In the example above, the German word for file is female (die Datei), while the German word for folder is male (der Ordner). To account for both scenarios in the same string looks messy, increases the length of the translation and reduces readability (see also section 3 below).

Naming your variables in a way that translators can understand is another way to provide context. So instead of using numbers for your variable like {1} and {2}, you could could name them {$file} and {$folder}.

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.

Providing your translation team with as much context as possible, right down to the string level, will save you time, because you will have to answer a lot less questions during the translation process, and 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.

Example 1

Linguistic unit	Presented string	German translation
{1}'s file	String 1: {1}	Die Datei von {1}
	String 2: 's file

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.

Example 2

Linguistic unit	Presented string	German translation
{1}’s file was downloaded by {2}	String 1: {1}	Option 1: Die Datei von {1} wurde von {2} heruntergeladen. Option 2: {2} lud die Datei von {1} herunter.
	String 2: 's file was downloaded by
	String 3: {2}

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. This will allow the translators to follow the right grammatical order in their language and reorder the sequence in which the variables appear in the translation if necessary.

 

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 string	German string
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 that includes both genders 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 so you can then produce phrases like I ran, you ran and they ran, it 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 issue, 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.

Note: Since we’re referring to a person’s gender here, this solution still poses some issues around the use of inclusive language (see more information at the end of the article). The neutral translation here is not an inclusive translation in the sense that it is binary – it either refers to a male or a female friend, but doesn’t include people who identify as non-binary.

 

Final notes on best practices for app translation

Text expansion

Getting your app code fit for localisation is just one consideration. Another is ensuring that the localised versions of your app will look great on screen. When translating out of English, there will be a certain amount of text expansion, meaning that the translated text will be longer than the English original. Did you know, for example, that German translations can be 25 to 30% longer than English? Just take the English Add (three characters), which translates into Hinzufügen in German (ten characters).

Since space is generally in short supply in app user interfaces, it’s important to think about this text expansion. This might mean ensuring that content elements can expand rather than being set to a fixed width, as well as leaving enough whitespace to ensure the translations don’t look too crammed on the screen.

Inclusive language

Finally, the use of inclusive language is becoming increasingly important. This poses particular challenges when translating from a non-gendered language like English into a gendered language like German. Before you delve into the actual project of translating your app, it’s important to understand the complexities around using inclusive language. If you’d like to read up on this topic, check out our articles on the differences between Germanic and Romance languages, and how to translate inclusively into German and French.

If you would like to talk in more detail about best practices around app translation, get in touch here or simply book a discovery call for an informal chat.