Wikipedia:Technik/Skin/MediaWiki/Änderungen

Änderungen im MediaWiki-Namensraum

---

Auf dieser Seite können lokale Änderungen an Codeseiten im MediaWiki-Namensraum, an Helferlein (Gadgets) sowie an Javascript- und CSS-Seiten anderer Benutzer vorgeschlagen werden. Diese können nur von Benutzeroberflächenadministratoren umgesetzt werden.

Automatische Archivierung

Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit 14 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind.

Vorlage:Autoarchiv-Erledigt/Wartung/Festes_Ziel

Archiv

2024 2023 2022 2021 2020 2019 2018

MediaWiki:Common.css – allmähliche Verschlankung

Keine einzelne Aktion, sondern EPIC. Grundlage für eine Serie von Änderungen.

• Die Seite MediaWiki:Common.css sollte weitestmöglich verschlankt werden; eines Tages sogar komplett in Gadgets umgewandelt sein (so auch das angestrebte Ziel seitens der MediaWiki-Entwickler).
• Jede Definition hier wird bei jedem beliebigen Seitenabruf immer eingebunden.
  • Das kostet zumindest einmalig Netzwerk-Traffic.
  • Es zwingt aber den Browser auf jeder Seite, diese nach jeder definierten Regel zu durchsuchen, ob sie hier anzuwenden wäre.
  • Das ist sehr ineffizient, wenn die Trefferquote der Seiten, die solche Selektoren auch enthalten würden, niedrig ist.
• Mit den TemplateStyles und irgendwann hoffentlich auf Namensraum und Spezialseiten eingrenzbaren Gadgets wird sich das weiter reduzieren lassen, so dass nur noch solche Seiten das CSS mitgeliefert bekommen, die auch die Selektoren enthalten können.
• Gadgets werden zumindest momentan noch vor der Common.css in den Kopf des Dokuments geschrieben, so dass CSS aus Gadgets genauso rechtzeitig vor der Darstellung des DOM vorhanden ist und es nicht zum FOUC-Ruckler kommt.
• In den 1990er Jahren war die Trennung von Präsentation und Inhalt aufgekommen, und damit die Verwendung eines einzigen projektweiten CSS-Stildokuments, in dem alle Dekoration vereinbart werden solle, und unabhängig und abgetrennt davon der nackte Inhalt als undekoriertes HTML.
  • Das ist im Grunde genommen sinnvoll.
  • Jedoch funktioniert das lediglich bei einem Projekt mit nur mäßig vielen Stildefinitionen und relativ wenigen Grundtypen von Seiten, die mit einem solchen überschaubaren Satz an Klassen und zugeordneten Dekorationen auskämen.
  • Für ein Wiki wie unseres mit Millionen inhaltlicher Seiten, Feuerwehrautos rot dekoriert und Forstwirtschaft dunkelgrün und Blümchen hellgrün und BVB schwarz-gelb und Hertha blau-weiß und Wolfsburg grün ist es der helle Wahnsinn, eine auf nur wenigen oder gar einer einzigen Seite benötigte Stildefinition alle in die Common.css reinzuschreiben und gnadenlos allen Arten von URL aufzudrücken.
  • Gleichwohl hatte man bei uns diese Strategie bis ca. 2010 verfolgt, es danach aber abgebrochen, weil offenkundig ins Uferlose führend.
  • MediaWiki Diskussion:Common.css/Archiv/3 – suche: Die Commons.css sollte, außer der Hauptseite, keine seitenindividuelle Anpassungen erhalten.
  • Vorlagen bieten eine uns angemessene Möglichkeit, spezifische einheitliche Dekorationen über mehrere Seiten sicherzustellen, und können von sehr vielen Autoren auch selbst erstellt und gepflegt werden, und die Zentralisierung in der Vorlage erlaubt die effiziente Pflege an nur einer Stelle.
  • Dabei werden relativ zwangsläufig auch inline styles verwendet. Abstrakte Theoretiker mögen das zwar als Verletzung der alleinseligmachenden Lehre geißeln; es ist aber eine unmittelbar einleuchtende Methodik mit gut überschaubaren Auswirkungen, während die Konstruktion von in einer Seite gleichzeitig wirkenden und kollisionsfrei zu organisierenden Klassensystemen und Definition über TemplateStyles von der Autorenschaft kaum geleistet werden kann.
• 2016 hatte Entlinkt bereits in verdienstvoller Weise aufgeräumt, Ballast aufgelöst und die Seite strukturiert, soweit bis dahin möglich.

VG --PerfektesChaos 16:41, 21. Sep. 2018 (CEST)

Änderungswünsche

Benutzeroberfläche‎: Umfrage beendet

Zu: Wikipedia:Umfragen/Verschlankung der Benutzeroberfläche

• Vorbemerkung: Die „Auswertung“ stammt nicht vom Ersteller der Umfrage und erfolgte unabgesprochen und ungefragt.

Grundsätzlich ist es jetzt Einschätzung möglicherweise umsetzender Admins, inwieweit die absolute Anzahl an Stimmen sowie das Verhältnis für eine Aktivität hinreichend erscheint.

Zu den Punkten im Einzelnen:

• Zu „Datei hochladen“ wird offenbar eine Umlenkung des Linkziels gewünscht.
  • Das müssten die BOA dann in eigener Verantwortung realisieren.
• Der Punkt „Änderungen an verlinkten Seiten“ wird offenbar von einigen Langzeit-Autoren weiterhin für sich persönlich gewünscht, kann aber offenkundig ohne Not für nicht angemeldete Leser wegfallen.
  • Das ließe sich über die Common.css realisieren, indem #t-recentchangeslinked zunächst ein display:none erhält, und danach .useronly #t-recentchangeslinked ein display:block
• „Fragen von Neulingen“ wird offenbar von einigen Benutzern gewünscht; ggf. einfügen.
• Die „Druckversion“ macht nichts anderes als die heutzutage möglichen Browser von selbst machen können.
  • MediaWiki wird dies über kurz oder lang von selbst im Zuge anderer Desktop-Änderungen entfernen.
  • Kann bis dahin per CSS ausgeblendet werden; ist uns nicht direkt zugänglich.
  • Grundsätzlich fällt umso mehr Aufmerksamkeit auf die verbleibenden Punkte, je weniger andere Funktionen es gibt – umso kürzer die Aufzählungen sind.

Generell läuft zurzeit auch global ein Experiment zur Modernisierung der seit 2010 unveränderten Desktop-Oberfläche.

• Dabei haben sich um zehn Wikis gemeldet, die bereit sind, auf ihrem Wiki Änderungen zu erproben und auswerten zu lassen.
• Die Erfahrungen dieser Wiki-Communities werden danach global für sämtliche Wikis einheitlich umgesetzt. Ansichten der deutschsprachigen Wikipedia sind dann irrelevant.
• Insbesondere ist zu erwarten, dass für nicht angemeldete Leser die Oberfläche deutlich gestrafft und reduziert sowie voraussichtlich auch eingeklappt wird.
• Was für angemeldete Benutzer passieren soll, bleibt abzuwarten; es werden aber wohl in jedem Fall die Funktionalitäten inhaltlich sauberer gegliedert umsortiert.
• Generell gilt die Desktop-Oberfläche von 2010 auch in Koexistenz mit der Mobil-Oberfläche und der zeitgenössischen Gestaltung von den Lesern vertrauter anderer Webseiten als Sanierungsfall.

Was mir schon vor der Umfrage klar war: Für die Autoren von 2005 muss alles auf ewig so bleiben wie sie es 2005 mal gelernt hatten. Der Rest der Welt einschließlich aller Nur-Leser hat sich nach ihnen zu richten.

VG --PerfektesChaos 01:28, 1. Mär. 2020 (CET)

Ich rate von der Umleitung des Datei-hochladen-Ziels auf einen direkten Commons-Upload immer noch dringend ab! Des Weiteren war das eine Umfrage, kein MB. Eine Umfrage dient nur dazu, um abzuschätzen, wie die Stimmungslage ein. Konkrete Handlungen können daraus keine resultieren. -- Chaddy · D 21:42, 1. Mär. 2020 (CET)

Eine direkte Commons-Verlinkung halte ich persönlich auch für schwierig. Eine Verlinkung auf eine Zwischenseite fände ich gut, die klarmacht, dass zwar das Gros nach Commons gehört, Dateien, die unter das Schutzlandprinzip fallen (u.Ä.), aber hier hochgeladen werden müssen. NNW 10:17, 2. Mär. 2020 (CET)

MBs sind keine Pflicht – wenn Konsens besteht, kann selbstredend auch ohne die Oberfläche modifiziert werden. --MGChecker – (📞| 📝| ) 12:18, 2. Mär. 2020 (CET)

*quetsch* An Umfragen nehmen aber stets nur recht wenige Leute teil, eben weil sie durchaus zu Recht der Ansicht sind, dass es ja nur eine unverbindliche Umfrage sei. Daraus dann einen Konsens ableiten zu wollen ist zu kurz gegriffen. -- Chaddy · D 15:41, 2. Mär. 2020 (CET)

• Mein ursprünglicher Vorschlag in der Portalseite lief darauf hinaus, die Direktverlinkung auf die hiesige Spezialseite im Portal-Rahmen ersatzlos zu streichen und nur noch über Bildertutorial, Hilfeseiten oder andere Projektseiten zum Hochladen zu führen; ersatzweise über Spezial:Spezialseiten für Insider.
  • Dadurch sollen Hochlade-Interessenten sich vorher Gedanken über Rechte, unerwünschte Bilder und auch die Wahl des geeigneten Wikis machen.
  • Die „Zwischenseite“ wäre gerade die Anleitung, die sowas erklärt, und davon haben wir bereits diverse. Tendenz der Umfrage ist jedoch, dass sich für die Hardcore-Autoren von 2005 nichts ändern darf, was sie 2005 mal gelernt hatten, und es deshalb keinerlei zusätzlichen Klicks und zwischengeschalteten Menüs wie Spezial:Spezialseiten geben dürfe, sondern für sie alles mit nur einem Klick erreichbar bleiben solle.
• Die Direktverlinkung im Portal stammt von 2003/2004 und damit aus einer Zeit, als es noch gar keine großen Anleitungen gegeben hatte, und auch Rechtsfragen in DACH unterschiedlich als auf dem gerade erst begründeten Commons steckten noch in den Kinderschuhen.
• Weil alles auf ewig so bleiben muss, wie es 2005 mal gewesen war, auch wenn es inzwischen um die 200 Spezialseiten gibt und seinerzeit noch kein Dutzend, die man mal alle einzeln im Portal direkt zu verlinken gedachte, sieht der Rahmen halt noch so aus wie 2005/2010 stehengeblieben.
• Auf WP:NEU #Version 1.35.0-wmf.21 steht inzwischen bereits die Ankündigung des Legacy-Vector, welches den Zustand von 2010 einfriert, während Vector sich davon abkoppeln wird und Schritt für Schritt zunächst für nicht angemeldete Besucher die Modernisierung vollziehen wird.
• Kein Admin ist verpflichtet, ein Ergebnis der Umfrage umzusetzen, das als nicht zielführend eingeschätzt wird.

VG --PerfektesChaos 12:54, 2. Mär. 2020 (CET)

Diesen Vorschlag halte ich für sinnvoller als einen direkten Commons-Link.

Ein bisschen weniger auf uns alte Hasen zu schimpfen wäre allerdings auch nicht verkehrt. -- Chaddy · D 15:44, 2. Mär. 2020 (CET)

wikEd

Ich habe eben den „wikEd“ unter den Helferlein in den Einstellungen ausprobiert. Dieser editor ist eine einzige Katastrophe. Ein Beispiel: Wenn ich auf der Disk signieren will, lande ich - ohne es zu zu beabsichtigen - in der Überschrift des Threads. Auch andere schwerwiegende Fehler traten auf. Die Programmierung ist sehr fehlerhaft. Kann der wikEd bitte sofort aus der Liste der empfohlenen Helferlein entfernt werden?!!! (Ich hoffe, ich bin auf der richtigen Seite für so ein Problem gelandet.) Gruß --Orik (Diskussion) 23:47, 4. Apr. 2020 (CEST)

