tekom-Jahrestagung 2008 #3

Translation Reuse Strategies

von Hans Pich

Eigentlich wollte ich in den Vortrag zu DITA, XLIFF und Co., aber irgendwie bin ich durcheinander gekommen, aber thematisch war auch dieser Vortrag durchaus auch nicht verkehrt 😉

Zuerst hatte ich erwartet, dass einfach wieder über den tollen Einsatz von TMS und blablabla erzählt wird. Der Ansatz von Herrn Pich ging zwar natürlich in die Richtung, aber die Kernaussage war, dass auch die ganze Systemlandschaft aus CMS, TMS, Terminologiedatenbank und was man sonst so hat, einen nicht davor retten kann, dann man schlechte Übersetzungen hat bzw. Übersetzungen, die man doch nicht wiederverwenden kann.

Folgende Probleme sind bei der CMS-TMS-Kombi da:

  • Kontextarmut/Stückeltexte: hat man ein CMS eine Weile in Betrieb, kriegt die Übersetzung irgendwann nur noch Textteile und nicht mehr vollständige Texte. Eigentlich ist es ja ein Vorteil, das man nur noch Dinge zur Übersetzung weiterleitete, die sich auch geändert haben, aber so völlig ohne Kontext hat es ein Übersetzer echt schwer. Damit kann sich die Textqualität der Übersetzung ungewollt verschlechtern.
  • Inkonsistenz/Sprachentwicklung: diese Überlegung war mir völlig neu, ist aber sehr schlau. Einzelne Textfragmente / Wörter, /Wendungen die heute noch passend und aktuell sind, könnten in 10 Jahren völlig out-of-date sein. Bloß, wie findet man diese wieder, wenn sich an der Quelle nichts geändert hat und damit nichts zur erneuten Übersetzung kommt, wo dies vielleicht angepasst würde. Als Beispiel wurde die polnische Sprache genannt, die sich in den letzten Jahren wohl signifikant entwickelt hat.
  • Übersetzungsfehler: das schlägt in die ähnliche Kerbe, wie die Sprachentwicklung. Was erst einmal im CMS bzw. TMS drin ist, bleibt auch drin.

Folgende Wege aus dem Dilemma, dass Tools alleine nicht helfen, gibt es hier:

  • Qualität folgt aus Qualifikation
    • ausgebildete Redakteure
    • technische Übersetzer
  • Semantisch vollständige Informationseinheiten an Übersetzer geben!
  • Übersetzungsgerechte Quelltexte produzieren
  • Definierte Quellterminologie
  • Lokalisierungsangaben
  • Styleguides

Damit stehen die Chancen höher, dass  man Qualität in CMS und TMS reinpumpt. Und man will ja auch schließlich nur Qualität wiederverwenden.

Bei der Auswahl der Übersetzer sollte man ebenfalls sehr sorgfältig sein, z.B. site visits machen, um zu sehen wie die arbeiten. An dieser Stelle folgte dann eine Frage aus dem Publikum: Was mache ich, wenn mein Übersetzer seine Texte lieber in Excel haben will als in einem TMS-Format? Hab ich den falschen Übersetzer oder mache ich was falsch? Klar, was da die Antwort war 😉

Fazit

Über Reuse hat man jetzt nicht viel gehört, sondern eher was über Qualitätssicherung. Für mich war das meiste nichts Neues, aber für die Manager und Führungskräfte denen man als Redaktion diese Dinge verkaufen muss, sicherlich gute Denkansätze. Am Ende hat es mich halt doch geärgert, dass ich den DITA+XLIFF-Vortrag verduselt habe…

Lokalisieren mit DITA

Eigentlich ist es eine ganz einfache Sache bei DITA: man setzt xml:lang-Attribut auf die gewünschte Sprache/Sprachvariante und zack, sind die Standardtexte (so etwas wie „Achtung“, „Voraussetzung“ u.ä.) lokalisiert. DITA bringt schon eine ganze Latte von Sprachdateien mit sich, die diese Texte enthalten und zwar unter DITA_OT/xsl/common.

Nun habe ich diese Dateien erweitert und das hat in der Standardsprache meiner Pilot-Doku (en-us) auch super geklappt das einzubinden. Als ich nun diese Doku in das britische Englisch (also en-gb) übersetzen wollte, wurden die Standardtexe weiterhin aus der Sprachdatei für en-us eingebunden. Ein kurzer, erfolgreicher Test mit der Lokalisierung ins Deutsche hat ergeben, dass die Lokalisierung an und für sich schon funktioniert, aber nur die Sprachvariante en-gb nicht.

Und was war des Rätsels Lösung? In der strings.xml wird definiert für welche Sprache welche Sprachdatei verwendet werden soll und da stand glatt für alle Sprachvarianten einer Sprache immer eine „Hauptsprache“ drin. Das heißt in allen Englischvarianten stand en-us als Standard drin, bei Deutsch beispielsweise de-de und so weiter.

Natürlich war das nirgends dokumentiert, aber dank Community war auch das dann gelöst – und zwar so:

ALT: <lang xml:lang=“en- gb“ filename=“strings-en-us.xml“
NEU: <lang xml:lang=“en- gb“ filename=“strings-en-gb.xml“ />

Ich hatte schon etwas Angst bekommen, dass das Problem komplizierter ist, weil es einige Artikel gab, in denen stand, dass beim PDF-Generieren die Lokalisierung anders läuft. Allerdings ist das nur so, wenn man pdf2 nutzt. Immerhin etwas Gutes hatte es an dieser Stelle, dass wir noch FOP nutzen 😉