Inhaltsverzeichnis
Das letzte Termcafé im September fand in veränderter Form statt: Anstelle mehrerer virtueller Tische mit einzelnen Themen entschieden wir uns für eine Diskussionsrunde im Plenum. Wir wollten gezielt die konkreten Problemstellungen der Teilnehmenden besprechen. Dabei ging es um spezielle Terminologieprobleme bei Übersetzungsaufgaben. Lesen Sie selbst!
Use Case 1: GUI-Übersetzungen manuell nachprüfen
In einer Technischen Redaktion werden für Softwareprodukte Onlinehilfen erstellt. Die UX-Writerin kümmert sich um das Erstellen der sprachspezifischen GUI-Elemente. Nach der Übersetzung fällt auf: Die Übersetzungen stimmen nicht mit der firmenspezifischen Terminologie überein. Am Ende enthält die Software Schaltflächen, die nicht zu den Funktionen der Software passen, sodass sich User nicht zurechtfinden. Die Folge: mühsame und langwierige manuelle Nacharbeit in Excel, die das Team zunehmend belastet.
Das Problem tritt auf, obwohl eine Termbank existiert, die auch mit dem Übersetzungsdienstleister geteilt und fortlaufend aktualisiert wird. Die Hoffnung liegt nun bei einem zweisprachigen QA-Checker, der die Ausgangsterminologie mit der Zielterminologie im Vergleich anzeigt, um die manuellen Aufwände zu reduzieren. Solche Funktionen findet man hauptsächlich in CAT-Tools (auch „Translation-Memory-Systeme“ genannt) als QS-Schritt nach der Übersetzung. Ansonsten auch in speziellen Tools für die zweisprachige Terminologieprüfung wie etwa Kalcium Checkterm (in Verbindung mit Kalcium Quickterm), Verifika oder XBench. Für formale Prüfungen können sich auch reguläre Ausdrücke anbieten.
Aber ist das die einfachste Umsetzung? Immerhin kauft man sich damit wieder ein Tool ein, hat den Aufwand der Tooleinführung, der Einarbeitung, des Datenaustauschs und trotzdem noch die wiederkehrenden Aufgaben der Prüfung. Eigentlich hat der Übersetzungsdienstleister ja alle Daten vorliegen, um genau den gewünschten QA-Check durchzuführen.
Was wäre also der einfachste erste Schritt zur Lösung? Einfach mal miteinander reden! Möglicherweise gab es ein technisches Problem, sodass die Termbank gar nicht oder nicht auf dem aktuellsten Stand eingebunden wurde (wie es bei einer anderen Teilnehmerin schon mal der Fall war). Der Dienstleister weiß vielleicht auch gar nicht, was die Qualitätsmerkmale sind, die dann vom Kunden manuell nachbearbeitet werden. Solche Inhalte lassen sich übrigens gut in einem Terminologieleitfaden festhalten, formalisieren und dann intelligent (nicht manuell) abprüfen.
Use Case 2: Locale Codes in einer großen Termbank verwalten
In einem anderen Unternehmen aus der Medizintechnik wurde vor einigen Jahren erfolgreich eine Termbank eingeführt und in über 40 Sprachen gepflegt. Beim Anlegen der Termbank wurden bestimmte Sprachvarietäten als übergreifende Standardsprache festgelegt. Das betrifft Sprachen, die in unterschiedlichen Ländern und Regionen gesprochen werden, z. B. Englisch in den USA oder im UK, Italienisch in Italien oder in der Schweiz. Diese Sprachvarietäten werden technisch in den sogenannten Locale Codes festgelegt und bestehen aus den genormten ISO-Kürzeln Sprachcode plus Ländercode, z. B. en-US, en-UK, it-IT, it-CH.
Wofür braucht man diese Unterscheidung? Zum einen in der Übersetzung, da sich Sprachvarietäten in der Wortwahl, Terminologie und Grammatik deutlich unterscheiden können. Wenn ein Unternehmen bestimmte Zielgruppen über ihre Websites, Webshops, Softwareprodukte, lokal regulierte Produkte etc. ansprechen will, sind solche differenzierten Übersetzungen und Lokalisierungen notwendig. Gerade auch mit KI-Anwendungen wie Chatbots bemerkt man, dass diese regionalen Unterschiede immer relevanter werden.
Im konkreten Use Case wurde die Terminologie z. B. auf Spanisch standardmäßig in „es-LATAM“ (Spanisch für Lateinamerika) gepflegt. Wie können nun die Unterschiede zum europäischen Spanisch festgehalten werden, ohne Dopplungen in der ohnehin schon umfangreichen Termbank zu erzeugen?
Folgende Lösungen wurden diskutiert:
- Metadaten
Keine neuen Sprachvarietäten verwenden, sondern nur das Metadatum „geografischer Gebrauch“: Die wenigen Unterschiede, die in der Praxis tatsächlich vorkommen, können als erlaubtes Synonym gepflegt werden. Die automatisierten QA-Checks (wie in Use Case 1 angesprochen) funktionieren in diesem Fall nicht so einfach – bei der Lösung muss man sich auf die Genauigkeit der Übersetzer:innen verlassen. - Propagation-Strategie
Mithilfe von Workflows könnte man automatisiert die Einträge für weitere Sprachvarietäten doppeln und den Übersetzer:innen bzw. Terminolog:innen zur Prüfung vorlegen: Entweder ist die bisherige Terminologie immer noch gültig oder sie kann für bestimmte Regionen geändert werden. Die Terminologieprüfung in CAT-Tools funktioniert dann auch ohne manuelle Zwischenschritte. Mit dieser Strategie erzeugt man schnell enorme Datensätze. - Fallback-Strategie
Terme werden nicht doppelt gepflegt, sondern nur Abweichungen in der Sprachvarietät festgehalten. In der Termbank wird festgehalten, welche Sprachvarietät von welcher Standardsprache erbt. Ein Beispiel: „Deutsch“ ist als übergreifende Standardsprache festgelegt. „Deutsch (Schweiz)“ und „Deutsch (Österreich)“ erben von den Einträgen dieser Standardsprache, wenn sie keinen eigenen Eintrag haben. Wer das Redaktionssystem SCHEMA ST4 nutzt, kennt diese Fallback-Funktion bei den Sprachaspekten. Bei den Termbanken nutzt Lexeri ebenfalls das Feature der Fallback-Sprachen.
Fazit
Beide Use Cases zeigen die Komplexität der Terminologiearbeit in mehrsprachigen Projekten. Letztendlich sollte man sich zunächst für die einfachste und aufwandsärmste Lösung entscheiden, die gleichzeitig zum gewünschten Erfolg führt. Mehr Tools sind nicht automatisch die beste Lösung – vor allem, wenn das Problem darin besteht, dass an irgendeiner Stelle die Kommunikation auf der Strecke bleibt.
In der Zusammenarbeit mit mehreren internen und externen Projektbeteiligten zeigt sich schnell, dass das einfache Festlegen von Qualitätsanforderungen z. B. bei der Übersetzung von GUI-Elementen oder dem Verwenden von bestimmten regional markierten Synonymen schon den Großteil der Probleme abdeckt. Sollten weitere Probleme bestehen, können immer noch technische Lösungen infrage kommen. Dieses Vorgehen entspricht unserem Ansatz „Bare Bones Terminology“: schnelle Lösungen für konkrete Probleme.
Unser letztes Termcafé in diesem Jahr findet übrigens am 4. Dezember statt. Sie sind herzlich dazu eingeladen!