Du bist auf einer durchaus zur Erörterung geeigneten Seite gelandet.

Der wikEd funktionierte wohl ein Jahrzehnt lang recht gut.

Dies unbeschadet durchaus kritikwürdiger und riskanter Programmierpraktiken; sowie der klaren Beschränkung auf eine spezielle Browser-Architektur. Ist aber bei einem Riesendingens wie diesem als ehrenamtliches Solo-Werk kaum zu vermeiden, zumal die Anfänge von wikEd in einem völlig anderen Zeitalter lagen und dies immer wieder deutlich modernisiert wurde.

Bekannt ist allerdings, dass der ein Jahrzehnt lang unermüdlich schuftende Entwickler in jüngerer Zeit wohl recht inaktiv war, insbesondere keine Anpassungen mehr vornahm.

Die dortigen Erörterungen in der englischsprachigen Wikipedia wären für unser weiteres Vorgehen maßgeblich; also Benutzer- bzw. Projektseiten.

Die erste Stufe nach erster Erkenntnis wäre jedoch nur ein allgemeiner Warnhinweis auf Wikipedia:Technik/Skin/Gadgets/wikEd.

Es ist jedem unserer Bearbeiter freigestellt, das Dings wieder wegzuhakeln, wenn es beim eigenen Browser nicht (mehr) korrekt funktioniert. Es ist keine Default-Option, die wir allen Benutzern aufzwingen würden.

Erst bei nachhaltiger unreparierter schädigender Funktion würden wir unser Gadget durch irgendeine Form von Fehlermeldungsbaustein ersetzen bzw. dahingehend ändern, da wir ohnehin nur nach einigen Vorbereitungen das englischsprachige Gadget laden.

VG --PerfektesChaos 13:56, 5. Apr. 2020 (CEST)

inhaltlicher falscher Seitenschutz-Hinweis in englischer Sprache

(Nicht ganz sicher, ob das hier richtig ist.)

Ich wollte gerade eine Seite mit *Halbschutz* *Dreiviertelschutz* bearbeiten und bekam folgenden Text in einer gelben Warnbox eingeblendet:

Warning: This page has been protected so that only users with administrator privileges can edit it. The latest log entry is provided below for reference: …

Meine Benutzeroberfläche wird in englischer Sprache angezeigt, deshalb ist die Wahl der Sprache zwar richtig, ihr Inhalt aber nicht da die Seite ja nicht vollgeschützt ist und ich sie tatsächlich auch bearbeiten konnte. Mit URL-Parameter "?uselang=de" bekomme ich in der Tat die inhaltlich korrekte deutschsprachige Nachricht:

Achtung: Diese Seite wurde geschützt, so dass sie nur durch Sichter bearbeitet werden kann. Gründe für den Seitenschutz finden sich im Seitenschutz-Logbuch, auf der Diskussionsseite oder in den Regeln für geschützte Seiten. Auszug aus dem Seitenschutz-Logbuch: …"

Jetzt finde ich gerade nicht, ob das onwiki irgendwo im Mediawiki-Namensraum zu verändern ist, oder ob das in die Software eincodiert ist oder über das Translatewiki geht. Kann da bitte mal jemand nachschauen?

Dankeschön, MisterSynergy (Diskussion) 21:39, 19. Apr. 2020 (CEST)

@MisterSynergy: Das ist eine lokale Anpassung in MediaWiki:Protectedpagemovewarning. Demnach hier nicht in Englisch verfügbar. Könnte man hier für Englisch natürlich einrichten. Das Original findest du hier: translatewiki:MediaWiki:Protectedpagemovewarning/de. — Raymond ^Disk. 21:45, 19. Apr. 2020 (CEST)

BK

Erstmal würden die einfachen WP:A/A hier reichen, wenn überhaupt, da es sich um eine textliche Nachricht auf dem Server handelt und nicht um eine Programmierung in einer Programmiersprache des Browsers.

Des weiteren könnte es um ein konzeptionelles Problem gehen; der englischsprachigen globalen Welt ist womöglich unser lokales Konzept des Dreiviertelschutz unbekannt – insbesondere sind „Sichter“ eine deutschsprachige Spezialität. Für fast jedes andere Wiki ist „mehr als Halbschutz“ identisch mit „Admin erforderlich“.

Deine eingangs erfolgte Situationsschilderung kann nicht zutreffen; es ginge nicht um „Halbschutz“ (IP oder Newbies ausgeschlossen), sondern um „Dreiviertelschutz“ (Nicht-Sichter ausgeschlossen).

Ich werde das weiter ermitteln und die weiteren Schritte veranlassen; hier erl.

LG --PerfektesChaos 21:48, 19. Apr. 2020 (CEST)

Ja sorry, ich glaube "Dreiviertelschutz" meinte ich. Vorlage:COVID-19-Box war die Seite, bei der ich das gemerkt habe. —MisterSynergy (Diskussion) 21:53, 19. Apr. 2020 (CEST)

 Info: Es ist nicht MediaWiki:Protectedpagemovewarning, wie weiter oben geantwortet wurde, sondern eine komplexe lokale Programmierung innerhalb von MediaWiki:Protectedpagetext, die auf den Schutzlevel editeditorprotected reagiert (was „Sichter“ meint). Diese müsste komplett ins Englische übertragen werden.

LG --PerfektesChaos 22:10, 19. Apr. 2020 (CEST)

Viele Wikis kennen ein Analogon zum Dreiviertelschutz, insbesondere enwiki mit en:WP:EXTENDEDCONFIRMED. --MGChecker – (📞| 📝| ) 16:46, 9. Jul. 2020 (CEST)

Neues Gadget: markLinks

Funktion

Markierung von Wikilinks.

Insbesondere Zuordnung von Benutzern zu bestimmten Gruppen.

Kompatibilität

Heißt: Neukonzeption von Benutzer:PDD/markAdmins.js

Alle dort bisher verwendeten Benutzerkonfigurationen sollen verstanden werden.

Das Ergebnis soll bis auf Kleinigkeiten und Updates unverändert sein.

Konfiguration

Fundamentaler Unterschied: Die Spezifikation der Gruppenzugehörigkeit einzelner Benutzer soll nicht mehr in einem JavaScript-Code erfolgen, sondern per Wikitext im MediaWiki-Namensraum.

Damit kann wieder jeder Admin die Gruppenzugehörigkeit aktualisieren.

Beispiel auf WP:BETA

Zurzeit werden BOA für die Aktualisierung benötigt.

Der definierende Wikitext kann angezeigt werden; Beispiel

Gadget-Organisation

Die Gadget-Spezifikation von markLinks soll als hidden Gadget hinterlegt werden.

Das bisher von den Benutzern konfigurierte Gadget markAdmins soll dann einbinden:

1. Kompatibilitäts-Code zur Interpretation von Konfigurationswerten
2. markLinks

Implementierung

Zurzeit nicht online.

Konzeption umsetzbar.

Stumpfsinniges, routinemäßiges Runterhacken der einen oder anderen 1000 loc fehlt noch.

Die Umsetzung hängt von der Diskussion in diesem Abschnitt ab.

Anwenderkonfiguration

Vielfältige individuelle Anpassungen können unterstützt werden:

• Alle bisherigen.
• Namensräume:
  • Hinzufügen: Ich will auch im ANR oder in meinem Portal die Signaturen von QS-Bausteinen oder Forumsbeiträge markiert bekommen.
  • Unterdrücken: Auf Dateibeschreibungsseiten will ich aus Performancegründen kein Theater; da interessiert mich das nicht.
• Optische Darstellung:
  • Andere Beschriftungen.
  • Farbkennzeichnung der Verlinkung (bunter Rahmen); dafür kein Text.
• Definition eigener Benutzergruppen und Zugehörigkeiten.

Erweiterung

Konzeptionell ist dies auf alle Namensräume ausdehnbar; also nicht nur auf verlinkte Benutzer.

Vorstellbar wären exzellente, lesenswerte Artikel usw.

Woher eine performante Datenversorgung herkäme stünde auf einem anderen Blatt.

Die technische Infrastruktur ist primär unabhängig von den Namensräumen der Wikilinks.

Selbst URL kämen in Frage, also Domains sowie bestimmte pattern bei bestimmten Domains.

Internationalisierung

Stammcode global einsetzbar; alle Sprachen und Schriften und Projekte.

VG --PerfektesChaos 15:01, 12. Jul. 2020 (CEST)

Wäre zur Konfiguratiion eine JSON-Seite nicht geeigneter? Das sollte deutlich einfacher zu parsen sein, kann (afaik) nicht korrput gespeichert werden, und kann perspektivisch per ResourceLoader in das Gadget geladen werden. --MGChecker – (📞| 📝| ) 20:11, 12. Jul. 2020 (CEST)

Das möchte ich aus mehreren Gründen bewusst nicht:

• Eines Tages geht das harmlosere editsitejson auch noch flöten, und dann sind wir wieder bei den BOA, von denen ich grad weg will;
• das Wikitable-Format ist für Non-Techies sehr viel intuitiver als JSON, und es ist auch robust gegen Syntaxfehler; dann hätte halt mal ein Eintrag keine Dekoration, aber der Rest funktioniert;
• die Wikitable lässt sich sofort und auf low level darauf überprüfen, ob bei eingeschaltetem Gadget die Dekoration übereinstimmt mit den Angaben in der Spalte daneben;
• die Wikitable erlaubt beliebige Kommentare, Standard-JSON null;
• die Wikitable lässt sich unabhängig vom Gadget beliebig für Übersichten durch alle nutzen und rumsortieren;
• statt einer MediaWiki:-Seite ließe sich, auch in anderen Projekten oder für andere Zwecke, genauso eine normale Projektseite verwenden. Könnte dann jetzt schon normale Projektseite unter Dreiviertel sein, aber die Administration der Administratoren organisieren die mal besser selbst unter sich. Im JSON-config steht übrigens noch kein Eintrag, wo die aktuelle Definition abgeholt werden kann.
• Das Parsen einer solchen Wikitable ist in ein paar Zeilen gemacht und fällt gegenüber dem Gesamtaufwand nicht ins Gewicht. Wegen Performance passiert im Hintergrund sehr viel mehr (Caching einer “byte-compiled” aufbereiteten Version). Deshalb interessiert mich auch das Laden der Ressource nicht. Der Abruf vom Server ist der gleiche Aufwand, ob nun ein Seiteninhalt raw oder eine message.

Danke gleichwohl fürs Mitdenken --PerfektesChaos 20:53, 12. Jul. 2020 (CEST)

Ich habe mir das auch mal angeschaut. Im Prinzip halte ich das für eine sinnvolle Idee. Die Definition per Wikitable ist erstmal ungewöhnlich, aber hat wie dargestellt auch Vorteile. Anwendbar wäre das 1:1 auch auf User:Anka Friedrich/markMentors.js, woraus sich meine Hauptfrage ergibt: bleibt eine benutzerspezifische Konfigurationsmöglichkeit erhalten? Ich nutze das Skript seit meiner Kontenmetamorphose nicht mehr, kann mich aber erinnern, dass einige gern auf die Exen-, Commons- oder Wikidata-Admin-Markierung verzichten wollten (genauso sind auch Mentoren nicht für jedermann von Belang) oder die Markierung lieber hochgestellt unfett etc pp. haben möchten. Das zweite könnte man per CSS und Klassenbezeichner regeln, das erste aber nicht. Und: bisher wurden die Markierungen immer innerhalb des Benutzerlinks eingefügt, also ohne Extraverweis zu Admins, BOAs, Stewards etc. Gruß, -- hgzh 18:28, 13. Jul. 2020 (CEST)

TL;DR: Ja.

Man müsste sich nur mit einer race condition herumplagen, bzw. dürfte nicht gleichzeitig über Einstellungs-Häkchen das traditionelle markAdmins starten. Weil, wenn der dann startet, dann würde einmal geflöht, und wer zu spät kommt, den bestraft das Leben.

Es dürften jedoch beliebig oft Definitionen abgefeuert werden, die projekt-offizielle ist nur eine unter gleichberechtigten, und ein Objekt könnte auch statt einer wikitable oder JSON-Seite direkt gefeuert werden.

