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.

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

...

• Spezial:LintErrors/obsolete-tag [1] erneut absichtliche Provokation durch Verwendung veralteter Tags und bewusster Erzeugung von Linterfehlern -- Lómelinde 06:43, 12. Jan. 2024 (CET)Beantworten

  Der Sinn und Zweck der Konstruktion bleibt rätselhaft.

  <div style="display:none">{{Du darfst nicht}}</div> ist ja völlig okay.

  Aber das strike um etwas, das ohnehin keinen sichtbaren Text enthält, geht nicht auf gleichem Level.

  Das angestrebte Ziel ist auch nicht nachvollziehbar: Was soll eigentlich sichtbar sein, was nicht? Was unsichtbar ist, braucht und kann auch nicht durchgestrichen werden.

  Um einen sichtbaren Block durchzustreichen, ginge: style="text-decoration:line-through"

  Was nur zur Erinnerung dastehen soll, aber nicht sichtbar oder sonstwie wirksam sein soll, wäre HTML-auszukommentieren.

  strike bleibt strike bleibt inline, und ändert diese Element-Eigenschaft auch nicht durch ein CSS-display, und lässt sich nicht HTML-valide anders verschachteln.

  VG --PerfektesChaos 09:31, 12. Jan. 2024 (CET)Beantworten

Es ist wirklich sehr unschön, dass Doc Taxon und da mit seinem Kommentar →Disk →Spezial:Diff/240895238 als Admin derart Felsbrocken in den Weg gelegt hat, und die Reaktionen = Provokationen damit befördert hat anstatt uns zu unterstützen, leider nicht zum ersten Mal. Das ist nicht hilfreich und macht alles nur noch schwieriger. Wenn wir es einem Benutzer erlauben sich provozierend gegen die Fehlerbehebung durchzusetzen, werden andere folgen. Wirklich sehr, sehr, sehr schade. Es ist eh schon schwer genug. Ich schrieb wird es administrativ entfernt werden und er als Admin antwortet „ne ist Sache des Benutzers darf jeder selbst entscheiden“ →Spezial:Diff/240885136. Ich fasse es echt nicht. --Liebe Grüße, Lómelinde Diskussion 07:29, 15. Jan. 2024 (CET)Beantworten

+1 Andim (Diskussion) 09:11, 15. Jan. 2024 (CET)Beantworten

1. Es gibt keinerlei Legitimation per MB, dass ihr andere in ihrem BNR belästigen dürft und du hast keinerlei Legitimation, mir Dinge zu verbieten. Bitte Wikipedia:Administratoren/Anfragen/Archiv/2024/Januar#Sinn_und_Unsinn_der_LintErrors-Korrekturen_im_BNR beachten, die Community wünscht dies nicht.

2. Und wenn Menschen mit >800 Artikeln von Accounts mit 0 Artikeln zu Rechtfertigungen gedrängt werden, läuft hier sowieso was falsch. „Das muss doch wirklich nicht sein.“

3. Wenn die Wikisoftware eines Tages das von mir gewählte Tag nicht mehr unterstützt, ist auf meiner Benutzerseite <center> zu lesen, mich wird das nicht stören. Wen provoziere ich damit, wenn das dann zu lesen ist & welcher Schaden entsteht dabei? --ɱ 10:47, 15. Jan. 2024 (CET) PS: Das center-Tag auf meiner BNR-Seite hat Bestandsschutz, ich widerspreche hiermit der damaligen Ersetzung.Beantworten

Seiten im BNR sind ausschließlich dafür vorgesehen, den Zielen des Gesamtprojekts zu dienen.

• In erster Linie werden hier Artikelentwürfe erarbeitet, oder Material und Komponenten für zukünftige ANR-Bearbeitungen zusammengestellt.
• Damit muss von aller fehlerhafter BNR-Syntax vermutet werden, dass sie früher oder später in den ANR gelangen wird.
• Der einfachste Weg ist es, dass es in keinem Namensraum ungültige Syntax gibt. Dieser Zustand war auch bereits über Monate bis auf vorübergehende Stunden in einzelnen Seiten aufrechterhalten worden.
• Wenn sich nun ein Berg an womöglich auch noch absichtlich ungültiger Syntax im BNR anhäuft, lässt sich nicht mehr frühzeitig in Artikelentwürfe eingreifen.

