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

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Navigations-Popup in Visual Diff

Seit einiger Zeit ist bei der Anzeige von Änderungen / Diffs ja die an sich sehr tolle visuelle Darstellung aktiv. Nur funktioniert in dem Modus das Helferlein "Navigations-Popups" über den Wikilinks im Text nicht mehr. Nur wenn ich auf den (alten) Wikitext-Modus umschalte, funktionieren sie.

Ist das ein Bug, oder muss man dafür etwas gesondert einstellen? --Hlambert63 (Diskussion) 13:52, 15. Apr. 2023 (CEST)

Edit: Scheinbar fehlen dort an den Links die Event-Listener für die Mausbewegungen.--Hlambert63 (Diskussion) 15:56, 15. Apr. 2023 (CEST)
Es handelt sich um ein von der enwiki gepflgtes Gadget, du müsstest daher auf en:Wikipedia:Tools/Navigation popups nachsehen bzw. fragen. Gruß, -- hgzh 18:48, 18. Apr. 2023 (CEST)
@hgzh Ah ja, okay, ich danke Dir, dann frage ich dort mal! --Hlambert63 (Diskussion) 19:33, 18. Apr. 2023 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: Wnme (Diskussion) 14:16, 19. Apr. 2023 (CEST)

Koordinaten übergangsweise in den Indikatorenbereich verschieben

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)

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)
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)
matmarex hat es freundlicherweise korrigiert, nun gut. -- hgzh 11:58, 26. Feb. 2023 (CET)
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)
  • 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)

matmarex hat es freundlicherweise korrigiert, nun gut.
  • Hat jetzt genau welche Konsequenzen?
VG --PerfektesChaos 16:54, 28. Feb. 2023 (CET)
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)

Migrationsprozess wurde mittlerweile gestartet.

--PerfektesChaos 17:11, 15. Mär. 2023 (CET)

Perspektivisch alles von rechts oben in normalen Wikitext überführbar.
VG --PerfektesChaos 17:41, 6. Jul. 2023 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: --PerfektesChaos 17:41, 6. Jul. 2023 (CEST)

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

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)

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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
@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)
citeRef.css ist live; common.css entsprechend bereinigt. -- hgzh 13:31, 6. Feb. 2023 (CET)
@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)
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)
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)
erledigtErledigt -- hgzh 21:07, 1. Mär. 2023 (CET)
Archivierung dieses Abschnittes wurde gewünscht von: hgzh 18:57, 18. Jul. 2023 (CEST)

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

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)

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)
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)
Archivierung dieses Abschnittes wurde gewünscht von: hgzh 18:57, 18. Jul. 2023 (CEST)

Admincon

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)

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

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

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)
Archivierung dieses Abschnittes wurde gewünscht von: hgzh 18:57, 18. Jul. 2023 (CEST)

Gadget-OpenStreetMap.js

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

Du hast nicht konkretisiert, in welchen Situationen, insbesondere auf welcher Seite du das bemerkt hast.
Das Werkzeug hat mehrfache organisatorische Probleme:
  • Es gibt keine technische Dokumentation zur Funktionsweise und zur Schnittstelle mit den Wikitexten; nur zum Einbinden des Gadgets durch Publikum.
  • Es gibt keine Anlaufstelle für den Komplex aus Gadget und Cloud-Tools, an das sich Techies wenden könnten.
  • Es gibt mutmaßlich keine aktive Maintainer.
Das Gebilde steht im Geist der Nuller Jahre.
  • Es wurde die damalige Welt der Desktop-Seiten in enWP und deWP als ewiger Maßstab genommen.
