Änderungen im MediaWiki-Namensraum

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

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

Vorlage:Autoarchiv-Erledigt/Wartung/Festes_Ziel

Archiv

2024 2023 2022 2021 2020 2019 2018

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 Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-PerfektesChaos-2018-09-21T14:41:00.000Z-MediaWiki:Common.css – allmähliche Verschlankung11Beantworten

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 Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-PerfektesChaos-2020-03-01T00:28:00.000Z-Benutzeroberfläche: Umfrage beendet11Beantworten

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 Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-Chaddy-2020-03-01T20:42:00.000Z-PerfektesChaos-2020-03-01T00:28:00.000Z11Beantworten

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 Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-NordNordWest-2020-03-02T09:17:00.000Z-Chaddy-2020-03-01T20:42:00.000Z11Beantworten

MBs sind keine Pflicht – wenn Konsens besteht, kann selbstredend auch ohne die Oberfläche modifiziert werden. --MGChecker – (📞| 📝| ) Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-MGChecker-2020-03-02T11:18:00.000Z-NordNordWest-2020-03-02T09:17:00.000Z11Beantworten

*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 Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-Chaddy-2020-03-02T14:41:00.000Z-MGChecker-2020-03-02T11:18:00.000Z11Beantworten

• 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 Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-PerfektesChaos-2020-03-02T11:54:00.000Z-MGChecker-2020-03-02T11:18:00.000Z11Beantworten

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 Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-Chaddy-2020-03-02T14:44:00.000Z-PerfektesChaos-2020-03-02T11:54:00.000Z11Beantworten

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) Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-Orik-2020-04-04T21:47:00.000Z-wikEd11Beantworten

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 Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-PerfektesChaos-2020-04-05T11:56:00.000Z-Orik-2020-04-04T21:47:00.000Z11Beantworten

(Nicht ganz sicher, ob das hier richtig ist.)

Ich wollte gerade eine Seite mit *Halbschutz* *Dreiviertelschutz* bearbeiten und bekam folgenden Text in einer gelben Warnbox eingeblendet:

Warning: This page has been protected so that only users with administrator privileges can edit it. The latest log entry is provided below for reference: …

Meine Benutzeroberfläche wird in englischer Sprache angezeigt, deshalb ist die Wahl der Sprache zwar richtig, ihr Inhalt aber nicht da die Seite ja nicht vollgeschützt ist und ich sie tatsächlich auch bearbeiten konnte. Mit URL-Parameter "?uselang=de" bekomme ich in der Tat die inhaltlich korrekte deutschsprachige Nachricht:

Achtung: Diese Seite wurde geschützt, so dass sie nur durch Sichter bearbeitet werden kann. Gründe für den Seitenschutz finden sich im Seitenschutz-Logbuch, auf der Diskussionsseite oder in den Regeln für geschützte Seiten. Auszug aus dem Seitenschutz-Logbuch: …"

Jetzt finde ich gerade nicht, ob das onwiki irgendwo im Mediawiki-Namensraum zu verändern ist, oder ob das in die Software eincodiert ist oder über das Translatewiki geht. Kann da bitte mal jemand nachschauen?

Dankeschön, MisterSynergy (Diskussion) Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-MisterSynergy-2020-04-19T19:39:00.000Z-inhaltlicher falscher Seitenschutz-Hinweis in englischer Sprache11Beantworten

@MisterSynergy: Das ist eine lokale Anpassung in MediaWiki:Protectedpagemovewarning. Demnach hier nicht in Englisch verfügbar. Könnte man hier für Englisch natürlich einrichten. Das Original findest du hier: translatewiki:MediaWiki:Protectedpagemovewarning/de. — Raymond ^Disk. Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-Raymond-2020-04-19T19:45:00.000Z-MisterSynergy-2020-04-19T19:39:00.000Z11Beantworten

BK

Erstmal würden die einfachen WP:A/A hier reichen, wenn überhaupt, da es sich um eine textliche Nachricht auf dem Server handelt und nicht um eine Programmierung in einer Programmiersprache des Browsers.

Des weiteren könnte es um ein konzeptionelles Problem gehen; der englischsprachigen globalen Welt ist womöglich unser lokales Konzept des Dreiviertelschutz unbekannt – insbesondere sind „Sichter“ eine deutschsprachige Spezialität. Für fast jedes andere Wiki ist „mehr als Halbschutz“ identisch mit „Admin erforderlich“.

