GUI und Nutzerinformationen im Einklang lokalisieren

Drei Szenarien zur Übersetzung von Graphical User Interfaces.

© cat027 / AdobeStock

© cat027 / AdobeStock

Mein Kollege Jörg Sannemann schrieb kürzlich einen Blog zum Thema GUI und Nutzerinformationen. Und genau hier möchte ich anschließen. Er schreibt: „Es gibt aber noch andere Brillen, die nicht direkt auf die Nase gesetzt werden, sondern eher in unseren Köpfen verankert sind.“ Eine davon ist die Brille der Übersetzung und vor allem die des Bedieners im Ausland. Und genau diese Brille muss ich oft abnehmen und mir erst einmal die Augen reiben oder am Bügel kauen, wenn Nutzerinformationen im Einklang mit dem vorhandenen User-Interface in der Fremdsprache lokalisiert werden sollen.

Folgende 3 Szenarien aus meinem Alltag fallen mir dabei sofort ein:

Szenario 1 (das Reiben der Augen):

Wir bekommen eine Übersetzungsanfrage für ein Dokument, in dem der Text der Softwareoberfläche (im Folgenden auch "GUI-Text") per Screenshot in der Ausgangssprache dargestellt und nicht in irgendeiner Fremdsprache vorhanden bzw. vorgesehen ist. Was ist also zu tun, wenn genau diese Meldungen auch im zu übersetzenden Fließtext der eigentlichen Anleitung auftauchen?

Am besten versucht man, sich zuerst immer in die Lage des Bedieners oder Anwenders im Ausland zu versetzen und sich dabei zwei Fragen zu stellen:

  1. Wie hoch ist die Wahrscheinlichkeit, dass ich die Ausgangssprache der Softwareoberfläche verstehe?
  2. Wie hoch ist das Potenzial, dass ich eine Fehlbedienung provoziere, wenn ich die Softwareoberfläche nicht verstehe?

Übergeordnetes Ziel ist es immer, für unseren Endnutzer eine Übersetzung zu erstellen, bei der er die übersetzten Handlungsanweisungen und Inhalte einfach in die Praxis umsetzen kann (zum Beispiel bei der Wartung einer Maschine).

In Absprache mit dem Auftraggeber empfehle ich in einem solchen Fall, die im Fließtext vorhandenen Screens frei zu übersetzen und die quellsprachige Benennung des jeweiligen GUI-Elements in Klammern dahinter zu schreiben. Das sieht zwar nicht sehr elegant aus, erfüllt aber den Zweck aus Sicht des Nutzers: Die übersetzte Information bleibt eindeutig und der Endnutzer weiß, was das jeweilige GUI-Element bedeutet und welches „Knöpfchen“ er drücken muss, und zwar ohne zu raten.

Szenario 2 (der zerkaute Brillenbügel):

Wir bekommen eine Übersetzungsanfrage für ein deutsches Dokument, in dem der GUI-Text per Screenshot in der Ausgangssprache Deutsch und nur in einer weiteren Sprache, meist Englisch, vorhanden sind. Die angefragte Übersetzung soll aber in eine andere Sprache – zum Beispiel ins Spanische – erfolgen. 

Neben denselben Überlegungen wie in Szenario 1 würde ich in diesem Fall zusätzlich analysieren, welche der beiden GUI-Sprachen den größeren Sprachraum abdeckt, also: Wie wahrscheinlich ist es, dass der spanische Bediener Deutsch oder Englisch spricht?

Ich würde einen Export der GUI-Elemente, meist in Form einer CSV- oder Excel-Datei, vom Auftraggeber anfordern. Diese Liste mit GUI-Texten aus den deutschen und englischen Screens kann ich dann dem Übersetzer zur Verfügung stellen mit der Bitte, die Bildschirmtexte ins Spanische frei zu übersetzen und (wie in Szenario 1) die jeweiligen englischen Entsprechungen dahinter in Klammern anzugeben. Somit ist auch hier eine eindeutige Zuordnung zwischen Softwareoberfläche und Nutzerinformation gegeben.

Szenario 3 (die unscharfe Brille):

Wir bekommen eine Übersetzungsanfrage für ein Dokument, in dem die GUI-Elemente per Screenshot in der Ausgangssprache einkopiert sind. Als Übersetzungsdienstleister erhält man nun zuerst den Auftrag, die Softwareoberfläche zu lokalisieren, um im Anschluss die Übersetzung des Dokuments (z. B. eine Bedienungsanleitung) zu erstellen. Die Schwierigkeit besteht darin, dass die Anzahl der in der Oberfläche dargestellten Zeichen begrenzt ist und bei der Erstellung der Softwareoberfläche eine Expansion durch mögliche Fremdsprachen nicht beachtet wurde.

Ein Beispiel, wie Sprachen expandieren können:

Sprache: ENG – GUI-Text: ON/OFF – Zeichenanzahl: 6

Sprache: DEU – GUI-Text: EIN/AUS – Zeichenanzahl: 7

Sprache: FRA – GUI-Text: DEMARRER/ARRETER – Zeichenanzahl: 16

In diesem Fall schlage ich vor, die GUI-Texte zunächst ohne Längenbegrenzung übersetzen zu lassen. Die dabei gewonnene Liste kann dann mit den ausgeschriebenen Benennungen für die Übersetzung der Bedienungsanleitung verwendet werden. Danach können die GUI-Texte für einen reibungslosen Import in die Softwareoberfläche und die dortige Darstellung auch abgekürzt werden. Wenn die Textexpansion durch die Übersetzung bei der Erstellung der Softwareoberfläche nicht berücksichtigt wird, besteht immer die Gefahr, dass der Übersetzer dazu gezwungen ist, die GUI-Texte teilweise nicht logisch abkürzen zu müssen, wobei der Sinn des Textes verloren gehen kann. In den Anleitungen gibt es jedoch keine Längenbegrenzung, daher kann der übersetzte GUI-Text ausgeschrieben werden; wenn man ganz sicher gehen will, kann die gekürzte (Bildschirm-)Form in Klammern dahinter gesetzt werden. Somit weiß der Nutzer der Anleitung immer, wenn er den Knopf betätigt, was sich hinter einem abgekürzten GUI-Text verbirgt und was er bedeutet.

Unser Fazit an dieser Stelle ist:

Bitte vergessen Sie bei der Planung und der Entwicklung Ihrer Softwareoberflächen nicht die Fremdsprachen und besonders nicht deren Expansion gegenüber der Erstellungssprache. Nur so wird auch der Nutzer im Ausland Ihre Maschine schnell und problemlos bedienen können.