Benutzer:Vlado/Sauberes Markup

Diese Seite wurde für die Wikipedia-DVD Herbst 2005 angelegt. Sie ist abgearbeitet, die Unterseiten können gelöscht werden.

---

Angelehnt an das erfolgreiche Projekt en:Wikipedia:WikiProject_Wiki_Syntax in der englischen Wikipedia soll auch das Markup der deutschen Wikipedia bereinigt werden.

Motivation

Die Fehlerlisten sind Nebenprodukt des Konverters WikiPress Publisher (WPP), mit dem die Wikimarkup-Daten für die Wikipedia-DVD und die WikiPress-Bände nach XML konvertiert werden. WPP bringt seinen eigenen alternativen Parser mit, d.h. der Parser basiert nicht auf der MediaWiki-Software.

In MediaWiki selbst ist jede Eingabe gültig, und mag sie noch so unsinnig sein - es gibt keine Syntaxfehler. Alternative Parser stehen vor dem Problem, den MediaWiki-Parser in möglichst vielen Verästelungen nachbilden zu müssen, d.h. genauso fehlertolerant zu sein und dabei möglichst den gleichen Output zu produzieren.

Die Komplexität alternativer Parser kann erheblich reduziert werden, wenn man davon ausgeht, dass das vorgefundene Wikimarkup in den meisten Fällen vernünftig ist: Geöffnete Elemente werden auch wieder geschlossen, Überschriftenebenen sind regulär, usw.

Neben diesen Fällen werden aber auch Listen von eindeutigen Fehlern erzeugt, wo selbst der MediaWiki-Output nicht erwünscht ist: Linkfehler, fehlende Vorlagen, fehlende Parameter, usw.

Mithelfen

• Wähle aus den Listen weiter unten eine Unterseite aus, die noch nicht durchgestrichen wurde.
• Such dir auf der Unterseite möglichst zufällig einen Block bestehend aus 5 Artikeln aus.
• Behebe nach Möglichkeit die Probleme der 5 Artikel und lösche dann den Block.

• Prüfe stets das Ergebnis nach dem Speichern visuell - es sollen weniger statt mehr Fehler werden!
• Bei Unklarheiten kommentiere das Problem im Block und lass ihn stehen, vielleicht hat ein anderer eine Idee.
• Die Prozentangabe bei jeder Stelle sagt in etwa, wo der Fehler im Quelltext ist.
• Schreibe [[Benutzer:Vlado/Sauberes Markup|Sauberes Markup]] in die Kommentarzeile, was dann in der Historie als Link auf diese Seite erscheint.

• Wenn die Unterseite leer ist, streiche die Unterseite weiter unten durch. Wenn noch einzelne Problemstellen geblieben sind, evtl. mit Kommentaren, streiche die Unterseite durch und füge ein Sternchen * hinten an.

Noch zu tun

• Listengenerator: Die Prozentangabe bei jeder Stelle stimmt nicht immer.
• Listengenerator: Einige Edit-Links funktionieren nicht.
• Tipps und Tricks, Fallbeispiele unten ergänzen, von en:Wikipedia:WikiProject_Wiki_Syntax lernen

Fehlerlisten

Die Fehlerlisten basieren auf dem Dump vom 20. Oktober 2005. Alle Korrekturen, die bis zum 19. Oktober ca. 1. November 2005 vorgenommen werden, kommen auch der Wikipedia-DVD Herbst 2005 zu gute.

Wir befinden uns jetzt im 2. Durchgang, nachdem die Listen vom Dump vom 2. Oktober 2005 größtenteils abgearbeitet wurden.

Inkonsistentes Inhaltsverzeichnis

Der Fehler wird gemeldet, wenn Unterüberschriften sich laut Markup nicht genau eine Ebene unterhalb des übergeordneten befinden.

...== Leben == ==== Jugend ====... wird dann zu ...== Leben == === Jugend ===...

Recht häufig finden sich in den bemängelten Artikel auch Überschriften der ersten Ebene (=Überschrift=). Das wird zwar nicht als Fehler angezeigt, sollte aber, wenn man schon mal dabei, ist ebenfalls korrigiert werden.

00000*

Ungültige Überschrift

MediaWiki ist ziemlich tolerant, doch sollte eine Überschrift so aufgebaut sein, dass sie auf einer Zeile mit gleich vielen Gleichheitszeichen = beginnt endet.

00000 00100 00200 00300

Parameter nicht gefunden