Insbesondere gibt es Anpassungsprobleme.
  • Es wird von einem Selektor id="coordinates" ausgegangen.
    • Es ist niemals offiziell definiert worden, dass dies ein reservierter Selektor ist.
    • Es ist niemals spezifiziert werden, mit welcher Wirkung dieser Selektor verknüpft sein soll.
    • Traditionell hat es zwei Wirkungen gleichzeitig:
      1. Das Element wird außerhalb des Inhaltsbereichs im Portalrahmen (und deshalb niemals auf Mobilgeräten) dargestellt; in stark verkleinerter Schrift zwischen Zeilen und Linien gequetscht.
      2. Die WIWOSM-Komponenten (JS-Gadget und Cloud-Tools) docken daran an.
    • Die beiden verknüpften Wirkungen lassen keine andere Funktionalität zu.
    • Nur genau ein einziges Element in der Seite lässt sich mit der Funktionalität ausstatten.
  • Es muss mit einem erweiterten Selektor-Konzept gearbeitet werden.
    • Die bisherige id="coordinates" bliebe zur Kompatibilität erhalten.
    • Es muss ein neuer Selektor definiert werden wie etwa: class="gadget-wiwosm"
      • Wir verwenden seit einem Jahrzehnt keine id= mehr, weil auch jede Abschnittsüberschrift diese auslöst; nur noch wenn auf ein Anspringen abgezielt wird.
      • Beliebig viele Elemente können parallel den Selektor erhalten.
      • Die Bezeichner müssen kollisionsfrei und global spezifisch für ihren Zweck sein. Ein allgemeines Wort coordinates ist nicht unverwechselbar und die Wirkung lässt sich nicht daraus ableiten.
    • Die strikt gekoppelten Auswirkungen „Darstellung in der Seite“ und „Das Werkzeug soll daran andocken“ müssen unabhängig voneinander werden.
  • Es können dann vom JS-Gadget mehrere Karten an der einen festgelegten Stelle verwaltet werden und zwischen noch nicht initialisierten oder bereits generierten hin- und hergeschaltet werden. Zurzeit ist nur genau eine einzige Karte vorgesehen.
  • Die Schnittstelle zu den Koordinaten und Fokussierung, die für die Generierung der Karte herangezogen werden soll, ist nirgendwo dokumentiert oder spezifiziert und kann deshalb nicht unterstützt oder gepflegt werden.
    • Es sind zukünftig neutrale Attribute des HTML-Elements vom Typ data-wiwosm="" zu verwenden, die lat,lon,dim etwa als Leerzeichen-getrennte Liste von Dezimalzahlen +/- bereitstellen.
    • Zurzeit werden die Koordinaten anscheinend den URL der an dieser Stelle verlinkten anderen Kartendienste entnommen. Das ist unzulässig statisch an andere URL gekoppelt und deshalb nicht zukunftsfähig.
  • Wir haben in unseren neuen Hinweiskästen genug Platz in normalgroßer Schrift. Wir könnten leicht auch ganz normale URL auf das Werkzeug anbieten, ohne auf angemeldete Konten beschränkte JS-Gadgets nunmehr für das gesamte Publikum und auch auf Mobilgeräten. Das muss dann allerdings wie die anderen Verlinkungen auch auf einer neuen HTML-Seite das Ergebnis darstellen, wenn kein JS-Gadget aktiv ist. Eine derartige Schnittstelle ist offenbar nicht im Angebot.
VG --PerfektesChaos 12:14, 19. Mai 2023 (CEST)
--WikedKentaur (Diskussion) 12:43, 19. Mai 2023 (CEST)
Kann ich nicht bestätigen, die Karte wird nachgeladen, dauert nur etwas. -- hgzh 19:27, 23. Mai 2023 (CEST)
Das war tatsächlich ein Problem im OSM4Wiki-Toolstack, ich hatte es zufällig bei FzW mitbekommen und behoben. --DB111 (Diskussion) 21:15, 23. Mai 2023 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: hgzh 18:58, 18. Jul. 2023 (CEST)

Änderungen Sichtungsbox

