Bei Übersetzungen für die IT-Branche bekommt man es unweigerlich auch mit XML-Daten zu tun. Einige davon enthalten Sprachstrings, die mit den Dateifiltern von Trados Studio einfach für die Übersetzung ausgelesen werden können. In diesem Fall wird die Übersetzung genau dort hingeschrieben, wo der quellsprachliche String stand und der Kunde bekommt ohne weiteres die übersetzte XML-Datei. Anders sieht die Sache aus, wenn zwei oder mehr Sprachen vom XML erfasst werden…
Die üblichen Trados-Filter erlauben die Markierung bestimmter Elemente (im DOM: « Nodes ») oder Attribute als « zu übersetzen » oder « nicht zu übersetzen ». Für XML, das nur eine Sprache enthält, die übersetzt werden soll, reicht das problemlos aus. Leider kann man Quell-, Ziel- und Kontextelemente im Dateifilter nicht separat angeben.
Bei mehrsprachigem XML müsste man aber idealerweise eine Quellnode angeben, die nur gelesen werden kann und die im TagEditor unveränderlich in der Quellspalte angezeigt wird, dazu eine Zielnode, die ausgelesen wird (vorhandene Übersetzungen beibehalten!), in der rechten Spalte des TagEditors übersetzt oder bearbeitet wird und deren Inhalte nach dem Übersetzen in diese Zielnode (zurück-)geschrieben werden. Und schließlich Kommentar- und Kontextnodes, die als Kommentar angezeigt werden und die in der Dateivorschau berücksichtigt sind.
Eine XML Beispieldatei:
<?xml version="1.0" encoding="UTF-8"?> <!-- ################################################################ --> <!-- Anzahl Anwendungsmeldungen: 2 --> <!-- Anwendung: XYZ --> <!-- ################################################################ --> <anwendungsmeldungen> <anwendungsmeldung id="XYZ00001"> <text><![CDATA[Die Verbindung konnte nicht aufgebaut werden: {0}.]]></text> <translation><![CDATA[ La connexion a échoué : {0}. ]]></translation> </anwendungsmeldung> <!-- ################################################################ --> <anwendungsmeldung id="XYZ00002"> <text><![CDATA[ Falsches Datum {0} im Feld "{1}": Geben sie ein Datum nach dem {2} an. ]]></text> <translation><![CDATA[ ]]></translation> </anwendungsmeldung> <!-- ################################################################ --> </anwendungsmeldungen> </xml>
Möglichkeit 1: Handarbeit
Wenn Trados nur in die Zielnode (im obigen Beispiel translation
) schreiben soll, kommt man scheinbar nicht darum herum, alle Quellstrings in die Zielstrings zu kopieren. Im schlimmsten Fall würde das manuell geschehen, fehleranfällig sein und ewig brauchen.
Möglichkeit 2: Suchen und Ersetzen
Ein wenig besser ist ein Editor wie Notepad++, der in der Funktion Suchen & Ersetzen mit regulären Ausdrücken umgehen kann. Dann kann man nach dem Inhalt von text
-Elementen suchen und diese automatisch in translation
-Elemente einfügen.
In diesem Fall würde man aber immer noch vor der Wahl stehen, entweder alle schon vorhandenen Zielstrings zu überschreiben oder im Zielstring plötzlich sowohl den kopierten Ausgangstext als auch den schon vorhandenen Quelltext hintereinander stehen zu haben. Wenn man bedenkt, dass Trados im TagEditor diesen kombinierten, mehrsprachigen String als « Quelle » ansieht, « verseucht » man sich also das Translation Memory mit Einträgen, die später ohnehin keine Matches mehr hervorbringen.
Möglichkeit 3: Der Umweg über CSV und Excel
Dieser Weg geht den Umweg über Excel, weil man mit dem Ausblenden von Spalten sehr gut steuern kann, was Trados übersetzen soll und was nicht. Außerdem kann man neben den ID-, Quell- und Zielspalten eine vierte Spalte mit einer Formel füllen, die entweder den Quellstring anzeigt, wenn das Ziel leer ist, oder den vorhandenen String, wenn die Zielspalte nicht leer ist: =WENN([@translation]="0";[@text];[@translation])
Dann blendet man alle Spalten aus außer der letzten, und übersetzt diese in Trados. Nachteil: Man sollte auf dem zweiten Monitor die Exceltabelle als Referenz offen haben, um zu prüfen, ob sich der Quellstring geändert hat, wenn in der linken TagEditor-Spalte ein Satz in der Zielsprache erscheint. Die fertige Tabelle kann dann wieder in XML umgewandelt werden, wobei man natürlich die neue Spalte als translation
-Element festlegt.
Diesen Weg bin ich (zu?) lange gegangen:
- Vorbereitung des XML mit Notepad++:
- Header und Footer manuell entfernen
- Suche:
<anwendungsmeldung id="(.*?)">\n<text><!\[CDATA\[\n(.*?)\n\]\]></text>\n<translation><!\[CDATA\[\n(.*?)\n\]\]></translation>\n</anwendungsmeldung>
und Ersetze mit:
$1\t$2\t$3
, um drei tabulatorgetrennte Spalten zu erhalten: ID, Quelle, Ziel.
- Suche:
<!-- #+ -->
und Ersetze mit: (nichts), um die inhaltslosen Trenner loszuwerden
- Die Textdatei als .CSV (Texttabelle) speichern
- CSV mit Excel öffnen und die zu übersetzende Arbeitsspalte mit der oben genannten Formel generieren, die anderen Spalten ausblenden und als XLSX speichern.
- In Trados übersetzen.
- In Excel alle Spalten wieder einblenden, die neu übersetzte Arbeitsspalte in die Zielspalte kopieren und dann löschen. Das Resultat mit den Spalten ID, Quelle, Ziel wieder als « Text » speichern (tabulatorsepariert, Zeichensatz UTF-8).
- Nachbereitung mit Notepad++:
- Suche:
^(.*?)\t(.*?)\t(.*?)[\t\s]*$
und Ersetze mit:
<anwendungsmeldung id="$1">\n<text><!\[CDATA\[\n$2\n\]\]></text>\n<translation><!\[CDATA\[\n$3\n\]\]></translation>\n</anwendungsmeldung>
- Suche:
</anwendungsmeldung>
und Ersetze mit:
</anwendungsmeldung> <!-- ################################################################ -->
, um die optischen Trenner wieder einzufügen.
- Manuell Header und Footer wieder hineinkopieren.
- Suche:
Das Verfahren hat natürlich einige Nachteile. Es ist zeitraubend (je 15-20 Minuten für Vor- und Nachbereitung der Datei), umständlich und damit auch potenziell fehleranfällig. Noch dazu vermeidet es immer noch nicht die Müll-Strings im Translation Memory.
Möglichkeit 4: Mit Excel nach Trados
Eine Verfeinerung von Möglichkeit 3, die das Translation Memory von unnützen Zielstrings in der Quellspalte befreit und obendrein einfacher und schneller ist.
Schritt 1: Aus der XML-Datei wird wieder eine Excel-Tabelle gemacht. Da wir inzwischen klüger sind, lassen wir aber den Umweg über Notepad++ und CSV-Texttabelle. Stattdessen benutzen wir in Excel die Schrittfolge Daten -> Aus anderen Quellen -> Vom XML-Datenimport
. Dies quittiert Excel mit der Meldung, dass kein passendes XML-Schema existiert und eines erstellt wird, sowie mit der Frage, wohin es mit den Daten soll. Beides quittieren wir einfach mit « OK » und freuen uns, wie einfach das Leben sein kann.
Die neue Excel-Tabelle wird dann in den Projektordner gespeichert und eine Kopie mit Speichern unter...
als « Unicode Text » (Texttabelle) abgelegt. Voilà: Wir haben eine dreispaltige CSV- (bzw. TSV-)Tabelle mit der Endung .txt.
Schritt 2: Trados Studio kann zwar keine mehrsprachigen Excel-Tabellen bearbeiten, dafür aber mehrsprachige Texttabellen. Über Optionen -> Dateitypen
kann man die nötigen Einstellungen bei Tab-delimitierter Text
setzen:
Den richtigen Spaltenbegrenzer (Tab), welche Spalte Quell- und Zieltext ist, ob es in Spalten danach Kommentare gibt, ob vorhandene Übersetzungen als Bestätigt oder nur als Entwurf eingefügt werden sollen, ob der Text in der Texttabelle in Anführungszeichen eingeschlossen ist (ist er, also das Häkchen bei « Text in Anführungszeichen » setzen!), etc.
Vorsicht: Excel speichert bei mir die Textversion fehlerhaft und fügt grundlos Zeilenumbrüche zwischen den Spaltentrennern ein. Wenn die Text-Tabelle so übernommen wird, zeigt Trados beim Übersetzen ebenfalls überflüssige Zeilenumbrüche im Editor an, und Excel macht später beim Rückimport Probleme, weil es seine eigenen Fehler nicht versteht. Hier ist tatsächlich der Rückgriff auf Notepad++ und sein Suchen und Ersetzen mit Regulären Ausdrücken geboten. Mit drei Schritten ist alles in Ordnung:
- Suche:
\t"\n
und Ersetze:\t"
- Suche:
\n"\t"
und Ersetze:"\t"
- Suche:
\n"$
und Ersetze:"
Schritt 3: Nachdem der Dateityp angepasst ist und die Texttabelle korrigiert wurde, öffnen wir sie in Trados Studio. Dann übersetzen wir fröhlich vor uns hin: Der Quelltext ist in der Quellspalte und die Zielspalte ist entweder leer oder schon mit der vorhandenen Übersetzung vorausgefüllt, wir können unser TM nutzen, alles ist gut. Sobald wir mit der Arbeit fertig sind, können wir das Projekt speichern, via Datei -> Batch -> Master-Translation Memorys aktualisieren
unser TM auf den neuesten Stand bringen und den Datei -> Zieltext exportieren
: Als txt mit der Zeichenkodierung Unicode (UTF-8). Fertig ist die übersetzte Texttabelle.
Schritt 4: Wenn man jetzt versucht, die Excel-Tabelle zu öffnen und mittels Daten -> Aus Text
die Texttabelle zu importieren, weigert sich Excel mit der Begründung, dass eine Abfrage eine XML-Datenzuordnung nicht überlappen darf. Die einfachste Möglichkeit ist daher, auch die übersetzte Text-Tabelle in Excel zu öffnen, dort die Zielspalte zu markieren, zu kopieren und in der Zielspalte der Exceltabelle (mit der Option « Werte », Strg + W) einzufügen. Danach kann man die Tabelle wieder per Speichern unter...
als XML-Datei speichern.
Aber was ist das!?
Alle Kommentare sind aus der XML-Datei verschwunden und die Inhalte sind nicht mehr durch CDATA-Anweisungen geschützt! Dafür hat Excel dem Wurzelelement ein neues Attribut verpasst: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
. So wird das der Kunde aber nicht haben wollen!
Fazit
Vorerst bleibt es wohl bei einer Mischung aus Möglichkeit 3 und 4: Wir sparen uns die Vorbereitungsrunde mit Notepad++, indem wir mit Excel einfach die drei benötigten Spalten (ID, Source, Target) extrahieren, müssen dafür überflüssige Zeilenumbrüche töten, arbeiten dann komfortabel und übersichtlich mit einer Texttabelle in Trados und benutzen schließlich Notepad++, um der Texttabelle direkt das ursprüngliche Markup wiederzugeben, anstatt sie noch einmal grundlos in Excel zu laden. Immerhin: 15-20 Minuten Vorbereitungszeit gespart, die vorhandenen Übersetzungen sind gleich im Editor, und ein sauberes Translation Memory im Projekt gibt’s auch dazu.
Wie macht ihr es besser? Ich freue mich auf Feedback!
Christopher von DeFrEnT
P.S.: Etwas später habe ich einen neuen, viel besseren Arbeitsablauf mit XSLT (Artikel in Englisch) entwickelt.
Laisser un commentaire