Hilfe Diskussion:Wikisyntax/Validierung

Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit 7 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind. Das aktuelle Archiv befindet sich unter Archiv.

Statistik

26. Mai 2022
NamensraumHTML5
misnested
Tidy font
link bug
Misnested
tags
Wikilink
in extlink
Missing
end tag
Obsolete
HTML
Stripped
tags
AndereGesamtzahl
Artikel00.leer  
Diskussion2.875 ↑26.775 ↑1 ↑29.651  
Benutzer42.413220.82511.8232.485837.560  
Benutzer Disk5151.772 ↑13.93922.9011.649540.286  
WPNR4.57513.75826.9011.70346.937  
andere NR1223200.037  
Gesamt (alle)91511.635375.29961.6275.87013154.471  
  • hohe Priorität – nur noch verweigerte Reparaturen
  • mittlere Priorität
  • niedrige Priorität – noch etliche tausend Fehler auch im ANR
  • _ Gemischt – vereinzelte Fehler in den Kategorien
    Noch 1.492 FfOoNnTt-Tags (Stand 26. Mai 2022). -- Lómelinde Diskussion 15:07, 26. Mai 2022 (CEST)Beantworten
    Aktuelle Zahlen: https://fireflytools.toolforge.org/linter/dewiki

    Ersatztabelle

    Fehler auslösende Signaturen, Tag- oder Fontfehler
    derzeit leer

    Bot-fixing: Missing end tag

    Nach einigem Tüfteln über Cirrus-Syntax und Server-Timelimit erlaube ich mir, einige Fälle als Listengenerator zu unterbreiten, für die sich eine Bot-mäßige Reparatur auf eigene Verantwortung anböte. Schlimmer kann es kaum werden.

    Letzteres trifft auch Fälle, wo zwischen URL und '' das Leerzeichen fehlt; diese könnten im Interesse der Syntaxhygiene erstmal bereinigt werden, auch wenn MW sie als funktionierend akzeptiert:

    Mag dann hinterher alles nochmal mit https als Vorab-Filter nachgeschärft werden.

    Weitere häufige Konstrukte können sinngemäß ausgetüftelt werden.

    Viel Spaß --PerfektesChaos 16:42, 8. Feb. 2022 (CET)Beantworten

    Falsch verschachtelte Tags

    Mal eine Frage an die Profi-Quelltextanalysatoren (wie Doc Taxon oder Wurgl): Schafft ihr es, Quelltexte so zu untersuchen, dass inline-Tags wie small, kursiv, fett usw., die über Zeilenumbrüche gespannt sind (), sicher zu finden? Falls ja, dann sollte es doch auch möglich sein, dass öffnende Tag durch ein passendes <div style=...> und das schließende durch ein </div> (zumindest in NS 1 und 4) zu ersetzen. Oder ist das zu naiv gedacht?--Mabschaaf 16:29, 24. Apr. 2022 (CEST)Beantworten

    Definiere "usw." :-)
    Grundsätzlich sind die schon auffindbar. Problematisch wird es nur, wenn dieses "mehrzeilig" über mehrere Zeilen einer Wikiliste, über Absätze, über Tabellen-Elemente etc. hinausgeht.
    In deinem Beispiel ist jede Zeile ein <dd>-Element und so wie ich den generierten HTML-Code sehe, ändert sich nix an der Fehlerhaftigkeit. Jetzt ist halt das <div>-Element über zwei Listeneinträge mit <dd> gespannt.
    Dein Beispiel benötigt auf jeden Fall zwei <small> oder <div>. --Wurgl (Diskussion) 16:46, 24. Apr. 2022 (CEST)Beantworten
    Es sind ja nicht nur Zeilenumbrüche.
    Zeilenumbrüche (ohne Leerzeile) können innerhalb eines Fließtextes beliebig oft eingestreut werden, und es bleibt ein Fließtext. Würde dieser ein div bekommen, dann würde nur daraus ein eigener Block und der Fließtext wäre zerstört.
    Das fragliche Beispiel lautet:
    ::::<small>Hier wird die Relevanz weder „mit Verkaufs“- noch „mit Werbekäse“ begründet.
    ::::Wer Musiker über Verkaufszahlen … bisher nicht durchgesetzt.</small>--[[Benutzer:Engelbaet|
    
    Auch hier wäre kein div möglich. Handarbeit.
    Unbeschadet dessen: Linter sieht beeindruckend aufgeräumt aus.
    VG --PerfektesChaos 16:39, 24. Apr. 2022 (CEST)Beantworten
    Zu "usw.": Ich wollte mir noch nicht die Mühe einer vollständigen Liste machen, wenn es aus anderen Gründen sowieso nicht funktioniert. Kann man zu gegebener Zeit noch ergänzen.
    Ansonsten: Ja, vielleicht ist das div keine gute Idee. Aber wenn prinzipiell und sicher auffindbar, dann sollte es doch auch möglich sein, die fehlenden Tags zu ergänzen, also im Beispiel von PC ein </small> in der ersten Zeile und ein <small> in der zweiten.
    Es ist halt manuell unendlich öde und superlästig zudem, wenn ein solches Tag über drei, vier, fünf Einrückungen gespannt wurde .
    @Wurgl: Natürlich sollen keine komplexeren Fälle automatisiert angefasst werden.--Mabschaaf 17:10, 24. Apr. 2022 (CEST)Beantworten
    Nee, das automatisierte Anfassen komplexer Fälle ist nicht das Problem. Das Problem ist schon das Erkennen solcher Fälle. Innerhalb so eines <small> könnte ja ein <ref> stehen und der Zeilenumbruch in der Referenz ist wohl zu ignorieren. Oder in diesem Absatz, das Code-Schnipsel hat PC hier in einen <pre-Block verpackt usw. Das ist das Komplizierte daran. Wenn der Kontext, in dem das Tag gefunden wurde, erstmal identifiziert ist, ist eine Ersetzung nicht mehr so wild. --Wurgl (Diskussion) 17:22, 24. Apr. 2022 (CEST)Beantworten
    Hm. Alles klar. Schade. Wäre auch zu schön gewesen...--Mabschaaf 20:21, 24. Apr. 2022 (CEST)Beantworten
    Ich denke eher, es ist eine Frage, wie intelligent man den Algorithmus dafür schreibt. Ein für diese Zwecke ausreichender "Detektor" frisst einiges an Entwicklungszeit. Man könnte auch pro Inline-Tag eingebaute Zeilenumbrüche auslesen, aber auf diese Art kann das wohl kaum erwünscht sein. Mal ne Frage: wenn wir so einen Detektor hätten, der das auch noch zuverlässig umbaut, wie lange würde man den noch verwenden müssen, wenn erst einmal alles korrigiert wurde? Ich glaube, PerfektesChaos hat mal irgendwo geschrieben, dass in Zukunft Editoren das während des Bearbeitens oder Speicherns selber machen können. – Doc Taxon Disk. 00:10, 25. Apr. 2022 (CEST)Beantworten
    Kann man irgendwie diesen Parameter lintid=455285 per Programm auswerten? Das würde das Entdecken deutlich erleichtern. --Wurgl (Diskussion) 00:35, 25. Apr. 2022 (CEST)Beantworten
    Frage ist beantwortet: https://de.wikipedia.org/wiki/Spezial:ApiSandbox#action=query&format=json&list=linterrors&formatversion=2&lntcategories=misnested-tag&lntlimit=2 "location" ist ja da. Hmm. Ich denk mal nach. --Wurgl (Diskussion) 00:53, 25. Apr. 2022 (CEST)Beantworten

    Je nachdem wie viele solcher Einrückungen vorkommen und, ob es sich um einfache Einrückungen oder Aufzählungen handelt ergibt sich aber die Problematik, dass die Zählung dann nicht mehr funktioniert. Daher muss in den Fällen dann jede Zeile ein öffnendes und ein schließende Tag erhalten.

    ::::<small>Hier wird die Relevanz weder „mit Verkaufs“- noch „mit Werbekäse“ begründet.</small>
    ::::<small>Wer Musiker über Verkaufszahlen … bisher nicht durchgesetzt.</small>--[[Benutzer:Beispielnutzer]] …
    

    Es gibt aber auch Fälle wo eine Ersetzung mit div möglich ist (eher händische Ersetzungen)

    ::::<small>Hier wird die Relevanz weder „mit Verkaufs“- noch „mit Werbekäse“ begründet.
    ::::Wer Musiker über Verkaufszahlen … bisher nicht durchgesetzt.--[[Benutzer:Beispielnutzer]] …</small>
    

    oder

    <small>
    ::::Hier wird die Relevanz weder „mit Verkaufs“- noch „mit Werbekäse“ begründet.
    ::::Wer Musiker über Verkaufszahlen … bisher nicht durchgesetzt.--[[Benutzer:Beispielnutzer]] …
    </small>
    

    kann durch

    <div style="font-size:smaller;">
    ::::Hier wird die Relevanz weder „mit Verkaufs“- noch „mit Werbekäse“ begründet.
    ::::Wer Musiker über Verkaufszahlen … bisher nicht durchgesetzt.--[[Benutzer:Beispielnutzer]] …
    </div>
    

    ersetzt werden. Bei Aufzählungen mit * oder # wäre das schwieriger und sollte in jeder Zeile einzeln erfolgen, es sei denn, die komplette Aufzählung befindet sich innerhalb der falsch verschachtelten Tags.

    Hier eine Liste der betroffenen Tags: <small>, <code>, <span>, <del><s>(strike), <u>, <ins>, <em><i>('' kursiv), <strong><b>(''' fett), <sup>, <sub>, <font>(muss ersetzt werden), <tt>(sollte ersetzt werden), <cite>, <big>(sollte ersetzt werden), <abbr>

    Inwieweit diese vorkommen weiß ich nicht. Siehe auch Hilfe:Tags#Inline-Elemente. Für einen Bot wäre es vermutlich am sinnvollsten die fehlenden Tags zu ergänzen, händisch versuche ich eher mit div größere Blöke einzuschließen. Bei code gibt es noch Fälle wo das Tag gänzlich entfallen kann.

    <code>
     irgendetwas mit Abstand über
      Leerzeichen
     vom Rand
    </div>
    

    Oder wo es durch pre ersetzt werden könnte. Allerdings kann das kein Bot entscheiden, weil pre das nowiki einschließt und bewusst eingesetzte Effekte sonst verloren gehen. Am sinnvollsten ist es also die fehlenden (öffnenden und schließenden) Tags einfach pro Zeile zu ergänzen. --Liebe Grüße, Lómelinde Diskussion 06:55, 25. Apr. 2022 (CEST)Beantworten

    Lómelinde: Ich behaupte mal, dein Beispiel mit "<div>" ist falsch. Die Doppelpunkte erzeugen je Zeile ein HTML-Element namens dd. Du hättest dann ein div-Element mit mehreren dd-Elementen als Kind. Das geht aber nicht. dd brauchen dl-Elemente als übergeordnete Dinger. Das mehrzeilige div geht nur, wenn die Zeile nicht mit so einem Listen-Dings (*, #, :, ;) anfängt. --Wurgl (Diskussion) 07:54, 25. Apr. 2022 (CEST)Beantworten
    • @Wurgl lintid=455285 – Die API liefert zu jeder ID Zeichenpositionen für Beginn und Ende des beanstandeten Bereichs.
      • Das kann auch mal über die halbe Seite gehen.
      • Mehrere Fehler derselben Seite müssen von hinten nach vorn gefixt werden, weil die oben sonst die Positionen unten verschieben.
    • @ automatische Analyse + Reparatur
      • Das ist hochkomplex, wird ggf. mehr automatisierten Kollateralschaden hervorrufen als die gleiche Arbeitskraft in händisches Kloputzen investiert.
      • Wie schon richtig dargestellt, kann der Fehler selbst in nowiki oder pre liegen und soll gerade als solcher erklärt werden, und was bei involvierten Vorlageneinbindungen gemeint wäre wussten die Autoren oft selbst nicht. Bei trivialem beanstandetem Mikro-Bereich wie eins vor mag es eine robuste Reparatur von Standardkonstellationen geben; ohne weitere Beteiligte in diesem Bereich (Verschachtelung).
    • @Zukunft:
      • Bisher wurde der kaputte Wikitext als Text in der Datenbank abgespeichert. Im Moment der Darstellung wurde dann das HTML-Dokument generiert, und eine Fremdsoftware (Tidy, momentan Remex) hat nach privater Heuristik zu erraten versucht, wie eine kaputte Struktur zu reparieren wäre, damit alle dasselbe valide HTML-Dokument ausgeliefert bekommen und die entsprechende Heuristik unterschiedlicher Browser nicht erst beim Publikum unterschiedliche Darstellungen produziert.
      • Zukünftig sollten Bearbeitungen überwiegend per VE und Discussion Tools laufen; in der Datenbank wird deren valide Objektstruktur hinterlegt. Wer Wikitext bearbeiten möchte, bekommt aus der Objektstruktur blitzsauberen Wikitext generiert, der beim Abspeichern und zur Vorschau wieder nach jetzt eigener Heuristik in die Objektstruktur konvertiert wird.
      • Zartes Problem: Vorlageneinbindungen, die eine korrekt gespeicherte Objektstruktur durch nachträglichen Programmierfehler bei der Darstellung schrotten können.

    VG --PerfektesChaos 08:07, 25. Apr. 2022 (CEST)Beantworten

    @Wurgl: ich weiß nur, dass das (derzeit) keine Linterfehler auslöst, dass die Doppelpunkte eigentlich generell gar nicht zur Einrückung verwendet werden sollten, steht auf einem anderen Blatt, (dl, dd) = Definitionsliste. Das wirst du aber nicht wegbringen. Und was, wo, wie im HTML-Element steht, weiß ich nicht, ich analysiere Seitenquelltext, nicht das, was der Inspektor sieht. Von Hand ist es sehr mühsam hunderte von Tags nachträglich einzutippen (wobei small nicht das Problem wäre). --Liebe Grüße, Lómelinde Diskussion 08:36, 25. Apr. 2022 (CEST)Beantworten
    Sorry Lómelinde war da etwas zu verwirrt und noch zu wenig Kaffee. <small> und </small> auf eigener Zeile geht natürlich bei so Doppelpunkt-Listen. Nur innerhalb einer Zeile muss es in der selben abgeschlossen sein.
    PC: Dass ich von hinten nach vorne arbeiten muss, ist klar. Dass der Beginn passt ist auch klar, das Ende passt nicht, aber das API liefert mir das beanstandete Tag und ich muss nur das korresponierende(!) Ende suchen und dann das dazwischen analysieren. Ich kann da ja mal triviale Fälle angehen und komplexen Kram einfach auslassen. Wenn ich euch von den 28.000 Fehlern ein paar tausend wegknabbere, dann ist das schon mal was. Leider liefert das Parse-API-Interface nicht die Lint-Errors, das wäre hier recht hilfreich. --Wurgl (Diskussion) 08:43, 25. Apr. 2022 (CEST)Beantworten
    @Wurgl: Wenn jemand möchte, kann ich in lintHint die beiden Zahlen auslesbar machen, und wer möchte kann dann ein privates interaktives JavaScript auf lintHint draufsetzen, das an der angegebenen Stelle eine manuell überwachte automatische Umformung auf Knopfdruck auslöst.
    Also meiner Tabelle eine weitere Spalte hinzufügt mit einem wooosh-Button, je nach Fehlertyp und Quelltext-Inhalt an dieser Stelle, und dann auf eingene Verantwortung, ohne mich.
    VG --PerfektesChaos 17:24, 25. Apr. 2022 (CEST)Beantworten

    @Wurgl: Wie eben angekündigt, gibt es jetzt User:PerfektesChaos/js/lintHint #table-range.

    • Du bist ja (neuerdings?) auch unter die Skriptbastler gegangen.
    • Damit kannst du interaktiv den spezifizierten Bereich inspizieren, schaun ob du ein Muster für eine automatische Reparatur für diesen Typ und den vorgefundenen Bereichstext kennst, und falls ja einen Button der Tabellenzeile hinzufügen.
    • Nach Anklicken eines solchen Buttons würde ich dazu raten, diesen und alle tieferen Buttons wieder aus der Tabelle zu löschen.
    • Heut machste dir keen Abendbrot, heut machste dir Jedanken.

    VG --PerfektesChaos 17:11, 26. Apr. 2022 (CEST)Beantworten

    Na, dann gute Besserung, und du kannst ja mit Denken anfangen wennste wieder flott bist. --PerfektesChaos 16:53, 27. Apr. 2022 (CEST)Beantworten

    Adminonly

    <gallery heights="20" caption="Besuchte Länder und Gebiete" perrow="5">
    Datei:Flag of …|<center>Blidlegende</center>
    </gallery>
    
    durch
    <gallery class="center" heights="20" caption="Besuchte Länder und Gebiete" perrow="5">
     Flag of …|Blidlegende
    </gallery>
    
    Diskussionsseite ein small weg ein verschachteltes entschachteln und auch hier oben das center der Box ersetzen

    Seiten öffnen, weil ich das nicht alles einzeln aufschreiben kann zu viele Fehler

    Frage gibt es für diese Boxen für Verstorbene eine Vorlage? Dann sollte die mal angepasst werden, um zu verhindern, dass dieses center immer neu eingefügt wird. --Liebe Grüße, Lómelinde Diskussion 09:36, 26. Mai 2022 (CEST)Beantworten

    Merkwürdige div-Syntax

    Das ist jetzt nicht wirklich Linterspezifisch aber was macht man mit so etwas?

    ähnlich gelagert auch

    oder so etwas

    Mehr fallen mir jetzt nicht mehr ein, ich habe schon zu viel solchen Schrunz gesehen. Das gibt es sicher auch mit anderen Tags. --Liebe Grüße, Lómelinde Diskussion 16:01, 29. Apr. 2022 (CEST)Beantworten