Platzhalter in Übersetzungen und wie man damit umgeht

Ich erinnere mich noch gut an mein erstes Projekt im Bereich Softwarelokalisierung. Ich wurde beauftragt, die Benutzeroberfläche eines industriellen Computersystems mit einem komplizierten Softwarelokalisierungstool zu übersetzen. Ich hatte keine Probleme mit technischen Dingen, aber das Übersetzen einer Benutzeroberfläche war neu für mich und die Aufgabe stellte sich als echte Herausforderung heraus.

Tatsächlich war mir der Stil der Texte nicht ganz fremd. Da ich mich einigermaßen mit IT auskenne, war mir die „Computersprache“, die typischerweise in Software verwendet wird, durchaus vertraut (unter dem Einfluss von Chatbots und Sprachschnittstellen hat sich meine Sichtweise seitdem allerdings drastisch geändert). Was mich wirklich verwirrte, waren diese seltsam aussehenden Zeichen: {0}, %d, %setup% und $stop$. Ich hatte keine Ahnung, wofür sie standen und ob die zwischen den Symbolen stehenden Wörter übersetzt werden sollten oder nicht, sodass ich in kürzester Zeit viele Fehler machte. Die Zeilenumbruchzeichen, dargestellt als \n, waren der letzte Schlag für mein Selbstvertrauen. Ich hatte diese Zeichen noch nie zuvor gesehen, und das Schlimmste daran war, dass sie oft mit anderen Wörtern verschmolzen waren. Als ob die Situation nicht schon lächerlich genug wäre, war der Text auf Deutsch, was es wirklich schwer machte zu erkennen, ob \nein „nein” oder „\n” + „ein” heißen sollte. Der Projektmanager muss seine Entscheidung, diese Aufgabe einem Dummkopf wie mir zu übertragen, bereut haben, nachdem er mit Fragen bombardiert wurde. Vielleicht hat er sich sogar auf Twitter darüber ausgelassen.

Die Platzhalter in den übersetzten Dateien für ein dringendes Projekt sind auf magische Weise verschwunden. #PMproblems #StartPanicking

— Lau Velázquez (@geekylau) 9. Oktober 2013

Übersetzer, welche den Platzhalter $DepartureTime$ mit $HeureDépart$ übersetzen sind einfach nur konsequent.

— Olivier Oswald (@ooswald)July 27, 2011

Die Übersetzer, die den Platzhalter „$Departure Time$“ mit „$HeureDépart$“ übersetzen, sind lediglich konsistent.

Der Moment, in dem ein Übersetzer beschließt, die Form der Anführungszeichen zu ändern, und die Hälfte Ihrer Variablen im Spiel verschwindet.

— Vojtěch Schubert (@falagor)12. Januar 2016

Auch Jahre später noch zaubern die Erinnerungen an meine erste Erfahrung ein Lächeln auf mein Gesicht. Selbstverständlich nehme ich mir immer Zeit, um Übersetzern zu erklären, wie Variablen funktionieren. Und die beste Methode, um Fehler zu vermeiden und Zeit für sich selbst und Ihr Team zu sparen, ist die Verwendung regulärer Ausdrücke. Mit ihnen lassen sich Variablen in nicht editierbare und leicht nachverfolgbare Objekte umwandeln. In verschiedenen Softwareprogrammen werden diese Objekte mit unterschiedlichen Namen bezeichnet. Wir bei Smartcat nennen sie gerne Platzhalter. Und falls Sie sich fragen, was reguläre Ausdrücke sind: Sie haben nichts mit Small Talk zu tun. Es handelt sich um Muster, die zum Abgleichen und Bearbeiten von Zeichenkombinationen verwendet werden. Um reguläre Ausdrücke zu lernen, sind keine Programmierkenntnisse erforderlich. Klicken Sie sich durch diese leicht verständliche Präsentation von Thomas Vackier, Lokalisierungsexperte bei Yamagata Europe, um einen Eindruck davon zu bekommen, was Regex (kurz für „reguläre Ausdrücke“) sind.

Die geheimnisvollen Symbole

Als kurzes Beispiel nehmen wir ein paar Zeilen aus dem Song „I’m Gonna Be (500 miles)” von The Proclaimers:

But I would walk 500 miles And I would walk 500 more Just to be the man who walked a thousand miles To fall down at your door

Angenommen, wir möchten, dass sich dieser Text ändert, wenn der Hörer an einen anderen Ort reist. Dazu benötigen wir Variablen:

Aber ich würde %$1s Meilen laufen Und ich würde noch %$2s mehr laufen Nur um der Mann zu sein, der {spelled-number} Meilen gelaufen ist Um vor deiner {location} niederzufallen

Welche Gefahren lauern hier? Wichtige Zeichen können gelöscht und/oder missbraucht werden. Die Ziffern in %$1s müssen einem sequenziellen Muster folgen, und „spelled-number“ und „location“ dürfen nicht übersetzt werden. Leider weiß das nicht jeder.

„Aber warum nicht einfach einen erfahrenen Übersetzer beauftragen, anstatt sich mit all diesen Anfängerproblemen herumzuschlagen?“, könnte man fragen. Was auch immer die tatsächlichen Gründe sein mögen, es lohnt sich, daran zu denken: Niemand wird als Lokalisierungsprofi geboren, aber jeder, der sich durch die ersten Schritte gekämpft und dabei wertvolle Erfahrungen gesammelt hat, kann einer werden.

Anfängerfreundlich oder wie man die Welt rettet

Was können wir also tun, um Katastrophen zu verhindern und uns Bearbeitungszeit zu sparen? Beschreiben wir die Variablen mit regulären Ausdrücken:

