Hilfe Diskussion:Wikisyntax/Validierung

[[:]]

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

Statistik

26. September 2022

Namensraum	HTML5 misnested	Tidy font link bug	Misnested tags	Missing end tag	Obsolete HTML	Stripped tags	Andere	Gesamtzahl
Artikel								000.0  ▼
Diskussion			1.542	24.394				25.936  ▼
Benutzer			1.824	17.743	08.389			27.956  ▼
Benutzer Disk	2	15	1.514	12.498	20.504	2	3	34.538  ▼
WPNR			3.770	11.933	24.427			40.130  ▼
andere NR				2		1		000.03  ▬
Gesamt (alle)	2	15	8.650	66.570	53.320	3	3	128.563  ▼

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.058 FfOoNnTt-Tags (Stand 26. September 2022). -- Lómelinde Diskussion Liebe Grüße, Lómelinde Diskussion 07:42, 26. Sep. 2022 (CEST)
Aktuelle Zahlen: https://fireflytools.toolforge.org/linter/dewiki

Ersatztabelle

Fehler auslösende Signaturen, Tag- oder Fontfehler

font color einfache Fälle

Gemeldet in Phabricator Task T316858 <font color="blue">…</font> oder <font color=blue>…</font> <font color="green">…</font> <font color="orange">…</font> <font color="red">…</font> <font color="00868B">…</font> <font color="#…">…</font> … andere Farbnamen Ersatz 701 wobei es mit und ohne Trennzeichen vorkommen kann und Fälle von color="00868B" (Beispielwert) für span das Hashtag benötigen siehe Zeile 5. Ebenso kann Groß- und Kleinschreibung vorkommen, oder auch mal Leerzeichen color = "00868B" dazwischen stehen und mit oder ohne Semikolon am Ende. Das könnte eventuell die Anzahl der veralteten Fonttags halbieren. Ló 17:17, 11. Jul. 2022 (CEST) Lómelinde, ich versuch's – Doc Taxon • Disk. • 16:18, 18. Jul. 2022 (CEST) da muss ich noch etwas Hirnschmalz reinstecken – Doc Taxon • Disk. • 19:39, 9. Aug. 2022 (CEST) <span style="color:blue;">…</span> <span style="color:green;">…</span> <span style="color:orange;">…</span> <span style="color:red;">…</span> <span style="color:#00868B;">…</span> <span style="color:#…;">…</span> … andere Farbnamen

tt-Signaturen

Fehler auslösende Signaturen

