MediaWiki Diskussion:Gadgets-definition/Archiv 2016

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[MediaWiki Diskussion:Gadgets-definition/Archiv 2016#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/MediaWiki_Diskussion:Gadgets-definition/Archiv_2016#Thema_1

Twinkle

Irgendein User hatte das ja mal versucht zu portieren, vielleicht sollte man das mal "offiziell" machen und in das Menü einbinden? --Laber□^Disk 13:57, 9. Mai 2016 (CEST)

Sinnhaftigkeit von MediaWiki:Gadget-Rot-Gruen-Sehschwaeche.css in der vorliegenden Form

Ich halte dieses Gadget in der vorliegenden Form für wenig sinnvoll. Es besteht nur aus zwei CSS-Regeln:

/* Dunkelblau auf Grün, statt Rot auf Grün in der Differenzansicht */
span.diffchange {color: #00008B;}

/* Hellblau statt Rotgelb hinterlegte Einträge auf Spezial:Neue Seiten */
li.not-patrolled {background-color: #BDBDFF;}

Achtung: Beide Kommentare im Code waren vor vielen Jahren einmal richtig, sind aber heute falsch.

Die erste Regel hatte einmal den Zweck, eine Farbänderung in der Diffansicht zu bewirken (Simulation in diesem Diskussionsbeitrag). Soweit ich das sehe, ist die Regel mittlerweile wirkungslos, weil die betroffenen Elemente nicht mehr <span>, sondern <del> bzw. <ins> sind. Darüber hinaus wurde die Farbgebung der Diffansicht im Jahr 2012 grundlegend geändert, und der Eintrag auf mw:MediaWiki 1.20/de#Diff behauptet zumindest, dass dabei auf Farbfehlsichtigkeit Rücksicht genommen wurde. Daher ist es vermutlich auch gar nicht notwendig, die Regel zu reparieren.

Die zweite Regel hat eine Wirkung, die aber unerwünscht ist: Aufgrund des Patrolling-Features von MediaWiki besitzt die Seite Spezial:Neue Seiten manchmal eingefärbte Einträge, aber da wir dieses Softwarefeature zugunsten der gesichteten Versionen nicht nutzen, wird die Einfärbung in MediaWiki:Common.css entfernt. Dieses Gadget stellt die Einfärbung wieder her.

Da kein einziges Bit des Gadgets in der vorliegenden Form sinnvoll ist, wäre ich dafür, es zu entfernen. Wie sehen das andere? Ist hier ein Löschantrag notwendig? Mir geht es ausdrücklich nicht darum, ob es grundsätzlich ein Gadget zur Rot-Grün-Sehschwäche geben sollte, sondern ganz konkret um den jetzigen Code. (Davon abgesehen wäre es aber wahrscheinlich sowieso sinnvoll, dafür zu sorgen, dass die Wikipedia ohne Gadget mit Rot-Grün-Sehschwäche benutzbar ist.) Gruß --Entlinkt (Diskussion) 04:18, 15. Mai 2016 (CEST)

+1 Da gibt's nichts zu widersprechen. ↔ User: Perhelion 09:48, 15. Mai 2016 (CEST)

Strategieempfehlung:

1. Alle derzeit wirkungslos erscheinenden Bytes herauslöschen.
2. WP:BIENE kontaktieren: Alles genehm, gibt es sonstige Probleme, konveniert die aktuelle Farbwahl auf der Diffpage oder sollte nachjustiert werden?
3. Leeres Gadget belassen; ist den interessierten Benutzern weiterhin zugeordnet.
4. Sobald es bei MediaWiki, in manchen Artikeln oder unter bestimmten Bedingungen wieder ein Problem gibt, kann das sofort mit geeigneten Regeln gefüllt werden.
5. Beim Abruf vom Webserver im Paket braucht das null Bytes, oder allenfalls einen Kommentar mit der Cache-ID. Steht in einem großen Block mit site-CSS und user-CSS; frisst kein Brot.

LG --PerfektesChaos 10:04, 15. Mai 2016 (CEST)

Auf Wikipedia:BIENE wird seit diesem Edit im Jahr 2012, also seit 4 Jahren, unwidersprochen ausgesagt, dass das Problem mit der Diff-Ansicht „behoben“ sei. Daher würde ich in dieser konkreten Angelegenheit nicht nachfragen, weil ich dafür keine Notwendigkeit sehe. Bei einer Nachfrage bestünde wohl eher die Gefahr, dass irgendwelche neuen Probleme mit der Diff-Ansicht extra gesucht werden, nur damit das Gadget nicht leer ist.

Nach allem, was ich weiß, besteht das Ziel, dass MediaWiki ohne Gadget bei Rot-Grün-Sehschwäche benutzbar sein soll. Die Farben in der Diff-Ansicht wurden ja explizit auch deswegen geändert. Wenn das stimmt, wären Rot-Grün-Probleme in MediaWiki in erster Linie in der Software selbst zu beheben und nicht per Gadget.

Gruß --Entlinkt (Diskussion) 10:34, 17. Mai 2016 (CEST)

MediaWiki:Gadget-Screenreader-Optimierung-TOC.js mutmaßlich defekt

Dieses laut Special:GadgetUsage ohnehin nur wenig genutzte Helferlein (31 aktive Benutzer) ist – falls ich die Funktionsweise des Codes richtig erahne – seit der Einführung des heutigen #mw-content-text-Elements vollständig defekt. Dieses Element hat seine ID mit rev:111647 erhalten (also im Jahr 2012), existierte aber schon einige Zeit vorher.

Hintergrund: Das Gadget soll die Einleitung von Artikeln vor Infoboxen etc. verschieben. Wenn ich den Code richtig verstehe, unterstellt er, dass die Artikeleinleitung ein Geschwisterknoten von #jump-to-nav bzw. #contentSub ist. Das ist seit der Einführung des heutigen #mw-content-text nicht mehr der Fall.

Wie sollen wir damit verfahren? Ich würde dazu tendieren, vorerst die Einbindung auf der Vorderseite zu entfernen, aber den Code selbst nicht zu löschen. Gruß --Entlinkt (Diskussion) 04:57, 15. Mai 2016 (CEST)

Ich vermute, die Einleitung ist der erste <p> als unmittelbares Kind von #mw-content-text oder zumindest der erste, der nicht nur aus <img> bestünde oder so.

Das ist heutzutage mit jQuery nicht sonderlich schwer zu realisieren; sind im Kern vier Zeilen.

Vielleicht gibt es eine Mutterversion oder einen gepflegten Fork auf einem anderen Wiki oder bei Benutzern? Unsere Dokus sind immer so mickrig.

Grundsätzlich kann ich das den auf Screenreadern angewiesenen Leutchen bauen, die das Fehlen vielleicht noch nicht wirklich bemerkt haben. Nur habe ich eine andere Agenda. Hauptaufwand ist Austesten und Dokumentieren. Prinzip so aus der Lameng etwa wie folgt:

function fresh( $content ) {
   var $paras = $content.children( "p" ),
       i, $p;
   // Aus $paras unerwünschte <p> ausfiltern, bis richtiges i gefunden.
   // Soll vielleicht unter den ersten vier ein Fettschrift-Element enthalten oder so.
   $p = $paras.eq( i );
   $p.detach();
   $content.prepend( $p );
}
if ( ! ( mw.config.get( "wgNamespaceNumber" ) % 2 )   &&   etc. ) {
   /*
    Alle Inhalts-NR.
    Auch Hilfe- und Projektseiten haben Einleitungsabschnitte, aber Shortcut und Linkboxen am Anfang.
    Dynamischer Preview-Modus darf auch genauso vorgelesen werden wie hinterher "view".
   */
   mw.hook( "wikipage.content" ).add( fresh );
}

{{Dieser Artikel}} und Minibilder und Infoboxen und so haben <div> oder <table> – manchmal gibt es sonstige Unterschrifts-Faksimile oder Logos und Koordinaten im DOM; weiß nicht ob es konkurrierende <p> geben könnte.

Trivialfall i = 0;

LG --PerfektesChaos 09:46, 15. Mai 2016 (CEST)

In Anbetracht der Tatsache, dass zu den Zeiten, als das Gadget noch funktionierte, es gefühlt mehr Benutzer versehentlich als absichtlich aktiviert haben ([1], [2]), bin ich klar gegen irgendeinen Versuch, das nach so langer Zeit zu reparieren. Das stiftet mehr Verwirrung als es nützt. Ich würde sogar noch einen Schritt weitergehen und den Code auch aus dem MW-Namensraum entfernen. Zur Dokumentation reicht eine Kopie auf Wikipedia:BIENE/Screenreader. --Schnark 09:43, 17. Mai 2016 (CEST)

• Ich schlage zunächst Anfragen vor:
  • WD:BIENE
  • Bitte um kurze Rückmeldungen auf WP:Umfragen.
• Je nach bekundetem Interesse dann weitere Entscheidung.
• Ich hätte kein Problem damit, einen Zehnzeiler für dewiki oder global als Benutzerskript anzubieten.
  • Dazu müsste ich erstmal verstehen, was genau ich wann machen soll.
    • Ich kann den ersten para auch hinter die Überschrift und die Überschrift physisch oberhalb der Kopfzeile schieben, egal welche Skin. Oder dort oben am body Kopien einfügen. Auch mit allen p bis TOC oder erste Überschrift <H1.
  • Hauptaufwand ist die Dokumentation.
  • In den nächsten Wochen und Monaten sicher nicht. Warteschlange kringelt sich schon um den Weihnachtsbaum.

LG --PerfektesChaos 10:20, 17. Mai 2016 (CEST)

Entfernten Signatur-Button wieder rückgängig

Auf Wunsch und immer wiederkehrender Anfragen zu dessen Verschwinden, hier die Anfrage zum Einfügen folgenden Skiptes (momentan nur für Wikieditor, für die Klassische Bar gibt es ja schon die „Extra-Editbuttons-Helferlein“): signature-button. Wie man auf En und hier sehen kann gab es überhaupt gar keine „gegenläufige“ Meinungsumfrage dazu. Raymond stand einem "generellen Revert" auch positiv gegenüber und sprach von einem Meinungsbild. Bis dahin ist ein ein status quo per Opt-in mehr als angebracht⁉ Siehe aktuell WP:FzW #Icon wieder einsetzen. ↔ User: Perhelion 16:33, 30. Jun. 2016 (CEST)

Du kannst das gern als von dir gepflegtes Benutzerskript den Interessierten anbieten.

Ansonsten wirst du gemerkt haben, dass wir als Community aus bestimmten Gründen schon seit mehreren Jahren keine JS-Skripte mehr anbieten; allenfalls triviale CSS-Gadgets, wobei sich selbst bei diesen gezeigt hat, dass sie unvorhersehbare Nebenwirkungen haben können.

Nebenbei wäre eine routinemäßige Kapselung Stand der Technik.

LG --PerfektesChaos 17:21, 30. Jun. 2016 (CEST)

Ähm* ne habe ich noch nicht gemerkt. Wer sagt denn sowas?? Ich benutze keine Variablen daher braucht man auch keine Kapselung (frei nach Krinkle). PS: Ich brauche das Script nicht, ich werde es auf Beta schieben. LG -- ↔ User: Perhelion 19:47, 30. Jun. 2016 (CEST)

Ich halte es für unsinnig, jetzt noch neue Skripte für die alte Bearbeiten-Oberfläche anzubieten. In den betroffenen Namensräumen ist der VisualEditor der Standardeditor, für den Wikieditor neue Skripte zu schreiben heißt auf sterbende Technologien zu setzen. --Schnark 12:02, 1. Jul. 2016 (CEST)

Okay, das glaube ich ehrlich gesagt nicht. Quelltext-Bearbeitung wird auch in 10 Jahren nicht ausgestorben sein (auch bei nicht alten Hasen). Wo hast du denn dieses überaus positive vorhersehende Feedback her? Alles was ich über den VE gehört habe ist eher negativ (kann aber auch schon ein Jahr her sein). Allerdings lasse ich mich auch gerne eines besseren belehren. -- ↔ User: Perhelion 12:27, 1. Jul. 2016 (CEST)

Bei den Artikelbearbeitungen neuer Benutzer wird inzwischen zu über 80 % der VE eingesetzt. Quelltext-Bearbeitungen werden zwar nicht aussterben, wohl aber der WikiEditor. Stattdessen wird die Quelltextbearbeitung so aussehen wie auf https://visualeditor-test.wmflabs.org (scheint gerade Probleme zu haben, dieses Video bietet einen guten Eindruck). --Schnark 12:41, 1. Jul. 2016 (CEST)

type= bei gemischten Ressourcen ab heute

Siehe WP:HW#type=.

Wurde heute begrüßt von Gadget "WikiMiniAtlas" styles loaded twice. Migrate to type=general.

Die nachstehenden Gadgets sind gemischt:

• DeepCat
• Pfeil-hoch
• PrettyLog
• ReferenceTooltips
• WikiMiniAtlas

Müssten erstmal die zweifelsfreien Spätzünder explizit nachgerüstet werden, und dann wird man sehen was übrigbleibt.

VG --PerfektesChaos 10:35, 7. Okt. 2016 (CEST)

DeepCat ent-CSSt sich (auf meinen Rat hin) gerade; wie eine Stunde nach dem letzten Post angekündigt wurde. VG --PerfektesChaos 14:42, 7. Okt. 2016 (CEST)

Ich habe ein paar types ergänzt. Sollen die reinen CSS-Gadgets auf [ResourceLoader|type=styles|top] umgestellt werden. Die dürften dann ja nicht per JS geladen werden, wie es "früher" bei reinen CSS-Modulen über ResourceLoader gewesen ist. Der Umherirrende 15:17, 7. Okt. 2016 (CEST)

• Wenn ich Task und Quellcodes richtig verstanden habe und ein erster Blick in die Server-Antwort es zu bestätigen scheint, so brauchen reine CSS-Gadgets jetzt weder type noch top, weil sie in der ersten Server-Antwort per <link> im head deklariert werden.
• Die gemischten oder nachgeladenen würden hingegen später mit <style> in den DOM-body eingefügt werden.
• Wenn MW mal eine saubere Doku- und Manual-Seite schreiben würde statt einiger Abschnitte in der Extension, könnte man sich da sicherer sein.
• DeepCat.

LG --PerfektesChaos 16:43, 7. Okt. 2016 (CEST)

MediaWiki:Gadget-ImageSiblings.js defekt?

Kann es sein, dass dieses Gadget momentan defekt ist? Beim Versuch der Inbetriebnahme erhalte ich folgenden Fehler:

index.php:1 Uncaught SyntaxError: Unexpected token <

… und index.php beginnt so:

<br />
<font size='1'><table class='xdebug-error xe-warning' dir='ltr' border='1' cellspacing='0' cellpadding='1'>
<tr><th align='left' bgcolor='#f57900' colspan="5"><span style='background-color: #cc0000; color: #fce94f; font-size: x-large;'>( ! )</span> Warning: Creating default object from empty value in /data/project/file-siblings/public_html/index.php on line <i>146</i></th></tr>

Gruß --Entlinkt (Diskussion) 06:09, 15. Mai 2016 (CEST)

Naja, das scheint die von //tools.wmflabs.org/file-siblings/index.php gelieferte Antwort zu sein, auf die Ajax-Anfrage.

Erwartet wird JSON und deshalb etwas das mit { beginnt.

Die Antwort beginnt mit < und dürfte die zitierte Fehlermeldung in HTML/XML sein.

Ist also weniger ein Problem von JS als dieses Tools in Labs.

Das sollte bei mode: 'json' auf Fehler anders reagieren und Warnungen dann generell unterlassen.

Vielleicht besser Magnus Manske kontaktieren; möglicherweise waren aber die übergebenen Anfrageparameter unvollständig und es wird kein leerer Dateiname erwartet oder sowas.

LG --PerfektesChaos 09:33, 15. Mai 2016 (CEST)

In Anbetracht der Tatsache, dass der Fehler immer noch besteht, sich aber bisher niemand auf WP:FzW oder sonstwo beschwert hat (zumindest habe ich davon nichts mitbekommen), könnte man beim Aufräumen dieses Gadget einfach mal entfernen, es scheint ja keiner zu vermissen. Was auch nicht verwunderlich ist, da es ja nur auf lokalen Dateibeschreibungsseiten wirksam ist und diese dank dem Mediaviewer und dem Dateibeschreibungsseiten-Überspring-Standard-Gadget nur sehr selten besucht werden. –Schnark 11:56, 20. Dez. 2016 (CET)

+1 Ich erkenne auch keinen weiteren Sinn in dem Gadget, vor allem Anbetracht der Tatsache, dass das hiesige Kategoriesystem eher rudimentärer Natur ist (wobei man [3] und [4] gleich zusammen verpacken kann) ↔ User: Perhelion 17:56, 20. Dez. 2016 (CET)

+1 --Atlasowa (Diskussion) 22:35, 20. Dez. 2016 (CET)

Sofern auch Magnus den Fehler nicht beseitigen mag, sollte das Gadget am besten deaktiviert werden. --Leyo 09:16, 27. Mär. 2017 (CEST)