Vor kurzem gab es ein Ehemaligentreffen an der HS Karlsruhe an der ich meinen Master in Technischer Redaktion gemacht habe und bei dem auch Noch-Studenten dabei waren. Bei dieser Gelegenheit sollten Ehemalige Vorträge über ihre bisherigen Berufserfahrungen halten und da musste ich einfach darüber referieren, wie ich die Technische Redaktion inzwischen sehe 
Bei der letzten tekom-Tagung wurde ich von Studenten zum Thema “Was gefällt Ihnen besonders an dem Beruf des technischen Redakteurs?” interviewt und spontan war meine Antwort: “Die Vielfalt!” Bei der Erklärung meines Berufs sage ich zwar oft: “Da schreibt man Hilfen, also Handbücher”, aber tatsächlich macht es doch den kleinsten Teil meiner tatsächlichen Arbeit aus. Und das hätte ich mir zu Studiumszeiten nicht wirklich träumen lassen Für mich ist der Beruf der technischen Redakteurin unglaublich facettenreich und ich habe in den letzten Jahren sehr viele Facetten ausprobiert.
Klassische Rollen
Die klassische Rollendefinition wie ich sie aus dem Studium mitgenommen habe, sieht so aus:
Das deckt sich ziemlich mit den Studieninhalten, die man hat. Hm, ist das wirklich alles?
Wie es wirklich sein kann
Die Erfahrungen aus den letzten Jahren ergeben für mich eine deutlichere Erweiterung der möglichen Rollen des Redakteurs:
In meiner Laufbahn hab ich diese Rollen ausprobieren können und durch das Studium hab ich mich trotzdem dafür qualifiziert gefühlt. Denn man lernt ja im Studium nicht nur irgendwelche konkreten Fertigkeiten, also z.B. wie man Handbücher schreibt, sondern auch etwas allgemeinere Konzepte, wie z.B. “Wie mache ich etwas verständlich?”. Und genau das kann einen etwa zum User Experience Designer qualifizieren oder eben zum Produkttrainer. Genauso kann man mit dem Wissen aus Content-Management in den Bereich des Wissensmanagement einsteigen (WMS statt CMS eben 
).
Was ihr wollt…
Ich habe zwischendurch immer mal die Phase gehabt, dass ich glaubte doch mal ganz klassisch Handbücher schreiben zu müssen, damit ich mal auch “richtige technische Redaktion” mache. In dieser Zeit war ich äußerst unglücklich bei der Arbeit – es war einfach nichts für mich. Dass es tatsächlich ein unglaublicher Vorteil und total spannend ist, ein Allrounder zu sein (was für mich den TRler ausmacht), hab ich erst später erkannt. Es gibt einem nämlich die wunderbare Möglichkeit sich aus den vielen Richtungen, die man im Studium mitbekommt, eine oder ein paar herauszupicken. Das kann eine eher sprachliche Orientierung hin zum Autor und Terminologen sein oder eine eher technische hin zum XSLT-Entwickler oder Web-Entwickler etc. Und am Ende steht im Berufstitel auf der Visitenkarte vielleicht gar nichts mit “Redakteur” oder “Writer”, aber wie immer kommt es ja nicht so stark auf die Verpackung an Man muss sich dessen bewusst werden, was einem Spaß macht und einen wirklich interessiert (ja, ich weiß, das ist der schwere Teil). Und das ist meiner Erfahrung nach schon mal die halbe Miete
In der Softwarebranche kommen technische Redakteure früher oder später mit dem Thema “Oberflächentexte” in Berührung. Ob sie sie schreiben oder nur verwalten dürfen, variiert von Firma zu Firma.
Bei mir gehört das Betexten der Oberflächen zum Arbeitsalltag und hier möchte ich gerne mal berichten, wie sich das gestalten kann.
Terminologiekontrolle, Hilfe und Beta-Test
Ich sehe es als klaren Vorteil, dass ich die Produkte betexten darf. So kann ich nämlich von vorneherein für eine entsprechende Textqualität sorgen – mit dem richtigen Text in der Software entfällt oft so mancher Hilfetexte. Ich denke, jeder Redakteur musste schon die ein oder andere krude Formulierung von Entwicklern oder Produktmanagern umständlich in der Hilfe erklären…
Für einen Redakteur ist das Betexten der Oberfläche also eine wunderbare Möglichkeit, um für Verständlichkeit und Terminologiekontrolle zu sorgen, aber sie eignet sich auch wunderbar zur Recherche für die späteren Hilfetexte. Dabei ist man dann gleich Beta-Tester, der schon weit vor der Qualitätssicherung die ersten Bugs findet. Ich finde das sehr spannend, weil ich gerne Applikationen neu entdecke und dabei der erste Usability-Tester bin
Ein Feld, das sicher noch stärker von Redakteuren erobert werden muss
Wie funktioniert Software-Lokalisierung?
Nun aber mal zu den technischen Grundlagen: Glücklich kann man schon mal sein, wenn der Text überhaupt vom Code getrennt ist In der Regel machen das die meisten Software-Entwickler auch automatisch so. Erstens ist es für Entwickler übersichtlicher. Zweitens kann man so die Applikation leichter in verschiedenen Sprachen betreiben, was auch meistens gefordert ist.
Gerade im Web-Bereich gibt es verschiedene Möglichkeiten zur Anwendungsbetextung.
Gemeinsam ist den meisten, dass man man pro Sprache eine große Datei mit dem gesamten Anwendungstext hat. Für jede Stelle an der Text erscheinen soll, wird in der Software eine ID vergeben. Dieser ID ist dann in der Datei beliebiger Text zugeordnet: ein Wort oder sogar ganze Sätze.
Nehmen wir als Beispiel mal Wordpress, die Blog-Software, die ich hier benutze. Im Screenshot seht ihr den deutschen Text angezeigt:
”
Und hier seht ihr, wie das ganze in der Sprachdatei aussieht:
#: wp-admin/edit-page-form.php:202
msgid "pub_202"
msgstr "<b>Sofort</b> publizieren"
Die ID pub_202 wird in der Software als Platzhalter verwendet und je nach gewünschter Sprache wird der dazugehörige Text entweder aus einer deutschen oder bspw. englischen Sprachdatei gezogen. In der englischen Sprachdatei sieht der Eintrag so aus:
#: wp-admin/edit-page-form.php:202
msgid "pub_202"
msgstr "Publish <b>immediately</b>"
Bei einer Software wie Wordpress kommt man auf stolze 3342 Texteinträge (Einträge, nicht Wörter!).
Soviel zu dem Grundlegendsten. Wie solche Dateien nun editiert werden können, was es bei der Software-Lokalisierung zu beachten gilt und welche Felsen man wie umschiffen kann… das seht ihr in den bald folgenden Posts
Es war etwas ruhig in den letzten Monaten. Das lag nicht zuletzt an einem äußerst spannenden Projekt mit DITA, das zwar genug Bloggenswertes ergab, aber auch dafür sorgte, dass ich gar nicht dazu kam zu bloggen bzw. auch mal nicht über DITA nachdenken wollte
Nichtsdestotrotz will ich meine Erfahrungen zum Thema “User assistance mit DITA” gerne weitergeben und praktischerweise ist mein Vortragsvorschlag dazu für die tekom-Jahrestagung 2010 angenommen worden
Einen Vorgeschmack auf den Inhalt gebe ich euch schon hier und freue mich natürlich über jeden Zuhörer
Die Herausforderung: eine kontext- und tarifabhängige Software-Hilfe, die den Kunden in seinen ersten Schritten begleitet. Dieser Vortrag stellt den Projektverlauf vor, in dem diese “embedded help” entwickelt wurde. Der Bogen wird dabei von den wirtschaftlichen Beweggründen über die technische Umsetzung mit DITA bis hin zu den Lessons learned gespannt. Einen Schwerpunkt bilden dabei die Möglichkeiten, die man mit DITA out-of-the-box hat, und jene, die man erst selbst entwickeln muss.
Der Dating DITA-Vortrag kommt mir gerade wieder in den Sinn, wo ich mich Metadaten beschäftige. Und da stehen mir wirklich die Haare zu Berge – das ist das erste Mal, dass ich DITA wirklich, wirklich unpraktisch finde und noch keine gute Lösung habe, wie ich da in Zukunft verfahren soll.
Wie man komplette Topics nicht rausfiltert
Nehmen wir mal an, ich generiere aus einer Map einen User-Guide und einen Admin-Guide. Viele Inhalte überschneiden sich, aber einige sind exklusiv nur für eine der Zielgruppen gedacht.
Bisher dachte ich mir das so: Wenn ich von einem kompletten Topic weiß, dass es nur audience=”user” ist, dann setz ich das Attribut auf das Root-Element, also so:
<task id="123" product="wundertuete2" audience="user">...
Dann wird doch dieses Topic, auf diese Weise attributiert, nun beim Generieren des Admin-Guides bestimmt nirgends verlinkt bzw. gar nicht erst generiert.
Weit gefehlt. Das Topic wird generiert und zwar leer (und damit nicht valide). Alle Verlinkungen, sprich: alle Topicrefs, sind auch im Output existent, führen aber natürlich ins Leere.
Wie man komplette Topics wirklich rausfiltert
Um zu verhindern, dass etwas überall verlinkt wird, muss man das Attribut auf jeden Topicref setzen!
<topicref id="123" product="wundertuete2" >
<
Und zwar auf wirklich jeden, auch die in den Relationship tables. Und das in allen Maps in denen das Topics vorkommt. Wenn ich da an zentrale, so gut wie immer gültige Attribute wie audience oder product denke, wird mir übel. Wie soll man das denn anständig pflegen oder gar mal aktualisieren? So müsste jeder Redakteur für jedes Topic erneut prüfen, welche Gültigkeit es hat und es auch wieder in der Map hinterlegen. Und darauf hab ich eigentlich überhaupt keine Lust.
(Im Übrigen gilt das Prinzip nicht nur für Topicrefs, sondern auch für den Einsatz anderer interner Verlinkungsarten wie xref oder related-links)
Zudem ist es sehr inkonsistent, dass es hier plötzlich ein eigenes Element audience gibt, zusätzlich zum gleichnamigen Attribut. Um die Verwirrung zu komplettieren, kann man beides gleichzeitig auf einen einzelnen Topicref beziehen.
<topicref id="123" product="wundertuete2" audience="user">
<topicmeta>
Eine passende Diskussion auf der Yahoo-Group hab ich schon gefunden, aber eben leider noch keine Lösung. Und sowas muss ich kurz vor dem Wochenende rausfinden 
Dateiendungen in DITA – kleines Problem
Heute ein kleiner Wissensschnipsel zu Dateiendungen in DITA. Prinzipiell ist es inzwischen erlaubt, sowohl Dateien mit XML-Endung als auch welche mit DITA-Endung in eine Map zu integrieren. Ich persönlich finde ja so einen Misch-masch nicht gut, und als ich es mal getestet habe, hat es auch nicht gut funktioniert.
Kommen wir aber zu einem Problem, das seine Ursache in diesem Misch-Masch hat, und das in den meisten Fällen gar kein Problem ist, außer man schafft es mal wieder einen Sonderfall zu erwischen. So wie ich
Ich musste gerade bei einer Transformation einem Topic die Information mitgeben, welchen Parent es hat – und zwar musste es die ID des Parents sein.
Da kam mir sehr gelegen, dass in unserem Redaktionssystem der Dateiname auch als Topic-ID fungiert .
Also geb ich hier einfach das href-Attribut des Parents aus, das ja den Dateinamen beinhaltet. Sehr einfach, juhu!
Aber Moment im Endergebnis der Transformation finde ich plötzlich das hier
Die Parent-ID stimmt im Prinzip, bloß ist da plötzlich XML als Dateiendung angegeben! Was soll das denn jetzt?
Ich habe eine Weile gesucht, blieb aber ratlos. Ein Artikel zur Verwendungvon Dateien mit XML-oder DITA-Endung hat mich dann auf die Lösung gebracht. Beim Generieren der temporären Dateien aus denen das Toolkit letzten Endes die Ausgabe baut, kann man sich auch “aussuchen” welche Dateiendung diese temporären Dateien haben sollen.
Standardmäßig werden sie in XML generiert, aber das kann man in seinen Build-Dateien auch ändern.. Also habe ich in meine Build-Datei flugs folgenden Parameter eingebaut:
Und schon hat es gepasst!