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.

Community-Übersetzungen mit Google Translate

Es ist der Traum eines jeden Budgetverantwortlichen: „Wir stellen den zu übersetzenden Text ins Internet und die Community macht den Rest. Bei Wikipedia klappt das doch auch und bei dem ganzen Open-Source-Kram. Die Leute machen das umsonst.“ Facebook setzt schon voll auf die Community bei diesen Dingen.

Google Translate

Bevor ich weiter in die „Ja, aber im professionellen Umfeld kann man doch nicht…“-Diskussion einsteige, gehe ich einen Schritt zurück und widme mich einer der aktuellsten Google-Neuheiten: Google Translate (oder „Google Übersetzer“ wie er auf Deutsch heißt).

Google hat ein neues Tool mit einem neuen Ansatz entwickelt:

Wir geben unzählige Texte mit Milliarden von Wörtern in den Computer ein. Dabei handelt es sich sowohl um einsprachigen Text in der Zielsprache als auch um abgeglichene Beispielübersetzungen von Menschenhand. Anschließend wenden wir statistische Lerntechniken zur Erstellung eines Übersetzungsmodells an. Bei den Auswertungen haben wir sehr gute Ergebnisse erzielt. (Quelle)

Google-Translate ist ein Online-Übersetzungsservice, den jedermann ziemlich einfach nutzen kann.

Übersetzen lassen

Man kann eine Übersetzungsfunktion in seine Homepage einbinden, die es den Lesern ermöglicht die Seite mit 2 Klicks in einer anderen Sprache anzeigen zu lassen.

Um eine Webseite in einer völlig fremden Sprache wenigstens ein bisschen zu verstehen, ist das oft schon genug. Hier und da ist die Satzsstellung nicht ganz korrekt, aber wie bei einer Unterhaltung mit einem fremdsprachigen Menschen, kann man sich auch erstaunlich viel zusammenreimen / ableiten. Dennoch stößt man noch auf genug der eher ulkigen Sätzen, die noch zeigen, dass eine automatische Übersetzung nicht an einen Muttersprachler heranreicht. Das sagt Google aber auch selbst klipp und klar. Diese Funktion erschließt einem also einen noch viel größeren Teil der im Netz verfügbaren Information.

Selbst übersetzen

Soweit die eher passive Komponente. Kommen wir zu dem Teil bei dem man als Teil der  Community aktiv werden  kann.

  1. Hierzu installiert man die Google Toolbar in seinen Browser.
  2. http://translate.google.com/translate_tools?hl=de aufrufen.
  3. Die Schaltfläche mit der gewünschten Zielsprache (also die Sprache in die man übersetzen möchte) auf die Lesezeichenleiste (Anmerkung an Google: Fehler in der Doku: Toolbar wird hier falsch verwendet) ziehen.
  4. Eine Seite aufrufen, die man übersetzen möchte (hier www.idratherbewriting.com).
  5. Danach auf den Link in der Lesezeichenleiste klicken.

Nun wird die Seite vorübersetzt, sofern möglich, angezeigt. Sobald man seine Maus über einen Absatz bewegt, bekommt man die Möglichkeit eine bessere Übersetzung einzugeben.

Klickt man auf den Link, öffnet sich direkt ein kleines Eingabefeld, in das man die Übersetzung eingeben kann. Die Übersetzung landet nach dem Abschicken im Übersetzungsppol von Google.

An diesem Punkt gibt man selbst eine völlig neue Übersetzung ein und hat keine Möglichkeit auf ein TM zuzugreifen, das einem z.B. 80%-Matches anzeigt. Google will hier vor allem soviel Übersetzungssegmente wie möglich sammeln.

Fazit

Aktuell ist es ein Tool, dass es einem ein manches Mal vielleicht ein bisschen einfacher macht auf fremdsprachigen Seiten zu surfen. Ein Szenario, dass eine Firma ihre Kundenwebseite gar nicht mehr übersetzt, sondern einfach nur Google Translate einbindet, scheint mir utopisch. Denn man kann hier nie 100%ig gewährleisten, dass nicht doch Müll auf der Seite steht.

Und bei Googles eigenen, automatisch übersetzten Seiten hätte ich im Übrigens gerade sehr gerne eine korrekte Übersetzung ins Deutsche eingegeben oder versteht das jemand? 😀

In solchen Fällen können Sie ein Translation Memory mit einer Übersetzung, indem Sie folgende Schritte Gesellschafterin

Nachdem ich mir nun Google Translate für jedermann angeschaut habe, kommt demnächst die Profi-Version dran: Google Translator’s Toolkit.

Firefox & seine html.css

Ich bin gerade dabei meine DITA-HTML-Hilfe zu stylen. Da es lediglich um Aufhübschen ohne große Effekte geht, reaktiviere ich also meine HTML & CSS-Fähigkeiten.

Eben hat mich aber eine Sache zum Wahnsinn gebracht, von der ich echt überrascht bin, dass ich sie noch nie bemerkt habe. Denn ich habe schon durchaus einige Zeit beim Webseiten-Bauen verbracht und das eigentlich immer nur unter Firefox.

In meinem Firebug hieß es bei einigen Elementen plötzlich, dass sie ihre CSS-Styles aus einer „html.css“ beziehen würden. Nun hieß meine eingebundene CSS-Datei aber anders! Ich hatte eine solche Datei nie erstellt und auch nie eingebunden! Argh!

