MediaWiki Diskussion:Gadgets-definition

Hier kannst du Helferlein für die Helferlein-Erweiterung vorschlagen. Aktuell vorhandene Helferlein sind mit den von ihnen verwendeten Dateien auf Spezial:Gadgets gelistet.

Für Anregungen hierzu siehe:

• Wikipedia:Technik/Skin
  • Wikipedia:Technik/Skin/Benutzerskripte
• Wikipedia:Helferlein
• fr:Discussion MediaWiki:Gadgets-definition (Französisch)
• en:Wikipedia:Gadgets (Englisch)

Neues Helferlein vorschlagen

Auf dieser Seite werden Abschnitte automatisch archiviert, die seit 7 Tagen mit dem Baustein {{Erledigt|1=~~~~}} versehen sind.

Archiv

2011 2010 2009 2008 2007

Wie wird ein Archiv angelegt?

Weitere Gadgets

Hallo, gibt es eine Seite zur koordinierten Gadget-Entwicklung? Ich habe mit ISBNLinks erstes Skript gebaut, dass mal ein Gadget werden soll, wenn es mal stabiler ist und würde mich über Feedback und Tipps freuen. -- Nichtich 23:25, 14. Jan. 2008 (CET)

Nein nicht direkt, aber ich denke dass Wikipedia:Skin (evtl. unter neuem Namen) sich dafür anböte. Die bisherige Wikipedia:Skin-Seite wird eh Schritt für Schritt durch die Gadgets in der derzeitigen Form obsolet. Wenn der blöde JS-Caching-Bug gelöst ist werd ich mir mal dein Script anschauen. Es sieht auf alle Fälle schonmal sehr interessant aus. :-) Arnomane 01:55, 18. Jan. 2008 (CET)

Vorschlag für MediaWiki:Gadget-Pfeil-hoch.js

Wenn bei diesem JavaScript dieser Quelltext

function PageHomeArrows()
{
        var contentElement = document.getElementById("bodyContent")
        for (var level = 2; level <= 6; ++level) {
                var h = contentElement.getElementsByTagName("h" + level);
                for (var i = 0; i < h.length; ++i) {
                        var arrow = document.createElement("a");
                        arrow.className = "noprint";
                        arrow.appendChild(document.createTextNode(" ↑"));
                        arrow.href = "#globalWrapper";
                        h[i].appendChild(arrow);
                }
        }
}
addOnloadHook(PageHomeArrows);

verwendet wird, dann wird bei Werkzeugleiste am rechten Rand keine Pfeile mehr angezeigt, da nur auf die Überschriften im bodyContent zurückgegriffen wird. Das ist der "Haupt"-Bereich. Auch wird beim Klick kein JavaScript mehr ausgeführt, sondern nur noch zum setzen benötigt. Zusätzlich wird die Seite kleiner, da Tabs anstatt leerzeichen am Anfang verwendet werden. Ist eine Anregung, da ich die Pfeile dort für überflüssig halte. Mich stört es nicht mehr, da ich mir das persönlich etwas modifiziert habe. Der Umherirrende 18:54, 12. Dez. 2008 (CET)

Gadget: Fundraiser Banner Deactivation

Warum gibt es eigentlich keine Option zum Deaktivieren des Spenden-Banners in den Benutzereinstellungen wie in :en (Settings -> Gadgets -> Suppress display of the fundraiser banner)?! Gerade auf Breitbildschirmen nimmt das Banner (wenn man die Browser-eigenen Werkzeugleisten berücksichtigt) sehr viel Platz weg und fördert nach einer gewissen Zeit nicht gerade die Spendenbereitschaft aufgrund seiner Penetranz... im Zweifel ist "Ärzte ohne Grenzen" die bessere Wahl. RIMOLA 15:14, 26. Dez. 2008 (CET)

Der Spendenaufruf läuft nur über eine bestimmte Zeit, danach braucht erstmal keiner mehr das Gadget. Außerdem kann jeder, der es will sich den Banner per CSS-Eintrag in /monobook.css ausblenden lassen. --Euku:^⇄ 15:35, 26. Dez. 2008 (CET)

Wenn der Spendenaufruf weg ist, kann man ja auch das Gadget wieder entfernen, nichts einfacher als das. Und die Gadgets gibt es eigentlich genau deshalb, weil sich manche Leute mit der Bearbeitung von CSS schwer tun. --Elian Φ 15:50, 26. Dez. 2008 (CET)

Ich bin kein Informatik-Student und will nicht erst einen Lehrgang machen, um ein nervendes Banner zu entfernen... in :en geht es doch auch problemlos über die Benutzereinstellungen. Außerdem: weniger ist mehr - irgendwann verkehrt sich die Wirkung des Banners und es wird gar nicht mehr beachtet oder mit Ignoranz bestraft. RIMOLA 16:03, 26. Dez. 2008 (CET)

Ok, bevor ich erschlagen werde, installiert das Ding :) --Euku:^⇄ 11:51, 28. Dez. 2008 (CET)

neues Gadget: automatisches Übersetzen der Bilder-Syntax

In den letzten Tagen wurden einige Keywords der Datei-Einbind-Syntax geändert. So wurde aus Bild → Datei, thumb → miniatur usw…

Ich habe ein kleines Gadget geschrieben, dass diese Keywords nun automatisch übersetzt, wenn man einen Seitentext bearbeitet. Es werden nur dann Änderungen vorgenommen, wenn sie auch wirklich sicher sind, und auch nur im Artikel- und Vorlagennamensraum. Ich glaube im Sinner der Vereinheitlichung und Vereinfachung könnte das Gadget auch noch für andere nützlich sein.

Getestet habe ich es mit Opera 9.63 und Firefox 3.0.4. Meinungen, Kommentare? --Revolus Apfel? 08:12, 27. Dez. 2008 (CET)

Sieht gut aus, einige Bemerkungen dazu:

• Evtl. sollte auch wgAction == 'submit' geprüft werden, damit es auch in der Vorschau funktioniert

  Das habe ich rausgelassen, weil man sonst die automatischen Änderungen nicht rückgängig machen kann … wofür auch immer, man weiß ja nie :-)

• Wenn ich es richtig sehe, werden bei dir alle vier Fälle (Image,Bild,Datei,File) auf "Datei" geändert. Sollte nicht besser (Image,Bild) auf "Bild" und (File,Datei) auf "Datei" abgebildet werden?
• String.replace mit callback-Funktion als zweitem Argument funktioniert nicht mit IE5.x und älteren Safari-Versionen.

  Ach, wer hat denn heute noch IE<8? ;-) Nee, im Ernst, ich finde es müßig alle Leute, die veraltete Software benutzen, glücklich machen zu wollen.

• Was ist der Parameter page=? Auf Hilfe:Bilder habe ich nichts darüber gefunden.

  Weiß ich ehrlich gesagt auch nicht. Aber es gibt das magische Wort :-\ [1]

• Wenn ich mich nicht täusche, wird auch innerhalb von <nowiki>-Bereichen und Kommentaren ersetzt. Das könnte manchmal zu Überraschungen führen.

  Ja, wird es. Aber auch wenn, sehe ich darin nichts Schlechtes. Wenn in der Bildsyntex irgendwo eine spitze Klammer vorkommt, wird dort jedenfalls keine Änderung vorgenommen.

• Statt einer automatischen Ersetzung wäre vielleicht ein Editbutton über dem Bearbeitungsfenster praktisch, wenn man nur fallweise ersetzen möchte.

  Weiß nicht, fänd ich umständlich.

Grüße --P.Copp 10:50, 27. Dez. 2008 (CET)

• Ich habe meine Antworten mal zwischen die Zeilen geschrieben. Gruß, --Revolus Apfel? 15:23, 27. Dez. 2008 (CET)

Ich halte einheitlich „Datei:“ für alle Verwendungen für richtiger/logischer, da „Bild:“ nur noch ein Alias ist. Der Parameter page= wird im Moment ausschließlich von DjVu-Dateien verwendet. Diese werden bisher meines Wissens ausschließlich auf Wikisource verwendet. Bald werden auch PDF-Dateien mit dem Parameter genutzt werden können (Brion hat die Inbetriebnahme der PDFHandler-Extension in Kürze [tm] in Aussicht gestellt). — Raymond ^{Disk. Bew.} 11:32, 27. Dez. 2008 (CET)

Aha, danke für die Info. Wieder was gelernt :) --P.Copp 11:56, 27. Dez. 2008 (CET)

verschoben für die Übersichtlichkeit --Revolus Apfel? 19:51, 27. Dez. 2008 (CET)

„ich finde es müßig alle Leute, die veraltete Software benutzen, glücklich machen zu wollen.“ - Ich würde dir rechtgeben, wenn es sich um ein normales Benutzerskript handelt. Wenn es allerdings als Gadget aktiviert werden soll, muss man damit rechnen, dass auch Benutzer mit älteren Browsern es verwenden. Bei denen würde dann der Bildtext durch den Programmcode der Funktion ersetzt. IMHO sollte zumindest ein Check eingebaut werden, damit das nicht passiert.

Ein weiterer Punkt ist mir noch aufgefallen: Wenn Wikilinks in der Bildbeschreibung vorkommen wird nicht ersetzt. Zumindest im Artikelnamensraum dürfte das ziemlich häufig der Fall sein. --P.Copp 15:58, 27. Dez. 2008 (CET)

Arg, da wird wirklich der Funktionstext ausgegeben? Okay, ich habe einen Test eingebaut. Das ist sonst wirklich nicht akzeptabel.

Das mit den Klammern ist ein ganz schwieriges Ding. Das Pumping Lemma für reguläre Ausdrücke zeigt, dass der Klammerungstest nicht regulär ist. Dafür bräuchte man eine kontextfreie Grammatik, die Javascript aber nicht bereitstellt. Und einen Kellerautomaten (Stack) hierfür zu bauen, halte ich für so eine kleine Ersetzung für übertrieben. --Revolus Apfel? 16:38, 27. Dez. 2008 (CET)

Naja genaugenommen ist dieser Spezialfall tatsächlich noch durch einen regulären Ausdruck erkennbar, da nur eine Verschachtelungstiefe von 1 erlaubt ist, aber ich gebe zu, dass es das ganze wesentlich komplizierter macht. Ich wollte auch nur darauf hinweisen, dass das Gadget in dieser Form nicht in allen Artikeln eine Vereinheitlichung bringen würde. Gruß und Dank für das Einbauen des Checks --P.Copp 16:49, 27. Dez. 2008 (CET)

Stimmt, es kann ja kein Link in einem Link vorkommen. Ich probier mal noch ein bisschen rum. --Revolus Apfel? 17:28, 27. Dez. 2008 (CET)

So, bei mir funktioniert es jetzt auch mit Links im Bildbeschreibungstext. Bitte mal testen. --Revolus Apfel? 19:51, 27. Dez. 2008 (CET)

