Die Technologie hinter dieser Website ist eine Demonstration der Herangehensweise von le-tex in Bezug auf medienneutrales Publishing. Beim Bearbeiten und Veröffentlichen dieser Seiten kommen viele der auch in der laufenden Produktion eingesetzten Tools zum Einsatz.

Datenformat: DocBook XML

Der textuelle Inhalt wird in einer einzigen XML-Datei gemäß dem DocBook-Dokumenttyp „book“ gepflegt, der ansonsten für einige der bei le-tex gesetzten Bücher zum Einsatz kommt.

Versionskontrolle: svn

Diese XML-Datei, die übrigen Inhaltsdaten (im Wesentlichen die Masterdateien der Bilder), die Layoutinformationen und die Konfiguration der HTML-Generierung befinden sich unter Versionskontrolle in einem svn-Repository.

Die Versionskontrolle Subversion (svn) setzt le-tex für zahlreiche Softwareentwicklungsprojekte ein. In einigen Produktionslinien befindet sich auch der Inhalt und die Konfiguration (z. B. projektspezifische LaTeX-Makros oder Makefiles) in svn-Repositories.

Die Versionskontrolle svn ermöglicht bei diesem und anderen Projekten:

  • gleichzeitige („konkurrierende“) Bearbeitung mit automatischem Zusammenführen der Änderungen bzw. mit Konflikterkennung, 
  • Nachvollziehen der Änderungen (wer hat es wann wie geändert, und warum) und 
  • Wiederherstellung älterer Versionen. 

Redaktion

Die XML-Datei wird mit einem visuellen XML-Editor oder mit einem XML-tauglichen Texteditor gepflegt. Aus dem Editor heraus erfolgt optional eine Rechtschreibprüfung. Als Tools kommen z. B. GNU Emacs/xemacs mit aspell oder neuerdings auch oXygen XML Editor zum Einsatz.

Größere neu geschriebene Passagen erfahren i. d. R. ein sprachliches Copy-Editing.

Übersetzung

Diese Website wird in Deutsch und Englisch angeboten. Dabei werden inhaltliche Änderungen an der deutschen Datei vorgenommen. Der Übersetzungsworkflow ist dabei wie folgt.

Eine externe Übersetzerin erhält die komplette Datei und übersetzt sie mit Hilfe eines Computer-Aided-Translation- (CAT-) Tools, SDL Trados.

Mit Hilfe dieses Tools wird ein so genanntes Translation Memory gepflegt, das sich Paare von übersetzten Phrasen dieser Website (und anderer Publikationen von le-tex) merkt. Das Tool kann dann bereits bekannte Textpassagen – je nach Grad der Übereinstimmung – automatisch übersetzen, so dass nur die geänderten oder neuen Passagen neu übersetzt werden müssen.

HTML-Erzeugung

Mit Hilfe eines XSLT-2.0-Stylesheets werden die einzelnen XHTML-Seiten aus den DocBook-Dateien erzeugt.*

Ein CSS2-Stylesheet bewirkt das eigentliche Layout der so erzeugten HTML-Seiten.

Die Rohfassungen der Bilder werden mit ImageMagick auf die Zielgröße skaliert.

Ein Makefile automatisiert die Generierungsprozesse und sorgt in Verbindung mit einem validierenden XML-Parser und weiteren Skripten dafür, dass die Daten den Web-Standards entsprechen und dass keine Links ins Leere zeigen. (Dass nur auf diejenigen fremdsprachigen Seiten verlinkt wird, für die es tatsächlich eine Übersetzung gibt, dafür sorgt bereits das XSLT-Sheet.)

Die einzigen Befehle, die sich ein Copy-Editor merken muss, sind dabei svn update, make und svn commit, denn damit kann er lokal die geänderten Quelldaten aktualisieren, eine Vorschau der Site erzeugen und die abermals geänderten Quelldaten nach der Bearbeitung ins svn-Repository zurückspielen. Der Webmaster muss (und darf) zusätzlich make install ausführen, um die Seiten freizuschalten, d. h., auf den Webserver hochzuladen.

Warum kein CMS?

Diese Site besteht aus statischem Inhalt, der gelegentlich (manchmal mehrmals wöchentlich, dann wieder einen Monat nicht mehr) aktualisiert wird. Wie oben ausgeführt, erfolgt die Redaktion, Übersetzung und HTML-Generierung mit Hilfe ausgereifter Tools.

le-tex setzt diese kommandozeilengesteuerte xemacs-/aspell-/make-Toolchain nicht bloß deswegen ein, weil es nichts anderes kennt, sondern weil diese Toolchain für die gestellte Aufgabe mächtiger, schlanker und damit kostengünstiger ist als eines der gängigen Content-Management-Systeme, die viel mehr Infrastruktur benötigen (Datenbank, Caching), deren Datenbankmodelle für semistrukturierten Inhalt häufig inadäquat sind und die typischerweise einiges an Systemintegration und Kompromissen erfordern, um Standardtools wie ein Translation Memory anzudocken.

Die Alternative am anderen Ende des Spektrums, statische HTML-Seiten, hätten dazu geführt, dass man jegliche Agilität eingebüßt hätte, was Umstrukturierung oder Layoutänderung angeht. Denn wenn man 40 HTML-Dateien mit redundantem Code hätte anfassen müssen, um globale Änderungen durchzuführen, würde man die Seite lieber jahrelang so lassen, wie sie ist. Das war genau das Schicksal der alten Seiten.

Der einzige Wunsch für die Zukunft (und das, was gute CMSe der beschriebenen Herangehensweise voraus haben) ist eine Workflowkomponente, die über die rein technische Ablaufsteuerung eines Makefiles hinausgeht: Mit Hilfe eines Business-Process-Management-Systems sollen später die heute noch rein informell angestoßenen Prozesse der Website-Pflege, des Copy-Editings, der Übersetzung und der Freischaltung in einen nachvollziehbaren Rahmen gepackt werden.

*

Wenn Sie dem Link folgen, sagen alle Browser außer Firefox, dass die „Seite“ nicht angezeigt werden kann. Möglicherweise versuchen die Browser, die .xsl-Datei so zu interpretieren, als ob sie im Browser HTML erzeugen müsste. Verwenden Sie die in diesem Fall die „Quellcode-anzeigen“-Funktion Ihres Browsers, um den XSLT-Quelltext zu sehen.