Über den MediaWiki VisualEditor und simultanes Schreiben

Ein kurzer Rückblick

BlueSpice 2 wurde mit einem TinyMCE-Editor ausgeliefert, wahrscheinlich der am meisten verbaute HTML-Editor im Web. WordPress und viele andere Open-Source-Projekte verwenden diesen Editor.

Doch bei MediaWiki steht man mit jedem Editor, auch mit TinyMCE, vor einer besonderen Herausforderung. Editoren wie Tiny bieten zwar eine word-ähnliche Oberfläche (“Rich Text”) und wandeln die Eingabe in HTML. Für MediaWiki muss die Eingabe aber auch in Wiki-Code gewandelt werden. Und das bietet kein verfügbarer Editor. Die Herausforderung einen HTML-Editor auf MediaWiki anzupassen besteht darin, dass diese Umwandlung nicht eindeutig ist. Es gibt mehrere mögliche Varianten, um dasselbe zu erreichen. Und umgekehrt ist WikiText sehr fehlertolerant. Das heißt, es entspricht nicht zwingend den gängigen formalen Anforderungen für eine Konvertierung.

Trotzdem haben wir in den letzten Jahren immer weiter an einem Wiki-Code-Parser geschrieben, der diese Übersetzungsleistung erbringt. Mit der Auslieferung des MediaWiki VisualEditors entfällt diese sehr zeitraubende Arbeit und wir können uns endlich neuen Themen zuwenden.

Mit BlueSpice 3 kam der neue Visual Editor

Mit der Veröffentlichung von BlueSpice 3 haben wir den neuen MediaWiki VisualEditor an unsere Kunden ausgeliefert.

• Der Editor ist nativ für MediaWiki entwickelt, basiert technologisch auf komplett anderen Verfahren als TinyMCE und ist direkt zugeschnitten und optimiert für den Einsatz mit MediaWikiText.
• Dieser VisualEditor ist stabil und wird gegen die gesamte Wikipedia getestet. Die Entwickler haben einmal alle Artikel durch den Editor laufen lassen, um Fehler zu finden.
• Es gibt viele Features, die wir uns schon lange gewünscht haben. So kann man zum Beispiel sehr bequem Vorlagen bearbeiten. Im Unterschied zur aktuellen Version in BlueSpice werden Vorlagen nicht nur als ein unbearbeitbarer Tag angezeigt, sondern man sieht die Vorlage im Bearbeitungsmodus so, wie sie auch publiziert aussieht. Und es wird noch besser: Man kann direkt aus dem Editor heraus die Inhalte in der jeweiligen Vorlage verändern. Man muss also nicht mehr in den Wiki-Code-Editor gehen. Das ist sehr komfortabel und wird die Nutzung von Vorlagen im Wiki grundlegend verändern und unterstützen. Denn bislang waren Vorlagen eine Funktion für Autoren mit vertieftem Wissen, da die Nutzung nicht unterstützt wurde und man Wikitext verstehen musste, um sie einsetzen zu können.

Leider ist die Tabellenbearbeitung noch nicht auf dem Stand, den wir uns vorstellen. Und es gibt einige Funktionen in BlueSpice, die wir gern ergänzen möchten. Aber für die BlueSpice-Anwender und für unsere Kunden ist das nun eine ideale Lösung.

VisualEditor ebnet den Weg zum Real-time-editing

Der VisualEditor bietet technologisch auch viele Möglichkeiten für die Zukunft. Zum Beispiel simultanes Schreiben, wie man das von Google Docs her kennt: Mehrere Autoren können gleichzeitig den Inhalt bearbeiten. Wir hatten schon vor drei Jahren auf diese Entwicklung aufmerksam gemacht.

Technisch ist das Problem im Prinzip gelöst. Die Grundlagen haben sich die Entwickler von Etherpad und Google Docs abgeschaut. Man muss das HTML vom Text trennen. Wieder zurück zu TinyMCE: Dieser Editor schreibt im Hintergrund HTML. Das heißt, der Autor schreibt einen Text, und der Editor setzt im Hintergrund Sonderzeichen: die HTML-Tags. Diese Tags sieht man aber nicht. Man weiß nicht, ist der Cursor gerade innerhalb des Tags oder außerhalb, beispielsweise, wenn ein Wort fett geschrieben wird.

