HowToImWiki

Q: Wie könnten HowTos in ein Wiki integriert werden, so dass die Änderungen zu den Maintainern zurückfließen ?

A: Tja, am allerbesten und im Sinne von Wiki "natürlichsten" wäre es wohl, Dokus und Howtos NUR im Wiki zu lagern, zu lesen und zu bearbeiten. Dann gäbe es auch nicht den Maintainer, sondern möglicherweise viele Maintainer und die Howtos wären vielleicht in einem besseren Zustand als heutzutage leider öfters der Fall.

Die Integration könnte auf die wiki-übliche Art erfolgen: zu einem Thema gibt es eine Seite. Wenn die zu lang wird und sich gut in Unterthemen aufspalten lässt, gibt es entsprechende Unterseiten. Sind es eher "nebenläufige" Themen, gibt es weitere (Haupt-)Seiten zu diesen Themen.

Man sollte sich dann allerdings von der Vorstellung eines HowTos als in sich geschlossenes, genau abgegrenztes Werk trennen und als Maintainer / Wiki-Autor seine Beiträge eher als Teilbeiträge zu einer großen Wissensdatenbank betrachten.

Siehe auch WiesoWikiFunktioniert und WiesoWikiBesserFunktioniert...

Q: Es wäre schön, wenn dieses Wiki sich zu einem Meta-HowTo entwickeln könnte.

A: Genau so ist das angedacht (daher auch die Seite LinuxKnowledgeBase). Da muss sich natürlich noch viel entwickeln, aber ich denke mit vielen fleißigen Wikizens ist das machbar.

A: Die Suchfunktion ist auch schon da und ich weiß wie ich meine kleinen Erfahrungen hier einbringen kann.

Q: D.h. die Fragen könnten hier in einer Art Netzstruktur gesammelt sein, die Antworten wären Links zu den entsprechenden Docs, HowTos etc. (am besten wäre, wenn diese auch noch in einem Wiki verwaltet würden).

A: Du sprichst mir aus dem Herzen. Allerdings muss hierzu natürlich noch einiges an Publikumsarbeit getan werden, denn das mit den Wikis hat sich noch nicht so arg rumgesprochen und viele Leute haben auch Vorbehalte.

