Ausgerechnet Webworks hat für den ePublisher mit Publish to Wiki (PDF) ein Feature angekündigt, das ich bei meinem Mediawiki-Projekt im letzten Jahr schmerzlich vermisst habe. Die wenigen Add-ons/Makros, die es für Word-to-Wiki o.ä. gab, waren allesamt nicht überzeugend, und dass ich nur einen normalen User-Zugriff aufs Wiki hatte, half auch nicht gerade weiter.

Ob ePublisher es besser hinbekommt, bleibt abzuwarten – da dieses Programm aber recht teuer und mein Bedarf daran sehr klein ist, bin ich auch weiterhin auf manuelles Wikifüllen oder liebevoll gestrickte Skripte angewiesen. Aber vielleicht nimmt ja Madcap die Idee auf…?

Share

Software-Dokumentation in einem Mediawiki

 Dokumentation, Übersetzung  Kommentare deaktiviert für Software-Dokumentation in einem Mediawiki
Sep 012008
 

MediawikiVielleicht werde ich irgendwann noch einen ausführlichen Bericht über mein Projekt (ca. 100 Seiten jeweils in Deutsch und Englisch) schreiben, doch heute möchte ich vorweg einige wichtige Gedanken zum Thema „Dokumentation in einem Mediawiki“ teilen.

  • Mehrere Bearbeiter – im Prinzip eine tolle Sache, allerdings ist es in Sachen QM und Konsistenz eine große Herausforderung, wenn man von außen die Artikel liefert und der Kunde dann Texte ändert oder hinzufügt, ohne das nochmals zurückzumelden. Und das in zwei Sprachen und bei ggf. nicht sichtbarer Versionierung.
  • „Suchen und ersetzen“ ist eine sehr wichtige, hilfreiche Funktion, die man bei einem Wiki von außen nicht erhält. Generell ist die Granulierung der Suche ziemlich oberflächlich.
  • Auch eine Sicherung der Wiki-Quelltexte von außen ist nicht so einfach möglich. Daher rechtzeitig nachfragen, ob der Kunde selbst Backups macht.
  • Die Bearbeitung ist eine Klick-Orgie; für jeden Text den Link im Hauptverzeichnis anklicken, dann „Editieren“ anklicken, am Ende „Speichern“. Und das für jede Sprache.
  • Die Druckausgabe ist tendenziell ein echtes Single Sourcing und erlaubt nicht unbedingt die schöne Ausgabensteuerung, wie sie z.B. Madcap Flare mit „Publishing Targets“ und bedingten Texten (print, online etcpp.) hat.
  • Schön wäre ein Knopf für Printausgabe on-the-fly, da ein PDF fürs Korrekturlesen hilfreich bis notwendig ist.
  • Man ist leicht von den Entwicklern abhängig ist, wenn diese am Wiki etwas ändern. So wurde in meinem Projekt nach einer Migration die Versionierung abgeschaltet, was zum „Blindflug“ bei Korrekturen führte (bzw. zu einem „Backup in Word“).

Mein Fazit: Eigentlich bräuchte man eine gute Schnittstelle zu Word o.ä., und zwar in beide Richtungen – die Tools, die ich vor einigen Monaten geprüft habe, arbeiteten leider immer nur von Word nach Wiki oder benötigten besondere Einstellungen. Einiges wäre leichter gewesen, wenn ich einen direkten Zugriff auf die Wiki-Datenbank gehabt hätte.

Daher würde ich von solchen Dokumentationsprojekten in einem Wiki aktuell eher abraten. Auf jeden Fall aber sollte man das Arbeitsumfeld sehr ausführlich auf die Anforderungen für Dokumentation abklopfen, und ggf. eine extra „Handling“-Gebühr drauflegen – bevor man selbst drauflegt.

Wer weiterlesen möchte – bei Xing gab es neulich ebenfalls eine Diskussion dazu.

Share
© 2012 Doku-Hotline Suffusion theme by Sayontan Sinha