Wenn man sich sicher ist, dass alle gewünschten Definitionen in der Warteschlange stehen, dann müsste das markLinks zum Schluss geladen werden, und das futtert dann alle angesammelten Definitionen und arbeitet sie ab.

Die vorgesehene markAdmins-Nachfolge-Implementierung würde auch nichts anderes machen als Kompatibilitäts-Optionen zu generieren und abzufeuern, die amtlichen Definitionswünsche abzufeuern, und zum Schluss das ausführende Gadget zur Abarbeitung aufzufordern.

Sollte dann nur keine Konflikte um Buchstaben-Codes geben, oder Design oder sonstige Konfigurationen.

Ob eine Definition von einer Benutzer- oder Projektseite käme, aus MediaWiki: oder in JSON oder Wikitext oder implizit als Objekt mit abgefeuert wird ist völlig egal. Es käme jedoch ggf. auf die Reihenfolge an.

Das markMentors hatte ich vor Jahren mal gesehen und vielleicht implizit im Hinterkopf, aber jetzt dieser Tage nicht von dort vor Augen geholt. War jedoch grundsätzlich mitgemeint. Müsste dann wissen, ob es für diesen Anwender ein markMentors+Admins oder ein markMentors ohne Admins werden solle.

Zu Präsentationsfragen:

• Das A ist in Simulation und JSON-Definition nicht mit einer Verlinkung unterlegt.
• Bei Gebilden wie Omb, so mal angetroffen, halte ich eine erklärende Verlinkung nebst Tooltip jedoch für sehr sinnvoll. Was war jetzt nochmal dieses S wenn es nicht in SG drinsteht? Auch jemand, der mit den Sonderfunktionen nicht so vetraut wäre und nicht sowieso auswendig alle Admins alphabetisch aufsagen kann, kann ja das Gadget aktiviert haben, um zu wissen, wer ihm da gegenübertritt. Hier wird man seltenere unktionsträger nicht herunterbeten können.
• Es ist auch alles konfigurierbar und muss auf jedes Wiki in jeder Schrift passen.
• Grundsätzlich sehe ich mich nicht dazu verpflichtet, jedes Pixel auf ewig exakt auf dem Stand von 2008 zu konservieren und jede verbesserte Funktionalität konsequent abzublocken weil früher hatten wir das ja auch nicht gehabt.

VG --PerfektesChaos 12:56, 14. Jul. 2020 (CEST)

Steward. --Count Count (Diskussion) 13:31, 14. Jul. 2020 (CEST)

Danke verbindlichst für diese Erläuterung an mich privat, aber das Gadget würde ja auch von weniger erfahrenen Benutzern eingebunden, die nicht alle diese Exoten und Codes sicher herunterleiern könnten. Auf der Simulation findest du das unmittelbar vor gell? mit Tooltip und verlinkt. VG --PerfektesChaos 14:28, 14. Jul. 2020 (CEST)

Ich finde das sehr interessant. Schade, dass das hier anscheinend eingeschlafen ist. Wie sieht das in Sachen Serverbelastung aus (Cache)? Auch im Vergleich zum Skript und der – von mir zusätzlichen genutzten und anscheinend noch gar nicht erwähnten – Möglichkeit ggu? — Speravir – 00:22, 12. Feb. 2021 (CET)

ggu verwende ich selbst seit Jahren.

Was der Verweis auf den Server-Cache bedeuten soll, ist unklar. Er hat mit dem gesamten Themenkomplex absolut nichts zu tun.

ggu wertet die im System hinterlegten Informationen aus. Damit ist es per se ungeeignet für:

• SG
• Ex-
• Mentoren
• Nur theoretisch für Com-A, en-A, WD-A usw.
  • Dies bedingt dann jedoch, dass auch alle 1000 Admins der enWP in die CSS-Regel aufgenommen werden müssten, und alle Commons- und WD-Admins auch. Könnte man machen, wird aber etwas übersprudelnd.

VG --PerfektesChaos 08:19, 12. Feb. 2021 (CET)

Caching einer Wikiseite versus eines Skriptes versus eines extern abzurufenden Stylesheets. Caching verringert normalerweise die Serverbelastung, könnte ja sein, dass das auch eine Rolle für die Darstellungsgeschwindigkeit spielt (ggu brauch immer einen Moment). Durch das Caching kann es sein, dass jemand einen veralteten Stand angezeigt bekommt, worauf man kurz hinwiesen sollte (Hilfe:Cache gibt’s ja schon). Mir ging es um den Vergleich, wenn das egal ist, um so besser.

ggu habe ich nur als eine bereits existierende Teilalternative erwähnt, die mehr – nein, besser: – andere Markierungen erlaubt als markAdmins. Du hast aber Recht, dass sie für einiges, was dir an Sinnvollem vorschwebt, nicht geeignet ist. — Speravir – 22:40, 12. Feb. 2021 (CET)

„Caching einer Wikiseite“

• Das hat aber völlig nullkommanullnullnullnull mit dieser gesamten Angelegenheit zu tun.
• Im Cache des Wiki-Servers steht ein HTML-Schnipsel, nämlich der Inhaltsbereich, der aus dem Wikitext generiert wird. Bei Spezialseiten, wo auch sehr häufig Admins usw. zum Markieren auftauchen, gibt es überhaupt keinerlei Cache und der Inhaltsbereich wird spontan generiert. Dieser Inhaltsbereich wird im Moment der Anfrage in den je nach Benutzer und Namensraum unterschiedlichen Portalrahmen eingebettet.
• Der Server liefert immer das gleiche HTML-Dokument aus und hat mit der Angelegenheit hier absolut nichts zu tun.
• Alle Dekoration, sei es über JavaScript wie traditionell markAdmins oder hier neu vorgeschlagen markLinks oder aber per CSS mittels ggu passiert im Client; das ist der Browser des Lesers, und modelt nachträglich das vom Server ausgelieferte immer gleiche HTML-Dokument nur für diesen Leser um.
• Die Ressourcen-Codes aller JavaScript oder CSS stehen sowieso im Browser-Cache des jeweiligen Lesers, werden ohnehin nicht jedes Mal neu übertragen, sondern die von der WMF stammenden Ressourcen werden nur kurz abgefragt ob die Version noch aktuell wäre; bei ggu passiert das einmal pro 24 Stunden.

„ggu brauch immer einen Moment“

• Das liegt daran, dass bei Eintreffen von CSS-Regeln, sei es im Original-HTML-Dokument oder später wirksame Gadgets, jede Regel gegen alle Elemente im Dokument geprüft werden muss, und bei den zutreffenden dann die entsprechende Dekoration angewendet wird.
• Mit je mehr CSS-Regeln man sich zukippt, desto länger dauert es bis alle Regeln für alle Elemente umgesetzt wurden.
• Deshalb steht auch im allerersten Text-Abschnitt dieser Seite eine Epik, die darlegt, warum es Dummfug ist, über 20 Millionen Seiten Regeln auszukippen, die nur in 0,0001 % der Seiten wirksam sind und ansonsten ins Leere gehen.

„für einiges, was dir an Sinnvollem vorschwebt“

• Das ist nicht das, was mir „an Sinnvollem vorschwebt“, sondern SG, Ex-, Com-A, en-A, WD-A usw. ist Kompatibilität zum bisherigen markAdmins, dessen Funktionalität vollumfänglich erhalten bleiben soll.

VG --PerfektesChaos 17:15, 13. Feb. 2021 (CET)

Na, wenn das Caching keine Rolle spielt, um so besser. Dass das Skript die Möglichkeit besitzt, war mir beim Schreiben auf die Schnelle nicht bewusst, obwohl SG ja sogar standardmäßig aktiv ist. Es bleibt aber: Schade, dass anscheinend niemand das hier mit Nachdruck weiterverfolgt hat (ich meine jetzt nicht dich) – wohl, weil es mit markAdmins vordergründig funktioniert und den Leuten die Einschränkungen hinter den Kulissen nicht so klar sind. Aber apropos: BOA kann markAdmins ja nicht markieren … — Speravir – 00:03, 15. Feb. 2021 (CET)

Vorschlag: Interne http:// - Links als externen Link behandeln

Mit der Commons.css wird verhindert, das interne Verlinkungen als externe Links gekennzeichnet werden. Meiner Meinung nach ergibt es Sinn die internen http:// Links, da diese "nicht sicherer" sind, auch zu kennzeichnen. Die Zeilen "#mw-content-text a.external[href^="http://xxx.Wikiprojekt.org"]," sollten meiner Meinung entfernt werden. --𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 _{Rechte | Kenst du scho de boarische Wikipedia?} 13:32, 29. Aug. 2020 (CEST)

Nein, sehr viele Bearbeiter wissen nicht, wie sie Verlinkungen auf Seiten in Wiki-Projekten als Wikilink formatieren könnten, und geben sie als URL an, wenn es sich nicht um den einfachen Seitennamen der Clean URL handelt.

Damit das aber nicht andauernd als angebliche Nicht-Wiki-Verlinkung gekennzeichnet würde, stellen wir Ziele auf eine Wiki-Seite (bestimmter ausgewählter Projekte, insbesondere wir selbst) einheitlich als „intern“ dar.

Typische Beispiele:

• URL-Difflink anstelle von Wikilink (ohnehin noch in unterschiedlichem Farbschema, jedoch ohne Icon).
• Ganz fremdes Wiki anstelle von Wikilink hat sogar den Icon.

Hingegen: Echtes externes Weblink

VG --PerfektesChaos 15:35, 29. Aug. 2020 (CEST)

@𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫: Grundsätzlich stimme ich PC hier zu, trotzdem nochmal eine Verständnisfrage: Warum meinst du, diese Links wären nicht sicherer? — Raymond ^Disk. 19:18, 29. Aug. 2020 (CEST)

@PerfektesChaos, @Raymond http://Links sind unverschlüsselt. Https:// ist seit Jahren Standard und mindestens 99% der Difflinks werden entweder per Wikilink oder mit einem URL-Difflink mit https eingefügt. Die vorgeschlagene Änderung betrifft in der Regel nur alte Archive.--𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 _{Rechte | Kenst du scho de boarische Wikipedia?} 19:33, 29. Aug. 2020 (CEST)

@𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫: Richtig, wenn wir hier nicht schon seit Juli 2019 die MediaWiki-Erweiterung SecureLinkFixer hätten. Diese schreibt im Hintergrund jedes http auf https um, wenn die Webseite standardmäßig https verwendet. Und dies ist bei WMF-Seite auch schon länger der Fall. — Raymond ^Disk. 19:40, 29. Aug. 2020 (CEST)

Raymond, wenn die links sowieso geändert wird, ist der Css code sowieso hinfällig.--𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 _{Rechte | Kenst du scho de boarische Wikipedia?} 08:22, 30. Aug. 2020 (CEST)

Ich denke nicht, denn die Änderung erfolgt nicht im Quellcode, sondern nur beim Rendern der Seite. ich muss aber zugeben, ich weiß nicht, on welcher Reihenfolge da im Hintergrund was passiert. Das könnte man sicherlich im Betawiki austesten. — Raymond ^Disk. 10:01, 30. Aug. 2020 (CEST)

@Raymond Ich habe es gerade getestet der Code ist überflüssig und sollte entfernt werden. --𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 _{Rechte | Kenst du scho de boarische Wikipedia?} 14:50, 30. Aug. 2020 (CEST)

Es wird für die Leser die identische URL im HTML-Dokument produziert für:

• http://de.wikipedia.org/wiki/Wikipedia:Technik
• Wikipedia:Technik

Beachte, dass ich http: geschrieben habe; die MediaWiki-Software erkennt wie korrekt von Raymond dargestellt ein eng befreundetes WMF-Projekt und schreibt das bereits im generierten und ausgelieferten HTML-Dokument auf https: um.

Die obere Verlinkung ist jedoch mit der class="external" gekennzeichnet, und diese bewirkt, dass ein der Verlinkung nachgestellt würde. Damit wären jedoch in unseren Artikeln auf für die Leser unbegreifliche Weise manche Links auf einen anderen unserer Artikel mit gekennzeichnet und die meisten nicht, und das würde nur verwirren. Deshalb unterdrücken wir dann mit dem von dir benannten CSS diesen Icon. Und deshalb ist das auch mitnichten überflüssig, nie gewesen, nie geworden und auch nicht zu entfernen.

