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

2025 2024 2023 2022 2021 2020 2019 2018

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.

Wikipedia:Technik/Skin/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#Hintergrundfarben nach Übernahme von wikitable in core-css.
• 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#Spezial:TopicSubscriptions, 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
• 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
• Special:GlobalContributions -> Spezial:Globale Beiträge
• Spezial:EditRecovery -> Spezial:Bearbeitungswiederherstellung
• Spezial:NamespaceInfo -> Spezial:Namensrauminformationen
• Spezial:RestSandbox -> Spezial:REST-Spielwiese
• Spezial:BlockedExternalDomains
• 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

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/266028669 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)

Infobox unfloat lokal?

Der momentan wirksame Stil für die infobox-Klasse auf Mobilgeräten spielt unnötigerweise auch an Rahmen, Padding, Textgröße und Textausrichtung herum und führt somit dazu, dass die Infoboxen sich mobil immer leicht abweichend verhalten oder gar Elemente, die pixelgenau arbeiten, zerschossen werden. Dies erschwert die Wartbarkeit und führt zu unerwünschtem Verhalten bzw. unpassender Darstellung (Überlauf, Scrollbalken etc.). Da wir inzwischen diese globalen Stile per MediaWiki:Wikimedia-styles-exclude deaktivieren können, wäre zu überlegen, ob es nicht eine lokale Kopie der Regeln geben sollte, die das Floating der Infobox aufheben und es gleichzeitig erlaubt, diese auch bei anderen Elementen, die keine Infoboxen sind, anzuwenden. Könnte dann in ein MediaWiki:Gadget-dewikiCommonResponsive.css o.Ä. ausgelagert werden. -- hgzh 12:58, 2. Mai 2024 (CEST)

Das mag sein; aber bitte nicht Common im Bezeichner.

• Das dewiki zeigt bereits an, dass es site ist.
• „Common“ bedeutet, dass es gemeinschaftlich für alle Desktop-Skins sein soll; genau das ist ja nun überwunden.
• Der umständliche Name passt dann auch nicht in die Linkbox.
• Am liebsten die bisherigen auch einkürzen und verschieben; sind ja nur relativ wenige Seiten zu ändern.

VG --PerfektesChaos 16:13, 3. Mai 2024 (CEST)

Ja, das war nur der erste Schuss. Meinetwegen auch einfach MediaWiki:Gadget-dewikiResponsive.css -- hgzh 21:44, 6. Mai 2024 (CEST)

Work in Progress: BETA -- hgzh 22:52, 6. Mai 2024 (CEST)

Update: Implementierung hier etwas verschoben, weil MediaWiki-seitig derzeit am zentralen Stylesheet geschraubt wird. -- hgzh 09:08, 28. Jun. 2024 (CEST)

Wikipedia:Technik/Skin/Gadgets/dewikiResponsive fehlt dann aber immer noch, so nebenbei bemerkt. Wurde bereits verlinkt.

Kann ja blind und Standard-Gerippe sein; hier wird gesammelt aber noch ist nix da. Immerhin ein Zweck.

VG --PerfektesChaos 14:28, 7. Okt. 2024 (CEST)