Deine eingangs erfolgte Situationsschilderung kann nicht zutreffen; es ginge nicht um „Halbschutz“ (IP oder Newbies ausgeschlossen), sondern um „Dreiviertelschutz“ (Nicht-Sichter ausgeschlossen).

Ich werde das weiter ermitteln und die weiteren Schritte veranlassen; hier erl.

LG --PerfektesChaos Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-PerfektesChaos-2020-04-19T19:48:00.000Z-MisterSynergy-2020-04-19T19:39:00.000Z11Beantworten

Ja sorry, ich glaube "Dreiviertelschutz" meinte ich. Vorlage:COVID-19-Box war die Seite, bei der ich das gemerkt habe. —MisterSynergy (Diskussion) Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-MisterSynergy-2020-04-19T19:53:00.000Z-PerfektesChaos-2020-04-19T19:48:00.000Z11Beantworten

 Info: Es ist nicht MediaWiki:Protectedpagemovewarning, wie weiter oben geantwortet wurde, sondern eine komplexe lokale Programmierung innerhalb von MediaWiki:Protectedpagetext, die auf den Schutzlevel editeditorprotected reagiert (was „Sichter“ meint). Diese müsste komplett ins Englische übertragen werden.

LG --PerfektesChaos Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-PerfektesChaos-2020-04-19T20:10:00.000Z-MisterSynergy-2020-04-19T19:53:00.000Z11Beantworten

Viele Wikis kennen ein Analogon zum Dreiviertelschutz, insbesondere enwiki mit en:WP:EXTENDEDCONFIRMED. --MGChecker – (📞| 📝| ) Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-MGChecker-2020-07-09T14:46:00.000Z-PerfektesChaos-2020-04-19T19:48:00.000Z11Beantworten

Seit letzter Woche erhalten unsere Tools eine neue Domain toolforge.org und sind dem Interwiki-Link-Format nicht mehr wirklich zugänglich. Um die lästigen zu vermeiden, sollte:

• in MediaWiki:Common.css
• vor der Zeile mit #mw-content-text a.external[href^="//tools.wmflabs.org"],
• eingefügt werden: #mw-content-text a.external[href*=".toolforge.org/"],

Im Übrigen müsste auf dieser Seite mal alles von 2019 verantwortlich archiviert werden.

VG --PerfektesChaos Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-PerfektesChaos-2020-04-22T23:03:00.000Z-URL der toolforge11Beantworten

Einspruch. Das würde auch auf http://www.example.com/a.toolforge.org/ anschlagen. Gruß --FriedhelmW (Diskussion) Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-FriedhelmW-2020-04-23T09:09:00.000Z-PerfektesChaos-2020-04-22T23:03:00.000Z11Beantworten

Seeeehr unwahrscheinlich, dass ein Fremdbetreiber unsere .toolforge.org/ in seine URL einbauen würde.

Sollte doch ein solcher externer Dienst auffallen, Massen an Google-Suchen nach uns, dann könnte diese spezielle Website notfalls wieder explizit extern geschaltet werden.

CSS-Syntax kennt leider keine RegExp.

VG --PerfektesChaos Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-PerfektesChaos-2020-04-23T10:20:00.000Z-FriedhelmW-2020-04-23T09:09:00.000Z11Beantworten

Ich habe es jetzt eingebaut. NNW Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-NordNordWest-2020-04-24T15:25:00.000Z-PerfektesChaos-2020-04-23T10:20:00.000Z11Beantworten

(Erle rausgenommen)

• nach der derzeitigen Lösung werden Links a la https://pageviews.toolforge.org (ohne abschließenden Schrägstrich, kommt vor) noch mit dem Extern-Symbol versehen. Bei Entfernen des Schrägstrichs könnte dann auch onlinedrugs.toolforge.organisedcrime.com als intern markiert werden. Handhabbares Risiko oder eher nicht?
• folgende Gadgets nehmen noch Umwege über die tools.wmflabs.org-Domain: MediaWiki:Gadget-toolserver-integration.js (Link), MediaWiki:Gadget-PB2.js (Link), MediaWiki:Gadget-Rechtschreibpruefung.js (Datenquelle), MediaWiki:Gadget-ImageSiblings.js (Datenquelle). Diese würde ich nach Funktionstest über die neue toolforge-URL gern umstellen. Einwände?

Gruß, -- hgzh Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-Hgzh-2020-07-18T12:35:00.000Z-URL der toolforge11Beantworten

