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

Benutzeroberfläche‎: Umfrage beendet

Zu: Wikipedia:Umfragen/Verschlankung der Benutzeroberfläche

• Vorbemerkung: Die „Auswertung“ stammt nicht vom Ersteller der Umfrage und erfolgte unabgesprochen und ungefragt.

Grundsätzlich ist es jetzt Einschätzung möglicherweise umsetzender Admins, inwieweit die absolute Anzahl an Stimmen sowie das Verhältnis für eine Aktivität hinreichend erscheint.

Zu den Punkten im Einzelnen:

• Zu „Datei hochladen“ wird offenbar eine Umlenkung des Linkziels gewünscht.
  • Das müssten die BOA dann in eigener Verantwortung realisieren.
• Der Punkt „Änderungen an verlinkten Seiten“ wird offenbar von einigen Langzeit-Autoren weiterhin für sich persönlich gewünscht, kann aber offenkundig ohne Not für nicht angemeldete Leser wegfallen.
  • Das ließe sich über die Common.css realisieren, indem #t-recentchangeslinked zunächst ein display:none erhält, und danach .useronly #t-recentchangeslinked ein display:block
• „Fragen von Neulingen“ wird offenbar von einigen Benutzern gewünscht; ggf. einfügen.
• Die „Druckversion“ macht nichts anderes als die heutzutage möglichen Browser von selbst machen können.
  • MediaWiki wird dies über kurz oder lang von selbst im Zuge anderer Desktop-Änderungen entfernen.
  • Kann bis dahin per CSS ausgeblendet werden; ist uns nicht direkt zugänglich.
  • Grundsätzlich fällt umso mehr Aufmerksamkeit auf die verbleibenden Punkte, je weniger andere Funktionen es gibt – umso kürzer die Aufzählungen sind.

Generell läuft zurzeit auch global ein Experiment zur Modernisierung der seit 2010 unveränderten Desktop-Oberfläche.

• Dabei haben sich um zehn Wikis gemeldet, die bereit sind, auf ihrem Wiki Änderungen zu erproben und auswerten zu lassen.
• Die Erfahrungen dieser Wiki-Communities werden danach global für sämtliche Wikis einheitlich umgesetzt. Ansichten der deutschsprachigen Wikipedia sind dann irrelevant.
• Insbesondere ist zu erwarten, dass für nicht angemeldete Leser die Oberfläche deutlich gestrafft und reduziert sowie voraussichtlich auch eingeklappt wird.
• Was für angemeldete Benutzer passieren soll, bleibt abzuwarten; es werden aber wohl in jedem Fall die Funktionalitäten inhaltlich sauberer gegliedert umsortiert.
• Generell gilt die Desktop-Oberfläche von 2010 auch in Koexistenz mit der Mobil-Oberfläche und der zeitgenössischen Gestaltung von den Lesern vertrauter anderer Webseiten als Sanierungsfall.

Was mir schon vor der Umfrage klar war: Für die Autoren von 2005 muss alles auf ewig so bleiben wie sie es 2005 mal gelernt hatten. Der Rest der Welt einschließlich aller Nur-Leser hat sich nach ihnen zu richten.

VG --PerfektesChaos 01:28, 1. Mär. 2020 (CET)

Ich rate von der Umleitung des Datei-hochladen-Ziels auf einen direkten Commons-Upload immer noch dringend ab! Des Weiteren war das eine Umfrage, kein MB. Eine Umfrage dient nur dazu, um abzuschätzen, wie die Stimmungslage ein. Konkrete Handlungen können daraus keine resultieren. -- Chaddy · D 21:42, 1. Mär. 2020 (CET)

Eine direkte Commons-Verlinkung halte ich persönlich auch für schwierig. Eine Verlinkung auf eine Zwischenseite fände ich gut, die klarmacht, dass zwar das Gros nach Commons gehört, Dateien, die unter das Schutzlandprinzip fallen (u.Ä.), aber hier hochgeladen werden müssen. NNW 10:17, 2. Mär. 2020 (CET)

MBs sind keine Pflicht – wenn Konsens besteht, kann selbstredend auch ohne die Oberfläche modifiziert werden. --MGChecker – (📞| 📝| ) 12:18, 2. Mär. 2020 (CET)

*quetsch* An Umfragen nehmen aber stets nur recht wenige Leute teil, eben weil sie durchaus zu Recht der Ansicht sind, dass es ja nur eine unverbindliche Umfrage sei. Daraus dann einen Konsens ableiten zu wollen ist zu kurz gegriffen. -- Chaddy · D 15:41, 2. Mär. 2020 (CET)

• Mein ursprünglicher Vorschlag in der Portalseite lief darauf hinaus, die Direktverlinkung auf die hiesige Spezialseite im Portal-Rahmen ersatzlos zu streichen und nur noch über Bildertutorial, Hilfeseiten oder andere Projektseiten zum Hochladen zu führen; ersatzweise über Spezial:Spezialseiten für Insider.
  • Dadurch sollen Hochlade-Interessenten sich vorher Gedanken über Rechte, unerwünschte Bilder und auch die Wahl des geeigneten Wikis machen.
  • Die „Zwischenseite“ wäre gerade die Anleitung, die sowas erklärt, und davon haben wir bereits diverse. Tendenz der Umfrage ist jedoch, dass sich für die Hardcore-Autoren von 2005 nichts ändern darf, was sie 2005 mal gelernt hatten, und es deshalb keinerlei zusätzlichen Klicks und zwischengeschalteten Menüs wie Spezial:Spezialseiten geben dürfe, sondern für sie alles mit nur einem Klick erreichbar bleiben solle.
• Die Direktverlinkung im Portal stammt von 2003/2004 und damit aus einer Zeit, als es noch gar keine großen Anleitungen gegeben hatte, und auch Rechtsfragen in DACH unterschiedlich als auf dem gerade erst begründeten Commons steckten noch in den Kinderschuhen.
• Weil alles auf ewig so bleiben muss, wie es 2005 mal gewesen war, auch wenn es inzwischen um die 200 Spezialseiten gibt und seinerzeit noch kein Dutzend, die man mal alle einzeln im Portal direkt zu verlinken gedachte, sieht der Rahmen halt noch so aus wie 2005/2010 stehengeblieben.
• Auf WP:NEU #Version 1.35.0-wmf.21 steht inzwischen bereits die Ankündigung des Legacy-Vector, welches den Zustand von 2010 einfriert, während Vector sich davon abkoppeln wird und Schritt für Schritt zunächst für nicht angemeldete Besucher die Modernisierung vollziehen wird.
• Kein Admin ist verpflichtet, ein Ergebnis der Umfrage umzusetzen, das als nicht zielführend eingeschätzt wird.

VG --PerfektesChaos 12:54, 2. Mär. 2020 (CET)

Diesen Vorschlag halte ich für sinnvoller als einen direkten Commons-Link.

Ein bisschen weniger auf uns alte Hasen zu schimpfen wäre allerdings auch nicht verkehrt. -- Chaddy · D 15:44, 2. Mär. 2020 (CET)

wikEd

Ich habe eben den „wikEd“ unter den Helferlein in den Einstellungen ausprobiert. Dieser editor ist eine einzige Katastrophe. Ein Beispiel: Wenn ich auf der Disk signieren will, lande ich - ohne es zu zu beabsichtigen - in der Überschrift des Threads. Auch andere schwerwiegende Fehler traten auf. Die Programmierung ist sehr fehlerhaft. Kann der wikEd bitte sofort aus der Liste der empfohlenen Helferlein entfernt werden?!!! (Ich hoffe, ich bin auf der richtigen Seite für so ein Problem gelandet.) Gruß --Orik (Diskussion) 23:47, 4. Apr. 2020 (CEST)

Du bist auf einer durchaus zur Erörterung geeigneten Seite gelandet.

Der wikEd funktionierte wohl ein Jahrzehnt lang recht gut.

Dies unbeschadet durchaus kritikwürdiger und riskanter Programmierpraktiken; sowie der klaren Beschränkung auf eine spezielle Browser-Architektur. Ist aber bei einem Riesendingens wie diesem als ehrenamtliches Solo-Werk kaum zu vermeiden, zumal die Anfänge von wikEd in einem völlig anderen Zeitalter lagen und dies immer wieder deutlich modernisiert wurde.

Bekannt ist allerdings, dass der ein Jahrzehnt lang unermüdlich schuftende Entwickler in jüngerer Zeit wohl recht inaktiv war, insbesondere keine Anpassungen mehr vornahm.

Die dortigen Erörterungen in der englischsprachigen Wikipedia wären für unser weiteres Vorgehen maßgeblich; also Benutzer- bzw. Projektseiten.

Die erste Stufe nach erster Erkenntnis wäre jedoch nur ein allgemeiner Warnhinweis auf Wikipedia:Technik/Skin/Gadgets/wikEd.

Es ist jedem unserer Bearbeiter freigestellt, das Dings wieder wegzuhakeln, wenn es beim eigenen Browser nicht (mehr) korrekt funktioniert. Es ist keine Default-Option, die wir allen Benutzern aufzwingen würden.

Erst bei nachhaltiger unreparierter schädigender Funktion würden wir unser Gadget durch irgendeine Form von Fehlermeldungsbaustein ersetzen bzw. dahingehend ändern, da wir ohnehin nur nach einigen Vorbereitungen das englischsprachige Gadget laden.