tt-Tags ersetzen durch {{Hilfe/tt}}
SteKrueBe [[Benutzer:SteKrueBe|<tt>SteKrueBe</tt>]] <sup><small> [[Benutzer Diskussion:SteKrueBe|<tt>Office</tt>]] </small></sup> [[Benutzer:SteKrueBe|<tt>SteKrueBe</tt>]] [[Datei:BSicon ANCHOR330.svg|18px|verweis=Benutzer Diskussion:SteKrueBe]] Ersatz 784 {{Hilfe/tt|1=[[Benutzer:SteKrueBe|SteKrueBe]] <sup><small>[[Benutzer Diskussion:SteKrueBe|Office]]</small></sup>}} [[Benutzer:SteKrueBe|{{Hilfe/tt|1=SteKrueBe}}]] [[Datei:BSicon ANCHOR330.svg|18px|verweis=Benutzer Diskussion:SteKrueBe]]
Lukas²³ <tt><sup>[[User:Lukas²³/b|Bew]]</sup> <small>[[WP:VJ|WPVB]]</small> <sub>[[WP:WPA|Plattenladen]]</sub></tt> <tt><sup>[[User:Lukas²³/b|Ⓑew]]</sup> <small>[[WP:VJ|ⓌPVB]]</small> <sub>[[WP:WPA|Ⓟlattenladen]]</sub></tt> Ersatz 126 {{Hilfe/tt|1=<sup>[[User:Lukas²³/b|Bew]]</sup> <small>[[WP:VJ|WPVB]]</small> <sub>[[WP:WPA|Plattenladen]]</sub>}} {{Hilfe/tt|1=<sup>[[User:Lukas²³/b|Ⓑew]]</sup> <small>[[WP:VJ|ⓌPVB]]</small> <sub>[[WP:WPA|Ⓟlattenladen]]</sub>}}
codc <sup>[[Benutzer Diskussion:Codc|<code style="border:none;">Disk </code>]]</sup><small>[[WP:RC|<tt>Chemie </tt>]]</small><sub>[[WP:MP|<tt>Mentorenprogramm</tt>]]</sub> <sup>[[Benutzer Diskussion:Codc|<span style="font-family:Monospace;">Disk </span>]]</sup><small>[[WP:RC|<tt>Chemie </tt>]]</small><sub>[[WP:MP|<tt>Mentorenprogramm</tt>]]</sub> <sup>[[Benutzer Diskussion:Codc|<tt>Disk </tt>]]</sup><small>[[WP:RC|<tt>Chemie </tt>]]</small><sub>[[WP:MP|<tt>Mentorenprogramm</tt>]]</sub> Ersatz 2.583 {{Hilfe/tt|1=<sup>[[Benutzer Diskussion:Codc|Disk ]]</sup><small>[[WP:RC|Chemie ]]</small><sub>[[WP:MP|Mentorenprogramm]]</sub>}}
Agathenon <tt>[[Benutzer:Agathenon|<span style="font-size:1.1em;"><span style="color:darkgreen;">Agathenon</span></span>]][[Datei:VeveLegba.svg|20px|verweis=Benutzer Diskussion:Agathenon]]</tt> Ersatz 374 {{Hilfe/tt|1=[[Benutzer:Agathenon|<span style="font-size:1.1em; color:darkgreen;">Agathenon</span>]]}}[[Datei:VeveLegba.svg|20px|verweis=Benutzer Diskussion:Agathenon]]
Elvaube <tt>—&nbsp;[[User:Elvaube|Elvaube]]&nbsp;<sup>[[BD:Elvaube|?!]]</sup></tt> Ersatz 251 {{Hilfe/tt|1=—&nbsp;[[User:Elvaube|Elvaube]]&nbsp;<sup>[[BD:Elvaube|?!]]</sup>}}
Fossa <tt>[[Benutzer:Fossa|<span style="color:darkorange">fossa</span>]]&nbsp;'''[[Benutzer:Fossa/Vertrauen|<span style="color:fuchsia">net</span>]]'''&nbsp;[[Benutzer_Diskussion:Fossa|?!]]</tt> Ersatz 681 {{Hilfe/tt|1=[[Benutzer:Fossa|<span style="color:darkorange">fossa</span>]]&nbsp;'''[[Benutzer:Fossa/Vertrauen|<span style="color:fuchsia">net</span>]]'''&nbsp;[[Benutzer_Diskussion:Fossa|?!]]}}

@ Doc Taxon damit wir hier mal weiter kommen. Das ist nur eine Auswahl an tt-Kandidaten, es wären aber rund 4800 Fehler weniger. --Liebe Grüße, Lómelinde Diskussion 08:30, 27. Sep. 2022 (CEST)

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.

• 468 304 Artikel
• 1.402 1.043 Artikel

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:

• 1.139 1.319 Artikel (ansteigend)

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)

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 (wahlloses Beispiel), 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)

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)

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)

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 [1].

@Wurgl: Natürlich sollen keine komplexeren Fälle automatisiert angefasst werden.--Mabschaaf 17:10, 24. Apr. 2022 (CEST)

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)

Hm. Alles klar. Schade. Wäre auch zu schön gewesen...--Mabschaaf 20:21, 24. Apr. 2022 (CEST)

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)

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)

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)

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
</code>

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)

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)

• @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)

@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)

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)

@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)

@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)

• Momentan leide ich am bekanntlich überaus tödlichen Männerschnupfen und mach lieber Zeuchs wo ich nicht so viel denken muss. Außerdem istwar Beta karp0tt! --Wurgl (Diskussion) 11:08, 27. Apr. 2022 (CEST)

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

