Maschinenherrschaft

Als technischer Redakteur muss man sich eh immer die Witze über die vom Chinesischen ins Deutsche übersetzten Anleitungen anhören. Dem halte ich dann immer entgegen, dass das inzwischen bei professionellen Firmen voll toll abläuft. Man hat Translation Memories, Terminologien, standardiertes Schreiben und all sowas.

wird falsch dem da Sein

Und dann kommt Microsoft® und knallt u.a. diesen Text hin:

Wenn eine DV-PAL-format-Kamera falsch meldet, dass es MPEG2TS-Datenformat unterstützt, wird falsch dem da Sein die DV-PAL-format-Kamera einer NTSC-Format-DV-Kamera angenommen. (Quelle)

It’s not me, it’s you!

Noch besser fand ich dann diesen Hinweis am Ende des Artikels:

Als Kunde fühle ich mich da so ein bisschen veräppelt: „Ja, sorry, wir haben halt auch nicht für alles Zeit. Aber hier hast du ein paar Brocken, ist ja besser als nix. Ach ja, und wenn da Mist drin steht, ist das nicht unsere Schuld, sondern dein Problem. Sei froh, dass wir dir irgendwas zu lesen geben.“

Kundenfreundlich ist definitiv etwas anderes. Gleichzeitig frage ich mich, ob dieser Haftungsausschluss wirklich rechtens ist. Sonst würde ja jeder auf Bedienungsanleitungen einen solchen Hinweis anbringen: „Für Probleme, die durch Fehler in der Dokumentation entstehen, sind wir nicht haftbar zu machen.“ Hm, wenn das so einfach wäre, hätte man mir an der Hochschule sicherlich die Vorlesung „Juristische und normative Aspekte in der Technischen Dokumentation“ erspart 🙂

Maschinelle Übersetzung?

Gibt man auf http://support.microsoft.com/ den Suchbegriff „maschinell“ ein, bekommt man mehr Beispiele dieser Art. In manchen Artikel ist das Deutsch sogar halbwegs verständlich, so dass der Einsatz der MÜ hier gar nicht so verkehrt ist. Aber so lange es solche kyptischen Auswüchse wie oben gibt, bleibt für mich der Beweis bestehen, dass Übersetzung momentan höchsten maschinen-unterstützt laufen kann.

DITA-Texte anpassen

Ja, die Zeit der Anpassung ist da 😉

Mit dem OT kommt ja schon ein Satz an Texten mit Übersetzungen mit. Natürlich passen einem da so manche Texte nicht wirklich und man möchte sie ändern. Oder man möchte vielleicht noch Texte hinzufügen, so wie ich einen umfangreichen, firmenspezifischen Copyright-Text.

Ich habe hier bisher in der Not die Dateien in DITA_OT/xsl/common entsprechend geändert. Hat funktioniert, hat mir aber nicht so richtig gefallen, weil es eben Original-OT-Dateien sind, die ich editiere.

Daher fand ich das StringsPluginExample aus dem Files-Bereich der DITA-Yahoo-Group richtig genial und habe auch gleich versucht, das zu installieren (Anleitung). Man kann damit seine eigenen String-Dateien definieren, die dann die des OTs einfach überschreiben. Eigentlich eine einfache Sache…!

  1. Leider ist nach der Installation beim Generieren einfach gar nichts passiert.
  2. Irgendwann stellte ich fest, dass so ein Override erst ab Version 1.4.2 des OT möglich ist.
  3. Kurz darauf versuchte ich bei meinem XMetal nach Anleitung ein OT-Upgrade durchzuführen (und zwar indem man die Variable DITA_OT_DIR auf das Verzeichnis der neuen version setzt). Hat nicht funktioniert.
  4. Dann habe ich wieder festgestellt, dass dieser Parameter mit der OT-Version 1.4.2 nicht funktioniert, aber dass JustSystems einen Patch anbietet.
  5. Mist, der Patch darf nur auf XMetal 5.1 angewandt werden. Und wenn man eine frühere Version hat, soll man doch bitte in Betracht ziehen erst einmal ein Upgrade von XMetal zu machen.

Kurz: ich mache alles wie bisher und kommentiere meine Änderungen brav. Allerdings finde ich es sehr bedenklich, dass ich ein Tool habe, mit dem ich nicht mal eben so ein Upgrade meiner Architektur durchführen kann. Klar, wenn ich nur in Notepad++ arbeite und über die Kommandozeile publiziere, ist das eher problemlos 😉

Ich frage mich, ob man das Problem z.B. auch mit Arbortext hat?

tekom-Jahrestagung 2008 #5 – Finale

Ich habe einen Haufen Vorträge gesehen und nachdem ich nun meine Highlights schon beschrieben habe, kommen wir zu der Kategorie „Ferner liefen…“. Hier findet sich sowohl Gutes als auch Schlechtes 😉

Adobe Air, eine neue Basis für Onlinehilfen?

Der erste Vortrag meines Tagungsprogramms lieferte einen gute Überblick über das was Air ist, was es kann und wozu es gut ist. Die Folien gibt es online.

Content Reuse – Zusammenspiel von Software-Entwicklung und Technischer Dokumentation

Definitiv eine der größten Enttäuschungen (neben der Tatsache, dass ich in manche Workshops nicht mehr reinkam). Es ging hier um ein Beispiel in dem für die Dokumentation die strukturierten Daten, die schon bei den Entwicklern vorkamen, wiederverwendet werden konnten. In diesem Fall handelte es sich um 15.000 Fehlermeldungen, deren Kodierung und Text über XML dann an die Doku weitergereicht wurde, auf dass diese die entsprechenden Erklärungen schreibt. Klar, das ist Reuse, aber definitiv eine Variante, die in der freien Wildbahn echt nicht oft auftaucht. Und in der Vortragsbeschreibung kam das auch ganz klar nicht raus. Da haben sehr viele etwas anderes erwartet 🙁