Ich sitze an der Nacharbeitung der Änderungen aus phab:T191156. Hatte mich heute Nachmittag mit dem Kollegen ausgetauscht, wodurch morgen zumindest zwei der ungewollten Effekte behoben sein sollten. Der Rest folgt. Daher würde ich morgen dann schon mal MediaWiki:Common.css#L-388 aktualisieren, also zu: 

#mw-fr-reviewformlegend .cdx-text-input {
   display: none;
}

Es liegt noch einiges im Argen, speziell die Interaktion mit VE ist gerade sehr komisch, aber wird schon werden. Eventuell könnten wir noch die Rotfärbung beseitigen, das scheint mir von vielen gewünscht zu werden. --XanonymusX (Diskussion) 18:55, 5. Jul. 2023 (CEST)

gerrit:935768 schafft es aber höchstens ins Deployment-Fenster nächsten Donnerstag, falls es nicht zwischendrin kommt. Meine Meinung ist, dass wir das aber durchaus noch etwas weiter abspecken können, so in der Art wie mein Code auf FZW. -- hgzh 07:46, 6. Jul. 2023 (CEST)
Ja, ich würde dann heute schon eine provisorische Lösung bei uns einsetzen; schau’s mir später genauer an. --XanonymusX (Diskussion) 11:25, 6. Jul. 2023 (CEST)

Hm, die Überschriften wegzulassen halte ich für nicht unbedingt notwendig, die gab es ja auch vorher schon. Aber gut, ich könnte damit leben; und dann erledigen sich auch die Diskussionen um die verständlichste Übersetzung. Dann würde ich vorschlagen (Schriftgröße erstmal ungefähr, das haben die Entwickler offenbar selbst noch nicht durchschaut): 

#mw-data-after-content #mw-fr-reviewform {
	font-size: 85%;
}
.flaggedrevs_reviewform span :not(input) {
	display: none;
}

Bei kommenden Änderungen können wir das dann zeitnah wieder anpassen. Gruß–XanonymusX (Diskussion) 13:51, 6. Jul. 2023 (CEST)

Eventuell könnten wir auch das VE-Problem gleich angehen; .ve-active #mw-fr-reviewform { display: none; } reicht dafür aus. --XanonymusX (Diskussion) 14:02, 6. Jul. 2023 (CEST)
Gehe ich mit, auch bzgl. VE. -- hgzh 14:24, 6. Jul. 2023 (CEST)
Perfekt, dann setz ich das mal um! --XanonymusX (Diskussion) 14:35, 6. Jul. 2023 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: hgzh 16:48, 19. Okt. 2023 (CEST)

Erfordernis der Lokalisation von Sprachvarianten entfällt

Wenn ich phab:T229992 richtig verstehe, müssen wir zukünftig /de-ch und /de-at bei Lokalisierungen nicht mehr zwingend mit berücksichtigen, weil die Rückfallebene nun erstmal die lokale /de-Überschreibung wird, nicht der Standardwert. Gruß, -- hgzh 09:29, 17. Jul. 2023 (CEST)

@Hgzh Das lese ich in https://lists.wikimedia.org/hyperkitty/list/wikitech-ambassadors@lists.wikimedia.org/thread/2G5SWZHVDA23RNNI4ASJREUW4V67NFAV/ ebenso. Ziemlich cool. --Raymond Disk. 17:29, 18. Jul. 2023 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: hgzh 16:48, 19. Okt. 2023 (CEST)

Korrektur-Vorschlag für MediaWiki:Edittools

Auf dem Umweg über WP:Reparatursommer wurde ein kleines technisches Problem an uns herangetragen. Wenn man in der Sonderzeichenleiste das   nutzt, landet der Textcursor danach zwischen & und nbsp;. So ist es nicht möglich, schnell mehrere Zeichen einzufügen, ohne jedesmal die Cursorposition zu korrigieren. Lösung: Ein Interface-Admin müsste auf MediaWiki:Edittools den Code &+nbsp; durch   ersetzen.

