How to Approach Software Translation in the Right Way

The Difference Between Translation and Localisation

Localising software or apps for mobile devices is no easy feat.

Unlike technical translation, localisation involves a combination of both technical and linguistic elements: strings of text aimed at users are mixed with strings of programming code meant for the machine only.

To avoid introducing bugs and compromising technical functions it is crucial to be able to recognise these and translate only “pure” text when translating.

This then leads to questions about how usable the localised product actually is:

• Is the interface accessible?
• Are special characters being displayed properly?
• Do the translated texts fit in the space available?

On the project management side, you also need to consider the documentation that comes with the software: user manuals, online guides, any brochures, and advertising material. All these translations must be consistent with one another and with the software in use, as well as in line with the market release time imposed by the company.

Localisation is therefore a high-tech type of translation that presents a range of different challenges, which need to be managed by highly-specialised professionals from multiple sectors: translators, localisers, project managers, software engineers and testers. But what is really meant by “localisation”?

The GILT paradigm

In the eighties, IT multinationals saw translation and adaptation to a foreign language as a process in itself, separate from both product planning and ongoing processes for other languages.

This led to terminological differences, technical issues, time-to-market delays, and extra costs for structural changes. In the nineties, with technological development and the exponential increase in demand for content localisation, a broader process was devised that included all the phases of commercialising tech products on foreign markets. The Localisation Industry Standards Association (LISA) was one of the first to talk about the proposed GILT paradigm, which stands for Globalisation, Internationalisation, Localisation, Translation.

Globalisation

What is meant by globalisation is a company’s intent to expand onto foreign markets and sell its products and services on both a local and global scale. In this first phase, all efforts are focussed on planning promotional activities and a support system for sales in countries of interest; this involves the company’s CEO and marketing department.

Internationalisation

Next comes internationalisation), the development of a digital product that is to be adapted to multiple markets without too many technical or linguistic changes being made. All the measures adopted in this preparation phase are designed to make the localisation process faster, sleeker, and cheaper.

For example, even though the product’s source language is almost always going to be English, you cannot use a set of 128 characters. It cannot represent the accented letters of the Romance languages, nor can it handle alphabets other than Latin. If you do not use an extended system (like Unicode) from the start, you risk having to rewrite the code from scratch, which is costly and slows down product release.

The software interface must be designed to tolerate a text increase of at least 30% because translations into a Romance language or one that uses ideograms, such as Chinese and Japanese, take up more space than English texts. In terms of graphics, it is best to use universally recognised icons and symbols, while linguistically speaking, a monolingual glossary must be drawn up to be used as a reference for the translation process that will follow.

Localisation

Localisation means adapting the product to the language, culture, and expectations of a given market in order for it to be perceived as authentic.

Technical parameters such as date and time expression, currency, units of measurement (temperature, weight, length, etc.), keyboard, writing direction and address format, telephone numbers, icons, colours, images, and cultural references must all be adapted.

If users do not see the conventions they are used to on the display, the user experience is much less intuitive; if button and image positioning are not adapted for languages with a different writing direction, like Arabic, navigating in those languages will be difficult. In some cases, failure to adapt to local culture can even be offensive: Consider, for example, how women are represented in some conservative Muslim cultures, or the effect of mentioning delicate geopolitical events in impacted areas.

Simply put, at this stage, adjustments must be made to ensure the localised product’s technical and cultural equivalence to the original.

Translation

Translation here means the linguistic transformation of the software’s text from one language to another, and accounts for just one third of the project’s budget. Users need to be able to access correctly translated content, but it is project management and the necessary structural changes that lead to issues and increased costs.

The phases of the localisation process

Analysis

In the first phase, the localisation kit provided by the client must be analysed, as it contains the executable files (in .exe, .com, .dll, .bat, .drv, or .bin format), the software programming environment, glossaries, previous translation memories, and any notes and guidelines.

The choice of localisation environment most often depends on file format.

The ideal situation is when files contain both the programme code and the text strings, as the broader linguistic context facilitates translation; to avoid accidentally translating code, you need a specific localisation platform that “blocks” it.

