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

Zur Archivübersicht

Warnbox in Common.css aufnehmen

Bitte die Definition des Standard-MediaWiki-Designs aus phab für Warnmeldungen in die MediaWiki:Common.css aufnehmen:

.mw-message-box-warning,
.warningbox {
	background-color: #fef6e7;
    	border-color: #fc3;

Hintergrund: Es werden hierzuwiki verschiedenste selbstgebastelte Warnboxen für den gleichen Zweck genutzt. Daher möchte ich dieses Standarddesign auch für lokale Systemnachrichten verwenden können. Gruß, --Wnme (Diskussion) 16:34, 21. Feb. 2022 (CET)

Das geht doch schon längst und wird auch so verwendet.

Test

-- hgzh 16:54, 21. Feb. 2022 (CET)

Naja, das ist so eine Sache.

Die Definitionen gibt es zwar, aber sie werden unzuverlässig in den Seiten bereitgestellt, und manche verschwinden auch wieder und manche gibt es nur wenn im statischen HTML-Text=wikitext bereits auftretend, nicht aber wenn erst durch JavaScript nachgeliefert.

CSS/Selektoren unter MediaWiki war mal nur rot und gelb und grün, aber .error gibt es nur wenn statisch im Wikitext und sonst nicht.

VG --PerfektesChaos 17:07, 21. Feb. 2022 (CET)

Stimmt schon, mir ist aber noch kein Fall untergekommen, in der die warningbox in Systemnachrichten nicht funktioniert hat. -- hgzh 18:52, 21. Feb. 2022 (CET)

Mein spezieller Freund ist seit Mitte letzten Jahres beauftragt, hauptamtlich den Dekorationsbereich zu ordnen, zu strukturieren und aufzuräumen.

• Das löst er dadurch, dass serienmäßig CSS-Deklarationen gelöscht oder irgendwohin verbannt werden, damit er es einfacher hat.
• Insbesondere soll es wohl nur noch die drei Farben weiß, schwarz und blau geben, so scheint es.

Anfragen, warum seit Jahrzehnten vorhandene Standardstile nicht mehr verfügbar sind, werden von den Vorgesetzten dahingehend beantwortet, dass den Projekten nur diejenigen Klassen zustehen, die auf offiziellen Seiten der WMF (MW) dokumentiert sind.

• Das wäre dann die Seite mw:Manual:Interface/IDs and classes, während die dort noch verlinkte en:Wikipedia:Catalogue of CSS classes eine irrelevante Privat-Aktion ohne Verbindlichkeit sei.
• Auf der WMF-Seite ist weder das Wort error noch warning auffindbar. Also, letzteres zwar schon, aber nicht in der Spalte mit Namen der Klasssen.
• Bei allem, was nicht offiziell durch MediaWiki dokumentiert sei, behalte man sich vor, es jederzeit ohne vorherige Warnung zu eliminieren.
• Wobei – .error gibt es offiziell seit Frühjahr 2006, weil wenn diese Klasse in " (und nicht in ' oder ohne) eingeschlossen sei, löst sie #iferror: aus, falls in deren Parameter vorkommend.
• Die Deklaration von .error ist etwa Ende letzten Jahres dahingehend verschärft worden, dass sie nur noch innerhalb des Content-Bereichs .mw-body-content wirksam ist. Einfach mal das Wort „Mitmachen“ im Desktop-Portalrahmen in HTML-Bearbeitung mit dieser Klasse über Browser-Werkzeugkasten versehen. Wird nicht rot. Ich füge jetzt mal das Wort „Fehler“ in eine Blanko-Klasse ein: Fehler – über HTML-Manipulation lässt sich hier der Name der Klasse ändern, und im Content ist das (noch) wirksam. Wenn ein Gadget eine Fehlermeldung im Seitenkopf einfügt, ist Essig.

Ich schau mir das schon eine Weile interessiert an und überlege, ob wir ein inhaltsgleiches Paket mit den jahrzehntealten häufig sinnvollen Basis-Klassen bereitstelllen sollten, das wir innerhalb von Seiten per TemplateStyles und für Gadgets und Benutzerskripte per JS-load verfügbar machen, unter den alten Selektoren und im klassischen Design und ohne Mätzchen.

@Wnme: Weil du hier angefragt hast, so gab es ja offenbar eine Situation, in der das CSS nicht definiert war. Um genau welche Umstände handelte es sich denn?

VG --PerfektesChaos 21:43, 21. Feb. 2022 (CET)

@PerfektesChaos: Ich komme mit den Details zur technischen Umsetzung zwar nicht ganz mit. Aber habe es mir noch mal angesehen. Hatte angefangen aufzuräumen, wo mir etwas über den Weg gelaufen ist und die Warnbox eingefügt. Teils wurden verschiedenste selbstgebastelte Designs verwendet. Teils gab es Warnhinweise ohne einen Style. Was ich mir wünschen würde wäre ein Design-Leitfaden, wo drauf verwiesen werden kann. Also z.B. „Kasten warn“ soll für use case x verwendet werden. Eine Struktur und ganzheitliche Lösung würde ich befürworten. Wie auch immer sie am Ende aussehen würde. Habe hier mal versucht den derzeitigen Stand der Einsatzzwecke der Styles zusammen zu fassen. Was mich am meisten beschäftigt sind die Styles für Filter und alles was newbies betrifft (zB. MediaWiki:revreview-editnotice, MediaWiki:Newarticletext-2). Die Überarbeitung der Texte der Filterwarnungen ist noch ein Projekt auf meiner Liste (Die Änderung bei MediaWiki:Abusefilter-!Box von abschreckenden rot auf rot zu grellen grün ist noch immer nicht unbedingt die optimale Lösung). Was das Thema Style howto betrifft können wir ja die Disk. an geeigneter Stelle fortführen. --Wnme (Diskussion) 10:02, 8. Mär. 2022 (CET)

Wird wohl doch nochmal interessant: phab:T300314. Müssen wir schauen, ob sich das durch eine Vorlage lösen lässt oder wir tatsächlich die globale CSS einsauen müssen. -- hgzh 07:56, 2. Mär. 2022 (CET)

Ja, ja, siehe auch Tech News 2022-09:

• Wenn du Vorlagen entwickelst oder Benutzeroberflächenadministrator bist und absichtlich die Standard-CSS-Styles von Boxen zur Rückmeldung an Benutzer (die Klassen successbox, messagebox, errorbox, warningbox) überschreibst oder nutzt, beachte bitte, dass diese Klassen und das zugehörige CSS bald aus dem MediaWiki-Kern entfernt werden. Dies soll Probleme verhindern, falls die gleichen Klassennamen in einem Wiki verwendet werden. Bitte lass es uns wissen, wenn du glaubst, dass du betroffen sein könntest, indem du in phab:T300314 kommentierst.

Global einsauen möchte ich uns auch nicht; allenfalls selektiv.

Dazu muss vorher mal zusammengetragen werden, wer wo was überhaupt benötigt. Es gibt drei Gebiete:

1. Vorlagen; könnten TemplateStyles nutzen.
2. Systemnachrichten; können kein TemplateStyles aber inline-style über eine zentral gepflegte Vorlage einbinden.
3. Gadgets und Skripte bräuchten spezielles: Gadget-dewikiGadgetStyles.css

Vielleicht können wir grundsätzlich andere Lösungen finden.

Die historischen Klassenbezeichner sind damit verbrannt, wenn unser WMF-Löscher sie unter fadenscheiniger Begründung zukünftig nicht mehr global unterstützen will. Schon wegen Kollisionen mit C&P aus anderen Projekten sind solche Trivialnamen damit unbrauchbar.

• Ich denke da an explizit lokale mit Präfix dewiki- und einem System, oder aber alternativ oder kombiniert an unser traditionelles Bausteindesign-Schema mit TYP und Klarnamen ohne Umlaute (und Kleinschreibung nach Bindestrich statt Großbuchstaben), auf die ggf. die bisherigen WMF-Designs abzubilden wären; bzw. wir auch neue definieren können, die WMF-Designs genauer wiedergeben. Irgendwas wie meldung-.
• Sofern das nur seitenspezifisch angefordert wird, können wir die historischen Bezeichner aber migrierend unterstützen.
• Misstrauisch hatte ich mir schon vor einigen Jahren die Deklarationen kopiert:

.error {
   color: #CC0000;
}
.warning {
   color: #705000;
}
.success {
   color: #009000;
}
.messagebox {
   background-color: #EAECF0;
   border-color: #A2A9B1;
}
.errorbox {
   background-color: #FEE7E6;
   border-color: #DD3333;
}
.warningbox {
   background-color: #FEF6E7;
   border-color: #FFCC33;
}
.successbox {
   background-color: #D5FDF4;
   border-color: #14866D;
}
.messagebox,
.errorbox,
.warningbox,
.successbox {
   border: 1px solid;
   color: #000000;
   padding: .5em 1em;
   margin-bottom: 1em;
}

resources/src/mediawiki.legacy/shared.css wurde mittlerweile gelöscht. Kein legacy, kein shared mehr.

• Es gibt auch keine auf WMF-Seiten hinterlegte Zusage, dass wir dauerhaft mw-message-box-warning usw. verwenden und uns darauf verlassen dürfen. Insofern würde ich die WMF-Stile nunmehr sukzessive in die Tonne kloppen, auch um Kollisionen mit zukünftigen Design-Extravaganzen zu vermeiden, und nunmehr unser eigenes Ding drehen.

Das Problem mit dieser Super-Idee, Klassen statt inline-style zu verwenden, zieht in unserem globalen Namensraum mit Kollaboration zwischen anderen Wikis und der WMF und diversen Vorlagen und Artikeln nach sich, dass es einer kollisionsfreien globalen Registrierung der Namen bedarf. Und die fehlt seit immer. Und deshalb ist inline-style ohne Kollisionsgefahr und mit zentraler Vereinbarung in einer Vorlage diesem ganzen class-Rummel bis heute haushoch überlegen.

VG --PerfektesChaos 15:53, 2. Mär. 2022 (CET)

Auch mw-message-box-warning wird nicht mehr immer verfügbar sein, so wie ich verstanden habe, wird die ganze messageBoxes.less nur noch vom Core geladen, wenn der Core sie auch braucht.

Ich hatte auch die Idee, das styling in Vorlage:Standardbaustein einzubauen. Ich weiß nur nicht, ob das dann auch in jeder Systemnachricht klappt. Gerade heute habe ich mich wieder darüber geärgert, dass die Systemnachrichten alles sein können, Konfigurationsvariable, Wikitext, HTML, Plaintext (und das noch abhängig vom Kontext) und raus findet man das praktisch nicht.

Naja, notfalls müssen eben Inline-Styles gebaut werden. -- hgzh 22:32, 3. Mär. 2022 (CET)

Ich sinne bereits auf Abhilfe.

• Dazu müsste aber erstmal geklärt werden, was wir wo brauchen; aus JavaScript oder in Vorlagen oder Systemnachrichten.

Mein momentaner Plan sähe dann so aus:

• Es gibt ein Gadget-dewikiMsgStyle.css
• Das kann einmalig pro Wiki-Seite eingelesen und in ein mw.loadData überführt werden, falls noch nicht bekannt.
• Das wandelt alle Klassendefinitionen in inline-geeignete CSS um. Was allerdings bei Pseudo-Selektoren nicht ginge, aber die sind ja aktuell nicht betroffen.
• Dadurch gibt es eine Lua-table mit Selektoren und zugeordnetem CSS-Code.
• Nun kann ein Lua-Funktionsmodul (das ggf. vorher auch einmalig die Generierung pro Seite des mw.loadData umgesetzt hätte) die Generierung eines HTML-Elements übernehmen, typischerweise div oder span, mit Klassen und weiteren style und lang und dir usw. Und natürlich ein textueller Inhalt.
• Die individuell übergebenen HTML-Spezifikationen und die Schlüssel werden zusammengeführt, und es kommt ein formatiertes Element heraus. Dem kann sogar eine Fehlerkat angeschlossen werden.

JavaScript kann das Gadget-dewikiMsgStyle wie üblich laden.

• Vorlage:Standardbaustein aber ebenso (die ließe sich damit deutlich vereinfachen); auch die traditionell laaaaangweilige Vorlage:Kasten.

Damit gibt es nur eine zentrale Definition.

Theoretisch könnte noch per C&P ein textidentisches TemplateStyles parallel gehalten werden; weil das aber in Systemnachrichten nicht funktioniert und die gern außerhalb des Inhaltsbereiches irgendwelche Kästen darstellen ist das überflüssig und style geht immer und überall.

OT: Mein ganz spezieller Alles-Aufräum-Experte mit Tellerrand endend in der enWP hat’s mal wieder verbockt; was du ja auf FZW schon kommentiertest.

VG --PerfektesChaos 16:40, 4. Mär. 2022 (CET)

@hgzh: So, ich habe mal zur geistigen Entspannung Vorlage:Kasten@BETA gebaut.

• Basiert auf MediaWiki:Gadget-dewikiMsgStyle.css die ich gern erstmal nur als existierende Seite hier hätte.
• Vergleiche mit hiesiger Vorlage:Kasten sowie Vorlage:Standardbaustein.
  • Vorlage:Standardbaustein ist inzwischen auf über 50.000 Einbindungen gekommen und damit Kandidat für Dreiviertel move=sysop geworden.
• Gadget muss das einleitend genannte jetzt noch nicht sofort werden.
  • Die Gadget-Schubserei machen wir vielleicht besser Mitte/Ende März; mir behagt momentan die Weltlage nicht und ich bin ziemlich down.

VG --PerfektesChaos 21:51, 7. Mär. 2022 (CET)

Danke, ich schau es mir mal an. Gruß, -- hgzh 07:34, 8. Mär. 2022 (CET)

So, nochmal ein bisschen drüber nachgedacht: wie sieht denn die Abgrenzung zwischen Vorlage:Kasten, Vorlage:Standardbaustein und Vorlage:Hinweisbaustein zukünftig aus? -- hgzh 20:03, 28. Mär. 2022 (CEST)

Es nimmt die historisch gewachsenen und in den Köpfen eingewurzelten Traditionen auf.

Rein technisch ist Vorlage:Kasten (zukünftig) wenig anderes als ein Standardbaustein ohne Icon.

• Könnte einen Unterschied in der beanspruchten Breite geben.
• Hat deshalb aber weniger Parameter im Blickfeld.
• Ob irgendwann Vorlage:Kasten intern Vorlage:Standardbaustein aufrufen mag oder nicht wäre ein späterer Schritt, nach Konsolidierung der ersten Phase.

Vorlage:Kasten ist dafür gedacht, direkt von Autoren im ANR, in Diskussionen und auf Projektseiten eingebaut zu werden.

• Bisher gibt es einen einzigen Parameter und genau ein Design, was ja auch kompatibel bleibt.
• Zukünftig sind mehr optische Lösungen im Angebot, die aber eher nicht völlig beliebig zusammengestellt werden sollten, sondern auf den traditionellen Satz an Standard-Designs kanalisiert würden. Momentan gibt es x private Direkt-Konstruktionen, auch mit Layout-Tabellen.
• Es gibt auch weiterhin die HTML-Universal-Attribute wie bei allen derartigen Universal-Basis-Vorlagen, die aber ignoriert werden dürfen und nur Spezialfälle abdecken.
• Es könnten unterstützte Parameter undokumentiert bleiben, fürs Volk: role dir

Vorlage:Standardbaustein ist wie auch Vorlage:Hinweisbaustein dafür gedacht, andere Bausteine zu konstruieren und den technischen Background auf einfache Weise unterstützt zu bekommen.

• Also QS-Bausteine, Systemnachrichten usw.
• Eine Direktverwendung für Autoren ist nicht vorgesehen, ließe sich aber nicht verhindern. Ergibt sich letztlich eher aus der Kategorisierung und Auffindbarkeit.
• Vorlage:Hinweisbaustein ist ein Sonderfall für die Konstruktion von ANR-Bausteinen, insbesondere mit den beiden Varianten „ganz oben“ und „ganz unten“. Hat damit auch ein anderes Schutzbedürfnis und Häufigkeit.
• Vorlage:Standardbaustein kann die neuen abstrahierten fehler warnung erfolg danach hinzulernen. Wäre ohnehin Migration einiger Design-Namen erforderlich (rotROT hellgrün), ist aber nur geringfügig verwendet worden.
• Vorlage:Standardbaustein transportiert noch Infos zur Migration von Vorlage:Bausteindesign4 Vorlage:Bausteindesign5 ,,, Vorlage:Bausteindesign13 wohingegen Vorlage:Kasten nahe Null ohne Altbestand loslegen kann.

Parameternamen und Design soll innerhalb der Familie soweit möglich vereinheitlicht werden; ebenso die Klassenbezeichner. Familie ist aber sehr weitläufig.

• VE-Unterstützung von vornherein mitgedacht. noprint zum Ankreuzeln.
• Schriftfarbe nur über Hex könnte ich mir für Vorlage:Kasten noch vorstellen.
• Systemnachrichten, Klassen und TemplateStyles beißen sich.
  • Man könnte den Dingern noch die class= mitgeben, dann funktionieren die Systemnachrichten, und wer unbedingt sein privates Design veranstalten will kann das mit !important kontra-re-stechen.
• Sind mehrere langjährige Migrationsphasen erforderlich, bis ein Optimalzustand erreicht wäre. Text@Kasten ist ein beliebiger Inhalt. Text@Zitat dann schon eher Text.

Nebenbei hatte ich auf BETA dein JS wohlwollend kommentiert.

VG --PerfektesChaos 15:23, 29. Mär. 2022 (CEST)

Danke für die Klärung und auch für das Feedback zum JS-Versuch auf Beta.

Da es nun wohl ernst wird und mit dem kommenden Softwareupdate die Box-Klassen aus dem allgemeinen Stylesheet gekickt werden, habe ich MediaWiki:Gadget-dewikiMsgStyle.css von Beta hierher kopiert. Zweierlei erzeugt noch Fragen meinerseits:

• wie wollen wir mit den hintergrundfarbe/rahmenfarbe-Klassen umgehen? Diese werden ja spezieller auch in Common.css und Mobile.css definiert, sollten also wenn möglich nicht konkurrierend bestehen. Die recht spezifische Definition der hintergrundfarbe-Klassen in der Common.css hatte seinerzeit einen Hintergrund: MediaWiki Diskussion:Common.css/Archiv/2.
• dewikiMsgStyle passt mit hintergrundfarbe/rahmenfarbe nicht mehr so wirklich, da die ja auch überall anders verwendet werden, nicht nur in Benachrichtigungskästen.

Grund zur Hektik besteht m.E. aber nicht, lokal verwendet wird sie nur von ein paar Handvoll Systemnachrichten, die ein paar Tage auch ohne Rahmen auskommen dürften. Gruß, -- hgzh 18:11, 20. Apr. 2022 (CEST)

@hgzh: Bitte die MediaWiki:Gadget-dewikiMsgStyle.css noch in das Content Model sanitized setzen.

• Nachdem gestern Ende von Sommer war und ich bei momentanen Temperaturen wieder anfangen kann zu denken, beginne ich nunmehr offene Baustellen abzuarbeiten.
• Was die Frage nach Duplizität der hintergrundfarbe/rahmenfarbe-Klassen angeht, so werden sie wohl sehr sehr langfristig sowohl im Gadget wie auch in Common.css dupliziert verbleiben müssen.
  • Sie sind dann aber auch auf Mobil wirksam; das wäre der nächste Teil einer Aktion; die parallele Deklaration aus MediaWiki:Mobile.css zu reduzieren. Wobei, da sind nicht alle Rahmenfarben identisch, aber das muss ich nicht verstehen
  • Jedoch würde im Zuge der Einarbeitung mittels TemplateStyles in Vorlagen, dann ggf. in ANR oder per irgendwann möglicher Namensraum-spezifischer Gadget-Einbindung die Nutzung aus projektweiter CSS-Bereitstellung nach und nach zurückgebaut werden können. Dazu muss aber erstmal TemplateStyles einsatzfähig sein.
• Name von dem Dingens, naja, „dewiki-und-Msg-Styles-Gadget“.

VG --PerfektesChaos 21:42, 18. Okt. 2022 (CEST)

Die Content-Model-Änderung hatte ich kürzlich vorgenommen. Wieso wir die Farbklassen aus Mobile.css rausnehmen könnten, aus Common.css aber nicht, verstehe ich noch nicht. Zudem wäre noch zu klären, was die nur noch generelle Definition der hintergrundfarbe-Klassen für Auswirkungen auf Tabellen hat. Wenn ich mich recht entsinne, waren die Definitionen à la table > * > tr > th.hintergrundfarbe8 so, um in wikitables wirken zu können, die die Hintergrundfarben so spezifisch festlegen. Gruß, -- hgzh 12:01, 4. Nov. 2022 (CET)

Deutsche Titel bei Spezialseiten

Hintergrund Spezial:PermaLink/226978873, zu ändern wären (Liste von hgzh, hab mal mit paar Vorschlägen angefangen, gerne einfach ergänzen):

• Spezial:TopicSubscriptions → Spezial:Themenbezogene Abonnements  Ok
• Spezial:ChangeContentModel -> Spezial:Inhaltsmodell einer Seite ändern
• Spezial:Manage Two-factor authentication -> Spezial:Zwei-Faktor-Authentifizierung verwalten
• Spezial:NewcomerTasksInfo -> Spezial:Einstiegs-Aufgabe
• Spezial:EditGrowthConfig -> Spezial:Growth-Konfiguration bearbeiten
• Spezial:FindComment -> Spezial:Kommentar finden  Ok
• Spezial:EditPage → Spezial:Seite bearbeiten
• Spezial:DeletePage → Spezial:Seite löschen
• Spezial:ProtectPage → Spezial:Seite schützen
• Spezial:PageInfo → Spezial:Seiteninformationen
• Spezial:PageHistory -> Spezial:Versionsgeschichte (schon vergeben). Stattdessen?
• Spezial:ApiSandbox -> Spezial:API-Spielwiese  Ok
• Spezial:GraphSandbox -> Spezial:Grafikspielwiese
• Spezial:GadgetUsage] -> Spezial:Statistik zur Nutzung der Helferlein
• Spezial:CreateLocalAccount -> Spezial:Erstellung eines lokalen Benutzerkontos erzwingen
• Spezial:PasswordPolicies -> Spezial:Passwortrichtlinien  Ok
• Spezial:BotPasswords -> Spezial:Botpasswörter  Ok
• Spezial:AutoblockList -> Spezial:Automatische Sperren
• Spezial:ChangeCredentials -> Spezial:Anmeldeinformationen ändern  Ok
• Spezial:RemoveCredentials -> Spezial:Anmeldeinformationen entfernen  Ok
• Spezial:PagesWithBadges -> Spezial:Seiten mit Auszeichnungen
• Spezial:EntityUsage -> Spezial:Objektverwendung
• Spezial:LintErrors → Spezial:Lint-Fehler
• Spezial:LintErrors -> Spezial:Lint-Vorlagenfehler
• Ganz neu: Spezial:Contribute -> Spezial:Beitragen  Ok
• neu Februar 2023: Spezial:MyLog -> Spezial:Mein Logbuch  Ok
• Spezial:CommunityConfiguration -> Spezial:Community-Konfiguration
• Spezial:GlobalVanishRequest
• Spezial:ListGrants -> Spezial:Berechtigungen  Ok
• Special:GlobalContributions -> Spezial:Globale Beiträge
• Spezial:EditRecovery -> Spezial:Bearbeitungswiederherstellung
• Spezial:NamespaceInfo -> Spezial:Namensrauminformationen
• Spezial:RestSandbox -> Spezial:REST-Spielwiese
• Spezial:BlockedExternalDomains -> Spezial:Gesperrte externe Domains  Ok
• Spezial:EnrollAsMentor -> Spezial:Als Lotse anmelden
• Special:MentorDashboard -> Spezial:Lotsen-Dashboard
• Spezial:ManageMentors -> Spezial:Lotsen-Verwaltung
• Spezial:DiscussionToolsDebug
• Spezial:MathWikibase
• Spezial:AutomaticTranslation
• Spezial:AccountSecurity -> Spezial:Kontosicherheit
• Spezial:IPContributions -> Spezial:IP-Beiträge
• Spezial:GlobalJsonLinks
• Spezial:RangeCalculator -> Spezial:IP-Range-Rechner
• Spezial:EditChecks -> Spezial:Bearbeitungsprüfungen

