Kategorie: Beruf

  • Community Management und technische Kommunikation

    In den letzten Monaten ist das Thema „Die Zukunft des Technischen Redakteurs“ ziemlich präsent gewesen. Mit den trendigen Themen Crowdsourcing und Community stellt man sich als technischer Redakteur so langsam die Frage: „Verlier ich meinen Job an die Crowd in der Cloud?“.

    Ein mögliches Betätigungsfeld, oder besser gesagt: ein Feld bei dem wir Redakteure uns was abschauen können, ist das Community-Management. Ich kannte den Begriff Community-Manager eigentlich nur von Spiele-Foren und habe das nicht besonders ernst genommen – in meinem Kopf waren das „nur“ Forenadministratoren (Asche auf mein Haupt, jaja). Wie ich mich jetzt mit dem Begriff „Community“ im Umkreis technischer Kommunikation auseinandergesetzt habe, ist mir der Begriff „Community Manager“ wieder eingefallen. Ich suchte, ich fand – und war erstaunt. Da ist ja richtig was los! Das ganze ist gar keine Randerscheinung irgendwelcher Nerd-Foren, sondern ein immer stärker werdender Berufszweig, in Deutschland sogar mit einem eigenen Verband, dem Bundesverband Community Managament (BVCM).

    Und was ist Community-Management?

    Community Management ist die Bezeichnung für alle Methoden und Tätigkeiten rund um Konzeption, Aufbau, Leitung, Betrieb, Betreuung und Optimierung von virtuellen Gemeinschaften sowie deren Entsprechung außerhalb des virtuellen Raumes. Unterschieden wird dabei zwischen operativen, den direkten Kontakt mit den Mitgliedern betreffenden, und strategischen, den übergeordneten Rahmen betreffenden, Aufgaben und Fragestellungen. (Quelle: BVCM)

    Der Begriff „Community“ ist also sehr weit gefasst: darunter fällt ein Forum, wie auch der Kreis an Twitter-Followern oder Facebook-Fans. Wenn man sich Stellenanzeigen anschaut, merkt man allerdings, dass es da noch kunterbunt zugeht. Community Manager, Social Media Manager – so ein richtiger Unterschied ist da häufig noch nicht zu bemerken.

    Und was hat das mit technischer Kommunikation zu tun?

    Ich denke, wir Redakteure können von Community Managern einiges lernen. Der Trend Hilfe-Communities heißt einerseits, dass wir Redakteure nicht mehr alles schreiben, was an den Kunden geht. Das ist der Punkt, der uns ein wenig Zukunftsangst verschafft. Andererseits bietet er eben auch neue Möglichkeiten. Das „Entstehen“ von Community Managern zeigt, dass man eine Community eben nicht einfach so sich selbst überlassen kann. Es muss immer ein paar geben, die ein wenig lenken, hier und da Leute zur Ordnung rufen und die grobe Richtung im Auge behalten, ganz egal ob es sich um ein Spieleforum, eine Facebook-Seite oder ein Hilfeportal handelt.

    Und da kommen wir Redakteure dann doch noch ins Spiel.

    Von den Community-Managern können wir  lernen, wie man eine Community aufbaut, wie wir die Nutzer so miteinbeziehen, dass sie sich engagieren, wie wir mit Konflikten (oder wie man heute auch sagt: Shitstorms) umgeht etc.

    Zusammen mit den Fähigkeiten eines Redakteurs könnten sich außerdem die folgenden Aufgaben ergeben: eine gewisse Grundstruktur vorgeben, einen Grundstock an Content ausäen, Redaktionsleitfäden konzipieren, Hilfe-Artikel aus der Community lektorieren, Feedback einarbeiten, Übersetzungen anstoßen und auch weiter selbst Artikel schreiben, bloß eben nicht mehr alleine 🙂

    Wie kann so eine Hilfe-Community aussehen?

    Ein interessantes Beispiel ist  die ubuntu-Community. ubuntu ist eine sehr populäre Linux-Distribution, die von der Firma Canonical gesponsert wird. Einer der Community Manager ist der Canonical-Mitarbeiter Jono Bacon, der auch das sehr lesenswerte Buch The Art of Community: Building, Managing, and Supporting Cooperation Over the Internet geschrieben hat.

    Ich habe diese Community als Beispiel genommen, weil sie verschiedene Arten der Beteiligung ermöglicht: Entwickler können entwickeln, Grafiker mitdesignen und Schreibwütige eben auch dokumentieren.

    Der Doku-Bereich gliedert sich dabei in 2 Teile: die offizielle System-Dokumentation, die mit der Distribution ausgliefert wird und bei der nur bestimmte Mitglieder mitwirken dürfen und die Community-Doku bei der jeder mitmachen kann. Es gab wohl auch schon Überlegungen, diese 2 Doku-Bereiche zu einem zu verschmelzen, aber ich vermute, über die „offizielle“ Doku wollen sie doch noch mehr Kontrolle haben, damit auch wirklich kein Mist drinsteht, und das ist im Community-Bereich dann doch etwas schwieriger zu überblicken.

    Sind Hilfe-Communities die Zukunft?

    In einigen Bereichen sicherlich. Was Open-Source angeht, sind sie sogar schon Realität. Im Firmenumfeld wird es in einigen Bereichen sicherlich immer mehr kommen. Für manche wird aber sicherlich die folgende Frage immer ein Showstopper sein: wer ist denn eigentlich haftbar, wenn in einem Community-Hilfe-Artikel etwas Falsches steht und daraus Schaden entsteht? Und auch die Frage der Übersetzung ist da meiner Meinung nach ziemlich schwierig. Klar, kann man das auch die Community machen lassen, aber wenn man Ende ein Produkt mit Doku ausliefern muss, kann man sich evtl. doch nicht drauf verlassen. Um eine Community zu schaffen, muss man ein Stück Kontrolle aufgeben, aber die Frage ist, ob es nicht ein gewisses Maß an Kontrolle gibt, das man als Firma einfach behalten muss, um nicht in die Bredouille zu geraten.

    Ich glaube, dass der Community-Trend uns Redakteure nicht die Jobs kosten wird. Zum einen, weil manche Dokus aus rechtlichen Gründen einfach nicht in die Community gegeben werden können 😉 Zum anderen sehe ich eher einfach nur die Entstehung einer neuen Facette für Leute mit TR-Fähigkeiten – und zwar eine sehr spannende 🙂

  • Die Redakteuse schreibt auch für dich!

    Hier und da konnte man es schon von Twitter ahnen und der eine oder andere wusste es: ich arbeite ab sofort freiberuflich als Technische Redakteurin.

    Ich werde weiterhin hier als Redakteuse schreiben, aber wer nun auch mit mir zusammenarbeiten will, darf gerne zu mp dokumentation rübergehen.

    Heute mache ich mich auch auf den Weg zur tekom-Jahrestagung – also vielleicht sieht man sich ja 🙂

    Logo mp dokumentation

  • 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? 🙂

  • 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! 🙂

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

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

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


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

  • Technische Redaktion – eine gute Wahl?

    Diese Woche bekam ich eine Anfrage einer zukünftigen TR-Studentin, die gerade etwas verunsichert ist:

    Seit ich die Zusage habe stolpere ich aber eigtl. nur noch über Berichte, wie langweilig und undankbar der Job als Technische Redakteurin sei und dass sowieso die meisten nicht lange in diesem Job durchhalten. Langweilig deswegen, weil es oft nur noch darum ginge, die von den Entwicklern gelieferten Texte in die Doku zu kippen. […] Wie beurteilst du denn die Punkte Langeweile und Undankbarkeit? Was denkst du, sollte man unbedingt mitbringen, wenn man diesen Beruf ausüben will?

    Suche dir eine interessante Branche
    Das ist für mich einer der wichtigsten Punkte. Bei mir waren es schon immer Software und Internettechnologien, die so mein Steckenpferd waren. Für mich sind die Recherche und das Ordnen meiner Ergebnisse mitunter die interessantesten Aspekte an der Arbeit und da sollte einen der Gegenstand doch etwas mehr interessieren. Einen Ausflug in die Elektrotechnik habe ich z.B. sehr schnell beendet, da ich kein besonderes Faible dafür habe. Ich konnte mich schon in die Materie einarbeiten, aber am Ende fiel es mir immer schwer mich in den Installateur oder Inbetriebnehmer hinzuversetzen – und dementsprechend habe ich sicherlich auch nicht die besten Hilfetexte meiner Laufbahn abgeliefert. Es war einfach nichts für mich.
    Suche dir deine Schwerpunkte

    Ich hab schon die Vielfalt des Studiums, des Jobs und der späteren Möglichkeiten erwähnt. Man kann sich seinen Schwerpunkt suchen und den möglichst bei der Jobwahl berücksichtigen. Wenn ich bspw. feststellen würde, dass ich nur Entwicklertexte in ein Worddokument reinkopieren und umformatieren soll… DAS ist  keine technische Redaktion.

    Mach was draus

    Was ist, wenn man schon im Job steckt und nicht so ganz zufrieden ist? Nun, ein Weg ist mal zu schauen, was der Horizont um einen hergibt. Also Augen offen  halten und selbst aktiv  werden. Was kann man bspw. im Team und in der Zusammenarbeit optimieren? Du merkst z.B. dass es doch immer wie zu Inkonsistenzen beim Schreiben kommt, weil der Redaktionsleitfaden nicht eindeutig ist. Hey, organisiere ein  regelmäßiges Review von Texten und ggf. das Update des Leitfadens. Oder du fängst mal an überall für Terminologiearbeit zu werben, weil diese aktuell nur von der TR betrieben wird.

    Bringe folgendes mit

    Neugier, Geduld (auch bekannt als:  Leidensfähigkeit und langer Atem), gute Strukturierungsfähigkeit, ein bisschen Unnachgiebigkeit (auch bekannt als: den Technikern mit 100 Rückfragen alles aus der Nase ziehen), ein bisschen Kämpfertum (auch bekannt als: und wir kriegen euch alle dazu diesen Term zu verwenden!). Und natürlich: einwandfreie Sprachkenntnisse und Interesse an Technik.

    Akzeptiere einiges… 🙂

    Gegen die Langweile kann man schon vorab sehr viel tun – das ist meine Meinung. Außer man ist vielleicht in einer sehr strengen und unflexiblen Umgebung, aber für mich wäre sowas schon mal gar nichts 😉

    Und nun zurUndankbarkeit… ja… das ist so. Jeder kann schreiben (handwerklich gesehen) und manche verstehen nicht einmal den Unterschied zwischen dem vom Entwickler geschriebenen Text und dem vom Redakteur (ok, das sind echt die ganz harten Nüsse, die man am besten ab sofort mit dem bösen Blick straft). An der TR wird gern gespart – mit Zeit,  Geld und Anerkennung. Manchmal kann man die Hilfe nicht so gut machen wie man gerne möchte, manchmal kriegt man doch wieder einen Term um die Ohren geklatscht, den das Marketing dann bitte doch anders haben möchte… Manchmal kriegt man einfach echt nur die Krise.

    Das muss man teilweise einfach ertragen können – und teilweise muss man einfach so kämpferisch sein und unermüdlich immer wieder die Wichtigkeit des eigenes Berufs betonen. Für mich ist dieser Beruf gerade wegen seiner Vielfalt noch immer genau mein Ding. Früher sah ich es als Makel ein Allrounder zu sein, so nach dem Motto: man kann viel, aber nichts zu 100%. Inzwischen weiß ich, dass auch 75-80% langen und genau das mein Vorteil ist 🙂

    Nachtrag: Sehr interessant hierzu ist auch der Artikel Tired of technical writing? How I revjuvenated my career