Hilfe Diskussion:Wikisyntax/Validierung

aus Wikipedia, der freien Enzyklopädie
< Hilfe Diskussion:Wikisyntax
(Weitergeleitet von Hilfe Diskussion:LINT)
Letzter Kommentar: vor 6 Tagen von Lómelinde in Abschnitt Statistik
Zur Navigation springen Zur Suche springen
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

[Quelltext bearbeiten]
Letzter Kommentar: vor 6 Tagen12 Kommentare4 Personen sind an der Diskussion beteiligt
2024-11-01 07:35:10 UTC
Namensraum Missing end tag Sonstige Gesamtzahl *
Artikel 0 0 0  
Benutzer 140 41 181  
Sonstige 5 0 5  
Gesamt (alle) 145 41 186  

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 1
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. Apr. 2024 3.358.445 371
3. Mai 2024 3.315.434 182
1. Juni 2024 3.225.221 96
1. Juli 2024 3.206.692 76
1. Aug. 2024 3.162.899 197
1. Sep. 2024 3.137.722 266
1. Okt. 2024 3.102.521 152
1. Nov. 2024 3.012.471 186
1 
Durch neue Fehleranalyse fehlendes Tabellenende |}
2 
Nicht berücksichtigt wird die Fehlerkategorie „Lint-Fehler: Die Inline-Stilregel für die Hintergrundfarbe existiert ohne eine dazugehörige Textfarbe“, die keinerlei zuverlässige Zahlen liefert, siehe den Hinweis: Hilfe:Wikisyntax/Validierung#Der Inline-Stil für die Hintergrundfarbe erfordert eine Textfarbe, sowie die Kategorie „Lint-Fehler: Doppelte IDs“.
@At40mha: Warum werden Doppelte IDs nicht berücksichtigt? Das ist ein Fehler der Kategorie „Hohe Priorität”, diese hier nicht zu berücksichtigen hat zur Konsequenz, dass diese Zahlen geschönt sind und nicht der Realität entsprechen. --ɱ 12:17, 2. Okt. 2024 (CEST)Beantworten
Die Kategorie "Doppelte IDs" wurde erst vor wenigen Tagen aktiviert und die Arbeit an der Behebung hat gerade erst begonnen.
Die Auswertung beruht auf den Fireflytools (dewiki bzw. enwiki) und in dieser Liste ist dieser Fehler noch nicht berücksichtigt. Aktuell beträgt die Zahl der Fehler "Doppelte IDs" in enwiki rund 3 Millionen und in dewiki 139.000. [Korrektur: Bei mehrmaligem Aufruf der Seite werden unterschiedliche Zahlen zwischen 130.000 und 300.000 angezeigt. 139.000 war offensichtlich ein zufällig niedriger Wert. Tatsächlich erscheinen derzeit am Häufigsten Werte um 230.000.] Tendenz in der dewiki bereits abnehmend, Dank der Aktivitäten von einigen wenigen Enthusiasten. --At40mha (Diskussion) 13:08, 2. Okt. 2024 (CEST)Beantworten
Dass fireflytools sie nicht berücksichtigt, sollte nicht maßgeblich für diese Statistik sein. Spricht etwas fachliches dagegen, diesen in der Statistik mit aufzunehmen? --ɱ 13:11, 2. Okt. 2024 (CEST)Beantworten
Fachlich spricht allein schon die Tatsache entgegen, dass die Zahlen bei jedem Aufruf schwanken. Zudem muss für eine exakte Auswertung der Parser erst _jede_ Seite neu erstellen, um belastbare Angaben zu erhalten. Und ich weiß auch nicht, was deine (nochmalige) Frage soll, wenn dir vorher bereits 2 User und mit mir ein dritter User widerspricht. --darkking3 Թ 13:35, 2. Okt. 2024 (CEST)Beantworten
Das kann man einfach lösen, in dem man die niedrigste Angabe nimmt und ein >= davor setzt. Und ich merke schon, die Priorität ist hier vollkommen egal und ein externes Nicht-WMF-Tool die Rechtfertigung dafür, die eigene Statistik schön zu schreiben. Lieber wird auf einem rumgehackt, sorry aber kein Verständnis und dann werde ich wohl in Zukunft Edits wie Spezial:Diff/249043698/249070649 unterlassen. --ɱ 13:47, 2. Okt. 2024 (CEST)Beantworten
Und „Hohe Priorität“ ist berechtigt, das ist kein Wischiwaschi-Fehler. z.B. https://de.wikipedia.org/wiki/Eurozone#FN_2_back Die Anmerkung FN_2 gibts zweimal und kann nur einmal angesprungen werden. Das sollte wie bei Einzelnachweisen mit einem a b mit eigenen Sprungzielen gelöst werden. Es gibt wirklich keinen Grund, in der Statistik diese schwerwiegende Fehlerkategorie auszuklammern. --ɱ 13:55, 2. Okt. 2024 (CEST)Beantworten
Die Aussagekraft einer Zahl mit >= einzuschränken ist gleichbedeutend mit einer Größenangabe ∞. Woher soll der Leser einer Statistik wissen, dass dies nicht um Faktor 10 oder 10^10 oder auch um ein Googol abweicht? Das weißt du selber nicht einmal. Eine solche Angabe ist damit einfach unseriös. Auch wäre die Frage, wer diese Zahl wie und wann bestimmt? Einzig korrekter Weg wäre, sich hier um eine vernünftige Zahlenauswertung zu kümmern. --darkking3 Թ 14:16, 2. Okt. 2024 (CEST)Beantworten
Schön Rechtfertigungen dafür, die hier ankommenden Interessenten mit einer Zahl 152 über die tatsächliche Zahl der Fehler zu belügen, kaum einer guckt ins Kleingedruckte. Macht wie ihr wollt, aber durch beschönigte Statistiken werden hier falsche Tatsachen vorgetäuscht. Anstelle >= kann man auch gerundete Werte oder Bereiche angeben, es findet sich sicher ein Lösung, die die Realität widerspiegelt. --ɱ 14:40, 2. Okt. 2024 (CEST)Beantworten

