Jeder kann schreiben

In diesem Beitrag zum Beruf des technischen Redakteurs habe ich bereits den Punkt “Undankbarkeit” erwähnt. Wann immer es um Text (und auch um Grafik, wie ich von befreundeten Grafik-Designern weiß) geht, hat die Allgemeinheit die Vorstellung: “Ja, das schreib ich schnell selber zusammen.” Oft kommen dabei Texte raus, die einem textliebenden Menschen den Magen umdrehen – egal ob es um Anleitungen,  E-Mail-  oder Anwendungstexte geht.

Was ist “guter Text”?

Ich führe die Diskussion, warum eben nicht jeder gut schreiben kann, ziemlich oft. Sehr gerne auch mit Entwicklern, die glauben, sie könnten die kleine Fehlermeldung mal eben schnell selber schreiben. Die Sache ist die: einige wenige können sogar ganz gute Texte schreiben, aber sehr viele eben nicht.

Dabei fällt es mir teilweise schwer, überhaupt zu vermitteln, warum eben die Profis an die Texte gelassen werden sollten und warum es tatsächlich eine halbe Stunde bis Stunde dauern kann einen bestimmten Absatz zu formulieren bis er wirklich gut ist. Irgendwelche Messkriterien für guten Text will ich jetzt schon mal gar nicht beachten, denn bisher hat mich noch nichts überzeugen können.

Für solche Diskussionen lege ich mir gerade eine kleine persönliche Sammlung an, die textliche “Lowlights” aus den Bereichen Doku oder Software-GUI enthalten soll, die mir in den letzten Jahren so untergekommen sind – und die dazugehörige Überarbeitung natürlich. Dabei geht es mir nicht um Übersetzungsfehler, sondern die Patzer, die eben schon im Quelltext entstehen (und dann vielleicht zu noch kurioseren Übersetzungen führen). Einige werde ich mit euch teilen, andere werde ich nur im Offline-Leben aus der Kiste zaubern können.

Meine Hoffnung ist, dass ich mit solchen konkreten Beispielen diese abstrakte Tätigkeit “Text schreiben” mal irgendwie greifbarer machen kann.

Warum muss es ein technischer Redakteur sein?

Bei der DITA Europe Conference in Wien habe ich einen Partnervortrag von Tony Self gesehen, bei dem ein “Doku auf DITA umstellen”-Projekt vorgestellt wurde. In diesem Projekt wurde beschlossen, dass in der Firma gescheite Kundendokumentation benötigt wird (yay!). Da man aber keine Redakteure hatte, rekrutierte man aus der Qualitätssicherung rund um die Welt Mitarbeiter, die “nebenbei” noch schreiben sollten. Für das “Drumherum” und für die Organisation dessen holte man sich immerhin Tony ins Boot. Aber ehrlich gesagt hat mich dieses Vorgehen baff gemacht und es kamen mir sorgenvolle Gedanken wie “Wenn das jetzt immer mehr so machen, weil es ‘gut genug’ ist, was ist dann meine Ausbildung noch wert?”.

Beim Thema “TR-Redaktionssystem” bemerke ich inzwischen auch oft, dass die Leute denken, dass man da einfach jeden davor setzen können muss. Ich vermute, dass dieser Irrglaube von der unglückseligen Benennung “Redaktionssystem /CMS” herrührt, die die meisten Leute eben doch an ein Web-CMS denken lässt. Und bei einem Web-CMS ist es ja das Wichtigste, den Leuten das Editieren piepeinfach zu machen.

Ein TR-Redaktionssystem soll das Editieren zwar auch einfach gestalten und die Leute von Technik und Layout fernhalten, aber der Punkt ist, dass hier doch sehr viel Basiswissen da sein muss, damit man so ein System effizient nutzt, z.B. in Sachen Modularisierung, Wiederverwendung, bedingtem Text, Übersetzungsmanagement, Standardisierung etc.

(Ich will damit übrigens nicht sagen, dass ein TR unbedingt studiert haben muss. Wie überall gibt es auch hier sehr gute Quereinsteiger. Aber wenn man hergeht und einfach irgendjemanden nimmt und mit der Aufgabe ein Handbuch zu schreiben vor ein Redaktionssystem setzt… Naja, lustig wird das ziemlich sicher nicht… )

Auf in den Kampf

Ich will mir in der nächsten Zeit mal Gedanken dazu machen, wie ich fachfremden Leuten besser klar machen kann, was wir TRler eigentlich machen und warum wir es machen sollten und es nicht jeder kann. Und zwar einerseits in Hinblick auf das Thema “Schreiben”, aber auch im Hinblick auf Sachen wie “CMS/Übersetzungsmanagement/Workflows”.  Das wird ne recht schwierige Sache, aber hey – Informationsvermittlung sollte doch für eine/n TR kein Problem sein  ;)

Und wie führt ihr diese Diskussionen? Oder müsst ihr die etwas gar nicht führen? :-)

Geschrieben in Beruf,Erweiterter Horizont,Redakteurs Alltag | 7 Kommentare

Muttersprachen-Prinzip