If, on the other hand, only one text file is provided, any assisted translation tool can be used, as they will still allow for terminological and style consistency (if there are translations of previous versions of the software).

Finally, the client can make various kinds of observations in the translation notes. For example, they may specify that certain sequences of characters or commercial names of products should not be translated, ask for a translation into Latin-American Spanish instead of European Spanish, or point out critical issues in a project.

Text translation

The next phase is translating the software’s text content. Usually, the elements that make up the graphical interface are translated first: dialogue boxes, menus and strings, then online support and user manuals, so there is time to create any videos that need to be included in the translated documentation.

More frequently, however, work volume and time-to-market lead localisation teams to work on resources simultaneously. Internal consistency is guaranteed by recycling texts that have already been translated and sharing glossaries and translation memories.

Quality control

Quality control is measured by revising the translation and testing the product on three levels:

1. linguistic testing
2. GUI testing
3. functional testing

The linguistic test checks terminological and style consistency, correct text display in terms of spacing and characters, and that all strings have been translated. When testing the graphical user interface, the localised version is checked to make sure it is aesthetically pleasing. The functional test ensures that the software has the same functionality as the original and is compatible with all the hardware devices (processor, graphics card and sound) it was designed for. These tests are crucial because poor localisation can seal the commercial fate of a product, with considerable damage to profit and public image.

Change report

At the end of a project, localisation teams are often asked to draw up a change report, an account of problems that have arisen during a phase of the project where time and cost issues have meant making changes becomes difficult. The information collected is used in the localisation of later software versions to optimise the various stages of the process.

Technical aspects of software localisation

A software programme has two levels of text:

1. Strings visible to the user and
2. Strings of programming code needed for the mechanism to function properly.

Localisation environments, i.e. programmes used to translate and adapt software, usually allow graphically these strings to be graphically highlighted in a way that blocks the code and leaves the translator free to focus on the text itself. In some cases, however, there are expressions or combinations that require a special approach.

In sequences of special and variable characters, symbols like the percentage (%) or dollar sign ($) inform the mechanism to interpret what follows as non-literal. The variables, which are also called placeholders and usually indicated with letters of the alphabet, represent an element that the software occasionally replaces with an appropriate value: an adjective, a file name, a numeric value, a loading percentage, and many more. Some standardised combinations are:

• %s for a string of text
• %d for a decimal number
• %x for a hexadecimal number
• %g for a floating-point number
• %u for a Unicode character
• %p for a page number

When translating from English, the grammatical and semantic implications of a missing word on the rest of the sentence must be taken into account.

There are four possible combinations when it comes to adjectives (masculine or feminine, singular or plural), two in the case of digits; both cases require the preceding article and following verb to be modified. You may also need to change the word order: in English, the adjective precedes the noun it refers to, but the opposite is true in many languages. In these cases, translators must rely on the linguistic context in order to understand what is being referred to. The client must in turn highlight special characters in the software, and the main values associated with the variables (at least grammatical number and category), so as to avoid having to make big corrections in the following phase.

In some cases you will find untranslatable text, i.e. terms that are actually internal software commands or file names. Of course, translating them would mean introducing bugs or creating links to non-existent files, so it is essential to identify which these are.

These range from strings like [x] or $x$, where x indicates the name of a file with its extension ($INPUT_List.csv$), to words written in capital letters (COPY, EDIT) and/or with underscores (TIME_OUT; NO_MORE_ENTRIES).

One of the trickiest problems in localisation is the presence of isolated, out-of-context terms.

The translator must rely on the surrounding text and - if the executable file has been provided - on the relevant programming code, which can give valuable information about the nature of the term.

Another way to clear up doubts is to take a look at the software’s graphical interface, but that is not always possible. If only the text is file available, refer to the user manual, online support or, as a last resort, ask the client to clarify.

The ambiguity of isolated terms depends on the English-language convention of expressing multiple grammatical categories and values with the same graphic form. For example, in software the term “copy” can mean both a noun and a verb, used in the infinitive or imperative forms. The position within the GUI may give away the correct meaning (when in a drop-down menu, it’s probably a command), but it is still a problem that is not to be underestimated.