Super, danke für die Mühe, jetzt funktioniert das Skript mit den meisten Artikel tadellos (außer bei HTML-Tags in der Bildbeschreibung wie z.B. bei Todesstrafe, aber das ist zu verschmerzen, weil recht selten). Ein kleiner Fehler hat sich eingeschlichen: In Zeile 37 muss noch s durch str ersetzt werden. Noch eine Kleingkeit: Die Präfixe Datei:, Bild usw. können theoretisch in jeder beliebigen Groß-/Kleinschreibung vorkommen, vielleicht möchtest du das noch abfangen. Gruß --P.Copp 23:53, 27. Dez. 2008 (CET)

So, jetzt müsste auch HTML drin sein. Gruß, --Revolus Apfel? 08:25, 28. Dez. 2008 (CET)

Yo, der obige Artikel klappt jetzt auch :) Nochmal danke und Gruß --P.Copp 23:27, 28. Dez. 2008 (CET)

Gute Idee mit dem Skript, allerdings gibt es auch schon Benutzer:BLueFiSH.as/JS/markup.js, was auch einige Normierungen vornimmt, wie z. B. [[Datei:Bla|thumb|right]] → [[Datei:Bla|thumb]]. Vielleicht wäre es besser ein Skript zu haben, das sämtliche Kosmetik im Quelltext durchführt. Von der langen BLueFiSH-Liste der Ersetzungen sind allerdings nicht alle sicher. --Euku:^⇄ 10:34, 29. Dez. 2008 (CET) // Schade um die englischen Bezeichnungen...

Eine weitere Idee: Normalisierung/Standardisierung der Dateilinks: also Unterstriche durch Leerzeichen ersetzen, ersten Buchstaben groß, urldecode, doppelte Leerzeichen, Leerzeichen um den Doppelpunkt herum, sortierung der Parameter. Falls das machbar wäre, halte ich das für eine sinnvolle Ergänzung. Die Übersetzung ist auch eine sinnvolle Sache, auch wenn am Anfang einige Leute sicherlich verwirrt sein werden, ich werde das im nächsten Jahr mal ausprobieren. Der Umherirrende 12:15, 29. Dez. 2008 (CET)

right wird jetzt gelöscht. Bildnamen normalisieren wäre auch noch toll, aber da muss ich noch nachdenken, wie. Kennt einer eine vorgegebene Funktion dafür? Die Parameter zu sortieren wäre möglich. Sag mir mal eine Reihenfolge. --Revolus Apfel? 18:13, 29. Dez. 2008 (CET)

Ich habe jetzt nicht geguckt, aber rechts sollte ja nur gelöscht werden, wenn das Bild ein thumb ist, da nur bei thumb ein Standard von rechts vorhanden ist. Sortierreihenfolge wäre sehr subjektiv. Ich würde thumb und dann float, danach könnte man die Größenangabe und Beschreibung natürlich ans Ende. Den Rest dann irgendwie dazwischen. Keine Ahnung. Der Umherirrende 20:19, 29. Dez. 2008 (CET)

Bei Reihenfolge von thumb und right würde ich mich das Skript halten, was schon Tausende von Änderungen mit sich brachte, sonst könnte das ein ungewolltes Hin und Her zwischen verschiedenen Skripten und Benutzern. Dort heißt es: "tv = tv.replace(/\|left\|thumb\|/g, "|thumb|left|"); // einfach nur Reihenfolge: wie-wo". Gruß --Euku:^⇄ 21:39, 29. Dez. 2008 (CET)

right wird jetzt nur noch bei thumbs gelöscht (hatte ich falsch gedacht :-\). Die Parameter werden jetzt automatisch in dieser Reihenfolge sortiert: miniatur, gerahmt, rahmenlos, vertikale Ausrichtung, horizontale Ausrichtung, hochkant, Größe in px, alternativtext, verweis und dahinter alles andere. Das Normalisieren des Bildnamens fehlt aber noch. Gruß, --Revolus Apfel? 21:18, 30. Dez. 2008 (CET)

Bin mir nicht ganz sicher, ob es an meinen Skripten oder an deinem liegt, aber kann es sein, dass in Simatic aus [[Datei:S7300.JPG|miniatur|Siemens Simatic S7-300]] plötzlich [[Datei:S7300.JPG|miniatur|Siemens Simatic S7-300|]] wird?

Bei mir auch: Fehler, zusätzlich ist teil der Beschreibung verschwunden. Meine weiteren Bearbeitung können nicht als referenz genutzt werden, da ich, falls nötig, nachgearbeitet habe --Der Umherirrende 14:38, 2. Jan. 2009 (CET)

Autsch. Okay, das mit dem Sortieren klappt dann wohl nicht. --Revolus Apfel? 15:16, 2. Jan. 2009 (CET)

Könnte man das ganze nicht in eine eigene Methode packen und diese bei Bedarf aufrufen?

if (wgNamespaceNumber == 0 && wgAction == "edit")
{
 addOnloadHook(dateisyntaxupdate);
}
 
function dateisyntaxupdate()
{
 /* was auch immer */
}

Dadurch wäre es möglich, die Methode auch von anderer Stelle auszuführen beispielsweise über die Adresszeile. Danke. Der Umherirrende 15:20, 2. Jan. 2009 (CET)

Na klar, habe die Funktion rev_syntax() getauft. --Revolus Apfel? 15:42, 2. Jan. 2009 (CET)

Das sieht gut aus, bis auf das du nicht die Methode rev_syntax aufrufst, sondern nur syntax, welche natürlich nicht vorhanden ist … --Der Umherirrende 16:11, 2. Jan. 2009 (CET)

Hubs, behoben. Gruß, --Revolus Apfel? 16:22, 2. Jan. 2009 (CET)

Bei diesem Edit habe ich das "rechts" selber entfernt, obwohl es doch nebeneinander steht im gegensatz zu diesem Edit, wo ich es auch manuell entfernt habe. Beim zweiten wurde es vielleicht nicht erkannt, da "miniatur" und "rechts" nicht beieinander steht, beim ersten habe ich keinen Schimmer. Der Umherirrende 16:54, 2. Jan. 2009 (CET)

Bei diesem Edit stehen sie anderes herum, auch dort habe ich manuell entfernt. Ich hoffe du kannst mit den Beispielen etwas anfangen. In den Vorversionen kann ich es auch immer reproduzieren. --Der Umherirrende 17:06, 2. Jan. 2009 (CET)

Right wird jetzt nicht mehr automatisch entfernt, da muss ich mir noch was ausdenken. --Revolus Apfel? 17:33, 2. Jan. 2009 (CET)

IE-Unicode-Problemsumgehungs-Gadget

Der Internetexplorer bis mindestens 6 kann bestimmte lateinische Unicodecodierte Zeichen - darunter auch einen Buchstaben des Rumänischen - nicht darstellen; es gibt aber bei den Zeichen jeweils Ersatzzeichen bzw. html-Formatierungen (Unterstrich/Durchstrich) - beides jedoch typografisch falsch - oder alternativ spracheneigene Ersatzzeichen mit dem man den Darstellungsfehler abfangen kann. (siehe Wikipedia_Diskussion:Namenskonventionen#Rumänische Sonderzeichen und Wikipedia Diskussion:Namenskonventionen/Archiv/2008-I#Umgang mit den rumänischen Sonderzeichen U+0218, U+0219, U+021A und U+021B). Sollte man das Schweizergadget nicht recht einfach anpassen können, damit es drumrumleitet? sугсго 14:13, 29. Jan. 2009 (CET)

Wie wärs mit einem Gadget, was den Zugang zur WP mit dem IE verbietet? ;-) ... Ne im Ernst: Dem Leser (!=eingeloggt und Gadget aktiviert) nützt das doch nichts. Hier müssen doch bestimmte Zeichen ersetzt werden, wenn der Browser <= IE6.0 ist, das ist eher was für alle: MediaWiki:Common.js. Besser wäre es aber, nur die IE-Nutzer mit diesem zusätzlichen Skript zu beladen. Im Quelltext dieser Seite finde ich auch:

 <!--[if IE 6]><link rel="stylesheet" href="/skins-1.5/monobook/IE60Fixes.css?203xx" type="text/css" media="screen" /><![endif]-->

Das müsste einfach für JavaScript erweitert werden. Dazu muss man allerdings einen Entwickler ansprechen. --Euku:^⇄ 15:11, 29. Jan. 2009 (CET)

Proposal for Translation Popups Gadget

Sorry about the English. I propose my code at

Benutzer:Endo999/monobook.js

as a gadget on de.wikipedia.org. It does translation popups of words and selected text you hover the cursor over. It is like the Google toolbar translation feature only it uses Google translation services to translate between 40 languages so far. Works on most browsers except Konqueror. On most browsers you can select up to 500 characters of text, hover the cursor within the selected text and get the translated result, as well as hover the cursor over a word to get the translation of that word.

An earlier version of this gadget has been running as a gadget in the Spanish Wikipedia for six months now without complaint.

Recent changes have been made so that the translation popup window does not conflict with navpopups or with link title popups.

The text literals are in English, but they can be customized (and therefore the language changed) in the monobook.js file.

Endo999 05:53, 22. Mai 2009 (CEST) Hi there,

Sorry about the English.

The GoogleTrans gadget, proposed above, has been on the enwiki for around a year now. It is also on 7 other wikipedias including the Serbian and the Macedonian.

It functions like the Google toolbar translation feature. When you position the cursor over a word in a webpage and hit the SHIFT key, the Google translation of that word (or of selected text < 500 characters) appears in a popup below the cursor.

The help page for the gadget is at:

http://en.wikipedia.org/wiki/User:Endo999/GoogleTrans

(This has instructions on how to port over to other wikis).

and the code for it is at:

http://en.wikipedia.org/wiki/User:Endo999/GoogleTrans.js

It really works well for people who have intermediate German as they can easily look up a word they don't know (every 2 or 3 sentences). This is how I use the tool to read French and Spanish webpages. However, the person who knows no German (like me) can simply select a sentence or two and have it translated as well. In each popup there is a link to Google Translation Services. If you click on this link then the whole page is translated.

The translate language is set as a default per wiki, but if you have a language preference in your profile (and this language preference is supported by Google) then this language is your translate to language for the purposes of the gadget.

Good luck with your dewiki. I believe you are over 1,000,000 articles now!.

Endo999 08:56, 3. Sep. 2010 (CEST)

Neuer Netbook-Skin

So schauts auf 800x600 aus (+ Grünes Modern-Thema + Kleinigkeiten) ...- .-. ... / -.. .. ... -.- 15:45, 29. Jun. 2009 (CEST)

