Übersetzungsdatenmanagement

Kapitel 10 Übersetzungsdatenmanagement Simon Varga Johannes Gutenberg-Universität Mainz Dieser Beitrag gibt einen Überblick über Strategien und Prozesse des Übersetzungsdatenmanagements. Die Reihenfolge der Kapitel orientiert sich an der Vorgehensweise bei der Durchführung von Translation-Memory-Harmonisierungs- /Zentralisierungsprojekten: von der Definition der Datenorganisation und der Identifizierung potenziell relevanter Datenquellen über deren Migration, Analyse, Bereinigung und Harmonisierung bis hin zu ihrer Implementierung in Produktionsprozessen und der kontinuierlichen Überwachung ihrer Qualität und Performance. 1 Einleitung Die Übersetzungsindustrie hat in den letzten Jahrzehnten einen grundlegenden technologischen Wandel erfahren. Auf das Übersetzen als Tätigkeit an sich hatten dabei insbesondere drei Technologien einen massiven Einfluss: So wurde mit der Veröffentlichung der ersten kommerziellen CAT-Tools in den frühen 1990er Jahren zunächst die einfache Wiederverwendung bereits übersetzter Texte ermöglicht – wodurch sich nicht nur das Arbeiten von ÜbersetzerInnen, sondern auch Art und Weise, wie sie ihre Leistungen abrechnen, grundlegend änderte. Mit der neuronalen maschinellen Übersetzung (NMÜ) folgte im Jahr 2016 dann der nächste Technologiesprung, in dessen Folge maschinelle Übersetzung von der Nischenzur Breitentechnologie wurde – auch hier sowohl mit Auswirkungen auf Arbeitsweisen und Abrechnungsmodalitäten. Mit der Entwicklung der adaptiven maschinellen Übersetzung im Jahr 2017, spätestens aber mit der Veröffentlichung der ersten Large Language Models (LLMs) Ende 2022 wurde es dann Simon Varga. 2026. Übersetzungsdatenmanagement. In Oliver Czulo, Martin Kappus & Felix Hoberg (Hrsg.), Digitale Translatologie, 155–179. Berlin: Language Science Press. DOI: 10.5281/zenodo.17523048 Simon Varga schnell einfacher, MÜ-Ergebnisse in Echtzeit – und ohne vorheriges aufwendiges Training – in die gewünschte Richtung zu lenken. Was alle diese Technologien gemeinsam haben? Sie funktionieren auf Grundlage von Daten. Waren Übersetzungsdaten im Zeitalter der CAT-Tools noch eine hochspezialisierte Ressource, die außerhalb klassischer Übersetzungsprozesse kaum eine Rolle spielten, so gewannen sie mit der Verfügbarkeit trainierbarer bzw. customisierbarer NMÜ-Modelle zunehmend auch breitere Bedeutung (Wang 2016: 12) – etwa für die Bereitstellung von maschineller Übersetzung als Self Service in Unternehmen; ein Trend, der sich mit dem schrittweisen Umschwenken vieler Anbieter auf LLMs nahtlos fortsetzt. In erster Konsequenz lässt sich daraus folgende Beobachtung ableiten: In dem Maße, in dem Übersetzungsdaten breiter eingesetzt und die auf ihrer Grundlage erstellten Übersetzungen nicht systematisch von Menschen überprüft werden (können), steigen die Anforderungen an ihre Qualität. Diese lässt sich definieren anhand der Dimensionen Genauigkeit (Accuracy), Konsistenz (Consistency), Vollständigkeit (Completeness) und Aktualität (Currency und Timeliness) (Scannapieco u. a. 2005, Batini & Scannapieco 2016). Konkret sollten Übersetzungsdaten also: • den an sie gestellten Qualitätsanforderungen entsprechen, etwa in Bezug auf die Einhaltung einer Corporate Language oder eines vordefinierten Metadatenschemas (Accuracy), • konsistent sein in Bezug auf die Einhaltung sowohl sprachlicher Vorgaben als auch auf die Verwendung von Metadaten (Consistency), • den jeweiligen Einsatzzweck abdecken (Completeness), • in ihrem Inhalt dem aktuellen Stand des durch sie abgebildeten Sprachgebrauchs entsprechen (Currency), also z. B. keine veraltete Terminologie enthalten, • durch geeignete Managementprozesse auf dem jeweils neuesten Stand gehalten werden (Timeliness) (vgl. Zielinski & Varga 2020: 307-309). Wie aus diesen Anforderungen deutlich wird, gehen erhöhte Anforderungen an die Übersetzungsdatenqualität Hand in Hand mit erhöhten Anforderungen an das Übersetzungsdatenmanagement. Vor diesem Hintergrund geben die folgenden Kapitel einen Überblick über die wichtigsten Schritte und Ansätze für ein effizientes Management von Übersetzungsdaten in Form von Translation Memorys (TMs). Das Augenmerk liegt dabei 156 10 Übersetzungsdatenmanagement nicht nur Aufbau und Pflege neuer Datenbestände, sondern auch und gerade auf der Zusammenführung von Daten aus unterschiedlichsten Quellen, wie sie im Rahmen von Zentralisierungsund Harmonisierungsprojekten in Übersetzungsabteilungen erforderlich sind. 2 Datenorganisation definieren Die Implementierung effizienter Managementprozesse für Übersetzungsdaten setzt zuallererst die Definition von Anforderungen und Zielen sowie einer darauf ausgerichteten Datenorganisation voraus. 2.1 Physische TM-Organisation Dies betrifft zunächst die physische Organisation von TMs: Sollen (bzw. können!) je Übersetzungsrichtung alle Inhalte in ein und demselben TM gespeichert werden? Die Vorteile eines solchen Single-TM-Ansatzes liegen auf der Hand: je kleiner die Zahl an TMs, desto kleiner der Aufwand für ihre Implementierung, Verwaltung und Pflege. Unterschiedliche TMs für Übersetzungen in derselben Sprachrichtung können jedoch etwa aus Vertraulichkeitsgründen erforderlich sein: Werden bspw. vertrauliche Inhalte von In-House-Übersetzern bearbeitet und andere Übersetzungen extern vergeben, kann über zwei separate TMs je Übersetzungsrichtung garantiert werden, dass ein Zugriff auf vertrauliche Inhalte durch externe Übersetzer – über Fuzzy-Matches oder Konkordanzsuchen – unmöglich ist. 2.2 Unterstützende Ressourcen Zusätzlich zu den TMs selbst müssen in diesem Schritt auch weitere Ressourcen erstellt bzw. geprüft werden, die sich direkt auf die Qualität der Übersetzungsdaten auswirken. Dies betrifft zunächst die TM-Einstellungen. Je nach verwendetem Tool bieten diese unterschiedliche Optionen für die Verwendung von TMs in Übersetzungsprojekten, wie etwa Filter, über die TM-Treffer mit bestimmten Metadaten priorisiert oder aber ausgeschlossen werden können (siehe Abschnitt 2.4). Weitere Ressourcen, die direkten Einfluss auf die Qualität der im Übersetzungsprozess entstehenden Daten hat, sind Segmentierungsregeln und Dateiimporteinstellungen. Segmentierungsregeln definieren jeweils für eine spezifische Ausgangssprache, an welchen Stellen Texte in einzelne Segmente aufgesplittet werden sollen, also etwa nach Satzendzeichen, Zeilenumbrüchen oder bestimmten 157 Simon Varga Sonderzeichen. Dateiimporteinstellungen wiederum definieren für ein bestimmtes Dateiformat (also etwa .docx oder .xml), wie Inhalte aus entsprechenden Dateien in den Übersetzungseditor importiert werden. Fehlerhafte Segmentierungsregeln und/oder Dateiimporteinstellungen wirken sich negativ auf Qualität und Wiederverwendbarkeit von Übersetzungseinheiten aus, indem sie Texte auseinanderreißen oder aber zu grob segmentieren oder zum Import nichtübersetzbarer Inhalte führen (siehe Abschnitt 5.2.1). Je nach System besteht darüber hinaus u. U. die Möglichkeit, nichtübersetzbare Elemente, wie etwa Produktnamen und -nummern, zu hinterlegen und im Idealfall sogar zu schützen. Hier sind unterschiedliche Ansätze möglich: So bieten manche Tools die Möglichkeit, zu schützenden Text mithilfe regulärer Ausdrücke in Tags zu verwandeln.1Eine zusätzliche toolspezifische Option ist etwa die Erstellung sog. Non-Translatables-Listen in memoQ (siehe Abb. 1). Unabhängig von der konkreten Vorgehensweise können fehlende/veränderte Elemente in laufenden Projekten über QA-Routinen identifiziert werden, sodass fehlerhafte Segmente erst gar nicht in das Master-TM gelangen. Abbildung 1: Regex-Tagging und Non-Translatables in memoQ 2.3 Berechtigungskonzepte Neben der Frage, wie TMs bearbeitet werden sollen, ist vor allem auch die Frage wichtig, wer die entsprechenden Berechtigungen dazu erhalten soll. Diese Frage betrifft sowohl die Verwendung in laufenden Übersetzungsprojekten als auch die flankierende TM-Pflege. In Bezug auf die Verwendung in Übersetzungsprojekten stellt sich etwa die Frage, ob Übersetzer nur Leseoder auch Schreibzugriff auf bestimmte TMs erhalten sollen. Ein typischer Ansatz ist hier die Unterscheidung zwischen 1Für einen Überblick über die Verwendung regulärer Ausdrücke in CAT-Tools siehe Rudd (2018). 158 10 Übersetzungsdatenmanagement Master-TMs (die bereits übersetzte Texte enthalten) und Arbeits-TMs (die für jedes Projekt neu erstellt und in die neue Übersetzungseinheiten zunächst gespeichert werden). Indem man den Schreibzugriff der Übersetzer auf das Arbeits-TM beschränkt, kann verhindert werden, dass diese unerwünschte Änderungen in Master-TMs vornehmen. 2.4 Metadatenschema Metadaten sind Daten über andere Daten. Konkret handelt es sich bei diesen „anderen“ Daten im Fall von TMs sowohl um das TM als Ganzes als auch um die darin enthaltenen Übersetzungseinheiten. Die hier relevanten Metadaten zu deren Beschreibung lassen sich grob in drei Kategorien einteilen (vgl. Pomerantz 2015, Zielinski & Varga 2020): • Administrative Metadaten • Beschreibende Metadaten • Nutzungsbezogene Metadaten 2.4.1 Administrative Metadaten Administrative Metadaten werden automatisch generiert, wenn ein TM erstellt, neue Übersetzungseinheiten darin gespeichert oder bereits darin vorhandene Übersetzungseinheiten geändert werden. Sie geben Aufschluss über die Erstellung und Herkunft von TM-Daten. Typische Beispiele hierfür sind etwa Name und Version des Tools, mit dem ein TM erstellt wurde, die IDs der Nutzer, die die darin enthaltenen Übersetzungseinheiten erstellt haben, sowie die Zeitstempel ihrer Erstellung und/oder Änderung. Zu den administrativen Metadaten gehören auch sog. strukturelle Metadaten, die etwa Auskunft darüber geben, um welche Art von Text es sich bei einem Segment handelt (Überschrift, Listenelement etc.). Auch die in einer Übersetzungseinheit gespeicherten Kontextinformationen fallen in diese Kategorie. 2.4.2 Beschreibende Metadaten Beschreibende Metadaten enthalten zusätzliche Informationen zu einem TM oder den darin enthaltenen Übersetzungseinheiten. Typische Beispiele für beschreibende Metadaten sind etwa die IDs von Kunden oder Projekten sowie Angaben zu Fachgebiet, Textsorte, Produkt(familie), Kommunikationskanal etc. 159 Simon Varga Im Gegensatz zu administrativen Metadaten werden beschreibende Metadaten nicht automatisch generiert, sondern müssen von den NutzerInnen selbst definiert/ausgewählt werden. Gespeichert werden diese Informationen entweder in Metadatenfeldern, die standardmäßig von dem verwendeten TM-System bereitgestellt werden, oder aber in benutzerdefinierten Metadatenfeldern. Dies bietet einerseits Flexibilität bei der TM-Verwaltung, andererseits erschweren fehlende oder inkonsistente Metadaten die Zusammenführung von Übersetzungsdaten aus unterschiedlichen Quellen, selbst wenn sie alle aus demselben Tool stammen. Je nach Tool kann es unterschiedliche Optionen für das Speichern bestimmter beschreibender Metadaten geben. So verfügen etwa memoQ-TMs über eine Option zum automatischen Speichern des Namens oder Pfads der Datei, aus der eine Übersetzungseinheit stammt – in Trados Studio hingegen kann ein solcher Wert, wie alle beschreibenden Metadaten, standardmäßig nur manuell über die Projekteinstellungen eingegeben werden. Generell gilt: Wo immer möglich, sollten die Metadatenwerte in beschreibenden Feldern als Auswahllisten hinterlegt werden, um Inkonsistenzen durch Schreibvarianten, Rechtschreibfehler etc. zu vermeiden. Freitextfelder bleiben typischerweise auf diejenigen Metadaten beschränkt, die sich von Projekt zu Projekt ändern, z. B. der Projektname. 2.4.3 Nutzungsbezogene Metadaten Nutzungsbezogene Metadaten geben Aufschluss darüber, ob und wie oft, von wem und wann zuletzt individuelle Übersetzungseinheiten wiederverwendet wurden. Dies ermöglicht es etwa, alte/nicht (mehr) genutzte Übersetzungseinheiten zu löschen und so übermäßig große TMs gezielt zu bereinigen, um Performanceproblemen entgegenzuwirken. Darüber hinaus können entsprechende Informationen auch dazu genutzt werden, gezielte Qualitätssicherung für häufig wiederverwendete Übersetzungseinheiten zu betreiben. 3 Datenquellen identifizieren Nachdem die Zielsituation definiert und die erforderlichen Ressourcen erstellt wurden, gilt es, Quellen für existierende Übersetzungsdaten zu identifizieren. Hier sind natürlich zuallererst vorhandene TMs relevant, die bereits in der eigenen Organisation oder von Übersetzungsdienstleistern verwendet und (idealerweise) gepflegt werden. Darüber hinaus können jedoch auch andere Daten von Interesse sein, insbesondere wenn vorhandene TMs unvollständig oder von schlechter Qualität sind. Alternative Möglichkeiten, um 160 10 Übersetzungsdatenmanagement an Übersetzungsdaten zu gelangen, sind mehrsprachige Dokumente, XLIFFDateien aus vergangenen Übersetzungsprojekten oder auch mehrsprachige Exporte aus inhaltsführenden Systemen, wie etwa Content-Management- (CMS), Produktinformationsmanagement- (PIM) und Enterprise-Resource-PlanningSystemen (ERP). 4 Daten exportieren und migrieren Nachdem alle relevanten Datenquellen identifiziert wurden, müssen die Daten im nächsten Schritt in ein einheitliches Format gebracht werden. Mit Blick auf die Verwendung von Übersetzungsdaten in CAT-Tools bedeutet dies konkret, dass diese in das proprietäre Format des jeweiligen Tools überführt werden müssen. Das genaue Vorgehen dabei hängt von Art und Umfang der Übersetzungsdaten ab: So können etwa XLIFF-Dateien aus vergangenen Projekten in den CATEditor importiert und darüber in ein neues TM gespeichert werden. In mehreren Sprachen verfügbare Dokumente, aber u. U. auch mehrsprachige Exporte aus inhaltsführenden Systemen erfordern hingegen ein aufwendigeres Alignment. Der vermeintlich einfachste Weg, bestehende Übersetzungsdaten zu migrieren, ist der Austausch über den Translation-Memory-eXchange-Standard (TMX). In den folgenden Unterkapiteln werden dieser Standard sowie seine Umsetzung durch unterschiedliche CAT-Tool-Hersteller und die daraus entstehenden Herausforderungen bei Datenmigrationen skizziert. 4.1 Der TMX-Standard Der TMX-Standard hat die Aufgabe, den Datenaustausch zwischen Übersetzungssystemen unterschiedlicher Hersteller zu erleichtern. Entwickelt und veröffentlicht wurde er von der Fachgruppe Open Standards for Container/Content Allowing Re-use (OSCAR) der Localization Industry Standards Association (LISA). Nach einer ersten Version aus dem Jahr 1998 erfolgten mehrere Überarbeitungen, bis zur Veröffentlichung der aktuellen Version des Standards, TMX 1.4b, im Jahr 2005 (Localization Industry Standards Association 2005). Der TMX-Standard basiert auf der Extensible Markup Language (XML), einer Auszeichnungssprache zur Darstellung hierarchischer Datenstrukturen in Textform, die sowohl menschenals auch maschinenlesbar ist.2 Eine TMX-Datei muss dabei mindestens die in Abb. 2 dargestellten Elemente enthalten: 2Für einen Überblick über den Einsatz von XML in Übersetzung in Lokalisierung siehe Savourel (2001). 161 Simon Varga • Die XML-Deklaration. • Das Root-Element <tmx> inkl. der Version. • Einen Header mit Metadaten über die TMX-Datei. Diese geben an: –mit welchem Tool (<creationtool>) in welcher Version (<creationtoolversion>) die Datei erstellt wurde, –welche Systemsprache in dem Tool eingestellt war (<adminlang>), –welches Dateiformat das Translation Memory hatte, auf dessen Grundlage die TMX-Datei erstellt wurde (<o-tmf>), –welche Art von Daten die TMX-Datei enthält (<datatype>), –wie die darin enthaltenen Übersetzungen segmentiert sind, bspw. satzoder absatzbasiert (<segtype>), –welche Ausgangssprache sie hat (<srclang>). • Das <body>-Element mit den Translation Units (<tu>), die die eigentlichen Übersetzungsdaten enthalten. Abbildung 2: TMX-Beispieldokument mit verpflichtenden Elementen (in Anlehnung an ebd.) Neben diesen verpflichtenden Elementen können TMX-Dateien eine ganze Reihe weiterer Elemente enthalten: darunter eine Reihe von Elementen, die im TMX-Standard definiert sind, wie etwa Angaben von wem und wann eine Übersetzungseinheit erstellt oder geändert wurde (<creationid> und <creationdate> bzw. <changeid> und <changedate>). 162 10 Übersetzungsdatenmanagement Darüber hinaus können jedoch auch sogenannte Properties (<prop>) enthalten sein, die nicht Teil des Standards sind, sondern vom jeweiligen Tool vorgegeben werden. Die Schwierigkeiten, die sich daraus für den Austausch von Übersetzungsdaten zwischen unterschiedlichen Tools ergeben, werden im folgenden Kapitel beschrieben. 4.2 TMX-Kompatibilität vs. -Interoperabilität Idee und Ziel hinter der Entwicklung des TMX-Standards sind eindeutig: den Austausch von Übersetzungsdaten über verschiedene Installationen bzw. auch unterschiedliche Systeme hinweg zu ermöglichen. Betrachtet man die große Zahl an Übersetzungssystemen, die TMX implementiert haben,3so scheint dieses Ziel erreicht. Allerdings: So „nahtlos“, wie der Austausch häufig dargestellt wird (siehe etwa Chan 2015, Roturier 2020), ist er bei genauerem Hinsehen nicht. Tatsächlich basieren die Austauschformate vieler CAT-Tools zwar auf TMX, die Hersteller gehen bei der Umsetzung des Standards jedoch eigene Wege. Die dabei entstehenden TMX-„Dialekte“ sind mehr oder weniger interoperabel, jedoch bei weitem nicht voll miteinander kompatibel.4 Grob lässt sich hierzu Folgendes festhalten: Die in einem TM gespeicherten Übersetzungen lassen sich typischerweise – auch über verschiedene Systeme hinweg – problemlos(er) per TMX austauschen (wobei es auch hier Inkompatibilitäten geben kann, die zu Matchverlusten führen, etwa in Bezug auf die Auszeichnung von Tags!). Anders sieht es hingegen mit den Metadaten aus, die Informationen zu diesen Übersetzungen bereitstellen. Dies betrifft zunächst beschreibende Metadaten, die von unterschiedlichen Tools unterschiedlich umgesetzt werden. So gibt es: • TM-Systeme, die eine feste Auswahl an Feldern für beschreibende Metadaten vorgeben. Dies trifft beispielsweise auf Phrase zu, wo es die Felder Client,Business Unit,Domain,Subdomain und Note gibt. • TM-Systeme, die feste Felder für beschreibende Metadaten vorgeben, zusätzlich aber auch benutzerdefinierte Felder zulassen. Dies trifft etwa auf memoQ zu. Neben den Standardmetadatenfeldern Client,Project,Domain und Subject lassen sich in memoQ-TMs für eine feingliedrigere Auszeichnung benutzerdefinierte Felder anlegen. 3Für eine Liste mit Beispielen siehe Chan (2015). 4Toolspezifische Dialekte und die damit verbundenen Schwierigkeiten betreffen neben TMX auch andere Datenaustauschformate wie etwa TBX (TermBase eXchange, siehe Wright 2018). 163 Simon Varga • Auf-/absteigende Sortierung der Ergebnisse (alphabetisch oder auf Grundlage der Segment-ID oder des Datums der letzten Bearbeitung) • Bearbeitung von Metadaten im Batch-Verfahren • Suchen und Ersetzen von Zeichenfolgen in Ausgangsoder Zieltext (an beliebiger Stelle oder nur als ganze Wörter bzw. ganze Segmente) • Löschen aller/bestimmter Tags Wie diese Liste zeigt, zielen diese Optionen eher darauf ab, bestimmte Segmente gezielt herauszufiltern und zu bearbeiten als umfängliche Qualitätssicherung zu betreiben. Für umfangreichere Überprüfungen, etwa von Terminologieund Rechtschreibung, sind somit externe Tools erforderlich. Hier gibt es unterschiedliche Möglichkeiten: • Clienbasierte QA-Tools mit Unterstützung für TM-Dateien wie ErrorSpy, ApSIC Xbench und QA Distiller • Cloudbasierte Tools wie myproof (http://www.glossa.de/de/dienstleistungen/ glossa-myproof.html#myproofplatform) • TM-Bereinigungsskripte in Python oder anderen Programmiersprachen (siehe etwa Barbu 2015, Barbu u.a. 2016, Sabet u. a. 2016, Negri u. a. 2017) Dezidierte QA-Anwendungen wie diese verfügen typischerweise über einen deutlich höheren Funktionsumfang im Vergleich zu integrierten TM-Editoren in CAT-Tools. So bietet etwa ApSIC Xbench in seiner aktuellen Version 3.0 u. a. Funktionen zum Auffinden von nicht oder inkonsistent übersetzten Segmenten, Terminologiefehlern, Differenzen zwischen Zahlen, Tags, Sonderzeichen etc. in Ausgangsund Zielsegment und Wortwiederholungen. 6.2 TM-Bereinigung mit Large Language Models Large Language Models (LLMs) bieten heute eine Reihe neuer Möglichkeiten bei der Pflege und Bereinigung von Übersetzungsdaten. Ein Anwendungsfall, der dies eindrücklich zeigt, ist die Bereinigung von Terminologiefehlern. Klassische Terminologieprüfungen dienen lediglich dem Auffinden von Segmenten mit potenziellen Terminologiefehlern. Eine automatische Korrektur (oder auch nur eine halbautomatische mittels Suchen und Ersetzen) war bei Terminologiefehlern jedoch bislang in den allermeisten Fällen nicht möglich. Problematisch waren in 170 10 Übersetzungsdatenmanagement diesem Zusammenhang sowohl flektierte Formen der Benennung als auch abhängige Wörter wie Adjektive, Artikel, Pronomen etc. Eine einfache Ersetzung von Benennungen hätte damit in der Vergangenheit unweigerlich zu Folgefehlern geführt. LLMs bieten nun erstmals die Möglichkeit, nicht nur inkorrekte Benennungen zu ersetzen, sondern auch alle erforderlichen grammatischen Anpassungen in deren Umfeld vorzunehmen – also etwa a) Artikel, b) Flexionsendungen und c) Pronomen zu ändern (siehe Abb. 8). Abbildung 8: Terminologiekorrektur mit ChatGPT (Zielinski & Varga 2024) Ob LLMs dabei als Ersatz oder Ergänzung klassischer Qualitätsprüfungen eingesetzt werden, hängt nicht zuletzt von wirtschaftlichen Überlegungen ab: Je nach Kosten des verwendeten Modells und Menge der zu prüfenden Daten kann es so etwa vorteilhaft sein, zunächst mit klassischen Methoden problematische Segmente zu identifizieren und nur diese dann gezielt mithilfe von LLMs korrigieren zu lassen. Unabhängig davon stellt sich die Frage, wie automatisch per LLM korrigierte Übersetzungseinheiten in Produktionsprozesse integriert werden. Unter bestimmten Voraussetzungen ist eine manuelle Überprüfung der angepassten Übersetzungseinheiten denkbar, bevor diese eingesetzt werden: dann etwa, wenn die erforderlichen Ressourcen vorhanden, die Datenmengen überschaubar und ihre Kritikalität hoch ist. Eine weitere Möglichkeit ist die Auszeichnung der ge171 Simon Varga änderten Segmente mit entsprechenden Metadatenwerten, die dann in den TMEinstellungen mit einer Penalty belegt werden können. Dadurch ist gewährleistet, dass automatisch geänderte Übersetzungseinheiten in Übersetzungsprojekten nicht als Kontextmatches erscheinen, sondern auf jeden Fall vom Übersetzungsdienstleister geprüft und ggf. bearbeitet werden. 7 Daten annotieren und harmonisieren Nach Analyse und Bereinigung der Übersetzungsdaten müssen diese anhand des neuen Metadatenschemas annotiert und harmonisiert werden. Ein wichtiger Schritt ist in diesem Zusammenhang die Ergänzung fehlender beschreibender Metadatenwerte. Diese können mithilfe unterschiedlicher Ansätze ermittelt werden, entweder anhand vorhandener Metadaten oder aber auf Grundlage der in den Übersetzungseinheiten enthaltenen Texte selbst. Die Kreuzung von Metadatenwerten kann dabei auf unterschiedliche Weise erfolgen. So lassen etwa beschreibende Metadaten wie Projektoder Dateinamen potenziell Rückschlüsse auf Content-Typen oder Fachgebiete zu. Gleiches gilt u. U. auch für administrative Metadaten, wenn z. B. ein bestimmter Content-Typ ausschließlich von einem festen Übersetzungsdienstleister bearbeitet wurde. Letztendlich sind die Möglichkeiten in diesem Bereich durch die vorhandenen Metadaten vorgegeben. Sind aus diesen keine Rückschlüsse auf die Inhalte von Übersetzungsdaten möglich, so besteht unter bestimmten Umständen auch die Möglichkeit, die Segmente selbst auf ihre Zugehörigkeit zu relevanten Kategorien hin zu untersuchen, und zwar anhand der der darin verwendeten Terminologie. Hierzu ein einfaches Beispiel: Liegen TMs mit Übersetzungen vor, die von verschiedenen Abteilungen – z. B. Marketing und Technische Dokumentation – in Auftrag gegeben wurden, können diese potenziell durch die darin vorkommenden Benennungen voneinander unterschieden werden. Voraussetzung hierfür ist natürlich zunächst, dass es zwischen den Inhalten beider Abteilungen terminologische Unterschiede gibt; darüber hinaus muss eine Terminologiedatenbank mit entsprechend gelabelten Einträgen existieren (bzw. angelegt werden!). 8 Daten anreichern Wie in den bisherigen Abschnitten deutlich wurde, befasst sich Übersetzungsdatenmanagement nicht nur mit der Verwaltung und Pflege von TMs, sondern auch mit flankierenden Ressourcen und Prozessen, die sich unmittelbar auf die Nutzbarkeit der Übersetzungsdaten auswirken – also etwa Segmentierungsregeln und 172 10 Übersetzungsdatenmanagement Non-Translatables. Eine weitere zentrale Tätigkeit ist in diesem Zusammenhang die Generierung von Übersetzungsdaten. Ob und in welchem Umfang eine solche erforderlich sein kann, hängt vom Zweck und den Zielen ab, zu denen die Übersetzungsdaten eingesetzt werden sollen. In klassischen Übersetzungsworkflows etwa ist der Wert solcher synthetischer Daten gegenüber „organischen“ TM-Treffern eher gering einzustufen: Einzelne Fuzzy-Matches genügen hier, um eine konsistente Übersetzung neuer Inhalte zu ermöglichen. Anders sieht es jedoch im Bereich MÜ-Training/-Customization bzw. MÜ-Output-Customization aus. Hier können automatisch generierte Übersetzungseinheiten die Qualität des MÜ-Outputs verbessern. Interessant ist diese Möglichkeit vor allem für Anwendungsfälle, in denen authentische Trainingsdaten nicht in ausreichender Menge vorhanden sind – was aus Sicht von Organisationen mit spezifischer Corporate Language eher die Regel als die Ausnahme darstellt. Es gibt eine Reihe von Möglichkeiten, synthetische Trainingsdaten zu generieren, von denen an dieser Stelle zur Illustration zwei kurz genannt werden sollen: die sogenannte Back-Translation und die Umformulierung existierender Übersetzungseinheiten. Back-Translation bezeichnet die Generierung zweisprachiger Trainingsdaten durch die maschinelle Übersetzung zielsprachlicher Inhalte in die gewünschte Ausgangssprache (Sennrich u.a. 2016, Edunov u. a. 2018). Das Ergebnis sind korrekte Zielsegmente mit einem oder mehreren (potenziell fehlerhaften!) maschinell übersetzten Ausgangssegmenten (Imamura & Sumita 2019). In diesem Zusammenhang können nicht nur monolinguale Daten (also nicht übersetzte Texte) verwendet werden, sondern auch die Zielsegmente bereits existierender Übersetzungseinheiten, zu denen alternative Ausgangssegmente generiert werden. Die Umformulierung bestehender Übersetzungseinheiten wiederum kann sowohl auf Ausgangsals auch auf Zielsegmente angewendet werden. Die konkreten Möglichkeiten sind hier vielfältig: So können etwa negierte Varianten von Sätzen erstellt werden (Wetzel & Bond 2012). Ein weiterer Ansatz besteht darin, Entitäten, wie etwa Personenund Städtenamen, durch andere Entitäten derselben Kategorie zu ersetzen und so verschiedene Varianten derselben Übersetzungseinheit zu erstellen (Winter & Zielinski 2020). Auch hier ermöglichen LLMs unterschiedlichste Transformationen, ohne dass hierfür aufwendige Methoden und Skripte entwickelt werden müssen – im einfachsten Fall mithilfe eines simplen Prompts, der bestehende Segmente rein syntaktisch variiert. Unabhängig vom gewählten Ansatz müssen synthetische Daten in nachgelagerten Prozessen eindeutig identifizierbar bleiben, indem sie etwa in separaten TMs gespeichert, mindestens aber mit entsprechenden Metadaten ausgezeichnet 173 Simon Varga und mit einer Penalty belegt werden. Ob und wie sie in klassische Übersetzungsprozesse eingebunden werden, hängt von der eingesetzten MÜ-Technologie ab: Bei Training/Customization von MÜ-Modellen sind sie nicht als Ressource in die eigentliche Übersetzung eingebunden. In den letzten Jahren zeichnet sich für viele Anwendungsfälle allerdings ein anderer Trend ab: Anstatt aufwendig MÜ-Modelle zu trainieren oder zu customizen, wird mithilfe sogenannter „adaptiver“ MÜ der Output des Modells selbst auf Grundlage der zur Verfügung stehenden Referenzübersetzungen angepasst (mittlerweile typischerweise mithilfe von LLMs!). 9 Daten integrieren Nach Abschluss ihrer Aufbereitung können die Übersetzungsdaten dann in die relevanten Systeme und Prozesse integriert werden, im einfachsten Fall etwa durch Import in lokale bzw. serveroder cloudbasierte TMs. Werden die Daten hingegen (auch) an anderer Stelle benötigt, bspw. für MÜ-Training/- Customization, müssen ggf. vorab geeignete Austauschformate und -routinen definiert werden. 10 Daten überwachen und pflegen Übersetzungsdatenmanagement ist ein kontinuierlicher, aktiver Prozess. Nach ihrer initialen Aufbereitung und Bereitstellung müssen Qualität und Performance der Daten überwacht werden. Hierfür bieten sich APIs an, über die ein kontinuierliches Monitoring durchgeführt werden kann, ohne dass die Daten aus laufenden Prozessen genommen werden müssen. Prinzipiell kommen auch hier etwa die in Abschnitt 5.2 vorgestellten Analysedimensionen zur kontinuierlichen Qualitätssicherung in Frage. Grundsätzlich sind jedoch Qualitätssicherungsmaßnahmen an der Quelle, also in laufenden Übersetzungsprojekten, die effektivsten Garanten für die Qualität von Übersetzungsdaten. Das Augenmerk sollte also auch und vor allem auf der Fehlervermeidung in den Übersetzungsprozessen selbst liegen – u. a. durch die in Abschnitt 2.2 genannten Maßnahmen. Dadurch werden nicht nur Qualitätsprobleme in den Übersetzungsdaten, sondern auch in den eigentlichen mehrsprachigen Inhalten vermieden – schließlich ist ein Fehler in den Übersetzungsdaten immer auch ein Fehler an anderer Stelle! 174 10 Übersetzungsdatenmanagement 11 Ausblick In den letzten Jahren haben Übersetzungsdaten zunehmend an Aufmerksamkeit gewonnen. Schließlich sind sie nicht mehr nur reine Übersetzungshilfen in von außen typischerweise unsichtbaren Prozessen, sondern können auch für andere Zwecke eingesetzt werden.5Wie bei anderen Daten auch hängt ihre Eignung für diese intendierten Einsatzzwecke – ihre fitness for use (Wang 1998) – dabei von explizit zu definierenden Qualitätskriterien ab, für deren Einhaltung ein aktives Datenmanagement unerlässlich ist. Ein solches setzt, wie aus den vorangegangenen Kapiteln deutlich wurde, eine ganze Reihe von Maßnahmen und entsprechenden Kompetenzen voraus, sei es auf technischer, organisatorischer oder prozessualer Ebene. Die Ausführungen hierzu bezogen sich in diesem Kapitel auf den aktuell vorherrschenden technischen Standard für die Speicherung von Übersetzungsdaten, nämlich in Form fein segmentierter Übersetzungseinheiten in Translation Memorys. Dieser Ansatz, Inhalte auf möglichst kleine, wiederverwendbare Einheiten herunterzubrechen, ist auch in der Content-Erstellung seit Jahren Standard, wie sich etwa an Component-Content-Management-Systemen (CCMS) in der technischen Redaktion deutlich erkennen lässt. Dabei handelt es sich aber keineswegs um den einzigen Ansatz: So halten Tools wie STAR Transit Übersetzungsdaten in Form von Referenzdokumenten ohne Feinsegmentierung vor. War dieser Ansatz bislang die Ausnahme, so könnten die aktuellen technologischen Entwicklungen ihn in Zukunft aus seinem Nischendasein holen: Die neuesten Generationen von Übersetzungssystemen sind mittlerweile nicht nur in der Lage, wesentlich umfassendere Kontexte einzubeziehen, als durch klassische Segmentgrenzen vorgegeben sind – sie liefern auch potenziell bessere Ergebnisse, wenn ihnen mehr Kontext zur Verfügung steht! Dies ist der Fall bei LLMs, aber auch bei NMÜ. Dies wird zunehmend zu Nachteilen führen, wenn etwa Texte aus CAT-Tools weiterhin segmentweise statt im Kontext maschinell übersetzt werden (siehe Abb. 9 und 10): Unberührt von einem möglicherweise bevorstehenden Paradigmenwechsel bleibt die Erkenntnis, dass datengetriebene Anwendungen und Prozesse nur so gute Ergebnisse liefern können, wie die Daten es zulassen. Für Hochschulen in der Übersetzerausbildung scheint also eine stärkere Einbeziehung von Aspekten 5Die Erwartungen an ihr Monetisierungspotenzial, die im Zuge der Verbreitung trainierbarer NMÜ-Modelle aufkamen, scheinen sich jedoch – zumindest bislang – nicht zu bewahrheiten. So wurde etwa der von der Translation Automation User Society (TAUS) im Jahr 2020 geschaffene Data Marketplace, auf dem Übersetzungsdaten gehandelt werden konnten, Anfang 2024 wieder eingestellt. 175 Simon Varga Abbildung 9: Maschinelle Übersetzung segmentierter Texte in memoQ mit DeepL (Zielinski & Varga 2024) Abbildung 10: Maschinelle Übersetzung unsegmentierter Texte im DeepL-Webeditor (Zielinski & Varga 2024) wie Data Literacy (Krüger 2022), Engineering und (Daten-)Prozessmanagement geboten, damit ihre Studierende auch lernen, mit Datenmengen umzugehen, die mit klassischen Übersetzungsstrategien nicht zu bewältigen sind. Literatur Barbu, Eduard. 2015. Spotting false translation segments in translation memories. In Proceedings of the Workshop on Natural Language Processing for Translation Memories (NLP4TM), 9–16. Hissar, Bulgaria. 176 10 Übersetzungsdatenmanagement Barbu, Eduard, Carla Parra Escartın, Luisa Bentivogli, Matteo Negri, Marco Turchi, Marcello Federico, Luca Mastrostefano & Constantin Orasan. 2016. 1st Shared Task on automatic translation memory cleaning preparation and lessons learned. In Proceedings of the 2nd Workshop on Natural Language Processing for Translation Memories (NLP4TM), 1–5. Portorož. Batini, Carlo & Monica Scannapieco. 2016. Data Quality Dimensions. In Carlo Batini & Monica Scannapieco (Hrsg.), Data and information quality. Dimensions, principles and techniques (Data-Centric Systems and Applications), 19–49. Cham: Springer International Publishing. Chan, Sin-Wai. 2015. Computer-aided translation: Major concepts. In Sin-Wai Chan (Hrsg.), The Routledge encyclopedia of translation technology, 32–67. Oxon, New York: Routledge. Edunov, Sergey, Myle Ott, Michael Auli & David Grangier. 2018. Understanding back-translation at scale. In Proceedings of the 2018 Conference on Empirical Methods in Natural Language Processing, 489–500. Brussels, Belgium: Association for Computational Linguistics. DOI: 10.18653/v1/D18-1045. Imamura, Kenji & Eiichiro Sumita. 2019. Long warm-up and self-training: Training strategies of NICT-2 NMT system at WAT-2019. In Proceedings of the 6th Workshop on Asian Translation, 141–146. Hong Kong: Association for Computational Linguistics. DOI: 10.18653/v1/D19-5217. Khayrallah, Huda & Philipp Koehn. 2018. On the impact of various types of noise on neural machine translation. In Proceedings of the 2nd Workshop on Neural Machine Translation and Generation, 74–83. Melbourne, Australia: Association for Computational Linguistics. DOI: 10.18653/v1/W18-2709. Krüger, Ralph. 2022. Integrating professional machine translation literacy and data literacy. Lebende Sprachen 67(2). 247–282. DOI: 10.1515/les-2022-1022. Localization Industry Standards Association. 2005. TMX 1.4b Specification. https: //www.gala-global.org/tmx-14b (11 September, 2024). Moorkens, Joss. 2015. Consistency in translation memory corpora: A mixed methods case study. Journal of Mixed Methods Research 9(1). 31–50. DOI: 10.1177/ 1558689813508226. Negri, Matteo, Duygu Ataman, Masoud Jalili Sabet, Marco Turchi & Marcello Federico. 2017. Automatic translation memory cleaning. Machine Translation 31(3). Number: 3, 93–115. DOI: 10.1007/s10590-017-9191-5. O’Brien, Sharon & Johann Roturier. 2007. How portable are controlled language rules? A comparison of two empirical MT studies. In Proceedings of MT Summit XI, 345–352. 177 Simon Varga Ott, Myle, Michael Auli, David Grangier & Marc’Aurelio Ranzato. 2018. Analyzing uncertainty in neural machine translation. In Proceedings of the 35th International Conference on Machine Learning (Proceedings of Machine Learning Research 80), 3956–3965. http://arxiv.org/abs/1803.00047 (3 März, 2020). Pomerantz, Jeffrey. 2015. Metadata (The MIT Press Essential Knowledge series). Cambridge, London: The MIT Press. Roturier, Johann. 2020. XML for translation technology. In Minako O’Hagan (Hrsg.), The Routledge handbook of translation and technology, 45–60. London, New York: Routledge. Rudd, Anthony. 2018. Practical usage of regular expressions. An introduction to regexes for translators. 4th edition. Germany. Sabet, Masoud Jalili, Matteo Negri, Marco Turchi, José G. C. de Souza & Marcello Federico. 2016. TMop: A tool for unsupervised translation memory cleaning. In Proceedings of ACL-2016 System Demonstrations, 49–54. Berlin: Association for Computational Linguistics. Savourel, Yves. 2001. XML internationalization and localization. Carmel, Indiana: Sams. Scannapieco, Monica, Paolo Missier & Carlo Batini. 2005. Data quality at a glance. Datenbank-Spektrum 14. 6–14. Sennrich, Rico, Barry Haddow & Alexandra Birch. 2016. Improving neural machine translation models with monolingual data. In Proceedings of the 54th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), 86–96. Berlin: Association for Computational Linguistics. DOI: 10.18653/ v1/P16-1009. Wang, Peng. 2016. The datafication of translation. In TAUS (Hrsg.), Keynotes 2015. A review of the TAUS October events, 11–14. Amsterdam: TAUS Signature Editions. Wang, Richard Y. 1998. A product perspective on total data quality management. Communications of the ACM 41(2). 58–65. DOI: 10.1145/269012.269022. Wetzel, Dominikus & Francis Bond. 2012. Enriching parallel corpora for statistical machine translation with semantic negation rephrasing. In Proceedings of SSST-6, 20–29. Jeju, Korea: Association for Computational Linguistics. Winter, Tom & Daniel Zielinski. 2020. Terminologie in der maschinellen Übersetzung. In Jörg Porsiel (Hrsg.), Maschinelle Übersetzung für Übersetzungsprofis, 210–233. Berlin: BDÜ Fachverlag. Wolff, Friedel. 2016. Combining off-the-shelf components to clean a translation memory. Machine Translation 30(3–4). 167–181. 178 10 Übersetzungsdatenmanagement Wright, Sue Ellen. 2018. TBX dialects. Making exchange work for you. In Barbara Ahrens, Lisa Link, Ute Barbara Schilly & Ursula Wienen (Hrsg.), Verschmitzt! Von Terminologie und Terminologen. Festschrift für Klaus-Dirk Schmitz, 223–241. Berlin: Frank & Timme. Zielinski, Daniel & Simon Varga. 2020. Translation memory quality and translation memory management. In Jean-Marc Dalla-Zuanna & Christropher Kurz (Hrsg.), Translation quality in the age of digital transformation, 300–319. Berlin: BDÜ Fachverlag. Zielinski, Daniel & Simon Varga. 2024. Super-charge your language data with and for AI. tcworld. 30–34. https://www.tcworld.info/e-magazine/translationand-localization/super-charge-your-language-data-with-and-for-ai-1318. 179