MediaWiki Diskussion:Common.js

Automatische Archivierung

Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit 7 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind. Die Archivübersicht befindet sich unter MediaWiki Diskussion:Common.js/Archiv.

Vorlage:Autoarchiv-Erledigt/Wartung/Festes_Ziel

css-Klasse für "Nur im Edit-Modus sichtbar"

Aus "Nur_im_Edit-Modus_sichtbar" WP:WVW:

Was würdet ihr von der Idee halten? Eine css-Klasse mit display:none, die durch Javascript in Commons.js im Edit-Modus aktiviert wird. Es gibt gerade mehrere Baustellen, wo man gerne einen Hinweis im Edit-Modus hätte (z.B. Vorlage:Belege fehlen). Auch gibt es mehrere Vorlagen, die bestimmte Hinweise, Fehlermeldungen, usw. nur für Projektmitarbeiter anzeigen, die das in ihrer eigenen css aktiviert haben. Viele dieser Meldungen könnte/sollte man im Edit-Modus auch für alle sichtbar machen. Implementierung analog zur Admin-CSS. Merlissimo 12:25, 26. Jul. 2009 (CEST)

Bug 19499 ist eventuell gefixed (bis jetzt noch nicht live), danach könnten wir auch wieder mit REVISIONID arbeiten. Das Problem ist aber immer, das der Benutzer auf Vorschau klicken muss, damit er die Hinweise sieht, das macht auch nicht jeder. Aber man könnte einen Teil erreichen. Welche Vorlagen haben bestimmte Hinweise für Projektmitarbeiter? Ich kenne aktuell keine (nur damit man ein Beispiel hat) --Der Umherirrende 16:18, 26. Jul. 2009 (CEST)

Vorlage:§/Wartung und Verwandte (§§,§§§,Art.) stammt von mir, ist aber auch nur von woanders geklaut übernommen. Bin aber schön öfters über sowas gestolpert - aber mehr Beispiele habe ich spontan auch nicht im Kopf, da müsste ich nochmal suchen. Wäre aber vielleicht auch bei veralteten Vorlagen als Alternative sinnvoll. Merlissimo 17:35, 26. Jul. 2009 (CEST)

Finde die Idee gut. Am besten auf MediaWiki:Common.js oder MediaWiki:Onlyifediting.js fragen? --Revolus Echo der Stille 11:50, 5. Aug. 2009 (CEST)

Das wäre auch mit reinem CSS möglich:

div.action-submit, span.action-submit { display:none }
body.action-submit div.action-submit { display:block }
body.action-submit span.action-submit { display:inline }

Beispiel div

Beispiel span --Fomafix 12:45, 25. Feb. 2012 (CET)

Oder kürzer mit :not():

body:not(.action-submit) .action-submit { display:none }

Beim Internet Explorer geht das aber erst ab Version 9. --Fomafix (Diskussion) 23:52, 24. Mai 2012 (CEST)

Aktuelle Client Uhrzeit mit Minuten

Hi! Ich suche eine Möglichkeit um in Artikel wo Zeitzonen angegeben sind (z.B. Städte, Länder, Zeitzonen selbst) die dort aktuelle Uhrzeit einzutragen. Wäre mMn keine "Spielerei", sondern eine große Hilfe für User, die die aktuelle Uhrzeit eines Ortes bzw. um wieviel diese dort gegenüber der ihrigen vor/nachgeht interessiert. Das ist sonst (v.a. wegen der unterschiedlichen Sommerzeiten) nur ausgesprochen schwer eruierbar. Meines Wissens nach geht das nur mittels JavaScript - siehe dazu WP:WikiProjekt Vorlagen/Werkstatt#Vorlage Zeitzone. Frage: Wer könnte mir dabei helfen? --Sebastian.Dietrich 21:42, 22. Mai 2010 (CEST)