Ich weiß, ja, leider muss ich das nochmal komplett durchdenken. Mglw. fällt das auch erstmal ganz flach wegen unkontrollierbarer Nebenwirkungen. Aber ich versuche, das in den nächsten Wochen noch einmal anzugehen. -- hgzh 14:40, 7. Okt. 2024 (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#L-1679 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#abbr_acronym 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)

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 #Einbindung​ 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)

Watchlist-summary-Methodik updaten

Am 21. November wird die laufende SG-Wahl-summary beendet.

Danach sollte die historische MediaWiki:Gadget-watchlistMessage.js nebst Zubehör komplett erneuert werden.

• Es enthält noch das obsolete Protokoll javascript: – das wird aus Sicherheitsgründen jetzt oder perspektivisch nicht mehr unterstützt.
• Es greift in den globalen Variablen-Namensraum ein bzw. könnte aus diesem heraus gestört werden.
• DOM ist letztes Jahrhundert; jQuery ist übersichtlicher und weiterhin Mittel der Wahl.
• Die Lösung mit dem Weiterzählen einer fortlaufenden Nummer und unbedingt merken wie die letzte war fordert hohe Aufmerksamkeit der Admins und ist fehleranfällig. Dabei war das von vornherein überflüssig; ein ISO-Timestamp wäre auch vor 20 Jahren schon gegangen.
• Es gibt jetzt den mittlerweile uns allgemein bekannten ISO-Timestamp von heute, den Admins ohne Verwaltung früherer Codes sofort setzen können.
• Für den Fall mehrerer Meldungen am selben Tag oder einer nachträglichen inhaltlichen Korrektur gibt es Thh:mm zum Ausweichen.
• Das Einflicken in kompliziertes HTML habe ich ersetzt durch eine „Vorlage“ mit robusteren Parametern und ggf. Syntaxcheck. Könnte noch die Hexcodes überprüfen, aber die Farben sind jetzt in der Vorschau sichtbar.
• Auf der Seite MediaWiki:Watchlist-summary ist eine Vorschau auch während der sysop-Bearbeitung sichtbar dargestellt.
• Mehr Barrierefreiheit per role="alert".

Auf BETA zu übertragen, dort nochmals intensiver zu erproben und dann hier zu implementieren wäre gemäß folgender Liste:

Benutzer:PerfektesChaos/Gadget-watchlistMessage.js

MediaWiki:Gadget-watchlistMessage.js

Benutzer:PerfektesChaos/Gadget-watchlistMessage/Box

MediaWiki:Gadget-watchlistMessage/Box

„Vorlage“

Durch Verschiebung ohne WL aus meinem BNR nach MediaWiki: zu übertragen.

Quelltext

Benutzer:PerfektesChaos/Watchlist-summary

MediaWiki:Watchlist-summary

Quelltext

Benutzer:PerfektesChaos/Watchlist-Demo

Nur Simulation.

Nach Abschluss der Übertragung SLA auf die drei verbleibenden BNR-Seiten.

VG --PerfektesChaos 17:44, 21. Nov. 2025 (CET)

Danke erstmal, ist lange nötig. Kannst du die Farbübergabe so anpassen, dass sowohl Hex-Farben als auch CSS-Funktionen übergeben werden kann (Darkmode und so)? Irgendwo meine ich, mal ein Modul dafür gesehen zu haben, aber ich find es grad nicht mehr. -- hgzh 18:38, 26. Nov. 2025 (CET)

Ich hatte durchaus darüber nachgedacht, das aber prinzipiell verworfen.

Die aktualisierenden Admins setzen eine sinnvolle Hintergrundfarbe für ein, zwei Wochen.

• Schriftfarbe ist typischerweise schwarz.
• Wenn jemand im Farbenspektrum mal ein sehr dunkles Grün setzt, das weiße Schriftfarbe erfordet, kann das so geschehen. Kontrast ist gesichert.
• Wenn sich der Inhalt ändert, etwa beim Umschalten von der Kandidatensuche zum Wahlvorgang, soll die Farbe sich deutlich ändern.

Es ist aber nur ein temporäres Design, das ziemlich alle Admins ohne Sonderlehrgang definieren können müssen.

• Es wird jetzt in der Vorschau der Systemnachricht die spätere Wirkung angezeigt; diese obendrein noch mit „CSS-Funktionen“ und Style Sheets und Erprobung Dark plus klassisch macht das kaum noch bedienbar.
• Ich fand das bisherige Gefummel im komplexen HTML schon herausfordernd, und war bemüht, dies durch simple Vorlagenparameter übersichtlicher und robuster zu gestalten; auch durch Check der Parameterwerte. Sechs Hexen bis F lassen sich kontrollieren.

Die gleiche Nachricht muss auf dem schwarzen Smartphone die gleiche Farbkodierung erhalten wie auf dem klassischen Desktop.

VG --PerfektesChaos 19:17, 26. Nov. 2025 (CET)

Bei dem SG-Kandidatensuche ./. -Wahl kam mir übrigens noch die Idee zu zwei weiteren optionalen Vorlagenparametern:

• |Start=
• |Stop=

Beide können mit einem Datum oder Zeitstempel ausgerüstet werden.

• Damit lassen sich Nachrichten definieren, die um Mitternacht oder zu einer sonstigen Zeit starten, und um Mitternacht wieder verschwinden.
• Einen halben Tag vorher kann die Nachricht eingerichtet werden, und einen Tag später kann sie wieder abgeräumt werden; mit zwei Cookies und zwei Farben nahtlos umschaltend, wer sie ein paar Stunden vor Ablauf zum ersten Mal gesehen hatte.
• Muss natürlich möglichst performant implementiert sein.

VG --PerfektesChaos 22:15, 26. Nov. 2025 (CET)

Ich habe es nun übertragen und noch einen Fehler in der Box gefixt. Muss dann noch die Feuerprobe bestehen. -- hgzh 11:19, 31. Jan. 2026 (CET)

Fehler in markAdmins?

Vielleicht bin ich nur zu blöd, doch dieses if kommt mir spanisch vor. Weshalb wird da nur die Hälfte der Variablen überprüft, ohne nachvollziehbares System? @Count Count: hatte das damals eingefügt, entsprechend zur Kenntnis. --MGChecker – (📞| 📝) 16:33, 8. Feb. 2026 (CET)

@MGChecker Wie kommst du darauf, dass das von mir ist? Das ist seit mindestens 2015 im Quelltext, weiter zurück habe ich nicht geschaut. Das ist in der Tat fehlerhaft, spielt aber in der Praxis keine Rolle, da wohl kaum jemand das Skript im eigenen common.js so konfiguriert, dass Admins nicht markiert werden. Ich nehme das komplett raus. --Count Count (Diskussion) 20:16, 8. Feb. 2026 (CET)

Ah, dann wurde es bei deiner Überarbeitung nur deutlich verschoben; in früheren Versionen hatte ich die Phrase nicht gesehen. --MGChecker – (📞| 📝) 20:18, 8. Feb. 2026 (CET)

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)