Da steht zwar ein Kommentar, dass man nicht am   "rumspielen" soll. Aber der ist von 2008 und war so weit ich das erkennen kann nie korrekt. Die mw:Extension:CharInsert hat seit 2005 ausdrücklich Unterstützung dafür und andere Wikis nutzen das auch seit langem. In der Versionsgeschichte hier sehe ich nur Experimente mit dem +, aber keins mit &. Ich vermute, der Kommentar kam zustande, bevor die eine Variante ausprobiert werden konnte, die funktioniert. --Thiemo Kreuz (WMDE) 12:43, 14. Nov. 2023 (CET)

Ich bin mir nicht so sicher, ob und was hier passieren soll, und was gemeldet wurde.
Ich wüsste nicht, dass wir in den letzten anderthalb Jahrzehnten MediaWiki:Edittools nutzen würden und dass bei uns <charinsert> irgendwo vorkäme. Es ist komplett ungepflegt und ignoriert.
Wir verwenden editMenus.
Bei mir steht der Cursor nach dessen Betätigung nach dem eingefügten Zeichen; hier also ; – und damit wäre das ein Problem eines inkompatiblen Browsers, der MW-Software zum Selektieren und Einfügen, oder es ginge um ein völlig anderes Wiki.
VG --PerfektesChaos 13:52, 14. Nov. 2023 (CET)
Eigentlich sollte Edittools nirgendwo mehr vorkommen, da die Inhalte auskommentiert sind und MediaWiki:Onlyifediting.js auch nicht mehr zentral eingebunden wird. -- hgzh 14:21, 14. Nov. 2023 (CET)

Zur Vermeidung künftiger Verwirrung schlage ich WL-freie Verschiebung als Unterseiten von Wikipedia:Technik/Archiv vor; also: Technik/Archiv/MediaWiki:Edittools und Technik/Archiv/MediaWiki:Onlyifediting.js

  • Die Abklingzeit von einigen Jahren, teils über ein Jahrzehnt ist abgelaufen.
  • Die VG mit Diskussion mag für die Wikipedistik-Geschichtsschreibung erhalten bleiben.
  • Beim .js müsste wohl das Content Model runtergesetzt werden; dafür <syntaxhighlight lang="javascript"></syntaxhighlight> drumrum.

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

Die Anfrage kommt tatsächlich über ein anderes Wiki zustande, das MediaWiki:Edittools aktiv nutzt. Ich hatte mich dann umgeschaut, wo besagtes &+nbsp; noch vorkommt, aber übersehen, dass die Seite hier auskommentiert ist. Bitte entschuldigt. Vielleicht einfach auf die Version von 2009 zurücksetzen? --Thiemo Kreuz (WMDE) 08:49, 16. Nov. 2023 (CET)

Ich habe den Seiteninhalt zunächst mal ersetzt, die Verschiebung kann dann nachgeordnet passieren. -- hgzh 10:17, 16. Nov. 2023 (CET)
Archivierung dieses Abschnittes wurde gewünscht von: Thiemo Kreuz (WMDE) 08:49, 16. Nov. 2023 (CET)

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

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)

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)
Archivierung dieses Abschnittes wurde gewünscht von: hgzh 17:31, 29. Nov. 2023 (CET)

Sp-contributions-footer

Bei allen "MediaWiki:Sp-contributions-footer"-Seiten bitte display: table und width: 100% entfernen und stattdessen overflow: hidden einfügen, sonst schwappt der rechte Rand der Box über und sieht nicht schön aus. --CyberOne25 (Diskussion) 13:30, 12. Nov. 2023 (CET)