Solltest du dich übrigens zur Verbesserung ohnehin bearbeiteter Artikel dafür interessieren, wo im ANR eine URL-Verlinkung statt Wikilink-Format benutzt wurde, könntest du in ähnlicher Weise derartige Verlinkungen für dich persönlich hervorheben, etwa durch einen bunten Rahmen um den Linktext.

Nebenbei bemerkt führt eine URL-Verlinkung nicht zu einer Aufnahme in die Spezial:Linkliste , wovon beim noping gelegentlich bewusst Gebrauch gemacht wird. Damit sind solche Artikel jedoch nicht mehr aktualisierbar, wenn bei Einrichtung von BKS oder sonstiger Aufteilung des Artikels alle bisherigen Verlinkungen gesucht werden. Aus diesem Grund sind URL-Links auf Artikel im ANR massiv unerwünscht.

VG --PerfektesChaos 15:31, 30. Aug. 2020 (CEST)

@PerfektesChaos Siehe hier im barWiki gibt es nur den Eintrag "a.external[href^="https://xxx.Wikiprojekt.org"]" hier werden auch http links nicht markiert.--𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 _{Rechte | Kenst du scho de boarische Wikipedia?} 20:03, 8. Sep. 2020 (CEST)

js/css-Seiten gesperrter Benutzer

Hallo, dank Wurgl gibt es eine Liste mit unbeschränkt gesperrten Benutzern, die eigene JS-Seiten (CSS wäre analog) in ihrem Benutzernamensraum haben. Da sie normalerweise keine Wirksamkeit mehr besitzen und auch nicht mehr von ihren Eigentümern gewartet werden können, schlage ich vor, solche Seiten zu löschen, sofern sie nirgendwo eingebunden sind und es sich nicht um Editcounter-Aktivierungsseiten a la EditCounterOptIn.js handelt. Die Vorteile lägen vor allem darin, möglicherweise veraltete Skripte, Skriptteile oder Funktionsverwendungen loszuwerden und deren Copy&Paste zu verhindern. Auf Phabricator laufen ja immer mal wieder Listen mit von Änderungen betroffenen Seiten auf, die so verkürzt werden könnten. Als zweiten Schritt könnte man diese Aktion noch auf seit langem inaktive Benutzer mit entsprechendem Hinweis auf Wiederherstellungsmöglichkeit ausweiten. Was denkt ihr? Gruß, -- hgzh 12:07, 24. Nov. 2020 (CET)

Finde ich einen guten Vorschlag. Sollte in allen Fällen einen Standardlink auf eine Seite enthalten die beschreibt warum und wie man das wiederkriegen kann. Viele Grüße, Luke081515 12:14, 24. Nov. 2020 (CET)

Kannst du *.js-Seiten denn mit wikitext als Content erzeugen? Oder willst das auf der Benutzerseite machen? --Wurgl (Diskussion) 12:21, 24. Nov. 2020 (CET)

Ich würde die Seite einfach in der Löschbegründung verlinken. Das geht auf allen Seiten. z.B. "xy löscht Seite bla.js ([[Doku|Aufräumaktion Skripte gesperrter/inaktiver Benutzer]])" etc. Viele Grüße, Luke081515 14:04, 24. Nov. 2020 (CET)

Grundsätzlich begrüße ich das in stufenweiser Umsetzung.

• Zunächst mal dürfte sich innerhalb dewiki keine Einbindung durch andere, noch aktive Benutzer finden lassen. Was nicht ausschließt, dass es global irgendwo angefasst würde oder keine triviale auffindbare Zeichenkette verwendet wäre.
• Begonnen werden sollte mit infinit gesperrten und verstorbenen (haben die nicht auch infinit?) Benutzern. Langjährig (5, 10 Jahre) inaktive könnten nach ersten Erfahrungen folgen.
• Skripte aus der Zeit um 2010 sind heutzutage wegen zahlreicher Anpassungen an moderne Browsertechnologie und Konfliktvermeidung im globalen Namensraum der JS-Variablen nicht mehr lauffähig. Sie ziehen bei der mittlerweile möglichen globalen Protokollierung von Skriptfehlern (welche die Anwender selbst nicht mitbekommen, weil diese nur auf der Konsole und bei der WMF vermerkt werden) Wartungs- und Pflegebedarf nach sich.
• CSS würde ich außen vor lassen, bis sich ein ernstzunehmendes Problem einstellt (globale Info der WMF, dass dieser und jene Selektor nicht mehr unterstützt würde).

Ich würde allerdings anders vorgehen:

• Überschreiben der Seite mit einer neuesten Version, bestehend nur aus

 window.alert( "Du verwendest das Skript User:" +
               Bot-eingefügt   Account/subpage.js
               + "@dewiki. Dieses bedarf der Pflege." +
               " Bitte melde dich bei ..." );
 // Eingefügt von Administrator ...... 2020-12-01
 // Wenn du dein Skript reaktivieren möchtest, brauchst du bloß ...

• Wenn das irgendwo noch verwendet würde, müsste jemand aufschlagen.
• Wenn keiner mault ist es erstmal egal.
• Wenn ein User wiederaufersteht, hat er die Versionsgeschichte und kann schlicht revertieren.

VG --PerfektesChaos 14:37, 24. Nov. 2020 (CET)

Joa, diese Nachricht wäre dann möglich, wenn das Skript noch irgendwo eingebunden wird, ansonsten sieht es ja niemand. Gruß, -- hgzh 19:47, 6. Dez. 2020 (CET)

Es wird inzwischen interessant, die BNR-Ressourcen von vor 2011 wie skizziert abzudecken.

MediaWiki-Entwickler gehen inzwischen dazu über, bei nachhaltig ungepflegtem JS wie diesem aus der Zeit vor 2011 global in allen Wikis die Ressourcen zwangsweise umzuschreiben. Irgendwie peinlich, dass dieses Wiki das nicht selbst auf die Kette bekommt.

Die Abschaffung der den globalen Namensraum verseuchenden Konfigurationsvariablen von vor 2011 steht offenbar unmittelbar bevor; nach zehn Jahren Migrationsperiode.

VG --PerfektesChaos 17:25, 13. Feb. 2021 (CET)

Ich habe jetzt mal einen Rutsch eindeutiger Fälle von unfreiwillig Gesperrten und Verstorbenen per Löschung bereinigt. Für alle weiteren müsste man nochmal überlegen – ein Hinweis wie oben würde ja bei jedem Laden der Seite erscheinen, da sehe ich schon Fackeln und Mistgabeln auf mich gerichtet. -- hgzh 19:29, 13. Feb. 2021 (CET)

In diesem Fall stelle ich mich mit breiter Brust vor dich.

Eine Löschung ist ein heftigerer Eingriff, weil Wiederauferstandene ihn nicht beseitigen können.

Eine Seite nur mit Klartext-Kommentar und Bedienungsanleitung ist das mildere Mittel, erklärt nochmal was los ist, kann vom Account unbürokratisch revertiert und durch die VG gebraust werden, und wenn wer zurückkommt dann mag man auch auf FZW oder TWS sich erklären lassen was los ist.

Ich bin grad hundemüde, aber zu morgen kann ich dir ersatzweise zum window.alert() eine narrensichere console-nicht-console-warning-nicht-warning-dann-log aufschreiben, die für den Fall eines von weißdergeierwoher aufgerufenen Skriptes immerhin einen Hinweis in der Konsole hinterlässt. Die kein Normalbenutzer zur Kenntnis nimmt, aber wenn es kein alert() sein soll bliebe nur diese ulkige mw.notification, mit der ich aber auch noch nie gearbeitet habe und die ich morgen nachmittag erstmal auf BETA ausprobieren müsste.

Würde heißen: Dauerhafter Konsoleneintrag und 5 Sekunden Einblendung, falls es noch Anwender geben sollte.

VG --PerfektesChaos 20:11, 13. Feb. 2021 (CET)

Irgendetwas nicht so aufdringliches wäre mir schon lieber. Ich lasse gerade die Query mit aktuellem Stand durchlaufen und rasiere dann nochmal die eindeutigen Fälle runter, anschließend könnte man dann die Seiten der freiwillig Gesperrten entsprechend mit einem Hinweis ausstatten. Ich denke auch über eine Wartungskategorie für solche Seiten nach, etwa Kategorie:Benutzer:Skriptseite deaktiviert, zum Ausklammern bereits besuchter Seiten bei späteren Iterationen.

Nb: funktionieren eigentlich solche Weiterleitungen skriptseitig? -- hgzh 11:09, 16. Feb. 2021 (CET)

• Schon wieder einer; die machen jetzt Ernst.
• Kategorisierung funktioniert; guté Idee.
• Diese Wikitext-Weiterleitungen wären gaga, das muss was mit mw.loader.load() sein (sie tauchen allerdings als verlinkte Seiten auf).
• Bin am Wochenende durch zwei frische dicke Hunde auf meiner ToDo-Liste und in meinen geistig wachen Stunden gestört worden. Es werden jeden Tag mehr neue Initiativen gestartet als ich Rückstände abarbeiten kann. Inzwischen nachgeforscht:

//////////////////////////////////////////////////////
// Dieses Skript wurde wegen Überalterung deaktiviert.
// Eingefügt von Administrator ...... 2021-03-18
// Wenn du dein Skript reaktivieren möchtest, brauchst du bloß ...
//////////////////////////////////////////////////////

( function ( mw ) {
   "use strict";
   var s = "################   Account/subpage.js      ##############";
   s = "Du verwendest das Skript User:"
       + s
       + "@dewiki.\n"
       + " Dieses bedarf der Pflege.\n"
       + " Bitte melde dich bei: w:de:WP:FZW";
   if ( typeof window.console  ===  "object"
        &&     window.console ) {
      if ( typeof window.console.warn  ===  "function" ) {
         window.console.warn( s );
      } else if ( typeof window.console.log  ===  "function" ) {
         window.console.log( s );
      }
   }
   if ( typeof mw  ===  "object"
        &&     mw   &&
        typeof mw.notify  ===  "function"  ) {
      mw.notify( s,  { autoHide: false } );
   }
}( window.mediaWiki ) );

// [[Kategorie:Benutzer:Ressourcenseite deaktiviert]]

VG --PerfektesChaos 15:23, 17. Feb. 2021 (CET)

Danke, ich werde das die Tage testen und dann mal beginnen. Das s kommt mir doppelt genutzt vor? Übrigens zum Thema ein kürzlicher Blogpost: Sailing Steady - How you can help keep Wikimedia sites Error-free, unter anderem mit der Empfehlung: User scripts should expire after a certain period and when users retire and no longer maintain them. If a user script hasn’t been edited in over 5 years for example, a bot should blank the page. Gruß, hgzh 11:33, 17. Mär. 2021 (CET)

Die erste Zuweisung var s = "Account/subpage.js"; ist die einzig variable Stelle im ansonsten konstanten Text einer Serie und ist dafür gedacht, das vielleicht irgendwie halbautomatisch ausfüllen zu können.

• Die zweite Zuweisung s = "Du verwendest das Skript User:" + s + "@dewiki.\n" bettet die erste, variable Zuweisung in einen konstanten Rumpf ein. Der wird dann relativ narrensicher kommuniziert.

Die Verlinkung ist irgendwie putt. Da sind gemäß englischer Typografie hair space um den en-dash gelegt. Das heißt, wenn es denn ein en-dash wäre, ist aber ASCII U+002D.

• Der Interwiki-Link löst aber gemäß Standard-Algorithmus hair space wie alle anderen Leerzeichen in _ auf.
• Die Seite ist aber nur mit zwei U+200A erreichbar.
  • wmfblog:2021/03/08/sailing-steady - how-you-can-help-keep-wikimedia-sites-error-free/ – Interwiki mit hair space geht nicht.
  • https://diff.wikimedia.org/2021/03/08/sailing-steady - how-you-can-help-keep-wikimedia-sites-error-free/ – der gleiche Pfad als URL.
