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
- Fehler:
[[[[<Wikilink>]]
- Beispiel: Beispiel
[[Benutzer:[[emeko|emeko]] weitere Beispiele (Ló)
- Fehler:
[[<Weblink>]
- Beispiel: Beispiel
- 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 …
- 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)
- 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)
- 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
- 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)
- Fehler: Fehlende, schließende Tags in
{{SEITENTITEL: }}.
{{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)
- Fehler: alle Tags, die Inlinetags sind und in zwei oder mehr Zeilen beginnen/enden.
<small>
Kleinerer Text
</small>
- Meldung durch Benutzerin:Lómelinde
- 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
- 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)
- 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)
- Fehler: eingerückte Tabellen (Beispiele) Ló 17:13, 16. Apr. 2023 (CEST)
::: {| class="wikitable"
|-
! Überschrift !! Überschrift !! Überschrift
|-
| Beispiel || Beispiel || Beispiel
|}
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- <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)
- Nicht geschlossenes
<syntaxhighlight lang="html"> gilt auch für ein alleinstehendes Ende </syntaxhighlight> Ló 19:17, 3. Okt. 2023 (CEST)
- 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)
- 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)
- 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)
- 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)
- unausgeglichene Tags fett und kursiv in Wikilinks Auslöser →Spezial:Diff/245628843/245672233 Spezial:Diff/237258657/237279427 I''s '' ?''' '''' ''?''' aber auch falsch eingefügte Kursivsetzung wie ''London School of Economics'', ''Imperial College'', ''King’s College London'' oder ''Mirèio'' statt Links auf London School of Economics (WL), Imperial College (WL), King’s College London, Mirèio Beispiele -- Ló 10:54, 6. Jun. 2024 (CEST)
- Tags, die über ref-Tags gespannt werden.
<code><small>'''''<ref>weder fett noch kursiv auch nicht klein oder codiert</ref>'''''</small></code>[1]
- Tags die über references gespannt werden
<code><small>'''''<references />'''''</small></code> haben hingegen schon die entsprechende Auswirkung erzeugen aber ebenfalls keine Fehlermeldungen, selbst wenn die Darstellung kaputt wäre. Eigentlich müsste so etwas zu falsch verschachtelten Tags gezählt werden, da es sich ja bei der Ausgabe um eine Aufzählung und nicht um einen Inhalt innerhalb einer Zeile handelt. Beispiel -- Ló 08:44, 26. Jun. 2024 (CEST)
- Etwas eher seltenes, halbe oder kaputte Tags <charinsert>Hallo</charinsert> würden nicht als Fehler erkannt. Dieser Murks hier
<charinsert>Hallo <charinsert><code>Du</code></charinsert></charinsert> würde also fehlerfrei durchgehen. Ob es solche Fehler mit unerwünschter Wirkung geben könnte, weiß ich nicht es gibt aber ein paar nicht geschlossene Tags. -- Ló 18:48, 27. Okt. 2024 (CET)
Einzelnachweise
weder fett noch kursiv auch nicht klein oder codiert
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
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)
