Wikipedia:Technik/Skin/MediaWiki/Änderungen

Änderungen im MediaWiki-Namensraum

---

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

Automatische Archivierung

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

Vorlage:Autoarchiv-Erledigt/Wartung/Festes_Ziel

Archiv

2024 2023 2022 2021 2020 2019 2018

MediaWiki:Common.css – allmähliche Verschlankung

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

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

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

Änderungswünsche

Explizite Vordergrundfarbe für .zebra

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

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

TL;DR: Der Vorschlag ist abzulehnen.

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

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

Momentan verwenden 16.758 Artikel diese Darstellung.

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

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

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

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

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

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

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

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

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

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

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

Ich möchte den Vorschlag, Hintergrundfarben nur zusammen mit Vordergrundfarben zu setzen, auf die hintergrundfarbe{1…9}-Klassen ausweiten. Deren Farben (_ _ _ _ _ _ _ _ _) sind so gewählt, dass sie mit schwarzer Schrift funktionieren, daher sollten allen color: black; hinzugefügt werden. So sind sie derzeit in MW:Common.css definiert (Zeilenumbrüche in Selektoren zur Übersichtlichkeit entfernt):

/* Wie Inhaltsverzeichnis (mediawiki.skinning/content.css) */
table > * > tr.hintergrundfarbe1 > th, table > * > tr > th.hintergrundfarbe1, table.hintergrundfarbe1, .hintergrundfarbe1 {
	background-color: #f8f9fa;
}
/* „Weiß“, für Nicht-Artikel-Seiten, neutral */
table > * > tr.hintergrundfarbe2 > th, table > * > tr > th.hintergrundfarbe2, table.hintergrundfarbe2, .hintergrundfarbe2 {
	background-color: #fff;
}
/* „Gelb“, auffällig */
table > * > tr.hintergrundfarbe3 > th, table > * > tr > th.hintergrundfarbe3, table.hintergrundfarbe3, .hintergrundfarbe3 {
	background-color: #ffff40;
}
/* Sehr auffällig */
table > * > tr.hintergrundfarbe4 > th, table > * > tr > th.hintergrundfarbe4, table.hintergrundfarbe4, .hintergrundfarbe4 {
	background-color: #fa0;
}
/* Neutral, abgesetzt */
table > * > tr.hintergrundfarbe5 > th, table > * > tr > th.hintergrundfarbe5, table.hintergrundfarbe5, .hintergrundfarbe5 {
	background-color: #eaecf0;
}
/* Allgemein „bunt“, für Hervorhebungen und Unterscheidungen */
table > * > tr.hintergrundfarbe6 > th, table > * > tr > th.hintergrundfarbe6, table.hintergrundfarbe6, .hintergrundfarbe6 {
	background-color: #b3b7ff;
}
/* Allgemein „bunt“, für Hervorhebungen und Unterscheidungen */
table > * > tr.hintergrundfarbe7 > th, table > * > tr > th.hintergrundfarbe7, table.hintergrundfarbe7, .hintergrundfarbe7 {
	background-color: #ffcbcb;
}
/* Allgemein „bunt“, für Hervorhebungen und Unterscheidungen */
table > * > tr.hintergrundfarbe8 > th, table > * > tr > th.hintergrundfarbe8, table.hintergrundfarbe8, .hintergrundfarbe8 {
	background-color: #ffebad;
}
/* Allgemein „bunt“, für Hervorhebungen und Unterscheidungen */
table > * > tr.hintergrundfarbe9 > th, table > * > tr > th.hintergrundfarbe9, table.hintergrundfarbe9, .hintergrundfarbe9 {
	background-color: #b9ffc5;
}

Wir können auch gerne explizite Farbangaben für den Dunkelmodus einführen. Das geht mit @media (prefers-color-scheme: dark) {}. Da Safari diese Media-Query schon länger unterstützt, vermute ich, dass dies auch für iOS-Apps gilt. — Christoph Päper 09:00, 26. Okt. 2022 (CEST)

Der „Darkmode“ ist eine Gaga-Idee und erfordert keine Maßnahmen von unserer Seite.

Der „Darkmode“ gehört zu Webseiten, die nur die Farben Weiß, Schwarz und ein wenig Blau kennen, kein benutzerdefiniertes Styling und keine benutzerdefinierte Grafiken mit transparentem Hintergrund haben – also Twitter, Facebook, eBay, Google und so.

Für uns ist das prinzipiell nicht realisierbar, und wir werden auch keine Million Artikel umschreiben, und wir werden auch keine Autoren-Umschulung veranlassen, damit zu den Hunderten von Syntaxregeln und RK und WWNI und WSGA und barrierefreier Gestaltung und Typografie und WP:ZR nun auch noch „Darkmode“-gerechte Artikelgestaltung erlernt werden muss.

Auch mit der vorgeschlagenen Änderung kommt es zu Darstellungsproblemen, schon weil extrem oft statt class style gesetzt ist. Und ebenfalls oft sind Schriftfarben gesetzt.

Wer „Darkmode“ haben will, kann den Blau-Anteil dämpfen und gelber schalten, zum Schlummern. Unsere Artikel waren noch nie für Schwarz-Weiß-Denken konzipiert.

VG --PerfektesChaos 18:07, 29. Nov. 2022 (CET)

Overflow für Musiknoten

Nachdem die Score-Extension mittlerweile glücklicherweise wieder funktioniert, scheint es mir an der Zeit, ein .mw-ext-score { overflow:auto; } zu verordnen. Im Moment ragen längere Notenzeilen auf schmalen Bildschirmen (das können Mobilgeräte, aber auch einfach der neue Vector sein) rechts über den Rand; bei den Desktop-Skins wäre das wohl noch vertretbar (da es im Moment auch noch keine einheitliche Softwarelösung für überbreite Tabellen gibt), aber in Minerva/Mobile ist eine Scroll-Möglichkeit absolut notwendig, sonst verrutscht am Ende der ganze Inhalt. Der Einfachheit halber würde ich vorschlagen, die Anweisung für alle Skins und alle Bildschirmbreiten zu vergeben, schaden kann sie ja nicht. Oder gibt es andere Vorschläge? Ich setze mir das jetzt erst einmal in mein Benutzer-CSS. Gruß --XanonymusX (Diskussion) 15:31, 25. Dez. 2021 (CET)

Wobei, für Desktop müsste man dann auch das display:inline-block deaktivieren, dessen Sinn habe ich noch nicht durchschaut. Eventuell muss die Lösung dann erst einmal auf Minerva/Mobile beschränkt bleiben. --XanonymusX (Diskussion) 15:37, 25. Dez. 2021 (CET)

Warnbox in Common.css aufnehmen

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

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

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

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

Test

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

Naja, das ist so eine Sache.

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

CSS/Selektoren unter MediaWiki#Beispielformatierungen 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)

Neues Gadget: localUserOptions

• Aufgabe: Für zahlreiche Anwendungen LocalStorage einfach verfügbar machen.
• Betrieb: hidden default
• Code: Benutzer:PerfektesChaos/js/localUserOptions.js
• Anwendungen:
  • watchlistMessage
  • Nachfolger unserer Navileisten-Ausblendung mögen ein Gedächtnis bekommen.
  • Zukünftig gäbe es von bestimmten Vorlagen ausgelöste JS-Gadgets, die dann interaktive Elemente einfügen könnten, namentlich Ausblendungs-Schaltzustände usw.
  • Speicherung lokaler Cookie-Zustände, auch wenn alle Cookies bei Browser-Ende gelöscht würden, und Wiederherstellung falls mit leeren Cookies aufgewacht.
  • Vorstellbar wäre auch eine Ausblendung der Rechtsbelehrung bei Quelltext-Bearbeitung für angemeldete auf 7 Tage. Da wäre das Benutzerkonto zu hinterlegen, und nach einer Woche muss die Ausblendung erneut bestätigt werden.
• Besonderheiten:
  • asynchrone Nutzung: Kontakt über mw.hook mit Callback-Funktionen
  • Eingebautes Vergessen; alle Zuweisungen erhalten eine Lebensdauer von maximal etwa 10 Monaten. Das vermeidet Kumulation und Karteileichen bei nicht mehr genutzten Anwendungen.
• Beispiele, in JS-Konsole ausprobierbar:

// Abfrage aktueller Stand, Meldung in Fehlerkonsole
mw.hook( "localUserOptions.fetch" )
  .fire( { sign: "Hello world",
           found: function (a){console.log(a)} } );
// Wertzuweisung; ohne Zeitlimit ergibt 24 Stunden
mw.hook( "localUserOptions.fill" )
  .fire( { _sign_: "Hello world",
           Name:   "Hugo" } );
// Wertzuweisung; mit Zeitlimit 5 Minuten
mw.hook( "localUserOptions.fill" )
  .fire( { _sign_:    "Hello world",
           _minutes_: 5,
           Name:      "Hugo" } );
// Nach zehn Minuten neue Seite aufbauen, Abfrage abschicken, ist dann vergessen.

• Noch’n Feature:
  • Mir fällt soeben auf, dass bei angemeldeten das Benutzerkonto noch an den Identifizierer angehängt werden müsste.
  • Weil mehrere Benutzerkonten könnten sich ein Browserprofil teilen.
  • Nicht angemeldete teilen sich einen Einstellungssatz.

VG --PerfektesChaos 15:29, 31. Jul. 2022 (CEST)

Multi-Account-Code wurde geschrieben, aber noch nie getestet. to be continued VG --PerfektesChaos 17:08, 5. Aug. 2022 (CEST)

Multi-Account-Code wurde kursorisch durchgetestet, scheint alles wie beabsichtigt zu funktionieren, Code a.a.O. einbindbar. VG --PerfektesChaos 17:03, 6. Aug. 2022 (CEST)

Folgendes scheint mir hier relevant zu sein: gerrit:804591 und phab:T121646 - ohne jetzt genauer hingeschaut zu haben, würde das wohl einen selbstgebauten Ablaufmechanismus unnötig machen. -- hgzh 08:01, 17. Aug. 2022 (CEST)

@PerfektesChaos: ich würde das gern mal auf Beta mit dismissableNotice (ex watchlistMessage) erproben. Kann ich mir das nach Beta kopieren? -- hgzh 23:47, 10. Feb. 2023 (CET)

Ich kopiere dir voraussichtlich heute Nacht die aktuellste Version auf BETA:Gadget-.

