Wikipedia Diskussion:Technik/Skin/Gadgets

Auf dieser Diskussionsseite

• kann über Gadgets diskutiert werden, die keine eigene Dokumentationsseite haben
• können Inhalte und Gestaltungsfragen der Vorderseite diskutiert werden
• können Betrachtungen über Gadget-Management angestellt werden.

Qualitätsstandards für Gadgets

Am liebsten wären mir folgende Qualitätsstandards für Gadgets:

---

Damit ein Skript als Gadget installiert wird, müssen folgende Dinge erfüllt sein:

• Das Skript hat einen aktiven Maintainer, der es in seinem Benutzernamensraum pflegt, auf Fehlermeldungen in angemessener Zeit reagiert und bereit ist, das Skript gegebenenfalls den folgenden Punkten entsprechend anzupassen.
• Das Skript enthält keine bekannten schwerwiegenden Fehler, insbesondere keine Sicherheitslücken, und nur wenige kleine Fehler, an deren Behebung gearbeitet wird.
• Das Skript verwendet keine Funktionen, die als deprecated markiert sind, der Quellcode entspricht Standards, wie sie etwa durch jshint festgelegt werden.
• Soweit anwendbar besteht ein Mechanismus zur Internationalisierung, Lokalisierungen sind für Deutsch und alle seine Varianten (Schweizer Deutsch, österreichisches Deutsch, Sie-Form) vorhanden.
• Das Skript ist mit allen Skins und allen gängigen Browsern kompatibel, Ausnahmen sind begründet, dokumentiert und werden automatisch abgefangen.
• Es erfolgte ein Review durch einen erfahrenen Benutzer, der dabei die obigen Punkte überprüfte.
• Das Skript erfordert keine zusätzliche Konfiguration durch den Benutzer.
• Das Skript besitzt eine Dokumentationsseite, die alle Funktionen erläutert, einen Ansprechpartner für das Skript nennt (besonders für Meldung von Sicherheitslücken, die nicht öffentlich erfolgen soll), und deren Diskussionsseite vom Maintainer auf Fehlermeldungen hin beobachtet wird.
• Die Funktion des Skripts ist so allgemein, dass es viele Benutzer gibt, die es nutzen wollen.

Sobald ein Skript diese Punkte erfüllt, kann es von jedem Administrator als vorläufiges Gadget eingerichtet werden. Der Quellcode wird dabei kopiert, also nicht einfach per importScript o. Ä. eingebunden. Nach ein bis zwei Monaten werden die Punkte erneut überprüft (insbesondere die tatsächliche Zahl der Nutzer) und das Skript entsprechend entweder wieder entfernt oder in eine der dauerhaften Rubriken verschoben.

Ist der Maintainer des Skripts nicht mehr aktiv oder kann oder will dieser gemeldete Fehler nicht in angemessener Zeit beheben und findet sich kein Nachfolger, so wird das Skript in eine Rubrik Gadgets ohne Maintainer verschoben. Treten Fehler bei einem Skript auf, das länger als einen Monat in dieser Rubrik steht, so wird es als Gadget ganz entfernt.

Sollen Änderungen an einem Gadget vorgenommen werden, müssen diese zunächst von einem erfahrenen Benutzer reviewt werden, außer der betroffene Teil ist durch Softwaretests abgedeckt, die weiterhin bestanden werden.

Alte Gadgets, die vor der Einführung dieses Verfahrens bestanden, und die den neuen Ansprüchen nicht genügen werden in eigene Rubrik Hic sunt dracones verschoben, damit sich die jahrelangen Benutzer nicht darüber beschweren, dass ihr Lieblingsgadget plötzlich verschwunden ist, von einer Verwendung wird aber abgeraten.

Gadgets aus anderen Wikis mit einem vergleichbaren Qualitätssicherungsprozess können direkt per mw.loader.load geladen werden.

---

Das würde die Pflege wesentlich erleichtern, man hätte nicht so Aktionen wie neulich mit contribs-range, etc. (Solche Standards werden ohnehin nicht eingeführt, aber den Wunsch äußern wollte ich einfach mal.) --Schnark 11:07, 6. Jun. 2014 (CEST)

Hoppla, gestern erst gesehen, irgendwie durch die Beo gerutscht.

• Du hast grundsätzlich völlig recht.
• Einen Punkt hätte ich noch zur Ergänzung der Liste:
  • Eine Versionsbezeichnung hat mindestens im Kommentar, besser noch zur Laufzeit auslesbar im Code vermerkt zu sein.
    • Bei dem ganzen C&P zwischen echter deWP, enwP, Beta, privatem Wiki und Festplatte ist es völlig ungenügend, sich auf die Versionsgeschichte nur in der deWP-Seite zu verlassen und danach die Versionsfolge nachvollziehen zu wollen.
    • Bei diesem contribsdings hatte ich nur auf die Versionsbezeichnung geguckt und eine englische gesehen. Die Leutchen, die dadrin rumgepfriemelt hatten, waren schlicht zu träge, eine einzige Kommentarzeile zu ergänzen, dass sie an dewiki anpassen, und was man jetzt eigentlich für eine Version vor sich hätte. Ich hatte mir das Dings natürlich nicht byteweise durchgelesen und dachte, es manipuliert nur irgendwelche IP-Adressen und nicht gesehen, dass es irgendwo tief im Innern auch Textausgaben gibt. Wobei die enWP es grundsätzlich nicht nötig hat, zu internationalisieren; insbesondere nicht mal einen Textkonfigurationsblock herauszieht und an den Skriptanfang stellt.
    • Ich kopiere aus den Wikis auf meine Festplatte und mache Diffs – dann will ich auch das Datum der Code-Veränderung im Diff erscheinen sehen; und mich interessiert nicht der Zeitpunkt in der Versionsgeschichte, wann in dieses Wiki diese Version kopiert wurde.
  • Die Bedeutung der Doku kann man gar nicht genug hervorheben.
• Ich hätte einen anderen Ansatz für neue Gadgets: Die Skripte im Mediawiki:Gadget- enthalten bei größeren Aufgaben nur noch ein kleines Kopf-Skript, das NR, action oder kanonischen Spezialseitennamen oder vielleicht Skin und mobile oder sowas prüft, und danach mit geeignetem max-age aus einer WMF-Benutzerseite lädt.
  • Für die Anwender bleibt es beim Häkchenmachen.
  • Die Maintainer sind klar.
  • Wenn das Ding Bockmist macht, kann die Seite administrativ gelöscht oder auskommentiert werden, und Ruhe ist.
  • Die Benutzer werden nicht auf jeder Seite mit Hunderten kB belästigt, nur damit die Skripte feststellen, dass sie ja nur beim Editieren wirksam werden.
  • Die Entwickler können die Produktivversion permanent weiter verbessern, ohne jedesmal auf WP:AAF mit neuer Version aufschlagen zu müssen.
  • Das Mediawiki:Gadget- enthält keine fehleranfällige und wartungsbedürftige Expertise.
  • Nur beobachtbare WMF-Benutzerseiten sind erlaubt, bei denen jede Version nachvollzogen werden kann; so mal eben böswillig einen sysop edit token ausborgen.
  • Die Anforderungen an neue Skripte entsprechen in etwa den von dir oben vorgetragenen; zumindest für die präsentierte Ausgangsversion. Die Seiten können danach ja jederzeit beobachtet und gedifft werden.
  • Auf versioning und Komprimierung durch MediaWiki ist gehustet. Dafür wird der Hauptteil des Skriptes erst dann geladen, wenn es wirklich benötigt wird; und nicht gnadenlos alles JS und alles CSS in jeder Situation in jede dafür überhaupt nicht geeignete Spezialseite. Dann dauert es halt mal ein paar Tage, bis eine frische Version kommt; in dringenden Fällen hängt ein Admin ein &17B an die Lade-URL.
  • markAdmins und dein Freund Cacycle operieren bereits so, wobei letzterer nur bei edit|submit erforderlich ist. Dein BKL-Check könnte auf die gleiche Weise für !NR%2 view|edit|submit aus deinem BNR eingebunden werden und den in Ehren ergrauten deprecateten ersetzen.
• Bei den Altlasten sehe ich das anders.
  • Es ist niemand zu vermitteln, dass ein seit fünf Jahren funktionierendes Skript aus formalen Gründen abgeschaltet wird.
  • Solange das Dings weiterhin seine Aufgaben erfüllt, läuft es weiter.
  • Wenn es nur wegen Veränderung der Bibliotheksfunktionen nicht mehr geht, werden die wohl oder übel durch die Werkstatt unter minimalem Aufwand angepasst werden müssen.
  • Wenn es grundsätzlich nicht mehr funktioniert, weil die Aufgabenstellung sich gewandelt hat oder mit modernen Browsern nicht mehr kompatibel ist, dann funktioniert es halt nicht mehr, muss von betroffenen Benutzern ausgehakelt oder irgendwann aus der Definitionsliste ausgetragen werden.
  • Altlasten mit nicht mehr aktiven Entwicklern laufen eben solange weiter, wie sie funktionieren oder ein neuer Maintainer sie in seine Benutzerseite übernimmt und aufarbeitet.