Ich schlag mal eine Vorlage {{UTC-Ticker|+2|30}} vor, die dann <span class="utcticker">+2:30 <span class="ticker">({{#time:H":"i":"s|2 hours 30 minutes}})</span></span> ausgibt. Der passende code (onload vorrausgesetzt) könnte so aussehen:

var tickers = getElementsByClassName(document.getElementById("bodyContent"), "span", "utcticker");
if (tickers && tickers.length > 0) ticktack(true);
function ticktack(start) {
   jetzt = new Date();
   if (jetzt.getSeconds() == 0 || start)
      for (i = 0; i < tickers.length; i++) {
         try {
            t = tickers[i].firstChild.data;
            hours = parseInt(t.match(/\d+/g)[0]);
            minutes = parseInt(t.match(/\d+/g)[1]);
            fb = t.match(/[+-]/)[1];
         } catch(e) { continue; }
         there = new Date(jetzt.parse() + ((fb==="+")? 1 : -1)*(hours*60+minutes)*60*1000);
         sp = tickers[i].getElementByTagName("span")[0];
         sp.data = "("+there.getUTCHours()+":"+there.getUTCMinutes()+")";
      }
   }
   window.setTimeout(function(){ticktack();},1000);
}

Könnte das funktionieren? Ich habe noch nie intensiv mit dem Date-Objekt gearbeitet.
meint -- ✓ ^Bergi 14:24, 24. Mai 2010 (CEST)

getElementsByClassName

Die Abschnitte der Form

var divs = document.getElementsByTagName("div");
for (i = 0; i < divs.length; i++) {
  if (divs[i].className !== "CSS-Klassenname") { continue; }
  …
}

können mit getElementsByClassName von http://bits.wikimedia.org/skins-1.5/common/wikibits.js für moderne Browser beschleunigt werden. --Fomafix 15:29, 7. Aug. 2010 (CEST)

Hinweis: Die getElementsByClassName-Implementation aus wikibits.js hat Inkonsistenzen (Bug 16459), die sie zwar nicht unbenutzbar machen, aber zu beachten sind. Gruß --Entlinkt 18:08, 7. Aug. 2010 (CEST)

Dachte jetzt ist jQuery angesagt:

$j("div.CSS-Klassenname").each(

? -- Perhelion 18:13, 5. Jan. 2011 (CET)

Ja, inzwischen. Ich denke wir sollten noch warten, bis MediaWiki 1.17 ausgerollt ist und dann unsere Skripte anpassen. --Fomafix 18:47, 5. Jan. 2011 (CET)

Auf jQuery umstellen kann man auch jetzt schon, hat man hinterher "nur noch" den ResourceLoader. Ich schreib schon mein Zeuchs auf jQuery um. --Guandalug 18:54, 5. Jan. 2011 (CET)

Scheint erledigt zu sein. Der Umherirrende 21:47, 13. Jun. 2012 (CEST)

Noch nicht erledigt. Es gibt weiterhin Konstrukte mit var divs = document.getElementsByTagName("div"); und anschließendem filtern auf bestimmte CSS-Klassen. Dies sollte durch jQuery ersetzt werden. Moderne Browser sollten damit schneller sein. Genaue Zeitmessungen könnten mit http://jsperf.com/ gemacht werden. --Fomafix (Diskussion) 22:03, 13. Jun. 2012 (CEST)

Ok, aber das bedeutet meistens noch mehr Arbeit, weil man danach ja mit jQuery-Objekten weiterarbeiten sollte. Ich hatte nach dem Wort aus der Überschrift gesucht, aber das wäre ja das Ziel und nicht das zu Änderne, daher falsch gedacht. Der Umherirrende 22:18, 13. Jun. 2012 (CEST)

Habe noch ein paar entfernt. Einige verbleiben in JavaScript was zu Vorlagen gehört, wie Vorlage:Link FA/Vorlage:Link GA, Vorlage:InterProjekt, Vorlage:Galerie und zu OSM ist erledigt Der Umherirrende 17:49, 15. Nov. 2012 (CET). Das sind jeweils Pakete, die man vermutlich generell überarbeiten/auf jquery stellen sollte. Der Umherirrende 14:12, 16. Jun. 2012 (CEST)

Funktion erstellt: History-Einträge zusammenfassen

Das Tool fasst Beiträge von gleichen Autoren zusammen...

...und klappt bei Bedarf auch die Unterversionen aus

Hallo,

mich hat immer sehr gestört, dass aufgrund vieler Edits eines Authors die Versionsgeschichte so überfüllt war. Ich habe mit JavaScript bzw. jQuery eine Lösung entwickelt, die aufeinanderfolgende Einträge von Autoren zusammenfasst.

Aus

10.10.2011 05:10 FooBar (21.618 Bytes)
10.10.2011 04:48 Blibla (21.611 Bytes)
10.10.2011 04:47 FooBar (21.610 Bytes)
10.10.2011 04:47 FooBar (21.600 Bytes)
10.10.2011 04:46 FooBar (21.605 Bytes)
10.10.2011 04:45 FooBar (21.604 Bytes)
10.10.2011 04:42 FooBar (21.604 Bytes)
10.10.2011 04:40 FooBar (21.616 Bytes)
09.10.2011 18:00 Asdfgh (21.588 Bytes)

Mache

10.10.2011 05:10 FooBar (21.618 Bytes)
10.10.2011 04:48 Blibla (21.611 Bytes)
10.10.2011 04:47 FooBar (21.610 Bytes) (Zusammengefasst: 6 Einträge)
09.10.2011 18:00 Asdfgh (21.588 Bytes)

Ich nannte es "historyCombine", hier ist der Quelltext: Benutzer:Nightfly85/common.js

Per Klick auf den Text werden die versteckten Elemente ein- und ausgeblendet. Sinnvoll ist es zusammen mit einer angepassten common.css, in der Einträge passend formatiert werden: Benutzer:Nightfly85/common.css (Abschnitt: historyCombine)

Wäre es möglich, diesen Vorteil allen Wiki-Usern zugänglich zu machen? Gruß --_{Nightfly85 | Disk} 13:11, 6. Okt. 2011 (CEST)

Ich würde daraus ein eigenständiges Gadget machen - dann kann sich jeder (angemeldete) Benutzer entscheiden, ob er#s möchte oder nicht... --Guandalug 13:14, 6. Okt. 2011 (CEST)

Wie geht das? :) --_{Nightfly85 | Disk} 13:26, 6. Okt. 2011 (CEST)

Ist nur was für Admins (wegen der fehlenden Schreibrechte anderer im MediaWiki-Namensraum). Ich schau mir deinen Code mal an.... --Guandalug 14:34, 6. Okt. 2011 (CEST)

Wäre das nicht sogar was, was direkt in die MediaWiki Software integriert werden könnte? --Stefan 14:47, 6. Okt. 2011 (CEST)

Jo... aber DAS macht dann wer anders ;) --Guandalug 14:58, 6. Okt. 2011 (CEST)

Aber irgendwie müssen die Entwickler ja drauf aufmerksam werden. ;) --Stefan 15:26, 6. Okt. 2011 (CEST)

Getestet und folgende Bemerkungen: Den Pfeil, den ich auf den beiden Screenshots von dir erkennen kann, hab ich nicht. Außerdem wäre es imho sinnvoll, erst ab drei Beiträgen zusammenzufassen, bei zwei lohnt sich das meiner Meinung nach noch nicht. Bei einer Seite, die nur von einem einzigen Benutzer bearbeitet wurde, würde ich von einem Zusammenfassen auch eher absehen. SteMicha 18:47, 6. Okt. 2011 (CEST)

sehr cool, sowas wollte ich immer serverseitig haben, bin aber unerklärlicherweise nie drauf gekommen, das auf dem client zu machen. klasse! -- ∂ 22:11, 6. Okt. 2011 (CEST)

Mein Tipp: statt nach body.action-history zu suchen einfach oben if(mw.config.get('wgAction') != "history") return; einfügen. Ist deutlich schneller / resourcensparender. Ansonsten: Gerne als Gadget, aber nicht mehr. -- ✓ ^Bergi 00:41, 7. Okt. 2011 (CEST)

Update

Screenshot

So, habe das Script nun grundlegend überarbeitet. Einhergehend habe ich das ganze nun auch etwas besser dokumentiert. Das Zusammenfassen findet nun erst bei mind. drei Beiträgen statt (kann aber bequem per Variable geändert werden). Auch Bergis Tipp habe ich befolgt. Weil es offenbar Probleme bei der Pfeil-Zeichendarstellung gibt, habe ich nun eine Wiki-eigene Pfeilgrafik verwendet. Den Link für das ein- und Ausklappen setzte ich nach hinten - ist irgendwie logischer. Ich verweise nochmal auf die Benutzer:Nightfly85/common.js und die ebenfalls aktualisierte Benutzer:Nightfly85/common.css. Für Fragen, Kritik und Anregungen bin ich offen. --_{Nightfly85 | Disk} 01:10, 7. Okt. 2011 (CEST)

Ein paar Anmerkungen auf die Schnelle:

• Statt var $listItems = $('ul#pagehistory li'); ist var $listItems = $('#pagehistory').find('li'); effizienter.
• Vergleiche mit 0 sollte man immer mit drei Gleichheitszeichen schreiben, statt stack.length == 0 also stack.length === 0 (auch wenn das hier vollkommen unnötig ist).
• '&nbsp;<a href="#" class="mw-historycombine-autoBundleInfo">zeige ' + ctText + ' von ' + lastAuthorName + '</a>' ist durch lastAuthorName prinzipiell anfällig für XSS, überlass das Escapen am besten vorgefertigten Funktionen: ' ' + mw.html.element('a', {href: '#', 'class': 'mw-historycombine-autoBundleInfo'}, 'zeige ' + ctText + ' von ' + lastAuthorName)

--Schnark 09:27, 7. Okt. 2011 (CEST)

Danke für die Tipps. Habe meine JS-Datei aktualisiert. --_{Nightfly85 | Disk} 10:05, 7. Okt. 2011 (CEST)

Der Pfeil wird bei immer noch nicht angezeigt. Kann das vielleicht daran liegen, dass ich meine .css nicht angepasst habe? Außerdem möchte ich nochmal vorschlagen, bei Seiten mit Bearbeitungen von nur einem einzigen Benutzer die Beiträge nicht zusammenzufassen. SteMicha 11:51, 7. Okt. 2011 (CEST)