Nun diese Datei repräsentiert anscheinend die Default-Einstellungen des Browsers, d.h. solche Dinge wie Überschriften werden standardmäßig gestylt, was ja auch sehr nützlich sein kann, wenn eine HTML-Seite mal gar nicht „extra“ gestylt ist. Aber irgendwie ist mir in Firebug diese Datei noch nie aufgefallen…

Extrem hilfreich zu wissen, wenn man mal wieder Webdesign betreibt. Wer mehr wissen möchte, möge bitte hierlang gehen: Undoing html.css

PS: Ich habe bestimmt noch nicht das tolle Firefox-Addon IETab empfohlen. Damit kann man den Internet Explorer im Firefox verwenden, was absolut genial ist 🙂

Spezialisierung: Eigene DITA-Attribute definieren

DITA bietet bereits einige Attribute, die schon sehr viele wichtige Dinge in der technischen Dokumentation abdecken: product, audience, platform seien da als Beispiele genannt.

Wenn es um sehr firmenspezifische Dinge geht, benötigt man hier schnell eigene Attribute. Für mich persönlich sehr wichtig, sind auch vorgegebene Attributwerte, weil eine vorgegebene Auswahl immer sehr viel weniger fehleranfällig ist.

Was bedeutet Spezialisierung?

In DITA nimmt man etwas Vorhandenes, also einen bereits vorhandenen Topictyp (z.B. Concept) oder ein bereits vorhandenes Attribut, und leitet davon seine eigene Version ab: man spezialisiert. Inbesondere in Bezug auf Topictypen ist wichtig zu wissen, dass man Festlegungen der DTD von der man ableitet, nicht „aufweichen“ kann. Wenn ein Element <hups> in der Ur-DTD zwingend erforderlich ist, kann man es in der Spezialisierungs-DTD nicht optional definieren.

Attribute spezialisieren

Es gibts 2 Arten von Attributen, die man spezialisieren kann: props (speziell für Filtern) und base (Sinn und Zweck hat sich mir noch nicht erschlossen…). Da ich mein neues Attribut zum Filtern des Contents benutzen möchte, benutze ich daher das props-Attribut.

Schritt 1: Attribut deklarieren
Ich werde nun ein Attribut definieren, das beschreiben soll, für welchen Hilfekontext das Element gilt: für die Hilfe im Web oder für die Hilfe in der Software.

  1. Zuerst erstelle ich eine Datei namens helpContextPropsDomain.ent mit folgendem Inhalt:



    Im ersten Teil lege ich den Namen des Attributs (help-context) fest und in meinem Fall auch 2 vordefinierte Werte (webpage, software).
  2. Ich speichere die Datei im dtd-Verzeichnis des DITA-OT ab.

Schritt 2: Attribut der DTD bekannt machen

  1. Nun öffne ich die concept.dtd und lege noch eine Sicherheitskopie von ihr unter anderem Namen ab Man weiß nie… ;).
  2. Unter dem Bereich DOMAIN ATTRIBUTE DECLARATIONS füge ich ein:

    SYSTEM "helpContextPropsDomain.ent"
    >
    %help-context-props-d-dec;
  3. Unter dem Bereich DOMAIN ATTRIBUTE EXTENSIONS erweitere ich :

  4. Unter dem Bereich DOMAINS ATTRIBUTE OVERRIDE erweitere ich :

    &ui-d-att; &hi-d-att; &pr-d-att; &sw-d-att;
    &ut-d-att; &indexing-d-att;&help-context-props-d-att;" >
  5. Diese Schritte müssen nun für alle Topictypen wiederhiolt werden, für die man das Attribut braucht.

Schritt 3: testen 🙂

  1. Ich erstelle eine XML-Datei auf Grundlage dieser DTD
  2. Ich füge das Attribut _help-context=“webpage“_ in ein-Element ein
  3. Ich jage das Dokument durch einen Validator – und wenn der nicht meckert, hat es funktioniert

Spezialisierung in XMetal DITA Edition
Der XMetal DITA Edition bindet ein DITA-OT ein. Wie es scheint benutzt er dieses ausschließich zum Generieren.
Die DTDs, die XMetal benutzt, liegen im Programmverzeichnis unter „…XMetaL 5\Author\DITA\DITA_OT_DTD\“<.

  1. D.h. die oben erstellten bzw. bearbeiteten Dateien müss dort hinein kopiert werden.
  2. XMetal neu starten
  3. Ein Concept anlegen
  4. Und sich freuen, dass man ein neues Attribut im Attribute Inspector sieht 🙂

Mehr zum Thema
In Eliot Kimbers Tutorial erfahrt ihr mehr zur Spezialisierung.

DITA und XMetal

Und jetzt erst finde ich diese Präsentation von Simon Bate (Scriptorium)! Meine Güte, da hätte ich mir einiges an nerviger Recherche sparen können.

Aber ich will mein Wissen natürlich brav weitergeben: also holt euch Popcorn, was zu schreiben und stellt das Radio aus. Hier wird es wirklich interessant und praxisbezogen 🙂

Hierbei muss ich erwähnen, dass ich Slideshare einfach großartig finde. Im deutschen Raum scheint es noch gar nicht sehr verbreitet zu sein. Vielleicht sollte man das auch mal den Leuten der tekom zeigen. Es wäre ja viel cooler, die Tagungspräsentationen hier zu posten, als irgendwo in den Irrungen&Wirrungen der tekom-Webseite (die sich nicht gerade durch einen großen information scent hervortut). Und ich glaub auch fast, dass man hier auch mehr Hits erhalten würde.