Wikipedia:Technik/Skin/MediaWiki/Änderungen/Archiv/2024

MediaWiki:GrowthMentors.json

Moin,

da Benutzer:CommanderInDubio gesperrt wurde, müsste er aus der Liste ausgetragen werden.

Viele Grüße, --Wandelndes Lexikon (Diskussion • ) 23:07, 20. Mär. 2024 (CET)

@Wandelndes Lexikon danke für die Info. Die Seite wird via Spezial:ManageMentors verwaltet, sowas kann also einfach via WP:AA beantragt werden. Ich bin mir ehrlich auch gar nicht sicher, ob die damit verbundene automatische Neuzuweisung der betreuten User [1] auch erfolgen würde, wenn man MediaWiki:GrowthMentors.json direkt bearbeiten würde. Ist jedenfalls nun von der Liste entfernt [2]. --Johannnes89 (Diskussion) 07:46, 21. Mär. 2024 (CET)
Die Bearbeitung der JSON-Seite können übrigens auch Admins vornehmen, das ist keine exklusive BOA-Aufgabe. Gruß, -- hgzh 07:48, 21. Mär. 2024 (CET)
Archivierung dieses Abschnittes wurde gewünscht von: --Johannnes89 (Diskussion) 07:46, 21. Mär. 2024 (CET)

MediaWiki:Gadget-uploadtools.js

Überarbeitung erforderlich.

  1. Dorthinein die Abfrage auf wgCanonicalSpecialPageName aus bislang MediaWiki:Common.js
    • Optimal erst darauf abfragen, wenn zutreffend dann Funktion f() mit bisheriger Programmierung.
  2. Außerdem das mw,$ richtig kapseln nach allgemeiner Praxis.
  3. wikEd ist window.wikEd
  4. -- wird in [[MediaWiki:Common.js]] eingebunden
  5. if ( false ) { return; } passiert nie.

MediaWiki:Gadgets-definition #Systemgadgets mit namespaces=-1 (Testen!)

Enjoy --PerfektesChaos 15:20, 18. Mär. 2024 (CET)

Wird dann eben komplett auf allen Spezialseiten geladen, aber Special:Upload sollte von -1 schon erfasst sein. Ansonsten schau ich es mir nach dem Wochenende an, wenn keiner sonst möchte. -- hgzh 11:20, 20. Mär. 2024 (CET)
Naja, ich kalkulierte über die Masse der Seitenabrufe und der ausgeführten Statements; und das sind überwiegend ANR-Abrufe aus dem Publikum.
Aber ein dewikiSpecial könnte ich mir vorstellen, nur mit einem switch über wgCanonicalSpecialPageName mit den case Upload und Watchlist und eines Tages vielleicht mal noch einer.
Dabei ggf. nach Mobil und Desktop auswählend; bisher wirkt das ja nur auf Desktop, weiß nicht ob momentan mobil was nutzbar. Wenn keiner mobil dann per skins= zu limitieren.
Die Gadgets generieren dann halt (wie bisher) nur Module, versioniert und komprimiert, mit dependencies. Kann aber weiterhin niemand auswählen.
  • rights mögen dann nochmal ein paar rausfiltern.
  • Spezialseiten können eigentlich ohnhin nicht anders als view angefasst werden.
VG --PerfektesChaos 12:22, 20. Mär. 2024 (CET)
Der Ansatz mit dem Lade-Gadget gefällt mir gut, ich habe dazu mal MediaWiki:Gadget-specialpageLoader.js angelegt. Vorteil ist neben Performance, dass, sollte irgendwann Laden nach CanonicalSpecialPageName möglich sein, die Gadgets ohne weitere Anpassungen direkt aus der Gadgets-Definition geladen werden können.
In dem Zug würde ich MediaWiki:Common.js/watchlist.js mal als watchlistMessage-Gadget registrieren, wenn das Laden aus der Common.js entfällt, ergibt diese Zuordnung keinen Sinn mehr. Die große Überarbeitung kann auch später mal erfolgen. -- hgzh 14:40, 22. Mär. 2024 (CET)
Archivierung dieses Abschnittes wurde gewünscht von: hgzh 08:23, 26. Mär. 2024 (CET)

tableSorterCollation noch benötigt?

bezieht sich auf MediaWiki:Common.js#L-14; dieser Code ist seit über zehn Jahren nahezu unverändert in der Common.js enthalten. 2019 wurde phab:T32674 geschlossen und seitdem auf eine native JS-Funktion zurückgegriffen, die inzwischen von allen Browsern unterstützt wird. Da die Sortierung in der Mobilversion auch ohne diese Zuweisung funktioniert, sollte die Zeile eigentlich entfallen können, oder übersehe ich etwas? -- hgzh 13:46, 17. Mär. 2024 (CET)

Ich weiß nicht, würde ich lieber noch länger ausschleichen lassen.
  • Hinterher beschweren sich wieder irgendwelche Altvorderen oder exotische Browser.
jquery.tablesorter.js wertet das ja noch aus.
Wenn, dann sollte das lieber global beendet werden und auch aus tablesorter eliminiert werden.
  • Kannst du ja auf Phab anregen; dann können die feststellen, dass localeCompare überall unterstützt wird, und es rausnehmen, und dann wird tablesorter schneller.
Aber wennste schon dankenswerterweise grad am Ausmisten bist: Das Statement drunter zu Upload ist mittlerweile per G-D obsolet.
  • Da könnte noch ein namespaces=-1 mit bei.
VG --PerfektesChaos 14:57, 17. Mär. 2024 (CET)
Ich hatte es so verstanden, dass tableSorterCollation weiterhin unterstützt wird, um projektspezifisch die Standards zu überschreiben. Habe aber gerade in einem Dokument gefunden, dass die Standardsortierung ä = ae wäre; dann müsste diese Zeile weiterhin so bleiben und ggf. auch mobil ergänzt werden.
Zu den Uploadtools: die werden in der Gadgets-definition derzeit nur definiert, aber nicht geladen - entweder man spart sich die drei Zeilen in jedem Seitenaufruf oder lädt die Uploadtools auf jeder Spezialseite oder wir bauen noch ein Caller-Gadget drumherum, das die drei Zeilen enthält. -- hgzh 15:16, 17. Mär. 2024 (CET)
Hm, gerade mal auf Benutzer:Hgzh/Temp getestet, sowohl Mobil als auch Desktop mit und ohne Safemode sortieren Hocke - Hof - Hölle, also ö = o -- hgzh 15:28, 17. Mär. 2024 (CET)
Zeile 505 sagt: // Android doesn't support Intl.Collator
  • Weiß nicht, ob das noch aktuell ist. Schon ne Weile drin.
  • Dass die Mainstream-Browser (Desktop-Engines) das können, hatte ich auch schon mitbekommen; und dass du sowas nutzt vermutete ich.
VG --PerfektesChaos 21:19, 17. Mär. 2024 (CET)
Hab das Beispiel gerade auf einem relativ neuen Android-Gerät im Standardbrowser getestet, sortiert wie gewünscht. --XanonymusX (Diskussion) 22:08, 17. Mär. 2024 (CET)
https://caniuse.com/?search=intl.collator listet eigentlich nur noch bei Exoten unbekannte Kompatibilität. -- hgzh 07:46, 18. Mär. 2024 (CET)

