Hilfe Diskussion:Wikisyntax/Validierung

Automatische Archivierung

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

Statistik

1. April 2024, 8:15

Namensraum	Missing end tag	Sonstige	Gesamtzahl
Artikel	0	0	0
Benutzer	154	185	339  ▲
Sonstige	2	30	32  ▲
Gesamt (alle)	156	215	371  ▲

Aktuelle Zahlen: https://fireflytools.toolforge.org/linter/dewiki

Outstanding linter errors bis 2023

Datum	en	de
Aug. 2018	24.083.947	1–5 Mio ???
Juni 2020	?	543.675
Juli 2021	22.450.097	321.470
März 2022	13.845.831	209.724
Juni 2022	11.248.900	152.810
Juli 2022	11.116.651	140.491
Nov. 2022	8.890.312	79.387
Feb. 2023	5.998.634	39.874
März 2023	3.996.924	31.800
14. Mai 2023	3.783.540	16.734
2. Juni 2023	3.771.213	12.562
2. Juli 2023	3.732.077	6.662
3. Aug. 2023	3.735.151	4.367
1. Sep. 2023	3.713.188	2.648
21. Sep. 2023	–	0
4. Okt. 2023	3.694.329	0
3. Nov. 2023	3.678,942	329⁠
2. Dez. 2023	3.617.472	0

ab 2024

Datum	en	de
3. Jan. 2024	3.466.188	1
1. Feb. 2024	3.421.157	57
1. März 2024	3.386.682	166
1. April 2024	3.358.445	371

¹ 

Durch neue Fehleranalyse fehlendes Tabellenende |}

Adminonly

...

ListeriaBot

• ListeriaBot erzeugt immer wieder unvollständige Syntax. Er betreut zahlreiche Listen und fügt eine maximals Anzahl an Zeichen in Tabellenspalten ein, ist darin Syntax enthalten, die erst nach dieser Anzahl an Zeichen geschlossen wird, so erzeugt das immer wieder neue Fehler, das muss irgendwie abgestellt werden. Ich hatte das schon mal bei einigen Benutzern angesprochen, es passiert aber wohl nichts.

• Beispiele: Holger1959, Derzno … fehler behoben und vom Bot wieder eingefügt Spezial:Diff/232694462/next das ist irgendwie sinnlose Mühe. @Doc Taxon, Wurgl: habt ihr, als Botbetreiber eine Idee, wie man das lösen kann? --Liebe Grüße, Lómelinde Diskussion 18:55, 17. Jun. 2023 (CEST)

Brutale Holzhammer-Methode: Bot sperren. Da muss der Betreuer des Bots reagieren. --Wurgl (Diskussion) 19:11, 17. Jun. 2023 (CEST)

@Wurgl: Das kriegen wir nicht hin, ListeriaBot müssten wir damit mindestens global sperren. Und ListeriaBot ist ja eigentlich schon hilfreich. @Magnus Manske:: bitte schau Dir das Problem mal an und melde Dich, was wir oder Du tun können. Ich versuche, den Kontakt mit Magnus herzustellen. Danke sehr, – Doc Taxon • Disk. • 19:44, 17. Jun. 2023 (CEST)

Ich muss nicht alles verstehen. Die Russen haben ihn dicht gemacht. --Wurgl (Diskussion) 19:47, 17. Jun. 2023 (CEST)

Das Problem ist nicht der Bot, er macht genau das, was er soll: nämlich bestimmte Informationen bei Wikidata abgreifen und als Liste darstellen. Die jeweils in Rede stehende unvollständige Syntax ist an den einzelnen Wikidata-Objekten hinterlegt. Soweit ich es überblicke, liegt es an der dort begrenzten Zeichenzahl in der Beschreibung. Die Bereinigung muss jedenfalls dort individuell erfolgen – oder noch besser: gleich im Vorfeld beim überwiegend automatisierten Anlegen der Wikidata-Objekte bitte nicht diese unvollständige (abgeschnittene) Syntax in den Beschreibungszeilen hinterlegen. Solange das dort nicht passiert, wird der wirklich tolle ListeriaBot immer wieder die dortigen Informationen abgreifen und unverändert 1:1 in den hiesigen Listen darstellen - mit den hier dargelegten unerwünschten Effekten. Grüße, --Kleeblatt187 (Diskussion) 20:34, 17. Jun. 2023 (CEST)

Es ist wirklich unschön, dass Fehler aus anderen Projekten quasi nach hier importiert und dadurch vervielfältigt werden. Die Listen verursachen ja nicht nur dort Probleme, sondern fluten auch die Kategorie:Wikipedia:Maximale Seitengröße durch Vorlageneinbindungen überschritten, auch das habe ich schon mal angesprochen, es passiert aber leider nichts. Den tieferen Sinn diese Listen hier bei uns zu führen kann ich auch nicht erkennen. Datensammlungen gehören, meiner Meinung nach, nach Wikidata und nicht zusätzlich nochmal nach hier. --Liebe Grüße, Lómelinde Diskussion 06:36, 18. Jun. 2023 (CEST)

Wobei das in Wikidata nicht zu einem Fehler führt. Wikidata ist json und kein wikitext. --Wurgl (Diskussion) 08:41, 18. Jun. 2023 (CEST)

Na ja in Wikidata gibt es auch tausende Linterfehler, zumindest laut firefly. --Liebe Grüße, Lómelinde Diskussion 08:55, 18. Jun. 2023 (CEST)

Unterscheide diese Items/Properties von den Diskusionsseiten, Kategorien etc. Da ist jedenfalls nix: https://www.wikidata.org/w/index.php?title=Q41238923&action=info und die deutsche Beschreibung hat diesen abgeschnittenen Text mit unabgeschlossenem "Kursiv" – wobei ich das als kursiv interpretiere, wikidata macht das ja nicht. --Wurgl (Diskussion) 09:34, 18. Jun. 2023 (CEST)

Ah jetzt verstehe ich was du meinst, danke für die Info. --Liebe Grüße, Lómelinde Diskussion 09:41, 18. Jun. 2023 (CEST)

Hallo zusammen, sorry dass der Bot Probeleme bereitet. Wenn ich das richtig vertehe, baut er kaputtes Wikipedia-Markup aus Item-Beschreibungen ein? Ich werde es mir mal angucken. @Lómelinde:: Der Bot überschreibt die komplette Liste bei jedem Update. Das steht so auch oben am Anfang der Liste :-) --Magnus Manske (Diskussion) 11:40, 19. Jun. 2023 (CEST)

Daher steht es ja hier als „Problemfall“, weil man das nicht dauerhaft von hier aus lösen kann. Weshalb solche Datenlisten allerdings nicht direkt in Wikidata angelegt und gepflegt werden, muss ich nicht verstehen, oder? --Liebe Grüße, Lómelinde Diskussion 11:51, 19. Jun. 2023 (CEST)

Solche Listen gibt's auch auf Wikidata, aber die Primärquelle für alle Listen sind die Items. Du kannst gerne zum Wikidata-Item gehen und die deutsche Beschreibung dort verbessern, dann wird das auch überall in den Listen so geändert. --Magnus Manske (Diskussion) 12:30, 19. Jun. 2023 (CEST)