Text strings are inserted in dialogue boxes, drop-down menus and error messages. Broadly speaking, the capacity of these sections is limited. This constitutes a problem when localising from English to other languages, which usually brings with it an increase in length of between 30% and over 200% for names of commands and icons. If the additional space is not calculated during the internationalisation phase, the translator, in some cases, will have to resort to synonyms, and anglicisms in order to comply with the graphical space limits.

It is essential, however, to keep terminological choices consistent (and therefore to include them in the project glossary), to use expressions that the user will understand, and leave out lesser-known loanwords or obscure acronyms.

Some localisation platforms allow you to generate a preview of the interface where translations can be inserted in real time, so you can see the available space. If you only have the text file and not the executable file, you can use the software documentation to help you, with the hope that the user manual will contain a screenshot of the relevant section.

In localisation, it is essential to adapt the locale, the set of technical parameters used to represent the reality of a geographic, cultural, and linguistic community. The ISO 639-1 standard on language classification identifies each locale with a two-letter code. There are two for Italian, one for Italy (it-IT) and one for Switzerland (it-CH), while languages such as English, Spanish and Arabic have a greater repertoire due to the large number of countries in which they are official languages. Language and locale are not synonymous here, as cultural conventions come into play. The most important of these are:

• the value and position of graphic symbols: while English places the currency symbol first, as in £10, $10 and €10, most other languages will place it after: 10€;
• how the date is written: the order of elements varies regionally (month-day-year in the USA, day-month-year in Europe, year-month-day in some Asian countries), as does the graphical use of bars (/), dashes (-) or points;
• how the time is written: though the 24-hour time system is prevalent through much of the world, the US uses a 12-hour time system;
• units of measurement: the kilos, metres, and degrees Celsius used by the Metric System become pounds, feet and degrees Fahrenheit in the British Isles and North America (with some conceptual differences between the United kingdom and the USA);
• how numbers are represented: thousands, hundreds, and decimals can be indicated with a point (above or below), a comma, or a space the same percentage may be written as 1.5 or 1,5%
• how addresses, postcodes, and phone codes are displayed.

Adapting these parameters gives the user the feeling of interacting with a product designed for their own needs, and avoids potential misunderstanding. Otherwise, the user experience deteriorates, and some features may even become inaccessible. If a piece of software does not provide the postcodes or telephone prefixes for a certain zone, the user may not be able to create an account; if amounts are not converted into localised values, it will be impossible to make purchases. Taking care of your locale therefore means respecting the speakers’ expectations and allowing them to access the same level of functionality as the original.

Cultural and linguistic aspects

The cultural component is a minor one in software design, since it is designed for practical use, like protecting a device from viruses, managing passwords or producing documents. However, the inclusion of certain features can be a reflection of a certain type of culture. In product internationalisation, you need to be aware of these differences, or run the risk of being rejected by the target market because the product cannot be assimilated into the local culture.

The translator is not, strictly speaking, responsible for these aspects. However, the more a digital product imitates human interaction, the more linguistic and cultural adaptations need to be made.

Industrial production software is used to perform actions and operate machinery. The interface asks the user questions (such as “Are you sure you want to restart?"), but the pragmatic component takes a back seat.

On the contrary, banking apps follow client-employee interaction on sensitive operations such as account management and service subscription: the user wants to feel “reassured” by the text and see familiar linguistic conventions. The translator must therefore respect the formal language used in the client’s culture.

For example, compared to other languages, English makes great use of expressions like please and would you like to + verb, which are often changed or even omitted in other European languages, by changing between indicative and subjunctive moods, as in Spanish and Italian. Similarly, the more informal register used in English may need to be raised for an Italian user. The order of components in a sentence is something else to explore entirely.

In English, there is a tendency to present more specific information first and generic information later, while in Italian, the information order is the opposite. Moreover, Italian is not bound to the same rigid subject-verb-object order as English - quite the opposite - it often needs to be modified to create more fluid and natural sentences.

Translating too literally from English can lead to odd expressions in Italian that sound forced and unnatural when not simply incorrect. Ultimately, it is important not to forget that in the case of text excerpts aimed at marketing, the text may need to be partially rewritten to assimilate to the sensibilities of the new audience, using what is called transcreation.