• Die Rubriken kann ich nachvollziehen; habe persönlich eine ähnliche Einteilung im Hinterkopf. Eine offizielle Klassifikation durch ein Board wird es aber nicht geben. Die guten kommen von den Board-Mitgliedern selbst, die bösen von Benutzern, die dann sehr böse werden, oder solchen, die schon seit Jahren nicht mehr aktiv sind und sich nicht wehren können.
• Zu den Anmerkungen im Einzelnen:
  • Sicherheitslücken sind sofort zu beseitigen; auf Fehlfunktionen ist so zu reagieren, dass kein Schaden entsteht. Notfalls hat das Skript eine Situation, mit der es nicht klarkommt, im Vorfeld zu erkennen und wird dann nicht weiter aktiv. Wenn Schaden angerichtet wird und das nicht sehr zeitnah beseitigt wird, dann folgt die administrative Abschaltung. Wenn der Fehler darin besteht, dass keine Funktion erbracht wird, dann wird sie halt nicht erbracht.
  • Ein Review aller Änderungen ist nicht umsetzbar.
    • Personell gibt es schlicht null freie Kapazität, die das zeitnah leisten könnte. Ich nicht, du nicht im ersten Halbjahr 2014, und auch der Rest ist voll ausgelastet. Ein Pflichtreview jeder Änderung würde also entweder zu einem nicht hinnehmbaren Stau (eigentlich einer Blockade) führen oder die Beteiligten unter massiven Druck setzen, alle eigenen Pläne über den Haufen zu werfen und alle eigenen Prioritäten hintanzustellen.
    • Wenn die Grundversion solide ist, dann gibt es immer mal kleine Optimierungen, Abfangen unvorhergesehener Situationen, Tippfehler in Meldungen oder verständlichere Formulierungen usw. Das müsste auch alles durch den Review, was in professionellen Systemen und für die weltweite Wiki-Software auch so gehandhabt wird.
    • Ich finde mich nur mit Mühen vier Wochen später noch durch meinen eigenen Code durch; und das überhaupt nur durch intensive innere Dokumentation und weil ich seit Jahrzehnten nach gleichen Mustern programmiere. Ich habe weder Zeit noch Nerv, mich bei jeder Änderung von Neuem in die Gedankenwelt anderer Leute einzuarbeiten und verantwortlich die Auswirkungen einer Umprogrammierung abzuschätzen und dafür geradezustehen; erst recht nicht, wenn ich das Skript nie selbst eingesetzt habe und dessen gewünschte Funktion nie im Alltag beobachtet hatte. Zumal die obigen Anforderungen keine innere (Programmierer-) Doku vorsehen und auch deine Skripte in dieser Richtung ausbaufähig wären. Es ist auch kein Gemeinschaftswerk vieler Entwickler wie MW, sondern geht immer noch stark auf Einzelpersonen zurück.
    • Die Kernfunktionen stehen im BNR, für das schadenfreie Funktionieren ist der Benutzer verantwortlich und Bugs mit Folgeschäden sind zeitnah abzustellen, sonst kommt das Teil von der Liste. Den Rest müssen die tatsächlichen Anwender mit dem Maintainer abkaspern.
  • „erfordert keine zusätzliche Konfiguration durch den Benutzer“ – das gilt für die Basisversion oder wenn die Vorgabe konkreter Seiten oder Kategorien oder individuelle Filterbedingungen usw. nicht erforderlich ist.
    • Natürlich kann jedes bessere Skript über die für alle Anwender erstmal praktikablen Grundeinstellungen hinaus optional an besondere Ansprüche, erfahrene Benutzer, zusätzliche Meldungen und erweiterten Funktionsumfang angepasst werden.

Liebe Grüße --PerfektesChaos 11:16, 18. Jul. 2014 (CEST)

Die Benutzer werden nicht auf jeder Seite mit Hunderten kB belästigt, nur damit die Skripte feststellen, dass sie ja nur beim Editieren wirksam werden. – Der Code liegt nach einmaligem Laden im Cache, ob der nun immer eingebunden wird oder nur dann, wenn er gebraucht wird, spielt keine Rolle. Der einzige Vorteil, und damit auch der einzige Grund, warum ich selbst diesen Ansatz verfolge, ist es, beim Debuggen sich nicht erst durch eine kilometerlange Liste an eingebundenen Skripts kämpfen zu müssen, bis man gefunden hat, was man sucht. Das funktioniert aber nur, wenn es ein Ladeskript für alles gibt, wenn jedes Skript wie du vorschlägst seinen eigenen Lade-Code hat, macht es das nur noch schlimmer.

Nur beobachtbare WMF-Benutzerseiten sind erlaubt, bei denen jede Version nachvollzogen werden kann; so mal eben böswillig einen sysop edit token ausborgen. – Frommes, aber leider realitätsfernes Wunschdenken. Es weiß ja schon fast niemand, was wikEd alles an anderen Skripten nachlädt (dazu unten mehr), und es würde nicht auffallen, wenn da etwas Bösartiges dabeiwäre. Daran, dass man Administratoren vertrauen muss, dass sie keinen bösartigen Code einfügen, kann man nichts ändern. Aber Vertrauen vererbt sich nicht so leicht, und damit reicht es eben nicht aus, dass bei der Einrichtung des Gadgets ein Administrator einmalig dem Skriptautor das Vertrauen ausgesprochen hat, dass dieser keinen bösartigen Code einfügt. Das Edit-Token eines Administrators ist noch das Harmloseste, was ein Angreifer erlangen kann, die CU-Erweiterung stellt auch eine API zur Verfügung.

Bei den Altlasten sehe ich das anders: Es ist niemand zu vermitteln, dass ein seit fünf Jahren funktionierendes Skript aus formalen Gründen abgeschaltet wird. – Deshalb habe ich den hic sunt dracones-Abschnitt vorgeschlagen. Dass ein Skript wieder rausfliegt, wenn es nicht gepflegt wird, sollte nur für neue Gadgets gelten, bei denen die Anwender damit schon von vornherein gewarnt sind, dass dies passieren könnte.

Sicherheitslücken sind sofort zu beseitigen; […] administrative Abschaltung. – Wie oben angekündigt, ein kleiner Exkurs über die Skripte, die wikEd lädt:

1. Wikipedia:WikEd: „Schnelles zeige Vorschau zeigt eine lokale Vorschau unter Verwendung von InstaView mit Ajax Technologie“ Soweit ich sehe, trifft das noch immer zu, auch wenn diese Vorschau direkt danach durch die des MW-Parsers ersetzt wird. Und es wird dafür Pilafs Originalskript verwendet.
2. Wikipedia:Helferlein/Navigation-Popups: „Liefert eine Voransicht (Preview) des Artikeltextes (Dank an Pilaf für sein Live-Preview-Skript, das dies ermöglicht)“ Auch das trifft zu, wobei Navigations-Popups eine Kopie verwendet.
3. https://en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-popups.js&action=history: „security fix“ (mehrfach), „another unsanitized table attribute“, „escape image filename“, „aggressively sanitize anything that looks like a tag“. Und dreimal darfst du raten welcher Teil des Codes da betroffen ist. Und nein, in Pilafs Original wurde nichts geändert. Ich denke, ich muss nicht erklären, was jeder Hacker, der lesen kann, aus diesen drei Punkten über wikEd erfährt.

Ein Review aller Änderungen ist nicht umsetzbar – Wenn sich jetzt keiner findet, der die Änderung reviewen kann oder will, dann findet sich in ein paar Jahren, wenn der ursprüngliche Autor nicht mehr aktiv ist oder sein Skript aufgegeben hat, niemand, der es weiterpflegt. Wenn ein Skript nicht zu einem Gadget wird, dann heißt das ja nicht, dass es niemand verwenden kann. Es heißt nur, dass man einen Eintrag in seiner common.js machen muss statt eines Häkchens in den Einstellungen, dass der potentielle Nutzer also aufmerkt: „Das ist keine offizielle, vollständig auf korrekte Funktion überprüfte Einstellung, du bist selbst verantwortlich in dem, was du mit diesem Skript tust.“ Natürlich wäre es wünschenswert, wenn sich Nutzer das auch bei einem Gadget sagen würden, aber das tun die meisten nun einmal nicht. Und wer einer Kopieranweisung für seine common.js nicht folgen kann, der hat offenbar nicht einmal die Lesekompetenz eines Grundschülers, mit sojemand habe ich kein Mitleid.

--Schnark 10:18, 19. Jul. 2014 (CEST)