So ich habe inzwischen bei Firefly angefragt, es gibt allerdings Einspruch, gegen eine Ergänzung der Kategorie zum Tool, weil es in en:wp zu viele falsch positive (oder zu viele schwierig zu lösende) Fehler wären. --Liebe Grüße, Lómelinde Diskussion 09:05, 11. Okt. 2024 (CEST)Beantworten

Was dritte dazu schreiben, ist eher uninteressant. Fakt ist, dass Firefly deine Anfrage komplett ignoriert hat. Das ist dann wohl keine gute Basis. --ɱ 13:12, 1. Nov. 2024 (CET)Beantworten
Nein Fakt ist, dass er seit dem 22. September 2024 →nicht online war und daher nicht geantwortet hat. Jemandem zu unterstellen meine Anfrage zu ignorieren steht dir nicht zu, zumal er dies bisher niemals getan hat. Und der Dritte hat sehr wohl ein Recht seine Bedenken zu äußern oder Einspruch zu erheben, da er aktiv an der Abarbeitung der Fehlerlisten beteiligt ist und daher weiß, wovon er redet. --Liebe Grüße, Lómelinde Diskussion 06:29, 2. Nov. 2024 (CET)Beantworten

 Info: Firefly wird wohl auf unbestimmte Zeit nur noch sporadisch aktiv oder komplett inaktiv sein. Schade, wenn das Tool mal wieder abstürzen sollte, wäre es wirklich schlecht, wenn man es nicht neu starten könnte. --Liebe Grüße, Lómelinde Diskussion 10:55, 19. Nov. 2024 (CET)Beantworten

Adminonly

[Quelltext bearbeiten]
Letzter Kommentar: vor 1 Monat1 Kommentar1 Person ist an der Diskussion beteiligt
Doppelte IDs

Fehler in den Lint-Listen

[Quelltext bearbeiten]
Letzter Kommentar: vor 29 Tagen70 Kommentare11 Personen sind an der Diskussion beteiligt

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

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)Beantworten
@Mabschaaf: hast Du zu Fehler 1 und 2 Beispiele? – Doc Taxon • Disk. • 19:19, 12. Apr. 2023 (CEST)Beantworten
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)Beantworten

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