Was mir auch noch aufgefallen ist: Spezial:Verwaltung Benutzerkonten-Zusammenführung könnte man an den angezeigten Titel Spezial:Globale Benutzerkonteninformationen anpassen, für die SUL-Zusammenführung wird die Seite doch nicht mehr benötigt… VG, –IWL04 • 18:09, 12. Okt. 2022 (CEST)

Das ist nichts was hier bewirkt werden kann.

Damit der Parser sowas versteht, muss PHP geändert werden, und dann ist die Frage ob nur für dewiki oder für alle de.

Also Phab-Ticket, gestützt auf einen Community Consensus.

Dazu muss für jede nachträgliche Übersetzung in projektoffener Diskussion erörtert werden, welches die beste Formulierung wäre.

Brauchen wir das? Bei allen? Gäbe es auch größere Probleme? Wem hülfe dies?

• Spezial:DeletePage und Spezial:ProtectPage könnten nur Admins; nutzen die das jemals? Jedenfalls nicht massenwirksam. An jeder Seite NR≥0 ist ein Link um genau dies auszuführen.
• Spezial:LintErrors – das gibt niemand direkt ein, verlinkt sich bei den Wartungsameisen. Die kennen die Seite.
• GadgetUsage nutzen Programmierfexe.
• Seiteninformationen – sicher wichtig, aber wer kommt per Spezialseite dorthin, und nicht über Verlinkung auf der fraglichen Seite?

VG --PerfektesChaos 19:10, 12. Okt. 2022 (CEST)

@PerfektesChaos Das Thema kann durchaus hier behandelt werden. Wir müssen es nicht komplizierter machen als notwendig. Wenn es vernünftige, projektneutrale Übersetzungen sind, können wir sie auf Basis der hiesigen Sammlung als Patch einreichen. --Raymond ^Disk. 20:25, 12. Okt. 2022 (CEST)

Ich würd mir erstmal die Frage stellen, wer wann wozu die Spezialseiten überhaupt benötigt?

• Bearbeitungskommentare, Logbuchaktionen: Hier sind keine URL möglich, und Spezial:Diff/226930539/226982225 sowie Special:PermaLink/266586 sind für die Funktionalität wichtig.
• Spezial:Spezialseiten ermöglicht Navigation zu vielen Effekten. Dabei sieht aber niemand wie die heißen. Die Verlinkung wird angeklickt und gut ist.
• Versionsgeschichte und Seiteninfo werden von den Verlinkungen der aktuellen Seite aus angesteuert. Ich kenne niemanden außer mir, der das im Wikitext zur Verlinkung per Spezialseite angibt, und glaube auch nicht dass irgendjemand solch eine Spezialseite in das Suchfeld eintippt. Die macht dann auch wieder action=info und action=history draus; niemand sieht die also in der URL und hat irgendeine Berührung damit.
• Vieles wird nur von IT-Experten genutzt, und dann auch nur über Spezial:Spezialseiten oder von einer Hilfeseite aus navigiert: PasswordPolicies BotPasswords AutoblockList ChangeCredentials RemoveCredentials PagesWithBadges EntityUsage GadgetUsage ApiSandbox GraphSandbox – niemand weiß auswendig, auf welcher Spezialseite das stünde, und wie die genau hieße, und würde den Namen in das Suchfeld eintippen. Und zusätzlich zum englischen Namen sollen die Handvoll IT-ler sich noch deutsche Lokalisierungen merken?
• Welcher Admin hat denn schon mal via Spezialseite eine Seite gelöscht?