• Um mit deinen letzten Betrachtungen zu beginnen: Anwender machen sich keine Vorstellungen von der Kurzlebigkeit der Skripte.
  • Bereits nach einem Jahr ist eine turnusmäßige Generalpolitur angesagt.
  • Ist man zum screengrabbing gezwungen, kann das nur beim permanent aktiven Benutzer angeboten werden, weil von einer auf die andere Woche mit Anpassungen zu rechnen ist.
  • Sehr viele der gewünschten und beliebten Skripte arbeiten intensiv mit der Benutzeroberfläche, Browserfunktionen usw. zusammen.
  • Änderungen der Browser-Technologie, Mobiltechnik, neue Skins, Weiterentwicklung der MediaWiki-Software machen ein halbwegs komplexes Skript mit mehr als einem Dutzend Zeilen nach fünf Jahren zum Totalschaden.
  • Die Rahmenbedingungen ändern sich einfach.
  • Niemand von uns weiß, ob er in drei Jahren noch aktiv sein kann; und welche Personen dann aktiv und in der Lage sind, komplexe fremde Skripte zu durchschauen und weiterzuentwickeln und wenigstens funktional zu halten, weiß nur die random-Funktion.
  • Ein umfangreiches Skript als Werk einer Einzelperson ist immer mit dem Risko der Vergänglichkeit behaftet. Es soll gute Dienste tun; jetzt und solange der Erfinder präsent ist. Deshalb ist es auch ein prinzipiell begrüßenswerter Ansatz, dass auf Labs die Tools durch Tool-Arbeitsgruppen entwickelt und gepflegt werden sollten und nicht grundsätzlich als Personen-Accounts wie auf dem Toolserver.
  • Ein Review jeder Einzeländerung würde erfordern, dass täglich jeder Edit gegengezeichnet werden müsste. Also ggf. auch dies und das und sowas. Dazu müssten die Tools zu mehreren entwickelt und gepflegt werden, um die Auswirkungen abschätzen zu können; und die verantwortliche Übernahme dann durch einen Admin vorgenommen werden. Die Zahl der aktiven Admins mit verschärften JS-Kenntnissen kommt mit Mühen in den einstelligen Bereich.
• Es müssen alle möglicherweise eingebundenen Ressourcen, insbesondere aber Skripte, in der Dokumentation aufgelistet sein.
  • Schon allein zur langjährigen Wartung und zum Verfolgen von Ausfällen ist das zwingend erforderlich, von der Sicherheitsüberprüfung aller Beteiligten mal abgesehen.
  • Man kann es nicht oft genug betonen: Die Doku ist genauso wichtig, eigentlich wichtiger als das Skript selbst.
  • Ich kenne da eine tausendfach kopierte Benutzeroberfläche, die nicht einmal eine Dokumentationsseite hat, sondern nur ein FAQ. Sie bindet etliche sonstige Skripte ein bzw. bietet sie zur Ausführung an, ohne dass irgendwo aufgelistet wäre, was das alles ist.
• Alle CU sollten grundsätzlich einen Zweitaccount erhalten.
  • Nur dieser bekommt die erweiterten Rechte.
  • Der Alltags-Account wird für Artikelarbeit genutzt und alltägliche Verwaltungsangelegenheiten, und mag vor Helferlein überquellen.
  • Der Zweitaccount wird sehr spartanisch ausgestattet und lediglich für Abfragen genutzt; vielleicht auch mal einen kleinen Absatz auf eine Disku schreiben, ohne VE oder wikEd oder sonstwas.
  • Du hast einen guten Namen; kannst du ja mal auf WD:CU vorschlagen und nett von mir grüßen.
  • Während Admin-Aktionen auffallende Spuren hinterlassen und reversibel sind, kann sich CU auf Ausspähen beschränken. Wobei auch CU geloggt wird, aber das mag zwischen Hunderten von Einzelqueries untergehen.
  • OS sinngemäß; wobei die noch spurenloser agieren und noch lohnenderes Ziel wären.
  • Ich würde ja den Hexer angreifen; da sind so schön viele alte Skripte.
• Es wird immer erst eine Reaktion und Konsequenzen geben, nachdem etwas passiert ist.
  • Solange alles eitel Sonnenschein ist, werden Blockierer und Bedenkenträger nur verspottet. Es funktioniert doch, was wollt ihr denn? Man soll nicht immer so negativ denken.
  • Eine Warnung vor Seeschlangen mag man ja überall drannageln; aber das würde nur abstumpfen, wenn dort sechs Jahre lang nie etwas passiert war, und hätte bei den Tausenden potentieller Nicht-Leser keine Konsequenz. Egal ob ich hier vor irgendwas gewarnt werde oder nicht; ich brauche dieses Werkzeug, und bei allen anderen funktioniert das ja auch ohne Probleme.
• Wenn ich das richtig sehe, sind seit Jahren keine JS-Gadgets mit mehr als einer Mini-Aufgabe hinzugekommen.
  • Das ist auch ganz gut so; ich habe keine Ambitionen, daran etwas zu ändern.
  • Wenn, dann würde ich nach den Erfahrungen der letzten acht Jahre nur noch eine Importerleichterung aus der verantwortlichen Benutzerseite (markAdmins) hinzufügen; nicht aber komplexen Arbeitscode als Gemeinschaftsverantwortung.
  • Was einmal im Bestand ist, das ist da auf ewig. Ohne einen triftigen Grund bekommt man das auch nicht mehr weg. Insofern ist es auch müßig, über wikEd zu fluchen. Man kann aber aus derart komplexen Systemen lernen. Und vielleicht verbietet ja MediaWiki nächstes Jahr das Bearbeiten des Quelltextes völlig; dann hat sich diese Frage auch gelöst. (VE for use for every content edit.)
• Was die Einbindung größerer JS-Codes betrifft:
  • O doch; es macht einen messbaren Unterschied. Auf mittelprächtigen Büro-PC konnte ich auch mit den Profilern deutliche Zeitunterschiede messen; insbesondere Opera wurde sehr zäh.
  • Meine Hausnummer liegt bei 100 kB, zu denen ich das selektive Laden routinemäßig vorsehen würde.
  • Bei VE und ULS, insbesondere in deren ersten Phasen der Zwangsaktivierung, kam es zur Verzögerung von mehreren Sekunden bei einem Mini-Artikel über einen deutschen Hügel, den es in keiner anderen WP gab.
  • Es hat schon seinen Grund, warum ich auf einer Spezialseite die 400 kB des komprimierten WSTM nicht einbinde.
• „Das funktioniert aber nur, wenn es ein Ladeskript für alles gibt“
  • Das wäre ja mal eine nette Sache für das sagenumwobene Gadgets 2.0, nach dem wir schon seit Jahren dürsten: Nicht nur skins, rights und targets, sondern auch eine Liste von namespace-Nummern, kanonischen Spezialseiten oder Liste von action-Werten.
  • Nicht ohne Grund steht seit einiger Zeit am Ende jeder meiner Dokus eine einschlägige Tabelle.

Liebe Grüße, und nett von dir was zu sehen --PerfektesChaos 18:10, 19. Jul. 2014 (CEST) kl.erg 18:20, 19. Jul. 2014 (CEST)

Ein Review jeder Einzeländerung würde erfordern, dass täglich jeder Edit gegengezeichnet werden müsste. Also ggf. auch […] sowas. – Jeder Administrator, der kopieren kann, kann diesen Edit auch reviewen. Außerdem schlug ich vor: außer der betroffene Teil ist durch Softwaretests abgedeckt, die weiterhin bestanden werden. Wenn man das großzügig interpretiert, dann bräuchte es nur jemand außer mir, der Benutzer:Schnark/js/browsertest verwendet und bestätigt, dass der Test weiterhin bestanden wird.

Alle CU sollten grundsätzlich einen Zweitaccount erhalten. – Nicht umsetzbar, zumal das gleiche Problem ja auch für alle Stewards besteht.

Ich würde ja den Hexer angreifen; da sind so schön viele alte Skripte. – Und Steward-Rechte. Zusammen mit CORS sollte es möglich sein, auf jedem beliebigen WMF-Wiki CU- und OS-Rechte zu bekommen. Und überall Code in die common.js einzufügen, der mir E-Mail-Adressen und Beobachtungslisten der aktiven Benutzer zukommen lässt, das sollte eine ganze Menge Geld wert sein.

Bei VE und ULS, insbesondere in deren ersten Phasen der Zwangsaktivierung, kam es zur Verzögerung von mehreren Sekunden – Beim VE mag es tatsächlich an der Größe des Codes liegen, aber nicht an der Download-Zeit, sondern beim Parsen. Bei ULS war es zum einen bugzilla:56894, zum anderen die Tatsache, dass ein Skript, was rechenintensive Operationen mit allen Knoten des DOM-Baums ausführt eben langsam ist.

--Schnark 12:09, 21. Jul. 2014 (CEST)