• @Schrägstrich:
  • Wir schreiben aus genau diesem und ähnlichen Hintergründen projektweit und im ANR vorrangig und weitaus überwiegend die Domains immer mit Schrägstrich.
  • Wenn ein Bearbeiter dazu zu faul ist, gibt es halt ein External-Symbol. Auch kein Weltuntergang.
  • Es war bereits eingewendet worden, dass theoretisch (etwa bei einer Web-Archivierung oder in einem nicht-Google-Suchergebnis) unsere URL auch als Teil der URL jenseits der Domain aufttreten könne. Noch weiter aufweichen sollten wir deshalb nicht, sondern an Syntax nutzen was CSS hergibt.
• @Gadgets:
  • Das soll ja angeblich seit Mitte Juni vollproduktiv in Betrieb sein; allzugroße Klagen über kaputte Zugriffe habe ich bislang bei fachgerechtem Umgang noch nicht gesehen.
  • Kann man also gern so allmählich bisherige Programmierungen nachziehen, um der neuen Lastverteilung möglichst viel Traffic auf den neuen Subdomains zuzuliefern.
• @Weil wir grad dabei sind:
  • Warum liefert eigentlich https://upload.wikimedia.org/wikipedia/commons/x/x1/Dokument.pdf ein External? Ich hätt jetzt gemeint, das würde als zur Familie gehörend erkannt.

LG --PerfektesChaos Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-PerfektesChaos-2020-07-18T13:42:00.000Z-Hgzh-2020-07-18T12:35:00.000Z11Beantworten

Dann oute ich mich mal als mitunter faul ;) Große Dringlichkeit hat es nicht für mich, ist eben nur verschieden zu den anderen dieser Regeln. Die Gadgets nehme ich mir dann die Tage stückweise vor. Commons wird ebenfalls nicht als zugehörig markiert, Wiktionary etc. auch nicht, nur Wikidata. Ein bisschen inkonsistent, aber da habe ich im Moment keine Präferenz für oder gegen eine Extern-Kennzeichnung. -- hgzh Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-Hgzh-2020-07-18T16:33:00.000Z-PerfektesChaos-2020-07-18T13:42:00.000Z11Beantworten

„verschieden zu den anderen dieser Regeln“ ist es, weil wir ansonsten die Subdomain genau kennen, und deshalb bei // beginnen können.

In der Toolforge hat jedoch jeder Account eine eigene Subdomain; das ist ja der Witz.

Und da es in CSS nur „fängt an mit“ oder „enthält“ zur Auswahl gibt, aber keine wildcards, muss halt auch mal bisschen inkonsistent sein.

LG --PerfektesChaos Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-PerfektesChaos-2020-07-18T16:53:00.000Z-Hgzh-2020-07-18T16:33:00.000Z11Beantworten

1. MediaWiki:Wikimedia-copyright + /en usw.
   • gemäß Spezial:PermaLink/200438729 #linkupdate
2. Spezial:Diff/200302850
   • Es geht darum, redundante div aus den CSS herauszunehmen, die zukünftig die Funktionalität blockieren werden, weil die Teile bald <nav> oder so heißen.
   • Diverse dürften inaktiv sein; Messerjokke79, Jogo.obb, Thoken fallen mir spontan als aktiv ein.
   • Wäre pragmatisch eine Lösung zu finden.
3. Im Übrigen bin ich der Meinung, dass die Angelegenheiten des Jahres 2019 auf dieser Seite verantwortlich zu archivieren wären.

VG --PerfektesChaos Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-PerfektesChaos-2020-05-29T14:50:00.000Z-Zwei Updates11Beantworten

1 ist umgesetzt. Verstehe ich das richtig, dass bspw. div#p-Mitmachen.portal unverändert bleibt? NNW Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-NordNordWest-2020-05-29T17:51:00.000Z-PerfektesChaos-2020-05-29T14:50:00.000Z11Beantworten

Es ist hier unser lokales Gewächs, und deshalb global unbekannt und nicht erwähnt, aber da müsste es vorsorglich auch weg.

#p-Mitmachen.portal wirkt auf das (erste) Element der Seite, das die id="p-Mitmachen.portal" hat, und das ist momentan ein <div> – es wirkt auf kein anderes, weil es auch das einzige mit dieser id= ist oder sein sollte.

