Technical aspects of localisation

Since localisation typically refers to the translation of software and their related documents, the files which translators end up working with are often source code files created in the programming process. Apart from the texts that need to be translated, these files also contain the codes needed for the software to function.

This is needed to allow the target language texts to be placed back into their original places in as few steps and in as short a time as possible.

These files need to be prepared in a way that does not damage the software code and allows for the translatable parts to be accessible to the translator. This task in particular is carried out by language engineers, who are professionals well-versed in both programming and the world of languages, meaning that they have a good grasp of foreign languages and are also knowledgeable about the various language families and their characteristics. When the programme code is separated from the text itself, it is labelled as metadata, since compared with the information in the actual text displayed, the source code’s text does indeed count as metadata. This way, the code is separated from the text that needs to be localised and is also secured, because once it is separated, the translator can no longer access it, thus ensuring that the code cannot be damaged. Furthermore, the translator can access the data stored in the source code (such as the length of the text, or the programmer’s comments about the text) with the help of computer-assisted translation (CAT) tools (Figure 1).

Figure 1

Text to be localised complete with metadata and variables

4.1. Linguistic aspects

4.1.1. User interface

The linguistic challenges encountered during the localisation process depend greatly on the type of text that needs to be translated. The types of texts that need to be localised are usually ones that show up in the user interface of software or on websites. These are known as UI (user interface) elements, and are provided to the translator in the form of strings (Figures 2 and 3). In other words, instead of working with linear texts made up of a logical series of sentences, the translator must work with standalone pieces of text arranged randomly, meaning that a given string may not necessarily be related to the preceding or the following

one. This means that one of the biggest challenges in localising such texts is the lack of context (Pym 2004, 2005, Sandrini 2005). Take the word ‘Save’ for example.

This may refer to the act of storing data but it can also mean spending less money on something. Without any context, it is impossible to decide which meaning the word refers to. We encounter a similar problem with the preposition ‘From’.

Once again, depending on context, this word can be interpreted as referring to the sender of a message or a starting date. The metadata described above may contain some information about context, such as where the translated text will appear, but this is still not enough to ensure a completely accurate translation. Given that the lack or complete absence of context can make it impossible to translate the text, or at least increase the chance of errors, translators have several ways of obtaining the necessary information about the contexts of strings throughout the localisation process.

Figure 2

Strings, as seen by the translator

Figure 3

The same strings as seen on the webpage

In order to obtain this information, it is important that translators make a conscious effort to find it, that they possess the necessary localisation skills, recognise potential ‘linguistic traps’ and maintain contact and good relations with the owner of the content, the client.

Clients who have enough knowledge about the localisation process know about the difficulties that can arise, and make an effort to provide translators with materials that can clarify the contexts of strings. These materials can come in the form of comments pertaining to certain portions of the text, actual screenshots of

the original product or clients can provide help by answering translators’ questions along the way.

The lack of context is usually offset by a so-called in-context review, when the translator is given a preview of how the translated text will look as part of the final product, for instance on the website where it will appear. This is when translators get a chance to correct any linguistic or grammatical errors (such as restructuring pieces of texts that are supposed to be parts of a list but were not translated with a list in mind) or display errors (for example when the translated text is too long for the space available).

Other elements that can cause headaches when translating strings are the so-called variables or placeholders. These are also part of the programme code but are usually found within a single sentence (or segment). The reason why these codes are called variables is that they can and do store various types of texts when the translation is used, such as dates, product names or even parts of a sentence. It is important that the translator ensure that the variable remains completely secure within the segment but at the same time complies with all grammatical rules of the language. This can be especially difficult in languages in which an unknown variable could potentially have different genders. There are also times when the source language text demands that multiple variables be placed in a single target language sentence, constituting a serious logical challenge.

4.1.2. Localisation of software-related documents

Another category of texts that often require localisation are software-related documents and manuals, such as user manuals or troubleshooting guides. Absence or lack of context is not a problem when it comes to translating these texts, since the translator is presented with linear segments, causing far fewer headaches and needing less extra research. Overall, these types of texts take less time to translate.

At the same time, translation fees for these texts tend to be significantly lower than for UI elements. These documents, however, do have their own particularities and distinct characteristics that localisation teams must be aware of in order to successfully translate them.

A software user manual, for example, describes how a given programme is to be used, and often includes screenshots of the user interface. It is designed in a way that allows for users to follow along with the guide’s instructions on their own devices, so it is particularly important that the manual contains illustrations that are identical to what users see on their screens. When translating these kinds of texts, the localisation team is expected to incorporate UI elements into the

translated document (Figure 4) – provided they are available in the target language – exactly the same way they appear on the screen.

Figure 4

UI elements in the user manual

There are two ways to do this. The first is by carrying out the steps laid out in the manual on the actual software (if it is available) and making sure that the same wording is used in the manual as on the software UI. If the translator does not have access to the software itself, they can simply ask to receive screenshots from the content owner. Or, as a more convenient method, the translator can use a term base that includes, primarily, UI elements.

The use of term bases, translation memories and CAT tools in general is inevitable when it comes to localisation. The nature of the content within these texts means that repetitions are fairly common, which stems from the life cycle of software products.

Typically what happens is that when a given software product is first introduced in a foreign market, every single text and document accompanying it is translated and localised into the target language in a single phase. This first localisation process usually covers large pieces of text. After these texts are released, only the texts pertaining to any software updates need to be localised. Given that there are likely to be multiple updates to a certain software, these texts are much smaller in volume but are localised separately, each at the time of its release. This usually generates pricing and organisational problems since a localisation task is time consuming for both the project manager and the translators, even if the length of the text to be translated is not that significant. Maintaining linguistic consistency in the long run is also a challenge, but one that can be handled with the use of CAT tools and database management software.

4.1.3. Adaptation of marketing materials

Although they are completely different from software user manuals, the translation of marketing materials pertaining to software products also counts as localisation, because they deal with the same subject. It is important to note, however, that the translation of these texts requires a completely different approach and skillset than software localisation, and therefore the various types of texts are often assigned to different translation teams.

The key to adapting marketing materials is (for the most part) a sense of style, a good grasp of the cultures of both source and target language users, and a creative use of language. It is important that translators recognise the aims of the content’s producers so that they can adapt the material in a way that the translation takes into account the linguistic and cultural particularities of their target market. It is also important to be knowledgeable about the product itself as well as its positioning in order to accurately convey the producer’s message to the market. Maintaining contact with the producers is once again crucial, as it helps translators gradually pick up and learn the most important elements of the product’s communication strategy.