Und diese Notwendigkeit der Auszeichnung bringt Probleme mit sich. Man nehme einmal an, man möchte einen Textteil kommentieren (“annotieren”). Mit HTML ist das furchtbar kompliziert, weil die Tags symmetrisch verschachtelt sein müssen. Da kann schnell sehr viel kaputtgehen.

Der MediaWiki VisualEditor trennt nun alles in zwei Bereiche auf:

• in eine reine Textebene. Hier wird nur der darzustellende Text bearbeitet, zusammen mit einer Positionsangabe.
• und in eine zweite Ebene, die Markierungen notiert, z.B. kursiver Schriftzug von Position 2 bis 7.

Der Clou: Erst am Ende aller Berechnungen wird eine HTML-Seite zusammengebaut. Da nun alles unabhängig von HTML läuft, kann man nun mit einer eigenen Logik – unabhängig von HTML – dafür sorgen, dass die Auszeichnungen fehlerfrei an der richtigen Stelle gesetzt werden. Das eröffnet viele schicke Möglichkeiten: Kommentare, farbige Markierungen u.a.m.

Das ist eine sehr vereinfachte und verkürzte Darstellung. Aber das ist die neue Technologie, die man verwendet, wenn ein neuer Editor entwickelt wird. Der von uns bislang verwendete TinyMCE ist so gesehen technologisch veraltet. Der MediaWiki VisualEditor hat im Prinzip alles, was man heute braucht.

Probleme der Wikimedia-Community

Dass simultanes Schreiben (Real-time-editing) in der Wikipedia und für MediaWiki noch nicht verfügbar ist, hat mit spezifischen Problemen der Wikipedia-Communities zu tun.

Es gilt in der Wikipedia bislang das Prinzip “eine Veränderung, ein Autor”. Das ist unter anderem wichtig, weil die Währung in der Wikipedia die Bearbeitungen (Edits) sind. Beim Real-time-editing durch mehrere Bearbeiter gleichzeitig stellt sich die Frage, wer die Credits bekommt. Beide? Der letzte? Und was passiert mit Zwischenversionen? Was mit den Versionierungen und bei einem Rollback?

Bei Google Docs oder Etherpad wird auch jede Änderung versioniert. Hier kann jeder Tastendruck rückgängig gemacht werden. Es ist die Frage, inwieweit sich dieses Verhalten – nicht nur ein Beitrag, sondern schon jeder Tastendruck ist ein Edit – in die Philosophie der Wikipedia passt. Das ist alles unklar.

Und noch ein ganz anderes Problem ist Spam: In der Wikipedia kann man ja anonym posten. Wie verhindert man, dass die Wikipedia von Spambots zugeschrieben wird? Das sind alles Fragen, bei denen die Entwickler sagen, das ist nicht geklärt und wir werden es nicht umsetzen, solange man uns nicht sagt, wie man es machen soll. Und zu befürchten ist, dass das eine Zeit dauert.

Dabei wäre es schon allein visuell spannend, wenn man auf eine Seite geht und man merkt, dass da gerade auch an anderen Ecken Leute schreiben. Dann hätte man eine automatische Lösung bei Editierkonflikten, die heute sehr umständlich aufgelöst werden.

Wenn man ein wenig hemdsärmeliger herangehen würde, gäbe es schon gute Lösungen. Wieder ist offen, ob hier nicht die Welt außerhalb der Wikipedia die ersten Schritte gehen muss, weil das simultane Arbeiten ja in erster Linie für Protokolle, Brainstorming oder Textentwürfe interessant ist. Es ist durchaus ein Witz, dass die Wikipedianer selbst Etherpad und Google Docs für ihre Arbeit verwenden. Vielleicht ändert sich das, wenn das Thema Entwürfe angegangen wird.

In jedem Fall eröffnet sich noch ein spannendes und wichtiges Gebiet für die Wikitechnologie.