Geruhsam ausschleichen lassen, nach folgendem Konzept; rennt nicht weg:

  1. Phab-Ticket zur globalen Eliminierung in jquery.tablesorter.js basteln. Mache ich ggf. irgendwann wenn ich Nerv habe.
  2. Kommentar in MediaWiki:Common.js ändern, Ticketnummer rein, Hinweis auf veraltend.
    • Z25 Beobachtung++s++liste – mehr für Textsuche denn wegen vorbildlicher Rechtschreibung; irritiert trotzdem.
  3. Wenn irgendwann aus jquery.tablesorter.js verschwunden dann sicher auch hier eliminieren.
  4. Wenn irgendwann die ganze MediaWiki:Common.js zum Gadget migriert und endgültig aufgeräumt wird, dann nochmal überdenken ob noch lohnend.
  5. Bis dahin Alt-User nicht mit Neuerungen konfrontieren.

„Habe aber gerade in einem Dokument gefunden, dass die Standardsortierung ä = ae wäre; dann müsste diese Zeile weiterhin so bleiben und ggf. auch mobil ergänzt werden.“

  • Der Sinn war gewesen, dass nicht nach Unicode das ä hinter z sortiert werden würde; was ohne Collation irgendeiner Art in JavaScript passieren würde.
  • Ob das ä nun auf ae oder a abgebildet würde, ist relativ egal.
  • Wir sortieren eigentlich enzyklopädisch (DIN, Methode #1). Also alle diakritischen Zeichen weg. Das ist aber gerade Intl.Collator und global.
  • Die Gleichsetzung ä = ae ist DIN, Methode #2, und gehört zu Telefonbüchern. Also wenn bei Namen unbekannt wäre, ob Möller oder Moeller geschrieben. Dann sollen die Einträge beisammen stehen.
  • Unsere Sort-Vorlagen (Modul) bilden grundsätzlich alle lateinischen Zeichen auf [a-z] ab; also enzyklopädisch, auch bei Personen.

VG --PerfektesChaos 15:14, 18. Mär. 2024 (CET)

Ich habe jetzt mal phab:T361828 aufgesetzt.
  • Bis das resolved und das Feature aus MW entfernt wurde, sollten wir das noch für irgendwelche Altgeräte unterstützen, bis deren Akkus verglüht sind.
  • Action: Im JS-Text diese Task zur Erinnerung hinterlegen.
VG --PerfektesChaos 14:29, 4. Apr. 2024 (CEST)
Habe es eingetragen, damit einstweilen erledigt. -- hgzh 21:56, 17. Apr. 2024 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: hgzh 21:56, 17. Apr. 2024 (CEST)

Skript für Vorlage:Galerie als Gadget auslagern

Passt ja jetzt durch kategoriebasierte Auslösung gut, daher als Abendbeschäftigung: Vorlage:Galerie – Vorlage:Galerie/styles.css – galleryTemplate.js. Gruß, -- hgzh 22:45, 10. Apr. 2024 (CEST)

Schönen Dank erstmal.
Zum Bezeichner:
  • Kategorie:MediaWiki:Gadget/templateGallery hatte ich auch schon.
  • Ich habe allerdings template an den Anfang gestellt, damit bei alphabetischer Aufzählung zukünftiger ähnlicher Gadgets alle derartigen beisammen stehen.
  • Von wegen template:Gallery und so.
  • Englisch ist gut, weil sich vielleicht mal ein anderes Wiki bei uns was kopieren mag.
Zu JavaScript:
  • GALLERY zur Konfiguration ist fein.
  • let/const
    • Die Einheiten sind nicht so unübersichtlich, dass eine Verhinderung des späteren unbeabsichtigten Überschreibens einer Konstante verhindert werden muss; bei drei Statements.
    • var ist ja nicht irgendwie veraltet und obsolet oder deprecated.
    • Sicherheitshalber zwecks Kompatibilität und ungeübter BOA lieber var konventionell.
  • Hypermoderne => schließt Masse konventionellen Pflegepersonals aus.
    • const init = $content => { kapiert niemand.
  • Eine Strukturierung der Funktionen im GALLERY ist hier nicht erforderlich; das wäre bei großer Zahl an Funktionen für L10N. und CONFIG. und RENDER. sinnvoll. Hier eher störend und verwirrend.
    • Herkömmliche lokale Funktionen tun es auch.
    • Haben die Tücke, dass sie in der Reihenfolge so anzuordnen sind, dass sie bei Nutzung bereits bekannt sind. Das wäre über GALLERY. zu umgehen, aber scheint mir hier trivial lösbar.
  • nowiki-jshint-Folklore wie hier bitte noch drumrum.
VG --PerfektesChaos 10:40, 11. Apr. 2024 (CEST)
Die ES6-Syntax verwende ich in Projekten außerhalb der Wikipedia, geht mir inzwischen flüssiger von der Hand als mehrfaches function(). Aber von mir aus. Bzgl. GALLERY hatte ich noch eine Teilung in GALLERY und UNIT überlegt, aber dann nicht weiterverfolgt, kann bei der Kürze wohl entfallen, ja. Erst nach dem Wochenende. -- hgzh 13:54, 12. Apr. 2024 (CEST)
Jetzt hier als MediaWiki:Gadget-templateGallery.js vorhanden, Aktivierung erfolgt die Tage. -- hgzh 19:54, 16. Apr. 2024 (CEST)
Jetzt aktiviert, sieht erstmal gut aus. -- hgzh 21:58, 17. Apr. 2024 (CEST)
Ja, danke.
Solang das var-function nicht offiziell deprecated wird, besser kompatibel mit ollen Browsern und ollen BOA bleiben.
VG --PerfektesChaos 19:25, 24. Apr. 2024 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: hgzh 19:44, 24. Apr. 2024 (CEST)

Gadget-dewikiCategories

Allgemeine Aufgabe: Alles, was spezifisch für den Kat-NR ist.

  • Speziell momentan: Verhindere, dass Infoboxen etc. in den Inhalt von Kategorien hineinragen.
    • Das betrifft auch mobil-Kategorieseiten.
  • namespaces=14
div.mw-category-generated {
   clear: both;
}

Eliminieren aus MediaWiki:Common.css

  • Dabei in den Header reinschreiben: gemeinsamen Desktop-Skin-Anpassungen

VG --PerfektesChaos 19:27, 24. Apr. 2024 (CEST)

Hatte ich schon überlegt, war aber noch unentschlossen, ob das zu atomisiert ist. Und float gibt es mobil ja auch kaum.
.mw-search-interwiki-header könnte man noch über den specialpageLoader auf Spezial:Suche laden, dann wäre wirklich fast alles ausgereizt. Person ist stückweise in Arbeit. -- hgzh 19:49, 24. Apr. 2024 (CEST)
Naja, perspektivisch sollten die MediaWiki:Common.* sowieso nur noch Gnadenhof für allmählich aussterbende Bestandsgeschichten sein.
Also muss eine dauerhafte Lösung für die Brösel gefunden werden.
Endgültig sollte es dann einheitlich unter Gadget- mit Doku und deiner Übersicht zu Systemgadgets wirksam sein, und die MediaWiki:Common.* werden Rotlinks und werden außerhalb des Namensraums archiviert.
Weil, auf ewig zweigleisig fahren bringt es auch nicht, das wäre noch verwirrender.
Und die Systemgadgets-Doku erspart uns die Zweigleisigkeit Mobil-Desktop.
Ein Gadget-dewikiSichtung nur wirksam in den namespaces= Sichtungsnamensräumen wär dann auch noch ein Brösel.
VG --PerfektesChaos 23:02, 24. Apr. 2024 (CEST)
Der Gadgettitel gefällt mir noch nicht so ganz. Zwecks Ausweitung auf weitere Namensräume vielleicht eher MediaWiki:Gadget-ns14 oder MediaWiki:Gadget-nsCategory oder MediaWiki:Gadget-dewikiNsCategory oder MediaWiki:Gadget-ns-Kategorie, falls mal noch Portal, Modul oder so dazukommen sollten. -- hgzh 22:53, 25. Apr. 2024 (CEST)
MediaWiki:Gadget-nsCategory wäre mir auch recht; für andere NR, und vielleicht werden wir eines Tages auch mal Vorbild für andere Wikis. VG --PerfektesChaos 13:38, 26. Apr. 2024 (CEST)
Dann dieses. -- hgzh 13:45, 26. Apr. 2024 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: hgzh 11:35, 7. Mai 2024 (CEST)

Nutzung der MediaWiki:Mobile.css auslaufen lassen

Mit gerrit:1010312, das am Donnerstag aktiv werden sollte, wird MediaWiki:Minerva.css auch im MobileFrontend geladen. Da die langfristige Perspektive gem. phab:T248416 ist, Mobile.css und MediaWiki:Mobile.js (bei uns ohnehin leer) gänzlich zu entfernen, schlage ich in diesem Zuge vor:

Da das recht umfassende Anpassungen sind, bitte ich um ein zweites Durchdenken, falls ich etwas nicht bedacht haben sollte. -- hgzh 12:26, 12. Mär. 2024 (CET)

Die Regel zu skinabhängigen absoluten Positionierungen muss ggf. bleiben oder für die einzelnen Skins anders gelöst werden, wenn sich durch die Auslagerung in ein Gadget die Reihenfolge der Definitionen ändert - bisher überschreiben, die Definitionen der Skins die Ausblendung per Common/Mobile.css. Mglw. ist dann ein !important für die Skin-Definitionen erforderlich, oder es bleibt erst einmal so wie es ist; da ja ohnehin Auslaufmodell. -- hgzh 12:57, 12. Mär. 2024 (CET)
Sieht nach erster Durchsicht korrekt aus, schönen Dank.
Die Bedenken mit den absoluten Positionierungen (meint wohl coordinates–shortcut) habe ich nicht verstanden.
  • Es ist immer genau eine Skin aktiv, eine Kaskade Common→Skin ist nicht erforderlich und damit kein Überschreiben und keine Reihenfolge.
  • Ergo ist der eine einzige Ort mit der wirklich wirksamen Spezifikation die jeweilige Skin.css und wieso ein Gadget (welches?) dafür was anders machen soll sehe ich grad nicht. Im Zweifelsfall wäre ein Gadget skin-abhängig.
Der prettytable-Spaß kann dann bei der Gelegenheit weiter zurückgebaut werden:
  • Im ursprünglichen Sinn wirksam nur noch für .ns-2 (BNR).
  • Parken unter MediaWiki:Gadget-dewikiCommonLayout.css
  • Im WP-NR sowie Portalen kommt das nur noch in zehn Jahre alten archivierten Diskussionen vor. Damit ist das Design dann halt ohne Linien. Pech.
  • Ansonsten nur im Rahmen uralter Diskussionsbeiträge verwendet. Bleibt Tabelle, halt ohne Linien.
  • Der ANR-Spaß mit den fetten roten Linien kann nach einigen Jahren Lernphase entfallen.
Endmaßnahme wäre Archivierung in Technik/Archiv.
VG --PerfektesChaos 17:11, 12. Mär. 2024 (CET)
Die absoluten Positionierungen werden in Common.css L224 ff. aus- und dann je Skin wieder eingeblendet. Anscheinend ist das eine Regelung aus dem Jahr 2006, s. die verlinkte MediaWiki Diskussion:Common.css/Archiv/1#Absolute Positionierungen, möglicherweise vor dem damaligen Hintergrund, dass mehrere Skins neu angeboten worden waren und dann diese immer erstmal mit zerschossenem Inhalt aufwarteten. Kann evtl. heute, wo die Zahl der Skins begrenzt ist, auch entfallen, wäre mir recht.
Prettytable wollte ich eigentlich gern komplett kicken dieses Jahr, uralte BNR-Unterseiten können m.E. auch wie uralte Diskarchive behandelt werden. -- hgzh 17:36, 12. Mär. 2024 (CET)
@absolute: In unserem Krabbelalter gab es auch noch selbstgeschmiedete Skins.
  • Die einzige Wirkung könnte eine generelle Ausblendung heute auf die „App“ haben; da diese jedoch Auslaufmodell und in ihrer technischen Vorgehensweise undokumentiert ist, wird das dann eben am Ort der Einbindung gezeigt. Shortcuts stehen praktisch immer ganz oben; und vielleicht verschiebt daraufhhin jemand Koordinaten an eine geeignetere Stelle.
@prettytable: #Aufschrei!!! – Wir haben in diesen Jahren noch genügend Aufstände der Boomer zu gewärtigen, da müssen wir noch keine BNR-Seiten verstorbener Gründergenerationisten beeinträchtigen. Jetzt erstmal die Uralt-Diskussionen entdekorieren und Reaktion abwarten; irgendwann später mal ganz aus dem globalen Support. Vorlage:Tabellenstile kann immer auf Anforderung tätig werden.
VG --PerfektesChaos 18:27, 12. Mär. 2024 (CET)
Apps: laut mw:Page Content Service werden Koordinaten entfernt - dann nehme ich die Ausblende-Definition mal heraus und warte, ob irgendwo ein Problem auftritt.
Prettytable: na gut, dann endgültig nach Vector-2022- und Koordinatenumstellung. Der Nachtmodus klingelt ja auch schon an. Es bleibt immer was zu tun... -- hgzh 21:45, 12. Mär. 2024 (CET)
@prettytable: Oder gleich ein endgültiges Parken unter MediaWiki:Gadget-prettytableLegacy.css und das nur im namespace=2 einbinden, um der Pietät in Sachen verstorbener Väter und Mütter Genüge zu tun. Kann nach einem halben Jahrhundert Wikipedia dann von unseren Enkeln entsorgt werden. VG --PerfektesChaos 22:35, 12. Mär. 2024 (CET)
Ja, dank inzwischen verfügbarer Namensraumeinschränkung sollte das die beste Lösung sein. -- hgzh 08:22, 13. Mär. 2024 (CET)

Jetzt abgeschlossen. -- hgzh 22:00, 25. Mär. 2024 (CET)

Schönen Dank.
Dann können VG und Disk ja nunmehr ins WP:Technik/Archiv verschoben werden, bevor noch irgendjemand verwirrt wird.
  • ContentModel=wikitext + Wikitext-Kasten mit Kurzerklärung obenauf.
VG --PerfektesChaos 15:28, 2. Apr. 2024 (CEST)
Damit will ich noch warten, bis die beiden Systemnachrichten wirklich nicht mehr wirksam sind (soll wohl so gegen Jahresende passieren). So bleibt der Hinweis erhalten, dort nichts mehr einzufügen, andernfalls käme vielleicht jemand wieder auf den Gedanken und dann hätten wir zwei Versionsgeschichten. -- hgzh 17:20, 2. Apr. 2024 (CEST)
Die Regel zum initialen Ausblenden der absoluten Positionierung habe ich testweise mal entfernt und bisher keine negativen Auswirkungen feststellen können, auch nicht in der Android-App. -- hgzh 19:46, 18. Apr. 2024 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: hgzh 18:36, 25. Jun. 2024 (CEST)

CSS-Variablen

Die neuen CSS-Variablen benötigen dann aber einer neuen zentralen Dokumentationsstruktur als Unterseite /Variablen von WP:CSS wie die anderen:

  1. Wann sie definiert sind und in genau welchem Moment wirken
  2. Wo sie definiert sind und wie sie heißen und was jede einzeln bedeutet

VG --PerfektesChaos 14:08, 26. Apr. 2024 (CEST)

Ja, kümmere ich mich drum. -- hgzh 14:20, 26. Apr. 2024 (CEST)
So, fertig. -- hgzh 17:19, 27. Apr. 2024 (CEST)
Schönen Dank erstmal soweit.
Was ich oben anriss, wurde aber noch nicht geklärt:
  • „und in genau welchem Moment wirken“
  • Bei CSS können kaskadierend Regeln in physisch definierter Abfolge die jeweils zuvor bereits zugewiesenen Regeln überschreiben.
  • Sobald der Browser Zeit hat und festgestellt hat, dass inzwischen eine Reihe weiterer Regeln hinzugekommen ist, werden diese en bloc auf das Dokument angewendet, in der physischen Abfolge.
  • Damit hängt das Resultat immer von der physischen Abfolge ab.
  • Wann genau werden nun diese Variablen definiert?
  • Was passiert, wenn sie erst nach den verwendenden Stil-Anweisungen in der Abfolge stehen?
  • Allgemein würde eine später eintreffende Variablen-Definition eine vorherige überschreiben.
  • In dem Moment, in dem eine CSS-Regel auf das Dokument angewandt wurde, ist diese verbraucht, mit der in diesem Moment gültig gewesenen Variablen-Definition.
Wie stellt das momentane dewiki-Paket die geeignete Reihenfolge sicher?
  • Ggf. sowas wie früher top (also async) oder so?
VG --PerfektesChaos 13:01, 28. Apr. 2024 (CEST)
Was da genau passiert, müsste ich erst recherchieren. Aber die Variablen stehen auch dann zur Verfügung, wenn sie später als der aufrufende Block definiert sind. -- hgzh 09:23, 29. Apr. 2024 (CEST)
Na, dann wären die komplexen Situationen und im zeitlichen Ablauf mal zu klären, sowohl hinsichtlich der expliziten Vorgaben in den Standard-Dokumenten, wie auch hinsichtlich der aktuellen Umsetzung in verbreiteten Browsern.
  • Was passiert, wenn nachträglich erstmals oder überschreibend ein neuer Variablen-Wert für eine verwendende Regel eintrifft?
    • Die bereits angewendeten Regeln verbleiben so wie zu diesem Zeitpunkt angewendet; die Variablen-Zuweisungen wirken erst auf später eintreffende Regeln.
    • Alle Regeln, die diese Variable enthalten, werden erneut auf das Dokument angewendet.
  • Auf welche Weise garantieren wir die beabsichtigte physische Deklaration?
    • Beispiel: Konventionell deklarieren wir Farbwerte für Standard-Hintergrund-Farben. Nun sollen diese nachträglich durch Farbwerte für eine invertierende Darstellung überschrieben werden.
VG --PerfektesChaos 14:06, 29. Apr. 2024 (CEST)
Das generelle Vorgehen ist hier beschrieben und mit Bezug auf die custom properties in diesem Beitrag angeschnitten. CSS-Variablen werden wie normale Attributzuweisungen per Spezifität und Kaskade je Element bestimmt und dann in Schritt vier zum computed value aufgelöst.
Was meinst du mit nachträglich? Innerhalb des gleichen Stylesheets spielt es wie schon gesagt keine Rolle, ob die Deklaration vor oder nach dem verwendeten Selektorblock kommt, weil ganz am Anfang die declared values gesammelt werden und somit zum Auflösen zur Verfügung stehen. Ein später zusätzlich geladenes Stylesheet wird dazu führen, dass die Kaskade neu berechnet wird und somit auch die Variablen neu aufgelöst werden. Das passiert ja auf Ebene der herkömmlichen Attribute genauso. Das Nachladen kann natürlich dann Auswirkungen auf die Darstellung haben, hatte ich auf Wikipedia:Technik/Skin/CSS/Variablen#projektweit verfügbare CSS-Variablen bei fouc angeschnitten.
Wenn die Initialwerte der Hintergrundfarbe-Variablen im :root deklariert sind, ergibt ein Überschreiben für einen Dunkelmodus nur in untergeordneten Elementen Sinn, weil man ja irgendeine Erhöhung der Spezifität braucht, um überhaupt zwischen Hell und Dunkel unterscheiden zu können. Damit ist dann die Reihenfolge wieder egal, weil die Spezifität die anzuwendenden Werte bestimmt. Im Minerva-Skin werden die Initalwerte im :root gesetzt und die Überschreibungen für den Dunkelmodus im spezifischeren html.skin-theme-clientpref-night. Die Reihenfolge würde nur eine Rolle spielen, wenn man die Initialwerte direkt im :root() überschreiben wollen würde, aber ist ja eigentlich kein Anwendungsfall. -- hgzh 22:36, 29. Apr. 2024 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: hgzh 18:36, 25. Jun. 2024 (CEST)

hintergrundfarbe0

Ich rege die Einführung einer hintergrundfarbe0 an. Diese soll den Basis-Seitenhintergrund erhalten, also weiß im Tag- und Dunkelgrau im Nachtmodus, bzw. --background-color-base. Die 0 steht dann sinnbildlich für die Basis- bzw. Ausgangshintergrundfarbe, auf die die anderen Farben aufbauen. Anwendungsfall: in zahlreichen Tabellen und Infoboxen wird mit hintergrundfarbe2 ein weißer Hintergrund eingeführt, weil der standardmäßig hellgraue Ton der Wikitable aus diversen Gründen dort nicht erwünscht ist, ohne dass die Zelle explizit „weiß“ sein soll. Im Dunkelmodus sollte eine entsprechende Formatierung möglich sein. hintergrundfarbe2 sollte explizit weiß bleiben. Es wäre für viele Anwendungsfälle hilfreich, diese Lücke in unserem Standard-Farbkanon zu schließen, auch wenn man dafür eine globale Klasse neu einführen muss. Da es sich aber um eine inzwischen erforderlich gewordene sinnvolle Ergänzung handelt, finde ich das in diesem Fall verkraftbar. -- hgzh 10:09, 22. Mai 2024 (CEST)

Mit der Ziffer 0 bin ich nicht einverstanden.
  • hintergrundfarbe-basis als Bezeichner, aut idem; mal unabhängig vom vorgesehenen Kontext.
  • Das Konzept 1–9 bzw. 1–5 war mal ein Kurzgriff von 2004, als noch niemand ahnen konnte, wie riesig und komplex die ganze Chose eines Tages mal werden würde.
    • Immerhin hatten sie nicht hgf7 genommen.
  • Heutzuge sind hintergrundfarbe-hellrot oder hintergrundfarbe-hellgruen für zukunftsfähige Weiterentwicklungen angesagt.
    • Ließen sich im Sinne von Aliasnamen parallel einführen und allmählich migrieren.
  • Solche Nummern spielen in der gleichen Liga wie die unbenannten Vorlagenparameter, die es allerdings zuerst nur unbenannt gegeben hatte.
Bei ‎MediaWiki:Gadget-dewikiDarkmode.css frage ich mich, wo der Konsens der Autoren sei, dass deWP sowas zukünftig unterstützen und alle Artikel entsprechend umgestalten würde, oder ein Konsens der Techies, dass wir von Füllung mit CSS-Inhalt an auf ewige Zeiten so etwas unterstützen und pflegen werden, und wer genau das machen würde.
VG --PerfektesChaos 14:01, 22. Mai 2024 (CEST)
Nur passt dann die eine hintergrundfarbe-basis nicht zum Rest 1-9, und noch einen langwierigen Migrationsprozess würde ich ungern vom Zaun brechen. In diesem Fall wäre ich dafür, das vorhandene altergebrachte Schema einfach etwas zu ergänzen, und nicht gleich die ganz große Lösung zu suchen.
Das Darkmode-Gadget soll wie bei responsive nur das globale Skript ersetzen, das mit allerlei Kram für andere Wikipedien gefüllt ist – damit eben nicht alle Artikel entsprechend umgestaltet werden müssen. Die Konsensfrage ist hinfällig, der Darkmode wird genauso kommen wie Vector-2022 und davor Vector und der Typography refresh etc. Da lässt sich die WMF schlicht nicht reinreden, wie auch immer man das nun selbst finden mag. Und der Darmode ist von den aufgezählten Änderungen wahrscheinlich noch der mit der größten Akzeptanz. Solche Rückzugsgefechte bringen nichts. -- hgzh 15:19, 22. Mai 2024 (CEST)
Es gibt nichts, das uns zu irgendwas verpflichten würde.
  • Wir sind nicht verpflichtet, das Weltbild von 2004 aus der Situation von 2004 auf ewige Zeiten als das einzig mögliche aufrechtzuerhalten.
    • Alle nach 2004 eingeführten Bezeichner hatten solche Nummerierungen immer vermieden; es gibt keinen Grund, jetzt wieder geistig zwei Jahrzehnte zurückzufallen und erstmals wieder eine solche Taktik zu fahren; aus einer Zeit mit einigen 10.000 Artikeln, mit einigen Bausteinen statt Vorlagen und winziger Projektinfrastruktur und Funktionalität.
    • Das ist eine neue Klasse mit einem Konzept der Welt von 2024, und Bezeichner sind nachhaltig und der Zukunft zugewandt zu vergeben.
  • Wir sind nicht verpflichtet, dass unsere Artikel einen Dark Mode unterstützen müssen.
    • Es fällt auf, dass die Community der deWP von den Befürwortern noch niemals informiert, geschweige denn per MB befragt wurde.
    • Jeder, der das toll findet und ggf. angemeldet ist, kann sich gern seine Oberfläche auf rosa Hintergrund mit grüner Schrift einstellen, wenn das besser gefällt; darf sich aber dann auch nicht beklagen, wenn es grottig aussieht.
    • Jeder kann in seinem Endgerät einen Schlummermodus für alle Webseiten und Apps einstellen, der blau senkt und dimmt, oder Farben wie auch immer umfrickelt, für alle Webseiten; darf sich aber dann auch nicht beklagen.
    • Die WMF teilt mit The team plans to initiate discussions across all wikis – es gab weder ein RfC noch die von der WMF versprochene Beteiligung der Wikis noch hiesige echte projektweite discussions noch eine Entscheidung der hiesigen Autoren, wie mit der Situation und ihren Artikeln umgegangen werden soll. Es sei denn, discussions heißt, ihr könnt ja gern alle rumdiskutieren, wie ihr wollt, aber die WMF setzt mit superprotect durch was sie vorher längst beschlossen hat. Ich sehe aber auch nicht, dass zwingende Einführungen ernsthaft von höheren Ebenen der WMF festgelegt wurden, die gibt ist höchstens bei einer Handvoll von extern eingekaufter Software-Leute, die noch nie ein Wiki von innen gesehen hatten. Bis jetzt gibt es nur Budget für Entwicklungsaufgaben, um zu unterstützen wo und für wen gewünscht.
    • Es ist überhaupt keinerlei unveränderliche Entscheidung getroffen, und nichts ist hier „alternativlos“.
VG --PerfektesChaos 15:44, 22. Mai 2024 (CEST)
Ich möchte nicht Weltbild von 2004 aufrechterhalten und auch nicht geistig zurückfallen, sondern ein System, das nun mal so ist, wie es ist, einmal leicht (!) ergänzen, um auf neu auftretende Anforderungen reagieren zu können. Klar kann man jetzt wieder das große Rad drehen und einen zehnjährigen Migrationsprozess anstoßen, aber ist die Einhaltung des „Dogmas“ den Aufwand wert? Meiner Meinung nach nicht. Eigentlich ist es blöd, wenn wir beide sowas immer allein auskaspern müssen... wenn man sich mal uneinig ist, geht gar nichts voran.
Darkmode: hier ist sowieso niemand zu irgendetwas verpflichtet, auch nicht dazu, alles, was mit Darkmode zu tun hat, als abzulehnende WMF-Bevormundung zu verteufeln. Oder mit deinen Worten: Jeder, der das toll findet, darf per Wikiprinzip darauf hinarbeiten, dass der Darkmode annehmbar funktioniert ;). Nun finde ich den Darkmode nicht toll, aber zumindest halte ich ihn für ein sinnvolles Feature. Wenn wider Erwarten doch der Stecker gezogen werden sollte, so what. Am hellen Modus ändert sich ja dadurch nichts. Gruß, -- hgzh 16:19, 22. Mai 2024 (CEST)
Ich lese das mal als Einladung zum Senfen. Das hier beschriebene Phänomen nehme ich seit Jahren als Problem wahr, vor allem bei Zebra-Tabellen. Auch wenn die Unterstützung eines Dark Modes von unserer Seite nicht perfekt möglich ist, sehe ich darin keinen Anlass, von einzelnen Verbesserungen wie hier beschrieben Abstand zu nehmen, soweit sich die Komplexität in Grenzen hält. --MGChecker – (📞| 📝| Bewertung) 17:49, 22. Mai 2024 (CEST)
+1 zu @Hgzh und zur Aussage von PC: Es fällt auf, dass die Community der deWP von den Befürwortern noch niemals informiert, geschweige denn per MB befragt wurde. Da ich selber den Darkmode nicht brauche, zählen meine 2 Kurierbeiträge zu dem Thema also nicht? Kann ich mit leben. --Raymond Disk. 18:10, 22. Mai 2024 (CEST)
Der Darkmode war 2019, 2022 und 2023 jeweils unter den meist gewünschten Features der globalen Community Wishlist Survey. Da wäre es völlig unzumutbar, nochmal in allen 900 Projekten lokale Abstimmungen durchzuführen (zumal bei solchen Anpassungen eine Abstimmung nur unter Autoren sowieso absurd wäre, weil sie nicht mit einbezieht, dass auch unsere Leser – die nicht mit abstimmen – erheblich profitieren, wenn sie Dark Mode Nutzer sind). Die dewiki Community kann sich wie alle anderen einfach an der globalen Abstimmung beteiligen. --Johannnes89 (Diskussion) 19:03, 22. Mai 2024 (CEST)
@Raymond: Wo genau finde ich mittels Vorlage:Beteiligen einen Aufruf zu einer wirklich projektweiten Erörterung, einer Darstellung, was eigentlich von wem geplant wäre, ob das tatsächlich wie behauptet unvermeidlich und unabwendbar sei, welche Folgen das für bestehende Artikel und die Kenntnisse und Fähigkeiten von Autoren hätte; und wo kam es bisher zu einer Entscheidungsfindung per Umfrage oder MB, ob die deWP-Community das wirklich will oder vielleicht auch nicht? Diejenigen, die etwas Neues haben möchten, sind in der Bringschuld.
@Johannnes89: Der Dark-Mode macht es erforderlich, dass die Gestaltung von Hunderttausender Artikel-Quelltexte der deWP verändert oder in teils absolut nicht-trivialer Weise für sowohl Weiß-Schwarz wie auch farbige Gestaltung umgeschrieben werden müssen, zuzüglich einer vierstelligen Zahl von Vorlagen, ggf. mit dauerhaft veränderter Darstellung und Verkomplizierung.
  • Ob die Autoren der deWP sowas haben möchten, haben sie in der deWP zu entscheiden; danach hat sie aber noch niemals jemand gefragt.
  • Dass irgendwelche Schlichtstrukturen in einer Befragung angeben, dass es toll wäre, wenn die Wikipedien genauso weiß auf schwarz sind, wie sie das von amazon, eBay, Facebook, Google, twiX und YouTube kennen (die nur farblosen Nettotext und intransparente User-Grafiken enthalten), und sie das für wichtig halten, ist ihnen unbenommen. Führungsstärke ist jedoch, nicht gleich jeder Mode hinterherzurennen. Wir sind durch so eine globale Wishlist-Umfrage zu absolut nichts verpflichtet.
  • Bislang gibt es weder eine Analyse, wie viele Seiten und Vorlagen umgeschrieben werden müssen, ob Autoren eine Veränderung ihrer Gestaltung hinnehmen müssten, oder eine Anleitung, aus der zu entnehmen wäre, wie aufwändig die Beibehaltung der momentanen Gestaltung bei gleichwertiger invertierter Darstellung sei, und die für Autoren verständlich deutschsprachig sämtliche auftretenden Situationen und die Lösungsmöglichkeit dazu angibt.
  • Wer schlechte Augen oder andere Probleme damit hat, bedarf einer soweit möglich darauf Rücksicht nehmenden Darstellung, etwa den Verzicht auf starke Schriftverkleinerung wichtiger Informationen, oder hohen Kontrast soweit ohne Einbußen anderweitiger Aspekte möglich. Wer nur ein Smartphone hat, bedarf einer für kleine Bildschirme geeigneten flexiblen Darstellung; über 300.000 userer Artikel wirken dem aktiv entgegen, und die Koordinaten des Artikelgegenstands verschweigen wir gleich komplett. Den Dark Mode muss hingegen überhaupt niemand haben; wem abends der Bildschirm zu grell ist, kann für alle Apps und Webseiten Blau senken, dimmen und auf Schlummern gehen.
VG --PerfektesChaos 15:59, 24. Mai 2024 (CEST)
also... hintergundfarbe0? :) -- hgzh 13:58, 18. Jun. 2024 (CEST)
Bedaure, nein.
Der erste Schritt auf eine lange Reise wird dadurch gemacht, dass ein Fuß in Richtung auf das Ziel gesetzt wird, und nicht nach rückwärts.
VG --PerfektesChaos 14:20, 18. Jun. 2024 (CEST)
So wie es {{Standardfarbe|text|rotlink|mode=dark}} gibt, also den selbsterklärenden Wert rotlink, kann es auch für die -farben blassrot mittelgrau basis blassgrau geben, statt kryptischer 5 und 3 und 7.
VG --PerfektesChaos 14:24, 18. Jun. 2024 (CEST)
Siehe auch:
Wenn du jetzt grad Vorlage:Standardfarbe überall einbaust, könntest du statt 5 ein zukunftsfähigeres hellgrau verwenden, und die 5 als historischen Alias unterstützen, wie Vorlage:Standardbaustein auch.
Nur das hellgruen ist noch ein ungelöstes Problem, wegen Vermeidung von Umlauten, obwohl heutzutage ja eigentlich weniger dramatisch.
VG --PerfektesChaos 15:41, 18. Jun. 2024 (CEST)
hellgrau ist in Dunkelmodus-Zeiten irreführend, da nicht immer hellgrau. Die Farbbenamsung passt da nicht. -- hgzh 10:31, 19. Jun. 2024 (CEST)