Mein letzter Blogpost wurde netterweise von Sarah O’Keefe übersetzt und im Scriptorium-Blog “wiederverwendet”. In Anbetracht der durchaus großen englischsprachigen Blog-Szene im Bereich Technische Redaktion habe ich mir schon oft überlegt auf Englisch zu schreiben, weil ich damit vermutlich ein größeres Publikum erreichen würde. Und Sarah hätte hier einfach nur verlinken können ;)

Warum ich es nicht mache? Deutsch ist meine Muttersprache. Mein Englisch ist durchaus gut – ich habe ein recht gutes Sprachgefühl und kann einigermaßen flüssige Konversationen halten, wenn ich mich warmgeredet habe. Aber es kostest mich unglaublich viel mehr Zeit einen englischen Text zu verfassen, der in Inhalt und auch Ausdruck genauso rüberkommt wie eine deutsche Version. Da steht mir mein englisches Sprachgefühl sogar ein bisschen im Weg, weil ich irgendwie merke, wenn der Satz nicht passt, aber es nicht besser machen kann. Am Ende kann ich mir nicht sicher sein, dass der Text wirklich so rüberkommt, wie ich es mir gedacht habe, weil dafür dieses letzte Stück Sprachgefühl fehlt, das man nur bekommt, wenn man in der entsprechenden Kultur lebt oder aufgewachsen ist. Ganz zu schweigen davon, dass der enorme Zeitaufwand das Schreiben an und für sich vermutlich sehr schnell komplett lähmen würde…

Für mich heißt das “Muttersprachen-Prinzip” Texte ausschließlich in meiner Muttersprache zu verfassen, für einen Übersetzer heißt es ausschließlich in seine Muttersprache zu übersetzen. Am eigenen Leib erfahre ich oft, dass ich nur nach diesem Prinzip schreiben sollte. Doch immer wieder lese ich in Stellenanzeigen für Technische Redakteure die Anforderung “Dokumentation in deutscher und englischer Sprache” verfassen. Und jedes Mal bin ich ein klein wenig ärgerlich, dass solche Anforderungen gestellt werden. Ein Grund für die Firmen ist sicherlich, dass es kostengünstiger und schneller ist, den Quelltext sofort in Englisch zu erstellen. Gerade wenn man in “exotischere” Sprachen (asiatische Sprachen zum Beispiel) übersetzt, ist es leichter Übersetzer mit dem Sprachpaar “Koreanisch-Englisch” zu bekommen als “Koreanisch-Deutsch”.

Fazit
Ich glaube, der Endkunde wird es immer irgendwie merken, wenn ein Nicht-Muttersprachler einen Text geschrieben hat. Zumindest hab ich die Erfahrung schon oft gemacht. Viele beachten diesen Aspekt nicht, wenn es um das Schreiben oder Übersetzen geht, bzw. ist er ihnen nicht bewusst. In der Realität sieht es nun aber leider doch so aus, als ob man als deutschsprachiger Redakteur auch immer öfter Englisch schreiben muss. Zu Lasten der Qualität… Aber vermutlich setzen hier viele Firmen auf das oft zitierte “Gut genug”.

Geschrieben in Beruf,Erweiterter Horizont,Redakteurs Alltag,Übersetzung | 3 Kommentare

Content-Management über Ordner und SubVersion

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.

Geschrieben in Redakteurs Alltag,Softwaredokumentation | Keine Kommentare

Softwarelokalisierung: Formate und Arbeitsablauf

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.


Geschrieben in Beruf,Lokalisierung,Redakteurs Alltag,Übersetzung | 1 Kommentar

Arbeite mit DITA und sprich darüber?

Ich war in den letzten Monaten häufiger in der Situation, das ich Kollegen aus anderen nicht-TR-Abteilungen erklären musste, wie wir in unserem Team eigentlich inzwischen Hilfe schreiben und warum manches nicht mehr so läuft wie früher.

Das Wort DITA nehme ich dabei übrigens eigentlich nur ganz nebenbei in den Mund. Warum? Weil es den Damen und Herren total egal sein kann :) Das ist jetzt nicht überheblich gemeint, aber es ist für sie ja auch gar nicht wichtig zu wissen,dass wir mit DITA arbeiten. Viele Leute konzentrieren sich oft viel zu sehr darauf einem zu erklären WIE sie etwas machen anstatt dass sie einem erklären WAS es den Beteiligten bringt. Oft beobachtet bei Entwicklern, die einem gern die Namen der neuesten Trendtechnologien um die Ohren hauen, die einen dann nur ratlos schauen lassen…

In unserem Fall ist das Prinzip unserer neuen Arbeitsweise an und für sich beispielsweise das wirklich Essentielle:

  1. Standardisierung
  2. Topic-Orientierung
  3. Trennung von Inhalt und Layout

Das sind die wichtigsten nach außen sichtbaren Vorteile und ich konzentriere mich lieber darauf diese transparent zu machen als dass ich groß DITA erkläre.

Man muss hierbei bedenken, dass sich das Vehikel mit dem wir diese Prinzipien umsetzen, auch mal ändern kann.

Die Abteilungen mit denen ich hier zusammen arbeite sind in der Regel vom Endergebnis betroffen und dann kann ihnen das WIE völlig egal sein. Sie müssen vor allem wissen warum sie die neue Arbeitsweise gut finden sollen ;-)

Geschrieben in Beruf,DITA,Redakteurs Alltag,Softwaredokumentation | Keine Kommentare