• Softwaretest (meint Modultest, für Mitleser) sind gut und schön, aber nicht alles.
  • Automatisierbare Modultests können Basisfunktionen und einfache Programmeinheiten überprüfen.
  • Ich setze vor jedem Speichern eines produktiven Lua-Moduls die Kategorie:Wikipedia:Lua/Modul/Testseite für einen letzten Routinetest ein.
  • Modultests können nur die Szenarien finden, die vorher als Konstellation erkannt und definiert wurden. Ein Fehler in URLutil blieb ein Dreivierteljahr unbemerkt, weil die arithmetische Konstellation bestimmter IP nicht abgedeckt war.
  • Modultests können gut Basisfunktionen checken, versagen aber bei komplexen interaktiven Abläufen oder wenn projektweit viele Seiten einbezogen sind. Hier können nicht alle Abfragen über externe Seiten mit manpulierten Resultaten simuliert werden, weil dieser Eingriff in die Programmlogik sebst fehleranfällig und gefährlich kompliziert wäre. Interaktive Abfolge wäre: Wenn der Benutzer Gadget X aktiviert hat und beim Bearbeiten eines Abschnitts in der Zusammenfassung auf Tab drückt, passiert im Browser Y seit Version Z dies und das, falls der Artikel noch nicht gesichtet war.
  • 2010 hatte ich noch Modultests in WSTM eingesetzt, das aber irgendwann aufgegeben, weil sie nie einen Fehler fanden. Das Problem stellte sich immer erst in realen Artikeln heraus, wenn in einem Einleitungsabschnitt (und nur dort) eine Bildlegende eine Vorlage enthielt, bei der nach dem Vorlagennamen ein Kommentar folgte, in dem ein nowiki-Tag enthalten war.
  • Ein automatischer Softwaretest auf einem System alle 24 Stunden ist eine tolle Sache. Unstimmigkeiten werden detektiert, und oft sind es Folgefehler von gravierenden Problemen an völlig anderer Stelle. Gerade auch bei nicht reproduzierbaren Fehlern ist die Protokollierung hilfreich.
• Modultests sind grundsätzlich nicht geeignet, unbeabsichtigte Sicherheitslücken oder vorsätzliche unerwünschte Wirkungen aufzudecken. Die reguläre Funktion ist ja vorhanden.
  • Da hilft lediglich aufwändige Code-Lektüre durch absolute Experten, die nur sporadisch und nicht mit jedem Review erfolgen kann. Vermeidung gefahrenträchtiger Programmierkunststücke, jshint und gut lesbarer Quellcode nebst interner Dokumentation sind dabei wichtig. Die an Ort und Stelle unauffällige und harmlose Veränderung kann 1000 Zeilen weiter große Wirkung haben.
• Komplexe Skripte mit hundert und mehr Programmzeilen können nur auf Beta erprobt und in realitätsnahen Situationen auf der simulierten WP durchgespielt werden, möglichst auch durch mehrere Anwender.
  • Bei einer komplexen Überarbeitung, die nicht nur ein paar Einzelzeilen betrifft, hilft auch ein diff nicht weiter.
• ULS, VE, wikEd: Auch wenn ich die Dinger deaktiviert habe, dann parsen die nicht nur JS-Deklarationen, sondern machen eine umfängliche Initialisierung, um am Ende zu merken, dass sie in der Situation oder ob der Benutzereinstellung überhaupt nicht gebraucht werden. Wenn ich ULS abschalte, dann hat der keinen riesigen DOM-Baum an einer großen Seite zu flöhen, sondern nur ein kleines interaktives Fensterchen zum Wiedereinschalten vorzuhalten, und braucht auch nicht mehr Code auf jeder Seite.

LG --PerfektesChaos 20:13, 20. Aug. 2014 (CEST)

Natürlich können Tests nur die Existenz, nicht die Abwesenheit von Fehlern zeigen. Aber von ein paar Ausnahmen abgesehen trifft das auf ein Code-Review auch zu (und im Beispiel mit Gadget X, Tab in der Zusammenfassung mit Browser Y seit Version Z im ungesichteten Artikel wird auch ein Code-Review nichts helfen). Aber in einer Umgebung, in der niemand ein Review leisten kann oder will, können Tests eine praktikable Alternative darstellen.

Der normale Benutzer interessiert sich ohnehin nicht dafür, ob der Code in allen erdenklichen Zusammenhängen funktioniert, er soll nur im Normalfall funktionieren und auch nach einer Änderung weiterhin funktionieren, und das kann ein Test ja durchaus bestätigen.

Selbst wenn man den Code versteht, ist ein Test manchmal besser geeignet. Beispiel: Diese Änderung im Code wird von dieser Änderung im Test begleitet. Die Änderung am Code ist schwer zu verstehen: Wenn du dich nicht sehr konzentrierst, kannst du nicht sehen, ob lis nach steigenden oder fallenden Folgen sucht (in der ersten Version in meinem Testwiki war es nämlich genau falsch herum, obwohl ich den Code nochmals sorgfältig durchgelesen habe), und die Auswirkungen dieser Änderung auf tatsächliche Diffs sieht man im Code ohnehin nicht. Der Test dagegen zeigt, dass lis in den beiden Extrem- und zwei Standardfällen das richtige Ergebnis liefert, und die Auswirkung auf die Diffs nicht falsch und sogar eher positiv ist.

2010 hatte ich noch Modultests in WSTM eingesetzt, das aber irgendwann aufgegeben, weil sie nie einen Fehler fanden. – Dass Tests keine Fehler finden, ist doch eigentlich der erwünschte Fall, wenn du nach jeder Änderung am Code erst einmal wieder mehrere kaputte Tests reparieren müsstest, dann müsstest du an deinen Fähigkeiten als Programmierer zweifeln.

Modultests sind grundsätzlich nicht geeignet, unbeabsichtigte Sicherheitslücken […] aufzudecken. – In begrenztem Rahmen schon, nämlich dann, wenn im ersten Review alle Stellen identifiziert werden, die potentiell gefährlich sind und diese dann gezielt mit potentiell schädlichen Eingaben getestet werden. Benutzer:Schnark/js/templateEditor.js/test.js hat ein paar Tests nach diesem Prinzip, und falls ich mal beim Überarbeiten das Escapen verpfusche, würde dieser Test das feststellen. --Schnark 10:01, 22. Aug. 2014 (CEST)

Proposal Gadget-externalsearch.js

Ich habe auf MediaWiki dieses schöne Standard-Gadget gesehen mw:MediaWiki:Gadget-externalsearch.js. Dies wäre eine sehr gute Verbesserung, da die interne Suche mehr schlecht als recht ist (nur ein Buchstabendreher und das Ergebnis ist nichts), und wir bekommen alle Vorteile der besten Suchmaschine der Welt(⁉ dessen Syntax auch gut bekannt ist …). ↔ User: Perhelion 13:02, 26. Jan. 2016 (CET)

Lies die Beschreibung genau, dann wirst du erkennen, warum es sinnlos ist, dieses Gadget hier anzubieten. --Schnark 10:31, 27. Jan. 2016 (CET)

Danke der Antwort, "die URLs" kann man ja natürlich anpassen. Auch wenn einiges evtl. nicht von Google abgedeckt sein sollte, finde ich es immer noch sehr nützlich. PS: Evtl. sollte ich erst mal ein paar praktische Beispiele liefern und die ganze Chose für mich testen. ↔ User: Perhelion 11:07, 27. Jan. 2016 (CET)

Ja, die URLs können angepasst werden. Aber nicht von "man", sondern von Serveradministratoren. --Schnark 11:20, 27. Jan. 2016 (CET)

Nun gibt es MediaWiki:Gadget-externalsearch.js. LG -- User: Perhelion 14:45, 18. Sep. 2018 (CEST)

related articles

Es gibt die Funktion "related articles" (dt. "mehr erfahren"), durch die durch mw:Extension:RelatedArticles unter Artikeln mehr oder weniger ähnliche Artikel mit Link zum Lesen anbieten kann. Die dewiki-Community hat im Jahr 2016 per Wikipedia:Meinungsbilder/Mehr erfahren eine standardmäßige Einführung abgelehnt, weshalb die Erweiterung hier nicht geladen wird.

Die Funktion könnte trotzdem für viele Benutzer interessant sein, und sie kann mit Javascript nachgeladen werden. User:MisterSynergy/relatedArticles.js (Kopie aus ruwiki, damit das einfach beobachtbar bleibt) enthält dazu den entsprechenden Javascript-Code, der sicherstellt dass relevante HTML-Elemente vorhanden sind, und dann die Erweiterung lädt. Alles eher trivial, und das funktioniert nach meinen Beobachtungen auch in allen Skins.

