Hilfe Diskussion:Wikisyntax/Validierung/Archiv

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Hilfe Diskussion:Wikisyntax/Validierung/Archiv#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Hilfe_Diskussion:Wikisyntax/Validierung/Archiv#Thema_1

Diskussion und so

Alles so rot hier. Wo wird das (inhaltlich, also nicht die Hilfe, sondern das Tool) diskutiert? Ich lese bspw. Bekannte „falsche Fehler“; ignorieren:... Falscher Ansatz imho. Der Software muss beigebracht werden, die selber zu erkennen. --AMGA (d) 10:17, 2. Jul. 2017 (CEST)

Middle

Es wundert, dass in der Dateioptionen-Fehlerliste kein einziges mal "middle" bemängelt wird, obwohl das etwa 70 Mal im Artikelbestand aufaucht und laut Hilfe:Bilder gar nicht existiert. Selbst wenn die Spezialseite noch nicht den ganzen Artikelbestand gescannt hat, würde ich zumindest ein paar Treffer erwarten. Wie kommts? 147.142.62.125 19:05, 2. Jul. 2017 (CEST)

middle oder mitte	oben	unten
Text mittig zum	Text steht am oberen Bildrand	Text steht am unteren Bildrand

Der Paremeter funktioniert, nur nicht immer so, wie man meinen würde. Siehe H:Bilder/vertikale Ausrichtung. Ich habe das auch schon mal versucht zu verwenden, es tat bloß nicht das was ich dachte. --Liebe Grüße, Lómelinde Diskussion 19:36, 3. Jul. 2017 (CEST)

Bei einem zu schmalen Fenster (also quasi auf jedem Smartphone, aber auch auf kleinen Laptops) steht der Text immer oben drüber. 129.13.72.197 08:59, 4. Jul. 2017 (CEST)

Oh das wusste ich nicht, ich habe kein Smartfone. Aber du hast Recht in der Mobilen Ansicht kann ich das auch sehen. Das müsstest du dann wohl bei der Technik melden. Ich weiß nicht ob das so gewollt ist oder eher ein Bug sein könnte. --Liebe Grüße, Lómelinde Diskussion 09:04, 4. Jul. 2017 (CEST)

Um das zu testen kannst du einfach dein Browserfenster schmaler machen, so dass es z. B. nur die Hälfte des Bildschirms ausfüllt. 129.13.72.197 09:10, 4. Jul. 2017 (CEST)

middle oder mitte

Text mittig zum

oben

Text steht am oberen Bildrand

unten

Text steht am unteren Bildrand

Dann mal in kleiner. --Liebe Grüße, Lómelinde Diskussion 09:14, 4. Jul. 2017 (CEST)

Mobil setzt es dann in die Mitte. Toll ist es nicht. Aber ich denke eher ein technisches Problem. --Liebe Grüße, Lómelinde Diskussion 09:16, 4. Jul. 2017 (CEST)

Die Option ist selten sinnvoll und nur für sehr kleine Grafiken geeignet, die in einen laufenden Fließtext eingestreut werden; ansonsten Quatsch, und deshalb auch kein technisches Problem. LG --PerfektesChaos 09:17, 4. Jul. 2017 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Lómelinde 06:59, 29. Dez. 2017 (CET)

Konfiguration

Wurde über Nacht die Konfiguration geändert oder hat jemand die restlichen 91 Benutzer- und Projektseiten auf Spezial:LintErrors/self-closed-tag erledigt? 129.13.72.198 10:06, 19. Jul. 2017 (CEST)

Ersteres kann schon sein. Vielleicht waren es false-positives. Vielleicht haben die aber auch alle ein bislang defektes Babel eingebunden oder was; grad wurde der Kurier-Ticker von 2006 repariert, aber irgendwie anders. en:Special:LintErrors hat noch was. LG --PerfektesChaos 13:22, 19. Jul. 2017 (CEST)

Es war wohl Benutzer:Plagiat, keine Konfigurationsänderung. 129.13.72.198 15:30, 19. Jul. 2017 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Lómelinde 06:59, 29. Dez. 2017 (CET)

Benutzer:W like wiki/Spielwiese

Das dürfte ein False-Positive sein. Es wird als Dateioptionsfehler "RECHTS" bemängelt, das ist aber eine reguläre Bildbeschreibung. 92.74.30.46 21:17, 23. Jul. 2017 (CEST)

Nö; Bildlegenden, deren Text mit einem Schlüselwort übereinstinnt, sind unzulässig. Da hilft ein vorneweg und fertig. VG --PerfektesChaos 21:23, 23. Jul. 2017 (CEST)

Unzulässig? Wo steht das? 92.74.30.46 21:50, 23. Jul. 2017 (CEST)

Allgemeine Syntaxregel; alles, was Parameterbezeichnung ist, kann nicht Freitext-Bildlegende sein. Woher soll die Software sonst wissen, wann ein Parameter gemeint ist und wann Bildlegende, zumal rein technisch auch nach der Bildlegende noch Parameter folgen dürfen und die Bildlegende somit auch nicht letztes Element sein muss. Nebenbei: Was gehen dich eigentlich Dateioptionen auf Benutzerseiten an, das ist deren Ding. ANR ist wichtig, der Rest geht im Rauschen unter und eine Spielwiese erledigt sich irgendwann wieder von selbst. VG --PerfektesChaos 22:06, 23. Jul. 2017 (CEST)

ANR erledigen andere, daher mach ich erst den Rest ;) Außerdem muss mir im BNR nicht nachgesichtet werden :P 92.74.30.46 23:24, 23. Jul. 2017 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Lómelinde 06:59, 29. Dez. 2017 (CET)

Benutzer Diskussion:Gereon Kalkuhl (WMF)