Zwar kein Gadgets, aber fast so nützlich: Ich habe von Benutzer:V.R.S. einen schönen Netbook-taublichen Skin erhalten. (Baut auf modern.css auf, Integration siehe Benutzer:Tischbeinahe/modern.css). Der Skin zeichnet sich dadurch aus, daß er die Seitenleiste komplett nach unten schiebt und so die Textdarstellung auf der ganzen Bildschirmseite ermöglicht. Bei der rasanten Zunahme von Netbooks, werden sicherlich auch andere Benutzer Interesse daran haben, weshalb ich vorschlage, ihn in die Skinauswahl zu integrieren. Der Skin stellt nämlich nicht bloß eine optische Verbesserung dar, sondern ermöglicht vor allem eine bessere Benutzbarkeit der Wikipedia und erhöht nochmals die Zugriffsmöglichkeiten (Netbooks sind vor allem auch bei Schülern wegen ihres geringen Preises beliebt). --Tischbein-ahe 22:13, 18. Jun. 2009 (CEST)

Na ja, ich sehe da keinen großen Vorteil gegenüber den Skins chick und nostalgia. (Okay, die Farben sind schon schicker ;-) --Revolus Echo der Stille 15:56, 29. Jun. 2009 (CEST)

Zudem werden chick und nostalgia nicht mehr gewartet. ...- .-. ... / -.. .. ... -.- 17:17, 29. Jun. 2009 (CEST)

QuickEdit

Hallo zusammen,

was haltet ihr davon QuickEdit als Gadget mit aufzunehmen? Das Script ist mitlerweile seit 3 Jahren in Benutzung, in der it-wiki ist es als Gadget verfügbar. Mit QuickEdit können Absätze per Ajax direkt in der Artikelansicht bearbeitet werden, mit Vorschau, Änderungsanzeige, Suchfunktion. Ich würde mich freuen, wenn ihr es euch einmal anschaut.

Getestet mit Firefox und Chrome, läuft noch nicht auf IE (es ist fürchterlich was dieser Browser macht!), ich hätte es aber im Falle einer Gadget-Implementation gerne IE-kompatibel. Sonderzeichen müssen gefixt werden (die Sonderzeichenleiste wurde wieder einmal auf den Wikis geändert) und Suchfunktion verbessert, das würde ich noch machen. Es ist mehrsprachig angelegt (basierend auf der Spracheinstellung) mit Übersetzungen für de, en, ca, pl, it, hr und besteht aus 3 Teilskripten sowie einer CSS-Datei. Nur für den Monobook-Skin. Ist Teil der PDD-monobook.js.

Vorschau: Bild:QuickEdit.png

Benutzen: importScript('Benutzer:ASM/quickedit.js');

Vielen Dank, gruß ×ASM× 22:12, 29. Jul. 2009 (CEST)

Hallo ASM, die Aufnahme deines Skripts in die Gadget-Liste würde ich begrüßen. Ich habe es vor vielen Monaten mal getestet sowie jetzt nochmal im Firefox 3.5 und halte es für eine nützliche Erweiterung. Die Einbindung erfolgt übrigens so:

importScript('Benutzer:ASM/quickedit.js');

Vielleicht könntest du noch „Live Vorschau“ mit einem Bindestrich zusammensetzen? Viele Grüße --Wiegels „…“ 12:58, 3. Aug. 2009 (CEST)

Hallo Wiegels, das mache ich doch gleich mal! Ansonsten freue ich mich über weitere Antworten (gern auch Kritik, Verbesserungsvorschläge, etc.). ×ASM× 15:29, 4. Aug. 2009 (CEST)

Script zum Setzen der DÜP-Vorlage

Auf allen Dateibeschreibungsseiten wird im normalen Lesemodus durch diese Funktion ein zusätzlicher Tab mit dem Namen „DÜP“ hinzugefügt. Klickt man auf diesen Tab, so wird ein kleines Fenster geöffnet, in dem man auswählen kann, welche Mängel vorliegen. Dann bestätigt man dies mit „Ok“ und es erfolgt daraufhin das automatische Setzen der Vorlage:Dateiüberprüfung mit den entsprechenden Parametern. -- Suhªdi 16:55, 22. Jan. 2010 (CET)

Feinere Unterteilung

IMHO würde eine feinere Unterteilung die Übersicht über die Helferlein verbessern. Die Unterteilung in Commons:Special:Preferences (deutsche Version) oder Wikipedia:Helferlein finde ich beispielsweise ganz gut. --Leyo 19:52, 26. Jan. 2010 (CET)

Gibt es irgendwelche Einwände? --Leyo 20:25, 29. Jan. 2010 (CET)

Nö. --APPER\^☺☹ 19:29, 30. Jan. 2010 (CET)

Ich habe mal meinen Vorschlag umgesetzt, aber es wird noch nicht richtig angezeigt. Muss sonstwo noch etwas geändert werden? --Leyo 18:16, 1. Feb. 2010 (CET)

So geht es nun, aber das wusste ich auch nicht. --Euku:^⇄ 19:06, 1. Feb. 2010 (CET)

Danke! Wenn jemand bei der Einteilung noch Verbesserungspotential sieht, nur zu… --Leyo 19:11, 1. Feb. 2010 (CET)

Benutzer:Ireas/Gadget-Commonsverschiebung.js

Dieses Skript bietet ein Interface für die Commons-Verschiebung per Bot (Wikipedia:Redaktion Bilder/Commons-Transfer per Bot). Könnte man das als „echtes“ Gadget hinzufügen? --ireas Diskussion // Bewertung 10:05, 26. Mai 2010 (CEST)

Jetzt hier: Wikipedia:Commons-Transfer per Bot Grüße --Brackenheim 15:21, 28. Mai 2010 (CEST)

DropdownToTabbar

Ich schlage einfach mal ein neues Helferlein vor, das ich in meiner vector.js habe und mir sehr nützlich erscheint. Es verfrachtet beim Vektor-Skin die Einträge des Dropdown-Menüs links vom Suchfeld in die Leiste und sie sind somit immer sichtbar. Siehe commons:MediaWiki:Gadget-DropdownToTabbar.js --тнояsтеn ⇔ 10:49, 10. Jun. 2010 (CEST)

Benutzerspezifische Koordinatenanzeige

Vor allem im Zuge der "Globalisierung" der Benutzerkonten wäre es wünschenswert, wenn es ein Helferlein gäbe, mit dem man die jeweils üblichen Koordinatenausgaben (Grad/Minute/Sekunde, Dezimalgrad, Grad/Dezimalminute etc.) angezeigt bekäme. -- Platte ^{∪∩∨∃∪} 17:42, 22. Jun. 2010 (CEST)

http://tools.freeside.sk/geolocator/geolocator.html ist nicht was du suchst? --Leyo 18:20, 22. Jun. 2010 (CEST)

Ne, ich meinte eher etwas, womit man die Koordinatenanzeige im jeweiligen Artikel anpassen kann. -- Platte ^{∪∩∨∃∪} 18:42, 22. Jun. 2010 (CEST)

Eigene Signatur hervorheben

Vorschlag unter WD:Meinungsbilder/Gestaltung von Signaturen#Gadget: Links auf die eigene Benutzerseite hervorheben (z.B. in der Signatur). --Leyo 10:29, 9. Jul. 2010 (CEST)

Keine Meinungen dazu? --Leyo 11:10, 28. Jan. 2011 (CET)

Hört sich für mich sinnvoll an - allerdings brauche ich es (weder als Gadget noch manuell) nicht. Viele Grüße --Saibo (Δ) 15:33, 28. Jan. 2011 (CET)

1.  Pro Ja warum nicht. -- Perhelion 17:38, 28. Jan. 2011 (CET)

Noch eine Frage zur Umsetzung: Wie muss man in