Nein, ich werde nicht auch noch in anderen Projekten anfangen Fehler zu beheben, die ich nicht erzeugt habe. Es reicht, dass ich hier bei uns seit 2017 fast nichts anderes mache als Linterfehler zu beheben. Irgendwann muss auch mal gut sein. --Liebe Grüße, Lómelinde Diskussion 12:55, 19. Jun. 2023 (CEST)

Update: Repariert, glaube ich... --Magnus Manske (Diskussion) 12:30, 19. Jun. 2023 (CEST)

Na dann hoffen wir mal, dass das hilft. --Liebe Grüße, Lómelinde Diskussion 12:55, 19. Jun. 2023 (CEST)

Danke auch von mir! „Repariert“ ist schön bescheiden: M.E. ist das vielmehr ein nützliches Funktionsupgrade, da ja am Bot eigentlich nichts kaputt war. Er kann jetzt noch mehr. Davon unbenommen: Wenn der ListeriaBot einmal über alle Listen hinweg ist, müssten damit tatsächlich eine ganze Menge der Lint-Fehler in den Benutzerseiten-Listen weg sein, zumindest wenn sie auf falsch hinterlegte Syntax in der Beschreibung bei den einzelnen Wikidata-Objekten zurückzuführen sind. Was aber zum manuellen Nacharbeiten bleiben dürfte, sind einige Mega-Listen, die der Bot wegen „Memory overkill“ schon seit Monaten nicht mehr aktualisieren kann. Dann nützt dann auch die individuelle Bereinigung an den Wikidaten-Objekten nichts mehr ... Grüße, --Kleeblatt187 (Diskussion) 19:11, 20. Jun. 2023 (CEST)

Ja das ist ein noch anderes Problem viel zu umfangreicher Listen, die ja mit jedem Uodate noch weiter anwachsen, da streikt dann auch anderes. --Liebe Grüße, Lómelinde Diskussion 06:40, 21. Jun. 2023 (CEST)

Bei den Mega-Listen: Die Listen soweit leeren, wie der Bot sie gefüllt hat und dann "einfach" neu erstellen lassen? Oder passiert da auch bereits nichts? --darkking3 ^Թ 08:38, 21. Jun. 2023 (CEST)

Ich hab da vor längerer Zeit mal geguckt. Die Listen haben eine Anfangs und eine Ende-Markierung. Wenn die Ende-Markierung nicht (oder falsch) gesetzt ist, dann wird immer hinten drangepappt. Aber wie gesagt, das ist schon länger her, das kann in der Zwischenzeit gefixt sein. --Wurgl (Diskussion) 15:03, 21. Jun. 2023 (CEST)

Ist leider nicht erledigt. →Holger1959 wobei dieser Benutzer seit 2017 hier nicht mehr aktiv ist Spezial:Beiträge/Holger1959 und man daher, meiner Meinung nach, all seine betroffenen Unterseiten leeren (Auskommentieren) könnte. Das würde auch die Kategorie mit den übergroßen Seiten merklich entlasten, und die Server sowieso, weil die ständige Aktualisierung dann wegfallen würde. Fußabdruck und so --Liebe Grüße, Lómelinde Diskussion 07:12, 24. Jun. 2023 (CEST)

Fehler in den Lint-Listen

Liebe Leute! Auch in Bezug auf den Abschnitt oben drüber, aber eigentlich generell: Bitte gebt uns hier bekannt, welche Fehler in den Lint-Fehlerlisten Eurer Meinung nach fehlen bzw. gelistet sein sollten. Es gibt ein Team, dass sich mit den Lintfehlerlisten beschäftigt, dem wir berichten können, um das ganze noch zu verbessern und auszubauen. Vielen Dank, – Doc Taxon • Disk. • 16:41, 12. Apr. 2023 (CEST)

Willst Du verhindern, dass sich Ló in Kürze aus Verzweiflung dem Fixen von toten Weblinks oder Akas Fehlerlisten zuwenden muss? ;-)

Aber ich habe da mal was eingetragen...--Mabschaaf 16:57, 12. Apr. 2023 (CEST)

@Mabschaaf: hast Du zu Fehler 1 und 2 Beispiele? – Doc Taxon • Disk. • 19:19, 12. Apr. 2023 (CEST)

Im ANR wird sowas schnell korrigiert, aber auf Diskus jede Menge: zu #1, zu #2 (um die Vorkommen mit ungleicher Anzahl öffnener/schließender Klammern zu finden, muss jemand mit mehr Regex-Kenntnissen als ich ran).--Mabschaaf 19:26, 12. Apr. 2023 (CEST)

Noch eine Anmerkung zu Punkt 8. Es handelt sich hier nicht um Vorlagen sondern um Parserfunktionen und es betrifft vermutlich alle also auch so etwas wäre denkbar {{SORTIERUNG:<span style="color:#FEDCBA;">Taxon, Doc}} warum auch immer. Hier noch ein Beispiel für SEITENTITEL Benutzer:Wahrerwattwurm verwendet vier öffnende aber nur drei schließende span-Tags. {{SEITENTITEL:<span style="font-family:Palatino">Benutzer:<span style="color:green;">W</span>ahrer<span style="color:green;">w</span>att<span style="color:green;">w</span>urm}} --Liebe Grüße, Lómelinde Diskussion 07:22, 13. Apr. 2023 (CEST)

Fehlerauflistung