Wer genau hat jetzt welches Problem womit?

VG --PerfektesChaos 20:45, 12. Okt. 2022 (CEST)

Naja, mindestens bei TopicSubscriptions, FindComment (= Teilnehmer in Diskussionen), 2FA-Kram (= Admins, zukünftig mglw. mehr), Passwortkram (= alle Benutzer), PagesWithBadges, EntityUsage (= Wikidata-Pflege) und Contribute (= Mobilnutzer) sehe ich derzeit oder zukünftig schon einen etwas breiteren Anwenderkreis, sodass eine Lokalisierung zumindest dieser Seiten erstmal naheliegend ist. Die anderen könnte man in dem Aufwasch sicher mitmachen, auch wenn die weiterleitenden Spezialseiten nun nicht die Wichtigsten sind. Aber wir haben eben bspw. auch Special:Weiterleitung, Spezial:Neuer Abschnitt, Spezial:Permanentlink und die ganzen Zufallsseiten lokalisiert. Und die kanonische Form funktioniert ja weiterhin. Gruß, -- hgzh 22:09, 12. Okt. 2022 (CEST)

Grundsätzlich wäre ich dafür, dass diese Spezialseiten genau den Namen haben, der eben auch schon als deutscher Titel angezeigt wird, sonst ist das inkonsequent. Wir müssten also in erster Linie die bestehenden Übersetzungen hier absegnen, dann die Seiten umbenennen lassen und alles ist gut. Gruß --XanonymusX (Diskussion) 22:11, 12. Okt. 2022 (CEST)

Also, Contribute würde ich eher von Mobil ausgeblendet haben wollen, falls das jemals da auftaucht. Ich fürchte, es wird. Genau so ein Dings hatten wir schonmal vom Desktop verbannt. Es forderte unangemeldete Benutzer dazu auf mittels CX einen Artikel aus einer anderen Wikipedia automatisch zu übersetzen und dann hier anzulegen, oder alle noch nicht verlinkten Wörter in einem Artikel zu verlinken, und derlei Unfug.

Es ist nicht erforderlich, nur um des Übersetzens willen alles und jedes zu lokalisieren, wenn es niemand gibt, der die Spezialseite benötigt oder seltener als einmal pro Jahr anfasst und dann ohnehin aus einer Hilfeseite kommen muss. Viel wichtiger wäre es, auf einem Dingens egal wie es heißt verständliche auf der Seite sichtbare Handlungsanweisungen zu geben. Ohne Hilfeseite sind viele der aufgezählten Angelegenheiten ohnehin unbegreiflich, und auf der steht dann auch die Verlinkung zum Anklicken.

H:SS/L ist lang genug, und mir kann niemand erzählen dass Normalsterbliche all diese Seiten wirklich benötigen und sich deutschsprachig oder auch nur englischsprachig merken können.

VG --PerfektesChaos 22:45, 12. Okt. 2022 (CEST)

Alles richtig. Aber sie sind eben schon übersetzt (soweit meine Stichproben gereicht haben), nur wurde das nicht konsequent auf den Seitennamen angewendet. Wie man all die Seiten finden und verstehen soll, ist ein anderes Thema (mir ist der Großteil auch unbekannt). Gruß --XanonymusX (Diskussion) 23:11, 12. Okt. 2022 (CEST)

Ich habe jetzt mal alle Überschriften der Spezialseite oben eingetragen. Bitte ändert gerne auf ggfs. sinnvollere (kürzere?) Namen ab. Nur bei PageHistory müssten wir eine Alternative finden. Raymond ^Disk. 12:33, 13. Okt. 2022 (CEST)

Durch MW übersetzt wurde wohl durchgängig die auffallend sichtbare Seitenüberschrift, nicht jedoch immer der in der Adresszeile von Desktop-Browsern sichtbare und bei Verlinkungen und für das Suchfeld benötigte (Alias-)Bezeichner.

Jeder technisch wirksame Alias, jede Weiterleitung einer Seite oder Alias eines Parameternamens ist eine Verkomplizierung des Systems.

• Es zwingt alle Beteiligten dazu, sich zu merken, dass Y dieselbe Wirkung hat wie X und nichts Neues ist, und bei Suchvorgängen alle Aliasse durchzuprobieren.
• Spezial:PageHistory ↔ Spezial:Versionsgeschichte lässt schon erahnen, welche Verwirrung und Konflikte diese Aktion zukünftig verursachen wird. „Benutzerbeiträge“ aka „Contribute“ ist das nächste Drama schon vor der Tür.
• Spezial:PageInfo/WP:MW/Ä bewirkt in der Adresszeile wieder die URL mit action=info und die VG analog action=history, bleibt also englischsprachig. Diese Spezialseiten als WL auf URL wurden nur systematisch eingeführt, um gelegentlich Verlinkungen zu ermöglichen, wo URL nicht angebracht sind. Wobei Spezial:Weiterleitung/user/310926 zwingend die englischsprachigen Schlüsselwörter page und user erfordern – wird also bestenfalls Denglisch, bewahrt uns aber vor Gender-Aliassen.
• Seiteninfo und VG werden über die an der betreffenden Seite angebrachten Verlinkungen angeklickt, und wenn jemand in FZW oder Artikeldisk eine derartige Darstellung zitieren möchte, dann wird die URL kopiert und verlinkt und gut ist. Niemand geht im Normalbetrieb zum Bearbeiten einer Seite erst auf eine Spezialseite und versucht dann diese Seite zu finden.
• Spezial:PageInfo wird außerhalb der hier erörterten Lokalisierung und ihrer Hilfeseiten auf einer Benutzerseite und einer Portalseite genutzt. Das rechtfertigt keinen Alias.
• In Systemnachrichten und Vorlagenprogrammierung ermöglichen die Spezialseiten-Aliasse gelegentlich einen eleganteren und übersichtlicheren Quelltext als die URL. Dann mögen sie genutzt werden, aber dort sind dann auch #switch und #ifeq im Spiel, und wer damit außerhalb des Sichtfeldes von Newbies zugange ist kommt auch mit PageInfo klar. Vor Benutzung muss ohnehin H:SS/P konsultiert werden.
• Wir haben auch einen Alias Spezial:Kaputte Weiterleitungen verlangt, der sich (118 Treffer) mit „Defekte Weiterleitungen“ (288 Treffer) beißt, neben BrokenRedirects (31 Treffer). Hilfe:Weiterleitung kennt das Wort „kaputt“ nicht; projektüblich sind nur „Defekte“ wie auch in WP:DWL.

Wenn die aktive Verwendung im Publikum seltener als einmal jährlich oder nie zu erwarten ist, weder im Suchfeld noch bei Konstruktion von Verlinkungen, dann sind Lokalisierungen der Bezeichner eher schädlich als hilfreich.

• Ein systematisches Vorgehen, um koste es was es wolle jeden momentan wirksamen Bezeichner einer Spezialseite unbedingt auch lokalisiert wie die momentan dargestellte Überschrift anzubieten, ist strikt abzulehnen.
• Wer sich langweilt, möge sich lieber darum kümmern, dass in der dargestellten Seite selbst eine in dem Moment hilfreiche Anleitung gegeben wird, und auf eine zugehörige Meta-Seite verlinkt wird, und dass es überhaupt eine Beschreibung der Funktionalität auf unseren Seiten gibt. Da gibt es in obiger Liste wesentlich größere Defizite.

VG --PerfektesChaos 13:39, 13. Okt. 2022 (CEST)

Zu PageHistory: Könnte da nicht Seiten- oder Versionsrückblick (oder auch -verlauf) passen? --Funkruf ^WP:CVU 16:58, 13. Okt. 2022 (CEST)

Liste aktualisiert. -- hgzh 11:06, 5. Mai 2025 (CEST) + -- hgzh 09:15, 13. Okt. 2025 (CEST) + -- hgzh 08:41, 25. Jun. 2026 (CEST)

MediaWiki:Gadget-editMenusDef.css Darkmode Anpassung

Der Code muss an den Darkmode angepasst werden, damit die Leiste im Darkmode nicht weiterhin weiß ist. Hier der Änderungsvorschlag:

.editMenus-button {
   background:   var(--background-color-neutral-subtle, #D8D8D8);
   border-color: var(--background-color-neutral, #E0E0E0) var(--color-disabled, #707070) var(--color-disabled, #707070) var(--background-color-neutral, #E0E0E0)
   border-style: solid;
   border-width: 2px;
   display:      inline-block;
   min-width:    1.5em;
   text-align:   center;
}
.menuSwitcher {
   margin-bottom: 1em;
   margin-top:    1px;
   background-color: var(--background-color-base, #FFF) !important;
   color:         var(--color-base, #000) !important;
}
.editOptions {
   clear: both;
}

In dem div gibt es auch noch style parameter die nicht aus der Klasse kommen. Aus MediaWiki:Gadget-editMenusDef.js kommen die jedoch nicht, daher vorerst die Lösung über !important. --GPSLeo (Diskussion) 12:12, 27. Okt. 2024 (CET)

--background-color-neutral-subtle ist recht hell, ich würde eher --background-color-neutral in Form von --dewiki-hintergrundfarbe5 nehmen, das kommt dem derzeitigen Aussehen näher.

Die Definitionen für den menuSwitcher kommen aus en:User:PerfektesChaos/js/menuSwitcher/d.js, da müsste PC die Zeilen 23 und 25 entsprechend anpassen. -- hgzh 07:46, 29. Okt. 2024 (CET)

en:User:PerfektesChaos/js unterliegt einem Sicherheits- und Versionierungsprozedere, kann ich einpflegen, Testen eher am Wochenede. VG --PerfektesChaos 16:14, 29. Okt. 2024 (CET)

en:Special:Diff/1254615359 live. VG --PerfektesChaos 22:34, 31. Okt. 2024 (CET)

Noch scheint das hier nicht wirksam zu sein. Vermutlich der Cache. -- hgzh 08:14, 4. Nov. 2024 (CET)

Offenbar scheint jQuerys .css()-Funktion die CSS-Variable in einen RGB-Wert zu expandieren. Da muss ich nochmal schauen, wieso das so ist und was man machen kann. -- hgzh 08:21, 11. Nov. 2024 (CET)

Offenbar sorgt das .clone() in en:User:PerfektesChaos/js/menuSwitcher/d.js dafür, dass CSS-Variablen expandiert werden. Es müsste also helfen, .css( GUI.css ); weiter oben zu entfernen und nach dem Klonvorgang auf $wrap anzuwenden:

   GUI.furnish = function ( appearance ) {
            // [...]
            if ( m ) {
               GUI.$wrappers = $( "<div>" );
               GUI.$wrappers.addClass( Sign );
			   
               GUI.$helpers = $( "<div>" );
               // [...]
               for ( k = 1;  k < m;  k++ ) {
                  $wrap = GUI.$wrappers.clone()
                                       .css( GUI.css );
                  j     = k + k;
                  // [...]
   };   // GUI.furnish()

-- hgzh 10:45, 19. Mär. 2025 (CET)

Werde ich voraussichtlich heute nacht wie vorgeschlagen in der d-Version zur Erprobung bereitstellen.

VG --PerfektesChaos 12:37, 19. Mär. 2025 (CET)

Bereit zur Erprobung:

1. Häkchen raus
2. en:Special:Diff/1281442821
3. mw.loader.load( "ext.gadget.editMenus" );

Enjoy --PerfektesChaos 13:11, 20. Mär. 2025 (CET)

Zum Verständnis: wie lade ich so die /d-Version? Es wird doch weiterhin die /r geladen wie angegeben, oder nicht? Aber wahrscheinlich war das ohnehin noch kein Treffer, irgendwo klemmt's noch immer. -- hgzh 13:50, 20. Mär. 2025 (CET)

Das Problem liegt doch nicht an .clone(), ich hatte vermutlich falsch getestet.

Seltsames Verhalten von jQuery:

• Testaufruf für Konsole:

  $("<div>").css("color", "var(--color-base, #202122)")
  

• bei Aufruf im Lesemodus (action=view) enthält das erzeugte Objekt wie gewünscht die Zuweisung var(--color-base, #202122)
• bei Aufruf im Bearbeiten-Modus (action=edit) wird die CSS-Variable in einen rgb-Wert ihres Fallbacks #202122 umgewandelt: rgb(32, 33, 34)

Ich weiß nicht, was soll es bedeuten. -- hgzh 14:07, 20. Mär. 2025 (CET)

„wie lade ich so die /d-Version?“

• Ganz normal, mit mw.loader.load() und raw-URL, Hauptsache zuerst.
• Die verbucht, dass sie bereits geladen ist.
• mw.loader.load( "ext.gadget.editMenus" ) weiß dann, dass es menuSwitcher schon gibt, und lädt kein anderes /r mehr.
• Selbst wenn du die /r-URL aktiv explizit lädst, zeigt sie dir nen Vogel, weiß dass sie schon vorher geladen wurde und bereits aktiviert ist, und streikt.

bei Aufruf im Lesemodus – bei Aufruf im Bearbeiten-Modus – ich stecke in meinen Programmierungen von 2019 nicht mehr so drin, würde aber vermuten, dass ohne action=edit-submit-upload bzw. ohne auffindbare Formularfelder kein GUI aufgebaut wird und überhaupt nichts vertiefend ausgeführt wird. GUI.fetch() und so.

VG --PerfektesChaos 15:19, 20. Mär. 2025 (CET)

Laden: jetzt verstanden, klar, menuSwitcher wird ja registriert.

Den Testaufruf meine ich ganz unabhängig von editMenus/menuSwitcher - ich erzeuge damit ja ein eigenständiges div mit jQuery, das sich unterschiedlich verhält. Das gleiche Verhalten ließe sich auch in enwiki beobachten. -- hgzh 16:59, 20. Mär. 2025 (CET)

Ich hab auch etwas rumgespielt, das beschriebene Objekt erstellt, geklont, mit beiden action, keine Auffälligkeiten.

• jQuery interessiert sich sicher nicht für Wikis und deren action.
• Es kann aber sein, dass jQuery im Monent der Ausführung guckt, ob eine Definition der var() live ist, und wenn nicht dann direkt das RGB auswertet.
• Würde heißen, dass irgendein Codex-Modul explizit zusammen mit dem Gadget geladen werden muss, weil in view ist irgendwas aktiv und zieht das rein, und bei edit zumindest in dem Moment nicht.
• Mal mit --dewiki-hintergrundfarbe-basis ausprobieren?
• Mir erzählt der Firefox-Inspektor, dass diese Variable (alle MW) nicht geladen sind; überall und immer. Vector2010.

VG --PerfektesChaos 23:07, 20. Mär. 2025 (CET)

Unter Vector 2010 ist --color-base undefiniert, ja, aber auch mit --dewiki-hintergrundfarbe1 passiert das exakt gleiche. Eigentlich müsste jQuery das völlig egal sein, denn um die Auswertung des Fallbacks kümmert sich CSS ja selbst. Das Problem tritt auch nur auf, wenn man einen Fallbackwert angibt, ohne Fallback bleibt die Variable auch im Edit-Modus erhalten. Vielleicht spreche ich mal auf Phab diesbezüglich vor, mglw. ergibt sich dadurch etwas. -- hgzh 07:49, 21. Mär. 2025 (CET)

Jetzt phab:T391461. Vielleicht bin ich auch völlig vertrottelt und übersehe etwas offensichtliches. -- hgzh 13:42, 9. Apr. 2025 (CEST)

@Hgzh @PerfektesChaos ich habe in enWP gesehen, dass die Leiste des Quelltext editors, Dark Mode gefixt ist, warum kann diese Lösung nicht in deWP verwendet werden? Karma (Diskussion) 22:30, 12. Jul. 2025 (CEST)

@Hgzh, @PerfektesChaos: Lasst mich das auch mal fragen. Offensichtlich zeigt uns ja enwiki, dass es doch möglich ist. Warum probieren wir es denn nicht einmal auf deren Weise, zu verlieren haben wir doch nichts. ... --Doc Taxon (Diskussion) 01:03, 28. Jan. 2026 (CET)

Mit enwiki hat das nichts zu tun, die nutzen ein anderes Skript da unten. Das Problem ist im Prinzip schon behoben, nur jQuery zerdengelt da irgendwas. -- hgzh 06:51, 28. Jan. 2026 (CET)

Explain

Wir haben ca. 4.200 ANR-Einbindungen der Klasse explain, die wohl irgendwann mal von einem zentralen Stylesheet mit einem Aussehen wie <abbr> (Beispiel) versorgt worden ist. Das geschieht mittlerweile nicht mehr, aber Hilfe:Tags beschreibt das ehemalige Verhalten noch. Was also tun damit? In abbr konvertieren, Klasse entfernen, Vorlage? Tendiere zu ersterem, wenn es sich wirklich um eine Abkürzung handelt. Gruß, -- hgzh 10:57, 22. Apr. 2025 (CEST)

ANR-Botlauf in Vorlage:Erklärt (Erläutert), und wir haben die zentrale Kontrolle, mit:

• Text= Pflicht
• Meint= Pflicht
• abbr= 0|1
• lang= kann interessant sein, weil Begriff echtes Fremdwort
• style= Routine für alle Elemente
• class= Routine für alle Elemente
• id= Routine für alle Elemente

<abbr> ist echte Abk., kann Screenreader zum Buchstabieren unbekannter Buchstabenfolgen veranlassen; Semantik-Missbrauch mag ich nicht.

• abbr=1 wandelt <span> in <abbr>
• Begriff muss keine Abk. sein, Text=proximal Meint=zum Rumpf hin – BKS Proximal.

Inline-Deko lieber als TS; Unterpunktelung in mittelgrau für Bright&Dark.

TS ungern wegen globaler Kollisionen des Selektors, ASCII und so. Braucht viel Phantasie.

• TS könnte aber auch alternativ ein content :after als hochgestelltes blaues Fragezeichen ohne C&P noprint darstellen.

Mittel der Wahl ist klassisch Wikilink [[Europäische Union|EU]], aber ich lernte, dass Tatsch-Geräte sofort dem Link folgen und kein Linkziel mehr als Tooltip zeigen.

Dekoration ist erforderlich, weil die Sehenden beim Lesen nicht ahnen können, dass sie mit Maus usw. eine Erläuterung bekommen würden; Blinde wissen das.

Vorlage liefert der Generation VE ein TD-Formular; Quelltext ist selbsterklärend; <abbr> ist für VE wohl Drama und Quelltext unverständlich.

VG --PerfektesChaos 14:16, 22. Apr. 2025 (CEST)

@bot: Wäre inhaltlich zu analysieren und zu separieren.

1. Wenn Inhalt nur bis zu einem halben Dutzend Großbuchstaben, dann abbr=1.
2. Wenn Inhalt Leerzeichen oder viele Kleinbuchstaben enthält, dann abbr=0.
3. GmbH enthält auch Kleinbuchstaben. Nach Schritt 1.+2. analysieren, was über bleibt.
4. <abbr> wird gern mal missbraucht um syntaktischen Effekt auszunutzen; bietet keine Gewähr.
5. usw. usw. sollte im ANR auf keinen Fall eine Erläuterung bekommen; das ist Quelltext-Überladung mit sinnlosen Kinkerlitzchen.
6. NATO ist zwar Abk., wird aber in einem Wort gesprochen. Mopo auch. Das Gewürge um die semantischen Definitionen von Kurzwörtern, Initialwörtern usw. hatte dazu geführt, dass 1998 die Abgrenzung von ACRONYM entnervt aufgegeben wurde. Eine Klassifizierung hat nur Sinn, wenn daraus was für Screenreader oder Rechtschreibprogramme folgen würde. Die sind aber auch nicht nur dumm.

VG --PerfektesChaos 20:46, 22. Apr. 2025 (CEST)

Ich habe mal etwas genauer durch die Treffer geschaut: vorwiegend Sport und Trivialfälle WM/EM/DNS/DNF, sollte machbar sein, das zu erkennen und umzuwandeln. Manchmal steckt die Klasse auch in Tabellensyntax, das wird dann schwieriger.

Eine Vorlage hätte Vorteile. Da hatte ich vor einem Jahr auch an einer Lösung herumgespielt, den Tooltip auch für Touchgeräte zu aktivieren: Abbr-Tests und styles (cc XanonymusX). Gruß, -- hgzh 08:43, 23. Apr. 2025 (CEST)

Ich habe die Vorlage nun angelegt; zum Boteinsatz überlege ich mir was. -- hgzh 11:50, 30. Aug. 2026 (CEST)

Kontrast hintergrundfarbe6 (blau)

In Wikipedia:Technik/Skin/Gadgets/dewikiCommonStyle sind die Klassen für die Hintergrundfarben definiert. Seit rund zwei Monaten ist Vector2022 der neue Standard-Skin und damit auch die Linkfarbe geändert worden. Dadurch ist der Kontrast (Rechner) zwischen der blauen Schrift und dem blauen Hintergrund (hintergrundfarbe6) von 4,5 auf 2,8 gesunken und beeinträchtigt das Lesen auch bezüglich der Barrierefreiheit. Auf Hilfe:Farbe (Disk.) gab es zwischen @Hgzh und @PerfektesChaos vor über einem Jahr schonmal eine Diskussion dazu, aber ich möchte dieses Thema mit Konzentrierung auf hintergrundfarbe6 nochmal aufgreifen, da Vector2022 wie gesagt neuer Standard ist und das Problem damit mittlerweile die Mehrheit der Lesenden betrifft. Im Hinblick auf alternative Farbtöne habe ich ein paar hier dargestellt:

Farbe (Kontrast)	Hex	Vector (alt)	Vector2022
hintergrundfarbe6 (2,8)	#B3B7FF	Frischer Blaulink Geklickter Blaulink	Frischer Blaulink Geklickter Blaulink
Mittelweg A (3,7)	#C3D6FF	Frischer Blaulink Geklickter Blaulink	Frischer Blaulink Geklickter Blaulink
Mittelweg B (4,0)	#D0DDFF	Frischer Blaulink Geklickter Blaulink	Frischer Blaulink Geklickter Blaulink
Starke Veränderung (4,5)	#CAF0FF	Frischer Blaulink Geklickter Blaulink	Frischer Blaulink Geklickter Blaulink

Farbe
hintergrundfarbe6	Mittelweg A	Mittelweg B	Starke Veränderung
hintergrundfarbe9
hintergrundfarbe8
hintergrundfarbe7

Nach den AA-Kriterien der WCAG 2.1 sollte der minimale Kontrast bei 4,5 liegen, was im alten Vector auch noch erreicht wurde. Mit der veränderten Linkfarbe (für die es gute Gründe gibt) müsste der Blauton stark verändert, fast schon cyan werden, um die 4,5 zu erreichen. Das wäre wahrscheinlich eine zu große Veränderung und auch zu nah zur grünen hintergrundfarbe9. Man kann aber Mittelwege gehen und so auch merkbare Verbesserungen (3,7–4,0) erzielen. Ich halte da den Mittelweg A (#C3D6FF) für durchaus brauchbar, da er auch zu den anderen definierten Hintergrundfarben passt, wo der bisherige Blauton spürbar dunkler ist. Die genauen Farbcodes sind natürlich nicht fest, falls sich da jemand mehr mit auskennt. Im Hinblick auf die mögliche Umsetzung gibt es wohl zwei mögliche Vorgehensweisen:

• Änderung der bisherigen hintergrundfarbe6: Würde alle bestehenden Artikel betreffen und in Einzelfällen eventuell zu Problemen führen, wo der exakte Farbcode gebraucht würde oder andere Blautöne daneben verwendet werden
• Einfügen als neue hintergrundfarbe10: Würde nur für neue Einbindungen und manuelle Änderungen eine Verbesserung erzielen. In Hilfe:Farbe müsste auf den ersetzenden Farbton hingewiesen werden.

Ich sehe die Farben sehr gerne, würde es daher begrüßen wenn sich eine definierte blaue Hintergrundfarbe ergibt, die auch mit Blaulinks wieder mit gutem Gewissen nutzbar ist. --Costamiri (Diskussion) 16:03, 30. Mai 2025 (CEST)

Wir können auch einfach hintergrundfarbe6 nur für Vector 2022 anpassen. Eine zehnte Klasse sollten wir jedenfalls nicht einführen. Gruß --XanonymusX (Diskussion) 19:23, 30. Mai 2025 (CEST)

Ganz anders herum: Dann muss ggf. das V2022-CSS dahingehend geändert werden, dass die beiden Linkfarben unmittelbar davor wieder so kräftig werden wie vor zwei Jahrzehnten. Die optische Wirkung von Link-Blautönen ist ohnehin je nach Hintergrund immer völlig anders.

• Die Hintergrundfarbe selbst darf nicht verändert werden, weil SVG usw. davon Gebrauch machen könnten und Kartenskizzen oder Tortendiagramme sich darauf verlassen könnten.
• Wobei man auf blauem Hintergrund ein gelbes Rechteck zeigen kann, in dem dann eine Verlinkung sichtbar sein kann.

Das sinnlose und plan- wie ziellose Rumgefummel der WMF im Altbestand widert an. Die Wikis verlassen sich seit Jahrzehnten auf den Kontrast zu ihren style- und class-Farben, und ein Konzept der WMF ist nicht erkennbar. Einen triftigen Grund für das Gehampel finde ich nirgendwo dargestellt, und das Phab-Gebastel geht in die falsche Richtung. Früher mal gab es Design-Strategie-Konzept-Seiten auf mw: , aber die sind alle ersatzlos gelöscht worden. Es gibt keinen Plan mehr.

VG --PerfektesChaos 20:25, 30. Mai 2025 (CEST)

Für den Darkmode gibt es so etwas bereits, da habe ich (für möglichst alle Elemente mit Hintergrundfarbe, funktioniert aber nicht in 100% aller Fälle) die Linkfarbe unbesucht auf _ #0000fa und besucht auf _ #5050fa gesetzt.

Wenn man etwas ähnliches im Standardmodus anwenden möchte, dann sollten aber 4, 6 und 7 gemeinsam angepasst werden, denn die haben alle das selbe Problem. -- hgzh 09:12, 2. Jun. 2025 (CEST)

Die saubere Lösung wäre ausschließlich Farben zu verwenden die im Codex definiert sind und solche die aktuell noch im Codex fehlen in diesen aufzunehmen. Spezialfarben sollte nur in Einzelfällen auf Metaseiten nicht aber in Artikeln genutzt werden. --GPSLeo (Diskussion) 09:31, 2. Jun. 2025 (CEST)

Nein, das allein wäre keine Lösung für das Kontrastproblem von blauer Schrift vor blauem Hintergrund, am Kontrastverhältnis ändert sich ja nichts, nur weil die Farben in irgendeinem Farbkanon stehen. Es gibt elf verschiedene Blautöne, von denen nur blue50 die Kontrastanforderungen als Hintergrundfarbe für Links erfüllt. Das ist aber eine völlig andere Farbe als unsere hintergrundfarbe6.

Außerdem ist Codex das Designsystem für das Interface und nicht für den Inhalt. -- hgzh 09:47, 2. Jun. 2025 (CEST)

Der Codex ist ja auch dazu da, damit alle wissen welche Farben es für welche Anwendung gibt (es ist nicht möglich das auch vielen Hundert Wikis herauszusuchen) und dass es eben nach Updates keine Kontrastprobleme gibt. --GPSLeo (Diskussion) 11:14, 2. Jun. 2025 (CEST)

In einigen anderen Sprachversionen (inklusive enWP) haben sie offenbar beschlossen, Links vor Hintergrundfarben nur noch schwarz und unterstrichen darzustellen. Schön finde ich das nicht, aber Kontrastproblemen kann das natürlich vorbeugen … --XanonymusX (Diskussion) 22:24, 2. Jun. 2025 (CEST)

Die enWP-Lösung kommt aus dem zentralen Darkmode-Stylesheet. Ich halte das für die schlechtestmögliche Lösung und aus UX-Sicht katastrophal. Es ist doch vollkommen verrückt, Links auf völlig unterschiedliche Art und Weise darzustellen, wenn eine Tabellenzelle eine Hintergrundfarbe hat. Dann muss man schon so ehrlich sein und alle Links nur unterstrichen darstellen. -- hgzh 07:41, 3. Jun. 2025 (CEST)

• Unterstreichung ist bei uns nicht akzeptabel, und sie löst auch überhaupt nicht das beanstandete Problem: Die Buchstaben wären schwerer zu erkennen, weil der Kontrast Schriftfarbe/Hintergrundfarbe ungenügend sei.
  • Schriftfarbe schwarz und Rotlinks schwarz und Verlinkungen nur durch Unterstreichung statt blau/rot ist inakzeptabel, weil wir dies nirgendwo so machen und die Unterstreichung ANR-weit bis auf Fachbedeutung verboten ist. Blaulinks in schwarz unterstreichen und Rotlinks rot nicht unterstreichen ist genauso wirr.
  • Außerdem kollidieren bei einer Unterstreichung ggf. die Unterlängen.
  • Unterstreichung würde in unseren Artikeln jedoch als Hervorhebung und nicht als Verlinkung verstanden werden.
• Zwei kräftige klassische Blautöne bei allen betroffenen Pastell-Hintergründen in V2022-CSS zu definieren, wenn direktes Kind, ist okay.
  • Auf Verlinkungs-Blautöne konnte sich nie jemand verlassen, weil diese klassisch Browser-konfigurierbar sind, und außerdem mit unbesucht→besucht ohnehin nicht vorhersagbar sind.
• Dass die Pastelltöne jedoch untereinander, mit SVG oder PNG, mit anderen Farben wie Gold oder Silber oder Bronze synchronisiert sind, darauf konnte sich quer durch alle Skins verlassen werden.
• Die Pastelltöne sind dezent gegenüber weißem oder sehr hellem Monobook-cologneblue-Hintergrund. Wenn der Rest der Seite aber nicht mehr hell sondern schwarz ist, dann knallen die natürlich rein statt dezent; aber das ist nicht zu ändern und Problem der Leute, die ein seit einem Vierteljahrhundert auf Vielfarbigkeit komponiertes Projekt in Facebook-eBay-Google-Stil darzustellen begehren. Pech; wirklich schwarzes Pech.
• Beim Wechsel von Normal zu Dark muss die gleiche Palette der Hintergrundfarben untereinander entstehen.
• Subjektive Farbwahrnehmung hängt vom unmittelbaren Hintergrund und der weiter umgebenden Hintergrundgestaltung ab.
• Der äußere Portal-Rahmen steht vollständig unter Kontrolle von MW; der innere Content unter Kontrolle der Autoren. Außen mag jede Farbe eliminiert werden, also schwarz-weiß-blau; innen gilt das nicht.

VG --PerfektesChaos 16:02, 3. Jun. 2025 (CEST)

Benutzer:Schnark/js/personendaten.js & normdaten.js

In den Reparaturtagen der Technischen Wünsche wurde der Wunsch wiederholt, dass Schnarks Tool auch in Artikelentwürfen im Benutzernamensraum nutzbar sein sollte. Wir halten das für eine sehr kleine Änderung, die eher eine Fehlerbehebung als eine funktionale Veränderung ist und bei der es in Ordnung sein sollte, wenn ein Oberflächenadministrator sie für den inaktiven Autor vornimmt. Schätzungsweise 300 Benutzer*innen würden davon profitieren. Unten unsere vorgeschlagenen Änderungen für die zwei zusammen hängenden Skripte. Vielen Dank!

Benutzer:Schnark/js/personendaten.js vorher:

//nur im ANR
mw.config.get('wgNamespaceNumber') === 0 &&

Nachher:

//Im Artikel- und Benutzer-Namensraum
[ 0, 2 ].includes(mw.config.get('wgNamespaceNumber')) &&

Benutzer:Schnark/js/personendaten.js/normdaten.js vorher:

if (ve || (mw.config.get('wgNamespaceNumber') === 0 && window.location.search.indexOf('oldid') === -1)) {

Nachher:

if (ve || (
    //Im Artikel- und Benutzer-Namensraum
    [ 0, 2 ].includes(mw.config.get('wgNamespaceNumber')) &&
    !window.location.search.includes('oldid')
)) {

--Thiemo Kreuz (WMDE) 15:26, 29. Aug. 2025 (CEST)

Grundsätzlich befürworte ich eine Aktivität in dieser Richtung; und es würde auch Schnarks Konzeption nicht wesentlich verletzen.

• Allerdings ändert es das Verhalten für alle, was unerwünscht sein kann, ggf. auch in Sachen Performance oder gar Netzwerk-Traffic.
• Es müsste deshalb konfigurierbar für besondere Interessenten gemacht werden (Opt-In außerhalb des globalen Variablen-Raums).
• In der vorgeschlagenen Form nicht akzeptabel. Obendrein wegen Fliegelflagel für einen Großteil der Wünschenden funktionslos.

Es müsste in Wikipedia:Technik/Skin/JS/mw/libs entsprechend erweitert werden. Danach ginge sinngemäß wie folgt:

var rooms = [ 0 ];
if ( typeof mw.libs.personendaten  ===  "object"
     &&     mw.libs.personendaten   &&
     typeof mw.libs.personendaten.roomsPD  ===  "object"
     &&     mw.libs.personendaten.roomsPD   &&
     typeof mw.libs.personendaten.roomsPD.length  ===  "number" ) {
   rooms = mw.libs.personendaten.roomsPD;
}
rooms.includes( ... )

@ „300 Benutzer*innen würden davon profitieren“

• Die Trefferliste ergibt nicht, dass alle noch aktiv wären; manche sind gar verstorben. Ob ein eingebundenes Dingens überhaupt noch benutzt wird, ist vielen Autoren überhaupt nicht klar. Da gab es mal einen Tipp, diese und jene Zeilen reinzukopieren.
• Unter den Aktiven mag es einige geben, die das bereits im eigenen BNR-Entwurf nutzen möchten.

Nebenbei ist es pfiffig, das Laden auf den ANR oder die gewünschen NR zu begrenzen; Benutzer:Schnark/js/personendaten erwähnt das nicht, aber Fliegelflagel verbessert die Performance und vermeidet den Start lauter unpassender Skripte.

• Weil Zeilen 147 wie auch 135 in Benutzer:Schnark/js/fliegelflagel.js/define.js das limitieren, würde der abschnittseröffnende Wunsch für die Fliegelflagel-User wirkungslos bleiben.
• Da ist seitens der BNR-Begehrenden schon einiges mehr an Umbauten zu leisten.
• Die Fliegelflagel-User lassen sich nicht über eine Abfrage herausfinden; wie viele Aktive das tatsächlich nutzen, bleibt unbekannt; wie viele davon Entwürfe im BNR erstellen, ist ebenso unklar. Aber sicher profitieren keine 300.

@ „Alternative wäre, dass ihr das Skript in den Gadget-Namensraum kopiert und dort gemeinsam weiter pflegt.“

• Das würde bedeuten, dass die derzeit 2–3 Tech-Betreuenden, die die gesamte Tech-Infrastruktur der deWP pflegen, auch noch dieses Teil übernehmen müssten; und weil die Community das mit einem Rechtsanspruch verbindet, dass alle unter Gadgets gelisteten Werkzeuge auf ewige Zeiten am Funktionieren gehalten werden müssen, würde das auch noch unseren Enkeln aufgebürdet werden.
• Inhaltliche Skripte dieser Komplexität, obendrein nur für bestimmte Themen, sind ab den 2010ern nicht mehr als Community-Gadget eingeführt worden.
• Ein Maintainer müsste im eigenen BNR mit entsprechenden Credits und Schnark-Würdigung einen Nachfolger anbieten. Die Verantwortung ist dann zwischen erstem Doppelpunkt und erstem Schrägstrich abzulesen.

VG --PerfektesChaos 15:25, 30. Aug. 2025 (CEST)

Ich denke nicht, dass hier unbedingt das große Konfigurationsrad gedreht werden muss. Das Skript ist ja relativ harmlos und der BNR-Anwendungsfall scheint mir sinnvoll zu sein. -- hgzh 12:52, 1. Sep. 2025 (CEST)

Die fliegelflagel-User (unter den Schnarkies stark vertreten) hätten trotzdem nichts von der Änderung.

Der Anfragende Benutzer:M2k~dewiki/common.js hat fliegelflagel auskommentiert ab Zeile 46, allerdings auch direkte Aufrufe in den Zeilen 68–70.

Perspektivisch müssen die Interessenten ohnehin einen eigenen Maintainer finden, weil das Werkzeug absehbar immer weiter inhaltlich gepflegt werden muss.

• Rund 5 % des Aufwands sind am Code und für Programmierung.
• 95 % werden für Dokumentation und Kommunikation (Anfragen, Gesuche, Erklärungen) benötigt.

WMDE müsste in Schnarks Dokumentation eingreifen und das Geschehen um den BNR präzise erläutern.

VG --PerfektesChaos 15:34, 3. Sep. 2025 (CEST)

Funktionsnamen updaten in Benutzer:Schnark/js/veHint.js

Hinweis auf BD

• Da sich keine Funktionalität ändern soll, sondern nur die Bibliotheksfunktion verändert wurde, halte ich das für zumutbar.
• Wie genau der neue Quellcode heißen soll, weiß ich erstmal auch nicht, da solle noch irgendwas mit after anzufügen sein.
• Einen neuen Maintainer dafür zu suchen ist aussichtslos; wenn ich das Œuvre richtig überschaue, schreibt bei uns niemand für den VE, und der Einstieg ist nicht trivial.

VG --PerfektesChaos 16:53, 11. Mär. 2026 (CET)

Ich kenne mich in der VE-Struktur nicht aus, müsste wahrscheinlich tief einsteigen. Da das Problem offenbar noch niemanden stört, lohnt sich das wahrscheinlich nicht... -- hgzh 09:42, 27. Mai 2026 (CEST)

Schutz vor usurpierten BOA

Als Konsequenz aus dem globalen Drama vom 5. März kam der Plan auf, über Bearbeitungsfilter unsere Ressourcen zu härten.

• Es wird keinerlei Plan oder Konzept erörtert, wie die WMF eine Wiederholung verhindern wollte, und es ist JS-technisch auch nicht erkennbar, wie die Wurminfektion eines BOA verhindert werden könnte.
• Wir können aber lokal sehr gut verhindern, dass unsere erwarteten Standard-Ressourcen unbemerkt einem gehackten lokalen oder globalen BOA zur Explosion verhelfen.

Prozedur:

• Alle Standard-JS wie MediaWiki:common.js sollten ohne WL nach WP:Technik/Archiv verschoben werden, Content Model wikitext und mit Disku und -Archiven zur History der VG.
• In monobook und dem nicht mehr anwählbaren modern gibt es noch wirksame Statements.
• Letzteres könnte auf Verdacht mal wegfallen; gucken ob das irgendwer merkt.
• MediaWiki:Gadget-dewikiMonobook.js für deren Reste, damit niemand über deren olle Skriptseiten weint.
• Wikitext-Kommentar der aktuellen obersten Version in einem netten Kasterl erklärt die Sache mit der Funktionalität und VG.

Anschließend den Bearbeitungsfilter-Trick:

• Bearbeitung aller mobil-Desktop-Standard-JS ausschließen (CSS lässt sich zwar auch bös hacken, kann sich jedoch nicht weiterverbreiten, höchstens ein Zählpixel einschleusen). Falls CSS komplett migriert, dann auch CSS blocken. Zusätzlich sysop-Blockade von create, aber das wäre vermutlich kein Schutz gegen BOA.
• Bearbeitung von JS/CSS im BNR wenn Konto nicht ROOTPAGENAME.
  • Zur ausnahmsweisen Bearbeitung von Fremd-BNR müsste der Bearbeitungsfilter kurz deaktiviert werden; mit dem Risiko, dass die Reaktivierung vergessen wird.
• Filter privatisieren.

VG --PerfektesChaos 16:11, 13. Mär. 2026 (CET)

Der Wurm könnte vor dem Verbreiten allerdings auch einfach selbst den Filter deaktivieren. Den Filter geheim zu halten funktioniert auch nicht, dann werden einfach alle Filter deaktiviert. Ohne Softwareanpassungen gibt es hier glaube ich keine sichere Lösung. --GPSLeo (Diskussion) 16:31, 13. Mär. 2026 (CET)

Möglich wäre das vielleicht mit zwei Accounts. Einer darf das JS bearbeiten, aber keine Filter. Der andere darf Filter bearbeiten, aber kein JS. --GPSLeo (Diskussion) 16:34, 13. Mär. 2026 (CET)

Ein Wurm-Skript würde in Meta: oder der enWP in irgendeinem Hilfswerkzeug-JS seinen Ausgang nehmen; von irgendwem, der mit ganz großem Knall die Wiki-Mitarbeit infinit beenden möchte.

Das Wurm-Skript, sofern unser BOA sich dieses Hilfswerkzeug einbindet, würde entweder bei einem globalen Admin versuchen sich auf andere Wikis auszudehnen, oder unser lokaler BOA verwendet es in der Artikelarbeit usw.

• Das Wurm-Skript würde die in allen Wikis zu erwartenden Standard-Ressourcen befallen und sie bearbeitbar am üblichen Platz suchen. Da sitzt niemand mit bei, der eine Prozedur über Filter und sonstwas örtlich steuert.
• Theoretisch könnte auch jemand per API eine Seitenliste aller JS-Gadgets im MediaWiki-Namensraum abfragen, deren Eintreffen abwarten, und dann auch diese befallen. Diese können wir nicht schützen; dann kämen wir überhaupt nicht mehr zum Arbeiten.
• Wir können jedoch wirksam eine Konstellation bauen, die einen Alle-Wikis-schnell-befall-Wurm von uns fernhält. Der erwartet die von allen Lesenden eingebundenen Standard-Ressourcen mit ihrem Standard-Seitennamen.

Es gibt JS-technisch keinerlei Möglichkeit, gute und böse JS-Bearbeitungen voneinander zu unterscheiden.

• Auf „Softwareanpassungen“ der WMF zu warten, kann einige Jahrzehnte dauern. Das ist ein süßer Traum. Es gibt auch keinerlei ernsthafte Versprechungen der WMF in dieser Richtung, und keinerlei Ideen wie das so realisiert werden könnte, dass die guten Nutzungen immer noch realistisch stattfinden könnten. Und es gibt kein Budget für sowas, wiewohl es in mehrere Mannmonate ginge und in den Jahresplan aufgenommen werden müsste.
• Außerdem betreibt wohl die enWP einen Bot mit BOA-Rechten, der externen JS-Code in Benutzer-JS-Seiten hineinkopiert, und die enWP ist stark unter den MediaWiki-Developern vertreten und wird alles verhindern, das diesen Bot blockt.
• Und auch andere Ideen mit „2FA“ würden erforderlich machen, dass bei jeder einzelnen Bearbeitung ein sechsstelliger Zahlencode in ein externes 2FA-Device/App außerhalb des Browser getippt werden müsste, und dann binnen 30 Sekunden ein sechsstelliges Einmal-Passwort in unsere Bearbeitungsseite. Die globalen Interface-Maintainer machen teils 100 Edits in fremden Wikis in einer Sitzung und werden auch 2FA-Pläne zu verhindern wissen. Budget ist keins da.

Wir könnten uns aber im Laufe des Wochenendes oder der kommenden Woche sehr wirkungsvoll gegen Standard-Würmer schützen.

@ zwei Accounts: Das ist ohnehin ein weiterer Plan, bei der aber ein Dutzend Leute mitziehen müsste. Das ist aufwändiger als die oben dargestellte Aufräum-Aktion. Es wäre ein Zweit-Account mit BOA-Rechten einzurichten, aber damit der ein fremdes Benutzerskript auf Wunsch bearbeiten kann, bräucht er sinnvollerweise normale sysop inklusive Filter. Aber vielleicht im safemode zu betreiben? Egal, andere Baustelle, steht auf meiner Agenda, aber nicht sofort. Ein Wurm-Skript erwartet aber erstmal keine Filter.

VG --PerfektesChaos 16:59, 13. Mär. 2026 (CET)

es wäre möglich den admins und damit auch den BOAs generell das filterbearbeitenrecht zu entziehen, es gibt ja eh grad die diskussion eine neue gruppe für filterbearbeiter einzurichten. benutzer mit BOA rechten sollten dann dieses recht nicht haben, wenn sie ausnahmesweise eine fremde js seite bearbeiten, muss entweder ein filterbearbeiter den filter kurz ausschalten, oder der BOA hat das filterbeareitenrecht in seinem standard adminaccount und nicht im 2BOAaccount. da das filterbearbeitenrecht bisher bei den adminsstandardmässig aktiviert war, sollte es formlos auf antrag direkt an die admins vergeben werden, 90% der admins haben es wahschrinlich noch nie benutzt.

ich weiss das dies umzusetzen nicht einfach wird, und ob sich der aufwand mit diskussionen etc lohnt, aber es ist halt nicht so, dass es nicht technisch möglich wäre. gruss --Wetterwolke (Diskussion) 14:23, 15. Mär. 2026 (CET)

Das ist aber nicht gewünscht und hier überhaupt nicht das Thema, und es wird auch nicht dazu kommen.

Das anderthalb Hundert Admins kann jederzeit auch das Log der privaten Filter einsehen, um stille Vandalismus-Warnungen zu überwachen, ohne dass dieser Personenkreis irgendwas mit Filter-Programmierung zu tun hätte und sich da so schnell rantrauen würde.

Wenn ein Techie, der die Programmierung eines offenen Filters versteht, einen Bug oder eine unbeabsichtigte Wirkung bemerkt, kann jederzeit auf WP:A/A der Code für die Verbesserung hingeschrieben werden, und alle Admins können den Fix sofort einpflegen, oder bei Totalversagen vorläufig einfach deaktivieren, ohne in der Urlaubszeit eine Woche darauf zu warten, bis eins von den 7 Angehörigen einer exklusiven Bearbeitungsfilter-Verwalter-Gruppe Zeit dafür hätte.

Bitte diesen Abschnitt nicht zu derailen mit lauter hier sachfremden Neben-Diskussionen. Hier geht es darum, unsere Standard-Ressourcen einem globalem Angriff wie dem vom 5. März zu entziehen. Und der würde nach Schema F die 50 Wikis mit häufigsten Zugriffszahlen durchlaufen.

VG --PerfektesChaos 14:34, 15. Mär. 2026 (CET)

Die WMF diskutiert diese Fragestellung aktuell in phab:T197160 und Untertickets. —DerHexer (Disk., Bew.) 19:23, 13. Mär. 2026 (CET)

Ja, danke.

• Da steht aber nichts Neues, und der BOA-Bot ist angesprochen.

Das einzig wirksame Mittel ist, jeden einzelnen Edit mittels 2FA durch einen Code generiert außerhalb des Browsers zu bestätigen.

• Die dort vorgetragene Idee, ein BOA solle vor seinem ersten Ressourcen-Edit nochmals 2FA bestätigen, funktioniert nicht und hätte das Prinzip 5. März nicht verhindert: Mit dem erneuten 2FA wird das Konto befugt, und mag ja jetzt einen guten Edit ausführen, aber nun kann der schlummernde Wurm zuschlagen und auch alle bösen Edits machen. Eine Stunde lang, wird im Phab-Ticket als Lösung vorgeschlagen.
• Das ist ein nassPelzTrockenwaschverfahren, das nicht aufgeht: Entweder Bot und globale BOA können schnell mehrere Dutzend Wikis besuchen und dort etwas anpassen, dann kann auch Wurm-JS ausgeführt werden. Oder pro Edit muss 2FA ausgeführt werden, was alle legitimen Aktivitäten ganz massiv ausbremst.

Wir hier sind in der komfortablen Situation, dass wir die Standard-Ressourcen praktisch nicht mehr benötigen.

• Wer einen Wurm programmiert, wird bei globalen BOA versuchen, die größten Wikis von der enWP, Commons und Meta runter eins nach dem andern zu infizieren, und da stehen wir weit vorn auf der Speisekarte. Oder jeder lokale BOA, der das zufällig gestartet hat.
• Dabei wird je einmal mobil plus Desktop am erwarteten Ort anzugreifen sein. Schema F durchgezogen in möglichst vielen Wikis.
• Wir haben nur noch MediaWiki:monobook.js mit etwas legacy-Spaß aktiv. Dazu ein wenig CSS, dass dann auch gleich abgeräumt werden sollte.
• Ich kann mich an die SuperUser-Affäre nur dunkel erinnern und habe wenig mit den Rechten und Konfigurationen zu tun.
• create=bureaucrat müsste aber gehen. Vielleicht nicht mit dem interaktiven Formular, jedoch per API.
  • Das führt zu einer Situation, die zurzeit niemand mehr aufdröseln kann: BÜR haben kein BOA und dürfen keine Rechte ändern, Admins dürfen wohl keine Rechte ändern, wenn sie nicht selbst etwa zur SuperUser-Gruppe gehören, BOA sind keine BÜR. Wer Ressourcen-Rechte ändern darf, weiß ich heute nicht mehr auswendig; vor einem halben Dutzend Jahre hatte ich mich mal dafür eingesetzt, dass Admins Ressourcen nur löschen dürfen (Not-Aus), aber sonst rein gar nix.
  • Wäre auf BETA mal an einem nie benötigten Seitennamen zu testen.
  • Würde den Filter auf die Standard-Ressourcen sparen.
  • Unsere Standard-Ressourcen sollte nur noch ein Dutzend Rotlinks sein, die niemand mehr anlegen geschweige denn bearbeiten kann.
• Ist ein wenig security through obscurity.
  • Die ist aber auch nicht wirkungslos. Viele Angriffs-Software bringt man erfolgreich dadurch zum Absturz, dass Dateipfade und Einstellungen nicht so liegen wie sie ein globaler Angreifer erwartet.
  • Kaum jemand wird unsere archivierten deutschsprachigen Hinterzimmer-Diskussionen alle durchlesen, oder in allen Wikis die Seiten-Eigenschaften und Rechte aller Ressourcen vor dem Angriff studieren und deWP-Sonderregelungen programmieren, um erst noch Filter oder Rechte zu modifizieren. Egal, ob in ein paar Monaten ein DIVA-infinit mit großem Knall passieren soll, oder russische Trolle bzw. MAGA auf die WMF angesetzt werden.
  • Mit dem Event vom 5./6. März ist die Idee eines globalen Wurms jedenfalls überall auf dem Planeten bekanntgeworden, und alle, die irgendein Benutzerskript programmieren können, sind auch in der Lage, ganz einfach den Standard-Angriff zu bauen und abzuwarten bis irgendein BOA aus welchen Gründen auch immer in die Falle tapst. Braucht ein bis zwei Dutzend moderne JS-Statements. proof of concept wurde grad weltweit kommuniziert.
  • Eine vollständige Sicherheit würde die normalen Vorgänge maximal ausbremsen, außer 2FA für jeden Edit sehe ich keinerlei Lösung, die nicht wieder genauso auszutricksen wäre.

VG --PerfektesChaos 21:08, 13. Mär. 2026 (CET)

Das relevanteste Angriffsszenario ist denke ich, dass ein IA ein User-Script eines anderen Users eingebunden hat und dieser User mutwillig oder weil der Account übernommen wurde das bisherige Script durch den Schadcode austauscht. In diesem Szenario kennt der Angreifer die deutschsprachige Wikipedia ganz genau. Nur die Common.js zu schützen reicht nicht aus, dann wird halt ein Gadget infiziert, das alle Admins aktiviert haben. Man könnte natürlich auch das Laden fremde User-Scripte verbieten. Was viele brauchen, muss halt ein Gadget werden und was nur wenige brauchen müssen diese halt komplett kopieren. --GPSLeo (Diskussion) 22:01, 13. Mär. 2026 (CET)

Das ist Teil 2 und nicht Gegenstand dieses Abschnitts hier; hier ginge es um einen globalen BOA, der kompromittiert wurde und in allen Wikis die Standard-Ressourcen verseucht. Das war das Event vom 5. März.

Die andere Seite ist in der Tat, dass alle BOA und auch die OS permanent die BOA-Rechte schussbereit haben, wir aber kaum 100 BOA-Edits pro Jahr im Projekt haben. Die OS haben meines Wissens noch nie das BOA-Recht eingesetzt, obwohl sie zur Erfüllung ihrer Aufgaben seit etlichen Jahren damit ausgestattet werden.

• Mit demselben Konto machen sie aber auch Artikel-Arbeit und nutzen administrative Helferlein aller Art.
• Teil 2 der Übung wäre also, dass unsere deWP-BOA alle einen Zweit-Account nutzen, der BOA ist, aber vielleicht mit safemode die normalen JS-Funktionen grundsätzlich deaktivieren und sich nur für die BOA-Tätigkeiten kurz einloggen. Ihr normales Helferlein-Portfolio ist im Zweitkonto nicht installiert. Nachdem getan wurde, was zu tun war, wäre logout angesagt. Macht man das in einem zweiten Browser, muss man sich aus dem ersten nichtmal ausloggen. Das Hauptkonto hat alle Helferlein von überallher.

@ „Was viele brauchen, muss halt ein Gadget werden und was nur wenige brauchen müssen diese halt komplett kopieren.“

• Das funktioniert nicht. Wir müssten Hunderte oder Tausende Seiten als eigene Gadgets etablieren und pflegen; und bei jedem Bugfix und jeder Verbesserung des Originals müssten wir das sofort mitbekommen und unsere Kopie auch aktualisieren. Und jedes Skript, das ein OS oder BOA nutzen möchte, müssten wir bereithalten. Außerdem stehen in den Skripten oft Seitenpfade und URL zum Nachladen weiterer Ressourcen; die müssten wir bei jeder Aktualisierung wieder alle auf unsere URL und unsere Seiten umbiegen.

Nein, das Hauptkonto ist ganz normaler Admin oder OS und macht ganz normale Arbeit mit allen Skripten wo lustig ist.

• Nur ist das Hauptkonto kein BOA mehr.

VG --PerfektesChaos 22:28, 13. Mär. 2026 (CET)

create=bureaucrat sollte nur gehen, wenn auch ein entsprechendes Schutz-Level konfiguriert ist. Derzeit ist das nicht der Fall.

Dass die OS BOA-Rechte haben, scheint im Übrigen so ein deutscher Sonderweg zu sein, den die OS damals einfach selbst beschlossen haben. Eine tatsächliche Notwendigkeit wurde in diesem Zuge nie überzeugend argumentiert. --MGChecker – (📞| 📝) 23:16, 13. Mär. 2026 (CET)

create=bureaucrat – naja, wenn das Anstrengungen bedarf, dann halt nicht. Ein privater Filter käme für einen externen Angriff völlig überraschend und wäre nicht vorhersehbar. Und selbst wer um dessen Existenz wüsste, hätte programmtechnisch allerhand zu tun, nur für uns, und fraglich ob es jemals gelänge den Schadcode wirkungsvoll auszuführen. Und wer die Liste der zwei Dutzend größten Wiks abarbeitet, kann das nicht ahnen.

@ „den die OS damals einfach selbst beschlossen haben. Eine tatsächliche Notwendigkeit wurde in diesem Zuge nie überzeugend argumentiert“.

• Doch, das ist durchaus sehr sinnvoll, und wurde bei Einführung der BOA im Sinne des Erhalts der zuvor vorhandenen Möglichkeiten so konzipiert. Genauso wie alle zuvor gewählten sysop auf Wunsch weiterhin BOA-Aktionen ausführen dürfen.
• Wenn jemand in seinem BNR eine CSS-/JS-Seite anlegt und als einzigen Kommentar Böses reinschreibt, dann konnten seit 2018 die OS nichts mehr machen. BOA könnten diese Seite revertieren oder löschen und sysop-verstecken, aber nicht OSsen. Damit das weiterhin möglich bleibt, hatte man das den OS gegeben, das war okay.
• Das Problem ist nur, dass seit 8 Jahren permanent 4–5 OS bei jedem Seitenabruf die BOA-Rechte scharf geschaltet haben, und im Hintergrund sonstwas ablaufen kann, während nicht bekannt wurde, dass es jemals einen Vorfall gegeben hätte. Das wäre mit Zweitaccount für den einen Einsatz alle Jubeljahre geschützt. Ist aber in diesem Abschnitt nicht das Thema.

VG --PerfektesChaos 13:10, 14. Mär. 2026 (CET)

MediaWiki:Gadget-PB2.js ?user= aus URL auswerten

Damit WP:PB auch auf mobilen Geräten verwendet werden kann, hätte ich folgenden Vorschlag:

1. Auf Wikipedia:Persönliche Bekanntschaften/neue Anfragen ?user= aus URL auswerten.
2. Auf https://pb.toolforge.org/user/name/Simon04 in der Spalte Rückbestägtigt=nein einen Link einfügen, der https://aufeinwort.info/wiki/Wikipedia:Pers%C3%B6nliche_Bekanntschaften/neue_Anfragen?user=Regiomontanus aufruft. Dazu muss https://github.com/tool-labs/pb/blob/master/web/templates/user.html angepasst werden.

Für 1. kann folgender Patch (Software) dienen:

-        if (tmpUser != mw.config.get('wgUserName'))
-            usersToConfirm += '<option value="' + tmpUserQuot + '" label="' + tmpUserQuot + '">' + tmpUserQuot + '</option>';
+        if (tmpUser != mw.config.get('wgUserName')) {
+            const selected = new URL(location.href).searchParams.get('user') === tmpUser ? 'selected' : '';
+            usersToConfirm += `<option value="${tmpUserQuot}" label="${tmpUserQuot}" ${selected}>${tmpUserQuot}</option>`;
+        }

Für 2. kann ich in weiterer Folge auch gerne einen Patch schreiben. Danke! --Simon04 (Diskussion) 22:14, 26. Mai 2026 (CEST)

Ersteller und Maintainer ist Benutzer:Euku, und dieser erfreulicherweise gelegentlich immer noch zugange, so zuletzt vor kaum einer Woche.

Zunächstmal wäre der Maintainer zuständig, wünschenswerte Veränderungen zu kommentieren und ggf. in eine BNR-Fassung einzupflegen und auszutesten.

Dass wir das als Community-Gadget am Hals haben, und die BOA jetzt für die Erprobung und Richtigkeit von Änderungen verantwortlich sind, ist ein Kardinalfehler der damaligen Altlasten. Heutzutage würde sowas im eigenen BNR des gerade zuständigen Maintainers liegen, und wer es nutzen möchte, kann es von dort einbindenn.

VG --PerfektesChaos 23:14, 26. Mai 2026 (CEST)

Das PB-Gadget wird momentan im Minerva-Skin nicht geladen; wenn das jemand testen will, kann ich das freischalten (Selbsttest fällt mangels Teilnahme an PB meinerseits aus); m.E. braucht es da keine Änderungen am Code. -- hgzh 09:50, 27. Mai 2026 (CEST)

@Simon04 siehe meine Anmerkung hier; besteht noch Interesse an einem Test? -- hgzh 08:36, 27. Aug. 2026 (CEST)

Hi zusammen! Nunja, das gibt es schon. Nehmen wir einen zufälligen Teilnehmer Benutzer:Lirum Larum. Da gibt es in der PB-Vorlage einen Link: → kenne ich, bestätigen der zwei Parameter bis zur Bestätigungsseite durchleitet.

Zum Punkt 2, nehmen wir https://pb.toolforge.org/user/name/Simon04 als Beispiel. Ich unterscheide hier einige Fälle.

Wenn ich als Besucher weder Simon04 bin, noch ihn getroffen habe, wird mir als Fremden dort kein Link weiterhelfen. Ich denke das ist kein sinnvoller Use-Case.

Besucher ist Simon04 selbst:

• Dann erwartet er unter "Erhaltene Bestätigungen" nur bei den "Rückbestätigt=nein"-Zeilen einen Link mit Vorselektion z.B. zu Reisen8, Granada etc. Klingt nützlich.
• Was erwartet Simon04 dann unter "Vergebene Bestätigungen"? Carokaffee und Co hat er schon bestätigt.

Ich als Besucher, war auf einem Treffen mit Simon04 und rufe die o.g. Seite auf:

• Dann bekomme ich unter "Erhaltene Bestätigungen" bei den "Rückbestätigt=nein"-Zeilen Links, die mir nichts nützten. Da stehe ich entweder selber mit Link zu mir selbst oder nicht, dann gibt es auch keine Zeile.
• "Vergebene Bestätigungen": Hier zeigen die Links alle Richtung Simon04, weil es sonst sinnlos ist. Was will ich mit anderen, die Simon bestätigt hat? Dann muss der Link aber auch nicht zigfach wiederholt werden.

Korrigiere mich bitte, aber eigentlich ist nur der erste Fall sinnvoll, nämlich "wer hat mich bestätigt und wen habe ich vergessen?" Das allerdings sagt mir der Bot auch über Nacht. Übersichtlicher finde ich einen solchen Link mit Vorselektion in der Benutzerseite zu finden. Dort kann ich besser sichergehen, dass dies der richtige Benutzer ist als über eine Liste von Namen. In WP haben wir das schon. Im Kopf von https://pb.toolforge.org/user/name/Simon04 können wir besprechen. Was denkst du? --Euku:^⇄ 23:37, 29. Mai 2026 (CEST)

Jüngste unabgesprochene Änderung in MediaWiki:Gadget-dewikiDarkmode.css

Spezial:Diff/266227624/269105496 verändert die bedeutungstragenden Farben in TemplateData-Beschreibungen:

• „Blau stellt Pflichtparameter dar.“
• „Weiß stellt vorgeschlagene Parameter dar.“

Diese Aussagen wurden jetzt zu Nonsens vergurkt.

Die Farben in TemplateData sind bedeutungstragend, nicht dekorativ.

• Das ist ungefähr genauso, als ob das weiß-blaue Rautenmuster Bayerns für den DarkMode in schwarz-gelb umgeschrieben wird.

Die Änderung muss revertiert werden. Bedeutungstragende Veränderungen zuerst hier auf dieser Seite diskutieren, Konsens herstellen, erst danach administrativ verändern.

Es geht mich ja nicht viel an, aber dieses CSS auf jegliche aufgerufene Seite anzuwenden, obwohl die Abruffrequenz von Vorlagendokus unter allen Seitenbesuchen minimal sein dürfte, ist auch nicht sonderlich performant.

VG --PerfektesChaos 10:38, 26. Jul. 2026 (CEST)

Pflichtparameter ist blau, vorgeschlagener ist weiß. Passt doch. Der vorherige Zustand war jedoch nicht darkmode-fähig, das ist zunächst grau schattiert. --Doc Taxon (Diskussion) 11:52, 26. Jul. 2026 (CEST)

Die Darkmode-Färbung, falls gewünscht, lässt sich aber gerne noch optimieren (Pflichtparameter ein dunkles Blau dann?). --Doc Taxon (Diskussion) 11:55, 26. Jul. 2026 (CEST)

Hab's in der Beschreibung gefunden: "Gemäß dem Status (benötigt, vorgeschlagen, optional, veraltet) werden die Zeilen in Hellblau, Weiß, Grau und Blassrot unterlegt (oder anderweitig konfiguriert)." Die Darkmode-Konfiguration ist jetzt als Variante drin mit benötigt: blau; vorgeschlagen: schwarz statt weiß; optional: grau; veraltet: rot. Diese Farben sind eher dunkel gehalten. Dies lässt sich noch optimieren. Als Darkmode-Variante sollte das in die Beschreibung dann auch einfließen, ich kann das gerne machen. --Doc Taxon (Diskussion) 14:00, 26. Jul. 2026 (CEST)

Wenn irgendwer mit irgendjemand anders dahingehend kommuniziert, bei den weiß unterlegten Parametern solle hier besser nichts angegeben werden, falls keine Werte vorliegen, dann ist das Müll, wenn die andere Person kein „weiß“ sehen kann. Und keiner von beiden muss jemals auf der fraglichen Hilfeseite gewesen sein und da in irgendeinem Abschnitt sowas gelesen haben, zumal es diese Farbkodierung schon seit einem Jahrzehnt gibt.

Bitte jetzt revertieren.

Die Spielregel, gerade bei einer schon langfristig umstrittenen Angelegenheit wie dieser, ist: Zuerst Vorschlag hier auf dieser Seite unterbreiten, dann mit genügend Zeit erörtern, bei Konsens separat erarbeitete stabile Lösung in einem einzigen Edit einpflegen.

• Wir wissen seit über einem Jahrzehnt, wie geschmeidiges Arbeiten läuft. Sooo nicht.
• Und eigenmächtige unangekündigte administrative Aktionen, die ich auch nicht selbst rvertieren kann und hgzh overruled haben, sind ein Armutszeugnis.

Ich verlange, dass ab jetzt alle weiß-blauen bayerischen Rauten überall im DarkMode nur noch schwarz-gelb gezeigt werden; das ist schließlich augenfreundlicher.

VG --PerfektesChaos 15:47, 26. Jul. 2026 (CEST)

Die Farbkodierung, die es seit einem Jahrzehnt schon gibt, soll ja auch gerne bleiben. Jetzt gibt es aber auch einen Darkmode, und ich denke, dass wir das gerne auch etwas konstruktiver diskutieren können. Für den Darkmode liegt jetzt eine Version vor, die die Farben ähnlich zeigt, außer für den Darkmode dann schwarz statt weiß. Die massiven weißen Flächen sind für die Anzeige im Darkmode nicht okay gewesen, aber mit Sicherheit auch nicht barrierefrei. Jetzt gibt es eine Darkmode-Variante und wir sind ein kleines Stück weiter in Richtung Barrierefreiheit. Ich finde das durchaus in Ordnung. Und selbstverständlich kann man das eine oder andere noch optimieren, dagegen habe ich ja nichts. Für den Lightmode gab es keinerlei Änderungen, dort ist alles wie gewohnt. Als Vergleichsversionen kann man beide jetzt auch gegenüberstellen, um gegenständlich weiterdiskutieren zu können, falls gewünscht. --Doc Taxon (Diskussion) 16:03, 26. Jul. 2026 (CEST)

per Ping BOA: @Chewbacca2205, Count Count, Doc Taxon, Euku, Hgzh, PDD, Raymond, Reinhard Kraasch, Seewolf, XanonymusX, Hyperdieter, Nolispanmo, Ra'ike, Tkarcher, Werner von Basil:
Was sagt Ihr zur Darkmode-Anpassung von TemplateData? Seht Ihr auch noch Verbesserungs- und Optimierungsbedarf? (Und wie weit ist unsere Mutterversion eigentlich global in Verwendung? In den größeren Wikipedien sehe ich ältere oder andere TemplateData-Versionen, die aber zu großem Teil schon lange vorher darkmode-tauglich waren – aber das nur nebenbei, ist ja auch nur eine Konfigurationssache.) Für Verbesserungsvorschläge bin ich offen. Vielen Dank für Meinungen, Ideen und Antworten. --Doc Taxon (Diskussion) 16:45, 26. Jul. 2026 (CEST)

@Doc Taxon Hilf mir bitte mal auf die Sprünge: Wofür ist das Gadget überhaupt da? Es gibt doch mittlerweile einen zentralen Dark Mode. --Raymond ^Disk. 18:39, 26. Jul. 2026 (CEST)

@Raymond: Das Gadget ist kein eigenständiger Darkmode-Switch – wie Du schon sagst, existiert der bereits nativ in Vector 2022 über die Klassen skin-theme-clientpref-night und skin-theme-clientpref-os. Das Gadget ist stattdessen ein ergänzendes, nicht opt-bares CSS-Stylesheet, das gezielt mehrere Kontrast- und Darstellungsprobleme behebt, die der zentrale, generische Darkmode systemweit nicht automatisch lösen kann oder per Change angepasst werden soll oder will. So führen Elemente mit beliebiger Inline-Hintergrundfarbe automatisch schwarze Schrift, unabhängig vom eigentlichen Farbwert, um Kontrastprobleme zu vermeiden. Das führt aber bei vielen dewiki-spezifischen Vorlagen und Konstrukten zu falscher oder unlesbarer Darstellung, wie z.B. dunkle Schrift auf dunklem Hintergrund in Infoboxen, Zeilenhintergründe bei Zebratabellen, Kontraste von Wikilinkfarben vor hellem Inline-Hintergrund, Galeriedateien mit transparentem Hintergrund, usw.
Ohne das Gadget blieben die Sachen im Darkmode unlesbar oder fehlerhaft dargestellt, weil die Core-Regel pauschal auf dunkle Schrift bei jeder Inline-Hintergrundfarbe setzt. Das Gadget ergänzt diese Lücken wie vom Projekt erwartet.
Diese TemplateData-Darkmode-Anpassung habe ich konkret deshalb vorgenommen, weil die Statuszeilen der Parametertabelle im Darkmode genauso hell waren wie im Lightmode. Aus welchen Gründen man auch immer im Darkmode arbeiten will oder muss, das liegt ja auf der Hand, sollte auch die TemplateData-Vorlage im Darkmode eher dunkel dargestellt sein. Da hier auf weitere Farben Wert gelegt wird, warum auch nicht, habe ich sie in vergleichenden dunkleren Farben wiedergegeben. So wurde hellblau dunkelblau, hellrot dunkelrot und weiß wurde in diesem Fall schwarz. --Doc Taxon (Diskussion) 19:35, 26. Jul. 2026 (CEST)

@Doc Taxon Danke für die Erläuterung; weil ich den Dark Mode auch gar nicht nutze. Ich schaue mir das gerne morgen im Detail an. Bin jetzt nach langer Bahnrückfahrt von der Wikimania müde und matschig. --Raymond ^Disk. 21:33, 26. Jul. 2026 (CEST)

@Raymond: Gute Erholung --Doc Taxon (Diskussion) 21:48, 26. Jul. 2026 (CEST)

@Doc Taxon Danke schön. Um sicher zu gehen, dass wir vom selben sprechen. Als geht beispielsweise um die Darstellung von TemplateData auf Vorlage:Normdaten? --Raymond ^Disk. 09:44, 27. Jul. 2026 (CEST)

Ja genau, im Lightmode und im Darkmode mal anschauen. Aber hgzh hat unten drunter einen weiteren guten Vorgang geschildert. --Doc Taxon (Diskussion) 11:22, 27. Jul. 2026 (CEST)

Danke, dann habe ich mir die richtige Seite schon angeschaut. Die Farben finde ich OK, die Umsetzung sollte besser wie von hgzh genannt erfolgen. --Raymond ^Disk. 12:25, 27. Jul. 2026 (CEST)

Gegen die Anpassung der Farbdarstellung habe ich erstmal nichts, wohl aber gegen die Umsetzung: seit Jahren versuchen wir, CSS und JS nur noch kontextabhängig zu laden und die zentralen Ressourcen nicht mehr mit Kram für Spezialfälle zu befüllen; jetzt haben wir CSS, das mobil und auf dem Desktop standardmäßig für jede Ansicht geladen wird, aber für den überwiegenden Großteil der Seitenaufrufe nicht relevant ist. Das ganze hätte von Anfang an in TemplateStyles unterhalb der Vorlage:TemplateData gehört, wo es abhängig geladen werden kann und auch thematisch hinpasst. Außerdem wäre es dann ratsam, die Farben gleich komplett im Stylesheet zu lagern, um sich das !important zu sparen. -- hgzh 10:54, 27. Jul. 2026 (CEST)

Hatte ich erst auch überlegt, aber nicht unterhalb der Vorlage sondern unterhalb des Moduls. Modul:TemplateData/config haben wir ja schon. Ich bin der Meinung, dass sich dort sowohl die Lightmode- als auch die Darkmode-Farben konfigurieren lassen. --Doc Taxon (Diskussion) 11:13, 27. Jul. 2026 (CEST)

Noch einmal: Sprachen auf der Hauptseite

Vorherige Diskussion: Wikipedia:Technik/Skin/MediaWiki/Änderungen/Archiv/2025, erneut aufgekommen in Wikipedia:Fragen zur Wikipedia/Archiv/2026/Woche 19 Aus meiner Sicht gibt es einen eindeutigen Konsens, die Sprachauswahl entsprechend in Vector 2022 anzupassen, nachdem sich für die anderen Skins ohnehin nichts ändert (für diese bleibt es bei Wikipedia:Hauptseite/Interwikis bzw. Wikipedia:Interwiki-Links auf der Hauptseite). Nachdem ein fertiges Konzept besteht, sehe ich nichts, was gegen eine Umsetzung sprechen würde. @XanonymusX: zur Info. –IWL04 • 12:12, 19. Aug. 2026 (CEST)

Den Diskussionsstand würde ich als irgendwie 1:1 unentschieden interpretieren; es gab auch mehrere sehr heftige Gegner einer „Umsetzung“.

BOA sind nicht dazu befugt, hier Entscheidungen zu treffen; sie hätten nur den klaren Willen der Community umzusetzen. Das gilt für Admins allgemein, die in einem vorgegebenen Rahmen LD und VM anhand der Umstände des Einzelfalls entscheiden, sonst nix.

Grundlage ist ein Verbot, mehr als irgendwelche 50 oder was andere Wikipedien auf der Hauptseite zu verlinken. Das stammte aus einer Zeit, als alle Links gleichzeitig statisch sichtbar waren, und ist für diese Situation sinnvoll. Dass dies absurd wird, sobald ein dynamisches Element vorhanden ist, das nur eine einzige Verlinkung sichtbar macht, und erst auf Wunsch irgendeine Navigation ermöglicht, ist völlig klar.

Zuallererst muss aber die Community dieses Verbot einschränken bzw. präzisieren.

• Dafür wurde ein MB gefordert.
• Einen Konsens gibt es nicht.
• Eine Umfrage würde die Mehrheitsverhältnisse deutlich machen, würde aber von einigen wenigen als unerlaubtes MB light abgelehnt werden.
• Also bleibt alles wie es ist, und wie es schon immer gewesen ist, bis zum MB.

VG --PerfektesChaos 13:36, 19. Aug. 2026 (CEST)

Das ist es ja genau: es gab eben keine Gegner der inhaltlichen Umsetzung, sondern es wurde sich nur am Format der Umfrage gestört. Unter Wikipedia Diskussion:Umfragen/Hauptseite: Sprachversionen, Anzahl und Darstellung heißt es auch ausdrücklich von einem dieser Kritiker „Vielleicht reicht ja wirklich Common Sense.“ – das würde ich begrüßen. Ein MB für diese Sache wäre völlig überzogen, generell sind sie kein verbindliches Verfahren, sondern nur dann notwendig, wenn kein Konsens erziehlt werden konnte oder um eine MB-Entscheidung zu ändern oder (diese gibt es hier nicht). –IWL04 • 15:36, 19. Aug. 2026 (CEST)

Es gab auf FZW und sonstwo auch entschiedene Gegner, und keinen Konsens.

Wenn es jemals ein eindeutiges Ergebnis gegeben htte, wäre das auch unverzüglich umgesetzt worden.

In der Sache wird die Zahl der sichtbaren Elemente von 30 oder 50 oder was auch immer auf genau eins reduziert, was vor zwei Jahrzehnten ja mal das Ziel der Geschichte gewesen war. Dort heißt es jedoch, die Anzahl erlaubter Sprachen müsse begrenzt sein, egal mit welcher Skin.

Du müsstest zuerst im Konsens die fragliche Projektseite in diesem Sinn verändern; mit der kannst du dann wieder hier aufschlagen. Vorher ist das Ressourcenvergeudung. Bislang hat sich null verändert.

VG --PerfektesChaos 16:29, 19. Aug. 2026 (CEST)

• 
  ULS bevorzugte Sprachen
• 
  ULS Sprachen wählen

Als vor zwei Jahrzehnten darüber abgestimmt wurde, musste das begrenzt werden, um nicht das linke Seitenmenü mit 300+ Sprachen vollzukleistern. Da war Vector 2022 und der neue Mechanismus zur Sprachauswahl noch gar nicht absehbar. Auch im Vergleich zur Umfrage von 2025 hat sich die Situation nochmal geändert, anders als damals schlägt ULS nun nicht mehr irgendwelche Sprachen vor, stattdessen kann man nun im Zuge des ULS rewrite selbst bevorzugte Sprachen auswählen. Dass man dann unter "Alle Sprachen" nur 50 Hauptseiten auswählen kann, ergibt gar keinen Sinn. --Johannnes89 (Diskussion) 10:31, 20. Aug. 2026 (CEST)

Das ist hier unter Techies alles völlig klar.

Die wesentlichen Umstände waren aber auch vor Jahren bereits bekannt gewesen, und waren trotzdem von der Community nicht konsentiert worden.

Zuallerallererst muss die fragliche Projektseite im Konsens konkretisiert, präzisiert und aktualisiert worden sein.

Erst nachdem dort Konsens mit der Community über mehrere Wochen robust bestanden hatte, kann es hier auf dieser Seite weitergehn. Hier ist das hintere Ende der Pipeline, die Umsetzung des Community-Willens, und nicht die Oktroyierung was die Community gefälligst zu wollen habe.

Vorher ist das Ressourcenvergeudung. Bislang hat sich null verändert.

VG --PerfektesChaos 10:57, 20. Aug. 2026 (CEST)

MediaWiki:Mobile.css und MediaWiki:Mobile.js deaktivieren

Ich würde gern die Deaktivierung der o.g. zentralen Ressourcenseiten veranlassen. Sie werden hier nicht mehr genutzt und sind ein verzichtbarer Angriffsvektor für auf vielen Seiten auszuführenden Schadcode. Ich hatte auf phab:T403380 schon einmal einen Antrag gestellt, bei dem auf eine formale Community-Zustimmung bestanden worden ist. Zu diesem Zeitpunkt war das nicht so dringend, aber nach der Aktion im März diesen Jahres ist es vielleicht doch nicht schlecht, hier ein Einfallstor zu schließen. Ich bitte daher um Zustimmung zu dem skizzierten Vorgehen, dann würde ich den genannten Task wieder aufmachen und hierher verweisen. -- hgzh 14:50, 31. Aug. 2026 (CEST)

Von mir aus gerne, sehe keinen Grund dagegen. --Johannnes89 (Diskussion) 15:22, 31. Aug. 2026 (CEST)

Liest sich sinnvoll. Unterstützung von mir. —DerHexer (Disk., Bew.) 11:53, 1. Sep. 2026 (CEST)

Statt sich den Mühen des WMF-Consensus hinzugeben, der manchmal akzeptiert wird mit einer nachweislich falschen Behauptung einer Einzelperson, dann jetzt hier eine formalere Rechtfertigung einfordert, empfehle ich folgendes homebrew-Vorgehen:

1. Alle Rest-Programmierungen aller Standard-Seiten auf System-Gadgets kopieren, sofern noch nicht geschehen.
2. Alle Standard-Ressourcen-Seiten ohne WL verschieben als entsprechende Unterseiten von WP:Technik/Archiv, da haben wir bereits einen Unterseiten-Pfad für Ex-MediaWiki.
3. Dort Content-Model ändern auf wikitext.
4. On Top der Ex-Ressource einen Wikitext-Kasten mit Hinweis auf die VG.
5. Diskussionsseiten mit WL korrespondierend verschieben.
6. Einen privaten BF bauen, der irgendwie genial und blockierend reagiert, sobald irgendwer versucht, auf diesen Rotlinks eine neue Seite anzulegen; das könnte so ein März-Aktivist sein.
7. Ich weiß nicht, wie sourcepage auf nicht existierende Seiten reagiert, aber ggf. würde /Doku auf der leeren Seite eingeblendet werden, und könnte befugte Menschen auf das System-Gadget sowie WP:Technik/Archiv hinweisen.
8. Globale BOA-Bot-Aktivitäten würden hingegen in den BF laufen.

@ WMF: I would enjoy to get default resources disabled by configuration, but we might be able to help ourselves.

Greetings --PerfektesChaos 16:33, 31. Aug. 2026 (CEST)

Link auf Abrufstatistik

Wir haben doch unten im Fußbereich auf allen Seiten (egal ob ANR oder ein anderer Namensraum) eine Verlinkung auf die Abrufstatistik („Pageviews Analysis“). Aktuell ist es dort so, dass, wenn man auf den Link klickt, die Seite standardmäßig in „Englisch“ und nicht in „Deutsch“ angezeigt wird. Man kann dann zwar auf der Seite die Sprache umstellen und das bleibt dann für die nächsten Aufrufe auch erhalten, allerdings nur bis man das Browserfenster schließt.

Wäre es hier nicht sinnvoll, dass das Tool standardmäßig in deutscher Sprache aufgerufen wird, so wie es bei dem Link für die „Autorschaft“ auch schon gemacht wird?

Falls ja: Die Sprache lässt sich recht einfach per URL-Parameter übergeben. Hierzu müsste lediglich der Code https://pageviews.wmcloud.org/?pages={{FULLPAGENAMEE}}&project=de.wikipedia.org in MediaWiki:Wikimedia-copyright-footer um &uselang=de erweitert werden.

Danke schon mal vorab und liebe Grüße --Guardian of Arcadia (Diskussion) 15:54, 5. Sep. 2026 (CEST)

Dieser Abschnitt kann archiviert werden. --Guardian of Arcadia (Diskussion) 17:09, 5. Sep. 2026 (CEST) (Wurde durch Ameisenigel nach Anfrage auf WP:AA bereits umgesetzt. Sorry für die Störung hier.)