MediaWiki:Robots.txt content model

Ich hätte gern das content model auf text geändert bekommen.

• Ohne eine Begründung angeben zu wollen, einfach mal so.

Danke im Voraus --PerfektesChaos 17:01, 11. Mär. 2026 (CET)

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-Direct-link-to-Commons.js

Das Helferlein CommonsDirekt funktioniert nicht mehr, siehe Wikipedia:Fragen_zur_Wikipedia#Bilder_werden_nicht_mehr_direkt_mit_Commons_verlinkt. Die letzte Änderung erfolgte hier in de.Wiki 2022, während die Version auf Mediawiki MediaWiki:Gadget-Direct-link-to-Commons.js inzwischen mehrfach geändert wurde, insbesondere diese Änderung sieht wichtig aus. Mir ist noch unklar, warum dieses Problem nicht in en.Wiki auftritt. Werden absolute URLs dort im Gegensatz zu de.Wiki nicht verwendet?

Die Lösung sollte jedoch sein, die Änderungen der Version im Mediawiki geeignet zu übernehmen. Mit meiner common.js habe ich das bereits erfolgreich getestet. --Kallichore (Diskussion) 18:50, 12. Apr. 2026 (CEST)

„Werden absolute URLs dort im Gegensatz zu de.Wiki nicht verwendet“

• In diese Richtung zu denken ist nicht verkehrt.
• Ich habe vor rund einer Woche bei einer anderen Ressource bemerkt, dass mit dem neuen Parsoid die URL kürzer ausfallen.
• Zurzeit sieht die URL einer Dateibeschreibungsseite maßgeblich wie folgt aus:
  <a href="/wiki/Datei:Dingens.svg" class="mw-file-description"><img
• Meiner Erinnerung nach ging das zuvor los mit:
  <a href="https://de.wikipedia.org/wiki/Datei:"
• Grundsätzlich ist es okay, wenn die relativere und kürzere URL ausliefern; der Browser schreibt den Rest wieder mit rein, solange du das HTML-Dokument in einem Online-Fenster hast, wird der Host ergänzt. Wenn das lokal gespeichert wird, ergänzt der Browser hoffentlich den momentanen Host.
• Unser JS verwendet mw.util.getUrl() und ich bin heute abend zu faul und zu müde, das auszuprobieren, meine mich aber zu erinnern, dass das früher https://de.wikipedia.org/w... lieferte.
• Das würde erklären, warum URL nicht erkannt werden.

Ein BOA müsste mal ganz dümmlich ohne diesen ganzen dynamischen Firlefanz reinschreiben und testen:
localBasePath = "/wiki/Datei:"

Sich mit der enWP zu synchronisieren ist nur begrenzt pfiffig, weil wenn ich das richtig verstanden habe, ist bei denen noch kein Parsoid aktiv?

