Best Practices für die Software-Lokalisierung: Sprache ist kein Puzzle

Ein Besuch hinter den Kulissen der Software-Lokalisierung: Wie funktioniert sie, wo wird es knifflig? Wie können Unternehmen Fehlerquellen entschärfen? Und was trägt zur Qualität bei?

Software-Lokalisierung ist überall

Was nutzen Sie? Windows, iOS, Android, Ubuntu? Office-Programme? Internet-Browser wie Firefox, Chrome oder Safari? Acrobat für PDF-Dateien?

Wenn Sie auf Ihrem Rechner oder Smartphone eines dieser Programme in einer anderen Sprache als Englisch benutzen, arbeiten Sie mit lokalisierter Software. „Lokalisiert“ bedeutet hier übersetzt und (im besten Fall) an die Gepflogenheiten des Ziellandes angepasst.

Dieser Artikel nimmt Sie mit hinter die Kulissen: Sie sehen, warum Software-Lokalisierung manchmal Detektivarbeit ist. Wie Erfahrung hilft. Und Sie erfahren, wieso Sie vielleicht manchmal Wunderliches auf Ihrem Bildschirm lesen.

Ich habe für Sie aus meinen Projekten Beispiele herausgesucht, die nicht sinnvoll übersetzt werden können. Und ich zeige, wie sich die Problemstellen mit wenig Aufwand (und einem etwas erweiterten Horizont) entschärfen lassen. Die Zusammenfassung meiner Tipps – sozusagen die Best Practices für die Software-Lokalisierung – finden Sie am Ende des Artikels.

Alle Beispiele habe ich, wo notwendig, so verfremdet, dass sie keine Rückschlüsse auf Produkt und Unternehmen zulassen.

Die Basics im Schnelldurchlauf

Damit Sie mir auf unserer Backstage-Tour folgen können, sollten Sie ein paar Fachbegriffe kennen.

Viele gängige Softwareprogramme stammen aus den USA und hatten ursprünglich eine englische Benutzeroberfläche. Die Benutzeroberfläche ist der Teil eines Programms, der auf Ihrem Bildschirm angezeigt wird – alle Menüs, Schaltflächen, Optionen, Rückfragen, Fehlermeldungen und so weiter.

Zur Lokalisierung der Software werden die Teile des Programmcodes, die diese Bildschirmtexte enthalten, zum Übersetzen geschickt. Diese Textstücke nennt man Strings.

Der Programmcode selbst, der den Computer anweist, was er tun soll, muss unverändert bleiben, sonst funktioniert das Programm nicht mehr. Ich nutze zum Übersetzen von Strings Programme, die den übersetzbaren Text erkennen und mir zum Übersetzen präsentieren, so dass der Code unangetastet bleibt.

Alles klar? Dann geht’s los!

Das erwartet Sie in diesem Artikel:

Variablen: praktisch, aber zum Haareraufen

Der, die, das – im Englischen unbekannt

Vier Fälle für ein Halleluja Durcheinander

Unterschiedliche Sprachen ticken … unterschiedlich.

Ohne Kontext sag’ ich gar nix.

Software-Lokalisierung: Best Practices …

… und Worst Practices

Kiefheim-Tipps für erfolgreiche Software-Lokalisierung

Variablen: praktisch, aber zum Haareraufen

Stellen Sie sich folgende Softwaremeldung vor: „In diesem Verzeichnis befinden sich 37 Dateien.“

Beim Programmieren dieser Meldung stellt sich das Problem, dass man nicht weiß, wie viele Dateien ein Verzeichnis enthält. Wie geht man damit um? Es wäre unsinnig, für jede mögliche Anzahl von 1 bis beispielsweise 500.000 einen eigenen String vorzusehen.

Man fügt daher die Anzahl als Variable ein, die in der laufenden Software durch die jeweilige Zahl Dateien ersetzt wird. Das sieht dann zum Beispiel so aus: „In diesem Verzeichnis befinden sich {{anzahl}} Dateien.“ Variablen können Zahlen oder Texte ersetzen.

Variablen sind also praktisch. Einerseits.

Andererseits gehen die Probleme beim Übersetzen mit ihnen erst richtig los.

Der, die, das – im Englischen unbekannt