1. Fehler: [[[[<Wikilink>]]

   Beispiel: Beispiel

   [[Benutzer:[[emeko|emeko]] weitere Beispiele (Ló)

2. Fehler: [[<Weblink>]

   Beispiel: Beispiel

3. Fehler: Dateiattribute in Galerien

<gallery> yellow card.svg|mini|Attribut mini, thumb, miniatur yellow card.svg|hochkant|Attribut hochkant, upright yellow card.svg|mitte|Attribut links, left, rechts, right, mitte, oben, unten, ohne, zentriert … |Nur Bildlegende aber kein Bild </gallery>

Attribut mini, thumb, miniatur Attribut hochkant, upright Attribut links, left, rechts, right, mitte, oben, unten, ohne, zentriert …

4. Fehler: Spezial:LintErrors/tidy-whitespace-bug, ich meine, da war mal was, also, dass diese Fehler noch nie aufgetaucht sind, obwohl es sie geben müsste, die hatten wir schon mal alle behoben →aber … man sieht es am Datum es gibt wieder welche. Ansonsten merke ich mir das nicht, weil es ja keine Fehler auslöst, wie soll man da wissen, dass da Fehler sind? --Liebe Grüße, Lómelinde Diskussion 18:04, 12. Apr. 2023 (CEST)

ich seh schon, es ist etwas schwierig, diesen Eingaben ohne Erklärung zu folgen. Ich denke, es geht um das letzte Leerzeichen in der geschweiften Doppelklammer? Warum ist das problematisch? – Doc Taxon • Disk. • 19:19, 12. Apr. 2023 (CEST)

schau ins Archiv Hilfe_Diskussion:Wikisyntax/Validierung/Archiv#Leerzeichenfehler es kann zu Darstellungsfehlern führen. --Liebe Grüße, Lómelinde Diskussion 19:41, 12. Apr. 2023 (CEST)

ah, ich erinner mich, danke – Doc Taxon • Disk. • 23:00, 12. Apr. 2023 (CEST)

5. Fehler: <ref>Text Text <!-- </ref> Nicht abgeschlossener Kommentar in einem Einzelnachweis, hat zur Folge dass alle nachfolgenden Einzelnachweise weg sind, also innerhalb des Kommentars. --Wurgl (Diskussion) 19:32, 12. Apr. 2023 (CEST)

   Sollte das nicht generell für alle Seiten mit <!-- ohne --> gelten?--Mabschaaf 19:52, 12. Apr. 2023 (CEST)

   Ja schon, aber sowas <ref>Text Text <!-- </ref> --> entdeckt man nicht so schnell. Im anderen Fall ist der Artikel doch deutlich kürzer, das sieht man viel schneller. --Wurgl (Diskussion) 20:50, 12. Apr. 2023 (CEST)

6. Fehler: verschachtelte Tabellen, die nicht geschlossen werden.

{|
|
{|
|

Kann zu Darstellungsfehlern führen Beispiel, wenn das Tabellenende nicht zeitgleich das Ende der Seite ist.Meldung durch Benutzerin:Lómelinde

7. Fehler: Formatierungen wie ''Text''' oder '''Text'' erzeugt keinen Fehler.

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’ Meldung durch Benutzerin:Lómelinde

Das halte ich persönlich nicht zwingend für einen Fehler, da das Apostroph letztendlich ein Apostroph ist. --darkking3 ^Թ 22:08, 12. Apr. 2023 (CEST)

das wird mit b und i als fehlendes End-Tag, in diesem Fall dann zwei fehlende, mit abgefrühstückt (hatte ich so schon x Mal unter den Fingern). – Doc Taxon • Disk. • 22:56, 12. Apr. 2023 (CEST)

invalid, das sind eigentlich keine Fehler: bold and italic dürfen innerhalb einer Zeile verschachtelt sein – Doc Taxon • Disk. • 00:41, 13. Apr. 2023 (CEST)

8. Fehler: Fehlende, schließende Tags in {{SEITENTITEL: }}.
   Gemeldet in Phabricator
   Task T334632

{{SEITENTITEL:<span style="color:#ABCDEF;">Hilfe Diskussion:Wikisyntax/Validierung}} Meldung durch Benutzerin:Lómelinde

Gilt mindest auch für Fett und Kursiv. --darkking3 ^Թ 22:08, 12. Apr. 2023 (CEST)

check

Magic Word "Displaytitle" wird zurzeit nicht richtig geparset, wie es eben sollte. Seit einiger Zeit wird daran schon gearbeitet, dann sollte das Lintlisting-Problem quasi automatisch behoben sein. – Doc Taxon • Disk. • 15:45, 13. Apr. 2023 (CEST)

9. Fehler: alle Tags, die Inlinetags sind und in zwei oder mehr Zeilen beginnen/enden.

<small>
Kleinerer Text
</small>

Meldung durch Benutzerin:Lómelinde

10. Fehler: Tags um Bilder wie gefettete Bildeinbindungen → Land Berlin und ähnliche Fälle (kommt besonders häufig auch in Babelbausteinen Parameter letter code) vor, gleiches gilt für span, small, big, s … Bilder kann man nicht durchstreichen Gesamtwertung Tour de France [Ló 08:38, 13. Apr. 2023 (CEST)]
11. Fehler: Mehr als eine Zeile "|+" in einer Tabelle. Details siehe hier: Hilfe_Diskussion:Tabellen/Archiv/2019#Doppelte_Titel_und_Darstellungsfehler --Wurgl (Diskussion) 10:54, 13. Apr. 2023 (CEST)
12. Fehler: quasi als Pendant zu div-span-flip <small><div style="color:#FF0000;">ein in smalltags eingeschlossenes div</div></small>
    ein in smalltags eingeschlossenes div
    es kann auch alle anderen Inlinetags betreffen (Beispiele) Ló 19:06, 15. Apr. 2023 (CEST)
13. Fehler: eingerückte Tabellen (Beispiele) Ló 17:13, 16. Apr. 2023 (CEST)

::: {| class="wikitable"
|-
! Überschrift !! Überschrift !! Überschrift
|-
| Beispiel || Beispiel || Beispiel
|}

14. Fehler: Wird ein Graph in einer Tabelle ohne Zeile eingebunden, erzeugt dies keinen Fehler (Falsch verschachtelter Inhalt), Siehe z.B. Spezial:Diff/232618356/next und Spezial:Diff/232943812; Aufgefallen durch die Abschaltung von Graph

{| class="float-left" style="padding-top:2.5em; margin:0.1em; clear:none;"
{{Graph:Chart
 | width=120
 …

Das gilt übrigens auch für <gallery></gallery> Tags,

{| class="float-left" style="padding-top:2.5em; margin:0.1em; clear:none;"
<gallery>
yellow card.svg|gelbe Karte
</gallery>
|}

wie ich soeben getestet habe. Ló 14:41, 19. Apr. 2023 (CEST)

Und ebenfalls für <inputbox></inputbox> Spezial:Diff/31236928 --Ló 16:04, 23. Mai 2023 (CEST)

15. Fehler: mehrfaches "id" In Ironman findet sich das Konstrukt <sup class="fussnoten-marke reference" id="FN_5_back"><a href="#FNZ_5">5</a></sup> 23 mal. "id" muss eindeutig sein, siehe https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/id --Wurgl (Diskussion) 16:24, 21. Apr. 2023 (CEST)
16. Fehler: Falsche Verschachtelung von Klammern [[Datei:Junghuhn Quersc(…)|230px|{{Center|Quer(…)java]]}} Siehe auch Spezial:Diff/233053556 --Wurgl (Diskussion) 09:04, 22. Apr. 2023 (CEST)
17. Fehler: Ähnlich wie beim font→Hilfe:Wikisyntax/Validierung#Altes Verhalten von Link-Wrapping-Font-Tags, wenn span-color-Anweisungen außerhalb von Links stehen, insbesondere bei Signaturen fiktives Beispiel: <span style="background:darkblue; color:gold;">[[BD:Beispielnutzer|Diskussion]]</span> sollte sein [[BD:Beispielnutzer|<span style="background:darkblue; color:gold;">Diskussion</span>]] = Diskussion oder bisher unbeanstandet Ralf ¿•Kãʄʄchen•? → <span style="color:maroon; class=texhtml"> [[Benutzer_Diskussion:Ralf Roletschek|¿•Kãʄʄchen•?]]</span> ¿•Kãʄʄchen•? sollte sein  [[Benutzer_Diskussion:Ralf Roletschek|<span style="color:maroon;">¿•Kãʄʄchen•?</span>]] ¿•Kãʄʄchen•? Ló 08:55, 8. Mai 2023 (CEST)
18. Fehler: ignorierte Tags alleinstehendes </p> Beispiele gilt ebenso für </ref> und ich füge hier mal auch noch falsche references mit ein →<references \> Ló 17:45, 8. Mai 2023 (CEST)
19. Fehler: Wird <small> innerhalb eines Links geschlossen, ist dies ein fehlendes End-Tag. Da aus einem vorherigen Fehler (siehe eins drüber) schließende Tags offensichtlich ignoriert werden, ist dies aus meiner Sicht kein fehlendes End-tag, sondern falsch verschachtelter Inhalt. <small>[[Benutzer Diskussion:Hosse|'' Talk''</small>]]; Diff; das gilt ebenso für Kursiv-Tags, jedoch werden zwei Fehler für fehlende end-Tags geworfen Diff --darkking3 ^Թ 10:38, 10. Mai 2023 (CEST)
20. Fehler: Syntax in Alternativtext von Wikilinks wird falsch behandelt: ''T<small>est''</small>. ist falsch verschachtelt; [[Test|''T<small>est''</small>.]] ist ein fehlendes End-Tag. Das schließende Tag wird ignoriert, siehe auch die beiden Fehler hierüber. --darkking3 ^Թ 15:45, 10. Mai 2023 (CEST)
21. Fehler: Durcheinander in Tabellensyntax führt dazu, dass für die Leser sowas wie „style="background…"“ oder „style="text-align:left“ sichtbar ist. Hab heute ca. 30 dieser Fehler korrigiert. --Wurgl (Diskussion) 16:19, 13. Mai 2023 (CEST)
22. Fehler Klammern [] im Weblink [http://www.example.org/ Linktext wird durch [Klammer] zerbrochen] fällt nur auf, wenn der Linktext kursiv gesetzt wurde. Ló 17:54, 28. Mai 2023 (CEST)
23. Fehler: eingerückte references-Tags Spezial:Diff/62955026 nach links verschobene und defekte Darstellung mit • vor dem ↑ deutlicher zu sehen wenn es mehrere refs sind →Spezial:PermaLink/229158856#cite note-4 Ló 09:09, 13. Jun. 2023 (CEST)
24. Fehler: Tabelle beginnt außerhalb von "Datei:" und endet innerhalb. Fehler sieht man im VE: https://de.wikipedia.org/w/index.php?title=Wahlen_zum_Repräsentantenhaus_der_Vereinigten_Staaten_1894&veaction=edit&oldid=229600536 (runterscrollen) Difflink: Spezial:Diff/229600536/234692463 --Wurgl (Diskussion) 16:29, 18. Jun. 2023 (CEST)
25. Fehler: nicht geschlossenes poem-Tag sowohl einzelne <poem …> als auch einzelne </poem> man könnte es durchaus aber erkennen, wenn eines der Tags fehlt. Beispiel <poem style="font-style:italic; margin-left:3em;"> das gilt vermutlich ebenso für math, chem, score also solche Tags mit Spezialdarstellungsfunktionen Hilfe:Tags#ext. --Ló 17:19, 18. Jun. 2023 (CEST)
26. Fehler: Kursiv außen um Vorlage:Webarchiv, zerlegt den Link Spezial:Diff/233920013#cite_note-24, so dass zwei Symbole für Externlink entstehen. Gilt auch für Kursivtegs, die außen um einfache Weblinks gesetzt werden, deren Linktitel ebenfalls schon kursiv gesetzt wurde Beispiel: ''Das ist ein [http://example.net/ ''Testweblink''] im Fließtext'' --Ló 09:37, 4. Jul. 2023 (CEST)
27. <big></big> wird scheinbar nicht erkannt. Oder wird überprüft, ob es sich um eine Artikelseite handelt? MfG, Dwain 13:51, 26. Sep. 2023 (CEST)
    • <big> als solches bzw. dessen Nicht-Beanstandung geht auf mich zurück. Grund ist, dass es kein sooo schlimmer Fehler ist, und HTML es sich hin und wieder mal anders überlegt und das genau gleichartige <small> ja auch noch legal ist. <b> und <i> waren auch schon mal veraltet gewesen und sind längst wieder okay. <font> ist hingegen so schrecklich 1992 und so grausam inkompatibel in den Attributen mit allem anderen, dass es verbannt werden muss. In der HTML-Welt gibt es Stimmen, die alle rein typografischen nicht-semantischen Elemente wie <s> <small> und ggf. auch <sub><sup> abschaffen möchten und das nur noch einheitlich über <span> und CSS realisieren möchten. Weil die aber alle mit einer trivialen Kompatibilitätsregel auch vom Wiki-Server im ausgelieferten Dokument simuliert werden können und wir mehr daran interessiert sind, dass die End-Tags zusammenpassen (welche in HTML sogar weggelassen werden dürften, zumindest momentan), schadet es der robusten Interpretation von Wikisyntax nichts. <pre> ist auch ein Wiki-Element und nicht das gleichnamige sehr ähnliche HTML-Element. VG --PerfektesChaos 14:22, 26. Sep. 2023 (CEST)

      Okay, dann weiß ich Bescheid :) MfG, Dwain 15:30, 26. Sep. 2023 (CEST)

28. Nicht geschlossenes <syntaxhighlight lang="html"> gilt auch für ein alleinstehendes Ende </syntaxhighlight> Ló 19:17, 3. Okt. 2023 (CEST)
29. magic words (ISBN, DOI, ISSN, RFC, PMID …) innerhalb von [Web]Links →ISBN 3-7891-4147-X (Wikilink auf Haus)↔ISBN 3-7891-4147-X oder PMID 12345678 (Weblink aufexample.net)↔PMID 12345678 (so gesehen wären das Links in Links)-- Ló 10:31, 20. Nov. 2023 (CET)
    • Kommentar: DOI und ISSN sind nicht magisch; RFC und danach auch PMID werden es mittelfristig nicht mehr sein. Nur ISBN ist längerfristig ziemlich unersetzbar. VG --PerfektesChaos 10:40, 20. Nov. 2023 (CET)
      • Mag ja sein Spezial:Diff/239293045 oder Spezial:Diff/239292841, mir geht es dabei mehr um Links innerhalb dieser Formate. Ich habe keine Ahnung wie man die herausfischen soll. --Liebe Grüße, Lómelinde Diskussion 10:50, 20. Nov. 2023 (CET)
      • Einmalige Grundbereinigung auf Hinweis eines freundlichen Bot-Betreibers mit Dump; insource ist wenig aussichtsreich. Eigentlich nur im ANR sinnvoll für aktuelle öffentliche Darstellungen. Weil das Feature perspektivisch ohnehin wegfällt und nicht Core-Syntax ist, wird Linter sich eher nicht damit befassen wollen. Der Parser weiß syntaktisch nicht so genau ob das zu einer Verlinkung führen würde oder nicht. VG --PerfektesChaos 10:59, 20. Nov. 2023 (CET)
30. in Bilddateien gleichzeitig vorhandene Angaben zur Breite in px und als hochkant [[Datei:yellow card.svg|mini|150px|hochkant=1.2]] erzeugt keinen Fehler das hochkant wird dann ignoriert, es müsste eigentlich ähnlich wie bei doppelter px- oder hochkant-Angabe auch fehlerhafte Dateioptionen anzeigen. -- Ló 11:55, 5. Mär. 2024 (CET)
31. Allein stehende, abschließende Section-Tags werden normal geparst und nicht in Spezial:LintErrors/stripped-tag gelistet. --darkking3 ^Թ 08:44, 21. Mär. 2024 (CET)
32. Tags zwischen || der Tabellensyntax
    Beispielsweise | rowspan="2" <div style="background:#FEED01"> | Zelleninhalt
    verhält sich wie |rowspan="2" style="background:#FEED01;"| Zelleninhalt
    Es ist für mich so keine gültige Tabellensyntax (weil die ohne div arbeitet) und zudem fehlt dann das schließende </div> -- Ló 10:33, 10. Apr. 2024 (CEST)

Diskussion

Lómelinde, die <li>-Tags müssen auch wieder geschlossen werden, wie bei Punkt 4. Siehe H:Listen. Auch so ein Ding, das nicht gelinterlistet wird. – Doc Taxon • Disk. • 22:48, 12. Apr. 2023 (CEST)

Das war ich, Lo antwort abends eher selten ;) Ich würde das wohl unter Punkt 9 einordnen ;) --darkking3 ^Թ 23:18, 12. Apr. 2023 (CEST)

Sorry Ló... aber wieso Punkt 9 Inlinetags über zwei oder mehr Zeilen? Das betrifft doch in der Regel nur eine Zeile. – Doc Taxon • Disk. • 23:31, 12. Apr. 2023 (CEST)

Weil es bei fett und kursiv (mit Wikisyntax) schon Fehler erzeugt

'''
Erzeugt keinen fetten Text aber Linterfehler
'''

Und weil es dann auch so

::<small>
::Kleinerer Text
::</small>

verwendet wird, was ebenfalls Linterfehler erzeugt. Daher wäre es halt sinnvoller, wenn inlinetag, wie es der Name schon sagt, in einer Linie stehen also wirklich in ein und derselben Zeile. Und das mit <li value="n"> weiß ich und ergänze </li> auch regelmäßig, wenn es mir auffällt. --Liebe Grüße, Lómelinde Diskussion 06:38, 13. Apr. 2023 (CEST)

ja, aber offene bold, italic und small werden doch schon in der missing-end-tags gelistet, wenn sie nicht in derselben Zeile geschlossen werden, das hat die letzten Wochen funktioniert. – Doc Taxon • Disk. • 15:49, 13. Apr. 2023 (CEST)

Nein nicht für normale Tags wie small, code, big … schau wenn die am Zeilenanfang stehen gibt das keine Fehler

Kleinerer Text _{Text tiefgestellt} Text groß geschrieben kodierter Text ^{Text weiter oben}

das ist es was ich meine. Dafür habe ich jetzt 15 Zeilen im Quelltext, dargestellt wird es aber trotzdem wie eine Zeile, nur dass die Tags eben nicht wirklich alle in der selben Zeile stehen. Und du wirst jetzt auch keine Fehlermeldungen dazu bekommen. --Liebe Grüße, Lómelinde Diskussion 16:23, 13. Apr. 2023 (CEST)

dass das in einer Zeile dargestellt wird, ist softwarebedingt. Dass keine Fehlermeldung in den Listen erscheint, muss wahrlich korrigiert werden. Ich kümmer mich drum. Danke, – Doc Taxon • Disk. • 17:27, 13. Apr. 2023 (CEST)

zu 12: es kann auch so aussehen

ein in smalltags eingeschlossenes div

als Textblock

mit mehreren Zeilenumbrüchen

• oder Aufzählungen

Ehe ich das wieder vergesse. --Liebe Grüße, Lómelinde Diskussion 19:06, 15. Apr. 2023 (CEST)

Noch eine Ergänzung zu 12. es kann auch pre eingeschlossen sein

<small><pre>
        \|||/
        (o o)
,~~~ooO~~(_)~~~~~~~~~,
|   Please don't     |
|   feed the TROLL!  |
'~~~~~~~~~~~~~~ooO~~~'
       |__|__|
        || ||
       ooO Ooo
</pre></small>

small hat leider derzeit noch den Effekt, dass es trotz Linterfehlermeldungen scheinbar korrekt das tut, was der Benutzer erreichen möchte. Kleine Tabellen, kleine Vorlagen, kleine Textblöcke … --Liebe Grüße, Lómelinde Diskussion 08:34, 18. Apr. 2023 (CEST)

Der Effekt ist leider nicht nur "scheinbar", siehe z.B. die Seite Benutzer:Schreibwerkzeug. Small als Inline-Tag verhält sich bei inkorrekter Syntax (felendes End-tag) wie ein Block-Element, sodass Nutzer irrtümlich annehmen, dass das so funktionieren kann. Fett und kursiv-Tags verhalten sich da besser. --darkking3 ^Թ 15:39, 19. Apr. 2023 (CEST)

Scheinbar schrieb ich, weil ich mir nicht ganz sicher bin ob das Tag wirklich nur als Inlineelement gedacht ist und ob das nach der Softwareumstellung anders reagieren wird. Und wenn du i und b Tags verwendest, dann siehst du, dass sich auch diese anders verhalten, als die Wikisyntax mit Apostrophen. --Liebe Grüße, Lómelinde Diskussion 16:04, 19. Apr. 2023 (CEST)

zu 3: mini in gallery wird nun als Fehler angezeigt. Andim (Diskussion) 09:05, 28. Apr. 2023 (CEST)

Attribut alt= bei Bildern

Ich habe einen ernstgemeinten Vorschlag. Ich habe mal random einen Artikel von der Hauptseite genommen und durch den offiziellen Validator der w3c gejagt: https://validator.w3.org/nu/?doc=https%3A%2F%2Fde.wikipedia.org%2Fwiki%2FAitana_Bonmat%25C3%25AD - neben einigen Syntax-Fehlern, auf die wir keinen Einfluss haben, sticht einer mir ins Auge:

Error: An img element must have an alt attribute, except under certain conditions. For details, consult guidance on providing text alternatives for images.
From line 381, column 187; to line 381, column 631
cription"><img src="//upload.wikimedia.org/wikipedia/commons/thumb/0/0b/Bal%C3%B3n_de_oro.png/40px-Bal%C3%B3n_…l%C3%B3n_de_oro.png/80px-Bal%C3%B3n_de_oro.png 2x" data-file-width="2529" data-file-height="2990" /></a></

@Doc: ich bitte darum, dies den Entwicklern mitzuteilen, dass dies ebenso als Lint-Fehler ausgewiesen wird. Die Einfügung des Attributs zusammen mit einem aussagekräftigen Alternativtext wäre ein enzyklopädischer Gewinn und würde so einen weiteren Syntaxfehler beheben. --ɱ 11:48, 18. Jan. 2024 (CET)

Alter Hut, der Fehler wurde durch Lint kurzzeitig bemängelt. Da dies mehrere hunderttaussend Seiten betraf, wurden in Vorlagen (Infoboxen etc.pp.) leere alt-attribute gesetzt, da ein automatisches Ausfüllen nicht mal eben trivial umzusetzen ist. Die Aussage ist ja auch nur, dass das Attribut vorhanden sein muss, nicht dass es befüllt ein muss. Das Ergebnis der kurzzeitigen Bemängelung ist zum großteil im VNR noch zu finden, da wurde anschließend nichts revertiert. --darkking3 ^Թ 12:02, 18. Jan. 2024 (CET)

Da bist du leider um 2 Jahre zu spät dran, das hatten wir schon, es wurde jedoch aufgrund der Unmengen an Linterfehlern (insbesondere in der en:wp waren es mehrere Millionen) wieder deaktiviert. Siehe Archiv dieser Seite HD:Wikisyntax/Validierung/Archiv#inline-media-caption und den Abschnitt auf der umseitigen Hilfeseite Hilfe:Wikisyntax/Validierung#Inline-Medien mit Bildunterschriften.

Zudem kommt das Bild aus einer Navigationsleiste und ist daher schon direkt = barrierefrei als <div class="NavPic"><span class="nomobile noviewer" aria-hidden="true" role="presentation"> deklariert, es wird also Lesern, die für sich eingestellt haben, dass sie Bilder nicht erkennen können, nicht angezeigt, benötigt daher auch keinen Alternativtext. Das wurde übrigens schon 2018 in der Vorlage:Navigationsleiste umgesetzt. --Liebe Grüße, Lómelinde Diskussion 12:30, 18. Jan. 2024 (CET)

Wie wäre es stattdessen mit manuellem Ausfüllen? Baut doch bitte einfach eine Syntaxt, die das Einfügen von Bildern verhindert, wenn kein entsprechender ALT Text ergänzt wurde. Es könnte so einfach sein. Man muss es nur wollen. --Zartesbitter (Diskussion) 12:07, 18. Jan. 2024 (CET)

Na ne. Der Validator sagt eindeutig: For details, consult guidance on providing text alternatives for images.. Da findet sich dann diese Seite: https://www.w3.org/WAI/tutorials/images/decision-tree/ – wir verwenden Bilder nicht zur Dekoration, sondern aus einem enzyklopädischen Anspruch. Gemäß dem verlinkten Dokument sind bei informativen Bildern ein aussagekräftiger Alternativtext Pflicht. --ɱ 12:14, 18. Jan. 2024 (CET)

Nein, gemäß der von dir verlinkten Seite: „Does the image contain text?“. „No: Continue.“, „Yes: … and the text is also present as real text nearby. Use an empty alt attribute.“ sowie „Yes: … and the text is only shown for visual effects. Use an empty alt attribute.“ Flaggen, Wappen, Bilder etc.pp. in Infoboxen enthalten i.d.R. keinen Text. Damit ist das leere alt-attribut syntaktisch korrekt. Selbst ein automatisches Befüllen allá z.B. xyz von ... wäre syntaktisch falsch. Insofern kann die Ausgabe vom Validator nicht korrekt (false positive) sein, da er offensichtlich nur auf ein vorhandenes alt-attribut prüft und ihm die Intelligenz fehlt, zu erkennen, dass ein Bild Text enthält. --darkking3 ^Թ 12:34, 18. Jan. 2024 (CET)

Man kann da ja noch den Image-Report anschalten – bitte nach unten scrollen: https://validator.w3.org/nu/?showimagereport=yes&useragent=Validator.nu%2FLV+http%3A%2F%2Fvalidator.w3.org%2Fservices&acceptlanguage=&doc=https%3A%2F%2Fde.wikipedia.org%2Fwiki%2FAitana_Bonmat%25C3%25AD - da steht aber auch: „The following images are links and have no textual alternative available (no alt attribute). Having an img element without a textual alternative as the content of a link is handled ungracefully by popular screen readers.“ – dann ist bei dem Bild aus der Infobox ein alt="" und meiner Meinung nach ist das kein dekoratives Bild, sondern ein informatives - das leere alt-Attribut ist somit als Syntaxfehler zu werten. Sehe ich das richtig, dass eine Lint-Error 0 wichtiger ist, als wirkliche Probleme zu beheben? --ɱ 12:45, 18. Jan. 2024 (CET)

Den Einwand verstehe ich auch nicht. Continue meint, den Baum weiter nach unten zu beschreiten, und dann kommt man bei Bonmatís Bildern bei Does the image contribute meaning to the current page or context? zu Yes: … and it’s a simple graphic or photograph. und Use a brief description of the image in a way that conveys that meaning in the alt attribute. -- hgzh 12:57, 18. Jan. 2024 (CET)

Das Phänomen ist bekannt.

• Die Folgerung wäre, dass die hier angestrebte barrierefreie Bildbeschreibung (zwischen 100 und 1000 Buchstaben pro Einbindung) entsprechend dem Kontext, was für diese einzelne Einbindung in genau dieser Seite die wichtigen Merkmale wären, von den Autoren der Wikis nachgeholt werden sollen.
• Das beträfe irgendwann irgendwas in der Größenordnung von 10 Millionen Bildeinbindungen im deWP-ANR.
• Das kann das Personal der deWP nicht leisten.
• Es ist auch keine triviale Änderung, bei der mal irgendwo ein Apostroph nachgetragen werden muss, ein End-Tag eingefügt oder mal eine Verschachtelung korrigiert werden muss. Vielmehr muss eine intensive inhaltliche Auseinadersetzung mit dem Bild und seinem Kontext erfolgen; auch um zu entscheiden ob die Information, dass dieser Artikel überhaupt ein Bild enthält für Blinde weiterführend wäre. Dieses Bild ist wie sehr viele andere überhaupt nicht sinnvoll textlich beschreibbar.
• Das kann die Wiki-Autorenschaft schlicht nicht leisten. Weder für die Einbindung eines neuen Bildes durch weniger erfahrene Bearbeitende, noch für eine Aufarbeitung des Altbestandes an Millionen Bildeinbindungen.
• Es gibt noch nicht mal eine verwertbare hilfreiche deutschsprachige Anleitung für Bildbeschreibungen im Internet, erst recht nicht in der deWP. Dass die alt-Texte dann auch tatsächlich für Blinde usw. hilfreich wären, steht dahin.
• Das Verfassen wirklich für Blinde zielführender Bildbeschreibungen ist eine komplexe Angelegenheit, die mehrere Monate der Einarbeitung und Gegenlesen durch andere bedarf. Ein ungeeigneter Bildbeschreibungstext, der dabei höchstwahrscheinlich herauskäme, ist mehr störend und kontraproduktiv und eine Verschlechterung. Häufig ist als Alibi-Veranstaltung zu finden, dass einfach der sichtbare Text der Bildlegende kopiert und nochmals als alt= eingefügt wird. Das ist aber dummes Zeug, die Blinden bekommen dann zweimal hintereinander den gleichen Inhalt erzählt.
• Die Schwelle zur Bearbeitung von Wiki-Artikeln soll möglicht niedrig liegen und allen eine Mitarbeit ermöglichen. Quelltextsyntax ist ja schon eine Hürde. WWNI und RK und WSIGA brauchen ein Jahr. Achten auf Farbenfehlsichtige und Mobiltauglichkeit (Layout-Tabellen) sind weitere Hürden. Das Erlernen zielführender Bildbeschreibungen geht bei vermutlich 95 % der am ANR Mitwirkenden über den Lernhorizont und Bereitschaft hinaus.
• Auch keine andere Wikipedia kann dies leisten.
• Die Validator-Meldung ist lediglich eine Empfehlung, zur Barrierefreiheit daran zu denken, solche Beschreibungen nachzurüsten. Ein Syntaxfehler ist es jedoch nicht.
• Die Wiki-Software und Parsoid sind nicht betroffen. Der Wikitext wäre regelkonform und ist eindeutig gültig interpretierbar, mit oder ohne alt.
• Die Entwickler der WMF würden ein derartiges Begehren deshalb auf gar keinen Fall dauerhaft umsetzen. Wenn es wohl eine vorübergehende Aktivierung gab, ist das aus vorgenannten Gründen sofort wieder rückgängig gemacht worden.

VG --PerfektesChaos 13:29, 18. Jan. 2024 (CET)

Benutzer-Disk Namensraum

Wer auf Benutzer-diskussionsseiten Linter-Fehler beseitigt, sollte darüber nachdenken, sich ggf. auf Benutzer:SignaturBot/Opt-Out einzutragen, dann entstehen in Archiven später weniger Verwechselungen. --darkking3 ^Թ 22:38, 23. Apr. 2023 (CEST)

Übergabeprotokoll

So ein kleines Statement: Bevor man andere Benutzerseiten bearbeitet …

• … sollte man die Benutzer doch ansprechen und erklären was der Fehler ist, zwecklos (im Fall Mirji) wurde mehrfach versucht, Erklärungen durch mehrere Benutzer an unterschiedlichen Stellen. Ist leider keine Lösung, da in solchen Fällen zwecklos. Quasi der Auslöser der jetzigen Situation
• … sollte man die Benutzer doch ansprechen, zwecklos da seit Jahren inaktiv, nur für diesen Edit aktiv oder leider verstorben
• … sollte man die Benutzer doch vorher ansprechen und auf die Fehler hinweisen. Auch das ist innerhalb von sechseinhalb Jahren hunderte Male versucht worden, mit dem Ergebnis:
  • jene die das nicht wollen ignorieren die Anfragen auf den Diskussionsseiten (es gibt keinerlei Antwort) oder (interessiert mich aus Prinzip nicht, ist meine Seite, geht keinen etwas an) leider auch praktiziert durch einige Benutzer in höheren Funktionen, was die Abarbeitung sehr erschwert hat
  • jene die es nicht verstehen sind nach der Erklärung bereit den Fehler zu beheben
• ist eine vorherige Ansprache aus genannten Gründen nicht praktikabel, man weiß nicht wer tatsächlich noch aktiv mitliest, man muss mitunter tagelang auf eine Antwort warten, es kostet wertvolle Zeit, in der man weitere Fehler hätte beheben können, die Diskussion kann trotz Antwort in Unverständnis münden da einige der Fehler derzeit eben noch keine optische Auswirkung haben (warum es funktioniert doch)

Für mich persönlich steht ein ausgegebenes Projektziel immer über den Befindlichkeiten einzelner Benutzer. Also entweder ganz oder gar nicht, daher habe ich mich nun entschlossen zum „gar nicht“ zu wechseln.

Hiermit übergebe ich, auch ausgelöst durch die letzten, für mich leider kontraproduktiven, Änderungen bezüglich der →Zielsetzung und durch andere ebenfalls zur Zielsetzung, diese Hilfeseite samt ihrer Fortführung, Wartung und Pflege im Falle neuer Fehlerkategorien oder sonstiger Veränderungen und Erarbeitung expliziter Beispiele zur Behebung an den Benutzer:Filzstift. Und diejenigen, die sich auf einer Seite, die ich nich bearbeiten werde, nun lautstark für die Beibehaltung von Fehlern in allen Namensräumen außer dem Artikelbereich aussprechen wollen Spezial:Diff/241360527/241364835 also insbesondere Filzstift, sich aktiv um all die Fehler zu kümmern, die jetzt durch meinen Ausstieg auf andere abgewälzt werden, weil er diese Ausnahmen quasi als für alle Zukunft biindend festgeschrieben hat. Ich hätte auch gern noch Links (Legitimationen) dafür gehabt, wer denn die „Sprecher der Community“ zu dem sich Nicola ja scheinbar berufen fühlt, gewählt hat:

„Man kann Deine "Aversion" jetzt als Trauma betrachten - oder als Verachtung für die Community.“

Dazu kann ich nur sagen, wer von jemandem verlangt, auf eine Seite zu kommen, an die sie (in diesem Falle ich) traumatische Erinnerungen hat und damit für mich gesundheitliche Beeinträchtigungen in kauf nimmt oder, dass ich dann eventuell lieber das Projekt verlasse, also quasi ankündigt, wenn du dich weigerst dorthin zu kommen melde ich dich …, dein angebliches Trauma nimmt dir eh niemand ab, dann grenzt so etwas „für mich“ schon an den aktiven Versuch der Nötigung (das ist meine ganz persönliche Empfindung/Interpretation, zu ihrem Vorgehen). Nachtrag: da wäre auch noch eine Prangerseite Benutzerin:Nicola/Lomelint mit einem Link der nun absolut rein gar nichts mit Linterfehlern zu tun hat, dann da ging es um seit Jahren veraltete Importartikel. (nachgetragen Ló 08:11, 22. Jan. 2024 (CET))

Der Versuch das Ganze auf eine neutrale Seite (also beispielsweise diese Diskussionsseite zu übertragen, um mich in die Diskussion einzubinden, wurde zudem abgeblockt.

1. Ich verachte die Community nicht, ich verabscheue aber die Meldeseite, aufgrund eigener, für mich traumatischer Ereignisse aus dem Jahr 2014, die fast dazu geführt hätten, dass ich seit damals nicht mehr hier aktiv wäre.
2. Ein nicht unerheblicher Teil der tatsächlichen Community hat mir in diesen abgelaufenen sechseinhalb Jahren übrigens eine deutliche Wertschätzung zukommen lassen indem sie meine Bearbeitungen mit einem Dankeschön quittierte. Immerhin waren es insgesamt 2199 unterschiedliche Benutzer, die sich bei mir in dem Zeitraum, seit es diese Dankeschöns gibt 7834 mal bedankt haben, es ist also nicht nachweisbar, dass „die Community“ meine Bearbeitungen ablehnt (auch nicht jene im BNR), ich meine immerhin knapp 2200 Benutzer quasi als „nicht Teil der Community“ abzuqualifizieren, halte ich doch für sehr anmaßend. Wie gesagt hätte ich da gern einen Link zu der Wahl der „Sprecher der Community“ und dem dort abgegebenen einheitlichen Ergebnis, das bestätigt, dass „die Community“ (das sollten schon erheblich mehr als 20 Leute sein) die Behebung von Syntaxfehlern im Benutzerbereich ablehnt.

Danksagung

• Ich bedanke mich bei allen, die es innerhalb von sechseinhalb Jahren ermöglicht oder aktiv dabei geholfen haben, die bis dahin aufgelaufenen und auf mehrere Millionen bezifferten Fehler (ausdrücklich in allen Namensräumen) zu beheben (immerhin im Juni 2020 hatten wir noch eine gute halbe Million Fehler).
• Mein besonderer Dank dabei geht an diejenigen, die für diese Fehlerkorrektur nützliche Hilfsmittel erstellt haben, also Perfektes Chaos für lintHint und :en:user:Firefly, für sein extrem nützliches Tool fireflytools, das mir die anfänglich tägliche handschriftliche Erstellung einer solchen Statistik abgenommen hat. Ohne diese Hilfsmitte wären hier noch einige Millionen Fehler übrig.
• Mein Dank geht natürlich auch an jene, die sich hier mit engagiert hatten, aber durch persönlichen Frust ihre Mitarbeit eingestellt haben, wie der Benutzer Plagiat

Abschluss

• So ich nehme diese Seite nun von der Beobachtungsliste, falls Pings von hier ins Leere gehen sollten, kann das an meiner persönlichen Blacklist liegen
• Ich habe diese Arbeit gern für all jene getan, die selbst nicht in der Lage sind oder waren solche Fehler zu beheben.
• Ich erwarte nicht wirklich, dass sich auch nur ein einziger der „die Community will das nicht Fraktion“ jemals aktiv an der Behebung der Fehler beteiligen wird. Schade, denn eigentlich wäre das eine Gemeinschaftsaufgabe, sich diesem Projektziel anzunehmen.

Meine Diskussionsseite steht (fast) jedem aber weiterhin offen, der Fragen zu Linterfehlern hat oder Hilfe bei deren Behebung erbittet, meine Bearbeitungen in dem Bereich werden sich erst einmal nur noch auf Seiten beschränken, auf denen ich zufällig Fehler sehe, oder für Menschen, die meine Hilfe dabei immer gern in Anspruch genommen haben. Diese sind stets willkommen. --Liebe Grüße, Lómelinde Diskussion 08:01, 22. Jan. 2024 (CET)

Noch ein Nachtrag, weil das als Argument mehrfach gegen einige Benutzer verwendet wurde, die sich hier der Korrektur gewidmet haben und es noch tun (insgesamt übrigens nur sehr wenige engagierte Leute, die mehrere Millionen Fehler allein bewältigt haben):

Quasi „was tut ihr denn schon für die Enzyklopädie“, „Benutzer XY hat noch nie selbst einen Artikel angelegt“ oder ähnliches:

Ich habe in den sechseinhalb Jahren nachweislich neben der aktiven Behebung von mehreren hunderttausend Linterfehlern

• etliche Seiten neu erstellt darunter Artikel, Hilfeseiten, Vorlagen Das Logbuch listet erst seit 2018
• im Zuge des WBW etliche Artikel überarbeitet und von Wartungsbausteinen befreit
• verwaiste Benutzerentwürfe ausgebaut/Überarbeitet und in den Artikelnamensraum verschoben
• auch etliche Seiten mit unsinnigen oder beleidigen Inhalten löschen lassen …

Die letzten beiden Punkte sind „für mich“ auch ein Argument für die Bearbeitung von Benutzerseiten.

Und als letzter Hinweis noch, ich lese auch nicht die Kurierseiten oder schreibe auf Seiten wie WP:AA oder WP:AN, allerdings geht meine Apathie dort nicht soweit, dass mir die Fehlerbehebung dort Probleme bereitet hätte. + @ bitte auch keine blockquote-Tags verwenden →Hilfe:Tags#Unerwünschtes HTML. --Liebe Grüße, Lómelinde Diskussion 09:07, 23. Jan. 2024 (CET)

Ich schließe mich dem an: Meine Disk. steht auch offen. LintErrors werde ich nicht mehr korrigieren. NeuerAccount001beta3 10:20, 22. Jan. 2024 (CET)

Da du mich unbedingt im zweiten Satz adressieren musstest: 2 Dinge. a) Mit deinem allerersten Beitrag jemals auf meiner Disk hast Du mir mit administrativen Maßnahmen gedroht – damit war die Kommunikation von Anfang an vergiftet. Ich wurde von dir auch noch verhöhnt: Zwergenaufstand. b) Dass das ganze auf der V-Disk besprochen wird, ist Dir zu verdanken: 1, 2, 3, 4. Ich hatte den Kurier gewählt & du hättest Dich ebenso auf WD:K#Fehler_auf_Benutzerunterseiten_/_Über_die_Fehlerfreundlichkeit_im_BNR zu Wort melden können, dort wurde diese Causa ebenso besprochen & dies ist eine neutrale Seite. Ich stehe zu meinen Wort aus dem Kurier: „Im ANR & auf Projektseiten ist das vollkommen legitim, da leisten sie unbestreitbar sehr gute Arbeit.“ – vielen Dank dafür. --ɱ 11:51, 22. Jan. 2024 (CET)

> »„Im ANR & auf Projektseiten ist das vollkommen legitim, da leisten sie unbestreitbar sehr gute Arbeit.“«

Das kann schon mal gar nicht ernst gemeint gewesen sein (sondern ein Hohn, wie er so häufig unterschwellig in deinen Worten mitschwingt). Schließlich war dir der Grund unserer Edits bis zur Aufklärung von PerfektesChaos auf WD:VM nicht bekannt. Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 12:52, 22. Jan. 2024 (CET)

Meine Worte waren vollkommen ernst gemeint, diese Beurteilung deinerseits ist falsch und steht dir nicht zu. Zu deinem letzten Satz sag ich jetzt mal nichts, ich verweise auf dieses Statement. --ɱ 13:16, 22. Jan. 2024 (CET)

Spezial:Permanenter Link/241453796#c-Eulenspiegel1-20240122122800-Ralf Roletschek-20240122101800 ;-) Ich wollte diese Diskussion nicht mehr führen. Warum reicht dir eigentlich nicht, dass zwei Korrektoren (wegen Starallüren von 10 Wikipedianern) jetzt so negative Gefühle mit der Wikipedia haben, dass sie sich nicht mehr trauen überall zu editieren (okay beide trauten sich vorher auch schon nicht überall zu editieren, durch toxische Aktionenen, [PA entfernt --ɱ 10:47, 23. Jan. 2024 (CET)] – aus meiner Sicht deutlich kein PA, höchstens einen leichten Verstoß gegen die Wikiquette. Jeder kann sich in der Versionsgeschichte selbst überzeugen Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 09:56, 7. Feb. 2024 (CET)). Wenn mich das nicht vom Rang des aktiven Sichters ausgeschlossen hätte, hätte ich mich übrigens schon längst sperren lassen … Murdoch Mysteries Episodenliste- und Die Legenden von Andor-Aktualisierer 09:05, 23. Jan. 2024 (CET)

Wirklich kaum jemand hat gefordert, dass ihr dies in den Content Namespaces einstellt, es ging uns vorrangig um den BNR. Generell keine Korrekturen mehr durchzuführen ist eure freie Entscheidung, die ihr für euch getroffen habt und dafür könnt ihr niemand verantwortlich machen, den Schuh ziehen wir uns nicht an. Hab einen schönen Tag. --ɱ 11:17, 23. Jan. 2024 (CET)

Nur als Info

mw:Help:Lint errors/night-mode-unaware-background-color Tracking only. --Liebe Grüße, Lómelinde Diskussion 18:59, 4. Apr. 2024 (CEST)