VG --PerfektesChaos 13:56, 5. Apr. 2020 (CEST)

Neues Gadget: markLinks

Funktion

Markierung von Wikilinks.

Insbesondere Zuordnung von Benutzern zu bestimmten Gruppen.

Kompatibilität

Heißt: Neukonzeption von Benutzer:PDD/markAdmins.js

Alle dort bisher verwendeten Benutzerkonfigurationen sollen verstanden werden.

Das Ergebnis soll bis auf Kleinigkeiten und Updates unverändert sein.

Konfiguration

Fundamentaler Unterschied: Die Spezifikation der Gruppenzugehörigkeit einzelner Benutzer soll nicht mehr in einem JavaScript-Code erfolgen, sondern per Wikitext im MediaWiki-Namensraum.

Damit kann wieder jeder Admin die Gruppenzugehörigkeit aktualisieren.

Beispiel auf WP:BETA

Zurzeit werden BOA für die Aktualisierung benötigt.

Der definierende Wikitext kann angezeigt werden; Beispiel

Gadget-Organisation

Die Gadget-Spezifikation von markLinks soll als hidden Gadget hinterlegt werden.

Das bisher von den Benutzern konfigurierte Gadget markAdmins soll dann einbinden:

1. Kompatibilitäts-Code zur Interpretation von Konfigurationswerten
2. markLinks

Implementierung

Zurzeit nicht online.

Konzeption umsetzbar.

Stumpfsinniges, routinemäßiges Runterhacken der einen oder anderen 1000 loc fehlt noch.

Die Umsetzung hängt von der Diskussion in diesem Abschnitt ab.

Anwenderkonfiguration

Vielfältige individuelle Anpassungen können unterstützt werden:

• Alle bisherigen.
• Namensräume:
  • Hinzufügen: Ich will auch im ANR oder in meinem Portal die Signaturen von QS-Bausteinen oder Forumsbeiträge markiert bekommen.
  • Unterdrücken: Auf Dateibeschreibungsseiten will ich aus Performancegründen kein Theater; da interessiert mich das nicht.
• Optische Darstellung:
  • Andere Beschriftungen.
  • Farbkennzeichnung der Verlinkung (bunter Rahmen); dafür kein Text.
• Definition eigener Benutzergruppen und Zugehörigkeiten.

Erweiterung

Konzeptionell ist dies auf alle Namensräume ausdehnbar; also nicht nur auf verlinkte Benutzer.

Vorstellbar wären exzellente, lesenswerte Artikel usw.

Woher eine performante Datenversorgung herkäme stünde auf einem anderen Blatt.

Die technische Infrastruktur ist primär unabhängig von den Namensräumen der Wikilinks.

Selbst URL kämen in Frage, also Domains sowie bestimmte pattern bei bestimmten Domains.

Internationalisierung

Stammcode global einsetzbar; alle Sprachen und Schriften und Projekte.

VG --PerfektesChaos 15:01, 12. Jul. 2020 (CEST)

Wäre zur Konfiguratiion eine JSON-Seite nicht geeigneter? Das sollte deutlich einfacher zu parsen sein, kann (afaik) nicht korrput gespeichert werden, und kann perspektivisch per ResourceLoader in das Gadget geladen werden. --MGChecker – (📞| 📝| ) 20:11, 12. Jul. 2020 (CEST)

Das möchte ich aus mehreren Gründen bewusst nicht:

• Eines Tages geht das harmlosere editsitejson auch noch flöten, und dann sind wir wieder bei den BOA, von denen ich grad weg will;
• das Wikitable-Format ist für Non-Techies sehr viel intuitiver als JSON, und es ist auch robust gegen Syntaxfehler; dann hätte halt mal ein Eintrag keine Dekoration, aber der Rest funktioniert;
• die Wikitable lässt sich sofort und auf low level darauf überprüfen, ob bei eingeschaltetem Gadget die Dekoration übereinstimmt mit den Angaben in der Spalte daneben;
• die Wikitable erlaubt beliebige Kommentare, Standard-JSON null;
• die Wikitable lässt sich unabhängig vom Gadget beliebig für Übersichten durch alle nutzen und rumsortieren;
• statt einer MediaWiki:-Seite ließe sich, auch in anderen Projekten oder für andere Zwecke, genauso eine normale Projektseite verwenden. Könnte dann jetzt schon normale Projektseite unter Dreiviertel sein, aber die Administration der Administratoren organisieren die mal besser selbst unter sich. Im JSON-config steht übrigens noch kein Eintrag, wo die aktuelle Definition abgeholt werden kann.
• Das Parsen einer solchen Wikitable ist in ein paar Zeilen gemacht und fällt gegenüber dem Gesamtaufwand nicht ins Gewicht. Wegen Performance passiert im Hintergrund sehr viel mehr (Caching einer “byte-compiled” aufbereiteten Version). Deshalb interessiert mich auch das Laden der Ressource nicht. Der Abruf vom Server ist der gleiche Aufwand, ob nun ein Seiteninhalt raw oder eine message.

Danke gleichwohl fürs Mitdenken --PerfektesChaos 20:53, 12. Jul. 2020 (CEST)

Ich habe mir das auch mal angeschaut. Im Prinzip halte ich das für eine sinnvolle Idee. Die Definition per Wikitable ist erstmal ungewöhnlich, aber hat wie dargestellt auch Vorteile. Anwendbar wäre das 1:1 auch auf User:Anka Friedrich/markMentors.js, woraus sich meine Hauptfrage ergibt: bleibt eine benutzerspezifische Konfigurationsmöglichkeit erhalten? Ich nutze das Skript seit meiner Kontenmetamorphose nicht mehr, kann mich aber erinnern, dass einige gern auf die Exen-, Commons- oder Wikidata-Admin-Markierung verzichten wollten (genauso sind auch Mentoren nicht für jedermann von Belang) oder die Markierung lieber hochgestellt unfett etc pp. haben möchten. Das zweite könnte man per CSS und Klassenbezeichner regeln, das erste aber nicht. Und: bisher wurden die Markierungen immer innerhalb des Benutzerlinks eingefügt, also ohne Extraverweis zu Admins, BOAs, Stewards etc. Gruß, -- hgzh 18:28, 13. Jul. 2020 (CEST)

TL;DR: Ja.

Man müsste sich nur mit einer race condition herumplagen, bzw. dürfte nicht gleichzeitig über Einstellungs-Häkchen das traditionelle markAdmins starten. Weil, wenn der dann startet, dann würde einmal geflöht, und wer zu spät kommt, den bestraft das Leben.

Es dürften jedoch beliebig oft Definitionen abgefeuert werden, die projekt-offizielle ist nur eine unter gleichberechtigten, und ein Objekt könnte auch statt einer wikitable oder JSON-Seite direkt gefeuert werden.

Wenn man sich sicher ist, dass alle gewünschten Definitionen in der Warteschlange stehen, dann müsste das markLinks zum Schluss geladen werden, und das futtert dann alle angesammelten Definitionen und arbeitet sie ab.

Die vorgesehene markAdmins-Nachfolge-Implementierung würde auch nichts anderes machen als Kompatibilitäts-Optionen zu generieren und abzufeuern, die amtlichen Definitionswünsche abzufeuern, und zum Schluss das ausführende Gadget zur Abarbeitung aufzufordern.

Sollte dann nur keine Konflikte um Buchstaben-Codes geben, oder Design oder sonstige Konfigurationen.

Ob eine Definition von einer Benutzer- oder Projektseite käme, aus MediaWiki: oder in JSON oder Wikitext oder implizit als Objekt mit abgefeuert wird ist völlig egal. Es käme jedoch ggf. auf die Reihenfolge an.

Das markMentors hatte ich vor Jahren mal gesehen und vielleicht implizit im Hinterkopf, aber jetzt dieser Tage nicht von dort vor Augen geholt. War jedoch grundsätzlich mitgemeint. Müsste dann wissen, ob es für diesen Anwender ein markMentors+Admins oder ein markMentors ohne Admins werden solle.

Zu Präsentationsfragen:

• Das A ist in Simulation und JSON-Definition nicht mit einer Verlinkung unterlegt.
• Bei Gebilden wie Omb, so mal angetroffen, halte ich eine erklärende Verlinkung nebst Tooltip jedoch für sehr sinnvoll. Was war jetzt nochmal dieses S wenn es nicht in SG drinsteht? Auch jemand, der mit den Sonderfunktionen nicht so vetraut wäre und nicht sowieso auswendig alle Admins alphabetisch aufsagen kann, kann ja das Gadget aktiviert haben, um zu wissen, wer ihm da gegenübertritt. Hier wird man seltenere unktionsträger nicht herunterbeten können.
• Es ist auch alles konfigurierbar und muss auf jedes Wiki in jeder Schrift passen.
• Grundsätzlich sehe ich mich nicht dazu verpflichtet, jedes Pixel auf ewig exakt auf dem Stand von 2008 zu konservieren und jede verbesserte Funktionalität konsequent abzublocken weil früher hatten wir das ja auch nicht gehabt.

VG --PerfektesChaos 12:56, 14. Jul. 2020 (CEST)

Steward. --Count Count (Diskussion) 13:31, 14. Jul. 2020 (CEST)

