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

Interwiki-Links kommentieren

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

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

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

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)

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)

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)

IE60Fixes.js

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)

ts_parseFloat() wieder an formatnum anpassen

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

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

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

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

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

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

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

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

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

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

Javascript-Fehler mit Vector-Skin

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

Error: talk is null

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

Line: 417

Die betreffenden Zeilen lauten:

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

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

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

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

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

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

Danke. Sehr kompakter Code :)

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

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

Weitere Suchmaschinen

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

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

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

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

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)

MediaWiki:Common.js/watchlist.js

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

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

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

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

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

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

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

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

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

Ja, bitte wieder herstellen, damit

#watchlistfor {display:none}

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

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

Links zu gerenderten PNG-Grafiken von SVGs: Optimierte Funktion

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

Hallo Leyo, änder mal bitte die Zeile

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

in

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

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

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

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

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

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

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

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

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

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

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

Navileisten-Abschnitt

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

Alles von

var indexNavigationBar = 0;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

appendCSS('.noscript {display:none;}');

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

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

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

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

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

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

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

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

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)

wgMainPageTitle

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

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

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

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

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

/secure.js

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