„Der Tee“, „die Milch“, „das Frühstück“ – deutsche Substantive haben ein grammatisches Geschlecht, an das wir die dazugehörigen Artikel und Adjektive anpassen müssen. Wo „the“ im Englischen immer korrekt ist, braucht es im Deutschen „der“, „die“ oder „das“. Es gibt keinen Generalschlüssel, der für alle Lebenslagen passt: Wir müssen genau die richtige Form verwenden, sonst ist der deutsche Satz falsch. Weil das im Englischen unbekannt ist, sind englische Strings auf solche Komplikationen selten eingestellt.

Die folgenden Beispiele zeigen, welche Probleme das verursacht.

"Document successfully added to your %1$s."

„%1$s“ ist die Variable, und dafür könnten eingesetzt werden „cloud storage“, „database“ oder „account“. Also (der) Cloudspeicher, (die) Datenbank oder (das) Konto.

Doch was mache ich mit „your“? „Das Dokument wurde Ihrer/Ihrem %1$s hinzugefügt“? Sehr hässlich.

Als Notlösung funktioniert zwar immer eine Konstruktion à la „Dokument hinzugefügt zu: %1$s“, aber befriedigend ist das nicht.

Kiefheim-Tipp:
In Fällen wie diesen, wo die möglichen Varianten begrenzt sind, ist es lokalisierungsfreundlicher, für jede Variante einen eigenen String zu spendieren und auf die Variable zu verzichten.

Vor allem: „Lokalisierungsfreundlicher“ heißt in jedem Fall „nutzungsfreundlicher“, denn ein ordentlicher deutscher Satz ist immer besser verständlich und leichter erfassbar als eine notdürftig hingebogene Konstruktion.

"Your:"

Gleiches Problem: Welches grammatische Geschlecht folgt hier im Deutschen? Ohne Kontext und weiterführende Informationen ist dieser String, den ich genau so zum Übersetzen erhalten habe, nicht zu übersetzen. Jedenfalls nicht so, dass ein Bildschirmtext dabei herauskommt, der den Menschen am Rechner unauffällig und klar durch seine Aufgabe leitet.

Was tun also?

• Nachsehen, ob es zu diesem String einen Kommentar aus der Softwareentwicklung gibt, der mir verrät, worum es hier geht und was auf den Doppelpunkt folgen soll.
• Prüfen, ob ich mit dem Auftrag einen Screenshot aus der laufenden Software erhalten habe. Wenn ich den Kontext kenne, kann ich vielleicht eine ganz andere Lösung finden, die das Gemeinte ausdrückt und das grammatische Problem elegant umschifft.
• Beim Projektmanagement nachfragen, was nach dem Doppelpunkt folgen wird. Und hoffen, dass ich schnelle und brauchbare Antworten erhalte, damit ich den vereinbarten Liefertermin einhalten kann.

Kiefheim-Tipp:
Es wäre besser, den Teil nach dem Doppelpunkt in den String aufzunehmen. Oder, falls machbar, für alle möglichen Varianten einen eigenen String bereitzustellen.

Vier Fälle für ein Halleluja Durcheinander

Der nächste gravierende Unterschied zwischen der deutschen und der englischen Sprache: Im Deutschen ändern sich viele Wortarten nicht nur – siehe oben – abhängig vom grammatischen Geschlecht, sondern auch abhängig vom Fall, fachsprachlich: dem Kasus.

Sie erinnern sich vielleicht noch aus der Schule:
Nominativ – der Text; Genitiv – des Textes; Dativ – dem Text; Akkusativ – den Text. Dies betrifft Pronomen (sie, seinem, deren), Adjektive (schöne, schönes) und Substantive (Buch, Buchs).

Das macht Deutsch noch ein bisschen komplizierter – und auch damit rechnet beim Programmieren mal wieder niemand.

"Your {{subscription-type}} subscription will end after {{duration-time}} {{duration-type}}."

Übersetzt soll das so aussehen: „Ihr Abonnement des Typs Alles-drum-und-dran endet nach 12 Monaten.“

Die ersten beiden Variablen – der Name des Abonnements und die Anzahl der Monate – sind unproblematisch. Doch bei der dritten wird es knifflig: Die Übersetzungen für Allerweltsangaben wie Woche(n), Monat(e) und Jahr(e) sind in der Regel längst irgendwo in der Software hinterlegt. Wir können davon ausgehen, dass „months“ als „Monate“ übersetzt wurde. Wenn diese Standardübersetzung jetzt hier eingefügt werden soll, stünde auf Ihrem Bildschirm „… endet nach 12 Monate.“ Das geht natürlich nicht.

