Ä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.

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

Archiv

2024 2023 2022 2021 2020 2019 2018

MediaWiki:Common.css – allmähliche Verschlankung

Letzter Kommentar: vor 5 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

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)Beantworten

Änderungswünsche

Explizite Vordergrundfarbe für .zebra

Letzter Kommentar: vor 1 Jahr7 Kommentare4 Personen sind an der Diskussion beteiligt

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)Beantworten

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)Beantworten

/*
 * 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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

Overflow für Musiknoten

Letzter Kommentar: vor 2 Jahren2 Kommentare1 Person ist an der Diskussion beteiligt

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)Beantworten

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)Beantworten

Warnbox in Common.css aufnehmen

Letzter Kommentar: vor 1 Jahr17 Kommentare3 Personen sind an der Diskussion beteiligt

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)Beantworten

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

Test

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

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)Beantworten

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)Beantworten

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)Beantworten

@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)Beantworten

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)Beantworten

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:

Vorlagen; könnten TemplateStyles nutzen.
Systemnachrichten; können kein TemplateStyles aber inline-style über eine zentral gepflegte Vorlage einbinden.
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)Beantworten

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)Beantworten

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)Beantworten

@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)Beantworten

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

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)Beantworten

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)Beantworten

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)Beantworten

@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)Beantworten

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)Beantworten

Neues Gadget: localUserOptions

Letzter Kommentar: vor 1 Jahr10 Kommentare2 Personen sind an der Diskussion beteiligt

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)Beantworten

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

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)Beantworten

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)Beantworten

@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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

Ich hab das alles noch nicht so ganz restlos durchdacht und verstanden, aber ich nehme es auf. -- hgzh 18:28, 24. Feb. 2023 (CET)Beantworten

Deutsche Titel bei Spezialseiten

Letzter Kommentar: vor 1 Jahr11 Kommentare6 Personen sind an der Diskussion beteiligt

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

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)Beantworten

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)Beantworten

@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)Beantworten

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/245151729 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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

Zu PageHistory: Könnte da nicht Seiten- oder Versionsrückblick (oder auch -verlauf) passen? --Funkruf

^WP:CVU 16:58, 13. Okt. 2022 (CEST)Beantworten

MediaWiki:Vector.css coordinates hacks

Letzter Kommentar: vor 1 Jahr19 Kommentare5 Personen sind an der Diskussion beteiligt

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)Beantworten

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)Beantworten

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)Beantworten

@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)Beantworten

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)Beantworten

@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)Beantworten

@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)Beantworten

@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)Beantworten

@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)Beantworten

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)Beantworten

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)Beantworten

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

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

(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)Beantworten

Änderungen in Syntax der Medieneinbindung

Letzter Kommentar: vor 1 Jahr8 Kommentare3 Personen sind an der Diskussion beteiligt

s. mw:Parsoid/Parser Unification/Media structure/FAQ - Da kommt eine weitere Mammutumstellung auf uns zu. Einige Klassen, die auch produktiv im ANR oder in Vorlagen verwendet werden, sind wohl von Umbenennung betroffen (thumbinner, tleft, tright), zudem ändert sich die komplette Struktur der Medieneinbindung, sodass sicherlich einige Selektoren in Skripten und Stildateien anzupassen sind. Womöglich müssen wir die Klassendefinitionen erst einmal lokal weiterbetreiben, um nicht signifikant Artikelbestand zu zerschießen. -- hgzh 14:07, 30. Nov. 2022 (CET)Beantworten

Some of these concerns are addressed in the FAQ

https://www.mediawiki.org/wiki/Parsoid/Parser_Unification/Media_structure/FAQ/de#Wie_wurde_dies_getestet?

We don't expect there to be any visual differences after this change.

https://www.mediawiki.org/wiki/Parsoid/Parser_Unification/Media_structure/FAQ/de#What_about_templates_that_mimic_the_parser_output?

The old styles will continue to be shipped until content that depends on them can be migrated away.

Sorry for the English. --Arlolra (Diskussion) 17:27, 1. Feb. 2023 (CET)Beantworten

English is absolutely fine within this page.

Regular community might complain, but this is technical environment and software development here.

Greetings --PerfektesChaos 01:01, 2. Feb. 2023 (CET)Beantworten

Please make changes like the following to MediaWiki:Common.js,

https://ca.wikipedia.org/wiki/Especial:ComparePages?page1=MediaWiki%3ACommon.js&rev1=24309161&page2=Usuari%3AArlolra%2Fsandbox%2FMediaWiki%3ACommon.js&rev2=31054319&action=&unhide=

https://ca.wikipedia.org/wiki/Especial:ComparePages?page1=MediaWiki%3ACommon.js&rev1=31055727&page2=Usuari%3AArlolra%2Fsandbox%2FMediaWiki%3ACommon.js&rev2=31058458&action=&unhide=

For more information, see mw:Parsoid/Parser_Unification/Media_structure/FAQ

Thanks, --Arlolra (Diskussion) 20:29, 31. Jan. 2023 (CET)Beantworten

Hi @Arlolra, thanks for the notification, I applied the changes in Special:Diff/230416921. Regards, -- hgzh 08:11, 1. Feb. 2023 (CET)Beantworten

Und was macht dieses Feature auf mobil?

Ggf. lieber Anlage eines galleryTemplate default hidden.

Mag dann irgendwann auch fokussierter nach action und Namensraum passieren. Wobei, >99,9 % sind ANR und view.
Jedenfalls wäre eine Gadget-Einheit besser dokumentierbar und hat eine hübschere Versionsgeschichte; und lässt sich später im spezifischen Kontext diskutieren. Dieser heutige Abschnitt kann dann die Disku eröffnen.

VG --PerfektesChaos 09:21, 1. Feb. 2023 (CET)Beantworten

Mobil sind das bloß untereinander angeordnete Bilder und Common.js pfuscht dort dann nicht rein. Aber mittelfristig sollte das, wie (fast) die ganze Common.js, ein Gadget werden, da bin ich bei dir. -- hgzh 09:33, 1. Feb. 2023 (CET)Beantworten

Insbesondere falls es mal eine kontext-sensitive Auslösung gäbe; heißt: Nur Seiten mit Einbindung template:Galerie lösen die Lieferung des Gadgets für genau diese Seite aus. VG --PerfektesChaos 10:04, 1. Feb. 2023 (CET)Beantworten

Zukunft des Rot-Grün-Sehschwäche-Helferleins

Letzter Kommentar: vor 1 Jahr2 Kommentare2 Personen sind an der Diskussion beteiligt

Das Gadget wird momentan mit den in MediaWiki:Gadget-Rot-Gruen-Sehschwaeche.css festgelegten Definitionen aktiv. Diese sind beide praktisch unwirksam:

die Diff-Engine arbeitet schon seit einiger Zeit mit ins/del anstelle von span, und die Farbkorrektur wäre selbst bei einer Korrektur ohnehin nur noch dann sinnvoll, wenn man die Difffarben von vor einer Dekade aktiviert hat. Da sich niemand über Funktionslosigkeit beschwert hat, gehe ich davon aus, dass der Bedarf nicht mehr da bzw. die Schnittmenge zwischen beiden Gadgets zu gering ist.
not-patrolled wird per Common.css als Teil des obsoleten Patrol-Systems auf transparent gesetzt. Leute, die dieses Gadget aktiviert haben, bekommen also überhaupt erst mal wieder eine Farbe zu Gesicht, was aber nicht Sinn und Zweck des Gadgets ist.

Meiner Meinung nach sollten mindestens die unwirksamen Definitionen entfernt werden, womit aber gar nichts mehr verbleiben würde. Ich denke, wir sollten keine Funktion vorgaukeln, wo nichts ist. Also entweder auf versteckt setzen oder ganz löschen. Wenn man es nur versteckt, wäre es wieder reaktivierbar, falls es erneut Bedarf gäbe. Ehrlicherweise sehe ich es aber in der heutzutage als primäre Aufgabe der Zuständigen UX-Experten bei der WMF, dafür zu sorgen, dass MediaWiki eine barrierefreie Oberfläche hat. Plädiere also eher dafür, es ganz zu löschen. -- hgzh 19:25, 13. Jan. 2023 (CET)Beantworten

Kann ja zukünftig wieder Regeln bekomen; etwa wenn jemand (etwa 9 % aller Männer) sich beklagt, dass class=hintergrundfarbe* rahmenfarbe* Kästen Ja-Nein-Tabellenzellenfärbungen nicht auseinanderzuhalten wären und hier Vorkehrungen zu treffen sind.

Momentan liefert es bei Aktivierung 0 Bytes aus und schadet nix.

Wenn es aus der -definition eliminiert würde, oder hidden, dann kann es niemand mehr deaktivieren.

Besser in der definition-Beschreibungsnachricht weit vorn (nach dem Bezeichner) ein (zurzeit keine Wirkung) einfügen; und ans Ende der -definition setzen.

In den Konten-Einstellungen lebt es aktiviert sowieso weiter.

VG --PerfektesChaos 09:18, 1. Feb. 2023 (CET)Beantworten

Ergänzung von MediaWiki:Common.css für Referenzformatierung nötig

Letzter Kommentar: vor 1 Jahr18 Kommentare3 Personen sind an der Diskussion beteiligt

siehe mw:Parsoid/Parser_Unification/Cite_CSS. Diese zusätzlichen CSS-Regeln bräuchten wir, damit unsere gewohnte Referenzformatierung auch in einer zukünftigen Parsoid-Umgebung erhalten bleibt (die Abweichung ist jetzt schon im VE erlebbar). Der alte Parser zieht sich die Formatierung aus MediaWiki:Cite references link many format backlink labels und MediaWiki:Cite references link many format. Ich würde daher die erforderlichen Anpassungen demnächst vornehmen. Gruß, -- hgzh 08:47, 31. Jan. 2023 (CET)Beantworten

Nach einem Test auf beta reicht:

span[rel="mw:referencedBy"] > a::before {
	font-style: italic;
	content: counter(mw-ref-linkback, lower-alpha);
}

-- hgzh 18:30, 31. Jan. 2023 (CET)Beantworten

You also need this (this is also present on the page you linked above)

a[rel="mw:referencedBy"]::before {
  font-style: italic;
}

--SSastry (WMF) (Diskussion) 01:40, 1. Feb. 2023 (CET)Beantworten

Hi @SSastry (WMF) yes, it's on the page, but it seems to style the single backlinks (↑) italic which is, by Special:Permalink/229631367#L-337, not intentional even if the current Common.css definition matches it (it also has no effect on all the systems I tested this). Or am I missing another case? -- hgzh 07:36, 1. Feb. 2023 (CET)Beantworten

Und was macht Mobil?

What about mobile?

Ggf. lieber Anlage eines cite-ref default hidden.

Mag dann irgendwann auch fokussierter nach action und Namensraum passieren. Wobei, >99,9 % sind ANR und view.
Jedenfalls wäre eine Gadget-Einheit besser dokumentierbar und hat eine hübschere Versionsgeschichte; und lässt sich später im spezifischen Kontext diskutieren.

Auch wenn wir selbst mal zu anderen Zwecken weitere ref-cite-Regeln hinzufügen wollen; namentlich wird ein Zeilenumbruch zwischen [Anm. und 5] beklagt (natürlich auch mobil). Andere beschweren sich über zu kleine Schriftgröße; 10 % des Publikums hat schlechte Augen. 87% wären angebrachter, [oben] und unten. Zurzeit 11/14px = 75%. Ein Pixel Abstand vor [ref] wird wegen Kollisionen mit Anführungszeichen und manchen Buchstaben gewünscht, insbesondere bei Kursivschrift und Fleisch in der rechten oberen Ecke. Oder auch zwei. Die^{[71][11][123]} bappen zu dicht zusammen und sind schwieriger als einzelne Ziele auseinanderzuhalten, Augen und so; padding-left. Auch mobil.

Kann dann womöglich zu opt-out und user-config ausgebaut werden.

Was macht lower-alpha eigentlich beim 27. backlink? Auf allen Browsern?

Greetings --PerfektesChaos 09:10, 1. Feb. 2023 (CET)Beantworten

Mobil braucht dann vermutlich analog einen Eintrag in Mobile.css (falls MediaWiki:Cite references link many format backlink labels nicht mehr wirkt), da machen wir bislang ja gar nix zu Referenzen und haben auch die Kursivsetzung nie nachgeführt. Kann man sicher auch auslagern und dann an zentraler Stelle als Gadget pflegen, dann spart man sich die Dopplung.

lower-alpha fängt dann nach meinen Tests brav bei aa wieder an, so wie gehabt. -- hgzh 09:45, 1. Feb. 2023 (CET)Beantworten

Ich will generell weg von den historischen Desktop-großer-Kupferkessel-alles-reinschmeiß-und-rumrühr-Zaubertränken Common.* und hin zu Destktop+Mobile DRY mit individuell zugeordneter Wikitext-Dokumentation und Diskussion.

Nur noch ein paar Brösel und langfristig wegfallende Geschichten mögen noch bei den Common.* verbleiben. Damit werden die Reste auch übersichtlicher.

Diskutieren in Richtung auf ein Ziel kann dann erstmal gebündelt bei den Gadgets passieren; wenn entscheidungsreif dann kann hier auf dieser Seite die erarbeitete Umsetzung vorgeschlagen werden.

VG --PerfektesChaos 09:58, 1. Feb. 2023 (CET)Beantworten

Hab auf Beta mal die Gadget-Variante getestet, funktioniert damit auch mobil. Dann lager ich das ganze aus. -- hgzh 12:51, 1. Feb. 2023 (CET)Beantworten

Ich hätte dann auch noch zur Verhinderung der Übergröße beim unerwünschten Einsatz in Überschriften, oder sonst vergrößerten oder verkleinerten Bereichen in rem (BETA-Test für alles noch erforderlich, freihändig):

sup.reference {
    font-family:  sans-serif;
	font-size:    0.87rem;
	font-variant: normal;
}

Also alle Schrift-Eigenschaften des Kontextes zurücksetzen.

sup.reference {
    padding-left: 0.1rem;
	white-space:  nowrap;
}

Von oben. Kursivschrift von Buchstabe mit was rechts oben führt gern dazu, dass in H^[1] die kursivierte rechte obere Ecke kollidiert. H^{[71][11][123]} sieht für manche Leute aus wie ein Barcode, lauter vertikale Striche, wo ist denn jetzt welches ref zum Anklicken?

Wikipedia:Technik/Skin/Gadgets/citeRef würde ich anlegen, nachdem du hier erstmal noch ohne Wirkung MediaWiki:Gadget-citeRef.css angelegt hast.

VG --PerfektesChaos 15:05, 1. Feb. 2023 (CET)Beantworten

Mal durchgetestet: white-space, font-style und font-weight kommen inzwischen bereits aus dem zentralen ext.cite.styles.css, die können also lokal entfallen.

0,87rem sind größer als zuvor (ca. gleiche Höhe wie Text), weil sie auf die 16px von body abstellen und die zusätzliche Verkleinerung von sup überschreiben: Beta - hier müsste nochmal genau überlegt werden, was passieren soll. Eigenmächtig vergrößern halte ich für eher ungünstig.

Die anderen sind soweit okay.

Im Übrigen sollten wir alsbald irgendwo festhalten, wo und welche zentralen Projektstile und -skripte für alle als Gadget ausgelagert worden sind. Einen Vorteil haben die Common-Files: man weiß, wo man wahrscheinlich fündig wird. Leeren sie sich, wird das Auffinden betroffener Definitionen und Programmierungen schwieriger, selbst jetzt wissen wahrscheinlich nur vier Leute, uns beide eingeschlossen, wo etwas im Fehlerfall zu finden wäre. -- hgzh 22:05, 1. Feb. 2023 (CET)Beantworten

Enträtselbare Bezeichner in Verbindung mit der Box rechts in jedem dokumentiertem Gadget lösen das letztangesprochene Problem. Da wir aber immer mehr responsiv und mobil+desktop die Ressourcen vorhalten, ist der olle große Kessel Common.* mit dem aus allem zusammengekochten Zaubertrank ohnehin nicht zukunftsfähig. Er berücksichtigt nicht die Synchronisation mit Mobil, und wenn Miraculix mal beim Mistelschneiden vom Baum fällt, dann steht das Dorf ratlos und ohne Dokumentation da. Weil, die paar Kommentarzeilen in den jeweiligen Codes sind ungenügend.

Was die Schriftgröße angeht, so soll sie wie die anderen Font-Eigenschaften das Problem eines nicht ganz normalen Fließtextes lösen, dass dann dieser Kontext auch auf das Anmerkungszeichen durchschlägt. Wenn es innerhalb einer small-Umgebung passiert, wird nochmals verkleinert, 0.75×0.75 und wenn unerwünschterweise in einer Überschrift dann riesig.

Die obigen 0.87rem waren erstmal gegriffen anhand der em im Content. Bei allen Skins und Mobile ausgenommen Monobook gibt es aber eine ähnliche Transformation body→wiki-Content; die müsste dann noch mal rausgerechnet werden. Dann mögen es 0.7rem sein; also so dass das [ref] gegen seine normale Artikel-Grundschrift gut 85 % verkleinert. Dann ist das auch mit weniger guten Augen noch lesbar. Etwa 90 % wünschen sich die Ratgeber zur Barrierefreiheit; ein paar Prozentpunkte mag man noch druntergehen. Bei Monobook letztlich auch; aber da ist die Verkleinerung Artikel-Grundschrift gegen root=body nochmal schärfer und die bräuchten eine nachgeschaltete Extra-Regel, so dass das nicht unangenehm groß, aber auch nicht zu winzig wird. Wobei die Monobook-Generation ja damals perfekte Sehkraft gehabt haben muss, aber die sind inzwischen zwei Jahrzehnte älter geworden.

VG --PerfektesChaos 00:59, 2. Feb. 2023 (CET)Beantworten

MediaWiki:Gadget-citeRef.css ist angelegt, zunächst mal ohne die Textgrößenanpassung, die kann aber nachgetragen werden.

Die Liste unterhalb von Wikipedia:Technik/Skin/Gadgets kenne ich, aber da werden persönlich aktivierbare Gadgets mit „Systemgadgets“ gemischt, was ein Auffinden erschwert. Ich würde mir eine Aufstellung ähnlich Wikipedia:Technik/Skin/MediaWiki#Ressourcen dort oder anderswo wünschen. -- hgzh 07:45, 2. Feb. 2023 (CET)Beantworten

@Hgzh If you open any page, Special:Permalink/229631367#L-337 causes the single backlinks (↑) to be italic. But, if you open the same page in VisualEditor (VE), the ↑ is not in italic anymore. The rule I provided fixes that so that Parsoid HTML display in VE matches the default display. --SSastry (WMF) (Diskussion) 15:55, 1. Feb. 2023 (CET)Beantworten

citeRef.css ist live; common.css entsprechend bereinigt. -- hgzh 13:31, 6. Feb. 2023 (CET)Beantworten

@Hgzh Because of some changes to the default CSS shipped by the Cite extension (to accommodate all wikis), you will now need to add the following additional rule to the cite gadget.

span[rel="mw:referencedBy"] {
    counter-reset: mw-ref-linkback 0;
}

--SSastry (WMF) (Diskussion) 00:52, 1. Mär. 2023 (CET)Beantworten

Hi @SSastry (WMF), did I get the discussion on en:User_talk:Izno#Just_a_heads_up_about_Parsoid_Cite_CSS_requests right that you changed the init value to let wikis with decimal counters start by 1.0 linkbacks etc.? Just want to understand what I'm changing :) -- hgzh 07:51, 1. Mär. 2023 (CET)Beantworten

Alphabetic counters start at 1 whereas numeric counters (like decimal) start at 0. See https://www.w3.org/TR/css-counter-styles-3/#alphabetic-system. Right now, the Cite extension defaults to numeric counters and an init value of -1. So, when wikis use alphabetic and other counter types (like dewiki), they need to override the init to 0. Does that help? --SSastry (WMF) (Diskussion) 20:56, 1. Mär. 2023 (CET)Beantworten

Erledigt -- hgzh 21:07, 1. Mär. 2023 (CET)Beantworten

Gadgets and user scripts will be changing to load on desktop and mobile sites

Letzter Kommentar: vor 1 Jahr3 Kommentare2 Personen sind an der Diskussion beteiligt

Heute auf der Ambassador-Mailingliste:

Gadgets and user scripts will be changing to load on desktop and mobile sites. Previously they would only load on the desktop site. It is recommended that wiki administrators audit the gadget definitions prior to this change, and add skins=… for any gadgets which should not load on mobile. More details are available.

--Raymond ^Disk. 11:47, 6. Feb. 2023 (CET)Beantworten

Danke für den Hinweis. Ich würde vorschlagen, dass wir erst einmal die derzeitige implizite Zuordnung nur Desktop explizit machen und dann Stück für Stück entscheiden, ob die jeweiligen Gadgets auch mobiltauglich sind. Der BKL-Check sicherlich ja, das OSM-Gadget nicht. Müsste sorgfältig geprüft werden. -- hgzh 13:08, 6. Feb. 2023 (CET)Beantworten

Hab erst einmal alles auf Desktop beschränkt, was noch nicht war, Mobil-Erprobung dann irgendwann mal, wenn ich Zeit habe. -- hgzh 12:42, 11. Feb. 2023 (CET)Beantworten

Admincon

Letzter Kommentar: vor 1 Jahr6 Kommentare3 Personen sind an der Diskussion beteiligt

Liebe Technikexpert:innen, eine Bitte: Falls jemand von euch an der AdminCon im März teilnimmt, könnten wir dort vielleicht mal über die aktuell noch nutzbaren und nützlichen Benutzerscripte sprechen? Welche sind für Admins sinnvoll, welche veraltet, was ist inzwischen offizielles gadget, was hat sich an der Einbindung geändert? Gruss, –MBq ^Disk 13:31, 7. Feb. 2023 (CET)Beantworten

Hallo, ich komme nicht nach Cuxhaven (zu weit weg). Die Frage ist, was das Ziel sein soll: Identifikation kaputter Skripte zur Reparatur, Ideensammlung zu neuen Tools, oder einfach nur Sammlung (oder anderes?). Ich kann bei Interesse vielleicht etwas zuarbeiten, würde es aber ungern machen, wenn dort hauptsächlich über die blöden Entwickler genölt wird, die Skripte kaputtmachen. -- hgzh 12:51, 11. Feb. 2023 (CET)Beantworten

a) Cuxhaven: schade, aber vielleicht beim nächsten Mal! b) ich hatte an eine Sammlung und Übersicht der Skripten gedacht, die im Moment aktuell und gewartet sind. Weil soweit ich weiss einige Kollegen noch mit Altversionen arbeiten, vieles funktioniert gar nicht mehr. c) das Nölen hat zum Glück nachgelassen dank Deiner und PCs unermüdlichen Erklärungen! d) Danke für die Antwort! --MBq ^Disk 13:10, 11. Feb. 2023 (CET)Beantworten

... so etwas wie Wikipedia:Technik/Skin/Benutzerskripte? Ließe sich sicher noch um das eine oder andere ergänzen. Gruß, -- hgzh 13:41, 11. Feb. 2023 (CET)Beantworten

@ WP:HX = Wikipedia:Technik/Skin/Benutzerskripte – die ist informell an drei, vier Bedingungen geknüpft:

Tool hat eine Wikitext-Dokuseite mit Funktions- und Nutzungsbeschreibung.
Maintainer (Host-Konto) trägt persönlich die Veröffentlichung seines Werkzeugs auf dieser Seite ein.
Werkzeug ist allgemein nutzbar, also etwa nicht speziell für einzelne Fach- und Themengebiete.
Werkzeug funktioniert auf Minimalstandard, hat also obsolete Funktion von vor 2010 aktualisiert.

Hier scheint es ja nur um Adminonly-„Benutzerscripte“ zu gehen?

Die werden gleich mehrere der aufgezählten Bedingungen reißen.
Es gibt Dual-use, also etwa IP-Recherche und IP-Ranges, was von allen benutzt werden kann, aber was nur mit sysop-Knöppen funktioniert hat nix auf WP:HX am Suchen.

Eher eine Unterseite von WP:A bauen, „Werkzeuge“ oder so, und ggf. nicht nur JS sondern auch WMF-Cloud und extern darstellen.

Schwerpunkt auf Adminonly, Importeure und so, oder sonstige Werkzeuge für Admin-Arbeit (IP), und technische Arbeitsabläufe mit derartiger Unterstützung für Admin-Aufgaben. Admin-Gadgets.
Darstellung dort kann fehlende Wikitext-Dokuseite ersetzen und externe Einschätzung zur Verwenbarkeit liefern.
Diverse Werkzeuge sind effizienter mit ähnlicher Funktion selbst neu zu erstellen, als Teile von 2006 modernisieren zu wollen.

VG --PerfektesChaos 16:47, 12. Feb. 2023 (CET)Beantworten

Vielen Dank euch beiden für diese Hinweise! Vielleicht machen wir mal einen Online-Adminstammtisch dazu. LG --MBq ^Disk 12:46, 13. Feb. 2023 (CET)Beantworten

Koordinaten übergangsweise in den Indikatorenbereich verschieben

Letzter Kommentar: vor 1 Jahr9 Kommentare3 Personen sind an der Diskussion beteiligt

Hallo, nachdem das gestrige Softwareupdate den Hack für die Koordinatendarstellung, der schon vorher nicht besonders gut war, im Vector-2022 wieder zerschossen hat, frage ich mich, ob wir diese nicht übergangsweise in den Indikatorenbereich packen sollten. Dann kümmert sich die Software um die Positionierung und wir wären auf einen Schlag den ganzen Mist los. Ich habe offen gestanden keine Lust mehr, dieses Zeug zu debuggen und die im MB beschlossene Umstellung der Koordinatendarstellung ist im Moment nicht abzusehen.

Ein paar andere Sprachversionen machen das ja bereits, es ist also nicht unmöglich und schlechter als die derzeitige Lösung geht es ja eigentlich kaum. Sieht dann eben ein bisschen anders aus. Gruß, -- hgzh 19:36, 24. Feb. 2023 (CET)Beantworten

Jedes Provisorium ist von unendlicher Dauer.

Ich störe mich an dem Wort „übergangsweise“.
Meine Erfahrung ist vielmehr, dass jegliches Ersetzen eines Hacks durch den Missbrauch einer anderen Funktionalität nichts löst, und ein Gewurstel das nächste ablöst. Wobei dann Leute auftauchen, die nunmehr verlangen, die „Übergangslösung“ solle die endgültige sein, weil für sie wäre ja jetzt alles fein, und an diesem Status quo dürfe nun nichts mehr verändert werden.

Mobilgeräte bekommen davon immer noch nichts mit; sobald Indikatoren dort aktiv würden, zerschießt dort ein Koordinaten-Bandwurm die auf einige wenige Icons ausgelegte Menüleiste.

Vielmehr sollte das zum Anlass genommen werden, jetzt die ohnehin erforderlichen Bot-Läufe zu starten und nach und nach alle ANR-Einbindungen hinter die Einzelnachweise usw. vor die Navileisten, Auszeichnungen, Folgeleisten, Metadaten und Kategorien zu verschieben.

VG --PerfektesChaos 20:55, 24. Feb. 2023 (CET)Beantworten

Na ja, es ist schon deutlich weniger Gewurstel, weil sämtliche absolute Positionierung über die Wupper geht. Man kann sogar argumentieren, dass es ein Zwischenschritt wäre, weil ja der Koordinaten-Indikator später mal sowieso dahin kommt. Eine zeitlang bleiben eben die Koordinaten dort oben stehen, dann wandern sie woanders hin (was noch in Einzelfällen zu definieren wäre, da ist noch nicht alles klar). Mobil kann man sie im Ernstfall immer noch ausblenden, wobei mir nicht bewusst wäre, dass es irgendeinen Zeitplan für die Einführung von Indikatoren in der Mobilansicht geben würde (mag sein, dass das einfach so mal passiert). Dafür, dass es dann nicht auf ewig so bleibt, sorgt nötigenfalls das beschlossene Meinungsbild.

Und sicher kann man den Botlauf auch forcieren, aber der Realisierungszeitraum scheint mir länger zu sein als der zur Einführung von Vector-2022 als Standardskin, und dann geht das ganze Spektakel von vorne los. -- hgzh 21:45, 24. Feb. 2023 (CET)Beantworten

matmarex hat es freundlicherweise korrigiert, nun gut. -- hgzh 11:58, 26. Feb. 2023 (CET)Beantworten

Hat die Verschiebung der "Shortcuts" auch damit zu tun? Bei mir (Windows 10, Firefox 110, Skin Vector legacy) kleben die Abkürzungen jetzt in der Linie unter der Suchbox. Jedenfalls auf einigen Seiten - nicht auf allen, so ist z.B. auf dieser Seite das Shortcut unter der Linie der Überschrift - hier wird die {{Shortcut}} aber auch anders eingebungen als z.B. auf WP:FzW, WP:AAF und dergleichen.

Wenn ich die negative Verschiebung in der MediaWiki:Vector.css lokal in meiner common.css überschreibe (#shortcut { top: 0 !important; }), dann rutschen die Abkürzungen auf den "normalen" Seiten in die gleiche Zeile wie die "Brotkrümel-Navigation" links, also unter die Linie der Überschrift. Auf dieser Seite tut sich nichts, hier wäre der Selektor aber auch #shortcut-ca. --Gelegenheits-Wikipedianer (Diskussion) 11:59, 27. Feb. 2023 (CET)Beantworten

Ich habe Wikipedia:WikiProjekt Georeferenzierung/Migration Seiten-Koordinate 2023 angelegt.
- Die Analysen und Umstellungen und bei entsprechender Massierung auch Bot-Aktionen können damit nunmehr in großem Stil beginnen.
- Die Umsetzung und Sichtbarmachung auch mobil kann in drei Schritten erfolgen.
Vector2022 soll sich ja im Design der Mobilversion annähern. Mobil hatte noch niemals Koordinaten angezeigt, würde es auch bei Vergewaltigung des Indikatorenbereichs nicht machen; dann zeigt Vector2022 konsequenterweise halt auch keine Koordinaten an.
Shortcuts nutzen traditionell die identische gehackte Bockmist-Technologie von 2004.
- Auf Seiten im Hilfe-Namensraum und Unterseiten von Wikipedia:Technik stehen Linkboxen, die ein korrektes HTML-Arrangement sicherstellen.
- Bei denen ist der Shortcut jedoch Teil des normalen Seiten-Inhalts und deshalb auch mobil nutzbar.
- Auf den meisten Meta-Seiten des Designs der Nuller-Jahre ist der Seitenbeginn („Intro“) mit einem überflüssigen Rahmen umgeben, der nur Platz vergeudet, insbesondere auf einem Smartphone. Würde man dort die identische Technologie anwenden, dann wäre eine komplette erste „Zeile“ nur für den Shortcut konsumiert und der Rahmen begönne erst darunter. Würden diese Seiten so umgestaltet, dass der Rahmen die responsive Anordnung von Elementen nciht ausschließt, dann könnte der Shortcut dort bedarfsweise genauso einfließen.

VG --PerfektesChaos 16:52, 28. Feb. 2023 (CET)Beantworten

matmarex hat es freundlicherweise korrigiert, nun gut.

Hat jetzt genau welche Konsequenzen?

VG --PerfektesChaos 16:54, 28. Feb. 2023 (CET)Beantworten

Sie hat den Fehleranlass meines eingangs verärgert verfassten Beitrags, die Teilüberdeckung der Indikatoren durch unsere absoluten Positionierungen, wieder behoben, sodass Stand jetzt alles erst mal wieder halbwegs annehmbar aussieht. -- hgzh 17:07, 28. Feb. 2023 (CET)Beantworten

Migrationsprozess wurde mittlerweile gestartet. --PerfektesChaos 17:11, 15. Mär. 2023 (CET)Beantworten

Gadget-OpenStreetMap.js

Letzter Kommentar: vor 1 Jahr1 Kommentar1 Person ist an der Diskussion beteiligt

Die WIWOSM Karte funtioniert nicht. --WikedKentaur (Diskussion) 10:42, 19. Mai 2023 (CEST)Beantworten

Wikipedia:Technik/Skin/MediaWiki/Änderungen

Inhaltsverzeichnis

MediaWiki:Common.css – allmähliche Verschlankung

Änderungswünsche

Explizite Vordergrundfarbe für .zebra

Overflow für Musiknoten

Warnbox in Common.css aufnehmen

Neues Gadget: localUserOptions

Deutsche Titel bei Spezialseiten

MediaWiki:Vector.css coordinates hacks

Änderungen in Syntax der Medieneinbindung

Zukunft des Rot-Grün-Sehschwäche-Helferleins

Ergänzung von MediaWiki:Common.css für Referenzformatierung nötig

Gadgets and user scripts will be changing to load on desktop and mobile sites

Admincon

Koordinaten übergangsweise in den Indikatorenbereich verschieben

Gadget-OpenStreetMap.js

Navigationsmenü

Wikipedia:Technik/Skin/MediaWiki/Änderungen

MediaWiki:Common.css – allmähliche Verschlankung

Änderungswünsche

Explizite Vordergrundfarbe für .zebra

Overflow für Musiknoten

Warnbox in Common.css aufnehmen

Neues Gadget: localUserOptions

Deutsche Titel bei Spezialseiten

MediaWiki:Vector.css coordinates hacks

Änderungen in Syntax der Medieneinbindung

Zukunft des Rot-Grün-Sehschwäche-Helferleins

Ergänzung von MediaWiki:Common.css für Referenzformatierung nötig

Gadgets and user scripts will be changing to load on desktop and mobile sites

Admincon

Koordinaten übergangsweise in den Indikatorenbereich verschieben

Gadget-OpenStreetMap.js

Navigationsmenü

Suche