Als interessierter Benutzer muss ich jetzt allerdings das Skript noch in meine common.js einbinden, und (zurzeit) in meiner common.css Regeln überschreiben, die die Funktion in der mobilen Ansicht wieder anschaltet, weil in MediaWiki:Mobile.css die Anzeige der entsprechenden HTML-Elemente unterdrückt wird. Die Nutzung ist deshalb zurzeit im Wesentlichen Javascript-vertrauten Benutzern vorbehalten, das sollte sie aber meines Erachtens nicht sein. Ich bitte darum, ein entsprechendes Gadget einzurichten, so dass das Setzen eines Hakens über Special:Preferences#mw-prefsection-gadgets reicht, um die Funktion an- bzw. abzuschalten.

Dokumentation und ggf. einige andere Sachen müssten noch erstellt werden, da kann ich gern mithelfen. Da ich bisher keine Gadgets eingerichtet habe, bitte ich um Rückmeldung, was wo im Einzelnen gebraucht wird. Danke und Viele Grüße, MisterSynergy (Diskussion) 15:20, 8. Aug. 2019 (CEST)

Ich bin für das Gadget. Soweit ich weiß wirken Gadgets aber in der mobilen Ansicht nicht. Das müsste jede(r) für sich mit minerva.js und minerva.css machen. Versionsimport halte ich für sinnvoll. Gruß --FriedhelmW (Diskussion) 20:34, 8. Aug. 2019 (CEST)

Wenn das Gebilde hier ein offizielles Gadget werden soll, dann würde die Community und deren Techies auf ewig die Verantwortung für ordnungsgemäße Funktion, sinnvolle Resultate, keine Sicherheitslücken und unverzügliche Beseitigung von Problemen übernehmen und dauerhaft die Pflege garantieren.

• Das werden die Techies der Community voraussichtlich nicht mitmachen.
• Schon allein deshalb nicht, weil die Community diese Funktionalität offiziell per MB abgelehnt hat. Wenn es eine auch aus inhaltlichen Gründen abgelehnte Funktion ist, ist schwer nachvollziehbar, warum es als offizielles Community-Gadget geadelt werden soll.
• Auch die inhaltliche Qualität der durch einen dumpfen „Algorithmus“ gewonnenen Ergebnisse (gleiche Wörter in viel verlinkten Artikeln) wurde mehrfach in diversen aktuellen FZW-Stellungnahmen beanstandet, und die absurden Resultate scharf kritisiert.
• Es steht dir frei, dies als Benutzerskript jedem anzubieten, zu dokumentieren, anschließend auf WP:HX zu verlinken und dauerhaft die Pflege und Verantwortung zu übernehmen. Die weitaus überwiegende Menge der Skripte hat den Status eines Benutzerskripts. Daraus resultiert auch sofort die Verantwortlichkeit: zwischen Doppelpunkt und Schrägstrich.
• Neue Community-Gadgets zu neuen Funktionen für alle Benutzer haben wir schon seit einem Jahrzehnt nicht mehr eingeführt.
• Wer das für sich persönlich für so weltbewegend hält, dass unbedingt diese Funktion benötigt würde, kann sich das anhand der gut geschriebenen Doku selbst installieren.
• Wobei es nicht erforderlich ist, an irgendwelchen CSS-Seiten herumzumachen; das könnte ein wirklich gut geschriebenes Gadget (dieses hier ist aus mehrerlei Gründen auf Anfängerniveau) automatisch selbst erledigen. Wobei Anfängerbasteleien ohnehin kein Ausgangspunkt sind, den Techies der dewiki-Community die Verantwortung aufzuschwatzen.
• Wobei es sowieso völlig rätselhaft ist, warum überhaupt noch ein separates Skript mit diesen Aktivitäten erforderlich ist. Wenn das Hand und Fuß hätte, dann wäre alles das in die globale Ressource bereits integriert, und es würde als Aufruf ausreichen:

            mw.loader.load( "ext.relatedArticles.readMore.bootstrap" );

• Wobei mir die Funktion deines Codes suspekt ist; die dortige Funktion mw.loader.using() setzt voraus, dass irgendeine Nachfolgefunktion angegeben wird, die ausgeführt werden soll, nachdem eine Ressource geladen wurde. Dieser Pflichtparameter wurde nicht angegeben, und bereits das legt nahe, dass das keine robuste und stabile Programmierung wäre, sondern Anfänger-Pfusch, der früher oder später zu seltsamen Dysfunktionalitäten führen wird, und eigentlich jetzt schon Fehlermeldungen auslösen müsste.

VG --PerfektesChaos 23:05, 8. Aug. 2019 (CEST)

Ich halte es für höchst angemessen, dass die Community hier die Wartung übernimmt – gerade *weil* es das Meinungsbild mit dem bekannten Ergebnis gegeben hat. In dem Meinungsbild wurde die standardmäßige Aktivierung für alle Benutzer, angemeldet wie unangemeldet, abgelehnt; das Meinungsbild kann mir und anderen Benutzern aber nicht verbieten, die Erweitung trotzdem zu benutzen, und die Möglichkeit eines Gadgets wurde in dem Meinungsbild überhaupt nicht behandelt. Zurzeit erfordert die Aktivierung der Funktion allerdings erweiterte technische Fähigkeiten, und wenn "die Community" nun die Einrichtung eines Gadgets verweigert, zumal mit Verweis auf das Meinungsbild, das ist das im Grunde der Fuck-you-Mittelfinger für alle technisch weniger begabten Benutzer. Ich finde es daneben, wenn verfügbare technische Funktionen durch absichtlich erschwert gehaltene Zugänglichkeit einer kleinen Elite mit speziellen Fähigkeiten vorbehalten bliebe.

Nun kann und möchte ich niemanden zwingen, hier die Wartung eines Gadgets zu übernehmen. Wer es könnte, aber nicht möchte, darf für sich diese Aufgabe gern ablehnen oder das hier ignorieren. Dann aber bitte hier nicht im Weg rumstehen, danke …

Ob die Funktion gute Ergebnisse liefert, oder absurde Resultate, ist im Übrigen nicht relevant für die Einrichtung eines opt-in Gadgets. Es kann wohl jeder für sich selbst bewerten, was man da angeboten bekommt.

Wie Du selbst siehst und schreibst, ist "mein" Javascript-Code eher nicht von höchster Qualität, und das liegt daran dass ich praktisch keine Ahnung von Javascript, JQuery, und Mediawiki habe. Den Code habe ich angeboten bekommen, allerdings wurde er als schneller Hack zusammengeschustert. Ich verstehe was er macht, aber nicht warum das so (oder anders) zu tun ist und wenn was auseinanderfällt, kann ich es bestenfalls vielleicht und nur mit viel ausprobieren reparieren.

Ich habe nun noch ein bisschen weiter rumprobiert (!); tatsächlich scheint die Erweiterung auch zu funktionieren, wenn sie einfach mit mw.loader.load geladen wurde (keine Ahnung, warum im phab-Thread von zwei Benutzern mw.loader.using empfohlen wurde). Allerdings muss für die mobile Oberfläche das CSS weiterhin verändert werden, weil an entsprechender Klasse in dewiki über Mediawiki:Mobile.css projektweit rumgepfuscht wird. Alles in allem dürfte die Wartung eines solchen Gadgets für versierte Benutzer aber eher einfach sein, wenn es macht im Grunde nichts anderes als eine fertige und von WMF gut gepflegte Funktionalität nachzuladen. —MisterSynergy (Diskussion) 09:51, 10. Aug. 2019 (CEST)

Zur Frage ob load() oder using() siehe mw:ResourceLoader/Core modules und https://doc.wikimedia.org/mediawiki-core/master/js/#!/api/mw.loader. Ich meine es macht keinen Unterschied. Gruß --FriedhelmW (Diskussion) 13:22, 10. Aug. 2019 (CEST)

Abschaltung des Gadgets "Deepcat"

Der hinter Deepcat stehende Service "Catgraph" wird zum Ende des Monats abgeschalten, das Gadget Deepcat wird dann wirkungslos. Deepcat wurde von WMDE entwickelt, wird jedoch nicht mehr maintained. Bereits jetzt funktioniert Deepcat oft nicht. Eine vergleichbare Funktion ist unter dem Namen "deepcategory" seit 2018 in die Suche eingebaut und kann über die Erweitere Suchoberfläche (Advanced Search) genutzt werden. Das Gadget sollte deshalb bereits jetzt aus der Liste entfernt werden. -- Michael Schönitzer (WMDE) (Diskussion) 13:59, 9. Jan. 2020 (CET)

Nutzung von Chats Graphen und Vorlagen aus anderen Sprachumgebungen z.B. der englischen Wikipedia

Sehr geehrtes Team aus dem Bereich von Technik/Skin und Gadgets ich wende mich an Euch mit der Bitte um Unterstützung und Diskussion für folgenden Sachverhalt.

Neben der technischen Komponente liegt der Funktion "switscher" auch eine befriedenden Komponente bei, die unsägliche Diskussionen wie am Beispiel ist log-Skalierung oder lin-Skalierung angemessen (vgl. weiter unten) ganz einfach lösen könnte. Ich Bitte um Diskussion und ggf. Hilfe bei der Umsetzung, gerne will ich praktisch mitwirken, wenn ich darf und wenn ich kann.