Danke verbindlichst für diese Erläuterung an mich privat, aber das Gadget würde ja auch von weniger erfahrenen Benutzern eingebunden, die nicht alle diese Exoten und Codes sicher herunterleiern könnten. Auf der Simulation findest du das unmittelbar vor gell? mit Tooltip und verlinkt. VG --PerfektesChaos 14:28, 14. Jul. 2020 (CEST)

Ich finde das sehr interessant. Schade, dass das hier anscheinend eingeschlafen ist. Wie sieht das in Sachen Serverbelastung aus (Cache)? Auch im Vergleich zum Skript und der – von mir zusätzlichen genutzten und anscheinend noch gar nicht erwähnten – Möglichkeit ggu? — Speravir – 00:22, 12. Feb. 2021 (CET)

ggu verwende ich selbst seit Jahren.

Was der Verweis auf den Server-Cache bedeuten soll, ist unklar. Er hat mit dem gesamten Themenkomplex absolut nichts zu tun.

ggu wertet die im System hinterlegten Informationen aus. Damit ist es per se ungeeignet für:

• SG
• Ex-
• Mentoren
• Nur theoretisch für Com-A, en-A, WD-A usw.
  • Dies bedingt dann jedoch, dass auch alle 1000 Admins der enWP in die CSS-Regel aufgenommen werden müssten, und alle Commons- und WD-Admins auch. Könnte man machen, wird aber etwas übersprudelnd.

VG --PerfektesChaos 08:19, 12. Feb. 2021 (CET)

Caching einer Wikiseite versus eines Skriptes versus eines extern abzurufenden Stylesheets. Caching verringert normalerweise die Serverbelastung, könnte ja sein, dass das auch eine Rolle für die Darstellungsgeschwindigkeit spielt (ggu brauch immer einen Moment). Durch das Caching kann es sein, dass jemand einen veralteten Stand angezeigt bekommt, worauf man kurz hinwiesen sollte (Hilfe:Cache gibt’s ja schon). Mir ging es um den Vergleich, wenn das egal ist, um so besser.

ggu habe ich nur als eine bereits existierende Teilalternative erwähnt, die mehr – nein, besser: – andere Markierungen erlaubt als markAdmins. Du hast aber Recht, dass sie für einiges, was dir an Sinnvollem vorschwebt, nicht geeignet ist. — Speravir – 22:40, 12. Feb. 2021 (CET)

„Caching einer Wikiseite“

• Das hat aber völlig nullkommanullnullnullnull mit dieser gesamten Angelegenheit zu tun.
• Im Cache des Wiki-Servers steht ein HTML-Schnipsel, nämlich der Inhaltsbereich, der aus dem Wikitext generiert wird. Bei Spezialseiten, wo auch sehr häufig Admins usw. zum Markieren auftauchen, gibt es überhaupt keinerlei Cache und der Inhaltsbereich wird spontan generiert. Dieser Inhaltsbereich wird im Moment der Anfrage in den je nach Benutzer und Namensraum unterschiedlichen Portalrahmen eingebettet.
• Der Server liefert immer das gleiche HTML-Dokument aus und hat mit der Angelegenheit hier absolut nichts zu tun.
• Alle Dekoration, sei es über JavaScript wie traditionell markAdmins oder hier neu vorgeschlagen markLinks oder aber per CSS mittels ggu passiert im Client; das ist der Browser des Lesers, und modelt nachträglich das vom Server ausgelieferte immer gleiche HTML-Dokument nur für diesen Leser um.
• Die Ressourcen-Codes aller JavaScript oder CSS stehen sowieso im Browser-Cache des jeweiligen Lesers, werden ohnehin nicht jedes Mal neu übertragen, sondern die von der WMF stammenden Ressourcen werden nur kurz abgefragt ob die Version noch aktuell wäre; bei ggu passiert das einmal pro 24 Stunden.

„ggu brauch immer einen Moment“

• Das liegt daran, dass bei Eintreffen von CSS-Regeln, sei es im Original-HTML-Dokument oder später wirksame Gadgets, jede Regel gegen alle Elemente im Dokument geprüft werden muss, und bei den zutreffenden dann die entsprechende Dekoration angewendet wird.
• Mit je mehr CSS-Regeln man sich zukippt, desto länger dauert es bis alle Regeln für alle Elemente umgesetzt wurden.
• Deshalb steht auch im allerersten Text-Abschnitt dieser Seite eine Epik, die darlegt, warum es Dummfug ist, über 20 Millionen Seiten Regeln auszukippen, die nur in 0,0001 % der Seiten wirksam sind und ansonsten ins Leere gehen.

„für einiges, was dir an Sinnvollem vorschwebt“

• Das ist nicht das, was mir „an Sinnvollem vorschwebt“, sondern SG, Ex-, Com-A, en-A, WD-A usw. ist Kompatibilität zum bisherigen markAdmins, dessen Funktionalität vollumfänglich erhalten bleiben soll.

VG --PerfektesChaos 17:15, 13. Feb. 2021 (CET)

Na, wenn das Caching keine Rolle spielt, um so besser. Dass das Skript die Möglichkeit besitzt, war mir beim Schreiben auf die Schnelle nicht bewusst, obwohl SG ja sogar standardmäßig aktiv ist. Es bleibt aber: Schade, dass anscheinend niemand das hier mit Nachdruck weiterverfolgt hat (ich meine jetzt nicht dich) – wohl, weil es mit markAdmins vordergründig funktioniert und den Leuten die Einschränkungen hinter den Kulissen nicht so klar sind. Aber apropos: BOA kann markAdmins ja nicht markieren … — Speravir – 00:03, 15. Feb. 2021 (CET)

Vorschlag: Interne http:// - Links als externen Link behandeln

Mit der Commons.css wird verhindert, das interne Verlinkungen als externe Links gekennzeichnet werden. Meiner Meinung nach ergibt es Sinn die internen http:// Links, da diese "nicht sicherer" sind, auch zu kennzeichnen. Die Zeilen "#mw-content-text a.external[href^="http://xxx.Wikiprojekt.org"]," sollten meiner Meinung entfernt werden. --𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 _{Rechte | Kenst du scho de boarische Wikipedia?} 13:32, 29. Aug. 2020 (CEST)

Nein, sehr viele Bearbeiter wissen nicht, wie sie Verlinkungen auf Seiten in Wiki-Projekten als Wikilink formatieren könnten, und geben sie als URL an, wenn es sich nicht um den einfachen Seitennamen der Clean URL handelt.

Damit das aber nicht andauernd als angebliche Nicht-Wiki-Verlinkung gekennzeichnet würde, stellen wir Ziele auf eine Wiki-Seite (bestimmter ausgewählter Projekte, insbesondere wir selbst) einheitlich als „intern“ dar.

Typische Beispiele:

• URL-Difflink anstelle von Wikilink (ohnehin noch in unterschiedlichem Farbschema, jedoch ohne Icon).
• Ganz fremdes Wiki anstelle von Wikilink hat sogar den Icon.

Hingegen: Echtes externes Weblink

VG --PerfektesChaos 15:35, 29. Aug. 2020 (CEST)

@𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫: Grundsätzlich stimme ich PC hier zu, trotzdem nochmal eine Verständnisfrage: Warum meinst du, diese Links wären nicht sicherer? — Raymond ^Disk. 19:18, 29. Aug. 2020 (CEST)

@PerfektesChaos, @Raymond http://Links sind unverschlüsselt. Https:// ist seit Jahren Standard und mindestens 99% der Difflinks werden entweder per Wikilink oder mit einem URL-Difflink mit https eingefügt. Die vorgeschlagene Änderung betrifft in der Regel nur alte Archive.--𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 _{Rechte | Kenst du scho de boarische Wikipedia?} 19:33, 29. Aug. 2020 (CEST)

@𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫: Richtig, wenn wir hier nicht schon seit Juli 2019 die MediaWiki-Erweiterung SecureLinkFixer hätten. Diese schreibt im Hintergrund jedes http auf https um, wenn die Webseite standardmäßig https verwendet. Und dies ist bei WMF-Seite auch schon länger der Fall. — Raymond ^Disk. 19:40, 29. Aug. 2020 (CEST)

Raymond, wenn die links sowieso geändert wird, ist der Css code sowieso hinfällig.--𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 _{Rechte | Kenst du scho de boarische Wikipedia?} 08:22, 30. Aug. 2020 (CEST)

Ich denke nicht, denn die Änderung erfolgt nicht im Quellcode, sondern nur beim Rendern der Seite. ich muss aber zugeben, ich weiß nicht, on welcher Reihenfolge da im Hintergrund was passiert. Das könnte man sicherlich im Betawiki austesten. — Raymond ^Disk. 10:01, 30. Aug. 2020 (CEST)

@Raymond Ich habe es gerade getestet der Code ist überflüssig und sollte entfernt werden. --𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 _{Rechte | Kenst du scho de boarische Wikipedia?} 14:50, 30. Aug. 2020 (CEST)

Es wird für die Leser die identische URL im HTML-Dokument produziert für:

• http://de.wikipedia.org/wiki/Wikipedia:Technik
• Wikipedia:Technik

Beachte, dass ich http: geschrieben habe; die MediaWiki-Software erkennt wie korrekt von Raymond dargestellt ein eng befreundetes WMF-Projekt und schreibt das bereits im generierten und ausgelieferten HTML-Dokument auf https: um.