In Roberto Sighel #Eisschnelllauf-Weltcup-Platzierungen findest du übrigens eines von vielen Beispielen, wo sich die Autoren seit Jahrzehnten darauf verlassen hatten, dass hintergrundfarbe3 Gold und hintergrundfarbe5 Silber sei, hintergrundfarbe4 dann Bronze.

  • Selbstverständlich darf der Dark Mode aus einer Silbermedaille keine Traueranzeige zwischen Gold und Bronze machen; die silberfarbene = hellgraue Darstellung muss erhalten bleiben.
  • Es gibt auch textliche Bezüge, die dann auf die „hellgrau markierten Tabelleneinträge“ verweisen.
  • Heißt: Auch in Dunkelmodus-Zeiten muss „hellgrau“ immer „hellgrau“ bleiben.

Mal was mit hervorgehoben; weniger deutlich wäre neutral oder standard, aber vielleicht für die Seiten-Grundfarbe oder so.

"hintergrund": [
   {
      "keys": [
         "5",
         "hervorgehoben"
      ],
      "colors": {
         "light": "EAECF0",
         "dark":  "27292D"
      }
   },
   {
      "keys": [
         "7",
         "blassrot"
      ],
      "colors": {
         "light": "FFCBCB"
      }
   },

Effizienter wäre übrigens folgendes JSON mit Aliassen:

"hintergrund": {
    "blassrot": { "colors": { "light": "FFCBCB" } },
    "7":        "blassrot",
    "blassblau":

Nicht sehr performant ist:

for _, block in ipairs( group ) do

Besser wäre mit vorstehenden Aliassen:

local e = group[ key ]
if type( e ) == "string" then
    e = group[ e ]
end
if type( e ) == "table" then
    return true, e.colors
end

VG --PerfektesChaos 15:55, 24. Jun. 2024 (CEST)

Sighel zeigt eben den Zielkonflikt bei einigen der Farbklassen: einerseits wird die Farbe für explizites grau verwendet, andererseits als Imitation der Tabellenkopfhintergrundfarbe. Das hat sich bisher nicht widersprochen, nun aber schon und daher müssen eben die betroffenen Artikel nach und nach angepasst werden (verbreiteter ist für silber im Medaillenkontext übrigens eher silver als CSS-Farbname). Nicht umsonst steht ja einleitend auf Hilfe:Farbe zu den Klassen: Wikipedia-Farbdefinitionen über Klassen (class) haben den Vorteil, dass sie sich den unterschiedlichen Skins anpassen können, also jeweils unterschiedlich sein können. Sie geben Artikeln und anderen Seiten eine ruhige und einheitliche Gestaltung und passen sich sobald erforderlich auch den Skin-Einstellungen des Betrachters an. Und das tun sie eben jetzt.
Zum JSON: überlegenswert, danke. -- hgzh 16:54, 24. Jun. 2024 (CEST)
Zum einen lesen die Autoren nicht vor der Verwendung von Syntaxelementen eine Hilfeseite oder Vorlagendoku, und das Halbsatz für Halbsatz intensiv alle juristischen Folgen reflektierend. Sie übernehmen die Syntax so wie das in anderen Artikeln gemacht wird, und so wie das offensichtlich sauber funktioniert.
Zum anderen ist diese Palette der Hintergrundfarb-Klassen vor zwei Jahrzehnten dafür bestimmt gewesen, um in den hellhäutigen Skins ästhetisch die helle Hintergrundfarbe der Skin und die Klassen optimal um Nuancen aufeinander abzustimmen. Monobook hat bis heute eine etwas gedimmte allgemeine Hintergrundfarbe, CologneBlue oder Chicken waren irgendwie hellbeige oder sowas. Darauf, also auf die Varianten des hellen Hintergrunds, sollten ggf. die Farbschattierungen minimal abgestimmt werden; für einen schwarzen Skin-Hintergrund hat bald zwei Dutzend Jahre lang kaum ein Autor seinen Artikel konstruiert.
Erklär mal einem Autor, warum er die hellgrauen Zeilen mit den Regierungsbezirken zur Gliederung seiner Ortschaften-Tabelle nicht mehr hellgrau nennen darf, obwohl sie glasklar hellgrau sind und immer schon waren.
Seit wann steht das auf der Hilfeseite, und ab wann werden alle Autoren das gelesen und verstanden haben und es umsetzen? Wo ist der Kurier-Artikel? Wo ist die vollständige leichtverständliche Anleitung zur Umstellung des langjährig funktionierenden Artikelbestands?
VG --PerfektesChaos 19:39, 28. Jun. 2024 (CEST)
Eine Überarbeitung von Hilfe:Farbe kommt mit der Einführung der Basis-Hintergrundfarbe. Eine genauere Ausgestaltung von Wikipedia:Dark Mode ist in der Pipeline. -- hgzh 09:48, 1. Jul. 2024 (CEST)

hintergrundfarbe-basis implementiert. -- hgzh 16:46, 17. Jul. 2024 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: hgzh 16:46, 17. Jul. 2024 (CEST)

Häufiges Problem von Neulingen: "Speichern"-Button nicht gefunden

 Info: Kopiert von WP:AN, dort erledigt. --Count Count (Diskussion) 14:31, 8. Jun. 2024 (CEST)

Besteht eine Möglichkeit für Oberflächen-Admins, dagegen etwas zu unternehmen? Am besten konsistent über Quelltexteditor, Visual Editor, Komplett- und Abschnittsbearbeitungen usw. --Prüm ✉ 13:53, 8. Jun. 2024 (CEST)

Naja, egal was jemand bei uns jetzt verändern würde, knallt Zehntausend Alteingesessene vor den Kopp und würde revertiert werden, weil irgendwas nicht mehr wie gewohnt ist.
Außerdem müsstest du bitte konkretisieren, was wo wie anders gelöst werden soll. Es sind nun mal völlig verschiedene Oberflächen und Konstellationen in Desktop-Quelltext, Mobil, VisualEditor.
Ansonsten wüsste ich nicht, worin ein Unterschied bestehen soll zwischen „Komplett- und Abschnittsbearbeitungen“.
VG --PerfektesChaos 14:23, 8. Jun. 2024 (CEST)
Könntest Du das "häufige Problem" mal konkretisieren? Und woher ist das Problem bekannt? Wenn jemand den Speichern-Button tatsächlich nicht findet, kann er ja nicht hier schreiben. Und wenn es wirklich ein Problem ist, worin besteht der konkrete Vorschlag? "Möglichkeit (...),dagegen etwas zu unternehmen" kann ja sehr vieles heißen. -- Perrak (Disk) 14:41, 8. Jun. 2024 (CEST)
Das Problem ist schon x-fach in den WP:FvN ([3], [4], [5], [6]) und anderswo, z.B. zuletzt hier (Lotsenfragen) aufgetreten. Es geht wohl meist um eine konsistente Benennunung und das Problem, dass im BNR "Veröffentlichen" verwirrt. --Prüm ✉ 15:48, 8. Jun. 2024 (CEST)
Wenn es nur um die Button-Beschriftung geht: Sehr vielen Newbies war überhaupt nicht klar gewesen, dass sofort mit einem Klick darauf dieser Text weltweit sichtbar im Internet veröffentlicht wird.
  • Deshalb wurde schon vor etlichen Jahren global dahingehend vereinheitlicht, dass die Beschriftung überall einheitlich Publish / Veröffentlichen lauten soll.
  • Einen "Speichern"-Button wie in der Abschnitts-Überschrift benannt sollte es also überhaupt nicht mehr geben.
  • Mag aber sein, dass das irgendwie noch uneinheitlich übersetzt oder lokal überschrieben wäre. Müsste bei DiscussionTools – VE – Quelltext mal in allerlei Konstellationen überprüft werden.
Der Ausdruck "Speichern"-Button weist auf „knallt Zehntausend Alteingesessene vor den Kopp“ (14:23, 8. Jun.) hin und ist längst veraltete Sprache; mindestens Mentoren müssten sich dann daran gewöhnen, dass der „Veröffentlichen-Button“ heißt.
  • Wer neu anfängt, kann überhaupt nicht wissen, dass der vor einem Jahrzehnt mal "Speichern"-Button geheißen habe.
  • Das Problem ist die Crew von 2005, die nicht akzeptieren will, dass sich irgendwas aus guten Gründen ändert, und es muss immer alles genau so bleiben wie es 2005 mal war, und wenn das 2005 mit „Speichern“ beschriftet war, dann darf das nie mehr verändert werden, weil sonst finden nicht die Newbies von 2024 sondern die Wikifanten von 2005 den "Speichern"-Button nicht mehr.
VG --PerfektesChaos 16:09, 8. Jun. 2024 (CEST)
Nach meinen Erfahrungen im Lotsenprogramm ist dies insbesondere bei Artikelentwürfen im BNR missverständlich, da man meinen könnte, dass mit diesem Button der BNR-Entwurf im ANR veröffentlicht wird. Ist eine Namensraum-spezifische Anpassung möglich? Gruß --NadirSH (Diskussion) 16:14, 8. Jun. 2024 (CEST)
Das wäre noch verwirrender und noch erratischer, und überhaupt nicht mehr verständlich oder nachvollziehbar.
Auch für einen Entwurf im BNR gilt, dass er jetzt sofort weltweit sichtbar im Internet veröffentlicht wurde.
Genau das war vor etwa einem Jahrzehnt der Denkfehler, weil die Newcomer jetzt etwa glaubten, das wäre nur in einem privaten Profil und niemand anders außer ihnen selbst könne das sehen, weil es ja „ihr BNR“ sei.
VG --PerfektesChaos 16:28, 8. Jun. 2024 (CEST)
Dass wissen selbstverständlich die Insider, aber eben nicht jeder Newcomer. Ich verstehe daher deinen Punkt, jedoch nicht deine Schlußfolgerung. Gruß --NadirSH (Diskussion) 16:35, 8. Jun. 2024 (CEST)
Na, dann mal anders: „Wenn du mit deiner Bearbeitung fertig bist, klickst du auf [Veröffentlichen].“ So steht das auf Hilfeseiten zu DiscussionTools – VE – Quelltext, einheitlich für alle.
Jetzt soll (vielleicht nur für Newbies???) geändert werden in „Wenn du mit deiner Bearbeitung fertig bist, klickst du auf [Veröffentlichen], außer, du bist in deinem „eigenen“ BNR, dann klickst du auf [Speichern], aber deine Bearbeitung wird dann trotzdem sofort im gesamten Internet für alle sichtbar.“ – Und das soll eine Vereinfachung sein?
Die Lotsen und Mentoren müssten sich des Problems bewusst sein und einige Punkte bedenken:
  • Es heißt nicht mehr „Speichern“, sondern „Veröffentlichen“; wenn angewiesen wird, man solle einen "Speichern"-Button anklicken, werden Newbies den nicht finden.
  • Anders als bei Facebook ist der BNR kein privater, nicht einsehbarer Bereich, sondern jede Wiki-Seite ist sofort für alle einsehbar. Die Newcomer schleppen Erwartungen und Vorstellungen aus anderen Bereichen ein, und meinen hier wäre das genauso.
  • Das Konzept des BNR und des Artikelentwurfs im BNR und der Unterschied zum ANR muss erklärt werden; Hilfe:Benutzernamensraum sagt das eigentlich explizit und korrekt aus, aber ggf. müsste dort noch weiter präzisiert, verständlicher und abgegrenzt werden.
VG --PerfektesChaos 17:05, 8. Jun. 2024 (CEST)
Okay, das Problem habe ich auch schon gesehen, wenn auch selten. Dass Neulinge denken, Artikel im BNR wären irgendwie privat und nicht allgemein sichtbar habe ich auch erlebt.
Dazu kann ich nur sagen: Wenn jemand solche Probleme hat, ist es gut, wenn er fragt und Hilfe sucht. Eine andere Beschriftung des Buttons würde das Problem durch andere, gravierendere Probleme ersetzen, wie PerfektesChaos auseinandergesetzt hat, die sich vermutlich weniger leicht lösen ließen. Insofern sehe ich da kein Problem, das einer technischen Lösung bedürfte. -- Perrak (Disk) 19:38, 8. Jun. 2024 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: hgzh 16:47, 17. Jul. 2024 (CEST)

Goodbye, Common.css

Die letzten beiden in MediaWiki:Common.css verbliebenen Definitionen können auch noch vermieden werden:

  • Für Spezial:Suche: wenn ich in MediaWiki:Search-summary eine Kategorie einbinde, kann ich ein kategoriebasiertes CSS-Gadget auf der Spezialseite laden, muss nur .catlinks dort zusätzlich ausblenden. Gerade auf Beta getestet, funktioniert.
  • Buchfunkion: kann auch per Config-Schalter ausgeblendet werden, phab-Anfrage sollte mit dem Verweis, dass es seit längerem zentral ausgeblendet ist, kein Problem sein.

Dann kann obiges #MediaWiki:Common.css – allmähliche Verschlankung als abgeschlossen archiviert werden. -- hgzh 09:13, 28. Jun. 2024 (CEST)

Klasse Arbeit, danke! --Raymond Disk. 11:57, 28. Jun. 2024 (CEST)
Ein sechs Jahre währender Migrationsprozess neigt sich dem Ende zu, fein fein.
Ich denke, bis zum Ende des Sommers sollte aller CSS-Code auf Kommentare reduziert worden sein.
  • Dann stünde im Herbst eine WL-freie Verschiebung nach Wikipedia:Technik/Archiv an, mit Disk und VG usw.
  • Das kann dann als ContentModel wikitext Verlinkungen zu der rotlinkenden Systemnachricht (liefert Whatlinkshere) und den „System-Gadgets“ sowie eine Erklärung für die Historie auf der aktuellsten Version enthalten.
  • Das verbleibende Rotlink wird dann irgendwann staunende Nachfragen von BOA anderer Wikis auf FZW auslösen, wo denn unser Common.css abgeblieben wäre. Erklären wir gern.
Der oben genannte Abschnitt kann mit Erledigung archiviert werden; für .js noch ein ähnliches Drama auf der Zielgeraden.
An Aufräumarbeiten bliebe noch, aus den Gadgets dewikiCommon das Common rauszuschieben, weil nach klassischer Interpretation „Common“ ausschließlich Desktop meint, diese Gadgets aber gerade Mobil+Desktop versorgen sollen, und der Bezeichner auch die Linkbox sprengt. Sind ja jeweils nur rund vier Seiten betroffen.
VG --PerfektesChaos 19:30, 28. Jun. 2024 (CEST)
Punkt 1 erledigt, Punkt 2 ist als phab:T368900 gestellt. Vielleicht lade ich den erforderlichen Patch selber hoch, wenn ich Zeit und Nerven finde. -- hgzh 13:16, 1. Jul. 2024 (CEST)
Konfigurationsänderung ist durch. Damit ist die Common.css nun leer. Ich würde sie aber nicht archivieren wollen; wenn irgendjemand mal einen Hotfix oder irgendentwas anderes einträgt und die Seite dann neu anlegt, haben wir zwei Versionsgeschichten. Leer frisst sie ja kein Brot dort, wo sie ist.
dewikiCommon nach dewiki höchstens dann mal, wenn gar nichts mehr zu tun ist, jedes Verschieben bedeutet Duplikation, Warten auf den Cache etc. pp. Ist zu aufwendig für so ein bisschen Namenskosmetik. -- hgzh 17:21, 4. Jul. 2024 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: hgzh 16:46, 17. Jul. 2024 (CEST)
Quelle: https://de.wikipedia.org/wiki/Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen/Archiv/2024