Es ist also mal wieder eine Nachfrage beim Projektmanagement fällig: Ich muss versuchen, das Problem für Leute zu erklären, die vermutlich kein Konzept von „Kasus“ haben, und dann müssen wir eine funktionierende Lösung finden.

Kiefheim-Tipp:
Eigene Strings für Wochen, Monate und Jahre, und zwar getrennt für Singular und Plural („nach 1 Jahr“ vs. „nach 2 Jahren“). Damit fiele {{duration-type}} als Variable weg und das Problem wäre beseitigt.

Theoretisch wäre es auch möglich, für die Variable {{duration-type}} eigene Strings für Tage, Wochen usw. anzulegen, die ausschließlich in diesem String verwendet werden. Dann kann ich sie für genau diesen Kontext passend übersetzen. Das erfordert allerdings eine sehr zuverlässige String-Verwaltung, die garantiert, dass die betreffenden Strings wirklich nirgendwo anders auftauchen. Ich würde mich darauf nicht verlassen wollen.

"Duplicate documents in" + "directories"

Wer hier (angesichts der mittlerweile oft unterirdischen Wortpreise für Softwareübersetzungen) auf den Stundensatz schielt und den erhaltenen Job möglichst schnell runterschrubbt, wird vermutlich schlicht zwei Einzel-Strings übersetzen: „Doppelte Dokumente in“ und „Verzeichnisse“.

Doch mit etwas Erfahrung ahnt man, dass der separate String „directories“ die Fortsetzung von „Duplicate documents in“ ist und zwischen den beiden Strings eine Zahl eingefügt wird.

Bei der obigen Schnell-Schnell-Übersetzung würde dann auf Ihrem Bildschirm erscheinen: „Doppelte Dokumente in 3 Verzeichnisse“. Natürlich verstehen Sie, was gemeint ist, aber richtiges Deutsch geht anders: Es muss hier „Verzeichnissen“ heißen, mit n am Ende.

Kiefheim-Tipp:
Dies wäre ein Fall für eine Variable. Damit kann man die ganze Meldung in einem einzigen String zusammenfassen und die Zahl als Variable hinterlegen: „Duplicate documents in {{number}} directories“

Unterschiedliche Sprachen ticken … unterschiedlich.

Ich habe – in meiner Arbeit im Allgemeinen und in diesem Artikel im Besonderen – vor allem die Unterschiede zwischen Englisch und Deutsch im Blick. Bei anderen Sprachen gibt es noch ganz andere sprachliche Eigenheiten: Beispielsweise haben Slowenisch und Arabisch den „Dual“ als spezielle Zahlform für die Anzahl „2“, und im Serbischen gibt es sogar eine eigene Kategorie für „2 bis 4“, den „Paukal“.

Ich verrate Ihnen ganz ehrlich, dass ich mit derartigen Feinheiten nie gerechnet hätte. Wie kann ich also von englischsprachigen Programmierern und Programmiererinnen erwarten, dass sie die Eigenheiten aller möglicher Zielsprachen im Blick haben?

Und trotzdem bereitet die kompromisslose Anwendung englischer Sprachlogik unnötige Probleme.

"In"

Jetzt wundern Sie sich sicherlich, was so schwierig an „in“ sein soll, stimmt’s? Schließlich heißt dieses kleine Wörtchen auch im Deutschen schlicht „in“.

Doch an dieser Stelle war klar, dass entweder eine Ortsangabe oder eine Jahreszahl folgt. Problem: Anders als im Englischen sagen wir im Deutschen zwar „in Hildesheim“, nicht aber „in 2024“. Das bedeutet für die Übersetzung, dass ich im ersteren Fall „in“ schreiben kann, im letzteren jedoch das Wort komplett streichen muss. Dieser String kann nicht für beides funktionieren.

Kiefheim-Tipp:
Besser wären zwei separate Strings (hier gerne mit Variablen, endlich mal!): einer für Ortsangaben und einer für Jahreszahlen.

Es ist immer unglücklich, wenn die Programmierung vorsieht, Satzfetzen, Zahlen und Einzelwörter zu einem ganzen Satz zusammenzuflanschen. Für eine gute Übersetzung braucht es ganze Sätze und auch Kontext (siehe unten).