Die Geschichte mit div#p-Mitmachen.portal macht es nicht besser; es kommt im Moment das gleiche Element dabei heraus, aber wenn das Portal irgendwann mal vom unspezifischen <div> auf die speziellen semantischen strukturellen Elemente von HTML5 umgestellt wird, dann verhindert die explizite zusätzliche Forderung nach div, dass diese Elemente noch die Forderung erfüllen.

VG --PerfektesChaos Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-PerfektesChaos-2020-05-29T18:28:00.000Z-NordNordWest-2020-05-29T17:51:00.000Z11Beantworten

Alle entfernt, die auf Phabricator gelistet sind zzgl. p-Mitmachen. NNW Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-NordNordWest-2020-05-29T19:05:00.000Z-PerfektesChaos-2020-05-29T18:28:00.000Z11Beantworten

Liebe Mitinteressierte, da wir jetzt erstmals einen Nichtadmin haben, der als BOA tätig sein möchte, habe ich das angekündigte MB in die Vorbereitung gestellt und bitte um Unterstützung. Gruss, --MBq ^Disk Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-MBq-2020-07-06T10:18:00.000Z-Meinungsbild11Beantworten

Gemäß WP:A/A#HS-definitiv erfolgt heute in der Nacht der (erste Versuch zum) Neustart unserer Hauptseite.

• Gut wäre es, wenn ein BOA nach Mitternacht noch erreichbar wäre, sicherheitshalber.
• Ansonsten nach Lagebericht auf WP:A/A am Sa morgens.
• Nachstehend zwei Blöcke; der erste kann noch Fr im Lauf des Abends abgearbeitet werden; der zweite (MediaWiki:Common.css) nach Erfolg die Abschaltung möglicherweise konfligierender Regeln.
  1. Ab jetzt:
     •  Ok Jeweils ein simples - (ASCII-Bindestrich) in:
       • MediaWiki:Mobile-frontend-logged-in-homepage-notification
       • MediaWiki:Mobile-frontend-logged-in-homepage-notification/en‎
       • MediaWiki:Mobile-frontend-logged-in-homepage-notification/es
       • MediaWiki:Mobile-frontend-logged-in-homepage-notification/fr
       • MediaWiki:Mobile-frontend-logged-in-homepage-notification/it
     • Für sehr unwahrscheinliche Konstellationen (Mobildarstellung auf HD-Breitbildschirm), die heute schon pervers aussieht, vorbeugend wegen Konflikt mit der Gesamtbreite
       •  Ok MediaWiki:Mobile.css mit Kommentar voranzustellen oder anzuhängen:

         .page-Wikipedia_Hauptseite .pre-content,
         .page-Wikipedia_Hauptseite .content {
            max-width: none;
         }
         

       •  Ok MediaWiki:Minerva.css mit Kommentar voranzustellen oder anzuhängen:

         .page-Wikipedia_Hauptseite .pre-content,
         .page-Wikipedia_Hauptseite .content {
            max-width: none;
         }
         

       •  Ok MediaWiki:Timeless.css mit Kommentar voranzustellen oder anzuhängen:

         .page-Wikipedia_Hauptseite .ts-inner {
            max-width: none;
         }
         

  2. In MediaWiki:Common.css müsste nach erfolgreicher Umschaltung in den frühen Morgenstunden des Sa 11. Juni ziemlich zeitnah alles heraus, was mit +++++ 3. HAUPTSEITE zu tun hat. Meinem Eindruck nach gibt es entweder überhaupt keine Konflikte wegen völlig abweichender neuer Selektoren, oder sie hätten vorläufig verschmerzbare Wirkung. Es sollen dort nur noch verbleiben:

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

VG --PerfektesChaos Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-PerfektesChaos-2020-07-10T14:58:00.000Z-Hauptseite – Neue technische Umsetzung11Beantworten

als BOA/A steh ich gerne zur Verfügung bis morgen früh 5:30 Uhr ca., zur Koordination/Messages würde ich aber gerne einen Abschnitt auf meiner Disk verwenden, um ein munteres Hin-und-Her-Switchen währenddessen zu vermeiden. Gehen wir so vor? – Doc Taxon • Disk. • Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-Doc Taxon-2020-07-10T17:14:00.000Z-PerfektesChaos-2020-07-10T14:58:00.000Z11Beantworten

wo soll auf den Mobile-frontend-logged-in-homepage-notification denn der Bindestrich hin? – Doc Taxon • Disk. • Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-Doc Taxon-2020-07-10T18:42:00.000Z-Doc Taxon-2020-07-10T17:14:00.000Z11Beantworten

