Die Redakteuse

Autor: Marijana Prusina

  • Linkklassen und Usability

    Das DITA-Open Toolkit unterscheidet im XHTML-Output zwischen Links auf Concepts, References und Tasks. Konkret werden die Links wie hier angezeigt:

    Mal abgesehen davon, dass die vom Open Toolkit mitgelieferten deutschen Standard-Überschriften „Zugehörige Konzepte/Tasks“ etwas wunderlich klingen, bin ich persönlich kein Freund dieser Aufteilung der Links.

    Ich habe z.B. an der Hochschule gelernt, dass solche Topic-Beziehungen klassifiziert und standardisiert werden sollten. Zum Beispiel indem man festlegt, welche Topictypen einander verlinken dürfen und wie. Das finde ich auch absolut okay und notwendig, denn so kann man verhindern, dass unsinnige Link-Urwälder entstehen in denen jedes Topic jedes andere Topic verlinkt, was dann am Ende nicht mehr sehr hilfreich für den Nutzer ist.

    Aber: ich bin mir nicht sicher, ob diese Klassifizierung dem Nutzer an dieser Stelle unbedingt so vermittelt werden muss. Hat der Nutzer tatsächlich etwas davon, wenn ich ihm sage: hier kannst du verwandte Anleitungen finden und hier verwandte Erklärungen? Manchmal weiß der Nutzer doch selbst gar nicht so genau was er sucht und ist so eine Klassifizierung nicht vielleicht einfach nur ein Stolperstein?

    In meinen Augen ringt so eine Aufteilung dem Nutzer noch einmal eine Entscheidung zuviel ab, die er auf der Suche nach der passenden Information treffen muss.  Er muss sich dann nochmal fragen: „Ja, was such ich denn eigentlich?“ und ehrlich gesagt ist man nicht in der Stimmung über so etwas nachzudenken, wenn man Hilfe sucht. Daher plädiere ich dafür verwandte Links unter einer Überschrift zusammenzufassen. Mir geht diese Aufteilung auf Nutzerseite einen Schritt zu weit und sie hat so ein bisschen was von „Ich mach es so. Weil ich es kann.“

    Wie seht ihr das? Was macht ihr mit Links auf verwandte Themen und warum?

  • tekom 2010: Documentation for Software Engineers

    In meinem ersten Job wurde ich zur Betreuung der internen Dokumentation und des Firmen-Wikis eingestellt. Die Vision damals war, dass ich mal tüchtig aufräume und danach alle Abteilungen in der Firma tolle Dokumentation haben. Nun, das wäre super gewesen 🙂 Aber ich musste feststellen, dass das so einfach nicht ist. Es kommt zum einen darauf an, um was es sich für eine Abteilung handelt ( PR? Marketing?Personal? Entwicklung? Wenn ja, welche Richtung? etc), denn die Anforderungen sind dann natürlich unterschiedlich. Dazu hätte ich mich im Detail mit jeder Abteilung und ihrer Dokumentation auseinander setzen müssen. Eine Person alleine kann das für eine große Firma nicht schaffen – und: die Abteilungen müssen am Ende trotzdem auch immer noch selbst Dokumentation schreiben. Das war für die meisten die größte Überraschung damals 😉

    In dem Vortrag „Documentation for Software Engineers“ von Ulrike Parson habe ich nun einiges erfahren, wie man das Thema interne Dokumentation angehen kann. Und es hat meine oben erwähnten Erfahrungen bestätigt.

    Zielgruppen
    Auch bei interner Dokumentation ist es wichtig sich über die Zielgruppe Gedanken zu machen. Das wird bei diesem Thema oft vergessen – es ist ja „nur“ für intern. Die Zielgruppe ist hier der Software-Entwickler und seine verschiedenenen Ausprägungen. Frei übersetzt teilte Ulrike Parson sie wie folgt auf:

    • Den Praktiker:
      • will loslegen
      • benötigt Code-Kommentare, Code-Beispiele
    • Den Gründlichen:
      • liest zuerst einmal die Grundlagen
      • benötigt Hintergrundinfo zu API/Framework, Beschreibung allgemeiner Programmieraufgaben (Error handling, Lokalisierung &Co.)
    • Bedarfsleser
      • Liest bei konkreten Fragen nach
      • Benötigt Code-Kommentare, Hintergrundinformationen und Code-Beispiele

    Anhand dieser Zielgruppenanalyse schlüsselt sie dann auf, welche Dokumenttyen geliefert werden müssen, um diesen Anforderungen gerecht zu werden. Und auch wie sie geliefert werden müssen, z.B. als PDF oder Wiki mit Feedback-Funktion, Index etc.

    Die Rolle des technischen Redakteurs
    Ich habe von Entwicklern schon so oft gehört, dass sie endlich mal dokumentieren müssten oder endlich mal „gescheit dokumentieren“ müssten. Gleichzeitig hab ich mich immer gefragt: wie könnte ich dabei helfen? Immerhin heißt es doch auch „technische Dokumentation“, was ich studiert habe 😉

    Inwieweit der technische Redakteur die Entwickler beim tatsächlichen Dokumentieren unterstützen kann, hängt natürlich stark davon ab, wieviel Programmierwissen und -erfahrung er selbst hat. Aber es ist ununmgänglich, dass die Entwickler auch selbst dokumentieren – wer etwas selbst macht, weiß einfach am besten darüber Bescheid. Frau Parson hat sehr schön gezeigt, dass der Redakteur auch ohne selbst viel zu schreiben, doch sehr viel hier mitarbeiten kann.

    So können die Aufgaben des Redakteurs aussehen:

    • Zielgruppen- und Bedarfsanalyse
    • Dokumentationsworkflows erstellen
    • Terminologie erarbeiten, pflegen und bereitstellen
      • gerade in der Entwicklung lebt so manch uralter produktname ewig weiter
      • Missverständnisse untereinander werden vermieden
    • Neue Texte redigieren/korrigieren
    • Neue Texte evtl. schreiben
    • Strukur der Dokumentation entwickeln und überwachen
    • Dokumentvorlagen bereitstellen

    Und wenn man sich das mal genau anschaut, sieht man wieder, dass das ganz klassische Redakteursaufgaben sind. Nur ist der Fokus nicht so sehr darauf alles auch selbst zu schreiben, sondern viel mehr zu recherchieren, strukturieren, den Entwicklern eine Basis zu geben.

    Als praktisches Beispiel wurde abschließend noch ein Wiki gezeigt, das vor allem von den Entwicklern befüllt wird. Von der Redakteursseite wurde eine Grundstruktur angelegt und auch verschiedene Templates, damit die Entwickler nicht vor einer weißen Seite stehen und nicht wissen wo sie anfangen sollen. Der Redakteur überwachte nun die Entwicklung der Dokumentation und greift hier und da korrigierend ein. Zudem gibt es einen Freigabeprozess, so dass man auch wirklich nur qualitativ hochwertige Dokumentation publiziert.

    Für den einen oder anderen Software-Entwickler klingt das ganze vielleicht nach zu viel Reglement, aber ich habe schon zuviel schlechte und veraltete SW-Dokumentation gesehen und das klingt für mich nach einem plausiblen Weg aus der Misere.

    Fazit

    Ein hochinteressanter Vortrag (als PDF), der auch mal neue Wege für Redakteure aufgezeigt hat, die nicht in der klassischen Schiene liegen, aber am Ende doch perfekt auf das Skillset passen. Vielen Dank dafür! 🙂

  • Terminologie: DITA und DITA Open Toolkit

    Desöfteren ist mir aufgefallen, dass hier und da die Terme „DITA“ und „DITA Open Toolkit“ miteinander vermischt werden – das mag ich als strenge Redakteuse nicht leiden. Beispiel: „DITA generiert das so und so.“ Jetzt muss ich einfach mal damit aufräumen und sagen:

    ditaOT

    DITA
    Hier handelt es sich um die Darwin Information Typing Architecture. Das ist im Großen und Ganzen eine Ansammlung von DTDs und dahinter stehenden Konzepten, wie z.B. der Topic-Orientierung und der Vererbung/Spezialisierung. Hier wird also definiert, wie ich Topics schreibe und welche Elemente verwende. DITA an und für sich ist also mehr als eine Art Konzept und Regelwerk zu sehen.

    DITA Open Toolkit
    Wohingegen es sich beim DITA Open Toolkit um einen Baukasten mit verschiedenen Tools handelt, der etwas aus dem zaubert, das ich anhand des obigen Regelwerks produziert habe. Es ist eine schöne Ansammlung von Skripten und Stylesheets, deren Zusammenspiel am Ende aus den in DITA-XML geschriebenen Topics einen bestimmten Output (xhtml, pdf…) erzeugt. Das Toolkit ist also zur Transformation da, was eben auch heißt, dass man ohne das Toolkit trotzdem immer noch DITA „machen“ kann. Man könnte das gesamte Transformationsgerödel prinzipiell auch selber schreiben. Das Toolkit wurde im Endeffekt dafür entwickelt, um die Leute nicht vor eine große Hürde zu stellen, wenn sie DITA benutzen möchten, sondern ihnen schon direkt eine Transformationsbasis mitzugeben.

    That’s all folks

  • tekom Jahrestagung 2010 – Rückblick

    So, es ist geschafft 🙂

    Ich habe den Beinahe-Laptopausfall und die Vor-Vortrags-Nervosität halbwegs überstanden und ich denke, mein Vortrag ist ganz gut angekommen. Aber Genaueres weiß ich erst, wenn die Feedback-Bögen eintreffen. Und da bin ich äußerst gespannt! Meine Folien werde ich demnächst hier veröffentlichen sind nun unter Downloads erhältlich.

    Nun, wie sah es mit dem Rest der Tagung aus?

    Das Zielgruppen-Problem

    Bei mir und bei vielen anderen (u.a. auch im neuentdeckten Blog von Jason A. Nichols), herrschte ein wenig Unmut darüber, dass man in vielen Fortgeschrittenen- oder Experten-Vorträgen dann doch wieder mit sehr vielen Basics konfrontiert wurde. Ich weiß schon gar nicht mehr in welchem Vortrag das war, aber als man anfing uns zu erklären, dass Standards gut sind, da kam ich mir etwas veräppelt vor (das gehört für mich zur Grundausstattung des Redakteurs!). Vielen fiel es sichtlich schwer, den Vortrag zielgruppengerecht aufzubereiten. Vielleicht fehlt aber auch ein genaue Beschreibung der Klassifikationen „Einsteiger – Fortgeschrittene -Experten“? Ich habe mir rückblickend nämlich überlegt, dass ich meinen Vortrag wohl besser als „Für Experten“ eingestuft hätte, aber so richtig sicher bin ich mir nicht. Daher mein Vorschlag an die tekom, da vielleicht mal den Versuch einer detaillierten Klassifikation zu starten. Als Zuhörer ist es wirklich sehr ärgerlich, wenn man sich in einem Vortrag wiederfindet, der einfach gar nicht passt. Ich kann mir gut vorstellen, dass sich viele die Investition in die nächste Tagung nochmal gut überlegen.

    Die Idee von Urs Klenke nicht mehr so viele verschiedene Vorträge anzubieten, aber dafür ausgewähltere und diese auch zu wiederholen, finde ich prinzipiell auch ganz gut, wobei es organistorisch bestimmt ziemlich kompliziert wäre…

    iPad, iPhone, ePub

    Das war definitiv der Hype in diesem Jahr. Vieles war hier noch recht theoretisch – ich hoffe im nächsten Jahr auf erste richtige echte Beispiele!

    User assistance

    Der Hype dauert immer noch an, wobei ich da weiterhin hoffe, dass es auch hier noch mehr echte Beispiele geben wird. Die Theorie ist so langsam bekannt – jetzt will ich sehen was andere machen 🙂

    … und der Rest

    Es war einfach mal wieder nett so komplett unter „seinesgleichen“ zu sein und sich über das Fach austauschen zu können – und auch so einige Leute mal „in echt“ zu treffen 😉 Zielgruppen hin oder her – es waren immer noch Vorträge dabei, die einem hier und da wieder einen neuen Denkanstoß gegeben haben. Ich werde mir zum Beispiel in nächster Zeit einige Gedanken dazu machen, wie ich eventuell eine Verknüpfung meiner Hilfedateien mit den Textdateien unserer Applikationen hinbekommen kann, so wie in dem Vortrag „User Interface-Texte in der Dokumentation„.

    Und last but not least: endlich ist mir bei einem von Tony Selfs Vorträgen eine Frage eingefallen! Dafür wird man nämlich mit einem echten Aussie-Koala belohnt 😉

    Tony-Self-Koala

    EDIT: einen interessanten Rückblick bietet auch Sarah.

  • Redakteuse live – tekom Jahrestagung 2010

    Die alljährliche tekom-Jahrestagung rückt näher und ich freu mich schon riesig.

    Noch mehr freue ich mich, wenn ich den einen oder anderen Leser für meinen Vortrag „User assistance mit DITA“ gewinnen kann – gerne auch die Kollegen mitbringen 😉

    Hier nochmal als Erinnerung, wann und wo ihr mich dort finden könnt:

    User assistance mit DITA – Do 04.11., 11:15 Uhr, Raum 6.2

  • 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“.

  • DITA-OT um Sprachen erweitern

    Das DITA-Open-Toolkit bringt schon ziemlich viele Sprachen mit sich, aber irgendwo findet sich doch immer eine, die doch noch nicht abgedeckt ist.  Das Hinzufügen neuer Sprachen ist glücklicherweise kein Hexenwerk. Allerdings gilt letztere Aussage nur für Sprachen mit der Schreibrichtung „links nach rechts“ – die andere Richtung hab ich noch nie getestet und weiß nicht, ob es da noch andere Dinge zu beachten gilt.

    Das Sprachkürzel herausfinden

    Im Attribut xml:lang jedes Topics muss die Sprache angegeben werden. Es gibt verschiedene Übersichten im Netz über diese so genannten „Locale IDs“ , z.B. hier. Nehmen wir mal an, ich möchte kolumbianisches Spanisch einbinden. So lautet das Kürzel also: es-co.

    Sprache in strings.xml hinterlegen

    1. Öffne das Verzeichnis xsl/common in deinem DITA-OT.
    2. Öffne die Datei strings.xml.
    3. Kopiere die Zeile mit der Definition des Spanischen und füge die Kopie direkt drunter ein.
    4. Ändere das Sprachenkürzel entsprechend der gewünschten Sprache, hier als Beispiel kolumbianisches Spanisch.
      es-co

    Neue Sprachdatei anlegen

    1. Kopiere eine der vorhandenen Sprachdateien aus dem Verzeichnis xsl/commonund füge sie unter dem Namen es-co.xml in dasselbe Verzeichnis ein.
    2. Übersetze die Strings in der Datei in die gewünschte Sprache. Oder lasse übersetzen 😉
    3. Kopiere die Zeile mit der Definition des Spanischen und füge die Kopie direkt drunter ein.

    Fertig!
    Das war es tatsächlich schon. Ab sofort kannst du in den Topics und Maps das neue Sprachkürzel verwenden und die automatischen Strings wie z.B. „Hinweis“ oder „Achtung“ werden entsprechend lokalisiert 🙂

  • 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.

  • Softwarelokalisierung und Kontext

    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:
    html1

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

    html_translator

    Was am Ende dabei rauskam:

    html2

    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.

  • 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.