MediaWiki Diskussion:Common.js/Archiv

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:Common.js/Archiv#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/MediaWiki_Diskussion:Common.js/Archiv#Thema_1

Link "Alle Sprachen" auf der Hauptseite

Wegen der Verschiebung der Hauptseite, wird dieser Link nicht mehr angezeigt. Bitte korrigieren -- Wickie37 15:26, 3. Jul. 2008 (CEST)

Oder entfernen... --Revolus Echo der Stille 18:03, 3. Jul. 2008 (CEST)

Wenn's denn doch geändert werden sollte, dann so…

	addOnloadHook(function() {
	   // only on the main page
-	   if ( wgTitle != 'Hauptseite' || wgNamespaceNumber != 0 )    return;
+	   if ( wgTitle != 'Wikipedia:Hauptseite' || wgNamespaceNumber != 4 )    return;

Gruß --W_I^KImaniac 14:49, 5. Jul. 2008 (CEST)

Erledigt (es wollte aber wgTitle != Hauptseite im if). --Complex 16:47, 7. Jul. 2008 (CEST)

Danke! Gruß --W_I^KImaniac 21:23, 8. Jul. 2008 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 19:59, 15. Feb. 2009 (CET)

if (wgAction === "delete") {

was hat der abschnitt unten in der Common.js zu suchen? ohne ein entsprechendes skript ist das anscheinend zu nichts gut. also könnte man's auch dort integrieren oder? -- ∂ 17:46, 1. Dez. 2008 (CET)

Das stammt noch aus der Zeit, als der Artikeltext noch in die Löschbegründung kopiert wurde, siehe diesen Thread im Archiv von WP:AN. Der Abschnitt ist jetzt überflüssig und könnte gelöscht werden. --P.Copp 17:50, 1. Dez. 2008 (CET)

sehr schön. dann nehm ich den mal raus. -- ∂ 17:52, 1. Dez. 2008 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 19:59, 15. Feb. 2009 (CET)

CharInsert beim Hochladen

Schlage vor im "Onlyifuploading"-Block zusätzlich auch MediaWiki:Onlyifediting.js einzubinden. Dann würde die CharInsert-Box praktischerweise auch im Hochladeformular korrekt (sprich als Dropdown) angezeigt werden:

	if (wgCanonicalSpecialPageName == "Upload") {
	   includePage("MediaWiki:Onlyifuploading.js");
+	   includePage("MediaWiki:Onlyifediting.js");
	}

--PasO 02:47, 8. Jan. 2009 (CET)

Dadurch bedingt, das die MediaWiki:Edittools jetzt komplett in MediaWiki:Onlyifediting.js integriert wurden, werden keine Sonderzeichen mehr beim Hochladen angezeigt. Die vorgeschlagende Ändeurng sollte durchgeführt werden. Der Umherirrende 19:43, 8. Mär. 2009 (CET)

Erl. — Raymond ^{Disk. Bew.} 19:52, 8. Mär. 2009 (CET)

Funktioniert leider nicht, da auf Spezial:Hochladen kein

<div class="mw-editTools"></div>

im HTML-Quelltext enthalten ist, wie beim Bearbeiten und somit das Skript nicht seinen Platz findet, wo es etwas einfügen soll. ich weiß nicht, wie es dort vorher aussah, ob das div vorhanden war oder nicht. Andernfalls könnte man in MediaWiki:Edittools ein div einbauen, und die Klasse wird dann verwendet. Ich denke, das div ist von MediaWiki generiert (zumindestens nach dem Namen zu urteilen), daher wundert es mich, das es einmal vorhanden ist und einmal nicht … Der Umherirrende 20:01, 8. Mär. 2009 (CET)

Ach, wenn MediaWiki:Edittools <div id="mw-editTools"></div> enthalten würde, würde das auch das Auffinden in MediaWiki:Onlyifediting.js erleichern:

  box = document.getElementById('mw-editTools');
  if(!box) { return; }

also sollte man das in jedem Fall einfügen. --Revolus Echo der Stille 21:37, 8. Mär. 2009 (CET)

Ein Schritt ist schon getan. Ich habe trotzdem Bug 18116 eröffnet. Für den zweiten Schritt muss, meiner Meinung nach, noch folgendes auf MediaWiki:Onlyifediting.js ausgetauscht werden:

  //get div.mw-editTools
  box = document.getElementById('wpTextbox1');
  while(box && (box.className !== 'mw-editTools')) {
    box = box.nextSibling;
  }
  if(!box) { return; }

mit

  //get div#mw-editTools
  box = document.getElementById('mw-editTools');
  if(!box) { return; }

Danke. Der Umherirrende 19:59, 23. Mär. 2009 (CET)

Der Bug ist gefixed, mal schauen wann die nächste Softwaresynchronisation ansteht bzw. wer schneller ist … Der Umherirrende 20:37, 23. Mär. 2009 (CET)

Ist behoben --Der Umherirrende 20:27, 25. Mär. 2009 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 20:27, 25. Mär. 2009 (CET)

aufgeräumt

wenn das ärger macht [1] bitte bescheid geben. -- ∂ 00:13, 27. Jun. 2008 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Leyo 10:02, 17. Jun. 2009 (CEST)

SVG-Grafiken: Links zu PNGs verschiedener Breiten

Es gab ja in der Vergangenheit immer wieder Diskussionen darüber, dass SVG-Grafiken schlechter weiterzunutzen wären als beispielsweise PNGs. Die auf Bildbeschreibungsseiten angezeigten Grafiken sind zwar im PNG-Format, aber häufig zu klein. Für neue Benutzer ist es nicht trivial, an (automatisch generierte) PNGs in höherer Auflösung zu kommen. Ich habe daher in der Redaktion Bilder Lösungsideen dargelegt. Die IMHO beste Variante ist diese, die auch mit von Commons eingebundenen SVG-Grafiken funktioniert und die ich hiermit zur Ergänzung der Common.js vorschlage. --Leyo 01:30, 25. Mai 2009 (CEST) PS. Mein Dank für die technische Umsetzung geht an Slomox.

Erstmal vielen Dank dafür. Ich bin nicht grade Frischling hier, mir war es aber immer ein Graus, SVG zu nutzen, habe das immer per Screenshot gemacht. Auf Commons funktioniert es noch nicht, da kann man sich aber die URI hierher kopieren. Warum gibts die 2048px-Grenze? Bei solchen Karten ist das doch etwas wenig. Aber unterm Strich ist das eine sehr wertvolle Neuerung, die ich uneingeschränkt unterstütze. --Marcela 13:37, 4. Jun. 2009 (CEST)

Das mit Commons verstehe ich nicht. Weshalb diese Grenze besteht, weiss ich nicht. Wohl aus Performancegründen und weil Grafiken in der WP wohl kaum noch grösser verwendet werden. --Leyo 16:38, 4. Jun. 2009 (CEST)

Wenn ich direkt auf Commons bin, habe ich die Links nicht. Aber klar, da wirkt ja die .js aus der Wikipedia nicht. Hätt ich auch selbst drauf kommen können. Was kommt nun? Wird es für alle installiert? --Marcela 16:54, 4. Jun. 2009 (CEST)

Da sich bisher niemand dagegen ausgesprochen hat, werde ich dies bald umsetzen. --Leyo 17:02, 4. Jun. 2009 (CEST)

Sehr gut! Eine wirklich sinnvolle Ergänzung. --Marcela 17:04, 4. Jun. 2009 (CEST)

Hab’s nun ergänzt. Ändern oder entfernen kann man es ja immer noch, wenn doch noch Einwände kommen sollten.

In deinem eigenen Monobook muss du’s nun wieder entfernen, da es sonst doppelt gemoppelt ist. --Leyo 17:14, 4. Jun. 2009 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Leyo 10:01, 17. Jun. 2009 (CEST)

addOnloadFunct

hallo, das addOnloadFunct ist jetzt in der wikibits.js (sorry for my bad deutsch). 77.216.96.39 17:57, 16. Dez. 2007 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Leyo 09:37, 30. Jun. 2009 (CEST)

Ergänzung für den Abschnitt "Skrypt für Vorlage:Galerie"

Durch eine Idee zu den Positionskarte bin ich auf eine Ergänzung für den untersten Abschnitt der Common.js kommen:

Es sollte möglich sein, eigene Überschiften statt des automatischen (1/3) anzugeben. Dafür wären nur ein paar geänderte Zeilen nötig. Ich habe sie auf Benutzer:Revolus/Gal geschrieben (Diff [nebst einiger Kleinigkeiten]). Mit Setzen eines title-Attributes könnte man dann die automatische Überschrift überschreiben. --RevoLus Echo der Stille 03:20, 8. Sep. 2008 (CEST)

gefällt mir. hab's mal eingebaut. -- ∂ 00:31, 9. Sep. 2008 (CEST)

Danke. --RevoLus Echo der Stille 00:37, 9. Sep. 2008 (CEST)

Interessante Sache :-). Allerdings fehlt eine Zeile:

	if (j != units.length - 1) {
+	  rightlink.href = "#";
	rightlink.onclick = toggleImageFunction(i, j, j+1);
	rightlink.appendChild(document.createTextNode("▶"));
	}

Liebe Grüße --Finn-Pauls ._. 13:20, 29. Sep. 2008 (CEST)

Die Zeile fehlt noch immer, so sie denn wirklich fehlt… --Leyo 19:18, 21. Jun. 2009 (CEST)

Ja, die sollte noch rein. --Revolus Echo der Stille 20:18, 21. Jun. 2009 (CEST)

OK, habe die Zeile ergänzt. --Leyo 11:07, 22. Jun. 2009 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Leyo 09:36, 30. Jun. 2009 (CEST)

Wikiminiatlas

Bevor es anlässlich meines Reverts heißt, ich habe zu wenig kommuniziert: Wikipedia:Tellerrand#WikiMiniAtlas_standardmäßig_aktivieren?. Arnomane 02:29, 22. Dez. 2007 (CET)

Hast du. Es gibt offenkundige Probleme, du ignorierst sie. Es gibt Stimmen, die sich fragen, ob sowas nicht individuell aktiviert werden sollte, du ignorierst sie. Bevor man zehntausende Seiten ändert, sollte man dem ganzen mehr als 24 h Zeit geben. --Polarlys 02:38, 22. Dez. 2007 (CET)

So weit ich das beobachten konnte, wird die standardmäßige Aktivierung des Mini-Atlas von der Gemeinschaft keineswegs einhellig begrüßt. Zuerst einmal gibt es eine große Gruppe, der das egal ist, weil sie zum größten Teil wohl gar nicht bemerkt hat, dass man die lustigen blauen Kleckse anklicken kann. Dann gibt es einige (mich eingeschlossen), die stört, dass plötzlich überall in den Infoboxen blaue Weltkugeln auftauchen. Oben rechts wäre das akzeptabel, aber warum unten im Text? Die eigentliche Funktion des Atlas scheint mir ebenfalls sehr umstritten zu sein, da er nur sehr wenige, scheinbar völlig zufällig ausgewählte Punkte einblendet und deshalb kaum als Navigationswerkzeug zu gebrauchen ist. Er entspricht momentan eher der Funktion „zufälliger Artikel“. Lange Rede, kurzer Sinn: Können wir den Atlas bitte als Gadget einbetten, so dass ihn jeder für sich selbst ein- und ausschalten kann? --TM 20:53, 5. Jan. 2008 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Guandalug 12:20, 1. Jul. 2009 (CEST)

returnObjById()

Function returnObjById() looks pretty much useless: look at runOnloadHook() inside wikibits.js: first it checks for document.getElementById support, which means in very old browsers any function scheduled with addOnloadHook is not executed anyway. -- Alex Smotrov 19:05, 26. Jun. 2008 (CEST)

right. i replaced it with a direct call to document.getElementById -- ∂ 20:54, 26. Jun. 2008 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Guandalug 12:20, 1. Jul. 2009 (CEST)

frühjahrsputz

es wird mal wieder zeit für eine entschlackungskur, finde ich. wir haben zu viel code, der zur funktion der wikipedia überhaupt nicht notwendig ist, aber denoch von jedem nutzer geladen werden muß.

• Vorlage:Korrekter Titel ist schon ewig veraltet. den JS-code dazu hab ich daher rausgeworfen.
• der MiniAtlas ist wirklich niedlich und genau das richtige für ein gadget. den code habe ich daher auch rausgeworfen.
• der PngFix ist ziemlich länglich und ich sehe dieses alte IE-problem nicht unbedingt als das unsere. jemand was dagegen, wenn der auch rausfliegt?

so. nochjemand eine idee, was man rauswerfen könnte? -- ∂ 22:35, 5. Jan. 2008 (CET)

Hm, also ganz rausschmeißen muss man den PngFix ja nicht, schließlich gibt es immer noch ein paar IE-Benutzer. Allerdings müsste es doch möglich sein, das PngFix-Skript in eine eigene JS auszulagern und nur dann (per JS) in die Seite einzubinden, wenn es tatsächlich gebraucht wird. D. h., in die allerletzte if-Abfrage, die ggf. die beim Laden auszuführenden Aktionen die PngFix hinzufügt, käme ein zum Beispiel document.write() oder ähnliches. Grüße, --CyRoXX ^(? ±) 23:48, 5. Jan. 2008 (CET)

Bitte werft den „PngFix“ wieder raus oder repariert ihn zumindest. Wie weiter oben schon angemerkt verursacht dieser Hack Darstellungsfehler in diversen Vorlagen, vor allem wenn es um pixelgenaue Positionierungen geht. In der Vorlage:Lageplan konnte ich das Problem beheben, aber ich gehe davon aus, dass das noch mehr Vorlagen betrifft. --TM 15:29, 13. Jan. 2008 (CET)

Ist entfernt.--Τιλλα 2501 ^± 15:34, 13. Jan. 2008 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Guandalug 08:42, 9. Jul. 2009 (CEST)

Bereiche in Vorlagen, die nur Admins angezeigt werden

Ich schlage vor, Common.js zu ergänzen, damit Bereiche in Vorlagen festgelegt werden können, die nur Admins angezeigt werden. Siehe dazu diesen Thread. --Leyo 09:08, 15. Mai 2009 (CEST)

Die Umsetzung kann auf zwei Arten erfolgen:

1. So wie auf Commons, wo in Abhängigkeit der Benutzergruppe eine weitere CSS-Seite geladen wird. Vorteil: Änderungen die nur die Sache betreffen lassen sich nachvollziehen. Es muss nur diese Seite neugeladen werden, wenn sich etwas ändert. Nicht-Administratoren können die Seite über ihre eigene Skin.js auch laden.
2. in Abhängigkeit der Benutzergruppe die Methode appendCSS(text) aus wikibits.js bemühen. Vorteil: Es gibt keine weitere Seite und es ist alles sofort ersichtlich. Aber bei einer Änderung wird für jeden Benutzer die Seite neugeladen.

Der Umherirrende 22:21, 16. Mai 2009 (CEST)

Und welche der beiden bevorzugst du? Gibt es weitere Meinungen? --Leyo 12:42, 17. Mai 2009 (CEST)

Ich glaube, das können besser die JavaScript-Profis sagen, die können die Vor- und Nachteile besser abschätzen. Also: Meinungen willkommen. Der Umherirrende 20:30, 18. Mai 2009 (CEST)

Ich würde sagen, man sollte gleich ein Javascript und ein CSS-Skript nachladen. Auch wenn das unmittelbar etwas übertrieben scheinen mag, was man hat, hat man. "Experimente" könntet ihr dann erstmal im Adminskript gemacht werden, bevor es die Allgemeinheit zu Gesicht bekommt und Ähnliches. Bei Bedarf könnte man das Ganze sogar noch andere Benutzergruppen erweitern.

if(typeof wgUserGroups !== "undefined") {
  for(var i = 0; i < wgUserGroups.length(); ++i) {
    if(wgUserGroups[i] === "sysop") {
      importScript("MediaWiki:Group-sysop.js");
      importScript("MediaWiki:Group-sysop.css");
      break;
    }
  }
}

Weitere Stimmen? --Revolus Echo der Stille 20:47, 18. Mai 2009 (CEST) (Code bitte reviewen.)

Von mir aus kann auch ein JavaScript-Skript nachgeladen werden oder auch erst, sobald ein Bedarf vorhanden ist.

Auf Commons wird das CSS-Skript Admin.css genannt, aber dein Vorschlag ist auch OK. --Leyo 15:35, 26. Mai 2009 (CEST)

Ich habe den Vorschlag von Revolus ergänzt (die Zeile mit "MediaWiki:Group-sysop.js" auskommentiert), MediaWiki:Group-sysop.css angelegt und es in Vorlage:JetztAuchSVG getestet. Nur wird es aber für Admins und IPs (testweise ausgeloggt) ausgeblendet. Revolus, kannst du dir das bitte mal anschauen? --Leyo 11:44, 21. Jun. 2009 (CEST)

Da ist wohl ein Typo in dem Code: length() muss in length geändert werden, da es keine Funktion ist. Zudem muss bei der CSS-Seite anstatt importScript importStylesheet benutzt werden. Gruß --P.Copp 12:28, 21. Jun. 2009 (CEST)

Hallo, bitte diese Änderung revertieren und in Zukunft Code immer erst vorher testen, bevor er für die Allgemeinheit eingebunden wird. Wie schon gesagt wurde, ist length eine Eigenschaft und keine Methode, CSS-Dateien sind Formatierungsanweisungen und keine Skripte, werden also mit Content-Type text/css (Funktion importStylesheet) statt text/javascript (Funktion importScript) eingebunden. Außerdem sind leere Benutzergruppen wie bei unangemeldeten Benutzern als Null-Objekte definiert, also nicht undefiniert. --Wiegels „…“ 12:42, 21. Jun. 2009 (CEST)

Oh, das hatte ich übersehen, danke für den Hinweis. Also müsste noch die Zeile

if(typeof wgUserGroups !== "undefined") {

in

if( window.wgUserGroups ) {

geändert werden. --P.Copp 12:55, 21. Jun. 2009 (CEST)

Richtig --Wiegels „…“ 13:09, 21. Jun. 2009 (CEST)

(BK) Danke P.Copp! Ich habe die Fehler korrigiert. Die Fehlerkonsole hatte mir übrigens wgUserGroup.length is not a function angezeigt. --Leyo 12:46, 21. Jun. 2009 (CEST)

Gut, habe das korrigiert. Danke euch beiden. --Leyo 13:25, 21. Jun. 2009 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 21:12, 21. Jul. 2009 (CEST)

Vorschlag zur Änderung der Tabs bei von Commons eingebundenen Bildern

Bei von Commons eingebundenen Bildern soll die Diskussionsseite auf Commons verlinkt werden: Wikipedia:Administratoren/Notizen#angebotene Bild-Diskussionsseite auf de, obwohl die Bild-Datei von Commons eingebunden ist --Leyo 08:22, 5. Jun. 2009 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Leyo 12:14, 3. Aug. 2009 (CEST)

Aus SVG automatisch erzeugte PNG-Grafiken in verschiedenen Auflösungen

Einige Verbesserungspunkte:

• Ich fände es hilfreich, wenn das div eine id bekommt, damit man das ausblenden kann.

+div.id = "file-svg-info";

• Die Seite sollte auch für Personen mit https-Zugang gestaltet werden.

-if (document.getElementById("shared-image-desc") == null) url = "http://de.wikipedia.org/w/thumb.php?f=";
-      else url = "http://commons.wikimedia.org/w/thumb.php?f=";
+if (document.getElementById("shared-image-desc")) url = wgServer + wgScriptPath + "/thumb.php?f=";
+      else url = "http://commons.wikimedia.org/w/thumb.php?f=";

Die Commonsurl muss für https nicht angepasst werden, da die anderen Links nach Commons auf der Seite auch nicht https sind.

• es fehlt encodeURIComponent

-url + wgTitle + "&width
+url + encodeURIComponent(wgTitle) + "&width

Danke. Der Umherirrende 21:10, 21. Jul. 2009 (CEST)

Punkt 2 und 3 habe ich umgesetzt, bei Punkt 1 bin ich mir nicht sicher, ob die Zeile vor oder nach div = document.createElement("div"); kommen muss. Und an dieser Seite rumspielen möchte ich ja nicht. :-) --Leyo 18:51, 31. Jul. 2009 (CEST)

Bei Punkt 2 ist nun durch das fehlende == null der then- und der else-Zweig vertauscht. Richtig wäre:

-if (document.getElementById("shared-image-desc") == null) url = "http://de.wikipedia.org/w/thumb.php?f=";
-      else url = "http://commons.wikimedia.org/w/thumb.php?f=";
+if (document.getElementById("shared-image-desc")) url = "http://commons.wikimedia.org/w/thumb.php?f=";
+      else url = wgServer + wgScriptPath + "/thumb.php?f=";

--Fomafix 19:09, 31. Jul. 2009 (CEST)

Danke Formafix, das stimmt, da hatte ich garnicht dran gedacht. Schlechter Stil des ersten Programmiers ;) --Der Umherirrende

Punkt 1 muss nach der Zeile, damit auch ein Objekt des typs vorhanden ist. Ich habe immer die Hoffnung, das ein JavaScript-Profi-Admin hier vorbei schaut … Der Umherirrende 19:13, 31. Jul. 2009 (CEST)

id ist eingebaut, aber ich konnte mich nicht zurückhalten und musste das ganze ein wenig kürzen [2]. wenn's jetzt kaputt sein sollte, bitte bescheidsagen. -- ∂ 20:39, 31. Jul. 2009 (CEST)

Der then- und der else-Zweig sind immer noch vertauscht. So wäre richtig: --Fomafix 13:48, 1. Aug. 2009 (CEST)

		var url	= document.getElementById("shared-image-desc")
-				? wgServer + wgScriptPath + "/thumb.php?f="
-				: "http://commons.wikimedia.org/w/thumb.php?f=";
+				? "http://commons.wikimedia.org/w/thumb.php?f="
+				: wgServer + wgScriptPath + "/thumb.php?f=";

hab das mal ungeprüft übernommen [3]. du wirst schon wissen was richtig ist :) -- ∂ 13:53, 1. Aug. 2009 (CEST)

Danke, jetzt funktioniert es wieder. --Fomafix 15:50, 1. Aug. 2009 (CEST)

Die richtige Adresse für Commons bei https wäre übrigens: https://secure.wikimedia.org/wikipedia/commons/w/thumb.php --Fomafix 13:53, 1. Aug. 2009 (CEST)

Damit würde es so aussehen: --Fomafix 15:50, 1. Aug. 2009 (CEST)

		var url	= document.getElementById("shared-image-desc")
				? wgServer.match( /^https/ )
					? "https://secure.wikimedia.org/wikipedia/commons/w/thumb.php?f="
					: "http://commons.wikimedia.org/w/thumb.php?f="
				: wgServer + wgScriptPath + "/thumb.php?f=";

das wird ja immer häßlicher... erledigt. [4] -- ∂ 12:00, 3. Aug. 2009 (CEST)

Ein klassisches if-else-Konstrukt kann manchmal schöner und leserlicher sein, aber es kann so bleiben, man kann es ja verstehen. --Der Umherirrende 15:35, 3. Aug. 2009 (CEST)

Danke ∂. Gegen eine https-Lösung für den Commonslink spricht (wie oben erwähnt), das eine Bildbeschreibungsseite mit https keinerlei https-links auf Commonms hat, daher wäre es unnötig. Aber so ist es schon sinnvoller. Der Umherirrende 15:35, 3. Aug. 2009 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 15:35, 3. Aug. 2009 (CEST)

JavaScript-Fehler

Hallo, könnte bitte jemand den Code reparieren, den Hcatlin vorhin eingebaut hat? Es fehlt mindestens am Anfang von Zeile 456 ein „/“. Ein Semikolon am Ende von Zeile 485 wäre auch schön. Anschließend bitte erfolgreich testen oder alle Änderungen zurücksetzen. Danke --Wiegels „…“ 23:23, 31. Jul. 2009 (CEST)

erledigt [5] -- ∂ 23:48, 31. Jul. 2009 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 11:01, 3. Aug. 2009 (CEST)

PNG-Version für SVG

Wenn man auf einer Bildseite ist, die es nicht gibt, aber die mit .svg endet, bekommt das Skript erwartungsgemäß einen Fehler. Beispielseite File:Flag of germany.svg. Das ganze wird zwar eher selten sein, sollte man aber vermeiden. Man sollte nach getElementById generell eine Überprüfung machen, ob es das Objekt auch gibt und dann erst nutzen. Danke. Der Umherirrende 12:33, 14. Aug. 2009 (CEST)

erledigt. ich bin gespannt, wann das fileDiv.nextSibling.nextSibling zum ersten mal bricht. -- ∂ 14:21, 14. Aug. 2009 (CEST)

Danke. So schnellt bricht das nicht, es steht eher an der falschen Stelle. Dann muss aber auch schon ein Software-Update kommen und das fällt sicher auf. Der Umherirrende 16:36, 14. Aug. 2009 (CEST)

Commons:MediaWiki:Common.js könnte ggf. auch upgedated werden. Mir ist's aber zu kompliziert. --Leyo 14:26, 14. Aug. 2009 (CEST)

da ist der fehler wohl schon länger gefixt [6] -- ∂ 14:35, 14. Aug. 2009 (CEST)

Ich habe nicht nur diesen, sondern auch zuvor korrigierte Fehler und Codebereinigungen gemeint. Aber wenn nichts Wichtiges dabei ist, umso besser. --Leyo 14:41, 14. Aug. 2009 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 16:36, 14. Aug. 2009 (CEST)

uselang=de

Probably nicer to use uselang=' + wgUserLanguage (I did this at nlwp). Multichill 17:53, 12. Mär. 2010 (CET)

Thanks for the hint. Were done --Der Umherirrende 19:39, 22. Mär. 2010 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 19:39, 22. Mär. 2010 (CET)

MediaWiki:Common.js/watchlist.js

Siehe Wikipedia Diskussion:Schiedsgericht/Wahl/November 2009#Beteiligen. Gerade eingebaut. Merlissimo 20:37, 8. Nov. 2009 (CET)

Vielleicht sollte man eine eigene Seite in MediaWiki:Watchlistfor einbinden, damit man eine getrennte Versionsgeschichte hat. Der Umherirrende 20:33, 9. Nov. 2009 (CET)

Gute Idee. Name? MediaWiki:Watchlist-message? Merlissimo 20:53, 9. Nov. 2009 (CET)

Du hast fragen … Dein Vorschlag hört sich aber gut an, da die Nachrichten ja bereits so benannt wurden. Der Umherirrende 20:56, 9. Nov. 2009 (CET)

Ok, ;-). Übersetungen brauchen wir doch nicht, oder? Ich binde die Seite dann direkt ein anstatt {{INT:}} zu benutzen. Merlissimo 21:02, 9. Nov. 2009 (CET)

Ja, das reicht völlig aus. Der Umherirrende 21:10, 9. Nov. 2009 (CET)

Nach dieser Info könnte man auch MediaWiki:watchlist-summary als Einstiegspunkt nehmen. Ich weiß nur nicht, ob es bei der Spezialseite auch funktioniert. Der Umherirrende 10:54, 14. Nov. 2009 (CET)

Tatsache (gerade im Testwiki getestet). Das kannte ich auch nicht. Erscheint dann direkt über dem Kasten. Ich verschiebe ich die Nachricht dorthin und lösche WatchlistFor. Merlissimo 11:38, 14. Nov. 2009 (CET)

Durch das Löschen von MediaWiki:Watchlistfor fehlt aber das div mit der id zum ausblenden. Der Umherirrende 11:47, 14. Nov. 2009 (CET)

Ja, bitte wieder herstellen, damit

#watchlistfor {display:none}

wieder funktioniert. --Fomafix 11:58, 14. Nov. 2009 (CET)

Danke, für’s wiederherstellen von MediaWiki:Watchlistfor. --Fomafix 08:58, 16. Nov. 2009 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 18:53, 22. Apr. 2010 (CEST)

Links zu gerenderten PNG-Grafiken von SVGs: Optimierte Funktion

Auf meinen Vorschlag hin, gibt es in der en-WP ebenfalls Links auf gerenderte PNG-Grafiken. Die Funktion auf Commons wurde darauf hin ebenfalls angepasst. Ich denke, wir könnten die optimierte Version ebenfalls übernehmen. Meinungen? --Leyo 19:07, 30. Nov. 2009 (CET)

Hallo Leyo, änder mal bitte die Zeile

var l = new Array( 200, 500, 1000, 2000 )

in

var l = [200, 500, 1000, 2000];

Gruß, --Revo Echo der Stille 19:46, 30. Nov. 2009 (CET)

Inkl. ; am Ende? --Leyo 20:33, 30. Nov. 2009 (CET)

Ja. --Revo Echo der Stille 21:52, 30. Nov. 2009 (CET)

Auf Commons geändert. Was ist mit de-WP? --Leyo 18:13, 8. Dez. 2009 (CET)

Scheint nichts dagegen zu sprechen. --Revo Echo der Stille 18:22, 8. Dez. 2009 (CET)

Momentan wird nach http und https unterschieden. Dies sehe ich in der Commons-Funktion nicht. Oder ist es „versteckt“? --Leyo 18:27, 8. Dez. 2009 (CET)

Das Skript auf Commons benutzt einen anderen Einstiegspunkt, um die gerenderten Bilder abzuholen. Die Unterscheidung ist deshalb unnötig. Als Nebeneffekt würde es (wahrscheinlich) nicht auf nicht-Wikimedia/Wikia-Installationen funktionieren. Aber eigentlich sollte man das als „Verbraucher“ nicht weiter merken. --Revo Echo der Stille 18:35, 8. Dez. 2009 (CET)

Done. Scheint zu klappen. --Leyo 18:47, 8. Dez. 2009 (CET)

Der Funktionsname SVGThumbs könnte eingespart werden, indem addOnloadHook eine anonyme Funktion übergeben wird. --Fomafix 20:16, 8. Dez. 2009 (CET)

So war's vorher. Falls der Funktionsname keine Vorteile mitbringt, kann der von mir aus auch wieder entfernt werden. --Leyo 20:25, 8. Dez. 2009 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Leyo 18:50, 22. Apr. 2010 (CEST)

Navileisten-Abschnitt

Ich habe mit gerade den Code angeschaut, der für das Einklappen der Navileisten zuständig ist. Dabei ist mir etwas aufgefallen, was man „heutzutage“ besser machen könnte: Anstatt über alle divs zu iterieren und manuell die NavFrames zu suchen, könnte man direkt die Funktion getElementsByClassName MediaWikis verwenden, die genau das, bloß besser (da, wenn möglich, optimiert), macht.

Alles von

var indexNavigationBar = 0;

bis zum Ende der Funktion müsste gegen dieses hier ersetzt werden:

   // iterate over all NavFrames
   var NavFrames = getElementsByClassName(document.getElementById("content"), "div", "NavFrame");
   for (var i=0;  i<NavFrames.length; i++) {
       var NavFrame = NavFrames[i];
       var NavToggle = document.createElement("a");
       NavToggle.className = 'NavToggle';
       NavToggle.setAttribute('id', 'NavToggle' + i);
       NavToggle.setAttribute('href', '#');
       NavToggle.onclick = toggleNavigationBarFunction(i);

       var NavToggleText = document.createTextNode(NavigationBarHide);
       NavToggle.appendChild(NavToggleText);

       // add NavToggle-Button as first div-element
       // in < div class="NavFrame" >
       NavFrame.insertBefore(NavToggle, NavFrame.firstChild);
       NavFrame.setAttribute('id', 'NavFrame' + i);
   }
   // if more Navigation Bars found than Default: hide all
   if (NavigationBarShowDefault < NavFrames.length) {
       for(var i=0; i<NavFrames.length; i++) {
           toggleNavigationBar(i);
       }
   }

Getestet auf Opera 10.10. Eine Durchsicht wäre vielleicht trotzdem gut. Gruß, --Revo Echo der Stille 17:17, 8. Dez. 2009 (CET)

Ist eingebaut. Die Performance ist deutlich schneller. Beim IE 6 ohne SP2 kann es laut MW-Entwicklern wohl zu Fehlern führen. In den Fall sind die Navileisten dann immer ausgeklappt. Merlissimo 20:42, 14. Jan. 2010 (CET)

Der Dinosaurier? Wer IE6 ohne SP2 nutzt, ist selber Schuld. Wird Zeit, dass diese Krankheit (ein browser isses ja wohl eher nicht) endlich verschwindet :D --Guandalug 21:06, 14. Jan. 2010 (CET)

Wüsste nicht, warum der IE Probleme machen sollte, Tests im IE5.5 und 6 sehen gut aus. Wo es allerdings nicht mehr funktioniert, ist der Modern-Skin, da er kein Element mit der ID "content" hat, das Ding heißt dort "mw_content" :D. Gruß --P.Copp 14:44, 15. Jan. 2010 (CET)

Erl. Warum wird eigentlich der Skin-Mischmasch so ziemlich als letztes von Browser geladen. Die ganzen Gadgets kommen vorher. Sollte man das nicht vertauschen? Merlissimo 15:22, 15. Jan. 2010 (CET)

Wo wir gerade dabei sind: die Vorlagenwerkstatt wünscht, dass der Vorlagennamensraum vom standardmäßigen Einklappen ausgenommen wird. Das ist sowohl bei klappbaren Wartungsvorlagen aus der Doku sowie bei verschachtelten Navileisten sinnvoll, man will im VorlagenNR ja den Inhalt sehen. ich schlage einfach mal foglende Zeile vor:

   if (wgNamespaceNumber == 10) return;
   // if more Navigation Bars found than Default: hide all
   ...

meint -- ✓ ^Bergi 21:06, 19. Apr. 2010 (CEST)

Ich hatte eher daran gedacht den ganzen Hook im VNR rauszunehmen anstatt abzubrechen. Merlissimo 21:11, 19. Apr. 2010 (CEST)

Ich fänd's aus den dargelegten Argumenten sinnvoll. Welche Variante besser ist, kann ich nicht beurteilen. --Leyo 09:43, 20. Apr. 2010 (CEST)

Dann kann man die Boxen ja nicht mehr einklappen, das ist insbesondere bei der angesprochenen Vorlage:Navigationsleistenwartung alles andere als sinnvoll. Zudem sieht der Nutzer dann in der Vorschau nicht, dass es sein Ziel (eine klappbare Leiste zu gestalten) erreicht hat. eher könnte / müsste man eine (zusätzliche) Meldung ausgeben, dass die Navileiste hier nicht klappbar ist. Ich sehe mich schon von Fragen auf WP:WVW bestürmt "Warum geht denn das nicht, der code stimmt doch" mit der hilflosen Antwort "muss man erst woanders einbinden damit das geht". Das ist nicht anwenderfreundlich!
meint -- ✓ ^Bergi 14:18, 20. Apr. 2010 (CEST)

erledigtErledigt Merlissimo 13:53, 22. Apr. 2010 (CEST)

Danke. --Leyo 15:07, 22. Apr. 2010 (CEST)

Archivierung dieses Abschnittes wurde am 13:53, 22. Apr. 2010 (CEST) gewünscht von Merlissimo

Bitte HTML-noscript-Tag mittels einer CSS-Klasse simulieren

• Hierher kopiert von „WP:FZW#Warum geht das HTML-noscript-Tag im Wiki-Quelltext nicht?“ (Permanent-Link)

Warum geht das HTML-noscript-Tag im Wiki-Quelltext nicht? Oder anders vielleicht besser gefragt, was spricht dagegen? MfG, --ParaDoxa 20:31, 9. Jan. 2010 (CET)

Ich wüsste nicht wozu wir das hier brauchen. Scripte sind sowieso nicht erlaubt, und die von der Software erzeugten, haben für uns keine Bedeutung. Daher braucht man eigentlich keinen extra Hinweis bei deaktiviertem Javascript. -- chatter™ 21:59, 9. Jan. 2010 (CET)

„wir“ ganz pauschal „brauchen“ das sicherlich nicht, aber nicht vernachlässigbar wenige von „uns“ mMn ganz gewiss. Zwei (mMn alles andere als ungewöhnliche) Fälle habe ich, wo eine funktionierendes HTML-noscript-Tag sehr nützlich wäre, um bei aktiviertem JavaScript keine überflüssige Hinweise sehen zu müssen: Siehe (a) roten „Standard-Sortierung“-Hinweis und (b) den „JavaScript muss aktiv sein um nach anderen Spalten sortieren zu können“-Hinweis in der vierten Zeile. MfG, --ParaDoxa 02:07, 10. Jan. 2010 (CET)

Eine solche Funktion könnte man auch recht einfach mittels einer CSS-Klasse simulieren. Dazu müsste z.B. auf MediaWiki:Common.js die Zeile

<syntaxhighlight inline lang="javascript">appendCSS('.noscript {display:none;}');</syntaxhighlight>

hinzugefügt werden. Statt <noscript></noscript> könnte man dann <div class="noscript"></div> verwenden. Gruß --P.Copp 15:35, 10. Jan. 2010 (CET)

Coole Lösung :) --APPER\^☺☹ 19:45, 10. Jan. 2010 (CET)

Fantastisch! Jetzt wäre es nahezu utopisch ;-) wenn das jemand der kann und will, das auch in die „MediaWiki:Common.js“ einfügen würde, bitteschön… --ParaDoxa 15:42, 12. Jan. 2010 (CET)

MfG, --ParaDox 19:46, 15. Jan. 2010 (CET)

Ich sehe dafür eigentlich keinen Verwendungszweck. Wer Javascript deaktiviert hat, weiß das auch und dass das Folgen auf die „Dynamizität“ der Webseite hat. Andererseits würde eine solche Zeile auch nicht unbedingt schaden … --Revo Echo der Stille 00:22, 16. Jan. 2010 (CET)

Ich hab’s eingebaut, da ich das durchaus für sinnvoll halte (Stichwort Tabellensortierung). --32X 06:45, 16. Jan. 2010 (CET)

Vielen Dank :-)  Ich habe es schon an zwei Stellen ausprobiert (A und B), und (spätestens) nach leeren vom Browser-Cache und purgen funktioniert es auch perfekt, nicht nur in DIV-Tags, sondern auch in SPANs. Vermutlich noch nicht ideal in Bezug auf Stelle und Form, habe ich das auch schon in „[[Hilfe:Tabellen]]“ dokumentiert. MfG, --ParaDox 10:11, 16. Jan. 2010 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 18:53, 22. Apr. 2010 (CEST)

/secure.js

Kann man dort bitte noc.wikimedia.org von der Umwandlung ausnehmen, da man ansonsten auf eine nicht existente Seite kommt? – Giftpflanze 16:55, 29. Mär. 2010 (CEST)

Wurde von Merlissimo erledigt --Der Umherirrende 18:49, 22. Apr. 2010 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 18:49, 22. Apr. 2010 (CEST)

Bitte Vorlage:Link FA und Vorlage:Link GA auch im Vector-Skin berücksichtigen

Derzeit ist Vorlage:Link FA (und auch Vorlage:Link GA) im Vector-Skin wirkungslos. Da der Vector-Skin zukünftig der standardmäßige Skin sein soll, wäre es fein, wenn jemand die js/css anpassen könnte, sodass auch mit diesem Skin die FAs und GAs ersichtlich sind. Danke im voraus! --UV 21:17, 28. Mär. 2010 (CEST)

Ich bin schon am basteln..... --Guandalug 22:10, 28. Mär. 2010 (CEST)

Die Bastelei wurde eingebaut. Verbesserungsvorschläge sollten auf MediaWiki Diskussion:Vector.css angebracht werden. Der Umherirrende 16:12, 14. Mai 2010 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 16:12, 14. Mai 2010 (CEST)

includePage

Auf WP:Skin steht, das man includePage nicht mehr verwenden soll. Die Common.js sollte dann auch mit guten Beispiel voran gehen. Also bitte vorhandene Aufrufe durch importScript ersetzen und die Funktion deutlich als veraltet (deprecated) kennzeichnen. Bitte nicht entfernen, da sie noch in Benutzerskripten verwendet wird, eine Anpassung derer halte ich aber für unnötig. Vielen Dank. Der Umherirrende 16:00, 14. Mai 2010 (CEST)

Spricht eigentlich etwas gegen:

function includePage(name) { return importScript(name); }

als "alias" ? Die Aufrufsyntax ist ja (anscheinend) identisch.... --Guandalug 18:31, 14. Mai 2010 (CEST)

Das return ist sogar richtig. Ich hätte nicht erwartet, das man das script zurückbekommt. Somit wäre die Schreibweise möglich. Der einzige Unterschied ist die Art des Encodings und hier wird die MediaWiki-Lösung wohl weniger Probleme verursachen. Der Umherirrende 10:11, 15. Mai 2010 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Guandalug 16:02, 11. Jun. 2010 (CEST)

Bedingung der Einbindung von MediaWiki:Onlyifediting.js

Ich möchte vorschlagen, die Bedingung zur Einbindung der Seite MediaWiki:Onlyifediting.js zu ändern:

if (document.URL.indexOf("action=edit") > 0 || document.URL.indexOf("action=submit") > 0) {
    includePage("MediaWiki:Onlyifediting.js");
}

nach:

if ( wgAction == 'edit' || wgAction == 'submit' ) {
    includePage("MediaWiki:Onlyifediting.js");
}

Ich finde es sinnvoller die variablen zu benutzen, anstatt sich erst die URL zu holen und dann diese zu prüfen. Ob es irgendein Vorteil der einen oder der anderen Methode gibt, mag ich nicht sagen. Falls es aber so ist, wäre ich für Aufklärung dankbar. Vielen Dank fürs ändern. Der Umherirrende 16:08, 14. Mai 2010 (CEST)

Ich vermute mal, der Code oben ist älter als die Variable. Besser lesbar ist das mit Variable allemal. Gute Idee. --Guandalug 16:10, 14. Mai 2010 (CEST)

Das wäre eine plausible Erklärung. Ich werde mir aber nicht die Mühen machen, das zu überprüfen. Der Umherirrende 10:12, 15. Mai 2010 (CEST)

Lohnt auch nicht. Ich stell das um, wenn ich das mit dem importScript eins drüber angehe. Nur erst testen natürlich. --Guandalug 10:19, 15. Mai 2010 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Guandalug 16:02, 11. Jun. 2010 (CEST)

Bitte blog.wikimedia.org aus der /secure.js rausnehmen

Ansonsten wird man auf einen falschen Link gebogen. – Giftpflanze 22:10, 15. Jun. 2010 (CEST)

Archivierung dieses Abschnittes wurde am 22:37, 15. Jun. 2010 (CEST) gewünscht von Merlissimo

Javascript-Fehler mit Vector-Skin

Wenn ich das Vector-Skin aktiviere, bekomme ich im Firefox einen Javascript-Fehler auf allen Bildbeschreibungsseiten:

Error: talk is null

Source File: http://de.wikipedia.org/w/index.php?title=-&action=raw&smaxage=0&gen=js&useskin=vector

Line: 417

Die betreffenden Zeilen lauten:

	var talk = document.getElementById( 'ca-talk' );
	if( !talk.className.match( /(^| )new( |$)/) ) return;

Das Problem dürfte sein, dass der Diskussionslink bei Vector die ID ca-image_talk und nicht ca-talk hat. Ich habs nicht getestet, aber folgendes sollte auch mit Vector funktionieren:

	var talk;
	if( skin=="vector" ) {
		talk = document.getElementById( 'ca-image_talk' );
	} else {
		talk = document.getElementById( 'ca-talk' );
	}
	if( !talk || !talk.className.match( /(^| )new( |$)/) ) return;

Gruß, dapete 17:51, 31. Jul. 2009 (CEST)

Hi Dapete, hier für dewiki bestätigt. Könntest du es bitte mal im http://translatewiki.net probieren? Das läuft mit der allersuperaktuellsten MediaWiki-Version (dewiki hinkt mal wieder Woooochen hinterher). — Raymond ^{Disk. Bew.} 18:20, 31. Jul. 2009 (CEST)

gefixt [7] -- ∂ 23:55, 31. Jul. 2009 (CEST)

Danke. Sehr kompakter Code :)

Ich hab auf translatewiki.net nachgesehen, da hat das doch wieder die ID ca-talk - wenn wir die Version die da läuft auch bekommen, kann die Unterscheidung wohl im Prinzip wieder wegfallen. --dapete 09:40, 1. Aug. 2009 (CEST)

Die Unterscheidung kann wieder ausgebaut werden, da gestern die neue Version live gegangen ist. Der Umherirrende 17:27, 18. Sep. 2009 (CEST)

Unterscheidung wurde ausgebaut. Der Umherirrende 11:34, 19. Jun. 2010 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 11:34, 19. Jun. 2010 (CEST)

wgMainPageTitle

• Ich denke man könnte wgMainPageName entfernen und durch wgMainPageTitle ersetzen. (Für die Mobilgeräte). wurde ganz entfernt
• Die Ergänzung des Links Wikipedia:Sprachen auf der Hauptseite könnte man auf wgMainPageTitle laufen lassen, anstatt den Titel und Namensraum dort vorzugeben.

Vielen Dank. Der Umherirrende 18:03, 12. Mär. 2010 (CET)

Diese Änderung ist noch nicht ganz, was ich eigentlich wollte. In HTML-Quelltext jeder Seite gibt es eine js-variable wgMainPageTitle="Wikipedia:Hauptseite". Mithilfe dieser Variable kann das ganze geprüft werden und funktioniert auch nach Umbenennung der Hauptseite (was nicht in Aussicht steht, aber wenn jemand es in andere Wikis übernehmen möchte, ist es auch einfacher, sofern die passende MediaWiki-Version genutzt wird).

    // only on the main page
    if ( wgPageName != wgMainPageTitle ) return;

Vielleicht ist es bei meinem anfangs geschriebenen nicht klar geworden. Der Umherirrende 11:39, 19. Jun. 2010 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Guandalug 12:02, 19. Jun. 2010 (CEST)

Bug auf Special:Search

Hi, schaut euch bitte mal bugzilla:23902 an. Da er afaik nur auf dewiki auftritt halte ich es für nicht unwahrscheinlich, dass ein Fehler in Common.js dafür verantwortlich ist (Fehler tritt in Vector und Monobook auf) --Church of emacs D B 11:13, 11. Jun. 2010 (CEST)

Ich debug das heute Abend mal mit FireBug und co. Mal sehen, ob ich irgendwas rausfinde.... --Guandalug 15:41, 11. Jun. 2010 (CEST)

Kann ich im IE8 nicht nachvollziehen, aber im FireFox 3.6.3. Idee habe ich aber auch keine --Der Umherirrende 19:16, 11. Jun. 2010 (CEST)

Ich kann den Bug mit Opera 10.60 und Firefox 3.6.3 nicht bestätigen. Gruß, --Revo Echo der Stille 19:24, 11. Jun. 2010 (CEST)

witzig auch, daß man mit rechtsklicks im FF 3.6.3 auch (einen nach dem anderen) alle buttons nach oben schubsen kann :) -- ∂ 19:26, 11. Jun. 2010 (CEST)

Das hab ich auch. Und ich dachte schon, der Fehler läge an mir. ;) --Revo Echo der Stille 19:28, 11. Jun. 2010 (CEST)

ich hab auch den beschriebenen bug, daß es beim ersten klick nichts tut. mir scheint, daß der onmousedown-handler manchmal erst nachdem behandeln des klickt drankommt, wo es bereits zu spät ist und die vor der manipulation im a.href stehende URL bereits geladen wird -- ∂ 19:44, 11. Jun. 2010 (CEST)

falscher eindruck, mwSearchHeaderClick wird aufgerufen und die URL im a.href wird auch geändert - nur passiert danach gar nichts mehr. ob da jemand den click-event auffrißt? ich hätte da den code hinter suggest-popup in verdacht. -- ∂ 20:11, 11. Jun. 2010 (CEST)

function mwSearchHeaderClick(obj) { 
    var searchbox = document.getElementById("searchText"); 
    if (searchbox === null) { 
        searchbox = document.getElementById("powerSearchText"); 
    } 
    if (searchbox === null) { 
        return; 
    } 
    var searchterm = searchbox.value; 
    var parts = obj.href.split("search="); 
    var lastpart = "";
    var prefix = "search="; 
    if (parts.length > 1 && parts[1].indexOf("&") >= 0) { 
        lastpart = parts[1].substring(parts[1].indexOf("&")); 
    }
    else {
        prefix = "&search="; 
    } 
    obj.href = parts[0] + prefix + encodeURIComponent(searchterm) + lastpart; 
}

<script type="text/javascript">hookEvent("load", function() {document.getElementById('searchText').focus();});</script>
<div class="mw-search-formheader">
    <div class="search-types">
        <ul>
            <li class="normal">
                <a href="/w/index.php?title=Spezial:Suche&amp;fulltext=Suche&amp;ns0=1&amp;redirs=0" title="Suchen in (Artikel-)" onmousedown="mwSearchHeaderClick(this);" onkeydown="mwSearchHeaderClick(this);">Inhaltsseiten</a>
            </li>
            <li class="normal">
                <a href="/w/index.php?title=Spezial:Suche&amp;fulltext=Suche&amp;ns6=1&amp;redirs=0" title="Nach Bildern suchen" onmousedown="mwSearchHeaderClick(this);" onkeydown="mwSearchHeaderClick(this);">Multimedia</a>
            </li>
            <li class="normal">
                <a href="/w/index.php?title=Spezial:Suche&amp;fulltext=Suche&amp;ns4=1&amp;ns12=1&amp;redirs=0" title="Suchen in Wikipedia, Hilfe" onmousedown="mwSearchHeaderClick(this);" onkeydown="mwSearchHeaderClick(this);">Hilfe und Projektseiten</a>
            </li>
            <li class="current">
                <a href="/w/index.php?title=Spezial:Suche&amp;fulltext=Suche&amp;ns0=1&amp;ns1=1&amp;ns2=1&amp;ns3=1&amp;ns4=1&amp;ns5=1&amp;ns6=1&amp;ns7=1&amp;ns8=1&amp;ns9=1&amp;ns10=1&amp;ns11=1&amp;ns12=1&amp;ns13=1&amp;ns14=1&amp;ns15=1&amp;ns100=1&amp;ns101=1&amp;redirs=0" title="Gesamten Inhalt durchsuchen (inklusive Diskussionsseiten)" onmousedown="mwSearchHeaderClick(this);" onkeydown="mwSearchHeaderClick(this);">Alles</a>
            </li>
            <li class="normal">
                <a href="/w/index.php?title=Spezial:Suche&amp;fulltext=Suche&amp;advanced=1&amp;ns0=1&amp;ns1=1&amp;ns2=1&amp;ns3=1&amp;ns4=1&amp;ns5=1&amp;ns6=1&amp;ns7=1&amp;ns8=1&amp;ns9=1&amp;ns10=1&amp;ns11=1&amp;ns12=1&amp;ns13=1&amp;ns14=1&amp;ns15=1&amp;ns100=1&amp;ns101=1&amp;redirs=0" title="Suche in weiteren Namensräumen" onmousedown="mwSearchHeaderClick(this);" onkeydown="mwSearchHeaderClick(this);">Erweitert</a>
            </li>
        </ul>
    </div>
    <div style="clear:both"></div>
</div>

Arg! So macht man das auch auch nicht. Die letzte Zeile von mwSearchHeaderClick sollte return (obj.href = ...); heißen. --Revo Echo der Stille 20:02, 11. Jun. 2010 (CEST)

Behoben (Danke an die IRC-Chatcrew für die Tests). Der "Fehler" ist ein CSS-Bug... oder besser, WAR einer. damit hat er sich dann verabschiedet. --Guandalug 20:55, 11. Jun. 2010 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Guandalug 11:16, 19. Jun. 2010 (CEST)

NavFrame und IDs

Das Skript überschreibt die ID-Attribute von NavFrames. ID-Attribute wären aber durchaus nützlich, um Vorlagen wie Infoboxwartung, Kategoriewartung und Navigationsleistenwartung von echten Navigationsleisten zu unterscheiden.

Muss der (soweit ich das sehe) nur für interne Zwecke des Skripts benötigte Index wirklich als ID ins Dokument geschrieben werden oder lässt sich das irgendwie vermeiden? (Man könnte zwar zur Unterscheidung auch auf Klassen ausweichen, finde ich aber etwas von hinten durch die Brust ins Auge.) Gruß --Entlinkt 00:38, 7. Aug. 2010 (CEST)

es läßt sich vermeiden, wenn man die elemente einfach direkt referenziert, statt den umweg über die id zu gehen [8]. sollte mein patch nicht funktionieren, bitte bescheid sagen. -- ∂ 01:12, 7. Aug. 2010 (CEST)

Sieht gut aus und funktioniert (IE >= 5.5 und aktuelle Versionen von allem anderen getestet). Vielen Dank! --Entlinkt 02:32, 7. Aug. 2010 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 15:29, 7. Aug. 2010 (CEST)

ts_parseFloat() wieder an formatnum anpassen

Da formatnum die Zahlen mit einer Leerstelle anstatt eines Punktes ausliefert, muss auch die Funktion ts_parseFloat angepasst werden:

-    num = num.replace(/\./g, "");
+    num = num.replace(/\.|#160;/g, ""); /* auch geschützte Leerstellen aus Tausendertrenner akzeptieren */

Gruß, --Revolus Echo der Stille 04:26, 21. Jun. 2009 (CEST)

Bevor ich es anpasse, würde ich gerne noch auf ein, zwei Meinungen warten… --Leyo 13:28, 21. Jun. 2009 (CEST)

Ich denke, seit rev:42715 ist das lokale Überschreiben der Funktion nicht mehr notwendig. Ich schätze, wenn man die Funktion hier löscht, sollte das ganze auch wieder funktionieren. Gruß --P.Copp 13:51, 21. Jun. 2009 (CEST)

Ah, okay, noch besser :-) --Revolus Echo der Stille 14:10, 21. Jun. 2009 (CEST)

Gut, ich habe die Zeile gelöscht. --Leyo 11:07, 22. Jun. 2009 (CEST)

Fast. ;-) Die ganze Funktion muss raus. Gruß, --Revolus Echo der Stille 11:48, 22. Jun. 2009 (CEST)

Jetzt besser? --Leyo 12:02, 22. Jun. 2009 (CEST)

Unter Hilfe Diskussion:Tabellen#Fehler in der deutschen Sortierfunktion gibt es Hinweise auf ein fehlerhaftes Sortieren in Tabellen. Ich kann nicht sagen, ob dies mit der Entfernung oder der Umstellung von Formatnum zu tuen hat. Wäre gut, wenn jemand das auflösen könnte. Danke. Der Umherirrende 20:57, 21. Jul. 2009 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Guandalug 15:06, 15. Aug. 2010 (CEST)

Weitere Suchmaschinen

Benutzer:Pmartin hat netterweise MediaWiki:SpezialSuche.js repariert und dann in der Commons.js wieder aktiviert.

Dies habe ich rückgängig gemacht, weil das auch im einfachen Suchformular erscheint. Das einfache Suchformular heißt aber einfach, weil es so wenig Elemente wie möglich enthalten soll. Dies geht auf Untersuchungen der Usability-Initiative der Wikimedia Foundation zurück.

Nun mag es Benutzer geben, die die weiteren Suchmaschinen benötigen/mögen/wasauchimmer, diese dürften jedoch in der Minderheit sein, so dass es meiner Meinung nach vertretbar ist, wenn die weiteren Suchmaschinen nur im erweiterten Suchformular erscheinen. Kann das Code in MediaWiki:SpezialSuche.js entsprechend angepasst werden? — Raymond ^{Disk. Bew.} 15:11, 3. Aug. 2009 (CEST)

Inzwischen funktioniert LuenceSearch zuverlässig und erkennt auch Ähnlichkeiten usw. Ich sehe deshalb auch keinen Grund mehr für eine externe Suchoption. Sollte die WP-eigene Suchmaschine mal streiken, kann man es mal kurzfristig einschalten. Aber damit rechne ich nicht. Merlissimo 15:23, 3. Aug. 2009 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Guandalug 15:07, 15. Aug. 2010 (CEST)

Interwiki-Links kommentieren

Liebe Fachleute, bei Wikisource gibt es eine sehr schöne Funktion, die es über die Vorlage Interwiki-Info ermöglicht,

• Interwiki-Links mit einem Kommentar zu versehen – dort in der Regel der Hinweis auf die Originalversion bei einer Übersetzung; in der Wikipedia könnte man z.B. bei Bedarf auf eine Version mit deutlich mehr Informationen hinweisen, insbesondere, wenn dies einmal nicht die englische Version ist, – sowohl als Service für Leser, die der betreffenden Sprache mächtig sind, als auch als Hinweis für weitere Wikipedianer, dass es sich lohnt, Informationen von dort zu übernehmen (bei "kleineren" Themen gibt es ja in der Regel in keiner Sprache einen "exzellenten Artikel");
• mehrere Interwiki-Links auf dieselbe Sprache durch einen zusätzlichen Hinweis voneinander zu unterscheiden – bei Wikisource dient dies vor allem dazu, verschiedene Übersetzungen des gleichen Werks zu unterscheiden; hier könnte man mit dieser Funktion bei komplexen Themen, die in anderen Wikipedias anders aufgeteilt sind als in der deutschen, mehrere Interwiki-Links auf dieselbe Sprache anlegen und diese für den Leser sichtbar unterscheiden.

(Am ausgiebigsten wird diese Funktion bisher bei der englischen Wikisource benutzt; hier gibt's eine Übersicht der Seiten, die sie verwenden.) Wie mir El Cazangero erklärt hat, wird das bei Wikisource durch die function interwikiExtra() in s:MediaWiki:Monobook.js ermöglicht. Ich fände es schön, wenn man diese Funktion auch in das Wikipedia-JavaScript übernehmen könnte. --Daniel Bunčić 07:20, 31. Jan. 2007 (CET)

Will das irgendwer einbauen? Das liegt jetzt schon ein paar Jahre hier rum. Da keine Kommentare kamen (weder Pro noch Kontra) wäre ich für eine Schließung. --Guandalug 10:54, 15. Aug. 2010 (CEST)

Die Funktion liegt übrigens in s:en:MediaWiki:Common.js rum und sieht auf den ersten Blick mit den 2 verschachtelten for-Schleifen wenig effizient aus... (aber das mag ich jetzt nicht genauer analysieren). Interessanterweise ist der fest verdrahtete Text dann auch noch Deutsch... sehr seltsam. --Guandalug 14:50, 15. Aug. 2010 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Guandalug 23:55, 12. Jan. 2011 (CET)

"Alle Sprachen" auf der Hauptseite und https

Der Link zu Wikipedia:Sprachen wird aktuell über JavaScript auf die Hauptseite gesetzt und bei https-Verbindungen anschließend umgebogen. Hier wäre es sinnvoller, direkt einen richtigen Link zu setzen, denke ich. Nach meinem Verständnis dürfte es mit

	var completelist = mw.util.addPortletLink(
		'p-lang',
		mw.util.wikiGetlink( 'Wikipedia:Sprachen' ),
		'Alle Sprachen',
		'interwiki-completelist',
		'Alle Sprachen'
	);

funktionieren. Ich würde mich über Kommentare freuen. Vielen Dank. Der Umherirrende 21:10, 23. Jul. 2011 (CEST)

In einem Monat sollte das Problem sich doch von selbst lösen. --Steef ³⁸⁹ 22:07, 23. Jul. 2011 (CEST)

Daher bin ich ja darauf gekommen. Ich glaube nicht, das es sich von selbst löst, da dort noch ein http steht. Auch wenn man das http entfernt würde das relative Protokoll nicht aufgelöst werden, weil es sich um JavaScript handelt und ich glaube nicht, das sich das bis dort durchschlägt, auch wenn der RessourceLoader das vielleicht unterstützen könnte. Aus diesem Grund mein Vorschlag aus dem aktuellen absoluten Pfad einen relativen Pfad (nicht relatives Protokoll) zu machen. Das funktioniert jetzt und wird nach der Umstellung auch funktionieren. Der Umherirrende 00:21, 24. Jul. 2011 (CEST)

Ergänzend: Es funktioniert aktuell mit //de.wikipedia.org/wiki/Wikipedia:Sprachen, aber die URL für https gibt es noch nicht, daher können wir nicht umstellen. Wenn aber erst ein Admin das ändert, wenn WMF-Wikis umgestellt sind, gibt es eine Zeitspanne wo der Link nicht auf https linkt, daher mein Vorschlag das JavaScript anzupassen. Hat auch den Vorteil, wenn in Zukunft sich andere Teile der URL ändern, das diese sofort dabei sind. Alternativ kann man auch MediaWiki:Common.js/secure.js umstellen, das relative Protokolle auf die aktuell funktioniere https-Variante umgestellt werden, dann kann man hier schon das http entfernen und hat keine Zeitspanne wo es falsch ist. Der Umherirrende 18:41, 25. Jul. 2011 (CEST)

Die Zeitspanne kann durch Caches auch noch größer werden. Wenn das http erst nach der Umstellung entfernt wird, steht im Cache der Benutzer immer noch http. Dadurch das die neuen https-Links genutzt werden, wird MediaWiki:Common.js/secure.js nicht mehr geladen und somit bleibt der Link dort auf http stehen. Kein großes Ding, aber ich wollte nur davor warnen. Der Umherirrende 19:25, 25. Jul. 2011 (CEST)

Oder auch nicht, weil der RessourceLoader das schafft. Lassen wir es, wird schon passen. Der Umherirrende 20:23, 25. Jul. 2011 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 20:23, 25. Jul. 2011 (CEST)

Navigationsleisten im Modern-Skin

Die Navigationsleisten lassen sich im Modern-Skin nicht ein- oder ausklappen (Beispiel). Ich habe beim überfliegen keine Idee gehabt. Wäre schön, wenn sich jemand das anschauen könnte. Vielen Dank. Der Umherirrende 19:51, 31. Aug. 2011 (CEST)

Das liegt daran, dass rev:80786 noch nicht live ist und mw.util.$content.find( 'div.NavFrame' ) somit nichts findet. --Schnark 09:16, 1. Sep. 2011 (CEST)

Sollte jetzt (Mit 1.18) live sein. Der Umherirrende 21:30, 6. Okt. 2011 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 21:30, 6. Okt. 2011 (CEST)

WP:Meinungsbilder/Rollback-Recht: Änderung der Rollbackfunktion?

Ich wäre froh, wenn sich dort jemand zur Umsetzbarkeit dieses Vorschlags äussern könnte. --Leyo 13:44, 26. Jul. 2011 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Leyo 17:19, 22. Nov. 2011 (CET)

neue Sortierfunktion in MediaWiki 1.18

header
x
äa
ßa
ab
öa
ssb
ub
ob
üa

In Mediawiki 1.18 das auf die Nacht zu heute eingespielt wurde, besteht die Möglichkeit das Sortierverhalten für Tabellen global auf einem Wiki zu beeinflussen, siehe Wikipedia:Projektneuheiten in dem z.B.

tableSorterCollation={'Ä':'A', 'Ö':'O', 'Ü':'U', 'ä':'a', 'ö':'o', 'ü':'u', 'ß':'ss'};

in MediaWiki:Common.js aufgenommen wird, so dass auch Umlaute und das ß automatisch korrekt sortieren werden können ohne auf Vorlagen wie {{SortKey}} zurückgreifen zu müssen. Ich denke es wäre sinnvoll das aufzunehmen. --Mps 12:49, 6. Okt. 2011 (CEST)

Ich habe es zwar umseitig eingetragen, aber in meinem Test funktionierte es nicht. Hmm? --32X 09:08, 28. Nov. 2011 (CET)

Sieht bei mir garnicht mal schlecht aus. Cache? Der Umherirrende 19:27, 28. Nov. 2011 (CET)

Probablich, denn jetzt geht es bei mir auch. --32X 09:39, 29. Nov. 2011 (CET)

Bedeutet dies, dass man nun bei Artikeln wie Essigsäure {{SORTIERUNG:Essigsaure}} rausschmeissen kann? --Leyo 09:42, 29. Nov. 2011 (CET)

Nein. Diese Sortierreihenfolge betrifft nur sortierbare Tabelle. --Fomafix 09:48, 29. Nov. 2011 (CET)

Und wann kommt's dort? :-) --Leyo 10:11, 29. Nov. 2011 (CET)

Nie? (Weil es eine serverseitige Funktionalität vorraussetzt, hier jedoch clientseitige Skripte laufen.) --32X 19:51, 2. Dez. 2011 (CET)

Prinzipiell könnte der Unicode Collation Algorithm für die Kategoriesortierung aktiviert werden, allerdings müssten dazu noch ein paar serverseitige Module installiert werden. --Schnark 09:30, 3. Dez. 2011 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: --32X 09:39, 29. Nov. 2011, Schnark 09:30, 3. Dez. 2011 (CET)

admin ui changes

MediaWiki:Group-sysop.css wird mit der neuen Version automatisch für alle Administratoren eingebunden. Daher können und sollten die entsprechenden Zeilen aus MediaWiki:Common.js (einschließlich des auskommentierten Teils für .js, admin ui changes) entfernt werden. Um zu verifizieren, dass das klappt, folgt hier ein Satz, den nur Administratoren lesen können: Diesen Satz sehen nur Administratoren. --Schnark 10:23, 6. Okt. 2011 (CEST)

Falsch, das ist MediaWiki:Groups-sysop.css, was eingebunden wird ;) Muss ich testen, sollte aber gehen. --Guandalug 11:08, 6. Okt. 2011 (CEST)

Ich weiß ja nicht, wo du das Plural-s gelesen hast, aber includes/resourceloader/ResourceLoaderUserGroupsModule.php weiß nichts davon. --Schnark 09:11, 7. Okt. 2011 (CEST)

Auf Wikipedia:NEU steht's mit 's' (und das hab ich mangels Zeit eigener Analyse dann auch mal geglaubt. Deine Quelle sagt da klar was anderes). --Guandalug 09:26, 7. Okt. 2011 (CEST)

Habe es dort korrigiert, die Release-Notes haben übrigens lange Zeit eine noch mal andere Bezeichnung verbreitet. --Schnark 10:00, 7. Okt. 2011 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --32X 21:04, 30. Dez. 2011 (CET)

Drop down

Ich würde gerne längere Tabellen in Artikeln nur auf Anforderung des Lesers anzeigen. In der en.wp gibt es dazu eine "collapsible" funktion. Könnten wir die hier auch bekommen?--WerWil 14:26, 1. Feb. 2009 (CET)

(Zum Hintergrund zu dieser Anfrage siehe Wikipedia Diskussion:Tabellen#Ausklappbar. --W_I^KImaniac 14:48, 1. Feb. 2009 (CET))

Geht nicht? Oder ist unerwünscht?--WerWil 21:29, 12. Feb. 2009 (CET)

Meiner Meinung nach unerwünscht, da Benutzer-unfreundlich. Stichwort #Screenreader', Stichwort' ausdrucken'. --Guandalug 12:19, 1. Jul. 2009 (CEST)

Gibt's teilweise trotzdem, beispielsweise in Hansa Rostock. --Leyo 15:50, 3. Aug. 2009 (CEST)

Ja, oder bei Episodenlisten. Macht die Sache nicht schöner... oder erwünschter. Wie gesagt, meine Meinung. --Guandalug 15:54, 3. Aug. 2009 (CEST)

Die Benutzerunfreundlichkeit kann ich nicht erkennen. Manche Liste liefert für den Textfluss nicht notwendige Hintergrund- oder Zusatzinformationen, reißt aber den Artikel massiv auseinander. Wenn der Benutzer, dann entscheiden kann ob er sich das ansehen will oder nicht, dann ist das für mich ein erheblicher Komfortgewinn.--WerWil 20:04, 6. Sep. 2009 (CEST)

… insbesondere auf de.m.wikpedia.org. — Christoph Päper 12:42, 6. Mär. 2010 (CET)

Text
Hat sich mit class="mw-collapsible" erledigt. --Mps 01:51, 22. Jan. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Mps 01:51, 22. Jan. 2012 (CET)

Betragsteile Verstecken

Damit es möglich ist die Vorlage:Versteckt zu nutzen muss folgender Quelltext in die MediaWiki:Common.js kopiert werden und ich hoffe das dies Möglich ist:

    /** 
        Toggles the display of elements on a page 
        Author/contact: Austin Che http://openwetware.org/wiki/User:Austin_J._Che
        See http://openwetware.org/wiki/OpenWetWare:Toggle for examples and documentation
     */

// indexed array of toggler ids to array of associated toggle operations
// each operation is a two element array, the first being the type, the second a class name or array of elements
// operation types are strings like "_reset" or "" for the default toggle operation
var togglers = new Array();     
var allClasses = new Object(); // associative map of class names to page elements

function toggler(id)
{
    var toBeToggled = togglers[id];
    if (!toBeToggled)
        return;

    // if some element is in list more than once, it will be toggled multiple times
    for (var i = 0; i < toBeToggled.length; i++)
    {
        // get array of elements to operate on
        var toggles = toBeToggled[i][1];
        if (typeof(toggles) == "string")
        {
            if (toggles.charAt(0) == '-')
            {
                // treat as an element ID, not as class
                toggles = document.getElementById(toggles.substring(1));
                if (toggles)
                    toggles = new Array(toggles);
            }
            else
                toggles = allClasses[toggles];
        }
        if (!toggles || !toggles.length)
            continue;

        var op = toBeToggled[i][0]; // what the operation will be

        switch (op)
        {
            case "_reset":
                for (var j in toggles)
                    toggles[j].style.display = toggles[j]._toggle_original_display;
                break;
            case "_show":
                for (var j in toggles)
                    toggles[j].style.display = '';
                break;
            case "_hide":
                for (var j in toggles)
                    toggles[j].style.display = 'none';
                break;
            case "":
            default:
                // Toggle
                for (var j in toggles)
                    toggles[j].style.display = ((toggles[j].style.display == 'none') ? '' : 'none');
                break;
        }
    }
}

function createTogglerLink(toggler, id)
{
    var toggle = document.createElement("a");
    toggle.className = 'toggler-link';
    toggle.setAttribute('id', 'toggler' + id);
    toggle.setAttribute('href', 'javascript:toggler("' + id + '");');
    var child = toggler.firstChild;
    toggler.removeChild(child);
    toggle.appendChild(child);
    toggler.insertBefore(toggle, toggler.firstChild);
}

function toggleInit()
{
    var togglerElems = new Array();
    var toggleGroup = new Array();

    // initialize/clear any old information
    togglers = new Array();     
    allClasses = new Object();
        
    // make list of all document classes
    var elems = document.getElementsByTagName("*");
    var numelems = elems.length;
    for (var i = 0; i < elems.length; i++)
    {
        var elem = elems[i];
        if (!elem.className)
            continue;

        elem._toggle_original_display = elem.style.display;
        var togglerID = -1;
        var elemClasses = elem.className.split(' '); // get list of classes
        for (var j = 0; j < elemClasses.length; j++)
        {
            var elemClass = elemClasses[j];
            if (! allClasses[elemClass])
                allClasses[elemClass] = new Array();
            allClasses[elemClass].push(elem);

            // all the special classes begin with _toggle
            if (elemClass.substring(0, 7) != "_toggle")
                continue;

            if (elemClass == "_togglegroup")
                toggleGroup = new Array();
            else if (elemClass == "_toggle")
                toggleGroup.push(elem);
            else if (elemClass.substring(0, 12) == "_toggle_init")
            {
                // set initial value for display (ignore the original CSS set value)
                // understands _toggle_initshow and _toggle_inithide
                var disp = elemClass.substring(12);
                if (disp == "show")
                    elem.style.display = '';
                else if (disp == "hide")
                    elem.style.display = 'none';
                elem._toggle_original_display = disp;
            }
            else if (elemClass.substring(0, 8) == "_toggler")
            {
                if (togglerID == -1)
                {
                    togglerID = togglers.length;
                    togglers[togglerID] = new Array();
                    togglerElems[togglerID] = elem;
                }

                // all classes are of form _toggler_op-CLASS
                // figure out what class we're toggling
                // if none is specified, then we use the current toggle group
                var toBeToggled;
                var hyphen = elemClass.indexOf('-');
                if (hyphen != -1)
                    toBeToggled = elemClass.substring(hyphen+1);
                else
                {
                    toBeToggled = toggleGroup;
                    hyphen = elemClass.length;
                }

                var op = elemClass.substring(8, hyphen);
                togglers[togglerID].push(new Array(op, toBeToggled));
            }
        }
    }

    // add javascript links to all toggler elements
    for (var i = 0; i < togglerElems.length; i++)
        createTogglerLink(togglerElems[i], i);
}

addOnloadHook(toggleInit);

(nicht signierter Beitrag von Juser51 (Diskussion | Beiträge) 22:14, 15. Mär. 2011)

Nun, warum sollte man die Vorlage:Verstecken nutzen wollen? Was bewirkt sie? SteMicha 23:17, 15. Mär. 2011 (CET)

Kurze Antwort: Wenn etwas so irrelevant ist, dass es versteckt werden muss, dann sollte es lieber gleich ganz gelöscht werden. Gelegentlich wird hier in der Wikipedia die Klapp-Funktionalität der Navigationsleisten für andere Dinge missbraucht, im Allgemeinen wird eine solche Praxis in einer Enzyklopädie aber missbilligt. Deshalb gibt es hier in der deutschsprachigen Wikipedia keine offizielle Möglichkeit zum Ein- und Ausklappen von beliebigen Artikelabschnitten. --TMg 23:39, 15. Mär. 2011 (CET)

Tipp: Benutzer Diskussion:TMg/showInfoboxToggle.js. --TMg 23:40, 15. Mär. 2011 (CET)

Hat sich durch Einführung von class="mw-collapsible mw-collapsed" erledigt, unabhängig davon ob das sinnvoll ist oder nicht.

Archivierung dieses Abschnittes wurde gewünscht von: Mps 01:55, 22. Jan. 2012 (CET)

interwiki-completelist

Derzeit steht folgender Code in der MediaWiki:Common.js:

//==============================================================================
//*** Fügt einen Link "Alle Sprachen" auf der Hauptseite unter die Sprachverweise hinzu
// only on the main page
if(mw.config.get( 'wgIsMainPage' )){
jQuery( document ).ready(function() {
    try {
        var completelist = mw.util.addPortletLink("p-lang", "//de.wikipedia.org/wiki/Wikipedia:Sprachen", "Alle Sprachen", "interwiki-completelist", "Alle Sprachen");
        completelist.className='interwiki-completelist';
    } catch(e) {
        // lets just ignore what's happened
    }
});
}

Die zusätzliche CSS-Klasse .interwiki-completelist ist redundant zu der bereits vergebenen ID #interwiki-completelist und kann meiner Meinung nach entfallen. Der einzige Nutzer von interwiki-completelist ist anscheinend Benutzer:Odder/vector.css (Volltextsuche) und dort wird bereits die ID als Selector verwendet.

Außerdem sollte mw.util.wikiGetlink() verwendet werden, wie Der Umherirrende bereits vorgeschlagen hatte: MediaWiki Diskussion:Common.js/Archiv#"Alle Sprachen" auf der Hauptseite und https.

Wenn die Klassendeklaration entfällt kann auch der try-catch-Block entfallen. Unter Anwendung der mw:Manual:Coding conventions/JavaScript ergibt sich damit folgende vereinfachte Anweisung:

//==============================================================================
//*** Fügt einen Link "[[Wikipedia:Sprachen|Alle Sprachen]]" auf der Hauptseite unter die Sprachverweise hinzu
// only on the main page
if ( mw.config.get( 'wgIsMainPage' ) ) {
	jQuery( document ).ready( function () {
		mw.util.addPortletLink(
			'p-lang',
			mw.util.wikiGetlink( 'Wikipedia:Sprachen' ),
			'Alle Sprachen',
			'interwiki-completelist',
			'Alle Sprachen von Wikipedia'
		);
	} );
}

--Fomafix 17:21, 29. Jan. 2012 (CET)

Es fehlt nur noch die explizite Abhängigkeit zu mediawiki.util, würde ich sagen. Der Umherirrende 17:53, 29. Jan. 2012 (CET)

Richtig. Was da genau in Zukunft notwendig sein wird weiß ich nicht. Vielleicht wird in Zukunft jQuery.ready und die Abhängigkeiten zu einer MediaWiki-Funktion zusammengefasst. --Fomafix 19:23, 29. Jan. 2012 (CET)

Mit rev:110254 scheint die Abhängigkeit zu mediawiki.util zunächst mal automatisch erfüllt zu sein. --Fomafix 22:24, 29. Jan. 2012 (CET)

Ja, das hatte ich auch schon gesehen. Aber ich bin mir nicht sicher, ob man deshalb auf die Abhängigkeit verzichten sollte oder ob es nicht sauberer/ordentlicher ist, wenn man es doch angibt. Ob das aktiviert wird, weiß man ja auch noch nicht. Der Umherirrende 19:52, 30. Jan. 2012 (CET)

Mal schauen, wie sich das alles weiterentwickelt. Auch beim Thema Internationalisierung werden Abhängigkeiten benötigt. Bei Gadgets werden die Abhängigkeiten extern deklariert und können daher auch serverseitig verarbeitet werden. Ich habe daher das Gefühl, dass irgendwann die Common.js auch nur ein Gadget ist. --Fomafix 20:19, 30. Jan. 2012 (CET)

• Wenn man sowieso am Programmieren ist und es schon gerade bemerkt, sollte man die Abhängigkeit auch gleich sauber umsetzen.
• mw.loader.using() schaut einmal nach, ob "mediawiki.util" auf der Liste steht; ja, kennen wir – weiter geht’s.
• Es reicht nicht, dass es im Januar 2012 zufällig auch so funktioniert, im April dann wieder nicht bei manchen Browsern, im September dann wieder, 2013 dann gar nicht mehr. Da kann man nicht jedes Mal die Beschwerden auf FZW einfangen, dann versuchen, die Situation zu rekonstruieren, dann debuggen und dann herumwursteln.
• Ich habe mitnichten den Eindruck gewonnen, dass es zukünftig nur noch Gadgets geben solle, und kann aus mw:Extension:Gadgets auch nicht ansatzweise etwas derartiges herauslesen. Es geht um gekapselte, in ihren Abhängigkeiten sauber deklarierte Schnipsel von JS-Code, die ggf. auch Internationalisierung über Systemnachrichten ermöglichen. Das kann auf vielerlei Arten eingebunden sein (wenn extern und zwischen mehreren Projekten geteilt, dann ggf. auch mit mw.loader.implement()) und hat erstmal rein gar nix mit Gadgets zu tun. Wenn Allerwelts-Benutzer eine sinnvolle Wahlmöglichkeit bekommen sollen, einen solchen Schnipsel hinzuzufügen (oder in seltenen Fällen abzuwählen), dann und nur dann wäre dies ein Fall für die Gadgets-definition.

VG --PerfektesChaos 21:55, 30. Jan. 2012 (CET)

Ja, es soll wohl mal globale Gadgets geben (Bug 20153). Wird aber wohl erst mit dem ResourceLoader2 kommen (können). Dann wird das lokalisieren über Systemnachrichten wohl auch möglich sein, da das "Paket" ja Serverseitig geschnürt wird und man dort auch direkt die Nachrichten in der entsprechenden Sprache (mit Fallbacks) holen kann. Das ersetzen von Parametern kann ja bereits jetzt Clientseitig erfolgen und stellt wohl kein Problem mehr da. Der Umherirrende 22:04, 30. Jan. 2012 (CET)

Mhm, dies kenne ich. Das wäre etwas für den Fall, dass man den Quellcode für MediaWiki:Gadget-WikiMiniAtlas.js unmittelbar aus meta: einbinden will, statt über die momentane Zwischen-Krücke gehen zu müssen. Dies betrifft aber nur solche Code-Sequenzen, die zwischen mehreren (vielen) Projekten geteilt werden sollen und bei denen jeder Benutzer eine Auswahlmöglichkeit bekommen soll. Schönen Abend --PerfektesChaos 22:42, 30. Jan. 2012 (CET)

Ich habe mich jetzt für using entschieden, weil es einfach sicherer ist und somit weniger Probleme in der Zukunft geben sollte. Ist somit erledigt. Der Umherirrende 19:02, 12. Feb. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 19:02, 12. Feb. 2012 (CET)

Abhängigkeit von mw.util

Mit 1.19 wird der Resourceloader angeblich so schnell sein, dass alle Abhängigkeiten von anderen Modulen, selbst von solchen, die automatisch geladen werden, explizit angegeben werden müssen. Dazu sollte schon jetzt der gesamte Code in ein

mw.loader.using('mediawiki.util', function () {
//...
});

eingepackt werden. Alle Variablen und Funktionen, die global sein sollten, müssen dann explizit als Eigenschaften von window deklariert werden, also window.tableSorterCollation={'Ä':'A', 'Ö':'O', 'Ü':'U', 'ä':'a', 'ö':'o', 'ü':'u', 'ß':'ss'};. Und wenn man bei der Gelegenheit die seit etlichen Jahren veraltete Funktion includePage rauswirft, wäre das in meinen Augen auch kein Fehler (aber das sehen andere sicher anders). --Schnark 11:21, 17. Jan. 2012 (CET)

Auf translatewiki ist das ganze ja schon aktiv und da bekomme ich häufiger den Fehler das "util" nicht definiert ist. Also scheint mir der Hinweis hier sinnvoll zur Umsetzung zu sein. Der Umherirrende 21:01, 17. Jan. 2012 (CET)

Wobei dazu zusagen ist, das eventuelle $( … ) bestehen bleiben müssen, weil ansonsten eventuell das util-Object noch nicht fertig initialisiert ist (vorallem $content). Bei Gadgets ergibt sich das meistens automatisch, aber hier in der Common.js eventuell nicht. Der Umherirrende 20:31, 19. Jan. 2012 (CET)

Siehe auch bugzilla:33711 und [9], letzteres beweist, dass Javascriptfehler auftreten werden, wenn hier niemand rechtzeitig etwas macht. --Schnark 09:59, 21. Jan. 2012 (CET)

Ausreichend? --32X 00:03, 22. Jan. 2012 (CET)

Ihr habt da gerade Murks gebaut.

var window.tableSorterCollation geht gar nicht.

var window versucht, das window-Objekt des Browsers wegzuwerfen und mit etwas anderem zu überschreiben.

var objekt.komponente ginge ohnehin nie.

--PerfektesChaos 00:41, 22. Jan. 2012 (CET)

Und „schließende Klammer vom Skriptanfang“ ist ja lieb gemeint, aber da müsste schon auch erwähnt werden: mw.loader.using('mediawiki.util', function () { – um zweifelsfrei zu identifizieren, wozu diese Klmmer gehört. --PerfektesChaos 00:44, 22. Jan. 2012 (CET)

Und Schnark hat oben ja auch nix von var geschrieben.

Das window-Objekt ist schon da, das muss man nicht hinter dem globalen scope eines neuen window verstecken.

--PerfektesChaos 00:50, 22. Jan. 2012 (CET)

HALLO???

Falls ihr es noch nicht bemerkt habt: Die Skriptausführung der gesamten deutschsprachigen Wikipedia CRASHt an dieser Stelle.

Entweder fixen oder einfach REVERT.

--PerfektesChaos 00:57, 22. Jan. 2012 (CET)

hab's zurückgesetzt. -- ∂ 01:03, 22. Jan. 2012 (CET)

Es ist nicht empfehlenswert, einfach die gesamte Seite in eine 547 Zeilen umfassende Klammer einzuschließen und sich die Mühe einer differenzierten Betrachtung zu sparen. Der historisch gewachsene Code wird dadurch nicht sicherer und robuster, und erforderlich ist es auch nicht. Tatsächlich wird das using nur in einem einzigen Statement (mw.util.addCSS('.noscript...) benötigt. Alles andere sind deklarative Anweisungen oder Funktionen, die erst mit document.ready ausgeführt werden, und die zurzeit überhaut kein mw.util verwenden – falls doch eines Tages, dann sollte das jede Aktion individuell in ihrem eigenen scope explizit regeln. Nur so kommt man aus dem Dschungel undurchschaubarer Abhängigkeiten. Näheres im folgenden Abschnitt.

VG --PerfektesChaos 09:05, 22. Jan. 2012 (CET)

Nein, es gibt 4 Verwendungen von util, neben addCss, zweimal addPortletLink und einmal $content. Seit rev:109680 ist das Problem aber auch nicht mehr so akut, da wikibits.js aktuell immer geladen wird und somit auch immer util. Sauber ist es aber nicht und es sollte nicht drauf vertraut werden. Wäre diese Änderung richtig? Der Umherirrende 10:54, 22. Jan. 2012 (CET)

Das habe ich jetzt zwar nicht ausprobiert, aber es ist exakt die richtige Strategie: Jeder dieser inhaltlichen Blöcke mit document.ready sollte in sich unabhängig sein, und wenn dieser eine spezifische Block von irgendetwas Externem abhängt, dann sollte genau dieser Block explizit von genau dem abhängig gemacht werden, von dem er abhängt. Ich hatte erstmal nur nach dem geguckt, was im global scope von mw.util abhängt. Wenn erst einmal document.ready eingetreten ist, dann ist nach derzeitiger Lage mw.util auch schon eingetroffen. Die akute Problematik besteht in dem, was im global scope bereits im HEAD geladen ausgeführt wird, und wo mw.util in der Tat vielleicht noch nicht da ist. Schönen Rest-Sonntag --PerfektesChaos 14:17, 22. Jan. 2012 (CET) +Präzisierung --PerfektesChaos 17:23, 22. Jan. 2012 (CET)

Ich bin immer noch für einen großen using-Block um alles herum, nur eben ohne das var vor dem window.x. Globale Funktionen müssen übrigens mit window.f = function(){}; deklariert werden. Außerdem reicht das für die zuverlässige Nutzung von $content noch nicht, siehe oben verlinkten Bug (aber da sollte man noch etwas abwarten). --Schnark 09:24, 23. Jan. 2012 (CET)

Durch eine Softwareänderung ist das Problem wohl nicht mehr akut, unschön ist es trotzdem. --Schnark 09:25, 25. Jan. 2012 (CET)

Ich habe aber trotzdem die fehlenden Abhängigkeiten ergänzt. Dann sind wir auf der sicheren Seite. Der Umherirrende 21:32, 17. Feb. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 21:32, 17. Feb. 2012 (CET)

Bearbeitenlink für Commonslink

Auf Bildseiten, die lokal vor neuanlage geschützt sind, bekommt das Skript einen Fehler. Beispiel File:Flag of Germany.svg. Hier muss eine andere id abgefragt werden (ca-viewsource). Zusäzlich könne man den Text "Quelltext betrachten" auch noch umändert. Für beide Links sollte aber der Tooltip (title=) noch angepasst werden, damit sich der Benutzer nicht wundert, warum er beim Klick auf Bearbeiten auf Commons landet. Danke. Der Umherirrende 16:22, 3. Aug. 2009 (CEST)

hab erstmal den scriptfehler umgangen, ich schau mir das später nochmal an. -- ∂ 18:38, 3. Aug. 2009 (CEST)

Danke schonmal. Möchtest du noch mehr Ändern? Ansonsten setz einfach den Erledigt-Baustein. Mich stört es nicht weiter. Der Umherirrende 16:37, 14. Aug. 2009 (CEST)

hast du 'nen guten vorschlag, wie man die links belabeln könnte? "bearbeiten" gefällt mir z.b. nicht besonders, denn womöglich ist die commons-seite ja gesperrt.. tooltips kann ich auch noch ändern, was würdest du da reinschreiben? -- ∂ 17:33, 14. Aug. 2009 (CEST)

Ein guter Vorschlag fällt mir auch nicht ein. Die Commonsseite kann natürlich gesperrt sein, genauso, wie die Diskussionsseite schon vorhanden sein kann. Bem Tooltip würde ich auf jeden Fall einen Hinweis geben, das man auf Commons landet, den das ist ja das verwirrende für den normalen Benutzer. Man kann auch dazu schreiben, das es dort mehr Sinn macht, als lokal, da dort mehr Personen das ganze beachten. Der Umherirrende 18:39, 14. Aug. 2009 (CEST)

Diese Funktionalitaet ist ohne weitere Aenderung des linktextes eirsteinmal "ueberraschend". Und "ueberraschend" heist wenn es um usability geht "schlecht". Ich musste in mehrere Bildbeschreibungsseiten das ExzelentesBild template einfuegen, was durch dieses Script erschwert wurde. Jedem kann mans natuerlich nicht recht machen, aber man sollte den user irgendwie vorwarnen. --Dschwen 20:15, 14. Aug. 2009 (CEST)

ich bin nicht wirklich überzeugt, daß wir die links überhaupt ersatzlos umbiegen sollten. die lokalen seiten existieren nun mal, und da erwarte ich eigentlich, daß die tabs so funktionieren wie bei allen anderen seiten auch. vielleicht läßt sich eine bessere lösung finden, den normalnutzer auf die commons-seiten zu schicken? -- ∂ 13:30, 15. Aug. 2009 (CEST)

Das ganze scheint sich in den letzten Jahren bewährt zu haben, da kein weiterer Ärger darüber vornommen wurde. Daher mal auf erledigt gesetzt. Der Umherirrende 23:55, 24. Feb. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 23:55, 24. Feb. 2012 (CET)

Darstellung von Unicode etc. auf IE ohne Beeinträchtigung standardkonformer Browser

Ein Fehler von Internet Explorer verunmöglicht die Auswahl korrekter Schriftarten. Die derzeitige Behelfslösung besteht in der Verwendung von Vorlagen wie Vorlage:Unicode, die bestimmte in MediaWiki:Common.css definierte CSS-Klassen für Schriftarten auswählen. Beispielsweise ergibt der Wiki-Code {{Unicode|hello world}} die folgende Darstellung: hello world

Das Problem dabei ist, dass diese Internet-Explorer-Behelfslösung standardkonforme Browser beeinträchtigt. Das sollte auf keinen Fall passieren. Ursprünglich war dies auch nicht der Fall, denn ursprünglich verwendete Common.css einen Internet-Explorer-Hack, der eine unbeeinträchtigte Darstellung auf standardkonformen Browsern gewährleistete. Unmittelbar auf die Internet-Explorer-spezifische Definition der Schriftart folgte eine zweite Definition font-family /**/: inherit;. Diese zweite Definition stellte auf standardkonformen Browsern wieder eine unbeeinträchtigte Darstellung her, wurde aber von Internet Explorer ignoriert.

Dann trat der schlimmste Fall ein: Mit IE7 korrigierte Microsoft die Interpretation von font-family /**/: inherit;, ohne das ursprüngliche Problem zu beheben. In der Folge wurde die zweite Definition aus Common.css gelöscht.[10] Seither beeinträchtigt die Internet-Explorer-spezifische Behelfslösung eine korrekte Darstellung auf standardkonformen Browsern.

Auf der englischen Wikipedia ist eine Lösung für dieses Problem gefunden worden. Dort wurde das Common.js um speziellen Code für den Internet Explorer erweitert, damit Text in den betreffenden CSS-Klassen korrekt dargestellt wird.[11]

Um eine korrekte Darstellung sowohl auf den verschiedenen IE-Versionen zu gewährleisten, ohne dabei die Darstellung auf standardkonformen Browsern zu beeinträchtigen, müsste einerseits in Common.css der alte IE6-Hack wiederhergestellt werden. Das habe ich beantragt unter MediaWiki Diskussion:Common.css#font-family /**/: inherit;. Andererseits müsste, wenn ich das richtig verstehe, folgender Code zu Common.js hinzugefügt werden:

if (navigator.appName == "Microsoft Internet Explorer")
{
   /**
    * Behelfslösung für eine korrekte Schriftauswahl unter MSIE7, ohne die Darstellung in standardkonformen Browsern zu stören.
    */
   if (document.createStyleSheet) {
       document.createStyleSheet().addRule('.Unicode', 'font-family: "Code2000","Sun-ExtA","Arial Unicode MS","NSimSun",sans-serif;');
       document.createStyleSheet().addRule('.Unicode1', 'font-family: "Code2001","Quivira","MPH 2B Damase",sans-serif;');
       document.createStyleSheet().addRule('.Unicode2', 'font-family: "Sun-ExtB","Code2002",sans-serif;');
       document.createStyleSheet().addRule('.IPA', 'font-family: "Quivira","Code2000","Sun-ExtA","DejaVu Sans","Gentium","Arial Unicode MS","Lucida Sans Unicode",sans-serif;');
       document.createStyleSheet().addRule('.IAST', 'font-family: "Code2000","SunExtA","Arial Unicode MS",sans-serif;');
       document.createStyleSheet().addRule('.altitalisch', 'font-family: "Quivira","Code2001","MPH 2B Damase",sans-serif;');
       document.createStyleSheet().addRule('.gotisch', 'font-family: "Quivira","Code2001","MPH 2B Damase",sans-serif;');
       document.createStyleSheet().addRule('.hebrew', 'font-family: "Quivira","Sun-ExtA","Arial Unicode MS","SBL Hebrew","Code2000","MPH 2B Damase",  sans-serif;');
       document.createStyleSheet().addRule('.spanAr', 'font-family: "Arial Unicode MS","Scheherazade","Code2000","DejaVu Sans",sans-serif;');
       document.createStyleSheet().addRule('.music-symbol', 'font-family: "Musical Symbols","Euterpe","Code2001",sans-serif;');
   }
}

Das ist gewiss ein hässlicher Hack. In einer idealen Welt hätte so etwas keinen Platz. Es ist aber auf alle Fälle der jetzigen Situation vorzuziehen, wo eine Behelfslösung für den Internet Explorer die Darstellung auf standardkonformen Browsern beeinträchtigt. -- machᵗᵃˡᵏ 13:23, 1. Feb. 2010 (CET)

In MediaWiki:Common.css gibt es inzwischen eine IE6 und IE7 kompatible Browserweiche für Schriftarten. Eine JavaScript-basierte Lösung ist nicht mehr notwendig. --Fomafix 12:18, 26. Feb. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 12:18, 26. Feb. 2012 (CET)

Sortierschlüssel bei Tabellensortierung

Ich habe eine neue Version der Vorlage:SortKey geschrieben, die in sortierbaren Tabellen verwendet wird (die bisherige Version benutzt ein unschönes, per CSS "verstecktes" <Span>-tag). Allerdings ist dafür eine Änderung des Sortiercodes nötig; eine der Funkionen aus wikibits.js muss überschrieben werden. Der nötige JS-Code und ein Beispiel sind auf Benutzer:Dapete/SortKey/Beispiel zu finden. Bei der Diskussion in der Vorlagenwerkstatt kamen keine Einwände. Falls irgendwas unklar ist, bitte melden. --Dapeteおい 17:24, 20. Mär. 2008 (CET)

Ist das noch aktuell? --Leyo 18:58, 22. Apr. 2010 (CEST)

Der Optik nach schon.... aber wollen wir wirklich eine Funktion von wikibits lokal überschreiben? --Guandalug 10:38, 15. Aug. 2010 (CEST)

Der Tablesorter wurde mit MediaWiki 1.19 mächtig umgeschrieben, ich denke mal das Skript von Dapete wird daher nicht mehr so ganz funktionieren oder die Funktionalität ist bereits vorhanden. Falls nicht, einfach wieder (einen neuen Abschnitt) aufmachen. Der Umherirrende 21:46, 4. Apr. 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 21:46, 4. Apr. 2012 (CEST)

Vorschau-Schaltfläche ausblenden?

Nach dieser Diskussion auf WP:GVA hatte ich die verrückte Idee, auf WP:GVA die Vorschauschaltfläche per common.js auszublenden, damit „Neulinge nicht verwirrt werden“, indem sie gezwungen werden, nach der Vorschau eine Zusammenfassung geben zu müssen. Wie sieht es sonst technisch aus, kann man die Aufforderung zur Angabe einer Zusammenfassung bei der Vorschau für eine Seite abschalten, oder muss man dazu den MediaWiki-Code ändern? Gibt es noch andere Lösungsmöglichkeiten? Meinungen? – Giftpflanze 00:34, 14. Jul. 2010 (CEST) Per MediaWiki:common.css als body.page-Wikipedia_Gesichtete_Versionen_Anfragen input#wpPreview {display:none} realisierbar. – Giftpflanze 20:11, 16. Jul. 2010 (CEST)

Es ist Bug 17615, das die Betreffzeile überhaupt in der Vorschau erscheint. Man könnte den Bug lokal mit javascript lösen:

/**
 * [[bugzilla:17615]] - put nosummary back, if set
 */
addOnloadHook(function() {
 //test, if the url contains a nosummary=1
 if( (/(?:&|\?)nosummary=1(?:&|$)/i).test( document.URL ) ) {
  var editform = document.getElementById( 'editform' );
  if( editform ) {
   //Create the hidden input field inside the form
   var nosummary = document.createElement( 'input' );
   nosummary.name = 'nosummary';
   nosummary.value = '1';
   nosummary.type = 'hidden';
   editform.appendChild( nosummary );
  }
 }
});

Getestet mit IE8. Sehr unschön, das lokal zu lösen, alternativ kümmert sich ein Entwickler um den Bug. Der Umherirrende 20:24, 16. Jul. 2010 (CEST)

Bug ist FIXED, habe mich selber drum gekümmert. Kommt mit dem nächsten großen Software-Update. Der Umherirrende 21:43, 4. Apr. 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 21:43, 4. Apr. 2012 (CEST)

MediaWiki:Common.js/relative.js

In Anlehnung an MediaWiki:Common.js/secure.js möchte ich vorschlagen, ein JavaScript-Skript in der deutschsprachigen Wikipedia zu nutzen, welches absolute URLs auf Schwesterprojekte in relative URLs verändert, welche der Browser dann gegen das aktuelle Protokoll auflösen kann und somit kommt der Benutzer immer auf das für ihn passende Protokoll. Nicht alle Links in der deutschsprachigen Wikipedia sind mithilfe von Vorlagen oder Interwikis gemacht, sondern sind absolute URLs im Wikitext. Damit diese URLs auf das jeweils aktuelle Protokoll verweisen, sollte ein solches JavaScript-Skript eingesetzt werden. Als Plus könnte das JavaScript-Skript die alte https-Adresse auch zu einer relativen URL machen. Vielen Dank. Der Umherirrende 19:50, 13. Okt. 2011 (CEST)

Hört sich sinnvoll an. Mehr wollte ich nicht sagen. ;-) Viele Grüße --Saibo (Δ) 22:50, 16. Okt. 2011 (CEST)

will man wirklich auf jeder seite bei jedem laden sämliche links durchflöhen, nur weil einige links absolut sind? klingt mir erstmal nach einer ziemlichen resourcenverschwendung. wie viele und welche links betrifft das denn überhaupt, und wieviele davon sind nicht anders änderbar? -- ∂ 23:24, 16. Okt. 2011 (CEST)

Na, so viel Aufwand wäre das auch wieder nicht. Man beschränke sich auf nicht-ANR und nicht-Spezialseiten (oder gleich nur auf Diskussionsseiten?) und schaue alle Links im $content mal durch. Geändert werden müssen davon meist wenige, aber bei denen lohnt es. Vorschlag:

// Skript von [[Benutzer:✓]], das protokollabsolute Links auf Wikimedia-Projekte in -relative ändert
if (window.relativeProtocols === false || mw.config.get('wgNamespaceNumber') > 0) // nicht im ANR oder auf Spezialseiten
    $(function makeProtocolsRelative() {
        // zuverlässig mit beiden Protokollen verhaltensgleich funktionierende Domains
        var reg = new RegExp("^https?\\:\\/\\/(" + [
            // (download|.*?mobile|.*?m|mail) funktionieren nicht oder unterschiedlich
            "(?!download|[^/#?]*?mobile|[^/#?]*?m|mail).*?\\.?wik(ipedia|tionary|ibooks|iquote|iversity|isource|inews|imediafoundation)\\.org",
            // (dumps|downloads|stats|noc|ganglia|[^/]*?planet|mail) funktionieren nicht oder unterschiedlich
            // ticket und bugzilla leiten eh nur auf https weiter, donate auf http://wikimediafoundation.org
            // das wäre nur lang und umständlich: "(lists|upload|techblog|blog|wikitech|svn|commons|incubator|.+?\\.labs|nyc|species|advisory|ar|bd|br|co|dk|et|fi|il|mk|mx|nl|no|nc|pa\\.us|pl|pt|rs|ru|se|tr|ua|uk|ve|board|boardgovcom|noboard\\.chapters|auditcom|chair|chapcom|checkuser|steward|collab|exec|grants|internal|movementroles|office|searchcom|spcom|otrs-wiki|quality|meta|outreach|volunteer|strategy|usability|survey|wikimania.*?)\\.wikimedia",
            "(?!secure|dumps|downloads|stats|noc|ganglia|[^/#?]*?planet|mail|ticket|bugzilla|donate).*?\\.?wikimedia\\.org",
            "www\\.mediawiki\\.org",
            // wiki.toolserver leitet eh nur auf https weiter
            "toolserver\\.org",
            "wikimedia\\.ch",
            "wikimedia\\.at"
        ].join("|") + ")");
        mw.util.$content.find("a").each( function(index, link) {
            var href = link.getAttribute('href');
            if (!href || href.substring(0, 4) != "http")
                return;
            if (href.search(reg) == 0) {
                link.setAttribute('href', href.substr(href.substr(4,1)=="s" ? 6 : 5));
                return;
            }
            var parts = href.match(/^https\:\/\/secure\.wikimedia\.org\/(.+?)\/(.+?)\/(.*)/);
            if (!parts || parts.length<3)
                return;
            var projekt = parts[1],
                version = parts[2];
            if (projekt != "wikipedia") {
                if (projekt.substring(0, 6) == "skins-") // funktioniert eh nicht mehr, die "Korrektur" aber ist tödlich
                    return;
                href = "//"+version+"."+projekt+".org";
            } else {
                switch (version) {
                    case "foundation": href = "//wikimediafoundation.org"; break;
                    case "sources":    href = "//wikisource.org"; break;
                    case "mediawiki":  href = "//www.mediawiki.org"; break;
                    case "species":
                    case "meta":
                    case "commons":
                    case "incubator":  projekt = "wikimedia"; //no break
                    default: href = "//"+version+"."+projekt+".org";
                }
            }
            link.setAttribute('href', href+"/"+parts[3]);
        });
    });

Das ist zwar ein fetter Rundumschlag und ist auch auf Varianten ausgelegt, die laut Spezial:Weblinksuche/https://secure.wikimedia.org gar nicht vorkommen, deckt aber wirklich alles mögliche ab. Und ist dabei ziemlich schnell. Könnte m.M.n. sogar /secure.js vollständig ersetzen.
meint -- ✓ ^Bergi 01:48, 17. Okt. 2011 (CEST)

Man könnte es auch nur als (Default?-) Gadget anbieten. Oder nur dann aktivieren, wenn jemand auf https unterwegs ist. Hmm.. --Saibo (Δ) 02:00, 17. Okt. 2011 (CEST)

Da secure.js bei jedem Aufruf läuft und anscheind keinen nennenswerten Performance-Einbruch gab, sehe ich kein Problem. Es hilft solche Verwirrungen zu vermeiden. Ich würde es aber in jedem Namensraum laufen lassen. secure.js hatte einen Ausstieg am Anfang, den kann man gerne auch hier einbauen. Ich habe mir erlaubt, im Beispielquelltext einige Klammern und etwas space zu ergänzen. Der Umherirrende 19:43, 17. Okt. 2011 (CEST)

Bei jedem Aufruf? if(wgServer == 'https://secure.wikimedia.org') importScript( 'MediaWiki:Common.js/secure.js'); sagt mir was anderes :-)

Während es für https-Besucher wichtig war auf secure zu bleiben, werden einige der "normalen" Besucher (die in der Überzahl sind) das Relativieren sicher als unnötig, unnütz oder gar als verfälschend sehen. Daher habe ich einen Opt-out eingebaut. Im ANR kann man zusätzliche Performancebedenken abweisen, das Überprüfen von komplexen regulären Ausdrücken dauert (gerade auf älteren Maschinen) doch seine Zeit. Bei vielen Einzelnachweisen kann sich eine ganz schöne Zahl an mit "http" beginnenden Links anhäufen, das würde ich nicht vernachlässigen. Zudem sollten im ANR eh keine Hartlinks auf Wikimediaprojekte vorkommen, und wenn sollten sie es auch bleiben dürfen (Wenn ich im Artikel Wikipedia auf http://wikipedia.org klicke, will ich nicht bei https rauskommen). Auf Spezialseiten dasselbe: Links auf Wikimediaprojekte werden entweder soft generiert, oder sie sind berechtigt (z.B. in der Spezial:Weblinksuche).

Habe das Skript nochmal korrigiert. Es gibt einige Subdomains auf wikimedia.org, die beide Protokolle nicht gleich behandeln. Die vorherige Version, alles zu erlauben und dann einige blackzulisten hat mit secure.wikimedia.org nicht funktioniert, für whitelisting sinds zu viele, daher jetzt negative lookahead. -- ✓ ^Bergi 19:17, 18. Okt. 2011 (CEST)

Ich meinte natürlich, das es bei jedem Aufruf über https genutzt wurde, ansonsten macht das Skript ja auch keinen Sinn. Du magst Space nicht so gerne, sehe ich gerade ;-), geht eh durch den minifiy, da braucht man sich das nicht sparen, aber das ist Programmierstil und Gewohnheitssache. Ich hatte erst gesucht, warum du 3 Gruppen im RegEx bildest und erst später gesehen, das es unten nochmal genutzt wird, daher hatte ich das nach oben gezogen, damit man direkt sieht, das 3 Gruppen notwendig sind. Ich weiß nicht, ob Gruppen im search auch backreferences bilden und dann unnötigerweise die Substrings gespeichert werden, sonst könnte man das noch ändern.

Bei Spezialseiten kann ich deine Argumentation folgen. Hartlinks auf Wikimediaprojekte im Artikelnamensraum gibt es sicher einige, vermutlich aus Unwissenheit über die anderen Möglichkeiten. Der Umherirrende 20:06, 18. Okt. 2011 (CEST)

Da ist auch noch ein Fehler in deinem Regex. Der Link in Wikipedia:Fragen_zur_Wikipedia#Krieger ändert sich nicht, weil der Regex auf das namespace=0 in der URL matcht. Der Umherirrende 12:11, 6. Nov. 2011 (CET)

Danke für den Hinweis, jetzt sollte es wieder gehen. -- ✓ ^Bergi 14:28, 6. Nov. 2011 (CET)

Könnte aber mit planet genauso passieren, oder? Ich habe es so gelöst gehabt. Der Umherirrende 15:14, 6. Nov. 2011 (CET)

Klar, planet hatte ich nur vergessen hier zu ändern. Deine Lösung funktioniert aber nicht, auch wenn der Ansatz natürlich richtig und schöner ist: a) hast du die \\ vor dem . vergessen und b) darf auch eben kein / vorkommen, dein Regex matcht beispielsweise http://example.com/redirect=m.wikipedia.org -- ✓ ^Bergi 17:43, 6. Nov. 2011 (CET)

Ein Punkt in einer Zeichenklasse ist immer ein Punkt. Ich habe aber deine Änderung jetzt übernommen, erscheint sinnvoller. Der Umherirrende 18:26, 6. Nov. 2011 (CET)

Wobei es theoretisch auch http://example.com?m.wikipedia.org oder http://example.com#m.wikipedia.org geben könnte, die dann auch bei deinem Regex nicht richtig verarbeitet werden.

Außerdem werden die Links auf wikimedia.ch und wikimedia.de nicht umgestellt, weil danach noch ein .org sein muss. Der Umherirrende 18:52, 6. Nov. 2011 (CET)

Oh, ja. Punkt in Zeichenklasse verwirrt mich immer wieder. Die anderen beiden Punkte hab ich auch noch korrigiert. Wobei solche Links wirklich selten sind… -- ✓ ^Bergi 19:01, 6. Nov. 2011 (CET)

http://wikimedia.de.vu/ könnte es auch geben, was dein Skipt auch noch ändert. Ich finde es übrigens sehr praktisch, vorallem wenn man selber an verschiedenen Rechnern, verschiedene Zugänge nutzt. Der Umherirrende 19:15, 2. Dez. 2011 (CET)

Ich habe die Seite jetzt mal angelegt. Ich würde mich freuen, wenn noch jemand einmal drüber schauen könnte, dann würde ich es die Tage aktivieren. Der Umherirrende 21:54, 10. Apr. 2012 (CEST)

Ich hatte eigentlich eine Direkteinbindung vorgesehen. Insbesondere das einleitende if sollte jetzt aber vor die import-Anweisung statt in das Skript. Und grundverkehrt ist es auch noch, das war wohl mal ein if(relative===false||ns<1)return; - muss natürlich if (mw.config.get('relativeProtocols') !== false && mw.config.get('wgNamespaceNumber') > 0) lauten. Die Namensraumsbeschränkung hat auch ihren Sinn (siehe oben).

Ansonsten verwundert mich dieses [^/?#]*?\\.?. Gibts denn irgendwelche relevanten subdomains, die das benötigen? -- ✓ ^Bergi 01:08, 11. Apr. 2012 (CEST)

Das $(function makeProtocolsRelative() {...}); kommt mir irgendwie merkwürdig vor. Soweit ich weiß, hat das in verschiedenen Browsern verschiedene Auswirkungen (=IE hält sich nicht an den Standard), außerdem ist eine benannte Funktion – zumindest auf diese Weise – überflüssig, $(function() {...}); sollte reichen. --Schnark 12:06, 11. Apr. 2012 (CEST)

Ist beim Callstack-Debuggen äußerst hilfreich, da habe ich mir das angewöhnt (Du bist mit http://kangax.github.com/nfe/ vertraut?). Aber ja, in der Produktivversion sollte das wegen ☠☢☣⚠⚡ Internet Explorer wohl raus. -- ✓ ^Bergi 17:14, 11. Apr. 2012 (CEST)

*reinquetsch* Ich lese immer in der offiziellen Dokumentation nach, verlinkt unter [12] und [13] (linke Spalte unten). --Schnark 09:52, 12. Apr. 2012 (CEST)

If in Common.js verschoben (war aber nur kopiert, ohne Nachdenken), benannte function anonymisiert. Zur Subdomainen: Es gibt das Blog oder wird in Zukunft vielleicht auch noch Seiten geben. Der Umherirrende 18:35, 11. Apr. 2012 (CEST)

@Umherirrender: Kann man gern so machen, aber ist es wirklich Absicht, eine neue globale Variable isSecure einzuführen? Ich versuche gerade, die Dinger loszuwerden.

• Ggf. eine Fallunterscheidung auf secure... vornehmen und innerhalb der Zweige arbeiten, dann kommt man ohne vorab ermittelte isSecure aus.
• Die secure-URL ggf. aus properties von document zu entnehmen wäre hier übrigens einen Tick schneller als mit mw.config.get und dann wgServer – weil dies hier zwangsweise bei allen Lesern ausgeführt.

Beste Grüße --PerfektesChaos 18:35, 11. Apr. 2012 (CEST)

Geht, macht es aber nicht gerade lesbarer. Irgendwie war ich davon ausgegangen, das die Variable innerhalb des {}-Blocks nicht global wird, aber das war wohl nicht. Da die Abfrage auch schon vorher drin war, denke ich mal, das es so in Ordnung ist. Der Umherirrende 18:54, 11. Apr. 2012 (CEST)

• Wir können ja allmählich noch einen Tick besser werden als das früher mal so dagestanden hatte.

if ( window.location.host === 'secure.wikimedia.org' ) {
   // ...
} else if( mw.config.get( 'relativeProtocols', true ) === ... ) {
   // ...
}

ist einige Mikrosekunden schneller; die Zeichenkette ist kürzer, https:// ist in diesem Fall immer gegeben, und der Weg über mw.config lässt sich in einem zeitkritischen Bereich vermeiden. Das } else if stört dann hoffentlich weniger.

• Ja, nach einem Vierteljahrhundert C-Programmierung lege ich mich da auch gern selbst rein (meine Therapie).
• Du bist ja selbst schuld; wenn du nicht von 18:21:55 bis 18:23:21 für 86 Sekunden zwei Schrägstriche vergessen hättest, wäre ich hier nicht so bald aufgeschlagen.

Ich finde trotzdem gut, was du machst. --PerfektesChaos 22:24, 11. Apr. 2012 (CEST)

Danke für das Vertrauen. Nur kurz zu Erklärung: Ich hatte erst das load-statement kopiert, angepasst und auskommentiert und mir dann gedacht, die lange Zeile zu brechen. Dabei habe ich dann den Kommenater vergessen. In der Vorschau war mir der Fehler nicht aufgefallen und aufgrund fehlendem Highlighting (Bug 18227) hat man es dort auch nicht gesehen. Ich denke, das man hier nicht auf mw.config verzichten muss, war schon früher drin und hat keinem gestört. Falls das jemand anders sieht, nur zu. Der Umherirrende 18:49, 12. Apr. 2012 (CEST)

• Nur zur Klarstellung: Das mit den 86 Sekunden war ein Witz. Dir ist ein ganz normaler typo unterlaufen, hast es selbst gemerkt und binnen weniger als anderthalb Minuten gefixt. Das passiert jedem von uns, nur dauert es meist länger, bis es auffällt. SomeTHIng HAPPENS. – Pech war nur, dass grad in dieser Zeit meine Fehlerkonsole neben meinen selbstverursachten Fehlermeldungen und dem Mediwiki-Dauermüll "bannerList is null" mal eine Abwechslung auftauchte; als ich dem neugierig nachging, hattest du es schon wieder gradegerückt gehabt.
  • Wenn du übrigens Syntaxhighlighting und Zeilennummern für JS und CSS gleich beim Bearbeiten magst, kannst du diese Experimentalversion probieren: WP:JS#Code Editor – Ein worker-javascript.js fehlt (der deWP?) noch.
• Ist eigentlich sichergestellt, dass das Benutzerskript zum Zeitpunkt dieses Aufrufs schon beendet wurde und ein mw.config.set('relativeProtocols',true) gemacht hätte? (Siehe dazu hier).
  • mw.config.set() bevölkert derzeit sofort die globalen Variablen; mw.user.options.set() bleibt diskreter.
  • Die Änderungen der URLs sind für den Leser unsichtbar und sollten grundsätzlich erst nach Präsentation der sichtbaren Seite erfolgen. Dann hat er schon mal was zum Lesen und nur seine Maus zeigt ihm noch nicht die hover-Messages an. Ohne document-ready gibt es sowieso keine URL zum Basteln.
  • Ich würde deshalb empfehlen, ganz hinten unterzubringen:

$( function() {
   mw.loader.using( [ 'user', 'mediawiki.user', 'user.options' ],
                    function () {
      if ( window.location.host === 'secure.wikimedia.org' ) {
         if ( ! mw.user.options.get( 'disableSecureLinks', false ) ) {
            // ...
         }
      } else if ( mw.user.options.get( 'relativeProtocols', true ) ) {
         // ...
      }
   } );
} );

Schönen Abend --PerfektesChaos 23:12, 12. Apr. 2012 (CEST)

Heutzutage kann man garnichts mehr garantieren. Da aber site vor user geladen wird, kann site schon längst fertig sein, wenn die config gesetzt wurden und das hat damit kein Effekt. Vermutlich ist es daher einfacher, die config im Skript nach document.ready zu prüfen, weil dann so etwas schon längst (oder zu 99%) fertig ist. Hat aber den Nachteil, das die Skriptseite doch geladen wird, obwohl sie nicht ausgeführt werden müsste. Was man aktuell vermeiden möchte. Bei deinem Beispiel könnte man ready wohl auch weg lassen, weil es in jedem Skript nochmals steht. Da kenne ich mich aber damit zu wenig aus. Ein default-Gadget würde das einfacher machen … Der Umherirrende 23:29, 12. Apr. 2012 (CEST)

Die Konsequenz wäre natürlich, dass die document-ready in den geladenen Skripten entfallen können, und diese sich darauf verlassen können, dass die schon gelaufen sind. Doppelt gemoppelt würde auch nicht viel machen, weil: Ein .using oder $(), bei dem die Bedingung inzwischen schon erfüllt wurde, wird einfach sofort aufgerufen. Das umschließende ready bei mir soll die Beschäftigung mit dem Thema verzögern, bis zusammen mit dem onLoad hoffentlich schon das Rendern beginnt und der Leser was zum Begucken bekommen hat. VG --PerfektesChaos 23:44, 12. Apr. 2012

(du hast schon gemerkt, dass .loader.using('user') das Benutzerskript abwartet?) --PerfektesChaos 23:47, 12. Apr. 2012 (CEST)

Ja, hatte ich gesehen, aber 3 Module abwarten, ist auch irgendwie unübersichtlich. Ich werde das document.ready aber in den Skriptseiten lassen, weil diese dann autark funktionieren und die Abhängigkeiten für die Ausführung des Skriptes dort stehen. In Common.js sind ja nur die Abhängigkeiten für das Laden der Skriptseiten definiert. Klingt erstmal sauber getrennt. Der Umherirrende 10:24, 13. Apr. 2012 (CEST)

Nachfrage: Bist du dir sicher, das es so funktioniert? Bei mir scheint es nicht so zu sein. Der Umherirrende 10:53, 13. Apr. 2012 (CEST)

• Sicher bin ich mir, dass es grundsätzlich funktioniert; ich habe seit über einem Jahr mehrfach auf diesem Feld gepflügt.
• Was im Einzelfall hier das Problem wäre, weiß ich nicht; habe zurzeit auch leider keine Gelegenheit zum Intensiv-Debugging.
• Ein Blick in deine monobook lässt mich das .using("mediawiki.user") vermissen; siehe hier. – Ich hänge dann immer noch user.options dran; damit stehen die Dinger beim push hinten nach den server-seitigen aus dem startup.
• Ansonsten kannst du ja mal mw.user.options.values debuggen. Fehlermeldungen?

Mahlzeit --PerfektesChaos 13:40, 13. Apr. 2012 (CEST)

Debuggen ist sehr interessant. Es ist auf jeden Fall ein Ablaufproblem (zumindestens mit debug=true). Durch das using von user löst dieser noch ein nachladen desselben Modules aus (URL), nur liefert diese URL ein fast leeres Skript, wo nur das ready für user gesetzt wird und nicht das eigentliche Skript. Dadurch wird dann der entsprechende Codestück aus Common.js ausgeführt. Danach aber wird die tatsächlich bereits geladene user.js ausgeführt und die options gesetzt und am Ende nochmals das ready für user gesetzt, aber das hat dann keine Relevanz mehr. Somit würde auch das using für mediawiki.user vermutlich nicht helfen. Da das aber anscheind funktionieren soll, probiere ich das nochmal aus. Einfacher macht es die Sache dadurch aber nicht für den Benutzer, der etwas setzen möchte. Der Umherirrende 16:10, 13. Apr. 2012 (CEST)

Ist auch klar, das es leer ist, weil nicht angegeben ist, für welchen Benutzer das user-Modul geladen werden soll. Stellt sich nur die Frage, warum das überhaupt angefordert wird, obwohl es doch standardmäßig unterwegs ist. Da muss irgendwo die Registrierung fehlen, so dass der ResourceLoader clientseitig weiß, das es auf dem Weg ist. Das ist aber irgendwie schon tief im RL. Der Umherirrende 16:51, 13. Apr. 2012 (CEST)

Interessantes Deadlock.

• Ich gebe zu, dass ich nie von einem site-Skript (mangels Admin-Rechten und beta.-Testing) aus user.options aufgerufen habe.
• Es geht demnach grundsätzlich nicht, im Top-Level eines site-Skript wie diesem hier irgendwelche Benutzereinstellungen, user.options oder sonstwas auszuwerten. (Auch benutzerdefinierte globale Variablen kämen zu spät.)
  • Die Module site und user werden in dieser Reihenfolge aufgeladen, oder günstigstenfalls parallel.
  • Weil user zurzeit wohl nur über ein an die Benutzerskripte angehängtes .state("user","ready") definiert wird, wäre auf Seiten von MW eine Lösung vorstellbar, bei der server-seitig im startup .state("user","loading") vorbelegt wird. Sonst ist die Bedeutung von user beim Laden von site unbekannt und führt zum unbefriedigten Fehler, wenn von .using() angefasst. Mit der Vorbelegung ist dann aber "user" bekannt und "loading" signalisiert dem .using(), dass er sich noch einen Moment gedulden soll. Genauso für "user.options". – Da muss ich aber noch einmal in Ruhe drüber tüfteln.
• deWP-Lösungsmöglichkeiten:
  1. Ohne aufdringlich sein zu wollen: Nicht mit absoluter Sicherheit, aber recht zuverlässig funktionierender workaround wäre der Einschluss des Ganzen in ein document-ready – in der Praxis ist dann immer auch schon das user-Zeugs geladen.
  2. Gadgets, ggf. mit RL2; gäbe dann auch die Optionsmöglichkeit per Kreuzchen.

Immer dazulernend --PerfektesChaos 17:55, 13. Apr. 2012 (CEST)

Definiert ist das user-Module im startup, sonst würde das using einen Fehler schmeißen, aber dort wird es auf "registered" gesetzt, was dem using sagt, er muss es noch laden, wenn es verwendet werden soll. Du hast Recht, das hier "loading" stehen müsste, weil das Module ja über ein eigens Script-Tag geladen wird. Wie ich gerade gesehen habe, haben andere die gleichen Probleme und Gedanken gehabt: Bug 32537, siehe auch Bug 30358. Aktuell scheint es für User-Skripte zu funktionieren, weil dort schon etwas mehr Zeit vergangen ist. Der Umherirrende 20:26, 13. Apr. 2012 (CEST)

Da wir auch den state verändern können, wie wär es mit:

// following modules are loaded with <script> and starts with a wrong state in the resourceloader on the client-side - bug 32537
mw.loader.state( 'site', 'loading' ); //here we are right now
if( mw.loader.getState( 'user' ) === 'registered' ) { mw.loader.state( 'user', 'loading' ); }
if( mw.loader.getState( 'user.groups' ) === 'registered' ) { mw.loader.state( 'user.groups', 'loading' ); }

Am Anfang von Common.js? Dann müsste es doch passen und alles läuft sauber. Der Umherirrende 20:47, 13. Apr. 2012 (CEST)

• "registered" habe ich vorhin auf den ersten Blick in startup noch nicht mal gefunden, ich dachte es wäre undefined.
• Auch "user.options" und alles andere was irgendwann dynamisch in ein Inline-Skript geschrieben wird muss "loading" bekommen.
• Wenn du Lust hast, kannst du ja mal auf beta. ein wenig rumspielen, falls du das noch nicht getan hast. Am Anfang der Common.js mal diesen state auf alle inliner setzen.
• "registered" ist sowieso Käse, denn das bedeutet: Eine statische Ressource über load.php (von //bits.wikimedia.org) sei dort abrufbar, und die würde versucht zu laden, wenn jemand darauf using() anfordert.
• Wenn das Experiment klappt, wäre das wohl einen frischen Bugzilla wert.
• Auf irgendwelche zeitlichen Abläufe bei irgendwelchen Browsern kann man sich nicht mehr verlassen, das ist reines Roulette.

Amüsier dich --PerfektesChaos 23:08, 13. Apr. 2012 (CEST)

• Im Startup wird .register aufgerufen, welches dann "registered" setzt für die Module.
• Bei den Inline-Modulen ist es wohl nicht so kritisch, weil das .implement setzt "loaded" und das sollte alles schnell durch sein.
• Ich habe es gestern noch auf beta. ausprobiert und es funktioniert. Aber ich bin mir noch sicher, ob das auch Nebenwirkungen haben kann.
• Das ist das Problem, die Resource ist ja bereits unterwegs, innerhalb von script-tags und sollte daher nicht nachgeladen werden
• Im Change für Bug 32537 wird ein extra inline-Skript ergänzt, welches die States schon vorher auf "ready" setzt. Scheint mir weniger hilfreich zu sein (weil using dann schon weiter machen würde) und vermutlich noch ein Fehler in der Änderung.
• Ja, im Lotto zu gewinnen erscheint mir auch einfacher ;-)

Der Umherirrende 11:02, 14. Apr. 2012 (CEST)

Ich war jetzt mal mutig und habe den Workaround eingebaut. Falls das Probleme macht, kann er gerne von jedem wieder entfernt werden. Für mich erstmal hier erledigt. Danke für eure Mitarbeit. Der Umherirrende 14:01, 14. Apr. 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 14:01, 14. Apr. 2012 (CEST)

Collapsible tables

Hallo, heute wurde eine größere Anzahl Codezeilen zu collapsible tables eingefügt. Ist dieser Code kompatibel zu jenem, der in wenigen Wochen in MediaWiki 1.18 live gehen wird (siehe den letzten Eintrag des Abschnitts WP:NEU#Vorschau auf Version 1.18) oder wird es da Konflikte geben? Kann man dann, wenn MW1.18 live ist, einfach den heute eingefügten Code wieder entfernen und alles funktioniert weiter? --UV 00:18, 13. Jul. 2011 (CEST)

Löschen kann man es sicher, denn es hätte gar nicht hierher kopiert werden dürfen. Der jetzt eingefügte Code sucht nach Tabellen mit {| class="collapsible", aber nur danach, nach nichts sonst. Das taucht hier tatsächlich in verschiedenen Vorlagen auf, vor allem in solchen, die aus der englischsprachigen Wikipedia kopiert wurden. Was in Kürze kommt, funktioniert mit class="mw-collapsible", und zwar bei viel mehr als nur Tabellen. --TMg 03:09, 13. Jul. 2011 (CEST)

Bitte ganz schnell reverten, bevor das durch die Caches kommt! Begründungen:

1. Collapsible Tables wurden, auch wenn oft gefordert, wegen fehlender Barrierefreiheit (Drucken etc) vom Großteil der Community abgelehnt

• Es wurde keinerlei Anpassung an die deutsche WP vorgenommen:
  • Mit-Nutzen der vorhandenen Variablen NavigationBarShow bzw. -hide
  • Keine Übersetzung der Kommentare, keine, nicht mal rudimentäre Dokumentation
• Vorsätzliches Einbauen von neuen Funktionen, die bereits als deprecated gekennzeichnet sind
• keine Anpassung/Zusammenlegung mit dem bereits vorhandenen, ähnlichen Navigationsleisten-Skript

Sowie auch die Ergänzungen im common.css revertieren:

• Redundanz mit vorhandenem Code (v.a. der Navigationsleisten, zebra hartkodiert etc.)
• viele nicht verwendete Klassen

Allgemein wären da noch die nicht vorhandene Diskussion (ist sie das?) sowie die kaum benötigte Funktionalität für diese Vorlage. Das wäre mit Navileistensyntax auch gegangen (vielleicht etwas unschön), eine Anpassung wäre jedenfalls deutlich sinnvoller gewesen als Import von großteils nutzlosem Code. --✓ ^Bergi 14:22, 13. Jul. 2011 (CEST)

Volle Zustimmung meinerseits. Der „wilde“ Import hier torpediert neben dem bisherigen Konsens auch das kommende MediaWiki-Update. Daneben habe ich Infoboxen gefunden, die jetzt doppelt zugeklappt sind, weil sie die Navigationsleisten-Syntax nutzen und zusätzlich (offenbar eine Altlast aus einem früheren en-Import) die collapsible-Klasse enthalten. Diese war bisher wirkungslos, jetzt tauchen dort überall doppelte Klapplinks auf (Beispiel). --TMg 02:33, 14. Jul. 2011 (CEST)

Ich habe es erst einmal wieder zurückgesetzt. Gruß, --Flominator 08:19, 14. Jul. 2011 (CEST)

Die Collapsible tables von MediaWiki sind längst live. Hier erledigt. --Fomafix (Diskussion) 13:26, 24. Mai 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix (Diskussion) 13:26, 24. Mai 2012 (CEST)

Dynamic Navigation Bars

Der Klappmechanismus von Navigationsleisten (im Kommentar Dynamic Navigation Bars genannt) kann nicht so einfach auf ein Schlag durch die neue Klappfunktion von MediaWiki ersetzt werden. Vielleicht können einfacher nach und nach Teile ersetzt werden. Als erstes bieten sich die Beschriftungen der Knöpfe an:

var NavigationBarHide = 'Einklappen';
var NavigationBarShow = 'Ausklappen';

Die Texte stehen bereits mit mw.messages.get( "collapsible-collapse" ) und mw.messages.get( "collapsible-expand" ) in der gewünschten Sprache des Anwenders zur Verfügung. --Fomafix (Diskussion) 13:37, 24. Mai 2012 (CEST)

Sollte man gleichzeitig auch noch die Änderung des Textes erlauben? Deshalb sind das ja globale Variablen, damit jeder sie für sich ändern kann. Keine Ahnung, ob das aktuell überhaupt noch funktioniert. Außerdem sollte man mw.msg verwenden, glaube ich. Ansonsten klingt es gut. Der Umherirrende 20:53, 24. Mai 2012 (CEST)

• Die Idee mit der Benutzerkonfiguration ist grundsätzlich nicht verkehrt; jemand könnte + für Ausklappen und x für Einklappen haben wollen. Problem: Die Initialisierung durch MediaWiki:Common.js erfolgt vor der Benutzerkonfiguration. Wenn, dann müsste das .using("user") eingefasst werden. Angenommen, Benutzer könnten auf Wunsch die althergebrachten globalen Variablen in die Welt setzen – wie wäre es dann innerhalb der anonymen Funktion mit

         var labelHide, labelShow;
         if (NavigationBarHide) {
            labelHide  =  NavigationBarHide;
         } else {
            labelHide  =  mw.msg( "collapsible-collapse" );
         }
         if (NavigationBarShow) {
            labelShow  =  NavigationBarShow;
         } else {
            labelShow  =  mw.msg( "collapsible-expand" );
         }

• Damit wären wir wieder mal im Debugger zwei Einträge an globalen Variablen los; fein, fein!
• mw.msg() soll eine fertige Zeichenkette sein; mw.messages sind alle Message-Objekte, mw.messages.get() ist ein Message-Objekt, das ausgegeben bewirkt .toString() und das ist wieder eine Zeichenkette – nämlich mw.msg().

Schönen Abend --PerfektesChaos 21:53, 24. Mai 2012 (CEST)

Genau so habe ich mir das gedacht.

Die einzig sichtbare Änderung ist damit, dass der Text lokalisiert wird. Wir müssen dann untersuchen, ob das bei den vielen Verwendungen Probleme macht. Die Vorlage:Infobox hochrangige Straße (Beispiel: Bundesautobahn 7) hält beispielsweise für den Knopf eine Breite von 6em vor.

Als nächsten Schritt können wir vielleicht die paar wenigen Benutzer dazu bringen von var NavigationBarHide='▲' auf mw.messages.set( 'collapsible-collapse', '▲' ) zu wechseln. Die Abfrage der globalen Variablen kann dann auch entfallen. Eventuell wird damit auch die Klappfunktion von MediaWiki umbenannt; das hängt von der Ladereihenfolge ab. Vielleicht gibt es in Zukunft mal von MediaWiki zentral die Möglichkeit, dass sich jeder Benutzer seine eigenen Systemtexte einstellen kann. --Fomafix (Diskussion) 23:08, 24. Mai 2012 (CEST)

Tja; erstmal programmtechnisch die Funktion zukunftsfähig vorbereiten und die gewohnte Funktionalität unterstützen. Dann Hilfe:Navigationsleisten#Navigationsleisten dynamisch ein- und ausklappen auf den entsprechenden Stand mit .set() bringen. Wenn das dann nachlesbar wirkt, kann man ja versuchen, die Individualkonfigurierer nach und nach zur Umstellung zu bewegen und geduldig abwarten. Wenn irgendwann alle aktiven Benutzer umgestellt haben, kann die alte Technik wegfallen. Ich habe mir aber angewöhnt, sowas langfristig laufen zu lassen; ich ziehe auch nicht an den Grashalmen, damit sie schneller wachsen.

Was Infoboxen angeht, müsste man sich mal fundamental mit dem Thema collapsible beschäftigen. Da stehen irgendwie umgemurkste Navileisten (class="NavContent") drin, wenn ich mich recht erinnere. Sobald die zentrale MW-collapsible robust und stabil ist (ist sie das vielleicht schon?), sollten die Infoboxen nach und nach aufgeräumt und auf collapsible vereinheitlich werden.

Mit dem .messages.set() kann ja heute schon jeder Benutzer seine eigenen Systemtexte einstellen – vorausgesetzt sie werden noch zur Kenntnis genommen und laufen über JS. Sonst muss man sie sich halt über class und id und jQuery zusammensuchen.

Viel Spaß weiterhin --PerfektesChaos 23:45, 24. Mai 2012 (CEST)

Jetzt wacher, also Nachträge:

• Es muss oben natürlich jeweils heißen

                        if ( typeof NavigationBarHide === "string" ) {

weil sonst undeclared-error; nebenbei auch gegen unbrauchbaren Datentyp.

• Oben fragte sich der Umherirrende, ob das heute noch klappt. – Wird schon. Die Vorbelegung mit var findet hier vor allen anderen statt; dann mag im Benutzerskript was passieren, und erst hinterher nach load wird per $() ausgewertet. Bei immer schnelleren, moderneren und paralleleren Browsern sollte dies anlässlich einer Überarbeitung aber explizit mit .using("user") gesteuert werden.

Sonnigen Tag --PerfektesChaos 09:20, 25. Mai 2012 (CEST)

Damit mw.messages.values["collapsible-collapse"] und mw.messages.values["collapsible-expand"] sicher zur Verfügung stehen, muss die Funktion mit mw.loader.using( 'jquery.makeCollapsible', function () { … } ) gekapselt werden. Und ja, das Auslesen sollte mit mw.msg( 'collapsible-collapse' ) und mw.msg( 'collapsible-expand' ) geschehen. Natürlich keine Eile bei den Schritten, aber den nächsten Schritt kann man schon planen. --Fomafix (Diskussion) 10:36, 30. Mai 2012 (CEST)

Mit einem einfachen mw.messages.set( 'collapsible-collapse', '▲' ) in einer Benutzer-JavaScript-Datei können die Texte nicht geändert werden, weil das Modul jquery.makeCollapsible erst danach geladen wird und die Texte wieder überschreibt. Um die Texte zu ändern muss das bisherige

var NavigationBarHide = '▲';
var NavigationBarShow = '▼';

ersetzt werden durch

mw.loader.using( 'jquery.makeCollapsible', function () {
	mw.messages.set( {
		'collapsible-collapse': '▲',
		'collapsible-expand':   '▼'
	} );
} );

--Fomafix (Diskussion) 11:07, 1. Jun. 2012 (CEST)

Gleichzeitig mit der Umstellung auf mw.msg( 'collapsible-…' ) könnte um den Text die üblichen schon öfters gewünschten eckigen Klammern gesetzt werden. Ein Argument gegen das Hinzufügen von eckigen Klammern war bisher, dass dadurch die Textbreite sich verändert. Mit der Umstellung auf Texte in Anwendersprache verändert sich die Breite der Texte sowieso. --Fomafix (Diskussion) 12:04, 1. Jun. 2012 (CEST)

• Da würde ich empfehlen, die Benutzerdefinierten von den Translatewiki durch unterschiedliche Identifizierer zu trennen; am einfachsten durch ein Anhängen von -user oder -USER. Bei Verwendung gleicher Identifizierer kann es sonst immer dazu kommen, dass irgendwie im falschen Moment der benutzerdefinierte Textwunsch vom System wieder überschrieben wird.
• Nach Eintrudeln von .using(["user", "jquery.makeCollapsible"], kann man dann gucken, was los ist. Danach sollte auch niemand mehr die Werte überschreiben; höchstens die Benutzer selbst, wenn sie es sich nochmal überlegen.
• Klammern um den Text: Naja; die wären dann mit verlinkt, und in der gewohnten Optik stünden die Klammern unverlinkt und nur der Text als Link (vor allem wenn man mit der Maus drauf ist).

Schönes Wochenende --PerfektesChaos 23:39, 1. Jun. 2012 (CEST)

Die Texte für unsere Dynamic Navigation Bars und die Texte für die Klappfunktion nach jquery.makeCollapsible sind beides mal „Einklappen“ und „Ausklappen“. Daher schlage ich vor, für die lokalen Dynamic Navigation Bars die Texte von jquery.makeCollapsible zu verwenden, damit sie nicht nochmal definiert werden müssen. Mit dem Beispiel zum Überschreiben der Texte habe ich die Anwender gedacht und nicht für hier. Das Beispiel mit dem anderen Text war also nur ein Beispiel, wie sich Anwender die Texte ohne globale Variablen umdefinieren können.

Die Klammern um die Texte sollen selbstverständlich nicht verlinkt sein und dürfen daher nicht im Systemtext sein, sondern müssen im Code erzeugt werden. --Fomafix (Diskussion) 00:04, 2. Jun. 2012 (CEST)

Ja, das ist klar: Die Benutzerdefinition soll sich sowohl auf die veraltenden lokalen „Dynamic Navigation Bars“ wie auch auf die neueren globalen Entwicklungen einheitlich auswirken.

Klammern setzen können wir allerdings nur lokal. Damit können Profis unterscheiden, ob sie ein lokales oder ein globales Element vor sich haben.

Gute Nacht --PerfektesChaos 00:46, 2. Jun. 2012 (CEST)

Umgesetzt. Die Klammern werde ich nicht zentral setzen, weil Änderungen am Erscheinungsbild nicht immer gern gesehen werden. Man kann jetzt auch die Systemnachrichten ändern und es würde sich dann auch hier durchziehen. Das überlasse ich aber gerne anderen Benutzern, das zu ändern oder die Änderung zu erreichen. Der Umherirrende 22:41, 6. Jun. 2012 (CEST)

In dieser Änderung hast Du die Dokumentation für NavigationBarShowDefault von NavigationBarShowDefault = 1 auf mw.user.options.set( 'NavigationBarShowDefault', 1 ) umgestellt, aber gleichzeitig die Abfrage von mw.user.options.get( 'NavigationBarShowDefault' ) ausgebaut. --Fomafix (Diskussion) 14:18, 11. Jun. 2012 (CEST)

Stimmt, keine Ahnung warum. Ich habe es aber nachgeholt. Danke fürs kontrollieren. Der Umherirrende 19:05, 11. Jun. 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 19:05, 11. Jun. 2012 (CEST)

PngFix

Bei en:MediaWiki:Common.js gibt es eine Funktion PngFix mit der beim Internet Explorer 6 durch einen Workaround transparente PNGs beigebracht werden. Bisher werden beim Internet Explorer 6 transparente PNGs oder aus SVG erzeugte PNGs immer mit weißem Hintergrund dargestellt, wie bei folgendem Bild zu erkennen ist:

Wäre es sinnvoll diesen Workaround zu übernehmen um damit eine einheitliche Darstellung bei allen Browsern zu erreichen? --Fomafix 09:23, 14. Nov. 2007 (CET)

Der Quelltext sieht ja nach einem ganz seltsamen Hack aus. Aber wenn es funktioniert, auf jeden Fall pro. --Revolus Echo der Stille 09:34, 14. Nov. 2007 (CET)

Hat das hier sonst noch jemand gelesen? Wo sollte das angesprochen werden, damit es jemand liest? --Fomafix 21:59, 25. Nov. 2007 (CET)

Auch hier wird es gelesen.--Τιλλα 2501 ^± 22:01, 25. Nov. 2007 (CET)

Hast du, Admin, vielleicht auch vor das aufzunehmen? --Revolus Echo der Stille 00:27, 26. Nov. 2007 (CET)

Und wie sieht es danach mit dem IE6 aus?--Τιλλα 2501 ^± 00:46, 26. Nov. 2007 (CET)

Danke, bei meinem Internet Explorer 6 mit aktiviertem JavaScript wird das obige Bild nun wie bei den anderen Browsern ohne störenden weißen Hintergrund angezeigt. --Fomafix 09:22, 26. Nov. 2007 (CET)

Die Funktion löst in der Vorlage:Lageplan einen Darstellungsfehler aus. Ich zweifle ohnehin an der Sinnhaftigkeit dieses Hacks einerseits (hat nicht inzwischen fast jeder den Internet Explorer 7?), vor allem aber an seiner Qualität (müssen JavaScript-Quelltextzeilen nicht mit ; abgeschlossen werden?). Ich würde daher empfehlen, die Funktion wieder zu entfernen. Alternativ sollte bitte an der Stelle, wo bereits die fontSize auf 0 gesetzt wird, zusätzlich die Zeile outerSpanStyle.lineHeight = "0"; eingefügt werden. Das behebt den beobachteten Darstellungsfehler. --TM 20:53, 5. Jan. 2008 (CET)

IMO hat nicht jeder Lust von Schrott (IE6) auf Scheiße (IE7) zu updaten (oder kein ausreichend leistungsfähiges System) HardDisk ^{rm -rf} 21:17, 21. Mär. 2008 (CET)

Über ein jahr her, das soltle wohl auch erledigt sein? --Guandalug 08:43, 9. Jul. 2009 (CEST)

Bei en:MediaWiki:Common.js ist das inzwischen durch

    if (navigator.appVersion.substr(22, 1) == "6") {
        importScript("MediaWiki:Common.js/IE60Fixes.js")
    }

auf eine separate JavaScript-Datei für den IE6 ausgelagert worden. Diesen Vorschlag kann ich nur empfehlen. --Fomafix 09:26, 9. Jul. 2009 (CEST)

Es gibt ein Skript für IE6 um das fehlerhafte Verhalten von pngs zu beheben. Dies wurde unter Wikipedia:WikiProjekt Vorlagen/Werkstatt/Archiv 2009/1#Problem mit der Anzeige von SVG-Dateien angesprochen. Solange es nicht durch MediaWiki selber (bugzilla:12405) gelöst wird, sollte es lokal für die deutschsprachige Wikipedia zu Verfügung gestellt werden. Für das lokale Handling müsste en:MediaWiki:Common.js/IE60Fixes.js importiert/kopiert werden und ein Abschnitt in die Common.js ergänzt werden:

//Import scripts specific to Internet Explorer 6
    if (navigator.appVersion.substr(22, 1) == "6")
    {
        importScript("MediaWiki:Common.js/IE60Fixes.js")
    }

Der Name der Seite kann auch anders gewählt werden. Vielen Dank. Der Umherirrende 20:00, 15. Feb. 2009 (CET)

*Seitenhieb in 3 … 2 … 1* Jens Ihlenfeld: Der IE6 soll sterben. golem.de, 19. Februar 2009, abgerufen am 21. Februar 2009: „Wieder einmal sammeln sich aktuell Webmaster, um dem alten Microsoft-Browser den Todesstoß zu versetzen.“  :-P --Revolus Echo der Stille 02:08, 21. Feb. 2009 (CET)

Ich kann den Webentwicklerfrust auf den IE6 und den Boykottaufruf sehr gut verstehen. Aber das hilft uns hier nicht viel weiter: Der unerfahrene PC-Nutzer ("PC ist ein Gerät wie eine Waschmaschine") hat mit seinem IE6 (bisher) überwiegend keine Probleme, auch nicht, wenn er einfach etwas bei bei Wikipedia nachschlagen will. Bei manchen Seiten (aber nur bei deutschen, hier wieder unser Beispiel) sieht halt dies und jenes sehr merkwürdig aus. Wie soll dieser Nutzer aber ahnen, dass dies an seinem inzwischen veralteten Browser liegt? M.E. gibt es folgende Lösungsmöglichkeiten:

• Wir wollen die Leute vom IE6 wegbekommen. Dann müssen wir (zumindest bei bekannt problematischen Seiteninhalten) eine Anzeige generieren à la "Wenn Sie sich an auf dieser Seite unzulänglich dargestellten Grafiken stören, empfehlen wir Ihnen, einen neueren Browser zu verwenden" mit Link zu "Wie geht das". Genau diesen Ansatz gehen auch die aktuellen IE6-Boykotteure (man betrachte z.B. diese Seite mit dem IE6).
• Alternativ bleibt eigentlich nur die weitere Unterstützung des IE6, zumal für das hier diskutierte Problem die Lösung in Wikipedia bereits umgesetzt wurde, nur eben nicht in der deutschen.

Wenn keine von diesen beiden Lösungsmöglichkleiten gewählt wird, lässt man den IE6-nutzenden Gelegenheitsnutzer mit schlecht angezeigten Seiten im Regen stehen. Nach meinem Verständnis sollte Wikipedia jedoch auch für Nicht-PC-Freaks hilfreich sein. --Igelfleiß 18:38, 24. Feb. 2009 (CET)

Ist das ganze noch aktuell? Der Verbreitungsgrad vom IE6 sollte in der Zwischenzeit stark gesunken sein. Ich weiß auch garnicht, ob Wikipedia aktuell überhaupt sinnvoll mit IE6 nutzbar ist, vorallem hinsichtlich der (erweiterten) Bearbeitungswerkzeugliste oder der anderen Spielereien im Vector-Skin. Der Umherirrende 21:52, 13. Jun. 2012 (CEST)

MediaWiki unterstützt offiziell noch IE6: mw:Supported browsers#Browser. Erst ab einem Marktanteil von unter 0,1 % soll die Unterstützung zurückgefahren werden. Derzeit ist der MSIE 6.0 noch bei 1,20 %. Allerdings wird bereits die Unterstützung für den Internet Explorer 6 bereits zurückgefahren (Beispiel), obwohl auch dort JavaScript-Workarounds möglich wären.

Von mir aus kann hier auch die Beachtung des Internet Explorer 6 verzichtet werden und keine extra Workarounds eingebaut werden. --Fomafix (Diskussion) 22:30, 13. Jun. 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix (Diskussion) 22:30, 13. Jun. 2012 (CEST)

Überspringen der deutschen Dateiseite

Diskussion verschoben nach MediaWiki Diskussion:Gadget-Direct-link-to-Commons.js. --Fomafix (Diskussion) 16:53, 2. Jul. 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Fomafix (Diskussion) 16:53, 2. Jul. 2012 (CEST)

Nowiki

Hallo, damit so etwas nicht passiert und auch um unerwünschte Kategorisierung zu verhindern, nutzt doch einfach ein // <nowiki> am Anfang des Codes. Der Kommentar wird vom RL entfernt, übrig bleibt ein JavaScript ohne bad-escapements. Jede Vorlage, Kategorie oder Wikimagic (pre-save transformation (PST)) mit hässlichen Methoden zu zerstören, wird auf lange Sicht gesehen nur zeitraubend sein. -- RE rillke fragen? 16:13, 29. Jul. 2012 (CEST)

Ein paar Wikilinks sind ja gewollt, daher weiß ich nicht, ob das generelle nowiki hier die Sache besser macht. Aufpassen und JS-Vorschau wie bei Benutzer-JS hilft da mehr (Bug 18227). Der Umherirrende 19:50, 29. Jul. 2012 (CEST)

Für Syntaxfehler und ähnliche Probleme habe ich auf Commons übrigens commons:Help:JSValidator geschrieben. Ein Teil des Codes befindet sich unter commons:MediaWiki:JSValidator.js (dort kannst Du ihn auch gleich in Aktion sehen: In der Werkzeugliste der Eintrag "Check with JSLint"). Generell sollte er auch auf anderen Wikis funktionieren. Du kannst ihn auf Commons auch an Deiner Benutzer-JS testen. -- RE rillke fragen? 20:45, 29. Jul. 2012 (CEST)

Interessant, werde ich mir mal anschauen. Ich denke aber, das wir hier auch ohne nowiki gut umgehen können. Das Testen im Vorschaufenster war hier halt nicht genung, hätte ich es einmal abgespeichert oder besser in den Versionsunterschied gesehen, wäre es mir schon direkt aufgefallen. Den Versionsunterschied hatte ich mir aber nur angezeigt, um zu gucken, das ich weiter oben nichts kaputt gemacht habe und nur die Ergänzung abspeichere.

Gerne kann jemand anders nowiki ergänzen oder das erledigt wieder entfernen, aber ich sehe es erstmal als erledigt an. Der Umherirrende 17:04, 30. Jul. 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 17:04, 30. Jul. 2012 (CEST)

HD:Signatur#Standardsignatur

Vielleicht sollte man am besten auch hier den Ursprungszustand wiederherstellen, da es momentan keinen Konsens für die Änderung (entfernen von -- in der Standardsignatur) gibt. Ich möchte dies jedoch einem andern Admin oder Umherirrender selbst überlassen. --Leyo 10:31, 30. Jul. 2012 (CEST)

+1 (ohne mich mit Argumenten an der Diskussion beteiligen zu wollen – die gibt es nämlich meiner Ansicht nach für keine der beiden Varianten), und beim nächsten Mal Änderungen bitte erst auf beta.wmflabs testen. --Schnark 10:48, 30. Jul. 2012 (CEST)

Ist raus. Der Umherirrende 17:02, 30. Jul. 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 17:02, 30. Jul. 2012 (CEST)

Problem mit section=new-Link im Tab für nicht vorhandene Artikeldiskussionsseiten

Unter Wikipedia:Fragen zur Wikipedia#Diskussionsseitenproblem wurde berichtet, dass es beim Tabwechsel vom Artikel zur Artikeldiskussionsseite zu Problemen kommt, weil die Seite mit section=new endet. Das Problem habe ich erstmal mit einem Temp-Fix umgangen, aber es sollte noch geklärt werden, was der Auslöser hier ist, damit der Temp-Fix vielleicht auch wieder entfernt wird. Idee zur Problemursache war die neue jQuery-Version 1.8, vielleicht kann das jemand verifizieren. Ich würde mich über Hilfe bei der Aufklärung des Problems freuen. Der Umherirrende 12:39, 2. Sep. 2012 (CEST)

Schnark hat das bereits gemeldet. Wir sollten wohl noch einen Bug eröffnen, mit der Bitte um Update. --Steef ³⁸⁹ 12:44, 2. Sep. 2012 (CEST)

Das hört sich gut an. Danke. Ein Update in MediaWiki oder das einspielen des Fix als Patch wäre natürlich eine Überlegung wert. Keine Ahnung, ob man das über Bugzilla hinbekommt oder soviel Zeit verstreicht, das die neue Version eingespielt wird. Der Umherirrende 12:51, 2. Sep. 2012 (CEST)

Let's see. --Steef ³⁸⁹ 13:28, 2. Sep. 2012 (CEST)

Das ging mal schnell. Danke für die Mithilfe. Ich habe den Temp-Fix wieder entfernt. Der Umherirrende 18:37, 3. Sep. 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 18:37, 3. Sep. 2012 (CEST)

OSM bei Sternen

Auf WP:FzW wird Wega als ein Beispielartikel genannt, wo ein sinnloser Link für eine OSM-Karte generiert wird. Ein if (h.match(/skyhack/)) continue; sollte Abhilfe schaffen. --Schnark 10:17, 16. Okt. 2012 (CEST)

Von PDD erledigt. --32X → Autorenngilde № 1 19:17, 16. Okt. 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: 32X → Autorenngilde № 1 19:17, 16. Okt. 2012 (CEST)

Hack zur Großschreibung der Sprachlinks

Der müsste inzwischen überflüssig sein und sollte daher wieder entfernt werden. --Schnark 09:11, 25. Okt. 2012 (CEST)

Ich hatte in den Change übersichten gelesen, das jetzt per CSS das ucfirst erreicht wird, macht jeder Browser das richtig? Der Umherirrende 18:10, 25. Okt. 2012 (CEST)

Scheint doch noch nicht aktiv zu sein: gerrit:27039 hatte ich gesehen. Der Umherirrende 20:49, 25. Okt. 2012 (CEST)

Irgendwann wurden bei den Sprachen mit Klammer LRE am Anfang und PDF am Ende durch ein einfaches LRM am Ende ersetzt (analog für rechts-nach-links-Sprachen), sodass das erste Zeichen jetzt tatsächlich der erste Buchstabe ist. Da in allen Wikipedien, die ich stichprobenartig überprüft habe, Norsk großgeschrieben ist, und ich bezweifle, dass alle diese Projekte JavaScript dafür verwenden, gehe ich davon aus, dass diese Änderung inzwischen live ist. --Schnark 09:12, 26. Okt. 2012 (CEST)

Ah, das hatte ich garnicht mitbekommen. Es handelt sich um gerrit:24888. Ja, wenn das so ist, kann das wieder raus. Der Umherirrende 16:01, 26. Okt. 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 16:01, 26. Okt. 2012 (CEST)

Hints für Tabulatoren

Bevor das hier noch eskaliert, schlage ich folgendes Feature vor:

mw.loader.using( [ 'user', 'mediawiki.user', 'user.options', 'mediawiki.util' ],
                   function() {   // wait for user overrides
   if ( ! mw.user.options.get( 'disableTabHints', false ) ) {   // disable in user.js, if not desired
      switch ( mw.config.get( 'wgAction' ) ) {
         case 'view' :
            if ( mw.util.getParamValue( 'diff' ) !== null ) {
               document.title  = 'Δ ' + document.title;   // ± falls Darstellungsproblem
            }
            break;
         case 'edit' :
         case 'submit' :
            document.title  =  '* ' + document.title;
            break;
         case 'history' :
            document.title  =  '↓ ' + document.title;
            break;
      }   // switch
   }
                              } );

Bemerkungen:

• Der mit den Systemnachrichten gesetzte allgemeine Seitentitel wird dadurch nicht beeinflusst, sonst meckern die hier.
• Wer kein JS aktiviert hat, muss eben ohne hint vorlieb nehmen und nach den Anführungszeichen gucken.
• Die Geschichte soll für alle angemeldeten und unangemeldeten Benutzer gelten. Mit RL2 lässt sich über Opt-out der Viel-Fensterer und weltweit-Gadget reden; bis dahin muss mw.user.options.set langen.
• Bei Umsetzung empfiehlt sich Annoncierung auf FzW; gleich mit Kurz-Anker (oder gar Kurier/rechts?).
• Der obige Code ist (wie alles, was ich zwangsweise allen Benutzern aufdrücken würde) zeitoptimiert geschrieben.

Liebe Grüße --PerfektesChaos 11:01, 6. Jun. 2012 (CEST) *** code updates; last --PerfektesChaos 17:51, 6. Jun. 2012 (CEST)

etc. – scheint ja ein Benutzer-Interesse zu geben. Umgekehrt sieht man zumindest im ANR mehr davon, wenn die nicht gerade alle Schlacht be… heißen. VG --PerfektesChaos 11:10, 6. Jun. 2012 (CEST)

Das sind mal wieder benutzerspezifische Systemtexte. Hoffentlich gibt es das mal zentral von MediaWiki. --Fomafix (Diskussion) 13:26, 6. Jun. 2012 (CEST)

• Wobei es hier ausdrücklich nicht um den Systemtext geht, der groß und breit auf der Seite angezeigt bleibt, und der als vorhandener document.title so übernommen wird wie vorgefunden, sondern lediglich um deutlichere Kennzeichnung der Karteireiter, in denen besondere Aktivitäten stattfinden.

VG --PerfektesChaos 14:32, 6. Jun. 2012 (CEST)

Stimmt, unter title und unter #firstHeading wird die gleiche Systemnachricht verwendet. Wäre es sinnvoll hier generell separate Systemnachrichten in MediaWiki zu definieren? Es müssten vermutlich recht viele Systemnachrichten angelegt werden. Vorschlag: MediaWiki:Editing wie bisher für #firstHeading und MediaWiki:Editing-title für title. --Fomafix (Diskussion) 16:05, 6. Jun. 2012 (CEST)

Na, das schiene mir übermäßiger Wartungsaufwand, um all dies auch immer synchron und stimmig zu halten.

Es geht eigentlich nur um drei Sonderfälle (wobei Editing MediaWiki:Editing, MediaWiki:Editingsection, MediaWiki:Editingcomment und MediaWiki:Creating nebst MediaWiki:Creating/de-formal usw. usw. umfasst), die im d.title→Kartenreiter hervorgehoben werden sollen, damit sowohl die besondere Aktion wie auch der Anfang des Seitennamens sichtbar sind. Dafür -zig neue Systemnachrichten zu schaffen schiene mir unverhältnismäßig; die würde ich lieber aus der wgAction ableiten. Und den Nicht-JS-Benutzern bleiben die führenden Anführungszeichen.

Der Vorschlag oben wäre sehr kurzfristig umsetzbar und würde hoffentlich das aktuelle Gemecker beenden.

Grüße --PerfektesChaos 16:30, 6. Jun. 2012 (CEST)

Also ich würde eher meckern wenn das umgesetzt wird. Gut, ich weiß wie man es abschalten kann, aber der Großteil wird sich wohl drüber aufregen. Welcher Ottonormalnuter kann schon mit Δ, * oder ↓ etwas anfangen? -- ✓ ^Bergi 18:05, 6. Jun. 2012 (CEST)

Na, vor allen Dingen ging es bei dem Gezanke in den verlinkten Disku um die Bearbeiten-Tabs, von denen befürchtet wird, dass sie beim Schließen übersehen werden. Das * ist also das Wichtigste; die anderen beiden sind Extra-Kosmetik und könnten ggf. durch mehrwertige disableTabHints auch standardmäßig entfallen und erst in Stufe X zugeschaltet werden.

Wobei ich mittlerweile speziell für das Bearbeiten tabIcon geschrieben habe, das zunächst mal bei FF und Opera funktioniert. Pixelmalerei muss aber noch ausgebaut werden.

Schönen Abend --PerfektesChaos 22:13, 6. Jun. 2012 (CEST)

Unter MediaWiki Diskussion:Gadgets-definition#Vorschlag für MediaWiki:Gadget-paneMarker.js gibt es einen Vorschlag als Gadget. Es scheint auch so, das über die Zeit sich viele dran gewöhnt haben (oder sich nicht beklagen). Sollte daher hier erledigt sein. Der Umherirrende 08:49, 27. Okt. 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 08:49, 27. Okt. 2012 (CEST)

OSM @32X

Hallo 32X,

schön, dass du diesmal schneller bemerkt hast, dass deine Code-Änderungen Syntaxfehler enthalten.

Zur Info betreffend OSM:

1. Der auf meta: vorhanden OSM-Code ist veraltet; unserer ist möglicherweise bereits jetzt neuer.
2. Weiter oben auf dieser Disku findest du bereits eine aktuelle Neu-Implementierung, die demnächst eingebaut werden soll.

VG --PerfektesChaos 20:50, 7. Feb. 2012 (CET)

Da die Funktion in der Zwischenzeit umgeschrieben wurde, sehe ich diesen Hinweis als erledigt an. Der Umherirrende 17:48, 15. Nov. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 17:48, 15. Nov. 2012 (CET)

Überarbeitung dieses Skriptes

Die Seite ist historisch gewachsen, und bisher hat auch alles geklappt; aber es hat sich einiges angesammelt und sollte mit Ausbau des mw. auch in eine übersichtliche und sicher zu pflegende Struktur gebracht werden.

Reihenfolge

• Die Blöcke sollten in folgende physische Abfolge gebracht werden:
  1. Reine Deklarationen (global scope)
     1. Variable
     2. Funktionsdeklarationen
  2. Ausführbare Anweisungen
     1. Sofort beim Laden auszuführen
     2. Mit jQuery(document).ready() Ausführung erst nach Laden des DOM
• Das sind namentlich:
  1. Reine Deklarationen
     1. Variable
        • tableSorterCollation erledigt Der Umherirrende 19:28, 12. Feb. 2012 (CET)
        • ta dazu gesondert
     2. Funktionen mit global scope
        • includePage dazu gesondert
        • akeytt dazu gesondert
        • openStreetMapToggle fraglich; dazu gesondert
        • Rest fraglich; später mehr
  2. Ausführbare Anweisungen (sofort)
     • mw.util.addCSS('.noscript ... mit mw.loader.using erledigt Der Umherirrende 19:28, 12. Feb. 2012 (CET)
     • Importiere ggf. MediaWiki:Common.js/secure.js
       Hier falsch; müsste DOM abwarten, um alle document.links zu kennen. Verschieben auf jQuery(document).ready() – Resultat ist für den Benutzer nicht unmittelbar sichtbar; kann nach der Seitendarstellung im Hintergrund zusammengerödelt werden.
  3. Ausführbare Anweisungen (nach document.ready)
     • Die Blöcke mit anonymer Funktion lassen nie wieder benötigte Funktionen elegant aus dem global scope aller Benutzer verschwinden. Sie können auch ihre Konfigurationsvariablen mitnehmen und dadurch verstecken.
• Jeder inhaltliche Block sollte sein eigenes jQuery(document).ready() behalten. Damit werden sie in überschaubare Einheiten gegliedert, die sich in andere Projekte, andere Seiten kopieren lassen und die man auch sicher entfernen kann, wenn sich Strukturen ändern.
• Mit Eintreten des document.ready kann man guten Gewissens annehmen, dass mediawiki.util inzwischen geladen worden ist. Sollte sich eines Tages ergeben, dass das DOM schneller fertig ist als mw.util, können Blöcke, die in ihrem scope mw.util-Funktionen tatsächlich einsetzen, das explizit für ihren scope anfordern. Nachtrag: Oben hat der Umherirrende genau die Realisierung hierfür dargestellt. 17:26, 22. Jan. 2012 (CET)

Entfernung aus dem global scope

Um Namenskonflikte zu vermeiden und den global scope zu verschlanken, sollten Variable und Funktionen anonymisiert werden, die nur ein einziges Mal im Rahmen dieses Skriptes benötigt werden. Bei den nachstehend aufgeführten Einzelfällen ist nicht bekannt, dass sie später noch benutzt würden.Sollte dies anders sein, wäre das auch jeweils explizit zu dokumentieren.

• Anonymisierung von Funktionen:
  • SVGThumbs
  • openStreetMapInit
  • donate_rewrite_url erledigt Der Umherirrende 19:56, 8. Feb. 2012 (CET)
  • Bei openStreetMapToggle könnte Kolossos & Co. für die weltweite Verbreitung eine benannte Funktion angeboten werden, die innerhalb der anonymisierten openStreetMapInit mit dem onclick verbunden wird (Beispiele dafür siehe toggleImageFunction, toggleNavigationBarFunction). Dann stünde die gesamte openStreetMap-Aktion geschlossen in einem Block und könnte so auch für das Projekt OSM als Musterlösung benutzt werden.
• Anonymisierung von Variablen:
  • Soweit ersichtlich, werden nachstehende Konfigurationsvorgaben nie wieder benötigt, können in die bereits existierenden anonymen Funktionen einbezogen und aus dem global scope getilgt werden.
  • link[FG]A_.....
  • NavigationBar...

Deprecated

• importScript sollte im Rahmen dieses Skripts durch mw.loader.load ersetzt werden.
• Die Implementierung durch includePage sollte dabei den geeignet escapten Namen des Benutzerskripts verwenden. Hier könnte dann ggf. Umschreibung mit mw.loader.using notwendig werden.

Nebenbei bemerkt wird mw.config.get immer gleichzeitig mit dem ResourceLoader verfügbar.

Völlig veraltet

• includePage und akeytt sollten in 2012 einen alert() bekommen, um mit sanfter Gewalt die noch existierenden und benutzten Verwendungen zur Modernisierung zu zwingen.
• Gleichwohl sollten temporär während des Jahres 2012 zur Vermeidung von Abstürzen beim Benutzer in diesem Skript definiert sein:
  • ta[]
  • includePage()
  • akeytt()
• Zum Hintergrund siehe WD:Projektneuheiten #akeytt() in JavaScript ab 1.19. Die von TMg und 32X vorgetragene Vorstellung, dass Administratoren durch die Programmierung aller Benutzerskripte gehen und auch bei seit Jahren nicht mehr verwendeten Skripten jedes Vorkommen des Arrays ta und jede Funktionsbenutzung von akeytt() auskommentieren, dürfte sich spätestens mit der Aktion heute morgen als gaga erwiesen haben.

VG --PerfektesChaos 09:17, 22. Jan. 2012 (CET)

 Pro. Eine Verbesserung des OSM-Skripts hatte ich bereits im Juni '11 auf WP:AA zusammen mit Gadgets-Änderungen angeregt, wo es aber nach 1 Kommentar ohne Änderung archiviert wurde. Das /secure.js-Dingens sollte imho entfernt werden und das oben angesprochene relative.js direkt in die common.js integriert werden.

Vergessen in der Liste hast du /watchlist.js, welches sowohl hoffnungslos veraltet als auch oft grundlos geladen wird. Hatte ich nicht schonmal igendwo vorgeschlagen, es nur zu laden wenn ein div#watchlist-message [14] auf der Seite vorhanden ist? -- ✓ ^Bergi 16:39, 22. Jan. 2012 (CET)

• Für das secure.js kann ich mir insofern eine Zukunft vorstellen, als im https-Fall für alle document.links auf ein Wiki-Projekt ein explizit angegebenes http schlicht entfernt werden sollte, fertig. Die bisherige Manipulation des Pfades und der Domain mit secure.wikimedia.org kann wegfallen. Damit ist das eine so einfache Konstruktion (ohne RegExp), dass es hier inline in einem anonymen jQuery(document).ready() ausgeführt werden kann; die bisherige Unterseite MediaWiki:Common.js/secure.js kann dann gelöscht werden.
• Ich hatte mich in dieser Seiten-Disku erstmal auf den unmittelbaren Inhalt dieser Seite beschränkt; auf WD:NEU hatte ich weitere Kandidaten benannt, ohne heute morgen eine vollständige Auflistung sämtlicher Baustellen beabsichtigt zu haben – zumal ich erst über das Debugging zur Gespensterstunde heute früh hier aufgeschlagen war.

LG --PerfektesChaos 17:26, 22. Jan. 2012 (CET)

donate_rewrite_url aus dem global scope entfernt Der Umherirrende 19:56, 8. Feb. 2012 (CET)

Noch eine Frage, wo ich mir nicht sicher bin und nichts gefunden habe: Wann ist Geo definiert? Ich habe es jetzt außerhalb von document.ready genutzt, daher wäre es interessant zu wissen. Es wird in einem Skript-Tag von geoiplookup.wikimedia.org geladen. Ist wahrscheinlich sicherer, das doch wieder umzudrehen. Der Umherirrende 20:08, 8. Feb. 2012 (CET)

• Erstmal vielen Dank, dass du dich dieser Angelegenheiten widmest, mit deinen frischen Rechten.
  • Immer, wenn die URL //geoiplookup.wikimedia.org/ aufgerufen wird, gibt sie ein Mini-JS-Skript zurück. Dieses setzt in den global scope ein neues Objekt Geo – offenbar eine Analyse des ISP und seines Versorgungsbereichs.
  • Du kannst die //geoiplookup.wikimedia.org auch so in deinen Browser eingeben.
  • Das donate müsste (anonym) wieder zurück in die document.ready, weil es auf ein DOM-Element zugreift: "li#n-sitesupport a" – das geht erst nach document.ready. Außerdem wird möglicherweise diese Laufzeit für die Antwort auf //geoiplookup.wikimedia.org/ benötigt, damit im Moment der Abfrage das Geo definiert ist.
  • Schlau wäre es deshalb, dies im Inneren in eine Abfrage einzuschließen if(typeof(Geo)==="object") – falls die Antwort von //geoiplookup.wikimedia.org noch nicht eingetrudelt ist, gäbe es sonst einen Syntaxfehler.
  • Übrigens kannst du jQuery noch eine Kleinigkeit beschleunigen, indem du schreibst: "#n-sitesupport a" – wenn ein Element mit der ID n-sitesupport gefunden wurde, muss nicht noch kontrolliert werden, ob das auch ein li ist.

Schönen Abend --PerfektesChaos 21:14, 8. Feb. 2012 (CET)

Eine (vollständige) Typprüfung muss nicht sein, aber man könnte schauen, ob es da ist. Ich habe es mal so gemacht. Die anderen JS-Wissenden mit den notwendigen Rechten scheinen aktuell nicht so viel Zeit zu haben, Schade eigentlich, aber man tut, was man kann. Der Umherirrende 21:20, 8. Feb. 2012 (CET)

tableSorterCollation mit window versehen und nach oben gezogen, sowie Abhängigkeiten für noscript gesetzt. Der Umherirrende 19:28, 12. Feb. 2012 (CET)

Ich glaube in der Zwischenzeit sind die Punkte hier abgearbeitet/entfallen. Falls noch etwas nicht erledigt ist, bitte pro Punkt einen neuen Abschnitt anlegen, wo dann die notwendigen Dinge drinstehen. Vielen Dank. Der Umherirrende 14:46, 17. Nov. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 14:46, 17. Nov. 2012 (CET)

Blöcke

• Nachstehend Vorschläge für überarbeitete Blöcke, die als Ersatz für die überkommene Programmierung auszufeilen wären und diese dann ersetzen können.
• Weil thematisch voneinander unabhängig (OSM, Navileistenklapp, Spendengeldumlenkung), sollen sie in separaten Blöcken und nicht in einem geschlossenen jQuery(document).ready() angelegt werden. Bei Veränderungen am Einzelthema können sie dann ohne Nebenwirkungen geändert oder ersetzt/entfernt werden. Auch Export an andere Projekte ist dadurch fehlersicher möglich.

VG --PerfektesChaos 15:09, 29. Jan. 2012 (CET)

Da gebe recht. Separate Blöcke sollten in separaten Funktionen gehalten werden und gegebenenfalls separate Abhängigkeiten bekommen. Aus Gründen der Übersichtlichkeit und der Wartung wäre es sinnvoll, wenn separate Blöcke in separaten Dateien wären. Das derzeitige Einbinden per importScript() ist aber nicht ganz das richtige, weil dabei nicht die Minimierfunktion und das Zusammenfassen in einen Request vom ResourceLoader darüberlaufen kann. Für Standardmodule, die alle Benutzer bekommen sollen, wäre die Auslagerung in ein Gadget das richtige. Gadgets können als default markiert werden: mw:Gadgets#Options. --Fomafix 16:26, 29. Jan. 2012 (CET)

Ich gehe davon aus, dass alles, was auf MediaWiki:Common.js steht, zwangsweise immer jedem (auch nicht angemeldetem) Benutzer aufs Auge gedrückt werden soll. Dies in Pseudo-Gadgets auszulagern, die sich auch nicht abwählen lassen, ist nicht sinnvoll und kostet nur überflüssige Ressourcen.

Oder schlägst du spezifische Einzelfunktionen vor, die als Gadget ausgelagert werden sollen? Welche genau? OSM, Navileistenklapp, Spendengeldumlenkung sind doch „alternativlos“, wie die Kanzlerin sagen würde.

LG --PerfektesChaos 17:17, 29. Jan. 2012 (CET)

Default-Gadgets lassen sich für angemeldete Benutzer explizit deaktivieren (mw:Extension:Gadgets#Options. Das ist genau der Vorteil. Ich denke da vorallem an OSM. --Fomafix 17:35, 29. Jan. 2012 (CET)

Aha; ich müsste dann nur noch verstehen, wer welchen Vorteil von dieser OSM-Deaktivierung hätte; bislang schien sie mir harmlos.

Grundsätzlich keine Gadget-Kreuzchen sollten angeboten werden für Basisfunktionen, deren Deaktivierung den Benutzern keine Vorteile brächte. Würde der Navileistenklapp deaktivierbar sein, dann klicken Hunderte von Benutzern darauf herum, nehmen das Kreuzchen weg, schlagen anschließend auf FZW auf und beklagen sich bitter, dass diese doofe WP und ihre Navileisten nicht funktionieren.

Gadgets sind nach ihrem bisherigen Verständnis durch die Benutzer zusätzliche „Helferlein“. Die neuartige Möglichkeit, sie programmtechnisch als deaktivierbare Basisfunktion umzudeuten, scheint mir nicht recht OMA-tauglich. Was ein zusätzliches Helferlein-Kreuzchen nach sich zieht, muss in seinen Auswirkungen sowie Vor- und Nachteilen den Benutzern erklärt werden. Schiene mir bei OSM eher verwirrend?

Die bisher auf MediaWiki:Common.js vorgenommene Gliederung als Blöcke, getrennt durch Kommentarzeilen mit ===== etc. genügt meinen Ansprüchen an Modularisierung völlig und ist effizienter als Mini-Importe.

LG --PerfektesChaos 18:10, 29. Jan. 2012 (CET)

Wer bei den Gadgets etwas verstellt braucht sich über die Änderung nicht wundern. Die Deaktivierfunktion der Gadgets ist im Prinzip auch nichts anderes, als eine Deaktivierfunktion per globaler Variable in den persönlichen JS-Dateien. Ok, OSM bietet derzeit keine Deaktiverfunktion, aber sie schadet nicht und ist beim Weiterentwickeln des Software vielleicht ganz hilfreich. Gadgets bieten den Vorteil, dass dort Abhängigkeiten extern definiert werden können, sie besser lokalisiert werden können und besser weitergegeben werden können. --Fomafix 18:59, 29. Jan. 2012 (CET)

Mit dem RL2 sollen Gadgets auch als hidden markiert werden können. Default und hidden kombiniert müsste dann das derzeitige Verhalten der Commons.js nachbilden. Die Gadgets werden schon heute zu einem Request zusammengefasst. Das Ladeverhalten sollte sich daher nicht verschlechtern. Auch serverseitig nicht, denn die generierten minimierten Sammelcodeblöcke werden wie heute im Proxy gecachet. Im Gegenteil: Blöcke wie OSM könnte mit "position": "bottom" am Ende eingebunden werden und damit das Ladeverhalten der anderen Blöcke beschleunigen. --Fomafix 13:39, 23. Feb. 2012 (CET)

Das müsste es aber auch noch ein Skin-Parameter geben, damit man die Skin-JS/CSS-Seiten auch ablösen kann. Klingt aber erstmal interessant, auch wenn es nachher vermutlich schwieriger wird, den Überblick zu haben, was gerade für wen aktiv ist. Das müsste man sich aber dann anschauen. Der Umherirrende 18:36, 23. Feb. 2012 (CET)

Skin-Parameter gibt es jetzt (mit 1.19, rev:100509). Der Umherirrende 22:02, 1. Mär. 2012 (CET)

Für mich sehen die Blöcke erstmal als erledigt aus, wer noch etwas weiter diskutiert haben möchte, soll bitte pro Punkt einen eigenen Abschnitt (auf Stufe 2) neu anlegen. Vielen Dank. Der Umherirrende 15:05, 17. Nov. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 15:05, 17. Nov. 2012 (CET)

https

Die momentane Programmierung in MediaWiki:Common.js/secure.js ist weitgehend funktionslos geworden. Ersatz:

if (window.location.protocol === "https:") {
   // 2012-01-29
   jQuery(document).ready(function() {
      if (window.disableSecureLinks) {   // User defined inhibitor
         return;
      }   // ! window.disableSecureLinks
      var got;
      var n    =  document.links.length;
      var rek  =  /\.(download|dumps)$/;   // keep http
      var rew  =  /^(.+)\.(wik(?:i[mp]edia|tionary|isource|iquote|ibooks|inews|iversity|imediafoundation)|mediawiki|toolserver)\.org$/i;
      var url;
      for (var i = 0;  i < n;  i++) {
         url  =  document.links[i];
         if (url.protocol === "http:") {
            if (url.host.indexOf(".org") > 0) {
               got  =  rew.exec(url.host);
               if (got) {
                  switch (got[2]) {
                     case "wikimedia" :
                        if (rek.test(got[1])) {
                           continue;   // for i
                        }
                        break;
                     case "wikipedia" :
                        // any limitations??
                        break;
                  }   // switch
                  url.protocol  =  "https:";
               }
            }
         }   // http:
      }   // for i
                                      }   // function()
   );   // jQuery(document).ready
}   // https page

• Funktion:
  • Verlinkungen mit unverschlüsseltem Protokoll auf ein WMF-Projekt sollen auf https umgeleitet werden, wenn der momentane Benutzer sich die Seite verschlüsselt ansieht.
  • Bei Verfolgung des Links ist der Benutzer im fremden Projekt ggf. ebenfalls ein angemeldeter Benutzer und soll dort geschützt werden.
  • Wer durch Verschlüsselung ein besonderes Sicherheitsbedürfnis zeigt, sollte auch bei allen WMF-Aktivitäten geschützt sein.
• Steuerung:
  • Wird zu Testzwecken gewünscht, die Umleitung zu unterdrücken, kann ein Benutzer window.disableSecureLinks auf true setzen.
• Optimierung zur bisherigen Version
  • Die elementare Abfrage window.location.protocol wird genutzt, um von vornherein unnötige Aktionen zu unterbinden.
  • Die weiteren Aktivitäten erfolgen zeitverzögert, nachdem dem Benutzer die Seitendarstellung präsentiert wurde. Die Link-Modifizierung ist für Benutzer nicht sichtbar und soll nachträglich im Hintergrund erfolgen. Ohnehin kann erst nach Laden des DOM begonnen werden.
  • Alle <area href= und <a href= bilden Link-Objekte; alle sind bereits als document.links fertig eingesammelt. Eine Suche im DOM auf getElementsByTagName('a') ist zu aufwändig.
  • Alle durch die Wiki-Software generierten Verlinkungen sind protokoll-relativ bzw. benutzen direkt das aktuelle Protokoll; oder sollten zumindest bereits so verfahren. URL auf WMF mit http könnten eigentlich nur durch im Wikitext explizit angegebene Weblinks entstehen. Die Beschränkung auf URL mit http ohne Verwendung eines RE spart unnötige Analysen. Die Mehrzahl der ausgefilterten Weblinks mit http greift auf externe Domänen mit .com oder .de zu; nur .org ist über RE genauer zu analysieren.
  • Die Bildung eines neuen Pfades für secure.wikimedia.org ist entfallen; es wird schlicht das Protokoll ersetzt.
• Offene Fragen
  • Der syntaktische Sinn der Zeichenkette ".*?" im RE sub.match(/^(download… konnte nicht entschlüsselt werden.
  • Die Aktualität der Domain-Einschränkungen ist zu überprüfen.
    • Die Ausgangsversion stammt von April 2011; inzwischen (seit Herbst 2011) sind fast alle subdomains bis auf download = dumps über https zu erreichen. Weitere?
    • mobile ist über https verfügbar; gerade hierbei ist es nicht sinnvoll, https auszuschließen.
    • Die Query-Pfade mit .m werden offenbar nicht mehr generiert?
    • Die bugzilla ticket sind ausschließlich über https definiert; diese beiden von https auszuschließen ist nicht mehr sinnvoll.
• Anmerkung:
  • Sollte sich kein weiterer Verwendungszweck finden, kann das switch (got[2]) auch in ein if (got[2]) umgewandelt werden; für den Anfang erstmal auf Stand 2011 belassen.
• Nach Übernahme:
  • Block in MediaWiki:Common.js einfügen/ersetzen.
  • MediaWiki:Common.js/secure.js löschen.

--PerfektesChaos 15:09, 29. Jan. 2012 (CET) +kl.erg 17:17, 29. Jan. 2012 (CET)

Ich würde das Skript lassen, damit Benutzer des alten secure.wikimedia.org-Server auch weiterhin auf dem Server bleiben und für alle anderen würde ich ein neues Skript nutzen, vergleiche #MediaWiki:Common.js/relative.js. Der Umherirrende 17:59, 29. Jan. 2012 (CET)

OSM

@Bergi aut idem: Wie wäre es? Wenn die internationalen Seiten von OSM@WP nichts hergeben, dann eine zukunftsfähige Lösung mit anonymisiertem Toggelchen, und dies auch an Kolossos & Co. zur weltweiten Verbreitung übergeben. --PerfektesChaos 15:09, 29. Jan. 2012 (CET)

Was meinst du mit anonymisiert? International gibt nur en:MediaWiki:Gadget-OSM.js, meta:MediaWiki:OSM.js und Benutzer:Kolossos/osm.js her. Prinzipiell alles dasselbe und voneinander abgeschrieben. Eine "zukunftsfähige" Lösung sähe für mich so aus (deaktivier-Link bei Gadget-Einsatz eher nicht notwendig, lang=de hier hartcodiert):

// Verwendung von OpenStreetMap in Wikipedia.
// Bergi (de:Benutzer:✓), angelehnt an vorherige Version von Magnus Manske / Kolossos
 

jQuery(document).ready(function openStreetMapInit($) {
   if (window.noOSMlink) return; // deactivation
   var c = $('#coordinates'),
      geohref = '',
      osm = null;
   if (!c.length) return;
 
   c.find('a').each( function() {
      var h = this.href;
      if (h.indexOf("geohack") == -1 || h.indexOf("_globe:") > -1)
         return; // no OSM for moon, mars, etc
      geohref = f;
      return false; // stop loop
   });
   if (!geohref) return;
 
   var na = $('<a>Karte</a>').click(toggleOpenStreetMap);
   c.append(document.createTextNode(' ('), na, document.createTextNode(')'));
 
   function toggleOpenStreetMap() {
      if (osm)
         return osm.toggle();
      var url = '//toolserver.org/~kolossos/openlayers/kml-on-ol.php?lang=de&uselang='
       + mw.config.get( 'wgUserLanguage' )
       + '&' + geohref.substr(geohref.indexOf('params='));
      osm = $('<iframe/>', {
         id: 'openstreetmap',
         css: { width:'100%', height:'350px', clear:'both' },
         src: url
      });
      $('#contentSub').append(osm);
   }
});

Wobei ich jetzt mw.libs.dewiki = Object(mw.libs.dewiki); mw.libs.dewiki.osm = {init: function(){…}, toggle: function(){…}}; mal weggelassen habe. Wäre das evtl. sinnvoll? -- ✓ ^Bergi 21:28, 29. Jan. 2012 (CET)

• Danke erstmal. Wobei ich jetzt die Statements nicht im Einzelnen durchgetüftelt habe.
• Die von dir verlinkten Seiten kannte ich; entspräche in etwa auch dem bisherigen Code in der de.WP. Möglich aber dann wohl eher unwahrscheinlich wäre eine interne Weiterentwicklung der internationalen OSM@WP gewesen; aber die sind ja anscheinend noch bei addOnloadHook.
• toggleOpenStreetMap ist ja schon mal aus dem global scope verschwunden. Ich dachte mit „anonymisiert“ daran, auch openStreetMapInit wegzuzaubern – ist doch sonst deine Spezialität. Init klingt nicht so, als ob man das jemals wieder brauchen würde. mw.libs.dewiki.osm wäre eher (nur) etwas für Funktionen, die man später nochmals aufrufen muss; das ist hier aber wohl nie der Fall.
• Und wenn dann die L10N-Strings (nur einer = „Karte“?) für schlichte Projektadmins herausgezogen sind, wäre dies eine Variante, die man den OSMlern als Ersatz für die angesprochenen Seiten anbieten kann.
• Wenn man eine später benutzbare Funktion vorhalten müsste, kann man aber mw.libs.OpenStreetMap als weltweit einheitliche Komponente setzen, die sich nur bei der Definition durch das lokale Projekt in L10N unterscheidet. Ein Andocken unter mw.libs.dewiki ist hier eher verwirrend.
• Später mal, wenn sich MW 1.19 beruhigt hat, könnte OSM für L10N auch eine Message definieren, die dann über mw.message() eingebunden werden kann; aber da würde ich abwarten. Dann wäre gleichzeitig ein mw.loader.implement(module, URL, style, msgs) anzustreben.

Schönen Abend --PerfektesChaos 22:03, 29. Jan. 2012 (CET)

Ja, richtig. Init wäre möglicherweise auch für LivePreview etc. interessant, aber dafür wirds in einiger Zeit schon noch einen Hook geben. Daher hab ich auch init noch aus dem global scope rausgenommen, die einzige öffentlich interessante Komponente wäre wohl $('#openstreetmap').toggle(). Ich werd den Code mal testen, sobald er auf deWP läuft kann man ihn immer noch internationalisieren. -- ✓ ^Bergi 22:41, 29. Jan. 2012 (CET)

Ihr könnte euch auch gerne auf dem Testwiki austoben. Berechtigungen sollten kein Problem sein, falls ihr es als Gadget ausprobieren wollt. Einfach hier mit dem entsprechendem Konto melden, dann lässt sich was machen. Der Umherirrende 19:51, 30. Jan. 2012 (CET)

akeytt()

// Diese Deklarationen 2013 löschen:
window.ta      =  [ ];
window.akeytt  =  function() {
   alert("Ein Skript benutzt die veraltete Funktion akeytt()." +
         "\nWenn du der Autor des Skripts bist, solltest du sie entfernen." +
         "\nWenn du nichts darüber weißt, kannst du auf [[WP:TSW]] nachfragen." +
         "\n-- de.WP");
};   // akeytt()

Siehe dazu WD:NEU. --PerfektesChaos 15:09, 29. Jan. 2012 (CET)

includePage

window.includePage  =  function(access) {
   alert("Ein Skript benutzt die veraltete Funktion includePage()." +
         "\nWenn du der Autor des Skripts bist, solltest du sie entfernen." +
         "\nWenn du nichts darüber weißt, kannst du auf [[WP:TSW]] nachfragen." +
         "\n-- de.WP");
   mw.loader.using("mediawiki.util",
                   function() {
                      mw.loader.load(mw.config.get("wgServer")
                                     + mw.util.wikiScript()
                                     + "?title="
                                     + mw.util.wikiUrlencode(access)
                                     + "&action=raw&ctype=text/javascript",
                                     "text/javascript");
                   });
};   // includePage()

• Block in MediaWiki:Common.js ersetzen.

--PerfektesChaos 15:09, 29. Jan. 2012 (CET)

mw.libs.dewiki

Zurzeit wird dies offenbar noch nicht benötigt; für die Zukunft empfehle ich aber:

• Einzelne globale Konfigurationsinformationen, die eine eigenständige Extension nicht lohnen und die von diesem Site-Script gesetzt werden, sollten in einem dann zu deklarierenden Objekt abgelegt werden:

mw.libs.dewiki  =  { };

• Sie sind dadurch dem global scope entzogen, eindeutig der dewiki als Verursacher zuzuordnen und vermeiden Namenskonflikte.
• Das Statement kann bereits auskommentiert im „deklarativen“ Kopfbereich eingefügt und erläutert werden.

--PerfektesChaos 15:09, 29. Jan. 2012 (CET)

mw.libs.dewiki für die Zukunft klingt sinnvoll. Das auskommentierte Einfügen ist der Deklaration aber nicht notwendig. Besser hier die Dokumentation ausarbeiten und dann Deklaration mit Beschreibungskommentar eingefügten, wenn benötigt. --Fomafix 16:26, 29. Jan. 2012 (CET)

Danke, dass es dir gefällt.

Was hier auf dieser Disku steht, versinkt in den Tiefen der Archivierung und ist irgendwann untergegangen. Blubb.

Was auskommentiert im Quellcode steht, wird vom Minifier herausgefischt, dieser schreibt danach bei bits. in den Cache und niemand wird mit einem Kommentar belästigt. Dort ist es aber an prominenter Stelle für jeden von einem Dutzend potentieller Programmierer sichtbar, die gerade mal wieder eine globale Variable hineinschreiben wollen.

LG --PerfektesChaos 17:17, 29. Jan. 2012 (CET)

Mir ist schon klar, das Kommentare rausminimiert werden. Ich sehe MediaWiki:Common.js aber nicht als Programmieranleitung, sondern die Kommentare sollten nur den Quellcode dort erklären. --Fomafix 17:35, 29. Jan. 2012 (CET)

secure.wikimedia.org

Mit gerrit:13429 werden seit 14. November 2012 alle besuchten Seiten-URL mit secure.wikimedia.org über die Weiterleitung hinaus umgeschrieben auf die entsprechende neue Adresse. Damit kann keine besuchte Seite sich selbst mehr als secure.wikimedia.org ansehen.

Nachdem sich das einige Tage als stabil erwiesen hat, kann der entsprechende Code entfernt werden.

Liebe Grüße --PerfektesChaos 11:25, 15. Nov. 2012 (CET)

ist entfernt. Der Umherirrende 09:21, 17. Nov. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 09:21, 17. Nov. 2012 (CET)

globale Variablen Link_FA/Link_GA

Die 6 var zu Link_FA/Link_GA können mitsamt aller Kommentare ein Dutzend Zeilen tiefer in die anonyme Funktion mw.loader.using(... verschoben werden und verschwinden damit aus dem global scope. Es hätte auch kaum ein Benutzer noch die Chance, sie individuell umzudefinieren. LG --PerfektesChaos 18:33, 15. Nov. 2012 (CET)

Wenn ein Benutzer sich aus den Sternchen Kuller machen möchte, müsste er das am fertigen DOM machen; in die fortschreitende Initialisierung kann sich kein Benutzerskript mehr hineindrängeln.

Und übrigens gibt es diese Sternchen eigentlich nur im ANR, während es ungesternte Interlanguage auch in anderen NR geben mag. Also kann dieser komplette Block dann auch in eine entsprechende Abfrage eingepackt werden.

Zurück zu der Frage nach jQuery, die oben am ursprünglichen Diskussionspunkt aufgeworfen war: Eigentlich war vor einer Weile angedacht gewesen, mit dem RL2 und seiner hidden-Option diesen Block sortiert zu verschieben. Da von dort seit Juni 2011 nichts mehr zu sehen war, könnte man andere Überlegungen zur Strukturierung anstellen; etwa auch ein OnlyIfArticle.js oder ein OnlyIfFile.js nachladen und diese separaten Module nach aktuellen Sitten neu zu schreiben. Eigentlich nur eine Routine-Programmierarbeit; die Mühe liegt beim Austesten und meine Warteschlange ist lang.

LG --PerfektesChaos 21:02, 15. Nov. 2012 (CET)

Ist verschoben. Der Umherirrende 14:43, 17. Nov. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 14:43, 17. Nov. 2012 (CET)

withJS

Auf Commons kann man mittels des URL-Parameter withJS ein Script auslesen und starten (mehr Informationen, testen). Ich fände diese Funktionalität auch hier ganz praktisch, um Ladezeit-intensive Gadgets (z. B. Rechtschreibprüfung oder BKL-Check) nur bei Bedarf via Klick auf ein spez. Tab zu aktivieren. Auf Commons wird es beispielsweise in Commons:Template:BotMoveToCommons verwendet. Vielleicht gibt es hier auch Vorlagen, wo so etwas hilfreich wäre.
Was meint ihr? --Leyo 16:07, 13. Mai 2010 (CEST)

Echt keine Meinungen, Einwände, …? --Leyo 14:31, 16. Jul. 2010 (CEST)

Nu ja, so ganz happy bin ich erst mal damit nicht..... hab aber vergessen, hier zu senfen.

Bedenken habe ich, weil man so in einem Link jemandem JavaScript "unterschieben" kann. Wenn der Link lang genug ist, fällt das auf den ersten Blick nicht auf. Und je nachdem, wie "withJS" programmiert ist, kann das ganz schön ins Auge gehen - die einbindbaren Codeschnipsel müssten schon "Admin-Only" sein UND auf Nebeneffekte geprüft.

Wir hatten ja schon den Spass mit dem (weit verbreiteten) PDD-Monobook, dem AutoSave und einem Link, der Admins (wenn sie drauf klickten) zum Hauptseitenvandalen machte. Wenn man das jetzt noch mit "eigenem Code" und bei jedem machen kann..... ich weiss nicht.

Mag sein, dass ich da etwas ZU paranoid bin, aber Begeisterungsstürme löst diese Idee bei mir nicht aus. --Guandalug 14:36, 16. Jul. 2010 (CEST)

Danke für die Antwort. Ich verstehe die Bedenken, hoffe aber, dass es dazu eine Lösung gibt. Vielleicht ein passender Missbrauchsfilter, der IPs und neuen Benutzern das Posten solcher Links verbietet? Wenn ich mich erinnere, gab es bei Commons mal Probleme mit Autosave. Die sind aber gelöst soweit ich weiss. Die entsprechenden Diskussionen finde ich gerade nicht. --Leyo 14:44, 16. Jul. 2010 (CEST)

Commons hat es mit einer Einschränkung auf den MediaWiki - Namespace gelöst. AutoSave MUSS dort dann geschützt werden, müsste man nur drauf aufpassen. Ob es DAS Wert ist? --Guandalug 14:58, 16. Jul. 2010 (CEST)

Für Ladezeit-intensive Gadgets wie Rechtschreibprüfung oder BKL-Check wäre ja eine solche Beschränkung kein Problem. --Leyo 15:30, 16. Jul. 2010 (CEST)

Ich glaube nicht es es sich lohnt, den BKL-Check mit diesem Parameter einzubinden. Dieser Parameter ist nur dann sinnvoll, wenn man eine neue Seite mit einem speziellen JavaScript aufrufen möchte, wie es bei "BotMoveToCommons" auf Commons der Fall ist (Aufruf des Bearbeitenfenster). Für den BKL-Check könnte man höchstens einen Button/Link ergänzen, der auf der aktiven Seite das Script einbindet/ausführt. Das durch den Aufruf keine (Speicher-)Aktion ausgeführt werden soll, versteht sich ja zum Glück von selbst. Der Umherirrende 20:05, 16. Jul. 2010 (CEST)

Ich verstehe dein Statement nicht ganz, sorry. Es geht mir ja darum, zu ermöglichen z.B. den BKL-Check auf ähnliche Weise auszuführen wie die Fehlersuche oder den Weblink-Check, nämlich mittels Klick auf ein Tab. --Leyo 20:15, 16. Jul. 2010 (CEST)

Es ist möglich, nur muss dafür ja nicht die aktuelle Seite neugeladen werden, sondern auf der aktuellen Seite könnte das Skript einfach nach dem Tab/Button-Klick ausgeführt werden, dann spart man sich ein wenig Traffic, vorallem, wenn es eh schon "Ladezeit-intensive Gadgets" sind. Der Umherirrende 20:28, 16. Jul. 2010 (CEST)

Wenn ich beispielsweise BKL-Check-Gadget aktiviert habe, so wird jeder geladene Artikel untersucht. Ich möchte aber nur in bestimmten Fällen (< 5 %) Artikel auf BKLs überprüfen und möchte dann auf ein Tab klicken und nicht in die Einstellungen gehen, das Gadget aktivieren, den Artikel neu laden und am Ende das Gadget in den Einstellungen deaktivieren. Ist mein Anliegen so verständlich? --Leyo 15:04, 15. Aug. 2010 (CEST)

*ping* --Leyo 17:39, 5. Jan. 2011 (CET)

Für das Laden eines Scripts nur bei Bedarf, bei Druck auf einen Knopf/Tab/Link, ist keine eigene URL nötig. Wenn noch Interesse besteht, mal in der Skinwerkstatt nachfragen. -- ✓ ^Bergi 02:58, 24. Feb. 2012 (CET)

Naja, es soll nicht etwas für einzelne Benutzer sein, sondern für alle bzw. bestimmte Benutzergruppen. Zwei Beispiele:

• Mittels Logs-Filter-Gadgets gefilterte Ergebnisse können mit andern Benutzern (inkl. IPs) geteilt werden (Beispiel).
• Bei Sichtungsseiten könnte per Klick die tatsächlich noch nicht (nach)gesichteten Seiten markiert werden. Benutzer:P.Copp/scripts/markunreviewed.js müsste dafür in ein Gadget umgewandelt werden.

--Leyo 10:53, 24. Feb. 2012 (CET)

Für das einmalige manuelle aktivieren eines Gadgets oder eines Benutzerskriptes kann – auch als anonymer Benutzer – ein Bookmarklet verwendet werden. Beispiel: javascript:void( importScript( 'Benutzer:Fomafix/Gadget-bkl-check.js' ) ) in die Adresszeile eingeben. Ein URL-Parameter withJS hingegen finde ich sicherheitstechnisch bedenklich. --Fomafix 14:27, 24. Feb. 2012 (CET)

1. Bergi hatte schon recht: Diese Dataildisku mit Anforderungsprofilen ist was für die TSW; hier wohl nicht gut aufgehoben.
2. Gegen einen withJS-Parameter wäre ich strikt; zum einen wegen der überhaupt nicht paranoiden Begründung von Guandalug, zum anderen wegen fehlender Wartbarkeit bei projektweiter Unterstützung. Wer das individuell mag, kann auf eigene Gefahr in seinem Benutzerskript einen derartigen Parameter abfragen und sonstwas damit anstellen.
3. Zur Ausgangsfrage nach dem individuellen Gadget-Start der Funktionscode für einen Button, damit das erstmal vom Tisch und die Erle in Sicht käme:

if (typeof(bklCheck) === "object") {
   jQuery(document).ready(bklCheck.execute);
} else {
   mw.loader.load("//de.wikipedia.org/w/index.php?title=MediaWiki:Gadget-bkl-check.js&action=raw&ctype=text/javascript");
}

Wobei sich beim ersten Zweig einwenden ließe, dass du wohl kaum auf einen Button drücken könntest, wenn document.ready nicht schon gegeben wäre; aber der geistigen Vollständigkeit halber – es schadet auch nicht sehr.

Bald ist Wochenende, Gruss --PerfektesChaos 11:22, 24. Feb. 2012 (CET)

Zu 2: Bist zu bei deinem Votum von einer Einschränkung auf den MediaWiki-NR, auf „MediaWiki:Gadget-…“ oder ev. sogar einzelne Gadgets ausgegangen? --Leyo 11:37, 24. Feb. 2012 (CET)

Ganz grundsätzlich.

• Ein Sicherheitsproblem ließe sich zwar vermeiden, indem bei Bildung der URL für eine induzierte Ladeanweisung explizit der Namensraum vorangestellt bzw. abgeprüft wird.
• Die vorgeschlagene Methodik führt aber auch in vergangene Bastel-Zeiten vor die Monobook-Ära zurück. Mit FF10, mit MW 1.19, mit MW 1.20 werden Notwendigkeiten für Änderungen kommen, die immer mehr alte Techniken ausknocken. Wenn ich den BNR nach verdächtigen Zeichenketten durchsuche, kommen Hunderte von JS-Seiten mit Treffern heraus. Durch Einsatz des Umherirrenden in den letzten Wochen ist der zwangsweise ausgeführte Teil des MediaWiki-NR jetzt grade reif für die Umstellung auf MW 1.19 geworden. Die Gadgets sind noch weit davon entfernt; aber die kann man sich ja wegklicken, wenn sie rumspinnen.
• Auch für die Gadgets unterstützt withJS die Versionierung durch den ResourceLoader2 nicht.
• Für eine individuelle q&d-Pfriemelei mag sich jeder selbst so eine URL-Auswertung bauen; ein unterstützbarer Weg für WMF-Projekte mit dem Anspruch der Benutzer auf Wartung und Pflege der einmal bereitgestellten Features ist es nicht.

VG --PerfektesChaos 12:20, 24. Feb. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Leyo 10:57, 5. Dez. 2012 (CET)

NavFrame collapsed

Es gibt ja die Klasse "NavFrame", mit der man zusammen mit "NavHead" und "NavContent" eine Navigationsleiste zusammenbauen kann. Diese Navigationsleisten sind standardmäßig aufgeklappt, wenn sie "alleine" dastehen. Zwei hintereinander eingebunden Leisten werden dann als eingeklappt angezeigt.

Es gab schon in der Vergangenheit mehrere Anfragen, ob man denn eine Navigationsleiste nicht standardmäßig auf "Eingeklappt" stellen könnte, so dass sie beim Laden der Seite schon eingeklappt ist. In den meisten Wikipedias wird das durch den Zusatz "collapsed" hinter dem "NavFrame" gelöst.

Sowas wäre hier für die deutsche Wikipedia auch hilfreich. --weltforce (Diskussion) 18:10, 13. Aug. 2012 (CEST)

Anmerkung: auch bei der Klasse mw-collapsible hilfreich (mw-collapsible collapsed). --weltforce (Diskussion) 16:03, 19. Aug. 2012 (CEST)

Für mw-collapsible gibt es das schon mit mw-collapsed, siehe mw:Manual:Collapsible elements. Der Umherirrende 17:24, 19. Aug. 2012 (CEST)

Oh stimmt. Hab das mw- vor dem collapsed vergessen. Bleibt damit aber noch das NavFrame collapsed. --weltforce (Diskussion) 19:48, 19. Aug. 2012 (CEST)

Wäre dann eher für NavCollapsed, aber am Namen sollte es wohl nicht liegen. Da aber NavFrame eigentlich nur innerhalb der {{Navigationsleiste}} anwendung finden sollte, wäre es eigentlich auch unnötig, aber das Thema ist wohl schwierig. Der Umherirrende 20:37, 19. Aug. 2012 (CEST)

Es ist ganz und gar nicht unnötig. Ich habe schon mehrmals Tabellen gesehen, die mit Navigationsleisten ein- und ausgeklappt werden. Viele wollen, dass der Ausgangszustand dabei schon eingeklappt ist. --weltforce (Diskussion) 07:37, 20. Aug. 2012 (CEST)

Viele? --Leyo 11:37, 20. Aug. 2012 (CEST)

Definiere "viele" als wieviel du willst, es geht aber nicht darum, dass das Feature wegen dringendem Bedarf aktiviert werden soll, sondern da mittlerweile solche Feinheiten Standard sind und sicherlich produktiven Nutzen finden werden. Ich könnte jetzt schon auf Aufhieb mehrere Nennen. Es spricht wirklich nichts dagegen. --weltforce (Diskussion) 16:04, 20. Aug. 2012 (CEST)

Weltforce (bzw. Intforce), hör mal auf hier ständig angebliche Verbesserungen zu wünschen, die es angeblich in vielen anderen Wikipedias gibt und die angeblich sinnvoll sind. Wir schreiben eine Enzyklopädie und kleben sie nicht aus Boxen und Leisten zusammen. Und zum konkreten Vorschlag: Entweder etwas ist wichtig, dann gehört es ganz normal, und nicht eingeklappt (und auch nicht einklappbar) in den Artikel, oder es ist nicht wichtig, dann kanns ganz draußen bleiben. Steak 14:33, 24. Aug. 2012 (CEST)

Ich wünsche weder ständig Verbesserungen noch bestreite ich, dass wir eine Enzyklopädie schreiben. Und wenn es zum konkreten Vorschlag kommt: wenn du dich mal umschaust, werden Navigationsleisten oft als Aufklappelement benutzt. Wir haben hier in der deutschen Wikipedia aus irgendeinem Grund nur autocollapse aktiviert, welches Boxen automatisch zusammenklappt, wenn mehr als 2 vor ihnen auf einer Seite vorhanden sind, es gibt aber noch elemente wie off und collapsed. Diese Funktionen existieren bei mw-collapsible, bei der wir freundlicherweise ein mw-collapsed mitimportiert haben. --weltforce (Diskussion) 14:58, 24. Aug. 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Leyo 16:53, 6. Dez. 2012 (CET)

InterProject

Nachdem die Portlet Links jetzt von h5 zu h3 geändert wurden (wahrscheinlich das heutige Update), sollten diese auch im relevanten Code für Vorlage:InterProjekt angepasst werden (sisterprojectnav.innerHTML = '<h5>'+document.getElementById("sisterProjects").firstChild.innerHTML+'</h5><div><ul></ul></div>';). --Steef ³⁸⁹ 22:57, 5. Dez. 2012 (CET)

Klingt sinnvoll. Habe ich mal geändert. Der Umherirrende 16:49, 6. Dez. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 16:49, 6. Dez. 2012 (CET)

"Neuen Abschnitt"-Link an der letzten Überschrift

Diese Funktion, die es bei de-WP seit einiger Zeit gibt, gefällt mir so gut, dass ich sie nach de-Wikibooks übernehmen wollte. Auf Meta habe ich nur den Wunsch nach dieser Funktionalität gefunden. Über Hilfe:Bearbeiten-Links#Neuer_Abschnitt hat mir PerfektesChaos den richtigen Weg genannt und bei der Umsetzung geholfen. Ich möchte mich auf diesem Weg bei PerfektesChaos und allen anderen Nutzern bedanken, die die MediaWiki-Software ergänzen und verbessern − konkret diese JS-Seite.   -- Jürgen (Diskussion) 10:06, 14. Mai 2013 (CEST)

Bitte, gern geschehen.

Tipp: WP:TSW.

@Admin.dewiki: Auf b:Wikibooks:Ich brauche Hilfe #Abschnitt hinzufügen steht ein etwas moderner formatierter Quellcode. Soweit ich sehen kann, ist das mw- auf den hier relevanten Seiten schon überall angekommen, so dass wir bereits aus diesem Anlass diesen Block upgraden können und nicht bis zum 7. Juni warten müssen.

Viele Grüße --PerfektesChaos 11:03, 14. Mai 2013 (CEST)

Nein, ich denke nicht, das der komplette Cache bereits einmal neu erstellt wurde, denke auch an IPs und Artikeldiskussionseiten, die weniger häufiger besucht werden. Dort dürfte sich noch ein editsection (also ohne mw-) finden. Daher sollte bis zum 7. Juni gewartet werden. Man kann nicht an anderer Stelle Abwärtskompatibilität fordern, um sie hier wieder zu vernachlässigen. Auch wenn es nur ein Link ist. Ich würde das alles zusammen aufräumen. Monobook.js und Vector.js können nämlich zur gleichen Zeit bereinigt werden. Der Umherirrende 16:57, 14. Mai 2013 (CEST)

Ist jetzt lokal bereinigt. Der Umherirrende 21:00, 10. Jun. 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 21:00, 10. Jun. 2013 (CEST)

AFT-Hack

Meiner Ansicht nach sollte der AFT-Hack in ein

(function(){
//...
})();

eingepackt werden. Einfach mal eine Handvoll globale Variablen erzeugen ist schon kein guter Stil, aber dann noch solche mit so konfliktträchtigen Namen wie article sollte nun wirklich nicht sein. --Schnark 09:30, 8. Jun. 2013 (CEST)

Eingepackt. Der Umherirrende 20:56, 10. Jun. 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 20:56, 10. Jun. 2013 (CEST)

AFT-Hack entfernen

Der AFTv5-Hack könnte auch mal wieder entfernt werden. Der Cache müsste seit mindestens 2 Wochen in Ordnung sein.--se4598 / ? 20:32, 24. Jul. 2013 (CEST)

Stimmt, ist entfernt. Der Umherirrende 20:37, 24. Jul. 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 20:37, 24. Jul. 2013 (CEST)

Johannes Kroll (WMDE)/Limestest/limesEmbed.js

Ich verwahre mich gegen die erneute Zwangsausführung dieses Blocks beim Lesen aller Seiten durch alle Benutzer.

• Sowas gehört in ein Benutzerskript (was es ja auch ist) und durch Interessierte eingebunden.
  • Wenn es von so projektweiter Bedeutung ist, dann notfalls als Gadget durch einfaches Ankreuzen aktivierbar.
  • Weil es aber nur auf Benutzerseiten und nicht im ANR ausgewertet werden kann, kann es nur auf ganz bestimmten Benutzerseiten und durch besonders Interessierte gelesen werden. Diese mögen sich dann selbst um ihr Zeugs kümmern.
• Die Programmierung auf Common.js ist stümperhaft: Man vergleicht nicht die Zeichenkette wgCanonicalNamespace, sondern die Ganzzahl wgNamespaceNumber. (Und wer Ahnung hat, nimmt drei statt nur zwei Gleichheitszeichen)
• Die Programmierung im Benutzerskript ist mehrere Jahre hinter der Zeit zurückgeblieben:
  • addOnloadHook
  • Verseuchung des globalen Namensraums
  • Triviale Namen mit dem Risiko des Namenskonflikts (schadet mir nicht; weil Benutzer später kämen)
  • Völliges Fehlen jeder Dokumentation; auch völliges Fehlen jeder Erklärung, warum und für wie lange Zeit dieser Test hier aktiviert bleiben soll.
  • Bereits einmal offenkundig gewordenes Sicherheitsproblem; auch weil völlig im Dunkeln bleibt, was wie mit welchen Ressourcen anschließend passiert.
• Der Umherirrende hatte beim Hexer bereits nachgefragt, was das solle, aber keine Antwort erhalten.
• Wenn WMF/WMDE Schwierigkeiten haben, ordnungsgemäß Javascript zu programmieren, können sie gern in der WP:TW nach Beratung fragen.

Es scheint neuerdings Mode zu werden, die Benutzer der WP durch WMF/WMDE ungefragt als Versuchskarnickel für irgendwelche Software-Tests zu missbrauchen; hier tools.wmflabs.org/render-tests/limes-git.

Verärgert --PerfektesChaos 11:38, 11. Aug. 2013 (CEST) +kl 11:52, 11. Aug. 2013 (CEST)

Wurde entfernt. Der Umherirrende 20:49, 4. Nov. 2013 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 20:49, 4. Nov. 2013 (CET)

class="noscript" nach common.css verschieben?

Wäre es evtl. sinnvoll, die Definition dieser Klasse in Form einer Regel

.client-js .noscript {
	display: none;
}

nach MediaWiki:Common.css zu verschieben? Als Vorteile sehe ich die Übersichtlichkeit (die anderen projektspezifischen Klassen wie hintergrundfarbeX, toptextcells usw. sind auch dort versammelt) und die Tatsache, dass der zu versteckende Text wirklich von Anfang an versteckt ist (und nicht etwa beim Laden der Seite für einen kurzen Moment aufblitzt, wie es zurzeit der Fall ist).

Gibt es Nachteile? (Und: Wird die Klasse überhaupt wirklich benötigt?) --Entlinkt (Diskussion) 02:06, 28. Sep. 2013 (CEST)

Es gibt auch noch MediaWiki:Noscript.css, aber das obrige sieht auch gut aus. Keine Ahnung, wer die haben wollte und wer sie braucht. Der Umherirrende 08:21, 28. Sep. 2013 (CEST)

Langsam erinnere ich mich wieder, die Klasse wurde in Hilfe:Tabellen benutzt, aber nur ein gutes halbes Jahr lang, bis sie wieder rausgeworfen wurde (von mir), trotzdem wurde sie in dieser Zeit in zahlreiche Artikel kopiert (meist inklusive Kommafehler und merkwürdigem Wortlaut „JavaScript muss aktiv sein um nach anderen Spalten sortieren zu können“, z. B. in Liste der Synagogen in Deutschland; man sieht dort auch sehr schön das kurze Aufblitzen bei aktiviertem JavaScript). Google findet momentan 66 Verwendungen.

An sich könnte sie sinnvoll sein, wenn man sie sparsam einsetzt (also nicht bei x-beliebigen sortierbaren Tabellen, sondern nur dann, wenn im Fließtext speziell auf die Sortierbarkeit eingegangen wird und das auch sinnvoll ist). Da sie aber in Verwendung ist, muss sie sowieso bleiben. Ich werde sie dann mal nach common.css verschieben (MediaWiki:Noscript.css wäre wohl besser, aber damit kann man m E. nur die umgekehrte Logik implementieren). --Entlinkt (Diskussion) 09:07, 28. Sep. 2013 (CEST)

Als Anmerkung: Siehe auch bugzilla:45731. --Schnark 09:18, 28. Sep. 2013 (CEST)

Dankeschön, das ist ja sogar genau derselbe Code.

Die Formulierung mit den „anderen Spalten“ stammt übrigens von dieser Benutzerseite (vgl. Diskussion) und ist dort auch sinnvoll, in den meisten anderen Fällen aber nicht.

Ich habe die Definition mittlerweile in common.css eingefügt. Kann die Definition hier sofort entfernt werden oder muss man damit warten, bis alle Caches geleert sind? --Entlinkt (Diskussion) 09:37, 28. Sep. 2013 (CEST)

• Vermutlich hatte es damals die .client-js noch nicht gegeben, als das hier reinkam.
• Ob es gegen das Aufblitzen hilft, wäre ich mir nicht so sicher: Auch die .client-js wird in resources/mediawiki.page/mediawiki.page.startup.js durch JS erst generiert und damit auch eine Regel unter MediaWiki:Common.css erst nachträglich greifend. Auch wenn jene einen Tick eher passiert; beides wird im HEAD vor Aufbau des DOM gestartet.
  • Aber wir müssen das auf JS-Ebene nicht ein zweites Mal ausführen.
• Es scheint sich um eine frühe deWP-eigene Spezifikation zu handeln.
• Fertige Aufzählungen für display:none; zum Einfügen eines weiteren Selektors haben wir sowieso.
  • Auch wenn es übersichtlicher gegliedert wird: Eine zentrale und gemeinschaftlich kommentierte Liste von fünf und mehr ausgeblendeten Selektoren fände ich übersichtlicher (und einen Tick performanter) als fünf separate Regeln:

    /* Diverse Ausblendungen: * Dies * Das * Jenes */

• Die Ein-/Ausblendung von .noscript sollte prophylaktisch vorgehalten werden. Auf Artikel schreiben wir sowas nicht drauf; aber bei Projektseiten, Vorlagen, Hilfeseiten, Spezialseiten im Zusammenhang mit Werkzeugbenutzung kann es gelegentich ausgenutzt werden (etwa auf Hilfe:Einstellungen oder Spezial:Einstellungen#mw-prefsection-gadgets eingeblendet werden, dass der Benutzer JS deaktiviert habe und deshalb dies und jenes zurzeit nicht funktionieren würde.)
  • MediaWiki:Noscript.css kannte ich noch nicht. Es wäre jedoch logisch diametral wirkungslos, dort unterzubringen:

    .client-js .noscript { display: none; }

  • Dort könnte höchstens hinein:

    div.noscript { display: block ! important; }

    span.noscript { display: inline ! important; }

  • Aber vielleicht gibt es eine Gegen-Systemnachricht wie MediaWiki:Script.css.
• Eigentlich ist das Simulieren des verbotenen <noscript> eine zentrale Aufgabe, die bereits das weltweite CSS anbieten sollte; steht es da möglicherweise schon irgendwo drin?

Schönes Wochenende --PerfektesChaos 09:47, 28. Sep. 2013 (CEST)

Das Aufblitzen ist zumindest laut meinen Tests tatsächlich gelöst, vgl. auch bugzilla:30497#c2 und rev:103905 (wenn <body> zu diesem Zeitpunkt noch nicht verfügbar ist, muss das wirklich extrem früh ausgeführt werden).

Die common.css muss sowieso noch sehr viel logischer gegliedert werden, über die Zusammenfassung von Selektoren kann man sich dann Gedanken machen. --Entlinkt (Diskussion) 09:58, 28. Sep. 2013 (CEST)

Die Aufblitzerei kam wahrscheinlich daher, dass erst das Laden von 'mediawiki.util' abzuwarten war; die beiden JS-Aktionen hingegen grundsätzlich fast zeitgleich ausgeführt wurden. Das direkte jQuery-Einfügen von .client-js in das HTML-Element passiert hingegen sofort. Linksrutsch:

Zur umseitigen Aufräumaktion melde ich schon mal Wünsche an:

• Alle FR auf einem Haufen
• Alle table auf einem Haufen
• Alle TOC auf einem Haufen
• Lose Einzelregeln bündeln:

/* Diverse Ausblendungen
 *    #***-icon etc., .topicon
 *       Skinabhängige absolute Positionierungen
 *       [[MediaWiki Diskussion:Common.css/Archiv 1#Absolute Positionierungen]]
 *    .patrollink
 *       Eweiterung ist hier nicht aktiviert
 *       Optik ähnelt zu sehr den gesichteten Versionen
 *    .mw-special-Watchlist .mw-rollback-link
 *       Rollback-Knopf auf Beobachtungsliste
 *       dort nur von sehr beschränktem Nutzen
 *       führt zu sehr vielen Reverts aus Versehen
 *    .geo
 *       [[Vorlage:Coordinate]]
 *       "geo-microformat" zur semantischen Auszeichnung des Texts
 *       Inhalt dieses Tags ist nicht für den Leser bestimmt
 *    .limitreport
 *       [[Hilfe:Vorlagenbeschränkungen|Parser-Profiling-Daten]]
 *    .client-js .noscript
 *       <noscript>-Emulation via <div class="noscript"></div>
 */
#commons-icon,
#coordinates,
#editcount,
#issnlink,
#shortcut,
#spoken-icon,
.topicon,
.patrollink,
.mw-special-Watchlist .mw-rollback-link,
.geo,
.limitreport,
.client-js .noscript {
   display: none;
}

Viel Spaß --PerfektesChaos 13:10, 28. Sep. 2013 (CEST)

noscript wurde verschoben, die logische Gliederung von common.css sollte auf MediaWiki Diskussion:Common.css angesprochen werden. Bitte bei Bedarf rüberkopieren. Danke. Der Umherirrende 20:53, 4. Nov. 2013 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 20:53, 4. Nov. 2013 (CET)

Wunschzettel

In Anbetracht der angekündigten Änderungen an MediaWikis Javascript habe ich folgende Wünsche:

1. Die Zeilen zur Definition von includePage sollten ersetzt werden durch

mw.log.deprecate( window, 'includePage', importScript, 'includePage ist veraltet, verwende stattdessen importScript. Die Funktion includePage wird hier zeitgleich mit der Einführung von MediaWiki 1.23 entfernt.' );

Damit erhalten die verbliebenen Nutzer dieser Funktion im Debug-Modus eine Warnung, ansonsten ändert sich (noch) nichts. In 1.23 werden so viele alte Funktionen entfernt, dass mit dem Entfernen von includePage wohl nichts zusätzlich kaputt gehen wird.

2. Da jquery.ui.button nicht mehr automatisch geladen werden soll, aber auf einigen Seiten verwendet wird, schlage ich vor, folgenden Code zu ergänzen:

//jquery.ui.button laden, falls Klasse ui-button auf Seite verwendet wird
mw.hook( 'wikipage.content' ).add( function ( $content ) {
	if ( $content.find( '.ui-button' ).length ) {
		mw.loader.load( 'jquery.ui.button' );
	}
} );

3. MediaWiki:Common.js/watchlist.js verwendet getElementsByClassName, und muss daher sehr bald modernisiert werden, bitte auf Wikipedia:Technik/Werkstatt#MediaWiki:Common.js/watchlist.js vorbeischauen.

4. MediaWiki:Onlyifediting.js verwendet addOnloadHook, und sollte daher modernisiert werden, bitte auf MediaWiki Diskussion:Common.css#Sammelsurium unter dem Bearbeitungsfenster vorbeischauen. Benutzer mit eigenen Skripten, die nach Verwendungen von veralteten Funktionen Ausschau halten, sollten nicht auch noch Warnungen bekommen, für die sie nichts können.

5. Benutzer:Johannes Kroll (WMDE)/Limestest/limesEmbed.js verwendet ebenfalls addOnloadHook, und ich sehe auch nicht ein, warum irgendein Alpha-Test für alle Benutzer geladen werden soll. Meiner Ansicht nach sollte diese Einbindung ganz entfallen, wenn es unbedingt sein muss, kann ein Gadget daraus gemacht werden. --Schnark 09:39, 4. Nov. 2013 (CET)

Punkt 5 ist erledigt. Der Umherirrende 20:50, 4. Nov. 2013 (CET)

Punkt 4 ist im Zuge einer anderen Änderung erledigt. Gruß --Entlinkt (Diskussion) 21:32, 4. Nov. 2013 (CET)

Nur um noch mal auf die Dringlichkeit hinzuweisen: Mit der für den 7. November geplanten Aktualisierung wird /watchlist.js in der augenblicklichen Form nicht mehr funktionieren, und es wird nicht möglich sein, die beiden Meldungen auszublenden, weil die Funktion getElementsByClassName einfach ein leeres Array zurückliefern wird. --Schnark 12:22, 5. Nov. 2013 (CET) PS: Wollen wir Wetten darauf abschließen, wer sich als erster darüber beschweren wird, dass die Navigations-Popups nicht mehr funktionieren?

Punkt 3 durch TMgs minimalen Patch erledigt. --Entlinkt (Diskussion) 04:35, 6. Nov. 2013 (CET)

Habe Puntk 1 auch entfernt, erstmal ohne Zeitangabe, keine Ahnung, wie lange der Rest der jetzt deprecated wurde, bleibt, aber da kann man sich orientieren. Der Umherirrende 20:15, 8. Nov. 2013 (CET)

Punkt 2:

• Ein kontextabhängiges load statt blindem immer-load würde ich begrüßen, und es scheint mir den kleinen Rest-Aufwand für immer-Durchsuchen zu rechtfertigen. Insofern sogar ein Fortschritt gegenüber dem bisherigen immer-load von MW.
• Ich stecke in dem UI-Zeugs nicht so drin. Welche Arten von Seiten, Benutzereinstellungen oder Aktivitäten sind es denn, wo solche Elemente vorkommen?

Schönen Tag --PerfektesChaos 10:12, 8. Nov. 2013 (CET)

Punkt zwei sollte zumindest als Übergangslösung umgesetzt werden bis eine endgültige Entscheidung getroffen ist, da seit gestern etliche Buttons auf Projektseiten wie WP:Fragen zur Wikipedia, WP:Grafikwerkstatt, WP:WikiProjekt Vorlagen/Werkstatt fehlen (der reine Textlink ist zum Glück noch vorhanden).

Hier habe ich einige Alternativen zusammengefasst die als langfristige Lösung in Frage kommen. --Patrick87 (Diskussion) 14:11, 8. Nov. 2013 (CET)

Ich habe es mal ergänzt. Schön ist es aber nicht, weil man immer noch sieht, das es erst später eintrifft, aber das war vorher ja auch schon so. Der Umherirrende 12:44, 10. Nov. 2013 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 12:44, 10. Nov. 2013 (CET)

gerrit:94270: Rename mw.util.wikiGetlink to getUrl.

Mit gerrit:94270 (Rename mw.util.wikiGetlink to getUrl) wurde mw.util.wikiGetlink() durch mw.util.getUrl() ersetzt. Die Funktion wird hier einmal verwendet und sollte bei Gelegenheit ersetzt werden. --Fomafix (Diskussion) 15:07, 14. Nov. 2013 (CET)

erledigt. Der Umherirrende 17:21, 14. Nov. 2013 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 17:21, 14. Nov. 2013 (CET)

Deaktiviert …, da Ressourcen von externen Webseiten geladen werden (Verstoss gegen Datenschutz Policy)

Bitte ebenso die Verwendung von OpenStreetMap in Wikipedia. entfernen, da Ressourcen von u.U. http://maps.google.com/ (z.B. mapfiles/kml/shapes/placemark_circle_highlight.png) und openstreetmap.org geladen werden. Danke! -- RE rillke fragen? 10:19, 8. Aug. 2013 (CEST)

Wenn ich bei einem Geo-Artikel auf die OSM-Schaltfläche bei den Koordinaten klicke, zeigt FireFox mir keine Quelle google.com an. Oder muss es dafür ein bestimmter Artikel sein?

Wenn das so ist, solltest du Kolossos mal ansprechen, da gibt es vermutlich Alternativen oder er muss sich um alternativen kümmern. Der Umherirrende 12:50, 10. Nov. 2013 (CET)

Scheint sich erledigt zu haben. Vorher wurde z.B. http://maps.google.com/mapfiles/kml/shapes/placemark_circle_highlight.png irgendwie eingebunden. -- RE rillke fragen? 23:38, 3. Dez. 2013 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: RE rillke fragen? 23:38, 3. Dez. 2013 (CET)

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)

getElementsByClassName wird nicht mehr genutzt. Der Umherirrende 19:20, 8. Feb. 2015 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 19:20, 8. Feb. 2015 (CET)

Announced JavaScript change for badges implementation

Hi! I want to let you know that in near future badges will be deployed on Wikidata and the Wikipedias. They help us with displaying the good and featured article icons next to the sitelinks and will replace the javascript hack which is used at the moment together with the Link GA and Link FA templates. To avoid an overlap where the current system and the new feature conflict, I will add a minor fix to your Common.js which adds the class names to the interwiki links. This is part of my task as a global edit interface editor for the Wikidata team. Thanks, Bene* (Disk) 21:25, 11. Aug. 2014 (CEST)

Prima. Nur zu! --Howwi (Diskussion) 21:30, 11. Aug. 2014 (CEST)

Hat Bene* überhaupt das Recht unsere MediaWiki:Common.js zu bearbeiten? Ich meine, die ist ja jetzt superprotected und er gehört nicht zur Staff-Gruppe. --BHC (Disk.) 21:44, 11. Aug. 2014 (CEST)

Dann wird er doch merken das er nichts machen kann. --Alchemist-hp (Diskussion) 22:07, 11. Aug. 2014 (CEST)

Erstmal sorry, dass ich hier auf Englisch geschrieben habe, ich habe nur die gleiche Nachricht auf allen Projekten verteilt.

Dieses Problem sehe ich jetzt aber auch, denn auch als global edit interface editor kann ich natürlich keine super-protected Seiten bearbeiten. Allerdings finde ich, dass hier sowieso einiges aus dem Ruder gelaufen ist, sowohl bei der Foundation als auch bei der Community. -- Bene* (Disk) 23:45, 11. Aug. 2014 (CEST)

Ich habe ja noch die Hoffnung, dass, wenn ein JavaScript-Code für die korrekte Opt-in-Variante gefunden und implementierbar ist, dies auch getan wird und die Seite ihren superprotect-Schutz wieder verlieren wird … Grüße, —DerHexer (Disk., Bew.) 23:47, 11. Aug. 2014 (CEST)

Nach dieser klaren Absage? Ne, das wäre eine Kapitulation und aufgeben erden Erik und co. nicht wollen. --BHC (Disk.) 23:55, 11. Aug. 2014 (CEST)

@Bene*: Was genau hast du denn vor zu ändern? Meiner Meinung nach sollten wir den lokalen JavaScript-Code zu diesem Feature schnellstmöglich loswerden (möglichst komplett), aber es müsste geklärt werden, welche Icons benutzt werden sollen (die Icons sind in MediaWiki:Common.css und MediaWiki:Cologneblue.css festgelegt). --Entlinkt (Diskussion) 23:52, 11. Aug. 2014 (CEST)

Der JavaScript Code wird erstmal unabhängig vom Style so angepasst, dass sich die beiden Systeme nicht überschreiben. Dadurch vermeiden wir eine Übergangsphase, in der keine Icons sichtbar sind, oder sich die Systeme überlappen. Das ist erstmal der wichtigste Schritt, damit wir schließlich den Code ganz entfernen können, wenn die Migration der Link GA und Link FA Vorlagen abgeschlossen ist. -- Bene* (Disk) 00:04, 12. Aug. 2014 (CEST)

Vorlage:Link FA und Vorlage:Link GA wurden gelöscht, da die Daten von WikiData kommen, das zugehörige JS und CSS wurde entfernt. Der Umherirrende 19:18, 8. Feb. 2015 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 19:18, 8. Feb. 2015 (CET)

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)

Probleme seit 1.24wmf17

Seit der Aktivierung von MediaWiki 1.24wmf17 am 21. August 2014 wird beim Firefox 31 die OpenStreetMap-Funktion nicht mehr ausgeführt und es erscheint in der JavaScript-Konsole folgende Fehlermeldung:

ReferenceError: openStreetMapToggle is not defined

Jetzt muss etwas gemacht werden! Die einfachste Lösung ist, dass die Funktion openStreetMapToggle() als anonyme Funktion in den Abschnitt darüber integriert wird:

/**
 * Verwendung von OpenStreetMap in Wikipedia.
 * (c) 2008 by Magnus Manske, Released under GPL
 */
mw.loader.using( [ 'mediawiki.util' ], function() { $( function() {
  var c = $( '#coordinates' );
  if ( !c.length ) {
   return;
  }

  var a = c.find( 'a' );
  var geohack = false;
  for (var i = 0; i < a.length; i++) {
    var h = a[i].href;
    if (!h.match(/geohack/)) continue;
    if (h.match(/skyhack/)) continue;
    if (h.match(/_globe:/)) continue; // no OSM for moon, mars, etc
    geohack = true;
    break;
  }
  if ( !geohack ) {
   return;
  }

  var separator = $( document.createElement( 'span' ) );
  separator.text( ' | ' );
  separator.attr( 'class', 'noprint coordinates-separator' );
  c.append( separator );
  var img = $( document.createElement( 'img' ) );
  img.attr( {
   'src': '//upload.wikimedia.org/wikipedia/commons/thumb/c/c9/OpenStreetMapLogo.png/17px-OpenStreetMapLogo.png',
   'width': '17px',
   'height': '17px'
  } );
  var a = $( document.createElement( 'a' ) );
  a.attr( {
   'href': '#',
   'title': 'Zeige Koordinaten auf einer Karte von OpenStreetMap',
   'class': 'noprint osm-icon-coordinates'
  } );
  a.click( function () {
   var c = $( '#coordinates' );
   if ( !c.length) {
    return;
   }
   var cs = $( '#contentSub' );
   var osm = $( '#openstreetmap' );

   if ( cs.length && osm.length ) {
    if ( osm.css( 'display' ) === 'none' ) {
     osm.css( 'display', 'block' );
    } else {
     osm.css( 'display', 'none' );
    }
    return false;
   }

   var found_link = false;
   var a = c.find( 'a' );
   var h;
   for (var i = 0; i < a.length; i++) {
    h = a[i].href;
    if (!h.match(/geohack/)) continue;
    found_link = true;
    break;
   }
   if ( !found_link ) {
    return; // No geohack link found
   }

   h = h.split('params=')[1];

   var url = '//tools.wmflabs.org/wiwosm/osm-on-ol/kml-on-ol.php?lang=de&uselang='
           + mw.util.rawurlencode( mw.config.get( 'wgUserLanguage' ) )
           + '&params=' + h
           + '&title=' + mw.util.wikiUrlencode( mw.config.get( 'wgTitle' ) );

   var iframe = $( document.createElement( 'iframe' ) );
   iframe.attr( 'id', 'openstreetmap' );
   iframe.css({
    'width': '100%',
    'height': '350px',
    'clear': 'both'
   });
   iframe.attr( 'src', url );
   cs.append( iframe );
   return false;
  });
  a.append( img );
  c.append( a );
})});

--Fomafix (Diskussion) 13:27, 22. Aug. 2014 (CEST)

done - please verify that it works. --Tgr (WMF) (Diskussion) 17:41, 22. Aug. 2014 (CEST)

Thanks. It works again. --Fomafix (Diskussion) 17:44, 22. Aug. 2014 (CEST)

OSM ist jetzt ein Gadget. Der Umherirrende 21:12, 17. Jul. 2015 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 21:12, 17. Jul. 2015 (CEST)

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)

Zähler ist über die "Seiteninformationen" verfügbar, dort wird er auch gecachet, so dass die Server nicht schmelzen müssen. Der Umherirrende 21:09, 17. Jul. 2015 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 21:09, 17. Jul. 2015 (CEST)

Abschalten MV

Gemeldet in Bugzilla
Bug 69292 Resolved “won’t fix”

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

Mit Drohungen werdet ihr nichts erreichen. Setzt den Willen der Community um und niemand hat ein Problem. --DaB. (Diskussion) 13:48, 10. Aug. 2014 (CEST)

Deine Lösung bricht den Opt-in und ist damit nicht in line mit dem Meinungsbild. Wenn man das wirklich deaktivieren möchte, dann bitte ordentlich über die mediawiki-configuration. Grüße, Hoo man (Diskussion) 13:54, 10. Aug. 2014 (CEST)

+1 Wie kann ich es wieder einschalten? --elya (Diskussion) 14:52, 10. Aug. 2014 (CEST)

In dieser Situation nicht, da der umseitig eingefügte Code den Mediaviewer in deWP vollständig blockiert. Viele Grüße Patrick Stützel (Diskussion) 15:03, 10. Aug. 2014 (CEST)

Opt-in Lösung: Jemand (ein Admin mit Gadget-Erfahrung) muss einfach besagte Zeile in eine Gadget-Seite setzen und das Gadget dann auf default setzen und schon kann jeder in den Einstellungen den MV Aus-/Anschalten (hat auch jemand so auf Commons erwähnt).

PS: IMO halte ich es eh für intuitiver die Option da zu suchen. Nachträglich könnte man das Gadget noch dahin erweitern, dass es auch die "normale" Option für den MV ebenfalls manipuliert. → User: Perhelion 15:23, 10. Aug. 2014 (CEST)

Keine Ahnung ob man die normale Einstellung per js manipulieren kann, per CSS ausblenden dürfte aber ohne Probleme gehen. Viele Grüße Patrick Stützel (Diskussion) 16:02, 10. Aug. 2014 (CEST)

Hallo Jan (WMF), wer genau ist "wir"? "Die WMF", Du persönlich in Deiner Rolle als angestellter Community Advocate (inwiefern bist Du dabei ein Advokat der Community?) oder wer sonst? Mir persönlich ist der MV ziemlich egal, und die Frage, ob und wie das Meinungsbild umzusetzen ist, kann sicher kotrovers in diesem Projekt diskutiert werden. Wenn aber die WMF meint, eingreifen zu müssen, wüsste ich schon gerne, wer da genau was auf Basis welcher Grundlage tut und wer die persönliche Verantwortung dafür trägt. Gruß --Magiers (Diskussion) 15:39, 10. Aug. 2014 (CEST)

Jan, du kannst dich ja stattdessen als unser Advocat mal dafür einsetzten, dass die Foundation die Community und deren Entscheidungen respektiert. Dass dieses Ergebnis zustande kam, ist eure eigene Schuld. --Julius1990 Disk. Werbung 15:49, 10. Aug. 2014 (CEST)

Hallo Jan (WMF). Das Projekt wiki lief zweifellos jahrelang ohne den MV sehr erfolgreich. In den wenigen Wochen, die der MV in Betrieb ist, hat es bestenfalls bewiesen, das er den Erfolg (noch?) nicht gebremst hat. Einen Spruch wie "Sonst [also für den Fall das der MV abgeschaltet ist] 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" kann ich nur als dummdreist bezeichnen. Du suggerierst hier eine Gefahr im Verzug (die angeblich nicht vorhandene volle Funktionsfähigkeit ohne MV), die nachweislich nicht gegeben ist. Die WMF möge doch bitte bitte mal zur Sachlichkeit zurück kommen!!! -- Gerold (Diskussion) 16:07, 10. Aug. 2014 (CEST)

Nicht dummdreist, diese totalitäre Phantasie wird (siehe Kurier-Disk) bereits evrfolgt. Julius1990 Disk. Werbung 16:10, 10. Aug. 2014 (CEST)

Add a new protection level called "superprotect" ... --Steinsplitter (Disk) 16:10, 10. Aug. 2014 (CEST)

Und es kommt gleich zum Einsatz. 85.212.8.241 16:23, 10. Aug. 2014 (CEST)

"You might as well make the topic line ‚Declare war on local site admins‘" Das trift es, jatzt auch technische Entmachtung der Community. Jan und Eric Möller wollen tatsächlich die Eskalation. --Gleiberg (Diskussion) 16:27, 10. Aug. 2014 (CEST) PS: Man kann sich wenigstens ein bisschen wehren

Sind nicht für genau diese Fälle Deadmin-Verfahren vorgesehen? --Drahreg01 (Diskussion) ^3Wf 17:09, 10. Aug. 2014 (CEST)

nachteiligen Eingriff in die Funktionsweise des Projekts....volle Funktionsfähigkeit blablabla. Mal wieder inhaltsleeres Geblubber seitens der WMF, genauso wie auf der Diskussionsseite des Meinungsbildes. Kann man eigentlich ignorieren. 85.212.8.241 16:16, 10. Aug. 2014 (CEST)

Hallo, wir haben den Schreibzugriff auf diese MediaWiki-Namensraumseite zurückgenommen um die volle Funktionsfähigkeit des Projekts für alle Benutzer sicherzustellen. Vielen Dank und Grüße, --Jan (WMF) 16:26, 10. Aug. 2014 (CEST)

Herzlichen Dank für die freundliche Serviceleistung. Wir hoffen auch zukünftig mit guten Produkten in Form von Artikel Ihnen dienstbar zu sein und die Klappe zu halten. --Gleiberg (Diskussion) 16:28, 10. Aug. 2014 (CEST)

Ja da sieh mal einer an, wenn es schnell gehen muss dann geht es schnell. Das neue "Feature" kann wohl besser als "God mode" bezeichnet werden. Wie sieht es aus wenn das Fass hier überläuft? → User: Perhelion 16:30, 10. Aug. 2014 (CEST)

Diese Serviceleistung kann mit einem Autogramm auf Wikipedia:Adminwiederwahl/Jan_eissfeldt gewürdigt werden. 85.212.8.241 16:31, 10. Aug. 2014 (CEST)

(Bk) Das nenne ich mal mit Kanonen auf Spatzen geschossen. Als ob der Mediaviewer für das Funktionieren der Wikipedia essentiell wäre. Wer den Mediaviewer angeschaltet haben will kann das, selbst wenn er hier ausgeknipst ist, immernoch über da eigene Common.js tun. Viele verdutzte Grüße Patrick Stützel (Diskussion) 16:39, 10. Aug. 2014 (CEST)

Für mich wurde heute der Rubikon seitens der Foundation endgültig überschritten. Julius1990 Disk. Werbung 16:33, 10. Aug. 2014 (CEST)

@Jan (WMF): Oben habe ich dir (bzw. der WMF in dessen Auftrag du handelst) dummdreist zu argumentieren. Nun wird haargenau mit diesem dummdreisten Argument dummdreist gehandelt. Liebe WMF - das geht nicht gut! -- Gerold (Diskussion) 16:34, 10. Aug. 2014 (CEST)

Somit hat die WMF gezeigt, dass euch die Belange derjeniger, die dafür Sorgen dass, das Projekt überhaupt funktioniert und dass die Chefetage ihr Gehalt bekommt, bestenfalls peripher tangieren. Das Overrulen eines verbindlichen Entscheides, der sich selbst verwaltenden Projekte, widerspricht dem Grundgedanken der Wikimedia-Projekte. Bis gestern hätte ich so eine Aktion eurerseits nie für möglich gehalten. Aber man lernt nie aus. Durch euer Verhalten gegenüber der aktiven Nutzer, tretet ihr alles was die letzten 10 Jahre aufgebaut wurde, die ganze Energie und Zeit die durch diverse Aktive kostenlos und ehrenamtlich eingebracht wurde mit Füßen. "Sauer" ist gar kein Ausdruck für die Gefühle die ich gerade hege. -- Jogo30 (Diskussion) 16:35, 10. Aug. 2014 (CEST)

Wikipedia ist keine Demokratie, das Meinungsbild eines, dass so oder so in eine Sackgasse führt. Ein zentrales Problem des MB war es ja, dass es von Gefühlen getragen wurde, und dass man Fakten wie die Weiterentwicklungen ignorierte. Frohes Schaffen — Boshomi ☕⌨☺  16:53, 10. Aug. 2014 (CEST)

<quetsch nach BK> :::: MIt dieser Argumentation führst du sämtliche Meinungsbilder, so wie die Selbstverwaltung der Wikimedia-Projekte, eines der Grundsätze, ad absurdum. -- Jogo30 (Diskussion) 16:58, 10. Aug. 2014 (CEST)

Von mir gibt es keine finanzielle Unterstützung mehr. --84.226.187.197 16:56, 10. Aug. 2014 (CEST) (ein ehemaliger Spender)

Meinungsbilder insbesondere jene die nur einfache Mehrheit erfordern haben grundsätzlich keine Rechtskraft. Zuerst gelten die Grundprinzipien, Meinungsbilder haben sich unterzuordnen, und könne durch Einzelfallentscheidungen jederzeit overruled werden. Es sind Leitlinien, an denen man sich orientieren kann, aber nicht muss. Die fehlende Rechtskraft von Meinungsbildern ist dabei gewollt, um die Fortentwicklung sicherzustellen und übertriebene Regulierungswut abzudämpfen. Frohes Schaffen — Boshomi ☕⌨☺  17:31, 10. Aug. 2014 (CEST)

Deine Privatmeinung sei dir unbenommen, aber sie ist und bleibt nichts als deine Privatmeinung @Benutzer:Boshomi, denn es ist Konsens, dass Meinungsbilder verbindlich sind, auch der Entwickler hat sich daran zu halten. Das sind die Grundsätze unseres Projektes. Im übrigen ist trotz der im MB geforderten lediglichen einfachen Mehrheit, eine 2/3-Mehrheit locker zustande gekommen, somit ist selbst deine Privatmeinung erfüllt. --Jogo30 (Diskussion) 17:55, 10. Aug. 2014 (CEST)

Nein, das ist falsch, Jogo30. "Meinungsbild" ist eigentlich die deutsche Übersetzung für englisch "Request for Comment", und es geht um die Stärke der Argumente, nicht um die Stärke der Stimmen !vote! (inklusive Sockenpuppen...). Erst seit ca. 2 Jahren wird auf deWP von einigen so getan, als sei ein Meinungsbild eine Volksabstimmung und Wikipedia eine Demokratie. Das ist aber nicht die ursprüngliche, und erfolgreiche Vorgehensweise, sondern ein Missverständnis. Wir haben bei Löschdiskussionen auch keine "Abstimmung" nach Stimmenzahl, sondern Abwägung der Argumente, und bei Artikeln wird ebenfalls nach sachlichen Argumenten entschieden, nicht nach Geschmack der Mehrheit. --Atlasowa (Diskussion) 18:11, 10. Aug. 2014 (CEST)

Wir arbeiten in der deutschen Wikipedia und sehen als solche (Konsens!) MBs für verbindlich, das können wir deshalb, weil eines der Grundsätze von Wikimedia-Projekten, die Selbstverwaltung des eigenen Projektes ist. Ein Vergleich mit Vorgehensweisen in anderen Projekten ist daher irrelevant. Die Löschdiskussion ist in der Tat keine Abstimmung, das bedeutet aber nicht, dass ein MB ebenfalls keine ist. WP:Wikipedia ist keine Demokratie bedeutet nicht, dass grundsätzlich keine demokratischen Prozesse stattfinden, sondern dass es Situationen gibt, in denen nicht demokratisch entschieden werden kann, ein MB gehört nicht dazu. -- Jogo30 (Diskussion) 18:22, 10. Aug. 2014 (CEST)

Jogo30, Deine Privatmeinung ist in der Sache falsch und wird auch durch Wiederholung nicht wahrer. EOD. --Atlasowa (Diskussion) 18:48, 10. Aug. 2014 (CEST)

Danke Benutzer:Atlasowa, exakt der Meinung bin ich auch. Das Ganze würde ich gerne noch etwas weiter ausführen, bzw. in Bezug darauf, dass die Umsetzung, die hier versucht wurde, vorzunehmen, die User quasi ins Gesicht schlägt, die den Medienbetrachter gerne Nutzern möchten (so einer bin ich auch...). Ich denke, dass keiner den MB in Frage stellt, bloß die, ich nenne es mal, voreilige Umsetzung dessen geht einfach in die falsche Richtung. Zudem (ich betrachte das mal rückblickend) wurde der Superprotect erst eingeführt, als hier auf der Seite ein Editwar entstand. Was daran dann noch sachlich sein soll, verstehe ich nicht. Daher verstehe ich aber die Schritte der WMF. Ich bin mir sicher, dass man mit einer sachlichen Diskussion vieles erreichen kann. Grüße --Florianschmidtwelzow (Diskussion) 23:32, 10. Aug. 2014 (CEST)

Was bei der unseligen Bildfilter-Geschichte damals (nach meiner Beobachtung) geholfen hat, war die konkrete Vorbereitung eines Forks. --Drahreg01 (Diskussion) ^3Wf 17:10, 10. Aug. 2014 (CEST)

Was ich besonders übel finde: Abermals wird sich hinter einem "wir" versteckt: keine Übernahme persönlicher Verantwortung, keine Erklärung, wer hier auf wessen Veranlassung und auf Basis welcher Grundlage aktiv wird. Sozusagen die Funktion kommentarlos zurücksetzen mit selbst verliehenen Superrechten für die Foundation. --Magiers (Diskussion) 17:13, 10. Aug. 2014 (CEST)

Die Supersperre (als Steigerung zur Vollsperre) sehe ich auch als heikel an, der Revert war trotzdem richtig. Das MB ist klar zugunsten eines Opt-In ausgegangen; ein komplettes Deaktivieren mit einem Bastelt-euch-doch-irgendwie-einen-JS-Hack ist aber keine Umsetzung des MB, sondern ein Vor-den-Kopf-stoßen der Abstimmenden. Entweder das MB wird so umgesetzt, wie dort im Vorschlag steht, oder eben gar nicht.

Im Übrigen kann ein MB über ein Softwarefeature nicht mehr sein als eine Bitte an die Foundation. —Morten Haan · Wikipedia ist für Leser da 18:09, 10. Aug. 2014 (CEST)

Eine Bitte? Das sehe ich anders. Ich wiederhole mich, einer der Grundsätze von Wikimedia-Projekten ist, dass die Projekte sich selbst verwalten, das wird von Seiten WMF auch so protegiert, daher ist auch für die WMF ein Meinungsbild bindend. Mich hat niemanden vor den Kopf gestoßen, mit Ausnahme der WMF, die durch ihr Overruling nicht nur vor den Kopf stößt, sonder projektschädigend ist. -- Jogo30 (Diskussion) 18:24, 10. Aug. 2014 (CEST)

+1 (BK )@Morten Haan Mit welcher Begründung, mit welchen Recht kann es nur eine Bitte sein? Dazu hat es schließlich auch mal ein MB gegeben. Einzig ein Unvermögen für ein neues Feature unsererseits würde eine Bitte rechtfertigen. → User: Perhelion 18:32, 10. Aug. 2014 (CEST)

(BK) Die Software wird aber nunmal von der WMF verwaltet und kann somit nicht im Bereich der Selbstverwaltung der Community liegen. Zumindest diejenigen wurden vor den Kopf gestoßen, die sich klar für ein Opt-In entschieden haben.

Wäre es nicht eine Lösung, den JS-Code, welchen DaB in die Commons.js eingefügt hat, in ein Gadget einzufügen, das standardmäßig aktiviert ist? —Morten Haan · Wikipedia ist für Leser da 18:37, 10. Aug. 2014 (CEST)

Dieser spezielle Code nicht, da er nicht genau dem MB entspricht – ein Gadget, welches genau dieses umsetzt, wäre dagegen natürlich optimal. Die Frage ist nur, wer das basteln könnte, vielleicht könnten das ja Der Umherirrende und PerfektesChaos, sofern sie dazu bereit sind. --BHC (Disk.) 18:42, 10. Aug. 2014 (CEST)

Man könnte sich jetzt die Mühe machen, gegen den Willen der WMF den MediaViewer zu deaktiveren, über Common.js, Gadgets oder andere Sachen, sofern aber auch das deaktivieren für angemeldete Benutzer nicht akzeptiert wird, bringt das nur mehr superprotect-Seiten, die Handlungsfähigkeit der WMF in dieser Hinsicht lahm zulegen, wird viel Kraft und Nerven kosten. Da halte ich mich gerne heraus. Der Umherirrende 18:49, 10. Aug. 2014 (CEST)

Die Admins @MBq, Schniggendiller: sind bereits techn. in der Richtung des MV tätig geworden (PerfektesChaos ist leider, erstaunlicher Weise noch kein (Tech-) Admin, aber ich denke auch er würde sich da raushalten). → User: Perhelion 18:53, 10. Aug. 2014 (CEST)

@Gadget (BHC): Um's nochmal deutlich zu sagen, man braucht hier keine besonderen JS-Kenntnisse, einfach eine Gadget-Seite erstellen, und nur diese eine Zeile genau wie hier in der Common.js einsetzen, fertig ist das Gadget!! → User: Perhelion 19:32, 10. Aug. 2014 (CEST) PS: und eine Seite für die Beschreibung: "Den Medienbetrachter deaktivieren.". Genaue Anleitung hier. → User: Perhelion 19:48, 10. Aug. 2014 (CEST)

Warum sollten die Genannten das machen? Um Öl in den frisch entfachten Konflikt zu gießen? Das Meinungsbild war, wie man jetzt sehr deutlich sieht, miserabel vorbereitet, und man hatte offensichtlich keine mit der Foundation abgestimmte Vorgehensweise für den Erfolgsfall des MB ausgearbeitet. Das muss jetzt im Nachhinein per Machtkampf entschieden werden.  Frohes Schaffen — Boshomi ☕⌨☺  19:46, 10. Aug. 2014 (CEST)

Weil das die genaue Umsetzung des Opt-in des MB's wäre!! → User: Perhelion 19:48, 10. Aug. 2014 (CEST)

Dass die Mehrheit dem MB zugestimmt hat, ändert nichts an der Tatsache der miserablen Vorbereitung. Die Folge wären bloß wenig zukunftsfähige Alleingänge, ein Gang in eine erkennbare Sackgasse. Frohes Schaffen — Boshomi ☕⌨☺  19:55, 10. Aug. 2014 (CEST)

Die Frage ist nur wer was miserabel vorbereitet hat. Die WMF mit ihrem MV Alleingang (notfall mit dem Superprotect-Knüppel) oder diejenigen die das MB vorbereitet haben, als das Kind bereits schon in den Brunnen gefallen ist. --Alchemist-hp (Diskussion) 20:04, 10. Aug. 2014 (CEST)

Mieserabel war beispielsweise, dass man die Foundation nicht angemessen in die Vorbereitung des MB miteinbezogen hat, keine im Konsens ausgearbeiteten Umsetzungsvorschläge bereit hielt und keine Vision entwickelte wie der Mediaviewer aussehen sollte. Nun bleibt eben nichts übrig als dieser Machtkampf, denn ein leichtfertiges Einlenken der Foundation hätte weitreichende negative Auswirkungen auf das Gesamtprojekt.  Frohes Schaffen — Boshomi ☕⌨☺  20:15, 10. Aug. 2014 (CEST)

Offensichtlich nehmen sich beide Seiten nicht viel wenn ein Zitat MB „wird als technisch unausgereift bewertet[es Feature]“ dadurch abgeschaltet werden soll in dem man eine technisch unausgereifte Lösung wählt („Das generelle Abschalten kommt dem MB-Ergebnis näher als ihn komplett anzulassen.“). Diese Ironie. --Mps、かみまみた^Disk. 20:17, 10. Aug. 2014 (CEST)

Vorlage:Smiley/Wartung/smile   Frohes Schaffen — Boshomi ☕⌨☺  20:29, 10. Aug. 2014 (CEST)

Gut, das es noch nicht anders probiert wurde. Vll. erst informieren bevor hier Schwachsinn verbreitet wird? Diese Ironie... --217.87.205.179 (21:10, 10. Aug. 2014 (CEST), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

Gut, das mit dem Gadget ist dann auch gestrichen. → User: Perhelion 21:26, 10. Aug. 2014 (CEST)

Wenn die von der WMF verwaltete Software nicht im Selbstverwaltungsbereich der Community liegt, wie erklärst du es dir dann, dass die WMF in Punkto WP:Gesichtete Versionen sehr auf die einzelnen Communitys gehört hat und nach deren Wünschen aktiviert oder eben nicht aktiviert hat? Die Gesichteten Versionen sind Teil der volle[n] Funktionsfähigkeit des Projekts und dennoch wurden sie in der englischsprachigen Wikipedia nur in einem beschränkten Umfang aktiviert. Dort hat die WMF gezeigt, dass sie der Community auf Augenhöhe begegnet und ihre Wünsche ernst nimmt und respektiert. Der seitens der WMF im jetzigen Fall eingesetzte Schreibrechteentzug für hiesige Admins stellt einen nachteiligen Eingriff in die Funktionsweise des Projekts dar, zugleich bleiben einfache Fragen an JEissfeldt und Eloquence unbeantwortet. Es stellt sich also die Frage: Warum agiert die WMF nicht mehr auf Augenhöhe mit der Community sondern spuckt nun auf uns? -- 32X 11:27, 13. Aug. 2014 (CEST)

@32X: no.wikipedia wurde vor ein paar Tagen die Aktivierung der gesichteten Versionen trotz Community-Konsens verweigert: bugzilla:64726#c15, das taugt also nicht (mehr) als Beispiel. --Schnark 11:59, 13. Aug. 2014 (CEST)

<nach-links-rück> Das heißt dann, dass das MB nicht umsetzbar ist? —Morten Haan · Wikipedia ist für Leser da 21:35, 10. Aug. 2014 (CEST)

Sagen wir mal so - die WMF tut alles damit es nicht umsetzbar ist. -- Gerold (Diskussion) 23:36, 10. Aug. 2014 (CEST)

Genauer: Die WMF hindert mit ihrer Hoheit über Server und Software die örtliche Community an der Umsetzung des Meinungsbildes. Meiner Einschätzung nach steht es hier Hoheit über Technik vs. Hoheit über Inhalt. Nun, die Technik kann man austauschen … —‏הגות‎⁴¹⁴ 07:25, 11. Aug. 2014 (CEST)

WMF soll nochmal neu bewerten. Vielteich setzt nach dem ganzen Drama der Verstand dort ein. --Steinsplitter (Disk) 09:16, 11. Aug. 2014 (CEST)

Eine Komplettbschaltung des MV ist keine Umsetzung des Meinungsbildes (aber nach dem vorstehend verlinkten Statment hätte die WMF wohl auch eine Umsetzung des MB verhindert ...) --PM3 18:38, 11. Aug. 2014 (CEST)

 Info: Zufälliger Weise wurde jetzt genau diese Option als Gadget-Einstellungen (auf Commons) erstellt und zudem freundlicher Weise ein Hinweisbanner.[15] (PS: allerdings ebenfalls als Hack, da sich die WMF wohl Zeit lässt und wie von Krinkle angemerkt dies eher über PHP vorgesehen ist.) → User: Perhelion 15:40, 12. Aug. 2014 (CEST)

Hallo JEissfeldt und Eloquence, wenn die Kinder nicht artig sind, dann müssen die Eltern knallhart durchgreifen, schon klar. Ihr habt einen nachteiligen Eingriff in die Funktionsweise des Projekts per Mutti-Zugriff knallhart abgewiegelt, um die volle Funktionsfähigkeit des Projekts für alle Benutzer sicherzustellen. Eine Frage gestattet ihr mir aber sicherlich: Ich nutze ein Netbook, ihr wisst schon, die Geräte für die damals eigens im Monobook die Suchzeile direkt unter das Logo gewandert ist. Wenn ich (beispielsweise) im Artikel Köln auf das schöne Panorama von der Deutzer Brücke klicke, dann wird mir zwar nach ein paar Sekunden das ganze Bild gezeigt, allerdings in der gleichen Größe. Der Rundblick vom Dortmunder Fernsehturm wird mir sogar verkleinert dargestellt. Eine Zoomfunktion fehlt. Ist das tatsächlich „die volle Funktionsfähigkeit“, die ihr mir und allen anderen Nutzern mit derart mobilen Computern zur Verfügung stellen könnt? Vorschlag zur Güte: Die WMF hört weniger auf ihre BWLer und mehr auf die Entwickler und aktiviert neue Funktionen erst dann, wenn sie keine Verschlechterung zum Ist-Zustand darstellen. Dann ist auch die Community weniger bockig. -- 32X 08:52, 12. Aug. 2014 (CEST) PS: „Wikipedia ist ein Projekt zum Aufbau einer Enzyklopädie aus freien Inhalten“. Die Funktionsweise/Funktionsfähigkeit des Projekts ist nicht beeinträchtigt, wenn schlechte Software deaktiviert wird, solange die Enzyklopädie noch lesbar ist.

+1 → User: Perhelion 15:40, 12. Aug. 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 21:07, 17. Jul. 2015 (CEST)

Lösungsvorschlag

Gemäß dieses Vorschlags plädiere ich unabhängig von der angeheizten Diskussion dafür, diese Lösung zu implementieren. Imho kann man auch noch darüber nachdenken, den MediaViewer für unangemeldete Benutzer anzuschalten, da er ja für genau diese Zielgruppe design wurde. Falls jemand diese Lösung implementieren will und es genug Unterstützer gibt, schlage ich folgende Schritte vor:

/**
 * Deaktivierung des MediaViewers für angemeldete Benutzer,
 * kann in den Einstellungen wieder angeschaltet werden,
 * indem das Helferlein "MediaViewer ausschalten" deaktiviert wird.
 */
( function( mw ) {
	'use strict';

	if ( mw.config.get( 'wgUserName' ) ) {
		mw.config.set( 'wgMediaViewerOnClick', false );
	}

} )( mediaWiki );

Dieser Code könnte in die Seite MediaWiki:Gadget-MediaViewer ausschalten.js kopiert werden und dann in MediaWiki:Gadgets-definition als Default-Gadget eingefügt werden. Dann könnten Leser den MediaViewer immer noch nutzen und angemeldete Benutzer ihn einfach wieder einschalten. Ich hoffe, mit dieser Lösung können wir zumindest technisch einen Kompromiss finden. Mit den besten Absichten, -- Bene* (Disk) 16:58, 12. Aug. 2014 (CEST)

War es nicht das Ergebnis des Meinungsbildes, dass der Mediaviewer für alle Benutzer abgeschaltet werden soll? --Drahreg01 (Diskussion) ^3Wf 17:57, 12. Aug. 2014 (CEST)

Der Vorschlag von Bene* ist im Gegensatz zu der Aktion von vorgestern durch das Meinungsbild gedeckt; es wäre zumindest mal eine Teilumsetzung als erster Schritt. Für eine vollständige Umsetzung scheint es ja bislang keine technische Möglichkeit zu geben. Ja, ich weiß dass diese Möglichkeit von der WMF verhindert wird, dieses Wissen bringt uns nur praktisch nicht weiter. --PM3 18:04, 12. Aug. 2014 (CEST)

+1 Zudem das nicht explizit im MB genannt wurde, eher im Gegenteil, „kann aber von angemeldeten Benutzern... aktiviert werden“ → User: Perhelion 18:17, 12. Aug. 2014 (CEST)

(BK) Ich halte es für unklug, jetzt der WMF ihren Willen zu geben, bevor es eine Äußerung seitens der WMF gibt, wie man in Zukunft mit dem Community-Willen umzugehen gedenkt. Just my 2c. --Drahreg01 (Diskussion) ^3Wf 18:18, 12. Aug. 2014 (CEST)

@Drahreg: Nein, im MB wurde klar auf ein Opt-In entschieden. Wo steht, dass wir damit der WMF ihren Willen geben?

@Perhelion: Durch deaktivieren des Gadgets wird der MV aktiviert. Wo ist das Problem? —Morten Haan · Wikipedia ist für Leser da 18:24, 12. Aug. 2014 (CEST)

@Morten Haan: Es geht um Nichtangemeldete-Benutzer (IP's). Für mich hat der Vorschlag des MB klar impliziert dass diese nicht gemeint sind (schon alleine da ein Opt-In für diese gar nicht erwähnt wurde). → User: Perhelion 18:34, 12. Aug. 2014 (CEST)

(BK) Ich fände es besser, hier bei der Sache bleiben statt ad organisationem zu argumentieren. --PM3 18:35, 12. Aug. 2014 (CEST)

@Perhelion: Ich verstehe das MB eindeutig so, dass der MV für alle Benutzer standardmäßig abgeschaltet werden soll; die angemeldeten werden dann als Ausnahme von der Regel genannt, weil sie den MV wieder einschalten können sollen. --PM3 18:53, 12. Aug. 2014 (CEST)

(BK) Wenn der MV auf Opt-In gestellt wird, dann können IPs diesen nicht verwenden. Deshalb habe ich gegen den MB-Vorschlag gestimmt. —Morten Haan · Wikipedia ist für Leser da 18:55, 12. Aug. 2014 (CEST)

(BK) Ja ich ebenfalls, ähm formal... @PM3: Wenn man das Wort Benutzer alleine verwendet steht es eindeutig für angemeldete Benutzer, da IP's zwar indirekt auch Benutzer sind aber niemals alleine so bezeichnet werden. Da steht kein alle! → User: Perhelion 18:59, 12. Aug. 2014 (CEST)

Siehe WP:IP. --PM3 19:01, 12. Aug. 2014 (CEST)

Vgl. Amerikaner → User: Perhelion 19:05, 12. Aug. 2014 (CEST)

Die Formulierung in dem MB ist logisch eindeutig. Da steht „Der Medienbetrachter wird standardmäßig deaktiviert“, und dann kommt eine Ausnahme für angemeldete Benutzer. Unschön ist allerdings, dass eine echte Pro/Contra-Liste fehlt, in der man nochmal explizit darauf hingewiesen hätte dass die IPs ihn dann nicht mehr nutzen können. War fies konstruiert das MB. --PM3 19:18, 12. Aug. 2014 (CEST)

Könnte für IPs nicht ein Cookieparameter gesetzt werden um den MV zu aktivieren? --Anselmikus (Diskussion) 19:06, 12. Aug. 2014 (CEST)

MediaWiki:Vector.js und MediaWiki:Monobook.js verwenden anstatt common.js. --Steinsplitter (Disk) 19:20, 12. Aug. 2014 (CEST)

Dann gibt es noch MediaWiki:Group-user.js --Steinsplitter (Disk) 19:27, 12. Aug. 2014 (CEST)

Unangemeldete Benutzer können kein Monobook einstellen und verwenden, sie bekommen immer Vector zu sehen. Die Vector.js würde also ausreichen. --Winternacht 21:25, 12. Aug. 2014 (CEST)

@Steinsplitter: Und damit quasi heraufbeschwören, dass auch diese Seiten (und ggf., je nachdem was da noch so kommt der komplette MediaWiki Namensraum) für die Bearbeitung von Nutzern mit Superprotect-Recht begrenzt werden? Nur so ein Gedanke, dass weitere Eskalationen hier (von beiden Seiten!!!) mit Sicherheit keinerlei zufriedenstellende Lösung herbeiführen wird --Florianschmidtwelzow (Diskussion) 23:05, 12. Aug. 2014 (CEST)

Ich denke man sollte damit erst mal zur WMF gehen und versuchen, sich zu einigen. Es wäre etwas anderes als die Komplettabschaltung vorgestern, und die müssten inzwischen auch gemerkt haben dass sie die Lage falsch eingeschätzt haben. Wenn man sich nicht einig wird kann man sich immer noch Gedanken über einen Plan B machen. --PM3 23:56, 12. Aug. 2014 (CEST)

Dazu bedarf es einer Softwareänderung. —Morten Haan · Wikipedia ist für Leser da 19:22, 12. Aug. 2014 (CEST)

Sicher? Der daktivierungscode sollte auch in den oben genannten MediaWiki's arbeiten. --Steinsplitter (Disk) 19:27, 12. Aug. 2014 (CEST)

Im MB wurde entschieden, dass der MV deaktiviert wird und dass angemeldete diesen aktivieren können. Das ist zwar nicht meine Meinung, wurde aber nunmal so entschieden. Daher ist ein Gadget sinnvoll, welches standardmäßig für alle aktiviert ist und von Angemeldeten ausgeschaltet werden kann und das den MV deaktiviert. —Morten Haan · Wikipedia ist für Leser da 20:09, 12. Aug. 2014 (CEST)

@Code: Anhand des Bsp. auf Commons wurde jetzt (einfach) ersichtlich dass Gadgets doch für IP's ausgenommen werden können[16] (steht auch hier im Ansatz in einer Anleitung. Das hatten bei der letzten AA hier die beiden Admins nicht gewusst, aber scheinbar eh die wenigsten, selbst Herr Eloquence persönlich hat darauf verzichtet) Also kann(/könnte) der ganze Code sich wieder auf die eine Zeile, wie hier in der Common.js beschränken. → User: Perhelion 00:25, 13. Aug. 2014 (CEST)

PS: Allerdings hat hier jemand einen Code gepostet, der beide Optionen verbinden würde (wie oben schon mal von mir als Idee erwähnt) also die offizielle MV Option unter Aussehen und die unter Helferlein. (was allerdings nicht funzt da auf den EinstellungsSeiten JS deaktviert ist, s. Kmt. beim Gadget Commons)

Auf jeden Fall sollte jede weitere Änderung erst mal mit der WMF abgesprochen bzw. es versucht werden, bitte raus aus dem ABF- und Konfrontationsmodus, das machts nur schlimmer! --PM3 01:04, 13. Aug. 2014 (CEST)

Ja, für die WMF. Die WMF kann nicht jederzeit mit uns (mit)reden?? → User: Perhelion 07:03, 13. Aug. 2014 (CEST)

Vllt. wird die Tage auch einfach zu viel geschrieben: Wikipedia Diskussion:Kurier#Austausch mit WMF -- 95.91.251.138 08:52, 13. Aug. 2014 (CEST)

Ja, genau: lasst uns einfach die Duckmäuser spielen. Die Zeit wird es schon richten. Arbeiten wir weiterhin fleißig für die leeren Taschen der WMF Mitglieder. Wir sind nun mal das Ende der Nahrungskette. Das Projekt "Wikipedia" ist für mich eh schon gescheitert gewesen und nun sogar durch das Verhalten des WMF vollends bestätigt. --Alchemist-hp (Diskussion) 09:41, 13. Aug. 2014 (CEST)

Dazu wohl ähnlich der letzte Thread beim MB. → User: Perhelion 13:57, 13. Aug. 2014 (CEST)

Für IP's könnte endlich mal ein einfaches Einstellungsmenü (mit nur den wichtigsten An-Aus-Schaltern) implementiert werden, das Cookies als Speicher nutzt. Dann hätten IP's zumindest die Möglichkeit bestimmte persönliche Anpassungen vorzunehmen. --2003:63:2F58:3700:D1E:F414:5B9E:464E 11:12, 13. Aug. 2014 (CEST)

Es ist einer der Vorteile einer Anmeldung, Dinge für sich persönlich einstellen zu können. Warum sollte man aufwändig die Vorteile von Anmeldungen verringern? Damit noch mehr nachgesichtet werden muss? Besser, man meldet sich an, wenn man die Vorteile nutzen will. Wenn IP-Benutzer dauerhaft unangemeldet mitmachen, dann vergrößern sie damit nur die Arbeit für alle anderen Benutzer. Über kurz oder lang ist anmelden besser. --Winternacht 13:16, 13. Aug. 2014 (CEST)

+1 Genau meine Sicht, es ist schon ein Zugeständnis, dass IP's überhaupt mitarbeiten können (was alles schon ganz oben mehrmals zur Debatte stand). Auch wenn Gerold mit einem (vlt. zur Situation untergegangenem) längeren Kmt. versucht sachlich richtig das Gegenteil zu begründen. → User: Perhelion 13:39, 13. Aug. 2014 (CEST)

+1; wenn man mehrere Geräte oder einen öffentliche PC verwendet, ist es ohnehin deutlich umständlicher, mit Cookies zu arbeiten, als sich einmalig einen Account zuzulegen. Besser wäre es, wenn das Ausblenden von Site- und Centralnotices bei Angemeldeten per Accounteinstellungen statt per Cookie funktionieren würde. —Morten Haan · Wikipedia ist für Leser da 16:16, 13. Aug. 2014 (CEST)

Der Media Viewer kann von IPs bereits permanent ein- oder ausgeschaltet werden, gerade getestet und funktioniert prima - die Einstellung überlebt einen Session-Wechsel und einen IP-Wechsel. Geht über die Optionen direkt im Medienbetrachter bzw. der alten Medienanzeige. Somit würde eine Umsetzung des MB also IPs nicht an der Verwendung des MV hindern. --PM3 03:57, 14. Aug. 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 21:06, 17. Jul. 2015 (CEST)

Live-Diskussion

ist in Planung: WP:BÄR#SuperTalk - mach mit! --user.js (((☎))) 15:26, 14. Aug. 2014 (CEST)

Verlinkter Abschnitt ist verschwunden. Für Live-Diskussionen bieten sich andere Tools an. Der Umherirrende 21:14, 17. Jul. 2015 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 21:14, 17. Jul. 2015 (CEST)

MediaWiki:Common.js in den sorbischen Wikipedien

Hallo. Wenn ich jetzt in der obersorbischen oder niedersorbischen Wikipedia bei irgendeinem Artikel mir die Bearbeitungsvorschau anzeigen lasse, verschwinden sämtliche Symbole in der Symbolleiste oberhalb des Bearbeitungsfensters. Außerdem steht in der Fehlerkonsole vom Firefox 31 Fehler: ReferenceError: GeoBox_Init is not defined Quelldatei: https://bits.wikimedia.org/hsb.wikipedia.org/load.php?debug=false&lang=hsb&modules=site&only=scripts&skin=vector&* Zeile: 66. Vor der Aktualisierung am 21. 8. trat diese Fehlermeldung noch nicht auf. Was muß also an den Skripten in hsb:MediaWiki:Common.js bzw. dsb:MediaWiki:Common.js geändert werden? Oder kommt die Meldung durch das Browserupdate? --Tlustulimu (Diskussion) 19:11, 23. Aug. 2014 (CEST)

(+) Die gleiche Fehlermeldung erscheint auch in der Esperantowikipedia, obwohl die eo:MediaWiki:Common.js größtenteils ganz anders aussieht als in den beiden sorbischen. Was muß denn dort angepaßt werden? --Tlustulimu (Diskussion) 19:14, 23. Aug. 2014 (CEST)

Du benutzt FireFox? Dann handelt es sich um Bug 69924, siehe auch (diverse) Abschnitte auf WP:FzW. Einfachste Lösung: Anderer Browser, ansonsten muss man die ganze Common.js neu ordnen, damit der Fehler in FireFox nicht auftritt oder man versucht den anderen im Bug genannten Hotfix. Der Umherirrende 19:22, 23. Aug. 2014 (CEST)

Leider verstehe ich auf der Seite Bug 69924 nur Bahnhof. :-( Warum tritt die Fehlermeldung jetzt plötzlich auf, obwohl das Browserupdate und die Aktualisierung der MediaWiki-Software schon einige Tage her sind? Ist der Browsercache schuld? --Tlustulimu (Diskussion) 19:42, 23. Aug. 2014 (CEST)

Ja, der Browser-Cache könnte hier Schuld sein, das erst jetzt bei dir die neue Version genutzt wird. Was genau für eine Änderung an Common.js notwendig ist, kann ich auch nicht sagen, weil bei deinem Beispiel mit GeoBox_Init die Funktionsdeklaration vor dem Aufruf kommt. Der Umherirrende 10:15, 24. Aug. 2014 (CEST)

@Umherirrender: Ich habe erst mal provisorisch korrigiert, indem ich den Aufruf hinter die Funktionsdefinitionen verschoben habe. Das klappt sogar. :-) Ich werde denn mal nach und nach die übrigen Funktionen durchgehen, denn dort ist ja ziemlich viel veralteter Kram dabei. --Tlustulimu (Diskussion) 11:01, 24. Aug. 2014 (CEST)

Aso, du hattest schon korrigiert. Ich hatte mich gewundert, warum GeoBox_Init angemeckert wurde. Das ist aber der richtige Weg. Der Umherirrende 11:10, 24. Aug. 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 21:04, 17. Jul. 2015 (CEST)

MediaWiki:Common.js/relative.js

Muss MediaWiki:Common.js/relative.js eigentlich noch geladen werden? http-Links sollte man auf aktuellen Seiten kaum mehr begegnen, und selbst wenn, werden diese auf https weitergeleitet, auch ohne dass sie von dem Skript in relative Links umgewandelt wurden. --Schnark 10:14, 17. Aug. 2015 (CEST)

Hmmm, müsste ich länger drüber sinnieren.

Im Prinzip hast du recht.

Bookmarks würde man sich von der aktuellen Seite holen, also immer https.

Die Browser-Funktion „Linkadresse kopieren“ würde http abgreifen, was uneinheitlich wäre.

In den Seiten können als Permalink, Difflink oder auf die VG sehr wohl noch viele http vorkommen; nicht unbedingt im ANR, aber auf Disku und Projektseiten.

Konsequenzen für fehlgeleitete Skripte, Auswertungen und CSS-Regeln müsste ich erstmal eine Woche durch meinen geistigen Verdauungstrakt kneten.

LG --PerfektesChaos 10:24, 17. Aug. 2015 (CEST)

• Auf jeden Fall könnte das Dingens eine Entschlackung und Kapselung vertragen.
• Danach könnte es als Default-Gadget ausgelagert werden, so dass angemeldete performance-besorgte Nutzer es deaktivieren können.
• Der URL-Parameter ist obsolet und kann weg.
• Ebenfalls tschüss kann in der Regel die Richtung „Mache https zu http“, weil nicht mehr vorkommend.
  • Gäbe es nur noch für dumps/download, uraltes Mobil-m und das Sorgenkind beta.wmflabs.org – bis die WMF mal 500 Dollar für ein Zertifikat zusammenkratzt.
• Bliebe „http zu https“ und beides mit Verhinderung des XSS-Verdachts.
  • Das sind deutlich weniger zu untersuchende URL-Konstrukte.
  • Mit Glück werden die eingebauten Links vom Browser sowieso als relative /w/index.php usw. auch an JS weitergegeben; sind dann noch weniger, die überhaupt mit explizitem Protokoll auffallen, wie auch bisher schon.

LG --PerfektesChaos 12:30, 17. Aug. 2015 (CEST)

Ich habe mal alle Spuren zu dem Skript vernichtet. Der Umherirrende 20:08, 23. Aug. 2015 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 20:08, 23. Aug. 2015 (CEST)

Function „Neuen Abschnitt“-Link

Mal abgesehen davon, dass diese Funktion vollkommen unnötig und verschwenderisch auf jeder Seite versucht (mit Modul und jQuery-Selektor) zu greifen, wollte ich eigentlich fragen, wie es mit denn Seiten aussieht aller WP:GWS? Ich finde die Funktion an sich auch nützlich (auch wenn ich sie nicht nutze, da sie im Prinzip eher einen anderen Bug vermeiden soll und eher für Neulinge gedacht ist), allerdings könnte man diesen Umstand auch per Phab melden (wie man im Archiv hier sieht, nicht nur hier nützlich ist/sein kann). Grüße PS: wahrscheinlich lohnt sich das nicht, da derlei Seiten wohl eh viel zu selten sind.↔ User: Perhelion 17:19, 10. Feb. 2016 (CET)

Der JavaScript-Codeschipsel hier erzeugt nicht nicht den Neuen-Abschnitt-Knopf, sondern dupliziert den Knopf von der Werkzeugleiste von ganz oben – sofern vorhanden – zum letzten Abschnittbearbeitungsknopf. Der Knopf oben wird auf Diskussionsseiten automatisch und auf anderen Seiten durch das magische Wort __NEWSECTIONLINK__ (oder __NEUER_ABSCHNITTSLINK__ oder __PLUS_LINK__) erzeugt. Siehe Hilfe:Variablen#Schalter und andere magische Wörter. --Fomafix (Diskussion) 17:35, 10. Feb. 2016 (CET)

Aja, trotzdem ist das Suchen nach dem Link im Artikelnamensraum (wie bestimmt in der Mehrzahl Namensräumen) vollkommen sinnlos, genau genommen fällt mir nur der Projekt-NR (4) und der Diskussions-NR ein (evtl. noch Benutzer).

PS. Variable: ist es wirklich sinnvoll die NR var, hier konkret 6mal per mw.config.get( 'wgNamespaceNumber' ) abzurufen?↔ User: Perhelion 21:40, 10. Feb. 2016 (CET)

Die Seite wurde in funktionale Abschnitte gegliedert, die einzeln kopierbar sind. In diesem Fall kommt es zu Duplizierung von Code oder Conditions. Ich denke aber, das dies aus Performance-Sicht sehr zu vernachlässigen ist und die erkennbaren Abschnitte hier überwiegen. Anders sähe es aus, wenn es Beschwerden über Performance gibt und die auf diese Seite zurückzuführen sind. Der Umherirrende 21:48, 10. Feb. 2016 (CET)

Gut kann man so sehen, ich habe wohl eine Art Performanz-Phobie. Eine einzelne DOM-Suche fällt wohl tatsächlich nicht auf (allerdings treten Probleme immer in Kombination auf). Noch erwähnen wollte ich, dass ich diesen "Zwangshack" (übertrieben gesagt) gar nicht zu Gesicht bekomme (da ins Leere läuft), da ich das wesentlich nützlichere (ältere) Helferlein SectionLinks von Schnark benutze. PS: ebensowenig bekomme ich Disksussionsbeiträge (ohne Weiteres) zu Gesicht, die als Minor markiert sind.↔ User: Perhelion 13:51, 13. Feb. 2016 (CET)

Man muss immer ein gesundes Maß zwischen Performanz und Wartbarkeit hinbekommen, das kann eine Gradwanderung werden oder von verschiedenen Personen unterschiedlich aufgenommen werden. Die Modul-Abfrage hier ist unkritisch, weil das Modul im Standard vorhanden ist. Der Hack sollte jeden "Treffen", außer die Kopie wird explizit wieder entfernt. Alle meine Bearbeitungen sind minor, daher auch meine Diskussionsbeiträge. Der Umherirrende 20:06, 14. Feb. 2016 (CET)

Ok, danke der klärenden Antwort. Aber schon etwas lustig mit deinen Minoredits. ^^ ↔ User: Perhelion 14:43, 17. Feb. 2016 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: ↔ User: Perhelion 14:43, 17. Feb. 2016 (CET)

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)

Zwischenzeitlich ist bugzilla:19499 zu phab:T21499 mutiert und gefixt. Daher gehe ich (ohne es wirklich sicher zu wissen) davon aus, dass das Ziel durch Vorlagenprogrammierung erreichbar ist und weder JavaScript- noch CSS-Ergänzungen angezeigt sind.

Falls diese Annahme nicht stimmt und das Feature weiterhin gewünscht wird, bitte ggf. melden und den konkreten Einsatzzweck nennen, dessen Sinnhaftigkeit dann zu beurteilen wäre. Allerdings wird die Etablierung neuer derartiger Klassen mittlerweile sehr zurückhaltend gehandhabt. --Entlinkt (Diskussion) 06:04, 27. Mär. 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Entlinkt (Diskussion) 06:04, 27. Mär. 2016 (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)

Wie in dem zwischenzeitlich archivierten Abschnitt der Vorlagenwerkstatt prophezeit, findet sich wohl kein Admin, der dies einbaut.

Im Gegensatz zur Anfrage finde ich persönlich die aktuelle Uhrzeit eines Ortes außerdem gar nicht schwer eruierbar, käme aber kaum auf die Idee, in einem Lexikon danach zu suchen. Dafür gibt es reichlich Apps und dergleichen. Im Übrigen ist der Neueinbau von JavaScript speziell für einzelne Vorlagen mittlerweile kaum noch üblich. --Entlinkt (Diskussion) 05:30, 27. Mär. 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Entlinkt (Diskussion) 05:30, 27. Mär. 2016 (CEST)

Navigationsleisten und Live Preview

Ist Live Preview noch ein lebendiges Projekt? Wenn ja, wäre es schon schön, wenn auch unser Navigationsleisten-Klappmechanismus damit kompatibel wäre. Derzeit sind im DOM keine Spuren des Skripts erkennbar, wenn Live Preview benutzt wird. --Entlinkt (Diskussion) 00:54, 20. Apr. 2016 (CEST)

• LivePreview ist wohl unverändert voll im Leben.
  • VE müsste vom selben Problem betroffen sein, aber den benutze ich nicht.
  • Eine Modernisierung würde sich also lohnen.
• Problem: Das Ding sieht aus wie von irgendwoher kopiert.
  • Dann müsste upstream aktualisieren, oder wir müssten uns zum Fork entscheiden.
• Wenn Fork, dann mit mir nur per default gadget (opt-out).
  • Dann kann es sauber gekapselt werden, und die dann vierfach ineinander verschachtelten Funktionsdefinitionen werden transparenter.
  • Dann bekommt das Kind auch einen Namen, und es kann en bloc aus und nach BETA kopiert werden, und erhält eine Versionsgeschichte.
  • Als unabhängige Programmeinheit könnte es dann auch eine Dokumentation für Programmierer erhalten.
  • Im Moment sind es nur irgendwelche namenlosen Zeilen irgendwo zwischen irgendwelchen anderen namenlosen Zeilen.
  • So wie du das Common CSS entschlackst, möchte ich perspektivisch ein modulares Common JS haben mit möglichst kurzem allgemeinen Common-Site-Code.
  • Die Organisation in einem großen Haufen zusammenkopierter Zeilen ist so zeitgemäß wie die Aufforderung, man möge doch regelmäßig seine komplette monobook aus einer anderen monobook abkopieren.
  • Gäbe im Übrigen Benutzern die Möglichkeit zum Abschalten des Einklapp-Codes.
  • Ansonsten siehe Ende des vorherigen Abschnitts.

LG --PerfektesChaos 10:05, 20. Apr. 2016 (CEST)

Der Navileisten-Klappcode ist wirklich eine Eigenentwicklung von uns (März 2005), siehe hier und dort. Den haben vielmehr manche von uns geforkt (siehe den Kommentar „box hiding thingy from .de“ in en:MediaWiki:Common.css).

Aber Moment, vielleicht ist die Kopie in en:MediaWiki:Common.js ja schon angepasst? Die Zeile

mw.hook( 'wikipage.content' ).add( createNavigationBarToggleButton );

sieht nicht schlecht aus. --Entlinkt (Diskussion) 11:04, 20. Apr. 2016 (CEST)

Stopp, 1:1-Übernahme aus enwiki geht nicht, die haben diverse zwischenzeitlich erfolgte Verbesserungen von uns nicht. --Entlinkt (Diskussion) 11:10, 20. Apr. 2016 (CEST)

Das Statement ist genau das, welches es für LivePreview und VE braucht.

Nur wird das dann eine noch umfangreichere Geschichte; und das geht anonym mit einer weiteren Funktionsdefinitionsebene oder mit einer benannten Funktion, was es noch länger und auslagerungsbedürftiger macht.

Das mit diesem Raus- und Abkopieren von einigen Dutzend Zeilen ist genau das, was die Herkunfts- und Versionsgeschichten und die Wartung/Pflege so unerfreulich macht. Ich durchschaue das schon lange nicht mehr; dass die enWP einen unabhängigen Fork hat, weiß ich aus Bilderwunsch-Zeiten. Es geistern ein halbes Dutzend Implementierungen für die gleiche Aufgabe durch die Wiki-Welt; von MW bis enWP und C&P.

LG --PerfektesChaos 11:54, 20. Apr. 2016 (CEST)

Es müsste reichen bei uns das

mw.loader.using( [ 'mediawiki.util', 'jquery.makeCollapsible', 'user', 'mediawiki.user', 'user.options' ], function() { 
$(function() {

zu ersetzen durch

mw.loader.using( [ 'jquery.makeCollapsible', 'user', 'mediawiki.user', 'user.options' ], function() { 
mw.hook( 'wikipage.content' ).add( function( $content ) {

und das

var NavFrames = mw.util.$content.find( 'div.NavFrame' );

duch

var NavFrames = $content.find( 'div.NavFrame' );

Wobei ich mir aber auch schon mal überlegt habe, ob man die Navigationsleisten nicht ganz auf jquery.makeCollapsible umstellen sollte. Das würde allerdings zusätzliche Klassen in der Navileistenvorlage (und eventuell weitere Umstrukturierungen) erfordern, sowie für den Startzustand je nach Anzahl auf kürzlich eingefügt Hooks zurückgreifen. --Schnark 09:33, 21. Apr. 2016 (CEST)

@Schnark: Bei dir fehlt noch eine schließende Klammer ;-}

Das mit der Umstellung auf …Collapsible war auch schon mal diskutiert worden.

• mw-collapsible wäre am simpelsten.
• Das gibt es aber nur mit einer Animation von 0,4 Sekunden.
• Und um diese 0,4 Sekunden gäbe es dann hier Zeter und Mordio … und vertane Lebenszeit im Wochenbereich.
• MediaWiki findet die Animation schick und zeitgemäß und will die weltweiten User nicht mit blitzschnell veränderten Seiteninhalten erschrecken.
• MediaWiki wird sicher nicht ihre Software verkomplizieren, indem sie irgendwelche site-user-konfigurierbaren Extraselektoren und Optionen einbauen, mit denen man einige oder alle Elemente ohne Animation je nach Projekt- und Benutzerkonfiguration klappern lässt.
• Stichwort Bilderwunsch/TMg.
• Aus der Nummer kommen wir nicht raus.

LG --PerfektesChaos 10:17, 21. Apr. 2016 (CEST)

@PerfektesChaos: Ich bin nicht sicher, ob es um die Animation unbedingt Zeter und Mordio geben muss. Ich habe zwar selbst erst kürzlich auf Vorlage Diskussion:Bilderwunsch auf drohenden Protest wegen der Animation hingewiesen, aber vor allem deshalb, weil TMg sich dort vehement dagegen ausgesprochen hatte.

Ich bin aber nicht sicher, ob das der Weisheit letzter Schluss sein muss. Das Inhaltsverzeichnis in fast jedem Artikel hat ja schon seit einiger Zeit die Animation, und da kann ich mich nicht daran erinnern, große Proteste vernommen zu haben. Vielleicht sollte man einfach mal eine Vorlage „zum Test“ umstellen und schauen, was dann passiert.

Natürlich kommt dafür nur eine Vorlage in Frage, bei der das sowieso sinnvoll wäre. Vielleicht ist die Vorlage:Bilderwunsch insofern sogar ein guter Kandidat, da auf der dortigen Diskussionsseite die unerwünschte Wechselwirkung mit Navigationsleisten bemängelt wurde. --Entlinkt (Diskussion) 20:16, 23. Apr. 2016 (CEST)

Mach wie denkt du – außer dass sich deine AWW füllt, kann ja nicht viel passieren, und wenn es einen Zwergenaufstand gibt, kann man ja auch reverten. LG --PerfektesChaos 20:26, 23. Apr. 2016 (CEST)

AWW wegen Edits in einer nur 1/2 (noch nicht mal 3/4) geschützten Vorlage? Glaube ich nicht. Wir hatten letztens erst „merkwürdige“ Edits in der vollgeschützten Vorlage:Navigationsleiste (inklusive temporärer Komplettzerstörung), und da gab es keine AWWs.

An das Skript hier würde ich mich allerdings tatsächlich nur nach sehr guter Vorbereitung herantrauen, soweit die Optik wahrnehmbar betroffen ist. Gruß --Entlinkt (Diskussion) 20:36, 23. Apr. 2016 (CEST)

Wo soll bei mir eine Klammer fehlen? --Schnark 10:20, 21. Apr. 2016 (CEST)

Du hast recht; es haben

mw.hook( 'wikipage.content' ).add(

und

$(

genau gleich viele geöffnete Klammern. LG --PerfektesChaos 10:28, 21. Apr. 2016 (CEST)

Ich habe nach (kurzem) Test im β-dewiki den Patch von Schnark übernommen. --Entlinkt (Diskussion) 03:07, 22. Apr. 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 16:36, 22. Apr. 2016 (CEST)

Unnötige Abhängigkeit bei keepLocalFileTabs?

Kann es sein, dass in dem Teil

if (mw.config.get( 'wgNamespaceNumber' ) === 6) {
 mw.loader.using( [ 'mediawiki.util', 'user', 'mediawiki.user' ], function() { $( function() { //wait for overrides in user.js
	if ( mw.config.get( 'keepLocalFileTabs', false ) ) {
		return;
	}
... usw. usf. ...

die Abhängigkeit von mediawiki.user unnötig ist? Ich hatte diese zusammen mit user vor 3 Jahren (relativ ahnungslos) eingefügt, weil die Einstellung nicht funktioniert hatte, aber eigentlich sollte doch user ausreichend sein, oder? --Entlinkt (Diskussion) 20:28, 29. Apr. 2016 (CEST)

Gemäß Schnark überflüssig, da er dies auch bei mir mal beanstandete. ↔ User: Perhelion 22:15, 29. Apr. 2016 (CEST)

Danke. Ich hab's entfernt. Das war nur von den anderen Stellen abkopiert (also genau so, wie man es nicht machen sollte). Gruß --Entlinkt (Diskussion) 22:31, 29. Apr. 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Entlinkt (Diskussion) 22:31, 29. Apr. 2016 (CEST)

Commons-Tab-Manipulation

Die common.js enthält Code, der (unter anderem) den Bearbeitenlink bei Dateibeschreibungsseiten nach Commons ändert (und auch die Diskussionsseite, aber das ist nicht so problematisch), siehe „Lokaler Dateidiskussionsseitenlink eines Commonsbildes verweist nach Commons“. Das hat mehrere Probleme:

• Bei Standardeinstellungen (d. h. mit VE) führt der primäre Bearbeiten-Link zum Anlegen einer lokalen Dateibeschreibungsseite, das Skript manipuliert nur den Quelltexteditor-Link.
• Wenn man den Quelltexteditor im VE aktiviert hat, dann führt ein normaler Klick auf den geänderten Link zum Anlegen der Beschreibungsseite ebenfalls zur lokalen Seite, trotz geänderter URL, öffnet man dagegen den Link in einem neuen Tab, so kommt man nach Commons. Hat man dort den NWE aber nicht aktiv, kommt man erst einmal nicht in den Bearbeiten-Modus.
• Die Änderung der Beschriftung hat zwar zunächst keine sichtbare Auswirkung (da sie vom VE direkt wieder überschrieben wird), führt aber dazu, dass die Breite, die die Tabs benötigen, falsch berechnet wird, siehe Wikipedia:Fragen zur Wikipedia#Menüleiste verrutscht Update.

Mit anderen Worten, der Code macht mehr Probleme als er löst und sollte meiner Ansicht nach entfernt werden. Der Teil, der den Link auf die Diskussionsseite ändert, kann meinetwegen bleiben, falls ihn andere für sinnvoll halten, der macht zumindest keine störenden Probleme. –Schnark 09:16, 21. Feb. 2017 (CET)

1. [ceterum censeo] Auslagern dieses Code-Blocks in ein separates Gadget: fileTabCommons.
   • Damit gibt es eine separate Dokumentation und Versionsgeschichte.
2. Erstmal Opt-Out draus machen; als Soforthilfe.
3. Weitere dependency: user.options
4. Dann die user.options kurz analysieren, ob Immer-VE, Wikitext-VE; dementsprechend die Tabs überhaupt nicht oder anders mit Links belegen.
5. Was zum Henker ist das eigentlich mal wieder für ein undokumentiertes keepLocalFileTabs?
   • Mit einem Opt-Out kann es wegfallen, genauso wie die deswegen immerhin schlauerweise eingefügte dependency user (wiewohl das die Sicherheit das Schlafwandlers und mehr zufälliges Glück war).
6. Beiläufig unterstellen, dass auf Commons gleichartige Präferenzen wie lokal voliegen.

LG --PerfektesChaos 12:05, 21. Feb. 2017 (CET)

Es kann auch entfernt werden. Es gibt schon länger einen entsprechenden Button für Commons. Wenn man dann doch mal auf der lokalen Bearbeitungsseite landet, gibt es auch einen Hinweis, dass man "falsch" ist. Im VE leider nicht (phab:T158693). Würde dann auch weniger Abweichungen zu anderen Wikis bedeuten. Der Umherirrende 21:09, 21. Feb. 2017 (CET)

Wenn sich nach einer Woche keiner äußert, dann habe ich mal entschieden, es ohne zu versuchen. Mal schauen wie es ankommt. Der Umherirrende 19:54, 28. Feb. 2017 (CET)

Die Reiterleiste wird jetzt zumindest zuverlässig eingeklappt, wenn sie zu lang ist. –Schnark 08:51, 1. Mär. 2017 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 20:04, 3. Mär. 2017 (CET)

Temporäre Funktion vom 12.-22.4.

Hallo allerseits, vom 12. bis 22.4. würden wir gern folgende Zeile in der common.js ergänzen:

/*  mw.loader.load( '/w/index.php?title=User:Addshore/wmdespring2017.js&action=raw&ctype=text/javascript' );

und zwar mit folgendem Hintergrund: In diesem Zeitraum läuft eine Neuautor*innenkampagne. Wir wollen am Ende der Kampagne auswerten, wie erfolgreich sie war, d.h. wie viele Registrierungen darüber erfolgt sind. Desweiteren soll zufallsgesteuert den Neuregistrierten eine geführte Tour angeboten werden. Hier soll ausgewertet werden, wie hilfreich eine solche Tour war. Die Kampagne selbst und die geführte Tour wurden bereits an den verlinkten Stellen diskutiert. Das aufgerufene Modul ist hier (Phabricator Task) einsehbar. Im Beta-Wiki wird die Funktion gerade getestet.

Sieht jemand Probleme mit der Funktion? --Verena Lindner (WMDE) 19:19, 10. Apr. 2017 (CEST)

• Das grundsätzliche Ziel soll gern erfüllt werden.
  • Ist üblicherweise binnen eines halben Tages live.
  • Einfach Bescheid geben, wenn Tests abgeschlossen sind, und die Aktion starten soll.
• Was die organisatorische Umsetzung angeht, hätte ich allerdings andere Vorstellungen.
  • Ich denke mehr an MediaWiki:Gadget-guidedTour/2017a.js
  • Benutzer:Addshore/wmdespring2017.js wie oben suggeriert gibt es ohnedies nicht. Und aus BETA würden wir erst recht nicht laden.
  • Müsste Addshore da nochmal und dauernd ran?
  • [ResourceLoader|hidden|dependencies=mediawiki.cookie,mediawiki.util|default]
• @Addshore:
  • I would prefer lazy loading of ext.guidedTour.launcher iff trigger was pulled, avoiding loading for the other 50 % and registered users.
  • You won’t need ==0, even more with two rather than three equal signs. Omitting that term results in the same statistical quota.
  • Do you expect a need for permament access to that code? Or fire and forget? Copying once into MediaWiki: would be preferred over User:.

Greetings --PerfektesChaos 20:20, 10. Apr. 2017 (CEST)

So, it looks like we will no entirely be doing this in PHP, so no JS / change to Common.js will be needed! Addshore (Diskussion) 12:58, 11. Apr. 2017 (CEST)

That’s fine. Enjoy --PerfektesChaos 13:08, 11. Apr. 2017 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Entlinkt (Diskussion) 02:26, 30. Apr. 2017 (CEST)

jquery.ui.button

Das Modul jquery.ui.button wurde vor kurzem als deprecated markiert, sodass man jetzt auf Seiten wie Wikipedia:Qualitätssicherung eine Warnung in der Browserkonsole erhält, weil durch Common.js das Modul geladen wird, wenn die entsprechende Klasse auf einer Seite verwendet wird. Aktive Seiten, die die Klasse verwenden, gibt es zum Glück nicht so viele. Hat jemand Lust, sich ein bisschen Unmut von Benutzern zuziehen, die gegen jegliche Veränderung im Aussehen sind, diese Verwendungen auf mw-ui-button umzustellen und anschließend das Modul nicht mehr zu laden? --Schnark 11:47, 23. Aug. 2016 (CEST)

I do volunteer for template:button.

• Ich muss mich da aber erstmal in den neuesten mw-Design-Stand einlesen, damit die Änderung möglichst sanft ausfällt. Die restliche Programmierung (Parameter) wäre dem vermutlich ebenfalls anzupassen. Also zunächst BETA.

Für den Rest empfehle ich dann einen Bot-/Admin, der gemäß dieser Erkenntnisse eine zarte Änderung aus neutraler Position ausführt; ggf. direkt auf die Vorlage als neutrale zentrale Hülle umstellt.

Haste mal ’ne Task # als Argumentationshilfe?

LG --PerfektesChaos 12:09, 23. Aug. 2016 (CEST)

phab:T142418 --Schnark 12:23, 23. Aug. 2016 (CEST)

Übrigens ist auch bei mediawiki.ui damit zu rechnen, dass es über kurz oder lang als deprecated markiert wird, siehe [17]. --Schnark 09:27, 25. Aug. 2016 (CEST)

Ach du heiliges Spaghettimonster.

• Ich habe mir zwischenzeitlich die ganzen Verwendungen durchgeguckt.
• Mich außerdem in die neuesten Design-Moden und OOjs eingelesen.

Ich schlage folgende Strategie vor:

1. Projektweite Seiten wie WP:QS oder WP:3M mit direkter oder indirekter Einbindung:
   • Ersatz durch Vorlage:MediaWiki-Button
   • Diese als einzige zentrale Vorlage für das hiesige Projekt unterhalten und gemeinschaftlich pflegen.
   • Hierfür C&P der weltweiten Elemente; irgendwie halten die das Design ja auch am Laufen.
2. Portale, Wikiprojekte, BNR:
   • Auf Disk informieren; anraten, ein Gleiches zu tun.
3. WP:NEU – Ankündigung der hiesigen Abschaltung zum 31. Dezember 2016.
4. Vorlage:Clickable button 2 und Vorlage:button
   • Als veraltet kennzeichnen.
   • Kein Projekt-Support von dewiki mehr.

Viel Spaß bei der Umsetzung --PerfektesChaos 00:04, 4. Okt. 2016 (CEST)

@Umherirrender: Bitte als Sofortmaßnahme auf BNR einschränken:

if ( mw.config.get( "wgNamespaceNumber" ) === 2 ) {
   mw.hook( 'wikipage.content' ).add( function ( $content ) {
           if ( $content.find( '.ui-button' ).length ) {
                   mw.loader.load( 'jquery.ui.button' );
           }
   } );
}

• Es soll ab jetzt niemand mehr Erfolgserlebnisse auf irgendeiner Projektseite haben.
• Außerhalb des BNR sind ab heute alle aktiven Verwendungen durch blaue Buttons ersetzt:
  • ui-button
  • Vorlage:Button
• Nebenbei wird jede andere Seite dadurch ein μ schneller.
• Den restlichen Benutzern sollte administrativ angekündigt werden, dass sie ihre Seiten nun freundlicherweise umbauen dürfen; mit Hinweis auf fehlende MW-Unterstützung.
  • Spätestens mit 31. Dezember 2017 sollte der obige Code entfernt werden.
  • Sind vermutlich auch inaktive dabei.
  • Der Seite passiert erstmal nichts, sieht nur nicht aus.
  • Vorlage:Button ist 2018 Löschkandidat, und das Modul auch.

Außerdem bitte auf MediaWiki:Common.css #mw-content-text #issnlink, eliminieren.

• Vorlage:ISSN-Link wurde aufgelöst.

LG --PerfektesChaos 01:06, 24. Jul. 2017 (CEST)

Code wurde eliminiert.

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 10:32, 14. Aug. 2017 (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)

Archivierung dieses Abschnittes wurde gewünscht von: hgzh 14:39, 11. Apr. 2022 (CEST)

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)

Gibt es da einen Phabricator-Task zum Thema? --Leyo 14:24, 6. Mär. 2017 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: hgzh 14:39, 11. Apr. 2022 (CEST)

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: [18] [19] [20]. More information: Magnus blog.
How to: just add the following line at the end of Common.js.

// Results from Wikidata
// [[File:<file>28</file>]]
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)

Siehe dazu auch Wikipedia:Fragen zur Wikipedia#Roter Interwikilink, wo ein Einbau befürwortet wird. Wenn niemand was dagegen hat, könnte es ja demnächst aktiviert werden. NNW 15:48, 9. Jul. 2015 (CEST)

@NordNordWest: Dieses Skript wir schon seit einiger Zeit in der Esperantowikipedia genutzt. Ich weiß aber nicht, welcher Admin es dort in eo:MediaWiki:Common.js eingebaut hatte. --Tlustulimu (Diskussion) 16:27, 9. Jul. 2015 (CEST)

Sörwiß. NNW 16:32, 9. Jul. 2015 (CEST)

Also, das vorgeschlagene importScriptURI schreiben wir hier ganz sicher nicht rein.

en:MediaWiki:Wdsearch.js gucke ich mir die Tage mal näher an. Ist etwas komplexer.

Wer sowas ganz dringend haben möchte, kann es sich jederzeit selbst aktivieren.

Generell bauen wir sowas ohnehin nicht mehr in diese Common.js hier ein, sondern nur noch unter Gadgets, wo es angemeldete Benutzer auch leicht deaktivieren könnten.

VG --PerfektesChaos 16:33, 9. Jul. 2015 (CEST)

@PerfektesChaos: Die Idee mit dem Gadget finde ich gut. Komisch, daß ich da nicht selbst drauf gekommen bin, obwohl in den drei Wikipedien, wo ich Admin bin, schon einige Gadgets erstellt habe. Wie sieht denn so etwas als Gadget aus? Gruß --Tlustulimu (Diskussion) 19:07, 9. Jul. 2015 (CEST)

• Eine einfache Syntaxanalyse offenbart im Ziel-Skript zunächst zehn Schlampigkeiten bzw. Kodierungsmängel; darüberhinaus einen schweren Syntaxfehler und reihenweise laienhafte Programmierpraktiken.
  • Diese Version hat noch nie jemand zu kompilieren versucht, oder irgendeine Version syntaktisch analysiert; soweit doch, wurde erfolglos versucht, die Fehlerwarnungen zu unterdrücken.
• Auf gar keinen Fall darf sowas zwangsweise und unausweichlich von unserer Common.js eingebunden werden.
  • Obendrein nehmen wir nichts größeres Neues mehr in unsere Common.js auf, sondern lagern es vielmehr perspektivisch in separate Module aus.
  • Im Idealfall ist zum Schluss unsere Common.js fast leer, oder enthält nur noch wenige Konfigurationszeilen und einen Universal-Algorithmus zur situationsabhängigen Aktivierung von ausgelagerten Einzelaufgaben gemäß einer Datentabelle.
• Ob es gewünscht und ratsam ist, dieses Werk offiziell in unseren Kanon aufzunehmen, werde ich nicht entscheiden. Das muss der Admin verantworten und anschließend weiter pflegen und betreuen, der das einfügt.
• Wenn es denn so sein soll, sind folgende Schritte auszuführen:
  1. Deutschsprachige Doku unter Wikipedia:Technik/Skin/Gadgets/wdsearch anlegen.
     • In der inhaltlichen Gliederung kann man sich weitgehend an Wikipedia:Technik/Skin/Gadgets/wikEd halten. Die macht in etwa den gleichen Vorgang, nur zu einer völlig anderen Thematik.
     • Allerdings verweist jene hinsichtlich der Funktionsbeschreibung auf Wikipedia:Technik/Text/Edit/wikEd – das müsste in diesem Fall integriert werden, so wie bei Wikipedia:Technik/Skin/Gadgets/Vorlagenmeister.
  2. Danach kann zur Aktivierung so vorgegangen werden wie unter Wikipedia:Technik/Skin/Gadgets beschrieben.
     • Dabei kann man sich wieder an wikEd anlehnen.
     • @Tlu: Das müsste alle deine Fragen beantworten können.
  3. Der JS-Code sähe, anders als anderen Stellen dargestellt, wie folgt aus:

/// w:de:MediaWiki:Gadget-wdsearch.js  2015-07-10
/*jshint curly:true, eqeqeq:true, latedef:true, laxbreak:true,
         strict:true, trailing:true, undef:true                        */
/*global window:false                                                  */

( function ( mw ) {
   "use strict";
   var env = mw.config.get( [ "wgArticleId",
                              "wgCanonicalSpecialPageName" ] );
   if ( env.wgCanonicalSpecialPageName === "Search"   ||
        ! ( env.wgArticleId  ||  env.wgCanonicalSpecialPageName ) ) {
      mw.loader.load( "https://en.wikipedia.org/w/index.php?title=MediaWiki:Wdsearch.js&action=raw&bcache=1&maxage=3600&ctype=text/javascript" );
   }
   mw.loader.state( "ext.gadget.wdsearch", "ready" );
}( window.mediaWiki ) );

LG --PerfektesChaos 00:04, 13. Jul. 2015 (CEST)

Magst du den „schweren Syntaxfehler“ nicht unter en:MediaWiki talk:Wdsearch.js melden, so dass dieser behoben werden kann? --Leyo 00:33, 13. Jul. 2015 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: hgzh 14:39, 11. Apr. 2022 (CEST)

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
			);
		} );
	} );
} );

Archivierung dieses Abschnittes wurde gewünscht von: hgzh 14:39, 11. Apr. 2022 (CEST)

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)

2 Jahre später kein Ergebnis aus diesem Diskussionsstrang. Soll daraus nochmal etwas werden?

Meiner Meinung nach ist eine realistische Chance für Ergebnisse gegeben, wenn man kleine Schritte vereinbart. Ich würde deshalb vorschlagen, als Erstes die sowieso schon in separate Seiten ausgelagerten Codeteile in hidden-Gadgets umzuwandeln. Das sollte keine große Sache sein. Spielraum gibt es hier eigentlich nur bei den Namen. --Entlinkt (Diskussion) 02:46, 21. Apr. 2016 (CEST)

Sehr gern.

• MediaWiki:Onlyifuploading.js → Gadget-onUpload
  • Ist von Schnark und aktuell; nur noch kapseln.
  • hidden
• MediaWiki:Common.js/watchlist.js → Gadget-watchlistMessage
  • hidden
  • Komplettsanierung erforderlich:
    • document.cookie
    • globale dismissWatchlistMessage
    • javascript:dismissWatchlistMessage ist teilweise schon von Browsern unterbunden.
    • halb DOM, halb jQuery
    • Ein Cookie pro Watchlist-Message ist auch archaisch. Heutzutage schreibt man in persistenten lokalen sessionStorage (Web Storage), während Cookies mit jedem Seitenabruf an den Server übertragen werden.
    • Das mit dem Raufzählen von Nummern ist auch antik; ich würde eine id="watchlist-message-BeliebigesSchlagwort" setzen. Weil nur eine einzige brandaktuelle Nachricht angezeigt wird, muss man sich nicht die lokal bis zu 5 oder 10 frischesten freien Bezeichner merken, sondern nur, ob man den brandaktuellsten schon gesehen hat.
  • Es wäre heutzutage möglich, die Existenz einer ungelesenen watchlistMessage erst zu prüfen und den HTML-Code nur einzublenden, wenn es eine ungelesene Nachricht gibt. Die sehen dann allerdings die JS-Deaktivierten nicht. Hingegen gäbe es für Interessierte die Möglichkeit, das Teil standardmäßig per CSS auszublenden, bei einer ungelesenen Nachricht jedoch aktiv wieder einzublenden, indem statt id die class als Selektor genutzt würde.
  • Würde ich auf BETA völlig neu schreiben und vorstellen; aber erst in einigen Wochen.
  • Siehe auch Wikipedia:Technik/Skin/MediaWiki#Aktuelles – anscheinend die einzige Doku bislang.
• MediaWiki:Onlyifediting.js → Gadget-editsourceInsertstrings
  • Noch nicht einmal hidden, sondern ganz normal sichtbar zum opt-out, somit default.
  • Die Abfrage, ob es benötigt wird (Quelltextbearbeitung), würde ich dann in ein sichtbares Mini-Gadget voranstellen und im Erfolgsfall den jetzigen Code als in der Tat hidden im minimierten und versionierten Paket mittels ResourceLoader nachziehen. VE-Nutzer und Nur-Leser laden das Paket wie bisher nie herunter.
  • Würde ich codierungstechnisch aktualisiert auf BETA anpassen und vorstellen; aber erst in einigen Wochen.
    • Müsste zumindest gekapselt werden; stellt zurzeit eine var charinsert in den globalen Namensraum.
    • Ist komplett in DOM geschrieben; das würde ich dann als jQuery-frei auch in der Kapselung zum Ausdruck bringen.
• Die neuen Seiten wären von BETA hierzuwiki neu anzulegen; nach erfolgter erfolgreicher Umstellung die bisherigen Versionsgeschichten dranbamseln und die alten Seiten löschen.
  • Diskussionen gehen nach WD: an die Doku.

Tja, mal so eben fünf oder zehn Jahre altes Zeugs nur mit einem neuen Seitennamen versehen ist nur die halbe Miete; wenn schon ein deutlicher Umbruch, dann sollte das auch in die Gegenwart beamen.

LG --PerfektesChaos 14:47, 21. Apr. 2016 (CEST)

OK, ich sehe ein, dass das wohl nur bei MediaWiki:Onlyifuploading.js ohne größere Codeänderungen geht.

@Schnark: Was hieltest du davon, MediaWiki:Onlyifuploading.js nach MediaWiki:Gadget-onUpload.js zu verschieben und hier mittels mw.loader.load('ext.gadget.onUpload'); zu laden? Ganz ehrlich, allzu viel Ahnung habe ich davon nicht; ich gehe davon aus, dass es (hier wahrscheinlich eher marginale) Vorteile und keine (erheblichen) Nachteile hat und diese Art des Umbaus prinzipiell erwünscht ist. Ein Nachteil wäre, dass dann überhaupt kein gemeinsames Schema zwischen den drei ausgelagerten Teilen mehr besteht, aber ein Vorteil wäre, dass mit diesem Umbau zumindest begonnen ist. Ich lasse mich da aber auch gern eines Besseren belehren. Gruß --Entlinkt (Diskussion) 01:56, 24. Apr. 2016 (CEST)

Ja, minimale Vorteile (besseres Cache-Verhalten) und minimale Nachteile (ein paar Bytes zusätzlich auf jeder Seite für die Moduldefinition, Wikis ohne Gadgets können unseren Code nicht mehr so leicht kopieren). Da der Code ja ohnehin nur provisorisch hier existiert, bis phab:T4537 global gelöst wurde, spricht letzteres aber in meinen Augen auch nicht wirklich dagegen, die Änderung vorzunehmen.

Mit [ResourceLoader|dependencies=mediawiki.util,jquery.accessKeyLabel|rights=hidden] würde auch der alles umfassende Aufruf von mw.loader.using überflüssig. --Schnark 09:50, 25. Apr. 2016 (CEST)

Dieser Umbau wurde mittlerweile vollzogen, siehe MediaWiki:Gadget-uploadtools.js. --Entlinkt (Diskussion) 02:40, 30. Apr. 2017 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: hgzh 14:39, 11. Apr. 2022 (CEST)

bcache statt smaxage

Hi, der Nächste, welcher hier vorbeieditiert, mag mal das &smaxage=21600 ersetzen durch &bcache=1 – dann wird auch das Tagesalter von maxage wieder wirksam. LG --PerfektesChaos 11:41, 27. Nov. 2014 (CET)

Würde aber bedeuten einen Bug (phab:T71460) zu umgehen. Keine wirkliche Lösung, wenn ich das richtig verstehe. Der Umherirrende 18:10, 27. Nov. 2014 (CET)

Genau darum geht es.

• Ohne &bcache=1 bleibt das &maxage= wirkungslos.
  • Damit bleibt die alte JS-Version ggf. 30 Tage im Cache des Benutzers erhalten, falls nicht zufällig mal geleert würde.
• &smaxage= ist unter HTTPS Nonsens, weil es keine Proxy- oder Knotenrechner unterwegs gibt, die die URL kennen dürfen, und deshalb niemand auf halber Strecke mit einer Seitenversion antworten kann. Nur der Browser des Anwenders und der Zielserver sollen die URL über den Host hinaus kennen, und vielleicht die NSA.

LG --PerfektesChaos 20:09, 27. Nov. 2014 (CET)

smaxage wird durchaus beachtet, nämlich von den WMF-Cache-Servern selbst, zumindest wenn man den Bug per bcache=1 umgeht. Das kann aber ein zweischneidiges Schwert sein, denn die Server cachen die Ressource dann wirklich so lange wie angegeben, und lassen sich von nichts und niemandem überzeugen sie vorzeitig zu aktualisieren. --Schnark 09:23, 28. Nov. 2014 (CET)

• Ja, ist schon völlig klar; deswegen soll der ja auf jeden Fall aus der URL raus.
  • Ursprünglich hatte das mal die shared Zwischenknoten im Netz beeinflusst, was halt unter HTTPS obsolet ist.
• Wenn hingegen die durchaus sinnvolle Begrenzung per maxage greifen soll, dann muss hingegen bcache=1 erstmal rein.

LG --PerfektesChaos 09:50, 28. Nov. 2014 (CET)

Da es solche Bearbeitungen gab, sollten man dieses Thema wohl ignorieren. Der Umherirrende 09:57, 10. Aug. 2015 (CEST)

Na, da widerspricht er sich ja selbst.

• Wenn "maxage" and "bcache" don't exist, does nothing zutreffen würde, dann kann causes edits to not purge the script. (E.g. users continue to get old version) ja nicht sein.
• Das ist genau der Grund, warum ich die Parameter einsetze: Wenn ich abschätzen kann, dass eine Ressource (wie der Wiki-Ball links oben, oder ein stabiles und monatelang nicht mehr zu änderndes Skript) sich in den nächsten Tagen und die kommende Woche nicht mehr verändern wird, und wenn doch, dann wäre eine Verspätung unproblematisch. Ansonsten setze ich eine angemessene Zahl von Stunden.
• Für jedes Skript, für jede kleine Grafik vom Wiki-Ball über bis zu jahrelang ungeändertem CSS wird eine einzelne Anfrage an den Server geschickt, ob die noch frisch wären, bei jedem Seitenaufruf. Ich bin im Moment im Sommerurlaub und hänge an einem lahmen Internet; ich habe aber httpfox drauf und gucke über 20 Sekunden zu, wie er laufend 2kB-Fragen stellt und 2kB-Antworten bekommt; ja, 304, alles fein.

Ob dieser Edit in unserer Community angemessen war, wäre zu hinterfragen. Dieser Contractor scheint sich langsam zu einem Alleinentscheider über 1000 Wikis zu entwickeln, um diesen seine Sichtweisen aufzuzwingen.

LG --PerfektesChaos 10:15, 10. Aug. 2015 (CEST)

Es gab vor einiger Zeit eine Softwareänderung für JavaScript und CSS-Seiten, die nach einer Bearbeitung die action=raw-URLs aus dem Squid-Cache löschen (sofern sie "normalen" Aufbau haben, gedrehte Parameter werden nicht entfernt), damit zumindestens serverseitig die neuste Version ausgeliefert wird. Ob dies Browser-seitig Auswirkungen hat, kann ich nicht beurteilen. Der Umherirrende 10:36, 10. Aug. 2015 (CEST)

Ich bin momentan nicht in der Lage, das genauer zu untersuchen.

Der Server soll ja immer die frischesten Versionen bereithalten, auch in den slaves, keine Frage.

Zumindest bislang war es so, dass bei der oben entfernten Parameterkombination der Browser eine maxage-Direktive im HTTP-Header mitgeliefert bekam, die ihm sagte, dass bis zu dem angegebenen Alter für diese URL keine Rückfragen beim Server erforderlich wären.

Ansonsten liefert MW jeden Mist mit einem erlaubten Höchstalter von Null Sekunden aus. Was für den Text dieser Disku auch sehr sinnvoll ist; bei einem vor zehn Jahren zuletzt bearbeiteten Icon hingegen nicht – da kann man auch mal einen Tag auf eine aufgefrischte Version warten.

Ich hatte mal ein FF-Add-On, das für Ressourcen dieses Nachfragen unterband und die Browser-Cache-Version benutzte, falls vorhanden. Das Add-On ist nicht mehr am Markt, aber den Quellcode habe ich noch. Leider bin ich knapp an Programmierzeit, aber irgendwann baue ich nach dem Muster ein Add-On, das solche Zählpixel wie Powered by MediaWiki, Wikiball, WMF-Logo, Linkmarkierungen und Favicon usw. nebst frei konfigurierbarer Ressourcenliste per URL-RegExp auf den WMF-Seiten auf wenigstens 24 Stunden setzt.

LG --PerfektesChaos 11:01, 10. Aug. 2015 (CEST)

Und übrigens: Wenn man mal ganz dringend einen Hotfix unter die Leute bringen muss, dann kann bei unserem trafficsparenden Vorgehen einfach aus der 259200 eine 259201 gemacht werden. Damit ist es eine andere URL, und damit bekommen sofort alle Gadget-Nutzer mit der nächsten Seite die frischeste Version.

LG --PerfektesChaos 11:32, 11. Aug. 2015 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: hgzh 14:39, 11. Apr. 2022 (CEST)

Phabricator-Tasks

Hallo allerseits, mir ist aufgefallen, dass über diese Datei hier doch einiges an Performance flöten gehen kann (vor allem in Anbetracht dass man diese Funktionalität überhaupt nicht braucht). Des Weiteren sollte es für die meisten Funktionen hier einen Phab-Task geben, da sie ja wohl von allg. Nutzen sind!? Nun bemerkt nicht jeder gleich, dass es diesen gibt und daher auch nicht wenn oder überhaupt dieser gelöst bzw. in MediaWiki integriert. Daher schlage ich übersichtshalber vor, wenigstens hier als Diskussions-header, entspr. P-Tasks (mit vollem Namen) hinweisend zu verlinken. In der Art:

• T7642: Provide "add new section" link at the bottom of (discussion) pages

Erfolgreiches Neues ↔ User: Perhelion  13:11, 30. Dez. 2015 (CET)

1. Das hier sind deWP-interne Angelegenheiten, über die alle deWPler ohne sprachliche oder technische Hürden mitdiskutieren können sollen.
   • Somit scheidet Phabricator als Regelfall aus.
2. Gelegentlich mag sich eine Angelegenheit in der weltweiten Software widerspiegeln; dann kann ja tracked angegeben werden.
3. Was da als Abschnitts-Header verlinkt werden soll, habe ich nicht verstanden; und wenn ich das schon nicht kapiere, dann wird ein zufällig hier etwas anregender Wikipedianer ohnehin nicht begreifen, wie und was er in die Überschrift reinschreiben soll. Also bleibt es bei formloser Mitteilung.
4. Wer Phab-Links angeben mag, hat die Möglichkeit, Show= anzugeben; tracked sieht das nicht vor. Ob und wem der Titel, der teilweise recht lang sein mag und trotzdem wenig aussagen könnte, nun weiterhilft, ist eine andere Frage. Ich müsste in der Regel immer die Task aufmachen und mir durchlesen, worum genau es da ginge. Dass es irgendwas mit dem hiesigen Abschnitt zu tun hätte, würde ich mal annehmen.

LG --PerfektesChaos 13:26, 30. Dez. 2015 (CET)

Ja du hast wohl Recht, Phabricator als Regelfall wohl nicht. Ich meinte eben nicht Abschnitts-Header sondern hier im Kopf der ganzen Diskussionseite, da Abschnitte ja archiviert werden (was ja keinen Sinn macht wenn es sozusagen zur Dokumentation gehören soll).

Hm* tracked würde auch passen, wenn es denn nicht zu aufdringlich erscheint!? Also im Prinzip ist dies hier eher ein Anliegen für eine kleine Dokumentation zur Übersicht, natürlich kann man auch alles in den Quelltext schreiben!?

PS: Ich bin mir relativ sicher dass was für die Deutsche Wikipedia gut ist, ist auch für andere gut, und wenn nicht ist es auch nicht so gut. :-P LG ↔ User: Perhelion  15:22, 30. Dez. 2015 (CET)

Umseitig steht eine Zusammenstellung von Schnipseln.

Langfristig sollten die (auch im neuen Gadgets-Namensraum) sinnnvoll gruppiert in einzelne Seiten zerlegt werden und als hidden gadgets oder, wo ernsthafter Bedarf bestünde, die Ankreuzliste aufblähend für Angemeldete deaktivierbar sein.

Ein Schnipsel über die deutschsprachige Sortierreihenfolge ist genausowenig weltweit von Interesse wie ein deutschsprachiger Hinweis auf andere Wikipedien für die Hauptseite oder unser privates includePage wie auch Spenden-Links für DACH.

Das Zeugs ist über fünf Jahre alt und wäre vorbeugend renovierungsbedürftig.

Da es nahezu keine Admins mit soliden JS-Kenntnissen und Weitsicht mehr gibt, die auch Lust hätten, sich hier auf Experimente einzulassen, wird also einstweilen alles so bleiben wie es ist.

Wem sollen deine Wünsche denn jetzt was bringen und was erwartest du ernsthaft, dass sich ändern würde?

VG --PerfektesChaos 21:26, 30. Dez. 2015 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: hgzh 14:39, 11. Apr. 2022 (CEST)

Links zu Schwesterprojekten

Nachdem inzwischen Schwesterprojekte-Links von Wikidata eingefügt werden, sollte – sofern möglich und nötig – für die weiteren Links (insbesondere Wiktionary) kein neuer Kasten eingefügt werden, sondern die Links an die vorhandenen angefügt werden. Ungetesteter Codevorschlag:

if( mw.config.get( 'wgNamespaceNumber' ) > 0 ) {
  mw.loader.using( [ 'mediawiki.util' ], function() { $( function() {
    var iProject = $( '#interProject' );
    if( !iProject.length ) {
        return;
    }
    var otherProjects = $( '#p-wikibase-otherprojects' );
    var otherProjectsId = 'p-wikibase-otherprojects';
    if( !otherProjects.length) {
        var sistersibling = $( '#p-lang' );
        if( !sistersibling.length ) {
            sistersibling = $( '#p-tb' );
        }
        if( !sistersibling.length ) {
            return;
        }
        //Link auf Parentnode des Portletmenues
        var sisterparent = sistersibling.parent();

        //Erzeuge neues Portletmenue
        var sisterprojectnav = $( document.createElement( 'div' ) );
        sisterprojectnav.attr( 'id', 'p-sisterprojects' );
        sisterprojectnav.attr( 'class', sistersibling.attr( 'class' ) );
        var header = $( document.createElement( 'h3' ) );
        header.text( $( '#sisterProjects:first' ).text() );
        sisterprojectnav.append( header );
        var portletDiv = $( document.createElement( 'div' ) );
        var sistersiblingsub = sistersibling.find( 'div:first' );
        if( sistersiblingsub.length ) {
            portletDiv.attr( 'class', sistersiblingsub.attr( 'class' ) );
        } else {
            portletDiv.attr( 'class', 'pBody' );
        }
        sisterprojectnav.append( portletDiv );

        //Wenn möglich vor den Interwikis einfügen
        if ( sisterparent.has( '#p-lang' ).length ) {
            sisterprojectnav.insertBefore( '#p-lang' );
        } else {
            sisterparent.append( sisterprojectnav );
        }
        otherProjectsId = 'p-sisterprojects';
    }

    //Schwesterlinks ermitteln und einfügen
    iProject.find( 'a' ).each( function() {
        $this = $( this );
        var sistername = $this.text();
        mw.util.addPortletLink(
            otherProjectsId,
            $this.attr( 'href' ) + '?uselang=' + mw.util.rawurlencode( mw.config.get( 'wgUserLanguage' ) ),
            sistername,
            'sister-' + sistername,
            sistername
        );
    });
  })});
}

--Schnark 12:02, 17. Feb. 2016 (CET)

Jetzt sogar getestet. --Schnark 12:10, 17. Feb. 2016 (CET)

Vielleicht lieber als hidden default-Gadget in gekapselt und so, von wegen zukunftsfähig, statt in dem ollen Namensraum in seinem Brei.

Vielleicht braucht ja wer ein Opt-Out.

LG --PerfektesChaos 12:36, 17. Feb. 2016 (CET)

Wenn alle Skripte an einem Ort sind, muss man nicht erst lange suchen, bis man das hat, was man sucht. Wichtiger als irgendwelche akademische Gedanken über die Zukunftsfähigkeit (so alt wie der Stil des Codes ist, sind die nämlich wirklich nur akademisch), ist es zügig etwas zu machen, weil zwei Abschnitte in der Seitenleiste für den gleichen Zweck wie etwa auf Wikipedia:Fragen zur Wikipedia einfach blöd aussehen. --Schnark 09:31, 18. Feb. 2016 (CET)

Hallo, also (wenn man hier "ungetestet" schreibt, da weiß ich nicht genau ob man da Respekt sagen kann :P) die Idee ist ja nicht schlecht, (auch wenn es nur ein vorübergehender oder doch dauerhafter Hack sein sollte). Ich habe mal getestet und es tut sich etwas anderes als beschrieben, also bei FzW sind jetzt zwei lange Kästen vorhanden. Daher verstehe ich den Code nicht, dass ein addPortletLink (in einer Schleife) verwendet wird, das sollte man bei schon vorhanden Elementen doch gar nicht benötigen bzw. auch gar kein neues Menue!? (Da wir ja alle wenig Zeit haben, habe ich mir da auch nur kurz angesehen). LG ↔ User: Perhelion 12:40, 20. Apr. 2016 (CEST)

Das lag wohl daran, dass ich nicht des ersetzenden Codes gewahr war (und somit beim Testen ein doppeltes Menue erschien). Nichtsdestotrotz bleiben die doppelten Links ja unnötig erhalten!? Daher habe ich den Code (etwas optimiert und eine var aus der Schleife genommen) um ein Feature erweitert, das doppelte Projekt-Links ausschließt, siehe Beta. VG ↔ User: Perhelion 13:39, 24. Apr. 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: hgzh 14:39, 11. Apr. 2022 (CEST)

Alle Navigationsleisten ausklappen

Nur zur Dokumentation (wehe, das nutzt jemand im ANR): Durch die Nutzung globaler Variablen gibt es einen lustigen Trick, wenn man alle Navigationsleisten standardmäßig ausgeklappt zeigen will: Man muss dazu nur <div id="NavigationBarShowDefault"></div> irgendwo auf der Seite einfügen. Dadurch gibt es eine globale Variable NavigationBarShowDefault, die das div-Element enthält, beim Vergleich mit der Zahl der Navigationsleisten entscheidet sich das Skript dafür, alle ausgeklappt zu zeigen. Wer ein Argument braucht um globale Variablen zu entfernen, hat jetzt eines. --Schnark 10:20, 15. Sep. 2016 (CEST)

Bei NavigationBarShow und NavigationBarHide funktioniert es nicht, das sich etwas ändert, da typeof Object ergibt und dort auf string abgefragt wird (Wobei es für diese Variablen auch keine Möglichkeit gibt, sie als Nicht-global zu nutzen, außer man schafft es zeitlich das mw-Objekt zu verändern). Soll NavigationBarShowDefault noch auf string und number abgefragt werden? Soll man Angaben über mw.user auch entsprechend abfragen?

Die Global wird aus Kompatibilitätsgrunden wohl erhalten bleiben müssen. Der Umherirrende 18:13, 16. Sep. 2016 (CEST)

Nix tun, schade um Zeit und Mühe.

Müsste in gekapseltem modernen Gadget-Stil komplett neu gebaut werden.

Der JS-Hack in window richtet ja keinen Schaden an.

LG --PerfektesChaos 18:22, 16. Sep. 2016 (CEST)

Ich bin auch für Nichtstun, zumal das ja nicht die einzige Stelle ist, wo ein vergleichbares Problem vorkommt. MediaWiki:Gadget-markAdmins.js, MediaWiki:Gadget-Rechtschreibpruefung.js, MediaWiki:Gadget-Extra-Editbuttons.js, MediaWiki:Gadget-ReferenceTooltips.js und sicher noch ein paar Gadgets, dazu höchstwahrscheinlich einige Benutzerskripte (einschließlich welcher von mir) haben das Problem ja auch in der einen oder anderen Form.

Findet eigentlich jemand Angaben dazu, in welchen Browsern das vorkommt? Es sieht eigentlich nach einem ziemlich archaischem Feature aus, aber als mir vor ein paar Tagen ein alter Firefox (so um die Version 20) in die Hände fiel, konnte ich es dort nicht reproduzieren. --Schnark 09:38, 17. Sep. 2016 (CEST)

Auf stackoverflow wird gesagt, es kommt aus IE und wurde in die anderen übernommen und bei FF ist es buggy (bzw. der erste Zugriff erstellt sie, funktioniert aber nicht über die Konsole). Die Spec ist dort auch verlinkt (Window-Property sind alle named objects und die Ids gehören dazu). HTML-Injection ist bei den Gagdgets aber nicht möglich, da die Sachen mit Strings verwendet werden und dadurch ergibt sich ein [object HTMLDivElement] Der Umherirrende 22:16, 19. Sep. 2016 (CEST)

Aha, mal wieder ein Versuch anderer Browserhersteller bugkompatibel mit IE zu sein. Prinzipiell kann das durchaus Sicherheitslücken erzeugen, etwas

var title = 'Standardtitel';
if (typeof globaleKonfiguration !== 'undefined' && globaleKonfiguration.title) {
   title = globaleKonfiguration.title;
}
$('#firstHeading').html(title);

--Schnark 08:56, 20. Sep. 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: hgzh 14:39, 11. Apr. 2022 (CEST)

Links zu gerenderten PNGs bei SVG-Dateien

Gemeldet in Phabricator
Task T106263

Wenn wir schon dabei sind: Braucht es heutzutage wirklich noch den Code unter „Fügt bei SVG-Grafiken Links zu gerenderten PNGs in verschiedenen Breiten hinzu“? Inzwischen gibt es solche Links (wenn auch mit anderen Größen) standardmäßig (Beispiel), sodass es keinen Grund mehr gibt, diese Links mittels JS hinzuzufügen. Klar, wir können auch warten, bis sich die Datei-URLs so ändern, dass der Code ohnehin kaputtgeht. Aber meiner Ansicht nach können wir ihn auch gleich entfernen. –Schnark 10:36, 1. Mär. 2017 (CET)

zustimmung hab mich immer schon gefragt warum es auf den dateibeschreibungsseiten 2 zeilen mit verschiedenen auflösungen gibt anstatt einer. --Wetterwolke (Diskussion) 11:23, 1. Mär. 2017 (CET)

Info: Die zugehörigen Phabricator-Tasks sind phab:T4581 und phab:T8834, siehe insbesondere auch den Kommentar unter phab:T8834#1427580. Meiner Meinung nach sollte der Code zügig entfernt werden. --Entlinkt (Diskussion) 12:50, 2. Mär. 2017 (CET)

Dann warte ich mal keine 7 Tage. Entfernt. Der Umherirrende 20:04, 3. Mär. 2017 (CET)

Leyo mag es nicht. Da ich einer der wenigen Bearbeiter der Seite bin, wurden auch alle vorherigen Änderungen zurückgesetzt. Es gibt Gründe gegen Rollback, auch wenn man es mit Kommentar verwendet. Der Umherirrende 20:50, 3. Mär. 2017 (CET)

(BK) Ich habe leider den Abschnitt hier übersehen. Da die von MediaWiki angebotenen Grössen in vielen Fällen unbrauchbar sind, habe ich die Entfernung (vorläufig) revertiert. Gerade bei komplexen/detailreichen SVGs (Beispiel) reicht eine Maximalgrösse von z.B. 1355 × 1355 Pixel keinesfalls. Zudem sind die angebotenen Auflösungen teilweise ziemlich merkwürdig: 320 × 226 Pixel | 640 × 453 Pixel | 1024 × 724 Pixel | 1280 × 905 Pixel | 1052 × 744 Pixel. (die letzten drei sind sehr ähnlich). Es fehlt für OMA eindeutig eine grosse Auflösung oder eine Maximalauflösung. Die Umsetzung sollte ja eigentlich nicht ein riesiges Problem darstellen. --Leyo 21:07, 3. Mär. 2017 (CET) PS. Den Rollback-Unfall habe ich korrigiert. Sorry!

Um hier mal einen Kreis zu schließen, die selbe Diskussion gab's auch auf Commons vor einiger Zeit. Ergebnis war demnach phab:T106263 (offen). MfG -- User: Perhelion 23:10, 3. Mär. 2017 (CET)

Kannst vielleicht du einen Patch schreiben? --Leyo 00:00, 4. Mär. 2017 (CET)

Die „OMA“ kommt überhaupt nicht auf die lokale Dateibeschreibungsseite. Die sieht das Bild im Medienbetrachter und kommt eventuell noch auf die Beschreibungsseite auf Commons. Wenn das das einzige Argument ist, den Code hier zu behalten, dann kann er wirklich entfernt werden. –Schnark 09:53, 4. Mär. 2017 (CET)

@Schnark: Nun da ist auf den ersten Blick etwas dran. Der Medienbetrachter bietet die Funktion wohl erst gar nicht, was natürlich einen weiteren Phab-Task berechtigt!?

@Leyo: Den Phab-Task kann ich nicht erl. (da wohl PHP basierend).

Allerdings könnte man tatsächlich den hier (zur Löschung gewünschten) Code dahingehend ändern, dass er entweder einen größeren Wert (an die Default-Leiste) anhängt oder ein Eingabefeld erzeugt (was jetzt für den nicht-OMA-User tatsächlich von geringerer Bedeutung wäre, allerdings machen modernere Browser wie Yandex, die URL-Manipulation auch etwas uneinsichtiger). -- User: Perhelion 15:00, 5. Mär. 2017 (CET)

Ja, PC-affine Personen können sich tatsächlich via URL-Anpassung behelfen. Für mich wäre auch ein Eingabefeld OK. --Leyo 21:28, 5. Mär. 2017 (CET)

Leyo, wenn es zu klein ist wie in deinem bsp kann man immernoch auf Originaldatei klicken, eine datei sollte in nutzbarer grösse erstellt werden (extrembeispiele wirst du immer finden, wo dann aber auch 2000px nicht ausreichen). merkwürdig ist es allerdings in der tat zu 1024 × 724 Pixel | 1280 × 905 Pixel | 1052 × 744 Pixel. auch noch 1000px hinzuzufügen, das ganze dann auch noch 2 zeilen tiefer, in ander schriftgrösse, mit px statt pixel und komma statt pipe. du verschlimmbesserst es eindeutig. auserdem ist es nicht ok, dass du zurücksetzt und dann erst die diskussion aufsuchst. bevor der code entfernt wurde, war hier die diskussion. es täte dir gut genauso vorzugehen und auf der diskussion zu schreiben, dass du es anders siehts und man es wieder herstellen sollte. auf mediawiki seiten wird äusserst vorsichtig vorgegangen, wenn du es nicht kannst lass es. gruss --Wetterwolke (Diskussion) 11:34, 4. Mär. 2017 (CET)

Es geht mir darum, dass eine SVG-Datei für OMA gegenüber einer PNG-Datei bezüglich Weiternutzung keine Nachteile hat. Wie man dies ohne die Hilfe von MediaWiki macht, ist längst nicht jedem/r bekannt. Ich gehe davon aus, dass es die Bevölkerungsmehrheit betrifft. Umherirrender hat das Feature mit guten Intentionen, aber nach nur zwei Tagen Diskussion etwas vorschnell entfernt. Dass ich die Rollbackfunktion verwendete, war ein klarer Fehler. Die Diskussion aber findet beim Status quo statt. Zuerst muss der angesprochene Mangel beseitigt werden. Wenn ich mich richtig erinnere, war die Einführung von MediaWiki:Show-big-image-preview-differ auf meine Intervention zurückzuführen. Zuvor wurde nicht erwähnt, dass die Vorschauen im PNG-Format sind. --Leyo 21:28, 5. Mär. 2017 (CET)

Ich habe nichts gegen das zurücksetzen. Ich hatte im letzten Monat auch schon den Gedanken, das man es nicht mehr braucht, durch den Abschnitt hier wurde ich darin nur bekräftigt, daher habe ich keine Woche gewartet, wie bei anderen Abschnitten. Diese bisherigen Nachrichten basieren unteranderem auf dieser Diskussion auf commons (gerrit:225682). Der Umherirrende 20:01, 6. Mär. 2017 (CET)

@Leyo: „Es geht mir darum, dass eine SVG-Datei für OMA gegenüber einer PNG-Datei bezüglich Weiternutzung keine Nachteile hat.“ Unabhängig davon, dass ich angesichts deiner Haltung vermute, dass du diesen Satz anders gemeint als geschrieben hast, stimme ich dieser Aussage, so wie sie dasteht, vollkommen zu: Während zu der Zeit, als dieser Code eingefügt wurde, die Weiternutzung von SVG noch problematisch war, gibt es heute keine Nachteile mehr gegenüber PNG, zur Weiternutzung sollte man (auch „OMA“) eigentlich immer die originale SVG-Datei herunterladen und nutzen. Wie ich [21] entnehme, werden SVGs inzwischen sogar von Microsoft Office problemlos unterstützt. Damit sehe ich wirklich keinen Grund mehr, die lokal erzeugten Links zu den PNGs zu behalten. –Schnark 10:07, 8. Mär. 2017 (CET)

Ich bezog mich auf eine SVG- bzw. eine PNG-Datei bei Wikipedia.

Meine PowerPoint-Version kann SVG-Dateien nicht importieren. Ich denke, die Beurteilung darüber, ob gerenderte PNG-Grafiken für OMA noch nützlich ist, sollte von im Grafikbereich aktiven Benutzern vorgenommen werden. Davon abgesehen, tut es wirklich weh, die MediaWiki-Funktion mit einer deutlich grösseren Auflösung oder einem Eingabefeld zu ergänzen? --Leyo 10:21, 8. Mär. 2017 (CET)

Eine solche Ergänzung innerhalb von MediaWiki wäre aus meiner Sicht kein Problem. Was ein Problem ist und worum es in diesem Abschnitt geht, ist lokaler Code, der zum einen nicht gepflegt wird (und von dem anzunehmen ist, dass er über kurz oder lang deshalb nicht mehr funktionieren wird), zum anderen die Funktion nicht ergänzt, sondern (in leicht veränderter Form) dupliziert. –Schnark 10:46, 8. Mär. 2017 (CET)

Sobald die Mängel bei MediaWiki behoben sind, kann dieser lokale Code entfernt werden, aber nicht vorher. --Leyo 11:22, 8. Mär. 2017 (CET)

Dieser „Mangel“ ist ein marginales Problem: Es tritt auf, wenn ein Benutzer es irgendwie schafft auf die lokale Dateibeschreibungsseite einer SVG-Datei zu gelangen, die eine nominale Größe kleiner als 2000px hat (Datei:Meiosis Stages.svg zeigt ja, dass größere Auflösungen von MW angeboten werden, wenn die SVG-Datei diese angibt), aber bei einer Breite von 1024px nicht gut nutzbar ist, der Benutzer sie als PNG-Datei weiternutzen will und nicht weiß, dass er die URL-Parameter so ändern kann, dass er die Breite bekommt, die er will. Jeder einzelne dieser Punkte kann auftreten, aber dass alle zusammen auftreten, ist extrem unwahrscheinlich. Daher sehe ich immer noch keinen Grund, warum der Code bleiben muss, bis das in MW behoben ist (oder, wesentlich wahrscheinlicher, bis er kaputt geht und niemand ihn reparieren kann/will). –Schnark 12:11, 8. Mär. 2017 (CET)

Es mag ja sein, daß die Verwendung von SVG in Mediawiki mittlerweile problemlos ist, das kann ich nicht einschätzen. Die gerade verlinkte Datei ist mit InDesign oder Quark überhaupt nicht zu öffnen und Photoshop braucht 12 Minuten(!) zum Rendern (bei 64GB RAM). Eine RAW-Entwicklung eines Bildes dieser Größe (ca. 12.000x3.000) ist in Sekundenbruchteilen erledigt. Das ist für Nachnutzer keine Option. In der Druckvorstufe brauche ich niemandem eine SVG schicken, damit kann keiner was anfangen. --M@rcela 17:28, 13. Mär. 2017 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: hgzh 14:39, 11. Apr. 2022 (CEST)

Link Personensuche in die Werkzeugleiste

Dieser Edit

• bläht den globalen Namensraum aller JS-Variablen um drei Variablen auf, was absolut unerwünscht ist; wir versuchen im Gegenteil, immer mehr lose herumgeisternde JS-Variablen zurückzubauen und ihren Anwendungen zuzuordnen, statt jetzt noch weitere lose Gespenster in die Welt zu setzen.
  • Was andere, auch nicht sehr intelligente Skripte mit zufällig gleicher Namenswahl zerschießen kann, und umgekehrt.
• Die Aktion wird auf allen Seiten aller Namensräume aller Bearbeitungszustände ausgeführt.
  • Es funktioniert mit Sicherheit nur bei Artikeln, und ist ganz offensichtlich nur für view gedacht.
  • Damit verschwendet es Ressourcen bei allen, die die Seite aufrufen.
• Sowas gehört anständig gekapselt.
  • Derartige Basteleien machen wir schon seit zehn Jahren nicht mehr.
  • Früher hieß sowas mal „Monobook-Skriptbastler“; davon sind wir schon lange weg.
• Der ganze Kram hat überhaupt nichts mitten in der allgemeinen Common.js zu suchen, die wir seit langem versuchen schlanker zu machen, zurückzubauen und robuster und effizienter und übersichtlicher zu machen.
  • Das gehört in ein eigenständiges Gadget, das sauber zu dokumentieren wäre, und das man bei Nichtgefallen auch abwählen kann.
• In sein privatess Benutzer-JS kann man solch ein Gefrickel ja gerne reinschreiben, aber im Projekt hat sowas absolut nichts am Suchen.

VG --PerfektesChaos 18:57, 31. Mär. 2018 (CEST)

Ich weise darauf hin, dass das nur ein Entwurf für ein proof of concept von mir war. Dass das jemand direkt hier einfügt, trifft mich absolut unerwartet; und mir war auch klar, dass das vermutlich unerwünscht sein würde. --MGChecker – (📞| 📝| ) 19:24, 31. Mär. 2018 (CEST)

So, so.

Für Entwürfe gibt es BETA.

Ein korrektes Gadget lässt sich heute bereits so konfigurieren, dass es nur bei view anspringt.

• Eines schönen Tages sind die ja vielleicht auch mal so weit, dass sie nur zu gelisteten Namensraum-Nummern laden, wie es Fliegeflagel seit ewig vormacht.

Der erste Schritt ist dann die Doku; Anleitung + Musterbeispiele

Hier ist leider gerade ein Rückfall um ein Jahrzehnt zu beobachten: 175623284, 175617503, 175617694 – hektisches Rumprobieren am produktiv für alle Benutzer wirkenden Projekt-JS ist ein absolutes NoNoNoNoNoNoNoNoNoNo-Go.

• Das kann man in seinem BNR oder auf BETA erproben; hier hat es erst dann was zu suchen, wenn es robust und nach bestem Wissen und Gewissen fehlerfrei ist; ggf. nach Review durch erfahrene Programmierer.
• Wir hatten es eigentlich schon mal mühsam diesen Monobook-Rumwurstlern ausgetrieben, ihre unausgereiften ungetesteten Experimente an allen Benutzern des produktiven Projekts auszuprobieren.
• Jetzt geht die ganze Scheiße wieder von vorn los.

Die Common.js & Co. sollen mittelfristig auf Null reduziert und abgeschafft werden. Da wird nicht noch irgendein Gefrickel administrativ reingedroschen, da werden vielmehr sauber strukturierte und dokumentierte Gadgets angelegt. Wir haben schon genug mit den Altlasten zu tun und müssen da nicht noch Gemurkse aus dem letzten Jahrhundert im Jahr 2018 frisch dazumüllen.

Es gibt noch genau vier JS-Variablen im globalen Namensraum:

• mediawiki
• jquery
• ooui
• ve

Heute Abend ist das Kunststück gelungen, die Welt noch um drei neue zu bereichern, statt die elenden Altlasten weiter abzubauen.

Es ist einfach nur zum Kotzen. Ich hoffe, ein Admin hat Rückgrat und revertiert die Kacke von heute Abend. --PerfektesChaos 23:08, 31. Mär. 2018 (CEST)

Da ist nichts mehr zu probieren, das Skript wurde verbessert und ich habe es erst getestet. Es funktioniert zwar, kann aber dennoch verbessert werden. Drei Var mehr, nenne ich nicht aufblähen, und der Link war von mehreren Leuten erwünscht. Wenn das besser als Gadget zu machen geht, hab ich kein Problem damit, Verbesserungen sind immer gut. – Doc Taxon • Disk. • WikiMUC • Wikiliebe?! • 08:05, 1. Apr. 2018 (CEST)

Ein weiterer Einwand war gut, der Link erscheint nur noch im Namespace 0 bei view und edit. – Doc Taxon • Disk. • WikiMUC • Wikiliebe?! • 09:34, 1. Apr. 2018 (CEST)

„Verbesserungen sind immer gut“

• Zu verbessern gibt es hieran nichts, weil es grundsätzlich auf der falschen Seite steht.
• Die Common.js steht im Rückbau, mindestens in der Bereinigung von Altlasten aus der Bsstel-Zeit vor 2010.
• Das hier war genau genommen gleich ein Rückfall in die Welt des letzten Jahrhunderts, als auf einer Webseite ein, zwei oder drei Skripte aktiv waren, die aufeinander keine Rücksicht nahmen. Heute können auf einer Wiki-Seite Hunderte von unabhängigen Software-Einheiten parallel arbeiten, die sich nicht beeinflussen dürfen.
• Perspektivisch wird es irgendwann überhaupt keine Common.js mehr geben.
  • Ein Grund, nur in begründeten Ausnahmefällen Neues hinzuzufügen; eher was auszulagern.
  • Perspektivisch wird es im MediaWiki-Namensraum weder JavaScript noch CSS mehr geben.
  • Die Aktion hier ging mit Vollgas und im Blindflug nach hinten.

„als Gadget oder in den eigenen JS-Abschnitt“ (hgzh)

• Völlig korrekt.
• Maximal als Gadget (im MW-Sinn).
• Ob das überhaupt ein vom Projekt angebotenes und gepflegtes Gadget sein muss, wäre erstmal herauszufinden. Oder ob es nur eine winzige Zahl von Verwendern gäbe, die sich dafür interessieren.
• Wer das nicht haben möchte, muss die Möglichkeit des Opt-Out haben. In der Verktor-Skin ist die fragliche Leiste ausklappbar, in MonoBook statisch und enthält immer alle Elemente.
• Wobei sich eher Opt-in anbieten würde.
• Der Code hier wird zwangsweise bei jedem Seitenbesuch ausgeführt, und er unterliegt strengen Kriterien hinsichtlich Notwendigkeit, Effizienz und Robustheit. Die Gesamt-Seite muss außerdem möglichst kurz und übersichtlich sein.

Gadget:

• Siehe oben: Anleitung + Doku-Musterbeispiele
• Zwei Dutzend Gadget-geeignete Programmierungsbeispeiele.
• Der Code für ein Gadget (im MW-Sinn) wird überhaupt erst dann zum Benutzer durch das Netzwerk transportiert und ausgeführt, wenn die Bedingungen (hier zunächst action) für die fragliche Seite und ggf. diesen Benutzer erfüllt sind. Damit wird die Aufbauzeit jeder Seite nicht unnötig belastet.

Ablauf:

• Wie bei jeder zentralen Meta-Seite werden wesentliche Veränderungen zuallererst auf der Diskussionsseite vorgeschlagen.
• Das gilt hier genauso; abgesehen von absoluten Notfällen wegen Systemzusammenbruch etc.
• Weiterhin haben wir das BETA, in dem die vorgesehene Neuerung zur Produktionsreife entwickelt, erprobt und abschließend vorgeschlagen werden kann.
• Erst nachdem ggf. Kritikpunkte beseitigt wurden und Konsens (im WP-Sinn) besteht, wird in einem Edit die endgültige Version hierher produktiv kopiert.

VG --PerfektesChaos 12:12, 2. Apr. 2018 (CEST)

Ich möchte das bitte auch nicht haben, zum einen sorgt es für Unruhe in der Werkzeugleiste und ist zum anderen auch redundant zur Ausgabe der Normdaten-Vorlage am Artikelende. Wer das unbedingt haben will, kann es sich als Gadget oder in den eigenen JS-Abschnitt installieren, aber bitte nicht zwangsbeglückt für alle. -- hgzh 16:55, 1. Apr. 2018 (CEST)

Ich hab ein wenig bei Wikipedia_Diskussion:Normdaten#Wikipedia-Personensuche_Teil_2 geschrieben. Ich will das Thema nicht hier aufdröseln, es passt hier nicht und eine Wanderdiskussion ist nicht gar so gut nachvollziehbar. --Wurgl (Diskussion) 13:28, 2. Apr. 2018 (CEST)

Der Gedanke war ja, den Link in der Normdatenvorlage mittelfristig eventuell dadurch zu substituieren. Aber es geht hier viel mehr ums Prinzip, dass man nicht einfach yolo-mäßig irgendwas in die Common.js klatscht, weil es einem gerade passt und irgendwie funktioniert (oder nicht mal das). Wie das hier lief, ist schockierend; über das projektweite JS wird nicht eben mal auf einer Vorlagendiskussionsseite entschieden. --MGChecker – (📞| 📝| ) 19:26, 2. Apr. 2018 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: hgzh 14:39, 11. Apr. 2022 (CEST)