Ja, ohne eine angepasste CSS sind die Pfeile nicht zu sehen. Bei Seiten mit Bearbeitung nur eines Authors werde ich mir mal Gedanken machen. --_{Nightfly85 | Disk} 11:56, 7. Okt. 2011 (CEST)

Bearbeitungen nur eines Autors werden doch sowieso nicht zusammengefasst? Das passiert aufgrund des Bugs, dass bei mehreren Bearbeitungen am Ende der Versionsgeschichte kein "neuer" Autor mehr gefunden wird, der das Zusammenklappen der vorigen auslöst. Löst man den Bug, muss man natürlich eine Option für nicht-Reduzieren bei mindestens x Aufeinanderfolgenden (default: Länge der History) ermöglichen.

PS: Wäre noch schön, wenn nach dem Aufklappen "verstecke" statt "zeige" angezeigt wird. Das ist aber kompliziert, weil durch die Animationsdauer mehrere Klicks trotz nur einer Klappaktion möglich sind. Zudem fände ich persönlich .slideToggle schöner als .fadeToggle:-) -- ✓ ^Bergi 16:39, 7. Okt. 2011 (CEST)

Du hast nicht die neueste "Version" getestet, dort sind die beschrieben Bugs behoben. Außerdem habe ich dort bereits auch slideToggle benutzt :) Deine Idee mit "zeige"/"verstecke" werde ich bald einbauen. --_{Nightfly85 | Disk} 16:52, 7. Okt. 2011 (CEST)

+Zeitpunkt der ersten ausgeblendeten Bearbeitung wär gut: zeige weitere 8 Beiträge von Nightfly85 seit 12:59, 28. Sep. 2011. Eine wahrnehmbare Animationsdauer sollte es nicht geben. Ist da (schon) irgendwo eine Schaltfläche, um alle Bearbeitungen aller Benutzer einzublenden? Ist es möglich und will man die Zusammenfassungen der Ausgeblendeten Bearbeitungen (wenn sie denn welche haben) fließend aneinandergereiht einblenden? Ein Grund für die letzten zwei Fragen: Manchmal suche ich mit der Browser-Textsuche in der Versionsgeschichte. --Diwas 17:06, 7. Okt. 2011 (CEST)

• Das mit dem Zeitpunkt hätte ich auch gerne. Leider besitzt dieses Element / diese Elemente im Wiki-Quellcode (Markup) kein eigenes Element, es ist quasi eine rohe Text-Node. Eine Lösung, um an die Zeitinformation zu gelangen, bin ich daher leider noch nicht gekommen.
• Die Animationsdauer werde ich verkürzen
• Ich werde eine Schaltfläche einbauen, um alle Elemente auszuklappen
• Fließend aneinandergereihte Zusammenfassungen: Mhh, wie sieht sowas denn aus? Da geht die Übersicht doch erst Recht flöten?

Danke für deine Kritik! --_{Nightfly85 | Disk} 17:12, 7. Okt. 2011 (CEST)

Eine Alternative wegen des Zeitpunktes wäre vielleicht, die erste Bearbeitung nicht auszublenden, wie das ja bei zwei Bearbeitungen ohnehin schon ist, bei drei Bearbeitungen, wäre also nur die zweite Bearbeitung ausgeblendet. --Diwas 19:52, 7. Okt. 2011 (CEST)

Sorry, vielleicht bin ich zu müde, aber ich verstehe nicht was du mir sagen willst :) Im Moment ist es so, dass, sofern es zu einer Zusammenfassung kommt, nur die oberste ( = neueste) Änderung gezeigt wird, während der Rest des Stacks versteckt wird. --_{Nightfly85 | Disk} 23:58, 7. Okt. 2011 (CEST)

Lies es morgen nochmal;-) also ich weiß nicht, ob das jetzt so ist, aber ich meine gelesen zu haben, dass erst ab drei Bearbeitungen was ausgeblendet wird, also wird bei zwei Bearbeitungen, die erste und letzte angezeigt, was auch sonst;-) Wenn man das auch bei mehr als zwei Bearbeitungen, so machen würde, was natürlich die Funktion etwas abschwächt, dann würde immer die erste und letzte Bearbeitung eines fortlaufend bearbeitenden Benutzers abgezeigt, damit auch der erste (manchmal aussagekräftigste) Kommentar und der erste Bearbeitungszeitpunkt. Ob das aber sinnvoll ist und ob das überhaupt einfach zu programmieren ist, weiß ich nicht. --Diwas 00:14, 8. Okt. 2011 (CEST)

Ah, so ists verständlicher :) Vom programmiertechnischen Aufwand her wäre es machbar. Allerdings hätte man dann wieder eine Zeile mehr, die man ja eigentlich verhindern möchte. Nein, ich muss irgendwie an das Datum kommen, und sei es mit nem regulären Ausdruck. So ists am sinnvollsten. --_{Nightfly85 | Disk} 01:49, 8. Okt. 2011 (CEST)

Update Habe nun Links zum anzeigen/verstecken aller angefügt, die Animationsdauer verkürzt und die Texte der einzelnen Links angepasst (zeige/verstecke XXX Beiträge von XXX). Benutzer:Nightfly85/common.js Über weitere Kritik und vor allem Performanceberichte freue ich mich! --_{Nightfly85 | Disk} 01:49, 8. Okt. 2011 (CEST)

Irgendeine Chance, dass das "ofiziell" wird? Also für alle als autoamtisch aktives Feature? Finde das extrem nützlich. --Stefan 16:09, 7. Nov. 2011 (CET)

Könnte neben zeige 3 weitere Beiträge von Benutzername noch ein Link auf den Versionsvergleich, der die zusammenhängenden Bearbeitungen umfasst, eingebaut werden? --Diwas 15:35, 15:53, 8. Nov. 2011 (CET)

+1 --Stefan 15:40, 8. Nov. 2011 (CET)

Allerdings stelle ich gerade fest, dass das Drücken von Enter ausreicht, wenn man vorher die richtigen Radiobuttons angeklickt hat. War mir nicht (mehr?) bewusst. Hab entweder Popups verwendet für die einzelnen Diffs oder die Schaltfläche angeklickt. Zwei Klicks und einmal Enter ist zumutbar. Ein direkter Link wäre effizienter, aber nur wenn die Performance nicht zu sehr leidet. --Diwas 16:08, 8. Nov. 2011 (CET)

Ich verstehe den Vorschlag nicht recht. Meint ihr damit, dass per Klick alle Versionen mit der vorherigen (oder nachfolgenden) Bearbeitung eines *anderen* Benutzers verglichen werden kann? Wenn ja - der Radiobuttons der neuesten zusammenhängenden Eintrages wird doch trotzdem mit angezeigt. Oder stehe ich auf dem Schlauch? :) --_{Nightfly85 | Disk} 02:57, 14. Nov. 2011 (CET)

Achso! Ihr meint, dass es mit einem Klick möglich sein soll, die erste und die letzte Bearbeitung des zusammengefassten Beitrages zu vergleichen? --_{Nightfly85 | Disk} 03:01, 14. Nov. 2011 (CET)