Der gesamte Seiteninhalt ist der Bindestrich. Heißt: Kein Textinhalt. VG --PerfektesChaos Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-PerfektesChaos-2020-07-10T18:56:00.000Z-Doc Taxon-2020-07-10T18:42:00.000Z11Beantworten

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 Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-PerfektesChaos-2020-07-12T13:01:00.000Z-Neues Gadget: markLinks11Beantworten

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 – (📞| 📝| ) Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-MGChecker-2020-07-12T18:11:00.000Z-PerfektesChaos-2020-07-12T13:01:00.000Z11Beantworten

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 Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-PerfektesChaos-2020-07-12T18:53:00.000Z-MGChecker-2020-07-12T18:11:00.000Z11Beantworten

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 Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-Hgzh-2020-07-13T16:28:00.000Z-PerfektesChaos-2020-07-12T18:53:00.000Z11Beantworten

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 Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-PerfektesChaos-2020-07-14T10:56:00.000Z-Hgzh-2020-07-13T16:28:00.000Z11Beantworten

Steward. --Count Count (Diskussion) Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-Count Count-2020-07-14T11:31:00.000Z-PerfektesChaos-2020-07-14T10:56:00.000Z11Beantworten

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 Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-PerfektesChaos-2020-07-14T12:28:00.000Z-Count Count-2020-07-14T11:31:00.000Z11Beantworten

Hallo, kürzlich wurde der mobilen Version der Seite ein Spenden-Link hinzugefügt (siehe T219793). Analog zur Desktop-Version (letzte entsprechende Bearbeitung von MediaWiki:Common.js) soll auf de.m.wikipedia.org der Link so umgebogen werden, dass er ebenfalls auf unsere Spendenseite zeigt und entsprechende Informationen zur Zuordnung enthält). en:User:Ammarpad hat in unserem Phabricator-Task (T257791) den Code-Schnipsel leicht angepasst und wir haben das auf unseren eigenen User-Script-Seiten getestet. Könnte jemand von euch den Code auf der Seite MediaWiki:Mobile.js hinterlegen? Die finale Version, in der auch die entsprechenden Parameter für unser Web-Analytics-Tool enthalten sind, findet ihr auf Benutzer:Kai_Nissen_(WMDE)/minerva.js.

Ich habe übrigens die ungenutzten Parameter language und country sowie die Abfrage auf die Spracheinstellung entfernt. Letzteres, weil der standardmäßig hinterlegte Zielseite donate.wikimedia.org auf GeoIP basierend immer auf unsere Spendenseite weiterleitet. Diese Änderung könnte auch in der Version auf MediaWiki:Common.js nachgezogen werden. Vielen Dank! Kai Nissen (WMDE) (Diskussion) Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-Kai Nissen (WMDE)-2020-07-17T12:13:00.000Z-Spenden-Link in MediaWiki:Mobile.js11Beantworten

Jo, kann man wohl so machen.

Ohne dass ich mich mit piwik_ und einer mobilen Sidebar auskennen würde.

In MediaWiki:Common.js solle der Abschnitt unter Ändere den Spenden-Link im Sidebar für Besucher aus Deutschland durch den identischen neuen Code ersetzt werden; jedoch hieße der Selektor dort n-sitesupport a für Desktop-Skins.

Zwei Anmerkungen zum Code:

1. typeof wird schon seit längerer Zeit als Operator notiert und nicht als Funktion; also ohne die Klammern.
2. window.Geo ist hoffentlich nie null.

VG --PerfektesChaos Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-PerfektesChaos-2020-07-17T12:32:00.000Z-Kai Nissen (WMDE)-2020-07-17T12:13:00.000Z11Beantworten

Vielen Dank schonmal, deine beiden Anmerkungen kannst du gern auch einfließen lassen. Alles, was die Fehleranfälligkeit reduziert, ist natürlich sinnvoll. Die Bemerkung zum Nachziehen der Änderung auf MediaWiki:Common.js bezog sich lediglich auf die nicht benötigten Parameter und die Bedingung, nicht auf den gesamten Schnipsel. Kai Nissen (WMDE) (Diskussion) Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-Kai Nissen (WMDE)-2020-07-17T13:29:00.000Z-PerfektesChaos-2020-07-17T12:32:00.000Z11Beantworten

