Software-Lokalisierung für Technische Redakteure

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

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

Geschrieben in Beruf,Erweiterter Horizont,Lokalisierung,Übersetzung | 1 Kommentar

User assistance mit DITA – Redakteuse live

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.

Geschrieben in DITA,Erweiterter Horizont,Softwaredokumentation | 4 Kommentare