• Ist ein halbes Jahr her, ich habe alles vergessen.
• Möglicherweise gibt es eine frischere und/oder robustere Version; muss ich mich erstmal einlesen und diffen. Hatte zwischenzeitlich irgendwann irgendwas geändert; weiß nicht mehr wo bereits eingeflossen.

Spoiler-Warnung: Es gibt eine Anwendung, die von sowas Gebrauch machen will. Beschreibung dann hier, wird aber komplex.

Ich habe die MW-Version verglichen und kommuniziert.

• Meines unterscheidet Benutzerkonten + 1×anonym.
• Meines ist robuster bei JSON- und Daten-Fehlern, etwa durch manuelles Eingreifen des Users in seinen Storage oder Fehlfunktion oder Fehlbedienung von Werkzeugen oder Browser-Absturz. Löscht dann möglichst selektiv beschädigte Bereiche.

VG --PerfektesChaos 12:09, 11. Feb. 2023 (CET)

Gut, danke. Die Expiry-Funktion in mw.storage kommt sowieso nicht in Frage, weil die sich ja nur auf einen ganzen Key bezieht, ich ja aber unterschiedliche Ablaufdaten bräuchte. Also hier nicht weiter relevant. -- hgzh 12:40, 11. Feb. 2023 (CET)

Hab grad einen BETA-Blocker von einer Minute auf die andere kassiert. Wird sich erfahrungsgemäß in den nächsten Stunden lösen.

• Gadget kommt dann, gebe Nachricht.
• Ich scheine keine signifikanten Änderungen gemacht zu haben; obiges ist somit aktuell.

„ich ja aber unterschiedliche Ablaufdaten bräuchte“

• Das ist aber bei allen Verfahren das Gleiche.
• Es gibt nur einen key pro automatisches expiry mit diesen Bibliotheksfunktionen.
• Die Methodik wäre eine andere:
  • Entweder komplette Selbstverwaltung in einem Objekt dismissableNotice und selbst erledigte nach Unix-Zeit rauslöschen.
  • Oder jede Nachricht bekommt einen key: dismissableNotice.WiciCon.2023LastCall und der bekäme ein Ablaufdatum; in dem Fall von zwei Wochen und damit Verfall nach Ende der Veranstaltung.
  • Wäre zu klären, was bei mehreren aktuellen Nachrichten passieren solle.
  • Irgendwie war das schon mal im Zusammenhang mit dem modernisierten Gadget erörtert worden; käme ich drauf zurück.

VG --PerfektesChaos 14:35, 12. Feb. 2023 (CET)

BETA ließ mich tagelang nicht rein, zwischenzeitlich schien ganz wmflabs down oder Tools über Stunden nicht erreichbar.

• Dann kamst du aber zum Erproben auch nicht rein; also konnten wir die Angelegenheit auch um einige Tage verschieben.
• Ich habe mir derweil mal ein paar Gedanken gemacht; ganz frisch und ohne nach meinen früher bereits mal ausgearbeiteten Vorstellungen zu gucken.
• BETA live durch JS-Ersteller, noch ohne definition usw.

Anforderungen an unser Gadget:

• Sowohl für watchlist wie für site mit derselben einen Ausführung wirksam.
• Kein FOUC.
• Auch ohne JS nutzbar, selbst wenn deren Apostel gegenüber unserer Kindergartenzeit heute minimal sein dürften.
• Mehrere Banner gleichzeitig aktiv; drei Tage nach dem ersten mag eine dringliche zweite Meldung nötig werden. Wer die erste bereits weggedrückt hate, sieht nur die neue, die anderen dann eben zwei.
• Das mit der unterschiedlichen anonymen SiteNotice hab ich grad nicht restlos durchschaut; müsste präziser definiert und dokumentiert werden. Ggf. von uns andere Methodik zur Definition einer SiteNoticeAngemeldetOnly.
• Volle Mobil-Unterstützung.
• Global (Angebot an andere Wikis).

SiteNotice

• Wir nutzen deren Framework für die Platzierung in der Seite.
• Mobil und Vector2022 sind tückisch.
• Wir machen jedoch deren dynamische Elemente platt, falls unser localStorage wirksam.

MediaWiki:Watchlist-summary

• Bisher nur eine Nachricht; zukünftig mehr.
• Bisher nur mit JS; zukünftig auch nur CSS.
• Bisher dem Namen nach nicht mobil.
• MediaWiki:Common.js/watchlist.js entfällt dann.

Ablauf nach Seitenabruf:

• Pseudo-Name jetzt mal dingens-notice als Arbeitstitel.
• JS aktiv, Laden wird gestartet; wiederholter Code geblockt.
• Herausfinden, ob NSN===8 und wenn ja Titel beginnend mit Gadget-**site** oder Gadget-**watch** (und wenn ja ob Content Model gleich wikitext – aber eigentlich egal). Wenn, dann Schalter Larry=true.
• Bin ich Watchlist? Wenn, dann Schalter ListWatch=true.
• DOM abwarten.
• Nachdem DOM rettich:
  • Wenn Larry dann nach dem MW-Selektor suchen und ein solches Element aus der Seite löschen, anschließend in jedem Fall Ausführung beenden.
  • Gibt es ein Element mit hasClass unserer dingens-notice? Wenn nicht, dann jetzt Ausführung beenden.
• Situation: Es gibt mindestens ein Element mit unserer Klasse in der Seite.
  • Unser localStorage laden.
  • Nachdem eingetroffen:
    • Welche ID sind bereits hinterlegt, falls überhaupt?
    • Ist localStorage schreibbar?
      • Das Limit für localStorage könnte überzogen sein, oder zum Privacy-Schutz blocken manche User und Browser das Hinterlegen verborgener Wiedererkennungs-Codes früherer Seitenbesuche.
    • Wenn es ein Objekt gibt, wird für alle unsere ID in der Seite geprüft, ob es einen Objekt-Eintrag mit booleschem Typ gibt.
      • Wenn es eine bereits bekannte ID gibt, wird dieses Element aus der Seite gelöscht.
    • Wenn es mindestens eine Löschung aus der Seite gab, wird die Ergebnismenge gefundener Elemente unserer Art aktualisiert.
  • Wenn es kein Element mit dieser Objekt-ID in der Seite (watchlist?) gibt, dann diesen Eintrag aus dem Objekt löschen.
  • Wenn es keines unserer Elemente gibt, wird ein MW-site-Block aus der Seite gelöscht.
  • Wenn es hingegen einen MW-site-Block geben sollte, wird (ggf. nach einigen Millisekunden) das MW-Einklappen aus der Seite gelöscht, sofern unser localStorage schreiben kann (sonst alter MW-Cookie-Mechanismus mit ID=99999).
  • In jeden einzelnen unserer Blöcke wird ein Button [Ausblenden] eingefügt und mit click() versehen.
  • Der style für CSS-Ausblenden wird aus der Seite eliminiert.
  • Wenn localStorage schreibbar, dann rechts daneben weiteren Button einfügen: [Erledigt] title="Dauerhaft entfernen"
  • Wenn [Erledigt] angeklickt, dann:
    • Element aus der Seite löschen.
    • Neue ID dem Objekt hinzufügen.
    • Dabei Booleschen Wert je nach Art des Elements:
      • true – watchlist
      • false – site

localStorage-Ökonomie

• Gemäß Algorithmus bleibt der allerletzte Eintrag im Objekt zurück, nachdem der Bannertext administrativ genullt wurde, weil nunmehr nicht mehr ein Element mit unserer Klasse in der Seite vorhanden ist und deshalb unser Gadget nicht mehr geladen wird.
• Das sind mitsamt expiry vielleicht 100 Bytes oder sowas.
• Wurscht. Es geht nur darum, dass die key in der localStorage nicht über mehrere Jahre kumulieren.
• Der key als solches erhält aber ein expiry von 14 oder 30 oder wasweißich Tagen; 14400 Minuten sind zehn Tage.
• Nach dem letzten Erledigt bleibt ein Eintrag noch für zwei Wochen tot stehen und wird dann komplett von der localStorage-Verwaltung entsorgt.
• Nix in 2022.

FOUC

• Früher gab es kein CSS-Fading, was mittlerweile immer erwartet werden darf.
• Es ist heutzutage wohl extrem selten, dass jemand ohne JS arbeitet, aber das müssen einige ganz hartnäcktige sein.
• Ich würde deshalb absolute überdeckende Positionierung statt reinschieben und rausruckeln vorsehen.
• Die Überdeckung passiert 500–1000 ms nach Seitenaufbau, damit JS Zeit bekommt, um unerwünschtes erstes Aufblitzen vor abgeschlossener JS-Ausführung zu vermeiden.
  • Ggf. mit Steigerungsverlauf in den zweiten 500 ms und 10 % verbleibender Transparenz.
• Nach pro Nachricht konfigurierbarem Intervall von 15 bis 60 Sekunden faded sich der Inhalt wieder weg, falls kein JS aktiv ist. Pech. Block das Zeugs halt nicht.
• Die CSS-Eigenschaft transition bietet hinreichende Möglichkeiten, um ein Non-JS ablaufen zu lassen.
• Ggf. wäre ein Reinschieben ohne Überdeckung nach 1 Sekunde realisierbar, aber das kommt in der Community erfahrungsgemäß nicht gut an, weil der bereits zu Lesen begonnene Text vor den Augen abrutscht. Dann besser drüberklatschen, Kenntnisnahme, erledigt.

Objekt-Beispiel, oben Beo:

{ "WikiCon2024LastCall": true,
  "Serverwartung 2023-03-01 15:00": false
}

HTML-Block für Beo, sonst eine class weniger; ID HINTERGRUND RAHMEN INHALT ersetzen, kann man noch opacity-Animation von 0 bis 0.9 verwursten:

<div class="dingens dingens-watchlist"
     style="clear: both; position: absolute; visibility: hidden;"
     data-id="WikiCon2024LastCall">
<div style="background‑color: #HINTERGRUND; border: #RAHMEN 3px solid; border-radius: 4px; opacity: 0.9; transition: visibility 750ms; visibility: visible;">
<div class="dingens-fadeout"
     style="transition: visibility 30s; visibility: hidden;">
INHALT
</div>
</div>
</div>

• Bedarf einer übersichtlichen /Editnotice sowie guter Gadget-Doku.
• JS überschreibt in .dingens-fadeout die visibility mit visible oder löscht auch gleich noch die ganze transition .
• HTML-Code freihändisch ungetestet nur Symbolbild.