Nachgefragt da diese Fehler noch immer zu den häufigsten Neueintragungen gehören: @Doc Taxon und Wurgl, habt ihr inzwischen eine Lösung für diese Probleme gefunden? Insbesondere auch für die mit Linkklammern verschachtelten Kursivtags. HD:Wikisyntax/Validierung#Bot-fixing: Missing end tag (kursiv und Linkklammern verschachtelt oder Leerzeichen zwischen URL und kursiv fehlt) --Liebe Grüße, Lómelinde Diskussion 06:51, 16. Jun. 2022 (CEST)

Diese drei Muster guck ich regelmäßig.

• insource:/\[https?:\/\/[^'\]]*''[^'\]]*\]\.''[^\]]/
• insource:/\[https?:\/\/[^'\]]*''[^'\]]*\]\,''[^\]]/
• insource:/\[https?:\/\/[^'\]]*''[^'\]]*\]''[^\]]/

Also [https://blah''blubb blubb]'' nicht gefolgt von ] und ev. ein Punkt oder Komma nach der schließenden Klammer. Und zwar in den Namensräumen 0, 1, 3, 4, 5, 100, 101. 550 hat der Bot am 17. April gemacht und jetzt finde ich wohl nix mehr.

Das '' unmittelbar nach dem Link, also der potentielle IABot-Fehler mach ich nebenbei mit, wenn es mir über den Weg läuft, aber extra gesucht wird nicht danach. --Wurgl (Diskussion) 09:05, 16. Jun. 2022 (CEST)

Nun ja, oben wünschte sich jemand genau das. Ich zitiere mal: „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:“ PC am 8. Februar 2022 um 16:42 (CET) --Liebe Grüße, Lómelinde Diskussion 09:29, 16. Jun. 2022 (CEST)

1998 Artikel (bzw. Seiten) weniger. --Wurgl (Diskussion) 18:29, 16. Jun. 2022 (CEST)

Trennung von Kursivauszeichnung innerhalb der Links:

|     1744 | 20220616                    |
|      141 | 20220618                    |
|      216 | 20220619                    |
|      112 | 20220620                    |
|        3 | 20220621                    |
|       13 | 20220622                    |
|       86 | 20220623                    |
|      122 | 20220624                    |
|      136 | 20220626                    |
|      195 | 20220627                    |
|      104 | 20220628                    |
|       43 | 20220629                    |
|      342 | 20220630                    |
|      191 | 20220701                    |
|      200 | 20220702                    |
|       34 | 20220703                    |
|      176 | 20220704                    |
|       83 | 20220705                    |
|       53 | 20220706                    |

Ich kapiere diese Suche nicht. Okay, der arme Bot fällt jeden Tag ins Timeout, aber dennoch findet der jeden Tag einen ganzen Sack voll Fälle. Wann ist Schluss? --Wurgl (Diskussion) 08:08, 6. Jul. 2022 (CEST)

Es wird nie Schluss sein! Weit täglich neue Fehler eingefügt werden. Wenn du dir oben die Statistik ansiehst, wirst du feststellen, dass „Missing end tag“ noch rund die Hälfte aller Fehler ausmacht. Davon sind etliche durch verschachtelte Kursivtags ausgelöst, andere beispielsweise auch durch leere '''' oder '''''' weil sich manche Benutzer denken das kann man so schon mal einfügen auch wenn der Inhalt noch fehlt. Letzteres erzeugt zwei Fehler fett und kursiv nicht geschlossen. Oder einfach offen gelassene Tag oder Zeilenumbrüche. Hier mal ein Beispiel, wobei sich der Benutzer weigert Spezial:Diff/223107503/223107508 das zu beheben, er hat etliche Unterseiten die rund 200 Fehler erzeugen, wobei pro Seite maximal 21 Fehler in den Listen angezeigt werden. Ich habe keine Ahnung was man mit denen machen soll. Das ist leider kein Einzelfall, und solange es legitim ist, die Reparaturen zu verweigern oder aktiv zurückzusetzen, wird es auch nie enden können. --Liebe Grüße, Lómelinde Diskussion 09:18, 6. Jul. 2022 (CEST)

Das sind uralte Dinger. Wenn was neu hinzukommt, dann zwei oder drei Artikel aber nicht 50, 100 oder 200. Irgendwie wird der Suchindex jeden Tag neu umsortiert. --Wurgl (Diskussion) 09:28, 6. Jul. 2022 (CEST)

Im ANR kommen jeden Tag etliche Fehler neu hinzu (manchmal auch mehr als 50), das weiß ich, weil das sonst Null sein müsste.

Klar sind in deiner Abfrage noch alte Fälle, die aber keine Linterfehler erzeugen.

Auch die Syntaxanalyse findet manchmal noch Linterfehler in Seiten, die lange nicht bearbeitet wurden, oder, weil die Analyse verschärft wurde. Aber irgendwann müssten die „Altfälle“ ja durch sein. Und je weniger es werden, desto besser wird die Suche funktionieren, weil es irgendwann nicht mehr zu Zeitüberschreitungen kommt. Wichtig ist, es hilft valide Syntax herzustellen, egal wie lange es noch dauert. Du hast einen Bot, was soll ich sagen? Ich mache das täglich seit 2017 von Hand, hey ich wäre froh, wenn es ein Ende nehmen würde, aber wie gesagt, manche Benutzer machen es einem sehr schwer, warum auch immer, verstehen kann ich das nicht. --Liebe Grüße, Lómelinde Diskussion 09:44, 6. Jul. 2022 (CEST)

Adminonly

...

<div style="margin:1.5em; border:7px solid #AAAAAA; padding: 2em 1em 2em 1em; background-color:#FFFFFF; align:center;">
[[File:Kerze 2007k.JPG|80px|left]]<center>

</center><div align="right"></div>
</div>

center ersetzen durch

<div style="margin:1.5em; border:7px solid #AAAAAA; padding: 2em 1em; background:#FFFFFF; text-align:center;">
[[Datei:Kerze 2007k.JPG|80px|left]] 

</div>

Teilweise fehlt auch hinten das Ende </center><div align="right"></div> --Liebe Grüße, Lómelinde Diskussion 15:30, 25. Sep. 2022 (CEST)

Merkwürdige div-Syntax

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

• <div class="NavEnd">&nbsp;</div> gibt es wirklich eine solche Klasse?

ähnlich gelagert auch

• <div class="NavHead" style>…</div> zumeist noch begleitet von einem unnötogen <div align="center">…</div> denn NavHead ist schon zentriert

oder so etwas

• </div style> und </div style=> wohlgemerkt das sind „schließende“ Elemente
• <div clear="all" style="clear:both;"></div> mit clear= als Attribut. Da müssten eigentlich auch mal alle br clear und br style ersetzt werden, insbesondere die selbsschließenden.
• <div > und </div >

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)

Hallo Ló, nur zur Info: Werde übers Wochenende die syntaktisch falschen div-Ende-Tags bearbeiten. Nach ersten Korrekturen fiel auf, dass alle Stellen bislang vom selben Autor stammen – habe ihn daher angesprochen... Grüße u. Schöne Pfingsten, --rolf_acker (Diskussion • Beiträge) 12:49, 3. Jun. 2022 (CEST)

Das ist nett von dir, vielen Dank. Ich wünsche dir ebenfalls angenehme Feiertage. --Liebe Grüße, Lómelinde Diskussion 12:59, 3. Jun. 2022 (CEST)

Nicht geschlossene Kommentare

Mich wundert dass ein öffnender Kommentar <!-- ohne schließendes --> keinen Linterfehler erzeugt. Gerade eben hatte ich sowas in Maura und da sind drei Begriffe einfach nicht angezeigt worden. Auf Seiteninformationen hab ich jedenfalls keinen Linterfehler gefunden. --Wurgl (Diskussion) 09:27, 28. Jul. 2022 (CEST)

Nein das wird auch nicht erkannt, soweit ich weiß. Probleme bereiten zudem Kommentare in Kommentaren, <!-- Kommentare <!--in Kommentaren -->--> weil das erste gefundene Ende, dann als Ende für das erste öffnende Kommentartag angesehen wird Hilfe:Tags/Kommentar#Syntaktischer Inhalt. Das verhält sich so ähnlich wie das <nowiki> nowiki in <nowiki>nowiki</nowiki></nowiki> das endet auch mit dem ersten schließenden nowiki. Du kannst das gern im Phabricator anregen, dass so etwas gefiltert wird. Es gibt noch etliches, was noch nicht erfolgreich erkannt wird, denke ich. Ab und zu verschärfen sie da etwas und man merkt es nach einem Update an neuen Fällen, die man bisher nicht hatte. Wie man so etwas finden soll, weiß ich aber auch nicht. Es gibt auch mit halben ref-Tags Probleme, die Inhalte verschwinden lassen. Man sieht es halt nicht sofort, wenn etwas fehlt. --Liebe Grüße, Lómelinde Diskussion 09:58, 28. Jul. 2022 (CEST)

Die nicht geschlossenen Kommentare findet mein Vorlagen-Dingsbums auf persondata.toolforge.org/vorlagen … hierzuwiki ist das kein Problem, aber es gibt ja noch 900+ andere. --Wurgl (Diskussion) 10:09, 28. Jul. 2022 (CEST)

nowiki innerhalb nowiki zu platzieren bringt gar nichts außer unerwünschte, oben genannte Problematik. Dasselbe gilt für Kommentare. Solche Konstruktionen sollten meiner Meinung nach aufgelöst werden (innere nowiki- und Kommentar-Tags raus). – Doc Taxon • Disk. • 05:17, 23. Aug. 2022 (CEST)

Der Wiki-Coede wurde einst erfunden, damit man sich genau nicht mit solchen Details herumschlagen muss!

Der Wiki-Coede wurde einst erfunden, damit man sich genau nicht mit solchen Details, wie korrekte HTML-Tags herumschlagen muss! Irgendwie ist des deshalb eine grobe Zielverfehlung, wenn man nun beginnt, solche Code-Standrads durchzusetzen. Wenn Pasoid / VisualEditor und ähnliche Tool mit dem in der WP bisher funktionierenden Code nicht umgehen können, sind diese Tool unzureichend/zu unflexibel. Ich habe bisher gedacht, dass Tools wie Pasoid / VisualEditor den Autoren Arbeit abnehmen sollten. Nun scheint es aber so, dass damit Probleme geschaffen werden, die es ohne diese Tools nicht gäbe. Wenn diese Tools zu unflexibel gestaltet sind und sie es nicht schaffen aus nicht immer ganz strandendkonformem Wiki-Code in Browsern funktionierenden HTML-Code zu erzeugen, läuft die Entwicklung in die total falsche Richtung. Die WP sollte sich auf Inhalte, statt auf "schönen" Code konzentrieren. Sonst vertreibt man noch mehr Autoren. So bleiben am Ende nur noch die Bürokraten. Schade. ---Thomei08 --Thomei08 08:18, 7. Sep. 2022 (CEST)

Beschwere dich bei den Softwaretechnikern, die diese Softwareumstellung betreiben, hier ist absolut der falsche Platz dafür. Hier geht es nur darum die durch diese Neuerungen entstehenden Fehler vorab zu beheben. --Liebe Grüße, Lómelinde Diskussion 09:09, 7. Sep. 2022 (CEST)

Es gibt ja viele hilfreiche Benutzer, die eventuelle Probleme beheben. Und dann gibt es Benutzer, die stolz auf die Fehler sind. Ich fordere seit langem, dass auf Seiten, die Syntax-Fehler aufweisen, große Warnungen erscheinen. Andim (Diskussion) 09:32, 7. Sep. 2022 (CEST)