Die obere Verlinkung ist jedoch mit der class="external" gekennzeichnet, und diese bewirkt, dass ein der Verlinkung nachgestellt würde. Damit wären jedoch in unseren Artikeln auf für die Leser unbegreifliche Weise manche Links auf einen anderen unserer Artikel mit gekennzeichnet und die meisten nicht, und das würde nur verwirren. Deshalb unterdrücken wir dann mit dem von dir benannten CSS diesen Icon. Und deshalb ist das auch mitnichten überflüssig, nie gewesen, nie geworden und auch nicht zu entfernen.

Solltest du dich übrigens zur Verbesserung ohnehin bearbeiteter Artikel dafür interessieren, wo im ANR eine URL-Verlinkung statt Wikilink-Format benutzt wurde, könntest du in ähnlicher Weise derartige Verlinkungen für dich persönlich hervorheben, etwa durch einen bunten Rahmen um den Linktext.

Nebenbei bemerkt führt eine URL-Verlinkung nicht zu einer Aufnahme in die Spezial:Linkliste , wovon beim noping gelegentlich bewusst Gebrauch gemacht wird. Damit sind solche Artikel jedoch nicht mehr aktualisierbar, wenn bei Einrichtung von BKS oder sonstiger Aufteilung des Artikels alle bisherigen Verlinkungen gesucht werden. Aus diesem Grund sind URL-Links auf Artikel im ANR massiv unerwünscht.

VG --PerfektesChaos 15:31, 30. Aug. 2020 (CEST)

@PerfektesChaos Siehe hier im barWiki gibt es nur den Eintrag "a.external[href^="https://xxx.Wikiprojekt.org"]" hier werden auch http links nicht markiert.--𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 _{Rechte | Kenst du scho de boarische Wikipedia?} 20:03, 8. Sep. 2020 (CEST)

js/css-Seiten gesperrter Benutzer

Hallo, dank Wurgl gibt es eine Liste mit unbeschränkt gesperrten Benutzern, die eigene JS-Seiten (CSS wäre analog) in ihrem Benutzernamensraum haben. Da sie normalerweise keine Wirksamkeit mehr besitzen und auch nicht mehr von ihren Eigentümern gewartet werden können, schlage ich vor, solche Seiten zu löschen, sofern sie nirgendwo eingebunden sind und es sich nicht um Editcounter-Aktivierungsseiten a la EditCounterOptIn.js handelt. Die Vorteile lägen vor allem darin, möglicherweise veraltete Skripte, Skriptteile oder Funktionsverwendungen loszuwerden und deren Copy&Paste zu verhindern. Auf Phabricator laufen ja immer mal wieder Listen mit von Änderungen betroffenen Seiten auf, die so verkürzt werden könnten. Als zweiten Schritt könnte man diese Aktion noch auf seit langem inaktive Benutzer mit entsprechendem Hinweis auf Wiederherstellungsmöglichkeit ausweiten. Was denkt ihr? Gruß, -- hgzh 12:07, 24. Nov. 2020 (CET)

Finde ich einen guten Vorschlag. Sollte in allen Fällen einen Standardlink auf eine Seite enthalten die beschreibt warum und wie man das wiederkriegen kann. Viele Grüße, Luke081515 12:14, 24. Nov. 2020 (CET)

Kannst du *.js-Seiten denn mit wikitext als Content erzeugen? Oder willst das auf der Benutzerseite machen? --Wurgl (Diskussion) 12:21, 24. Nov. 2020 (CET)

Ich würde die Seite einfach in der Löschbegründung verlinken. Das geht auf allen Seiten. z.B. "xy löscht Seite bla.js ([[Doku|Aufräumaktion Skripte gesperrter/inaktiver Benutzer]])" etc. Viele Grüße, Luke081515 14:04, 24. Nov. 2020 (CET)

Grundsätzlich begrüße ich das in stufenweiser Umsetzung.

• Zunächst mal dürfte sich innerhalb dewiki keine Einbindung durch andere, noch aktive Benutzer finden lassen. Was nicht ausschließt, dass es global irgendwo angefasst würde oder keine triviale auffindbare Zeichenkette verwendet wäre.
• Begonnen werden sollte mit infinit gesperrten und verstorbenen (haben die nicht auch infinit?) Benutzern. Langjährig (5, 10 Jahre) inaktive könnten nach ersten Erfahrungen folgen.
• Skripte aus der Zeit um 2010 sind heutzutage wegen zahlreicher Anpassungen an moderne Browsertechnologie und Konfliktvermeidung im globalen Namensraum der JS-Variablen nicht mehr lauffähig. Sie ziehen bei der mittlerweile möglichen globalen Protokollierung von Skriptfehlern (welche die Anwender selbst nicht mitbekommen, weil diese nur auf der Konsole und bei der WMF vermerkt werden) Wartungs- und Pflegebedarf nach sich.
• CSS würde ich außen vor lassen, bis sich ein ernstzunehmendes Problem einstellt (globale Info der WMF, dass dieser und jene Selektor nicht mehr unterstützt würde).

Ich würde allerdings anders vorgehen:

• Überschreiben der Seite mit einer neuesten Version, bestehend nur aus

 window.alert( "Du verwendest das Skript User:" +
               Bot-eingefügt   Account/subpage.js
               + "@dewiki. Dieses bedarf der Pflege." +
               " Bitte melde dich bei ..." );
 // Eingefügt von Administrator ...... 2020-12-01
 // Wenn du dein Skript reaktivieren möchtest, brauchst du bloß ...

• Wenn das irgendwo noch verwendet würde, müsste jemand aufschlagen.
• Wenn keiner mault ist es erstmal egal.
• Wenn ein User wiederaufersteht, hat er die Versionsgeschichte und kann schlicht revertieren.

VG --PerfektesChaos 14:37, 24. Nov. 2020 (CET)

Joa, diese Nachricht wäre dann möglich, wenn das Skript noch irgendwo eingebunden wird, ansonsten sieht es ja niemand. Gruß, -- hgzh 19:47, 6. Dez. 2020 (CET)

Es wird inzwischen interessant, die BNR-Ressourcen von vor 2011 wie skizziert abzudecken.

MediaWiki-Entwickler gehen inzwischen dazu über, bei nachhaltig ungepflegtem JS wie diesem aus der Zeit vor 2011 global in allen Wikis die Ressourcen zwangsweise umzuschreiben. Irgendwie peinlich, dass dieses Wiki das nicht selbst auf die Kette bekommt.

Die Abschaffung der den globalen Namensraum verseuchenden Konfigurationsvariablen von vor 2011 steht offenbar unmittelbar bevor; nach zehn Jahren Migrationsperiode.

VG --PerfektesChaos 17:25, 13. Feb. 2021 (CET)

Ich habe jetzt mal einen Rutsch eindeutiger Fälle von unfreiwillig Gesperrten und Verstorbenen per Löschung bereinigt. Für alle weiteren müsste man nochmal überlegen – ein Hinweis wie oben würde ja bei jedem Laden der Seite erscheinen, da sehe ich schon Fackeln und Mistgabeln auf mich gerichtet. -- hgzh 19:29, 13. Feb. 2021 (CET)

In diesem Fall stelle ich mich mit breiter Brust vor dich.

Eine Löschung ist ein heftigerer Eingriff, weil Wiederauferstandene ihn nicht beseitigen können.

Eine Seite nur mit Klartext-Kommentar und Bedienungsanleitung ist das mildere Mittel, erklärt nochmal was los ist, kann vom Account unbürokratisch revertiert und durch die VG gebraust werden, und wenn wer zurückkommt dann mag man auch auf FZW oder TWS sich erklären lassen was los ist.

Ich bin grad hundemüde, aber zu morgen kann ich dir ersatzweise zum window.alert() eine narrensichere console-nicht-console-warning-nicht-warning-dann-log aufschreiben, die für den Fall eines von weißdergeierwoher aufgerufenen Skriptes immerhin einen Hinweis in der Konsole hinterlässt. Die kein Normalbenutzer zur Kenntnis nimmt, aber wenn es kein alert() sein soll bliebe nur diese ulkige mw.notification, mit der ich aber auch noch nie gearbeitet habe und die ich morgen nachmittag erstmal auf BETA ausprobieren müsste.

Würde heißen: Dauerhafter Konsoleneintrag und 5 Sekunden Einblendung, falls es noch Anwender geben sollte.

VG --PerfektesChaos 20:11, 13. Feb. 2021 (CET)

Irgendetwas nicht so aufdringliches wäre mir schon lieber. Ich lasse gerade die Query mit aktuellem Stand durchlaufen und rasiere dann nochmal die eindeutigen Fälle runter, anschließend könnte man dann die Seiten der freiwillig Gesperrten entsprechend mit einem Hinweis ausstatten. Ich denke auch über eine Wartungskategorie für solche Seiten nach, etwa Kategorie:Benutzer:Skriptseite deaktiviert, zum Ausklammern bereits besuchter Seiten bei späteren Iterationen.

Nb: funktionieren eigentlich solche Weiterleitungen skriptseitig? -- hgzh 11:09, 16. Feb. 2021 (CET)

• Schon wieder einer; die machen jetzt Ernst.
• Kategorisierung funktioniert; guté Idee.
• Diese Wikitext-Weiterleitungen wären gaga, das muss was mit mw.loader.load() sein (sie tauchen allerdings als verlinkte Seiten auf).
• Bin am Wochenende durch zwei frische dicke Hunde auf meiner ToDo-Liste und in meinen geistig wachen Stunden gestört worden. Es werden jeden Tag mehr neue Initiativen gestartet als ich Rückstände abarbeiten kann. Inzwischen nachgeforscht:

//////////////////////////////////////////////////////
// Dieses Skript wurde wegen Überalterung deaktiviert.
// Eingefügt von Administrator ...... 2021-03-18
// Wenn du dein Skript reaktivieren möchtest, brauchst du bloß ...
//////////////////////////////////////////////////////

( function ( mw ) {
   "use strict";
   var s = "################   Account/subpage.js      ##############";
   s = "Du verwendest das Skript User:"
       + s
       + "@dewiki.\n"
       + " Dieses bedarf der Pflege.\n"
       + " Bitte melde dich bei: w:de:WP:FZW";
   if ( typeof window.console  ===  "object"
        &&     window.console ) {
      if ( typeof window.console.warn  ===  "function" ) {
         window.console.warn( s );
      } else if ( typeof window.console.log  ===  "function" ) {
         window.console.log( s );
      }
   }
   if ( typeof mw  ===  "object"
        &&     mw   &&
        typeof mw.notify  ===  "function"  ) {
      mw.notify( s,  { autoHide: false } );
   }
}( window.mediaWiki ) );

// [[Kategorie:Benutzer:Ressourcenseite deaktiviert]]

VG --PerfektesChaos 15:23, 17. Feb. 2021 (CET)

Danke, ich werde das die Tage testen und dann mal beginnen. Das s kommt mir doppelt genutzt vor? Übrigens zum Thema ein kürzlicher Blogpost: Sailing Steady - How you can help keep Wikimedia sites Error-free, unter anderem mit der Empfehlung: User scripts should expire after a certain period and when users retire and no longer maintain them. If a user script hasn’t been edited in over 5 years for example, a bot should blank the page. Gruß, hgzh 11:33, 17. Mär. 2021 (CET)

Die erste Zuweisung var s = "Account/subpage.js"; ist die einzig variable Stelle im ansonsten konstanten Text einer Serie und ist dafür gedacht, das vielleicht irgendwie halbautomatisch ausfüllen zu können.

• Die zweite Zuweisung s = "Du verwendest das Skript User:" + s + "@dewiki.\n" bettet die erste, variable Zuweisung in einen konstanten Rumpf ein. Der wird dann relativ narrensicher kommuniziert.

Die Verlinkung ist irgendwie putt. Da sind gemäß englischer Typografie hair space um den en-dash gelegt. Das heißt, wenn es denn ein en-dash wäre, ist aber ASCII U+002D.

• Der Interwiki-Link löst aber gemäß Standard-Algorithmus hair space wie alle anderen Leerzeichen in _ auf.
• Die Seite ist aber nur mit zwei U+200A erreichbar.
  • wmfblog:2021/03/08/sailing-steady - how-you-can-help-keep-wikimedia-sites-error-free/ – Interwiki mit hair space geht nicht.
  • https://diff.wikimedia.org/2021/03/08/sailing-steady - how-you-can-help-keep-wikimedia-sites-error-free/ – der gleiche Pfad als URL.
• Die dümmlichste Idee, die mir in den letzten Wochen unterkam, war die Benennung eines Blogs als „Diff“.

Die zitierte Empfehlung ist nur halbgar.

• Es gibt relativ schlichte Skripte, die funktionieren auch noch nach zehn und fünfzehn Jahren ohne Maintainer.
• Kritisch war die Wende im globalen Namensraum um 2010, und die Einführung des mw-Objekts. Was älter ist, braucht Anpassung zur Migration der wikibits-Ära 2004–2010.
• Je komplexer, je mehr Screengrabbing, desto wahrscheinlicher wird Wartungs- und Anpassungsbedarf.
• a bot should blank the page – auf blank the page läuft das da oben hinaus, nur luxuriöser.
• Ist aber sowieso nur als private Einzelmeinung zu werten.
• Die Bug-Auswertungsmöglichkeiten muss ich mir mal genauer anschauen.
• Als allgemeine Empfehlungen alles ganz okay, aber Anweisungen zum Eingriff in den BNR sind ein anderes Kaliber.

VG --PerfektesChaos 21:16, 17. Mär. 2021 (CET)

Bzgl. s hast du Recht, da hab ich schief geguckt. Den Link muss ich mir morgen nochmal ausgeschlafen anschauen. Gruß, -- hgzh 21:23, 17. Mär. 2021 (CET)

Ich bin gegen die Löschung von js/css-Seiten freiwillig gesperrter Benutzer. Eine Sperrung hindert ja nicht daran, sich einzuloggen! Im Zweifel den Benutzer vorher auf seiner Disk ansprechen und hinreichend Zeit zur Reaktion geben. 84.137.67.241 22:15, 18. Mär. 2021 (CET)

Die Seiten sollen auch nicht gelöscht, sondern überschrieben werden, sodass sie sich bei Bedarf leicht zurücksetzen lassen. hgzh 12:58, 19. Mär. 2021 (CET)

float-right/float-left

Auf Geräten mit geringer Bildschirmbreite führt die aktuelle Definition der float-Klassen zu unschönen Ergebnissen. Insb. float-right führt in einer Vielzahl von Fällen zu Bildern die über den linken Rand hinausschauen (in diese Richtung kann man bekanntlich nicht einmal scrollen). Man sieht dies bspw. im Artikel Erster Weltkrieg oder Benton Street Bridge. Beheben lässt sich dies durch jeweils Einfügen von max-width: 100%; also Änderung des entsprechenden Teils von Mediawiki:Common.css zu

.float-left {
	clear: left;
	float: left;
	margin: 1em 1em 1em 0;
	max-width: 100%;
}
[…]
.float-right {
	clear: right;
	float: right;
	margin: 1em 0 1em 1em;
	max-width: 100%;
}

Ich habe dies in meine persönliche common.css aufgenommen und konnte noch keine negativen Auswirkungen entdecken. Liebe Grüße, KPFC 💬 23:10, 18. Jan. 2021 (CET)

Mag sein, mag nicht sein.

Die Auswirkungen können jedoch komplex sein und sind nicht trivial zu überblicken.

Intensive Recherchen bei MW und in anderen Wikis (en) sind zunächst erforderlich, um dies weiter zu analysieren. Es stellt sich auch die Frage, ob das Gesamtverhalten nicht einer Serie von Browserversionen oder einer einzelnen Engine zuzuordnen ist und nach einem Bugfix wieder verschwände.

Mir war bislang noch niemals ein Nachteil aufgefallen, und auch nicht in dem angeführten Beispiel.

Eine längere Beobachtungszeit durch individuelle Erprobung´ist zunächst erforderlich. Ich habe das in mein CSS aufgenommen und werde einige Wochen darauf achten; insbesondere auf vorstellbare Kollateralschäden. Mobilgeräte sind besonders zu untersuchen. Bislang hatte noch nie jemand von einem derartigen Problem berichtet.

Benton Street Bridge ist auch einfach schlecht gemacht. Die starren Doppelbilder sind ungeschickt, es ist keine Mindestbreite der verbleibenden Textspalte programmiert worden, und in #Baustellen­schweißungen und Betonierung sowie #Bürgersteig usw. sind zwei Einzelbilder starr nebeneinander layoutet worden. Intelligentes Design sähe anders aus; die Doppelbilder würden sich in zwei Bilder übereinander auflösen, sofern die Bildschirmbreite dies erfordert. Dafür ist allerdings teilweise zu wenig Text für zu viel Bild vorhanden. Nebenbei, warum eigentlich fest vorgegebene Auflösungen? Wir verwenden in der Regel raum- und ressourcensparende Miniaturbilder.

„führt in einer Vielzahl von Fällen zu Bildern die über den linken Rand hinausschauen“ – das weist eher auf ein anderes Problem hin, das nicht per CSS zu lösen ist: Autoren haben aus Jahrzehnten Desktop-Gewohnheit in Hunderttausenden von Artikeln überbreite und starre Datentabellen verbrochen, bzw. Layout-Tabellen für breite Bildschirme fest vorgegeben. Das lässt sich mit einer CSS-Deklaration auch nicht geradebiegen.

Danke für die Anregung jedenfalls.

VG --PerfektesChaos 01:02, 20. Jan. 2021 (CET)

In den angegebenen Beispielen sieht man es nicht mehr, weil ich die Vorlage geändert habe.

Vielleicht ist es bei erneuter Betrachtung doch leichter es in den konkreten Fällen zu beheben statt die common.css zu ändern, template-styles bieten da jetzt ja echte Möglichkeiten. Ich hatte auch in Erinnerung, dass starr eingebundene Bilder wie [[File:test.png|1000px|rechts]] zum gleichen Problem führen, aber das ist offensichtlich nicht mehr der Fall. Liebe Grüße, KPFC 💬 02:13, 20. Jan. 2021 (CET)

Statt der starren Doppelbilder in statischer Anordnung und fester Abmessungen und mit rücksichtsloser Zerquetschung der verbleibenden Textspalte wäre es in Benton Street Bridge die simple Lösung, Galerien zu zwei Bildern unterhalb des Textabsatzes anzuordnen. Die haben von Hause aus Miniaturbilder in Größe der aktuellen Benutzereinstellung, und wenn die Bildschirmbreite nicht ausreicht, dann werden sie untereinander angeordnet.