VG --PerfektesChaos 12:53, 15. Feb. 2023 (CET)

Ich hab das alles noch nicht so ganz restlos durchdacht und verstanden, aber ich nehme es auf. -- hgzh 18:28, 24. Feb. 2023 (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
• 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
• 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
• Spezial:GraphSandbox -> Spezial:Grafikspielwiese
• Spezial:GadgetUsage] -> Spezial:Statistik zur Nutzung der Helferlein
• Spezial:CreateLocalAccount -> Spezial:Zwangsweise ein lokales Benutzerkonto erstellen
• Spezial:PasswordPolicies -> Spezial:Passwortrichtlinien
• Spezial:BotPasswords -> Spezial:Botpasswörter
• Spezial:AutoblockList -> Spezial:Automatische Sperren
• Spezial:ChangeCredentials -> Spezial:Anmeldeinformationen ändern
• Spezial:RemoveCredentials -> Spezial:Anmeldeinformationen entfernen
• Spezial:PagesWithBadges -> Spezial:Seiten mit Auszeichnungen
• Spezial:EntityUsage -> Spezial:Objektverwendung
• Spezial:LintErrors → Spezial:Lint-Fehler
• Ganz neu: Spezial:Contribute
• neu Februar 2023: Spezial:MyLog

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

MediaWiki:Vector.css coordinates hacks

Hello, apologies fro writing in English.

The following fragment of MediaWiki:Vector.css has caused conflicts with the MediaWiki software several times, most recently in T315700 and previously in T283427:

/*
 * Die folgenden Regeln ändern den Bezugsrahmen für absolut positionierte
 * Elemente von .mw-body-content nach .mw-body und gleichen in diesem Sinne den
 * Vector-Skin an den Monobook-Skin an, um die von dort „bewährte“ Koordinaten-
 * position über der SiteNotice zu ermöglichen.
 * Dies hat schädliche Auswirkungen, unter anderem bewirkt es, dass der Bereich
 * des Moduls „mw.notify“ für „bubbles“ viel zu weit unten angezeigt wird, vgl.
 * [[phab:diffusion/SVEC/browse/master/skinStyles/mediawiki.notification.less]]
 */
.mw-body {
	position: relative;
	z-index: 0; /* [[phab:T40848]] */
}
#bodyContent {
	position: static;
}

I rely on automatic translation to read German, but the code comment seems to also complain about software issues it causes (added by @Entlinkt in 2016: [1]).

I am wondering what would be needed to allow this code to be removed? --Matma Rex (Diskussion) 01:48, 9. Nov. 2022 (CET)

German native speaker here :)

