Monat: September 2010

Wie man meinem Blog entnehmen kann, beschäftige ich mich seit ca. 2 Jahren mit DITA. Anfangs haben wir unsere Daten über Ordner und SVN verwaltet. Inzwischen haben wir schon fast alles im Redaktionssystem drin – das SVN ist bald Geschichte. Da ich aber weiß, dass ein Redaktionssystem häufig zu den unerfüllten Träumen von technischen Redakteuren gehört, teile ich hier mal meine Erfahrungen mit DITA und SVN.

Übersetzungsmanagement

Die einzelnen Sprachen auf demselben Stand zu halten gestaltet sich schwierig. Man muss sehr diszipliniert sein, denn sonst vergisst man leicht, dass ein kleiner Fix in der einen Sprache auf die anderen übertragen werden sollte.

Bei Änderungen an bestehenden Daten hat man das Problem, das man das Delta entweder manuell rauskopieren, übersetzen und dann wieder reinkopieren muss. Oder man gibt eben immer nur komplette Topics zur Übersetzung, auch wenn nur ein Satz neu ist (was aber schnell recht teuer werden kann).

Verwaltung

Versionshistorie ist Gold wert 🙂

Dateileichen herauszufinden ist schwierig, z.B. wenn man in der Konzeptionsphase mehrere Topics angelegt hat und am Ende einige gar nicht braucht. Bei uns sind solche Leichen teilweise übersetzt worden, obwohl sie nie gebraucht wurden. Hier können kleine Skripte hilfreich sein, die alle Dateien listen, die in keiner Map referenziert sind.

Man schludert schnell mit SVN-Kommentaren und am Ende weiß man selber nicht mehr, was man eigentlich mit  dem Kommentar „Änderung“ gemeint hat 😉

Tags und Branches sind äußerst wichtig, damit man komfortabel an neuen Projekten arbeiten kann und immer noch gleichzeitig den aktuellen Online-Stand aktualisieren kann. Am Anfang hab ich nur auf dem trunk gearbeitet, was darin resultierte, dass ich im Projektverlauf keine Updates am Online-Stand machen konnte und als sich dann das Projekt verschob, alle Änderungen händisch zurücknehmen musste.

Wenn man die Ordner erst einmal angelegt hat, wird es ziemlich kompliziert sie wieder zu reorganisieren, wenn man z.B. merkt, dass die Struktur doch nicht so gut ist. Zum einen können Referenzen zwischen Topics aus verschiedenen Ordnern kaputt gehen, zum anderen muss man im SVN aufpassen, dass man die Versionshistorie nicht verliert.

Fazit

Man kann auch topicorientiert schreiben und mit XML arbeiten ohne ein CMS zu benutzen. Eine Sache, die gern außer Acht gelassen wird, aber ich muss sagen, dass es nicht drauf ankommt welches Tool oder welche Standardisierungsmethode man verwendet – wichtig ist, was am Ende rauskommt!

Wenn man als Redaktion also kein Redaktionssystem zur Verfügung hat und trotzdem mit DITA arbeiten will, ist eine Verwaltung über Ordner und SVN meiner Meinung nach eine super Alternative.  Die Benutzung von SVN ist sogar absolut obligatorisch, wie ich finde.

Bei dieser Arbeitsweise müssen allerdings viele Dinge über Regeln und Workflows als „Denk dran“-Lösung abgedeckt werden, und die Erfahrung zeigt nun mal, dass man im Eifer des Projektgefechts nicht immer dran denkt.  Man kann zwar Skripte schreiben, die einem bestimmte Dinge abnehmen, aber am Ende muss man eben doch dran denken, das auch zu benutzen. Wenn sich mit der Zeit solche kleinen Fehler einschleichen, hat man irgendwann ein Problem. Man muss das Redaktionsteam außerdem ausführlich  schulen, denn die Grundfunktionen von SVN sind relativ schnell drin, aber gerade solche Dinge wie Tags/Branches/Merging sind nicht intuitiv.

Ich habe bereits erwähnt, dass ein GUI-Texter/Übersetzer einfach nur eine Datei mit Text bekommt, im schlimmsten Fall eine ellenlange Datei mit Tausenden von Einträgen. Die Schwierigkeit hierbei ist nun, dass man gar nicht weiß wo der Text genau erscheint, in welchem Kontext er sich befindet, wenn man einfach nur die Datei vor sich hat. In manchen Fällen macht es das sehr schwer, überhaupt einen Text zu formulieren, der in diesem Kontext Sinn macht und man hat auch das Problem, dass man nie weiß, ob der Text in der GUI überhaupt genug Platz hat (z.B. „Publish“ versus „Veröffentlichen“: hier ist das deutsche Wort fast doppelt so lang).

Beispiel für die Folgen von Kontextarmut

Das Kontextproblem ist den meisten, die mit der Thematik kaum in Berührung kommen, nicht sofort verständlich. Für diese Fälle habe ich mein Lieblingsbeispiel aus der Praxis parat, das ich auch euch nicht vorenthalten möchte. Es führt klar und deutlich vor Augen, was fehlender Kontext bedeuten kann:

Der Ausgangs-Dialog:

Was der Übersetzer sehen konnte, war einfach nur Text  (vereinfachte Version):

Was am Ende dabei rauskam:

Die Moral von der Geschicht: Übersetzen geht ohne Kontext nicht!

Wenn der Übersetzer des obigen Beispiels den Dialog vor sich gehabt hätte, wäre wohl kaum dieses Ergebnis rausgekommen. Es ist also dringend notwendig, dass ein Übersetzer den Kontext zu sehen bekommt.

Wie bekommt der Übersetzer den Kontext?

Das Allerbeste wäre eine Lokalisierungssoftware, die dem Übersetzer ein so genanntes „In-Place Editing“ erlaubt, d.h. der Übersetzer öffnet bspw. einen Dialog der zu übersetzenden Applikation und kann direkt an Ort und Stelle den Text ändern. Dabei stehen im in der Regel auch Translation Memories zur Verfügung. Gängige Namen für Lokalisierungssoftware sind hier „Passolo“ oder „VisuaLocalize“. Allerdings ist der Einsatz solcher Software bei den heutzutage hochdynamischen Web-Applikationen äußerst schwierig, da hier Seiten und Elemente zur Laufzeit generiert werden und eine ständige Verbindung zu anderen System haben müssen (deswegen bin ich auch gespannt auf den Vortrag „LOC13 Visual localization of web-based application“ auf der tekom-Tagung). Wenn man dann auch noch mehrere Applikationen übersetzen muss, die auch noch unterschiedliche Basistechnologien einsetzen, wird es richtig kompliziert.

Eine andere gute Lösung für den Übersetzer ist eine Testversion der Software oder ein Testzugang der Webseite in der Quellsprache. Wenn das nicht möglich ist, dann sollte man zumindest Screenshots mitliefern. Und wenn das auch nicht praktikabel ist, muss ein Lektor her, der die übersetzten Texte in der GUI überprüft und bei Fehlern dann auch das Translation Memory aktualisiert.

Weiter geht es mit meiner angefangenen Serie zur Software-Lokalisierung für Technische Redakteure

Formate und Tools
Die Formate mit denen man sich auseinandersetzen muss, sind vielfältig. Es hängt von der eingesetzten Technologie ab und vielleicht auch von den Präferenzen der jeweiligen Entwicker. Mit diesen Formaten habe ich im Bereich von Webapplikationen am häufigsten zu tun:

• PO-Dateien, oftmals bei Anwendungen mit JavaScript, PHP (z.B. WordPress)
• selbst definierte XML-Dateien
• Java Properties

Jedes dieser Formate hat seine Eigenarten, wie etwas unterschiedliche Zeichenkodierungen (UTF-8, ISO-8859-1).  Bei Java Properties muss man Sonderzeichen beispielsweise gesondert kodieren – so wird aus einem „ü“ ein \u00fc. Glücklicherweise gibt es auch Editoren, die einem solche Späße übernehmen oder die das Editieren generell vereinfachen (für PO ist es z.B. PO Edit).

Diese Formate sind einigermaßen gängig und können heutzutage auch von den allseits bekannten Translation-Memory-Systemen eingelesen werden, die dann diese Kodierung beispielsweise auch völlig selbständig im Hintergrund übernehmen.

Datenaustausch und Pflege
Der Datenaustausch findet bei uns meistens über das SubVersion der Entwicklung statt. Die Entwickler generieren leere Dateien mit IDs, wir checken diese aus, befüllen die IDs mit Werten (also Text) und checken sie wieder ein.

Das initiale Betexten und Übersetzen solcher Textdateien ist noch eine schöne Sache. Man hat eine Datei von der man weiß, dass man sie nun komplett überarbeiten bzw. übersetzen muss.

Unangenehm kann es dagegen werden, wenn bereits bestehende Textdateien um einige Zeilen erweitert werden. Das kann dann unter Umständen so aussehen:

1. In der ellenlangen Datei nach der leeren ID suchen
2. Einen Text eingeben.
3. Diesen Text rauskopieren in eine Extra-Datei
4. Diese Datei zu Übersetzung geben
5. Die Übersetzung manuell in die ellenlange Textdatei zurückkopieren.
6. sie dann herauskopiert, zur Übersetzung gibt und am Ende manuell die fertigen Übersetzungen in die Textdateien zurückpfriemelt.

Wie man sieht: Eine sehr mühselige, zeitaufwändige und fehleranfällige Tätigkeit, die man ziemlich schnell mit Skripten automatisieren sollte. Man kann sich z.B. kleine Skripte bauen, die die neuen Strings automatisch in eine neue Datei extrahieren, die man dann bequmm betexten/übersetzen lassen kann. Und die Skripte bauen die Übersetzungen anschließend wieder zurück, so dass man sich diese fehleranfälligen Zwischenschritte sparen kann.