"add selected items to {{name}} group"

Hier wurde ich misstrauisch, weil dieser String mit einem Kleinbuchstaben beginnt. Ich muss davon ausgehen, dass dies nicht der Anfang des Satzes ist und wir mittendrin einsteigen. Doch ohne den Satzanfang zu kennen, kann ich kein grammatisch korrektes Satzende schreiben.

Lautet der Satzanfang „Sie können nun“, fahre ich fort mit „ausgewählte Elemente zur Gruppe {{name}} hinzufügen“. Lautet der Satzanfang dagegen „Klicken Sie hier, um“, muss ich schreiben: „ausgewählte Elemente zur Gruppe {{name}} hinzuzufügen“.

Es könnte natürlich auch sein, dass „add“ ein Schreibfehler ist und „Add“ heißen sollte. Dann schreibe ich „Ausgewählte Elemente zur Gruppe {{name}} hinzufügen“.

Auch kommt es immer wieder vor, dass jemand schlampt und den Satzpunkt vergisst. Für die Übersetzung macht das einen großen Unterschied, denn mit Satzpunkt wird im Deutschen aus dem Ganzen eine direkte, persönliche Aufforderung: „Fügen Sie die ausgewählten Elemente zur Gruppe {{name}} hinzu.“

Kiefheim-Tipp:
Bildschirmtexte niemals aus Satzschnipseln zusammenbasteln, sondern immer mit ganzen Sätzen arbeiten!

"We were not able to process the request for"

Dieser Satz müsste auf Deutsch heißen „Wir konnten die Anfrage für XYZ nicht verarbeiten.“ Problem: Im Englischen steht XYZ am Ende des Satzes, im Deutschen dagegen muss XYZ in der Mitte stehen.

Solange die Variable für XYZ nicht Teil des Strings ist, kann ich keinen vernünftigen deutschen Satz herstellen. Ich muss mich daher wieder in Ausweichmanöver retten: „Wir konnten die Anfrage für folgende Person nicht verarbeiten:“ Geht auch, aber es wäre schöner, einfach normales Deutsch abliefern zu können.

Kiefheim-Tipp:
Eine Variable sollte unbedingt Teil des Satzes sein, denn es ist immer möglich, dass die Satzstellung in anderen Sprachen ganz anders ist.

Ohne Kontext sag’ ich gar nix.

„Kontext!“ Das ist quasi der Schlachtruf der übersetzenden Zunft. Wir beantworten die Frage „Wie heißt … auf Deutsch?“ nicht, solange wir den Kontext nicht kennen. („Ohne meinen Anwalt sag’ ich gar nix.“)

Und natürlich geht ohne Kontext auch in der Software-Lokalisierung nichts.

"off"

Ohne Kontext tappe ich hier völlig im Dunklen: Ist eine Funktion abgeschaltet? Wird ein Preisnachlass angekündigt? Sicher sind auch noch andere Bedeutungen denkbar.

Als Übersetzung kämen also schon mal „aus“ und „Rabatt“ in Frage. Das zeigt: Ohne Zusatzinformationen lässt sich dieser String nicht seriös übersetzen.

"Open"

Heißt das nicht einfach „Öffnen“? Nicht unbedingt: Es könnte genauso gut „Geöffnet“ heißen. Und wenn ich Pech habe, folgt auf dieses Wort sogar noch das, was geöffnet ist. Dann müsste es je nach grammatischem Geschlecht „Geöffneter“, „Geöffnete“ oder „Geöffnetes“ heißen.

Ich muss also wieder einmal nachfragen.

Software-Lokalisierung: Best Practices …

Damit ist unsere kleine Tour beendet – schütteln Sie den Code- und Grammatikstaub ab und treten Sie wieder ins Licht der Welt.

Ich hoffe, ich konnte Ihnen zeigen, wie viel Arbeit „diese paar Wörter“ in Softwarestrings machen können. Welcher Aufwand dazugehört, damit Sie in der deutschen Programmversion korrekte, aussagekräftige und dem Kontext angemessene Meldungen erhalten. Und welchen Wert dabei ausreichende Erfahrung in der Software-Lokalisierung hat. (Ich mache das schon seit den Neunzigern.)

Gute Softwarequalität fängt schon beim Programmieren an: Sie haben gesehen, dass umsichtig und lokalisierungsfreundlich geschriebene Strings bereits viel zu einer guten Übersetzung beitragen.