The edit following up to latest comment made the possible negative impact even toned down. Before it said, that phab:T40848 would be impacted more by the rules (I can't access that restricted task myself).

Given the many extensions possibly impacted by setting `z-index` and not be tested in dewiki, I would strongly advise to remove such general layout rule in just this language wiki. The rule might have made more sense in the shift from Monobook to Vector years ago, but I doubt the benefits with most development being based around Vector-first. – Volker E. (WMF) (Diskussion) 02:27, 9. Nov. 2022 (CET)

Hi, it is planned to remove the absolute positioning of coordinates completely, cf. Wikipedia:Meinungsbilder/Darstellung der Seiten-Koordinaten - however, work on this hasn't started yet as it probably requires changes in a lot of articles. Removing the mentioned code earlier would also require changes to the coordinate positioning section following in Vector.css to prevent interferences with lead elements such as infoboxes. Regards, -- hgzh 07:48, 9. Nov. 2022 (CET)

@Volker E. (WMF) phab:T40848 is public now, by the way, if you wanted to know what it was about. --Matma Rex (Diskussion) 01:55, 30. Nov. 2022 (CET)

I think it's possible to keep the current design for coordinates etc. without the problematic styles.

My suggestion is to replace as follows:

Before

After

/* +++++ Anpassungen für absolut positionierte Objekte: [[phab:T40848]] +++++ */ /* * Die folgenden Regeln ändern den Bezugsrahmen für absolut positionierte * Elemente von .mw-body-content nach .mw-body und gleichen in diesem Sinne den * Vector-Skin an den Monobook-Skin an, um die von dort „bewährte“ Koordinaten- * position über der SiteNotice zu ermöglichen. * Dies hat schädliche Auswirkungen, unter anderem bewirkt es, dass der Bereich * des Moduls „mw.notify“ für „bubbles“ viel zu weit unten angezeigt wird, vgl. * [[phab:diffusion/SVEC/browse/master/skinStyles/mediawiki.notification.less]] */ .mw-body { position: relative; z-index: 0; /* [[phab:T40848]] */ } #bodyContent { position: static; } /*m * Koordinaten und diverse andere Anzeigen oben rechts, siehe * [[:Kategorie:Vorlage:mit Seitenindikator#Textelemente]]. * Beachte, dass diese Elemente im Wikitext an beliebigen Stellen auftreten und * deshalb allerhand Eigenschaften erben können. Das gilt insbesondere für die * Schriftgröße. * Der folgende Darstellungsfehler ist bekannt: Wenn die Fensterbreite kleiner * als 982px ist und die Schriftgröße des Wurzelelements wie üblich 16px ist, * überlappen sich die 17px hohen Icons der Gadgets „WikiMiniAtlas“ und * „OpenStreetMap“ mit der SiteNotice. */ #mw-content-text #coordinates, #mw-content-text #editcount, #mw-content-text #shortcut, body.ns-special #mw-content-text .specialpage-helplink { display: block; font-size: x-small; line-height: 1.5; position: absolute; right: 1.6em; text-align: right; text-indent: 0; top: .2em; white-space: nowrap; } @media screen and (min-width: 982px) { #mw-content-text #coordinates, #mw-content-text #editcount, #mw-content-text #shortcut, body.ns-special #mw-content-text .specialpage-helplink { right: 2.4em; } }

/* * Koordinaten und diverse andere Anzeigen oben rechts, siehe * [[:Kategorie:Vorlage:mit Seitenindikator#Textelemente]]. * Beachte, dass diese Elemente im Wikitext an beliebigen Stellen auftreten und * deshalb allerhand Eigenschaften erben können. Das gilt insbesondere für die * Schriftgröße. * Der folgende Darstellungsfehler ist bekannt: Wenn die Fensterbreite kleiner * als 982px ist und die Schriftgröße des Wurzelelements wie üblich 16px ist, * überlappen sich die 17px hohen Icons der Gadgets „WikiMiniAtlas“ und * „OpenStreetMap“ mit der SiteNotice. */ #mw-content-text #coordinates, #mw-content-text #editcount, #mw-content-text #shortcut, body.ns-special #mw-content-text .specialpage-helplink { display: block; font-size: x-small; line-height: 1.5; position: absolute; right: 0; text-align: right; text-indent: 0; top: -9em; white-space: nowrap; } .skin-vector-legacy #mw-content-text #coordinates, .skin-vector-legacy #mw-content-text #editcount, .skin-vector-legacy #mw-content-text #shortcut, body.ns-special.skin-vector-legacy #mw-content-text .specialpage-helplink { top: -7em; }

This places the coordinates in almost exactly the same location (and also corrects the positioning on Vector 2022). Matma Rex (Diskussion) 18:49, 28. Nov. 2022 (CET)

@Matma Rex: Hi, on this page here English is fully okay.

Thanks for your efforts, but we already decided to discontinue CSS hacks and insert regular HTML DOM instead, as soon we are triggered to do so.

Positive reasons:

• Better visibility for persons with bad eyes, typing data into other device.
• Multiple “page coordinates” possible, e.g. city center narrowed and also surroundings with 50 pins of landmarks, or dealing with two relevant locations within one page.
• Longer and unlimited texts, remarks.
• Possibility to offer not only one tool link, but perhaps multiple services for this location.
• Works on App as well.
• Link to “page coordinates” still in top region via <indicator> and giving the classic feeling and functionality.
• Robust solution, no maintenance efforts any longer.

Negative reasons:

• More and more difficult to find sufficient gap on various skins each and mobile etc.
• Out of content clipboard.
• Always afraid to be forced to maintain.
• Not available on mobile interface, out of content clipboard, no predictable gaps.

Greetings --PerfektesChaos 17:55, 29. Nov. 2022 (CET)

@PerfektesChaos I saw the discussion that @hgzh linked above (Wikipedia:Meinungsbilder/Darstellung der Seiten-Koordinaten), and I agree that it would be better to avoid absolute positioning here (one way or another), but if I'm reading it correctly, the vote has been closed in March 2021; it is almost 2023 now, and yet this code is still there. I'd still like to replace the current version with my proposal, even if someone is going to delete it for good soon. --Matma Rex (Diskussion) 19:40, 29. Nov. 2022 (CET)

@Matma Rex your code would change positioning of the link when a CentralNotice is displayed. Not sure if a jumping coordinates link while showing/hiding CNs is a considerable disadvantage and leads to a significant amount of misclicking etc. But I think that is the reason why the current code was originally implemented. -- hgzh 13:05, 30. Nov. 2022 (CET)

@hgzh Thanks, I didn't realize that; but now that I tested it, I think it looks good enough: before, after (testing on [2]). I even like having the coordinates more "connected" with the article. --Matma Rex (Diskussion) 14:44, 30. Nov. 2022 (CET)

So… Would anyone oppose replacing the current styles with my proposal? If no one objects, I will make the changes later this week. (I'm a global interface editor and I can edit the page myself.) --Matma Rex (Diskussion) 19:52, 11. Dez. 2022 (CET)

I'm fine with the change, we'll see if there will be some reactions because of the points I mentioned in my previous statement. Considering the disadvantages the current code has, for me, it seems acceptable. -- hgzh 14:55, 13. Dez. 2022 (CET)

I applied the changes. Matma Rex (Diskussion) 12:01, 15. Dez. 2022 (CET)

Seems like we need a slightly higher y pos moving (10em) for vector-2022, the coordinates are currently unaccessible due to the language switcher. -- hgzh 17:09, 15. Dez. 2022 (CET)

To me it looks fine, where do you see the problem? But overall it is a pretty counterintuitive position for anything related to the article content, so we really should find a better way of dealing with the coordinates soon. --XanonymusX (Diskussion) 17:28, 15. Dez. 2022 (CET)

Ritchie Point, but seems to be Firefox specific, Edge has correct positioning and I guess Chrome too. In Firefox, positioning is correct if there are page indicators. And you're right, we need an alternative solution here. -- hgzh 19:51, 15. Dez. 2022 (CET)

This is very surprising, this only happens on Firefox and only on some pages (e.g. I don't see the issue on Berlin, where I did most of my testing). It seems to be affected somehow by the FlaggedRevs interface? I reverted the change for now, I will figure it out tomorrow. --Matma Rex (Diskussion) 20:37, 15. Dez. 2022 (CET)

I tracked down the browser inconsistency and reported it as https://bugs.chromium.org/p/chromium/issues/detail?id=1401690 (it turns out to be a Chrome bug after all; Firefox's rendering was correct, and my styles only worked correctly on articles with an audio version or good article badge). --Matma Rex (Diskussion) 14:22, 16. Dez. 2022 (CET)

I applied the changes again, with an extra addition to fix this problem. Hopefully everything works correctly this time. Thank you for testing. --Matma Rex (Diskussion) 15:13, 16. Dez. 2022 (CET)

(I also filed T325391 about the previous problem, since it turns out that it also affects several other Wikipedias.) --Matma Rex (Diskussion) 21:02, 16. Dez. 2022 (CET)

Mit Vector-Zebra fliegen uns die Koordinaten wieder um die Ohren, da der vertikale Weißraum zwischen Header und Inhalt reduziert wurde. Einfachster fix wäre wohl, diesen wieder um 1em hochzusetzen. -- hgzh 08:21, 12. Dez. 2023 (CET)

Neues Gadget: CoordinatesPagePopup.js

Hintergrund: laufende Umstellung infolge von Wikipedia:WikiProjekt Georeferenzierung/Migration Seiten-Koordinate 2023 und diverse Anmerkungen und Überlegungen auf Vorlage Diskussion:Hinweis Seiten-Koordinaten.

Anwendungsfall: da die Darstellung der Seitenkoordinaten oben rechts für Desktopnutzer wegfällt und diese in einen entsprechenden Hinweiskasten verschoben werden, ist der Weg zu den Koordinaten etwas länger geworden, was insb. bei häufigem Zugriff auf Koordinaten umständlich ist. Mittels eines Popups soll eine Art Mittelweg zwischen der bisherigen und zukünftigen Darstellung gefunden werden.

Implementierungsdetails: Das Gadget prüft, ob ein entsprechender Indikator und der Hinweiskasten vorhanden sind. Ist beides der Fall, wird der Inhalt aus dem Hinweiskasten in einem Popup gespiegelt, das beim Überfahren des Indikators mit der Maus erscheint. Ein Klick auf den Indikator springt weiterhin zum Hinweiskasten.

Vorbedingungen: innerhalb der Vorlage:CoordinatesPage wäre ein Element hilfreich, dass die im Popup zu spiegelnden Texte enthält. Im gegenwärtigen Zustand funktioniert auch ein rudimentärer Selektor, aber sobald sich da etwa noch der WikiMiniAtlas oder das OSM-Gadget reinhängen, müsste eine saubere Unterscheidung getroffen werden können.

Geplante Aktivierung: default, aber individuell abschaltbar. Skins: alle, außer Minerva. Actions: view.

Code: https://de.wikipedia.beta.wmflabs.org/wiki/Benutzer:Hgzh/CoordinatesPagePopup.js

Gerne Feedback bzw. Review. Gruß, -- hgzh 22:57, 20. Jul. 2023 (CEST)

Bedaure, aber ich möchte nicht, dass dies auf ewig ein von der BOA-Community zu pflegendes Gadget wird.

Gründe:

• Der Personenkreis ist zu eng begrenzt. Es geht letztlich um wenige Hundert Veteranen, die ihr „ich will meine Welt auf immer so behalten wie sie immer schon gewesen ist“ konservieren möchten.
• Die Screengrabbing-Programmierung ist viel zu komplex und damit änderungsanfällig und wartungsaufwändig, als dass das einfach mal so eben auf ewig gepflegt werden kann. Das ist dann eine ewige Hypothek für unsere Enkel.
• Wenn so etwas erstmal als Community-Gadget angeboten wurde, dann fordern die Veteranen, dass die BOA das auf Gedeih und Verderb auf ewig immer irgendwie bereitstellen müssen. Auch wenn es nur noch drei Konten gibt, die das verwenden.
• Für anonyme Konten ist das nichts. Die Trefferquoite (maximal Dreiviertelmillion unter 20 Millionen Seiten) ist viel zu schlecht, um jede Seite erstmal komplett durchsuchen zu müssen. Anonymes Publikum erwartet derartige Angebote dort auch überhaupt nicht.
• Default deshalb auf gar keinen Fall, auch nicht für Angemeldete.
• Das Desktop-Design und das Mobil-Design sollte möglichst analog sein, sofern nichts durch die Platzverhältnisse erzwungen wird. Wenn die MediaWiki-Superhelden endlich mal nach einem Jahrzehnt entscheiden, ob sie die Seitenindikatoren in die obere oder untere Icon-Leiste einfügen möchten, dann können auch die mobilen genau gleichartig die Funktionalität wie beim Desktop bekommen, also Icon-Klick. Die enzyklopädischen Inhalte in jeden Smartphone-Seitenkopf hineinzudreschen wird diesen wohl zersprengen. Enzyklopädische Inhalte gehören in den Inhaltsbereich, die Navigation durch Projekt, Seitenfunktionen und Benutzerkonto gehören in den Portalrahmen.
• Wer nicht zu den Veteranen gehört, erwartet auf keiner Skin derartige weggebeamte Inhalte. Es ist letztlich ein rein psychologisches Problem: Wer erstmal auf diesen uralten Hack angefixt wurde, bekommt Entzugserscheinungen und jammert; wer das noch nie sah, kommt überhaupt nicht auf die Idee, völlig willkürlich sowas zu erwarten und vermisst auch nichts. Die kommenden Generationen brauchen sowas nicht.

Als persönliches Benutzerskript kannst du das ja gern dokumentieren und im Kurier annoncieren.

• Bei einem Benutzerskript steht der Nick des Alleinverantwortlichen zwischen dem ersten Doppelpunkt und dem ersten Schrägstrich.

Inhaltlich schau ich mir den Code gern an, aber brauche unter den momentanen kühlen Nächten etwas, bis ich all das aufgearbeitet habe, was in den Glutwellen liegenblieb. Ich hab pro Tag immer nur wenige Viertelstunden zum Denken.

VG --PerfektesChaos 23:29, 20. Jul. 2023 (CEST)

Ich sehe das anders.

Dass die Koordinaten oben rechts erscheinen, ist seit vielen Jahren und in zahlreichen anderen Sprachversionen so. Das ist ja an sich auch keine blöde Idee, sonst hätte man sich den Aufwand mit dem blöden Hack nicht gemacht, zumindest nicht aus Spaß an der Freude dort irgendwas mit absoluter Positionierung reingedengelt. Schnell nachschauen, wo das Artikelobjekt überhaupt liegt und dann die Einleitung weiterlesen ist nichts, was nur wenige hundert Veteranen machen, sondern ziemlich praktisch. Die Lebensdaten bei Personen stehen ja auch nicht nur in den Personendaten, sondern in der Einleitung dabei (um mal einen zugegeben etwas hinkenden Vergleich zu wählen).

Screengrabbing wird da problematisch, wo wir wenig Kontrolle haben, also bspw. in irgendwelchen MediaWiki-Softwarekomponenten, die sich unbemerkt ändern. Hier greifen wir nur auf eine lokale und ziemlich statische Vorlage zu, über die wir die volle Kontrolle haben. Sicher wird die Zeit kommen, in der mal eine Anpassung nötig werden wird, aber wie oft kam das bei der Koordinatenvorlage vor? Die ist ja immer noch die gleiche wie vor 15 Jahren, weshalb wir diesen Tanz hier ja überhaupt erst tanzen. Und komplex ist das Gadget nun wirklich nicht, immerhin hat es ein in JS relativ unbedarfter Benutzer:Hgzh geschrieben - Anpassungen bekommt man hin. Als Ausgleich könnte ich anbieten, MediaWiki:Gadget-contribsrange.js der Wartung zu entziehen, niemanden hat gestört, dass es bis vor kurzem kaputt war und mit IP-Masking wird es wohl sowieso nicht mehr funktionieren.

Dass ein Leser ein Angebot für Koordinaten oben rechts nicht erwarten würde, nachdem diese 20 Jahre lang dort zu finden waren, würde mich überraschen. Wie oben schon angedeutet, halte ich die Darstellung dort für nicht schlecht, eben nur bisher schlecht gemacht. Der Nutzen überwiegt die Last (900 Bytes minified) für mich. Wo kommen die 20 Millionen Seiten her? Special:Statistik nennt gerade mal 7,7 Mio. Als Default-Gadget läuft es ohnehin nicht Gefahr, nur noch von drei Leutchen genutzt zu werden, es sei denn, der KI übernimmt irgendwann die Ausspielung des wikiweiten Koordinatenwissens ;)

Der Unterschied zwischen Mobil und Desktop wird für mich hier über die Bedienung erzwungen, touch kennt nun mal kein hover; Zustimmung zum Platz - aber wieso nicht die Stärken des jeweiligen Bedienmittels nutzen? Um die Mobilversion geht es ja hier explizit nicht.

Gruß, -- hgzh 16:35, 21. Jul. 2023 (CEST)

Über den Icon (zurzeit nur Desktop, irgendwann auch mobil, anders als dieser Vorschlag) ist die wirksame und kommentierte Verlinkung einen (in Worten: einen) Mausklick entfernt.

Es wird immer so getan, als ob das allerallererste, was irgendjemand machen wird, der auf eine Seite kommt, sich den Längengrad und den Breitengrad anzugucken und dann noch vor dem Lesen des Einleitungsabschnitts die Karte mit der Umgebung aufzurufen.

• Das bezweifele ich allerdringendst.
• Ich sehe auch keinerlei Nachweis, dass dies bei Millionen im Publikum und auch nicht in der Autorenschaft die eine allerwichtigste und dringlichste Aufgabe sei.
• Ich gehe davon aus, dass bei einem von Tausend Artikelbesuchen mal jemand derartige Karten angucken möchte. Es sei denn, es wäre die eine Autorin, die serienmäßig chilenische Bergdörfer neu einbaut. Die hat aber noch gar keine Koordinaten im Artikel zu stehen. Und auch bei einer pflegenden Kontrolle reicht ein einziger Mausklick zusätzlich.
• Der Vorschlag ist ein recht komplexes Gadget, das zwangsläufig bei jedem Besuch der 20 Millionen Wikitext-Seiten und jeglicher Kombination der unendlichen Spezialseiten-Auswertungen gestartet werden müsste. Das ist eine unverhältnismäßige Belastung bei einer Dreiviertelmillion Erfolge beim Finden und einem von 1000 nachfolgenden Kartenbesuchen, nur um einen Mausklick einzusparen.

Es ist eigentlich nur ein psychologisches Problem, das diejenigen haben, die ihr Monobook von 2005 in Ewigkeit genauso wie es immer schon war beibehalten möchten.

• Das sind aber 100 oder 200 Menschen, und werden zwangsläufig weniger werden. Alle die das noch nie sahen oder die Karte ohnehin fast nie angucken wollen vermissen nichts.
• Hätte man damals in allen Artikeln über Personen das Geburts- und Sterbedatum zwischen die Verlinkung von Diskussionsseite und Quelltextbearbeitung gequetscht, dann wäre auch das zum absolut unverzichtbaren Wesenskern aller Wikipedien geworden.
• Nur weil 2004 mal jemand in der enWP eine unverzeihliche Pfuscherei in die Welt gesetzt hatte und alle Wikis das gedankenlos abkopiert hatten, ist es noch lange kein lebensnotwendiges Feature. Die Wikis waren in der ersten Hälfte der Nuller Jahre in der Krabbel- und Selbstfindungsphase; niemand wusste wo das alles enden würde, und jede Bastelei die jetzt erstmal irgendwie funzte wurde halt abkopiert. Gute Techies machen jedoch nicht alles was technisch möglich ist.

Die Hartgesottenen können sowas gern als Benutzerskript installieren.

• Ein neuerliches Angebot durch die Community, das dann bis zum jüngsten Tag am Leben gehalten werden muss, lehne ich strikt ab.

Seit einem Dutzend Jahren haben wir aus sehr guten Gründen kein komplexeres hier entstandenes JavaScript mehr im Konsens und nach Absprache neu in die Community gebracht.

• Alles wird nur noch auf WP:HX angeboten.
• Wir haben noch mangelhaft gepflegtes Community-JavaScript und Schnarks vielgenutzte Bibliothek, die auch an sich ändernde Umstände angepasst werden müsste. Und Common.js usw. müssten ebenfalls saniert, ausgedünnt und modernisiert werden.
• Wir haben noch nicht einmal qualifiziertes Personal, um den Bestand ordentlich zu pflegen. Die meisten BOA stehen nur auf der Liste und können Zeichenketten in markAdmins ersetzen.
• Wir haben absolut keinerlei Kapazitäten, um neue komplexe Community-Funktionalitäten in die Welt zu setzen und dauerhaft zu pflegen.

Jedes Mal, wenn eine der Funktionalitäten von 2004 beendet werden soll, wird Mord und Totschlag angedroht und der sofortige Weltuntergang heraufbeschworen.

• Wir haben überhaupt keine Möglichkeit, eine leichtfertig in die Welt gesetzte und überflüssige Community-Funktionalität wieder zu beenden.
• Schon wenn aus unbenannten Vorlagenparametern benannte werden sollen, wird nach Meinungsbild gebrüllt und das Ende der Autorenarbeit angekündigt, eine weitere Projektmitarbeit wäre damit unmöglich.
• Dabei sind es letztlich nur zwei Dutzend Leutchen, die aber lautstark auftreten, sechsstelligen Editcount haben und seit 2004/2005 dabei sind. Alle anderen Projektinteressen, wie das von 10.000 anderen Wikipedistas, oder gute Performance oder robuste und einfache, wartungsfähige Strukturen sind völlig wurscht.

Wenn die Community bei jeglicher minimalen Veränderung so ein Affentheater aufführt, dann dürfen keine neuen Community-Programmierungen mehr in die Welt gesetzt werden.

VG --PerfektesChaos 17:54, 21. Jul. 2023 (CEST)

Einig werden wir uns diesbezüglich wohl hier nicht. TBC, hab aber gerade keine Zeit dafür. -- hgzh 18:30, 27. Jul. 2023 (CEST)

Vereinheitlichung der DBL-Einträge

Gudn Tach!

Vorgeschichte: Wikipedia:Bots/Anträge_auf_Botflag#2023-10-24_–_CamelBot (und davor WP:AN#MediaWiki:Spam-blacklist_->_Spezial:BlockedExternalDomains).

Zusammenfassung:

• Special:BlockedExternalDomains (kurz DBL für Domain-Blacklist) bietet ist ein neues Admin-Tool, mit dem die WP:SBL entlastet werden soll. Es bietet zwei Felder an: 1. zu blockierende Domain, 2. Bemerkung.
  Am Ende werden die Einträge in MediaWiki:BlockedExternalDomains.json gespeichert, eine Datei die grundsätzlich auch direkt bearbeitet werden kann.
• Es ist im Hinblick auf (automatisierte) Durchsuchbarkeit und Nachvollziehbarkeit sinnvoll, das Bemerkungsfeld mit mehreren Standardinfos (wann, welcher Admin, weshalb = Link auf Diskussion) und einheitlich zu befüllen.
• Das UI ist sehr spartanisch und führt leicht zu uneinheitlichen und unvollständigen Einträgen, wie man bereits an anderen Sprachversionen sieht, z.B. en:Special:BlockedExternalDomains.

Denkbare Lösungen:

• (Ein Bot könnte die Einträge automatisiert postprozessieren. Nachteile: 1. Es ist schwierig, einem Bot das Recht zu geben, die json-Datei zu bearbeiten; 2. Man ist abhängig von nicht in der Wikipedia gehostetem Code.)
• Per JS könnte man das Bemerkungsfeld vorausfüllen lassen. Beispielhaftes Script: user:Lustiger_seth/admin_stuff.js. Nachteile: 1. Alle Admins, die mal die DBL bearbeiten wollen, müsste vorher das Script aktivieren oder jemand kümmert sich um die manuelle Nacharbeit des json-Files.
• PerfektesChaos schlug ein Community-Gadget vor, das ans Recht editsitejson geknüpft wäre. Nachteil: Irgendwer müsste es erstellen oder zumindest ein Grundgerüst, in das dann der eigentliche Code eingefügt wird (wobei der o.g. Code wohl noch nicht die Qualitätsrichtlinien erfüllt).

Wegen des letzten Lösungsvorschlags bin ich hier. Verstehe ich es richtig, dass das Gadget dann automatisch bei allen Admins aktiv wäre? (Fänd ich sinnvoll.) -- seth (Diskussion) 20:04, 4. Nov. 2023 (CET)

Also prinzipiell habe ich, wie schon gesagt, nichts dagegen.

Ein Gadget anzulegen ist nicht weiter schwierig, hier wäre es etwa MediaWiki:Gadget-domainBlacklist.js inkl. der erforderlichen Einbindung in MediaWiki:Gadgets-definition. Dort kann man festlegen, dass das Gadget nur für Nutzer mit editsitejson-Recht, nur auf Spezialseiten geladen, standardmäßig aktiv, deaktivierbar werden soll. -- hgzh 20:21, 7. Nov. 2023 (CET)

Gudn Tach!

Ok, danke für die Hinweise. Zum Verständnis ein paar Fragen:

• MediaWiki:Gadget-domainBlacklist.js kann ich erstellen, ohne dass das etwas am Verhalten der Software ändert, richtig?
• Erst Änderungen an der MediaWiki:Gadgets-definition können das Script aktivieren bzw. schlimmstenfalls irgendwas kaputt machen, oder?
• Soll ich schon mal den vorgeschlagenen Code in das JS-File packen, sodass man ihn anschließend überarbeiten kann?
• Der Eintrag in der Definition wäre am Ende folgender?

domainBlacklist[ResourceLoader|default|hidden|namespaces=-1|rights=editsitejson|dependencies=mediawiki.config,mediawiki.user]|domainBlacklist.js

• Kann man ein solches automatisch aktiviertes Script überhaupt irgendwie (z.B. per JS) deaktivieren bzw. persönlich für sich überschreiben? Oder geht das nur, wenn hidden nicht gesetzt ist (und dann einfach übers Web-Interface)?

-- seth (Diskussion) 23:39, 7. Nov. 2023 (CET)

Das Gadget wird erst geladen, wenn es auf der Definitionsseite eingetragen ist, aber damit würde ich erst noch warten. Die JS-Seite kannst du von mir aus schon anlegen. In der Definition würde ich hidden weglassen, damit es über die Einstellungen deaktivierbar ist. Anzulegen wäre damit auch MediaWiki:Gadget-domainBlacklist, das die Kurzbeschreibung enthält und auch Wikipedia:Technik/Skin/Gadgets/domainBlacklist mit ausführlicherer Beschreibung, was das Gadget tut. Das kann aber nachgeordnet passieren. Dependency mediawiki.config dürfte nicht erforderlich sein.

Den Code schau ich mir später nochmal genauer an bzw. würde ihn dann direkt auf der Gadgetseite bearbeiten, spontan springt mich const an, das als ES6-Element zwar in Userskripten, aber nicht in Gadgets funktionieren dürfte. Geht mit requiresES6 in der Gadget-Definition. Gruß, -- hgzh 07:39, 8. Nov. 2023 (CET)

• Ich würde aus perspektivischen Planungsgründen eine längere ID verwenden, um für die Zukunft weitere Optionen offenzuhalten: Gadget-domainBlacklistSpecial
• Ich empfehle, zuerst im BNR die Kinderkrankheiten zu beseitigen, und als allererste Version in MediaWiki: einen vorbildlichen Code der Nachwelt zu überliefern.
  • const war mir auch schon aufgefallen, aus demselben Grund, und dient zur Verhinderung irrtümlichen Überschreibens in den weiteren Hunderten Programmzeilen. Bei momentan drei Statements eher nicht zu befürchten.
  • Ich kann im Lauf des Tages eine Meckerliste zuliefern.

VG --PerfektesChaos 08:39, 8. Nov. 2023 (CET)

zur namensgebung bitte überlegen ob nicht Block statt Black besser benutzt werden sollte:

• es gibt bedenken bezüglich blacklist siehe T337431 und T254646
  Gemeldet in Phabricator
  Task T337431
  Gemeldet in Phabricator
  Task T254646
• dann wäre es auch konsistent zum namen der neuen spezialseite (die ja perspektivisch an bedeutung gegenüber der alten lösung gewinnen wird)

--Wetterwolke (Diskussion) 14:13, 8. Nov. 2023 (CET)

Wie angedroht:

• Bezeichner:
  • Dann SpecialDBL und dann ist wurscht was das „B“ bedeuten mag und der Bezeichner ist kürzer.
  • Gadget zu einer Spezialseite halt, die mit dem DBL.
  • „DBL“ ist dann das Nachfolgesystem zu SBL (WP:SBL), und während S=„Spam“ Litspam und Linkspam sein mag, geht es hier präziser um spammende URL-Domains.
  • Das „Datenbanklink“ aus den schNuller-Jahren bekommt mal eine konkurrierende Interpretation des DBL. WP:DBL müsste leergeräumt werden, H:DBL bliebe. WP:DBL hätte 40 Bot-mäßig umbiegbare Einträge und mag dann neu belegt werden.
• Leerzeichen
  • In allen Welten unstrittig sind bestimmte Leerzeichen, um als Mensch gut zu erfassen.
  • Definitiv nicht: $(function (){ (zwei Leerzeichen fehlen), if(mw.config.get ist bäh.
  • mw:Manual:Coding conventions/JavaScript #Whitespace
    • Mit den Tabs bin ich nicht einverstanden; mal als acht Zeichen und die dritte oder vierte Schachtelung jenseits von Gut und Böse; mal generiert die Darstellung drei oder vier oder zwei Zeichen, und das wird uneinheitlich bei Fortsetzungszeilen.
    • Das Line breaking dort ist teils ungebräuchlich und riecht nach Privatgeschmack, wird von den MW-devs wohl auch flächendeckend ignoriert.
• Validator
  • MW verwendet https://eslint.org/
  • Wir traditionell https://jshint.com/
  • Egal wie; es muss ohne vermeidbare Meldungen herauskommen.
• const war bereits thematisiert und beantwortet.
  • var reicht hier.
  • Ich würde allen Symbolen zu Beginn der Funktion entweder die Werte zuweisen oder zumindest ihre Namen mit Komma aufzählen.
• getName() == 'Lustiger
  • String-Vergleich mit ===
• mw.user ist nicht notwendigerweise zu Beginn geladen; müsste korrekterweise zur Vermeidung einer race condition mit mw.loader.using() erst synchronisiert werden.
  • Wobei das in der Praxis bei $() vermutlich schon passiert wäre; ist trotzdem sehr unsauber.
  • wgUserName in mw.config.get() ist hingegen sofort (vorher) vorhanden.
• Kapselung von allem gegen global und Schnittstelle für die Aliasse mw und $ über die längeren und weniger schnell abgeschossenen Symbole mediaWiki sowie jQuery; ggf. auch im globalen Objekt des Browsers verankert weil ohne Browser dieses JS nicht ausführbar ist.
• Siehe zu allem vorstehend: en:user:PerfektesChaos/js
• Vorkehrung, falls Skript durch anonym geladen; sogar im Kontext der Spezialseite (die alle angucken dürfen aber nichts ausfüllen können).
• Komplexe Ausdrücke einmalig berechnen und speichernd hinterlegen.
  • mw.user.getName()
    Doppelt ausgewertet.
    • sysop = mw.config.get( "wgUserName" );
  • new Date()
    Doppelt ausgewertet.
    • now = new Date();
• () * 60 * 1000).toISOString().slice(0, 16).replace(/T/, ' ')
  • Das sieht ja arg kompliziert aus.
  • Was genau soll die Multipliziererei bewirken?
  • .toISOString() liefert 2011-10-05T14:48:00.000Z und da wäre
    stamp = now.toISOString();
stamp = stamp.slice( 0, 10 ) + " " + stamp.slice( 11, 15 ) + ":00Z";
    wenn ich richtig verstehe was du vorhast.
• document.getElementsByName
  • C&P-Klau-Mischung von DOM vor 2010 und jQuery als $.
  • Wir schreiben seit 2010 einheitlich in jQuery.
• Nicks umschreiben:

switch ( sysop ) {
   case "Hgzh" :
      sysop = sysop.slice( 0, 0 ).toLowerCase()  +
              sysop.slice( 1 );
      break;
   case "Lustiger seth" :
      sysop = "lustiger_seth";
      break;
}   // switch sysop

• Resultat mit Vorkehrung für Feldeinteilung: stamp + " @ " + sysop + " @ "
• Alle vorstehenden Code-Beispiele freihändig ungetestet.

VG --PerfektesChaos 15:26, 8. Nov. 2023 (CET)

Das kann man ja nicht mit ansehn: BETA

Übernahme bitte per XML-Import. Danke.

VG --PerfektesChaos 12:12, 9. Nov. 2023 (CET)

Gudn Tach!

Oh, wow, vielen Dank für Zeit und Aufwand!

• Die Multiplikation war nur drin, um Zeitzonen zu berücksichtigen, aber UTC finde ich eh besser (und hatte es ja im Original-Code auch schon vorbereitet), insofern: passt!
• Den Eventhandler hast du absichtlich entfernt?
• Wenn ich auf Special:Import keine XML-Auswahl sehe, liegt das vermutlich an fehlenden Import-Rechten, richtig? @user:Doc Taxon: Du bist Interface-Admin und hast Import-Rechte. Würdest du die von PerfektesChaos in Beta angelegte Seite hierher umziehen?

-- seth (Diskussion) 01:04, 10. Nov. 2023 (CET)

„Den Eventhandler hast du absichtlich entfernt?“

• ????
• Wenn du $(fill) meinst: Das ist das letzte ausführbare Statement.
• Ich mag keine umfangreichen anonymen Funktionen, die als Parameter in irgendwas reingequetscht werden.
• Weil ja jetzt gekapselt, bin ich auf die Anonymität nicht mehr angewiesen und könnte für die Kapsel ggf. auch Konfigurationsparameter wie den Feldbezeichner separat definieren.

VG --PerfektesChaos 09:30, 10. Nov. 2023 (CET)

Gudn Tach!

• Die Fragezeichen interpretiere ich als "Wovon redest du?". Ich meine die Zeilen 15 bis 18 in user:Lustiger_seth/admin_stuff.js, durch die auf einen Abschnitt in WP:SBL verwiesen wird (was natürlich manuell bearbeitet werden kann, aber idealerweise meistens einfach so zutrifft, siehe bisherige Einträge).
• Problematisch ist unabhängig von einem Automatismus allerdings noch, dass die Diskussionsabschnitte ja irgendwann archiviert werden. Vielleicht also eher Permalinks? Die sind nur leider immer so hässlich und lang.
• Denkbar wäre ansonsten, aber das sprengt vielleicht den Rahmen der hiesigen Diskussion, dass man für die Domains Unterseiten anlegt, also statt WP:SBL#example.org eher WP:SBL/example.org oder sogar (in Anlehnung an eine Idee von dir, die bald ihr 10-jähriges Jubiläum feiert): WD:Weblinks/Blockiert/example.org, dann wären wir auch von der Technik (SBL/DBL/FILT) und von Jahreszahlen unabhängig.

-- seth (Diskussion) 02:57, 11. Nov. 2023 (CET)

Eventhandler

• Der einzige Eventhandler hier beginnt jeweils mit: $(f
• Er gehört zum Event „onDOMready“.
• Die Funktion wird ausgeführt, nachdem die Elemente des HTML vollständig in das DOM überführt worden sind.
• „Eventhandler“ ist ein Fachausdruck der HTML-Script-Technologie.

Zeilen 15 bis 18

• Das meint wohl was mit: [[WP:SBL#
• Das hatte ich weggelassen, weil funktionslos; zumindest so wie es da steht.
• Das Gadget wird ausgeführt, sobald die Seite geladen worden ist (onDOMready).
• Zu diesem Zeitpunkt sind die Formularfelder leer. Es sei denn, irgendwer tippt in 1/10000 Sekunde die Domain ein.
• wpDomain ist deshalb immer leer.
• Du hattest vermutlich bei bereits geladener Spezialseite und schon ausgefülltem Formularfeld das Script manuell gestartet.

Vorbelegung des Kommentars anhand der eingegebenen Domain

• Dazu müsste man den Submit-Button kapern.
• Geht am einfachsten, indem er aus dem HTML-Dokument gelöscht und durch einen eigenen Button ersetzt wird.
• Der eigene Button wird mit einer Funktion verknüpft, die die beiden fertig ausgefüllten wpDomain und wpNotes analysiert und verwurstet.
• Diese ändert ggf. den Feldinhalt wpNotes.
• Kann natürlich noch einen Syntaxcheck für wpDomain machen.
• Danach löst sie das HTML-Event „SubmitForm“ aus.

Vorbelegung des Kommentars zum Selbstausfüllen

• Dazu wäre nach XML-Import mein Code an zwei Stellen zu ergänzen:
• Im „Modul“-Kopf bei var Env eine Konfigurationsvariable: var Story = "[[WP:Weblinks/Block///]]";
• Unten nach letzter stamp-Zuweisung:

if ( Story ) {
   stamp = stamp + " " + Story;
}

• Man gliedert solche Text-Zuweisungen an den Kopf der Module aus, damit spätere Anpassungen und Wikilinkfixe durch Dritte ohne langes Rätselraten ermöglicht werden.
• Genauso könnten die beiden Feldnamen hinterlegt werden; aber die dürften erstmal stabil sein, und wenn sich die Struktur und Logik der Spezialseite fundamental ändern, dann wird das nicht mit Anpassung von zwei ID getan sein.

Organisation zukünftiger Projektseiten

• Das entgleitet dem Scope dieser Seite hier.
• Grundsätzlich ist eine von Werkzeugen und Methoden unabhängige Dokumentation der problematischen Domains der momentanen Struktur vorzuziehen.
  • Eine Anbindung als Unterseite von WP:Weblinks bietet maximale Auffindbarkeit; die „Defekten“ leben auch bereits dort.
  • WP:Weblinks/Block ist deutsch-englisch und vemeidet „black“.
• Die Unterseiten würde ich reverse-domain organisieren.
  • Also gauner.example.com unter WP:Weblinks/Block/com/example/gauner in individuell beliebiger Schachtelungstiefe; je nachdem wieweit die zusammengehören.
  • Siehe Anordnung in Wikipedia:Technik/Netzwerk/Domains.

VG --PerfektesChaos 10:30, 11. Nov. 2023 (CET)

Gudn Tach!

• Nee, ich hab nix manuell gestartet. Die Zeilen sorgen (zumindest unter Firefox, aber ich dachte, der Code sei weitgehend Browser-unabhängig) dafür, dass wenn man ins obere Feld irgendwas einträgt, dynamisch das zweite Feld befüllt wird und man idealerweise gar nix mehr dort zu ändern braucht (es aber kann!).
• Das heißt: schreibe ich ins obere Feld example.org, dann steht unten bereits 2023-11-11 14:55 lustiger_seth: [[WP:SBL#example.org]].
• Eine Submit-Button-Modifikation braucht's da nicht. Oder wir reden von unterschiedlichen Dingen.
• Organisation: Ja, bereden wir besser unter MediaWiki_Diskussion:Spam-blacklist#Restrukturierung_2023.

-- seth (Diskussion) 15:01, 11. Nov. 2023 (CET)

• Ich hatte deine .js-Version vom 21. im Browser-Tab und die Version vom 28. nicht mitbekommen, mein Code basierte dann darauf.
• XML-Import ist damit erstmal hinfällig.
• Deine Version vom 28. ist aber trotzdem nicht bedienbar.
  • Wenn jemand im Domain-Feld etwas nachbessert, vielleicht eine Subdomain einschränkend hinzugefügt oder eine voranstellt, dann wird das Notes-Feld gnadenlos überschrieben.
  • Wenn man jedoch zwischenzeitlich an das Notes-Feld noch eine Bemerkung dranschrieb, dann ist die hiermit gelöscht.
  • Davon kann ich aber nichts mitbekommen, weil der Text aus Zeitstempel und Nick so lang ist, dass ich das Ende mit meiner Bemerkung nicht mehr sehen kann, und auch nicht mit diesem Verhalten rechne.
• Das wäre anders zu realisieren:
  1. HTML-Submit-button verstecken.
  2. Eigenen Button an gleicher Stelle hinzufügen; gleiche Beschriftung plus ein <sup>*</sup>.
  3. Wenn angeklickt, dann folgenden Handler aufrufen:
     • Domain trimmen und lowercasen und normalisierten Wert in das Domain-Feld eintragen.
     • Notes trimmen, falls was drinstünde.
     • Domain syntaktisch prüfen:
       • Beginnt mit: ^[a-z]
       • Endet auf: \.[-a-z0-9]+$
       • Enthält nur: ^[-_%.a-z0-9]+$
       • Enthält keine: \.\.
     • Wenn Domain okay dann Zeitstempel und Nick und ggf. Wikilink und eingetragenen optionalen Notes-Inhalt in das Notes-Feld eintragen, und ein click auf den unsichtbaren HTML-Submit-button.
     • Wenn Domain nicht okay dann Domain-Feld rot unterlegen. Nix weiter.
  4. Das Notes-Feld bleibt meist leer oder erhält einen optionalen Zusatz-Kommentar.
• Weitere Aktivitäten lohnen sich erst, nachdem die Struktur der Projektseiten endgültig definiert ist.
  • Ggf. erübrigt sich das Wikilink auch noch.
  • Ggf. wäre eine URL-Verlinkung sinnvoller, weil die Spezialseite keine anklickbaren Verlinkungen auf die Projektseite generiert. Ob die URL-Links mitmacht glaub ich aber auch nicht, weil wegen Sicherheit.
  • Wenn sich aber die Projektseite nachvollziehbar aus der Domain ergibt, dann langt ein Wikilink einmalig im Kopf der Spezialseite, mit Erläuterung, zur Selbstnavigation.

VG --PerfektesChaos 13:33, 13. Nov. 2023 (CET)

Gudn Tach!

• Die Beschreibung "nicht bedienbar" halte ich für deutlich übertrieben. Da ich es bedienen kann, ist es auf jeden Fall bedienbar. Dass es kleinere Mängel hat, will ich nicht bestreiten, nur bitte ich darum, Pauschalisierungen zu vermeiden.
• Die Idee, das automatisiert erst beim Absenden einzufügen, hat zugegebenermaßen ihren Charme. Wenn ich es richtig verstehe, hätten die Eintragenden dann aber keine Möglichkeit, den Link vorm speichern zu modifizieren, oder?
• Was meinst du mit "weil die Spezialseite keine anklickbaren Verlinkungen auf die Projektseite generiert"? Die SBL-Links auf special:BlockedExternalDomains sind anklickbar.

-- seth (Diskussion) 23:57, 17. Nov. 2023 (CET)

Die Projektseiten sind exakt so zu organisieren, dass ich zu einer Domain auch eindeutig vorhersagbar das Wikilink bilden kann, unter dem ich die Diskussion dazu finden würde.

• Wenn ich weiß, an welchem Tag eine LD begonnen wurde oder eine FZW-Erörterung, dann kann ich daraus exakt vorhersagbar ermitteln, wie die Archiv-Unterseite heißt.
• Über WL können ggf. Dubletten auf eine zentrale Erörterung desselben Verantwortlichen umgelenkt werden; genauso auch mögliche separat nicht sinnvolle Subdomains auf die gemeinschaftliche Domain.
• Wenn aus der Domain eindeutig folgt, wo und wie ich die Erörterung finden kann, dann sind sämtliche Extrawürstchen aller Art unzulässig, und dann ist es auch nicht erforderlich, im interaktiven Formular noch irgendwie am Wikilink herumzubasteln.
• Neben der Eingabe im interaktiven Formular bleibt immer noch die Quellcode-Bearbeitung in JSON.

„Bedienbarkeit“ bedeutet, dass alle Menschen ohne besondere Vorkenntnisse das Formular intuitiv richtig und zuverlässig bedienen können (Principle of Least Surprise – Paradefall: „Generell sollte Software niemals Daten entfernen, die möglicherweise noch benötigt werden“; genau das macht aber die vorgelegte Programmierung, ohne dass dies erkennbar wäre).

• Dass die Einzelperson, die sich das ausgehackt hatte, es selbst bedienen könnte und um die unvorhersehbaren und verborgenen Fallgruben und Fußangeln weiß, ist völlig unerheblich.

Von der Anklickbarkeit in der Spezialseite weiß ich einstweilen wenig. Welche Wikisyntax genau hier unterstützt würde, wäre erst noch zu erforschen; erfahrungsgemäß ist das nur eine begrenzte Teilmenge.

VG --PerfektesChaos 10:45, 18. Nov. 2023 (CET)

Gudn Tach!

• "zu einer Domain auch eindeutig vorhersagbar das Wikilink bilden" -> Ja, haste eigentlich recht. Ich hab auf WP:SBL#Restrukturierung_2023 bei dem Beispiel mit dem ukrainischen SEO-Spam beim Schreiben auch gedacht: "Hmm, eigentlich beschreibe ich hier nur die Praxis, finde diese Praxis aber selbst nicht so super, nun ja." Vermutlich würden wir das (mit einigen Weiterleitungen) hinbekommen. Das ist aber eher ein Thema, was wir dort weiterbesprechen sollten, oder?
• Verstehe ich es richtig, dass dein Ansatz wäre, z.B. die erste Spalte von Special:BlockedExternalDomains per JS so zu modifizieren, dass sie gleich auf [[WD:Weblinks/block/example.org]] (oder was auch immer es dann sein wird) verlinkt, sodass man meine Sperenzchen mit dem dymanischen Ausfüllen gar nicht braucht, sondern nur (so wie ursprünglich gedacht) Timestamp + Name initial (oder eben beim Speichern) einträgt? Fänd ich, glaube ich, auch ok.

-- seth (Diskussion) 22:10, 18. Nov. 2023 (CET)

Im Prozess der Abspeicherung (syntaktisch zulässige wpDomain vorausgesetzt) schriebe ich als Feldinhalt von wpNotes:

• Timestamp @ Nick @ [[WP:Weblinks/Block/org/example]] <optional>Leerzeichen Feldinhalt von wpNotes</optional>

Wenn irgendeine „erste Spalte von Special:BlockedExternalDomains per JS so zu modifizieren“, dann würde das nur auf Personen wirken, die das Gadget aktiviert hätten; das wären per Definition jedoch nur Admins, und alle Normalmenschen, die die Spezialseite besuchen, sähen nur literally die JSON-Inhalte.

Dessen ungeachtet ließe sich jedoch mit Lua aus JSON eine sortierbare Wiki-Tabelle generieren, in der die Timestamp menschenlesbar eingekürzt und die Nicks verlinkt sind, und die Notes erst nach dem zweiten @ dargestellt werden.

VG --PerfektesChaos 08:19, 19. Nov. 2023 (CET)

Gudn Tach!

• Zur Struktur siehe WP:SBL#restrukturierung_2023. Da hab ich auch was zur Rückwärtsschreibweise geschrieben.
• Erste Spalte: Das wäre dann ein anderes Script und dieses dann nicht nur für Admins aktiviert.
• Falls da ressourcenschonend eine hübschere Ansicht mit Lua bewerkstelligt werden könnte: gerne (solange ich es nicht in Lua programmieren muss).

-- seth (Diskussion) 00:37, 20. Nov. 2023 (CET)

@ „Das wäre dann ein anderes Script und dieses dann nicht nur für Admins aktiviert“

• Ein derartiges Skript wird es nicht geben. Punkt.
• Wenn (auch nicht angemeldete) erst ein „Skript“ installieren müssen, um eine Spezialseite lesen und übersichtlich verständlich darzustellen, dann ist diese Spezialseite für die Öffentlichkeit unbrauchbar.
• In dem Moment, in dem all dieses Timestamp-Nick-Gedöns dransteht, ist die Spezialseite nur noch intern für pflegende Admins verwendbar.
• Die verständliche Darstellung kann über Lua erfolgen.

VG --PerfektesChaos 09:57, 20. Nov. 2023 (CET)

Gudn Tach!

Zum Punkt 2: Das sehe ich ganz genauso, weshalb ja mein Vorschlag auch ein für alle aktiviertes Script war, was aber wegen Punkt 1 wohl nicht geht.

Zum Punkt 4: Wenn du das (später) machst, gerne. :-)

Magst du dich bei Gelegenheit mal auf WP:SBL#Restrukturierung_2023 äußern? Ich würde ungern was umsetzen, mit dem du am Ende todunglücklich bist. -- seth (Diskussion) 09:47, 25. Nov. 2023 (CET)

Gudn Tach!

Zur Info: user talk:lustiger_seth#Blocked_external_domains. So einfach kann's gehen. Bin mal gespannt, ob auch das Datum noch ergänzt wird. -- seth (Diskussion) 20:42, 15. Jan. 2024 (CET)

Fehlendes CSS auf Datei:-Seiten

Bitte bei Wikipedia:Fragen_zur_Wikipedia#Unterschied_zwischen_Darstellung_bei_"Datei:"_und_bei_"c:File:"_(Galerie) kommentieren. --Enhancing999 (Diskussion) 09:45, 10. Nov. 2023 (CET)

Die Diskussion oben wurde inzwischen archiviert. Ich habe den Link aktualisiert.

@Raymond, Hgzh: nützlich wäre die besprochene Ergänzung bei Links die direkt auf die Datei führen, vgl. Special:Search/insource:/:Datei/. --Enhancing999 (Diskussion) 21:03, 29. Nov. 2023 (CET)

MediaWiki:Cite link label group-lower-alpha

Könnte man die Seite MediaWiki:Cite link label group-lower-alpha mit dem Inhalt von w:MediaWiki:Cite link label group-lower-alpha erstellen?

vgl. dazu mw:Help:Cite#Grouped_references. Könnte in gewissen Fällen Vorlage:FN ersetzen. --Enhancing999 (Diskussion) 11:58, 18. Nov. 2023 (CET)

Übersehen. Halte ich nicht für sinnvoll, erzeugt nur zusätzliche Komplexität und offensichtlich ist der Bedarf weitgehend durch vorhandene Lösungen gedeckt. Zudem geht der Trend in der Cite-Extension eher weg von diesen Systemnachrichten hin zu CSS-only Lösungen, siehe MediaWiki:Gadget-citeRef.css. -- hgzh 18:54, 3. Apr. 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:

• Sowieso-Maßnahmen
  • in MediaWiki:Gadget-dewikiCommonLayout.css ausgelagerte Definitionen aus MediaWiki:Mobile.css zu entfernen  Ok
  • MediaWiki:Gadget-NavFrame.css aktiv werden zu lassen sowie die redundanten Definitionen aus MediaWiki:Common.css und MediaWiki:Mobile.css zu entfernen  Ok
• Zusatzmaßnahmen
  • die gemeinsamen Ausblendedefinitionen aus Common.css und Mobile.css in ein neues MediaWiki:Gadget-dewikiCommonHide.css auszulagern und in den Einzelressourcen zu entfernen  Ok
  • die Regel zu span.subpages zu entfernen (sollte nicht mehr nötig sein, habe aber in phab:T270872 noch einmal nachgefragt)  Ok
  • die Nowrap-Regel nach Minerva.css zu übertragen  Ok
• Endmaßnahme
  • Mobile.css zu leeren bzw. archivieren.  Ok

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)

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)

Dieser Abschnitt kann archiviert werden. hgzh 21:56, 17. Apr. 2024 (CEST)

Gadgets per Kategorie auslösen

• BETA
• Kategorie:MediaWiki:Gadget
• Hauptseite, Stufenplan:
  1. Wikipedia:Hauptseite (Vollschutz) ++ 3 Kats hinzufügen
  2. 3 Gadgets von 3 Kats abhängig machen
  3. Erproben
  4. Rollback oder Probleme abwarten
  5. Erstellung eines neuen MediaWiki:Gadget-Hauptseite.js, das alle bisherigen drei in einer Programmierung zusammenfasst und situationsabhängig mobil oder desktop oder beides reagiert. CSS usw. usw. per Selektoren.
  6. Erprobung auf BETA.
  7. Ersatz der hiesigen drei Gadgets mittels neuer Kategorie.

Enjoy --PerfektesChaos 17:23, 2. Apr. 2024 (CEST)

Kommt, geht auch mit MediaWiki:Gadget-PB.js, das wird nur auf Wikipedia:Persönliche_Bekanntschaften/neue_Anfragen geladen.

Zusammenfassen halte ich für keine gute Idee, Suchfokus-Hauptseite ist kein Default-Gadget und sollte es auch nicht sein. MediaWiki:Gadget-desktopHauptseite.js funktioniert ohnehin nur im Vector-/Monobook-Skin. Die beiden CSS-Gadgets lassen sich vielleicht sinnvoll zusammenfassen, kann ich aber nicht testen, habe keinen HD-Breitbildschirm. Ansonsten sind die Regeln doch noch recht spezifisch für die jeweiligen Skins, kann also eigentlich auch erstmal so bleiben. Anstelle dreier Kategorien tut es vielleicht auch einfach Kategorie:Wikipedia:Hauptseite als Ladeziel. -- hgzh 13:56, 3. Apr. 2024 (CEST)

Die Kategorie:MediaWiki:Gadget soll schon exakt Gadgets laden, deren Unterkats sind im Unterschied zu Kategorie:Wikipedia:Hauptseite auch versteckt.

• Unix-Philosophie – Mache eine Sache, und die mache gut.
• Die Wikitext-Seiten, die an der Generierung der Hauptseite beteiligt sind, sind eine Sache; Gadgets ausführen eine andere.
• Das blendet dann ggf. wieder irgendwelche Seitenteile unerwünscht aus, oder hat sonstwelche unvorhersehbaren Nebeneffekte.

Die Suchfokus-Option kann dann ja ggf. auch eine der beiden oder beide anderen Kats mitbenutzen, bzw. die eine zusammengefasste.

Der Split in Desktop und Mobil scheint mir obsolet.

• Ich kapiere mobileHauptseite sowieso nicht.
  • Entweder ist es ein Smartphone, dann gibt es auf dem keinen HD-Breitbildschirm (das sind bei mir 4k).
  • Auch ein Desktop-HD-Breitbildschirm soll bei allen Skins die volle Fenstergröße ausnutzen; das ist ja der Witz bei der responsiv gelayouteten neueren Hauptseite.
  • body.skin-minerva würde bedarfsweise einschränken; aber dafür sehe ich keinen Anlass.
• Die Selektoren zum Desktop-CSS existieren mobil überhaupt nicht, und wenn würde deren Ausblendung mobil auch keinen Schaden anrichten.
  • Hinsichtlich CSS kann also eigentlich beides in eine gemeinsame Ressource, und das JS kann gucken und switchen.
  • Ich stelle gern ein Universal-JS auf BETA bereit.

VG --PerfektesChaos 14:53, 3. Apr. 2024 (CEST)

Na ja, wenn die Kategorie nach Gadget A benannt ist, aber Gadget B auf einmal auch drauf anspringt, ist das verwirrend. Dann lieber zwei bzw. drei. Mir fällt da noch Wikipedia:Hauptseite/Archiv ein, wobei das vernachlässigbar sein sollte.

Grad nochmal nachgeschaut; .content und .pre-content aus MediaWiki:Gadget-mobileHauptseite.css gibt es nur im Minerva-Skin, die Regeln sorgen dafür, dass die Hauptseite im Minerva-Skin nicht auf 993px beschränkt ist (wahrscheinlich Tablets im Querformat oder so). An sich ist das Laden nur für Minerva also ok, wenn man diesen Spezialfall haben möchte (Hintergründe kenne ich nicht, hatte mich bei der HS-Umstellung weitgehend rausgehalten, vielleicht erinnert sich XanonymusX noch). Theoretisch wäre das dann auch für Vector-2022 interessant, weil es auch dort eine fixierte Seitenbreite gibt.

Also einen zwingenden Grund, das jetzt wieder zusammenzufassen, sehe ich nicht. Dann werden eben drei Kats eingebunden, sieht sowieso niemand. -- hgzh 18:46, 3. Apr. 2024 (CEST)

Ich habe jetzt mal MediaWiki:Gadget-Hauptseite@BETA bereitgestellt.

• Der kann erforderlichenfalls auch auf minerva verzweigen, falls wir eines Tages dort reinzugrätschen wünschen.
• Damit können die beiden Gadgets für d+m auch im CSS vereinigt werden.
• Gibt eine Kategorie:MediaWiki:Gadget/Hauptseite für das Gadget selbst.
• Suchfokus-Hauptseite kann sich dann von dieser Fremdkategorie abhängig machen.

VG --PerfektesChaos 14:36, 4. Apr. 2024 (CEST)

Die Skin-Einschränkung müsste dann noch auf Vector-2022 erweitert werden, weil das mit der geänderten Sprachauswahl nicht zusammenpasst. Aber nach wie vor erschließt sich mir die Notwendigkeit der Zusammenlegung nicht, das Minerva-Gadget macht brav das, was es soll, ebenso das Desktop-Gadget. Passt auch zur Unix-Philosophie. -- hgzh 11:53, 5. Apr. 2024 (CEST)

Zu fisselig, zu verwirrend und unübersichtlich.

Die Aufteilung war sinnvoll gewesen, als sie auf >10.000 Projektseiten wirkte, oder womöglich zuvor jeden Aufruf.

Jetzt wird es auf genau eine Seite wirken, deren Performance durch zurzeit 8 Statements JS ohne Auswirkung nicht gestört werden wird, und womöglich wollen wir an Mobil irgendwann auch mal irgendwas JS-rummachen.

Das CSS im Überblick in der Wirkung auf manche oder alle oder einige Skins wirkend statt wieder woanders ist für Pflegepersonal, das es sich nicht selbst ausgetüftelt hatte, nicht mehr durchschaubar.

Tendenziell soll ja global die Darstellung von Desktop und Mobil immer weiter zusammenwachsen, immer ähnlicher zu bedienen sein, sofern dem die Display-Begrenzung nicht entgegensteht.

Die bisherige strikte Trennung in Desktop-Ressourcen und Mobil-Ressourcen und deren Doppelleben lösen wir ja grad auf.

• Die Aufteilung als m.-Subdomains war auch mal eine Panikreaktion der frühen 2010er Jahre gewesen, nachdem diese kleinen Mistdinger aufkamen und alle Hosts schnell ein gesondertes Angebot basteln mussten. Mittlerweile erkennen die Frontend-Server das sowieso und können auf einheitlicher URL reponsiv den passend aufbereiteten Content liefern.
• Das target-Kriterium in der Gadgets-Definition ist ja auch weggefallen; vermutlich aus Gründen.

VG --PerfektesChaos 14:25, 5. Apr. 2024 (CEST)

Umstellung auf kategoriebasiertes Laden ist jetzt erfolgt, funktioniert. -- hgzh 19:15, 10. 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)