a[href$="Benutzer:Dein_Benutzername"] { background:#ffaaaa; font-weight:bold; color: #000000; }

„Dein_Benutzername“ ersetzen? --Leyo 11:23, 1. Apr. 2011 (CEST)

Weiterleitungs-Check

Ich würde mich über einen Weiterleitungs-Check (in Analogie zum Begriffsklärungs-Check) freuen! -- Henrik 12:48, 16. Jul. 2010 (CEST)

Meinst Du nur ein farbliches hervorheben von Weiterleitungen oder so etwas wie bei Benutzer:✓/monobook/weiterleitungen.js? --Fomafix 12:59, 16. Jul. 2010 (CEST)

Was meint denn ✓? Mir würde ein farbliches Hervorheben beim Lesen und in der Vorschau wie beim Begriffsklärungs-Check genügen. -- Henrik 13:08, 16. Jul. 2010 (CEST)

Das Skript von Benutzer:✓ zeigt das Weiterleitungsziel an (das Navigations-Popus-Gadget u.a. auch). Eine einfache farbliche Hervorhebung der Redirects geht in deiner vector.css (oder whatever) einfach:

a.mw-redirect { color: #009966; background-color: #0000FF; !important; }

(die Farbkombi ist wohl zu much, das wäre grüne Schrift auf blauem Hintergrund; ich selbst nutze nur die grüne Schrift). --YMS 13:18, 16. Jul. 2010 (CEST)

Aber bitte nicht alle Links auf Weiterleitungen ersetzen. Das ist bei BKS sinnvoll, bei Weiterleitungen nicht. --Leyo 13:33, 16. Jul. 2010 (CEST)

Genau und deshalb halte ich ein allgemeines Gadget nur zum farblichen Hervorheben von Weiterleitungen nicht sinnvoll. Wer das haben will, kann es sich per CSS in der gewünschten Farbe einstellen. Auf eine einheitliche Farbe könnten wir uns wahrscheinlich sowieso nicht einigen.

Eine optionale Anzeigemöglichkeit des Weiterleitungsziels hingegen halte ich für eine generell sinnvolle Funktionalität. Am besten sollte so etwas nicht per JavaScript nachträglich abgefragt werden, sondern von MediaWiki zusammen mit class="mw-redirect" im HTML ausgeliefert werden. --Fomafix 14:17, 16. Jul. 2010 (CEST)

Funktioniert wirklich super! Vielen Dank! -- Henrik 16:52, 16. Jul. 2010 (CEST)

Entfernen religiöser Symbole

Da Kreuze manche Leute fast so fuchsig machen wie das ß unsere Schweizer Kollegen, könnte man ja vielleicht unter Lesehilfen dieses nützliche Tool einbinden: Benutzer:PDD/Gadget-Religiöse-Korrektheit.js. — ^PDD — 13:28, 1. Sep. 2010 (CEST)

Nur mal so aus Interesse (was ja eigentlich in der Einleitung vom Skript oder in einer Doku dazu stehen sollte), durch was werden die (Toten)Kreuze (†) mit dem Skript ersetzt?

--Konrad – 09:44, 3. Sep. 2010 (CEST)

Durch »gest.«. Grüße, --ireas :disk: :bew: 10:02, 3. Sep. 2010 (CEST)

alle ausgewählten Gadgets temporär deaktivieren

Hallo, eigentlich ist dies kein Vorschlag für ein neues Gadget, oder doch? Gibt es eine Möglichkeit alle Gadgets zu deaktivieren und später mit einem Klick die vorher aktiven gadgets wieder zu aktivieren? --Diwas 00:54, 12. Sep. 2010 (CEST)

Hier lesen nur wenige mit. Vielleicht fragst du besser unter WP:FZW. Die Antwort kannst du ja dann hier posten. --Leyo 00:26, 23. Sep. 2010 (CEST)

Eine Möglichkeit für einen „abgesicherten Modus“ ist mir derzeit nicht bekannt. Ein Export/Import der Einstellungen wie bei der Beobachtungsliste ist vermutlich unerwünscht. Ein zusätzlicher URL-Parameter, der alle Gadgets temporär für den nächsten Klick deaktiviert, könnte ich mir aber vorstellen. Sicherheitsmäßig wird ein solcher Parameter unbedenklich sein. --Fomafix 13:50, 23. Sep. 2010 (CEST)

Jedenfalls danke für die Antworten.--Diwas 00:12, 24. Sep. 2010 (CEST)

Darstellung von Bildnotizen

Wann wird endlich die Darstellung von Bildnotizen in der deutschsprachigen Wikipedia aktiviert? --Wuselig 01:42, 22. Sep. 2010 (CEST)

Meinst du commons:Help:Gadget-ImageAnnotator? Der hat gerade erst die Server lahmgelegt (Bug 25238). Ich halte den für unnötig. Die wenigsten Bilder die noch auf de.wp verbleiben werden das gebrauchen. Die meisten Bilder werden nach Commons übertragen. Oder möchtest du nur die Darstellung eventuell vorhandener Bildnotizen von Commonsbildern auf der lokalen Dateibeschrebungsseite haben? Weiß nicht, ob das gebraucht wird. Der Umherirrende 16:11, 24. Sep. 2010 (CEST)

Zur Zeit funktioniert es tatsächlich noch nicht einmal auf Commons selbst, war vielleicht ein schlechter Zeitpunkt zu fragen. Aber was ich mir wünsche, sollte das Gadget mal wieder funktionieren ist, dass die Notizen auch bei der Einbindung eines Commonsbildes in einer nationalen Wikipedia, i.e. de direkt angezeigt werden, am besten schon im thumbnail/miniatur. Vor längerer Zeit war davon die Rede, dass dies in Kürze möglich sein soll, aber offensichtlich ist das ganze Gadget noch nicht ganz ausgegoren. Ich fände es aber schade, wenn das Gadget in die Tonne gekloppt wird, es hat meiner Meinung nach hohen enzyklopädischen Wert. --Wuselig 21:33, 24. Sep. 2010 (CEST)

Meine unmaßgebliche Meinung dazu ist, dass die Thumbnails erkennen lassen sollten dass da Bildnotizen sind, und diese dann nach dem Aufrufen des Bildes nutzbar sind. Nicht erst nach Aufrufen Wikipedia-Bild und dann Commons-Bild sondern nach einmal anklicken. --Diwas 22:38, 24. Sep. 2010 (CEST)

mwEmbed

Das gibt es mindestens auf commons und der en:WP. Damit können Untertitel von Videos in deutsch angezeigt werden. Siehe: Commons:Commons:Timed Text --Goldzahn 22:39, 19. Okt. 2010 (CEST)

+1. Habe es hier oben rechts mal getestet. Untertitelansehen geht mangels Erweiterung hier leider nur per ext. Link nach Commons. Viele Grüße --Saibo (Δ) 19:21, 27. Jan. 2011 (CET)

Friendly und Twinkle

Schlage vor, die beiden Gadgets Friendly und Twinkle auch in der deutschen Wiki einzuführen. -- Shenhemu 13:50, 3. Nov. 2010 (CET)

Die kann man nicht 1:1 übernehmen. Da wäre viel Anpassungsarbeit notwendig. Würdest du dies machen? --Leyo 14:44, 31. Mär. 2011 (CEST)

bytechange in den Versionsgeschichten

... so wie es auch in der Beo aussieht. Aktuell hier: Benutzer:Steef389/bytechange.js.

Besitzt den Parameter replace_size = true; um die Größenangabe zu ersetzen. Den Parameter habe ich persönlich nicht aktiv - ich sehe gern beide Zahlen. Viele Grüße --Saibo (Δ) 19:25, 27. Jan. 2011 (CET)

Hier die Ausgangsdiskussion dazu (im Archiv) --Saibo (Δ) 19:49, 27. Jan. 2011 (CET)

Mach ’ne „saubere“ und leicht dokumentierte Version davon und erstelle noch eine Dokumentationsseite, dann verschiebe ich beide an die entsprechenden Positionen. --32X 10:45, 28. Jan. 2011 (CET)

Das verschieben bekäme ich schon selbst hin - eher wusste ich nicht in welchem Format die Gadgets sein müssen. Nun habe ich aber oben gesehen, dass da wohl die Gadget-Definitionen verlinkt sind - dann schaue ich mir das mal an. Viele Grüße --Saibo (Δ) 15:31, 28. Jan. 2011 (CET)

Habe den Code jetzt auskommentiert und noch ein bisschen umgebaut. Eine Dokuseite könnte ich morgen noch erstellen, komme ich jetzt nicht mehr dazu. Wenn am Code noch etwas geändert werden soll, gebt mir bescheid (oder ändert es selbst; it's a wiki). --Steef ³⁸⁹ 20:50, 28. Jan. 2011 (CET)

Super, ich danke dir. Wenn eine Seite komplett geleert wurde, dann wird NaN statt der korrekten Differenz angezeigt - das könntest du vielleicht noch ändern, wenn du lustig bist. Beispiel: "(leer) (NaN)" in Benutzer:Saibo/eigene Spielwiese

Eine Doku habe ich mal hier vorbereitet - ich nehme an, dass das gemeint war: Benutzer Diskussion:Steef389/bytechange.js

Viele Grüße --Saibo (Δ) 21:37, 28. Jan. 2011 (CET)

NaN-Problem behoben. --Steef ³⁸⁹ 23:57, 28. Jan. 2011 (CET)

Danke, funktioniert. Viele Grüße --Saibo (Δ) 00:53, 29. Jan. 2011 (CET)

MediaWiki:Gadget-searchbox.js

Dieses Gadget ist sehr hilfreich. JackPotte 12:31, 11. Feb. 2011 (CET)

Commons:MediaWiki:Gadget-rightsfilter.js

Ich finde die Möglichkeit, Logs, Beitrags- und Beobachtungslisten zu filtern, ganz praktisch. Wie wär's dieses Gadget auch hier einzuführen? --Leyo 16:51, 30. Mär. 2011 (CEST)

Mach. Ich würde es, wie bei wikEd, aus dem Fremdwiki laden. (Andernfalls endet man wie in WikiSource irgendwann bei einer Uraltversion.) Probleme gibt es ggf., wenn man sich per HTTPS anmeldet. --32X 11:12, 31. Mär. 2011 (CEST)

Also so?

document.write('<script type="text/javascript" src="'

+ 'http://commons.wikimedia.org/w/index.php?title=MediaWiki:Gadget-rightsfilter.js'

+ '&action=raw&ctype=text/javascript"></' + 'script>');

--Leyo 14:49, 31. Mär. 2011 (CEST)

Bitte keine document.writes! Von mw:ResourceLoader/Migration guide (users)#Gadgets kopierter und angepasster Code:

/*
 Importiert die aktuelle Version des Gadgets Rightsfilter von Commons.
 Ermöglicht eine Filterung von Spezial:Log mit regulären Ausdrücken.
*/
var commonsBase = 'http://commons.wikimedia.org';
if ( mw.config.get( 'wgServer' ).indexOf('https://') === 0 ) {
        commonsBase = 'https://secure.wikimedia.org/wikipedia/commons';
}
mw.loader.load( commonsBase + '/w/index.php?title=MediaWiki:Gadget-rightsfilter.js&action=raw&ctype=text/javascript&smaxage=21600&maxage=86400' );

--Schnark 09:18, 1. Apr. 2011 (CEST)

Danke! Ich habe das Gadget so unter MediaWiki:Gadget-rightsfilter.js angelegt. Es scheint zu funktionieren.

Nach deinen obigen Ausführungen müsste MediaWiki:Gadget-wikEd.js angepasst werden, oder? --Leyo 09:48, 1. Apr. 2011 (CEST)

Ersetze „müsste“ durch „sollte“ und jeden Verweis auf Commons durch en (letzteres am einfachsten durch C&P des Navigation Popups-Beispiels auf der verlinkten mw-Seite). Falls du ohnehin dabei bist, MediaWiki:Gadget-WikiMiniAtlas.js und MediaWiki:Gadget-wikEd.js verwenden auch noch document.writes. --Schnark 10:34, 1. Apr. 2011 (CEST)

Ist das so und so korrekt? --Leyo 10:49, 1. Apr. 2011 (CEST)

Sieht gut aus, WikiMiniAtlas über http habe ich auch gerade erfolgreich getestet. WikEd erzeugt bei mir Fehler, aber das liegt an meinen Browser-Einstellungen. Da bei allen Benutzern, die das Gadget aktiviert haben, automatisch der Cache umgangen und der aktuelle Code geladen wird, werden Beschwerden schon schnell genug auf WP:FzW aufschlagen, falls es doch irgendwelche Probleme geben sollte. --Schnark 11:09, 1. Apr. 2011 (CEST)

Das Gadget Rightsfilter funktioniert hier noch nicht (außer man verwendet gleichzeitig das Popups-Gadget o. Ä.). Soweit ich sehen kann, kann man dies ohne Nebenwirkungen lösen, indem in MediaWiki:Gadget-rightsfilter.js noch die Zeile

window.getParamValue = mw.util.getParamValue;

am Anfang eingefügt wird. Alternativ bringt man einen Commons-Admin (im Zweifelsfall commons:User:Krinkle) dazu, in commons:MediaWiki:Gadget-rightsfilter.js alle getParamValue durch mw.util.getParamValue zu ersetzen. --Schnark 10:02, 5. Apr. 2011 (CEST)

Bei mir hat's aus diesem Grund funktioniert. Ich habe wie vorgeschlagen und im Vertrauen auf deine Kenntnisse die Commons-Version angepasst. --Leyo 15:45, 5. Apr. 2011 (CEST)

Funktioniert nun wunderbar. --Schnark 09:10, 6. Apr. 2011 (CEST)

en:User:Cacycle/wikEdDiff

Ich nutze Wikipedia:WikEd seit Einführung des Vector-Skins nicht mehr, aber der farbige diff ist weiterhin sehr praktisch zum Hilfe:Sichten. Gruß Matthias 09:03, 27. Apr. 2011 (CEST)

Kennst du Benutzer:Schnark/js/diff (oder auch Benutzer:Schnark/js/jsmodules)? --Leyo 10:35, 27. Apr. 2011 (CEST)

Nein, kannte ich bis jetzt noch nicht. Danke für den Tipp auch wenn ich zwischen Benutzer:Schnark/js/modulverwaltung und MediaWiki:Gadgets-definition ein Not-Invented-Here-Syndrom bzw. eine gewisse Redundanz sehe. Gruß Matthias 10:59, 27. Apr. 2011 (CEST)

Zur Ehrenrettung von Schnark: Schnark hat ein Workaround geschrieben, das eine fehlerhafte Funktion umgeht: en:User talk:Cacycle/wikEd#Bug in diff.js. Erfahrungsgemäß dauert es über 12 Monate, bis User:Cacycle einen bug beseitigt. – Eine Schnittmenge zwischen der Registrierung und Cookie-Steuerung in modulverwaltung und Gadgets-definition kann ich nicht erkennen. VG --PerfektesChaos 15:54, 12. Jun. 2011 (CEST)

eo:MediaWiki:Gadget-Popups.js, eo:MediaWiki:Gadget-markblocked.js

Hallo. Die Seiten eo:MediaWiki:Gadget-Popups.js, eo:MediaWiki:Gadget-markblocked.js verwenden noch document.write. Wie müßte ich sie anpassen? Gruß --Tlustulimu 17:14, 12. Jun. 2011 (CEST)

Geo-Referenzierungs-Dings-Bums

Moin! IMHO koennte/sollte ein Geo-Ref Tool wie z.B. GetCoordinate von Mcaviglia eingebaut werden. Ich mag nicht meine monobook immer wieder aendern und manchmal stolpert man ja auch einfach ueber eine fehlende Koordinate. Wer kann sowas basteln? :) --Hedwig in Washington (Post?)•B 02:37, 20. Jun. 2011 (CEST)

Kompakte Einverständiserklärung

Beim Bearbeiten werden zwei Boxen mit Hinweisen zu Lizensierung angezeigt:

Das Kopieren urheberrechtlich geschützter Werke ist verboten! Mit dem Speichern dieser Seite versichere ich…

und

Wenn du nicht möchtest, dass dein Text weiterbearbeitet und weiterverbreitet wird…

Ich sehe ein, dass diese Hinweise für Erstbenutzer besonders plakativ und eindringlich sein müssen und ich sehe auch ein, das jede Bearbeitung beim Speichern korrekt lizensiert werden muss. Ich schlage vor, diese Meldungen für angemeldete Benutzer per Option auf ein Mindestmaß (mit weiterführenden Links) zu verkürzen - sinngemäß so wie auf jeder Internet-Bestellseite steht

Ich habe die Allgemeinen Geschäftsbedingungen CC 3.0 und GFDL einschließlich der Nutzungsbedingungen gelesen und erkenne diese an.

Ich erhoffe mir davon, mehr vom dem wertvollem Bildschirmplatz für den Editor oder die Vorschau verwenden zu können.--Spischot 22:56, 9. Jul. 2011 (CEST)

Ich habe sie bei mir per Adblock komplett ausgeblendet - sehe ich genauso wie du. Man könnte natürlich sich auch in die skin.css etwas schreiben. Per Gadget müsste es auch gehen, ja. Allerdings sollte die Ausblendentscheidung schon wirklich wissenlich und bewusst getroffen werden, da ja dort die Zustimmung zur Lizenzierung drinsteht. Nicht das jemand das versehentlich macht und dann meint für ihn gelte die Lizenz nicht... Das scheint mir per Gadget-Checkbox etwas schwierig. Vielleicht fällt ja jemandem was ein. Viele Grüße --Saibo (Δ) 02:44, 10. Jul. 2011 (CEST)

Die Erklärung soll ja nicht weg sondern nur platzsparend dargestellt werden – justitisch ist das äquivalent. Ich sehe da kein Problem, insbesondere, nachdem das erst auf expliziten Benutzerwunsch reduziert wurde. CSS und Adblock sind keine Alternative für Gadgets. (Aber trotzdem mal neugierig gefragt: Wie lautete die entsprechende Filterregel für Adblock denn?) --Spischot 08:25, 10. Jul. 2011 (CEST)

Ich habe jetzt mal selbst herumprobiert und folgende Filterregeln erstellt:

!Hinweise für Nutzungsbedindungen beim Editieren von Wikiperdia unterdrücken (Die Nutzungsbedingungen gelten dennoch)
##div#editpage-copywarn
##div.mw-tos-summary

Ich habe dann noch versucht, diese Regel auf die Wikipedia-URLs zu beschränken:

|http://*.wikipedia.org##div#editpage-copywrn
|http://*.wikipedia.org##div.mw-tos-summary

Das funktioniert leider nicht – irgendwas mache ich wohl noch falsch. --Spischot 10:09, 10. Jul. 2011 (CEST)

Achso - ja - stimmt, wenn sie nur komprimiert dargestellt werden, dann ist das per Gadgethäkchen schon okay. Ich nehme an, dass per Gadget nur Javascript und nicht CSS aktiviert werden kann. Daher müsste dann wohl per Javascript eine entsprechende CSS-Regel injiziert (oder das Element gelöscht) werden.

wikimedia.org##DIV#editpage-copywarn
wikimedia.org##DIV.mw-tos-summary

Habe ich (für secure-Server) - für de.wikipedia.org dann natürlich das m durch ein p tauschen. Wenn wir schon dabei sind: "wikimedia.org##DIV#footer:last-child" finde ich auch noch praktisch. Viele Grüße --Saibo (Δ) 15:46, 10. Jul. 2011 (CEST)

Es geht auch CSS per Gadget. Vielleicht reicht aber hierfür auch ein Abschnitt auf WP:Skin oder so, da es schon sehr einfach ist, aber das sind andere Gadgets auch, also zwiespältig, ob es dafür lohnt. Der Umherirrende 16:28, 10. Jul. 2011 (CEST)

Skinbasteleien sind halt für den Ottonormaluser doch um einiges schwieriger, als ein Häkchen zu setzen. ;-) Per CSS könnte man sie aber nur ganz ausblenden und nicht den Text austauschen, richtig? Viele Grüße --Saibo (Δ) 18:46, 10. Jul. 2011 (CEST)

Text ändern geht nicht, aber kleiner kann man es machen. Der Umherirrende 18:49, 10. Jul. 2011 (CEST)

Schade, dass das mit den Ändern nicht geht, denn selbst verkleinern bringt nur wenig Platzgewinn. Die untere Box kann wohl ohne rechtliche Probleme ganz weg, da sie nur Hinweise und keine rechtlichen Erklärungen des Autors enthält. In der oberne Box sind ebenfalls drei Hinweise-Sätze („Das Kopieren …“, „Bitte gib …“ und „Wikipedia-Artikel …“, gleicher Art die eher weg sollten, was aber eine Änderung bräuchte. Und selbst der einzig juristisch bedeutende Satz „Mit dem Speichern …“ hat deutliches Kürzungspotential („Mit dem Speichern dieser Seite erkenne ich die Nutzungsbedingungen an“). Das Kleingedruckte als extrem klein gedrucktes bringt es irgendwie nicht. --Spischot 19:07, 10. Jul. 2011 (CEST)

Benutzer:Flominator/Weiterleitungshinweis.js

Blendet den Vorlage:Weiterleitungshinweis aus, wenn man nicht weitergeleitet wurde. Was haltet ihr davon? Was müsste man noch umstellen, bevor es freigeschalten werden könnte? --Flominator 07:44, 23. Okt. 2011 (CEST)

Funktioniert nicht mit anderen Sprachen und Skins (bei cologneblue und standard hat das Element nur die Klasse subtitle). Wo überall etwas zum Subtitle hinzugefügt wird, erfährst du hier, vielleicht hilft das weiter (Spezialfallbeispiel).

Ansonsten nutze jQuery.ready statt addOnLoadHook und die Überprüfung auf document.getElementById sollte man sich mitterweile auch sparen können.

Ob eine derartig triviale Funktionalität eines Gadgets würdig ist, weiß ich nicht. -- ✓ ^Bergi 21:33, 30. Okt. 2011 (CET)

Danke für das Feedback. Mit "eines Gadgets würdig" meinst du "lass den Quatsch" oder "pack es gleich in die Common.js"? Gruß, --Flominator 11:28, 13. Nov. 2011 (CET)

Letzteres, die Funktionalität ist ja sinnvoll. Nur "lohnt" sich für einen solchen Dreizeiler (etwas verkürzt geschrieben wirds einer) kaum eine eigene Skriptdatei zum Laden (gut, RessourceLoader hilft). Jetzt ist halt abzuwägen, ob die Community das in den Einstellungen aktivierbar haben möchte, defaultmäßig angeschaltet (MediaWiki:Common.js) haben möchte oder es als zu unbedeutend ansieht und man sich die Zeilen in die eigene common.js kopieren soll („…wenn mans unbedingt braucht“). -- ✓ ^Bergi 19:04, 13. Nov. 2011 (CET)

Wo sollte man das diskutieren? --Flominator 18:09, 4. Dez. 2011 (CET)

Hier ist eigentlich der richtige Ort dafür, nur leider zu wenig Publikum. Starte eine kleine Inline-Umfrage und verweise von FzW darauf? Eine Option hab ich übrigens vergessen: defaultmäßig angeschaltet als Gadget, d.h. nicht per Userscriptdatei sondern in den Einstellungen abschaltbar. -- ✓ ^Bergi 14:44, 27. Dez. 2011 (CET)

Ich würde, wenn dann Gadget mit RL bevorzugen - sollte so nicht wirklich länger dauern als per common.js, oder? Ein gesteigertes Bedürfnis für das Gadget habe ich allerdings nicht. ;-) Wahrscheinlich führt es z.B. dazu dass auf meinem lahmen Computer/Firefox der ganze Artikeltext herumhüpft, wenn das Script (auf einer der extrem wenigen 478 Seiten mit einem solchen Hinweis) geladen ist. Viele Grüße --Saibo (Δ) 19:30, 27. Dez. 2011 (CET)

Wenn Bug 32230 live ist, sollte das Script unbedingt auf wgRedirectedFrom umgestellt werden. Vielleicht kann damit auch die Ladereihenfolge so geändert werden, dass eine CSS-Definition aktiviert wird, bevor die Seite geladen ist, damit die Position nicht mehr herumhüpft. --Fomafix 21:41, 27. Dez. 2011 (CET)

Na, wenn ich das so verstehe, dass mit MW 1.19 dieses wgRedirectedFrom sowieso kommt, dann machen wir daraus doch gleich eine richtige Funktionalität für die MediaWiki:Common.js (Klassennamen als Arbeitstitel):

if (mw.config.get("wgRedirectedFrom")) {
   mw.util.addCSS("                              \
      .Seite-wurde-weitergeleitet-ausblenden {   \
         display: none;                          \
      }                                          \
      .Seite-wurde-weitergeleitet-einblenden {   \
         display: block ! important;             \
      }                                          \
                  ");
}

Wirkung: Wenn wgRedirectedFrom, dann ist das bereits in der HEAD-Ladephase oder jedenfalls so früh wie irgend möglich vor ContentLoad bekannt, und die beiden CSS-Definitionen werden wirksam.

Nun kann in jede einschlägige Vorlage die geeignete Klasse hineingeschrieben werden, also ein class="Seite-wurde-weitergeleitet-einblenden" style="display:none" in die Vorlage:Weiterleitungshinweis. Normalerweise ist wgRedirectedFrom immer unbekannt, damit in der Vorlage:Weiterleitungshinweis also unwirksam. Ist es jetzt tatsächlich eine WL, greift die Zuordnung und das display:none wird übertrumpft.

Wenn dann der BODY der Seite aufgebaut wird, sind die Stile von vornherein bekannt und die Vorlage wird gar nicht erst angezeigt, die Flickerei beim Seitenaufbau also vermieden.

Auf Wunsch noch mit negiertem Pfad und Klasse, noch hüpfsicherer:

} else {
   mw.util.addCSS("                                    \
      .Seite-wurde-nicht-weitergeleitet-ausblenden {   \
         display: none;                                \
      }                                                \
      .Seite-wurde-nicht-weitergeleitet-einblenden {   \
         display: block ! important;                   \
      }                                                \
                  ");

Falls man es also auf diesem Weg löst, kann man sich die Reklame für Gadgets und die Diskussion und Rückfragen und Doku mit Helferlein sparen und es kommt unbemerkt für alle einschließlich IP – ohne dass jemand die Wirkung mitbekommt.

Schönes Rest-2011 --PerfektesChaos 11:12, 28. Dez. 2011 (CET)

Na, und ich sehe gerade:

Abwarten auf MW 1.19 ist nicht erforderlich; es geht auch heute schon (und ging schon seit Jahren):

/* MW 1.19 -- bis dahin workaround
if (mw.config.get("wgRedirectedFrom")) {
*/
if (document.location.pathname !==
    mw.util.wikiGetlink(mw.config.get(wgPageName)) ) {

Mit MW 1.19 sollte der Ausdruck allerdings hübscher gestaltet werden.

URL-Encoding mag noch differieren; sollte aber auch den Umlaut von Bund für Umwelt und Naturschutz Deutschland richtig identifizieren, zumal nur im ANR und wohl ausschließlich im Zusammenhang mit Abkürzungen eingesetzt.

Kann sofort in MediaWiki:Common.js eingebaut werden, Gadget ist nicht erforderlich.

Wenn die else-Clause wahrgenommen wird, wäre in Vorlage:Weiterleitungshinweis einzufügen: class="Seite-wurde-nicht-weitergeleitet-ausblenden"

Enjoy. --PerfektesChaos 13:04, 28. Dez. 2011 (CET)

…&& mw.util.getParamValue("title") != encodeURIComponent(wgPageName) (oder so ähnlich)?

@Klassen: Bitte nicht doppelt moppeln, einmal redirected-hide und einmal notredirected-hide sollten genügen. Und bitte keine ganzen Sätze im class-Attribut :-) -- ✓ ^Bergi 13:27, 28. Dez. 2011 (CET)

• Das mit den title= war mir auch aufgefallen, würde ich aber im vorläufigen workaround nicht verkomplizieren. Bei diffpages, preview und Permlink zeigt der workaround eben „fälschlich“ und wie auch schon seit Jahren die Kiste – das kann dann später mit dem sichereren MW 1.19 auch noch wegfallen. Der Umlaut wird ja wohl bereits richtig erfasst. In erster Linie geht es um einfache Leser, auch als IP, die im Suchfeld über GPL gekommen sind, oder aber über interne Verlinkung auf GNU General Public License. Wobei man dann künftig als Linkziel die ausgeschriebene Form GPL wählen sollte, mit der Abkürzung als Linktitel – was auch bisher schon zu einem selbsterklärenden Tooltip führt und ggf. einen Klick auf den Artikel spart.
• Die „ganzen Sätze“ in der class (einleitend als „Arbeitstitel“ bezeichnet) oder auch die vom Minifier nicht erfassten Leerzeichen im addCSS() dienen dem leichteren Verständnis der Diskutanten.

In diesem Sinne --PerfektesChaos 14:01, 28. Dez. 2011 (CET)

Ungefähr so wollte ich es auch umsetzen. Ganz zufrieden bin ich aber noch nicht. Der Artikel GNU General Public License hat neben der Weiterleitung GPL auch noch die Weiterleitung GNU GPL. Bei einem Aufruf von GNU GPL ist ein Weiterleitungshinweis auf GPL (Begriffsklärung) ebenso nicht sinnvoll. Der Weiterleitungshinweis sollte daher nur dann angezeigt werden, wenn wgRedirectedFrom gleich {{{1}}} der Vorlage:Weiterleitungshinweis. Für Hinweise auf mehrere Weiterleitungen muss die Vorlage und deren Einbindungen aber noch umgebaut werden. Die zwei Monate bis MediaWiki 1.19 und damit wgRedirectedFrom bei uns kommt, können wir auch noch warten. --Fomafix 15:45, 28. Dez. 2011 (CET)

• Ich bewundere deinen Optimismus. Ich halte es eher mit der alten Bauernregel: Software-Projekte dauern immer doppelt so lange wie angekündigt, und erwarte MW 1.19 eher zu Ostern.
• Es schadet nichts, die überwiegende Zahl der vermeidbaren Boxen-Anzeige bereits in diesem Jahr standardmäßig per workaround zu entfernen. Die Feinarbeit kann dann irgendwann in 2012 kommen.
• Da es offenbar ausschließlich nur um den ANR geht, lässt sich unnötiger DOM-style-Aufwand vermeiden mit einem umschließenden ! wgNamespaceNumber und anschließend innen auch wgAction==="view" – auf einer diffpage kann es praktisch nie eine WL der beschriebenen Art geben, zumindest in keinem üblichen Arbeitsablauf.
• Nun zu der von dir benannten Tücke, dass mehrere unterschiedliche WL auf die Seite verweisen, aber nur bei der Standard-Abkürzung die Box gezeigt werden soll.
  • Wurde direkt auf den vollständigen Seitennamen verlinkt, dann kann bereits in der HEAD-Phase flickerfrei die Box in einem äußeren div unterdrückt werden mit:
    • class="redirected-no-hide"
    • Das kann jetzt schon per document-workaround für den Standardfall geregelt werden.
  • Handelt es sich um eine Weiterleitung von irgendwas, dann muss {{{1}}}} abgeglichen werden. Das ist aber erst während des BODY und DOM-Aufbau analysierbar. Je nachdem, wie schnell und in welcher Reihenfolge DOM-Analyse, Rendering, Skriptausführung, DOM-Veränderung, Auswirkung des eingefügten Styles greifen, ist in diesen Fällen Flackern und Hüpfen nicht völlig auszuschließen, wenn eine Irgendwie-Weiterleitung auch eine Abk-WL ist.
  • Unterdrückt werden kann die Anzeige mit der Definition von (syntaxhighlight-Problem mit " im RE-Literal)

if (mw.config.get("wgRedirectedFrom")) {
   if (mw.config.get("wgAction" === "view")) {
      mw.util.addCSS("                   \
         .redirected-from-"
               + / +:*=%&?()\/'"{},/.replace(mw.config.get(wgRedirectedFrom), "")
               + "           {           \
            display: block ! important;  \
         }                               \
                     ");
   }
} else {
   mw.util.addCSS("           \
      .redirected-no-hide {   \
         display: none;       \
      }                       \
                  ");
}

und in der Vorlage in einem zweiten, inneren

<div class="redirected-from-{{{1|}}}}" style="display:none">

• Für die auftretenden Fälle von Abk-WL müsste man mal die Seitentitel analysieren.
  • Soweit ich das erstmal sehen kann, sind die Abkürzungen alle aus den 26 A–Z (Großbuchstaben ohne Umlaute). Sollte sich erweisen, dass bei irgendwas Kleinbuchstaben oder URL-encoded Zeichen oder Leerzeichen für die Bildung des BKL-Lemmas auftauchen, müsste dafür ein 2. Vorlagenparameter eingeführt werden mit

    <div class="redirected-from-{{{2|{{{1|}}}}}}}}" style="display:none"

• Wirkung: Bei einer Weiterleitung ist die äußere Klasse redirected-no-hide nicht wirksam, das äußere div wird angezeigt. Das innere div schaltet grundsätzlich auf unsichtbar (display:none); dieses wird genau dann aufgehoben, wenn der Name des Referrers zum redirected-from- der Abk passt. In diesem Moment könnte es zum Flackern kommen, oder aber manche ungebräuchliche Browser könnten das important verschlafen und den Hinweis nicht anzeigen. Diese Benutzer hätten dann halt Pech gehabt, aber Browser dieser Schlafmützigkeit wären mir nicht mehr bekannt.
  • Über ein encodeURL(wgRedirectedFrom) statt .replace() wäre gesondert nachzudenken. Gemäß CSS1/HTML4-Definitionen ist nicht vorgeschrieben, dass die Zeichen im Klassenbezeichner ASCII sein müssen. Ein schlichtes Ä würde keinen Ärger machen, das Prozentzeichen in einem encoded könnte das aber durchaus. Eventuell kann man an ein .toUpperCase() denken, ggf. in Kooperation mit einem {{uc:}}.
  • Das redirected-from- gibt für den Fall der Nicht-Buchstabe/Ziffer den ursprünglich aufgerufenen Seitennamen nicht exakt wieder; es ist aber egal und nur der Fall der vollen Übereinstimmung mit Abk ist relevant.
  • Es sind Browser im Gebrauch, die bei einer class nur den ersten Bezeichner für CSS-Darstellungen auswerten; deshalb zwei geschachtelte div, bei denen die CSS-relevante class jeweils einen eigenen Bezeichner hat.
• Auf einer diffpage, preview usw. sollte Vorlage:Weiterleitungshinweis grundsätzlich nie angezeigt werden; wäre immer sinnfrei. Über {{REVISIONID}} im {{ns:0}} kann die Vorlage das bereits selbst unterdrücken; JS würde dies wo immer möglich weiter fördern.
• Diese ausführlichen Darlegungen sind dafür vorgesehen, in Teilen in die Doku der Vorlage(n) aufgenommen zu werden.

Viel Spaß --PerfektesChaos 14:53, 29. Dez. 2011 (CET)

---

MediaWiki 1.19 ist aktiv und es gibt die globale Variable wgRedirectedFrom. --Fomafix (Diskussion) 22:16, 1. Mär. 2012 (CET)

Na dann! Für MediaWiki:Common.js:

mw.loader.using( "mediawiki.util", function() {
    var css = [];
    css.push(".noscript { display:none; }"); // <noscript>-Emulation via <div class="noscript">
 
    var red = false;
    if (mw.config.exists('wgRedirectedFrom') && (red = ""+mw.config.get('wgRedirectedFrom')) && red.length) // only set for redirects? maybe an array? will surely change in future
        css.push(".show-redirected { display:none; }"); // == hide if not redirected
    else {
        css.push(".hide-redirected { display:none; }"); // == show if not redirected
        red = red.replace(/[\u0000-\u00A0]/g, function(x) {
            return x.match(/[-_0-9a-zA-Z]/) ? x : x==" "?"_":"\\"+x;
        });
        css.push(".hide-redirected-from-"+red+" { display:none; }");
        css.push(".show-redirected-from-"+red+" { display:block; }");
        css.push("span.show-redirected-from-"+red+" { display:inline; }");
    }
 
    mw.util.addCSS(css.join("\n"));
});

Das sollte eigentlich alle möglichen Fälle abdecken. die Vorlage:Weiterleitungshinweis wird standardmäßig mit class="show-redirected" versehen, wenn man einzelne WL berücksichitgen will kann man das mit class="hide-redirected-from-Gefahrenpiktogramm" oder class="hide-redirected show-redirected-from-\!" tun.

• Damit braucht man auch kein style-attribut, welches mit !important overruled werden muss. Springen sollte nicht passieren, das common.js wird eh recht früh geladen – optimieren geht nicht.
• eine valide CSS-Klasse ist schwierig. Unter U+00A1 sind nur die üblichen Verdächtigen erlaubt. Ausgeschlossen werden müssen also \u0001\u0002\u0003\u0004\u0005\u0006\u0007\b\t\n\v\f\r\u000e\u000f\u0010\u0011\u0012\u0013\u0014\u0015\u0016\u0017\u0018\u0019\u001a\u001b\u001c\u001d\u001e\u001f !\"#$%&\'()*+,./:;<=>?@[\\]^`{|}~\u007f\u0080\u0081\u0082\u0083\u0084\u0085\u0086\u0087\u0088\u0089\u008a\u008b\u008c\u008d\u008e\u008f u0090\u0091\u0092\u0093\u0094\u0095\u0096\u0097\u0098\u0099\u009a\u009b\u009c\u009d\u009e\u009f\u00a0, wobei die meisten Steuerzeichen und [] eh nicht als Seitentitel erlaubt sind.
• Browser, die nur eine CSS-Klasse berücksichtigen, gehören in den Schrott und können nicht in DOM-Strukturen berücksichtigt werden.
• wgAction sollte keine Rolle spielen. Die Vorlagen müssen authentisch reagieren, und in diff/preview/sonstwas gibts auch so kein wgRedirectedFrom
• Das Ganze wurde mit noscript zusammengelegt, um stylesheets zu sparen (was von addCSS eigentlich selbst erledigt werden sollte)

meint -- ✓ ^Bergi 03:35, 2. Mär. 2012 (CET)

Guten Morgen; wieder fit?

• Bug report:
  • mw.config.isset meint wohl mw.config.exists
  • red.length meint wohl css.length
  • css.join("\n") – der Mehrwert von \n vor dem </style> hat sich mir nicht erschlossen.
  • css = []; css.push() – Argument von addCSS ist ein String.
• Eine versteckte Wertzuweisung knockt jeden späteren Bearbeiter aus:

       (red = ""+mw.config.get('wgRedirectedFrom') && red.length)

Im Übrigen ist sie völlig überflüssig; wgRedirectedFrom wird offenkundig dann und nur dann gesetzt, wenn es nicht leer ist. Wer trotzdem einen leeren String in wgRedirectedFrom befürchtet, mag setzen:

     var red = mw.config.get("wgRedirectedFrom");
     if (red) {
        // ...
     } else {
        // "" oder null (=undefiniert)
     }

• Das Ganze in eine Abfrage einzuschließen (etwa wgIsArticle) spart dem Gadget-Benutzer Ladezeit und DOM-Manipulation und Neuaufbau des CSS-Modells, um Seiten oder Zustände auszuklammern, bei denen die Vorlage nicht existieren kann (Spezialseite; edit immer unter wirklichem Titel – Anzeige schlimm?). Wenn es denn wirklich kein Gadget mehr sein soll, sondern zwangsweise jedem Leser per MediaWiki:Common.js aufgedrückt werden soll, muss es sorgsam mit dessen Ressourcen haushalten.
• Im Übrigen bin ich aber der Meinung, dass die Vorlage dann (MediaWiki:Common.js) so zu schreiben ist, dass CSS-Direktiven nur benötigt werden, wenn tatsächlich der Fall wgRedirectedFrom eingetreten ist; die Vorlage also standardmäßig ausgeblendet ist und nur in der Situation wgRedirectedFrom CSS-Direktiven eingefügt werden, die ein allgemeines oder selektives Einblenden (Abk.) ermöglichen.
• Mir schmeckt es überhaupt nicht, dass zwangsweise bei jedem Leser eine mühselige nachträgliche DOM-Manipulationim HEAD und CSS-Modell eingeführt wird, die nur in einem winzigen Bruchteil von Seitendarstellungen tatsächlich erforderlich ist.
• Wenn in der Vorlage auf eine Klasse verwiesen würde, die statisch in MediaWiki:Common.css als { display:none; } definiert ist (ein allgemeines .hide), und anschließend eine ID div#redirect-warning auf { display:block; } das ganze Teil sichtbar macht, müsste man die aktive CSS-Manipulation auf Fälle einer echten Weiterleitung beschränken können, sofern .hide und #redirect-warning dasselbe div identifizieren.
• mw.loader.using("site", function () { wird erst nach dem Laden der MediaWiki:Common.css ausgeführt.

VG --PerfektesChaos (D) 10:11, 2. Mär. 2012 (CET)

Nein, das ist explizit für die Common.js gedacht. Da frisst es keine Ressourcen, wird rechtzeitig (im Head) geladen und ist für alle Benutzer drin. Am (body-)DOM wird nichts manipuliert, das style-tag sowieso erzeugt (.noscript). 1 Zeile mehr CSS (bzw. 3 im Falle einer WL, selten) zu parsen wird man nicht mal messen können.

das mit dem überflüssigen Überprüfen wäre ich mir nicht so sicher. Wo du schreibst "offenkundig", bin ich da lieber vorsichtig. Im Bug steht auch was von Array (gut, bei genauem Lesen wieder revidiert). Möglicherweise vereinfachungswürdig, ja.

von deinem Bugreport stimmt nur der exists()-Fall (isset muss irgendwie von der PHP-Schiene gekommen sein). Und eine vergessene Klammer hab ich noch gefixt. Ansonsten gibt der join eines Arrays einen String zurück (ohne joiner am Ende), und eine versteckte Wertzuweisung sehe ich auch nicht - die ist extra.

Auf allgemeines Ausblenden würde ich gerne verzichten:

• User ohne js sehen dann nämlich gar nichts mehr von dem Hinweis
• display:none ist schwer zu überschreiben. block? inline? table? sonstwas? Eine Ausblendung ist deutlich einfacher
• common.css könnte man erwägen. Trifft dann aber wieder die noscript-user, und kann auch nicht weniger Flackern verhindern.

denkt -- ✓ ^Bergi 11:12, 2. Mär. 2012 (CET)

Habt ihr den mehrzahl-Parameter gesehen? Damit wird es dann unmöglich. Ich würde das erst ausblenden, dann auf ready warten und den Text vergleichen, wenn er gleich ist, das ganze wieder einblenden.

if( mw.config.exists( 'wgRedirectedFrom' ) ) {
 mw.loader.using( [ 'mediawiki.util' ], function() {
  mw.util.addCSS( '#Vorlage_Weiterleitungshinweis { display: none; }' );
  $( function() {
   if( mw.config.get( 'wgRedirectedFrom' ).replace( /_/g, ' ' ) === $( '#Vorlage_Weiterleitungshinweis_text' ).text() ) {
    mw.util.addCSS( '#Vorlage_Weiterleitungshinweis { display: block; }' );
   }
  });
 });
}

Dafür müsste mal allerdings in der Vorlage Parameter 1 in ein span mit id packen. Vorsichtshalber sollte man den Parameter vorher durch FULLPAGENAME schicken, damit er auch entsprechend ist. Der Umherirrende 20:21, 2. Mär. 2012 (CET)

Bei deiner Lösung wird derzeit die Vorlage standardmäßig eingeblendet :-)

Aufs DOM warten lassen wir lieber mal, und schon gleich Abgleiche mit Vorlagenparametern. Ersteres führt 100%ig zu Flackern, und zweiteres wird von viel zu vielen Unsicherheiten beeinflusst.

Meine Lösung ist ganz einfach ausgelegt, wie am Anfang von Fomafix vorgesehen: Die Tabelle bekommt neben der Id noch die Klasse show-redirected und wird damit nur eingeblendet, wenn man weitergeleitet worden ist. Fertig. bzw ist sie eingeblendet, wenn keine Skripte verfügbar sind

Der Rest ist nur für Spielkinder (und sollte wahrscheinlich gar nicht in die Vorlage). So könnte man die Box in American Standard Code for Information Interchange etwa mit den Klassen hide-notredirectedshow-redirected hide-redirected show-redirected-from-ascii show-redirected-from-ASCII versehen, damit sie wirklich nur bei diesen beiden WL angezeigt wird. Oder eben im Text sowas wie du wurdest von <span class="hide-redirected-from-ASCII">ascii</span><span class="hide-redirected-from-ascii">ASCII</span> hierher geleitet schreiben (mit den verschiedenen Kombinationen ist alles möglich). Das ist aber viel zu kompliziert für den Standardgebrauch.

Da wäre es fast einfacher, man böte in einem fest versteckten div (style="display:none;") verschiedene DOM-Bausteine an. Sobald eine Weiterleitung erkannt wurde, kann ein Script onDomReady den passenden Auswählen und mit großem Traraa in einen roten Kasten an den Anfang des Artikels animieren (einfaches Auftauchen lassen würde Flackern bedeuten). Der noscript-Nutzer wird sich sicher darüber freuen, dass er gar keine Information mehr bekommt.

meint -- ✓ ^Bergi 02:24, 3. Mär. 2012 (CET)

Stimmt, den Fall, das man die Seite ohne Weiterleitung besucht, hatte ich irgendwie nicht auf dem Schirm gehabt … Der Umherirrende 16:43, 3. Mär. 2012 (CET)

MW 1.19 ist da. Wie geht es nun weiter? --Flominator 16:33, 4. Mär. 2012 (CET)

secure.wikimedia.org

Wäre einer der Admins so lieb, secure.wikimedia.org in protokoll-relative URL zu vereinfachen?

• MediaWiki:Common.js 2012: siehe unten
• MediaWiki:Gadget-revisionjumper.js
• MediaWiki:Gadget-rightsfilter.js erl.
• MediaWiki:Gadget-wikEd.js nach Benutzerbeschwerde
• MediaWiki:Gadget-WikiMiniAtlas.js erl.

Danke --PerfektesChaos 20:16, 15. Nov. 2011 (CET)

Dass MediaWiki:Gadget-revisionjumper.js sowohl für http:, als auch https: und secure funktioniert, hast du gesehen? ;o) Hatte ich natürlich gleich angepasst … Grüße, —DerHexer (Disk., Bew.) 22:13, 15. Nov. 2011 (CET)

Wäre es denn problematisch, wenn man secure rausstreicht? Also dass von secure.wikimedia.org Dateien von //*.wikipedia.org (ebenfalls per https) angefordert werden, oder würden da Cross-Domain-Probleme entstehen? -- ✓ ^Bergi 22:49, 15. Nov. 2011 (CET)

In diesem Skript könnte man secure entfernen, wenn man davon ausgeht, dass niemand mehr dieses Skript unter secure verwendet (das bezweifle ich mal teilweise). Bei anderen Skripten meinerseits besteht aber dieses Cross-Domain-Problem. Grüße, —DerHexer (Disk., Bew.) 23:32, 15. Nov. 2011 (CET)

• Mir geht es nur darum, den Code (hier: Helferlein, von Vielen genutzt) möglichst lesbar und nachvollziehbar zu gestalten und grundlose Ausnahmen zu vermeiden.
• Die anderen Skripte bestünden dann nur aus einer Zeile wie

      mw.loader.load("//en.wikipedia.org/..............

• Bei revisionjumper.js verhält es sich insofern etwas anders, als hier das eigentliche Arbeitsskript hinterlegt ist.
  • Gleichwohl würde das nämliche Vorgehen zum Erfolg führen:

      mw.loader.load(wgServer+wgScript+
      // vielleicht besser als
      mw.loader.load("//de.wikipedia.org/w/index.php?title=

• Ich habe meine Bookmarks auf secure.wikimedia.org behalten und melde mich zu Testzwecken regelmäßig auch darüber an. Cross-Domain-Probleme kann ich mir vorstellen, wenn die API involviert ist, wie das bei revisionjumper der Fall ist, weil dann XMLHttpRequest auf die Domain Wert legt. Das hängt aber nicht von der URL ab, unter der das umgebende Skript geladen wurde, sondern von der Gestaltung jedes einzelnen API-Aufrufs.

Liebe Grüße --PerfektesChaos 09:45, 16. Nov. 2011 (CET)

Da eh schon Sachen von bits geladen werden, scheint es beim laden des Skripts nicht zu stören. Viel wichtiger ist es, dann angebotende Links auch auf secure.wikimedia.org bleiben, damit der Benutzer angemeldet bleibt. Bei einem Skript, was nur interne Links erzeugt ist das einfach. Bei links auf Commons müsste man es so machen, wie in der Common.js derzeit ist. Der Umherirrende 11:53, 16. Nov. 2011 (CET)

1. Das ausgeführte Skript hat keinerlei Kenntnis davon, von welcher URL sein Quellcode stammt (debugging-Funktionen mal ausgenommen).
2. Richtig ist, dass generierte Verlinkungen die Umgebung des Benutzers beachten sollen, der es ausführt; API-requests müssen in dieser Domain bleiben.
3. Wer unter https angemeldet ist, sollte nur Ressourcen einbinden müssen, die über zertifiziertes https geladen werden.

LG --PerfektesChaos 17:22, 16. Nov. 2011 (CET)

Status 2012: Common.js an zwei Stellen

1. Bilddiskussionsseitenlink kann bei secure.wikimedia.org weiterverlinken auf https://commons.wikimedia.org/wiki/ und ansonsten Protokoll-relativ.
2. Import von /secure.js wird nicht wirksam bei https://de.wikipedia.org – müsste aber allgemein bei window.location.protocol==="https" ausgeführt werden, um die expliziten http in der Seite umzusetzen.

VG --PerfektesChaos 00:04, 7. Jan. 2012 (CET)

Die Commons-Link sind in Ordnung, weil man dann seine Domain nicht verlässt. Import von secure.js ist für protokoll-relative WP nicht sinnvoll, weil es secure.wikimedia.org-Links generiert. Ich hatte daher unter MediaWiki Diskussion:Common.js#MediaWiki:Common.js/relative.js ein ähnliches Skript für protokoll-relative WP vorgeschlagen. Das Beispiel dort funktioniert, aber es hat sich bis jetzt noch niemand gefunden, das entsprechend umzusetzen. Der Umherirrende 22:59, 7. Jan. 2012 (CET)

• Commons-Domain nicht verlassen bei secure – ja, okay, ist ein Gesichtspunkt; vielleicht denkt sich jemand was dabei.
• Wenn ein secure.js eingebunden wird, dann soll dieses natürlich künftig auf protokollrelativ statt auf http verlinken, fertig. Geht viel einfacher als die bisherige Praxis und wäre für beide https-Wege nutzbar.

Schönen Sonntag --PerfektesChaos 23:28, 7. Jan. 2012 (CET)

Abhängigkeiten von mw.util deklarieren

Mit 1.19 wird es notwendig sein, alle Abhängigkeiten von mw.util zu deklarieren (so wie es bereits bei PermaPageLink geschehen ist). Dies betrifft mindestens Gadget-Zeitzonenkonverter, Gadget-rightsfilter und Gadget-toolserver-integration. --Schnark 11:49, 17. Jan. 2012 (CET)

Wenn jetzt in den Gadgets [ResourceLoader|dependencies=mediawiki.util] rein geschrieben wird, wird erst der RL-Support aktiviert. Die meisten Gadgets werden nicht per RL geladen, aber aufgrund der Ladereihenfolge funktioniert mw.util und jQuery dort. Man müsste also die Gadgets durchgehen und auf RL heben und kann dann den RL-Support mit Abhängigkeiten deklarieren. Seit rev:109680 dürfte das Problem aber nicht mehr akut sein. Der Umherirrende 11:33, 22. Jan. 2012 (CET)

Ich sehe nicht, wie diese Änderung etwas am Problem ändert, oder wird mediawiki.util durch wikibits so zum impliziten Top-Modul? --Schnark 09:30, 23. Jan. 2012 (CET)

Solange WMF-Wikis mit legacy Code ($wgIncludeLegacyJavaScript) ausgeliefert werden, wird auch wikibits ausgeliefert und somit auch mediawiki.util. So zumindestens mein Verständnis der Sache. Wenn allerdings, wie beispielsweise im translatewiki, der legacy code deaktiviert wird, dann könnten wir hier ein Problem bekommen, weil man dann nicht abschätzen kann, ob es da ist oder nicht. Schöner und sauberer ist eine Deklarierung der Abhängigkeit, vorallem hinsichtlich eines Exports in andere Wikis und so. Der Umherirrende 18:27, 23. Jan. 2012 (CET)

Ausgeliefert wird mediawiki.util immer, die Frage ist nur, wann. Es kann durchaus passieren (bzw. um genau zu sein: es passiert), dass zuerst der Code des Gadgets und erst direkt danach der von mw.util geladen wird. In diesem Fall ist es natürlich für das Gadget notwendig zu warten, bis der Code von mw.util dann tatsächlich auch ausgeführt wurde. --Schnark 10:53, 24. Jan. 2012 (CET)

Auch wenn du es nicht wusstest, hattest du dennoch Recht: Durch die Änderung wird mediawiki.util frühzeitig geladen, sodass das Problem wirklich nicht mehr akut ist. --Schnark 09:24, 25. Jan. 2012 (CET)

Ja, es war eine Annahme von mir. Dadurch das Wikibits sehr früh geladen werden muss (aktuell mit dem startup-Module), wird auch mediawiki.util früh angefordert und könnte somit vor allem anderen fertig sein. Anders ist aber tatsächlich schöner. Der Umherirrende 19:00, 25. Jan. 2012 (CET)

Internal link translator

One my friends developed internal link translator this code helps users to translate articles, templates, categories with their internal links also it has option to change language

how it works?

it adds translate links to fa button next to title of the page and whit clicking on translate it replace other wikis links inside the text .in edit view or general view it has two different works. now we are using it in fa.wiki as external extention and it is realy useful for translating nave boxs . by clicking on fa you can change the language to home-wiki

case for templates

I translated en:Template:Fars Province Labelled map and en:Template:Persian Constitutional Revolution Persions from fa.wiki to en.wiki.(by one click!)

case for categories;

in fa.wiki many of the users use this script to copy categories with their upper category

case for lists

I translated many list of cities from de.wiki to en.wiki and fa.wiki

next features

in my opinion it is much better to add possibility to use it as gadget in home wiki but the major problem is when you want to transfer a template or text from second-wiki->home-wiki you must instal it in second-wiki and it is very difficult for elementary users that they cannot work with vector.js also they can not handle it from their home-wiki.if some one can extend this script to ask page name in other wiki (with text box) and transfer translated text to user's sub-page or predefined page it will be useful and possible to handle it in home-wiki.Reza1615 (talk) 20:49, 8 February 2012 (UTC)

I don't think is needed often enough to be provided as a gadget. Also, it should be made possible to translate from any langugage into the current wiki, instead of translating the current wiki page to another language; use jsonp to call external apis. But feel free to add it to our script index! -- ✓ ^Bergi 23:17, 8. Feb. 2012 (CET)

the main Idea of this script is using other wikis pages (nave boxes, articles, lists,...) and translate them to home wiki language in simple way not exporting home wiki to others (it is in second point)so in this case it should install in second wiki else some one improve it. Unfortunately I am not advanced in j.s. and i cannot develop in js. is it possible for you to extend this code to accept external link?Reza1615 10:45, 9. Feb. 2012 (CET)

Bug tracking helper gadget

The release of 1.19 is imminent, and, to help track any issues reported on-wiki (for example on WP:FZW or the like), I'd like to get the gadget we have been using on enwiki.beta deployed here. I've found this gadget very useful on the problem reports and hope to use it here. Please add it. -- ☠MarkAHershberger☢(talk)☣ 01:29, 13. Feb. 2012 (CET)

Na, it seems to break bugzilla :-( -- ✓ ^Bergi 02:34, 13. Feb. 2012 (CET)

So I see ☹. I'll work with Rob Moen to get the identified problem fixed. -- ☠MarkAHershberger☢(talk)☣ 20:00, 13. Feb. 2012 (CET)

It is tracked under Bug 34366. Der Umherirrende 18:32, 14. Feb. 2012 (CET)

cat-a-lot

Hi, I found a version of commons:MediaWiki:Gadget-Cat-a-lot.js that works on wikis ( change page's instead of file's categories). we use it in fa.wiki (fa:مدیاویکی:Gadget-Cat-a-lot.js) may be it is interesting for you.Reza1615 10:40, 16. Feb. 2012 (CET)

There's already the Wikipedia:WikiProjekt Dateikategorisierung/Werkzeug/x.js, which seems to do quite the same but with much more abilities. -- ✓ ^Bergi 11:15, 16. Feb. 2012 (CET)