Vielen Dank

--ETRS89UTM (Diskussion) 16:21, 26. Jul. 2020 (CEST)

Am Beispiel der folgenden Wiki-Seite

https://en.wikipedia.org/wiki/COVID-19_pandemic_in_Germany/Statistics

ist erkennbar, dass dort verschiedene Graphen Chart-Darstellungen machen, das gibt es in der deutschen Wikipedia auch ABER z.B. die Funktion Switcher gibt es nicht.

Meine Fragen: Wie können solche Vorlagen sprachübergreifend genutzt werden? oder Wie kann die Vorlage in den deutschen Namensraum übertragen und dadurch nutzbar gemacht werden?

Ich würde mich gerne einbringen, leider fehlen mir aktuell noch die Kenntnisse. Vielen Dank für alle Hinweise, Antworten und Unterstützungen.

--ETRS89UTM (Diskussion) 08:01, 25. Jul. 2020 (CEST)

{{Switcher|
{{Graph:Chart <!-- Combined (lin) -->
|type=line
|linewidth=1
|showSymbols=1
|width=1200
|height=450
|colors=#F46D43, #FFC000, #A50026, #87CEEB
|xAxisTitle=Date
|xAxisAngle=-60

|x=24 Feb, 25 Feb, 26 Feb, 27 Feb, 28 Feb, 29 Feb, 1 Mar, 2 Mar, 3 Mar, 4 Mar, 5 Mar, 6 Mar, 7 Mar, 8 Mar, 9 Mar, 10 Mar, 11 Mar, 12 Mar, 13 Mar, 14 Mar, 15 Mar, 16 Mar, 17 Mar, 18 Mar, 19 Mar, 20 Mar, 21 Mar, 22 Mar, 23 Mar, 24 Mar, 25 Mar, 26 Mar, 27 Mar, 28 Mar, 29 Mar, 30 Mar, 31 Mar, 1 Apr, 2 Apr, 3 Apr, 4 Apr, 5 Apr, 6 Apr, 7 Apr, 8 Apr, 9 Apr, 10 Apr, 11 Apr, 12 Apr, 13 Apr, 14 Apr, 15 Apr, 16 Apr, 17 Apr, 18 Apr, 19 Apr, 20 Apr, 21 Apr, 22 Apr, 23 Apr, 24 Apr, 25 Apr, 26 Apr, 27 Apr, 28 Apr, 29 Apr, 30 Apr, 1 May, 2 May, 3 May, 4 May, 5 May, 6 May, 7 May, 8 May, 9 May, 10 May, 11 May, 12 May, 13 May, 14 May, 15 May, 16 May, 17 May, 18 May, 19 May, 20 May, 21 May, 22 May, 23 May, 24 May, 25 May, 26 May, 27 May, 28 May, 29 May, 30 May, 31 May, 1 Jun, 2 Jun, 3 Jun, 4 Jun, 5 Jun, 6 Jun, 7 Jun, 8 Jun, 9 Jun, 10 Jun, 11 Jun, 12 Jun, 13 Jun, 14 Jun, 15 Jun, 16 Jun, 17 Jun, 18 Jun, 19 Jun, 20 Jun, 21 Jun, 22 Jun, 23 Jun, 24 Jun, 25 Jun, 26 Jun, 27 Jun, 28 Jun, 29 Jun, 30 Jun, 1 Jul, 2 Jul, 3 Jul, 4 Jul, 5 Jul, 6 Jul, 7 Jul, 8 Jul, 9 Jul, 10 Jul, 11 Jul, 12 Jul, 13 Jul, 14 Jul, 15 Jul, 16 Jul, 17 Jul, 18 Jul, 19 Jul, 20 Jul, 21 Jul, 22 Jul, 23 Jul
|yType=integer
|yAxisMin=1

|y1Title=Total confirmed cases
|y1=16, 18, 21, 26, 53, 66, 117, 150, 188, 240, 349, 534, 684, 847, 1112, 1460, 1884, 2365, 3062, 3795, 4838, 6012, 7156, 8198, 10999, 13957, 16662, 18610, 22672, 27436, 31554, 36508, 42288, 48582, 52547, 57298, 61913, 67366, 73522, 79696, 85778, 91714, 95391, 99225, 103228, 108202, 113525, 117658, 120479, 123016, 125098, 127584, 130450, 133380, 137439, 139987, 141672, 143457, 145694, 148046, 150383, 152438, 154175, 155193, 156337, 157641, 159119, 160758, 161703, 162496, 163175, 163860, 164807, 166091, 167300, 168551, 169218, 169575, 170508, 171306, 172239, 173152, 173772, 174355, 174697, 175210, 176007, 176752, 177212, 177850, 178281, 178570, 179002, 179364, 179717, 180458, 181196, 181482, 181815, 182028, 182370, 182764, 183271, 183678, 183979, 184193, 184543, 184861, 185416, 185674, 186022, 186269, 186461, 186839, 187184, 187764, 188534, 189135, 189822, 190359, 190862, 191449, 192079, 192556, 193243, 193499, 193761, 194259, 194725, 195228, 195674, 196096, 196335, 196554, 196944, 197341, 197783, 198178, 198556, 198804, 198963, 199375, 199726, 200260, 200843, 201372, 201574, 201823, 202345, 202799, 203368

|y2Title=Number of active cases
|y2=16, 18, 21, 26, 53, 66, 117, 150, 188, 240, 349, 534, 684, 829, 1092, 1440, 1862, 2345, 3008, 3741, 4780, 5940, 7084, 8114, 10907, 13854, 16543, 18483, 22164, 24032, 25805, 30410, 34435, 38657, 40658, 43343, 45230, 47934, 51250, 54879, 58220, 61672, 63357, 64318, 55067, 56195, 57239, 57714, 57606, 55917, 53929, 51730, 49881, 48162, 47929, 46803, 45768, 43659, 41415, 39652, 38262, 37138, 36535, 34943, 33024, 31126, 29331, 27377, 26128, 25247, 23783, 21929, 20576, 19072, 18334, 17882, 17423, 16558, 15775, 14972, 14216, 13628, 13291, 13041, 12162, 11503, 11007, 10605, 10038, 9734, 9734, 9113, 8700, 8215, 8106, 7908, 7807, 7782, 7404, 7106, 6519, 6383, 6158, 6132, 6211, 5919, 5632, 5432, 5461, 5311, 5341, 5282, 5070, 4939, 4754, 4808, 5262, 5552, 6040, 6174, 6267, 6235, 6352, 6508, 6789, 6842, 6700, 6186, 5940, 5934, 5671, 5786, 5623

|y3Title=Total deaths
|y3=0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2, 2, 3, 5, 5, 8, 12, 13, 12, 12, 20, 31, 47, 55, 86, 114, 149, 198, 253, 325, 389, 455, 583, 732, 872, 1017, 1158, 1342, 1434, 1607, 1861, 2107, 2373, 2544, 2673, 2799, 2969, 3254, 3569, 3868, 4110, 4294, 4404, 4598, 4879, 5094, 5321, 5500, 5640, 5750, 5913, 6115, 6288, 6481, 6575, 6649, 6692, 6831, 6996, 7119, 7266, 7369, 7395, 7417, 7533, 7634, 7723, 7824, 7881, 7914, 7935, 8007, 8090, 8147, 8174, 8216, 8247, 8257, 8302, 8349, 8411, 8450, 8489, 8500, 8511, 8522, 8551, 8581, 8613, 8646, 8668, 8674, 8711, 8729, 8755, 8763, 8781, 8787, 8791, 8800, 8830, 8856, 8872, 8883, 8882, 8885, 8895, 8914, 8927, 8948, 8954, 8957, 8961, 8973, 8985, 8994, 9003, 9010, 9012, 9016, 9024, 9036, 9048, 9054, 9060, 
9063, 9064, 9068, 9071, 9078, 9082, 9083, 9084, 9086, 9090, 9095, 9101

|y4Title=Total recoveries (estimated)
|y4=0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 18, 18, 19, 19, 46, 46, 46, 60, 60, 72, 72, 72, 72, 72, 422, 3290, 5600, 5900, 7600, 9600, 13500, 16100, 18700, 21400, 23800, 26400, 28700, 30600, 33300, 46300, 49900, 53913, 57400, 60300, 64300, 68200, 72600, 77000, 81800, 85400, 88000, 91500, 95200, 99400, 103300, 106800, 109800, 112000, 114500, 117400, 120400, 123500, 126900, 129000, 130600, 132700, 135100, 137400, 139900, 141700, 143300, 144400, 145600, 147200, 148700, 150300, 151700, 152600, 153400, 154600, 155700, 156900, 158000, 159100, 159800, 160300, 161200, 162000, 162800, 163200, 164100, 164900, 165200, 165900, 166400, 167300, 167800, 168500, 168900, 169100, 169600, 170200, 170700, 171200, 171600, 171900, 172200, 172600, 173100, 173600, 174100, 174400, 174700, 174900, 175300, 175700, 176300, 176800, 177100, 177500, 177700, 178100, 179100, 179800, 180300, 181000, 181300, 181700, 182200, 182700,
183100, 183600, 184000, 184400, 184600, 185100, 185500, 186000, 186400, 186900, 187200, 187400, 187800, 188100, 188600, 189000

|yGrid=true
|xGrid=true
}}
|Show linear scale|
{{Graph:Chart <!-- Combined (log) -->
|type=line
|linewidth=1
|showSymbols=1
|width=1200
|height=450
|colors=#F46D43, #FFC000, #A50026,#87CEEB
|xAxisTitle=Date
|xAxisAngle=-60

|x=24 Feb, 25 Feb, 26 Feb, 27 Feb, 28 Feb, 29 Feb, 1 Mar, 2 Mar, 3 Mar, 4 Mar, 5 Mar, 6 Mar, 7 Mar, 8 Mar, 9 Mar, 10 Mar, 11 Mar, 12 Mar, 13 Mar, 14 Mar, 15 Mar, 16 Mar, 17 Mar, 18 Mar, 19 Mar, 20 Mar, 21 Mar, 22 Mar, 23 Mar, 24 Mar, 25 Mar, 26 Mar, 27 Mar, 28 Mar, 29 Mar, 30 Mar, 31 Mar, 1 Apr, 2 Apr, 3 Apr, 4 Apr, 5 Apr, 6 Apr, 7 Apr, 8 Apr, 9 Apr, 10 Apr, 11 Apr, 12 Apr, 13 Apr, 14 Apr, 15 Apr, 16 Apr, 17 Apr, 18 Apr, 19 Apr, 20 Apr, 21 Apr, 22 Apr, 23 Apr, 24 Apr, 25 Apr, 26 Apr, 27 Apr, 28 Apr, 29 Apr, 30 Apr, 1 May, 2 May, 3 May, 4 May, 5 May, 6 May, 7 May, 8 May, 9 May, 10 May, 11 May, 12 May, 13 May, 14 May, 15 May, 16 May, 17 May, 18 May, 19 May, 20 May, 21 May, 22 May, 23 May, 24 May, 25 May, 26 May, 27 May, 28 May, 29 May, 30 May, 31 May, 1 Jun, 2 Jun, 3 Jun, 4 Jun, 5 Jun, 6 Jun, 7 Jun, 8 Jun, 9 Jun, 10 Jun, 11 Jun, 12 Jun, 13 Jun, 14 Jun, 15 Jun, 16 Jun, 17 Jun, 18 Jun, 19 Jun, 20 Jun, 21 Jun, 22 Jun, 23 Jun, 24 Jun, 25 Jun, 26 Jun, 27 Jun, 28 Jun, 29 Jun, 30 Jun, 1 Jul, 2 Jul, 3 Jul, 4 Jul, 5 Jul, 6 Jul, 7 Jul, 8 Jul, 9 Jul, 10 Jul, 11 Jul, 12 Jul, 13 Jul, 14 Jul, 15 Jul, 16 Jul, 17 Jul, 18 Jul, 19 Jul, 20 Jul, 21 Jul, 22 Jul, 23 Jul
|yType=integer
|yAxisMin=1

|y1Title=Total confirmed cases
|y1=16, 18, 21, 26, 53, 66, 117, 150, 188, 240, 349, 534, 684, 847, 1112, 1460, 1884, 2365, 3062, 3795, 4838, 6012, 7156, 8198, 10999, 13957, 16662, 18610, 22672, 27436, 31554, 36508, 42288, 48582, 52547, 57298, 61913, 67366, 73522, 79696, 85778, 91714, 95391, 99225, 103228, 108202, 113525, 117658, 120479, 123016, 125098, 127584, 130450, 133380, 137439, 139987, 141672, 143457, 145694, 148046, 150383, 152438, 154175, 155193, 156337, 157641, 159119, 160758, 161703, 162496, 163175, 163860, 164807, 166091, 167300, 168551, 169218, 169575, 170508, 171306, 172239, 173152, 173772, 174355, 174697, 175210, 176007, 176752, 177212, 177850, 178281, 178570, 179002, 179364, 179717, 180458, 181196, 181482, 181815, 182028, 182370, 182764, 183271, 183678, 183979, 184193, 184543, 184861, 185416, 185674, 186022, 186269, 186461, 186839, 187184, 187764, 188534, 189135, 189822, 190359, 190862, 191449, 192079, 192556, 193243, 193499, 193761, 194259, 194725, 195228, 195674, 196096, 196335, 196554, 196944, 197341, 197783, 198178, 198556, 198804, 198963, 199375, 199726, 200260, 200843, 201372, 201574, 201823, 202345, 202799, 203368

|y2Title=Number of active cases
|y2=16, 18, 21, 26, 53, 66, 117, 150, 188, 240, 349, 534, 684, 829, 1092, 1440, 1862, 2345, 3008, 3741, 4780, 5940, 7084, 8114, 10907, 13854, 16543, 18483, 22164, 24032, 25805, 30410, 34435, 38657, 40658, 43343, 45230, 47934, 51250, 54879, 58220, 61672, 63357, 64318, 55067, 56195, 57239, 57714, 57606, 55917, 53929, 51730, 49881, 48162, 47929, 46803, 45768, 43659, 41415, 39652, 38262, 37138, 36535, 34943, 33024, 31126, 29331, 27377, 26128, 25247, 23783, 21929, 20576, 19072, 18334, 17882, 17423, 16558, 15775, 14972, 14216, 13628, 13291, 13041, 12162, 11503, 11007, 10605, 10038, 9734, 9734, 9113, 8700, 8215, 8106, 7908, 7807, 7782, 7404, 7106, 6519, 6383, 6158, 6132, 6211, 5919, 5632, 5432, 5461, 5311, 5341, 5282, 5070, 4939, 4754, 4808, 5262, 5552, 6040, 6174, 6267, 6235, 6352, 6508, 6789, 6842, 6700, 6186, 5940, 5934, 5671, 5786, 5623

|y3Title=Total deaths
|y3=0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2, 2, 3, 5, 5, 8, 12, 13, 12, 12, 20, 31, 47, 55, 86, 114, 149, 198, 253, 325, 389, 455, 583, 732, 872, 1017, 1158, 1342, 1434, 1607, 1861, 2107, 2373, 2544, 2673, 2799, 2969, 3254, 3569, 3868, 4110, 4294, 4404, 4598, 4879, 5094, 5321, 5500, 5640, 5750, 5913, 6115, 6288, 6481, 6575, 6649, 6692, 6831, 6996, 7119, 7266, 7369, 7395, 7417, 7533, 7634, 7723, 7824, 7881, 7914, 7935, 8007, 8090, 8147, 8174, 8216, 8247, 8257, 8302, 8349, 8411, 8450, 8489, 8500, 8511, 8522, 8551, 8581, 8613, 8646, 8668, 8674, 8711, 8729, 8755, 8763, 8781, 8787, 8791, 8800, 8830, 8856, 8872, 8883, 8882, 8885, 8895, 8914, 8927, 8948, 8954, 8957, 8961, 8973, 8985, 8994, 9003, 9010, 9012, 9016, 9024, 9036, 9048, 9054, 9060, 
9063, 9064, 9068, 9071, 9078, 9082, 9083, 9084, 9086, 9090, 9095, 9101

|y4Title=Total recoveries (estimated)
|y4=0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 18, 18, 19, 19, 46, 46, 46, 60, 60, 72, 72, 72, 72, 72, 422, 3290, 5600, 5900, 7600, 9600, 13500, 16100, 18700, 21400, 23800, 26400, 28700, 30600, 33300, 46300, 49900, 53913, 57400, 60300, 64300, 68200, 72600, 77000, 81800, 85400, 88000, 91500, 95200, 99400, 103300, 106800, 109800, 112000, 114500, 117400, 120400, 123500, 126900, 129000, 130600, 132700, 135100, 137400, 139900, 141700, 143300, 144400, 145600, 147200, 148700, 150300, 151700, 152600, 153400, 154600, 155700, 156900, 158000, 159100, 159800, 160300, 161200, 162000, 162800, 163200, 164100, 164900, 165200, 165900, 166400, 167300, 167800, 168500, 168900, 169100, 169600, 170200, 170700, 171200, 171600, 171900, 172200, 172600, 173100, 173600, 174100, 174400, 174700, 174900, 175300, 175700, 176300, 176800, 177100, 177500, 177700, 178100, 179100, 179800, 180300, 181000, 181300, 181700, 182200, 182700,
183100, 183600, 184000, 184400, 184600, 185100, 185500, 186000, 186400, 186900, 187200, 187400, 187800, 188100, 188600, 189000
|yScaleType=log
|yGrid=true
|xGrid=true
}}
|Show logarithmic scale}}