Fehlerauflistung

[Quelltext bearbeiten]
  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 mini, thumb, miniatur
  • Attribut hochkant, upright
    Attribut hochkant, upright
  • Attribut links, left, rechts, right, mitte, oben, unten, ohne, zentriert …
    Attribut links, left, rechts, right, mitte, oben, unten, ohne, zentriert …
  2. 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)Beantworten
    3. 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)Beantworten
    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)Beantworten
    ah, ich erinner mich, danke – Doc Taxon • Disk. • 23:00, 12. Apr. 2023 (CEST)Beantworten
  3. 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)Beantworten
    Sollte das nicht generell für alle Seiten mit <!-- ohne --> gelten?--Mabschaaf 19:52, 12. Apr. 2023 (CEST)Beantworten
    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)Beantworten
  4. 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
  2. Fehler: Formatierungen wie ''Text''' oder '''Text'' erzeugt keinen Fehler.
    3. 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)Beantworten
    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)Beantworten
    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)Beantworten
Gemeldet in Phabricator
Task T334632
  2. Fehler: Fehlende, schließende Tags in {{SEITENTITEL: }}.
    3. {{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)Beantworten
    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)Beantworten
  4. Fehler: alle Tags, die Inlinetags sind und in zwei oder mehr Zeilen beginnen/enden.
<small>
Kleinerer Text
</small>
Meldung durch Benutzerin:Lómelinde
  2. Fehler: Tags um Bilder wie gefettete Bildeinbindungen →Berlin 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 Gelbes Trikot Gesamtwertung Tour de France [Ló 08:38, 13. Apr. 2023 (CEST)]Beantworten
  3. 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)Beantworten
  4. 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)Beantworten
  5. Fehler: eingerückte Tabellen (Beispiele) Ló 17:13, 16. Apr. 2023 (CEST)Beantworten
::: {| class="wikitable"
|-
! Überschrift !! Überschrift !! Überschrift
|-
| Beispiel || Beispiel || Beispiel
|}
  2. 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)Beantworten
Und ebenfalls für <inputbox></inputbox> Spezial:Diff/31236928 --Ló 16:04, 23. Mai 2023 (CEST)Beantworten
  2. 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)Beantworten
  3. 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)Beantworten
  4. 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)Beantworten
  5. 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)Beantworten
  6. 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)Beantworten
  7. 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)Beantworten
  8. 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)Beantworten
  9. 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)Beantworten
  10. 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)Beantworten
  11. 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)Beantworten
  12. 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)Beantworten
  13. 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)Beantworten
  14. <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)Beantworten
    • <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)Beantworten
      Okay, dann weiß ich Bescheid :) MfG, Dwain 15:30, 26. Sep. 2023 (CEST)Beantworten
  16. Nicht geschlossenes <syntaxhighlight lang="html"> gilt auch für ein alleinstehendes Ende </syntaxhighlight> Ló 19:17, 3. Okt. 2023 (CEST)Beantworten
  17. 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)Beantworten
  18. 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)Beantworten
  19. 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)Beantworten
  20. 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)Beantworten
  21. 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)Beantworten
  22. 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)Beantworten
  23. 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)Beantworten

Einzelnachweise

  1. ↑ weder fett noch kursiv auch nicht klein oder codiert

Diskussion

[Quelltext bearbeiten]
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)Beantworten
Das war ich, Lo antwort abends eher selten ;) Ich würde das wohl unter Punkt 9 einordnen ;) --darkking3 Թ 23:18, 12. Apr. 2023 (CEST)Beantworten
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)Beantworten
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)Beantworten
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)Beantworten
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)Beantworten
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)Beantworten

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

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

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

Attribut alt= bei Bildern

[Quelltext bearbeiten]

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

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

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

Benutzer-Disk Namensraum

[Quelltext bearbeiten]
Letzter Kommentar: vor 1 Jahr1 Kommentar1 Person ist an der Diskussion beteiligt

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

math id

[Quelltext bearbeiten]
Letzter Kommentar: vor 1 Monat6 Kommentare4 Personen sind an der Diskussion beteiligt

