„Hilfe Diskussion:Wikisyntax/Validierung“ – Versionsunterschied
Änderung 241346423 von NeuerAccount001beta3 rückgängig gemacht; Nein geht tatsächlich um ANR, revert und tut mir leid Markierung: Rückgängigmachung | |||
Zeile 354: | Zeile 354: | ||
[[Hilfe:Wikisyntax/Validierung#Fehlendes End-Tag in der Überschrift]], dort werde ich noch Beispiele einfügen. --Liebe Grüße, [[Benutzerin:Lómelinde|Lómelinde]] [[Benutzerin Diskussion:Lómelinde#top|Diskussion]] 12:53, 18. Jan. 2024 (CET) | [[Hilfe:Wikisyntax/Validierung#Fehlendes End-Tag in der Überschrift]], dort werde ich noch Beispiele einfügen. --Liebe Grüße, [[Benutzerin:Lómelinde|Lómelinde]] [[Benutzerin Diskussion:Lómelinde#top|Diskussion]] 12:53, 18. Jan. 2024 (CET) | ||
== Lösungsorientierte Kompromisssuche zur namensraumübergreifenden Behebung von Lint-Fehlern == | |||
-> Fortsetzung der Diskussion von [[WD:VM#Wikipedia:Vandalismusmeldung#Benutzer:Mirji 2]] | |||
An dieser Stelle soll ein Kompromiss zwischen Autoren und Technikern gefunden werden, wie künftig mit der namensraumübergreifenden Behebung von Lint-Fehlern umgegangen werden soll. | |||
Die Lage ist angeheizt, wir alle sollten uns aber an das Gebot von [[WP:KPA]] halten und objektiv auf die Sache bezogen diskutieren. – [[Benutzer:Doc Taxon|Doc Taxon]] • <small>[[BD:Doc Taxon|Disk.]]</small> • 22:43, 19. Jan. 2024 (CET) | |||
:Einen ersten Vorschlag zitiere ich von PerfektesChaos: | |||
:Es gibt eine Karenzzeit von n Stunden. | |||
:Vorher wird der BNR nicht korrigiert. | |||
:Im Zweifelsfall zuvor auf der BD aufschlagen, mit präziser Fundstelle und korrigiertem Wikitext zum Selbsteinlöten, oder Delegation an Spezialisten für bestimmte Konten. | |||
:Im Gegenzug gibt es auch weiterhin keine Akkumulation eines Bergs an neuen Altlasten, sondern eine Eliminierung spätestens nach einer Woche. | |||
:<br /> | |||
:→ Die Karenzzeit wurde mittlerweile auf 48 Std. beziffert und auf den BNR beschränkt. | |||
:→ Techniker sollen zunächst auf der BD aufschlagen und erklären, womit es auf sich hat, um den Text vom Autoren selbst zu korrigieren, oder wenn zu kompliziert, darum zu bitten. Dabei sollte ein wohlwollender, nichtbelehrender "Ton" angeschlagen werden. | |||
:→ Die Stimmen der Autorenseite beinhalteten die Nichtkorrektur auf BNR-Seiten oder Korrektur erst nach Verschub von Artikelentwürfen aus den BNR in den ANR (mit Verweis auf BNR-Hoheit und Gestaltungshoheit). --– [[Benutzer:Doc Taxon|Doc Taxon]] • <small>[[BD:Doc Taxon|Disk.]]</small> • 22:52, 19. Jan. 2024 (CET) | |||
:::; Ganz persönliche Anmerkung | |||
:::Wie ich zuvor schrieb, habe ich mich schon vor Jahren über diese Änderungen im ANR geärgert und mich dagegen zur Wehr gesetzt. Ja, [[Benutzer:Yellowcard|Yellowcard]], ich habe gefaucht - aber Dir kann ich eh wohl nichts mehr recht machen. | |||
:::Ich bin vorrangig Autorin - von Technik habe ich kaum Ahnung, höchstens das, was ich mir autodidaktisch durch Abschauen angeeignet habe. Mehr brauche ich für meine Zwecke in der Regel nicht, und wenns mich überfordert, frage ich kundige Menschen. | |||
:::Also: Autoren sagen, das stört uns, und da stimme ich Kolleginnen und Kollegen hier zu: Autoren und Fotografen sind in der WP das Salz der Erde. Ohne Artikel ist perfekte Technik nichts wert. | |||
:::Anstatt aber jetzt die gekränkten Gefühle von Autorinnen und Autoren ernst zu nehmen, nimmt eine der Hauptprotagonistinnen an der Diskussion gar nicht erst teil, weil sie "Wichtigeres" zu tun habe - und andere Kollegen schütten jetzt diese Seiten mit ihrem ausschweifendem Technikkauderwelsch zu, offensichtlich um ihre Allwissenheit zu demonstrieren und die Autoren schwer zu beeindrucken. So habe ich null Ahnung wer oder was die "Parser" sind, ich kenne nur Perser oder Parler. Dieser Dom ist mir ebenfalls unbekannt, obwohl es einen gibt, den ich nahezu von meinem Balkon aus sehen kann. Ich hoffe allerdings, dass der nicht vorhat zu "migrieren". | |||
:::So kommt das auf jeden Fall bei mir an, und das finde ich mehr als ärgerlich. --[[Datei:Radsportler.svg |15px|verweis=Portal Diskussion:Radsport]] [[Benutzer:Nicola|Nicola]] [[Benutzerin Diskussion:Nicola| <small>kölsche Europäerin</small>]] 22:46, 19. Jan. 2024 (CET) | |||
::::Schön geschrieben. Aber auch Autoren und Fotografen benötigen funktionierende und v.a. zukunftssichere Technik. Ohne ist der beste Artikel auch nichts wert. Am Ende ergibt sich Eins aus vielem. --[[Benutzer:darkking3|darkking3]] <sup><small>[[BD:darkking3|Թ]]</small></sup> 22:59, 19. Jan. 2024 (CET) | |||
:::::Es geht - soweit ich das noch verstehen konnte bei diesem ganz Fachsprech - vorrangig um '''Entwürfe im ANR'''. Die MÜSSEN nicht funktionieren, weil sie eben genau das sind - nämlich Entwürfe. Ich gebe doch auch den Entwurf einer Arbeit beim Lehrer ab, damit er sie korrigiert. --[[Datei:Radsportler.svg |15px|verweis=Portal Diskussion:Radsport]] [[Benutzer:Nicola|Nicola]] [[Benutzerin Diskussion:Nicola| <small>kölsche Europäerin</small>]] 23:27, 19. Jan. 2024 (CET) | |||
: Ich bin hier raus. Sperrt mich doch. [[User Talk:NeuerAccount001beta3|NeuerAccount001beta3]] 23:09, 19. Jan. 2024 (CET) |
Version vom 20. Januar 2024, 01:10 Uhr
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
Namensraum | Missing end tag | Sonstige | Gesamtzahl |
---|---|---|---|
Artikel | 0 | 0 | |
Benutzer | 1 | 1 | |
Sonstige | 0 | 0 | 0 |
Gesamt (alle) | 1 | 0 | 1 |
Aktuelle Zahlen: https://fireflytools.toolforge.org/linter/dewiki
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 |
3. Jan. 2024 | 3.466.188 | 1 |
Adminonly
...
- Spezial:LintErrors/obsolete-tag →weiterhin eine Unterseite, ist leider nicht beendet. -- Lómelinde 06:31, 18. Jan. 2024 (CET)
- jetzt ist mal gut, im Quelltext steht, dass ich diese Seite in einem Monat löschen lasse. --ɱ 10:26, 18. Jan. 2024 (CET)
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)
- @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)
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)
- 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)
- Na ja in Wikidata gibt es auch tausende Linterfehler, zumindest laut firefly. --Liebe Grüße, Lómelinde Diskussion 08:55, 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)
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)
- 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)
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)
- 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)
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)
- @Mabschaaf: hast Du zu Fehler 1 und 2 Beispiele? – Doc Taxon • Disk. • 19:19, 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>
|
|
- 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)
- 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)
- 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)
- Ja schon, aber sowas
- Sollte das nicht generell für alle Seiten mit
- 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
undi
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)
- das wird mit
- 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)
- 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)
- check
- Gilt mindest auch für Fett und Kursiv. --darkking3 Թ 22:08, 12. 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
[Ló 08:38, 13. Apr. 2023 (CEST)]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 dives 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)
- 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)
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
- 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)
- Das war ich, Lo antwort abends eher selten ;) Ich würde das wohl unter Punkt 9 einordnen ;) --darkking3 Թ 23:18, 12. Apr. 2023 (CEST)
- 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)
'''
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
- 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)
- 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
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)
- 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)
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)
- 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)
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)
- 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)
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)
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)
Heute neu hinzugekommen
Hilfe:Wikisyntax/Validierung#Fehlendes End-Tag in der Überschrift, dort werde ich noch Beispiele einfügen. --Liebe Grüße, Lómelinde Diskussion 12:53, 18. Jan. 2024 (CET)