MediaWiki Diskussion:Common.js

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

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)

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)

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

Aus 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)

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)

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)

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)

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)

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)

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

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: '&nbsp;' + 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)

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)

Ü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 [1] 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)

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)

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)

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)