Mindestens display: table sehe ich kritisch; das steht da nicht aus Langeweile.
overflow: hidden würde bewirken, dass Inhalte rechts einfach verschwinden.
Grundsätzlich ist schon der Plan, dass über den gesamten Fußbereich der Block zu 100% gehen soll.
Alles dies wäre mit geeigneten Alternativlösungen zunächst auf BETA zu erproben; in vielerlei Konstellationen Desktop/mobil.
Diese Konfiguration gibt es seit Juni 2020; sooo falsch kann das nicht sein.
Der Anfrage fehlt die konkrete und präzise Angabe, in genau welcher Konfiguration ein Problem existieren soll.
VG --PerfektesChaos 14:40, 12. Nov. 2023 (CET)
Und diesen wenig kompetenten Eingriff habe ich grad revertiert.
Eine jüngste unabgesprochene und untaugliche Experimentiererei an der bald einen Million mal eingebundenen Vorlage:Hinweisbaustein ist in sehr unangenehmer Erinnerung.
Auch dieser unterkompetente unabgesprochene Eingriff in das Design der Hauptseite musste umgehend revertiert werden.
Die Versionsgeschichten jüngst bearbeiteter Vorlagen sehen schwer nach planlosem ungetestetem Experimentieren an Produktivversioen aus.
Spezial:Diff/239041593 und die vorgenommenen Änderungen wären administrativ kritisch zu begleiten. Das hat nicht aus Langeweile Vollschutz.
VG --PerfektesChaos 15:02, 12. Nov. 2023 (CET)
Also das hier habe ich gemacht, weil dieser Baustein so genutzt werden soll (kannst du beim Beispiel auf der Vorlagenseite einsehen; sonst overflowt der rechte Rand). Was das mit Barrierefreiheit zu tun haben soll habe ich nicht verstanden.
Meine vorgeschlagenen Änderungen habe ich schon erprobt (dafür gibt's Developer Tools im Browser) und sie folgen dem Beispiel von Vorlage:Exzellent; das geht zu 100% über den Fußbereich, aber dort gibt es kein width: 100%. Dort gibt es auch overflow: hidden und kein display: table. Die Darstellung mit meinen vorgeschlagenen Änderungen ist genau wie vorher, nur dass es nicht mehr über den rechten Rand hinausragt. Wie gesagt kannst du das alles selber mit den Developer Tools im Browser (z.B. in Firefox, Chrome oder Edge) ausprobieren. --CyberOne25 (Diskussion) 15:45, 12. Nov. 2023 (CET)
Die Technik der Vorlage:Bausteindesign7 ist mitsamt aller ihrer Schwestern sei einem Jahrzehnt für derartige Zwecke obsolet und wird überall systematisch zurückgebaut; keinesfalls neu eingefügt.
Deine jüngere Beitragsliste an Vorlagen zeigt, dass du regelmäßig an Produktivversionen 3–5 Edits dicht hintereinander machst. Wer es kann, schafft das meist in einem einzigen Edit, um die erprobte Lösung umzusetzen. Manchmal hat sich noch ein kleiner Tippfehler eingeschlichen, dann kommt selten mal ein zweiter. Heißt: Du experimentierst so lange an den Produktivversionen, bis es auf deinem Handy gut aussieht. Genau sowas wollen wir bei wichtigen oder häufigen Vorlagen auf gar keinen Fall haben.
Ich gestehe dir ja gern zu, dass du es gut meinst. Ich will auch gern glauben, dass viele Syntaxkonstrukte in diesem Wiki auf und für Desktop entwickelt wurden und echt-mobil unter Umständen Probleme machen – auch weil die WMF am mobilen Frontend so im Lauf der Zeit herumbastelt, bis es in der enWP nett aussieht.
Aber bevor du wesentliche Änderungen vornimmst, wäre wohl zukünftig Kommunikation mit dem Rest des Projekts erforderlich, ob deine technischen Ideen tatsächlich eine Verbesserung sind. Dies klärt die WP:VWS.
VG --PerfektesChaos 16:01, 12. Nov. 2023 (CET)
Archivierung dieses Abschnittes wurde gewünscht von: hgzh 17:32, 29. Nov. 2023 (CET)

Geänderte Überschriftenstruktur

Siehe mw:Heading_HTML_changes – die haben uns gerade die Hauptseite und etwa auch das WP:Autorenportal zerrammelt, wohl durch die DiscussionTools unbeabsichtigt vorfristig eingeführt. Wie man ganz unten auf der verlinkten Seite lesen kann, werden nicht nur per Wikitext == erzeugte Überschriften umgestellt, sondern sogar manuell mit <h2> erzeugte mit diesem Wrapper umschlossen. Das ist gemein, weil wir unsere Klassen auf die dann innenliegenden h2-Elemente anwenden, die Styles aber außen aus dem Wrapper kommen und wir da nicht mehr ran kommen.

Wir müssten uns für die Zukunft überlegen, wie wir damit umgehen. :has() als eine Art Parent-Selector wird noch nicht von allen Browsern unterstützt und derzeit auch noch vom Sanitizer abgelehnt. So richtig hab ich noch keine Idee, außer alles in divs umzuwandeln und die Heading-Semantik manuell nachzurüsten. -- hgzh 21:51, 14. Dez. 2023 (CET)

  1. Analyse: Wie viele Seiten beträfe das?
    • 1.500 Suchtreffer?
    • Wikipedia:Kurier hat auch sowas, als Promi.
    • Ca. 18 Vorlagen machen produktiv von <h2> Gebrauch.
  2. Beträfe das auch Seiten, die das Bearbeiten von Abschnitten deaktiviert haben? Oder schadet es denen nicht weiter?
  3. Betrifft das Problem nur Seiten, auf die wir mit TemplateStyles oder anderes CSS applizieren, oder auch sonst?
    • Welche CSS-Regeln sind bekannt und betroffen und wo definiert?
    • Welche sind „unsere Klassen“?
VG --PerfektesChaos 22:47, 14. Dez. 2023 (CET)
Cirrus sagt ca. 1200 Treffer akut. Die geänderte Struktur gab es wohl schon länger, aber erst jetzt wurden die von MediaWiki ausgelieferten Styles eingeführt. Wird also wohl so bleiben und später (verlinkte MW-Seite spricht von 2024) auch auf die noch nicht betroffenen Namensräume und auch den ANR ausgedehnt.
Die ganzen Heading-Styles habe ich noch nicht komplett durchschaut, aber es wird alle Seiten betreffen, die dem h[1-6]-Element spezifische Styles zuweisen, ob per TemplateStyles („unsere Klassen“) oder Inline-CSS.
Einzige Möglichkeit, die ich derzeit sehe, ist alles <h2 zu <div class="mw-heading mw-heading2" role="heading" aria-level="2" o.Ä. umzusetzen. -- hgzh 23:12, 14. Dez. 2023 (CET)
@Matma Rex do you see another solution than Special:Diff/240192687 to fix the issue? -- hgzh 23:18, 14. Dez. 2023 (CET)
(It seems that this is my fault, I'm sorry.) Hi, there is probably some less disruptive solution. I'm reviewing some pages from the search you linked, and trying out some things. I'll write up some ideas and examples later today. Luckily it seems that most pages are not too badly broken, so this can wait a few minutes (in fact at first I didn't realize they're not supposed to look the way that they do :) ). --Matma Rex (Diskussion) 23:25, 14. Dez. 2023 (CET)
Thank you very much! -- hgzh 23:42, 14. Dez. 2023 (CET)
Before I start with ideas, let me describe the problem better: when you write <h2 class="…" style="…">, the styles and classes now only apply to the heading text, rather than the heading box; the heading box is now a new <div class="mw-heading"> wrapper.
So, first of all, we should probably think about that behavior of the software before we start changing thousands of pages. It may make sense to make it move some or all attributes, written on the h2 in wikitext, to the div, and so make them apply to the heading box again. I haven't thought this through yet, but it should be possible, and I'll consult with some folks next week. I'm not sure how good of an idea this is though, it could be unintuitive for editors. How would you feel about that?
If that doesn't work out, or you can't wait, then I think you could fix many pages just by adding display: block to the <h2 style="…"> (you may need to tweak margins and fonts, though). That basically turns the heading text into another box, which can be styled more easily. Similar solutions can be applied with TemplateStyles (and there, you can also style the .mw-heading wrapper). --Matma Rex (Diskussion) 00:07, 15. Dez. 2023 (CET)
I wonder why and where there is a damage and where not.
Looking at some examples, I do not see a problem. Probably since <h2> has no attributes?
Thanks for your support --PerfektesChaos 01:11, 15. Dez. 2023 (CET)
wrt H:? I just applied a quick fix.
However, this is a problem when every skin/mobile is using a different margin-bottom to be overcome.
Good night --PerfektesChaos 01:30, 15. Dez. 2023 (CET)
I documented the issue from the MediaWiki side at T353489 and I'll ask the parser experts for feedback, and try to do something about it next week. Thanks for reporting this in the first place! --Matma Rex (Diskussion) 01:37, 15. Dez. 2023 (CET)
Zur Info: Firefox unterstützt als einziger Browser noch nicht dem :has-Selektor, er ist aber nur deaktiviert und kann mit einer Einstellung aktiviert werden. In Kürze (laut Planung in wenigen Tagen, am 19.12.2023, vergleiche Firefox Release Calendar, version 121) wird Version 121 erscheinen und dort ist diese Einstellung standardmäßig aktiv. Dann wäre die derzeitige ESR-Version des Firefox die letzte, die den Parameter von Hause aus nicht beachtet (nächste ESR-Version soll entsprechend Firefox Release Calendar am 9.7.2024 veröffentlicht werden).
Worauf ich hinauswill: Wenn man an einer Stelle wirklich keine andere Lösung findet, dann sollte man diesen Parameter durchaus einsetzen. — Speravir – 01:45, 16. Dez. 2023 (CET)
Es bleibt das Problem, dass der Sanitizer es nicht akzeptiert, damit kann es nicht in TemplateStyles verwendet werden. -- hgzh 08:11, 16. Dez. 2023 (CET)
Diesbezüglich siehe T217722. --MGChecker – (📞| 📝| Bewertung) 22:56, 16. Dez. 2023 (CET)
Ach so, ja, stimmt. — Speravir – 00:04, 18. Dez. 2023 (CET)
Ich würd da jetzt mal auf den Weihnachtsmann warten und gucken, wie viel Problem nächstes Jahr noch übrig ist.
Mit Glück passt vieles wieder so wie es vorher gewesen war; was sich geändert hat tangiert uns überwiegend nicht.
Nur wo es zu offensichtlichen Darstellungsfehlern kommt, wie bei APO, müsste mindestens temporär eingegriffen werden.
Probleme haben wir ggf. dort, wo überhaupt nichts diskutiert wird, und der neue Wrapper überhaupt nicht benötigt wird und hoffentlich auch wieder abgeschafft wird.
Im Massengeschäft der Diskussionsforen wie auch auf dieser Seite ändert sich durch projektweite Aktivitäten nur wenig an der Darstellung; möglicherweise gibt es aber Benutzerskripte, deren Selektoren an den Wrapper angepasst werden müssen.
VG --PerfektesChaos 18:38, 17. Dez. 2023 (CET)
Ein Fix ist live. hx-Überschriften werden nun nicht mehr mit dem Wrapper ausgestattet, wenn sie zusätzliche Attribute haben. -- hgzh 09:56, 21. Dez. 2023 (CET)
This should be resolved now. You'll need to purge any affected pages. You can probably undo any workarounds that were applied (but you don't have to). --Matma Rex (Diskussion) 09:58, 21. Dez. 2023 (CET)
Archivierung dieses Abschnittes wurde gewünscht von: hgzh 12:11, 12. Mär. 2024 (CET)
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Wikipedia:Technik/Skin/MediaWiki/Änderungen/Archiv/2023&oldid=243474794“