Gegen schlechtes Papier-Design mit dem Weltbild „Ich habe einen Desktop und ein breites Browserfenster und wer das nicht hat soll meinen Artikel dann halt nicht lesen“ hilft auch keine CSS-Frickelei. Das ist schon mit schmaler gezogenem Browserfenster (wie oft bei mir) katastrophal, dazu braucht das Smartphone nicht für erfunden werden.

VG --PerfektesChaos 16:11, 20. Jan. 2021 (CET)

Grundsätzlich: Ich habe in der Vergangenheit auch schon diverse Infoboxen dahingehend überarbeitet (mit max-width:100%), das Problem ist sicher nicht so selten (speziell sichtbar bei richtig schmalen Bildschirmen, die möglicherweise bald wieder mehr in Mode kommen). Die vorgeschlagene zentrale Lösung muss ich mir aber noch in Ruhe anschauen. Gruß–XanonymusX (Diskussion) 16:15, 20. Jan. 2021 (CET)

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)

prettytable im ANR vergrämen

Seit 2012 bis vor einem guten Jahr wurde daran gearbeitet, prettytable aus dem ANR, aus allen Vorlagen und allen aktuellen offiziellen Projektseiten zu eliminieren.

• Crazy1880, eine bekannte IP und diverse andere hatten daran mitgewirkt und Zigtausende rausgeworfen.

Alle paar Monate findet sich noch jemand, der die Klasse frisch im ANR verbaut.

• Manchmal IP (offenkundig von damals), manchmal Altgediente, die alle zwei Jahre einen Edit machen, auch seeehr langjährige Admins.
• Teils Stinkstiefel von Wikifanten mit sechsstelligem Editcount.
• Um auf der jeweiligen BD aufzuschlagen, und das zu erklären, fehlt meist die Kommunikationsbasis.
• Story im Lauf der Zeit.
• prettytable hatte 2006–2008 Bestand, seit 2008 ist es wikitable, aber es hat immer noch nicht jeder gerafft. Obwohl die Umstellung viermal so lange her ist wie die ursprüngliche Lebenszeit.
• Beliebtes Argumentationsmuster ist, dass alles, was 2007 mal richtig gewesen war, bis zur Sternenzeit 23456 durch das Projekt und MediaWiki unterstützt werden muss, und umzulernen sei eine absolute Zumutung.

Ich hätte deshalb gern in MediaWiki:Common.css nach der prettytable-Spezifikation:

/* Temporäres Vergrämen aus dem ANR */
.ns-0 table.prettytable::before {
   background-color: #FFFF00;
   content: "class=prettytable ist veraltet, wikitable verwenden";
   color: #FF0000;
}
.ns-0 .prettytable {
   background-color: #FF69B4;
   border: 1em solid #FF0000;
}
.ns-0 table.prettytable > * > tr > th,
.ns-0 table.prettytable > * > tr > td {
   border: 1em solid #FF0000;
}

Serviervorschlag

Zelle	Zelle	Zelle
Zelle	Zelle	Zelle

Wenn sich dann wer beschwert, und auf FZW aufschlägt, dem wird sich das auch durch den vorangestellten Meldungstext leicht erklären lassen.

Mittelfristig müsste die Eliminierung aus anderen Bereichen angegangen werden.

• Jetzt zum Jahreswechsel steht wohl grad das Ende der JavaScript-wikibits bevor, nach zehn Jahren Migrationszeit.
• Da gibt es wieder Aufstand – prettytable besser im Frühjahr 2022.
• Ein Artikel im Kurier sollte dazu auffordern, seinen BNR, seine Redaktionsseiten und WikiProjekt und Portal entsprechend durchzusehen.
• Wer nicht auf wikitable umstellen möchte, also Kopfzellen explizit färben, kann die neue Vorlage:Tabellenstile einbinden und gut ist.
• Zum Jahreswechsel 2022/2023 mag dann die Bereitstellung in MediaWiki:Common.css wegfallen. Dann ist die Tabelle halt ohne Linien und so; ist aber immer noch eine Tabelle.
• Diesem und jenem entnehme ich dafür gewisse Sympathie.
• Im ANR mögen Regeln .ns-0 noch einige Jahre weiterwirken. Ist halt ein Lernprozess, und da lernen manche schneller als andere.

VG --PerfektesChaos 02:18, 3. Dez. 2021 (CET)

Klingt soweit gut, ich warte noch ein Weilchen und setze das dann demnächst mal um. -- hgzh 22:55, 13. Dez. 2021 (CET)

 Ok ist live. -- hgzh 21:48, 23. Dez. 2021 (CET)

Keine Reklamationen eingegangen. VG --PerfektesChaos 17:44, 9. Feb. 2022 (CET)

Dieser Abschnitt kann archiviert werden. PerfektesChaos 17:44, 9. Feb. 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)

Gadgets aktionsabhängig

Wenn es bis Februar kein rollback gab, sollte wie nachstehend umgesetzt werden.

• Damit wird vermieden, dass mit jedem Seitenaufbau unnötig Gadgets gestartet werden, die erst anlaufen, und dann feststellen dass es nichts zu tun gibt, und sofort wieder beenden.
• Ggf. auch entsprechende Ausgründungen aus Common.js als hidden und damit deren weitere Verschlankung und höhere Performance.
• Neu ist actions= für MediaWiki:Gadgets-definition.
• Bitte meine nachstehende freihändig aufgesetzte Liste schon mal durchgehen, auf Erfassung aller sinnvoller actions checken, ggf. weitere eingrenzen:
  • Vorlagenmeister|actions=edit
  • wikEd|actions=edit
  • HotCat|actions=view
  • editMenus|actions=edit,upload?
  • editMenusDef|actions=edit,upload?
  • mediawiki.toolbar|actions=edit,upload?
  • LegacyToolbar2006|actions=edit,upload?
  • Extra-Editbuttons|actions=edit,upload?
  • Suchfokus-Hauptseite|actions=view
  • Pfeil-hoch|actions=view,edit
  • editsection-align-end|actions=view,edit
  • Personendaten|actions=view,edit
  • old-diff-style|actions=view,diff,edit
  • ReferenceTooltips|actions=view,edit
• Stolzer geistlicher Vater: phab:T204201

VG --PerfektesChaos 11:20, 7. Jan. 2022 (CET)

Scheint recht stabil zu sein, würde das die Tage umsetzen. supportsUrlLoad gibt es ja inzwischen auch, aber einen Anwendungsfall sehe ich nicht. -- hgzh 08:23, 9. Feb. 2022 (CET)

Fein, dann bitte gemäß folgendem Schlachtplan immer abwechselnd für die neuen hidden:

1. Du legst alle Ressourcenseiten mit den Schnipseln an.
2. Ich schreibe alle Dokus (dafür brauche ich die Ressourcen).
3. Wenn ich fertig, dann legst du die Beschreibungstexte an, die auf die Doku-Seiten verlinken; also solche Dinger
4. Danach die MediaWiki:Gadgets-definition ganz unten um alles auf einmal erweitern. Die Dokus enthalten zusätzliche spezifische Infos dafür.
5. In den Stunden danach die JS und dann die CSS Stück für Stück zurückbauen und auf ruckelfrei erhaltene Funktionalität prüfen.

Die obige Begrenzung der bereits existierenden ist davon nicht betroffen.

Ich habe grad noch zwei neue hinzugefügt.

Bis dann --PerfektesChaos 17:34, 9. Feb. 2022 (CET)

@Hgzh: Spezial:Diff/220105290 historysubmit ist eigentlich seit vielen Jahren veraltet, kann kaum einer in einer wirksamen URL nutzen, aber history muss unbedingt sein. Beide mit Komma schadet nichts. VG --PerfektesChaos 22:51, 11. Feb. 2022 (CET)

Ja, das war ein Test, da nach wie vor auf mw:Action präsent. Scheint aber identisch mit view zu sein. -- hgzh 22:57, 11. Feb. 2022 (CET)

So, ich bin erstmal durch und habe alles einmal durchgetestet. Ein paar Abweichungen zu deiner Liste oben gibt es, da z.B. wikEd auch Diffs beeinflusst. Wirklich relevant sind eigentlich nur edit, history und view. Mal sehen, ob Probleme auftreten. Die hidden-Gadgets kommen dann ein andermal dran. -- hgzh 23:44, 11. Feb. 2022 (CET)

Ja, das sollte jetzt erstmal eine Woche ruhen und auf FZW-Proteste warten.

MediaWiki:Gadgets-definition sollte bis dahin möglichst nicht angefasst werden, um Fehlerberichte nicht zu verfälschen.

Gleichwohl können die Ressourcen-Schnipsel der hidden bereits angelegt werden, ohne sie zu aktivieren, damit ich die Dokus darauf aufbauen kann.

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

Verschiedene hidden Gadgets

Zum Rückbau der MediaWiki:Common.css etc. schlage ich nunmehr die Auslagerung nachstehender Mini-Gadgets vor.

• Sie sollten in der Regel hidden sein; eine Konfiguration durch Benutzies ist kaum sinnvoll, wäre nur verwirrend und hamwajanochniejemacht.
• Möglichst alle auf einen Streich und im Zusammenhang mit der Februar-Aktion. Müssen wir nur einmal denken und brauchen uns nur einmal damit befassen.
• Ich übernehme die Dokus, sobald die CSS-/JS-Seiten angelegt wurden.
• hidden sollten später en bloc unterhalb der Admins geschrieben werden.

 Info:

• >99 % der Seitenabrufe sind view.
• Damit wirkt sich Auslagerung von edit deutlich auf die Masse des Publikums aus.
• Umgekehrt hätte eine Beschränkung auf view allein fast keine Wirkung. Jedoch ist namespaces= in der Pipeline, und in Kombination damit lässt sich was anfangen.
• CSS führt nicht zu allzu gravierenden Belastungen; auf ein paar Regeln mehr oder weniger käme es nicht an. Hingegen bewirkt der Start einer JavaScript-Anwendung immer eine deutlich messbare Verzögerung, und hierfür sollte mittelfristig jede vermeidbare Ausführung unterdrückt werden.

Anmerkung:

• /* Ist hier erstmal geändert, dauert es dank Cache eine Weile, bis die Änderungen bei allen Nutzern sichtbar oder, bei Fehlern, korrigiert sind. */
• Dieser Satz ist seit 2011 Nonsens. Eigentlich sogar vorher schon, aber da war tatsächlich noch ein Cache für CSS aktiv gewesen.
• Seit 2011 sorgt der RessourceLoader binnen rund einer halben Minute für Auslieferung und sofortige Wirksamkeit aktueller JS- und CSS-Ressourcen.

Disclaimer:

• Alle Codes (definition und auch JS) freihändig ungetestet.
• Unabhängiger Vorab-Test auf BETA empfohlen.

Hinweis zu winwr Scharfschaltung im Februar:

• Wegen enthaltener JS-Anteile zu wenig frequentierter Nachtstunde innerhalb einer Minute Definitionen aktivieren und gleichzeitig aus MediaWiki:Common.js löschen; weil sonst auf Hauptseite zwei Sprachlink-Geschichten. Dann besser eine Minute lang kein umstilisierter.

VG --PerfektesChaos 18:02, 7. Jan. 2022 (CET)

Nur kurz durchgeschaut, möglich wäre wohl noch old-movepage|actions=move. Kann ich gern Anfang bis Mitte Februar umsetzen. Gruß, -- hgzh 08:04, 10. Jan. 2022 (CET)

Jo, jo, soll erstmal ein paar Wochen zur allgemeinen Begutachtung hier stehenbleiben.

Wobei mir in Sachen Upload inzwischen nicht mehr so ganz klar ist, ob es das überhaupt gibt, wann es action ist und wann Spezialseite.

• Ich lade alle halbe Jahre mal einen Icon hoch, das nur auf Commons und dann gibt es da irgendeinen Wizard und ich weiß nicht so genau welche Konstellationen in Frage kämen.
• Es gibt mehrere TEXTAREA-Felder, und die sollen mit Sonderzeichen-Service usw. ausgestattet werden.
• Kann aber ggf. trotzdem bereits in MediaWiki:Gadget-uploadtools.js integriert werden, selbst wenn momentan noch view erforderlich. Das würde ich dann dahingehend neu schreiben, dass es synchron mit der benutzerdefinierten Abschaltmöglichkeit der Sonderzeichenfunktion, LegacyToolbar2006, Extra-Editbuttons diese ebenfalls bleibenlässt, sonst zuschaltet usw.
• Auf Phabricator hat man Blut geleckt, und sowohl mit namespaces=-1 wie auch irgendwann specialpages , das inzwischen auch herbeigesehnt wird, können die Konstellationen vom massenhaften ANR-view abgegrenzt werden.
• MediaWiki:Gadget-spezialBeo.js wäre danach der nächste Kandidat.

Ach ja, und in MediaWiki:gadgets-prefstext kann die Verlinkung mit „Weitere Helferlein vorschlagen“ raus. Erstens haben wir seit vor 2009 schon keine Gadgets mehr erfolgreich auf derartige Vorschläge aus dem allgemeinen Publikum hin neu eingerichtet, und außerdem wäre die Zielseite mittlerweile diese hier.

VG --PerfektesChaos 17:52, 10. Jan. 2022 (CET)

Angelegt:

• MediaWiki:Gadget-sourceEditing.css / MediaWiki:Gadget-sourceEditing.js
• MediaWiki:Gadget-desktopHauptseite.css / MediaWiki:Gadget-desktopHauptseite.js
• MediaWiki:Gadget-mobileHauptseite.css

Erstmal nicht angelegt:

• Prettytable: kann mE die zwei Jahre noch dort verbleiben, der Aufwand lohnt sich da doch nicht mehr wirklich
• specialInfo: das würde doch höchstens von vier, fünf Leuten genutzt, die sich für die Lintfehler interessieren. Meiner Meinung nach ein Fall für ein selbst einzubindendes Userskript, das nicht jeder bei actions=view bereitgestellt braucht.

Gruß, -- hgzh 17:59, 20. Feb. 2022 (CET)

Danke bis hierhin; ich mach mich im Verlauf der kommenden Woche dann mal auf die Strümpfe mit meinem nächsten Schachzug. VG --PerfektesChaos 18:41, 20. Feb. 2022 (CET)

sourceEditing

• MediaWiki:Gadget-sourceEditing.css
• Kommt von: /* +++++ 2. (a) SEITENBEARBEITUNG UND HOCHLADEN +++++ */
• sourceEditing[ResourceLoader|default|hidden|actions=edit,upload]|sourceEditing.js sourceEditing.css
• MediaWiki:Gadget-sourceEditing.js

// <nowiki>
/* global window: false                                                */
/* jshint bitwise:true, curly:true, eqeqeq:true, latedef:true,
          laxbreak:true,
          nocomma:true, strict:true, undef:true, unused:true           */
( function ( mw, $ ) {
   "use strict";
   $( function() {
      $( "#wpSummary" ).val( function( i, s ) {
            var re;
            if ( s.length > 3  &&
                 s.substring( 0, 2 ) === "/*" ) {
               re = "\\{\\{[\\s_]*:?[\\s_]*(?:(?:Template|Vorlage)[\\s_]*:[\\s_]*)?Anker[\\s_]*\\|[^}]*\\}\\}\\s*";
               re = new RegExp( re, "gi" );
               return s.replace( re, "" );
            }
                                              } );
                 } );
}( window.mediaWiki, window.jQuery ) );
// </nowiki>

• Aus MediaWiki:Common.js

VG --PerfektesChaos 18:02, 7. Jan. 2022 (CET) ed. 17:52, 10. Jan. 2022 (CET)

desktopHauptseite

• MediaWiki:Gadget-desktopHauptseite.css

.page-Wikipedia_Hauptseite h1.firstHeading,
.page-Wikipedia_Hauptseite #contentSub,
.page-Wikipedia_Hauptseite #contentSub2,
.page-Wikipedia_Hauptseite #catlinks,
.page-Wikipedia_Hauptseite #p-wikibase-otherprojects {
	display: none;
}

• Kommt von: /* +++++ 3. [[Wikipedia:Hauptseite|HAUPTSEITE]] +++++ */
• desktopHauptseite[ResourceLoader|default|hidden|actions=view]|desktopHauptseite.js desktopHauptseite.css
• Erst dann Entlastungswirkung wenn namespaces=4 aktiv.
• Richtig knallt das, wenn auch transcludes= – damit ist die seitengenaue Fokussierung möglich.
• Hinweis: Die Desktop-Elemente des Portalrahmens liegen außerhalb des Inhaltsbereichs und sind TemplateStyles damit nicht zugänglich.
• MediaWiki:Gadget-desktopHauptseite.js

// <nowiki>
/* global window: false                                                */
/* jshint bitwise:true, curly:true, eqeqeq:true, latedef:true,
          laxbreak:true,
          nocomma:true, strict:true, undef:true, unused:true           */
( function ( mw, $ ) {
   "use strict";
   if ( mw.config.get( "wgIsMainPage" ) ) {
      mw.loader.using( [ "mediawiki.util" ],
                       function() { $( function () {
                         mw.util.addPortletLink( "p-lang",
                         mw.util.getUrl( "Wikipedia:Sprachen" ),
                                         "Alle Sprachen",
                                         "interwiki-completelist",
                                         "Liste aller Sprachversionen von Wikipedia"
                                       );
                                                   } );
                                  }
                     );
   }
}( window.mediaWiki, window.jQuery ) );
// </nowiki>

• Aus MediaWiki:Common.js

VG --PerfektesChaos 18:02, 7. Jan. 2022 (CET)

prettytable

• MediaWiki:Gadget-prettytable.css

.prettytable {
	background-color: #f8f9fa;
	border: 1px solid #a2a9b1;
	border-collapse: collapse;
	color: black;
	margin: 1em 0;
}
table.prettytable > * > tr > th,
table.prettytable > * > tr > td {
	border: 1px solid #a2a9b1;
	padding: .2em .4em;
}
table.prettytable > * > tr > th {
	/* background-color: #eaecf0; */
	text-align: center;
}
table.prettytable > caption {
	font-weight: bold;
}

• prettytable[ResourceLoader|default|hidden|actions=view,edit]|prettytable.css
• Erst dann richtig sinnvoll, wenn namespaces=1,2,3,4,5,100,101
  • Andere Namensräume haben sowas nicht mehr, oder wenn doch erforderlich (Hilfe:Tabellen/prettytable) dann kann es auch über Vorlage:Tabellenstile bereitgestellt werden.