Ideal ist die direkte Zusammenarbeit zwischen Softwarefirma und Übersetzerin: So landen Fragen, Problemhinweise und Verbesserungsvorschläge direkt an der richtigen Stelle. Mit etwas Glück werden problematische Strings geändert und erneut zur Übersetzung geschickt. So arbeiten wir gemeinsam auf ein gutes Endprodukt hin!

… und Worst Practices

Leider läuft dies oft anders. Für Software-Lokalisierung wird ohnehin meist sehr wenig gezahlt. Hinzu kommt, dass Aufträge oft an eine Agentur gegeben und von dieser noch über mehrere andere Agenturen weitergereicht werden. Klar: Da bleibt nicht mehr viel Geld für die eigentliche Übersetzung übrig, und die Motivation zu – den so notwendigen! – Rückfragen strebt bei dieser Bezahlung gegen null.

Ohnehin ist es zweifelhaft, ob, wann und in welchem Zustand Rückfragen bei einer längeren Agenturkette überhaupt die auftraggebende Firma erreichen. Es kommt tatsächlich vor, dass die Zuständigen in den Agenturen keine Ahnung vom Übersetzen haben und daher nicht verstehen, warum die Fragen wichtig sind. Es ist schon vorgekommen, dass eine meiner Fragen umformuliert wurde – und zwar so, dass der wesentliche Punkt herausfiel!

Und die Antworten? Mitunter Glückssache. Ich habe selbst bei kurzen Wegen oft genug erlebt, dass Rückfragen nicht oder unbrauchbar beantwortet werden.

Angesichts dessen ist es geradezu tragisch, dass die Kosten für die Softwarefirma bei diesem Agenturketten-Modell ungefähr die gleichen sind wie bei der direkten Zusammenarbeit mit einer erfahrenen Übersetzerin. Doch zwischen den Resultaten liegen Welten.

Wenn Sie sich das nächste Mal über schlecht übersetzte Software ärgern, seien Sie nachsichtig: Es liegt nicht unbedingt an der Unfähigkeit derjenigen, die übersetzt haben. Und wenn Sie in einem Softwareunternehmen arbeiten, haben Sie jetzt eine Menge Praxistipps bekommen, wie Sie mit wenig etwas Umsicht und wenig Aufwand viel für ein gutes Ergebnis tun können. Ihre Kundschaft wird es Ihnen danken.

Kiefheim-Tipps für erfolgreiche Software-Lokalisierung

Diese Liste fasst die „Best Practices“ der Software-Lokalisierung aus den Beispielen zusammen.

• Aufpassen bei Variablen: Schreiben Sie bei wenigen Varianten für jede einen eigenen String und verzichten Sie auf Variablen. Dies ist gerade dann wichtig, wenn Einzelwörter per Variable mitten in einen Satz eingefügt werden. Zusätzliche Strings sorgen dafür, dass alle übersetzten Strings grammatisch korrekt sind.
• Geben Sie bei Ausdrücken wie „your“ oder „opened“ den Kontext an, damit klar ist, worauf sich diese Ausdrücke beziehen. Nur dann wird die Übersetzung grammatisch korrekt.
• Teilen Sie Sätze niemals in mehrere Strings auf. So umgehen Sie die Gefahr, dass die zusammengefügten Teile grammatisch nicht zueinander passen.
• Vorsicht bei kurzen, generischen Einzelwörtern: Liefern Sie Kontext mit, z. B. als Kommentar in der String-Datei, oder erweitern Sie die Strings so, dass der Kontext deutlich wird.
• Wenn zum ganzen Satz eine Variable gehört, dann achten Sie darauf, dass sie Teil des Strings ist. Damit sorgen Sie dafür, dass die Variable im übersetzten Satz an der richtigen Stelle stehen kann.
• Beantworten Sie Fragen der Übersetzerin und bedenken Sie ihre Hinweise: Das trägt zur Qualität der fertigen Software bei. So machen Sie Ihre Kundschaft glücklich!
• Ideal ist die direkte Zusammenarbeit mit Ihrer Übersetzerin: So können Sie Fragen schnell und direkt klären, ohne „Stille Post“ über eine kurze oder lange Agenturkette. Und nur wer angemessen bezahlt wird, kann auch Qualitätsarbeit liefern.