• Die dümmlichste Idee, die mir in den letzten Wochen unterkam, war die Benennung eines Blogs als „Diff“.

Die zitierte Empfehlung ist nur halbgar.

• Es gibt relativ schlichte Skripte, die funktionieren auch noch nach zehn und fünfzehn Jahren ohne Maintainer.
• Kritisch war die Wende im globalen Namensraum um 2010, und die Einführung des mw-Objekts. Was älter ist, braucht Anpassung zur Migration der wikibits-Ära 2004–2010.
• Je komplexer, je mehr Screengrabbing, desto wahrscheinlicher wird Wartungs- und Anpassungsbedarf.
• a bot should blank the page – auf blank the page läuft das da oben hinaus, nur luxuriöser.
• Ist aber sowieso nur als private Einzelmeinung zu werten.
• Die Bug-Auswertungsmöglichkeiten muss ich mir mal genauer anschauen.
• Als allgemeine Empfehlungen alles ganz okay, aber Anweisungen zum Eingriff in den BNR sind ein anderes Kaliber.

VG --PerfektesChaos 21:16, 17. Mär. 2021 (CET)

Bzgl. s hast du Recht, da hab ich schief geguckt. Den Link muss ich mir morgen nochmal ausgeschlafen anschauen. Gruß, -- hgzh 21:23, 17. Mär. 2021 (CET)

Ich bin gegen die Löschung von js/css-Seiten freiwillig gesperrter Benutzer. Eine Sperrung hindert ja nicht daran, sich einzuloggen! Im Zweifel den Benutzer vorher auf seiner Disk ansprechen und hinreichend Zeit zur Reaktion geben. 84.137.67.241 22:15, 18. Mär. 2021 (CET)

Die Seiten sollen auch nicht gelöscht, sondern überschrieben werden, sodass sie sich bei Bedarf leicht zurücksetzen lassen. hgzh 12:58, 19. Mär. 2021 (CET)

Menütext übersetzen

Hallo, ich wurde von WP:FZW hier her geschickt. Ich habe oben ein Menü (aus Wikipedia:Helferlein/Toolserver-Integration), dessen Einträge beim mouseover Englisch sind. Kann man die übersetzen? Das müßte ein (Oberflächen-)Admin machen (Screenshot hier).--Ceweran (Diskussion) 01:30, 9. Jan. 2021 (CET)

Wir können hier nichts tun, denn der Code des Gadgets liegt auf meta:MediaWiki:Gadget-MoreMenu.js – dort sind Lokalisierungen vorhanden, aber anscheinend werden sie nicht wirksam. Autor des Skripts ist meta:User:MusikAnimal. Gruß, -- hgzh 14:21, 9. Jan. 2021 (CET)

+1

Nach kursorischer Durchsicht wäre für diese Tooltips wohl jeweils ein weiteres Textfragment erforderlich, das durch Anhängen von -desc an den sichtbaren Linktext gebildet wird, und das weitere Hinweise spezifizieren mag.

Wäre eine Idee für den Gadget-Maintainer, in allen oder nicht-englischen Versionen den Tooltip noch sicherer zu defaulten als mit den bisherigen Mitteln vorgesehen; also Tooltip identisch Linktext wenn nichts genaueres weiß man nicht.

Im Übrigen könntest du den Gadget-Maintainer darauf hinweisen, dass es Sprachvarianten in gleicher Schrift mit geringer Abweichung gibt (bei uns de-at und de-ch, dazu de-formal, bei ihm vielleicht en-ca en-us en-gb en-uk en-au und ansonsten neben nl- auch pt-br). Falls Bindestrich enthalten und keine exakte Spezifikation (gäbe auch Varianten in anderen Schriften), dann Basis-Sprachcode verwenden.

VG --PerfektesChaos 14:45, 9. Jan. 2021 (CET)

Ich habe den User meta:User:MusikAnimal angeschrieben und arbeite an der Übersetzung. Für ein paar Begriffe suche ich noch auf toolforge nach dem richtigen Kontext, aber ich orientiere mich an bestehenden Übersetzungen. Ist also in Arbeit und hier erl. --Ceweran (Diskussion) 21:32, 18. Jan. 2021 (CET)

Update: Ich habe diese und andere Bausteine übersetzt und der User MusicAnimal hat sie eingefügt. Schaut bitte mal, ob das so weit passt. Vielen Dank.--Ceweran (Diskussion) 20:10, 26. Jan. 2021 (CET)

float-right/float-left

Auf Geräten mit geringer Bildschirmbreite führt die aktuelle Definition der float-Klassen zu unschönen Ergebnissen. Insb. float-right führt in einer Vielzahl von Fällen zu Bildern die über den linken Rand hinausschauen (in diese Richtung kann man bekanntlich nicht einmal scrollen). Man sieht dies bspw. im Artikel Erster Weltkrieg oder Benton Street Bridge. Beheben lässt sich dies durch jeweils Einfügen von max-width: 100%; also Änderung des entsprechenden Teils von Mediawiki:Common.css zu

.float-left {
	clear: left;
	float: left;
	margin: 1em 1em 1em 0;
	max-width: 100%;
}
[…]
.float-right {
	clear: right;
	float: right;
	margin: 1em 0 1em 1em;
	max-width: 100%;
}

Ich habe dies in meine persönliche common.css aufgenommen und konnte noch keine negativen Auswirkungen entdecken. Liebe Grüße, KPFC 💬 23:10, 18. Jan. 2021 (CET)

Mag sein, mag nicht sein.

Die Auswirkungen können jedoch komplex sein und sind nicht trivial zu überblicken.

Intensive Recherchen bei MW und in anderen Wikis (en) sind zunächst erforderlich, um dies weiter zu analysieren. Es stellt sich auch die Frage, ob das Gesamtverhalten nicht einer Serie von Browserversionen oder einer einzelnen Engine zuzuordnen ist und nach einem Bugfix wieder verschwände.

Mir war bislang noch niemals ein Nachteil aufgefallen, und auch nicht in dem angeführten Beispiel.

Eine längere Beobachtungszeit durch individuelle Erprobung´ist zunächst erforderlich. Ich habe das in mein CSS aufgenommen und werde einige Wochen darauf achten; insbesondere auf vorstellbare Kollateralschäden. Mobilgeräte sind besonders zu untersuchen. Bislang hatte noch nie jemand von einem derartigen Problem berichtet.

Benton Street Bridge ist auch einfach schlecht gemacht. Die starren Doppelbilder sind ungeschickt, es ist keine Mindestbreite der verbleibenden Textspalte programmiert worden, und in #Baustellen­schweißungen und Betonierung sowie #Bürgersteig usw. sind zwei Einzelbilder starr nebeneinander layoutet worden. Intelligentes Design sähe anders aus; die Doppelbilder würden sich in zwei Bilder übereinander auflösen, sofern die Bildschirmbreite dies erfordert. Dafür ist allerdings teilweise zu wenig Text für zu viel Bild vorhanden. Nebenbei, warum eigentlich fest vorgegebene Auflösungen? Wir verwenden in der Regel raum- und ressourcensparende Miniaturbilder.

„führt in einer Vielzahl von Fällen zu Bildern die über den linken Rand hinausschauen“ – das weist eher auf ein anderes Problem hin, das nicht per CSS zu lösen ist: Autoren haben aus Jahrzehnten Desktop-Gewohnheit in Hunderttausenden von Artikeln überbreite und starre Datentabellen verbrochen, bzw. Layout-Tabellen für breite Bildschirme fest vorgegeben. Das lässt sich mit einer CSS-Deklaration auch nicht geradebiegen.

Danke für die Anregung jedenfalls.

VG --PerfektesChaos 01:02, 20. Jan. 2021 (CET)

In den angegebenen Beispielen sieht man es nicht mehr, weil ich die Vorlage geändert habe.

Vielleicht ist es bei erneuter Betrachtung doch leichter es in den konkreten Fällen zu beheben statt die common.css zu ändern, template-styles bieten da jetzt ja echte Möglichkeiten. Ich hatte auch in Erinnerung, dass starr eingebundene Bilder wie [[File:test.png|1000px|rechts]] zum gleichen Problem führen, aber das ist offensichtlich nicht mehr der Fall. Liebe Grüße, KPFC 💬 02:13, 20. Jan. 2021 (CET)

Statt der starren Doppelbilder in statischer Anordnung und fester Abmessungen und mit rücksichtsloser Zerquetschung der verbleibenden Textspalte wäre es in Benton Street Bridge die simple Lösung, Galerien zu zwei Bildern unterhalb des Textabsatzes anzuordnen. Die haben von Hause aus Miniaturbilder in Größe der aktuellen Benutzereinstellung, und wenn die Bildschirmbreite nicht ausreicht, dann werden sie untereinander angeordnet.

Gegen schlechtes Papier-Design mit dem Weltbild „Ich habe einen Desktop und ein breites Browserfenster und wer das nicht hat soll meinen Artikel dann halt nicht lesen“ hilft auch keine CSS-Frickelei. Das ist schon mit schmaler gezogenem Browserfenster (wie oft bei mir) katastrophal, dazu braucht das Smartphone nicht für erfunden werden.

VG --PerfektesChaos 16:11, 20. Jan. 2021 (CET)

Grundsätzlich: Ich habe in der Vergangenheit auch schon diverse Infoboxen dahingehend überarbeitet (mit max-width:100%), das Problem ist sicher nicht so selten (speziell sichtbar bei richtig schmalen Bildschirmen, die möglicherweise bald wieder mehr in Mode kommen). Die vorgeschlagene zentrale Lösung muss ich mir aber noch in Ruhe anschauen. Gruß–XanonymusX (Diskussion) 16:15, 20. Jan. 2021 (CET)

nowiki in Benutzerskripte wegen <source>

In Kategorie:Wikipedia:Seite mit Syntaxhervorhebungsfehlern schlagen .js-Seiten auf, die vermutlich veraltetes <source> enthalten.

• Diese müssten jeweils ergänzt werden um:
  • Nach einem ggf. einleitenden Kommentarblock Zeile mit:
    // <nowiki>
  • Als letzte Zeile anfügen:
    // </nowiki>
  • Oder ggf. enger um die fragliche Stelle herum.
• Kommentare in Skripte einzufügen zählt nicht zu den funktionalen Veränderungen.

Besten Dank im Voraus --PerfektesChaos 17:54, 7. Apr. 2021 (CEST)

Stammt wohl aus einer Zeit, als Skriptseiten noch kein automatisches Syntaxhighlight hatten. insource:/\<source/ für weitere Kandidaten, wird bei Langeweile stückweise weggeputzt. -- hgzh 19:12, 7. Apr. 2021 (CEST)

Ach du Schreck. Das muss ja schon ein Jahrzehnt her sein.

• Natürlich können auch solche Kommentarzeilen ohne Beeinträchtigung der Funktionalität aus Skriptseiten eliminiert werden.
• Der Hack funktioniert schon seit Ewigkeiten nicht mehr, ist auch nicht mehr erforderlich, und löst im besten Fall die Wartungskat aus.

Das Umschließen des wirksamen Programmcodes mit // <nowiki> kann aber auch nicht schaden.

• Der JS-Code wird ja zusätzlich als Wikitext geparsed.
• Weil da öfters mal Kategorien, Vorlagensyntax usw. zum Einfügen in Quelltext drinstehen, löst das „Links auf diese Seite“ und wirre Kategorisierungen aus.
• Ich ahne schon, dass wir eines Tages dann auch noch Linter-Fehler für sowas am Hals haben werden.

VG --PerfektesChaos 17:36, 8. Apr. 2021 (CEST)

Explizite Vordergrundfarbe für .zebra

Wie hier diskutiert, sind Tabellen mit der Klasse zebra für zeilenweise wechselnde Hintergrundfarbe im Darkmode der App (zumindest iOS) unlesbar. Daher sollte eine explizite Schriftfarbe (z.B. color: white) angegeben werden, die die Heuristik dann invertieren kann.

Alternativ könnte .zebra auch ganz gelöscht werden, da solche Formatierungen ohnehin nicht in die Hände von Artikelautoren gehören. — Christoph Päper 23:16, 8. Jul. 2021 (CEST)