Wer nicht weiß, was ungültige Syntaxkonstruktionen wären, müsste ggf. die Kenntnisse in Quelltextsyntax verbessern. Das ist etwa bei Verschachtelung von inline und block nicht immer trivial.

• Aus den unter AGF ausgeführten Korrekturen lässt sich lernen, wie es richtig geht.
• Früher hat die Wiki-Software alles unbeanstandet akzeptiert, und es kam irgendwas dabei heraus. Bei ungültiger und damit undefinierter Syntax war das Ergebnis aber nur zufälliger Momentanzustand, und mit Wechsel der Werkzeuge für die Interpretation undefinierter Konstruktionen (Tidy, Remex, …) kam etwas ganz anderes heraus. Sichtbare und zerschossene Darstellungen durch unerlaubte Syntax mussten wir später in Zigtausenden von Edits über Jahre reparieren.
• Logischerweise ist der Schluss daraus, zu lernen, wie es richtig geht, und dies überall bei Quelltextbearbeitung umzusetzen.
• Ein Nutzen für das Projekt ist nicht ersichtlich, der darin bestehen soll, es mit voller Absicht falsch zu machen, weil optisch kommt ja bei mir das raus wie ich es mir vorstelle.

VG --PerfektesChaos 11:36, 15. Jan. 2024 (CET)Beantworten

„lässt sich nicht mehr frühzeitig in Artikelentwürfe eingreifen.“ ist doch Blödsinn, das Projekt hat doch problemlos die Anzahl der LintErrors im ANR von x Mio auf 0 gedrückt, da kommt es auch mit Artikelentwürfen zurecht, die erst dann korrigiert werden, wenn sie im ANR eingestellt werden. „müsste ggf. die Kenntnisse in Quelltextsyntax verbessern“ – japp, machen wir die Mitarbeit bei einem Autorenschwund noch komplizierter, das ist der richtige Weg. Und bei meiner Benutzerseite handelt es sich um keinen Artikelentwurf, da gibts daher noch weniger einen Grund, mich zu bevormunden. Wie gesagt, holt euch per MB eine Legitimation. Ihr habt euch da BNR-Befugnisse angeeignet, die euch keiner gegeben hat. --ɱ 11:46, 15. Jan. 2024 (CET) PS: deprecated != falschBeantworten

Das Meinungsbild, dass behauptet, dass die Community das nicht wünscht hätte ich bitte offiziell verlinkt! Es ist eher das Gegenteil der Fall, sehr, sehr, sehr viele Benutzer bedanken sich tagtäglich für diese Fehlerbehebungen auch in ihrem Benutzerbereich. Das kannst du an den Dankeschöns jener Benutzer nachvollziehen, die sich um die Behebung dieser Fehler kümmern. Es ist überhaupt nichts kompliziert, da sich nicht jeder mit Syntax auskennt werden die Fehler im Hintergrund behoben. Es gibt nur eine handvoll Benutzer die lautstark meint auf ihren Fehler bestehen zu müssen. Vergleichen wir doch mal die Zahlen der Dankeschöns vom letzten Jahr, da hat zwar auch Mirji 244 Dankeschöns aber nehmen wir At40mha, dem du ja vorwirfst keinerlei Artikelarbeit zu leisten so stehen dort 623 Dankeschöns zu Buche und bei mir sind es sage und schreibe glatte 1000. Soviel zu „von der Community unerwünscht“. Auch Andim hat mit 318 weit mehr als du. Ich würde sagen Du stehst da eher allein auf weiter Flur, mit der Meinung Fehler müssten erlaubt sein. Ach ja und die Hilfeseite könnte ich jederzeit textlich anpassen, der Inhalt dort stammt überwiegend sowieso von mir. --Liebe Grüße, Lómelinde Diskussion 12:08, 15. Jan. 2024 (CET)Beantworten