Hier wird wohl in der Zeile [[File:Wikimedia-logo.svg|{{#switch:{{CONTENTLANG}}|ar=left|he=left|right}}||150px]] eines der beiden doppelten Pips bemängelt. Warum aber nicht beide? Ich hatte so einen Fall schonmal. Das kann man testen, indem man nur das erste doppelte Pipe korrigiert. Dann verschwindet der Eintrag aus der Liste, obwohl nochmal eine Dopplung vorhanden ist. 94.217.96.206 23:12, 24. Jul. 2017 (CEST)

Dass der Eintrag aus der Liste „verschwindet“, beweifle ich.

Wenn die neue Seitenversion abgespeichert wird und neu analysiert wird, und eine veränderte Fehlerkonstellation gefunden wird, dann bekommen die neu detektierten Fehler eine frische Fehlernummer, und die Seite wird gaanz ganz hinten neu aufgelistet.

Mit der alten Fehlernummer am historischen Ort ist sie nicht mehr sichtbar; das stimmt.

VG --PerfektesChaos 09:48, 25. Jul. 2017 (CEST)

Ich hab den ersten Fehler (der auf der Spezialseite bemängelt wurde) behoben. In der Liste ist die Seite jetzt trotz weiterer Doppelpipe nicht mehr enthalten. 129.13.72.198 13:26, 25. Jul. 2017 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Lómelinde 06:59, 29. Dez. 2017 (CET)

Portal Diskussion:Polen/Archiv bis 2010

Soweit ich das sehe ist diese Seite die einzige in der Liste mit den falsch verschachtelten Tags, bei der in der zweiten Spalte nicht er falsche Tag angegeben ist. Was hat es damit auf sich? 94.217.96.206 23:31, 24. Jul. 2017 (CEST)

Vielleicht aus einer Einbindung, muss ich mir später ansehen. Kann ich auf die Schnelle nicht sagen. --Liebe Grüße, Lómelinde Diskussion 07:42, 25. Jul. 2017 (CEST)

So nun kannst du es sehen und einzeln anklicken. --Liebe Grüße, Lómelinde Diskussion 11:27, 25. Jul. 2017 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Lómelinde 06:59, 29. Dez. 2017 (CET)

Dateiparameter link und alt

So ich bleibe dabei, es gibt immer wieder fostered errors, die eindeutig durch leere Parameter in Bilddateien ausgelöst werden. Entweder sind die „false positive“ oder es wird tatsächlich explizit geprüft, dass sie einen Wert haben müssen, wenn sie vorhanden sind. Ich habe es jetzt mehrfach gehabt, dass man das löschen musste. Die Links auf # zu legen finde ich schlechter als |link= zu entfernen. Dann lieber den Link zur Dateibeschreibung, als auf die Hauptseite umzuleiten. Das ist eher verwirrend. --Liebe Grüße, Lómelinde Diskussion 19:43, 30. Jul. 2017 (CEST)

link

So die Vorlage:Smiley hatte ein Serverproblem, oder wie soll ich das beschreiben.

1. Da wurde angezeigt der Auslöser wäre link und zwar aus der Einbindung {{Smiley|happyface}} ausgelöst durch eine Vorlage (Vorlage:Smiley/Dokumentation)
   • Es ließ sich beheben, wenn man alle |link= entfernt. Die Vorlage wurde nicht mehr bemängelt.
2. Ebendiese löste auch auf mehreren Benutzerseiten Fehler aus, ausgelöst durch eine Vorlage:Smiley bei genauerer Betrachtung immer {{Smiley|happyface}}.

Im Endeffekt war das Problem aber ein Nulledit der jeweils die Seiten aus der Liste entfernt hat. Einmal die Doku der Vorlage, in den anderen Fällen jeweils die betroffene Benutzer(Diskussionsseite).

Da sucht man sich doch dumm und dusselig, um das zu finden, oder auf so etwas zu kommen.

Es gibt aber weitere zwei Vorlagen, bei denen ich es nicht beheben kann.

Ähnliches Problem link Schwesterprojekte entfernt man |link= sind sie aus der Liste raus, setzt man es wieder ein, sind sie wieder dort. Wo soll ich denn hier einen Nulledtit tätigen?

Es wird keine einzelne Einbindung moniert sondern jeweils der komplette … Komplex Ich weiß es einfach nicht.

alt

als Beispiel alternativtext und   ???

Ich weiß es nicht genau, aber danach war der Fehler aus der Liste.

---

Auch die {{Infobox S-Bahn}} kriege ich nicht gelöst. Hat irgendjemand noch eine Idee, wie man das beheben kann? --Liebe Grüße, Lómelinde Diskussion 07:35, 1. Aug. 2017 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Lómelinde 06:59, 29. Dez. 2017 (CET)

Neue Einträge

Kann man irgendwo sehen wie weit die Spezialseite schon durch den Seitenbestand "gecrawlt" ist? So wie ich das sehe fehlen allein bei den Dateifehlern im Wikipedia-Namensraum noch 1800 Seiten. Von einer Ladung von 1872 Seiten stehen gerade einmal 2 in der Spezialseite drin. Das würde bedeuten, dass die Spezialseite nicht einmal 1% der Seiten gecrawlt hat. 129.13.72.198 16:16, 31. Jul. 2017 (CEST)

Ganz so extrem scheint es mir nicht zu sein, Vielleicht geht das auch nach Priorität, denn bei den oberen kommen ja täglich nicht mehr wirklich viele hinzu. Ich denke aber es ist auch so, dass Seiten die lange nicht bearbeitet wurden erst später erscheinen als jene die kürzlich im Zugriff waren. Eventuell geht es nach Namensraumnummern? Ich denke wir liegen schon recht gut.

Nach welcher Art Fehler hast du denn gesucht? Wovon sind 1872 von denen erst 2 gelistet wurden? --Liebe Grüße, Lómelinde Diskussion 17:22, 31. Jul. 2017 (CEST)

Hier. 88.67.125.95 19:46, 31. Jul. 2017 (CEST)

Ach so Doppelpipes. Davon hatte ich auch schon zwei oder drei. Das könnte eigentlich auch ein Bot beheben, denke ich. Ist ja recht gut aufzuspüren. Leichter jedenfalls als meine Phantome mit dem Hinweis link. --Liebe Grüße, Lómelinde Diskussion 06:26, 1. Aug. 2017 (CEST)

• Das neue Parser-System (Parsoid) generiert diese Fehlermeldungen als Abfallprodukt; das Linter-System fängt nur bestimmte davon auf, verwaltet sie in einer Datenbank und macht diese zugänglich.
• Linter ist also rein passiv und schreibt einfach nur mit.
• Erst wenn die Seite neu geparst wird, weil sie bearbeitet wurde oder aber weil sie wegen Überalterung und Desinteresse aus dem Cache herausgefallen war und sie nun plötzlich doch mal wieder jemand sehen wollte, geht Parsoid erneut drüber.
• Bei einem Artikel über eine nigerianische Landstraße oder ein Diskussiosnsarchiv oder FZW von 2007 kann das auch ein halbes Jahr dauern, im Prinzip mehrere Jahre.
• Prioritäten, Namensraum oder sonstwas spielen keine Rolle; aber die als wichtig eingestuften Fehler sind seltener und haben nicht so viel Bewegung.
• Bevor die Seite nicht durch Parsoid gegangen ist, kann niemand vorausahnen, welche Fehler darin liegen könnten und welche Priorität der hätte; wenn Parsoid einen Fehler sieht und die Verbindung mit der Linter-Datenbank gerade wach ist, dann wird das dort auch eingetragen. Wenn eine Seite fehlerfrei geparst wurde, wird auch das an Linter gemeldet, und diese Seite aus der Datenbank genommen, falls vorhanden.
• „gecrawlt“ wird überhaupt nix.
• Doppelpipes sind so völlig schnuppe und machen keinerlei Probleme, dass sie nicht einmal einen Bot-Einsatz lohnen; nur im Zusammenhang mit wirksamen Edits.

LG --PerfektesChaos 10:47, 1. Aug. 2017 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Lómelinde 06:59, 29. Dez. 2017 (CET)

Weitere Fehlertypen

Mit welchen und wievielen weiteren Fehlertyp-Analysen ist in mittlerer Zukunft zu rechnen? 178.2.95.188 18:39, 29. Sep. 2017 (CEST)

Das ist völlig unvorhersagbar.

Wo auch immer ein Programmierer grad eine Gelegenheit sieht und Lust auf Umsetzung hätte.

Beispielsweise könnte man sich die Frage stellen, welche Atttribute in MW- und HTML-Tags zulässig wären und was in einem style= oder class= für Wertstrukturen angegeben werden dürfen. Oder ob sich ein id= mit anderen Fragmentbezeichnern überschneiden würde.

VG --PerfektesChaos 20:22, 30. Sep. 2017 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Lómelinde 06:59, 29. Dez. 2017 (CET)

Wikipedia:Café/Archiv 2017 Q2

Die Seite wird in der bogus-imageoptions-Liste aufgeführt, aber der markierte Fehlerbereich sieht richtig aus?! 129.13.72.197 17:23, 26. Okt. 2017 (CEST)

Das Problem ist, dass die Seite so groß ist, dass LintHint es nicht auswerten kann. Die Einbindung ist vermutlich nicht der Auslöser, sondern irgendetwas davor, ein nicht geschlossenes Tag oder ein nicht geschlossener Link. Ich hatte da auch schon mal reingeschaut, aber mein Rechner verträgt diese Bytezahlen nicht gut. Ich kann aber noch mal schauen, ob ich es finde. --Liebe Grüße, Lómelinde Diskussion 17:29, 26. Okt. 2017 (CEST)

Also alles habe ich noch nicht gefunden verbliebene Fehler, aber wie gesagt kann ich das nur sehr schlecht bearbeiten, weil die Seite einfach viel zu groß ist. Da geht alles extrem langsam. Man könnte auch mal alle Doppelten Pipes suchen, oder jede einzelne Dateieinbindung checken. Für mich zu zeitaufwendig. Da kommt mein Browser nicht hinterher. Änderungen oder Skrollen im Zeitlupentempo sind nicht so das was ich mir unter effektivem Arbeiten vorstelle. --Liebe Grüße, Lómelinde Diskussion 10:36, 27. Okt. 2017 (CEST)

Trick: Quartal wochenweise nach lintHint kopieren. LG --PerfektesChaos 11:45, 27. Okt. 2017 (CEST)

Und wie viele Tage soll das dauern? Die Seite kann ja nicht einmal Abschnittsweise bearbeitet werden. Das ist mir zu unwichtig, als dass ich da nochmals eine Stunde investieren möchte. Dank Syntaxhighlight sehe ich schon einige der Fehler schneller, weil der Text sich entsprechend einfärbt wenn etwas fehlt, aber ebenso verlangsamt es alles um ein vielfaches. Ohne sehe ich aber quasi nichts als eine Textwüste. Es hapert ja schon an der Markierung der Textfragmente, das geht im Schneckentempo. Ne so wichtig ist diese eine Seite dann auch nicht. Es ist ein Archiv und die haben keinerlei Priorität. --Liebe Grüße, Lómelinde Diskussion 12:13, 27. Okt. 2017 (CEST)

@PerfektesChaos: Kann man irgendwie die Lintanalyse purgen? Ich denke einige der Fehler sind gar nicht mehr vorhanden, klick mal spaßeshalber WP:Cafe den letzten der angeblichen small-Tag-Fehler an, hier das kann unmöglich die Stelle sein, die einen Fehler auslöst. Das ist auch bei den anderen. Eigentlich müsste die Seite auch ans Ende gerückt sein, da ich sie ja kürzlich bearbeitet hatte, sie bleibt aber auf ihrer Position. --Liebe Grüße, Lómelinde Diskussion 15:33, 28. Okt. 2017 (CEST)

Du kannst dir doch einfach die ganze Seite auf eine Unterseite oder die Spielwiese kopieren. Wenn der Fehler dann wieder gefunden wird, ist er noch da. 92.75.105.36 23:22, 28. Okt. 2017 (CEST)

Könnte man machen es ist ja nicht nur ein Fehler sondern trotz mehrerer Anpassungen werden noch immer 21 angezeigt. Ich mag aber solch große Seiten eigentlich gar nicht bearbeiten. Ich habe gestern mal bei einer recht großen Seite versucht den VisualEditor zu verwenden, weil ich eine Tabellenzeile komplett löschen wollte. Auch da versagte mein Rechner den Dienst. Es kam ständig die Meldung dass ein Skript wohl überlastet sei. Und die Seite war vergleichsweise klein (141.416 Bytes, nach mühevoller zeitraubender Kleinarbeit waren es 74.538 Bytes weniger). Du kannst das aber gern mal testen. Wie ich schon schrieb, so megawichtig ist diese eine Seite dann auch nicht. --Liebe Grüße, Lómelinde Diskussion 06:45, 29. Okt. 2017 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Lómelinde 06:59, 29. Dez. 2017 (CET)

Font-bug

Das ist doch total doof, da werden tausende SignaturFarbLinkFehler kommen, wer soll sich denn so etwas antun? Kann man da nicht irgendetwas machen, so dass nur Artikelseiten gelistet werden? Ich drehe echt am Rad, wenn ich den Zuwachs betrachte. Und effektiv lässt sich nichts … rein gar nichts … beheben, ohne dass man Gefahr läuft angezählt zu werden. So macht das wirklich keinen Spaß.

Halllooooo SoftwareanAlyseLinterTechniker hört mich jemand da draußen? <seufz> --Liebe Grüße, Lómelinde Diskussion 17:49, 2. Nov. 2017 (CET)

Ich bereinige die aktiven Projektseiten und Portale; ANR müsste 0 sein, weil es da sowieso kein font gibt, und der Rest ist Jahrzehnte alter Signaturschrott und Fall für die Archäologie. Das werden wir zukünftig mit vielen alten Features erleben, die in Archiven verrotten. LG --PerfektesChaos 18:01, 2. Nov. 2017 (CET)

Ach ja, aber es wäre halt schöner wenn die gar nicht erst auftauchen würden, ich schrieb es schon einmal irgendwo, kann man nicht alles was irgendwie Archiv im Namen trägt ausblenden, dann sähen die Zahlen in den Listen weit freundlicher aus. Na ich hoffe mal das der Kaktus wenigstens etwas positives vewirken kann. Einen schönen Abend noch. --Liebe Grüße, Lómelinde Diskussion 18:15, 2. Nov. 2017 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Lómelinde 06:59, 29. Dez. 2017 (CET)

Fehlerhafte Dateioptionen

Ich habe den Artikelsnamensraum nun einmal komplett durch. Jetzt sind nur noch die Fälle übrig, wo genau eine Pipe zuviel ist, und ein paar Sonderfälle, bei denen ich nicht weiterkomme. Andim (Diskussion) 11:10, 11. Nov. 2017 (CET)

Helau; erstmal schönen Dank, du fleißiges Bienchen.

Ich habe deinem Wirken interessiert zugesehn; einige Male kam ich eine halbe Stunde nach dir, und guckte stumm auf dem leeren Tisch herum.

Die Pipes tun keinem weh; die kann WSTM im Lauf der Zeit automatisch mit abräumen – angemeldete Benutzer bekommen Zoff mit den Autoren für Mikro-Edits.

Die Spezialfälle sind teilweise recht knifflig, ich war auch schon an einigen und hatte sie nicht auf Anhieb geknackt bekommen. Heute tanz ich eher Stippeföttche, als dass ich mich noch auf intensive Denkarbeit einlassen werd.

LG --PerfektesChaos 11:17, 11. Nov. 2017 (CET)

Ich liebe kniffelige Fälle, die sind aber zumeist gar nicht so kompliziert, wenn man den Auslöser erst einmal gefunden hat. Ich hatte mich schon gewundert wer da am Werk war, da ich alle Zahlen beobachte war das fast die einzige Liste, wo die Zahlen stetig runter und nicht rauf gehen. Vielen Dank.

Beispielsweise der Parameter Ziel= in Länderflaggen, wenn es nicht, wie es der Parameter erwartet identisch sondern Linkziel + {{!}} Linkiname gesetzt wurde. {{ARG|Ziel=Francisco Aguirre (Fußballspieler, 1977){{!}}Francisco Aguirre}} sollte sein →Argentinien Francisco Aguirre Es hatte etwas gedauert bis ich das verstanden hatte, aber das {{!}} machte mich etwas stutzig. --Liebe Grüße, Lómelinde Diskussion 12:29, 11. Nov. 2017 (CET)

@PC, WSTM kann nicht alles lösen. Jõhvi (Stadt) hat auch ein Leerzeichen.

{{Infobox Ort in Estland
  |Karte                = Johvi location.png
  |Kartenbreite         = 
  |Beschriftung         = 
}}

Wird wohl so ähnlich sein wie neulich bei den Infoboxen mit den hochrangigen Straßen, an denen ich beinahe verzweifelt wäre. --Liebe Grüße, Lómelinde Diskussion 17:56, 11. Nov. 2017 (CET)

Die fehlende Kartenbreite wird nicht richtig behandelt und es wird

[[Datei:Johvi location.png|frameless||Karte von Estland, Position von Jõhvi (Stadt) hervorgehoben]]

erzeugt. Andim (Diskussion) 18:08, 11. Nov. 2017 (CET)

Auch die Vorlage BS-daten zeigt dieses Verhalten, Andim (Diskussion) 18:13, 11. Nov. 2017 (CET)

Mmmh, hatte schon mal ein halbes Dutzend mit Kartenbreite umgebaut, aber längst vergessen wie das war. Heute nicht mehr.

{{#invoke:FileMedia|setParSize|{{{Kartenbreite|260px}}}}}

LG --PerfektesChaos 18:17, 11. Nov. 2017 (CET)

Hast Recht, heute nicht mehr. :-) Ich wünsche euch einen angenehmen Abend. --Liebe Grüße, Lómelinde Diskussion 18:40, 11. Nov. 2017 (CET)

A Ruah is. LG --PerfektesChaos 22:37, 11. Nov. 2017 (CET)

Ich drehe echt noch durch mit diesen Infoboxen, was ist denn da nun wieder falsch??? Geh mal mit der Maus auf das Logo, da hast du schon invoked und nun steht im Tooltip frameless zudem lässt sich die Größe nicht ändern. Wenn Größenangabe dann keine Fehlermeldung und kein frameless im Tooltip.

Bitte Dokumentation konsultieren
Größe wird nicht verändert das sind keine 500px
Austragungsort

{{Infobox Handballturnier
|bild = Handball-Weltmeisterschaft der Herren 2005 Logo.jpg
|bildgroesse =500px
|bildunterschrift = finales Logo
}}

wenn keine Angabe zur Größenänderung dann Originalgröße aber Fehler und frameless im Tooltip.

{{Infobox Handballturnier
|bild = Handball-WM der Frauen 2013.png
|bildgroesse =
|bildunterschrift = Logo der 21. Handball-Weltmeisterschaft der Frauen
}}

Ich werde diese Einbindung nie verstehen. Die Pipes zu den px- oder Tooltip-Legenden-Angaben müssten mit dem Parameter Bildgröße/Beschreibung erzeugt werden, wenn nicht dann auch {{:KeinPipe}} nada nichts absolutly nothing

* {{#if: {{{Bildgröße|}}} | {{!}}{{{Bildgröße|250px}}} | <noinclude>nada nichts absolutly nothing</noinclude> }}
* {{#if: {{{Bildgröße|}}} | {{!}}{{{Bildgröße|}}} | {{!}}300px}}

Logo Logo Datei:Handball-WM der Frauen 2013.png Datei:Handball-WM der Frauen 2013.png

Frauenlogik --Liebe Grüße, Lómelinde Diskussion 08:26, 12. Nov. 2017 (CET)

Die setParSize macht in etwa das, was du beschrieben hast, nur robuster.

Handball macht mit einer seltsamen und womöglich unseriösen Konstruktion rum, die ich noch nie gesehen habe, nämlich 0px.

Ich folge gerade deiner Anregung und führe einen Pipe-Parameter bei setParSize ein, der ggf. die Pipe mit generiert und ansonsten den Wert komplett weglässt.

Die Infobox habe ich nachgerüstet; jetzt zufriedener?

LG --PerfektesChaos 12:42, 12. Nov. 2017 (CET)

Ja jetzt sieht es besser aus. Dankeschön. Nur das mit der Größe scheint nicht zu funktionieren, falls man in dem anderen Beispiel aus der Vorlagendoku den Wert auf 500px setzt wird es nicht 500px breit. Auch die Frauen-WM möchte nicht über die Originalgröße hinaus beeinflusst werden. Merkwürdig ist das schon. Liegt aber wohl am frameless, als wenn es nicht auch so schon verwirrend wäre. Das bedeutet im Umkehrschluss, wenn ich ein Logo der Originalgröße 20px hätte könnte ich es (in der Infobox) nie größer als 20px ausgeben. Ich bin echt heute völlig verwirrt. --Liebe Grüße, Lómelinde Diskussion 13:13, 12. Nov. 2017 (CET)

Muttu Perhelion fragen.

• Ggf. muss H:B klarer formuliert werden.
• Beliebig skaliert werden können wohl nur SVG; alle anderen werden nur kleiner.
• frameless hat anscheinend einen Einfluss; mit ohne geht größer.

Vorlagenexpansion liefert:
[[Datei:Handball-Weltmeisterschaft der Herren 2005 Logo.jpg|frameless|500px|finales Logo]]

LG --PerfektesChaos 13:29, 12. Nov. 2017 (CET)

Nö egal, habbich morgen schon wieder vergessen. Ist nicht meine Box. --Liebe Grüße, Lómelinde Diskussion 13:48, 12. Nov. 2017 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Lómelinde 06:59, 29. Dez. 2017 (CET)

Thank you, and next steps re: Tidy fixes

Hi everyone,

in July 2017, we announced that we intend to replace Tidy with RemexHTML across the Wikimedia cluster by July 2018. In order to make this switch, we identified a number of broken wikitext patterns that required fixing on wikis, highlighted via the high priority categories in the Linter extension.

I would like to acknowledge the fast, important progress that volunteers at this wiki have achieved with the fixes related to the Tidy parsing library replacement.

Almost all of the relevant issues in the Article (main) namespace have been fixed in just a few months: this is a remarkable result, and on behalf of the Parsing team, I would like to thank everyone who made this possible here.

(Lómelinde, PerfektesChaos: congratulations on the guide as well. It looks so comprehensive.)

We plan to finish turning off Tidy in July 2018, and doing early switches of wikis from Tidy to Remex will let us identify any lingering issues that are not already caught by the linter categories and our QA testing. We are encouraging big wikis that have worked hard to switch soon.

Looking at the current scale of high priority linter issues, we think that this wiki is ready to switch from Tidy to Remex. To be clear, if we notice problems (or if the wiki requests it), we will revert the change, after identifying the source of the problem. If you notice any incorrect rendering, you can use ?action=parsermigration-edit to identify if the switch from Tidy actually caused it.

We are suggesting 5 December 2017 as the possible date for the switch to happen (so there would still be plenty of time to fix any issues before the holidays start). We look forward to hearing any concerns you would have with this, and about how we can help make this transition as smooth as possible.

Best, Elitre (WMF) (Diskussion) 19:21, 16. Nov. 2017 (CET)

Reciprocal thx.

Technically, I have no objections regarding a shift to Remex at any time.

However, this is just a guide for editors regarding particular syntax expressions. Project management is discussed at WD:NEU #Tidy-ex.

Greetings --PerfektesChaos 01:24, 17. Nov. 2017 (CET)

Nicht geschlossene Anführungszeichen

Auch geschlossene Anführungszeichen führen zu Fehlern. Auf Benutzer:HelfenGKS/Spielwiese ist in der ersten Überschrift die Fettschrift korrekt geschlossen, trotzdem ist der ganze Text danach fett. Auf der Seite befindet sich zwar auch eine nicht geschlossene Formatierung, aber erst ganz am Ende, das dürfte keinen Effekt haben. 129.13.72.197 09:48, 15. Dez. 2017 (CET)

Die nicht geschlossenen Anführungszeichen stehen in == '''Weblinks== und die steht im Inhaltsverzeichnis und deshalb steht alles ab dem Inhaltsverzeichnis in Fettschrift; völlig egal was == Entstehung == machen würde.

VG --PerfektesChaos 09:58, 15. Dez. 2017 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Lómelinde 06:59, 29. Dez. 2017 (CET)

Bot-Aufgabe ?

Das wäre imho eine Botaufgabe, jenes wohl auch. 92.75.111.186 20:01, 15. Dez. 2017 (CET)

Zu deiner Änderung, kommt diese Anordnung mehr als einmal auf einer Seite vor, so …

… <small>antwortet selten,[[Benutzer Diskussion:BerlinerSchule| schreibste hier.</small>]]
… <small>antwortet selten,[[Benutzer Diskussion:BerlinerSchule| schreibste hier.</small>]]

… wird es der Liste verzeichnet und löst für jeden einzelnen Aufruf zudem ein fehlendes End-tag aus

Eine einzelne Einbindung auf einer Seite hingegen …

… <small>antwortet selten,[[Benutzer Diskussion:BerlinerSchule| schreibste hier.</small>]]

… löst keinen Fehler in dieser Liste aus. Da sie sich explizit auf mehrere small- oder big-tags auf einer Seite bezieht. Dies löst nur ein fehlendes End-tag aus.

Daher bitte nicht die Meldungen (Listen) durcheinander werfen. Man könnte es höchstens als weiteres Beispiel mit einfügen.

Ich frage dort lieber nicht mehr. --Liebe Grüße, Lómelinde Diskussion 07:23, 16. Dez. 2017 (CET)

Warum nicht? Willst du es lieber von Hand korrigieren? 92.75.111.186 11:17, 16. Dez. 2017 (CET)

Zur Bot-Frage:

• Das sind Diskussionsseiten und vergleichbare.
• Auf denen wird nichts in großem Stil rumkorrigiert.
• Soweit ich sehen kann, hat der fragliche Syntaxfehler in der Signatur keine Auswirkungen auf den Rest der Seite und nachfolgende Diskussionsbeiträge.
• Man wird sich verdammtnochmal an die Vorstellung gewöhnen müssen, dass wir aus den ersten 15 Jahren einen Schrotthaufen kaputter Diskussions- und Benutzerseiten mitschleppen, in denen syntaktisch falsche Signaturen, kaputte Toolserver-Links, gelöschte Vorlagen und Bilder, vermurkste Tabellen, defekte Weblinks und sonstwas verrottet.
• Unsere Aufgabe sind der ANR – außerdem aktive Projektseiten und Portale. Damit kommen wir schon kaum hinterher.
• Jetzt noch zigtausende von Bot-Reparaturen für Hunderte versemmelter Signaturen liegen völlig außerhalb der Kapazitäten und sind auch gaga pur.
• Maximal könnte man aktive Benutzer über kaputte Signaturen informieren. Benutzer:BerlinerSchule ist jedoch im Mai verstorben und damit diese Angelegenheit erledigt.

VG --PerfektesChaos 15:41, 16. Dez. 2017 (CET)

Man muss sich an gar nichts gewöhnen. Insbesondere wenn ein fehlendes schließendes Durchstreichen-Tag fehlt und große Teile einer Seite gar nicht lesbar sind oder durch mehrere offene small-Tags der Text unleserlich klein ist wäre es absurd zu sagen "nö, das wird nicht mehr korrigiert". Im Übrigen zähle ich Artikeldiskussionsseiten durchaus zu "aktiven Projektseiten". 129.13.72.197 09:47, 19. Dez. 2017 (CET)

Na immerhin, in soweit sind wir uns einig, ich würde auch lieber alle Fehler bereinigt sehen. Kann aber auch die Argumentation nachvollziehen, es gibt zunächst wichtigeres. Archivseiten könnte man ignorieren, wäre schön wenn die insgesamt aus den Listen herausgestrichen würden, da das den Arbeitsumfang erheblich verringern würde. Um alte Meinungsbilder, Abstimmungen oder gesperrte Seiten mögen sich die Admins kümmern (wird kaum passieren).

Zu deiner Frage, nein ich würde es nicht gern alles einzeln anpassen, allein schon deshalb nicht, weil es Gefahren mit sich bringt, die ich lieber vermeiden sollte. (Da manipuliert jemand Signaturen en mass) Kann ich mir nicht leisten. Die letzte Anfrage nach einer für mich eher harmlosen Ersetzung verlief erfolglos, wenn es also nicht erwünscht ist, dann frage ich auch nicht mehr. --Liebe Grüße, Lómelinde Diskussion 10:16, 19. Dez. 2017 (CET)

In Benutzer- und Diskussionsseiten steht tausenderlei zusmmengehauener Murks.

Jeder Beitrag steht unter der persönlichen Verantwortung des einstellenden Benutzers.

Niemand ist befugt, an den persönlichen Ausdrucksformen großartig nachträglich herumzukorrigieren, wenn es keine triftigen Gründe gibt.

Abgesehen von PA-Entfernung wäre, wie ich oben bereits schrieb, wenn der „fragliche Syntaxfehler in der Signatur keine Auswirkungen auf den Rest der Seite und nachfolgende Diskussionsbeiträge“ hat, auch keine Grundlage für die Veränderung fremder Beiträge gegeben.

Nein; wir polieren nicht jedes hingerotzte Gequatsche und jede jahrelang vergeigte Signatur nachträglich zum enzyklopädisch wertvollen Inhalt auf. Jeder, der auf Benutzer- und Diskussionsseiten schreibt, hat selbst die Gelegenheit, sein eigenes Zeug zu korrigieren. Wenn das nicht genutzt wird, bleibt es eben so.

VG --PerfektesChaos 10:21, 19. Dez. 2017 (CET)

Du siehst doch aber, dass es bereits zu Anfragen kommt. Wikipedia:Fragen zur Wikipedia#Mikroschrift. Aber mir soll es egal sein. Beta wird übrigens gerade von den Technikern bestreikt. Sie mag mich nicht „Die Datenbank wurde für Wartungsarbeiten gesperrt“. Nachdem sie gestern schon die Versionen nicht mehr lesen konnte. --Liebe Grüße, Lómelinde Diskussion 10:34, 19. Dez. 2017 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Lómelinde 06:59, 29. Dez. 2017 (CET)

Vorlage AUT

Ist [1] korrekt? Es werden nun einige Dateioptionsfehler angezeigt. Andim (Diskussion) 10:29, 22. Dez. 2017 (CET)

Erst jetzt, oder war das auch schon zuvor in der Liste? Ich sehe da zumindest andere Fehler, 2 × ein nicht geschlossenes kursiv. Ich schaue mal kurz ob ich etwas sehe. Zumindest scheint die Zahl der Listeneinträge nicht enorm angestiegen zu sein. --Liebe Grüße, Lómelinde Diskussion 10:47, 22. Dez. 2017 (CET)

→Hilfe:Bilder#noviewer sollte eigentlich o.k. sein. --Liebe Grüße, Lómelinde Diskussion 10:54, 22. Dez. 2017 (CET)

Auf den ersten Blick scheint auch mir die Änderung korrekt zu sein. Nur haben wir in der Liste der fehlerhaften Dateioptionen nun einige Fehler durch die Vorlage AUT. An den Artikeln wurde in letzter Zeit nichts geändert, z.B. Alpiner Skiweltcup 1998/99, letzte Änderung am 3. November 2017. Andim (Diskussion) 11:00, 22. Dez. 2017 (CET)

Scheinen aber o.k. zu sein, purge mal eine. --Liebe Grüße, Lómelinde Diskussion 11:21, 22. Dez. 2017 (CET)

Nulledit hilft, Andim (Diskussion) 11:31, 22. Dez. 2017 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Lómelinde 06:59, 29. Dez. 2017 (CET)

Sollten wir ein Erledigt-Archiv hier einfügen?

Ich mag es nicht so sehr wenn man nicht erkennen kann was noch akut ist oder eher nicht.

OT: @IP, du könntest dich doch um die sichtbaren Fehler kümmern, so etwas, wo halbe Seiten durchgestrichen oder fett sind. Dagegen können doch die Kritiker an deinen Anpassungen wirklich nichts haben, denn das sind ja Dinge, die eher abschreckend wirken und die zudem in ihrer Auswirkung deutlich als fehlerhaft sichtbar sind. Die Meldung hättest du besser vermeiden sollen, was hast du eigentlich erwartet? Versuch doch einfach zumindest im ANR wirklich mehr als nur den Linterfehler anzupassen, damit da nicht immer nach Korrektoren und unnötiger Kleinkram, Kinkerlitzchen etc. gerufen wird. So etwas meine ich Portal Diskussion:Fußball/Archiv/2017/Juli. Ich konnte leider nicht diese zurückgesetzten Edits alle wieder revertieren, die Gefahr war mir zu groß, und auf meine Nachfrage bei dem Benutzer kam leider keine Antwort. --Liebe Grüße, Lómelinde Diskussion 15:27, 23. Dez. 2017 (CET)

Betreffend Archivierung: Ja, klar, „Erledigt“,7 Tage.

Betreffend KÄ: Meine Rede.

LG --PerfektesChaos 01:01, 29. Dez. 2017 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Lómelinde 06:59, 29. Dez. 2017 (CET)

Klappfunktion der Listenauswahl

alle Spezielseite kel) N alles ab hier nach oben ist inaktiv Diskussion Benutzer Benutzer Diskussion alle

Ich war ja ein paar Tage anderweitig beschäftigt, aber mir ist aufgefallen, dass seit Kurzem? die Auswahl für die Namensräume nach oben ausklappt, wenn man die Seiten aufruft. An und für sich ist das ja auch o.k., nur steht der obere Teil der Liste dann unterhalb des Reiters für den Seitennamen sprich Spezialseite. Dadurch lässt sich nun beispielsweise der direkt darunter verborgene Namensraum Artikel, den ich für besonders wichtig halte, nicht auswählen, weil etwas darüber liegt und das verhindert. Mit etwas Scrollerei auf der Seite kann man zwar der Auswahlkasten so manipulieren, dass er dann nach unten klappt und man alle Auswahlpunkte erreichen kann, aber das scheint mir ja irgendwie nicht im Sinne des Erfinders zu sein. Zumal der Pfeil ja auch nach unten deutet, aber das wäre nebensächlich. (mobil klappt es immer nach unten, denke ich) --Liebe Grüße, Lómelinde Diskussion 10:53, 15. Dez. 2017 (CET)

Er klappt nur dann nach oben, wenn die Fehlerliste wenig Einträge hat und die Seite somit nicht sehr lang ist. Ist im Prinzip das gleiche Verhalten wie bei einem Rechtklick in Windows. Wenn du den am unteren Bildschirmrand machst, geht das Kontextmenü auch nach oben auf. 129.13.72.197 11:02, 15. Dez. 2017 (CET)

@Schnark, Elitre (WMF): It is bad programming in oo-ui-menuSelectWidget and MW page interaction.

• See Special:LintErrors/multiline-html-table-in-list.
• The OO-UI element is MW homebrew, not an HTML <select>.
• As long page is in loading process, select element is operational.
• When JS execution has been finished, Vector equipment is running over OO-UI select element. Traditional HTML would not. Vector bar is layer above OO-UI. Race condition might occur.

@Ló: Help page on front side provides direct links to all artcle categories.

Enjoy --PerfektesChaos 11:35, 15. Dez. 2017 (CET)

(Is the ping meant as an FYI or would you like me to help with something here? Thanks. Elitre (WMF) (Diskussion) 11:47, 15. Dez. 2017 (CET))

Ich weiß, wie ich die aufrufen kann, es ging nicht um mich. :-) Und es betrifft ja auch alles was man nach oben durchscrollt, das wird unerreichbar, bei meiner Bildschirmeinstellung halt gerade ab Artikel, es kann aber auch mehr oder weniger problemlos sein. @Elitre (WMF) please fix it, this might not be correct and is not comfortable to use. --Liebe Grüße, Lómelinde Diskussion 12:01, 15. Dez. 2017 (CET)

Oh, the things I would fix if I only knew how :D I filed phab:T182999, which anyone can add to. Best, Elitre (WMF) (Diskussion) 17:45, 15. Dez. 2017 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: --Lómelinde 08:59, 18. Jan. 2018 (CET)

Ref-name-in-Poem-Problematik

Mehrere Fälle von angeblich verwendetem veraltetem tt-Tag

• Georgij Wladimirowitsch Iwanow

<poem style="margin-left:2em;">
Es ist mir nicht mehr zum Fürchten. Es ist mir träumerisch zumute.
Ich fliege langsam in den Abgrund
An euer Russland erinnere ich mich nicht
Und möchte mich gar nicht erinnern.
[…]
…Ich sehe von der Bühne zum Parkett
Ein Leuchten… Giselle… Wolken…
Die Einschiffung nach Insel Kythera,
Wo auf uns die Tscheka wartet.<ref name="Poem" /><ref>Georgij Iwanow: ''„Mne bolsche ne straschno. Mne tomno.“'' In: Andrej Arjew: ''Georgij Iwanow. Stichotworenija.'' St. Peterburg 2010, S. 316, Kommentar S. 651. (Arjew weist darauf hin, dass der zweite Kythera-Band eindeutig inhaltlich auf Charles Baudelaires Gedicht ''„Un voyage à Cythère“'' hinweist). </ref>
</poem>
Bereits verwendetes Ref-tag irgendwo im Text
<ref name="Poem"> Übertragen v. T. Senn. In: Tatjana Senn: ''Georgij Ivanov. Die russischen Jahre im literarischen und historischen Kontext''. München 2013, S.&nbsp;383–483.</ref>

Auslöser hier ist das <ref name="Poem" />

• Agni Parthene

<poem style="margin-left:2em; float:left;">
;Wörtliche Übersetzung <ref name="Bachmaier" />

'''4. Strophe,'''
'''mittlerer Melodieteil:'''

Werte und makellose Tochter,
allheilige Herrin/Herrscherin,
Erhöre mich, Unbefleckte,
der ganzen Welt Herrin,
</poem>

Auslöser hier ist das <ref name="Bachmaier" />

Es hat schon einige Zeit gedauert, bis ich das erkannt habe, aber wie löst man dieses Problem? --Liebe Grüße, Lómelinde Diskussion 12:13, 21. Jan. 2018 (CET)

• Männer und Frauen passen einfach nicht zusammen. Ach ne, das war jemand anders. Ne, <poem> und <ref> passen einfach nicht zusammen.
• <poem> ist dafür gemacht, den reinen Text eines Gedichts usw. aufzunehmen, vielleicht mal was kursiv zu stellen oder zu verlinken, aber ist kein normaler Wikitext.
• Die Herkunftsangabe eines Textes gehört an den einleitenden, begleitenden Text außerhalb des <poem> und da ist dann auch Gelegenheit für <ref>.
• Erläuterungen von Wörtern gingen mit Vorlage:FNBox oder mit [[#AnmDingens|Dingens]] → {{Anker|AnmDingens}}.
  • Wenn dann damit erstmal aus dem <poem> raus, dann geht auch wieder <ref>.
• H:poem wäre ggf. auszubauen.

LG --PerfektesChaos 16:12, 21. Jan. 2018 (CET)

O.k. ich schaue mal, wie ich das in den Griff bekommen kann. Dankeschön. --Liebe Grüße, Lómelinde Diskussion 16:58, 21. Jan. 2018 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: --Lómelinde 10:34, 26. Jan. 2018 (CET)

Einrückung in einem bereits eingerückten Parameter

Vorgefunden hatte ich folgenden Ausgangscode:

: {{#if: {{{anmerkung|}}} | <div style="background:LemonChiffon">Anmerkung: {{{anmerkung|}}}</div> | Anmerkung: {{{anmerkung|}}} 
:&nbsp;}}

Ergibt eine eingerückte

Anmerkung: Text der Anmerkung

So noch nicht weiter problematisch, in der Anwendung jedoch fanden sich in dem Parameter anmerkung dann nochmals einrückende Doppelpunkte.

{{WLWcheckurl | id=  014071 | eingangvor= 2016-06-30 | seite= Baťův kanál | url= http://moravske-karpaty.cz/ote/38/3_prirodni_pomery_38.htm | returnurl=http://moravske-karpaty.cz/ote/38/3_prirodni_pomery_38.htm | urlstatus= 404 – requested resource could not be found – [] | archivstatus= 200 – standard response for successful HTTP requests – [] | anmerkung=  
:Archive.is first: https://archive.is/20120710212454/http://moravske-karpaty.cz/ote/38/3_prirodni_pomery_38.htm (200 – standard response for successful HTTP requests – [<Response [302]>]), }}

Das löste dann je einmal ignorierte Tags und fehlendes Endtag aus, wie bei dem Beispiel mit den Zitatvorlagen hinter Doppelpunkten. Es hat schon etwas gedauert bis mir das aufgefallen ist, dass bereits in der Vorlage eine Einrückung per Doppelpunkt stand.

Ich habe es mal so gelöst.

{{#if: {{{anmerkung|}}} | <div style="background:LemonChiffon;margin-left:1.6em;">Anmerkung:<nowiki />{{#if:trim|{{{anmerkung|}}}}}</div> | 
:&nbsp;}}

Mit Trimmung, weil ich nicht wusste, wie ich es sonst abfangen sollte. Es hat zumindest beide Listen um einige, ich schätzt je rund 500, Einträge reduziert. Ich weiß nur gerade nicht ob, und wenn ja, wie ich das vorne erklären soll. --Liebe Grüße, Lómelinde Diskussion 07:25, 6. Feb. 2018 (CET)

Spezialproblem etwas konfuser Vorlagenprogrammierung; damit nichts für den ANR und das breite Volk und somit nicht umseitig.

Wobei generell : * # ; zu Beginn eines Auswertungsblocks ihre Syntaxwirkung für Zeilenanfänge auslösen; und genau das scheint mir hier unbeabsichtigt passiert zu sein, ohne es aber im Detail analysiert zu haben.

LG --PerfektesChaos 12:11, 8. Feb. 2018 (CET)

O.k. reicht ja wenn es hier steht. --Liebe Grüße, Lómelinde Diskussion 14:28, 8. Feb. 2018 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: --Lómelinde 16:43, 20. Jan. 2021 (CET)

Ungenauigkeit in den Listen

Mir ist jetzt seit einiger Zeit aufgefallen, dass die Angaben zu den Einträgen keine verlässlichen Zahlen mehr bereitstellen, aktuell hängt die Anzeige seit rund zwei Tagen fest (gemeint ist, dass erledigte Einträge nicht mehr aus den Listen gelöscht werden, Beispiel: 2 × Konsonanz und Dissonanz DIV erl. 2. März der Server sagt aber noch immer 2 ignorierte Tags). Kann man da etwas anschieben???

Was ich aber eigentlich meine sind eher die merkwürdigen Sprünge insbesondere bei der niedrigen Priorität. Teilweise werfen die oberen beiden identische Zahlen aus, ehe sie sich beim nächsten Aufruf dann wieder auseinanderdividieren und unterschiedliche Werte ausgeben. So weiß man nie welche Zahl aktuell wirklich stimmt.

heute Fehlendes End-Tag (250.594 Fehler) + 5.616 Veraltete HTML-Tags (286.060 Fehler) - 9.581 Ignorierte Tags (90.270 Fehler) + 8.172

gestern Fehlendes End-Tag (244.978 Fehler) - 5.448 Veraltete HTML-Tags (295.641 Fehler) + 9.388 Ignorierte Tags (82.098 Fehler) - 8.282

vorgestern Fehlendes End-Tag (250.426 Fehler) + 6.412 Veraltete HTML-Tags (286.253 Fehler) - 9.842 Ignorierte Tags (90.380 Fehler) + 8.094

Auffällig springt auch der Wert für HTML5/HTML4 oder bei falsch verschachtelten oder ignorierten Tags

heute (tatsächliche Anzahl grün ) (8.840 Fehler) HTML4/5 →4.420 (70.832 Fehler) Falsch verschachtelte Tags →35.416 (90.270 Fehler) Ignorierte Tags →45.135

letzte Woche (4.441 Fehler) für 3 Tage nur halb so viele Einträge zwischen (67.764 Fehler) und (58.304 Fehler) schwankend (91.660 Fehler)

die größeren Zahlen sind immer gradzahlig und derzeit nahezu doppelt so hoch davor lange Zeit von 4.500 → 4.452 dann ein Sprung auf 9.018 → steigend 9.044 davor lange Zeit von 33.800 → 33.463 dann ein Sprung auf 58.814 → steigend 71.202 davor lange Zeit von 47.329 → 42.323 dann ein Sprung auf 78.374 → steigend 91.436

Irgendwie ist das frustrierend, man kann den Fortschritt nicht mehr ablesen. --Liebe Grüße, Lómelinde Diskussion 09:28, 5. Mär. 2018 (CET)

Mir ist das auch schon aufgefallen, weder Purge noch Nulledit helfen. Andim (Diskussion) 11:55, 5. Mär. 2018 (CET)

Einfach ignorieren; überwiegend sind das Phantome. Plötzlich sind dann 10.000 auf einen Schlag verschwunden.

Richtig ist die Beobachtung, dass aus Performance-Gründen die Zählung betreffend der vielen unwichtigen nur alle paar Tage aktualisiert wird; die wichtigen Sachen hingegen kontinuierlich.

Kann auch gut sein, dass gerade doppelt gezählt wird; das gibt sich wieder. Nicht dauernd auf die Zahlen starren.

LG --PerfektesChaos 21:45, 5. Mär. 2018 (CET)

Na doch ich schreibe die doch mit damit ich sehe, ob es irgendwo einen plötzlichen Anstieg gab, der möglicherweise durch eine einzelne Änderung hervorgerufen wurde. Aber bei derartigen Schwankungen ist das unmöglich. Manchmal ist es simpel ein Verteiler, also Vorlage Beteiligen oder so etwas, wo ein small am Ende fehlt, das lässt sich dann schnell beheben. --Liebe Grüße, Lómelinde Diskussion 06:12, 6. Mär. 2018 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: --Lómelinde 16:43, 20. Jan. 2021 (CET)

Anything you'd like to share?

Greetings, all! As you know, several other wikis are getting switched to Remex these days. It's possible that for a few very large ones the change will happen in a very last minute fashion :p I think we agree that switching early here was a good call, and that a combination of factors made it successful. We're particularly interested in hearing from you now about any kind of recommendations, advice etc. that you would like to offer to either us as we support the communities during the switch, or to community members who, like yourselves, may be willing to help with the necessary fixes. For example, is there anything that you wish you knew before starting to work on this project? Any documentation page that you know had a particularly positive impact? Any tool that saved the day? Any reminders that people like me forgot to send out? We would like to make the transition easier for as many communities as possible while at the same time highlighting your great efforts. Thanks a lot for your help! Myself and my colleague Benutzerin:Whatamidoing (WMF) are looking forward to hearing from you. Best, Elitre (WMF) (Diskussion) 14:41, 27. Apr. 2018 (CEST)

All I wish is more comprehension (by other users) more support (but nearly nobody wants to do such boring things). So much peope in this project don’t care about these errors. I would wish a bot will go over this font-bug-pages and change some deprecaded syntax like this

<font color=#33AA33>[http://de.wikinews.org/wiki/Hauptseite Wikinews]</font>
<font color=#ABDCEF>[[Benutzer:XYZ]]</font>

to

[http://de.wikinews.org/wiki/Hauptseite Wikinews]
[[Benutzer:XYZ]]

But I think it would be useless to ask for bots. It ist not easy to do this silly things, and who would like to spend time for it just a very few users do, do not ask why they do it. They must be ansolutely crazy. As you know … I do not know anything about „Remex“, all I hope is that there would be somehow a light at the end of this dark tunnel. --Liebe Grüße, Lómelinde Diskussion 15:36, 27. Apr. 2018 (CEST)

I collect some ideas.

• First of all: Define priorities!
  • Focus on main space, active project pages.
  • Focus on visible effects.
  • Forget about old HTML syntax.
  • Ignore archived talks.
  • If a user signature works design shortcomes by bad syntax are neglectable, as long the following text is not affected.
• Prepare policy and strategy.
  • Pages in user responsibility, stuff of particular groups, special maintainers.
  • Consider wikitext generated by bots and gadgets.
  • Ponder on bot usage for certain safe tasks.
  • Before switching get the major pages and dramatic changes completed, then just remove bugs caused by fresh edits.
• Knowing that and good help pages in own language is sufficient.
  • We created our helpers ahead of WMF.
  • Copying and translating the front page here is for free.
  • Establish MediaWiki:linterrors-summary context sensitive links.
• Tools:
  • Use lintHint.
  • lintHint would like the API to answer on page name only rather than being limited to source analysis, collecting the entire source by client first.
  • Counts per namespace and type rather than overall figures on statistical overview would be useful.
  • Filtering or sorting per error details per error type per namespace would be helpful to remedy similar problems in consecutive order.

Have a nice weekend --PerfektesChaos 15:49, 27. Apr. 2018 (CEST)

Thanks all, this was insightful. Will share with the colleagues that need such analysis. Danke, and talk to you soon! Elitre (WMF) (Diskussion) 15:05, 2. Mai 2018 (CEST)

You’re welcome. --PerfektesChaos 15:38, 2. Mai 2018 (CEST)

Oh, re #2 for lintHint, Subbu lets me know it's done: https://en.wikipedia.org/api/rest_v1/#!/Page_content/get_page_lint_title_revision .Elitre (WMF) (Diskussion) 16:06, 2. Mai 2018 (CEST)

Lómelinde, I like your idea about removing font tags entirely. It might be feasible as a quick-fix. This change from Tidy to Remex was accidentally made at enwiki last week (just for a few hours, until the devs found the problem and fixed it), and all of the complaints were about talk-page signatures. Bad signatures/fancy formatting "leaked" all over the rest of the page. Whatamidoing (WMF) (Diskussion) 18:29, 2. Mai 2018 (CEST)

It would be helpful, so much of these errors are comming just form users signatures in archives or on talkpages many thousands in this project. In articles you will find very few uses of the fonttag. --Liebe Grüße, Lómelinde Diskussion 18:37, 2. Mai 2018 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Lómelinde 16:43, 20. Jan. 2021 (CET)

Nur mal zum Anschauen

Fettung in der Einleitung Fehler

• Spezial:LintErrors/html5-misnesting span
• Spezial:LintErrors/stripped-tag SPAN

Das hat mich gerade total verwirrt so dass sogar mein Bearbeitungskommentar jetzt unpassend war weil ich fett sagte und nicht span und fehlendes Ende statt ignoriertes Tag. Das ist schon sehr ungewöhnlich. Denn scheinbar wird dann das vordere fett nicht gesehen, erwartet hätte ich als Anzeige eigentlich
Exsudation (lateinisch exsudare, „ausschwitzen“, „abfließen“; englisch "exudation"), gelegentlich auch Wurzelexudation' bezeichnet

Ich muss das nicht verstehen, wenn man davor Zeichen einfügen würde wäre es jedenfalls auch fett, also nochmal anders als in der Fehlerhaften Version.
Ausgabe im Artikel:

• 'Exsudation (lateinisch exsudare, „ausschwitzen“, „abfließen“; englisch "exudation"), gelegentlich auch Wurzelexudation bezeichnet

Mit Text davor wäre es so dargestellt worden:

• Die Exsudation' (lateinisch exsudare, „ausschwitzen“, „abfließen“; englisch "exudation"), gelegentlich auch Wurzelexudation bezeichnet

Nur weil ich so etwas vorher noch nicht hatte. --Liebe Grüße, Lómelinde Diskussion 17:22, 28. Jun. 2018 (CEST)

Lohnt kein großes Koppmachen; das dritte ' nach Wurzelexudation war halt zu viel, und der Parser wusste nicht, wohin mit all denen. LG --PerfektesChaos 17:26, 28. Jun. 2018 (CEST)

Na, mich hat es total aus der Bahn geworfen. Und es ist ja auch nur zum Anschauen, falls jemand mal so einen Fall haben sollte. --Liebe Grüße, Lómelinde Diskussion 17:42, 28. Jun. 2018 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Lómelinde 16:43, 20. Jan. 2021 (CET)

Nur mal so wohin die Reise geht

Gemeldet in Phabricator
Task T37704

Auf lange Sicht soll CSS aus der allg. Wiki-Syntax (Artikel-NR) verschwinden. Was angesichts der Web-Entwicklung von HTML-Tags → CSS evtl. problematisch bzw. auf mehr Templates hinauslaufen wird. Daher sollten wir diese Richtung schon mal als allg. Empfehlung aufnehmen!? MfG -- User: Perhelion 13:41, 8. Aug. 2018 (CEST)

Du bist echt süß, du weißt doch, dass ich da nun rein gar nicht verstehe was dort steht, worum es dort geht oder was das konkret für mich bedeutet. Ich verstehe nicht einmel den Satz den du hier hingeschrieben hast. --Liebe Grüße, Lómelinde Diskussion 14:12, 8. Aug. 2018 (CEST)

Uraltes Märchen und theoretisierendes Geschwafel, das nicht in die Praxis umsetzbar ist.

Wolkenkuckucksheimerei; dazu müssten zunächst nur in der enWP Tausende von Klassendefinitionen mit TemplateStyles konzipiert und geschaffen werden, und danach vielfach in Millionen von Artikeln eingebaut werden, von deren restlichen Projektseiten mal abgesehen. Dazu gibt es weder eine technische Notwendigkeit noch auch nur ansatzweise eine Aussicht auf Umsetzbarkeit.

Trotz Vorlagenverliebtheit und massivem Bot-Einsatz – die enWP bekommt ja auch nach einem Jahr noch nicht mal gerades HTML in deren ANR auf die Reihe, da sollten die Protagonisten besser hübsch die Klappe halten.

Für die anderen Wikis und extern wäre ein Zwang zur reinen Verwendung von Klassendefinitionen katastrophal und schlicht nicht zu leisten, und es gibt auch keinerlei sachlichen Grund dafür, außer dem dummen Geschwätz von Akademikern mit fünf Webseiten und drei Tabellen.

VG --PerfektesChaos 16:28, 8. Aug. 2018 (CEST)

Ja, beim ersten Erblicken dieses Tasks, war "absurde Utopie" auch mein Gedanke (wie am Dislike-Daumen zu sehen). Was in 10 Jahren hier ist kann keiner sagen. PS: Allerdings kann man derart sinnreiche und weitreichende Ideen auf viele andere Tasks/Ideen "von" Wikimedia übertragen. -- User: Perhelion 17:24, 8. Aug. 2018 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Lómelinde 16:43, 20. Jan. 2021 (CET)

Warum erkennt die Analyse das font hier nicht?

In dem Artikel ist eine Galerie, die ein font enthält, weder LintHint noch die Linterliste sehen das scheinbar als falsch an.

• 
  Phtalocyanin (Aza[18]annulen)
• 
  C.I. Reactive Blue 7

Eigentlich müsste das hier einen Fehler veraltete Tags auslösen

(<font style="color:red">Aza[18]annulen</font>)

Alleinstehend, außerhalb der Galerie, würde es das auch. Ich habe es nur durch Zufall gefunden, weil ich nach <font …> gesucht habe. Was bringt die schönste Analyse, wenn so etwas unbemerkt neu hinzukommen kann. --Liebe Grüße, Lómelinde Diskussion 08:59, 6. Jan. 2019 (CET)

Ich vermute mal ins Blaue, dass das an der Extension liegt.

• Heißt: Alle Teile, die zu Extensionen gehören, werden zuerst aus dem Seitentext herausgeschnitten, und erst hinterher wieder in das fast fertige HTML-Dokument eingefügt.
• Dann müsste das mit <ref>-Bereichen genauso sein.
• Kannste ja mal auf der LintHint-Spezialseite rumprobieren.
• Alle Tags, die nicht HTML sondern MediaWiki sind, müssten sich genauso verhalten, sofern in ihrem Innern (zumindest teilweise) Wikitext möglich ist. nowiki und pre beispielsweise verhalten sich so; da ist das aber auch kein Wunder.
• Würde bedeuten, dass der Linter nur den Wikitext ohne Extensionen analysiert. Insofern seltsam, als Parsoid ja dann wieder über das Innere von Extensionen geht, und es dort auffallen müsste.

Wäre mir insgesamt neu.

Wenn das konkretisiert wird, müsste ich nach existierenden Phab-Berichten suchen, ansonsten einen neuen schreiben.

LG --PerfektesChaos 13:19, 6. Jan. 2019 (CET)

Oh, ich sehe gerade, es ist etwas anderes, das Phthalocyanin / Aza[18]annulen]]| habe ich glatt übersehen, unausgegorene Syntax --Liebe Grüße, Lómelinde Diskussion 13:56, 6. Jan. 2019 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: --Lómelinde 16:43, 20. Jan. 2021 (CET)

Dateifehler

→Benutzer:DrTrigonBot/Subster/Doku

1. Toolserver gibt es nicht mehr
2. ich wüsste nicht wie ich es repariert bekomme.

Daher traue ich mich da nicht dran. --Liebe Grüße, Lómelinde Diskussion 12:24, 29. Jan. 2019 (CET)

Das ist aus mehreren anderen Gründen eine tückische Angelegenheit.

Auch die nicht mehr funktionierenden URL sollten unverändert beibehalten werden, um nachfolgende Programmierer dies nachvollziehen zu lassen.

Es gibt leider nicht nur den Toolserver nicht mehr, sondern auch DrTrigon.

Lass die einfach drin, pfeif auf deine Nuller-Statistik. Wenn man die Spezialseite aufmacht, ist auf einen Blick zu sehen, dass dies etwas anderes ist.

LG --PerfektesChaos 15:42, 29. Jan. 2019 (CET)

Na gut, aber nur ungern. --Liebe Grüße, Lómelinde Diskussion 15:56, 29. Jan. 2019 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: --Lómelinde 16:43, 20. Jan. 2021 (CET)

kleinpx?

Folgende Angabe wird nicht als Linterfehler erkannt (Reconstruction →2014 eingefügt)

• [[Datei:Waud - 1867 - The First Vote.jpg|kleinpx|mini|Die „Reconstruction“ sorgte unter anderem für die Befreiung der Sklaven, sodass Afroamerikaner das Recht hatten, im Jahr 1867 zum ersten Mal zu wählen.]]
• Eigentlich wäre das doch eine quasi doppelte Bildlegende, daher meine Frage was ist das? Es kommt noch ein weiteres Mal in Panama#Eisenbahn vor. [[Datei:Panamanian Train.jpg|Kleinpx|mini|Das Innere eines Wagons der Panama Canal Railway Company]]

Eine Wirkung kann ich nicht erkennen. Hat jemand eine Idee was das sein könnte? --Liebe Grüße, Lómelinde Diskussion 07:53, 11. Nov. 2019 (CET)

Ich vermute mal, der aktuelle Parser nimmt alles, was hinten auf px endet, als Größenparameter.

Linter wird nur informiert wenn der Parser unzufrieden ist.

Es gibt auch seltsame Werte wie x100px oder 80x100px oder sowas. Ich vermute, die aktuelle Programmierung untersucht das an dieser Stelle (Parser) noch nicht genauer, und es stellt sich erst später heraus dass was nicht passt.

Du kannst ja mal spielen mit supercalifragilisticexpialigetischpx oder gross kleinpx und so.

WSTM will ein halbwegs korrektes Format sehen, korrigiert jedoch Leerzeichen zwischendrin.

LG --PerfektesChaos 12:36, 11. Nov. 2019 (CET)

Na ja, WSTM hat es ja auch erkannt, daher wunderte ich mich. Es hätte ja sein können, dass es irgendwo so ein Attribut gäbe, ich kenne ja nicht alles was möglich ist. --Liebe Grüße, Lómelinde Diskussion 13:59, 11. Nov. 2019 (CET)

Ich hab grade ein bisschen mit insource: rumgespielt und keine weiteren derartigen Aufälligkeiten gefunden. 147.142.76.43 14:16, 11. Nov. 2019 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: --Lómelinde 16:43, 20. Jan. 2021 (CET)

Altes Verhalten von Link-Wrapping Font-Tags

Spezial:LintErrors/tidy-font-bug Ich füge hier mal eine Tabelle ein, die nicht mehr korrekt dargestellte Signaturen und die Behebung der Fehler zeigt. --Liebe Grüße, Lómelinde Diskussion 16:37, 9. Feb. 2021 (CET)

Noch offen gesperrt oder VM-Seiten

• WPNR verbleiben 264
• Benutzer Diskussion verbleibend 43 gesperrt und 27 zu große Seiten

Für mich bleibt also noch viel übrig, schreibst Du in der ZuQ. Ich bin dran ... und melde mich wieder. – Doc Taxon • Disk. • 19:19, 23. Mär. 2021 (CET)

Noch etwas mehr als 300. cool wie du die anderen fonts reduziert hast. --Liebe Grüße, Lómelinde Diskussion 19:00, 24. Mär. 2021 (CET)

*selbstschulterklopf* – Doc Taxon • Disk. • 19:54, 24. Mär. 2021 (CET)

So mein Part in dieser Liste ist beendet. Es sind nur noch geschützte Seiten oder jene, die ich nicht bearbeiten möchte. Insgesamt sind es noch 307 zuzüglich des Problems mit den zu großen Seiten, die geteilt werden müssten. --Liebe Grüße, Lómelinde Diskussion 16:17, 25. Mär. 2021 (CET)

Ja, ich hab das schon auf dem Schirm und in den letzten zwei, drei Tagen sehr viel geschafft. Glückwunsch und auch ein dickes Danke zur Erledigung Deines Teils. Freundliche Grüße, – Doc Taxon • Disk. • 08:01, 26. Mär. 2021 (CET)

@Lómelinde: font color-Seiten haben im WNR innerhalb ein, zwei Tage um 1000 abgenommen. – Doc Taxon • Disk. • 12:05, 26. Mär. 2021 (CET)

Ich weiß, sogar weit mehr als 1000 eher 10.000, ich habe das im Blick, aber hier geht es ja um die restlichen Font-Bugs, da wo die Tags außen um Links stehen. Ich habe von den 70 oben Benutzer Diskussion (also eher von den 27, zu großen) eine Seite bereinigt indem ich das Archiv teilen durfte, dadurch sind das jetzt nur noch 15. Da wäre noch diese Disk Spezial:Diff/210162188/210225566 (13 Fehler), da kann ich nicht fragen, da der Benutzer scheinbar verstorben ist und das Schnabeltassentier, das auch schon ein Jahr inaktiv ist. --Liebe Grüße, Lómelinde Diskussion 12:13, 26. Mär. 2021 (CET)

@Lómelinde: was würde in diesem Fall passieren, wenn man die Seite einmal teilt und dann wieder zusammenfügt. Liebe Grüße, – Doc Taxon • Disk. • 12:46, 26. Mär. 2021 (CET)

Das weiß ich nicht, aber man müsste nach dem teilen dann beide Teile einzeln analysieren, die restlichen Fehler beheben und es würde für spätere Analysen dann wieder das selbige Problem entstehen. Die Seite ist schlich zu riesig. Ich weiß doch nicht wie die Softwaretechniker das analysieren und ab welchem Byte es zum overkill kommt. Was ich herausgefunden habe ist, dass teilen hilft. Mehr kann ich auch nicht sagen. --Liebe Grüße, Lómelinde Diskussion 12:50, 26. Mär. 2021 (CET)

@ Doc Taxon machst du noch mit, oder streikst du, weil ich keine FAQ-Seite schreiben möchte? --Liebe Grüße, Lómelinde Diskussion 10:19, 1. Apr. 2021 (CEST)

@Lómelinde: Ich muss MerlBot reparieren. Das dauert etwas ... – Doc Taxon • Disk. • 11:31, 1. Apr. 2021 (CEST)

Ach so, ich dachte schon es liegt an mir. --Liebe Grüße, Lómelinde Diskussion 11:33, 1. Apr. 2021 (CEST)

Probleme mit der Signatur ?

Ein Bot entfernte meinen Kommentar bei einer Nachsignatur mit der Begründung: Bot: Parameterkorrektur: Vorlage:Unsigniert ist ohne Signatur zu verwenden; diese aufgrund Problemen bezüglich H:LINT entfernt.
Ich stimme dem Bot zu und es steht auch so in der Doku:
Keine zusätzliche eigene Signatur
Um die Übersicht zu bewahren, sollte diese Vorlage nicht noch zusätzlich durch den Benutzer, der nachträglich signiert, unterschrieben werden. Diese Dopplung würde außerdem Probleme mit der automatischen Archivierung bereiten, da der Beitrag so neuer erscheint, als er eigentlich ist.
Nur handelt es sich um keine zusätzliche Signatur. Ich vermute, dass es der Link zu einer Benutzerseite ist, welche die Aufmerksamkeit des Bots auf sich gezogen hat. Meine Frage ist: ist das ebenfalls problematisch wie eine zusätzliche Signierung (das genannte Problem bei der Doku ist eher das Datum) oder handelt es sich hier um ein false positive und die Änderungen des Bots könnte einfach revertet werden. Grund meines dortigen Kommentars ist, dass auf der alten Benutzerseite kein Hinweis gibt, dass der Name geändert wurde bzw. das Konto wirklich mal existierte, wie ich es sonst kenne. Eventuell aus der alten Benutzerseite eine Weiterleitung erstellen ? --Anton Sachs (Diskussion) 00:47, 8. Mär. 2021 (CET)

Schreibe doch den Kommentar einfach hinter die Vorlage. Ich sehe aber auch nicht wirklich den Nutzen des Zusatzes. Zu der Zeit war das sein Benutzername. Es gibt Benutzer die sich ständig neue Aliasse zulegen, soll dann am Ende dort eine ganze Reihe hingeschrieben werden? Allerdings gebe ich dir Recht, es war als Parameter 3= gekennzeichnet und hätte eigentlich stehen bleiben sollen. Der Bot sollte eigentlich nur Signaturen aus dem Parameter 2= entfernen, in dem das Datum und die Uhrzeit des Beitrags stehen sollten. --Liebe Grüße, Lómelinde Diskussion 06:30, 8. Mär. 2021 (CET)

Hinter die Vorlage möchte ich nichts hinzufügen, da es technisch mal relevant sein könnte, dass ein Beitrag mit einer Signatur o.ä. endet (Ich las auch mal dazu etwas.) Nächster Punkt: Mir geht es nicht darum, eine Reihe verwendeter Benutzernamen anzufügen, sondern nur den, der damals verwendet wurde und eine Möglichkeit zur heutigen Benutzerseite zu gelangen. Das ist eigentlich kein Problem, da auch bei einer oder mehrerer Verschiebungen man sich noch »durchhangeln« könnte. Nur in dem Fall, wenn man auf den Namen klickt, sieht man keine Anzeichen, dass es den Benutzer überhaupt mal gegeben haben könnte. Selbst bei einem gesperrten Nutzer oder eine gelöschten Benutzerseite gibt es etwas zu sehen.

@Anton Sachs: Ja, genauso wie das Einfügen einer Signatur ist auch der Benutzerseitenlink problematisch und erscheint aber auch meiner Meinung nach wirklich als nicht notwendig. Bitte achte künftig darauf. Trotzdem vielen Dank für Deine Nachsignaturen. Liebe Grüße, – Doc Taxon • Disk. • 23:53, 15. Mär. 2021 (CET)

Wenn ich jetzt nach Lómelinde gehen würde, täte ich die Änderung des Bots reverten. Nach Doc würde ich eine Benutzerseite erzeugen mit einer Weiterleitung. Zumindest würde ich gerne irgendwie einen Link auf die Beiträge setzten können, die sich nun unter dieser URL befinden. Der automatisch erzeugte Link in der Vorlage führt zu einer Seite, die sagt, dass es den Nutzer nicht gibt. Den gibt es aber, nur unter einem neuen Namen. Versteht ihr jetzt meine Absichten ?--Anton Sachs (Diskussion) 21:29, 21. Mär. 2021 (CET)

@Anton Sachs: da der Benutzer umbenannt wurde, wurden auch seine Beiträge mit übernommen. Ersetze also in der Unsigniert-Vorlage den alten Benutzernamen mit dem neuen, und dann ist das erledigt. Liebe Grüße, – Doc Taxon • Disk. • 07:59, 26. Mär. 2021 (CET)

Ich hab die Nachsignatur jetzt manuell geschrieben, so dass ich keine Einschränkungen durch die Vorlage hatte und das an diesen Sonderfall anpassen konnte. Als Bonus gibt es ohne den Einsatz der Vorlage auch keinen Konflikt mit dem Bot. Von meiner Seite erledigt. --Anton Sachs (Diskussion) 08:03, 12. Jul. 2021 (CEST)

<tt>

Niemand wird hier so schnell konsequent <span style="font-family: monospace,monospace;"> schreiben, wenn <tt> viel kürzer ist. Hier von Autoren - die alle völlig freiwillig und ohne Bezüge von der Foundation schreiben - sowas zu verlangen, ist echt überheblich. Die Browser werden "tt" auch in zehn Jahren noch parsen können. ÅñŧóñŜûŝî (Ð) 21:57, 10. Apr. 2021 (CEST)

Ich zumindest mal verlange das nicht. – Doc Taxon • Disk. • 23:58, 10. Apr. 2021 (CEST)

@Doc Taxon: Ich finde es nicht so gut, wenn da einfach ein Bot drüberfährt, denn viel Fälle sind kurzer Code und dann ist das Code-Tag richtig. Bitte deinen TaxonBot nicht mehr darauf ansetzen. ÅñŧóñŜûŝî (Ð) 00:19, 11. Apr. 2021 (CEST)

Bei tt wäre umseitig vielleicht eher so was zu erwähnen: Wird durch deWP offiziell unterstützt (analog Wikiqote). Punkt. Alles andere verwirrt nur und führt zu unnötigen Botläufen, wie wir gerade gesehen haben. --Filzstift (Diskussion) 11:09, 11. Apr. 2021 (CEST)

Ich bin konsequent dagegen, <tt> durch einen expliziten Font zu ersetzen, da dies dazu führen kann, dass ein Artikel zwei unterschiedliche Fonts für monospaced-Text verwendet. Einen, der per CSS für <code> festgelegt ist, und dann halt den, der explizit über font-family: monospace angegeben ist. Das direkte style= lässt sich zudem nicht per CSS übersteuern. --RolandIllig (Diskussion) 21:41, 18. Mai 2021 (CEST)

<small>

@Doc Taxon: Hier gilt ähnliches wie beim TT: Viel zu aufwändig und es ist absolut unverantwortlich, das Tag durch einen festen Prozentsatz zu ersetzen und damit die benutzereigenen CSS-Einstellungen zu überschreiben. Bitte sofort damit aufhören!!! Es gibt Benutzer, welche für das Small-Tag eigene CSS-Angaben festgelegt haben. ÅñŧóñŜûŝî (Ð) 00:32, 11. Apr. 2021 (CEST)

Und dabei ist <small> noch nicht einmal von HTML missbilligt, nur <big>.

Siehe im Übrigen BD:Doc Taxon #tt-Replace.

VG --PerfektesChaos 00:35, 11. Apr. 2021 (CEST)

Schön, dass wir mal einer Meinung sind... Vorlage:Smiley/Wartung/;-) 

Ist denn ausgeschlossen, dass <big> nicht als WP-eigenes Feature weiterlebt? ÅñŧóñŜûŝî (Ð) 00:37, 11. Apr. 2021 (CEST)

Kann ich bei <big> nicht so genau sagen, weil auch nicht ganz klar ist, mit welchem Faktor es vergrößert werden sollte, und in welchen Fällen das überhaupt sinnvoll im Text zu verwenden wäre.

Oft geht es um nicht-lateinische Schriftzeichen, die aber sowieso über Vorlagen und lang-Attribute angesteuert werden, und wo das so wie bei uns etwa in Vorlage:heS #TemplateStyles projektweit geeignet und im Rahmen der umgebenden Zeilenhöhe dezent vergrößert wird.

Oder es geht um Überschriften und um Zwischenüberschriften in Tabellen, und da kann sowieso geeignet per style= formatiert werden.

Oder es ist völlig überflüssig und man kann die Dekoration komplett eliminieren.

Bei all diesen Dingern muss manuell geguckt werden, welche Lösung für einen Text auf einer ANR- oder Projektseite gerade angemessen ist. Stupide per Bot irgendwas durch riesige Konstrukte zu ersetzen ist definitiv eine Schnapsidee.

HTML5 wurde um 2009 aktiviert; seitdem, also seit einem Dutzend Jahren sind sich MediaWiki und zumindest ich uns über die Lage im Klaren – ruhige Hand, keine Hektik, keine stumpfsinnige Ersetzungen ohne triftigen Grund und ein aktuell zu lösendes Problem.

VG --PerfektesChaos 00:51, 11. Apr. 2021 (CEST)

naja, <big> ist auch so ein Problem, aber wo hab ich denn <small> ersetzt? – Doc Taxon • Disk. • 16:32, 11. Apr. 2021 (CEST)

Hast du (mit einem festen Faktor), aber verlange von mir jetzt nicht, dass ich das bei deinen Tausenden Bot-Edits nochmal heraussuche. ÅñŧóñŜûŝî (Ð) 17:05, 11. Apr. 2021 (CEST)

Diskussionsbeiträge

Diskussionsbeiträge sollten nur geändert werden, wenn sie ohne Eingriff in ihrer Aussage verfälscht werden, also Linkfixe oder nicht mehr funktionierender Code. Ansonsten bitte nicht verändern. ÅñŧóñŜûŝî (Ð) 11:43, 11. Apr. 2021 (CEST)

Wie meinst du das. Es geht doch gar nicht um Änderungen der Aussagen sondern nur um den Ersatz von veralteten Tags, wie font, center, tt oder strike. Aber wenn ich Fehler sehe wie diese Spezial:Diff/210694036 oder Spezial:Diff/210694469 wo offensichtlich versehentlich eine Signatur zerstört wurde, dann repariere ich so etwas. Das ist auch keine inhaltliche Verfälschung. Zeig mir mal an einem Beispiel was du meinst. --Liebe Grüße, Lómelinde Diskussion 11:53, 11. Apr. 2021 (CEST)

Center kann man gar nicht zuverlässig mit dem Bot ändern. Es ist ja schon manuell schwierig, das zu ersetzen, weil man da ggf. die halbe Seite umkrempeln muss. Ebenso verändert der Bot Signaturen, was m. E. auch bei "nicht-zerstören" gar nicht geht, wenn es ohne Eingriff weiterhin funktioniert (Siehe Benutzer Diskussion:Mart o-cloc). Zu Tt, Small und Big siehe die anderen Abschnitte. Es geht hier auch um die Autorenhoheit über eigene D-Beiträge.

Wurde Benutzer:1971markus darüber informiert, dass der Bot seine Signatur verändert? Vermutlich nicht. Ich hole das mal nach. ÅñŧóñŜûŝî (Ð) 12:13, 11. Apr. 2021 (CEST)

Was genau ändert sich denn daran? Inhaltlich nichts optisch ebenfalls nichts. Schlimm genug, dass dieses Tag überhaupt verwendet wurde. Nochmals wo genau bemängelst du eine inhaltliche Veränderung? Nur rummosern ist auch nicht hilfreich. --Liebe Grüße, Lómelinde Diskussion 12:38, 11. Apr. 2021 (CEST)

Es geht darum, dass man nicht unnötig an anderer User Signaturen herumfummelt. Selbstverständlich kann man erwarten, dass ein User seine Signatur zukünftig an gültigen Code anpasst, aber bereits gesetzte sind nur mit Zustimmung zu ändern, egal ob das Erscheinungsbild verändert wird. ÅñŧóñŜûŝî (Ð) 12:42, 11. Apr. 2021 (CEST)

Nein, es geht darum, dass diese Signatur auch in Zukunft noch so aussieht wie es der Ersteller einmal haben wollte, selbst dann wenn er lange schon nicht mehr hier aktiv ist. Das ist ein Service. Und ich sehe es so, dass du diesen Service = vorbeugende Wartung, falls du so etwas kennst, ablehnst. Warum? Die Signaturen sind teilweise fehlerhaft un verunstalten komplette Seiten. Wem ist also damit geholfen, wenn man das so lässt? Du weichst meiner Frage aus, wo wurde etwas inhaltlich verändert? „Herumfummeln“ ist sehr abwertend und kränkend, denn ich zumindest bemühe mich um Ersatz, der optisch nichts verändert, sondern die Syntax so interpretiert, wie es gewünscht war. Nur mit Zustimmung und wie fragst du verstorbene Mitarbeiter wie Lady Whistler, ob es ihr recht wäre, dass ihre Signatur so erhalten bleibt wie sie sie einmal entworfen hatte? Ich kann dich nicht verstehen. Erst der Aufriss bei Neitram nun schon wieder diese Vorwürfe. --Liebe Grüße, Lómelinde Diskussion 12:53, 11. Apr. 2021 (CEST)

Zusammenfassung

Ich wage mal eine kurze Zusammenfassung dessen, was sich hier im Laufe der Zeit so ergeben hat. Wer mag, kann das gerne ergänzen oder anpassen. ÅñŧóñŜûŝî (Ð) 11:47, 11. Apr. 2021 (CEST)

Aufnehmen kann man noch: Systematische Botläufe auf vollgeschützten Seiten ("Admin-Bots"): Nur nach Ankündigung auf WP:AN, 1 Tag Wartefrist (etwas anderes sind gezielte, manuelle Anpassungen, weil z.B. eine alte AK plötzlich voll-ge"small"t ist). --Filzstift (Diskussion) 22:15, 11. Apr. 2021 (CEST)

Ich finde es absolut erschreckend dass jetzt auch noch Admins die Validierung aktiv und bewusst boykottieren: Eine echte Schande so etwas. Es verbleiben dann am Ende solche Listen mit Verweigerern. Listen, die eigentlich schon komplett bereinigt waren!

• Spezial:LintErrors/self-closed-tag
• Spezial:LintErrors/tidy-font-bug
• Spezial:LintErrors/html5-misnesting

Ich zitiere hier mal Perrak, der sagte: „Schlechter Stil ist es auch, als Admin nicht diejenigen zu verteidigen, die technische Fehler ausbessern, sondern denjenigen, der die Verbesserung wegvandaliert.“ (Disk) So unterschiedlich können hier die Meinungen sein. Auch wenn es hier vielleicht keine kommentarlosen Reverts waren, es wurde bewusst fehlerhafte Syntax wieder hergestellt und durch Seitensperrung festgeschrieben. Was allerdinge „voll-ge"small"t“ sein soll verstehe ich nicht. Warum gebt ihr keine Difflinks zu den Dingen über die ihr euch beschweren wollt? Irgendetwas in den Raum zu stellen ist für mich auch schlechter Stil. Das Smalltag wird eigentlich überhaupt nicht angefasst. Das Fonttag sollte Zitat: „… unbedingt aus allen Wikiseiten entfernt werden“ siehe Hilfe:Tags#font. Und genau danach richte ich mich. --Liebe Grüße, Lómelinde Diskussion 07:39, 12. Apr. 2021 (CEST)

Ich war halt nicht so geistesgegenwärtig, den Difflink von der Small-Ersetzung - keine Ahnung- wier viele es insgesamt waren- herauszukopieren. Der Doc wird - wenn er den Bot sorgfältig laufen lässt - schon wissen, wann er welches Skript hat laufen lassen und wann ein Austausch von Small im Code war. ÅñŧóñŜûŝî (Ð) 19:34, 13. Apr. 2021 (CEST)

@Antonsusi: Ich finde es trotzdem etwas unpassend einfach etwas in den Raum zu stellen ohne es auch zu belegen. By the way könntest du bitte deine eigene Unterseite Spezial:LintErrors/html5-misnesting so abändern, dass sie aus der Liste verschwindet und auch keine solchen Fehler „Expansion depth limit exceeded“ mehr erzeugt? Es wäre wirklich sinnvoll wenn jeder ein wenig selbst darauf achtet keine Fehler zu erzeugen, dann müssten andere sie nicht reparieren. Was das small angeht, ich ersetze es dort, wo es über komplette Aufzählungen, Tabellen oder Textblöcke gespannt wurde, denn das ist unzulässig Hilfe:Tags#Inline-Elemente. Klar gibt es da zwei Möglichkeiten, entweder man setzt mühsam jede einzelne Textzeile in eigene small-Tags oder man setzt außen ein div drum und verkleinert den kompletten Bereich. Aber das hat nichts mit einer flächendeckenden Ersetzung von small zu festen Werten zu tun und ist immer Einzelfallabhängig. Wie gesagt es geht hier um vorbeugende Wartung. Hier ein paar Beispiele von gestern, damit auch du verstehst warum ich mich da einsetze:

• strike (s)-Fehler Spezial:PermaLink/144374560#Lesenwert-Diskussion, abgeschlossen 6. September 2006 ab dort komplett durchgestrichen so Diskussion:Zöliakie/Archiv#Lesenwert-Diskussion, abgeschlossen 6. September 2006 soll es aussehen.
• strike (s)-Fehler ein extrem schwieriger Fall Spezial:Diff/210227272/210828676 da in den Beiträgen des Benutzers dieser Eintrag nicht mehr vorhanden ist weil hin und her kopiert wurde. Da muss ich richtig Zeit investieren, um das wieder gerade zu rücken.
• small und Signaturschriftart bis ans Seitenende: Spezial:PermaLink/113646791#Wikipedia:Kandidaturen von Artikeln, Listen und Portalen#Cabo Machichaco Missglückte Entfernung eines extrem störenden Nudelholzes durch den Benutzer in der Signatur eines anderen auf seiner Diskussionsseite Spezial:Diff/108701664/next.

Es gab noch weit extremere Seiten, die bis zur Unleserlichkeit verkleinert oder auch mal vergrößert wurden. Und genau darum geht es hier, solch fehlerhafte Syntax schon jetzt zu bereinigen, ehe sie komplette Seiten zerstören. Daher finde ich es auch extrem schlimm, wenn jetzt Admins meinen ihre eigenen Seiten vollschützen zu müssen un dadurch diese Fehler nicht nur zu provozieren, sondern die Behebung zu verhindern. Dieser mag es eben in purple und der Filzstift gönnt es dem Petar nicht, dass er mal eine dunkelrote Signatur Petar Marjanovic hatte Spezial:Diff/31038244/209336650, setzt es zurück Spezial:Diff/209336650/next und sperrt seine Seiten, wodurch schon jetzt die gewünschte Wirkung verloren ist. Nun ja, sinnvoll ist das in meinen Augen nicht, dann könnte man dort den Font-Quatsch auch ganz entfernen, sähe genau so ungefärbt aus und würde die Fehlerlisten entlasten. Aber das möchte man ja scheinbar nicht. Alternativ könnte man so wie hier Spezial:Diff/210579760/210581901 einfach alles in die Versionsgeschichte verbannen, auch dann würden die Einträge aus den Listen verschwinden und jenen, die sich hier aktiv seit mehr als drei Jahren um valide Syntax bemühen das Leben leichter machen. --Liebe Grüße, Lómelinde Diskussion 08:03, 14. Apr. 2021 (CEST)

Bin kein Admin und will auch keiner sein. Lediglich ein Leserecht auf "Gelöschtes" wäre ab und zu nützlich... Ich sperre keine Seiten. Was es die BNR-Seite angeht: Das ist eine Testseite für eine Vorlage und zeigt mit dem Lint-Fehler die Grenze auf... ÅñŧóñŜûŝî (Ð) 19:54, 14. Apr. 2021 (CEST)

Dankeschön fürs umbauen. --Liebe Grüße, Lómelinde Diskussion 15:48, 15. Apr. 2021 (CEST)

@Lómelinde: Das Thema ist zurzeit nicht aktuell, weshalb ich das umgebaut habe. Es ist aber immer mal damit zu rechnen, dass in einem BNR zu Testzwecken oder im Zusammenhang mit einer Diskussion Fehler gezielt erzeugt werden. ÅñŧóñŜûŝî (Ð) 18:23, 26. Apr. 2021 (CEST)

@ ÅñŧóñŜûŝî, ich weiß, dass es ein paar Seiten gibt die vermutlich auf ewig fehlerbehaftet stehen bleiben werden, aber wo es vermeidbar ist, da sollte man das auch beheben. Übrigens weißt du doch sicherlich, dass Dateieinbindungen in der Signatur eigentlich nicht erwünscht sind, da diese die Dateibeschreibungsseiten mit Spam fluten. Trotzdem machst du so etwas. Muss man sich eigentlich immer gegen alles stellen und zeigen, dass Regeln nur für andere gelten? Siehe auch Hilfe:Signatur#Hinweise zur Gestaltung der Signatur. Hunderttausende dieser Fehler in den Listen gehen nämlich genau auf die zwanghafte individuelle Gestaltung der Signaturen zurück. Würden sich alle an die Richtlinien halten, dann gäbe es weitaus weniger dieser Fehler über deren Behebung ihr euch hier nun so lautstark moniert habt. Hast du auf deine Anfragen bei Neitram oder Markus eigentlich eine Rückmeldung bekommen, dass sie sich da beschweren wollen, weil ihre ehemaligen nicht regelkonformen Signaturen (font sollte nie verwendet werden) bereinigt werden? Warum frage ich dich, verwendest du keine richtlinienkonforme Signatur? Warum prangerst du diesen Service an und stellst zudem solche Fehler wieder her? Warum erschwerst du es anderen diese Fehler zu beheben? --Liebe Grüße, Lómelinde Diskussion 07:56, 27. Apr. 2021 (CEST)

@Lómelinde: Da wären spezielle Icons nur für Signaturen nützlich. Bedauerlicherweise haben wir keine Kategorien mit "Icons für Signaturen" wie z. B. Smileys. Einbindelisten für Smileys sind unbedeutend. ÅñŧóñŜûŝî (Ð) 18:37, 27. Apr. 2021 (CEST)

Liste

• Keine Botläufe zum Austausch von <tt>, <small> oder <big>.
• Das uralte <font> gilt demgegenüber als austauschwürdig. Ob das ein Bot kann, muss noch geklärt werden.
• <center> ist austauschwürdig, aber nichts für den Bot. Da muss man meistens individuell umbauen.

Sepx

Der Fehler bei Sepx bei fehlerhaften Dateioptionen scheint vom px in Seps zu kommen. Was tun? Andim (Diskussion) 08:09, 17. Mai 2021 (CEST)

Hihi. Starkes Stück.

Werde ein Phabricator-Ticket schreiben. Bug im Linter.

Vorläufig abgefangen.

Danke für den Hinweis --PerfektesChaos 09:38, 17. Mai 2021 (CEST)

Das war mir schon bekannt und ich meine es gab da auch schon mal ein Ticket. --Liebe Grüße, Lómelinde Diskussion 11:14, 17. Mai 2021 (CEST)

Vorlage:Löschen

Da ist ein Span-Tag drin, dass asymetriche Wikisyntax umschließt, genauer: Eine einzelne geschlossene eckige Klammer: Hinter dem Kommentar "Link auf action=purge" steht die einzelne öffnende eckige Klammer. In Zeile 45, nach dem Kommentar "Falls Zeitdifferenz>10min fett markieren", steht etwas weiter in der If-Bedingung

{{LOCALTIMESTAMP}} - 0{{REVISIONTIMESTAMP}} > 1000

der Code für das Span-Tag

<span style="font-size:110%; font-weight:bold;">

Dann folgt hinter der Plural-Weiche Minute|Minuten die schließende eckige Klammer und später das </span>. Die Expr-Bedingungen sind identisch, aber das Span-Tag umfasst nur die schließende Eckige Klammer. Ich sehe darin die Ursache für den Eintrag auf https://fireflytools.toolforge.org/fireflytools/linter/dewiki in Zelle "Template/Misnested tags". Das sollte man beseitigen. Dazu muss ein Admin die Schließende Klammer direkt hinter </span>}}, also vor den Kommentar mit "weitere Links", verschieben. Gruß von ÅñŧóñŜûŝî (Ð) 20:25, 1. Aug. 2021 (CEST)

@Lómelinde: Soweit verständlich? ÅñŧóñŜûŝî (Ð) 20:34, 1. Aug. 2021 (CEST)

@Antonsusi, ich bin aber kein Admin. Was erwartest du nun was ich tun soll?

Ich meine aber es liegt eigentlich eher an etwas anderem nämlich der eckigen Klammerung die das span am Ende abtrennt, das müsste nach innen also von so

Seite [{{canonicalurl:{{FULLPAGENAME}}|diff=cur}} zuletzt bearbeitet] vor <!--
-->[{{canonicalurl:{{FULLPAGENAME}}|action=purge}} <!--
-->{{#ifexpr: {{LOCALTIMESTAMP}} < 0{{REVISIONTIMESTAMP}} | ? | <!--
-->{{#ifexpr: {{LOCALTIMESTAMP}} - 0{{REVISIONTIMESTAMP}} > 1000 | <span style="font-size:110%; font-weight:bold;"> }}<!--
-->{{#expr: ({{#timel: U | {{LOCALTIMESTAMP}} }} - {{#timel: U | {{REVISIONTIMESTAMP}} }}) / 60 round 0 }} }}&nbsp;{{PLURAL:{{#expr: ({{#timel: U | {{LOCALTIMESTAMP}} }} - {{#timel: U | {{REVISIONTIMESTAMP}} }}) / 60 round 0 }}|Minute|Minuten}}] <!--
-->{{#ifexpr: {{LOCALTIMESTAMP}} - 0{{REVISIONTIMESTAMP}} > 1000 | </span> }}

nach

Seite [{{canonicalurl:{{FULLPAGENAME}}|diff=cur}} zuletzt bearbeitet] vor <!--
-->[{{canonicalurl:{{FULLPAGENAME}}|action=purge}} <!--
-->{{#ifexpr: {{LOCALTIMESTAMP}} < 0{{REVISIONTIMESTAMP}} | ? | <!--
-->{{#ifexpr: {{LOCALTIMESTAMP}} - 0{{REVISIONTIMESTAMP}} > 1000 | <span style="font-size:110%; font-weight:bold;"> }}<!--
-->{{#expr: ({{#timel: U | {{LOCALTIMESTAMP}} }} - {{#timel: U | {{REVISIONTIMESTAMP}} }}) / 60 round 0 }} }}&nbsp;{{PLURAL:{{#expr: ({{#timel: U | {{LOCALTIMESTAMP}} }} - {{#timel: U | {{REVISIONTIMESTAMP}} }}) / 60 round 0 }}|Minute|Minuten}} <!--
-->{{#ifexpr: {{LOCALTIMESTAMP}} - 0{{REVISIONTIMESTAMP}} > 1000 | </span> }}]

Seite zuletzt bearbeitet vor ? Minuten

Dann nämlich löst es keine Fehler mehr aus.

@Mabschaaf magst du mal schauen, ob du das hinbekommen kannst? Es geht nur um die eckige schließende Klammer ], die von

|Minute|Minuten}}] nach unten

1000 | </span> }}] verschoben werden müsste, damit das span komplett innerhalb der Linkklammer steht. --Liebe Grüße, Lómelinde Diskussion 06:50, 2. Aug. 2021 (CEST)

ping hat zwar nicht funktioniert - aber done.--Mabschaaf 08:32, 2. Aug. 2021 (CEST)

@Mabschaaf, Lómelinde: Ach schade. Ich dachte, ich hätte es korrekt durchdacht Vorlage:Smiley/Wartung/:( . Echt eine harte Nuss. Wer kann da weiterkommen? ÅñŧóñŜûŝî (Ð) 19:20, 3. Aug. 2021 (CEST)

Was meinst du? Der Fehler ist doch jetzt weg. Ich hatte das auf später verschoben, so wie auch die anderen Fehler im Vorlagennamensraum, die ich derzeit noch nicht beheben konnte. „Hat zwar nicht funktioniert“ bezog sich auf mein Ping. --Liebe Grüße, Lómelinde Diskussion 06:18, 4. Aug. 2021 (CEST)

Vorlage:Smiley/Wartung/:d  Dann bin ich erfreut und beruhigt. ÅñŧóñŜûŝî (Ð) 22:24, 4. Aug. 2021 (CEST)

inline-media-caption

Moin Moin zusammen, ich habe unter mw:Help:Lint errors/inline-media-caption gesehen, dass es bald ein neues Linter gibt. Ich kann mal so gar nicht greifen, wie viele Probleme es da so geben könnte. Aber augenscheinlich kann man es schnell fixen und wollte fragen, ob dann nicht ein Bot-Lauf helfen könnte? Kann jemand vllt. auch mal ne Zahl liefern? Zur Kenntnis: Doc Taxon, Lómelinde, Wurgl mfg und vielen Dank im Voraus --Crazy1880 18:43, 2. Jan. 2022 (CET)

Frohes Neues; habe ich schon länger aufm Schirm und scanne den ANR-Bestand bei Bearbeitungen.

Die Aktion ist etwas übertrieben und dient dem Quelltext-Logik-Purismus; die angegebene Begründung ist dünn. Der unbenannte nicht zuzgeordnete (hoffentlich letzte) Parameter ist halt caption im Fall von Miniaturbildern und title im Fall wenn nicht. Hätt man auch wie bisher lassen können.

Es hat absolut keine Eile; da WSTM sowieso jede Bild-Einbindung im ANR-Quelltext analysiert, bin ich geistig darauf vorbereitet, das dort geruhsam umzustellen.

Schwieriger wird es mit Vorlagen, weil es in sehr sehr vielen einen Icon gibt, der einen solchen Tooltip-Text bereithält; bei der Gelegenheit müssten dann auch alte Layout-Tabellen durch moderne Muttervorlagen ersetzt werden. Die QS-Vorlagen sind regelmäßig noch so gestrickt.

VG --PerfektesChaos 18:53, 2. Jan. 2022 (CET)

Hallo Crazy, ein gesundes neues Jahr wünsche ich dir und natürlich auch PerfektesChaos. Leider weiß ich noch nicht wirklich, wie diese Fehler aussehen werden und was da alles zusammenkommt. Ich vermute es werden viele tausende Seiten betroffen sein und ein reines Einfügen von |alt= ist sicherlich nicht die Lösung weil dann die bisherige Funktion des Tooltips verloren geht, das wäre nicht gut. Ich habe das nur aus der verlinkten Seite beziehungsweise dort herausgelesen. Wenn ich wüsste wie ich das testen kann wüsste ich mehr. --Liebe Grüße, Lómelinde Diskussion 19:07, 2. Jan. 2022 (CET)

Moin, ja genau soetwas hatte ich mir schon gedacht, dass das mehr wird. mfg --Crazy1880 10:07, 3. Jan. 2022 (CET)

Hmm … und der Text der bisher bei Mouse-Over gekommen ist? Der ist dann weg oder was? --Wurgl (Diskussion) 13:03, 3. Jan. 2022 (CET)

Ja, das wäre wohl so, wenn man da nur ein |alt= einfügt, daher hoffe ich sie lassen das. Der Text beschreibt ja nicht immer wirklich das, was auf dem Bild zu sehen ist, und damit würde man das Attribut |alt= mit irgendwelchem Schrott zumüllen. Mir gefällt das gar nicht. Aber mich fragen sie da ja nicht. Richtig wäre es eher, wenn man den alternativen Text auf der Dateibeschreibungsseite hinterlegen könnte und der dann immer von dort angeboten würde, es sei denn man überschreibt ihn bewusst. Denn ausufernde Bildinhaltsbeschreibungen im Quelltext wären für mich auch alles andere als toll, denn das führt dann auch wieder zu Fehlern weil jemand meint er müsse dort einen Link ergänzen, keine Ahnung ob man damit etwas anfangen könnte, oder refs setzen … ich habe echt einen Horror davor was da auf uns zurollt, insbesondere an Vorlagen oderTextbausteinen …. Was wird beispielsweise aus Flaggenvorlagen, werden die auch Fehler auslösen oder nicht, ich weiß es nicht. Und sie schicken da auch garantiert kein unterstützendes Supportteam mit. Und was passiert mit so etwas [[Datei:P medicine caution.svg|25px|verweis=Wikipedia:Hinweis Gesundheitsthemen|Gesundheitshinweis|alt=]] ein leeres |alt= = Fehler J N --Liebe Grüße, Lómelinde Diskussion 13:39, 3. Jan. 2022 (CET)

 Info: So nun haben wir den Salat Spezial:LintErrors/inline-media-caption Anzahl 782.971 Fehler, das wirft uns um Jahre zurück, und setzt uns wieder auf die Millionengrenze. Heul!!! Ich hatte so sehr gehofft sie vergessen das schnell wieder. --Liebe Grüße, Lómelinde Diskussion 07:20, 14. Jan. 2022 (CET)

Tagfehler Klammer/kursiv

Falsche Klammer-/Tag-Reihenfolge

@Doc Taxon: Magst Du mal schauen, ob Du per Bot folgende Fehler korrigieren kannst (häufig im ANR):

• ''[<irgendeine.url> Linktext''] -> ''[<irgendeine.url> Linktext]''
• ''[<irgendeine.url> Linktext''.] -> ''[<irgendeine.url> Linktext.]'' (gerne auch mit dem Punkt außerhalb der eckigen Klammer und auch mit anderen Satzzeichen wie ! und ?)
• [<irgendeine.url> ''Linktext]'' -> [<irgendeine.url> ''Linktext''] (ebenso mit Satzzeichen)

oder auch alle genannten Varianten mit

• ''{{Webarchiv|... |text=Linktext'' |...}}

Danke und viele Grüße --Mabschaaf 14:27, 9. Jan. 2022 (CET)

ja, mag ich mal, aber nicht heute. – Doc Taxon • Disk. • 11:26, 10. Jan. 2022 (CET)

Dann aber schon heute vorauseilenden Dank dafür, denn dann kann ich mir weitere händische Korrekturen vorläufig sparen ;-) Ich fürchte, es wird noch genug übrig bleiben... --Mabschaaf 12:26, 10. Jan. 2022 (CET)

@Wurgl: kannst Du zu den vier Punkten irgendwie eine Artikelliste erstellen? Vielleicht hast Du auch erweiterte insource-Kenntnisse   – Doc Taxon • Disk. • 15:28, 19. Jan. 2022 (CET)

Ich glaub für die erste Konstruktion hab ich damals (am 10. Januar) aus Spass an der Freud eine Regexp gebastelt (aus Browser-History gekramt): insource:/\[[^\]]*''[^'\]]*\]''/ … wie zu erwarten fällt die natürlich ins Timeout, bei mir nach ca. 1100 Treffern. Ich mach mal eine Auswertung des letzten Dumps. --Wurgl (Diskussion) 15:50, 19. Jan. 2022 (CET)

Timeout macht übrigens erst mal nichts. – Doc Taxon • Disk. • 16:05, 19. Jan. 2022 (CET)

@Wurgl: kluge Insource-Abfragen würden mir sogar reichen. Du brauchst keine Dumps auswerten oder Listen erstellen. Für Deine Hilfe immer dankbar, – Doc Taxon • Disk. • 16:07, 19. Jan. 2022 (CET)

Dumps auswerten juckt nicht, ich hab das fix und fertig, muss da nur ein paar Zeilen mit Regexp dazupappen. Die regexp oben ist übrigens die dritte Form, nicht die erste. --Wurgl (Diskussion) 16:12, 19. Jan. 2022 (CET)

Die ersten beiden(!) Fälle wären insource:/''\[[^\]']*''[^'\]]*\]/ (ca. 410 Treffer bis Timeout) bzw. eine Regexp für alle drei: insource:/\[[^\]']*''[^'\]]*\]/ in dem Fall müsstest du dann zu Fuß suchen, ob die korrespondierenden '' davor oder danach rumlungern. Es gibt da aber False-Positive wie die Dateibeschreibung in Japan (edit Abschnitt Küche) --Wurgl (Diskussion) 16:25, 19. Jan. 2022 (CET)

Zum Webarchiv kann meine Vorlagensuche im ANR die Fälle finden (288 Artikel mit Parameter "text" in Vorlage:Webarchiv bzw. ganz allgemein 381 Artikel). Da gibt es klasse Konstrukte wie Air14 (edit Abschnitt Weblinks) Die Vorlagenfehler würde ich gerne selbst mit dem APPERbot machen, die sind wahrscheinlich nur vereinzelt außerhalb des ANR. --Wurgl (Diskussion) 16:12, 19. Jan. 2022 (CET)

@Wurgl: Die Dateibeschreibung in Japan hat aber auch nur doppelte Eckklammern. Hier geht es nur um single brackets. Vielleicht geht die Regexp so anzupassen, dass Doppeleckklammerergebnisse nicht aufkommen. – Doc Taxon • Disk. • 16:31, 19. Jan. 2022 (CET)

Stimmpt! Ich hab mal der Regexp gesagt, am Anfang und Ende sollen keine zwei Eckigen sein: insource:/[^\[]\[[^\]']*''[^'\]]*\][^\]]/ Da gibts aber auch den Hitler mit einem [sic] im Text, solche Falsch-Positive kann Regexp nicht ausklammern. --Wurgl (Diskussion) 16:38, 19. Jan. 2022 (CET)

Ja genau, die Webarchiv-Ergebnisse kannst Du natürlich selbst machen. Mach die ruhig auch im ex-ANR-Bereich, denn da sind die schließlich auch falsch (freut sich Lómelinde, aber auch ich wieder etwas mehr  ) – Doc Taxon • Disk. • 16:34, 19. Jan. 2022 (CET)

Außerhalb geht leider nicht, da hab ich keine Daten in meiner Datenbank. --Wurgl (Diskussion) 16:39, 19. Jan. 2022 (CET)

Wenn Du die insource-Abfrage machst, h#ttest Du Deine Daten ... – Doc Taxon • Disk. • 16:48, 19. Jan. 2022 (CET)

Ähm Wurgl, wenn das bei Dir soweit fix und fertig ist, kannst Du dann die Sachen mit Apperbot nicht gleich selbst korrigieren? – Doc Taxon • Disk. • 16:40, 19. Jan. 2022 (CET)

Die Dumpauswertung hab ich hier rumliegen (damit mach ich Benutzer:Wurgl/Fehler_Bilder (ist abgearbeitet)). Das Rumhampeln mit der Hochkommaverschiebung hab ich nicht. --Wurgl (Diskussion) 16:42, 19. Jan. 2022 (CET)

okay, @Wurgl:, dann haste mir jetzt schon mal sehr weitergeholfen. Vielen lieben Dank, – Doc Taxon • Disk. • 16:53, 19. Jan. 2022 (CET)

Ich kümmer mich drum, – Doc Taxon • Disk. • 07:14, 20. Jan. 2022 (CET)

Gruselig! Echt gruselig!

• ''{{Webarchiv|…|text=''|webarchive=…}} => {{Webarchiv|…|text=|webarchive=…}} (eventuell noch Leerzeichen vor der Vorlage)
• ''{{Webarchiv|…|text=Blah''…}} => {{Webarchiv|…|text=''Blah''…}}
• {{Webarchiv|…|text=''Blah…}}'' => {{Webarchiv|…|text=''Blah''…}} (eventuell noch Leerzeichen oder Satzzeichen nach der Vorlage)
• {{Webarchiv|…|text=''Sendung | Sender''}} => {{Webarchiv|…|text=''Sendung {{!}} Sender''}}
• {{Webarchiv|…|url=http:example.com/seite.html''Blah | text=Blubb''}} => {{Webarchiv|…|url=http:example.com/seite.html | text=''Blah Blubb''}}
• Zusätzlich: Wenn innerhalb <ref>…</ref> eine ungerade Anzahl von '' ist, dann wird das korrespondierende '' hinzugefügt. Selbiges bei einer listenartigen Aufzählung wie im Abschnitt Weblinks.

Damit decke ich ca. zwei Drittel der Fälle ab.

Aber für so Dinge wie * {{Webarchiv | … | text=Die Buchbesprechung zu "Miss Tschörmänie" auf: ''}}[[ARTE]].'' 26. Juli 2009 ist es heute einfach zu spät für klare Gedanken was sowas wohl werden wollte. --Wurgl (Diskussion) 22:28, 20. Jan. 2022 (CET)

Was es werden wollte? Ich schätze mal so

* {{Webarchiv | … | text=Die Buchbesprechung zu „Miss Tschörmänie“}} auf: ''[[ARTE]].'' 26. Juli 2009

oder

* {{Webarchiv | … | text=''Die Buchbesprechung zu „Miss Tschörmänie“''}} auf: ''[[ARTE]].'' 26. Juli 2009

Falls das am Ende gut funktioniert sollte mindestens ein Bot das regelmäßig wiederholen, denn diese kursiv- fett-Fehler sind jene, die am häufigsten nachkommen, meine ich. Neben denen, die durch Benutzer verursacht werden, die einfach meinen es sei cool die Tägs vorne zu setzen und bewusst auf das Ende zu verzichten, weil das ja pro Zeile automatisch abbrechen würde, oder aber den Tags die über mehrere Tabellenzellen oder Vorlagenparameter gespannt werden ! Datum || '''Zelle 2 || Zelle 3'''. Es in die Köpfe der Benutzer zu bekommen, dass eigentlich alle Tags aus zwei Teilen bestehen, ist aussichtslos. „Ham wa schon immer so gemacht, hat immer funktioniert, warum also etwas ändern?“ --Liebe Grüße, Lómelinde Diskussion 06:42, 21. Jan. 2022 (CET)

Ich denke an deine zweite Variante, es sei denn die '' stehen am Anfang (oder in der Mitte) des Textes. Und ja, das wird regelmäßig laufen. --Wurgl (Diskussion) 07:54, 21. Jan. 2022 (CET)

171 Artikel bin ich jetzt per Bot durchgegangen (gestern auch 129 einfache Fälle), in zwei hab ich zu Fuß was geändert weil dort irgendwann die Vorlage blödsinnig falsch eingesetzt wurde und 6 sind noch übrig:

@Mabschaaf:

• Antoine Porot Vorlage:Webarchiv (2. Einbindung)
• Crazy Town Vorlage:Webarchiv (2. Einbindung)
• Der auferstandene Christus (Tlalnepantla) Vorlage:Webarchiv
• ERMETH Vorlage:Webarchiv
• Naloxon Vorlage:Webarchiv
• Paulo-Afonso-Wasserkraftkomplex Vorlage:Webarchiv (2. Einbindung)

Das war jetzt nur die Vorlage Webarchiv, die anderen Vorlagen kommen noch, sind noch 121 Treffer. --Wurgl (Diskussion) 15:44, 21. Jan. 2022 (CET)

@Wurgl: Danke für Deinen Einsatz! Es ist völlig ausreichend, wenn Du die Standardfälle wegräumst, alles, was dann noch übrig ist, werden wir per Hand schon noch erledigen. Das gilt auch für die "normalen" eingangs erwähnten Weblinks. Alles händisch zu machen ist halt ziemlich stupide.--Mabschaaf 16:17, 21. Jan. 2022 (CET)

@ Wurgl So richtig einen Effekt habe ich hier bisher noch nicht bemerkt, hast du das schon laufen lassen? Dann war es zumindest nicht so, wie erhofft. --Liebe Grüße, Lómelinde Diskussion 16:57, 27. Jan. 2022 (CET)

Webarchiv ist gelaufen. So 300 Artikel waren das. Die anderen Vorlagen hab nicht noch nicht geguckt. --Wurgl (Diskussion) 17:00, 27. Jan. 2022 (CET)

Ach so, na das sind ja zumeist keine Vorlagen, sondern Weblinks. Die machen ja die meisten der fehlendes kursiv Fehler aus. Das schlägt dann immer doppelt zu Buche. Na ja eigentlich wollte sich der Doc darum kümmern, aber er ist wohl auch etwas überlastet. Ich mag diese Fehler nicht, weil sie echt öde manchmal aber auch wirklich schwierig aufzuspüren sind, wenn das ganze in Vorlagen in Vorlagen verschachtelt ist. --Liebe Grüße, Lómelinde Diskussion 17:11, 27. Jan. 2022 (CET)

@ Doc Taxon arbeitest du noch an diesem Thema? Es sind noch einige hundert und das sollte eigentlich zu einer Dauerlaufabfrage werden. Denn gerade diese in- und außerhalb von Linkklammern kommen immer wieder neu hinzu. --Liebe Grüße, Lómelinde Diskussion 16:25, 24. Mär. 2022 (CET)

Leerzeichenfehler

Weiß irgendjemand, ob das hier Hilfe:Wikisyntax/Validierung#Leerzeichenfehler (tidy-whitespace-bug) jemals funktioniert hat? Ich kann mich nicht erinnern, dass diese Fehler tatsächlich analysiert wurden oder ich auf so einen Fehler gestoßen bin. Ich meine nur wem nutzt so eine Fehlerkategorie, wenn sie doch nicht aktiv ist. In der en:wp gibt es 3 Fehler aber es ist nicht das was ich auf der Vorderseite als Beispiele habe.

• {{nowrap|[[Toy Story]] <small>(1995)</small> }}| = kein Fehler obwohl das Leerzeichen vor dem Pipe fehlt
• Toy Story (1995)|

und es eigentlich so aussehen müsste

• Toy Story (1995) |

Ich meine so etwas wird doch sicherlich mal irgendwo vorkommen insbesondere in Navileisten. --Liebe Grüße, Lómelinde Diskussion 11:10, 18. Jan. 2022 (CET)

Naja, ich kann mir schon vorstellen, dass dieser Fehler relativ selten vorkommen sollte. Aber wenn das mal passiert, schlägt der "Lintalarm" an, und das ist doch auch gut so, oder nicht? – Doc Taxon • Disk. • 15:22, 19. Jan. 2022 (CET)

Nein, das tut er eben nicht, das war doch meine Frage. Er sollte das bemerken tut es aber nicht. Ich kann mich daher nicht erinnern je so einen Fehler gehabt zu haben. Die Auswertung scheint nicht aktiv zu sein. Man sieht es doch eindeutig, dass da etwas falsch ist, aber Linter ignoriert das. Ich weiß nicht wie man danach suchen müsste. Das hier insource:/\{\{[nN]owrap\|^*\}\}/ oder das insource:/\{\{[nN]owrap\|^* \}\}/ bringt nur leere nowraps. Ich suche aber welche wo Inhalt ist und am Ende ein Leerzeichen steht. --Liebe Grüße, Lómelinde Diskussion 19:35, 19. Jan. 2022 (CET)

56 Stück Inline würde das so aussehen: insource:/\{\{[nN]owrap\|[^}]* \}\}/ … gibt aber ein paar falsche Treffer wenn eine Vorlage verschachtelt ist (und in der verschachtelten ein Leerzeichen vor den abschließenden }} ist und findet auch nicht alle (ebenfalls bei Vorlage in Vorlage wenn die innere Vorlage kein Leerzeichen am Ende hat). --Wurgl (Diskussion) 20:23, 19. Jan. 2022 (CET)

Dankeschön, es gäbe noch die Verwendung als style-Zuweisung irgendwo innerhalb eines span oder was auch immer.

• 251 nowrap alle Namensräume.

Ich sagte doch, es gibt da sicherlich welche, die Analyse scheint also nicht aktiv zu sein. Es sind in den meisten Fällen Tabellenzellen wo kein Inhalt folgt oder aber jemand hat bewusst ein Leerzeichen dahinter gesetzt. Daher fällt es in der normalen Ansicht auch nicht auf. Oder es folgt ein Zeilenumbruch oder ist das letzte Element {{nowrap|[[Link]] }}, wie in etlichen Navileisten, was das unauffällig macht. --Liebe Grüße, Lómelinde Diskussion 06:42, 20. Jan. 2022 (CET)

@Lómelinde: Guten Morgen, ich guck mal, ob ich das automatisch wegbringen kann. Liebe Grüße, – Doc Taxon • Disk. • 07:01, 20. Jan. 2022 (CET)

Dankeschön. --Liebe Grüße, Lómelinde Diskussion 07:05, 20. Jan. 2022 (CET)

@Doc Taxon: haste schon was gemacht? Weil ich hab nix gesehen, dass du machen willst und hätte es fertig. Ich würde das aber erst laufen lassen, wenn tatsächlich Fehler gezählt werden. Soweit ich gesehen hab, tritt der demonstrierte Fehler oben nicht im ANR auf. Diese nowrap sind alle von Leerzeichen gefolgt (oder Newlines, <br/>, Enden von Tabellenspalten, etc. --Wurgl (Diskussion) 16:35, 23. Jan. 2022 (CET)

@Wurgl: bissl was anderes zu tun habe ich auch noch. Und dann bin ich auch noch berufstätig – nein, nicht im Home Office. Ich hab das aber nicht vergessen ... – Doc Taxon • Disk. • 22:51, 23. Jan. 2022 (CET)

Hierfür muss ich ein Derivat meines Steuerzeichen-Jägers bauen. Mal schauen, – Doc Taxon Disk. • 12:37, 12. Apr. 2022 (CEST)

→ @Lómelinde, Wurgl: Die 56er-Wurgl-Liste ist schon mal abgearbeitet. – Doc Taxon Disk. • 22:34, 12. Apr. 2022 (CEST)

Vielen Dank. --Liebe Grüße, Lómelinde Diskussion 06:23, 13. Apr. 2022 (CEST)

→ Die 251er-Liste ist jetzt bis auf false positive auch leer. @Lómelinde, Wurgl: hier fände ich es gut, wenn Ihr da auch noch mal drüber schauen würdet. Vielen Dank, – Doc Taxon Disk. • 15:26, 13. Apr. 2022 (CEST)

Ich habe mal ein paar Stichproben gemacht, ein schönes Beispiel ist diese Seite → vorher (alles in einer Zeile und dadurch breiter als 100%) ↔ nachher (passt auch auf schmale Bildschirme) Ich denke das war daher eine sinnvolle Änderung. --Liebe Grüße, Lómelinde Diskussion 15:57, 13. Apr. 2022 (CEST)

Ich denke, dass das erledigt ist. – Doc Taxon Disk. • 12:22, 21. Apr. 2022 (CEST)

Dieser Abschnitt kann archiviert werden. – Doc Taxon Disk. • 12:22, 21. Apr. 2022 (CEST)

Fehler bei Quoting

Es dreht sich um weiter oben, diese "1.139 Artikel". Einzelnachweis 36 Ja, der Bot hat hier Unsinn gemacht. Aber die Url war vorher schon im Bobbes. Verändert hat sich an der falschen Verlinkung nix, trotzdem ist es Unsinn.
Irgendwas ist da faul. Wenn ich den ersten Link so wie er gedacht war aufrufe, also Copy/Paste aus dem Quelltext, dann sehe ich ein recht sinnfreies Inhaltsverzeichnis. Beim Link wie er in EW 36 steht, komm ich auf die selbe sinnfreie Stelle. Aber! Dickes aber: Wenn ich jetzt in der Browser-History zurückgehe, dann sehe ich ein Schnippsel aus Seite 251, scheinbar die Einträge 37-41 auf der selben Stelle. Ich fass das jetzt nicht an, weil ich den Sinn dieses Einzelnachweise nicht begreife, was soll diese Liste bzw. das Schnippsel über Affären um gefälschte Spielerpässe nachweisen?
Frage: soll ich das irgendwie abfangen? In dem Fall ginge das, weil danach nochmals ein Parameter in der URL zu finden ist: &f=false --Wurgl (Diskussion) 07:34, 13. Apr. 2022 (CEST)

Ja fang das mal ein, ich schaue gleich mal. Ist googlebook sollte lösbar sein. --Liebe Grüße, Lómelinde Diskussion 08:00, 13. Apr. 2022 (CEST)

Ich habe versucht irgendetwas in der Leseprobe zu finden, was irgendwie passen könnte = nichts, nicht einmal das Datum 25. August 2003 gibt es dort. Daher komplett entfernt. --Liebe Grüße, Lómelinde Diskussion 08:30, 13. Apr. 2022 (CEST)

Schönen Morgen! Ist denn der Fall damit erledigt? Können wir abhaken? – Doc Taxon Disk. • 05:35, 16. Apr. 2022 (CEST)

Nein natürlich nicht, es muss nur die Suche präzisiert werden, also beispielsweise wo die URL auf .html .htm .pdf oder ähnlichem endet müssten alle Fälle in denen daran direkt kursivtags anschließen also .html'' .htm'' .pdf'' zu .html '' .htm '' .pdf '' werden. In dem Beispiel war aber das Kursiv mitten innerhalb der URL Spezial:Diff/222023745 (https://books.google.de/…&q=''L%E2%80%99%C3%89v%C3%A9nement''%2C%2025.%20August%202003&f=false), das ist natürlich schwierig zu da herauszufiltern. Es sind noch immer hunderte und die kommen auch täglich neu hinzu. Ich habe die Zahlen oben mal aktualisiert, und das war ja auch bisher nur die Analyse für http: und es fehlt die identische Abfrage für https: Der ANR ist zwar jetzt fast sauber, aber wie gesagt das sind die Fälle die am häufigssten neu hinzu kommen und daher regelmäßig laufen sollten. --Liebe Grüße, Lómelinde Diskussion 06:22, 16. Apr. 2022 (CEST)

Ich mach das jetzt nur nebenbei mit. Also wenn ich was anderes ändere, dann dies als Schmankerl zusätzlich. Es ändert sich ja nix in der Anzeige und auch die verlinkte URL bleibt gleich. Das Webarchiv archiviert auch ohne die Quotes. Das einzige was sich ändert ist das Verhalten des IABot. Ist mir persönlich etwas zu wenig um da den Bot extra über alle laufen zu lassen. Aber ich lass mich gerne von anderen überzeugen. @Mabschaaf, Doc Taxon: Habt ihr eine Meinung dazu? --Wurgl (Diskussion) 07:55, 16. Apr. 2022 (CEST)

Der IABot läuft ja gerade nicht, weil er mit diesem Problem nicht umgehen kann. Insofern ist mM kein akuter Handlungsbedarf, aber nebenher bereinigen solltest Du auf alle Fälle. Kannst Du denn gezielt nach solchen URLs suchen, die eine öffnende und auch die schließende Kursivierung enthalten (wie das eine Beispiel oben)? Diese sollten mM schon abgearbeitet werden. Wartungsliste -> händisch sollte reichen. Ich erwarte da eher falsch positive wie [http://www.test.de''Website''] deren Weblinkbeschriftung nur aus einem Wort besteht.--Mabschaaf 08:40, 16. Apr. 2022 (CEST)

Es ist teuflisch! Die Suche nach insource:/\[https?:\/\/[^\]' ]*''[^\]' ]*''/ fällt ins Timeout. Und der Dump (dewiki-latest-pages-articles-multistream.xml.bz2) enthält nur geradzahlige Namensbereiche und auch keine Benutzerseiten. Diskussionsseiten sind da nicht drinnen. Man müsste also beides kombinieren. --Wurgl (Diskussion) 09:33, 16. Apr. 2022 (CEST)

Es gibt [2]. Dieser Dump enthält alle Namensbereiche. Andim (Diskussion) 11:00, 16. Apr. 2022 (CEST)

Ja, ich schnapp mir den Task mal und baue alle Quotes aus den Links um. Geht aber nicht von jetzt auf gleich. – Doc Taxon Disk. • 20:21, 17. Apr. 2022 (CEST)

Sind schon etwas weniger, ich komme stetig vorwärts. – Doc Taxon Disk. • 18:04, 19. Apr. 2022 (CEST)

Dieser Abschnitt kann archiviert werden. – Doc Taxon Disk. • 23:51, 21. Apr. 2022 (CEST)

strike-Tags

Die strike-Tags werden in Kürze mit s-Tags ersetzt. Dabei versuche ich, Zeilenumbrüche innerhalb dieser Tags zu lokalisieren. – Doc Taxon Disk. • 18:06, 19. Apr. 2022 (CEST)

Der häufigste Fall für mit diesem oder dem s-Tags verursachten Fehlern (verschachtelte Tags) ist so etwas

<s>Beitrag gestrichen
: Anmerkung zum Beitrag</s> erl. Admin

Häufig bei den (Wikipedia:Löschkandidaten/Urheberrechtsverletzungen#2. April) Spezial:Diff/222116522/222117466. Ich habe mir schon die Finger wund geschrieben, um die abarbeitenden Admins irgendwie dazu zu bringen das zu unterlassen WD:Löschkandidaten/Urheberrechtsverletzungen#Bitte Linterfehler vermeiden. Es ist zwecklos. Wenn der Bot so etwas reparieren könnte wäre das auch wunderbar, denn das s muss wie small und code und span immer in der selben Zeile geschlossen werden in der es auch geöffnet wurde. --Liebe Grüße, Lómelinde Diskussion 18:29, 19. Apr. 2022 (CEST)

@Leserättin, CaroFraTyskland, Krd: wäre nett, wenn Ihr darauf etwas Acht geben könntet. Vielen Dank, – Doc Taxon Disk. • 01:59, 20. Apr. 2022 (CEST)

Kein Problem. Ich bilde mir ein, mich daran schon eine Weile zu halten. Ähm, ich glaube, das gesamte VTRS-Team, das Freigaben bearbeitet, sollte informiert werden. Diese neigen dazu, auf der LKU-Seite ganze Absätze zu streichen, wenn Freigaben kommen. Und das ist doch meines Wissens das Problem, oder? BG, --Leserättin (Diskussion) 10:59, 20. Apr. 2022 (CEST)

Ja genau das ist das Problem, jedes Inlinetag muss in jeder Zeile mit öffnendem und schließendem Element stehen, siehe auch Hilfe:Tags#Inline-Elemente. Es geht darum, dass nach einem Softwareupdate nicht plötzlich die komplette Seite bis zum Ende durchgestrichen wird. Leider sieht man das derzeit noch nicht, was dann dazu führt, dass Inlinetags falsch verwendet werden. Das gilt ebenso für fett und kursiv … --Liebe Grüße, Lómelinde Diskussion 11:54, 20. Apr. 2022 (CEST)

Ich gebe das mal in die Mailinglist des VTRS-Teams zur Beachtung. Ich meine, das schadet ja nicht. Liebe Grüße, – Doc Taxon Disk. • 16:03, 20. Apr. 2022 (CEST)

@Lómelinde: Das mit den strike-Tags sieht mittlerweile ganz gut aus, oder? – Doc Taxon Disk. • 18:24, 20. Apr. 2022 (CEST)

Ja schon sehr gut, ein paar sind noch übrig und es kommen wie gesagt auch immer wieder welche hinzu. Was die verschachtelten angeht, weiß ich es gerade nicht, denn ich arbeite an anderer Stelle. --Liebe Grüße, Lómelinde Diskussion 18:27, 20. Apr. 2022 (CEST)

@Lómelinde: okay, bin nochmal drüber, – der Rest, denke ich, soll wohl so. Liebe Grüße, – Doc Taxon Disk. • 19:38, 20. Apr. 2022 (CEST)

Ich lese hier sowieso mit du musst nicht immer Pingen. :-) Ja, so passt es, denke ich. --Liebe Grüße, Lómelinde Diskussion 06:24, 21. Apr. 2022 (CEST)

ich denke, dass das erledigt ist – Doc Taxon Disk. • 12:22, 21. Apr. 2022 (CEST)

Dieser Abschnitt kann archiviert werden. – Doc Taxon Disk. • 12:22, 21. Apr. 2022 (CEST)

Bot-fix: Vorlage:Zitat

Kann ein Botbetreiber sicher die falschen inline-Einbindungen von Vorlage:Zitat finden und durch Vorlage:" ersetzen? Also schlicht immer dann, wenn {{Zitat|... nicht am Zeilenanfang steht, daraus {{"|... machen?--Mabschaaf 17:04, 3. Aug. 2022 (CEST)

Das würde ich dringendst bleibenlassen, weil es mehrere Alt-Bearbeiter gibt, die einen einzigen Quelltextparagrafen mit mehreren sehr langen und offensichtlich als Blockzitate beabsichtigten und auch so dargestellten Texten einfügen, und dabei auch spezifische Parameter angeben.

WSTM zerlegt das dann in einzelene Quelltextzeilen, auch pro einzelnen Parameter, vor allem für Text und Übersetzung, woraufhin das dann wieder alles in eine einzige riesige Quelltextzeile zusammngeklumpt umgeschrieben wird, durch sogenannte Hauptautoren.

Die Regel ist eigentlich, dass Vorlageneinbindungen, die einen eigenständigen block bewirken, auch auf eigenen Quelltextzeilen beginnen sollen, und bei unübersichtlichen längeren Parameterzuweisungen wie auch Infoboxen auch jeder Parameter eine eigene Zeile bekommen sollte.

Aber einige Herrschaften der Crew 2005 haben sehr eigene Vorstellungen von Syntax.

Für die Darstellung ist es egal, ob eine oder mehrere Quelltextzeilen.

VG --PerfektesChaos 17:34, 3. Aug. 2022 (CEST)

Gut. Anders gefragt: Gibt es eine Cirrus-Abfrage, mit der sich alle Zitat-Vorlagen finden lassen, die nicht am Zeilenanfang stehen? Dann würde ich da mal manuell durchpflügen.--Mabschaaf 17:52, 3. Aug. 2022 (CEST)

@Aka: Du kannst die sicher schneller rausfischen. 63.000 Artikel per API lesen ist doch etwas mühsam. --Wurgl (Diskussion) 17:56, 3. Aug. 2022 (CEST)

Klingt machbar. -- Gruß, aka 18:43, 3. Aug. 2022 (CEST)

-> Benutzer:Aka/Fehlerlisten/Zitatvorlage nicht am Zeilenanfang. Da waren immerhin 3 Zeilen Quellcode dafür notwendig ;-) -- Gruß, aka 18:53, 3. Aug. 2022 (CEST)

3.500 von 62.000 ANR. Plus mit ohne Leerzeichen. VG --PerfektesChaos 18:51, 3. Aug. 2022 (CEST)

weia. Was sich da alles findet...
Aber egal. Leider hilft mir das (noch) nicht wirklich weiter. Ich bin davon ausgegangen, dass jede Einbindung von Vorlage:Zitat, die sich nicht am Zeilenanfang befindet, zu einem Linterfehler führt. Tut sie aber nicht, wie ich jetzt gesehen habe. Linterfehler gibt es nur dann, wenn die Vorlage in Zeilen steht, die mit *, ; oder : beginnen. Diese finden sich zudem nur noch im BNR, BDNR und WDNR. Lassen sich diese finden?--Mabschaaf 19:09, 3. Aug. 2022 (CEST)

Bei allem außerhalb vom Artikenamensraum bin ich raus, denn meine Datenbank kennt nur die Artikel. -- Gruß, aka 19:17, 3. Aug. 2022 (CEST)

@ANR:

• Trotzdem bleibenlassen, reine Quelltextkosmetik ohne irgendwelche Auswirkungen auf die Darstellung, WSTM macht es routinemäßig mit.
• Artikel zur Geschichte sind Betätigungsfeld der genannten Alt-„Hauptautoren“, die das dann wieder auf eine einzige Quelltextzeile rvertieren werden, aber mächtig schimpfen.

@Linter:

• Naja, da umschließt das inline-code oder sonstwas ein Block-Zitat, und das geht logischerweise schief.
• Findet Linter am ehesten selbst, und Bots scheiden aus weil manuell der Sinn der Konstruktion beurteilt und ein geeigneter Ersatz gefunden werden muss.
• Vorlage:Zitat beansprucht grundsätzlich die volle logische Breite des Abschnitts und lässt sich (nach links) nicht irgendwie in irgendwelche links-Einrückungen einschließen.

VG --PerfektesChaos 19:19, 3. Aug. 2022 (CEST)

In diesen Artikeln gibt es Zitate in Zeilen, die mit einem der drei Zeichen anfangen:

1. Agudath Israel Weltorganisation
2. Alexandria
3. Alonso de Ercilla y Zúñiga
4. At-Taftāzānī
5. Ayrton Senna
6. Burg Böckingen
7. Eleonore
8. Erzählungen über Lenin
9. Fritz Geiges
10. Ritterstraße (Düsseldorf)
11. Tierrechtsbewegung

-- Gruß, aka 19:31, 3. Aug. 2022 (CEST)

Okay, dann geh ich per Script die anderen Namensräume durch. --Wurgl (Diskussion) 19:48, 3. Aug. 2022 (CEST)

Offtopic: Sind zwar keine Linterfehler, aber Vorlage:Zitat in einer Referenz sieht doch seltsam aus. https://persondata.toolforge.org/vorlagen/?tmpl=Zitat&with_wl&in_r --Wurgl (Diskussion) 20:11, 3. Aug. 2022 (CEST)

Sie ist seit immer schon dafür designed, einen linken Abstand vom linken Rand des Abschnittstextes zu gewährleisten, und links oben zu beginnen. Deshalb klappt auch die Einbindung in den von Mabschaaf ursprünglich beanstandeten Fließtext, und deshalb ist es nicht so gedacht, sie innerhalb von irgendwas anderem einzubauen, das seinerseits schon links einrückt, und deshalb gehen auch die Linter schief, und wenn man da jetzt was dran ändern würde, dann würde auch in rund 4000 Artikeln das Layout abstürzen.

Das war seinerzeit eine tagelange Erforschung von Entlinkt, das robst und sauber hinzubekommen.

Und der Abstand darüber und darunter gehört zum Hauptteil, und ist nicht für ref oder Aufzählungen gedacht. Zumal es weitere Blöcke für zurzeit eine und irgendwann beliebig viele Übersetzungen geben soll, die sich ebenfalls deutlich vom umgebenden Text absetzen müssen, aber die Zusammengehörigkeit untereinander verdeutlichen müssen.

VG --PerfektesChaos 21:23, 3. Aug. 2022 (CEST)

Mach mal Mouse-over bei Einzelnachweis 1 (Am Ende des Einleitungssatzes) Arbeitsgemeinschaft Bergen-Belsen *facepalm* --Wurgl (Diskussion) 21:54, 3. Aug. 2022 (CEST)

1. Diskussion:Malteser (Hunderasse)
2. Benutzer:Matt1971/Wikipedia intern
3. Wikipedia:Löschkandidaten/16. Dezember 2006
4. Wikipedia:Kandidaten für exzellente Bilder/Archiv2007/10
5. Benutzer Diskussion:Nolispanmo/Archiv/2008
6. Wikipedia:Löschkandidaten/4. Februar 2008
7. Wikipedia:Löschkandidaten/9. April 2008
8. Benutzer:WissensDürster
9. Benutzer Diskussion:Geos/Archiv6
10. Wikipedia:Urheberrechtsfragen/Archiv/2009/06
11. Wikipedia:Löschkandidaten/26. Juni 2009
12. Wikipedia:Redaktion Medizin/Archiv/2010/03
13. Wikipedia:Fragen zur Wikipedia/Archiv/2010/Woche 10
14. Diskussion:Animal Liberation. Die Befreiung der Tiere
15. Wikipedia:Administratoren/Anfragen/Archiv/2011/Februar
16. Wikipedia:Fragen zur Wikipedia/Archiv/2011/Woche 33
17. Wikipedia:Löschkandidaten/5. September 2011
18. Diskussion:Alternative für Deutschland/Archiv/001
19. Benutzerin Diskussion:Fallen Sheep
20. Wikipedia Diskussion:Verlinken/Archiv/2013
21. Benutzerin Diskussion:Itti/Archiv/Archiv9
22. Benutzer:TRXX-TRXX/Willy Stahl (Maler)
23. Wikipedia:Löschkandidaten/18. Januar 2014
24. Wikipedia:Löschkandidaten/7. März 2014
25. Diskussion:Befindlichkeitsstörung/Archiv/1
26. Wikipedia:Löschprüfung/Archiv/2016/Woche 14
27. Benutzer Diskussion:Mattes/Archiv 1
28. Benutzer:Hoefler50/Chartreuse des Écouges
29. Benutzerin Diskussion:Itti/Archiv/Archiv29
30. Wikipedia:Qualitätssicherung/16. Januar 2021

Die hab ich noch gefunden. Alles in nowiki, pre, code, und HTML-Kommentaren ist raus. --Wurgl (Diskussion) 21:42, 3. Aug. 2022 (CEST)

Ist abgearbeitet. Linters werden aber wohl nur dann geworfen, wenn per : eingerückt wurde.--Mabschaaf 23:54, 3. Aug. 2022 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Mabschaaf 23:54, 3. Aug. 2022 (CEST)

Unerklärlich auch das hier

Warum wird dieser Fehler nicht gefunden das hat eindeutig veraltete font-Tags

• '''[[hu:User:Bdanee|<font color="#3a8240"><span style="font-family: trebuchet ms;">Dani</span></font>]]'''<span style="position: relative; left: 0; top: -0.5ex; font-size: 1.5ex; line-height: 0;"><sup>[[hu:User vita:Bdanee|<font color="#000000">vita</font>]]</sup>08:11, 1. Aug. 2007 (CEST)</span>

Zudem sollte die Signatur auf der Seite Benutzer:Revolus/Diskussion/1-60#Hungarian Vorlagen-Meister so aussehen:

• Dani^vita08:11, 1. Aug. 2007 (CEST)

und nicht so

• Bye '08:11, 1. Aug. 2007 (CEST)

Ich weiß beim besten Willen nicht, was da auf der Seite zu dieser Darstellung führt und weshalb das font unterschlagen wird, und übrigens auch hier jetzt keinerlei Linterfehler erzeugt wird. --Liebe Grüße, Lómelinde Diskussion 10:27, 28. Jul. 2022 (CEST)

Ne stimmt nicht ganz, nur im Abschnitt wird mir hier kein Fehler angezeigt. Daher hier besser in nowiki gesetzt. --Liebe Grüße, Lómelinde Diskussion 10:31, 28. Jul. 2022 (CEST)

[[hu:User vs. [[:hu:User … mit dem Doppelpunkt am Anfang klappt es. --Wurgl (Diskussion) 11:48, 28. Jul. 2022 (CEST)

Oha da wäre ich jetzt nicht drauf gekommen. Dankeschön. --Liebe Grüße, Lómelinde Diskussion 11:53, 28. Jul. 2022 (CEST)

Ist das hier erledigt? – Doc Taxon • Disk. • 13:52, 22. Aug. 2022 (CEST)

Ja ist es, aber ich hatte es extra noch eine Weile hier stehen lassen, falls andere mal ein ähnliches Problem haben. --Liebe Grüße, Lómelinde Diskussion 14:45, 22. Aug. 2022 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Lómelinde 14:45, 22. 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)

Archivierung dieses Abschnittes wurde gewünscht von: --Wetterwolke (Diskussion) 21:52, 10. Feb. 2023 (CET)

Was machen wir mit diesen?

• 215 angezeigte Felher, wobei jede einzelne Seite mehrere tausend Fehler ausweist wie hier Spezial:Diff/228602367/229697528 sage und schreibe 17.374 Fehler in einer Seite. Der Benutzer fügt stur immer weiter neue Seiten oder weitere Inhalte mit Fehlern hinzu, obgleich er auf die Problematik angesprochen und gebeten wurde, diese Tags nicht mehr zu verwenden, sondern sie zu ersetzen. Korrekturen werden zurückgesetzt, Anfragen nicht beantwortet.
• 131 105 angezeigte Fehler, ähnlicher Fall, auch da stößt man auf taube Ohren →Revert statt Antwort, auch da sind es weitaus mehr Fehler, da ja pro Seite maximal 21 in den Listen erfasst werden.

Ich weiß mir keinen Rat. --Liebe Grüße, Lómelinde Diskussion 15:37, 10. Jan. 2023 (CET)

pssst, das schaffen wir alles schon. Meine Großbaustelle habe ich letzte Nacht erledigt. – Doc Taxon • Disk. • 17:07, 19. Jan. 2023 (CET)

Ich empfehle Salami-Taktik: Widerborstige im BNR, auch BD erstmal umrunden und die Artikeldisk und WP: besenrein machen.

Anschließend die einsame Zeile BNR/BD mit dem nunmehr greifenden Argument angehen, dass sie die letzten Mohikaner wären, und die Transformation der deWP auf die nächste Bewusstseinsstufe behindern würden.

Was genau genommen für veraltetes HTML (außer <font>) nicht gilt. center ist zwar nicht mehr ganz frisch, aber weder strike noch tt noch big richten einen syntaktischen Schaden an.

VG --PerfektesChaos 17:16, 19. Jan. 2023 (CET)

Ich würde mir etwas anderes wünschen, nämlich dass wir es ähnlich machen wie mit prettytable. Wer veraltete Tags einfügt sollte mit einer großen roten Meldung davon abgehalten werden, oder von mir aus auch durch einen Bearbeitungsfilter daran gehindert werden, die Seite zu speichern, in die er das einfügen wollte. Solche Leute interessieren sich nicht für Argumente, da kannst du dir die Finger wund schreiben, da kommt dann nur ‚na und es funktioniert doch was willst du von mir‘. Damit kommen wir nicht auf einen gründen Zweig. Und big ist derzeit auch noch gar nicht im Linterbereich enthalten, ich hoffe das bleibt so. Denn es gibt sehr sehr viele big-Tags. Fatal ist es eben, wenn einige sagen ich darf das und andere dann kommen und sagen was der darf darf ich auch. Würden hingegen ständig fette Meldungen die Seiten verunstalten, dann würden diese Tags vielleicht von ganz allein zurückgehen. --Liebe Grüße, Lómelinde Diskussion 17:45, 19. Jan. 2023 (CET)

5 der Taube-Ohren-Lintfehler habe ich nicht gefunden. Diese Liste ist jetzt einigermaßen leer. Helft Ihr mir beim Reste-Suchen? – Doc Taxon • Disk. • 16:26, 25. Feb. 2023 (CET)

Die 5 sind wech. --Wurgl (Diskussion) 16:42, 25. Feb. 2023 (CET)

Besten Dank – Doc Taxon • Disk. • 17:00, 25. Feb. 2023 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: – Doc Taxon • Disk. • 17:00, 25. Feb. 2023 (CET)

Franz Wilhelm Junghuhn

Linterliste

Wie kann man hier dem Problem Franz Wilhelm Junghuhn eigentlich beikommen? – Doc Taxon • Disk. • 13:13, 5. Feb. 2023 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: – Doc Taxon • Disk. • 09:10, 25. Feb. 2023 (CET)

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)

Ich denke, die sind alle erledigt. --Wurgl (Diskussion) 09:53, 18. Nov. 2022 (CET)

1) findet mit https noch 5

2) und 3) rennen in eine Zeitüberschreitung, alle paar tage tauchen aber ein paar neue auf, zum teil auch nur mit https --Wetterwolke (Diskussion) 12:45, 18. Nov. 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 [3].

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

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)

Diese "doppelt geschlossenen" Kommentare bewirken ein im Artikel sichtbares -->. Das müsste man doch automatisch finden können? Außerdem kann man da wohl nur einen Bot "durch die Lande fegen", also einfach alles lesen lassen der nur zählt, ob zuerst ein <!-- auftaucht, sich dann mit --> abwechselt und mit --> endet. Solange er nichts schreibt, kann er das mit Hochgeschwindigkeit machen und dann nur eine Seitenliste ausspucken. ÅñŧóñŜûŝî (Ð) 22:21, 13. Nov. 2022 (CET)

Ne du ganz so einfach ist es auch nicht, es gibt hier auch Leute, die beispielsweise --> als eine Art Pfeil verwenden, auch in der Form <-- … --> oder <-->. Und eingangs ging er ja mehr um diejenigen, wo das Ende --> fehlt. Etwas fehlendes zu finden ist schon etwas komplizierter. --Liebe Grüße, Lómelinde Diskussion 07:28, 14. Nov. 2022 (CET)

VM

aus der VM vom 21. Januar 2023:

Doc Taxon (Diskussion • Beiträge • gelöschte Beiträge • hochgeladene Dateien • SBL-Log • Sperr-Logbuch • globale Beiträge • SUL • Logbuch • sperren) Obwohl hier ganz klar steht (und das weiss er genau), dass archivierte Seiten nicht dazu gehören, vollgeschützte Seiten auch nicht, tut er ständig unter Missbrauch seiner Adminrechte vollgeschützte Benutzerdiskussionsarchive "korrigieren", heute gerade wieder: hier. --Filzstift (Diskussion) 19:29, 21. Jan. 2023 (CET)

Dazu kommt jetzt noch Editwar: [4]. Es ist mein BNR. --Filzstift (Diskussion) 19:36, 21. Jan. 2023 (CET)

Okay, diese Korrekturen gehören zum Wartungsprojekt HD:LINT, was dahinter steckt, steht sowohl dort als auch auf H:LINT. → zur Kenntnis: Mabschaaf, Lómelinde, PerfektesChaos – Doc Taxon • Disk. • 19:36, 21. Jan. 2023 (CET)

Und was steht im 1. Abschnitt auf H:LINT? Eben, keine Archive und dazu: "Nur vom jeweiligen Benutzer werden Benutzerseiten korrigiert." --Filzstift (Diskussion) 19:39, 21. Jan. 2023 (CET)

Das habe ich gar nicht gelesen. Ich sprech das aber im Projekt mal an. – Doc Taxon • Disk. • 19:46, 21. Jan. 2023 (CET)

---

Was also hat das mit dem genannten Passus auf sich? Oft wird sich beschwert, dass die Änderungen auf Disks und Diskarchiven rückgängig gemacht wird. Jetzt steht es aber ganz oben auf H:LINT, dass diese Seiten eben nicht zu korrigieren sind (ich habe das selbst gar nicht gelesen bis jetzt). Sollten wir nicht bei den Richtlinien bleiben, die sich das Projekt H:LINT selbst setzt? @Mabschaaf, Lómelinde: mich interessiert Euer Statement dazu. Danke sehr, – Doc Taxon • Disk. • 19:51, 21. Jan. 2023 (CET)

Zwar aus dem Artikelraum, aber als Beispiel, wie es aussehen kann, wenn veralterte Syntax nach eine Software-Änderung nicht mehr richtig gelesen würde Spezial:Permanentlink/192180765. Evt. Umfragen oder Meinungsbilder zur Änderung der Richtlinien würden von mir unterstützt. Freundl. Grüsse --Nordprinz (Diskussion) 20:07, 21. Jan. 2023 (CET)

Der ANR ist soweit sauber. Da ist kaum was zu machen. Ich sehe das Problem eher im Satz "sofern Darstellungsfehler auf einen einzelnen Benutzerbeitrag beschränkt bleiben und den Rest der Seite nicht stören." weil das bedeutet, dass man als Korrektor jede einzelne Seite anstarren muss, per Bot geht das nicht. Und weil es auf den Spezialseiten zu den Lint-Seiten keine sinnvolle Filterung gibt, ist das bei der Menge nicht zumutbar. Wenn das so bleibt kann man nur sagen: "Fertig, alles gemacht".

PS: Die Einschränkung "Nur vom jeweiligen Benutzer werden Benutzerseiten korrigiert." sollte eine Klausel für verstorbene/inaktive Benutzer ergänzt werden, wobei das nur sinnvoll ist, wenn man die Spezialseiten irgendwie filtern kann. --Wurgl (Diskussion) 21:07, 21. Jan. 2023 (CET)

Ich meine es war eine Vorgabe von PC dass ich das so schreiben sollte, und er noch weitere Einschränkungen dazu geschrieben hat. Ursprünglich diente das dazu, dass bevorzugt der ANR bereinigt werden sollte, also um potentielle Mithelfende auf den ANR zu leiten, damals war es nicht abzusehen wann allein der ANR jemals bereinigt sein würde. Und es hat ja auch etliche Jahre gebraucht, um da auf den jetzigen Stand zu kommen. Im Grunde habe ich die Seite angelegt und könnte somit den Text auch ändern, da sich nach meiner Meinung die Situation dahingehend geändert hat, dass der Berg von ehemals vielen Millionen Fehlern inzwischen zu einem kleinen Hügel abgeschmolzen wurde. Bei allen Seiten halte ich es für sinnvoll die Fehler zu beheben denn nur dann ist es möglich einer Verschleppung durch Kopien sinnvoll vorzubeugen. Wenn ein Benutzer darauf besteht, dass nur er seine Seiten bearbeiten darf, dann soll er diese Fehler selbst beheben. Das aber lehnt dieser Admin rigoros ab, das halte ich für absichtliche und bewusste Projektschädigung, da er durch sein Verhalten als Admin eine Vorbildfunktion erfüllen sollte, aber durch eben dieses Verhalten andere Benutzer dazu animiert und darin bestärkt sich ebenfalls gegen die Behebung der Fehler zu wehren. Es gibt keinen einzigen plausiblen Grund, weshalb man diese Fehler dauerhaft behalten sollte, einzig eine Simulation auf Seiten, die diese Fehler beschreiben halte ich für sinnvoll. Wenn die Softwaretechniker gewollt hätten, dass der BNR oder Archive ausgeschlossen werden sollten, dann hätten sie ihre Listen entsprechend so ausgelegt. Das ist meine Meinung. Wie bereits im Abschnitt zuvor geschrieben es ist sinnlos da mit Argumenten zu kommen, wer nicht will den kann hier niemand überzeugen, nur und ausschließlich über dicke fette rote Fehlermeldungen, wäre da eventuell Einsicht zu erreichen, aber ich fürchte selbst das wäre vergeblich. Ich finde es absolut beschämend dass ein Admin sich so verhält. Es schadet niemandem, die fehlerfreie Syntax auf seinen Seiten zu haben, es schadet aber dem Projektfortschritt, sich da quer zu stellen. In der en:WP gibt es eine Liste mit ausgenommenen Seiten en:Wikipedia:Linter/Pages with lint errors that should not be fixed da ist keine einzige Benutzerseite erwähnt. --Liebe Grüße, Lómelinde Diskussion 06:45, 22. Jan. 2023 (CET)

+1 zu allem. Ich habe die Vorderseite mal aktualisiert - wobei das natürlich als Vorschlag zu verstehen ist und gerne verbessert werden kann. Ich sehe hier aber dahingehend große Einigkeit.

Hinsichtlich der VM und der nachfolgenden Diskussion sollten wir nicht aus den Augen lassen, dass es -wenn ich mich nicht täusche - um genau zwei Benutzer geht, die sich mit Händen und Füßen wehren. Deren Seiten sollten dann mM vorläufig mal in Ruhe gelassen werden, vielleicht kann man sie ja ganz am Ende doch noch überzeugen.--Mabschaaf 10:28, 22. Jan. 2023 (CET)

Auf Wikipedia:Adminwiederwahl/Filzstift eintragen! Es wird höchste Zeit, dass Seiten mit Lint-Fehlern nicht gespeichert werden können und bei vorhandenen soll eine große Warnung erscheinen. Andim (Diskussion) 10:43, 22. Jan. 2023 (CET)

Zu der vorgeschlagenen Warnung: Nein, bitte nicht. Erst letzte Woche sind neue Fehler hinzugekommen (doppeltes px bei Bildern also 125pxpx; hauptsächlich durch Vorlagen) und es ist zu erwarten, dass weitere hinzukommen. Die Warnung kann man machen, wenn diese Linterfehler stabil sind und keine neuen Typen hinzukommen. --Wurgl (Diskussion) 11:09, 22. Jan. 2023 (CET)

Ich würde nicht gleich so gegen Filzstift auffahren, sondern erst mal nachfragen, was der Grund seiner Haltung diesgegenüber ist. Ich bin mir sicher, dass man mit ihm vernünftig diskutieren kann. @Filzstift: Ich ping Dich an, weil wir mal Deine konkrete Meinung hierzu erfragen und Deine Gegenargumente in Erfahrung bringen wollen. Hast Du eigentlich nur deshalb revertiert, weil die oben genannten Projektrichtlinien nicht eingehalten wurden oder gibt es da auch technische oder spezifische Gegenargumente bzw. sogar persönliche Antipathien (glaub ich jetzt weniger), die Dich so handeln lassen? Ich meine, wir können ja über alles reden, und vielleicht finden wir unter unseren Handlungsweisen sogar eine konsensuale Lösung. Melde Dich hier einfach mal. Danke sehr, – Doc Taxon • Disk. • 11:49, 22. Jan. 2023 (CET)

(BK)Über einen Editfilter sollte man schon langsam nachdenken. Der sollte aber mM nur gaaanz langsam schärfer werden - also zuerst stumm loggen mit nachfolgender freundlicher Meldung auf der Benutzerdisku, dann Warnen beim speichern und schließlich verbieten. Und das auch gestaffelt für die Art des Fehlers. Momentan könnte man bspw. schon obsolete Syntax wie <tt>, <center> und <font> überwachen. Auch könnte man zwischen angemeldeten Nutzern, die es besser wissen sollten, und IPs unterscheiden, bei denen wir toleranter sein sollten.

Generell gilt aber: WP war immer extrem fehlertolerant. Keiner hat irgendwo je per Filter verhindert, dass kompletter Murks in den Quelltext eingebracht wurde (Ausnahme: Spam-Blacklist). Es gehört auch mM zu unseren Grundprinzipien, dass WP leicht bearbeitbar bleiben soll und ein Edit nicht durch automatisch zuschlagende Filter verhindert werden soll. Will sagen: Wir sollten hier nicht per Keule zuschlagen, sondern AGF annehmen und genau abwägen.--Mabschaaf 11:58, 22. Jan. 2023 (CET)

Ich habe jetzt gerade kaum Zeit, daher nur ganz, ganz kurz: In Archiven werden Druckfehler in Büchern nicht korrigiert, HTML-Fehler auf ex. Geocities-Websites und IE-Murks auf archive.org nicht korrigiert. Es ist die Aufgabe der Rendering-SW, mit solchem Murks umzugehen. Heute hat fast jede Website irgendwelche Fehler (man möge nur die Browser-Console öffnen). Hier gilt es, fehlertolerant zu sein. Auf deWP übertragen: Parsoid schluckt vieles. Warum also ums Verrecken hinterherrennen. Im ANR, klar, aber Benutzerdiksussionsarchive und dergleichen? Denn es werden immer neue Dinge kommen, die gleichen Fehler werden stets gemacht. Da beisst die Katze in den Schwanz. --Filzstift (Diskussion) 12:23, 22. Jan. 2023 (CET)

Die Software kann es aber zukünftig nicht mehr richten, dass ist doch der Sinn der Fehlerkorrektur. Das macht hier niemand aus Spaß an der Freud. Und zudem dient das auch dazu, solche Fehler eben nicht ständig zu wiederholen, sondern aus ihnen zu lernen, wie es richtig ist. Die Parsermigration ist noch lange nicht abgeschlossen. Nochmals, was genau ist schlimm daran korrekte, zukunftsfähige Syntax auf seinen Seiten zu dulden? Nenne mir ein nachvollziehbares Argument gegen korrekte Syntax.

Absolut unverhältnismäßig ist es auch Leuten Vandalismus = „absichtliche Projektschädigung“ vorzuwerfen, weil sie sich für die Erreichung des Projektziels engagieren. Der Vergleich mit statischen Archiven hinkt übrigens doch sehr. Du kannst auch Druckwerke nicht mit dynamischen Internetseiten in einen Topf werfen. Zumal ein Druckfehler nicht das Layout einer Seite zerlegt, viele der Linterfehler hingegen schon. Einige schon jetzt andere erst später. --Liebe Grüße, Lómelinde Diskussion 13:32, 22. Jan. 2023 (CET)

Wie gesagt der Text, der da bezüglich der Fehlerkorrekturen stand, stammte nicht von mir, mir war von Anfang an unwohl dabei. --Liebe Grüße, Lómelinde Diskussion 13:49, 22. Jan. 2023 (CET)

Die Prioritäten, die damals gesetzt wurden, waren ja richtig. Jetzt sind wir aber ein paar gewaltige Schritte weiter und damit auch an dem Punkt angelangt, dass wir uns langsam über "reparieren" und "ANR" hinausgehende Gedanken machen sollten in Richtung "verhindern" und "Gesamt-deWP". Gibt es eigentlich irgendwo noch konservierte Werte, mit welchen Anzahlen an Fehlern wir anfänglich zu tun hatten?--Mabschaaf 14:58, 22. Jan. 2023 (CET)

Am 27. März 2021 hatten wir 360924 Fehler ([5]). Andim (Diskussion) 15:51, 22. Jan. 2023 (CET)

Wenn ich den Text so lese, dann hatte Lómelinde eine ganz geheime Privatstatistik. Da gibts vielleicht noch Zahlen von davor. --Wurgl (Diskussion)

Tatsächlich hatte ich mir anfangs die Mühe gemacht die Zahlen der einzelnen Linterfehlerlisten jeden Tag abzuschreiben, um die Veränderungen sehen zu können, da kannte ich aber firefly noch nicht, oder es hatte gestreikt, weiß ich nicht mehr. Das war megamühsam und begann mich dann zu frustrieren, als die Zahlen anfingen nicht mehr richtig anzuzeigen, so zeigten beispielsweise sehr sehr lange die Spezial:LintErrors/obsolete-tag Spezial:LintErrors/obsolete-tag identische Zahlen an, so dass man den aktuellen Stand nicht mehr ablesen konnte oder sie haben einfach nur noch rumgesponnen →Hilfe_Diskussion:Wikisyntax/Validierung/Archiv#Ungenauigkeit in den Listen (2018) dazu muss man sagen, da war die Analyse noch nicht so weit fortgeschritten und es kamen noch einige hunderttausende Fehler hinzu. Im Grunde sah es bei uns mal so aus wie hier. Ich habe aber irgendwann den ganzen Berg Zettel weggeschmissen. Und falls sie das hier inline media caption irgendwann doch noch mal wieder anschalten, dann kommt mal eben eine Million hinzu. --Liebe Grüße, Lómelinde Diskussion 19:26, 22. Jan. 2023 (CET)

@ Update umseitig betreffend Prioritäten und Namensräume

• Ist schon okay jetzt.
• Stammte aus einer Zeit, als wir Millionen von Fehlern hatten, Zigtausende im ANR.
• Gleichwohl ist das Problem mit dem BNR und bei signierten Beiträgen altbekannt. Wenn da eine IP reingeht, ist der Crash programmiert. Braucht im Minimum standing; ggf. auch vorläufige Umgehung gewisser alter Bekannter. Deshalb gab es dort eine Warnung an die blindlings alles anfassenden Massen-Editierer.
• Damals gab es aber auch noch viele Darstellungsfehler, etwa auf Disk <small><small><small><small>. Der ANR; die aktiven Meta-Seiten, aktuelle Diskussionsseiten waren mit Priorität aufzuarbeiten.

@ Zukunft des Wikitextes

• Langfristig soll dieser als Objekt in der Datenbank hinterlegt werden.
• Das entspricht dem DOM in HTML.
  • Das HTML-DOM für dieses Element ist dann sogar unmittelbar Teil des Wiki-Objekts.
  • Wobei die Datenbank das Objekt binär hinterlegt; natürlich nicht serialized oder marshalled wie in XML, JSON oder HTML als eine Zeichenkette dargestellt.
  • Sieht ungefähr aus wie in Spezial:Vorlagen expandieren – {{lang|en|Hi}} eingeben und „XML-Parser-Baum zeigen“.
• Der VisualEditor macht das heute schon: Er baut on-the-fly aus dem Wikitext im Aktionsbereich genau dieses Objekt, arbeitet in dessen Struktur, für Änderungen wird der Bereich in Wikisyntax konvertiert und eingefügt; das Objekt wieder weggeschmissen.
  • Langfristig steht nur das Objekt in der Wiki-Datenbank.
  • Wer auf klassischem Quelltext arbeiten möchte, kann dies anfordern, bekommt es on-the-fly in Wikisyntax konvertiert, mag darauf komplexere Aktionen als das Einfügen von Wörtern ausführen. Zur Vorschau und zum Speichern wird es in Objektstruktur konvertiert und der bearbeitete Quelltext verschwindet anschließend wieder.
• Für eine saubere Transformation ist erforderlich, dass der Inhalt jeder aktuellen Seite in syntaktisch richtiger Struktur vorliegt.
• Historische Syntaxfehler werden sich nicht in der aktuellen Seitendarstellung wiedergeben lassen; fehlerhafte Syntax lässt sich nicht in das Objekt überführen oder daraus reproduzieren.

@ „Parsoid schluckt vieles“ – Filzstift 12:23, 22. Jan. 2023

• Äh, nein. Nicht mehr lange.
• Siehe eben.
• Die PHP-Parser von 2001 bis heute noch schluckten, stellten dar was zufällig dabei rauskam, ob es das Erwartete war lag in Verantwortung der Bearbeitenden, wenn undefinierte Syntax dann konnte zukünftig eine andere Darstellung resultieren, weil es nur für definierte Syntax auch eine langfristige definierte Darstellung gibt.
• Fehlermeldungen gab es früher bis heute nie – „war immer extrem fehlertolerant“ heißt, dass alles ohne Warnung hingenommen wird, und dann wird dargestellt was MediaWiki plus Tidy-Nachbereitung gemäß dessen Heuristik oder momentan Remex-Nachbereitung gemäß dessen Regeln oder eines Tages komplett ohne eine Nachbereitung halt draus machen.

@ Vorgehensweise und mittelfristige Strategie:

• Zwei Wochen Linterpause (Ló) rate ich schon seit Monaten an; da musste ja kirre werden wennste jahrelang nur diesen Mist abarbeitest. Eine Woche LINT, zwei Wochen interessante spaßige andere wichtige Aufgaben, WBW, VWS.
• Schwerpunkt jetzt auf Nicht-BNR-Nicht-BD: Disk, WPNR (=Disk-Foren).
• Das veraltete HTML ist syntaktisch ungefährlich, bis auf das komplett verwirrte <font> und stört das DOM nicht.
  • Legacy-HTML ist Bestandteil des HTML-Standards, und ein altes Dokument, das ausschließlich aus Legacy-HTML besteht muss wie seinerzeit dargestellt werden. Die Mischung von Legacy-HTML und moderner Struktur ist undefiniert, es gibt keine Regeln wie das aussehen und wirken soll, etwa Vererbungsregeln.
  • Gleichwohl soll es so nach und nach aus dem Bewusstsein verschwinden, und zumindest nicht mehr neu eingefügt werden. Ist teils seit 1998, teils seit etwa 2010 obsolet und muss irgendwann mal aus dem menschlichen Bewusstsein verschwinden.
  • Wobei HTML auch mal Kapriolen schlägt und Veraltetes rehabilitiert. Der Trend geht allerdings dann eher dahin, für die Typografie außerhalb von Semantik und Layout nur noch <div> und <span> zu nutzen und den Rest per CSS oder Klassen zu handhaben.
  • War ohnehin nur Anhängsel und gehört bis auf <font> nicht zum eigentlichen Linter-Prozess.
• Tabelle von links nach rechts abarbeiten; echte Syntaxfehler und Strukturmängel bevorzugen.
• Bliebe zum Schluss ein Band im BNR übrig, welches dann bis auf eine vorläufige Ausschlussliste sperriger Privatbesitzer vor sich hingammeln mag, bis das ganze Projekt eines Tages in Objektstruktur migriert; dann verschwinden die Fehler per spontaner Zufallskonvertierung unkontrolliert.

VG --PerfektesChaos 14:05, 23. Jan. 2023 (CET)

Nur mal noch eine Anmerkung bezüglich des oben angesprochenen:

„Und was steht im 1. Abschnitt auf H:LINT? Eben, keine Archive und dazu: "Nur vom jeweiligen Benutzer werden Benutzerseiten korrigiert."“

– Filzstift 19:39, 21. Jan. 2023 (CET)

Archive soll man also auf Teufel komm raus so lassen, wie sie sind. Ernsthaft? →Spezial:Diff/227956592/229989772#Religiöse Dimension des Konflikts es gab schon haufenweise solcher oder ähnlicher Bot-Archivierungsfehler, soll man das wirklich nicht beheben? Ist so etwas wirklich im Sinne dieses Projekts, wenn man solchen Murks so stehen lässt? Und die Bots machen da keine Ausnahme, ob das BNR-Seiten wären oder andere, was sie nicht können, können sie überall nicht. Man sieht es den Fehlern in der Liste auch nicht vorher an, ob sie eine Seite zerstören oder nicht, manchmal folgt die sichtbare Zerstörung erst mit mehr Inhalt, also bei der nächsten Ergänzung.

Ich bleibe dabei, alles soll raus. Zudem kann man auch von Benutzern, die noch niemals etwas von Linterfehlern gehört haben, kaum verlangen, dass sie es selbst beheben, sie wissen ja oftmals gar nicht, was falsch ist. Ziel ist es aber, dass sie es lernen, weil sie im Difflink sehen können, was geändert wurde und wie es richtig aussehen sollte. --Liebe Grüße, Lómelinde Diskussion 15:10, 23. Jan. 2023 (CET)

@PC:

• "Zukunft des Wikitextes" > Du schreibst, dass das künftig als Objekt abgelegt wird.

• Für deWP sicher machbar. Ist halt schon so: Was wäre das Schlimme, wenn es mal ab und zu knallt, d.h. eine Konversion ins Objekt schief läuft (gerade in den hintersten uralten Diskussionsarchiven)? Zumal die VG sicher erhalten bleibt.
• Ich nehme an, das wird optional bleiben und das alte Parser-Tidy-Hacks-Whateverelse-System wird weitergepflegt (man denke an die non-WMF-MediaWiki-Installationen, die würden sonst böse Überraschungen erleben).

@Lómelinde

• Solche Dinge gehören korrigiert, sofern es sich um ANR-Seiten, relevante Projektseiten oder so handelt, keine Frage. Aber man muss nicht jeden Winkel und Ecke der deWP abgrasen, das wäre eine never-ending Story. Man korrigiert alles und dann kommt der nächste und baut die gleichen Fehler wieder rein. Oder die WMF-Leute merken, dass sie was übersehen haben und dann beginnt das Aufräumen wieder von vorne. Das kann man doch sein lassen. Natürlich wird es da und dort knallen, doch, eben, ich würde meinen: Was soll's - bei den Difflinks in älteren VM, AK, LD etc., da knallt es schon längst, das zeigt dein Beispiel oder meine erste AK, den es nur als Difflink gibt, schön, doch wir können damit umgehen. --Filzstift (Diskussion) 15:57, 23. Jan. 2023 (CET)
• Allerdings um des Friedens willen: Da Diskussionsarchvie - wie ich feststelle - , im Gegensatz zu PDF/A nicht unbedingt als "konserviert" zu betrachten sind, habe ich mein System umgestellt. Jetzt darfst du/dürft ihr mal da rüber, mit eurem Ziel, die "Error"-Counter reduzieren zu können. --Filzstift (Diskussion) 15:57, 23. Jan. 2023 (CET)

Danke, das ist eine gute und pragmatische Lösung. Das sollte vielleicht wieder Benutzer:Doc Taxon übernehmen, der schafft das mit weniger Edits, als ich bräuchte.--Mabschaaf 16:45, 23. Jan. 2023 (CET)

@ Filzstift:

• Danke erstmal für die Freigabe; wobei die ja wohl schon mal korrigiert wurden (??) und dann ein Revert durch den Hausherrn langen würde.
• Glaskugelei:
  • Es wird dann das gesamte Wiki von „wikitext“ auf „Objekt“ umgestellt, was die gesamte Datenbankspalte in der Tabelle betrifft, primär für alle Namensräume.
  • Wobei es ein jeweiliges Content Model für bestimmte programmierungstechnische Seiten gibt; also Systemnachrichten, JavaScript, CSS, Lus, JSON. Die natürlich nicht.
  • Wann genau das passieren wird, ob noch in den 2020ern oder erst ab 2030, kann ich nicht prognostizieren.
  • mw: ist vermutlich schon kurz davor.
  • Ein Haken ist der Umfang mit unseren Doppelpunkt-eingerückten Diskussionsforen. Wie das dann auch Smartphone-geeignet in validem HTML dargestellt und als Chatverlauf hinterlegt werden könnte, erproben seit Jahren die DiscussionTools.
  • Aber irgendwann kommt es; kleinere dezentrale Wikis zuerst.

VG --PerfektesChaos 16:57, 23. Jan. 2023 (CET)

Auch von mir Dankeschön für die Freigabe. Aber nochmals, man sieht es den Fehlern nicht im Vorfeld an, ob sie eine Seite zerstören oder nicht. Das sieht man erst wenn man eine Seite aufruft und wenn man dann schon mal da ist kann man es auch gleich beheben. --Liebe Grüße, Lómelinde Diskussion 19:11, 23. Jan. 2023 (CET)

@Filzstift: Zwar danke für die Freigabe. Aber damit wir jetzt alles mühsam noch einmal durchgehen müssen, hast Du also vorsichtshalber mal die vorher bereits bereinigten Versionen entfernt. War das ein Versehen oder willst Du uns ärgern? Vorlage:Smiley/Wartung/zwinker  – Doc Taxon • Disk. • 19:32, 23. Jan. 2023 (CET)

Nein, das war wirklich ein Versehen. Ich hätte die Version mit deinen Korrekturen als Grundlage nehmen sollen. --Filzstift (Diskussion) 22:53, 23. Jan. 2023 (CET)

wie diese seite bearbeiten

Gemeldet in Phabricator
Task T40848

durch den lint-fehler bin ich auf diese schwarze seite gestossen. siehe auch den task. kann jemand dise böse seite ändern? es sollte nicht erlaubt sein ausserhalb des inhaltsbereiches alles schwarzfärben zu können, und alle navigationselemente zu überdecken. gruss, --Wetterwolke (Diskussion) 02:06, 27. Feb. 2023 (CET)

Ich habe es mal abgemildert. --Liebe Grüße, Lómelinde Diskussion 06:29, 27. Feb. 2023 (CET)

vielen dank, ich habe es nicht geschafft das editfeld überhaupt nur zu sehen. gruss, --Wetterwolke (Diskussion) 14:15, 27. Feb. 2023 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: --Wetterwolke (Diskussion) 14:15, 27. Feb. 2023 (CET)

Verschlimmbesserungen bei Umbrüchen in Referenzen und Vorlagenaufrufen

In Geschlechtergerechte Sprache wurde das Tool durch @Darkking3: verwendet, wodurch Wikicode verschlechtert wurde:

• Referenzen in <ref> wurden bewusst auf mehrere Zeilen umbrochen, um besser wartbar zu sein. Dies wurde vom Tool rückgängig gemacht. Dieses Verhalten wird auf der Hilfeseite soweit ich sehe nicht dokumentiert, wäre damit also ein Bug.
• Vorlagenaufrufe von Vorlage:Beispiel starteten den Inhaltsparameter bewusst mit einem Zeilenumbruch nach der senkrechten Linie, damit die Liste korrekt verarbeitet wird. Das Tool hat | hinter den Umbruch verschoben, sodass der erste Listenpunkt nicht mehr richtig erkannt wird.

— Christoph Päper 09:25, 16. Mär. 2023 (CET)

Wovon genau redest du? Die Linterfehlerlisten sind kein Tool sondern Listen mit Fehlern, diese Hilfeseite ist ebenfalls kein Tool, sondern soll bei der Behebung dieser Fehler helfen, indem sie mögliche Fehler beschreibt, um sie leichter erkennen zu können. Ich vermute mal du bist hier falsch. --Liebe Grüße, Lómelinde Diskussion 10:11, 16. Mär. 2023 (CET)

Du solltest dir zuerst einmal angewöhnen, anzugeben, warum du etwas zurücksetzt! Ohne bzw. mit sehr unspezifischem Kommentar wird kein Nutzer deine Gründe erraten können. Im übrigen erfolgt die Syntaxkorrektur händisch, da es aufgrund der sehr unterschiedlich gelagerten Fehlerfälle kein Tool gibt. Die Änderungen, die du meinst, sind Markup-Korrekturen, welche per Tool erfolgen, da Referenzen im Fließtext inline erfolgen sollten, also ohne Umbrüche. --darkking3 ^Թ 10:13, 16. Mär. 2023 (CET)

Ich habe die beiden tatsächlichen Lint-Fehler korrigiert und Vorlage:Beispiel überarbeitet.

Danke für en Hinweis auf WikiSyntaxTextMod. Dessen bevorzugte Quelltextformatierungen für Vorlagenparameter und Referenzen stimmen offensichtlich nicht mit meinen überein. — Christoph Päper 15:22, 16. Mär. 2023 (CET)

Du kannst {{Beispiel}} per TemplateData auch sagen, wie sie im Quelltext dargestellt werden soll. Dies ist vor allem für den Visual Editor interessant. Ob und wie sich das auswirkt, kann ich jedoch nicht beurteilen. Hinweis: Bei {{Mehrspaltige Liste}} reagiert WSTM in der von dir vorgegebenen Weise. Auch sollte Vorlage Beispiel bestenfalls gesprochene Parameter erhalten, um Verwechselungen zu verringern (Doppelt Pipes sieht nicht jeder Nutzer im Quelltext). Eine Möglichkeit zur Bezeichnung enthält die Vorlage ja bereits. --darkking3 ^Թ 17:34, 16. Mär. 2023 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: — Christoph Päper 09:44, 17. Mär. 2023 (CET)

Indizierungsfehler?

Kann es sein, dass die Fehlerseiten nicht ganz mit der Datenbankgröße zurechtkommen? Aktuell gibt gab es hier einen Fehler (Fehlerhafte Dateioptionen), der eigentlich abgearbeitet sein sollte, da die Fehlerseite zuletzt leer war. Ich habe das Gefühl, dass Linter-Fehler erst bei einem notwendigen (neuen) Parsen erfasst werden, sonst könnte ich mir die Diskrepanz nicht erklären. --darkking3 ^Թ 10:15, 14. Mär. 2023 (CET)

Auch bei Wikipedia:GND/Fehlermeldung sind nicht alle Unterseiten mit Fehlern in den entsprechenden Kategorien aufgelistet. Wobei sich hier eher das Erstellen einer (fehlerfreien) Vorlage anbietet, statt die Fehler einzeln zu beheben. --darkking3 ^Թ 10:37, 14. Mär. 2023 (CET)

Ja das ist leider schon seit Jahren so dass diese Spezial:LintErrors spinnen (die Gesamtzahl gerade „18.140 Fehler“ pass dort nicht, es müssten ca. 32.606 sein), einzig der Firefly zählt richtig und aktualisiert die Zahlen in gewissen Abständen, also immer :15 : 35 :55 – für die Kategorien mit wenigen neuen Einträgen passt das aber.

In deinem Fall musste ich allerdings die einbindende Seite einmal purgen, das ist manchmal so, dann geht das auch weg. --Liebe Grüße, Lómelinde Diskussion 10:38, 14. Mär. 2023 (CET)

Das erklärt leider nicht alles, da auch Firefly den Fehler bisher nicht gelistet hatte (Sonst wäre er von dir bestimmt schon behoben gewesen). --darkking3 ^Թ 11:01, 14. Mär. 2023 (CET)

Ja, alles ein wenig dubios. Ich habe gestern auch einen Fehler im ANR beseitigt, in einem Artikel, der seit 2021 nicht angefasst wurde. Vielleicht wurde irgendeine eingebundene Unter-Unter-Vorlage geändert, was zum erneuten Parsen und damit zur Fehlermeldung geführt hat. Aber solange da nur Einzelfälle auftauchen und nicht gerade tausende ist es auch ziemlich latte.--Mabschaaf 11:41, 14. Mär. 2023 (CET)

Doch, ich wollte den Fehler gerade beheben, sah aber, dass du das schon getan hast, während ich noch am bearbeiten war. Danach habe ich dann gepurgt, weil ich weiß, dass solche Einbindungen manchmal etwas hängen bleiben. Als die Serververbindung mal für einige Tage unterbrochen war, da musste ich alle reparierten Seiten (mehrere hundert Fehler) später nochmals purgen, damit der Server merkte da hat sich etwas getan. Das hat fast nochmal so lange gedauert wie die Behebung selbst. --Liebe Grüße, Lómelinde Diskussion 11:48, 14. Mär. 2023 (CET)

Würde es dann nicht Sinn machen, botgestützt *alle 8.159.835* vorhandenen Seiten mal über mehrere Tage/Wochen zu purgen oder den "Frontend"-Cache generell neu aufzubauen? Alternativ ein Datenbank-Backup aller aktuellen Seitenversionen durch die Validierung schieben und alle gefundenen Seiten purgen? Ist vielleicht nicht die schönste Lösung, aber irgendwie nervt es. Wer einen besseren Vorschlag hat, immer her damit. --darkking3 ^Թ 13:20, 14. Mär. 2023 (CET)

Dafür reichen meine technischen Kenntnisse nicht aus. Seiten, die lange nicht bearbeitet wurden, tauchen manchmal noch immer plötzlich in den Listen auf, weil sie bisher nicht analysiert wurden oder, was weiß ich. Es hängen auch noch ein paar von den Fehlermeldungen „Hilfe:Wikisyntax/Validierung#Inline-Medien mit Bildunterschriften“ im Cache herum, habe ich gerade vorhin wieder gesehen, als ich Tschubby sagte, er solle mal seine Unterseiten durchgehen. Diese Fehlerkategorie existiert schon nicht mehr. --Liebe Grüße, Lómelinde Diskussion 13:51, 14. Mär. 2023 (CET)

Nicht nur, dass die Spezialseiten nur beim Neuparsen von Seiten Fehler entdecken, nun erkennt sie nichtmal alle LINT-Fehler auf einer Seite und listet sie auf. Hier zähle ich skriptgestützt 69 Fehler, die Spezialseite listet "nur" 21. Hier gibts Möglichkeiten, am "einfachsten" für uns als einfache User ist wohl per API mit bis zu 500 Seiten je Aufruf. Dann wäre man bei einem Aufruf je Sekunde an einem Tag durch. --darkking3 ^Թ 22:39, 16. Mär. 2023 (CET)

Es sind weniger Seiten notwendig. In der Datenbank gibt es das Feld "page_touched", dieses erhält einen Zeitstempel und der wird bei "action=purge" aktualisiert. Momentan gibt es 1,16 Mio Seiten bei denen dieser Zeitstempel vor Juli 2020 liegt und 2.72 Mio Seiten mit Zeitstempel vor Juli 2022. Der älteste solche Zeitstempel einer Seite mit Linter-Fehlern ist übrigens 20171103140945 und es gibt 8322 Seiten, die einen noch älteren Zeitstempel haben. Diese 8322 würde ich mal purgen, zumindest mit denen anfangen. Und je nach "Erfolg" irgendwann später dann das Datum langsam hochsetzen. Alle 8 Mio Seiten … da hab ich zu viel Mitleid mit den Servern. --Wurgl (Diskussion) 23:00, 16. Mär. 2023 (CET)

Vorher: 35.319 Linterfehler (also Einträge in der Datenbank, kein Schimmer ob ein Eintrag je Seite oder ein Eintrag je Fehler), jetzt 35.336. Dauert übrigens 2 Sekunden je 500er Block, aber ich denke das ist nur das Invalidieren des Cache und nicht das erneute Parsen. --Wurgl (Diskussion) 23:22, 16. Mär. 2023 (CET)

Ich hatte mir schon fast gedacht, dass es nicht so viel bringen wird, da die Seite von Harry8 zuletzt im Januar 2020 bearbeitet wurde. Die Anzahl passt mehr zur Gesamtfehlerzahl, daher ist es vermutlich ein Eintrag je Fehler) Zum Festhalten:

Firefly

timestamp	2023-03-16 22:15:14	2023-03-16 22:35:14
namespace	vorher	nachher
0	4	3
Diskussion	12.693	12.693
Benutzer	10.782	10.782
Benutzer Diskussion	6.766	6.768
Projekt	1.595	1.595
Vorlagen Diskussion	0	1
Kategorie Diskussion	0	12
Portal	0	3
Summe	31.838	31.857

Alles "nur" missing end tags, ich habe die Fehler gar nicht anschauen können, da Andim die bereits behoben hatte. Das mit den Servern ist mir bewusst, daher die zeitliche Einschränkung bzw. auch der Vorschlag, einen Dump zu validieren und die entsprechenden Seiten dann zielgenau zu purgen bzw zu bearbeiten. --darkking3 ^Թ 23:54, 16. Mär. 2023 (CET)

@Wurgl: kannst du in der Datenbank bei den angegebenen 2,72 Mio Seiten nach Namensraum filtern? Idee wäre, z.B. erst alle entsprechenden Seiten im ANR, usw. zu purgen? --darkking3 ^Թ 14:07, 17. Mär. 2023 (CET)

Ich werde über Nacht (wenn es hier ruhig ist und die Zahlen nicht durch zu viele Edits verfälscht werden) ein paar 1000 purgen und neu parsen lassen. Und vorher, zwischen purge und parsen und nachher die Zahlen in der linter-Datenbank-Tabelle ausgeben.

Danach weiß ich was zu tun ist. Momentan ist das ja noch Fischen im Trüben. --Wurgl (Diskussion) 14:16, 17. Mär. 2023 (CET)

Warum warten …

2023-03-17 13:43:55 78 Pages in namespace 9
2023-03-17 13:43:55 4 Pages with linter errors (before)
2023-03-17 13:43:55 4 Pages with linter errors (after purge)
2023-03-17 13:44:05 0 Pages with linter errors (after parse)

Purge ist nix wert. Parsen muss ich und das geht nur einzeln. Wenn du zu Fuß (also im Webbrowser) ein Purge machst, dann ist das Parsen automagisch, schließlich kannst du danach ja die Seite bestaunen und dazu muss sie frisch geparst werden. --Wurgl (Diskussion) 14:48, 17. Mär. 2023 (CET)

Ich bin durch Namespace 0 durch. Ausgelassen hab ich ca. 750.000 Weiterleitungen, in Weiterleitungen sind Formatierungen doch recht ungewöhnlich. --Wurgl (Diskussion) 15:32, 19. Mär. 2023 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: -- Lómelinde 11:14, 7. Apr. 2023 (CEST)

Bot-Unterstützung möglich?

Mal ein Vorschlag zur Diskussion, weil ich denke, dass es ziemlich unmenschlich ist, die >20.000 Fehler auf den Artikel-Diskus alle händisch zu beseitigen.

Könnte man nicht in folgenden Fällen ein Bot zum Einsatz bringen (Beispiel):

• Zeile beginnt mit oder ohne Einrückung/Aufzählung/Nummerierung [Leerzeichen], gefolgt von ''
• Innerhalb der Zeile befinden sich keinerlei andere Tags (oder HTML), nur Plain Text
• Zeile endet ohne ''
• Es ist der einzige Linter-Fehler auf der Seite (→ das intendierte schließende Tag kommt auch nicht drei Absätze später)

Dann könnte man doch per Bot am Ende der Zeile das fehlende '' ergänzen können.

Ich habe keine Ahnung, wie viele Fälle das wären, aber letztlich ist jeder Bot-gestützte Edit hilfreich. In gleicher Weise könnte man das mM auch für ''' und <small>-Tags laufen lassen. Oder übersehe ich was? @Botbetreiber: Wäre das machbar?--Mabschaaf 12:45, 6. Jan. 2023 (CET)

Ist irgendwo eine Liste um die abzuarbeiten? Oder muss ich Spezial:LintErrors/missing-end-tag durchgehen und alle "i" und "b" rausfiltern. API kann zwar nach "missing-end-tag" (ist das das richtige?) filtern, aber wohl nicht mehr. --Wurgl (Diskussion) 12:56, 6. Jan. 2023 (CET)

Wenn es wirklich nur fehlt sollte das gehen aber manchmal ist es auch einfach nur eine Zeile zu tief gerutscht.

• Manchmal sind fett und kursiv vermischt also so ''ich''' und ''du''' da kann man raten wie es werden sollte
• small kann auch mal kaputt sein also </small </smal> </small< </smll> hab ich alles schon gesehen
• bei kursiv gibt es noch ''Text' 'Text'' oder ''Text'# ebenso wohl für fett

natürlich wäre es schön, wenn man einige hundert oder tausend Fälle per bot lösen könnte, aber ich fürchte das wird schwierig. Wir müssen suchen ob wir passende Muster finden. CC: Doc Taxon --Liebe Grüße, Lómelinde Diskussion 13:00, 6. Jan. 2023 (CET)

@Wurgl: Auf Artikeldiskus (warum haben wir für diesen NR eigentlich keine Abkürzung?) gibt es nur noch "missing-end-tags", alle anderen sind erledigt.

@Ló: Deshalb kein anderer Code in der Zeile und keine anderen Linterfehler auf der Seite. Wenn noch ein schließendes Tag irgendwo drei Absätze später kommt, wirft dieses ja noch einen eigenen Fehler. Aber ja, alles was kaputt ist, finden wir nicht, es sei denn, schon irgendein weiteres ' oder < oder > würden auch bedeuten: Finger weg.--Mabschaaf 13:10, 6. Jan. 2023 (CET)

Ja ok, das könnte klappen, wenn man so etwas kann. Es wäre eine echte Erleichterung. Was alllerdings auch sehr sehr häufig vorkommt ist, dass die Leute vor ihrer Signatur ein halbes kursiv gesetzt haben also so Kommentar Antwort Text ''--[[Benutzer:Beispielnutzer|Beispielnutzer]] Das müsste man, so denke ich zumindest filtern können. Ich entferne es meistens nur, da nicht klar ist ob der Test davor oder die Signatur kursiv werden sollte. Hat vermutlich mal irgendjemand so angefangen und viele haben es nachgemacht. --Liebe Grüße, Lómelinde Diskussion 13:43, 6. Jan. 2023 (CET)

Alles, was anders aufgebaut ist, müssen wir getrennt betrachten. Aber es ist natürlich gut, wenn Du gehäuft auftretende Fälle schon mal sammelst. Es wird auch nicht alles per Bot gehen, da bin ich sicher. Aber, wie eingangs schon geschrieben, jeder zählt.

@Wurgl: Schaust Du mal, ob und was da so geht?--Mabschaaf 13:50, 6. Jan. 2023 (CET)

Ich schau mal. 20.000 sind ja wirklich ziemlich unmenschlich ;^) Und außerdem hängen wird damit die enWP ab!!!!111elf --Wurgl (Diskussion) 14:31, 6. Jan. 2023 (CET)

Ja, da muss ich auch mal drüber nachdenken, – ich wollte schon 3 Mal jetzt damit anfangen, immer aber kam irgendwas dazwischen. Hauptsächlich geht es hier also um Artikeldisk-Seiten, ja? Gibt es eine LintError-Seite, die auf i und b rauszufiltern vermag? – Doc Taxon • Disk. • 14:58, 6. Jan. 2023 (CET)

Nein nur die Gesamtliste mit derzeit 21.960 Fehlermeldungen. Es ist möglich sich 5000 Einträge pro Tabelle anzeigen zu lassen und dann könnte man sie nach i oder b sortieren. Die Sortierung bleibt aber nicht bestehen und lässt sich nicht einfach so kopieren, das wären also mindestens 5 4 3 Tabellen.

• 1–5000
• 5001–10000
• 10001–…

Ich kenne zumindest keine andere Lösung. --Liebe Grüße, Lómelinde Diskussion 15:17, 6. Jan. 2023 (CET)

Schade. Das API hat da leider auch nix besseres zu bieten. @Doc Taxon: mach was dazwischen, ich kämpf mich mal durch. --Wurgl (Diskussion) 16:08, 6. Jan. 2023 (CET)

Eigentlich wollte ich nur mal einen kleinen Testlauf mit einfachen Dingern machen, hab die erste Änderung versehentlich gemacht: Spezial:Diff/229556376 war sogar richtig. *schwei von der Stirn wisch* --Wurgl (Diskussion) 16:43, 6. Jan. 2023 (CET)

Sehr schön. --Liebe Grüße, Lómelinde Diskussion 17:02, 6. Jan. 2023 (CET)

ja, sehr gut, weiter so – Doc Taxon • Disk. • 12:09, 7. Jan. 2023 (CET)

30 Änderungen Im Namespace 3 ("Benutzer Diskussion") erstmal. Ein paar Massennachrichten hab ich als Spezialfall inkludiert. Swie/Archiv/2012 hab ich im Bot gefixt. --Wurgl (Diskussion) 12:20, 7. Jan. 2023 (CET)

@Wurgl: Der Link funktioniert nicht.--Mabschaaf 15:44, 7. Jan. 2023 (CET)

Habe ich auch gerade gesehen. -title= --Liebe Grüße, Lómelinde Diskussion 15:50, 7. Jan. 2023 (CET)

Linkfix: Dann halt auf die herkömmliche Weise. --Wurgl (Diskussion) 15:52, 7. Jan. 2023 (CET)

Soweit ich mir die Edits angeschaut habe hast Du viel mehr Intelligenz in deinen Bot gesteckt, als ich oben skizziert hatte. Fehler habe ich keine gefunden. Von meiner Seite also ein klares: Weiter so!--Mabschaaf 15:56, 7. Jan. 2023 (CET)

*grybel* Benutzer Diskussion:Leonie2837 Wenn etwas so überhaupt nicht in meinen Kopf reingeht, dann muss das wohl Kunst sein. (Altes Wurgl-Sprichwort) Und nein, den Linterfehler such ich nicht. --Wurgl (Diskussion) 19:48, 7. Jan. 2023 (CET)

Ja es gibt schon schräge Vögel hier. einfach raushauen oder in pre setzen. --Liebe Grüße, Lómelinde Diskussion 06:37, 8. Jan. 2023 (CET)

Leonies Disk ist aufgewischt – Doc Taxon • Disk. • 19:37, 9. Jan. 2023 (CET)

---

@Wurgl: Kann dein Bot ggf. die ganzen durch Tab-Header erzeugten Fehler beheben? I.d.R. sollte am Seitenende das schließende div-tag fehlen. --darkking3 ^Թ 10:09, 10. Mär. 2023 (CET)

Weiteres: 128 Seiten mit Fehlern aufgrund der Signatur eines Nutzers. Wurde zum Teil schon abgearbeitet. --darkking3 ^Թ 11:06, 10. Mär. 2023 (CET)

@Wurgl, Doc Taxon: ? --Liebe Grüße, Lómelinde Diskussion 08:12, 12. Mär. 2023 (CET)

Naja. Der Bringer war das nicht. Die 128 Treffer haben nur 4 echte Treffer gebracht, der Rest waren Nieten. --Wurgl (Diskussion) 10:19, 12. Mär. 2023 (CET)

Sry dafür, das sah auf den ersten Blick nach einem sinnvollem Botlauf aus. Muss ich das nächste Mal besser hinschauen. --darkking3 ^Թ 12:18, 12. Mär. 2023 (CET)

Es sei dir verziehen ;^) --Wurgl (Diskussion) 12:40, 12. Mär. 2023 (CET)

Der Bot ist durch alle Namensbereiche durch und hat alles vom Typ "wikitext" außer Weiterleitungen vor Juli 2022 mit purge und parse beglückt. --Wurgl (Diskussion) 08:46, 22. Mär. 2023 (CET)

Das erklärt die höhere Anzahl (~ 2,6k) an Fehlern bei firefly im Vergleich zu Ló's Statistik oben. Danke dafür --darkking3 ^Թ 08:50, 22. Mär. 2023 (CET)

Vielen Dank! Vielleicht jetzt noch die Weiterleitungen, ich habe hier schon soviel Mist im Quelltext gesehen. Keine Ahnung was da vielleicht eingebaut wurde. Dann wären wir auf der sicheren Seite. Andim (Diskussion) 09:12, 22. Mär. 2023 (CET)

Willst die Weiterleitungen wirklich? Dort findet sich doch keine Fett- oder Kursivschrift und auch <div> etc. gibts da nicht. Weblinks wohl auch nicht – ja Ausnahmen gibt immer. Ich kann schon, sehe das aber wirklich nur als sportliche Fleißaufgabe an. --Wurgl (Diskussion) 09:34, 22. Mär. 2023 (CET)

Sport ist Mord. Immer her damit, ich wäre auch für ein Purgen. Ich meine, auch schon WL gesehen zu haben, die Vorlagen enthalten. --darkking3 ^Թ 10:45, 22. Mär. 2023 (CET)

Ja, Personendaten & Normdaten gibts recht oft. Und Kategorien. Aber okay, mach ich halt … --Wurgl (Diskussion) 10:56, 22. Mär. 2023 (CET)

Hezlichen Dank! Andim (Diskussion) 21:45, 22. Mär. 2023 (CET)

Ist durch, hat wohl nix gefunden. --Wurgl (Diskussion) 19:52, 23. Mär. 2023 (CET)

---

Ich hab mal diesen Fehler auch noch ausgebaut. Wie weit sind wir denn mit diesem Kursiv-Fall, ist da ernsthaft jemand noch dran? – Doc Taxon • Disk. • 15:56, 12. Mär. 2023 (CET)

---

Ich frage jetzt hier noch mal an, ob diese Art von Fehlern →Spezial:Diff/216207605/232649444 oder Spezial:Diff/232647727 nicht doch mit Unterstützung der Bots behoben werden könnten. Konkret geht es um:

''Text in einer Zeile
''<!-- nichts leer -->

sollte sein

''Text in einer Zeile''
<!-- nichts leer -->

Es gäbe auch noch ähnliche Fälle

''Text in einer Zeile
fortgesetzt in der nächsten Zeile''<!-- nichts leer -->

müsste dann so aussehen

''Text in einer Zeile fortgesetzt in der nächsten Zeile''<!-- nichts leer -->

Leider weiß ich nicht, wie man gezielt danach suchen könnte, das erzeugt immer einen doppelten Fehler und müsste somit auch mit mindestens zwei Einträgen in der Linterliste stehen. Es gibt so etwas natürlich auch mit fett oder fettkursiv. @Doc Taxon, Wurgl: meint ihr das könnte man finden und ersetzen? --Liebe Grüße, Lómelinde Diskussion 11:51, 10. Apr. 2023 (CEST)

Lass mich Dir sagen, liebe Lómelinde, dass wir da dran sind. Es ist bloß kaum möglich, mal 30 Std. oder mehr am Tag dafür zur Zeit zu haben, um alles abzuarbeiten oder Bots zu entwickeln. Der adminonly-Cluster auf der Seite oben verzögert das auch noch. Ich weiß, dass es Dir etwas schwierig fällt, aber versuch's bitte mit etwas Geduld, also mehr Geduld als ohnehin schon. Vertrau uns, wir sind da dran ... – Doc Taxon • Disk. • 15:22, 10. Apr. 2023 (CEST)

Na ja, weißt du, ich habe so das Gefühl, dass die meiste Arbeit doch immer an mir hängen bleibt. Das allein wäre kein Drama, aber ich allein kriege auch immer den Ärger dafür ab, und das nervt schon sehr. Klar, wer viel macht, der fällt eben auch vielen auf. --Liebe Grüße, Lómelinde Diskussion 16:25, 10. Apr. 2023 (CEST)

Kann man so etwas

'''
== Beliebige Überschrift ==
'''

herausfiltern und von einem Bot die unwirksamen fett-Tags entfernen lassen? Beispiel --Liebe Grüße, Lómelinde Diskussion 10:20, 17. Apr. 2023 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: -- Lómelinde 09:09, 13. Jun. 2023 (CEST)

Benutzer:Filomusa/Labor

Gemeldet in Phabricator
Task T333754

Diese Seite lässt sich nicht aus dem Cache bereinigen →Linterfehler, obwohl die Fehler behoben wurden →Spezial:Diff/232351224/232355614. Auch mehrmaliges purgen brachte keinen Erfolg und LintHint gibt Timeout zurück. Hat irgendjemand eine Idee, wie wir sie weg bekommen? Vermutlich hat es etwas mit den vielen Math-Formeln zu tun, die die Seite überlasten. Sie wird auch in dieser Kategorie:Wikipedia:Seiten, die ein veraltetes Format des math-Tags verwenden gelistet, hat also auch andere Probleme. --Liebe Grüße, Lómelinde Diskussion 07:10, 1. Apr. 2023 (CEST)

Ich habe dem Benutzer vorgeschlagen, die Seite ggf. auzuteilen. Ich konnte den Quellcode nur in zwei Teilen per linthint validieren, das passt jedenfalls. Auch ein Nulledit hat leider nichts gebracht. --darkking3 ^Թ 12:14, 1. Apr. 2023 (CEST)

@darkking3: Wo hast Du denn die zwei validierten Teile geparkt? Versuch doch mal, diese zusammenzuführen und jag noch mal linthint drüber. – Doc Taxon • Disk. • 12:35, 1. Apr. 2023 (CEST)

Geparkt nicht: Quelltext kopieren, in andere Seite einfügen und per linthint validiert. Dass ich dabei seitenabhängige Variablen ignoriere, ist klar. Ich glaube aber nicht, dass die auf der Nutzerseite einen großen Einfluss haben. Ich habe auch die Syntaxhervorhebung temporär deaktiviert und per Spezialseite die Fehler direkt angesprungen und keine Fehler sehen können. Beim kopieren hätte ich auch diese Fehler mitkopiert, sodass da eigentlich nichts vorhanden ist. --darkking3 ^Թ 12:46, 1. Apr. 2023 (CEST)

Sie wurden ja auch definitiv behoben. Problem ist wohl der Timeout. Hatten wir früher sehr oft bei den Archiven des WP:Cafes, da lag es an der Seitengröße >2MB. --Liebe Grüße, Lómelinde Diskussion 12:57, 1. Apr. 2023 (CEST)

Ich melde das mal an die Technik-Jungs ... – Doc Taxon • Disk. • 21:53, 1. Apr. 2023 (CEST)

Seit gestern habe wir eine weitere problematische Seite

• Wer weiß denn sowas?/Episodenliste derzeit 21 Fehler ohne, dass da wirklich Fehler sind.

Vermutlich zu viele Vorlagen als Auslöser. --Liebe Grüße, Lómelinde Diskussion 07:45, 3. Apr. 2023 (CEST)

ähm, mir werden da aktuell keine Fehler angezeigt. Und Filomusas Labor läuft lokal sauber durch, in Production aber gibt's Fehlercode 500. Die arbeiten dran und verbessern dabei hoffentlich die Performance. Liebe Grüße – Doc Taxon • Disk. • 05:20, 4. Apr. 2023 (CEST)

Läuft sauber durch kann ich nicht bestätigen, bei mir ist noch immer Timeout. Aber ja gestern haben sie am Cloudserver gewerkelt. Die Phantome aus der Episodenliste sind erst einmal weg (es gab ja auch zwischenzeitlich eine weitere Bearbeitung), die vier Fehler aus dem Labor hingegen nicht. --Liebe Grüße, Lómelinde Diskussion 06:37, 4. Apr. 2023 (CEST)

Ich schrieb, dass das lokal sauber durchläuft, bei WMF auf einer Testkopie. Diese vier Laborfehler sind derzeit Arbeitsgrundlage des WMF-Teams, das ganze zu verbessern. – Doc Taxon • Disk. • 03:14, 5. Apr. 2023 (CEST)

Ach dort ist lokal für mich klang das nach hier. --Liebe Grüße, Lómelinde Diskussion 06:14, 5. Apr. 2023 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: -- Lómelinde 09:09, 13. Jun. 2023 (CEST)

Benutzer:Wrestling Freak

Ich zähle auf der Seite (im expandieren Quelltext) 7 öffnende Tabellen (als html-Tag und in wikisyntax), jedoch werden nur 6 Tabellen geschlossen. Ich erhalte allerdings von LintHint keine Fehlermeldung zu fehlenden end-tags. Füge ich ein schließendes Tag hinzu, bestätigt mir die Syntaxhervorhebung durch ihre Einfäbrung, dass es fehlt. Auch kann ich offensichtlich beliebig viele Tabellen öffnen und verschachteln, ohne dass ein Fehler geworfen wird. Bug oder Feature? --darkking3 ^Թ 22:21, 10. Apr. 2023 (CEST)

Bug denn leider erkennt Linter nur </table>-Tags als fehlend bisher jedoch kein |} Es kommt also immer darauf an, wie der Fehler sich verhält. Teilweise erscheint das dann in den Listen

Spezial:LintErrors/deletable-table-tag oder Spezial:LintErrors/fostered

Beispiele:

Spezial:Diff/231758995#Gedenkstein zur Schleswig-Holsteinischen Erhebung → Spezial:Diff/231762874 zwei öffnende Tabellen und entsprechend fehlende Zellensyntax samt Ende

Spezial:PermaLink/232566091#Einzelnachweise die Tabelle wandert ans Seitenende, weil ihr das Ende fehlt →Spezial:Diff/232566091/232568417#Bus da gehört sie hin

In deinem Fall kommt erschwerend hinzu

1. Das fehlende Tabellenende ist zugleich auch am Seitenende, somit fällt der Fehler nicht auf. Ist identisch zu den zighundert div-Fahlern, die noch auf Benutzerdiskussionsseiten auf und zukommen, wo die Leute unbedingt alles eingerahmt haben wollen und das div unten immer fehlt, nur dass das (weil es ein offizielles Tag ist) Linterfehler auslöst.
2. Es kommt aus einer eingebundenen Vorlage Benutzer:Warhog/Vorlage:Diskussionsseite (die ebenfalls ein offenes Ende hat und den Fehler auslöst). Ganz kompliziert wird es nämlich, wenn das dann mit Vorlagen wie /Oben eingebunden wird, dann wird es bei der Seitenbearbeitung von linhHint nicht mehr gefunden.

Baue mal Benutzer:Warhog/Vorlage:Diskussionsseite mit html-Tags also öffnenden <table> auf und lass lintHint anschließend analysieren, du wirst sehen, dann wird eine Fehlermeldung erfolgen, dass das Ende fehlt.

<table width="100%" cellspacing="0" cellpadding="0" valign="top">
<tr> <!-- SEITE:TABS -->
<td>

für fehlende divs auf Diskussionsseiten aktiver Benutzer weiß ich noch nicht, wie wir da vorgehen sollen, davor graut es mir schon jetzt, denn das Rahmenproblem lässt sich nicht lösen. Beispiel Benutzer Diskussion:Graphikus. --Liebe Grüße, Lómelinde Diskussion 07:36, 11. Apr. 2023 (CEST)

Danke für die doch sehr ausführliche Erläuterung. Ein Bug hätte mir gereicht :) Mich würde (irgendwann!) tatsächlich interessieren, welche Syntax bisher (noch) nicht ausgebessert ist, um zu wissen, was uns noch erwartet… --darkking3 ^Թ 21:15, 11. Apr. 2023 (CEST)

Da gibt es so einiges Beispiel ''Text''' oder '''Text'' erzeugt keinen Fehler. Würde man dafür i/b-Tags verwenden <i>Text</b> oder <b>Text</i> würden Fehler ausgegeben.

Noch ein Fall wo nix passiert {{SEITENTITEL:<span style="color:#ABCDEF;">Hilfe Diskussion:Wikisyntax/Validierung}} das hinten fehlende </span> wird nicht erkannt.

Inwieweit das dann noch irgendwann verschärft wird, weiß ich aber nicht. So etwas ''Text''' passiert leicht, wenn Leute das hier '''Text' weitere Text'' erreichen wollen, das soll dann so aussehen ‘Text’ weiterer Text oder anders so Text weiterer ‘Text’

Hinzu kommen wohl noch alle Tags, die Inlinetags sind und in zwei oder mehr Zeilen beginnen/enden.

<small>
Kleinerer Text
</small>

Wenn mir solche Fehler auffallen, behebe ich auch das immer schon vorbeugend. Insgesamt sieht es erst einmal ganz gut aus bei uns. --Liebe Grüße, Lómelinde Diskussion 09:48, 12. Apr. 2023 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: -- Lómelinde 09:09, 13. Jun. 2023 (CEST)

Modul:Wikidata

Aktuell scheint es für mich so, dass die heutigen Änderungen am Modul dazu führen, dass Vorlage:Navigationsleiste Elitserien (Bandy) Fehler verursacht und damit die Artikel mit reinzieht. Oder gibt es da keinen kausalen Zusammenhang? --darkking3 ^Թ 22:33, 26. Apr. 2023 (CEST)

Nun ja was genau bringt denn eine leere Navigationsleiste? Ich denke schon, dass es da einen Zusammenhang gibt. --Liebe Grüße, Lómelinde Diskussion 07:44, 27. Apr. 2023 (CEST)

hast sich erledigt, allerdings auch doppelt: in der Navileiste die Spans durch divs ersetzt und die Änderungen am Modul zurückgesetzt. --darkking3 ^Թ 12:54, 27. Apr. 2023 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: -- Lómelinde 09:09, 13. Jun. 2023 (CEST)

Verschärfungen

Moin zusammen, gibt es eigentlich irgenwo eine Übersicht, wann und vor allem welche Verschärfungen live genommen werden? Die Woche ja wohl für Gallery? mfg --Crazy1880 11:42, 1. Mai 2023 (CEST)

Weiß ich leider nicht, aber man merkt es immer, wenn sich etwas getan hat und plötzlich neue Fehler auftreten. Gut, dass ich schon vorher immer etliche Bildattribute aus den Galerien gelöscht habe. --Liebe Grüße, Lómelinde Diskussion 13:39, 1. Mai 2023 (CEST)

Bezüglich mini|hochkant und co @Doc Taxon, Wurgl: kann das bitte ein Bot übernehmen diese Bildattribute aus den Galerien zu werfen? Siehe auch #Fehlerauflistung Punkt 3. --Liebe Grüße, Lómelinde Diskussion 13:52, 1. Mai 2023 (CEST)

Mach ich gerne. Alle Namensräume *vermut* --Wurgl (Diskussion) 13:59, 1. Mai 2023 (CEST)

Überall wo du das kannst, es werden aber auch ein paar gesperrte dabei sein, denke ich. --Liebe Grüße, Lómelinde Diskussion 14:02, 1. Mai 2023 (CEST)

Hmm "links"? In BMW E3? Das wird nicht angenörgelt? Kann das weg?

• BMW 2500-E3 Rear-view.JPG|links|Heckansicht (1968–1971)

--Wurgl (Diskussion) 14:53, 1. Mai 2023 (CEST)

Ja natürlich, es hat doch keinerlei Wirkung, du kannst ein Bild nicht rechts, links, oben, unten, was auch immer setzen, wenn es sich in einer Galerie befindet. Daher hatte ich das doch da oben gelistet. --Liebe Grüße, Lómelinde Diskussion 15:03, 1. Mai 2023 (CEST)

Bis auf ANR (mit viel zu vielen Treffern) mach ich alle Namensräume sauber. Im ANR gibts so ungefähr 114.000 Artikel mit Gallery, die ältesten 10.000 hab ich durchrauschen lassen, da waren 53 darunter. Ich bau das aber in den nächtlichen Lauf ein. Da werden täglich zwei oder drei dazukommen. --Wurgl (Diskussion) 10:16, 2. Mai 2023 (CEST)

Super, vielen Dank. --Liebe Grüße, Lómelinde Diskussion 10:28, 2. Mai 2023 (CEST)

Heute sind es wieder recht viele Galerie-mini-Fehler. --Liebe Grüße, Lómelinde Diskussion 17:16, 4. Mai 2023 (CEST)

Einfach liegen lassen! Der Bot macht die in der Nacht. Nur die paar zum Frühstückskaffee sind Kandidaten, die könnten ein anderes Problem haben. --Wurgl (Diskussion) 17:51, 4. Mai 2023 (CEST)

Es nervt. Ich werte gerade den Dump aus und rausch dann mal drüber. --Wurgl (Diskussion) 10:31, 7. Mai 2023 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: -- Lómelinde 09:09, 13. Jun. 2023 (CEST)

Info: übergroße Tabellen

Da scheint es schon wieder etwas neues zu geben →Große Tabellen, die auf dem Handy schlecht zu sehen sind, wo kommt denn das plötzlich her? Firefly kennt es noch nicht und Spezial:LintErrors auch nicht, daher weiß ich nicht in welche Priorität das einsortiert werden wird. --Liebe Grüße, Lómelinde Diskussion 10:39, 11. Mai 2023 (CEST)

Die Kriterien, nach denen einsortiert wird, wäre mir fast lieber. Beim ersten Durchschauen kommen wohl viele Fehler über Vorlagen, sodass das einfacher als gedacht werden könnte. Spitzenreiter ist Vorlage:Verwaltungstabelle FR Kopf mit ~1.350 Fehlern. --darkking3 ^Թ 11:16, 11. Mai 2023 (CEST)

Nein alle Tabellen die mehr als 5 Spalten haben (und das werden sehr sehr viele sein) erzeugen Fehler. Mehr habe ich bisher noch nicht herausfinden können. --Liebe Grüße, Lómelinde Diskussion 11:22, 11. Mai 2023 (CEST)

Stimmt, das mit den 5+ Spalten konnte ich nachvollziehen. Meiner Meinung nach können "wir" solche Linterfehler gar nicht sinnvoll beheben, da das ein inhaltliches und kein Syntaxproblem ist. Z.B. gibt es Infoboxen, die aus gestalterischen Gründen 12 Spalten haben, bei denen alle Zeilen über rowspan anders zusammengefasst werden, um eine passende Tabellenaufteilung zu erhalten. Die Hoffnung kann noch sein, dass die prio noch unter low liegt und deshalb die Spezialseite noch nicht einsortiert wurde. (was ich aber nicht glaube) --darkking3 ^Թ 12:03, 11. Mai 2023 (CEST)

Ich hatte in der Technikwerkstatt angefragt, erst einmal ignorieren (was mir schwer fällt) --Liebe Grüße, Lómelinde Diskussion 12:54, 11. Mai 2023 (CEST)

„Since it's not 100% clear how to solve this problem, this should be a hidden linting rule so that editors are not made aware of pages with lint problems that they cannot fix.“ (phab:T334528). Da freut man sich echt, wenn für einen Skin eine weitere Lint-Seite hinzukommt. --darkking3 ^Թ 14:16, 11. Mai 2023 (CEST)

Nur mal ganz dumm gefragt, wie werden Benutzer denn sonst beim editieren auf die Fehler aufmerksam gemacht? Was soll mir der Satz denn sagen?

„Solange nicht zu 100 % klar ist, wie dieses Problem zu lösen ist, sollte es eine versteckte Linterregel sein, so dass Bearbeiter nicht auf Seiten mit Linterproblemen aufmerksam gemacht werden, die sie nicht beheben können“ was soll das denn dann? →phab:T336316 “We are looking for tables that break out of the limited width and/or on mobile break the viewport. Identify false positives and note down what is common between them.”

Gehen die wirklich davon aus, dass man alle Fehler aus den Listen einzeln über die jeweiligen Links anspringt und korrigiert? Da würde ich ja zu gar nichts kommen und manche Seite hundert mal bearbeiten müssen bis alle weg sind, beispielsweise hier 698 Fehler, das würde die Server belasten und die Versionsgeschichte unnötig aufblähen.

Und ja ich habe ein Problem damit Fehlermeldungen zu sehen und den Fehler nicht beheben zu können. Das frustriert nämlich. --Liebe Grüße, Lómelinde Diskussion 14:40, 11. Mai 2023 (CEST)

Da kommen glaube ich gerade zwei Dinge aufeinander: Der eine möchte eine versteckte LINT-Fehlerseite, der andere setzt die Seite "einfach" um und führt diese nur in der Zusammenfassung nicht auf. Dass aber LINT-Editoren häufig Tools zur Anzeige verwenden und per Benutzer-CSS Klassen anzeigen, wurde nicht berücksichtigt. Richtig wäre wohl eine LINT-Seite, ohne dass im Quelltext die entsprechenden Klassen gesetzt werden. Das wird aber vermutlich nicht möglich sein. --darkking3 ^Թ 14:56, 11. Mai 2023 (CEST)

Ich hatte echt Panik, als ich das vorhin zufällig angezeigt bekam. Und es stört mich wirklich, dass sie einen damit immer völlig allein lassen. --Liebe Grüße, Lómelinde Diskussion 15:07, 11. Mai 2023 (CEST)

 Info: Scheinbar haben sie es hinbekommen, dass die Phantom-Fehler zwar weiterhin für die Entwickler gelistet, aber nicht mehr von lintHint ausgewertet werden, so dass das nicht mehr unmittelbar bei der Seitenanalyse stört. --Liebe Grüße, Lómelinde Diskussion 07:02, 2. Jun. 2023 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: -- Lómelinde 09:09, 13. Jun. 2023 (CEST)

BNR vermeiden?

Erneut wird, diesmal in einem Abschnitt auf meiner Benutzerdisk zwischen @Lómelinde, Kurator71, aufgezeigt, was eine Lintfehlerkorrektur auf BNR-Seiten auf der negativen Seite nach sich ziehen kann. Nach reiflicher Überlegung bin ich mittlerweile der Meinung, dass Lintfehlerkorrekturen auf BNR-Seiten nur vollzogen werden sollten, wenn der Benutzer nicht mehr aktiv ist oder er den Wunsch von sich aus heranträgt. Dies sollte dazugehörige Archivseiten mit einschließen. Ist der Benutzer aktiv, sollten wir es ihm selbst überlassen, ob er seine Fehler auf seinen Seiten beheben will. Spätestens wenn die Seiten ab HTML5 kaputt sind, wird der Benutzer das schon richten oder richten lassen, das sehen wir aber spätestens dann. Viele Benutzer fühlen sich "gegängelt" (mir selbst ist das eigentlich unverständlich, ist aber so) und andere wünschen die Handanlegung in ihrem BNR schon grundsätzlich nicht. Eine Kooperation zwischen vielen Benutzern in diesem Bereich ist sowohl aus subjektiven als auch aus objektiven Gründen auf der deutschsprachigen Wikipedia kaum vernünftig möglich, in anderssprachigen Wikipedien seh ich eine grundlegend tolerantere Einstellung diesbezüglich – dies müssen wir nun einmal akzeptieren. Deshalb würde ich an die in diesem Wartungsprojekt beteiligten Mitarbeitenden appellieren, künftig wie ich eben vorgeschlagen habe zu verfahren. Danke, – Doc Taxon • Disk. • 10:28, 13. Jul. 2023 (CEST)

Nur um das klarzustellen, mir ging es nicht um die Lint-Fehler-Korrektur. Das könnt ihr ruhig machen, auch in meinem BNR. Wurgl macht das ja häufiger mal und mich stört das nicht. Mir ging es um Auftreten und Ton von Lómelinde in Umgang mit Importartikeln in meinem BNR (und auch in anderen BNRs). Das war komplett daneben. Ich hab aber auch da kein Problem, wenn mich Import-Admins wie du oder Frank Murmann ansprechen, ob ich diesen oder jenen Artikel noch brauche. Liebe Grüße, --Kurator71 (D) 10:36, 13. Jul. 2023 (CEST)

 Kontra Das hat absolut gar nichts mit Linterfehlern zu tun, es geht um Wikipedia:Importwünsche/Wartung‎, dass sich darunter auch ab und zu Seiten mit Linterfehlern befinden hat nichts mit der Redundanz von BNR und Artikeln oder verwaisten Importen zu tun. Lady Whistler hatte sich damals diese Wartung der Importe gewünscht und es wären da wohl längst nicht so viele Altlasten aufgelaufen, wenn sie nicht leider verstorben wäre. Bitte hier nichts vermengen.

Und ich stimme dir Doc Taxon da nicht zu, die Fehler gehören überall repariert, damit sie weder Kopiert noch in den ANR verschoben werden können. Manche der Benutzer sehen diese Fehler als unwichtig an, einige sind nicht bereit sie zu beheben oder beheben zu lassen, weil „frisst kein Heu“, andere sind schlicht damit überfordert, viele, ja wirklich sehr viele, bedanken sich für die Reparaturen, ich denke nicht, dass man das aufgrund der wenigen, aber dann lautstarken Benutzer aufgeben sollte, die sich um Wartung keinerlei Gedanken machen. Ich würde mir eher mehr Rückhalt durch die Adminschaft wünschen, das nämlich beeindruckt diese Benutzer mehr. Es hilft diesem Projekt nicht diesem Wunsch einiger weniger Benutzer nachzugeben. Wir sind wirklich so kurz vorm Ziel, da kann ich deinen Einwand nicht nachvollziehen.

@ Kurator71, es ist kein gutes Zeichen von kooperativer Zusammenarbeit, dass du dir nur durch Admins etwas sagen lässt. Dann hoffe ich mal dass diese dir nahelegen die Redundanzen in deinem BNR zu bereinigen, dann ist allen geholfen. Adminwartung = Wikipedia:Importwünsche/Wartung‎ wäre eigentlich auch Adminaufgabe, ich unterstütze auch da lediglich den Prozess. --Liebe Grüße, Lómelinde Diskussion 11:13, 13. Jul. 2023 (CEST)

Es geht nicht um Admin oder nicht Admin, es geht um deinen Umgang mit Autorinnen und Autoren und den oberlehrerhaften Ton, das ist alles andere als ein kooperativer Ansatz und vertreibt Autorinnen und Autoren. Was in meinem BNR ist, ist meine Sache, das ist meine Arbeitsplattform. Gegen die Korrektur von Lint-Fehlern/Vorlagenfehlern o. ä. im BNR (kommt bei mir eher selten vor) habe ich überhaupt nichts und darum ging es nie. Hier ist aber der falsche Ort für die Diskussion. --Kurator71 (D) 11:44, 13. Jul. 2023 (CEST)

 Kontra Linterfehler sind weiter zu beheben. Wenn wir jetzt anfangen, einen Namensraum auszunehmen, stellt sich die Frage warum man die anderen Namensräume bereits vollständig bereinigt haben. Damit diskreditiert man seine eigene sowie die Arbeit der anderen beteiligten Nutzer, die bereits nicht unwesentlich Zeit und Energie in die Behebung der Fehler gesteckt haben.

Besonders ggü. empfinde ich das als undankbar, da sie wer weiß wieviele Anfeindungen auf ihrer Disk und sonstwo aushalten musste und nun überlegt wird, den Namensraum einfach so zu belassen. Auch stellt sich die Frage, ab wann man einen Benutzer als inaktiv bezeichnen möchte. Ich habe die Tage ein Konto gesehen, was nach mehr als 10 Jahren Pause wieder editierte.

OT: Davon abgesehen, glaube ich schon, dass Lo das sicherlich etwas freundlicher hätte formulieren können. Ich bin mir aber sicher, dass dies mit den ganzen früheren Anfeindungen ihr ggü zusammenhängt und sich das mit etwas Zeit wieder bessern wird. --darkking3 ^Թ 12:22, 13. Jul. 2023 (CEST)

Ich wiederhole mich, das Speichern von Versionen mit Lint-Fehlern gehört technisch blockiert. Ich kann in einem Softwareprojekt auch keine Versionen einstellen, die sich nicht kompilieren lassen. Andim (Diskussion) 11:18, 13. Jul. 2023 (CEST)

@Andim: Das funktioniert nicht, weil das Lint-Fehler-System erst eingeführt wurde, als es die fehlerhaften Versionen schon gab.

Das würde schon funktionieren, die bestehenden Versionen bleiben bestehen, erst bei einer Bearbeitung wird korrekte Syntax verlangt. Nebeneffekt, das Zurücksetzen auf fehlerhafte Versionen wird verhindert. Andim (Diskussion) 15:37, 13. Jul. 2023 (CEST)

@Lómelinde: Es ging ausgangs um Importwünsche, später in der Diskussion bezog sich Kurator aber auf Lintfehler und seine Behebungspraxis. Beim Kopieren des fehlerhaften Krams in den ANR wird der Lintfehler gelistet und kann im Rahmen einer Korrektur behoben werden, das ist nicht problematisch, und dann kann sich der Benutzer oder Hauptautor auch nicht mehr beschweren. Von wem sich ein Benutzer etwas sagen lassen will oder nicht, ist übrigens ganz seine Sache, sollte durch seine Handlungen Vandalismus o.ä. entstehen, wird der Benutzer administrativ angesprochen bzw. bekommt bei Eskalation Auflagen. Im Rahmen der Lintfehlerkorrektur halte ich das aber für sehr unwahrscheinlich. Wir sollten die Benutzer und ihre Arbeitsweise respektieren, diese sollten aber auch die Korrektoren respektieren. Bei entstehenden Konflikten sollte eine objektive Diskussion im vernünftigen Stil aber immer möglich sein. Es gibt auch ganz viel Literatur darüber, wie man Konflikten eskalationsfrei begegnen kann. – Doc Taxon • Disk. • 11:46, 13. Jul. 2023 (CEST)

Du hast das hier angesprochen, es ging dabei nie um Linterfehler, ich hatte lediglich zu deinem einen angesprochenen Import eine Liste weiterer veralteter Importe hinzugefügt und um Bereinigung gebeten. Ich weiß echt nicht was das hier zu suchen hat. Und nein, es ist nicht richtig, dass hier jeder machen kann, was er möchte solange es in seinem BNR steht, und das weißt du auch. Es wäre daher nett wenn du dich darum kümmerst, dass seine Seiten aus der Wartung kommen. Damit wäre, wie gesagt allen geholfen. --Liebe Grüße, Lómelinde Diskussion 11:54, 13. Jul. 2023 (CEST)

Meinetwegen, dann ist das so. Und wenn Du möchtest, kannst Du von mir aus auch gerne so weiter machen, wie bisher. Ich gehe jetzt so vor, wie ich das oben beschriebe habe, weil ich darin ein insgesamtes Verbesserungspotenzial sehen konnte, und zwar für beide Seiten. – Doc Taxon • Disk. • 12:00, 13. Jul. 2023 (CEST)

Jein, es ging mir weniger um die Lint-Fehler, sondern generell darum, wie einige "rumwarten". Die Lint-Fehler zu beheben, ist ja sinnvoll, weil technisches Problem. Ob man das im BNR machen muss, weiß ich nicht, ich kann nicht beurteilen, wie die Community das so sieht. Ich beobachte aber immer häufiger, wie komplett unsinnig in Kleinstedits totaler Blödsinn "gewartet" wird, in dem z. B. Leerzeichen durch   ersetzt werden, Punkt an das Ende von Refs gesetzt werden o. ä. Zeug. Ich beobachte nicht ohne Belustigung, wie einer kommt und etwas wartet und ein paar Wochen der nächste im Artikel aufschlägt und genau diese Änderung wieder auf meinen Text zurückändert. Mich nervt das gar nicht so furchtbar, aber viele Autorinnen und Autoren stört das zunehmend und das ist nicht gut. Grüße, --Kurator71 (D) 12:06, 13. Jul. 2023 (CEST)

@Kurator71: Ja, ich komm auch regelmäßig ins Grübeln, was diese Kleinstkorrekturen sollen. (Und dann gibt's da noch die WP:KORR-Verstöße.) Zum Ref-Ende-Punkt: Benutzt man unsere sinnvollen Vorlagen {{Literatur}} und {{Internetquelle}}, gibt es gar nicht erst das Muss, die Refs zu korrigieren. Aber es werden ja sogar die Parameter-Anordnungen und -Reihenfolgen innerhalb definiert parametrierten Vorlagen "korrigiert". Das ist absoluter Nonsens, da weiß jemand nicht, wie er seine Zeit anders besser vertrödeln kann. – Doc Taxon • Disk. • 12:45, 13. Jul. 2023 (CEST)

Parameter-Anordnungen und -Reihenfolgen werden bei mir skriptbasiert verändert und dies auch nur, wenn ich wegen anderer Fehler eine ANR-Seite bearbeitet. Dabei werden allerdings auch Altlast-Aliase bei den Parametern behoben, (z.B. zugriff durch abruf ersetzt) sowie weitere Kleinigkeiten korrigiert. --darkking3 ^Թ 12:49, 13. Jul. 2023 (CEST)

Ja vielen Dank auch für das abwertende „rumwarten“. Und zuvor schon das abwertende, sogar zutiefst beleidigende „verschlimmbessern“, obwohl das, was ich dort verbessert hatte absolut korrekt war, denn 1947 gab es definitiv keine ISBN Immerhin hast du die Änderungen nicht zurückgesetzt. Muss das also wirklich sein, dass du mich auch noch beleidigen musst, geht es dir jetzt besser? Gut, schwamm drüber. Mag ja sein, dass manche hier Wartung als lästíg empfinden, ohne diese würde hier aber einiges megagrottig aussehen. @ Doc trittst du da jetzt auch noch nach du weißt dass das von WSTM kommen kann. --Liebe Grüße, Lómelinde Diskussion 12:51, 13. Jul. 2023 (CEST)

@Lómelinde: Nein, ich trete nicht nach, ich habe Dich weder direkt angesprochen noch gemeint. Und soweit ich das mitbekommen habe, machst Du so was auch nicht. "WSTM" habe ich öfter schon gehört, aber tatsächlich kenne ich das gar nicht. Wenn es dafür ein Projekt gibt oder was zum Reinlesen, bin ich für Links dankbar. So wie ich das rauslese, hat @Kurator71 auch nicht Dich mit "rumwarten" gemeint, und verschlimmbessern sah ich auf dieser Seite bisher gar nicht. Dass Du keine Verschlimmbesserungen vornimmst, ist uns, so denke ich, allen klar. – Doc Taxon • Disk. • 13:00, 13. Jul. 2023 (CEST)

Link zu WSTM --darkking3 ^Թ 13:05, 13. Jul. 2023 (CEST)

@ Doc, was er meint, das weiß er sicher besser als du, und hier der Link Zitat Kurator71: „Ich möchte dir damit sagen, dass du zukünftig die Finger aus meinem BNR lässt und mich in Ruhe lässt (und nicht noch Artikel verschlimmbesserst)“ und natürlich hat er mit „rumwarten“ auch mich gemeint, da ich ihn ja auf seiner Disk auf die Importwartung angesprochen habe. = „unnötiges belästigendes rumwarten“. Er würde das ja nicht hier derart betonen, wenn er nicht mich meinen würde. Das, was du hier jetzt angestoßen hast, bringt die Linterfehlerwartung zusätzlich in Misskredit, vielen Dank auch, ich habe Monate, wenn nicht sogar bereits Jahre meines Lebens für die Behebung dieser Fehler geopfert, das ist also der Dank. Aber nun möchte ich, dass dieses Bashing hier aufhört, räume das ab. Mein Beitrag war zweigeteilt Teil 1 Beleidigungen durch Kurator71 rumwarten“ und „verschlimmbessern“, Teil 2. Frage an den Doc. --Liebe Grüße, Lómelinde Diskussion 13:16, 13. Jul. 2023 (CEST)

Tja, austeilen aber nicht einstecken können. Ich meinte dich, aber nicht ausschließlich dich, insbesondere das "rumwarten" war allgemein gemeint. Mir geht es um das generelle Problem. Seit gestern erreichen mich zahlreiche Nachrichten, die fordern, dass sich was ändern muss. Und selbstverständlich war vieles daran eine Verschlimmbesserung. Die Herausnahme einer ISBN bei einer fortlaufenden Publikation, dis bis heute erscheint, ist vollkommen unsinnig und nahe am Vandalismus. Genauso wie dein Kommunikationsverhalten über den Artikeltext und die Zusammenfassungszeilen. Du wolltest einfach provozieren. Ich hab das nicht zurückgesetzt, weil ich dabei bin, Artikel zu schreiben. Und für mich ist die Diskussion hier zu Ende, weil sie an dieser Stelle stört und nicht hierher gehört. --Kurator71 (D) 13:31, 13. Jul. 2023 (CEST) P.S. Gibt ja auch positive Beispiele für Wartungen, wie Wurgl oder darkking (und sicher mehr, die mir gerade nicht einfallen)...

Für mich ist die Diskussion auch zu Ende, sie scheint nicht zielzuführen. – Doc Taxon • Disk. • 13:50, 13. Jul. 2023 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Wetterwolke (Diskussion) 17:47, 15. Jul. 2023 (CEST)

div

• Alles nur noch div-Problemfälle diese sind nur noch durch Admins und gezielte Ansprache zu beheben, Normalbenutzer haben da keine Chance, insbesondere, da einige der verbliebenen Diskussionsseite von Administratoren (auch ehemalige) sind, und andere sind einfach unbelehrbar. Das hier Spezial:Diff/235109747/235110251 wird vermutlich auch revertiert werden. @Doc Taxon, Mabschaaf: --Liebe Grüße, Lómelinde Diskussion 11:22, 2. Jul. 2023 (CEST)

Ja, SpBot hat es wieder kaputt gemacht [6], Andim (Diskussion) 08:13, 4. Jul. 2023 (CEST)

Es ist sinnlos das </div> auf Diskussionsseiten mit Archivierung ans Seitenende zu setzen, zumal diese Rahmen in der Form für Diskussionsseiten komplett ungeeignet sind. Graphikus habe ich vor einer gefühlten Ewigkeit bereits mehrmals, wenn ich mich recht erinnere, auf diese Problematik hingewiesen. Sinnlos, da ich keine praktikable Alternative anbieten kann wird Syntaxmurks in Kauf genommen. Gilt auch für die anderen. Wenn irgendwo auf der Seite ein Rest von Hintergrung und Rahmen verbleiben soll, muss dies oberhalb der tatsächlichen Diskussionsbeiträge geschlossen werden. Aber ich habe echt keinen Nerv mehr dazu, diese Benutzer anzusprechen, weil sie mich dann eh ignorieren es revertieren und es sie absolut nicht interessiert, dass sie dadurch Fehler erzeugen. Die einzige Chance die ich sehe ist eine Ansprache durch einen Admin, denn das hat mehr Gewicht als wenn einer von uns das versucht. --Liebe Grüße, Lómelinde Diskussion 08:32, 4. Jul. 2023 (CEST)

Habt ihr bereits darüber nachgedacht, die Botbetreiber anzusprechen, sodass diese das DIV in der letzten Zeile nicht archivieren? Wie sieht es mit templatestyles aus, könnten diese etwas bringen? Oder vielleicht auch das div oben schließen und per css bis zum ende benutzerinhalt ziehen? --darkking3 ^Թ 08:47, 4. Jul. 2023 (CEST)

Das Problem ist, wenn jemand auf einer Diskussionsseite einen Abschnitt hinzufügt wird dieser von der Software automatisch nach unten gesetzt, er landet also unter dem schließenden </div>, das ärgert den Benutzer und er entfernt es wieder.

Ich bin keine Programmiererin, alle die ich bisher gefragt habe, haben mir gesagt dass es technisch nicht möglich sei solche Rahmen hier für Diskussionsseiten zu verwenden. Gut das war bevor ich je etwas von templatestyles gehört habe. Doc Taxon kam schon mal auf die Idee das mit einer unten offenen Wikitabelle zu lösen, da das ja derzeit noch keine Linterfehler erzeugt, wohlgemerkt derzeit und auch nur wenn man Tabellen mit Wikisyntax erzeugt mit <table>…</table> gibt es aber bereits solche Linterfehler. Die Software müsste also das </div> am Seitenende als festen Bestandteil der Seite erkennen und neue Diskussionen immer da drüber setzen, da es aber auch andere schließende </div> dort geben könnte (Massennachrichten, Newsletter, Einladungen, …), würde dadurch eventuell mehr zerstört als alles andere.

Wenn dir eine praktikable Lösung einfällt, nur zu. Ich kann das jedenfalls nicht. --Liebe Grüße, Lómelinde Diskussion 08:59, 4. Jul. 2023 (CEST)

ein ping an @Hgzh, XanonymusX: mit bitte um einschätzung ob es grundsätzlich unter vertretbarem aufwand möglich wäre benutzer diskussionsseiten per templatestyles mit einer hintergrundfarbe oder rahmen zu versehen? manche benutzer hängen sehr dran und verzichten nur widerstrebend drauf oder behindern gar die abarbeitung der lintfehler. gruss, --Wetterwolke (Diskussion) 15:28, 5. Jul. 2023 (CEST)

Das hatte ich vor längerer Zeit schon einmal erörtert, ich glaube, mit Doc Taxon. Um die ganze Seite zu erwischen, müsste mw-parser-output modifiziert werden, TemplateStyles greifen aber erst eine Ebene darunter. Da bräuchte es wohl eine Softwareänderung, sodass alle (Benutzer-)Diskussionsseiten noch in ein zusätzliches div gehüllt werden, aber die hier angesprochenen Modifikationen sind sowieso nicht im Sinne der leichteren Zugänglichkeit von Diskussionsseiten, daher wäre eine solche Änderung eher nicht erwünscht. --XanonymusX (Diskussion) 15:43, 5. Jul. 2023 (CEST)

ok danke, für die antwort! dann ist das leider keine lösung. gruss, --Wetterwolke (Diskussion) 18:50, 5. Jul. 2023 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Wetterwolke (Diskussion) 21:16, 13. Aug. 2023 (CEST)

Tabellenfehler auf der bearbeitungsgeschützten Seite Benutzer:Thogo/Archiv/2007/I

Hallo (vor alllem @Doc Taxon),

im Abschnitt Baerenorden der bearbeitungsgeschützten Seite Benutzer:Thogo/Archiv/2007/I scheint ein Tabellen-End-tag fehlen. Im Folgenden sollten laut Quelltext noch viele weitere Abschnitte folgen, die alle nicht angezeigt werden. Da scheint also noch mehr im Busch zu sein. Magst du @Doc Taxon da mal draufschauen? MfG, Dwain 13:33, 10. Okt. 2023 (CEST)

@Dwain, das hat etwas mit includeonly zu tun

<includeonly>--[[Benutzer:Viele-baeren|Problembaeren]]   <small> <sup> [[Benutzer_Diskussion:Viele-baeren|?!?]]   [[Benutzer:Viele-baeren/Orden|BO]]  [[Benutzer:Viele-baeren/Viele-baeren|VB]] </sup> </small> 21:31, 8. Feb. 2007 (CET)</noinclude>

ändern in

--[[Benutzer:Viele-baeren|Problembaeren]] <small><sup>[[Benutzer_Diskussion:Viele-baeren|?!?]] [[Benutzer:Viele-baeren/Orden|BO]] [[Benutzer:Viele-baeren/Viele-baeren|VB]]</sup></small> 21:31, 8. Feb. 2007 (CET)

Dann sollte es sichtbar werden. --Liebe Grüße, Lómelinde Diskussion 06:46, 11. Okt. 2023 (CEST)

Vielen Dank Ihr beiden, die Seite ist jetzt repariert. Liebe Grüße, – Doc Taxon • Disk. • 12:07, 11. Okt. 2023 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: – Doc Taxon • Disk. • 12:07, 11. Okt. 2023 (CEST)

Wir haben 0 LintErrors!

Was passiert nun. Ab wann wird es die Migrierung geben (oder müssen dafür auch alle anderen Sprachversionen auch keine LintErrors mehr haben)? MfG, Dwain 18:02, 23. Sep. 2023 (CEST)

Nächste Woche erstmal nix.

• Die Migration wurde 2017 gestartet, und angeführt von irgendwas wie 50 Millionen oder was Syntaxproblemen in der enWP.

Es muss einen gewissen Grundstock kleinerer und größerer echter Wikis geben, um programmtechnisch die nächste Stufe zu zünden.

• Wir und nl-Wikibooks sind wohl die ersten unter den größeren Wikis.
• Es dürfte von firefly nicht erfasste kleine Wikipedien mit 1000 Artikeln oder so geben, die vielleicht nur wenige 100 LintErrors hätten, und die irgendwer als externe Hilfe vielleicht polieren mag.
• Wikisource sollten im Haupt-Namensraum relativ sauber sein; ein Wiktionary arbeitet stark mit Vorlagen und schematisierten Inhalten ohne Privatgeschmack-Gebastel, hat aber vielleicht alte Diskussionsseiten.

Wenn es einen gewissen Bestand an sauberen Wikis gibt, wird man vermutlich einen Konfigurationsschalter pro Wiki dafür einführen.

• Der würde dann zunächst mal eher nur bewirken, dass Fehlermeldungen direkt angezeigt werden.
• Das hatte es in unserer Kindergartenzeit nicht gegeben. Aus der eingetippten Syntax kam irgendwas bei raus, und wenn das wie gewünscht interpretiert wurde war es fein. Die Verantwortung lag bei der Quelltextbearbeitung. Weil das oft ziemlicher Käse war, hatte unter den Bedingungen von HTML.4 Tidy nach privater externer Logik geraten was das heißen soll. Weil bei ungültiger Syntax aber nicht vorhersagbar ist, was durch die Regelverletzung herauskommt, hatte die Validierung zum Ziel, alle ungültigen Wikitexte zu bereinigen.
• Wenn durch Konfigurationsschalter bekannt ist, dass das Wiki sauber sein soll, dann kann begonnen werden, bei jedem detektierten Syntaxfehler sofort eine Fehlermeldung darzustellen.
• Sowas geht grundsätzlich nicht, solange noch ein verseuchter Altbestand vorliegt. Das ist mit unseren Vorlagenprogrammierungen genauso: Bevor nicht (im Namensraum) alle Einbindungen bereinigt wurden, kann nicht für alle einschließlich anonymer Konten eine Fehlermeldung aufpoppen.
• Weil in einem Altbestand nicht plötzlich 50 Millionen Fehlermeldungen auf nahezu jeder Seite erscheinen dürfen, sind zunächst die Fehlersituationen in der LintErrors-Datenbanktabelle hinterlegt worden, ohne dass von ihnen in der Seite etwas zu bemerken wäre.
• Genau die gleichen Fehlersituationen können aber jetzt sofort bei uns als entsprechende Fehlermeldung auch in der Seite dargestelt werden, weil sie ja nur durch eine gerade eben erfolgte Bearbeitung entstanden sein könnten. Die LintErrors-Datenbanktabelle würde man jedoch intelligenterweise unverändert beibehalten, weil über ihre Kategorien projektweit zu den betroffenen Seiten navigiert werden kann.

Die letzte Stufe würde dann sein, die Datenbank durch einen weiteren Konfigurationsschalter zu erweitern auf ein zusätzliches Feld pro Seitenversion.

• Historisch wurde ein Wikitext abgespeichert.
• Wenn der VisualEditor benutzt wird, dann wird dieser in ein XML-artiges binäres Objektmodell wie ein „DOM“ überführt, der VisualEditor arbeitet in diesem Wiki-DOM, und generiert daraus beim Zurückschreiben wieder (sauberen) Wikitext.
• Die Zukunftsvision ist es, nur das binäre Objektmodell in der Datenbank zu speichern.
• Wenn der VisualEditor startet, kann er es direkt nutzen.
• Wenn eine Quelltextbearbeitung gestartet wird, dann wird aus dem Objektmodell ein Wikitext generiert, bereitgestellt, und wenn syntaktisch interpretierbar dann wieder als Objektmodell abgespeichert.
• Das Objektmodell kann grundsätzlich niemals einen Syntaxfehler enthalten, und jede Darstellung ist vorhersagbar immer korrekt und reproduzierbar.
• Die historischen Seitenversonen von vor der Migration blieben als reiner Wikitext erhalten.
• Diskussionsseiten mit :-Syntax sind da auch noch so ein Drama. Vielleicht käme sowas erstmal nur für den Haupt-Namensraum oder eine entsprechende Liste.

VG --PerfektesChaos 14:13, 24. Sep. 2023 (CEST)