Localise GUI and User Information in Perfect Harmony

Three scenarios for the translation of Graphical User Interfaces.

Localise GUI and User Information in Perfect Harmony

My colleague, Jörg Sannemann, recently blogged about GUIs and user information. And this is exactly where I would like to chime-in on this subject. He writes, "But there are other kinds of glasses that are not set directly on the nose, but rather are secured to our heads." One of these pairs of glasses are those of translation, and especially those of the user abroad. And it's precisely these glasses that I often have to take off, and first rub my eyes or just chew on my glasses' temples and think about whether user information should be localised in the foreign language, in accordance with the existing user interface.

The following three scenarios from my everyday life immediately come to mind:

Scenario 1 (the rubbing of the eyes):

We receive a translation request for a document in which the text of the software interface (also referred to as "GUI text") is displayed as a screenshot in the source language and isn't available or provided in any foreign language. So what should be done if these exact messages also appear in the translatable text of the actual manual?

It's always best to first try to put yourself in the position of the operator or user in the local country and ask yourself two questions:

  1. What's the likelihood that I understand the source language of the software interface?
  2. How high is the potential for misuse if I don't understand the software interface?

Our ultimate goal is to always create a translation for our end-users that he or she can easily put the translated instructions and content into practice (for example, when maintaining a machine).

In consultation with the client, I always recommend in such a case to freely (i.e. descriptively) translate the screens available in the continuous text and to descriptively write the source language name of the respective GUI element in parentheses immediately following it. While this doesn't look very elegant, it still serves the purpose from the user's point of view: the translated information remains unambiguous, and the end-user knows what the respective GUI element means and which "button" he or she must press, without having to guess.

Scenario 2 (the chewing on the glasses' temples):

We receive a translation request for a German document in which the GUI text is available in the source language (German) and in only one other language; mostly English (via a screenshot). However, the requested translation should be into another language – Spanish, for example. 

In addition to the same considerations as with Scenario 1, in this case, I would also analyse which of the two GUI languages covers the larger "linguistic territory"; for example, how likely is it that the Spanish operator speaks either German or English?

I would request an export of the GUI elements, usually in the form of either a .CSV or .XLSX file, from the client. I can then make this list of GUI texts from the German and English screens available to the translator with the permission to freely translate the screen texts into Spanish and (as in Scenario 1 above) to indicate the respective English equivalents immediately following them in parentheses. Thus, a clear distinction between software interface and user information is made here.

Scenario 3 (the blurry glasses):

We receive a translation request for a document in which the GUI elements are copied into the source language via a screenshot. As a Language Service Provider (LSP), we first receive the order to localise the software interface and then to translate the document (e.g. an operator manual). The difficulty lies in the fact that the number of characters displayed within the interface is limited and that expansion of possible foreign languages wasn’t considered when the software interface was developed.

An example of how Source-to-Target languages can expand:

Language: ENG – GUI-Text: ON/OFF – Number of Characters: 6

Language: DEU – GUI-Text: EIN/AUS – Number of Characters: 7

Language: FRA – GUI-Text: DEMARRER/ARRETER – Number of Characters: 16

In this case, I would recommend the translation of the GUI texts first without length limitation. The resulting list can then be used with the terms for the translation of the operating manual. Then, the GUI texts can be shortened, to allow for a smooth import into the software interface for the target language. If the text "expansion" (resulting from the translation) is not considered during the creation of the software interface, there will be the danger that the translator will sometimes be restricted from shortening the GUI texts logically, whereby the meaning of the text may be lost. However, there is no length limitation for the instructions, so the translated GUI text can be written out; if you want to be sure, the shortened (on-screen) form can be placed in parentheses immediately following it. Thus, the user of the manual will always know what is behind an abbreviated GUI text and what it means.

Our conclusion is:

When planning and developing your software interfaces, please don't forget the foreign languages and especially their expansion, in relation to the source language. This is the only way that users in foreign markets will be able to operate their machines both quickly and easily.

Mitja Sternkopf
Blog post Mitja Sternkopf
Newsletter Abonnieren

Subscribe to Newsletter

Subscribe to our kothes newsletter and you will receive regular e-mails on current topics, events and seminars.