A: Das Problem, das ich daran momentan noch sehe ist, dass das Wikiformat nicht so richtig portabel ist. Wenn jemand sich schon die Mühe (ge)macht (hat) ein Howto zu schreiben, will er das wenigstens in "vernünftigen" Formaten exportieren können. Das Deutsche Linux Howto Projekt (http://www.linuxhaven.de/dlhp/) bietet seine Howtos z.B. online und als ASCII, SGML, HTML, DVI, Postscript, Adobe PDF an. Außerdem kann man auch alle am Stück herunterladen. Aber vielleicht lohnt es sich mit den Leuten einfach mal zu reden. Weniger um deren Seite ins Wiki zu übernehmen, sondern mehr um die Einwände zu hören.

Zu unten: Ja, das ist schon alles klar, sehe ich ja auch so. Howtos und ManPages sind aber nicht nur zur Onlinenutzung gedacht. Das TLDP setzt z.B. auf SGML DocBook - nicht ganz zu unrecht. Solange diese Funktionalität von einem Wiki nicht zur Verfügung gestellt werden kann/will, glaube ich nicht das man die Autoren von ManPages und HowTos von dem Wiki-Konzept überzeugen kann (was ja inhaltlich auch erst mal noch hinzukriegen ist). Ich will hier nicht das Konzept der Wikis schlecht machen (im Gegenteil ich bin davon begeistert), es geht mir nur darum, warum sehr viele Leute ein Wiki nicht als akzeptable Plattform ansehen werden. Das schreiben von Howto ist heute eben wegen dieser Portabilität und Mächtigkeit so kompliziert. Wenn man hier aber eine Alternative zu den etablierten Institutionen und Verfahren aufsetzen will muss man mindestens den gleichen Funktionsumfang bieten, sonst wird man die "Doku-Experten" nicht dazu bringen das entspechende System zu nutzen.

• Wieso ist das nicht portabel? Also bei meinem Browser kommt diese Seite hier in HTML an. Portabler gehts doch wohl nicht. Wenn man oben rechts auf den kleinen Drucker klickt, ist der Firlefanz drumherum auch weg. Und HTML dann in ASCII, PDF oder wasauchimmer zu konvertieren, ist auch kein Hexenwerk. -- ThomasBayen

• normale Wiki-Seiten sind primär für Online-Benutzung gedacht (und machen offline nur begrenzt Sinn), das ist ein Unterschied zu einer Doku- oder Howto-Sammlung, die auf statischen, druckorientierten Files basiert.
• trotzdem könnte man natürlich eine Howto-Datei 1:1 auf eine Wiki-Seite bringen und hätte damit die Vorteile von Wiki zur Verfügung
• nur so am Rande: die Wiki-Seiten sind als reine ASCII-Daten gespeichert (nämlich genau das, was man im Editor eintippt)
  • dieses Format kann man sich auch mit action=raw auf den Schirm holen (oder auch speichern), wenn man das Bedürfnis dazu hat
• man kann sich mit action=print auch HTML ohne Kopf- und Fußbereich auf den Schirm holen (oder auch speichern)
• an einem Komplettbackup via XML wird gerade gearbeitet
• Drucken:
  • DVI/Postscript: das sind Druckformate
  • Drucken macht nur bei papierorientierten linearen Texten Sinn
  • Wiki ist Hypertext und Papier ist von der Bedienung her bekanntermaßen nicht Hypertext-kompatibel.
  • Drucken ist des öfteren IMHO reine Papierverschwendung, weil man mit dem entstehenden Material bei weitem nicht so gut arbeiten kann, wie mit dem Wiki:
    • keine Suchfunktion
    • kein Hypertext
    • keine dynamische Interaktion
    • keine Kollaboration
    • keine Aktualität (siehe das dt. PCMCIA-Howto von 1997)
• das Hauptproblem, was die Howtos haben, ist nicht das Dokumentenformat sondern:
  • die Aktualität und die Korrektheit:
    • wieviele Fehler bleiben unkorrigiert, weil es einfach umständlich ist, sie ausbauen zu lassen?
    • wieviele Howtos veralten aus dem selben Grund?
  • kaum Zusammenarbeit, die ganze Arbeit bleibt oft an einem Maintainer hängen
  • man muss sich viel mit Dokumentenformaten, Formatierung, Hoch- und Runterladen rumschlagen, anstatt sich auf den Inhalt zu konzentrieren
  • keine Querbezüge zwischen den Howtos

• Siehe auch WiesoWikiBesserFunktioniert.

• Wenn Du Dir mal das DE-Autor-HOWTO anschaust, dann siehst Du auch, warum es weniger Howtos gibt als denkbar / notwendig - unter diesen Randbedingungen wirst Du nämlich nur Howtos von Doku-Experten bekommen und deren Zahl ist recht begrenzt. Ebenso ist das Erstellen von SGML-Diffs sicher für dort sinnvoll, aber eben doch etwas komplizierter als im Wiki auf Editieren und Speichern zu klicken.

-- ThomasWaldmann 2002-07-31 12:08:54

A: Also die Howtos einmal in das Wiki zu übernehmen, sollte kein Problem darstellen - Docbook ist ja XML und man kann das deshalb recht einfach per XSLT in das Wiki-Format konvertieren! Dann würde es aber 2 Branches geben - einen der originalen HowTos und einen der WikiHowtos! -- JanRoehrich

Nachdem jahrelang SGML nicht richtig Fuß gefaßt hat und sich jetzt endlich die LDP-Autoren zu Docbook durchringen konnten, findet ihr also einen neuen Stein der Weisen. Klingt nicht sehr produktiv. SGML ist schon der richtige Weg. Schließlich geht es nicht darum, dass SGML in wer weiß wie viele Formate konvertiert werden kann, sondern dass man ein extrem reichhaltiges Markup hat, das automatisch verarbeitbar ist. Schreibe doch mal einer der Wiki-Advokaten ein Programm, dass automatisch versteht, um welches Anwendungsprogramm sich eine Seite dreht. Geht nicht? Eben, geht aber in Docbook, weil der Anwendungsname als <application> getagged ist. Wenn ihr Doku im Wikiformat schreibt, gehen diese semantischen Informationen alle verloren.

• das ist ein Argument. Aber was mache ich in SGML, wenn es nicht ein Programm, sondern ein Verfahren, ein Konzept, eine Idee, ein Datenformat, eine Abkürzung, ein Fachausdruck oder oder oder ist? Eine der Stärken von Wiki ist ja das freie Format. Und was man mit dieser automatischen SGML-Verarbeitbarkeit auf dieser semantischen Ebene sinnvoll getan wird, hab ich auch noch nicht gesehen.

  • Dranschreiben, gerade Docbook hat unwahrscheinlich viele Tags für die Dinge, die in technischer Dokumentation vorkommen. In den genannten Beispielen sind das etwa <procedure>, <acronym>, <term>, solche Sachen wie <term role="conception"> kommen auch in Frage. Siehe "DocBook: The Definitive Guide" für ein Beispiel extrem reichhaltigen Markups. Solche Informationen bringst du im Wiki-Format niemals unter: Das Markup bietet praktisch nichts außer Überschriften und Hervorhebungen. Alles weitere erledigst du über Konventionen, etwa Kategorien. Das ist aber weder einfach noch mächtig. Was machst du denn in einem Wiki, wenn du über ein Verfahren, ein Konzept oder ein Datenformat schreibst?

  • Was die automatische Verarbeitung betrifft, da gibt es bei SGML wenigstens Möglichkeiten, weil die semantischen Informationen überhaupt da sind. Im Wiki fehlen sie und können auch kaum später dazuerfunden werden. Das ist auch der tiefere Grund, warum es keine Konverter von HTML nach SGML oder von Texinfo nach SGML gibt: sie können alle keine Information dazu erfinden.

Ich sähe Verwendung für ein Wiki, dessen Inhalt als SGML-Dokument abgelegt ist, das eine formatierte Ansicht darauf bietet und das es ermöglicht, einzelne Elemente davon zu bearbeiten. Dass das dann SGML-Code ist und nicht Wiki-Markup sollte ja wohl nicht das Problem sein, es ist schließlich auch bloß ASCII-Text.

• Ohne dass ich mich damit näher auskenne: Die Idee von SGML ist, dass ich mir für jeden Zweck (z.B. Beschreiben von Linux Programmen - deshalb auch LinuxDoc SGML - die passenden tags definieren kann.

  • Korrekt im Prinzip. Eine gute DTD zu entwickeln ist trotzdem harte Arbeit. Darum bietet es sich an, eine fertige zu nehmen und ggf. anzupassen. LinuxDoc war ziemlich armseelig: Kapitel, Hervorhebungen, Links, nur eine handvoll logischer Tags. Deswegen wurde LinuxDoc auch durch DocBook abgelöst.

Implementierung linuxdoc

Es gibt inzwischen eine funktionierenden linuxdoc Parser für MoinMoin, der sgml2html aufruft. Er kann hier abgeschaut und getestet werden (inzwischen auch im Source). Dabei habe ich das folgende gelernt:

• MoinMoin ist sehr leicht zu erweitern.

• Für viele Funktionen müssen nicht einmal die Programmdateien geändert werden (Plugin-technik)
• Es ist keine Frage ob man etwas implementieren kann, es ist die Frage ob man es will und ob man weiss was genau.

Updates:

• bessere Fehlermeldungen
• Habe den linuxdoc spezifischen Teil vom Rest (Caching,...) getrennt. Weitere externe Parser sind jetzt schnell eingebaut.

Ich hab's mir grad angeschaut und folgendes ist so mal der erste Eindruck:

• die Integration ist Dir gut gelungen (soweit man das von außen sehen kann)
• Markup-Fehler (Tippfehler) sind ein Problem, die Fehlermeldungen sind zwar gut, aber man kann den Fehler schlecht lokalisieren
  • Wiki-Markup ist da besser, da gibt es keine Markup-Fehler - es sieht dann halt einfach nicht so aus, wie gewollt
  • für docbook muss man sich da noch was einfallen lassen, damit Fehler leichter lokalisierbar sind
    • hiermit geschehen

• ich mache mir gerade Gedanken über LinuxWiki/MehrSprachigkeit (de, en, ...) - ebenso könnte man ggf. auf Sourcecode-Ebene Mehrsprachigkeit implementieren (wiki, docbook, ...)

  • DocBook kann man ja wohl automatisch nach Wiki-Markup konvertieren (haben wir da schon einen Konverter?)

  • man müsste daher (ähnliche wie bei de/en-übersetzten Seiten) nur eine Koppelung zwischen den Seiten herstellen können
  • dann könnte man ein Howto im docbook-Format haben und auch im automatisch generierten Wiki-Format
  • der "Normalanwender" kann dann Korrekturen im einfacheren Wiki-Format machen
    • das System merkt dann allerdings, dass Wiki und Docbook nicht mehr übereinstimmt und zeigt das an, so dass jemand, der sich mit docbook auskennt, das dann korrigieren kann
    • genau das gleiche Verfahren braucht man auch für de/en-übersetzte Seiten, so dass man Änderungen an einer Version (manuell) übersetzen und in die anderen nachtragen kann
    • md5-Signaturen o.ä.?
  • der Anwender kann sich seine Sprache (en,de,...) und sein Editformat (wiki=default, docbook,...) aussuchen
  • das synchronisieren mehrerer Sprachen und Formate dürfte recht kompliziert werden

• DocBook mag zwar mächtiger sein, aber auch unübersichtlicher, da bleib ich dabei

• -- ThomasWaldmann 2002-09-17 13:17:43

• Eine Alternative wäre vielleicht ReStructuredText als Format zu wählen. Das ist ziemlich wiki-Like und kann wohl ein großes Subset von Docbook abbilden. Damit würde man einen Standard benutzen, der in viele andere Formate konvertierbar ist (oder sein wird). Eine Rudimentäre Unterstützung von ReStructuredText ist in MoinMoin bereits eingebaut. -- ThomasKalka 2002-09-12 16:18:59

Nichts gegen ReStructuredText, aber was für einen Sinn soll das haben? Wiki ist Wiki und definiert sich u.a. such durch den möglichst simplen Wiki-Markup. reStructuredText ist doch eigentlich nur ein Alternativformat dazu. Wie soll das dann in der Praxis aussehen? Zwei verschiedene Markup-Sprachen in einem Wiki? -- BennySiegert 2002-09-15 19:51:29

• Was bitte ist so toll an dem Wiki-Markup? Das Markup ist primitiv und stellenweise richtig unpraktisch, zum Beispiel kann ich diese Zeile nicht umbrechen und einrücken, weil sie dann auch eingerückt erscheint. Und dann kommt zu dem Markup von WardsWiki auch noch in jedem Wiki ein neuer Satz Erweiterungen. Ich meine sogar, MoinMoin hat das schon zu weit getrieben, mit Tabellen, Makros, eigener Linksyntax... und das alles, obwohl es in HTML genauso existiert. Ist denn <b> so viel schwieriger als drei Apostrophen? Ist <p> soviel schwieriger als ein Absatz? Ist <a> oder <link> so viel schwieriger als ein potthäßlicher WikiName? Und kann nicht mal jemand diese gelangweilten Studenten davon abhalten, neue Markup-Sprachen zu erfinden? Imho definiert sich WikiWiki als Integration aus Präsentation und Editor, als kollaboratives System, und ganz bestimmt nicht durch die konkret verwendete Syntax.

MoinMoin ist doch gerade stark darin, verschiedene Formate zu unterstützen. Es unterstützt so viele Formate, wie Parser installiert sind. Das Wikiformat ist für komplexe Informationen zu einfach. Außer Listen, Überschriften,Hervorhebungen und Links gibt es keine Strukturelemente. Um Dokumente wie Howtos oder Manpages zu verwalten, braucht es IMHO aber ein reicheres Format. -- 217.224.208.35 2002-09-16 10:29:22

Was fehlt denn deiner Meinung nach noch? Neben den von dir genannten Dingen gehen auch noch Tabellen und Codeschnipsel / präformatierter Text sowie die Einbindung von Grafiken und Dateianhängen. Wenn du ein #pragma section-numbers on an den Seitenanfang setzt, werden die Überschriften automatisch nummeriert, und auch ein Inhaltsverzeichnis kann dir ein Makro erstellen. Das Einzige, was mir noch einfiele, wäre das Setzen von "Ankern" für Verweise innerhalb der Seite (Frage: Geht das mit normalem Markup?). -- BennySiegert 2002-09-16 11:37:22

• Anker gibts, [[Anchor(anker)]] und [#anker]

• über InterWiki-Link Self:LinuxKnowledgeBase/DiskussionenWünsche#anker auch auf andere Seiten

Siehste mal, dann ist ja alles da . -- BennySiegert 2002-09-17 12:57:00

Ja, alles was man zum Formatieren braucht. Naja, vielleicht, XSL-FO bietet mehr. Übungsaufgabe: Wikimarkup zurück nach DocBook konvertieren, damit der Maintainer des HOWTOs auch was davon hat. Das ist eine gute Idee, sobald DocBook->Wiki->DocBook verlustfrei ist.

Mir ging es nicht um die Optik, sondern um die Semantik. Die Argumentation dazu ist aber oben unter der Diskussion zu SGML schon zu finden. Mein Argument sollte in die Richtung laufen, daß ReStructuredText semantisch nah an DocBook liegt, aber von der Optik (des Markups) ziemlich wiki-ähnlich ist. -- ThomasKalka 2002-09-26 23:42:29