Das Gadget war mal so gedacht, dass es auf allen Wikis wirkt, und deshalb diese lokalen Funktionen benutzt. Aber wenn das pro Wiki von Parsoid abhängt, ist das eh Grütze.

• Man müsste den RegExp mittels (?:...) so formulieren, dass er mit/ohne Protokoll und mit/ohne window.document.location.hostName funktioniert, egal wie Parsoid grad drauf ist.

VG --PerfektesChaos 21:13, 12. Apr. 2026 (CEST)

Ich hab es jetzt mal komplett neu geschrieben.

• Unabhängig von den ausgelieferten relativen URL-Anteilen.
• Robuster, performanter, sicherer, besser gekapselt, übersichtlicher.
• Ressourcen waren nicht dokumentiert und verließen sich auf gadgets-definition, was in anderen Wikis oder bei URL-Einbindung zur Ausführung ggf. noch nicht verfügbar ist.

/// <nowiki> Gadget-Direct-link-to-Commons.js
/// PerfektesChaos@de.wikipedia 2026-04
/* global window: false                                                */
/* jshint forin: false,
          bitwise:true, curly:true, eqeqeq:true, latedef:true,
          laxbreak:true,
          nocomma:true, strict:true, undef:true, unused:true           */
( function ( mw, $ ) {
   "use strict";

   // Gadget globals
   var Paths = { com: [ "//commons.wikimedia.org/wiki/File:",
                        "//commons.wikimedia.org/w/index.php?title=File:"
                      ],
                 upload: "upload\\.wikimedia\\.org/wikipedia/commons/" },
       RE;

   function factory() {
      // Create expensive objects
      var s6    = mw.config.get( "wgFormattedNamespaces" )[ "6" ],
          start = window.document.location.hostname;
      s6    = mw.util.escapeRegExp( s6 )  + ":";
      start = mw.util.escapeRegExp( start );
      start = "^(?:(?:https?:)?//" + start + ")?/";
      RE = { bracket: [ ],
             here:    [ ] };
      RE.bracket[ 0 ] = new RegExp( "\\(", "g" );
      RE.bracket[ 1 ] = new RegExp( "\\)", "g" );
      RE.here[ 0 ]    = new RegExp( start + "wiki/" + s6 );
      RE.here[ 1 ]    = new RegExp( start + "w/index\\.php" +
                                    "\\?title=" + s6 );
      RE.upload       = new RegExp( "^(?:https?:)?//" + Paths.upload );
   }

   function fiat( i, a ) {
      // Process single image element
      //    i  -- sequence number
      //    a  -- DOM element
      var $e = $( a ),
          s;
      if ( ! RE ) {
         factory();
      }
      if ( RE.upload.test( $e.find( "img" ).attr( "src" ) ) ) {
         // Media @ commons
         s = $e.attr( "href" );
         s = s.replace( RE.here[ 0 ], Paths.com[ 0 ] )
              .replace( RE.here[ 1 ], Paths.com[ 1 ] )
              .replace( RE.bracket[ 0 ], "%28" )
              .replace( RE.bracket[ 1 ], "%29" );
         // bracket[]:  prevent false positive XSS detection in NoScript
         $e.attr( "href", s );
      }
   }

   function find( $a ) {
      // DOM ready
      //    $a  -- $content
      $a.find( "a.image, a.mw-file-description" ).each( fiat );
   }

   function fire() {
      // Resources ensured if not by MediaWiki:Gadgets-definition
      if ( ! mw.user.options.get( "multimediaviewer-enable" ) ) {
         mw.hook( "wikipage.content" ).add( find );
      }
   }

   function first() {
      // Autorun on loading
      if ( mw.config.get( "wgNamespaceNumber", 0 )  >=  0 ) {
         mw.loader.using( [ "mediawiki.util",
                            "user.options" ],
                          fire );
      }
   }

   first();
}( window.mediaWiki, window.jQuery ) );
/// EOF </nowiki>   Gadget-Direct-link-to-Commons.js

VG --PerfektesChaos 14:09, 13. Apr. 2026 (CEST)

ja, geht nachher gleich los, BOA-Umsetzung kommt. --Doc Taxon (Diskussion) 11:10, 15. Apr. 2026 (CEST)

Änderung vorgenommen --Doc Taxon (Diskussion) 23:06, 15. Apr. 2026 (CEST)