Nun weiß ich nicht wohin damit, LintHint (und die Fehlerlisten) sagen da wären jeweils zwei IDs vorhanden, wenn das Tag ein id= verwendet. 

<math id="loglogPot">\lg\left(\log(a^b)\right) = \lg(b\cdot\log(a)) = \lg(b)+\lg(\log(a)) </math>

FragmentAnchors (ist nützlich, um doppelte Anker aufzuspüren) sagt „nöhö da ist nur einer“. Und WSTM sagt dann auch noch 

(6×) Tag mit unbekanntem Attribut
<math id=...>

das würde bedeuten raus damit, aber Hilfe:TeX sagt id= ist erlaubt. Ich vermute mal, dass keine Schlüsselwörter aus der TeX-Logik, oder wie man das nennen soll, in der id vorkommen dürfen. Wie kann man das beheben, ohne die id="…" zu löschen? Im Quelltext befinden sich jedenfalls keine weiteren Bezeichner die diese Doppelungen erklären würden. Sie durch andere Bezeichner (ohne TeX) zu ersetzen müsste zwar funktionieren, würde aber der Intention des Einfügenden widersprechen, notwendig scheinen sie aber nicht zu sein, es gibt keine Links auf diese Ziele. Es ist nicht so, dass alles was so als id angegeben wird, zu solchen Fehlern führt. Manch einer verwendet das scheinbar als Kommentarzeile Glicko-System#Der Algorithmus bricht sonst nicht ab, falls die Nullstelle fuer ein x i angenommen wird.← Anspringen lässt sich das aber nicht Spezial:Diff/198728044. Einfache Ziffern scheinen ebenso unzulässig zu sein, oder ist das ein Bug? Schließlich haben sie zuletzt auch an der math-Präsentation gearbeitet. Aber vermutlich kann fast alles von diesen hier weg. --Liebe Grüße, Lómelinde Diskussion 16:36, 2. Okt. 2024 (CEST)Beantworten

Das Problem ist, was Mediawiki daraus macht, der erzeugte Quellcode:
<span class="mwe-math-element" id="loglogPot">
[...]
    <img src="https://wikimedia.org/api/rest_v1/media/math/render/svg/9fdfa06f55f8be1347570efb247c85185b4d58d1" class="mwe-math-fallback-image-inline mw-invert skin-invert" id="loglogPot" aria-hidden="true" style="vertical-align: -1.005ex; width:46.477ex; height:3.343ex;" alt="{\displaystyle \lg \left(\log(a^{b})\right)=\lg(b\cdot \log(a))=\lg(b)+\lg(\log(a))}">
</span>
Darin kommt id="loglogPot" zwei mal vor. Daher am besten bei Phabricator melden. --ɱ 16:55, 2. Okt. 2024 (CEST)Beantworten
Was soll ich sagen, dafür bin ich zu „doof“, ich verstehe Phab nicht. Ich kann da auch nichts melden. Und es ist eben auch nicht immer, nicht alle der Seiten erzeugen auch Fehler. Induktivität hat als Inhalt der id "Die Erklärung steht bereits im Satz davor. Sowohl die Spannung, als auch der Strom sind zeitabhängig". Das das kein brauchbarer Anker ist, ist auch klar, aber der geht als ok durch. --Liebe Grüße, Lómelinde Diskussion 17:21, 2. Okt. 2024 (CEST)Beantworten
(quetsch) Habe diese Nonsens-ID in Induktivität entfernt. LG --rolf_acker (Diskussion) 15:18, 9. Okt. 2024 (CEST)Beantworten
Gemäß HTML-Standard ist Whitespace wie Leerzeichen nicht erlaubt und dies daher ebenso ein Fehler. --ɱ 16:57, 3. Okt. 2024 (CEST)Beantworten
Soweit ich sehen kann werden "Doppelte IDs" bei math-Tags dann erzeugt, wenn im angegebenen Wert kein Leerzeichen enthalten ist. Dann werden zwei gleichlautende ID-Ziele erzeugt.
Wenn ein Leerzeichen enthalten ist, dann unterscheiden sich die beiden Ziele dadurch, dass einmal (bei <p><span class="mwe-math-element" id="...") der angegebene Wert mit den Leerzeichen auftaucht (syntaktisch fehlerhaft) und einmal (bei <img src="..." class="mwe-math-fallback-image-inline mw-invert skin-invert" id="...") mit Unterstrichen anstelle der Leerzeichen.
Vielleicht erklärt das, weshalb nicht in jedem Fall ein Fehler "Doppelte ID" angezeigt wird. --At40mha (Diskussion) 12:47, 4. Okt. 2024 (CEST)Beantworten