TL;DR: Der Vorschlag ist abzulehnen.

Die Hinterlegung erfolgt unter Beibehaltung der schwarzen Schriftfarbe typischerweise mit sehr hellem grau, blassgelb, hellblau usw.

Eine Umsetzung des Vorschlags würde unsere Artikel für alle unlesbar machen, die nicht einen invertierenden Nachtmodus verwenden: sehr hellem grau, blassgelb, hellblau usw.

Momentan verwenden 16.758 Artikel diese Darstellung.

• Sie wurde vor über zehn Jahren eingeführt.
• Sie ist sehr beliebt, weil damit umfangreiche Datentabellen besser zeilenweise gelesen werden können.
• Die Behauptung, das würde angeblich „nicht in die Hände von Artikelautoren gehören“, ist nicht nachvollziehbar; noch weniger vor dem Hintergrund [sic!] der begehrten Vordergrundfarbe und der daraus für alle anderen resultierenden Konsequenzen.

Allgemein sind Wikiseiten für einen Nachtmodus ungeeignet, wie bereits auf FZW dargestellt.

• Erst recht, wenn ein solch strunzdummer Invertierungsalgorithmus verwendet wird wie offenbar bei iOS-App.
• Ein halbwegs intelligenter Nachtmodus erkennt die Kontraste und würde den Beispielfall dann etwa darstellen in sehr hellem grau, blassgelb, hellblau.
• Allerdings bleiben die meist nicht innerhalb der Grundfarbe, sondern spiegeln auf dem Farbkreis und reduzieren wegen Schlummer auch noch den Blau-Anteil im Spektrum, weshalb aus grün dann rot wird, und rote Zahlen grün usw.
• Im günstigsten Fall ist Österreichs Flagge dann rosa-schwarz-rosa.
• Nachtmodus ist nur dort einsetzbar, wo die Seiten nur schwarz und weiß und vielleicht noch blaue Buttons kennen, und Farben keine bedeutungstragende, sondern lediglich dekorative Funktion hätten.

VG --PerfektesChaos 03:12, 9. Jul. 2021 (CEST)

/*
 * Zebra-Tabellen. Bei Verwendung zusammen mit „rowspan“ richtet sich die Farbe
 * jeder Zelle nach der ersten Zeile, zu der die Zelle gehört.
 */
table.wikitable.zebra > tbody > :nth-child(even):not([class*="hintergrundfarbe"]) {
	background: white;
    color: black; /* diese Zeile soll hinzugefügt werden */
}

Die derzeitige Formatierung der Klasse zebra ist halt sehr naiv und zerbrechlich. Die Zugänglichkeitsempfehlungen waren schon immer, Vorder- und Hintergrundfarben stets gemeinsam festzulegen, damit ausreichender Kontrast sichergestellt ist. Hier wurde das nicht eingehalten und jetzt kracht es.

Ich habe mich gestern vertan, natürlich sollte das color: black heißen.

Ich sehe nicht, wie das zu Problemen mit anderen Hintergrundfarben führen sollte, unabhängig davon, dass die natürlich auch nur zusammen mit einer Schriftfarbe gesetzt werden sollten. — Christoph Päper 21:41, 9. Jul. 2021 (CEST)

PS: Außerdem geht es hier nicht um eine Fehldarstellung in irgendeinem obskuren Browser, sondern in der offiziellen App. 22:01, 9. Jul. 2021 (CEST) (unvollständig signierter Beitrag von Crissov (Diskussion | Beiträge) )

Nur zum letzten Satz: Die offizielle App ist allerdings doch ziemlich „obskur“ und wird so gut wie nicht verwendet, daher werden viele bekannte Fehler nicht behoben, obwohl gerade die offizielle App einfach auf WP-Eigenheiten anzupassen wäre. Beispielsweise werden bestimmte Infoboxen in der App komplett verschluckt, was auch noch nie korrigiert wurde. Ich würde die Apps nach wie vor als ein Experiment betrachten, nicht mehr.–XanonymusX (Diskussion) 18:38, 11. Jul. 2021 (CEST)

Ich finde, man könnte die Vordergrundfarbe in diesem Fall schon per default setzen. So blöd wie die App und ihr Nachtmodus hier ist, sie wird offensichtlich verwendet und eine Anpassung kostet uns nicht wirklich was, hilft aber dem Leser. -- hgzh 15:39, 11. Sep. 2021 (CEST)

Datatable

Gemeldet in Phabricator
Task T287997

Anlässlich phab:T287997: Was machen wir mit den über 2.000 Seiten, die bei uns mw-datatable verwenden? Auch wenn uns niemand gefragt hat, wird offenbar erwartet, dass wir das Problem jetzt selbst lösen. Ich hätte die Funktionalität ganz gerne rasch wieder. Gruß --XanonymusX (Diskussion) 00:30, 15. Aug. 2021 (CEST)

Auf gar keinen Fall werden wir 2000 Artikel anfassen, egal wie.

MW muss die unangekündigte Löschung zurücknehmen, ggf. durch breiten Druck bei der WMF.

Der Bursche ist zurzeit bei einer allgemeinen Aufräumaktion, und wir werden in den kommenden Wochen und Monaten noch viel mehr Spaß mit ihm haben.

• Allein in der laufenden Woche hat er vier Böcke geschossen.
• Er schmeißt einfach alles CSS usw. raus, das er für überflüssig hält Ohne Testen, ohne über die Folgen außerhalb seines geistigen Horizonts nachzudenken, was per definitionem auch nicht möglich ist.
• Erklärtermaßen ist ihm völlig egal, was das für Auswirkungen auf die 1000 Wikis mit ihrem Seitenbestand hätte. Das ist ja dann deren Problem.
• Für ihn ist nur wichtig, nur noch ganz wenig CSS+PHP gemäß seinem Masterplan und seiner Agenda zu haben, und dass er möglichst wenig Arbeit mit seiner Löschaktion hätte.

Grundsätzlich ist es sinnvoll, das historisch immer mehr zusammengestückelte CSS nach zwei Jahrzehnten zu ordnen, zu strukturieren, effizienter an Desktop- oder Mobil-Seiten auszuliefern usw.

• Die Veränderungen müssen aber idealerweise in einer Weise erfolgen, dass die Bestandswikis davon überhaupt nichts merken.
• Wo aus technischen oder organisatorischen Gründen eine langfristige Fortführung nicht mehr sinnvoll ist, etwa weil es nur wenige Verwendungen als Dublette zu einer mittlerweile vorhandenen besseren Lösung gibt, muss das odnungsgemäß migrieren.
• Heißt: Wenn Veränderung, dann breit kommuniziert vorher ankündigen, Gründe und Notwendigkeit erklären, Alternative erklären und Wege aufzeigen, wie Projekte ohne technische Kenntnisse die Problemfälle auffinden können (ggf. Wartungskategorie durch System) und das ggf. massenhaft ändern können, ohne Botbetreiber zu haben.
• Das ist ihm aber alles viel zu anstrengend; er knallt das einfach unangekündigt weg und basta. Es hatte vorher noch nicht einmal eine Task dazu gegeben, es war niemals erörtert worden.

Wir machen hier nix, erhöhen ggf. WMF-weit den Druck zum Rollback, und auf gar keinen Fall bietet jemand auf Phab lokale Behelfslösungen für große kompetente Wikis an, während die kleinen abgehängt werden.

VG --PerfektesChaos 11:10, 15. Aug. 2021 (CEST)

Ich schätze Jons Arbeit ja im Allgemeinen sehr, aber die Änderungen der letzten Tage waren wirklich maximal mies gemanagt (die Alliteration sei mir erlaubt). Und die letzten „Vorschläge“ von Izno halte ich auch für völlig realitätsfern. Da es sich letztlich nur um eine Designfrage handelt, können wir wohl abwarten, bis die das wieder zurückändern; ansonsten bleibt immer noch Common.css. Gruß—XanonymusX (Diskussion) 12:31, 15. Aug. 2021 (CEST)

So, wie weiter? Vonseiten der WMF wird das offensichtlich bewusst ausgesessen, also bleibt uns eigentlich nur der Weg über Common.css, wenn wir die Funktion wiederhaben wollen. --XanonymusX (Diskussion) 17:27, 10. Sep. 2021 (CEST)

Die Resonanz auf die Abschaltung war ja kaum vorhanden, was meiner Meinung nach nicht dafür spricht, dass das wirklich benötigt wird. -- hgzh 15:35, 11. Sep. 2021 (CEST)

Ich brauche sie jedenfalls, aber weiß nicht, wie gewichtig das Argument ist. ;) —XanonymusX (Diskussion) 16:13, 11. Sep. 2021 (CEST)

Helferlein für Abschnittsnummerierung

Mit dem kommenden MediaWiki-Update ist geplant, die bisher optional über die Einstellungen verfügbare Abschnittsnummerierung zu entfernen, vergleiche meta:Tech/News/2021/41 bzw. den entsprechenden Phab-Task phab:T284921. Der Entwickler Krinkle hat stattdessen ein, nein zwei Snippets bereitgestellt, bestehend aus Skript und CSS, über die diese Nummerierung weiterhin möglich ist, allerdings müssen diese als Gadget/Helferlein eingebunden werden, siehe mw:Snippets/Auto-number headings. Ich bitte darum, dieses Helferlein auch in der deutschen Wikipedia zur Verfügung zu stellen. Ping @Aschmidt, Chaddy, Perrak, die sich im Phab-Task geäußert hatten. — Speravir – 01:25, 13. Okt. 2021 (CEST)

+1. Das wäre schön, wenn es bitte jemand übernehmen könnte, das Helferlein zu installieren. Danke vorab! --Viele Grüße, Aschmidt (Diskussion) 07:00, 13. Okt. 2021 (CEST)

 Kontra Ich halte ein derartiges Community-JS-Gadget für absolut überflüssig bis schädlich:

• Eine Bezugnahme auf nummerierte Abschnitte statt auf den eher robusten Text der Überschrift ist kontraproduktiv.
• Die Idee mit dem Nummerieren ist ein Relikt aus der Zeit statischer Papierwerke und mit unseren permanent wandelbaren Seiten nicht vereinbar. Es war in der Säuglingsphase der Wikis mal den gedruckten Büchern nachempfunden worden; nicht voraussehend, dass eine statische Nummerierung mit der sich dynamisch entwickelnden Seitenstruktur kollidieren würde.
• Wer sich auf einen „fünften Abschnitt“ bezieht, macht etwas falsch.

Es besteht kaum Bedarf.

• Es gibt anscheinend ein halbes oder vielleicht auch ganzes Dutzend Benutzer aus der Zeit um 2005, die diese Darstellung unbedingt haben möchten, weil sie ja schon immer da war.
• Zehntausende unserer angemeldeten Benutzies kommen jedoch wunderbar ohne die in Papieren zuweilen sichtbare Zählung in Überschriften aus, ein Millionenpublikum an Leserschaft hatte sie noch nie gesehen und nie vermisst.
• Die Verkomplizierung und nachfolgende Notwendigkeit für Wartung und Pflege, diesen Abschnitt eingeschlossen, steht dazu in keinem Verhältnis.

Es ist nicht damit getan, ein paar Code-Zeilen irgendwo abzuwerfen, sondern neue Community-Gadgets haben auch ordnungsgemäß dokumentiert zu werden; also so wie in Kategorie:Wikipedia:Technik/Skin/Gadgets.

• Es war die Wurschtelei unserer Kindergarten-Zeit, die zu einem Wust nicht mehr pflegefähiger Bastelarbeiten führte.
• Das in Rede stehende Teil wird absehbar nicht langjährig stabil sein, da es sich auf wandelnde Einzelheiten des Seitenaufbaus verlässt, sogenanntes Screengrabbing.
• Wir haben noch einen Schwung ungepflegter mangelhaft dokumentierter kurz vor dem Verrecken stehender „Helferlein“ aus der Ära der Skriptbastelei, für die sich bereits heute keinerlei BOA finden, die sie sanieren würden. Dem noch eine weitere Ruine hinzuzufügen ist kaum zu verantworten.

