Skip to main content
Software Localisation Course 5

5. Sources of Problems in Localisation

When translating software, translators have to face new text forms which are different from the traditional forms of texts. For example, translatable text contained in software user interface differs from text in online help or printed manuals. This varied nature of texts in the localisation of software represents a challenge for translators, mainly because there are more possible sources of problems for translators in these types of text. However, translators can only be aware of the possible problems they may face; it is software engineers and developers' task to try to avoid these sources of problems or keep them under control.

A way of avoiding or controlling sources of problems is to first – before localising – to internationalise the software application. Internationalisation is the first step to ensure that the product is localisable and that it would be functional and accepted in international markets.

Many sources of problems for localisation when software is not internationalised have already been identified. Some of them follow:

Terminology: inconsistent use of terminology by software developers or technical writers (e.g. use of synonyms for the same process or concept)

Ambiguity: use of the same term for different processes or concepts in the same context (e.g. use of the same term for different operations in the software user interface)

Usage of local references: particularly when writing for an international audience – as it is mostly the case when writing texts for a software application –, examples provided should not contain local references. In this sense, locale-specific symbols should also be avoided.

Text in graphics: the fact that the text has to be translated would imply in this case that the graphics have to be edited, which can be a very time-consuming task.

Abbreviations: it is common to use abbreviations due to lack of space, but it is a problem if developers or writers do not use them consistently.

Space: especially in the case of software user interfaces, developers or writers have to keep in mind that, as a rule, the length of translated texts changes in comparison to the original texts. Therefore, it should be possible to resize elements (e.g. buttons), dialogue boxes should accept longer texts and/or in the program, memory should be reserved for longer error messages.

 

Non-separation of code and text: very often, translatable text is embedded in the program code. This represents a problem because when the application is updated all strings will have to be edited again and because there is a risk that translators mistakenly modify or delete code. It is also more difficult for translators to identify translatable text if this is mixed with programming code. In order to check that code and text are separated, developers and writers can use evaluation tools (e.g. developer tools, internationalization tools, localization tools, etc.)

Variables: when using variables in messages, developers and writers should take into consideration that target language grammar might require reordering of parameters. For example, the "%" in the message "% files last saved on % at % by %", may have to be placed somewhere else according to the correct word order in the target language. Also, the grammatical form (gender, number, case) of those elements which will substitute variables can be different, for example:

Date, time and number formats: developers and writers should also be aware that according to the target language or culture, conventions for date, time and number formats may be different. Therefore, their adaptation should be considered.

 

(Adapted from Esselink, 2000, and Ottmann, 2002)

Next