Drei geschweifte Klammern {{{ leiten einen Parameter für eine Vorlage ein. Stellt der Aufrufer der Vorlage den Parameter nicht zur Verfügung, wird dieser Fehler generiert.

00000

Vorlage nicht gefunden

Zwei geschweifte Klammern {{ leiten einen Vorlagenaufruf ein. Wenn die Vorlage nicht gefunden wird, schreibt MediaWiki den Ausdruck hin, als ob es sich nicht um einen Vorlagenaufruf handeln würde.

...{{Geokoordiante|... wird dann zu ...{{Geokoordinate|...

aber: ...zwei Klammern {{ bedeuten ... wird dann zu ...zwei Klammern <nowiki>{{</nowiki> bedeuten...

00000*

Klammern bei Vorlage nicht geschlossen

Der Fehler erscheint, wenn zwei geschweifte Klammern {{ rekursiv bis zum Ende der Seite nicht wieder geschlossen werden.

Unklar, im 2. Durchgang nicht upgedated.

00000

Tabelle im Wikimarkup nicht geschlossen

Eine Tabelle im Wikimarkup ...{|... muss stets mit ...|}... geschlossen werden.

00000*

Ungültiger Tag

Diese Tags haben typischerweise syntaktisch ungültige Parameter, oft in Verbindung mit falschem Verständnis des style=".."-Paramters entstanden.

In anderen Fällen ist eine öffnende spitze Klammer nicht als < kodiert bzw. nicht von <nowiki> umschlossen.

Eine Besonderheit sind Stellen wie tr align="right" bgcolor="#ffffff" |. Intern wandelt der Parser die Piped-Syntax der Tabelle in HTML um und findet dann <tr align="right" bgcolor="#ffffff" |> vor, d.h. die falsch platzierte Pipe "|" am Ende der Zeile wird mit in den Tag übernommen. In diesem Fall muss sie im Quelltext gelöscht werden.

Tipps für ASCII-Pfeile:

• Ersetze --> und ---> durch → sieht so aus: →
• Ersetze <-- durch ← sieht so aus: ←
• Innerhalb von <math> ersetze <-- und --> mit \leftarrow beziehungsweise \rightarrow.
• Ersetze |--> durch: <math>\mapsto</math>; sieht so aus: $\mapsto$
• Ersetze <---> durch <math>\leftrightarrow</math>; sieht so aus: $\leftrightarrow$
• Ersetze <---> durch ↔; sieht so aus: ↔
• Wenn nichts davon zutrifft, ersetze < durch <

Im 2. Durchgang nicht upgedated!

00000 00100 00200 00300* 00400* 00500 00600 00700 00800 00900 01000 01100* 01200* 01300 01400 01500 01600 01700 01800* 01900 02000 02100 02200 02300 02400 02500 02600 02700 02800 02900 03000 03100 03200 03300

Tag zweimal geöffnet

Der Fehler tritt meist auf, wenn der gleiche Tag vorher nicht geschlossen wurde. Dieser muss gefunden und an geeigneter Stelle geschlossen werden.

...<small>0</td><td><small>1</td>... wird dann zu ...<small>0</small></td><td><small>1</small></td>...

Manchmal wollte der Autor den Tag schließen und hat ihn aus Versehen zweimal geöffnet.

...<small>0<small>... wird dann zu ...<small>0</small>...

Im 2. Durchgang nicht upgedated, ist problematisch, siehe auch Diskussion.

00000 00100 00200 00300 00400 00500 00600 00700 00800 00900 01000 01100 01200 01300 01400 01500 01600 01700 01800

Tag geschlossen aber nicht geöffnet

Typischerweise wird <sub> und <sup> verwechselt.

Im 2. Durchgang upgedated, aber problematisch wegen geschachtelter SUPs usw.

00000 00100 00200

Tag nicht geschlossen

An bestimmten Stellen, z.B. vor Überschriften schließt MediaWiki automatisch alle Tags. Sauberer und nachvollziehbarer ist es, wenn diese Tags explizit geschlossen werden.

00000

Unerwünschter Tag

Dieser Punkt ist möglicherweise umstritten. Obwohl HTML-Listenelemente erlaubt sind, sind Wiki-Listen im Wikimarkup viel besser zu lesen und weniger fehleranfällig. Deshalb sollten Konstruktionen mit <ul>, <ol> und <li> vermieden werden. Siehe aber auch die Diskussion dazu.

00000

Kursiv nicht geschlossen

Zwei Anführungszeichen ...''... müssen wieder mit ...''... geschlossen werden. MediaWiki schließt diese an manchen Stellen (zwei Leerzeilen, Listenpunkte, Überschriften, ...) automatisch, so dass der Fehler nicht immer sichtbar ist.

Desweiteren passiert Magie an folgender Stelle: ... auf dem Album ''Rolin''' des australischen DJs ... ergibt gerendert ... auf dem Album Rolin' des australischen DJs ... Das hat der Autor auch so gewollt (ohne groß darüber nachzudenken), für einen Parser sieht die Sache aber so aus: Erst wird kursiv geöffnet, dann kommt ein Wort, dann wird fett geöffnet (!) und am Ende der Zeile wundert er sich, warum beides immer noch offen ist. Die Zeile sieht dann so aus: ... auf dem Album Rolin des australischen DJs ... Damit auch alternative Parser ohne Magie Wikimarkup parsen können, muss er wohlgeformt sein sein. Die Lösung ist, den Apostroph ' am Ende des Wortes als <nowiki>'</nowiki> zu schreiben oder den typografischen Apostroph ’ zu verwenden (ALT+0146).

Im 2. Durchgang nicht upgedated, es sind aber 600 Fehler weniger geworden.

00000 00100 00200 00300 00400 00500 00600* 00700 00800 00900* 01000 01100 01200 01300 01400 01500 01600 01700 01800 01900 02000 02100 02200 02300 02400 02500 02600 02700 02800 02900 03000 03100 03200 03300 03400 03500 03600 03700 03800 03900 04000 04100 04200 04300 04400 04500 04600 04700 04800 04900 05000 05100 05200 05300 05400 05500 05600 05700 05800 05900

Korrupte Bilder

Diese Bilder sind meist in einem anderen Dateiformat abgelegt als die Dateierweiterung es glauben machen will. Sie sollten entweder umbenannt werden oder im richtigen Format wieder gespeichert werden. Bitte die bearbeiteten aus der Liste löschen.

Korrupte Bilder

Falsche ISBN

Auf Anregung von Pjacobi hin wurden 10-stellige ISBNs mit falscher Prüfziffer gesucht. Eventuell hilft ISBN-Check weiter.

00000* 00100* 00200* 00300* 00400* 00500* 00600*

Gallery in Tabelle

00000

Fehlerhafte Personendaten

Hier bitte nur die offensichtlichen Fehler bearbeiten. Ich werde mir die nicht verarbeitbaren Daten anschauen, einiges kann der Parser da noch besser machen.

Ein Großteil der aufgelisteten Daten sind keine Fehler sondern Unzulänglichkeiten des Parses! Bitte ungenaue Angaben wie "um 1970", "1816 oder 1817", "13. April 1720 (getauft)" nicht korrigieren, wenn ihr nicht genau wisset, dass die korrigierte Zahl auch gesichert ist! Ein besserer Parser ist hier-- Nichtich 15:12, 27. Okt 2005 (CEST)

Na, na. Das steht schon oben; ein Großteil ist es sicher nicht; "um 1970" und "1816 oder 1817" wird sehr wohl verarbeitet und taucht nicht in der Liste auf; "13. April 1720 (getauft)" würde ich als "getauft 13. April 1720" (verarbeitbar) schreiben, letzteres ist aber Geschmackssache. Gibt es eine Wartungsliste des anderen Parsers? --Vlado 16:16, 27. Okt 2005 (CEST)

Guter Vorschlag mit dem "getauft". Mein Parser ist halt ziemlich fehlertollerant. Mir geht es nur darum, dass ungenaue Angaben nicht einfach in genaue Angaben umgewandelt werden "17. Mai 1660 oder 1662", "vor dem 12. April 1688", "Anfang August 1750", "21. oder 29. Juli 1797" sind alles eigentlich korrekte Angaben - wenn nicht mehr bekannt ist, kann man da auch nichts korrigieren. Eine richtige Fehlerliste hab' ich nicht, sondern nur sowas. -- Nichtich 18:59, 28. Okt 2005 (CEST)

Ich hab übrigens auch noch einen Parser für Daten (in anderem Zusammenhang entstanden) der auf nur ein/zwei regulären ausdrücken basiert und auch ansonsten ziemlich simpel aber fehlerunanfällig ist. Bei Gelegenheit würd ich auch mal sehen, ob ich Fehlerlisten generieren kann... allgemein ist "getauft 13. April 1720" aber wirklich besser als "13. April 1720 (getauft)". Ich bin aber auch eher ein Fan von einzelnen ungenaueren Angaben, also statt "21. oder 29. Juli 1797" einfach "um 25. Juli 1797" oder statt "17. Mai 1660 oder 1662" einfach "um 1661" ... da gehen zwar Infos verloren, aber "17. Mai 1660 oder 1662" lässt sich einfach nicht vernünftig parsen (natürlich kann man die zwei angaben ermitteln, aber wie der zusammenhang ist ist vollkommen unklar). --APPER\^☺☹ 18:29, 1. Nov 2005 (CET)

00000 00100 00200 00300 00400 00500 00600 00700 00800 00900 01000

Siehe auch Wikipedia:Personendaten/Wartung

Ich mache mit!

Ich weiß, dass Spaß etwas anderes ist, aber ich mache mit: Vlado, Mathias Schindler, jed, dbenzhuser, Michael, Qbi , Jensw, Avatar, Gnu1742, rdb?, Robot Monk, HaSee, Baikonur, Carl Steinbeißer, darina (wenn sie Zeit hat...), jpp, Trainspotter, Horgner, ChristianErtl, Ilion, Kam Solusar, janKG, Timo Müller Diskussion, WiseWoman, Ditschi, gNosis @, Kolja21,FlaBot, HD-α @

Siehe auch

• phab:T7478 (Bugzilla:5478): "Request for Special:WrongSyntax"