--ETRS89UTM (Diskussion) 08:01, 25. Jul. 2020 (CEST)

Dafür müsste en:MediaWiki:Gadget-switcher.js bei uns existieren. Habitator terrae 10:25, 25. Jul. 2020 (CEST)

Vielen Dank für die Antwort, nun stellt sich für mich die Frage, was kann,darf ich tun um dieses js bereitzustellen, wen kann man fragen und um Hilfe/Unterstützung bitten. Es wäre ein großer Vorteil, wenn solch ein switscher gerade für die Graphiken mit linearer oder log. Skalierung bereit stünde. Grund es gibt regelmäßig wilde Diskussionen. fast bis hin zu "Glaubenskriegen" ob eine Skalierung linear oder log richtig oder falsch oder gar tendenziös, oder politisch motiviert, oder gar spekulativ ist. Dies wäre sofort erledigt wenn man beide Varianten wie im Beispiel darstellen kann und dem Anwender das hin und her Schalten ermäglicht. Ergebnis: Streit vermieden, Information sehr gut aufbereitet und den jeweiligen Artikel nicht überlastet. Ich bitte um Unterstützung. Danke --ETRS89UTM (Diskussion) 09:50, 26. Jul. 2020 (CEST)

In diesem Fall hilft wohl Wikipedia Diskussion:Technik/Skin/Gadgets. Gruß --FriedhelmW (Diskussion) 11:01, 26. Jul. 2020 (CEST)