Ja, ich denke du meinst jetzt das, was wir meinen, also den zusammengefassten Versionsvergleich der zusammengefassten Bearbeitungen. Vergleich der Version die der Bearbeiter vorgefunden hat zu Version die der Bearbeiter schlussendlich hinterlassen hat. Also das, was man jetzt erreicht mit: linker Radiobutton der Version, die unmittelbar unterhalb der Zusammenfassung steht, anklicken – rechter Radiobutton der Zusammenfassung anklicken – enter drücken. --Diwas 19:34, 19:41, 14. Nov. 2011 (CET)

Ich fände eine mit Obigem verwandte Funktionalität sehr nützlich: In der (einfachen) Beobachtungsliste die im ausgewählten Zeitraum mehrfach geänderten Seiten markieren. --Leyo 17:24, 22. Nov. 2011 (CET)

Also beispielsweise alle nicht mehr aktuellen Versionen in grau darstellen oder grau hinterlegen? --Diwas 21:04, 22. Nov. 2011 (CET)

Da ich in den Einstellungen die Option Erweiterte Beobachtungsliste zur Anzeige aller Änderungen nicht angehakt habe, werden in der Beobachtungsliste keine nicht-aktuellen Edits angezeigt. Daher wäre eine Möglichkeit um anzuzeigen, wo weitere kürzlich getätigte Edits versteckt sind, praktisch. Wie viele es sind (≥2) spielt keine Rolle. --Leyo 00:15, 23. Nov. 2011 (CET)

Ach sorum war das, da hab ich wohl was verwechselt oder einfach falsch in Erinnerung gehabt. --Diwas 02:46, 23. Nov. 2011 (CET)

Ist nun an dem Script noch ein besonderer Wunsch zu erfüllen (habe etwas den Überblick verloren, ehrlich gesagt)? Wie sieht es mit der Integration in die common.js aus? --Nightfly85 | _Disk 13:56, 15. Mai 2012 (CEST)

Hallo, Bergi hatte es ein gutes Stück weiter oben angedeutet. Ich fasse mal den absehbar erfolgreichen Ablauf zusammen:

1. Benutzer:Nightfly85/common.js
   • Ausgliedern als Benutzer:Nightfly85/historyCombine.js
2. Benutzer-Doku Benutzer:Nightfly85/historyCombine als Wikitext schreiben; Muster unter Benutzer:Schnark/js #Meine Skripte für jeweiliges Einzelskript, etwa Benutzer:Schnark/js/diff
3. Wikipedia:Technik/Skin/JS #Benutzerskript ./. Gadget lesen und checken.
4. Link auf Benutzer-Doku einfügen unter Wikipedia:Technik/Skin/Benutzerskripte #Versionsgeschichten und -unterschiede
5. Verbreitung abwarten; Reklame auf Benutzer:Nightfly85 machen
   • Resonanz?
   • Irgendwelche Bugs?
6. Nachdem von allerhand Benutzern eingebunden und erfolgreich:
   • Vorschlagen auf MediaWiki Diskussion:Gadgets-definition
7. In diese MediaWiki:Common.js selbst werden spezielle Werkzeuge nicht (mehr) eingebunden.

Zuvor:

• Füge mal ziemlich weit oben ein:

     /*jslint plusplus: true, sloppy: true, vars: true, white: true, maxerr: 50, indent: 4 */
     /*globals  mw: true, $: true, document: true */

