MediaWiki Diskussion:Common.js

Automatische Archivierung

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

Vorlage:Autoarchiv-Erledigt/Wartung/Festes_Ziel

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)

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)

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)

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)

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: Vorlage:Unicode

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.[1] 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.[2]

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)

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)

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)

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)

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

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)

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)

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 [3], 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)