Vielen Dank für den Hinweis, ich halte es auch für besser, statt typeof( Geo ) === "object" lieber typeof Geo === "object" && Geo !== null zu verwenden (sowohl in Common.js als auch Mobile.js) Gabriel Birke (WMDE) (Diskussion) Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-Gabriel Birke (WMDE)-2020-07-17T13:50:00.000Z-PerfektesChaos-2020-07-17T12:32:00.000Z11Beantworten

Die Bedingung wäre also: if ( typeof Geo === "object" && Geo !== null && Geo.country === 'DE' ) {, unabhängig von der Benutzersprache, wie derzeit noch in der Common.js? -- hgzh Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-Hgzh-2020-07-18T12:19:00.000Z-Kai Nissen (WMDE)-2020-07-17T12:13:00.000Z11Beantworten

Ja, schon besser.

Allerdings hatte ich oben mit window.Geo unter 2.) noch etwas anderes angedeutet: Geo wird hier als deklarierte Variable vorausgesetzt.

• In dem Moment, in dem das site-JS gekapselt wird (wie es vorübergehend bis zu einem rollback schon mal kurzzeitig für Benutzer-JS eingeführt wurde), ist das nicht mehr bekannt, und im Falle des absehbaren strict führt die bloße Verwendung bereits zu einem protokollierten Laufzeitfehler.
• In jedem Fall könnte die Bedingung in einer gekapselten Umgebung nie ausgewertet werden, weil Geo dann immer undefined ist und die Spendengelder werden niemals umgeleitet.
• Ergo gehört das robust und zukunftssicher an das globale Objekt des Browsers angebunden.

Eine Abfrage nach explizit null ist nicht erforderlich, weil dies der einzige Zustand ist, in dem etwas nicht etwas wäre und trotzdem object sei.

• Wobei es durchaus realistisch ist, dass vor dem Klick auf den Spendenbutton irgendein Skript von irgendwem zuschlug und aus Datenschutzgründen das indiskrete Geo neutralisiert hätte, egal wie.

Damit schriebe sich die Anfrage in robust:

if ( typeof window.Geo === "object" && window.Geo && window.Geo.country === 'DE' ) {

Inhaltlich stellt sich mir die Frage, warum nur WMDE die Pinke umleitet und WMAT und WMCH nicht, aber mit der Finanzorganisation müssen sich die dortigen Schatzmeister auskennen.

VG --PerfektesChaos Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-PerfektesChaos-2020-07-18T15:02:00.000Z-Hgzh-2020-07-18T12:19:00.000Z11Beantworten

Seit einiger Zeit erscheinen die Links unter "In anderen Sprachen" in wirrer Reihenfolge, siehe Diskussion hier. Das Problem ist bekannt und in Phabricator gemeldet, aber anscheinend dauert die Lösung noch länger. Die polnische und die schwedische Wikipedia setzen daher anscheinend einen "Hack" bzw. Workaround ein, der die Reihenfolge korrigiert. Ich bitte also darum, diesen auch hier einzubauen. Gestumblindi Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-Gestumblindi-2020-07-20T09:09:00.000Z-Workaround für "In anderen Sprachen"11Beantworten

Es geht um folgenden Code (aus pl:MediaWiki:Common.js):

$( function () {
	var $ul = $( '#p-lang ul' );
	
	$ul.children().sort( function ( a, b ) {
		return a.classList[ 1 ].localeCompare( b.classList[ 1 ] );
	} ).appendTo( $ul );
} )

-- hgzh Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-Hgzh-2020-07-20T10:40:00.000Z-Gestumblindi-2020-07-20T09:09:00.000Z11Beantworten

• localeCompare ist relativ kompatibel; Edge allerdings erst ab 12. Ich weiß nicht, ob das viel oder wenig ist, bin bei Microsoft nicht mehr so auf dem Laufenden. Ggf. crasht das dann halt.
• classList ist DOM-Programmierung gemischt in jQuery-Programmierung ansonsten, was nicht sehr intuitiv verständlich wird.
• Die .children() des $ul sind <li>.
• .classList[ 1 ] ist in DOM die zweite Klasse einer Aufzählung von Klassenbezeichnern.
• class="interlanguage-link interwiki-en" ist beispielsweise die einem en-Interlanguage-li zugeordnete Klassenliste.
• Sortiert werden lauter Klassenbezeichner: interwiki-en interwiki-fr
• Das entspricht unserer traditionellen Grundsortierung nach den Sprachcodes, wie sie sich auch aus den href= gewinnen ließen.
• Den umständlichen und nicht mit Edge vollkompatiblen localeCompare-Ansatz habe ich nicht verstanden. Ich würde robuster und effizienter schreiben (ungetestet freihändig, mal Interessenten in BETA spielen gehen, wo aber wohl erstmal eine Testseite mit drei Interlanguages aufgemacht werden müsste; vielleicht besser auf testwiki: ein Benutzerskript):

$ul.children().sort( function ( a, b ) {
	return ( a.classList[ 1 ] < b.classList[ 1 ] );
} ).appendTo( $ul );

• localeCompare vergleicht Namen nach den Regeln der lokalen Sprache und Schrift, aber weil dies nur ASCII interwiki-en interwiki-fr ist, macht es die Aktion bestenfalls langsamer, wenn sie nicht bei irgendwem gleich ganz abstürzt.
• phab:T257625
• Sowas mag man terminiert bis 30. September 2020 als Hack mal einbauen; danach Revision.

VG --PerfektesChaos Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-PerfektesChaos-2020-07-20T12:06:00.000Z-Workaround für "In anderen Sprachen"11Beantworten

Getestet: hier lokal, da irgendwie auf sämtlichen Betas und Testwikis ordentlich sortiert wurde: funktioniert und ist auch bei großer Interwikilinkliste recht performant, der Vergleichsoperator müsste noch gedreht werden für die gewohnte A–Z-Sortierung. Im Phabricator-Task wurde vorgeschlagen, MediaWiki:Group-user.js zu benutzen, da unangemeldet die verkürzte Interwikiliste gezeigt wird und die angeblich schon immer nach eigenem Gusto sortiert. Das halte ich für den gegebenen Fall im Sinne der Reduzierung von Zusatzlasten sinnvoll. -- hgzh Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-Hgzh-2020-07-20T13:50:00.000Z-PerfektesChaos-2020-07-20T12:06:00.000Z11Beantworten

@MediaWiki:Group-user.js: Die wollte ich eigentlich nicht mehr einsauen und dokumentieren müssen.

• Irgendwann steht sowieso der Umzug aller Skin-Ressourcen in den 2015 gebildeten Gadget-Namensraum an.

Wenn dann also nur für angemeldete benötigt wird:

• Nach Vorbild von Wikipedia:Technik/Skin/Gadgets/dewiki-logo ein kleines kuscheliges Schnipselchen-Gadget aufmachen.
• Das bekäme dann auch eine Doku-Seite, und auf der können wir die obigen und weitere Erkenntnisse festhalten.
• Außerdem können wir das immer wieder aktivieren; ich habe es im Gefühl, dass sich der momentane Zustand wiederholen könnte, oder wir zukünftig anderweitige Modifikationen wünschen könnten, oder mobil oder was.
• interlangSort[ResourceLoader|rights=minoredit|default]|interlangSort.js
  • Die Syntax kennt zwar (noch) keine Benutzergruppen, aber minoredit sendemail editmyuserjs sind Non-IP.
• Damit können die Leute, die es nicht haben wollen, auch wieder opt-outen. Sei es wegen Performance, sei es weil es wohl noch Skripte gibt, die die Sprachnamen auf deutsch schreiben und dann vielleicht nach deutschen Sprachnamen alphabetisch oder was weiß denn ich, nach Kontinenten sortieren.

@Vergleichsoperator müsste noch gedreht werden:

• Deshalb schrub ich „ungetestet freihändig“ und empfahl einen Test; war aus dem Handgelenk.
• Bei diesen Sort-Vergleichsfunktionen muss ich jedes Mal 10 Minuten in die Doku gucken, wie war kleiner Null wenn dies oder sonst das bzw. true und false ist dann wann ergibt gleich was? Am Ende ist es immer genau andersrum als ich es zum Schluss dachte. Also teste ich lieber.

@performant: Bei Zeichenketten vergleichen < > plump die Unicodes.

• localeCompare macht erstmal ein Fass auf, initialisiert eine Umgebung, und ist dann vorbereitet auf ß und ö und é und ñ – was bei ASCII-Sprachcodes etwas overkillernd ist.

VG --PerfektesChaos Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen#c-PerfektesChaos-2020-07-20T19:44:00.000Z-Hgzh-2020-07-20T13:50:00.000Z11Beantworten