• Der Abschrecker ist auf 2022/23 ausgelegt und sollte bis dahin für den ANR aktiv bleiben; dann kann der Spaß weg und das letzte Fossil müsste mal was seit 2008 dazugelernt haben.
• Längerfristig sollte prettytable aber komplett aus dem aktiven Projekt verschwinden.

VG --PerfektesChaos 18:02, 7. Jan. 2022 (CET)

mobileHauptseite

• MediaWiki:Gadget-mobileHauptseite.css
• Aus Mobile.css

VG --PerfektesChaos 17:34, 9. Feb. 2022 (CET)

specialInfo

• MediaWiki:Gadget-specialInfo.js
• Aus BETA
• Mit Beschreibung
• Temporär bis zur Umsetzung von phab:T301374.

VG --PerfektesChaos 17:34, 9. Feb. 2022 (CET)

Zuletzt bearbeitet in der Mobilen Ansicht

In der Mobilen Ansicht steht ganz unten sowas wie Zuletzt bearbeitet vor 19 Stunden von Aka. Das führt dazu, dass neue und unerfahrene Benutzer (und IPs) sich an den letzten Bearbeiter wenden. Sinn dieser Leiste ist ja die Erreichbarkeit der Versionsgeschichte (einfach mal draufklicken), muss da wirklich der Name des letzten Bearbeiters stehen?

Aka will sich daher in Benutzer:Ich habe hier zwar eine Kleinigkeit korrigiert, sonst mit dem Artikel aber vermutlich nicht viel zu tun umtaufen, schließlich taucht er ja in sehr vielen Artikeln als letzter Bearbeiter auf.

Ich schlage vor die Anzeige in dieser Zeile in "Zuletzt bearbeitet vor 19 Stunden" zu ändern. --Wurgl (Diskussion) 16:06, 9. Jan. 2022 (CET)

Es geht um MediaWiki:Mobile-frontend-last-modified-with-user-hours (Translatewiki). Leuchtet ein, ich wäre auch dafür, das lokal um das von {{PLURAL:$5|[$6 $2]|0=einem anonymen Benutzer}} zu kürzen. --XanonymusX (Diskussion) 16:53, 9. Jan. 2022 (CET)

Fänd' ich auch in Ordnung. -- hgzh 08:07, 10. Jan. 2022 (CET)

Ich habe das gerade geändert, sehe zumindest im Moment aber noch keine Auswirkung. -- Gruß, aka 10:54, 10. Jan. 2022 (CET)

Lokal ist das vielleicht nicht so toll oder doch? Es gibt da wohl 7 (oder mehr) Meldungen: translatewiki-Suche. --Wurgl (Diskussion) 11:19, 10. Jan. 2022 (CET)

OK, davon wusste ich nichts. Im Translatewiki habe ich noch nie etwas geändert und kenne da auch die Regeln nicht, nach denen man so etwas abstimmen müsste. Vielleicht möchten andere Wikis ja genau diese Anzeige haben? -- Gruß, aka 11:44, 10. Jan. 2022 (CET)

@Aka nur kurz zur Info: Im Translatewiki bitte immer genau wie das englische Original übersetzen. Anpassungen, wie hier lokal besprochen, auch nur lokal vornehmen, nie im Translatewiki. Wenn eine allgemeine Änderung des Systemtextes sinnvoll erscheint, muss die englische Systemnachricht im Git/Gerrit via Patch geändert werden. --Raymond ^Disk. 12:06, 10. Jan. 2022 (CET)

Die Meldungen mit den anderen Zeitangaben habe ich jetzt lokal ebenfalls angepasst, weiterhin aber ohne Auswirkung. Dann muss ich eben doch bei WP:BÄ vorstellig werden ;-) -- Gruß, aka 11:48, 10. Jan. 2022 (CET)

Nach etwas Warten funktioniert es jetzt, also war das nur ein Cache-Problem. Bzgl. des Translatewikis müsste sich aber jemand anderes kümmern. -- Gruß, aka 11:54, 10. Jan. 2022 (CET)

Nein, im Translatewiki würde ich das nicht ändern, die Nachricht hat immerhin hours im Titel, das sollten wir als lokale Ausnahme behandeln.—XanonymusX (Diskussion) 11:59, 10. Jan. 2022 (CET)

Hauptseiten-Titel

In Bezug auf die Hauptseite gab es zuletzt ein paar Neuerungen; Projektneuheiten 9. Dezember: Über die neuen Systemnachrichten MediaWiki:Mainpage-title und MediaWiki:Mainpage-title-loggedin kann der HTML-title (English: HTML element#title) der Wikipedia-Hauptseite definiert werden. Standardmäßig ist kein title definiert (Task 255682, Gerrit:743050). Seitdem bekam ich auf der mobilen Startseite wieder das Willkommen, XanonymusX! zu sehen, das wir 2020 per MediaWiki:Mobile-frontend-logged-in-homepage-notification eigentlich ausgeblendet hatten. Nachdem ich das jetzt für MediaWiki:Wikimedia-mobile-mainpage-title-loggedin übertragen habe, ist die Begrüßung zwar weg, dafür aber Wikipedia:Hauptseite wieder da. Blickt da jemand durch? Mein letzter Stand war, dass wir weder den einen noch den anderen Seitentitel in der Mobilversion sichtbar haben wollen, aber ich habe grad keine Ahnung, was da wie zusammenwirkt. --XanonymusX (Diskussion) 21:10, 10. Jan. 2022 (CET)

Deaktivieren mittels - führt zu einem Fallback auf den Seitentitel, wenn man die Systemnachricht leert, wird die Überschrift ausgeblendet. Ich habe das mal mit MediaWiki:Wikimedia-mobile-mainpage-title-loggedin gemacht, allerdings fehlt jetzt oben etwas margin zum Header. Gruß, -- hgzh 07:54, 11. Jan. 2022 (CET)

Den oberen Abstand habe ich etwas hochgesetzt. In der Desktop-Ansicht dürfte das weniger stören als das Fehlen in der mobilen Ansicht. --Wiegels „…“ 10:57, 11. Jan. 2022 (CET)

Ok, ansonsten muss eben noch eine Extraregel her für eins der beiden. Habe nun den Hauptseitentitel auch für unangemeldete noch mittels MediaWiki:Mainpage-title deaktiviert. -- hgzh 11:57, 11. Jan. 2022 (CET)

Puh, da blick mal einer durch. Schaut für mich jetzt gut aus. Sind die drei bisher deaktivierten Nachrichten damit obsolet? Und muss das jetzt wieder für alle Sprachen einzeln geändert werden (ich meine, ja)?—XanonymusX (Diskussion) 12:56, 11. Jan. 2022 (CET)

Ja, ich habe die Sprachversionen noch entsprechend angelegt. Ob man MediaWiki:Mobile-frontend-logged-in-homepage-notification noch braucht, keine Ahnung, bleibt nur zu probieren. Gruß, -- hgzh 13:04, 11. Jan. 2022 (CET)

Hm, habe mal die vier alten gelöscht und noch ein paar Sprachversionen für die neuen angelegt. Sprachunabhängige Definition scheint leider immer noch nicht möglich zu sein. Gruß --XanonymusX (Diskussion) 17:06, 12. Jan. 2022 (CET)

Grad nochmal getestet: mit einer leeren MediaWiki:Mainpage-title kann das Deaktivieren per firstHeading auf der Hauptseite entfallen, da wird von MediaWiki ein display:none eingefügt. -- hgzh 17:37, 20. Feb. 2022 (CET)

Und mit gerrit:752176 braucht es die Sprachunterseiten auch nicht mehr (würde sagen für Desktop und Mobil), da immer die Inhaltssprache genutzt wird (nl-Version). Der Umherirrende 00:18, 22. Feb. 2022 (CET)

Das war mir auch schon aufgefallen, hatte aber noch nicht ganz drauf vertraut ;) Danke! -- hgzh 07:25, 22. Feb. 2022 (CET)

Hey! ;-) Es funktioniert aber, zum Beispiel auf Wikidata gibt es nur die fa-Unterseite, aber bei allen anderen Sprachen fehlt der Header auch durch das direkte style="display: none" und nicht (nur) über die Common.css Der Umherirrende 20:32, 22. Feb. 2022 (CET)

Achso, versteh's nicht falsch: ich hatte deinen Change nicht gesehen, wohl aber am 20. seinen Effekt bemerkt, aber war mir nicht sicher, ob das nun Zufall war oder nicht. Kein Misstrauen gegenüber deiner Änderung, das wäre sehr anmaßend ;) Ich habe aber nun die Sprachvarianten wieder gelöscht. Gruß, -- hgzh 21:33, 22. Feb. 2022 (CET)

Nein, ich verstehe das nicht falsch, wollte aber auf deinen Smily mit einem Smily reagieren, daher hab ich das so geschrieben, aber da fehlt natürlich der entsprechende positiver Tonfall im geschriebenen um den Smily-Gesichtsausdruck nochmals zu unterstreichen ;-). Außerdem wollte ich dir auch bestätigen, das es kein Zufall ist (der sich nochmals ändern könnte), sondern das neue Verhalten so beabsichtigt ist. Danke für das Löschen der Unterseiten (wobei die bei MediaWiki:Wikimedia-mobile-mainpage-title-loggedin vermutlich auch weg können), damit sieht das für mich hier erledigt aus. Der Umherirrende 23:50, 23. Feb. 2022 (CET)

Dieser Abschnitt kann archiviert werden. Der Umherirrende 23:50, 23. Feb. 2022 (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)