„wer hat hier den längsten“ – ernsthaft? Dankeschöns ersetzen MBs. Genau mein Humor. Einen schönen guten Tag. --ɱ 12:12, 15. Jan. 2024 (CET) PS: Bitte nicht meine Worte umdrehen: es gibt keinerlei MB, welches euch zur Bevormundung legitimiert. Waren die Dankeschöns alle für BNR-Edits? ^^Beantworten

"Problemlos" ist dein Empfinden. Dass das aber mehrere Jahre gedauert gedauert hat, wird dabei unterschlagen; ebenso wie die Tatsache, dass der BNR (inkl. Disk) mehr Linterfehler als jeder andere Namensraum hatte. Wir erschweren auch nicht die Mitarbeit von Neuautoren, da wir ausweislich deiner eigenen Forderungen offensichtlich nur deine Kenntnisse der Quelltextsyntax verbessern müssten. Derzeit verwendest du deine Benutzerseite nur dazu, einen absichtlichen Syntaxfehler in der WP zu halten. Wenn Doc Taxon hier Recht hat, kann man nur fassungslos sein. Im übrigen kann man durch Quantifizierung nicht auf Qualität schließen, so wie du es weiter oben versuchst. --darkking3 ^Թ 12:24, 15. Jan. 2024 (CET)Beantworten

Du irrst. Ein von _allen_ aktuellen Browsern unterstütztes Tag ist kein Syntaxfehler. --ɱ 12:29, 15. Jan. 2024 (CET)Beantworten

Nein, ich hatte nicht Recht, siehe Diff. Das war mir bis dato nicht bekannt. – Doc Taxon • Disk. • 12:30, 15. Jan. 2024 (CET)Beantworten

Im übrigen beruft sich da Mabschaaf auf eine Regel, die er eingefügt hat. Das ist anmaßend und durch kein MB legitimiert. --ɱ 12:34, 15. Jan. 2024 (CET) PS: Gestern auf AA gab es Widerspruch aus der Community, da musste es dann ganz schnell archiviert werden. Wie wäre es, über die dort aufgezeigten Probleme zu diskutieren, wie der Zwang zu zeitraubenden BKs? Die Empfehlung, in seinem eigenen BNR {{Vorlage:In Bearbeitung}} setzen zu sollen, damit man _in Ruhe_ an seinen Entwürfen arbeiten kann? Die Drohung mit administrativen Schritten gegenüber Mitarbeitern? Holt euch bitte erstmal die Legitimation!Beantworten

Es hat noch niemals ein MB stattgefunden, das die behaupteten Alleinbearbeitungsrechte verankern würde.

• Dementsprechend ist es auch nicht erforderlich, ein MB zu starten, das jetzt eine Ausnahme dieses nicht exisitierenden Alleinbearbeitungsrechts begründen würde, oder sonst irgendeine „Legitimation“ beibringt.

Es gibt nur im Rahmen einer technischen Software-Anleitung einige Hilfe:Benutzernamensraum #Konventionen.

• Dort wird allerdings eine Vielzahl von Einschränkungen und unzulässigen Inhalten einer Benutzerseite aufgezählt; jedoch ohne Anspruch auf Vollzähligkeit. Wenn dort etwas nicht explizit genannt ist, bedeutet das nicht, dass es dewegen erlaubt und in das ermessen des Kontos gestellt wäre.
• Das behauptete Verbot einer Bearbeitung durch nimand ausgenommen das Konto findet sich dort nicht.
• Lediglich eine „Gestaltungshoheit“ wird eingeräumt.

Ein Grundsatz lässt sich aber aus den Spielregeln des Projekts ableiten:

• Die BNR-Seiten müssen den Zielen des Projekts dienen.
• Sie dürfen nach außen keine schädlichen Wirkungen haben.
• Wenn den Projektzielen dienlich und nicht schädigend, dann wird erstmal pauschal geduldet was dort steht.

