Übersetzung des c-rex.net-Blogs mit MT
Das Szenario
Unsere c-rex.net-Blogbeiträge werden in oXygen XML Editor in einer DITA/XML-Umgebung erstellt.
Übersetzt werden die DITA-Quelldateien. Und zwar direkt, ohne den Einsatz eines Translation-Memory-Systems.
Der Grund für die Wahl dieser Konstellation?
Wir sind davon überzeugt, dass in Zukunft Machine Translation ohne Humanübersetzung eine zentrale Rolle spielen wird. Deshalb haben wir ein entsprechendes Übersetzungsszenario aufgebaut und stellen es Ihnen hier vor.
Dieses Szenario ist sicher nicht für jede Art von Texten geeignet. Es gibt weiterhin Anwendungsfälle, bei denen eine Translation-Memory gesteuerte Übersetzung durch Humanübersetzung die geeignete Wahl ist.
Wir sind sicher: Es gibt deutlich mehr Fälle als viele glauben, in denen ein so oder ähnlich automatisierter Prozess, wie wir ihn umgesetzt haben, der richtige ist!
Schauen wir uns den Prozess einmal im Detail an!
Drei Klicks und die Übersetzung ist fertig
Wir haben eine Tool-Landschaft aufgebaut, in der die technische Redaktion den gesamten Prozess von der Erstellung über die Übersetzung bis hin zur Publikation in einer Umgebung durchführt.
Alles aus einer Hand mit einem sehr hohen Automatisierungsanteil!
Nachdem ein Blogbeitrag in Deutsch fertig ist, starten wir vorkonfigurierte Transformationsszenarien, die den gesamten Übersetzungsprozess innerhalb weniger Sekunden ausführen.
Die übersetzten Dateien schieben wir dann in den Ordner der Zielsprache.
Es folgt die HTML-Publikation – ebenfalls anhand eines Transformationsszenarios, das wir eingerichtet haben.
Was hinter dieser 'Magie' steckt, welche automatischen Abläufe sich dahinter verbergen, das können Sie in den nächsten Abschnitten nachlesen.
Unsere Redaktionsumgebung
Wie läuft unser MT-Übersetzungsprozess ab? Welche Tools sind im Einsatz?
-
dem XML-Editor Oxygen XML Editor
-
c-rex.net DITA-OT-Plug-ins zur Erweiterung des DITA-OT Frameworks
-
unserem Cloud-Dienst Data Transformation Service DTS
-
der Machine Translation Engine DeepL
Wir arbeiten mit folgenden Tools:
Datensammlung und Datenorganisation über DITA-OT-Plug-ins
Selbst entwickelte Plug-ins, die das DITA-OT-Framework erweitern, setzen wir ein, um Daten zu sammeln, zu organisieren und so zusammenstellen, dass sie anschließend mit c-rex.net DTS verarbeitet werden können.
Diese Plug-ins integrieren die Funktionalität und den Zugriff auf den Cloud Service DTS nahtlos in die DITA-Standardprozesse.
Sie stehen unseren KundenKundinnenKunden und KundinnenKund:innen nach Abschluss einer Testphase als Standard-Erweiterungen für DTS zur Übernahme in bestehende DITA-OT-Integrationen zur Verfügung.
-
Sammeln der zu übersetzenden Dateien. Dabei werden in unserem Fall die Referenzen ignoriert (xref, conref, Grafiken). Dieses Verhalten kann bei Bedarf per Konfiguration der Schnittstelle angepasst werden.
-
Zippen der Dateien
Verschicken der zip-Pakete an den c-rex.net Data Transformation Service DTS
-
DTS übersetzt die Dateien in unserem Fall über DeepL und liefert das übersetzte zip-Paket zurück.
Selbstverständlich können auch alternative Machine Translation Engines wie Google, Bing oder andere eingebunden werden.
Das Zip-Paket enthält
-
einen Report
-
XLIFF-Dateien in der Ausgangssprache
-
zweisprachige XLIFF-Dateien mit der Ausgangssprache und den DeepL-Übersetzungen
-
übersetzte DITA-XML-Ressourcen (in unserem Fall ohne Grafiken und verlinkte Topics)
-
-
Entpacken des Übersetzungsergebnisses
-
Kopieren abhängiger Ressourcen in das Ausgabeverzeichnis, so dass die DITA-Map wieder vollständig ist
Der Prozess der Datensammlung und Datenorganisation läuft so ab:
Übersetzungsprozess auf dem DTS-Server
-
Generierung eines XLIFFs für jede zu übersetzende Datei
-
Auszeichnen der Übersetzung anhand der ITS Rules
Custom Rules können im DITA-OT-Plug-in mitgegeben werden.
-
Segmentierung der Übersetzungseinheiten auf Basis von SRX Rules
Custom Rules können im DITA-OT-Plug-in mitgegeben werden.
-
Auflösung der Variablen in Plain-Text
Für DeepL lösen wir Variablen (keyrefs) auf und geben sie zusammen mit dem zu übersetzenden Text in die Übersetzung. Das hat sich für DeepL bewährt, um die Qualität der Übersetzung zu erhöhen, vor allem was die Grammatik betrifft.
Gibt man sie nicht mit und hat einen Genderterm im Plural definiert, liefert DeepL beispielsweise die Übersetzung für Singular zurück.
Andere Machine Translation Engines verhalten sich hier anders; deshalb ist das Verhalten an diesen und anderen Stellen konfigurierbar.
-
Automatische Kennzeichnung von bestimmten Inhalten
Für das wichtige Thema Unternehmensterminologie haben wir in unserer Redaktionsumgebung eine Terminologiedatenbank angelegt, in der wir Begriffe, Zitate und andere Texte zusammen mit der von uns gewünschten Übersetzung hinterlegen.
Das könnte man auch mit Variablen machen. Wir haben uns jedoch für den Einsatz einer Terminologiedatenbank im tbx-Format entschieden.
Die korrekte Übersetzung dieser Begriffe ist essentiell. Wir meinen sogar, dass sie wichtiger ist, als dass der Text drum herum korrekt übersetzt wird.
Und nach diesen Begriffen suchen wir in diesem Prozessschritt und zeichnen sie automatisiert aus, um sie im Übersetzungsprozess entsprechend behandeln zu können.
So muss sich niemand bei der Erstellung darum kümmern.
-
-
Aufbereitung der Daten für DeepL
-
Die Unterstützung strukturierter Daten ist in DeepL rudimentär, auch wenn DeepL einen Konfigurationsschalter für XML hat. Es wird aber kein XML an sich verarbeitet, sondern es werden minimal andere Prüfroutinen im Plain-Text eingesetzt.
-
Deshalb lösen wir tiefgeschachtelte XML-Strukturen in DITA und in den resultierenden XLIFFs so weit auf, dass ein String möglichst nahe am optimalen Plain-Text generiert und an DeepL zur Übersetzung gegeben wird.
So reduzieren mögliche Fehlerquellen beim Behandeln von Tags auf ein Minimum.
-
An DeepL übergeben wir auch nicht zu übersetzenden Inhalte wie Variablen, so dass DeepL den vollständigen Kontext für die Übersetzung hat und damit eine gute Übersetzung liefert.
-
Maschinell übersetzte Inhalte werden in das Element 'target' im XLIFF geschrieben.
-
-
XLIFF nach DITA zurück exportieren
-
Im Weg zurück werden nicht zu übersetzende Inhalte wieder durch den Text im Ausgangsdokument ersetzt. Dies gilt auch für Variablen und die auto-getaggten Inhalte.
Dabei entfernen wir die Texte in den 'keyrefs' und ersetzen den von DeepL übersetzten Begriff bei den auto-getaggten Inhalten wieder durch den Text aus der tbx-Termdatenbank.
Das führt dann gelegentlich zu dem Problem, dass mal ein Wort oder Anführungszeichen entfernt wird, weil DeepL diese in die Tags schreibt und wir diese beim Ersetzungsvorgang mit überschreiben.
-
Abschließend wird das DITA-Dokument mit Hilfe des Skeleton aus den Inhalten des Elements target wieder aufgebaut.
-
Der c-rex.net Data Transformation Service führt die folgenden Operationen durch:
Darstellung der Übersetzung im c-rex.net-Blog
In unserem Blog ist eine Auswahlmöglichkeit für Übersetzungsvarianten integriert.
-
der automatischen Übersetzung durch DeepL,
-
der Variante, die durch automatisierte Nachbearbeitung durch c-rex.net entstanden ist
-
und einer vergleichenden Darstellung beider Varianten.
Sie können wählen zwischen
Zusammenfassung und Ausblick
Lassen Sie uns zusammenfassen. Was hat uns der Blick hinter die Kulissen gezeigt?
-
Der Einsatz der DITA-OT-Plug-ins und die damit erreichte Integration der DTS Cloud Services in den DITA-Standardprozess führt zu einem hohen Grad an Automatisierung und sehr schnellen Übersetzungsergebnissen.
-
Die Arbeit mit einer Terminologiedatenbank, um Unternehmensterminologie, wichtige Begriffe, Zitate mit einer feststehenden Übersetzung zu versehen, ist essentiell.
-
Die Übersetzungsqualität ist gut. Es gibt einige Unschönheiten und auch Fehler, mit denen wir jedoch gut leben können. Wir hoffen, unsere LeserLeserinnenLeser und LeserinnenLeser:innen auch!
Wie eignet sich Machine Translation für unseren Blog?
-
Für den Bereich Technische Dokumentation ist das hier beschriebene Szenario auch sehr gut geeignet.
Denn es gibt sowohl Inhalte, die einem 100% Qualitätsanspruch genügen müssen, als auch solche, bei denen das nicht der Fall ist.
-
Über Metadaten, gerade beim Einsatz von CCMS oder DITA, kann man den Prozess steuern und die Übersetzung von kritischen Inhalten (Sicherheitshinweisen, rechtlichen Texten) von der Übersetzung der restlichen Texte trennen.
Kritische Inhalte würden in einem solchen Szenario niemals über den MT-Prozess und immer über den Translation-Memory-Prozess mit Humanübersetzung laufen.
-
In anderen Fällen kann man das kombinieren, zunächst über MT wegen der Durchlaufzeit (Anwender warten auf Infos) und im Anschluss über den Humanübersetzungs-Prozess für den hohen Qualitätsanspruch.
Und wie sieht es mit Machine Translation im Bereich Technische Dokumentation aus?
