On 31.03.2011 18:14, poupou wrote:
einen editor zu bauen, der keinen spaghetti-code
produziert, sollte doch aber
eine herausforderung sein, die jeder programmierer gerne nachvollzieht. oder
ist das eine geheime rache der programmierer an den nutzern, die auf wysiwyg
stehen?
es ist leider schlicht unmöglich, einen wysiwyg-Editor zu bauen, der auch in
komplizierten fällen nichts kaputt macht(*). Es ist ebenso unmöglich,
automatisch zu erkennen, in welchen Fällen das passieren würde.
Man kann Editoren bauen, die "meistens" das richtige tun. Der von Wikia ist
wohl
der beste, den es gibt. Aber auch der macht manchmal was kaputt, und kann nicht
alles. Es bleibt immer Flickwerk.
Die einzige *wirkliche* Lösung wäre, die Wiki-Syntax so weit zu verbessern, dass
man sie ordentlich formal beschreiben und parsen kann. Dann kann man auch einen
vernünftigen Editor dazu bauen (und auch vernünftige Exporter für PDF, TeX,
etc). Aber es werden einige Seiten und vor allem auch Vorlagen dabei kaputt
gehen, die müssen dann von Hand repariert werden.
Letztlich ist das der einzige weg, und ich weiß, dass bei der Foundation
mittlerweile zumindest ernsthaft darüber nachgedacht wird. Das ist Teil des
"wiki.next" Programms, für das die Foundation gerade Brion Vibber wieder
eingestellt hat. Auch Trevor Parscal, einer der Chefentwickler, sagte mir, dass
ihm das Thema unter den Nägeln brennt.
Nicht umsonst ist "fix the parser" eines der Hauptthemen beim Hackathon, den
wir
im Mai in Berlin veranstalten. Ich bin schon sehr gespannt, was dabei heraus kommt.
Kurz: das Problem treibt uns schon seit 2004 um, aber die Aussicht,
möglicherweise Millionen von Seiten von Hand reparieren zu müssen, hat immer
abgeschreckt. Aber es wird nur schlimmer, je länger wir warten. Und Wikimedia
hat mittlerweile genügend Geld, das Problem mit etwas Wums anzugehen. Es scheint
mir, als wäre jetzt der richtige Zeitpunkt, das endlich zu erledigen.
-- daniel
(*) Erstens folgt die Syntax keine kontextfreien Grammatik, damit scheiden die
meisten formalen Beschreibungsmittel (EBNF, etc) und Parsergeneratoren aus. Es
ist soweit ich weiß nicht einmal sicher, ob die Sprache überhaupt entscheidbar
ist (D.h. ob der MediaWiki-Parser in allen Fällen terminiert). Zweitens ist es
notwenid, *vor* dem Parsen alle Templates, Parser-Functions, etc auszuwerten.
Das geht im Browser nicht, das kann nur der Server.