Die zitierte „Gestaltungshoheit“ zielt nur auf die resultierende Darstellung, insbesondere auch den Inhalt ab.

• Mit welcher Syntax die angestrebte Darstellung erreicht wird, ist davon nicht geschützt.
• Insbesondere ist nicht geschützt, absichtlich eine fehlerhafte Syntax zu verwenden, nur um etwas zu beweisen, und damit die Arbeit anderer vorsätzlich zu stören.

Es ist unmaßgeblich, was Browser unterstützen würden.

• Auch veraltete Syntax von 1992 versuchen Browser noch irgendwie darzustellen.
• Wikitext-Seiten sind in Wikisyntax geschrieben, nicht in irgendeinem HTML.
• Was gültige Wikisyntax ist, ergibt sich aus dem Wiki-Parser und der sonstigen Wiki-Software; wenn dieser zu behebende Fehler meldet, dann sind das Fehler.

Meinen Beitrag als „Blödsinn“ zu bezeichnen ist ein Verstoß gegen WP:WQ.

• Statt sich in persönlichen Angriffen zu ergehen und stundenlang nicht existierende Hoheitsrechte zu behaupten, wäre es dienlicher, die korrekte Wikisyntax zu erlernen, künftig überall anzuwenden und sich der Verbesserung des Gesamtprojekts zu widmen.

VG --PerfektesChaos 12:46, 15. Jan. 2024 (CET)Beantworten

„Sie dürfen nach außen keine schädlichen Wirkungen haben.“ - ich bin gespannt, worin die schädliche Wirkung eines <center> besteht? Im Gegensatz richtet ihr im BNR Schaden an, wenn die enzyklopädische Arbeit mit zeitraubenden BKs behindert wird! --ɱ 12:48, 15. Jan. 2024 (CET)Beantworten

Du möchtest provozieren, warum? Die WikiMedia hat das Tag als veraltet und „auf ihren Seiten nicht mehr erwünscht“ eingestuft und erwartet, dass derartige Fehler behoben werden, nur aus dem Grunde werden die Fehlerlisten erstellt, um Fehler finden zu können und sie zu beheben und irgendwann die nächste Stufe der Softwareumstellungen umsetzen zu können. Wenn die Projekttechniker eine Ausnahme der Benutzerseiten, und ein Verbleiben der dortigen Fehler gewünscht hätten, dann würden diese nicht gelistet werden, hast Du Dir darüber schon einmal Gedanken gemacht? Du behinderst dies absichtlich und bewusst, das könnte man als diesem Projektziel entgegenstehende Absicht bezeichnen. Was genau soll denn der Grund sein veraltete unerwünschte Syntax zu behalten, wenn das dem Projektziel widerspricht? Was hast du denn davon? Stress für alle, nur weil du das so möchtest? Möchtest Du Dir immer neuen Fehler ausdenken, damit Du andere belästigen und das angestrebte Projektziel sabotieren kannst? --Liebe Grüße, Lómelinde Diskussion 12:51, 15. Jan. 2024 (CET)Beantworten

Weiter unten Hilfe_Diskussion:Wikisyntax/Validierung#Fehler_in_den_Lint-Listen ist nachzulesen, dass nach euren Wünschen da Fehler aufgenommen werden. Oh, ihr bestimmt, was unterwünscht ist und ihr setzt das dann durch. Auf AA gabs Community-Widerspruch, holt euch Legitimation. Ich bin hier raus. --ɱ 12:53, 15. Jan. 2024 (CET)Beantworten

Fakten:
HTML-Standard „16.2 Non-conforming features [...] Elements in the following list are entirely obsolete, and must not be used by authors: [...] center [...]“
Wikipedia Hilfe-Seite Hilfe:Wikisyntax/Validierung#Namensräume und relevante Projektseiten „Ziel ist die Korrektur aller Fehler auf allen Seiten. [...] Aktuelle Benutzer- und Benutzerdiskussionsseiten sowie Artikeldiskussionsseiten.“ --At40mha (Diskussion) 13:07, 15. Jan. 2024 (CET)Beantworten