• Für Variablen mit aufeinanderfolgenden Zahlen: %\$\ds

• Für Variablen in geschweiften Klammern: \{.+?\}

Ich persönlich finde dieses Spickzettelchen sehr nützlich für die Erstellung regulärer Ausdrücke, und regex101.com ist ein großartiges Online-Tool, das ich zum Testen empfehle. Laden wir nun die Datei mit den Variablen in Smartcat hoch. Das Ergebnis sieht dann so aus:

Die Variablen werden als violette Einheiten angezeigt, die offensichtlich nicht übersetzbar sind und über eine Tastenkombination sicher aus dem Quelltext in die Zielsprache übertragen werden können. Diese Elemente bleiben nach dem Herunterladen im übersetzten Dokument erhalten. Die Verwendung von Platzhaltern ist nicht auf Lokalisierungsprojekte beschränkt. Stellen Sie sich vor, Sie haben ein umfangreiches Datenblatt für Luftpumpen mit Tausenden von Artikeln. Jedem Artikel sind Bestellcodes zugewiesen, die alle sehr ähnlich aussehen, sodass es leicht zu Verwechslungen kommen kann.

Ein einziger Fehler kann hier schwerwiegende Folgen haben. Bei der Auslieferung von Bestellungen aus dem Lager kann es zu Fehlern kommen, und auch die ordnungsgemäße Installation kann problematisch sein. Der Kunde erleidet Verluste oder Schlimmeres: Falsche Daten können technische Probleme verursachen, die wiederum zu einer Umweltkatastrophe führen können. Platzhalter werden nicht übersetzt, sondern lediglich sicher in die Zielsprache übertragen. Warum also Zeit damit verschwenden? Lassen Sie uns alle Bestellcodes mit diesem eleganten regulären Ausdruck [A-Z]{2}\d{4}\-\d{4} finden und sie auf magische Weise in nicht editierbare Elemente umwandeln:

Was für eine großartige Möglichkeit, unseren Übersetzungsprozess (und auch den Bearbeitungsteil davon) einfacher und schneller zu gestalten!

Derzeit werden Platzhalter standardmäßig nur für die gängigen Lokalisierungsdateiformate unterstützt. Wenn Sie sie in anderen Dokumenttypen verwenden möchten, lassen Sie es uns wissen.

Ich habe meine Kollegen nach ihren Erfahrungen mit Platzhaltern gefragt.

Fjodor Bezrukow, Geschäftsführer bei Logrus IT (Büro Kiew)

„Die Verwendung von Platzhaltern und Tags in Dokumentformaten ist für uns ein gängiges Arbeitsszenario. Sie sind eine große Hilfe, wenn Kunden Excel-Dateien mit HTML- oder XML-Markup senden. Dank der Unterstützung von Platzhaltern und regulären Ausdrücken in Smartcat ist die Bearbeitung solcher Ressourcen viel einfacher und bequemer geworden.“

Marina Ilyinykh, Lokalisierungsmanagerin bei Bookmate

„Wir verwenden in den Benutzeroberflächen unserer Apps häufig Variablen und Formatierungen. Durch das Ersetzen von Tags und Variablen durch Platzhalter können wir automatische Konsistenzprüfungen durchführen und wichtige Daten wie Preise, Abonnementdaten und Links sichern.“

Yannis Evangelou, CEO von lexiQA, teilte seine gemischten Gefühle mit:

Yannis Evangelou, CEO von lexiQA

„Es gibt ein häufiges Problem bei Übersetzern, die Texte innerhalb von Platzhaltern, Tokens und Tags übersetzen. Escape-Zeichen werden ebenfalls oft ignoriert. Die meisten von ihnen sind sich nicht bewusst, dass es sich hierbei um nicht übersetzbare lexikalische Einheiten handelt. Auch Projektmanager wissen das nicht. Diese Art von Nachlässigkeit kann jedoch zu kritischen Fehlern führen. Ein Übersetzer erzählte mir einmal, dass er einen Text mit HTML-Formatierung bearbeiten musste und die Zeile <p style="border: 1px solid red;"></p> in <π στυλ="περίγραμμα: 1 πίξελ συμπαγές κόκκινο;"></π> übersetzt. Er argumentierte, dass der Entwickler, der den Text verwenden würde, vielleicht kein Englisch spreche. Die Projektmanagerin hat dies nicht korrigiert, da sie die Argumentation des Übersetzers für ... vernünftig hielt!

Dann meldete sich Rolf Klischewski, Experte für Spielelokalisierung, zu Wort:

„Spielübersetzer müssen sich oft mit solchen Dingen auseinandersetzen:

Und natürlich gibt es damit auch alle möglichen Probleme.

Das Problem hierbei ist, dass manche Reiseziele einen Artikel erfordern. So heißt es „die Bahamas“, aber „Barbados“. Oder auf Deutsch heißt es „die Schweiz“ für „Switzerland“. In solchen Fällen lehnen wir das Projekt oft ab. Normalerweise würde ich Kunden raten, ihre Text-Engine zu ändern, da ich keine schlechte Arbeit abliefern möchte. Entwickler fragen dann meist: „Ist das wirklich so ein großes Problem?” Und ich sage dann: „Nein, denn man kann das Spiel ja spielen.” Wie geht man also mit solchen Problemen um? Man informiert den Kunden und erklärt ihm das Problem. Wenn er die Engine nicht reparieren kann oder will und man das Geld braucht, macht man den Auftrag, aber sorgt dafür, dass man nicht im Abspann genannt wird.