Special thanks an PerfektesChaos dafür --Doc Taxon (Diskussion) 10:48, 16. Apr. 2026 (CEST)

@Doc Taxon Sorry for not understanding your edit before I made my edit. I responded to a ping in the WP:FZW thread. I tested the gadget on a random article, and it did not work for me, so I assumed the problem was still unsolved after your edit. I realize now that the reason it did not work for me, is that I also have MediaViewer enabled (it is the default. I know that, but I assumed since this gadget is enabled by default, it must do something by default?). I have now confirmed, when I disable MediaViewer, that your version also works.

I recommend my simpler version, because it works with and without MediaViewer. This way, the link is easy to discover and understand (why would someone expect that disabling MediaViewer, will change this link?), for example by hovering the image to anticipate what happens (status bar). Even when MediaViewer is enabled, you can right-click "Open in new tab" to go to Commons directly. This version is from mw:Snippets/Direct imagelinks to Commons, which has been enabled and tested on many wikis, and means future issues are probably fixed for you automatically.

If this difference is important or if you prefer to maintain your own version, feel free to revert my edit! --Krinkle (Diskussion) 16:31, 16. Apr. 2026 (CEST)

FYI @PerfektesChaos --Doc Taxon (Diskussion) 16:49, 16. Apr. 2026 (CEST)

I am living in a world disabling both MediaViewer and CommonsDirect.

• I have no experience with pages running MediaViewer when clicking on an image. Therefore it sounds reasonable to me that the gadget stops execution if clicking the image would start the mediaviewer. However, this does not happen on small icons. I do need to go into details.
• For some reason (I was not involved) a dozen years ago the execution will stop on MediaViewer, and this is communicated on our Special:Preferences and doc page.
• It is meaningful to start both systems by default, since CommonsDirect can react on current MediaViewer state.

@Doc Taxon: Please re-revert now.

• I will analyse the situation during weekend.
• If there is compatibility of MediaViewer and at least small images I will improve our code.
• We have our own features, reacting on complaints.

Greetings --PerfektesChaos 16:49, 16. Apr. 2026 (CEST)

Reverted: no edit war. First discuss changes please. PerfektesChaos, we'll await your weekend. Thanks to all, --Doc Taxon (Diskussion) 17:13, 16. Apr. 2026 (CEST)

First results of investigation:

1. Small icons
   • class="noviewer" is available now. Might not have been present when we excluded MediaViewer.
   • Since at least some images show regular behaviour a general block when MediaViewer is active can be terminated.
2. Interference of regular images with MediaViewer not yet tested.
3. All our gadgets are migrating towards "use strict";
   • The “snippet” is using this which is forbidden in this place.
   • Therefore the snippet is not acceptable.

Regards, --PerfektesChaos 19:27, 16. Apr. 2026 (CEST)

Bin bissl neugierig, warum ist denn this verboten? --Doc Taxon (Diskussion) 19:50, 16. Apr. 2026 (CEST)

mozilla.org VG --PerfektesChaos 21:30, 16. Apr. 2026 (CEST)

Danke, --Doc Taxon (Diskussion) 21:33, 16. Apr. 2026 (CEST)

TL;DR: The dewiki behaviour since 2014 should not be changed here.

• Technical staff should not start unnecessary modifications without community consultation.

There is a certain reason to stay local:

• The environment is still German, and it is still the same project. Not a strange confusing somewhere in web.
• If wide audience is clicking on an image, they get some details about the topic, and learn about license and rights. Less challenging.
• A need to edit the media description is expected from regulars. When reading an article, nobody is urged to curate any metadata.

The default setting creates three four groups:

1. Read-only consumers: MediaViewer for large images, local German for small images.
2. Registered, preferences unchanged: the same.
3. Registered, MediaViewer disabled: Ready to edit Commons media description directly for all images.
4. Registered, both MediaViewer and CommonsDirekt disabled: Faster execution, all images local.

CommonsDirekt is disabled by side effect for the broad audience.

• Therefore they stay on dewiki pages, and they are not supposed to modify anything.

Greetings --PerfektesChaos 13:24, 17. Apr. 2026 (CEST)

Captcha-Hinweis

Die Box unter MediaWiki:Fancycaptcha-edit wird nicht aufgelöst, da sthet sstattdesen der Quelltext. Gruß -- ~2026-20971-53 (Diskussion) 02:11, 14. Apr. 2026 (CEST)