Hilfe:Wikisyntax/Validierung#Doppelte_IDs

[Quelltext bearbeiten]
Letzter Kommentar: vor 1 Monat5 Kommentare3 Personen sind an der Diskussion beteiligt

@PerfektesChaos:, das Beispiel auf der Vordeseite, name=WegekreuzPoststraße, etc. ist zwar richtig, aber wollen wir wirklich CamelCase an dieser Stelle? Ist nicht notwendig. name=Wegekreuz Poststraße ist mE besser. Bitte um umseitige Anpassung. lg --Herzi Pinki (Diskussion) 14:03, 9. Okt. 2024 (CEST)Beantworten

Das hat im Ansatz schon seinen tieferen Sinn.
  • Grundregel bei der Bildung von zusätzlichen Ankern ist, dass sie nicht mit vorhandenen Überschriften kollidieren sollen.
  • Deshalb wird empfohlen, solche Ausdrücke zu wählen (CamelCase), die nicht als menschlicher Text zu erwarten sind.
  • Wenn im Artikel == Wegekreuz Poststraße == vorkommt, dann tritt sofort wieder der Doppelte-ID-Bug auf, und es ist ggf. nicht die richtige Stelle.
  • Es hat ja seinen Grund, warum deren Einbindungen in der Fehlerliste aufschlagen.
Umgekehrt ist die Frage, ob dieses name= in der dargestellten Karte überhaupt sichtbar wird.
  • Falls ja, dann sollte idealerweise die Programmierung der Vorlage von sich aus für alle sinngemäß ein id="Koordinate {{{name}}}" generieren und damit die Kollision ausschließen; in der Hoffnung, dass es keinen Abschnitt == Koordinate Wegekreuz Poststraße == geben wird.
VG --PerfektesChaos 14:20, 9. Okt. 2024 (CEST)Beantworten
in id="" ist whitespace gemäß HTML-Standard unzulässig. --ɱ 14:24, 9. Okt. 2024 (CEST)Beantworten
@ „whitespace“: Gute Vorlagen setzen ohnehin ein urlencode zur Generierung ein. Die Bezeichnung Wegekreuz Poststraße ist Benutzereingabe aus 100.000 Einbindungen durch Autoren mit Leerzeichen.
Dann also komplett: id="Koord.{{urlencode:{{{name}}}}}" und eine Kollisionsgefahr mit == Koord.Wegekreuz Poststraße == ist ziemlich ausgeschlossen, weil „nicht als menschlicher Text zu erwarten“.
„sinngemäß“ bedeutet, dass die Programmierung noch nicht vollständig dargestellt sein sollte, sondern nur symbolisch das Wesentliche (Voranstellen eines Präfix) hervorgehoben wurde.
VG --PerfektesChaos 14:37, 9. Okt. 2024 (CEST)Beantworten

Ich staune. Das Name wird sichtbar in den über z.B. {{Hinweis Seiten-Koordinaten}} angesteuerten Karten. Nicht eindeutige Namen führen zu nicht identifizierbaren Punkten etwa in Liste der Kriegerdenkmale im Main-Tauber-Kreis: [1], aber Namen in CamelCase sind nur für Nerds lesbar, siehe etwa [2] oder [3] (dir fällt es sicher leicht, dir alle Whitespaces links wegzudenken und die Umlaute url-encoded zu lesen). Scheints als wäre das Problem in der aktuellen Konstellation nicht lösbar. lg --Herzi Pinki (Diskussion) 15:03, 9. Okt. 2024 (CEST)Beantworten

Abgerufen von „https://de.wikipedia.org/w/index.php?title=Hilfe_Diskussion:Wikisyntax/Validierung&oldid=250483360“