Die Web Hypertext Application Technology Working Group steht nicht über dem World Wide Web Consortium, deren Dokumente sind nicht bindend. --ɱ 13:14, 15. Jan. 2024 (CET)Beantworten

@Mirji: Ich fürchte du verstehst es wirklich nicht, dort unten haben wir aufgelistet, was uns noch an falscher Syntax aufgefallen ist, da liest aber keiner von den Softwaretechnikern mit, wir bestimmen nicht, was Fehler sind und wären froh, wenn der Spuk irgendwann mal vorüber wäre.

Und ja bezüglich deiner Streichung Spezial:Diff/241201050/241201087 eben, dein Zwergenaufstand um bewusst eingefügte Syntaxfehler und diese Diskussion hier und andernorts, die sich nur um dich und die von dir mutwillig verursachten Fehler drehen, erzeugen auf allen Seiten Stress. Dabei könntest du das ganz leicht abstellen, einfach den Fehler beheben und niemand würde mehr deine Seite[n] ansehen. --Liebe Grüße, Lómelinde Diskussion 13:16, 15. Jan. 2024 (CET)Beantworten

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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>

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

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

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

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

{|
|
{|
|

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

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

So etwas ''Text''' passiert leicht, wenn Leute das hier '''Text' weitere Text'' erreichen wollen, das soll dann so aussehen ‘Text’ weiterer Text oder anders so Text weiterer ‘Text’ Meldung durch Benutzerin:Lómelinde

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

8. 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)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

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

<small>
Kleinerer Text
</small>

Meldung durch Benutzerin:Lómelinde

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

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

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

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

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

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

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

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

15. Fehler: mehrfaches "id" In Ironman findet sich das Konstrukt <sup class="fussnoten-marke reference" id="FN_5_back"><a href="#FNZ_5">5</a></sup> 23 mal. "id" muss eindeutig sein, siehe https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/id --Wurgl (Diskussion) 16:24, 21. Apr. 2023 (CEST)Beantworten
16. Fehler: Falsche Verschachtelung von Klammern [[Datei:Junghuhn Quersc(…)|230px|{{Center|Quer(…)java]]}} Siehe auch Spezial:Diff/233053556 --Wurgl (Diskussion) 09:04, 22. Apr. 2023 (CEST)Beantworten
17. Fehler: Ähnlich wie beim font→Hilfe:Wikisyntax/Validierung#Altes Verhalten von Link-Wrapping-Font-Tags, wenn span-color-Anweisungen außerhalb von Links stehen, insbesondere bei Signaturen fiktives Beispiel: <span style="background:darkblue; color:gold;">[[BD:Beispielnutzer|Diskussion]]</span> sollte sein [[BD:Beispielnutzer|<span style="background:darkblue; color:gold;">Diskussion</span>]] = Diskussion oder bisher unbeanstandet Ralf ¿•Kãʄʄchen•? → <span style="color:maroon; class=texhtml"> [[Benutzer_Diskussion:Ralf Roletschek|¿•Kãʄʄchen•?]]</span> ¿•Kãʄʄchen•? sollte sein  [[Benutzer_Diskussion:Ralf Roletschek|<span style="color:maroon;">¿•Kãʄʄchen•?</span>]] ¿•Kãʄʄchen•? Ló 08:55, 8. Mai 2023 (CEST)Beantworten
18. Fehler: ignorierte Tags alleinstehendes </p> Beispiele gilt ebenso für </ref> und ich füge hier mal auch noch falsche references mit ein →<references \> Ló 17:45, 8. Mai 2023 (CEST)Beantworten
19. Fehler: Wird <small> innerhalb eines Links geschlossen, ist dies ein fehlendes End-Tag. Da aus einem vorherigen Fehler (siehe eins drüber) schließende Tags offensichtlich ignoriert werden, ist dies aus meiner Sicht kein fehlendes End-tag, sondern falsch verschachtelter Inhalt. <small>[[Benutzer Diskussion:Hosse|'' Talk''</small>]]; Diff; das gilt ebenso für Kursiv-Tags, jedoch werden zwei Fehler für fehlende end-Tags geworfen Diff --darkking3 ^Թ 10:38, 10. Mai 2023 (CEST)Beantworten
20. Fehler: Syntax in Alternativtext von Wikilinks wird falsch behandelt: ''T<small>est''</small>. ist falsch verschachtelt; [[Test|''T<small>est''</small>.]] ist ein fehlendes End-Tag. Das schließende Tag wird ignoriert, siehe auch die beiden Fehler hierüber. --darkking3 ^Թ 15:45, 10. Mai 2023 (CEST)Beantworten
21. Fehler: Durcheinander in Tabellensyntax führt dazu, dass für die Leser sowas wie „style="background…"“ oder „style="text-align:left“ sichtbar ist. Hab heute ca. 30 dieser Fehler korrigiert. --Wurgl (Diskussion) 16:19, 13. Mai 2023 (CEST)Beantworten
22. Fehler Klammern [] im Weblink [http://www.example.org/ Linktext wird durch [Klammer] zerbrochen] fällt nur auf, wenn der Linktext kursiv gesetzt wurde. Ló 17:54, 28. Mai 2023 (CEST)Beantworten
23. Fehler: eingerückte references-Tags Spezial:Diff/62955026 nach links verschobene und defekte Darstellung mit • vor dem ↑ deutlicher zu sehen wenn es mehrere refs sind →Spezial:PermaLink/229158856#cite note-4 Ló 09:09, 13. Jun. 2023 (CEST)Beantworten
24. Fehler: Tabelle beginnt außerhalb von "Datei:" und endet innerhalb. Fehler sieht man im VE: https://de.wikipedia.org/w/index.php?title=Wahlen_zum_Repräsentantenhaus_der_Vereinigten_Staaten_1894&veaction=edit&oldid=229600536 (runterscrollen) Difflink: Spezial:Diff/229600536/234692463 --Wurgl (Diskussion) 16:29, 18. Jun. 2023 (CEST)Beantworten
25. Fehler: nicht geschlossenes poem-Tag sowohl einzelne <poem …> als auch einzelne </poem> man könnte es durchaus aber erkennen, wenn eines der Tags fehlt. Beispiel <poem style="font-style:italic; margin-left:3em;"> das gilt vermutlich ebenso für math, chem, score also solche Tags mit Spezialdarstellungsfunktionen Hilfe:Tags#ext. --Ló 17:19, 18. Jun. 2023 (CEST)Beantworten
26. Fehler: Kursiv außen um Vorlage:Webarchiv, zerlegt den Link Spezial:Diff/233920013#cite_note-24, so dass zwei Symbole für Externlink entstehen. Gilt auch für Kursivtegs, die außen um einfache Weblinks gesetzt werden, deren Linktitel ebenfalls schon kursiv gesetzt wurde Beispiel: ''Das ist ein [http://example.net/ ''Testweblink''] im Fließtext'' --Ló 09:37, 4. Jul. 2023 (CEST)Beantworten
27. <big></big> wird scheinbar nicht erkannt. Oder wird überprüft, ob es sich um eine Artikelseite handelt? MfG, Dwain 13:51, 26. Sep. 2023 (CEST)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

28. Nicht geschlossenes <syntaxhighlight lang="html"> gilt auch für ein alleinstehendes Ende </syntaxhighlight> Ló 19:17, 3. Okt. 2023 (CEST)Beantworten
29. magic words (ISBN, DOI, ISSN, RFC, PMID …) innerhalb von [Web]Links →ISBN 3-7891-4147-X (Wikilink auf Haus)↔ISBN 3-7891-4147-X oder PMID 12345678 (Weblink aufexample.net)↔PMID 12345678 (so gesehen wären das Links in Links)-- Ló 10:31, 20. Nov. 2023 (CET)Beantworten
    • 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)Beantworten
      • 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)Beantworten
      • 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)Beantworten

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

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

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

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

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

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