Von 0 auf XML in 80 Tagen: Einführung eines XML Redaktionssystems auf Basis von Funktionsdesign

Hier hat der Kaffeemaschinenhersteller Jura vorgestellt, wie die Doku sich bei ihnen entwickelt hat. Irgendwann wurde ein Cut gemacht bei dem entschlossen wurde, dass nicht mehr Entwickler die Doku schreiben *lach*. Es wurde ein Funktionsdesign entwickelt, das dann auf alle neuen Anleitungen angewandt wurde. Irgendwann war alles an Doku standardisiert und dann kam man auf die Idee ein CMS einzusetzen. Und nachdem man sich für ein CMS entschieden hatte, dauerte es tatsächlich nur 80 Tage bis es einsatzbereit und mit bisherigem Content angefüllt war. Herrlich! Genauso sollte es laufen. Naja, bis auf die Tatsache InDesign einzusetzen… Aber ansonsten bin ich neidisch 🙂

Wissensmanagement bei dezentraler Dokumentationserstellung für multiple Märkte, Marken und Sprachen

Die Essenz dieses Vortrags war, dass jedes Wissen, dass in einem Prozess wichtig ist, auch in diesem Prozess verankert sein muss. Ein durchaus interessanter Ansatz. Sehr schön fand ich den Begriff „Denk-dran-Lösungen“: er wurde hier für alle Informationsinseln verwendet, die sich mit der Zeit in einem Unternehmen entwickeln. Ein bisschen schade fand ich, dass der Redner Wikis komplett als Lösungswegs ausgeschlossen hat, weil sie zu „unstrukturiert“ wären und ja auch bei der Wikipedia nur 1% der Nutzer auch aktiv wären, was bei einer Firma dann auch nichts bringen würde. Aus eigener Erfahrung kann ich sagen, dass die Wikipedia nicht mit einem Wiki in einem Firmenumfeld vergleichbar ist. Letzten Endes lebt jedes Wissensmanagementsystem davon es gut an die Mitarbeiter zu vermarkten, sei es ein schnödes Wiki oder irgendetwas Kommerzielles.

An overview of localization in Latin America

Der Titel sagt genau worum es ging, aber noch treffender wäre der Begriff „localization industry“ gewesen. Ich hatte mir erhofft zu hören, was es für Strategien oder Tipps gibt, wenn man für Lateinamerika lokalisieren muss. Aber es ging wirklich nur um die Lokalisierungsindustrie dort. Das einzig Interessante war hier die Anmerkung, dass man sich als Unternehmen durchaus mal überlegen solle, ob es nicht effizienter und qualititatv besser wäre, die Lokalisierung in die jeweiligen Länder zu geben. Mir kam es alles in allem mehr wie eine Marketingveranstaltung für die Lok-Industrie da drüben vor.

Writing for an International Audience

Gute Zusammenfassung dazu wie schlechte Doku und auch Gedankenlosigkeit die Übersetzungskosten in die Höhe treiben können und am Ende vielleicht doch nur Müll rauskommt, weil eben Müll reinkam. Schönstes Rechenbeispiel: wie die Änderung eines Field Labels am Ende 5500$ kostet 😀

Zielgruppen im Fokus – Zielgruppendefinition in der Technischen Dokumentation

Hm ja, das Übliche eigentlich:

  • site visits
  • workshops
  • Fragebögen
  • Communities
  • Usability-Tests
  • Auswertung der Definitionen von Marketing und Vertrieb

Interessant war der Ansatz, dass man festlegen sollte, welche Zielgruppe strategisch wichtig für das Produkt ist (sowas macht dann wahrscheinlich das produktmanagement) und dann die Redaktion deren Kommunikationsbedürfnisse ermittelt. Einfaches Beispiel: ein Flugzeugtechniker braucht für die tägliche Arbeit kein umfangreiches Handbuch, sondern vielleicht eher eine Loseblatt-Sammlung mit Checklisten.

Das Deutsch der Technischen Redaktion

Bei einer Kaffeepause erzählte mir eine Kommilitonin, dass Prof. Baumert aus Hannover ganz tolle Vorlesungen halten soll. Und so bin ich ganz spontan hineingelaufen – der Vortragsraum war schon 10min vor Beginn randvoll. Ich war hin und weg: er legte los mit den philosophischen Grundlagen, die letzten Endes unser alle Muthig+Schäflein-Armbruster zum Designen des Funktionsdesigns verleiteten. Supertoll vorgetragen und wirklich interessant, weil ich bisher eigentlich immer nur wusste, dass das Funktionsdesign aus der Sprechakttheorie hervorgeht. Aber mehr auch nicht.

Leider musste ich während des Vortrags wg. eines Termins raus. Sehr schade!

Fazit

Ich war teilweise doch sehr enttäuscht darüber, wie sehr manche Vortragsbeschreibungen von der Realität abwichen und man dann in einem Vortrag nach 5min merken musste, dass man wohl in die Falle getappt war.

Leider sind auch einige Vorträge ausgefallen, die ich sehr gern gehört hätte.

Alles in allem fand ich es aber trotzdem sehr gelungen. Ich hatte einige schöne Highlights, habe alte und neue Bekannte getroffen und nächstes Jahr werde ich wohl hoffenltich auch dazu kommen mehr von Wiesbaden zu sehen als die Messe und das Hotel 😉

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 😉