Vielen Dank FriedhelmW für die Information.

Stellungnahme:

Jeder Benutzer kann für sich selbst jedes beliebige JavaScript von jedem Ort auf dem Planeten einbinden, auch aus der englischsprachigen Wikipedia.

Hierfür bedarf es keines eigenen „deutschen“ Gadgets; im fraglichen Code tauchen auch keinerlei Vokabeln aus einer menschlichen Sprache auf, die zu übersetzen („lokalisieren“) wären.

Das Begehren deute ich dann allenfalls dahingehend, dass gewünscht wird, wir sollen dafür sorgen, dass jeder Leser irgendeiner unserer Seiten automatisch diesen JavaScript-Code ausführen soll, damit es nachgucken kann, ob in dieser Seite ein Element mit der Klasse switcher-container vorkommen würde, und dann ggf. weiter verfahren.

• Das werden wir mit größter Sicherheit nicht machen.
• Wir haben zehn Millionen Wikitext-Seiten, von denen wahrscheinlich auf ein oder zwei Seiten diese switcher-Funktion benötigt werden würde. Mag es ein ganzes Dutzend sein, egal. Es lassen sich Hunderte an Millionen URL konstruieren, um irgendwas hier darzustellen.
• Bei um 100 Millionen Seitenabrufen täglich in diesem Wiki würde das mit einer grottig schlechten Trefferquote die Performance aller Benutzer schädigen, die irgendeine andere außer der Handvoll betroffener Seitendarstellungen abrufen.

Jeder angemeldete Benutzer, der auf diese Funktion Wert legt, kann sich das gern für sich persönlich einrichten und seine private Performance schädigen; von mir aus minutenlang. Gar kein Problem. Mit Greasemonkey können das nicht angemeldete Benutzer ebenfalls.

Unsere Seiten müssen von den Autoren grundsätzlich so gestaltet werden, dass sie ohne JavaScript und Zusatzsoftware ordnungsgemäß lesbaren Wikitext darstellen.

• Wenn die Autoren der fraglichen Seite das mit ihren Grafiken nicht hinbekommen und auf Krücken angwiesen sind, ist das deren Problem. Dann müssen sie die von ihnen dargestellten Grafiken halt anders organisieren.

VG --PerfektesChaos 16:40, 26. Jul. 2020 (CEST)

Antwort auf die Stellungnahme von PerfektesChaos :

Zunächst möchte ich mich für die schnelle Stellungnahme bedanken.

Inhaltlich und technisch mag das in der Stellungnahme alles korrekt und richtig sein, das kann und möchte ich nicht beurteilen und bewerten, das können andere tun!

Was ich aber empfinde und was meine Meinung zu der Form und dem Ton der Stellungnahme ist kann ich frei hier wiedergeben!

Erstens habe ich höflich und freundlich um Information, Beratung und Unterstützung gebeten, nicht um eine Uminterpretation wie der o.g. Text "Das Begehren deute ich dann allenfalls dahingehend, ... " belegt.

Es mag sein, dass meine Frage ungeschickt ist oder war, es ist noch kein Meister vom Himmel gefallen! Ganz sicher ist und war es nie mein Anliegen mit einer "grottig schlechten Trefferquote die Performance aller Benutzer schädigen, die irgendeine andere außer der Handvoll betroffener Seitendarstellungen abrufen.".

Da haben Sie verehrter PerfektesChaos meine Frage und mein Anliegen absolut falsch verstanden oder falsch interpretiert. Denn dort wo das von mir bezeichnete Beispiel im Einsatz ist (engl. Wikipedia) scheint ein anderer Sachverhalt zugrunde zu liegen, aber das wissen Sie vermutlich besser als ich.

Es scheint mir, dass ich zufällig und unbewusst ein Thema berührt habe, das mit großen Emotionen verbunden zu sein scheint; denn der Ton Ihrer Stellungnahme scheint mir recht gereizt, das ist traurig; für Sie.

Trotzdem danke ich Ihnen für die Investition Ihrer Lebenszeit für Ihre Stellungnahme und werde Sie nicht wieder mit Fragen, die Sie wie auch immer interpretieren und in der Form unwirsch beantworten belasten. Da es mir lediglich um Information und Unterstützung ging, ich hier keine Stil und Formdiskussion beginnen will ziehe ich mich zurück.

Viele freundliche Grüße

--ETRS89UTM (Diskussion) 17:49, 26. Jul. 2020 (CEST)

Support JSON files in gadgets

Seit heute unterstützten die Gadgets auch JSON-Dateien (Task 198758, Gerrit:731284). Wie das genau funktioniert und ob uns das was bringt, habe ich noch nicht ausprobiert Ggfs. müsste das bitte umseitig noch beschrieben werden. --Raymond ^Disk. 08:23, 7. Jan. 2022 (CET)

Dunkelmodus / dark mode in deutscher Wikipedia

In der englischen Wikipedia gibt's einen aktivierbaren dark mode (unter Gadgets). In der deutschen Wikipedia finde ich das nicht unter Helferlein.

Hat jemand einen Tipp? Browserextension ist keine Möglichkeit für mich.

Danke Abdull (Diskussion) 01:01, 1. Okt. 2022 (CEST)

Siehe die Disk. dazu: WP:Technik/Skin/MediaWiki/Änderungen#Dark Mode Gadget. --Wnme (Diskussion) 10:19, 2. Okt. 2022 (CEST)

MediaWiki:Gadget-VectorClassic / MediaWiki:Gadget-VectorClassic.css

Dieses Gadget, jetzt mal angetestet, scheint nicht (mehr) zu funktionieren. M.W. sollten bei h2, h3, h4 eine sans-serif-Schriftart genommen werden. Bei mir (Chrome/Windows) nicht der Fall. Statt jetzt noch Energie reinzustecken, warum nicht das Gadget einfach entfernen (wir haben schon zu viele unnütze Helferlein)? Kann doch bei Bedarf in die eigene CSS. --Filzstift (Diskussion) 12:08, 12. Sep. 2023 (CEST)

Es gab zwar bei der Klassifizierung von Überschriften vor einem halben Jahr oder sonstwann eine Änderung, aber die schlägt hier nicht durch. class="mw-headline"

Neben dem Schriftstil geht es auch um die Schriftgröße, und diverse kleine Abstände.

Das Gadget wurde 2014 spontan eingeführt, weil in der globalen Software etwas verändert wurde, ohne vorher die Erlaubnis der deWP einzuholen.

• Es sollte mit nur zwei Mausklicks möglich sein, den Zustand von seit immer schon (seit 2010) wiederherzustellen.
• Es wird aus projektpolitischen Gründen auch ob der anderen Eigenschaften bestehen bleiben müssen. Sowas zu eliminieren gibt einen Volksaufstand; das muss jetzt auf ewig so bleiben wie es immer schon war.

Technisch kann ich deine Schilderung nicht nachvollziehen.

• Ich habe Firefox, mein Browser soll alle Webseiten erstmal sans-serif darstellen, irgendwelche Schriftarten für Wikis habe ich nicht installliert, ich nutze Vector 2010.
• Zur technischen Erörterung und ggf. Aktualisierung des Gadgets müsstest du dich an WP:TWS wenden, mit einer präziseren Schilderung deiner Konfiguration, was du wann wo siehst, was du hingegen erwartest.

VG --PerfektesChaos 13:27, 12. Sep. 2023 (CEST)