• Zusätzlich Klammern { return; } bei if(mw.config.get('wgAction') ... { return; }
• Dann mal hier reinstopfen: http://jslint.com/ (Syntax-Analyse)
  • for(var i

Viel Erfolg! --PerfektesChaos 17:48, 15. Mai 2012 (CEST)

Viiiiieeeelen Dank! --Nightfly85 | _Disk 18:21, 15. Mai 2012 (CEST)

openStreetMapToggle()

Die Funktion openStreetMapToggle() befindet sich nicht in dem dafür vorgesehen Kontext mw.loader.using( 'mediawiki.util', function () { $( function () { … } ); } ); und ist somit als globale Funktion erreichbar. Wenn die Funktion dort nicht gebraucht wird, sollte sie in den Kontext verschoben werden. --Fomafix (Diskussion) 15:33, 24. Jun. 2012 (CEST)

Genau. Das meinte ich oben mit „anonymisiertem Toggelchen“. --PerfektesChaos 16:16, 24. Jun. 2012 (CEST)

Oh, stimmt. Das habe ich ganz übersehen. Mir ist gerade nur aufgefallen, dass hier eine Funktion aus mw.util außerhalb von mw.loader.using( 'mediawiki.util', … ) verwendet wird. --Fomafix (Diskussion) 17:09, 24. Jun. 2012 (CEST)

Nach dieser Diskussion nutzen zwei Benutzer die globale Funktion: Benutzer:PatDi/monobook.js, Benutzer:Sebastian Sooth (WMDE)/vector.js --Fomafix (Diskussion) 17:09, 24. Jun. 2012 (CEST)

Die dortige Argumentation ist einleuchtend.

Bei einer Funktion, die nicht nur einmalig während der Seiten-Initialisierung auszuführen ist, sondern bedarfsweise später ausgelöst werden soll, kommt die Anonymisierung nicht mehr in Frage.

Dementsprechend wäre ein Anwendungsobjekt mw.libs.openStreetMap zu bauen, das eine API-Funktion mw.libs.openStreetMap.fire() bereitstellt und in Abhängigkeit einer in der common.js definierten .live=false individuell erstmal nichts macht.

Mit einem Anwendungsobjekt wäre auch alles aus dem global scope verschwunden.

Etwas freischwebend ist es, dass wir hier munter an kolossos vorbei für die weltweite OSM programmieren; aber das können wir ja dann als global gadget bereitstellen.

Nebenbei wäre das unter RL2 auch ein opt-out-Gadget-Kandidat.

Liebe Grüße --PerfektesChaos 18:11, 24. Jun. 2012 (CEST)

Neija, der Benutzerwunsch ist, dass Karte beim Laden angezeigt ist. Die globale Funktion ist eine Möglichkeit das zu erreichen. Die meiner Meinung nach sinnvollere Möglichkeit ist, dass das Helferlein OpenStreetMap einen entsprechenden Benutzerparameter bekommt, mit dem eingestellt werden kann, ob die Funktion bereits beim Start ausgeführt werden soll, oder nicht. Oder gibt es andere Anwendungen eine globale Funktion openStreetMapToggle() benötigen? --Fomafix (Diskussion) 23:26, 24. Jun. 2012 (CEST)

Das wird schlicht und einfach zu fummlig.

Wir können nicht vorhersehen, wer rund um den Planeten später noch mit irgendwelchen Sonderwünschen und API kommt. So wie sich mir kolossos und sein OSM-Projekt darstellt, würden wir hier die Ablösung seines JS für RL2 zum weltweiten Einsatz schreiben. Dann lieber richtig.

Wer dann in welchem Moment irgendwas einschalten, ausschalten, beim Laden, hinterher nicht, oder doch ausblenden, wieder aktualisieren möchte, … kann uns dann egal sein. Wer einen Benutzerparameter in common.js haben möchte, auf den können wir auch noch Rücksicht nehmen. Wenn das aber weder seine common.js noch Skin-Standard-JS ist, dann ist .using("user") auch schon vorbei und wir kommen an anonyme Funktionen nicht mehr heran.

Also lieber eine API anbieten, und dann kann jeder glücklich werden; sofern kein benutzerdefinierter Inhibitor mit .using("user") bekannt gemacht wurde, wird beim Laden die AutoRun-Funktion ausgeführt. Danach sollen die ausblenden, toggeln, irgendwas aktualisieren oder sonstwas anstellen; das juckt dann nicht mehr. Wer weiß, was sich die Leutchen mit einer iframe noch alles einfallen lassen.

Einmal langt mir, dass dann doch noch jemand mit einem Zugriffswunsch um die Ecke kam.

Süße Träume --PerfektesChaos 00:31, 25. Jun. 2012 (CEST)

Ein Konfigurationsparameter hat von Vorteil, dass er in Zukunft vielleicht mal als Benutzereinstellung für das Gadget gesetzt und gespeichert werden kann. Ein Funktionsaufruf hingegen wird sicherlich nur über persönliche JavaScript-Programmierung möglich sein, was nicht jedermannssache ist. Die Funktion openStreetMapToggle() kann übrigens auch über $('#coordinates a:last').click() aufgerufen werden. Daher sehe ich keine Notwendigkeit für eine global erreichbare Funktion. --Fomafix (Diskussion) 08:18, 25. Jun. 2012 (CEST)

Das Problem an der globalen Funktion ist auch, das die in den beiden oben genannten Fällen eigentlich zu früh aufgerufen wird, weil das document noch nicht ready sein muss und mediawiki.util auch noch nicht geladen sein muss. Wenn man da eine globale Methode haben möchte, muss man das eigentlich sicher stellen. Der Klick von Formafix könnte auch zu früh kommen, weil man auf die ready-Queue keinen Einfluss hat. Keine Ahnung, wie man damit weiter verfährt. Der Umherirrende 17:47, 15. Nov. 2012 (CET)

Naja, das ganze veraltete Zeugs müsste man neu und zukunftssicher schreiben; auch für RL2 und künftige Benutzerwünsche weltweit. Lokales Gefrickel in dewiki mögen Behelfslösungen sein, aber etwas neu Geschriebenes sollte von kolossos dann auch für alle WMF übernommen werden können. Wikipedia:Technik/Skin/Werkstatt/Baustellen/OSM weltweit --PerfektesChaos 18:23, 15. Nov. 2012 (CET)

Vorschlag: ordinal unsortierbare Spalte in Tabellen

Hallo. Seit Jahren gibt es immer wieder Probleme damit, dass in Tabellen wie Liste der Großstädte in Deutschland die erste Spalte von 1 aufwärts sortiert bleiben soll, wenn der Rest mittels der tablesorter-Funktion von MediaWiki sortierbar sein soll. Da sich anscheinend niemand an den Code wagt und derzeit die ganzen Zeilen umsortiert werden, was die Änderungen wohl auch nicht ganz so trivial macht, schlage ich folgenden Workaround aus der polnischen Wikipedia vor:

$('table.sortable th.unsortable.ordinal').each(function(i, th) {
  var $th = $(th), $table = $th.closest('table');
  $table.on('sortEnd.tablesorter', function() {
    $table.find('tr td:nth-child('+ (th.column+1) +')').each(function(j, td) {
      $(td).text( (j+1) );
    });
  })
});

Nach der Sortierung wird eine Spalte, deren table header mit der Klasse "unsortable ordinal" bezeichnet ist, einfach von 1 aufsteigend mit Zahlen gefüllt. Das ist natürlich keine perfekte Lösung, aber für 99% der Fälle hier in der Wikipedia reicht das. Der dazugehörige Bug (in dem auch dieser Code auftaucht) ist bugzilla:40618. --APPER\^☺☹ 06:43, 2. Jan. 2013 (CET) Kleine Ergänzung: Live kann man sich das ganze beispielsweise unter pl:Miasta_w_Polsce_(statystyki) anschauen. --APPER\^☺☹ 06:57, 2. Jan. 2013 (CET)

Öhm, hallo. Liest hier keine mit? Ich hätte schon gern 'nen Kommentar bevor ich mutig bin ;) --APPER\^☺☹ 08:39, 11. Jan. 2013 (CET)

Meiner Ansicht nach sollte das entweder direkt in MediaWiki oder gar nicht gelöst werden. Die vorgeschlagene Lösung ist auch nicht weniger Hack als die gegenwärtige, mit dem Zusatznachteil, dass sie nicht direkt in anderen Wikis funktioniert. --Schnark 09:52, 11. Jan. 2013 (CET)

Anzahl der Beobachter anzeigen lassen

Das Bild zeigt mein Benutzerscript "viewerInfo.js" in Aktion.

Hiho, nachdem die API aktualisiert wurde, habe ich nun mein Script fertiggestellt. Es zeigt oben rechts die Anzahl der Beobachter an. Ist diese Information nicht generell für jeden interessant? Hier gehts zum Script: Benutzer:Nightfly85/viewerInfo.js/Doku --Nightfly | _Disk 13:26, 15. Mär. 2013 (CET)

Ach so: Derzeit nur für den Vector-Skin. --Nightfly | _Disk 13:26, 15. Mär. 2013 (CET)

Gerade geprüft: Es funktioniert auch bestens im Monobook-Skin. --Nightfly | _Disk 13:42, 15. Mär. 2013 (CET)

Ich glaube, wenn das für jeden Seitenbesuch eingebaut wird, werden wohl die Server schmelzen. Im Hintergrund wird ja nicht einfach ein Datenbankfeld abgefragt, sondern es muss erstmal ein Aggregat (COUNT) gebildet werden. Ich werde es nicht einbauen, will es aber auch nicht blockieren. Der Umherirrende 15:42, 15. Mär. 2013 (CET)

Ah, verstehe. Dachte, der Integer wird als festes Feld abgelegt und bei Bedarf aktualisiert. --Nightfly | _Disk 16:12, 15. Mär. 2013 (CET)

Nein, in diesem Fall nicht. Gegenbeispiel ist die Anzahl der Bearbeitungen in den Einstellungen, das ist ein Feld, und die Anzahl der Seiten/Dateien/Unterkategorien auf der Kategorieseiten werden als eigene Felder gehalten, die Statistikzähler wie NUMBEROFARTICLES, NUMBEROFEDITS auch. Wobei es dabei bei den Feldern auch immer wieder Probleme mit der Aktualisierung gibt, so dass diese Zähler zu hoch oder zu niedrig sind. Da es kein eigenes Feld für die Beobachtungsanzahl gibt, lassen sich auch nicht alle unbeobachten Seiten auf einen Schlag ermitteln bzw. die entsprechende Spezialseite ist als "expensive" nur gecached verfügbar. Hat alles Vor- und Nachteile. Der Umherirrende 16:31, 15. Mär. 2013 (CET)

Give search results even when page doesn't exist

Screenshot of the Earth test search, with this script adding links to Wikidata, Reasonator, Commons, and Wikipedia.

Hello, I propose to enable the tool created by Magnus Manske (creator of MediaWiki) to provide results from other languages and Commons (via Wikidata) when a page doesn't exist here: links are added to Special:Search and noarticletext. This helps to encourage translation and to make readers use your wiki more, because they can be sure to find something even if it's not local (rather than searching directly on the biggest wiki). The Italian and Polish Wikipedias, among others already enabled it by default.
Examples: [1] [2] [3]. More information: Magnus blog.
How to: just add the following line at the end of Common.js.

// Results from Wikidata
// [[File:Wdsearch_script_screenshot.png]]
if ( mw.config.get( 'wgCanonicalSpecialPageName' ) === 'Search' ||  ( mw.config.get( 'wgArticleId' ) === 0 && mw.config.get( 'wgCanonicalSpecialPageName' ) === false ) ) {
	importScriptURI("//en.wikipedia.org/w/index.php?title=MediaWiki:Wdsearch.js&action=raw&ctype=text/javascript");
}

--Nemo 10:02, 12. Dez. 2013 (CET) (comments, translations and last instructions)

ProjektLinks

Ich habe hier für den Abschnitt ProjektLinks eine neue Implementierung, die auch Live preview unterstützt. --Fomafix (Diskussion) 09:02, 2. Apr. 2014 (CEST)

/*
## ProjektLinks ##
by Skript von [[user:Merlissimo]] (Idee basierend auf http://de.wiktionary.org/wiki/MediaWiki:Common.js von [[User:Pathoschild]] und [[wikt:de:User:Melancholie]])
erzeugt Sitebar-Interwiki zu Schwesterprojekten aufgrund von Vorlage [[Vorlage:InterProjekt]]
siehe auch Feature-Request [[bugzilla:708]]
*/
mw.loader.using( [ 'mediawiki.util' ], function () {
	if ( mw.config.get( 'wgNamespaceNumber' ) <= 0 ) {
		return;
	}

	mw.hook( 'wikipage.content' ).add( function ( $content ) {
		// Entferne Sisterlinks von vorherigem Aufruf
		$( '#p-sisterprojects' ).remove();

		var iProject = $content.find( '#interProject' );
		if ( !iProject.length ) {
			return;
		}
		var sistersibling = $( '#p-lang' );
		if ( !sistersibling.length ) {
			sistersibling = $( '#p-tb' );
		}
		if ( !sistersibling.length ) {
			return;
		}
		// Link auf Parennode des Portletmenues
		var sisterparent = sistersibling.parent();

		// Erzeuge neues Portletmenue
		var sistersiblingsub = sistersibling.find( 'div:first' );
		var sisterprojectnav = $( document.createElement( 'div' ) )
		.attr( 'id', 'p-sisterprojects' )
		.attr( 'class', sistersibling.attr( 'class' ) )
		.append(
			$( document.createElement( 'h3' ) )
			.text( $content.find( '#sisterProjects:first' ).text() )
		)
		.append(
			$( document.createElement( 'div' ) )
			.attr( 'class', sistersiblingsub.length ?
				sistersiblingsub.attr( 'class' ) :
				'pBody'
			)
		);
		
		// Wenn möglich vor den Interwikis einfügen
		if ( sisterparent.has( '#p-lang' ).length ) {
			sisterprojectnav.insertBefore( '#p-lang' );
		} else {
			sisterparent.append( sisterprojectnav );
		}
		
		// Schwesterlinks ermitteln und einfügen
		iProject.find( 'a' ).each( function () {
			var $this = $( this );
			var sistername = $this.text();
			mw.util.addPortletLink(
				'p-sisterprojects',
				$this.attr( 'href' ) + '?uselang=' + mw.util.rawurlencode( mw.config.get( 'wgUserLanguage' ) ),
				sistername,
				'sister-' + sistername.replace( /[ _\-]+/g, '-' ).replace( /[^\-a-z0-9]+/ig, '' ),
				sistername
			);
		} );
	} );
} );

Tuning und Struktur

Weil ich grad über die letzte Änderung mit Link_FA / Link_GA guckte:

• Warum wird die ganze Geschichte nicht auf den ANR beschränkt?
• Oder gibt es außerhalb des ANR noch FA, von denen ich nichts weiß?
• Kann gleich mit dem nächsten Block zu einem beschleunigten switsch zusammengefasst werden:

switch ( mw.config.get( 'wgNamespaceNumber' ) ) {
   case -1:
      break;
   case 0:
      //   Link_FA / Link_GA
      break;
   default:
     // "Sitebar-Interwiki", aber bitte mit 'd'
     // ...
     // Link "Alle Sprachen" auf der Hauptseite?
     if( mw.config.get( 'wgIsMainPage' ) ) {
}   //   switch wgNamespaceNumber

• Weiter hinten gibt es übrigens zwei Blöcke mit der gleichen Abfrage ( 'wgNamespaceNumber' ) === 6 – das kann innerhalb einer Abfrage gebündelt werden, oder auch gleich in den vorstehenden switch mit rein als fall-through.

Und damit der erste Fall (Spezialseite) nicht so leer ist, kann dort die importScript("MediaWiki:Common.js/watchlist.js"); in Betracht gezogen werden.

Im Übrigen bin ich schon seit Jahren dafür, ein Anwendungsobjekt für Projektangelegenheiten aufzumachen:

if ( typeof mw.libs.dewiki  !==  "object" ) {
   mw.libs.dewiki = { };
}

• Innerhalb des mw.libs.dewiki können dann die ganzen größeren Einzelfunktionen benannt vereinbart werden; das verunstaltet nicht den globalen Namensraum; und der Quellcode muss sowieso geparsed werden, das lässt sich ohnehin nicht einsparen.
• Hier schlau benannte Einzelfunktionen vorab definiert, und dann im switch nach Namensraum nur noch die Funktionen ausführen, die in diesem Namensraum auch sinnvoll sind. Damit wird der switch aber übersichtlicher und das ganze Zeug schneller.
• Beispiel für gleich zwei solcher switche: Benutzer:Flominator/common.js

Der jüngste Beitrag von Fomafix kann dann auch gleich als mw.libs.dewiki.projectLinks vorab deklariert werden und wird nur im entsprechenden NR ausgeführt.

Liebe Grüße --PerfektesChaos 09:52, 2. Apr. 2014 (CEST)

projectLinks benötigt keine globalen Variablen. Ein Anlegen von mw.libs.dewiki.projectLinks ist daher nicht notwendig. --Fomafix (Diskussion) 10:12, 2. Apr. 2014 (CEST)

Die Komponente mw.libs.dewiki.projectLinks würde nur der Reinhaltung des globalen Namensraums dienen.

Noch lieber wäre mir eine Kapselung, nach der ich seit langer Zeit giere, und die eine nachvollziehbare Benennung von Funktionsblöcken erlaubt, ohne als globale Variablen aufzutauchen:

/* jshint curly:true, latedef:true, laxbreak:true,
          trailing:true, undef:true, white:false                       */
/* global window:false                                                 */
( function ( mw, $ ) {
   "use strict";
   var NSN  =  mw.config.get( 'wgNamespaceNumber' );
   function link_FA_GA () {
      // ...
   }
   function projectLinks () {
      // ...
   }
   function projectLinks_onChangedContent ( $content ) {
      // ...
   }
   switch ( NSN ) {
      case -1:
         switch ( mw.config.get( 'wgCanonicalSpecialPageName' ) ) {
            case 'Upload':
               importScript("MediaWiki:Onlyifuploading.js");
               importScript("MediaWiki:Onlyifediting.js");
               break;
            case 'Watchlist':
               importScript("MediaWiki:Common.js/watchlist.js");
               break;
         }   //   switch wgCanonicalSpecialPageName
         break;
      case 0:
         link_FA_GA();
         break;
      default:
        // "Sitebar-Interwiki", aber bitte mit 'd'
        // ...
        // Link "Alle Sprachen" auf der Hauptseite?
        if( mw.config.get( 'wgIsMainPage' ) ) {
   }   //   switch wgNamespaceNumber
}( window.mediaWiki, window.jQuery ) );

Heißt:

• Am Anfang der Kapsel nur Deklarationen.
• Um die kommt man ohnehin nicht herum; nur in den Standard-Ressourcen hat man eine Aktualität von 10 Sekunden, sonst einen Monat. Importe lohnen sich nicht für Brösel.
• Daran anschließend eine reine Ausführung unter situationsabhängigen Bedingungen: Art der Seite, Modus, document.ready und sonstwas.
• Im Ausführungsteil stehen nur noch kurze, knappe, namentlich verständliche Aufrufe; auf Effizienz optimiert.
• Damit wird innerhalb eines kurzen Bereichs deutlich, was unter welchen Bedingungen auf welchen Seiten immer oder manchmal passiert.
• Weil die Namen innerhalb der Kapsel lokal sind, kann man verständliche Bezeichner für alles verwenden und muss keine unübersichtlichen Verschachtelungen anonymer Konstrukte verwenden.
• Übrigens brauchst du using( [ 'mediawiki.util' ] nicht gesondert abzufangen; ist im mw.hook()bereits mit gesichert.

Liebe Grüße --PerfektesChaos 11:05, 2. Apr. 2014 (CEST)

ProjectLinks erzeugt keine globale Variablen! Alles ist in Funktionen gekapselt. Das vergessene var habe ich korrigiert. Ein mw.libs.dewiki.projectLinks ist nicht notwendig.

Das implizite Laden von mediawiki.util ist vor mw.hook( 'wikipage.content' ).fire() kann sich mal ändern. Es ist daher sinnvoll mediawiki.util explizit anzugeben.

Meiner Meinung nach sollten die sauber gekapselten Module in separate Gadgets ausgelagert werden. --Fomafix (Diskussion) 13:23, 2. Apr. 2014 (CEST)

1. Im gekapselten Teil steht überhaupt nichts mehr von mw.libs.dewiki – das wäre nur der andere Ansatz gewesen.
2. mediawiki.util wird nicht mal so eben wieder herausgenommen werden, da auch MW selbst sich darauf verlässt, und mw.hook sich auf das statische mw.util.$content beruft: resources/mediawiki.page/mediawiki.page.startup.js
   • Sollte das wider Erwarten trotzdem geschehen, werden wir das schon rechtzeitg erfahren. Dann ließen sich mit Leichtigkeit die paar mw.hook finden und nachrüsten.
   • Im Moment ist es nur Ressourcenvergeudung bei allen Lesern.
   • Warum wird eigentlich auf sämtlichen Diskussionsseiten nach projectLinks gesucht? Die kann es eigentlich nur auf SUBJECTPAGE geben; wir schreiben ja auch keine Interlanguage auf die Diskussionsseite. Hingegen könnte es außerhalb des WPNR schon mal die Vorlage:Information sein, oder ein Benutzer findet das schau.
3. Gadgets würden immer geladen werden; unabhängig vom Namensraum, und müssten eigenständig untersuchen, ob sie auf dieser Art von Seite in der momentanen Situation überhaupt sinnvoll sind. Das frisst auch wieder nur Ressourcen; und sie werden in den Zusammenstellungen für alle Benutzer sichtbar und machen diese unübersichtlich (mw:Extension:Gadgets kennt kein „Unsichtbar“, und standardmäßig aktiviertes Konfigurationszeugs, das Benutzer nicht verstehen und auch nicht wissen, ob sie es abwählen sollen oder nicht, ist auch keine Lösung); jeder Eintrag in der Benutzerkonfiguration verlängert die bei jedem einzelnen Seitenabruf übermittelte individuelle Einstellungsliste. Unterseiten werden hingegen nur einmal pro Monat aktualisiert, wenn man kein maxage dranschreibt. Es gibt keine wirklich hübsche Lösung.
   • Für link_FA/GA mag Opt-out eine für viele Benutzer nachvollziehbare Option sein; für die URL-Anpassung ist das eher nix.
   • Für kleine Schnipsel ohne Konfigurationsbedarf der Benutzer sind die Funktionsdefinitionen hier schon der übersichtlichste und schnellste Weg.

mw.util.$content ist meiner Meinung nach veraltet und sollte durch mw.hook( 'wikipage.content' ).add( function ( $content ) { … } ersetzt werden. Der Aufruf von mw.util.init() in mediawiki.page.startup.js und damit die Abhängigkeit zu mediawiki.util kann damit entfallen.

Gadgets müssen nicht immer geladen werden. Sie können per mw.loader.load( 'ext.gadget.…' ) nachgeladen werden. Das hat gegenüber importScript( … ) die Vorteile, dass der Code minimiert geladen wird und dass mehrere Anfragen zusammengefasst werden können. Außerdem werden notwendige Module automatisch mitgeladen und das Caching-Problem wird auch gelöst. Ausblenden von Gadgets steht auf der Roadmap. Gadgets werden bereits jetzt ausgeblendet, wenn Recht oder Skin nicht zutreffen. Mit CSS-Tricks kann ebenfalls ausgeblendet werden. --Fomafix (Diskussion) 09:40, 3. Apr. 2014 (CEST)

Zu mw.util.$content habe ich Bug 63466 aufgemacht. --Fomafix (Diskussion) 11:53, 3. Apr. 2014 (CEST)

Ich persönlich halte nichts von der Idee, alles in einem switch abzuhandeln. Aus meiner Sicht sollten die einzelnen Funktionen weiterhin eigenständig auf der Seite stehen. Dazu gehört dann auch das erneute Abfragen von Namensraum oder ähnliches, hat aber den Vorteil das man diese Sachen ändern kann, ohne die gesamte Seite kennen zu müssen, weil alles eigenständig ist. Außerdem lassen sich Funktionen einfacher in anderen Wikis wiederverwenden, weil man direkt sieht, was man braucht und keinerlei Bedingungen vergessen kann.

Zusätzlich ist anzumerken, das man sich normalerweise erst über Tuning Gedanken macht, wenn es notwendig ist. Generell bekannte oder potenzielle Bottlenecks kann man gerne vorher schon beseitigen, aber das generelle in Frage zu stellen, wenn es nicht umbedingt notwendig erscheint, halte ich für übertrieben. Aber das nur am Rande. Der Umherirrende 20:56, 3. Apr. 2014 (CEST)

Möglichst nicht zu viele Baustellen schaffen.

• Dass das dynamische function($content) dem statischen mw.util.$content für editierbare Seiten überlegen ist, steht außer Frage.
  • Ob und wann mw.util.$content dann gemäß gerrit:123559 deprecated und abgeschafft werden würde, liegt nicht in unserer Hand.
  • Wenn das so umgestellt wird und die Abhängigkeit von mw.util ebenfalls abgeschafft wird (was man auch bei Abschaffung von mw.util.$content nicht zwangsläufig tun muss), bekämen wir das Wochen vorher mit.
  • Das MW-eigene JS verlässt sich ebenfalls darauf, dass mediawiki.util geladen ist.
  • Wenn wir uns an eine Restrukturierung unserer common.js machen, dann sollte die Ausführungsfunktion per using davon abhängig gemacht werden, dass zumindest [ "mediawiki.user", "mediawiki.util", "user" ] und vielleicht noch user.options geladen sind. Dann muss nicht mehr jede Einzelfunktion sich selbst quellzeilen- und zeitaufwändig selbst darum kümmern, und alle können etwa auf Benutzereinstellungen eingehen.
• Zurück zu der Geschichte mit Gadgets. Das klingt durchaus spannend, und wenn das ohne Nachteile umsetzbar wäre, dann sehr gern.
  • Du schlägst also eine Pseudo-Skin vor; etwa dewiki oder common oder intern oder hidden.
  • Hier würden alle JS-Sequenzen geparkt, die man modularisiert auslagern möchte.
  • Weil niemand eine Skin namens common eingestellt haben kann, würde keine davon automatisch geladen.
  • Sie sollen durch geeignete CSS-Maßnahmen auf Spezial:Einstellungen#mw-prefsection-gadgets unsichtbar gemacht werden, um die Benutzer nicht zu verwirren.
    • Welches CSS übrigens? Per CSS3-Namensschema mw-input-wpgadgets-Common- für id= und for= – und die Überschrift? JS geht nicht; CSS aber vermutlich.
  • Als registierte Gadgets bekämen sie vom System eine ID und eine Zuordnung von Code zu dieser ID; und sie würden in der aktuellsten Form über //bits abgerufen und eingebunden.
  • Sie sollen dann per mw.loader.load(ID) in den Situationen dynamisch geladen werden, in denen sie sinnvoll sind.
  • Angedacht ist seit Mitte 2012 in mw:Gadgets ja vieles, aber ich sehe seit fast zwei Jahren keinerlei Bewegung mehr; weder Gadgets 2.0 noch Gadgets 3.0 noch sonstwas. Was da also irgendwo vorgeschlagen steht, interessiert mich wenig; nur was bereits als commit zum approve ansteht, akzeptiere ich als konkret absehbar. Ob eine Verstecken-Option behauptet wird oder nicht, ist für uns gegenstandslos.
  • Bau doch auf WP:BETA eine Demo auf.
  • Unabhängig davon lässt sich bereits heute überlegen, welche momentan zwangsläufigen Sequenzen man Benutzern zum Opt-Out anbieten möchte. Diese wären dann ohnehin in sich gekapselt und müssten für sich selbst sorgen. Das lohnt sich aber nur für wenige, und es muss ein konkretes Interesse von Normalbenutzern plausibel sein, eine Funktionalität nicht zu wünschen.

LG --PerfektesChaos 20:22, 3. Apr. 2014 (CEST)

en:MediaWiki:Gadgets-definition, commons:MediaWiki:Gadgets-definition und mw:MediaWiki:Gadgets-definition verwenden rights=hidden|hidden zum verstecken. --Fomafix (Diskussion) 20:40, 3. Apr. 2014 (CEST)

Die Spezialseite ist schöner zu lesen: commons:Special:Gadgets. Aber es ist richtig, das man mit einer Benutzerrecht, welches keiner haben kann, die Eintrage auf der Einstellungsseite unsichtbar machen kann. mw.loader.using wird mit gerrit:75511/1.23wmf21 auch promise unterstützen, so dass mw.loader.using( 'foo' ).done( callback ); möglich ist. Keine Ahnung, ob das irgendwo bei hilft, aber es ist möglich. Der Umherirrende 20:56, 3. Apr. 2014 (CEST)

Abschalten MV

@DaB.: Dein generelles Abschalten des MV entspricht nicht dem MB. Das Opt-In ist damit nicht mehr wirksam. Zwar noch in den Einstellungen vorhanden, aber nicht mehr wirksam. Wenn du also unbedingt etwas basteln möchtest (ich befürworte das ausdrücklich nicht), halte dich bitte an den Text des MBs. Ich persönlich möchte den MV weiterhin nutzen. — Raymond ^Disk. 00:17, 10. Aug. 2014 (CEST)

Das generelle Abschalten kommt dem MB-Ergebnis näher als ihn komplett anzulassen. AFAIK kann auch jeder angemeldete Benutzer den MV wieder anschalten, indem er in seinem js die Variable wieder aktiviert. --DaB. (Diskussion) 00:23, 10. Aug. 2014 (CEST)

Naja, ich würde sagen das hätte man erstmal besser vorbereiten sollen, z.B. mit einer Option in den Einstellungen als Helferlein. Man könnte IP's auch erstmal(?) von der völligen Abschaltung ausschließen? Z.B. mit if (mw.config.get( 'wgUserName' )) davor. JS-Seiten benutzen doch wirklich die Allerwenigsten! (PS: Falls dieser Hack Bestand haben sollte – woran ich auch nicht glaube – müsste dann auch die entsprechende Option geändert werden. Nicht nur techn. sitzt ja die WMF am längeren Hebel...) → User: Perhelion 01:12, 10. Aug. 2014 (CEST)

Da die Lizenz-Schwierigkeiten auch (und gerade) bei IPs auftreten, dürfen genau diese den MediaViewer in der aktuellen Form nicht sehen. Eine Möglichkeit den Viewer in den Einstellungen wieder anzuschalten wäre natürlich genial; wenn du da Code liefern kannst übernehme ich ihn gerne. Gut Nacht :-). --DaB. (Diskussion) 02:43, 10. Aug. 2014 (CEST)

Die Lizenzschwierigkeiten sind meiner Erfahrung nach schon länger ausgeräumt. — Raymond ^Disk. 08:26, 10. Aug. 2014 (CEST)

Hallo @DaB.:, wir haben diese Änderung zurückgesetzt, weil sie einen nachteiligen Eingriff in die Funktionsweise des Projekts für zahlreiche Benutzer darstellt. Bitte stelle die Änderung nicht wieder her. Sonst könnten wir uns gezwungen sehen die Bearbeitbarkeit dieser MediaWiki-Seite zurückzunehmen um die volle Funktionsfähigkeit des Projekts für alle Benutzer zu erhalten. Vielen Dank und Grüße, --Jan (WMF) 11:17, 10. Aug. 2014 (CEST)