Es kann jeder in seinem BNR ein entsprechendes Skript usw. anlegen, es ordnungsgemäß dokumentieren, und danach auch offiziell anbieten oder privat weiterreichen.

• Damit verbleibt jedoch die Alleinverantwortung für aktuelle Dokumentation, Wartung und Pflege bei dem Nick, der zwischen Doppelpunkt und erstem Schrägstrich steht, und wird nicht ungefragt in Ewigkeit auf künftige Projektpfleger der Community abgewälzt.
• Es können sogar alle, die es haben möchten, sich jetzt gleich sofort selbst die Krinkle-Ressourcen einbinden; auf jeden Fall als statische Kopie oder sonst auch dynamisch gepflegt. Allerdings fehlt dem Dings offenbar eine Doku, die erklärt wie das ginge.

VG --PerfektesChaos 08:29, 13. Okt. 2021 (CEST)

+1 @PerfektesChaos. Bitte nicht absehbare Altlasten aktiv projektweit neu einführen. Manche Dinge ändern sich, und das hier nicht ist sicher nichts, wodurch jemand nicht mehr arbeiten könnte. --Krd 09:46, 13. Okt. 2021 (CEST)

Es wäre ein Service für die Leser gewesen, der enorm hilfreich war, um sich in länglichen Artikeln zurechtzufinden, die man liest. :( --Viele Grüße, Aschmidt (Diskussion) 19:23, 13. Okt. 2021 (CEST)

Mir geht es wie Aschmidt, dass mir die Nummerierung enorm hilft, mich bei längeren Seiten deutlich besser zurechtzufinden, was ich immer dann merke, wenn ich auf einem Wiki ohne solche unterwegs bin, aber natürlich geht es irgendwie auch ohne. Zu einigen Punkten von oben:

• Dokumentierung: Ja, davon kann es eigentlich nie zu viel geben (je länger, desto wichtiger ist die Strukturierung, wo mir wieder eine Nummeriereung helfen würde), wobei mir hier nicht ganz klar wäre, was man da groß dokumentieren soll außer dass den Abschnitten eine Nummer vorangestellt wird. Oder ist damit auch so etwas wie die Herkunft gemeint, was sicher sinnvoll wäre, oder eben die Warnung, dass die Nummerierung nie angegeben oder gar mitkopiert werden darf, weil sie sich ändern kann und für die Verlinkung unerheblich ist? Da die Doku nicht im MediaWiki-Namensraum sein soll, könnte diese sogar nicht allein von BOAs angelegt und bearbeitet werden.
• Bezugnahme auf nummerierte Abschnitte: Hab ich noch nie gemacht und habe ich bewusst auch noch nie gesehen, aber die Gefahr besteht tatsächlich – besteht sie aber schon, seit es die Einstellung gibt, die nun entfernt werden soll. Andererseits: Es gibt seit kurzem die Zeilennummerierung, und die kann man sogar verlinken, obwohl sie sich ebenso verändern kann. Da gibt es dann Wortkreationen wie „Stand heute“.
• Bedarf: Laut Phab-Task nutzten in der einzig untersuchten englischen Wikipedia 0,4 % der aktiven Autoren die Möglichkeit. Im Dewiki wären das um die 70 Nutzer (laut Spezial:Statistik waren es zuletzt rund 17.800 aktive Nutzer), aber ob die Quote stimmt, kann ich nicht überprüfen. Gibt es Statistiken über die Aktivierung von Helferlein?
• Langjährig nicht stabil/Screengrabbing: Verstehe ich nicht. Geht es dir, PC, um die Klassenselektoren, die im Zweifel tatsächlich anzupassen wären?
• „Es kann jeder in seinem BNR ein entsprechendes Skript usw. anlegen“. Jein, kann eben nicht jeder so leicht, vor allem, wenn es dann um mehr als nur eine einfache Kopie geht, im konkreten Fall müsste man sogar Javascript und CSS kombinieren. Statt einer Kopie wäre es auch deutlich besser, das Original einzubinden. Die sehr gute Doku in der deutschen Wikipedia kann dabei allerdings sehr gut behilflich sein.
• Krinkle-Ressourcen einbinden: Mir war zunächst nicht klar, was Du damit meinst, und bin mir dessen immer noch unsicher, habe aber daraufhin im Mediawiki unter den Gadgets nachgesehen und, siehe da: mw:MediaWiki:Gadget-autonum (wohl ein Beispiel, wie man es nicht machen sollte, eben weil dort ein Link zu einer Doku fehlt), mw:MediaWiki:Gadget-autonum.js und mw:MediaWiki:Gadget-autonum.css. Was für mich selbst bedeutet, dass ich genau dieses Skript und dieses Stylesheet bei mir einbinden werde. Aber um mich selbst ging es mir hier gar nicht (ich hatte Skript und Stil bereits zuvor lokal getestet, hätte also für mich selbst auf jeden Fall eine Möglichkeit gefunden).

— Speravir – 01:27, 14. Okt. 2021 (CEST)

In vollem Umfang +1 zu @Speravir. Die Nummerierung der Abschnittsüberschriften ist für mich ein Standardfeature für engagierte Autoren, die Wikipedia intensiv nutzen. --Viele Grüße, Aschmidt (Diskussion) 07:08, 14. Okt. 2021 (CEST)

@Seiten-Navigation: Also, ich springe mit einem Klick zum Seitenanfang, finde nach einem sehr kurzen Einleitungsabschnitt das Inhaltsverzeichnis und springe mit einem Klick zum genau richtigen Abschnitt. Mit der Frage nach einer Nummer habe ich mich noch niemals beschäftigt oder gar belastet.

@Bedarfsgruppe:

• Wir haben die Möglichkeit, per Anfrage eine statistische Analyse aufgeschlüsselt nach Gadget/Preference zu erhalten, passiert auch alle Jubeljahre, und die 0,4 % der enWP sind da sehr realistisch.
• Nicht jeder, der irgendwo ein Häkchen hingemacht hat, braucht das auch. Viele hatten auch einfach nur so mal dies und das angekreuzelt; wir erleben auch sehr regelmäßig, dass Aktive in ihrem JavaScript noch massenhaft Schnipsel herumzuliegen haben, die schon seit einem Dutzend Jahre dysfunktional sind, und wo sich die Verantwortlichen nicht erinnern können wozu sie sich das mal kopiert hatten und es nie gebraucht und nie vermisst haben. Es gibt auch etliche Benutzerseiten von Aktiven mit Verlinkungen im 2014 abgeschalteten Toolserver. Die Anzahl gemachter Häkchen ist also nicht notwendigerweise auch die Anzahl derjenigen Aktiver, die auf das Feature Wert legen.
• Trotz breiter Werbekampagne an mehreren Stellen sind die Protestierer an einer einzigen Hand abzuzählen. Insofern halte ich meine oben getroffene Abschätzung „halbes oder vielleicht auch ganzes Dutzend Benutzer aus der Zeit um 2005, die diese Darstellung unbedingt haben möchten“ für großzügig nach oben abgeschätzt. Das sind <0,1 % der Aktiven; >99,9 % Angemeldete vermissen nichts, und 100 % IP.

@Doku:

• Sie hat für laienhafte Anwender verständlich zu erklären, was die Funktion ist und wozu man das benötigen würde und was dann passiert und wie es zu bewerkstelligen wäre.
• Sie hat für pflegende Programmierer, die von der Angelegenheit noch niemals etwas gehört haben, alle erforderlichen Informationen bereitzustellen, insbesondere Methodik und wirksame Komponenten, damit bei allfälliger Veränderung irgendwelcher Rahmenbedingungen die Programmierungen verändert werden können und die beabsichtigte Wirkung wiederhergestellt werden kann.
• Beispiele sind in der Kat nachlesbar, etwa WP:HW/dewiki-logo; alle Dingse die in der Kat nicht unterlegt wurden sind dem Untergang geweiht.

@Screengrabbing: Alles, was sich auf den Aufbau des HTML-Dokuments verlässt und dessen momentane Struktur zur Informationsgewinnung auswertet, läuft immer Gefahr, bei einer jederzeit möglichen Veränderung der Serverprogrammierung, die davon nichts wissen kann und unangekündigt zu geschehen pflegt, vor die Wand zu fahren.

@Neue Gadgets: Von jedem Community-Gadget, das hier einmal eingerichtet wurde, wird verlangt, dass unsere Softwarebetreuer es auf Gedeih und Verderb in alle Ewigkeit bereitstellen müssen, auch wenn das kaum noch möglich ist. Einen müden Abglanz dieser Forderung, jedes Feature der letzten zwei Jahrzehnte müsse auf immer und ewig beibehalten werden, erleben wir gerade. Bloß wird Software irgendwann durch Anwender unbedienbar und für Programmierer nicht mehr robust funktionierend zu halten und nicht mehr effizient ausführbar, wenn man über Jahrzehnte alles kumuliert, obwohl es mit sich ändernden Rahmenbedingungen kollidiert. Und das Personal zur Wartung unseres Bestandes und zur Modernisierung hoffnungslos veralteter Überreste der Schnullerjahre ist bereits zu 500 % überlastet.

@Und nochmal: Jeder, der diese Dekoration unbedingt haben möchte, kann sie für sich selbst jetzt gleich und sofort einrichten, und konnte das schon vor Tagen.

VG --PerfektesChaos 18:04, 14. Okt. 2021 (CEST)

Du arbeitest auf eine Weise, andere auf eine andere. Du klingst gerade so, als ob sich alle nach dir zu richten haben (wobei ich glaube, dass Du es so nicht meinst). Und dass eben nicht jeder sich so etwas von allein einrichten kann, scheinst Du nicht verstehen zu wollen. — Speravir – 01:39, 15. Okt. 2021 (CEST)

Fürs Archiv, falls mal jemand danach sucht (ich will das aber auch noch in meinem Benutzerraum aufführen), einzufügen in die eigene common.js, wenn die Funktion nur in der deutschen Wikipedia genutzt werden soll, oder die global.js, wenn man sie für alle Wikimedia-Projekte nutzen will:

/* Nummerierung von Abschnitten, Import von Mediawiki-Gadget "Auto-number headings",
 * siehe auch https://www.mediawiki.org/wiki/Snippets/Auto-number_headings
 */
// https://www.mediawiki.org/wiki/MediaWiki:Gadget-autonum.js
mw.loader.load("https://www.mediawiki.org/w/index.php?title=MediaWiki:Gadget-autonum.js&action=raw&ctype=text/javascript");
// https://www.mediawiki.org/wiki/MediaWiki:Gadget-autonum.css
mw.loader.load("https://www.mediawiki.org/w/index.php?title=MediaWiki:Gadget-autonum.css&action=raw&ctype=text/css", "text/css");

— Speravir – 01:39, 15. Okt. 2021 (CEST)

„Du klingst gerade so, als ob sich alle nach dir zu richten haben“

• Hier haben vier oder fünf namentlich bekannte Benutzer einen individuellen Dekorationswunsch.
• Zigtausende registrierter und Millionen nicht angemeldeter Benutzer haben diese sehr ausgefallene Vorliebe nicht; sie war bisher auch nie irgendwo als besonders empfehlenswert thematisiert worden. Wie gezeigt, ist sie auch nicht erforderlich.
• Abschnittseröffnend wird nun gefordert, dieses sehr randständige und hinsichtlich Zitation problematische, vor Jahrzehnten unter anderen Rahmenbedingungen von einem Programmierer mal gebaute Feature solle jetzt von dieser Community zum auf ewig bereitzustellenden Angebot in der übersichtlichen Liste unserer Hilfsmittel gemacht werden.
• Es ist also eher die Handvoll, die den Zigtausenden vorgibt, wie sie sich Seitendarstellungen gestalten sollten, weil das angeblich eine wichtige und unverzichtbare Präsentation wäre, und man möge sich nach diesen vieren richten.
• Die zitierte Unterstellung ist somit eine groteske Verdrehung der Realität.

VG --PerfektesChaos 09:28, 15. Okt. 2021 (CEST)

Lieber @PerfektesChaos, das alles mag ja deine Meinung sein, ich glaube aber, @Speravir wollte dir sagen, dass du bisher in der Diskussion wenig empathisch reagiert hattest, und ich glaube auch, dass er damit Recht hat. Vielleicht könntest du an der Stelle noch etwas an dir arbeiten. Aber das ist nur ein Hinweis am Ende einer langen Woche. Ich wünsche euch allen schon einmal ein schönes Wochenende! --Viele Grüße, Aschmidt (Diskussion) 17:19, 15. Okt. 2021 (CEST)

Exakt, Aschmidt. PC, wenn ich dir meinen Eindruck schildere, dann ist das keine Unterstellung, in Klammern habe ich doch extra noch geschrieben, dass ich selbst glaube, Du meinst es anders. Zur „Handvoll, die den Zigtausenden vorgibt, wie …“: Ein standardmäßig deaktiviertes Helferlein kann doch niemandem etwas vorschreiben!? Keine Angst, ich habe den Rest auch gelesen und glaube, ihn verstanden zu haben. — Speravir – 01:23, 16. Okt. 2021 (CEST)

Jetzt, wo es die Nummerierung nicht mehr gibt, sieht man ja auch, wohin das führt: Die Unterschiede beim Schriftgrad der Überschriften ist so gering, dass man nicht mehr auf den ersten Blick sehen kann, auf welcher Gliederungsebene man sich in einem Artikel befindet. Das ist doch einfach nur Mist für engagierte Autoren. Es kommt nicht darauf an, wieviele das Feature einst aktiviert hatten, sondern wer das war. Ich brauche das für meine Arbeit, und ich gehe davon aus, dass die meisten, die es angeht, gar nicht wissen, wie man das wiedererhalten könnte. Und diejenigen von uns – @PerfektesChaos, @Krd –, die es zumindest wieder lokal für alle bereitstellen könnten, weigern sich mit wirklich abwegigen Argumenten, die in keiner Weise stichhaltig sind. Sehr, sehr traurig. Könntet ihr bitte noch einmal in euch gehen? – Ping zur Info an @Speravir. --Viele Grüße, Aschmidt (Diskussion) 12:37, 16. Okt. 2021 (CEST)

Ich fand die Nummerierung auch übersichtlicher, wie bei längeren Artikeln und speziell bei Diskussionsseiten etc. Mal sehen, wann die ersten Stimmen laut werden, die diese Änderung ändern wollen und wann das erste Meinungsbild dazu formuliert wird. Dort würde ich für die Nummerierung votieren. Die Skripte werde ich mir anschauen und ggf. einrichten. --Elrond (Diskussion) 14:54, 17. Okt. 2021 (CEST)

Ich verstehe nicht so recht, wieso hier auf einem Gadget bestanden wird. Weiter oben sind die zwei Zeilen, die in die entsprechenden Seiten einzufügen wären, bereits aufgeführt (und im Gegensatz zum Gadget funktioniert das per global.css sogar auf einen Schlag in allen Projekten). Dass Skripte auf diese Weise eingebunden werden, ist ja nun kein völlig neues Verfahren und wird bei einer Vielzahl weit häufiger genutzter Arbeitshilfen ebenso gehandhabt und auch auf entsprechenden Hilfeseiten erklärt. -- hgzh 15:30, 17. Okt. 2021 (CEST)

Für einen Nerd mag so was eine völlig simple Selbstverständlichkeit sein, aber 99+ % aller Wikipediabenutzer wissen entweder nichts von diesem Script oder wissen nicht, wie man es anwendet. Dein Einwand erinnert mich ein wenig an die Szene in 'Per Anhalter durch die Galaxis' als die Vogonen einen Einspruch von Erdlingen gegen die Sprengung der Erde mit dem Hinweis abschmettern, dass auf Alpha Centauri die Pläne drei Monate auslagen und kein Erdling Einspruch erhoben habe. --Elrond (Diskussion) 18:51, 17. Okt. 2021 (CEST)

Nebenbei, ich gehöre zu diesen 99+ %, weil ich zwar jetzt um die Existenz dieser Zeilen weiß, mir aber nicht zutraue, die ohne etwas zu zerdeppern in die oben genannte Seite einzufügen. Ich habe keinerlei Kenntnisse in HTML oder anderen Auszeichnungssprachen - und wenn jetzt jemand kommt uns schreibt Das ist kein HTML sondern... dann mag es zum Beweis genügen, wie gering meine Kenntnisse sind. --Elrond (Diskussion) 18:59, 17. Okt. 2021 (CEST)

Eine Bekannte wollte mal so ein JavaScript bei ihrem Account einbinden. Ich habe ihr am Telefon erklärt, wie man das macht. Ich habe ihr gezeigt, wie das bei meinem Account aussieht. Ich habe ihr den Quelltext und den Link per Mail geschickt, wo die richtige Seite für sie wäre, auf der sie den Text einfügen müsste. Am liebsten hätte ich es für sie gemacht, aber die Seiten sind schreibgeschützt, ich hatte keinen Schreibzugriff, deshalb musste sie es selbst machen. Sie hatte es erst im zweiten Anlauf geschafft. Und dann funktionierte das Skript doch nicht so wie bei meinem Account. Wir konnten nicht feststellen, woran es lag und haben es dann auf sich beruhen lassen. Wohlgemerkt: Sie ist Informatikerin. Aber sie fand sich hier in den Wikis (Wikipedia, Meta, Commons..., js, css, global, lokal...) nicht zurecht. – Ich habe den Snippet mittlerweile ausprobiert, er tut, was er soll, aber ich verwende mich ja hier für die Kollegen wie beispielsweise @Elrond – oder meine Bekannte. --Viele Grüße, Aschmidt (Diskussion) 19:43, 17. Okt. 2021 (CEST)

Bei einer ausreichend großen Anwenderbasis sind Gadgets natürlich sinnvoll, deshalb sind beispielsweise HotCat, Rechtschreibprüfung oder die BKL-Markierung völlig zurecht dort aufgeführt. Aber bereits jetzt gibt es dort Einträge, die nur für einen sehr kleinen Kreis, der sich auch nicht mehr vergrößern wird, überhaupt relevant sind (bspw. Typographie-Refresh- und Diff-Farben-Rückgängig oder 2006-Werkzeugleiste-Zurück). Die potenzielle Anwenderschaft der Abschnittsnummerierung ist mE nicht so groß, um einen Eintrag dort zu rechtfertigen. Gleichzeitig sind zahlreiche andere häufig genutzte Skripte schon seit jeher nur per manueller Installation verfügbar, etwa die komplette monobook.js, diverse Autoformatter oder Normdatenhelferlein, alle Schnarkskripte etc., ohne dass ein Bedarf für eine Aktivierung als Gadget gesehen worden wäre.

Im Übrigen sind Nerd und häufig strapazierte Filmzitate keine mir zuträgliche Diskussionsebene, weshalb ich hier nun raus bin. Gruß, -- hgzh 13:31, 18. Okt. 2021 (CEST)

Ich bitte darum, das Gadget zuzulassen. Die Nummerierung war für viele sehr nützlich und es ist eh schon ziemlich bescheiden, dass diese Funktion einfach abgeschafft wurde. Mit einem Gadget könnte sie auf Wunsch sehr einfach weiter genutzt werden. Wer die Funktion für überflüssig hält, muss das Gadget ja nicht nutzen, insofern sehe ich nicht, wieso hier irgendwem irgendwas vorgeschrieben werden solle. Eher wird ja wohl uns vorgeschrieben, dass wir keine Nummerierung verwenden sollten. Ich verstehe nicht, wieso sich hier so vehement gegen ein Gadget gewehrt wird. -- Chaddy · D 21:09, 7. Nov. 2021 (CET)

Die Behauptung „war für viele sehr nützlich“ bedürfte eines Beleges.

• Irgendwie kann ich die an einer Hand abzählen.
• Für solchen Nischenbedarf gibt es schon seit einem Jahrzehnt keinerlei Community-gepflegte Gadgets mehr, sondern ausschließlich Benutzerskripte.
• Ein Community-Gadget muss auf der Hand liegend, offenkundigen, in sich überzeugenden Bedarf für Tausende aktiver und ggf. sogar nicht angemeldeter Benutzer zeigen. Das wird hier aber ganz offensichtlich kilometerweit verfehlt; die Denkweise ist sogar als schädlich weil statisches Papier-Denken weiterführend einzuordnen.
• Es gibt eine Reiehe von Benutzerskripten, etwa den fliegelflagel oder die PDD-Bibliothek, die bald hundertfach häufigere Einbindungszahlen haben als für diese dynamischer Dokumententwicklung widersprechende Abschnittsnummerierung zu erwarten ist.

„aber 99+ % aller Wikipediabenutzer wissen entweder nichts“

• Und >99,9 % aller angemeldeten und 100 % aller IP benötigen keine Abschnittsüberschriftsnummerierung und vermissen auch keine.

Aus WP:CSS lassen sich Hunderttausende und Millionen Privatgeschmack-Dekorationen basteln.

• Das bedeutet aber noch lange nicht, dass die Community-Software-Betreuung dazu verpflichtet wäre, jetzt allen Benutzies jede erdenkliche Privat-Dekoration als separates offizielles Gadget anzubieten.
• Wobei dann gleich die nächsten jammern und wehklagen, es würde viel zu viele Möglichkeiten geben und sie würden sich schon heute nicht durch die ganzen Einstellungen und Extras hindurchfinden, und es wäre viel zu viel Angebot.

Hier will eine Handvoll Angemeldeter eine Privat-Dekoration, für die projektweit kein Interesse besteht, und die obendrein schädliche Nebeneffekte (Weiterleben in der Papierwelt des letzten Jahrhunderts) befördert.

• Wenn diese Handvoll Benutzies das gerne haben will, und nachweislich schon längst weiß wie sie das für sich umsetzen können, dann hätten sie schon längst verständlich im BNR eine Anleitung, Erklärung und Dokumentation schaffen können, und dieses Theater wäre lange erledigt.
• Es gibt nicht für jedes Fitzelchen für jede Handvoll Lautstarker ein individuelles Community-Gadget.
• Diese Community hat keine Kapazitäten mehr zur Software-Pflege.
• Wir hangeln uns am Abgrund vor einem Tsunami ungeklärter Altlasten an einer dünnen Wäscheleine entlang.
• Auf gar keinen Fall werden neue Pflegefälle geschaffen für randständige Privat-Dekorationen.
• Und was für ein fünfaktiges Shakespeare-Drama aufgeführt würde, wenn ein Community-Gadget für ein halbes Dutzend lautstarker Es-muss-alles-immer-so-bleiben-wie-es-immer-schon-war erstellt werden würde, und dann eines Tages nicht mehr funktioniert, das lässt sich an den in diesem Abschnitt bereits sinnlos verpulverten Ressourcen ablesen.

Also erstellt endlich euer elendes BNR-Dings, dokumentiert es verständlich, pflegt es selber, und Ende Banane.

• Oder kopiert euch jetzt gleich sofort die dämlichen zwei Zeilen.
• Wir bieten seit anderthalb Jahrzehnten BNR-Ressourcen an, und Tausende von Benutzies haben es auf die Reihe bekommen, sich gemäß Anleitung in der Wikitext-Dokumentation zumindest die Basis-Einbindung abzukopieren. Und die sind kaum pauschal alle als angebliche „Nerds“ wegzudiskutieren. Die einschlägigen BNR-JS-CSS-Seiten sind voll davon: CSS 6.693 / JS 11.992

VG --PerfektesChaos 10:47, 8. Nov. 2021 (CET)

Die Abschnittsnummerierung war, als sie noch in den Einstellungen verfügbar war, standardmäßig ausgeschaltet. 90 Prozent der Benutzer*innen dürften in ihren persönlichen Einstellungen wohl nichts oder nur das Wichtigste aktiv verändert haben. Insofern ist es nicht verwunderlich, dass die Abschnittsnummerierung selten verwendet wurde. Dieses Argument ist unfair.

Und ansonsten ist das mal wieder ein ganz typischer, hochgradig arroganter Kommentar von dir. Muss das sein? ---- Chaddy · D 19:08, 8. Nov. 2021 (CET)