MediaWiki Diskussion:Gadgets-definition

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche

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:

Neues Helferlein vorschlagen
Automatische Archivierung
Auf dieser Seite werden Abschnitte automatisch archiviert, die seit 7 Tagen mit dem Baustein {{Erledigt|1=~~~~}} versehen sind.
Archivübersicht Archiv
Wie wird ein Archiv angelegt?

Gadget: Fundraiser Banner Deactivation[Bearbeiten]

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[Bearbeiten]

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[Bearbeiten]

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[Bearbeiten]

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[Bearbeiten]

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 Blue ribbon.svg 15:56, 29. Jun. 2009 (CEST)
Zudem werden chick und nostalgia nicht mehr gewartet. ...- .-. ... / -.. .. ... -.- 17:17, 29. Jun. 2009 (CEST)

QuickEdit[Bearbeiten]

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[Bearbeiten]

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)

Benutzer:Ireas/Gadget-Commonsverschiebung.js[Bearbeiten]

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[Bearbeiten]

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[Bearbeiten]

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[Bearbeiten]

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. Symbol support vote.svg 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)

Entfernen religiöser Symbole[Bearbeiten]

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)

Darstellung von Bildnotizen[Bearbeiten]

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)
Ich möchte auch mal freundlichst dran erinnern, das einzubinden. Immerhin sagt ein Bild oft mehr als 1000 Worte. Und wenn wir anfangen Artikel zu straffen, sind wir wohl mengenmäßig bei Bildern um ein vielfaches effektiver. Die paar Notizen sind hier die perfekte Ergänzung. Da die Bilder von teilweise von Commons kommen, bringen sie ihre Notizen auch von ihrer jeweiligen Ablage bzw. URL mit oder die URL kann von der des Bildes abgeleitet werden. Ich halte das für eines der wichtigsten Tools, auch gerade weil es so hilfreich ist und bereits existiert. Ich denke hier fehlt die Kommunikation, das ganze richtig und übergreifend einzubinden. Dieser Schritt kommt schließlich allen Wikipedien zu gute. D.h. Kontakt zu den Entwicklern, Auswertung des Ursachen des letzten Fehlers, Simulation im Sandkasten, Freigeben des Sandkastens (Beta) und wenn keine Abstürze oder Fehler mehr vorkommen, Freigabe und Ausrollen. Ich weis, das Qualität fast soviel ist wie die Entwicklung selbst. Nur geben wir hier gerade auf halbem Weg auf. --Hans Haase (Diskussion) 10:49, 31. Okt. 2012 (CET)
+1. Dieses Gadget böte m. E. einen deutlichen Mehrwert für die Leser! Nur mal als Beispiel möchte ich Datei:Panorama von Hinterbrand zu Watzmann Hockalter und Co.jpg und Datei:64 ACPS Atlanta 1996 Swimming Australian Team.jpg nennen... die Notizen bieten Informationen, die in Textform kaum abzubilden sind. --тнояsтеn 10:57, 31. Okt. 2012 (CET)
Mochte noch etwas mit vereinten Kräften nachreichen: en:Help:Gadget-ImageAnnotator und nochetwas, Bild innerhalb der Notiz ist übrigens auch möglich! --Hans Haase (Diskussion) 11:35, 31. Okt. 2012 (CET)
Noch eine Anmerkung: Wenn das Bild in der WP und nicht auf Commons liegt, dann können es nur Insider finden, da sie die "Beschreibung auf Commons" erst finden müssen und wissen was dahinter steckt. Bitte bitte bitte einbinden. --Hans Haase (Diskussion) 21:08, 31. Okt. 2012 (CET)

mwEmbed[Bearbeiten]

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)

MediaWiki:Gadget-searchbox.js[Bearbeiten]

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

Geo-Referenzierungs-Dings-Bums[Bearbeiten]

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ändniserklärung[Bearbeiten]

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)

M.E. sollte nach Erstellung des Benutzerkontos – oder sobald man automatischer Sichter ist – eine Art EULA (Hinweis, dass alle Bearbeitungen, die an der Wikipedia getätigt werden …) angezeigt werden und drunter die Optionen, ob ich noch konkrete Erinnerungen in Form dieser Boxen möchte oder ob ich es verstanden habe und diese verstecken möchte. -- RE rillke fragen? 14:23, 31. Okt. 2012 (CET)

  1. Ein Ausblenden der juristischen Hinweise durch simplen Klick auf der Einstellungs-Seite ist juristisch extrem heikel.
    • Das kann auch durch irrtümlichen Klick und Herumprobieren auf den Einstellungen und Helferlein passiert sein.
  2. Mittel der Wahl unter den gegenwärtigen Bedingungen ist das individuelle Ausblenden per Benutzer-CSS.
    • Das hinterlässt auf Jahre hinaus Spuren in der Versionsgeschichte und ist zweifelsfrei rekonstruierbar.
    • Es kann auch nachvollzogen werden, dass zwischen dem Zeitpunkt des Ausblendens und dem ersten Edit mehrere Hundert Bearbeitungen gelegen haben, bis man herausgefunden hatte, wie das mit dem CSS geht. Damit ist aber nachweisbar, dass mehrere Hundert Mal die Kisten wahrgenommen werden mussten.
    • Das Gadget-Häkchen hinterlässt allenfalls kurzfristig eine Spur auf dem Server, eigentlich nur seinen momentanen Zustand, und keine History über mehrere Tage oder gar Jahre.
    • Das Bearbeiten von Benutzer-CSS ist eine komplexe aktive Handlung und kann nicht mal eben aus Versehen durch einen Mausklick an der falschen Stelle geschehen sein.
  3. Wie das mit CSS geht, steht unter WP:CSS #edithelps und auch mehr unter WP:CSS #hints.
    • Offenkundig dauert es ein Weilchen, bis man dorthin findet. Das ist auch gut so.
  4. Das Aufteilen in unterschiedliche Boxen (wie auch schon auf enWP) kann man in Absprache mit verantwortlichen Obermacs (Admin-Konsens, B, Stewards?, WMF) durchaus machen, etwa aufgeteilt in Bedienungshinweise und juristische Fragen. Über letztere muss man jedoch aktiv hinwegscrollen, um an den Speichern-Knopf zu gelangen; in der Fußzeile ist es wertlos, und sie müssen zusammen mit dem Speichern-Knopf sichtbar sein.
  5. Eine Lösung mittels Häkchen in einer Zustimmungs-Box müsste dauerhaft (etwa im Benutzer-Logbuch) dokumentiert werden; und dies bedürfte einer weltweit wirksamen Software-Änderung.
VG --PerfektesChaos 20:14, 31. Okt. 2012 (CET)
  1. Dann muss eben sichergestellt werden, dass man nicht "aus Versehen" diesen Haken drückt (z.B. durch die Bitte 2 zufällig generierte Zahlen zu addieren).
  2. Endbenutzerlizenzverträge sind schließlich auch rechtswirksam.
  3. Ich schlage vor:
  • MediaWiki:wikimedia-copyrightwarning erhält 2 Texte: Den kurzen Standardtext (oder noch knapper formuliert) und den längeren aktuellen Text.
  • Per CSS (im HTML style-attribut) wird der kürzere Standardtext ausgeblendet.
  • Beide Texte werden in einen Elternknoten mit individueller Klasse gepackt.
  • Das Gadget würde den langen Text ausblenden und den kürzeren, dennoch rechtlich unbedenklichen Text einblenden.
-- RE rillke fragen? 00:31, 2. Nov. 2012 (CET)

Benutzer:Flominator/Weiterleitungshinweis.js[Bearbeiten]

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)

Ich blicke hier nimmer durch. Wie geht es denn nun weiter? Was muss getan werden? --Flominator 13:15, 21. Apr. 2012 (CEST)

Internal link translator[Bearbeiten]

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[Bearbeiten]

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[Bearbeiten]

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)

Admin-Rechte?[Bearbeiten]

Interessante Aktionen. Ich hätte jetzt Admin-Rechte in diesem NR vermutet? --PerfektesChaos 20:59, 30. Mai 2012 (CEST)

Reedy ist Staff-Member und hat über Globale Gruppe "Staff" das editinterface-Recht. Hoo man gehört zu "Benutzeroberflächenbearbeiter". Hat (technisch) alles seine Richtigkeit, ob Benutzeroberflächenbearbeiter allerdings das machen sollte, kann ich nicht sagen. Bei Staff habe ich kein Problem damit, weil das auch die Serveradmins sind.
Hier scheint der Gadget-Cache leer gelaufen zu sein und ein erneutes Abspeichern der Seite füllt ihn wieder. Ob technisch ein Revert vorher notwendig ist, kann ich nicht sagen. Der Umherirrende 21:10, 30. Mai 2012 (CEST)
<Reedy> hoo: null edit is probably suffice
<Reedy> I remembered before that something didn't work
<Reedy> So blanking provided me with more luls, so I did that ;)
Also wäre Nulledit vermutlich ausreichend. --Steef 389 22:47, 30. Mai 2012 (CEST)
PS: Reedy hat nur einige wenige gefixt und hoo ist dann alle Sprachen durchgegangen.
Na, dann ist ja alles fein. Ich wurde nur misstrauisch, als ein redlink-Benutzer plötzlich diese Seite ändern konnte und befürchtete ein Sicherheitsleck; vielleicht kann man Hoo man in markAdmins ein paar Buchstaben in den Exponenten schreiben? --PerfektesChaos 23:00, 30. Mai 2012 (CEST)
+1. Ein etwas ausführlicherer Editkommentar als „blanking, willrevert“ wäre hilfreich gewesen… -- Bergi 23:07, 30. Mai 2012 (CEST)
Vielleicht könnte man hier mal von Amts wegen ein soft redirect stiften, so wie auf mw:User:Reedy, mit einem Kurzkommentar zum Thema Staff. Dann weiß jeder auf Anhieb, was los ist; en:User:Reedy bringt einen auch nicht viel weiter. --PerfektesChaos 09:24, 31. Mai 2012 (CEST)
Ich hätte mir eher eine Vorlage {{Globale Gruppe|sysadmin/editinterface/staff}} vorgestellt. Verlinkend sowohl auf die Gruppe, die Rechte, die Funktion bei WMF und das Heimatwiki des jeweiligen Nutzers. Hätte das sogar per Bot gemacht, muss aber feststellen dass es kein API-Äquivalent globalusers (filterbar nach globalen Gruppen) gibt? -- Bergi 14:34, 31. Mai 2012 (CEST)
Den Gedanken an Sicherheitsleck hatten andere bei früheren Aktionen auch schon und sehe ich auch als völlig verständlich an, wenn man nicht an die Globalen Gruppen denkt. Die Zuordnung zu "Oberflächenbearbeiter" dürfte aber nur zeitlich befristet sein, müsste man den Antrag mal heraussuchen. CentralAuth ist mager mit API, siehe Bug 16860. Der Umherirrende 16:14, 31. Mai 2012 (CEST)
Befristet bis 22. Juni. Mit Option auf ein weiteres Jahr. Gruß --Steef 389 17:08, 31. Mai 2012 (CEST)
  • Die Idee, bei Vorhandensein einer Benutzerseite und von deWP-Beiträgen durch Globale User mit besonderen Rechten administrativ eine Infobox zu setzen, in der uns die Rechte erläutert werden, fände ich gut.
    • Die paar aktiven staff und developer, für die das erstmal nur interessant ist, werden sich ja wohl notfalls manuell durchgucken lassen.
  • Der Text sollte etwas sein wie
Diese(r) Benutzer(in)GENDER

ist global
für WMF tätig.
Wikimedia-Logo

  • (ggf. Rechte)
  • (natürlich verlinkt mw:/meta:)
  • Aktive staff, sysadmin und developer (coder?) und vergleichbare sowie WMF-Spitze (ggf. ohne Rechte) sollten das Ding bekommen; nicht aber jeder mit einem SUL – und es muss auch nicht jeder Steward, der thailändische oder südamerikanische Angelegenheiten betreut, in der deWP gepflegt werden. Die genaue Funktion ist nachrangig; ergibt sich aus den Rechten und sollte nicht gesondert gepflegt werden müssen.
  • das Heimatwiki des jeweiligen Nutzers – Die Art, wie dies gestaltet wird, bliebe ja dem jeweiligen Benutzer überlassen; das Heimatwiki könnte auch deWP sein, und die Benutzer könnten ja auch eine reguläre Benutzerseite in der deWP haben – Benutzerin:Sue Gardner, Benutzer:Brion VIBBER, der hier hat Seite braucht deshalb keine Infobox; hier sollten wir nur beim momentanen redlink individuell und außerhalb der Infobox ein soft redirect setzen.
  • {{Globaler Benutzer|gender=m|staff=irgendwas|sysadmin=irgendwas|editinterface=irgendwas}} oder ähnlich – übergeordnete Rechte, die andere einschließen, reichen; also auch recht1=staff und fertig.
  • Das Einbinden der Vorlage mag sogar mit MBF bewehrt werden.
  • Raymond als global tätiger developer + Ex-bureaucrat mag in die Umsetzung eingebunden werden.
  • Ich habe überhaupt nichts dagegen, wenn mit dem Zweck des störungsfreien Betriebs globale Berechtigte technische Aktionen wie diese hier zu unserem Besten ausführen.

Schönen Abend --PerfektesChaos 21:14, 31. Mai 2012 (CEST)

Vorschlag für MediaWiki:Gadget-paneMarker.js[Bearbeiten]

Ich möchte das genannte Gadget vorschlagen.

Beschreibungsseite:

Code:

Resource loader:

  • Dependencies: user, mediawiki.util

Liebe Grüße --PerfektesChaos 00:31, 14. Jun. 2012 (CEST)

Das Favicon ist mir einen Tick zu aufdringlich und zumindest bei langsamen Internetverbindungen dauert es ein wenig, bis die Seite vollständig geladen ist und das Favicon getauscht wird. Abgesehen davon ist es eine gute Idee und könnte aktiviert werden. Auf der anderen Seite könnte man auch einfach wieder die Überschrift beim Bearbeiten ändern. Gruß, --Flominator 09:30, 20. Aug. 2012 (CEST)
  • Mit einer langsamen Internet-Verbindung hat dies nichts zu tun; die gesamte Aktion erfolgt lokal im Browser. Mehraufwand besteht im einmaligen Herunterladen des Icons (225 Bytes) und des Gadgets (6,1 kB). Diese beiden stehen dann im Browser-Cache, mindestens bis Sitzungs-Ende, und ihre Größe steht in keinem Verhältnis zum Umfang der Wiki-Seiten.
  • Es besteht auch die Möglichkeit, einen individuellen Icon zu kreieren (etwa W) oder den invertierten Testwiki-favicon.png zu verwenden oder ganz dezent Wikipedia new favicon.png (was sich kaum noch unterscheidet).
mw.libs.paneMarker.opt  =  { faviconICO: "https://secure.wikimedia.org/favicon.ico" };
  • Ich habe heute eine zusätzliche Option eingeführt, die den Favicon unterdrückt, die anderen Features jedoch nutzt. „Zu aufdringlich“ hatte ich noch nicht in meinem Weltbild; alle anderen wünschten sich einen deutlich sichtbaren Hinweis darauf, in welchen Tabs zurzeit ein Bearbeitungsfeld offen ist.
mw.libs.paneMarker.opt  =  { lazy: true };
  • Der alte Zustand führt dann wieder dazu, dass für alle Seiten nur zu lesen ist:

       Wikipedia-favicon.png Bearbeiten vo…   Wikipedia-favicon.png Bearbeiten vo…   Wikipedia-favicon.png Bearbeiten vo…   
Beste Grüße --PerfektesChaos 23:58, 21. Aug. 2012 (CEST)

Symbol support vote.svg Pro Also ich als Langzeitanwender kann sagen dass ich ohne nicht mehr kann (man fühlt sich ohne sprichwörtlich behindert)!!

PerfektesChaos: Könnte man dieses nicht mit jenem kombinieren?? Das würde Sinn machen da dies ebenfalls für Leute mit vielen Tabs gedacht ist. Beste Grüße -- ΠЄΡΉΛΙΟ 22:12, 17. Apr. 2014 (CEST)
paneMarker ist internationalisiert geschrieben.
Das heißt: Kann auch Russisch und Arabisch.
Es werden alle Aliasnamen im Projekt durchsucht, und einer mit möglichst wenigen Buchstaben (bis zu vier) ausgesucht.
Deshalb werden auch WT: und PD: je nach den Gepflogenheiten in der lokalen Schrift und Sprache verwendet.
U: versteht hier keiner. User hat auch nur vier Buchstaben und wird so belassen.
WP: ist in vielen Wikipedien bekannt, aber auf Wikisource irreführend. paneMarker verwendet dort WS: (falls definiert).
Dafür wird BD: genommen.
LG --PerfektesChaos 23:55, 17. Apr. 2014 (CEST)
Ich finde die Resonanz hier etwas traurig (gelinde gesagt). Entweder wirst du, wie schon von anderen vorgeschlagen, zu einer Art Tech-Admin oder man muss sich hier woanders hinwenden. So kann's ja irgendwie nicht gehen hier. User: Perhelion19:51, 2. Jul. 2014 (CEST)

Umstellen auf ResourceLoader[Bearbeiten]

Mit dem ResourceLoader werden JavaScript-Helferlein schneller geladen, indem mehrfache Anfragen zusammengefasst werden und der Code minimiert wird. Bitte alle Gadgets auf den ResourceLoader umstellen, bei denen es dadurch keine Probleme gibt. --Fomafix (Diskussion) 09:03, 20. Jun. 2012 (CEST)

Ja, klingt sinnvoll und ich hatte damit auch schonmal angefangen, aber ich kann nicht bei jedem Gadget beurteilen, ob es unter ResourceLoader auch noch funktioniert und welche Abhängigkeiten sinnvoll sind. Ich möchte hier auch ungerne mit den Benutzern Versuchskaninchen spielen und werde es daher nicht weiter versuchen.
Meine damalige Umstellung bei markAdmins waren Aufgrund eines fehlerhaften Zusammenspiels von FireFox und dem ResourceLoader beispieslweise nicht geglückt. Daher habe ich das nicht weiter verfolgt und lasse lieber den Status Quo, wo ich davon ausgehen kann, das es wohl funktioniert. Der Umherirrende 19:17, 20. Jun. 2012 (CEST)
Auf commons:MediaWiki:Gadgets-definition werden fast alle Gadgets mit dem ResourceLoader geladen. Was für Probleme kann es bei der Umstellung geben? Wie können wir die Gadgets sauber testen? --Fomafix (Diskussion) 20:26, 20. Jun. 2012 (CEST)
Ich denke mal, es kann Abhängigkeitenprobleme geben, wenn die Skripte auf einmal schneller da sind, als sonst und die Seite noch nicht fertig ist. Ich glaube, die JavaScript-Hacker-Community auf Commons ist aktiver und vermutlich auch mehr davon Admins, die das direkt mitmachen, was auch die höhere Anzahl und die niedrigeren Einstiegshürden für Gadgets erklären könnte. Der Umherirrende 20:37, 20. Jun. 2012 (CEST)

Um daraus was Operationales zu machen, schlage ich unter Leitung des Umherirrenden vor:

  1. In diesem Abschnitt für jedes noch-nicht-RL-Gadget eine ====-Überschrift aufzumachen.
  2. Die üblichen Verdächtigen (+ Bergi, Schnark, TSW-Annonce) analysieren den jeweiligen Quellcode und schreiben ihr Denkergebnis auf.
  3. Von welchen Faktoren genau hinge es ab, dass ein Gadget nicht RL-geeignet wäre? Was genau hatte oben Probleme bereitet?
  4. Welche Gadgets erscheinen unproblematisch? Sehen das die anderen auch so?
  5. Bei welchen könnte man eine .using() usw. einbauen, um es fit zu machen?
  6. Sind die ursprünglichen Autoren noch aktiv und könnte man sie einbinden?
  7. Welche Skripte sind einfach zu lang, zu unübersichtlich, zu undokumentiert?
  8. Allgemeine Modernisierung? jQuery, mw? jslint/jshint?
  9. Ggf. in den labs erproben.
  10. Im Lauf der Jahre müssen wir da nach und nach sowieso ran.
  11. Ceterum censeo: In den Kopfbereich jedes Skript-Quellcodes gehören einige Kommentarzeilen, mit denen dokumentiert wird, welche dependencies oder sonstige Voraussetzungen es gibt.

Schönen Abend --PerfektesChaos 22:46, 20. Jun. 2012 (CEST)

Vorschlag für MediaWiki:Gadget-resultListSort.js[Bearbeiten]

Ich möchte das genannte Gadget vorschlagen.

Beschreibungsseite:

Code:

Resource loader:

  • Dependencies: user, mediawiki.util

Auch Einbindung als Link vorstellbar in MediaWiki:Linkshere usw.

Liebe Grüße --PerfektesChaos 20:12, 21. Jul. 2012 (CEST)

Gadget: Wikipedia Redefined[Bearbeiten]

Das Gadget Wikipedia Redefined basiert auf dem kürzlich tierisch gehypten Entwurf. Es ist meiner Meinung nach produktiv bei der Artikelarbeit auf dem Desktop, Notebook und Handy nutzbar. Ich würde damit gerne gleichzeitig eine gut bedienbare Oberfläche anbieten und einer breiteren Autorenschaft zeigen, wie Wikipedia auch aussehen kann. Die ständige Usability-Diskussion und -Kritik kann etwas Bewegung glaube ich ganz gut gebrauchen.

Vorteile gegenüber Vector, Monobook und der App:

  • Automatische Umschaltung auf Touchdisplay-freundliche Version bei entsprechenden Geräten
  • Keine linke Spalte für schmale Browser, auch oben wenig Platzbedarf
  • Selten genutzte Links weniger präsent dargestellt, so dass die wichtigsten Funktionen auffallen
  • Sämtliche Funktionen mobil nutzbar, auch editieren
  • Nix umständlich App installieren und verschiedene Darstellung in App und Webseite haben
  • Deep Links funktionieren immer
  • Geile Optik


Bekannte Probleme:

  • Manche Browser zicken, bitte ggf. melden
  • Gadgets und Userscripts gehen nicht alle, auch hier bei Problemen melden
  • Textarea zum Bearbeiten der Artikel wird in mobilen Browsern oft ungünstig gezoomt

Wikipedia Redefined Screenshot

So müsste der Eintrag auf MediaWiki:Gadgets-definition aussehen: WikipediaRedefined|WikipediaRedefined.css|WikipediaRedefined.js

Dateien auf test.wikipedia.org: Beschreibung, JavaScript, CSS

-- NetAction (Diskussion) 11:39, 2. Sep. 2012 (CEST)

Ist es nicht ein bisschen seltsam, einen Skin als Gadget anzubieten? --Leyo 23:10, 2. Sep. 2012 (CEST)
Aus Benutzersicht absolut. Ein Skin kann aber nur die Foundation mit recht hohem Aufwand installieren. Auch Updates laufen dann nur über ganz wenige Entwickler. Daher sollte das Style erst Anklang und Optimierung in der Community bekommen. Und das geht nur über ein Gadget. -- NetAction (Diskussion) 01:30, 3. Sep. 2012 (CEST)
Nein, die Community der Entwickler, die aktiv etwas an MediaWiki ändern können ist gewachsen, weil mit Gerrit/Git jetzt ein anderer Ansatz verfolgt wird (Siehe mw:Developer access und viele weitere Seiten). Die Entwicklung des Skins wirst du wohl als Extension machen können, ob es aber auf WMF-Wikis aktiviert wird, kann keiner sagen. Der Umherirrende 17:48, 3. Sep. 2012 (CEST)
Wenn man Zugang erhält und möglichst einen Linux/Mac Rechner zur Hand hat, ist das sicher ganz schön. -- RE rillke fragen? 19:04, 5. Okt. 2012 (CEST)
Soweit ich das gelesen habe, erhält jeder Zugang zu Git/Gerrit und Wikimedia Labs. Ich nutze ein Windows-Rechner für meine Commits und komme damit ganz gut zurecht und sehe die Notwendigkeit für ein Linux/Mac Rechner nicht. Der Umherirrende 19:58, 9. Okt. 2012 (CEST)
Nutzt Du die Windows Console direkt, MINGW oder die GUI? Man erhält nur Zugang wenn man sich mit den Lab-Terms and Conditions einverstanden zeigt. Ich mag aber halbfertige Dinge/ oder Tests nicht unter freien Lizenzen veröffentlichen bzw. benötige ich die JSON-Lizenz für bestimmte Werke und die ist nicht OSI approved. "Consequently I don't think I should create an account for you", hieß es sinngemäß in der E-Mail. -- RE rillke fragen? 09:52, 10. Okt. 2012 (CEST)
Als Java-Entwickler nutze ich eclipse mit Erweiterungen (Eclipse EGit und PHP Development Tools (PDT)). Somit habe ich eine GUI mit der ich die Kommandos ausführe. War am Anfang etwas schwierig, die Befehle von den Hilfeseite in den entsprechenden Menüs zu finden. Ein paar Dinge von den Hilfeseiten funktionieren auch nicht oder ich bin unfähig es einzurichten (git-review, braucht man aber auch nicht, da es andere Möglichkeiten gibt). Da ich den Labs Teil im Moment eh nicht nutze, stören mich die Bestimmungen nicht so sehr. Der Umherirrende 19:56, 10. Okt. 2012 (CEST)
Hallo Umherirrender, danke für die Antwort. Eclipse hab' ich mal installiert um Google App Engine zu testen. Mal sehen … -- RE rillke fragen? 22:54, 10. Okt. 2012 (CEST)

Vorschläge[Bearbeiten]

Folgende Skripte schlage ich zur Aufnahme in die Helferlein vor:

--Seth Cohen 18:33, 20. Okt. 2012 (CEST)

Zoom-Voreinstellung mit Koordinaten in Kartenvorschau[Bearbeiten]

Wikipedia:Lagewunsch und der Kartenvorschau (WP:WikiMiniAtlas/de) ergibt sich die Problematik des Zooms. Wird er mehrfach getippt, stoppt der Toolserver (entweder down oder bruteforce-bann). Extrembeispiele sind ein Land auf der Welt oder ein Objekt innerhalb einer Stadt. Frage wie bekommen wir den Zoom mit rüber, ohne das klicken für den ersten Blick erforderlich zu machen? Währe es möglich, die Vorlage Coodinate zu erweitern, dass sie Zoom annimmt und weitergibt? --Hans Haase (Diskussion) 12:09, 31. Okt. 2012 (CET)

Das macht die Vorlage eigentlich automatisch über den type-Parameter, das scheint aber im WikiMiniAtlas nicht zu funktionieren. Wo ein abweichendes Zoomlevel gewünscht wird, geht mit dem Parameter dim, siehe Vorlage:Coordinate#dim. Habe mal den Entwickler um Hilfe gebeten: Benutzer Diskussion:Dschwen#Zoomlevel WikiMiniAtlas. --тнояsтеn 13:16, 31. Okt. 2012 (CET)
Super, dankeschon, das Ergebnis ist in Autobahnkreuz, Autobahnkreuz Oberhausen-West und Anschlussstelle (Autobahn) zu bewundern und ergibt einen gelungenen Größenvergleich. --Hans Haase (Diskussion) 14:29, 31. Okt. 2012 (CET)
Bruteforce-bann gibt es beim Toolserver nicht. Ich kann das stoppen bei mehrfachem tippen des zooms auch nicht reproduzieren. Ich klicke oft vier mal schnell drauf und dann baut sich der angewaehlt zoom auf. Der type parameter wird im WMA abgefragt:
 // Find a sensible Zoom-level based on type
 if( /_type:(airport|edu|pass|landmark|railwaystation)/.test(coord_params) ) {
  zoomlevel = 8;
 } else if( /_type:(event|forest|glacier)/.test(coord_params) ) {
  zoomlevel = 6;
 } else if( /_type:(adm3rd|city|mountain|isle|river|waterbody)/.test(coord_params) ) {
  zoomlevel = 4;
 }
Es schein mir eher, dass die voreingestellten Zoomlevel nicht den Erwartungen der User entsprechen. Achso, adm1st und 2nd sind nicht drin, aber was will man da auch gross erwarten. Soll ich die Defaulteinstellung an Russland oder Liechtenstein anpassen? Grundgedanke war bei der Auswahl des type zoomlevels das Objekt in einem Kontext anzuzeigen. So wie eine Positionskarte eben auch nicht voll das Objekt kartenfuellend anzeigt. Das kann man natuerlich alles nachverhandeln ;-) --Dschwen (Diskussion) 15:33, 31. Okt. 2012 (CET)
Danke ist klar, aber auch s.o. gelöst. Ich habe die entspechenden Artikel per find&replace nachgeflegt. Der Ansatz ist aber dennoch interessant, wobei 'River' ein ähnliches Spektum sein kann. --Hans Haase (Diskussion) 21:05, 31. Okt. 2012 (CET)

Proposal for right edit links[Bearbeiten]

Siehe Gadget: Bearbeiten-Links Rechts, recht kompliziert ich hoffe das ist technisch möglich. - Leider habe ich in beiden vorhergehenden älteren Posts widersprüchliche bzw. halbwahre Angaben gemacht.

PS: Warum gibt es eigentlich nicht einen einzigen Link vom Wikipedia- (oder Hilfe-) Namensraum hierher? -- ΠЄΡΉΛΙʘ 19:55, 1. Nov. 2012 (CET)

  • Auf Hilfe:Einstellungen #Helferlein gibt es ein solches Link; ansonsten wird an diversen Stellen zum Vorschlag aufgefordert. Gemeinhin erfolgt die Publikumsdiskussion eher auf Wikipedia:Helferlein, während sich im MediaWiki-Namensraum die Eingeweihten treffen.
  • Ansonsten müssten die meisten der Monobook-Streithähne sich allmählich beruhigt haben; mir ist das relativ egal.
  • Was mir nicht ganz klar ist, wäre der Umstand, dass es zwei Gadgets gäbe, die sich gegenseitig ausschließen, die man aber beide gleichzeitig anklicken kann. Hier wäre etwas mehr Klarheit und Doku mit Beispielen erforderlich, um dem Vorschlag folgen zu können.
VG --PerfektesChaos 20:29, 1. Nov. 2012 (CET)
Hej, erst mal vielen Dank, dass wenigstens einer darauf eingestiegen ist. Dann habe ich mich mal selbst auf dem Weg der Klarheitsbeschaffung(/Forschungsreise) gemacht (auch im Angesicht dass niemand das(/mich) zu verstehen scheint). Dabei bin ich nach kurzem Test/Suche auf diverse Hacks und falsche Beschriftungen vorgestoßen.
  • Erstmal wird hier MediaWiki:Vector.js (und hier MediaWiki:Monobook.js) der MediaWiki Standard umgebogen. Allerdings ist das genau das was angeblich das MediaWiki:Gadget-editsection-right machen soll
  • Also sind im Prinzip beide Beschreibungen verdreht, denn der vermeintliche Standard (von MediaWiki) wird aktiviert mit MediaWiki:Gadget-editsection-left.js
  • Also müsste die Beschreibung für Option left wie folgt lauten: Bearbeiten-Links Links verschiebt die [Bearbeiten]-Buttons rechts zum Fensterrand. (Was in der Tat eine Pseudo-Beschreibung ist, aber nun mal dem tatsächlichen Endergebnis entspricht) Das Gadget gibt es gar nicht (mehr??)!!!
  • Test Edit: (was ich ebend erst bemerkt habe) ich dachte das Gadget für Left (leider ziemlich störende zweideutige Bezeichnung mit Links Links) ist in der Common.js vorhanden, ist es aber nicht!?!?! Der einzige Unterschied ist dass bei Zweiterer die Links durch MediaWiki:Gadget-editsection-right.css kleiner sind
  • (Zu guter Letzt dann noch ein vermutlich zusammenhängender Fehler MediaWiki:Gadget-Einleitung-bearbeiten.js: (warum allerdings dieses direkt verwandte Script nicht gleich bei den anderen beiden liegt ist mir auch ein Rätsel) Hier ist der Link ganz Links obwohl oldEditsectionLinks = true aktiviert.)
Kannst Du/ihr irgendwas davon nachvollziehen? (Ich habe selbes Bild in aktuellem FF und Chrome) -- ΠЄΡΉΛΙʘ 22:47, 5. Nov. 2012 (CET)
Du gestattest, dass ich mich aus dieser Disku ausklinke. Mir ist das inhaltlich völlig egal, und zu wirr und aus der alten Monobook-Ära, als dass ich mich damit befassen würde. Es gibt eine unbekannte Zahl von Benutzern, die seit Jahren das eine oder das andere oder beide Dinger angeklickt haben, und für die darf sich nichts ändern, sonst gibt es mal wieder Zwergenaufstand. Zu tun gäbe es also eher klarere Doku als Programmierung. LG --PerfektesChaos 23:10, 5. Nov. 2012 (CET)
Ok, zwar schade aber... könntest du wenigstens eine Kurzbeschreibung des Erscheinungsbildes (der 3 möglichen Zustände) bei dir wiedergeben?! Ich habe unter vector.js hierher hingewiesen, daher hoffe ich dass sich bald jemand kundiges meldet. PS.: Gibt es eine Seite für Wikipedia-Parodien? Im Prinzip ist es ganz genau so wie es  ✓ damals beschrieben hat! Also eine Option könnte gelöscht werden (da es ja Links Links anscheinend so oder so nicht (mehr) gibt) Grüße -- ΠЄΡΉΛΙʘ 23:19, 5. Nov. 2012 (CET)
  • Das Erscheinungsbild dürfte Browser-unabhängig sein.
  • Benutzer:Schnark/js/section-links
  • Weil eine unbekannte Anzahl von aktiven Benutzern dieses Zeugs seit langer Zeit angehäkelt hat und allenfalls ServerAdmins herausfinden könnten, wer das überhaupt angeklickt hat, ist eine Änderung an diesen beiden Gadgets kaum möglich; man kann höchstens darauf wetten, wie laut der Proteststurm wird und sie danach entfernen – dann weiß man es.
  • Sollte sich für eines sicher nachweisen lassen, dass es heute funktionslos ist, kann es raus.

LG --PerfektesChaos 10:10, 8. Nov. 2012 (CET)

Siehe auch Wikipedia:Technik/Archiv/Baustellen/editsection. Der Umherirrende 19:00, 9. Nov. 2012 (CET)

Gadget-Direct-link-to-Commons[Bearbeiten]

Hier bitte ein Admin zur Tat schreiten: MediaWiki Diskussion:Gadget-Direct-link-to-Commons.js Seit über einem Monat funzt dieses nicht mehr, daher bitte dortige letzte Kommentare beherzigen. Ansonsten werde ich hier jeden der hier posted zum Admin kandidieren. :D  -- ΠЄΡΉΛΙʘ 21:49, 7. Nov. 2012 (CET)

Wurde der Fehler inzwischen behoben? Notfalls kannst Du auch einen Admin direkt anschreiben. Eine Auswahl findest du hier: Liste der Administratoren. --Cherryx sprich! 00:23, 11. Nov. 2012 (CET)

Wikidata-Einträge anzeigen[Bearbeiten]

Die ungarische Wikipedia hat das Tool Display Wikidata Info on Wikipedia in ihre Liste der Standard-Helferlein aufgenommen. Ich habe bislang durchweg positive Erfahrungen mit ihm gemacht. Da die Sprachlinks in Zukunft zentral von Wikidata gesammelt und verwaltet werden, wird das Interesse an dem Tool vermutlich groß sein. --Kolja21 (Diskussion) 01:06, 15. Jan. 2013 (CET)

Auf der ungarischen Wikipedia ist WikiData seit gestern standardmäßig aktiv, siehe WP:NEU#14. Januar. Der Umherirrende 17:28, 15. Jan. 2013 (CET)
Jup, und am 30. sollen Italienisch und Hebräisch folgen. Hilfreich ist das Tool auch für Admins, die Verschiebereste u.a. Einträge löschen. Ohne einen kurzen Blick auf Wikidata, führen diese Löschungen dort zu Fehlermeldungen. --Kolja21 (Diskussion) 03:04, 25. Jan. 2013 (CET)
  • Also, wenn überhaupt nur als copy des Quellcodes und nicht als „importScriptURI“ auf ein jederzeit änderbares Skript eines unbekannten Benutzers auf einem fremden Projekt, das jetzt vor allem Admins einbinden sollen.
  • Wobei es eigentlich nicht unser (menschliches) Problem ist, wenn durch eine Löschung ein Linkbreak auf Wikidata auftritt; das soll Wikidata gefälligst selbst per Bot herausfinden. Außerdem kann auf Wikidata der Name bis auf Weiteres registriert bleiben, auch wenn der Artikel momentan nicht aktiv ist. Vielleicht wird er wieder unter diesem Titel angelegt; er müsste nur als zurzeit nicht erreichbar markiert sein. Im Wikidata-Konzept kann ich dazu nichts finden.
  • Nicht aus der Doku der Wikidata geht auffindbar hervor, was passiert, wenn die Seite im Inhaltswiki verschoben wurde und noch eine WL existiert. Aktualisieren die sich dann automatisch, per turnusmäßiger Bot-Analyse? Sonst bricht jede Schreibfehlerkorrektur oder unsere beliebte Klammerzusatzkonventionsschubserei dort oder verursacht menschliche Mehrarbeit.
  • Offensichtlich speichert Wikidata auch nur den Titel und nicht die letzte bekannte curid im Zielprojekt. Das wäre allerdings als Rückfallposition sinnvoll, wenn ohne WL verschoben wird. Wird hingegen unter altem Titel die Seite neu angelegt, ist schon der Titel die erste Wahl. Aber das sind Probleme von Wikidata, nicht unsere.

VG --PerfektesChaos 10:30, 25. Jan. 2013 (CET)

Kein Admin wird durch das Gadget gezwungen, irgendwelche Arbeit für Wikidata zu erledigen. Es gibt aber sicherlich mehr Leser und Autoren wie mich, die es schätzen, die Verknüpfung auf einen Blick zu sehen, statt über den Umwegs eines Edit-Buttons, den es bislang nur in der ungarischen Wikipedia gibt, herauszufinden, ob ein Wikidataeintrag zu dem Thema vorliegt. --Kolja21 (Diskussion) 06:02, 26. Jan. 2013 (CET)


  • Du schreibst:
    Hilfreich ist das Tool auch für Admins, die Verschiebereste u.a. Einträge löschen. Ohne einen kurzen Blick auf Wikidata, führen diese Löschungen dort zu Fehlermeldungen.
    Daraus ergibt sich deine Erwartungshaltung, dass in Zukunft alle Admins bei Löschungen und im Zusammenhang mit Verschiebungen einen kurzen Blick auf Wikidata werfen sollen, um dort ggf. manuell Änderungen vorzunehmen und Fehlermeldungen abzuwenden.
  • Eine solche Arbeitstechnik ist strikt abzulehnen.
    • Bislang wurde die Konsistenz der magic interlanguage durch die Interwiki-Bots und ihre menschlichen Betreiber wahrgenommen und automatisiert aktualisiert. Wir haben uns bei der Seitenverwaltung nie darum gekümmert, welche Interlanguages es in anderen Projekten geben könnte.
    • In gleicher Weise hat das Wikidata-Projekt zukünftig die Wartung und Pflege zu übernehmen.
  • Die auf den offiziellen allgemeinen Projektseiten von Wikidata gegebenen Informationen sind äußerst mager. Es wird lediglich das Format des Eintrags beschrieben.
    • Eine Darstellung, auf welche Weise in den folgenden Jahren Wartung, Pflege und zeitnahe Aktualisierung erfolgen soll, ist nicht auffindbar.
    • Insbesondere fehlt eine konkrete Spezifikation der Prozesse und der ausführenden Personenkreise.
  • Ich erwarte von Wikidata, dass turnusmäßig (etwa täglich) alle referenzierten Seiten der Fremdprojekte analysiert werden, ob die Verweise noch aktuell sind.
    • Findet sich eine Weiterleitung, so ist automatisch die neue Zielseite einzutragen.
    • Wird die bezogene Seite nicht (mehr) gefunden, so ist der Eintrag automatisch als zeitweise nicht mehr verfügbar zu markieren.
      • Vielleicht handelte es sich nur um einen Schreib- oder C&P-Fehler bei der Neueintragung.
      • Vielleicht wurde die Seite gelöscht. Dann ließe sich der Seitentitel gleichwohl für eine künftige erneute Anlage unter gleichem Titel oder Wiederherstellung vormerken.
      • Dass die Seite unter diesem Titel gelöscht worden ist, lässt sich kinderleicht automatisch feststellen. Menschliche Ressourcen bei den Projekten dafür aufzuwenden wäre dreist; die Klicks der Admins lassen sich für andere Zwecke besser einsetzen.
      • Intelligent ist es, jeweils automatisch die Seitenkennnummer (curid) gefundener Seiten intern zu hinterlegen; kam es zu einer Verschiebung ohne Weiterleitung, lässt sich die Seite wiederfinden. Wurde nie eine curid gefunden, hat die Seite nie existiert und es gab einen Schreib- oder C&P-Fehler bei der Neueintragung. Die curid hat ausschließlich automatisch im Hintergrund verwaltet zu werden. Kommt es zu einer neu angelegten Seite unter dem bisher bekannten Seitentitel und damit zu einer neuen curid, ist nunmehr diese curid zu hinterlegen. Bei regulärer Verschiebung mit Weiterleitung bliebe die curid ohnehin unverändert.
  • Nur von sehr wenigen Experten benötigte Spezialsoftware bieten wir nicht allgemein als Gadgets an; wenn wir einbinden, dann nur entweder hier vollständig beobachtbaren Quellcode oder aber Importe aus fremden Projekten, deren Bearbeiter uns langjährig bekannt sind.
--PerfektesChaos 10:08, 26. Jan. 2013 (CET)

Es geht hier um ein Schwesterprojekt, das auf der Hauptseite verlinkt ist; kein Grund Panzerabwehrgeschütze aufzufahren. Niemand will dich angreifen oder verknechten. Und was die "wenigen Experten" angeht: Wikidata hat bereits jetzt mehr Einträge als die deutschsprachige Wikipedia und wird demnächst die Sprachlinks zentral verwaltet. Jeder, der Sprachlinks setzt, zählt in Zukunft also zu den Experten. Wenn du ein besseres Gadget für diesen Zweck kennst, können wir gerne auch das nehmen. --Kolja21 (Diskussion) 02:17, 27. Jan. 2013 (CET)

Weiterleitungs-Check[Bearbeiten]

Hallo! Analog zu "Der Begriffsklärungs-Check hebt Links auf Begriffsklärungsseiten farblich hervor." wäre es zumindest zeitweise hilfreich, wenn man einen "Weiterleitungs-Check", der Links auf Weiterleitungen hervorhebt, in den Einstellungen als Helferlein aktivieren könnte. So sieht man bei Bearbeiten/Korrigieren von Seiten sofort, wo eine Seite direkt, wo via Weiterleitung verlinks ist. Manche Weiterleitungen machen Sinn (wird künftige evtl. ein eigener Artikel), manche können aber gleich ausgebessert werden (z. B. WL von veralteten auf gültige Artnamen etc.).

Vorgeschlagene Optik (weniger "aufdringlich" als bei dem BKS-Check - wo IMHO übrigens auch ein schmaler roter Rahmen reichen und ggf. sogar die Lesbarkeit verbessern könnte!): schmaler oranger oder dunkelgelber Rahmen und ein hochgestelltes "WL". Evtl. ist es möglich, mit dem "WL" nicht die Zielseite der Weiterleitung (wie mit dem Linktext), sondern die WL-Seite selbst aufzurufen?

Um Fälle der ersten Art nicht oder anders (blauer Rahmen statt orangem) darstellen zu können, müsste im Quelltext ein entsprechender Marker als "Absichtserklärung" rein (z. B. <wlok>[[Linktext]]</wlok> für "Weiterleitung ok" oder so...). Gibt es irgendwann einen eigenen Artikel unter dem Lemma der bisherigen WL, macht dieser Marker auch nix - für ganz genaue Artikelpflege könnte man den dann wieder anders markieren (grauer Rahmen mit durchgestrichenem WL z. B.), weil der Marker ja dann auch entfernt werden kann (oder ein Bot macht das mal...). --kai.pedia (Dis.) 14:10, 25. Jan. 2013 (CET)

Gibt es schon: WP:CSS #redirect; allerdings zum Selber-in-die-common.css-Schreiben und nicht edel über ein Häkchen in den Einstellungen. In der Farbgestaltung bist du aber dadurch völlig frei.
Liebe Grüße --PerfektesChaos 14:18, 25. Jan. 2013 (CET)
Alternativ auch über importScript('Benutzer:Flominator/BklRedir.js'); in deiner monobook.js, vector.js oder common.js. Vorteil: Es werden auch doppelte Weiterleitungen, Weiterleitungen auf BKLs und Links auf Übersichtsartikel wie Weltausstellung erfasst und gleich das Ziel des Redirs angezeigt. --Flominator 12:19, 24. Feb. 2013 (CET)

Diaschau für Galerien[Bearbeiten]

Genau so etwas hatte ich gesucht - eine Funktion, die aus statischen Galerien mit einem Klick eine Diaschau macht! Dank se4598 hat mir den entscheidenden Tipp gegeben: Auf Commons gibt es das Gadget „Slideshow", das als Helferlein für diese Funktion sorgt. Vielleicht kann man es noch ein wenig eindeutschen. Wie dem auch sei: Unbedingt in die deutsche Wikipedia aufnehmen!!! Gruß --Ökologix (Diskussion) 16:03, 1. Mär. 2013 (CET)

Gibt es jemanden, der hierzu Stellung nehmen möchte? --Ökologix (Diskussion) 19:50, 15. Mär. 2013 (CET)

Helferlein für Spezialseiten[Bearbeiten]

Hallo! Dem Hinweis in Hilfe:Helferlein folgend bringe ich meinen Vorschlag hier ein: kann man die Spezialseiten (z. B. Spezial:Verwaiste_Seiten) und/oder die Helferlein auch so gestalten, dass z. B. die Anzeige von BKL-Seiten auch in den Spezialseiten funzt? Im o. g. Beispiel der verwaisten Seiten wäre das eine große Hilfe: BKL-Seiten können durchaus verweist sein, da diese ja "nur" Sucheingaben besser zuzuordnen helfen sollen... --kai.pedia (Dis.) 13:57, 6. Mär. 2013 (CET)

  • Grundsätzlich wäre das möglich.
  • Das Wikipedia:Helferlein/Begriffsklärungs-Check müsste dazu verändert werden. Es schließt im Moment die Spezialseiten explizit aus (letzte Zeile von MediaWiki:Gadget-bkl-check.js).
  • Dein Wunsch müsste allerdings eine benutzerdefinierte Option werden. Es belastet die Anzeige der Seiten und Benutzer mit magerem Netzwerk-Kontingent, und auf sehr vielen Spezialseiten ist die Abfrage auch wirklich sinnlos.
  • Dazu müsste das ganze Helferlein einmal komplett neu programmiert werden. Es war damals auf der Höhe der Zeit und sehr fortschrittlich; heute gibt es vielerlei, was man anders machen würde (mw.libs, mehr Benutzeroptionen, Namensraum- und Seitenfilter [Disku], „Benutzerin“, mw.Api, jQuery).
  • Nachdem wir uns hier ausgetauscht haben, werde ich diesen Thread auf die Disku des Helferleins kopieren und auch an anderen Stellen Reklame machen.
  • Am Rande bemerkt, ist dies hier die Seite für den Vorschlag komplett neuer Helferlein, aber das macht nichts; wir finden uns schon durch.
  • Einstweilen würden mich mal andere Beispiele von Spezialseiten interessieren, bei denen du das sinnvoll findest. Spezial:Verwaiste Seiten ist ja ganz nett, aber wegen der Beschränkung auf 2000 Seiten nicht so arg im Mittelpunkt des Interesses.
Bis dann --PerfektesChaos 14:28, 6. Mär. 2013 (CET)
Hallo! Danke für die wohlwollende Prüfung/Aufnahme! - wobei neu programmiertes Helferlein ist ja fast schon neues Helferlein :-)
auf Spezial:Älteste_Seiten wäre die Anzeige der BKL auch hilfreich (da ändert sich halt manchmal nix mehr) - aber die ist ja außer Betrieb...
was wohl unabhängig von der Helferlein-Programmierung funzt sind die Markierung von Weiterleitungen 0 das geht auch auf Spzielseiten.
wenn ich Wikipedia:Helferlein/Begriffsklärungs-Check richtig lese, könnte man sich auch irgendwelche Kategorien markieren lassen (nicht nur technische wie BKL und LK) = also z. B. alle Finken (wie Buchfink usw.), d. h. eine thematische Eingrenzung/Hervorhebung vornehmen
sowas suche ich schon lange - für diverese Listen (wie die ungesichteten usw.) - leider gibt es für manchen Themenbereiche kaum suchfreundliche=übergeordnete Kategorien (wie Vogelarten, Pflanzenarten, Tierarten...), denen auch die Einzelartikel zugeordnet sind - anders isses mit "Mann", "Frau" usw. = da würde das gehen, oder? [naja muss vllt. doch in die Helferlein-Dis. gehen?...]
cu --kai.pedia (Dis.) 17:55, 6. Mär. 2013 (CET)
noch ne Seite, BKL-Anzeige gut wäre: auf Spezial:Begriffsklärungsverweise könnte man BKL, die auf BKL verweisen (oft mit siehe auch) überspringen...
was hier gut wäre: wenn man erkennen könnte, ob aus einem BKH heraus auf die BKL gesprungen wird oder aus dem Text heraus = DAS wäre doch was für ein neues Helferlein (oder einen neue Funktion des bestehenden...)? --kai.pedia (Dis.) 18:00, 6. Mär. 2013 (CET)
  • Naja, Spezial:Begriffsklärungsverweise ist wieder so ein Ding, das auf 2000 begrenzt ist, und damit für das praktische Arbeiten unbrauchbar (haben wir im guten sechsstelligen Bereich). Immerhin kurzfristig aktualisiert. Aber überall, wo ein BKH drinsteht, schlägt das auf dieser Spezialseite auf.
  • Diese Spezialseiten kommen aus den Kinderjahren der Wikipedia. Ein kleines oder ganz junges Wiki kann damit was anfangen, wir schon lange nicht mehr.
  • Mit der Aktivität würdest du dir meist keinen Gefallen tun. Wenn du auf Weblinksuche bist, würde das Skript immer durch 500 Ergebnisse graben und ggf. zu jeder Seite beim Server anfragen. Auch, wenn du den Namensraum etwa auf Wikipedia: eingeschränkt hast. Immerhin merkt das Skript das, und fragt den Server dann nicht.
  • Dass ein Link ein Redirect ist, sieht die Datenbanktabelle sofort und liefert diese Info in der HTML-Seite gleich mit. Für BKL usw. fragt das Skript erst blockweise beim Server nach, in welche Kategorien das Link eingeordnet ist.
  • Man könnte bei einer Neuprogrammierung eine Benutzeroption einbauen, dass man in der Werkzeugbox ein Link haben möchte, dass auf dieser normalerweise nicht dafür vorgesehenen Seite eine BKL-Analyse manuell auslöst werden kann; das ist relativ simpel.
  • Im Regelfall sehe ich auf keiner Spezialseite einen Anlass für BKL-Check.
  • Elementar einfach kannst du dir Links auf Namensräume markieren: WP:CSS #Namensräume
  • Kategorien gingen über das Skript; du stellst aber schon richtig fest, dass die Zielseiten nicht alle in der Kategorie „Finken“ stehen, sondern bei Buchfinken, Heftfinken, Schmutzfinken.
Schönen Abend --PerfektesChaos 21:52, 7. Mär. 2013 (CET)

Bearbeiten-Links[Bearbeiten]

Hat jemand auf dem Schirm, dass sich laut Meta ab dem 8. Mai

  1. die Standardposition der Bearbeiten-Links ändert (sie befinden sich dann direkt rechts neben den Überschriften) und
  2. sich der Klassenname des beinhaltenden <span>s ändert (statt class="editsection" in Zukunft class="mw-editsection").

D.h. das Gadget Bearbeiten-Links Links muss angepasst werden und Bearbeiten-Links Rechts wird überflüssig (da Standard) sollte jedoch durch ein Gadget ersetzt werden, dass den bisherigen Standard wiederherstellt (Bearbeiten-Links rechts am Fensterrand).

Der neue CSS-Code wird dafür jedoch denkbar einfach (Beispiel zum Wiederherstellen des bisherigen Standards, kopiert von Meta):

.ltr .mw-editsection {
  float: right;
}
.rtl .mw-editsection {
  float: left;
}


P.S. Irgendwas scheint auch bereits im Gange zu sein, denn die Barbeiten-Links werden bereits direkt rechts neben den Überschriften angezeigt. Die Mediawiki-Software ist aber definitiv noch nicht aktualisiert, scheint also an anderer Stelle jemand die Finger im Spiel zu haben. --Patrick87 (Diskussion) 01:11, 3. Mai 2013 (CEST)

Hat jemand.
Trotzdem danke fürs Mitdenken und Erinnern, könnte ja auch mal untergegangen sein.
VG --PerfektesChaos 09:21, 3. Mai 2013 (CEST)

Typografie.js[Bearbeiten]

Von einem anderen Benutzer wurde mir geraten, mein Helferlein zur automatischen Umwandlung von Anführungszeichen, Gedankenstrichen, Auslassungspunkten etc. in die typografisch korrekte Version beim Eingeben hier vorzuschlagen. Das tue ich hiermit; das Skript ist zu finden unter Benutzer:Jowereit/Typografie. Jowereit (typografie.js) 21:04, 14. Jul. 2013 (CEST)

Ehrlich gesagt, wäre es mir lieber, wenn es „dein“ Benutzerskript bliebe.
Liebe Grüße --PerfektesChaos 20:47, 18. Jul. 2013 (CEST)
Meiner Ansicht nach sollte das Skript in ein Eingebeschema für ULS umgewandelt und direkt in MediaWiki aufgenommen werden. Dies hätte folgende Vorteile:
  • Es würde wesentlich kürzer, da nur die Ersetzungsregeln definiert werden müssen, nicht die Funktionen für die Cursorposition etc.
  • Falls/sobald ULS mit VE kompatibel ist (was Aufgabe der entsprechenden Entwickler ist), wird es automatisch in VE funktionieren, gleiches gilt für WikEd.
  • Das Ein- und Ausschalten wäre konsistenter.
  • Es wäre noch leichter zu aktivieren als durch ein Gadget.
Nachteile sind:
  • Konfiguration durch globale Variablen ist nicht möglich.
  • Kompatibilität mit WikEd geht erst einmal verloren.
  • Funktionen, die mit markiertem Text arbeiten, funktionieren nicht mehr.
  • Solange es nicht offizieller Bestandteil von ULS ist, ist es extrem eklig zu testen.
Wie dem auch sei, hier ein schneller Versuch:
( function ( $ ) {
	'use strict';
 
	var de = {
		id: 'de-typographic',
		name: 'Typografie für Deutsch',
		description: 'input method for typographic characters in German',
		date: '2013-07-18',
		URL: 'https://de.wikipedia.org/wiki/Benutzer:Jowereit/Typografie',
		author: 'Benutzer:Jowereit, Benutzer:Schnark',
		license: 'CC-by-sa 3.0',
		version: '1.0',
		maxKeyLength: 1000000,
		patterns: function ( text ) {
			var lastChar = text.charAt( text.length - 1 ), nextToLastChar = text.charAt( text.length - 2 );
			switch ( lastChar ) {
			case '"':
				if ( nextToLastChar === '=' || text.lastIndexOf( '="' ) > text.lastIndexOf( '>' ) || text.lastIndexOf( '="' ) > text.lastIndexOf( '|}' ) ) {
					return text;
				} else if ( '\n ([{|'.indexOf( nextToLastChar ) > -1 ) {
					if ( text.lastIndexOf( '„' ) > text.lastIndexOf( '“' ) ) {
						return text.substring( 0, text.length - 1 ) + '‚';
					} else {
						return text.substring( 0, text.length - 1 ) + '„';
					}
				} else {
					if ( '0123456789'.indexOf( nextToLastChar ) > -1 && text.lastIndexOf( '„' ) <= text.lastIndexOf( '“' ) ) {
						return text.substring( 0, text.length - 1 ) + '″';
					} else if ( text.lastIndexOf( '‚' ) > text.lastIndexOf( '‘' ) ) {
						return text.substring( 0, text.length - 1 ) + '‘';
					} else {
						return text.substring( 0, text.length - 1 ) + '“';
					}
				}
				break;
			case '-':
				if ( nextToLastChar === '–' ) {
					return text.substring( 0, text.length - 2 ) + '---';
				} else if ( nextToLastChar === '-' && text.charAt( text.length - 3 ) !== '-' && text.charAt( text.length - 3 ) !== '!' ) {
					return text.substring( 0, text.length - 2 ) + '–';
				}
				break;
			case '.':
				if ( nextToLastChar === '.' && text.charAt( text.length - 3 ) === '.' ) {
					return text.substring( 0, text.length - 3 ) + '…';
				}
				break;
			case '\'':
				if ( nextToLastChar === '’' || nextToLastChar === '′' ) {
					return text.substring( 0, text.length - 2 ) + '\'\'';
				} else if ( '0123456789'.indexOf( nextToLastChar ) > -1 ) {
					return text.substring( 0, text.length - 1 ) + '′';
				} else if ( nextToLastChar !== '\'' ) {
					return text.substring( 0, text.length - 1 ) + '’';
				}
				break;
			case '>':
				if ( nextToLastChar === '–' ) {
					return text.substring( 0, text.length - 2 ) + '-->';
				}
			}
			return text;
		}
	};
 
	$.ime.register( de );
 
}( jQuery ) );
 
jQuery.ime.languages.de.inputmethods.push( 'de-typographic' );
jQuery.ime.sources['de-typographic'] = {
	name: 'Deutsch (Typografie)',
	source: 'rules/ml/ml-transliteration.js' //DUMMY
};
Zum Testen:
  1. In den Editmodus gehen, als Sprache des Eingabefeldes Englisch auswählen (oder irgendetwas anderes als Deutsch).
  2. Die JavaScript-Konsole des Browsers aufrufen und den obigen Code ausführen. (In Firefox Umschalt+F4, Code einfügen, Strg+R)
  3. Als Sprache wieder Deutsch und Typographie als Eingabeschema wählen.
  4. Testen
  5. Eingabeschema wieder ausschalten.
--Schnark 09:34, 19. Jul. 2013 (CEST)

old-diff-style.css[Bearbeiten]

„Stellt Versionsunterschiede in den bisherigen Farben dar“

Ich bitte darum, dass diese Beschreibung aussagekräftiger wird. Meines Erachtens gab es in den letzten sieben Jahren immer wieder mal Änderungen bezüglich der Farben, zum Teil foundationübergreifend, manchmal auch nur lokal oder skinabhängig. Ich habe mir schon vor Jahren andere Farben verpasst, so dass ich mich jedesmal frage: Welche sind eigentlich die bisherigen Farben? -- 32X 10:35, 4. Nov. 2013 (CET)

Wo ist das Problem? Zielgruppe dieses Gadgets sind genau die Benutzer, die bei der Umstellung, zu der es eingeführt wurde, laut geschrien haben: "Wir wollen die bisherigen Farben zurück!" Wer nicht weiß, was mit den alten Farben gemeint ist, der braucht das Gadget nicht.
Das ist natürlich an sich kein Grund, dass die Beschreibung tatsächlich suboptimal ist, aber die Qualität unserer Gadgets ist so miserabel, dass es auf eine schlechte Beschreibung mehr oder weniger nun wirklich nicht ankommt. --Schnark 10:39, 4. Nov. 2013 (CET)
Wo das Problem ist? Auf Spezial:Einstellungen#mw-prefsection-gadgets wird mir eine Option mit nichtssagender Beschreibung angeboten. Mit jeder unkonkreten Beschreibung mehr vermüllt die Seite und hilfreiche Gadgets werden schwieriger auffindbar. -- 32X 12:17, 4. Nov. 2013 (CET)
Hilfreiche Gadgets – sehr guter Witz. (SCNR) --Schnark 12:23, 4. Nov. 2013 (CET)
Warum ist Benutzer:Schnark eigentlich kein Administrator hier auf de? Dann könnte mal jemand ein bisschen Bewegung in die Gadget-Landschaft bringen. Auf Commons – und dort gibt es wegen mangelden Multimedia-Supports in MediaWiki wesentlich mehr Gadgets – sind beispielsweise >90% der Gadgets auf ResourceLoader umgestellt. Das erfordert jedoch ausgiebiges Testen und Anpassen "fremden" Codes. Hier hat wohl kein Admin Lust darauf. Ferner fehlt eigentlich überall ein "Try it", mit dem der Nutzer die Gadgets gleich austesten kann, Nutzungsstatistiken und Angaben, wann ein Gadget das letzte Mal aktualisiert wurde und deren Einfluss auf das Ladeverhalten der Seite, sowohl objektiv als auch durch Nutzerbewertungen, übersichtlich in einer Tabelle angeordnet und ein "Did you know?" das über hilfreiche, aber eher unbekannte Gadgets cross-wiki-wise informiert, sowie einem System, das Benutzeraktionen auswertet und darauf basierend Vorschläge macht. -- RE rillke fragen? 13:01, 4. Nov. 2013 (CET)
Dann könnte ich nicht mehr über die Gadgets meckern … --Schnark 09:13, 5. Nov. 2013 (CET)
Dafür könntest Du über Deine Kollegen herziehen und über die "kleinen" Benutzer. -- RE rillke fragen? 15:47, 6. Nov. 2013 (CET)
„Stellt Versionsunterschiede in den bisherigen Farben, Rot und Grün, dar“ -- RE rillke fragen? 13:01, 4. Nov. 2013 (CET)
Nicht, dass ich etwas gegen diesen Vorschlag hätte, aber ich sehe im Gegensatz zu 32X noch immer nicht den Grund, warum alle Benutzer alle Beschreibungen verstehen müssen. Wer eine Beschreibung nicht versteht, der wird doch wohl einfach das so beschriebene Gadget nicht aktivieren, und das ist hier genau das erwünschte Verhalten. Und wenn es wirklich Benutzer geben sollte, die bei der ersten unverständlichen Beschreibung die Seite mit den Gadgets wieder schließen, dann kommen die über „Zeigt die Beiträge von 16er und 24–32er CIDR-Ranges und Wildcardbenutzernamen wie „Splark*“ an.“ gar nicht erst hinaus. --Schnark 09:13, 5. Nov. 2013 (CET)
„Stellt Versionsunterschiede in rot und grün dar“. Wo ist das Problem, dass man da überhaupt drüber diskutieren muss? --TMg 01:18, 6. Nov. 2013 (CET)
Ich glaube, was Schnark möchte ist, dass das Gadget möglichst wenig benutzt wird um es alsbald wieder entfernen zu können. Ob ein Gadget überhaupt der richtige Weg war, wage ich zu bezweifeln. Damit haben wir den Benutzer-Frust von den MW-Entwicklern weggenommen und auf uns geladen, denn der wird sich entladen, sobald das Gadget abgeschaltet wird. -- RE rillke fragen? 15:47, 6. Nov. 2013 (CET)
Ach so, stimmt auch wieder. Die Vorgehensweise finde ich gut. Auf diese Weise wird die Community schrittweise an Neuerungen heran geführt und wir müssen nicht auf einen Schlag 100 % der Benutzer überzeugen. Der nächste Schritt wäre dann wirklich, das Gadget zu entfernen und den immer noch nicht überzeugten Benutzern zu zeigen, wie sie es auf dem Weg über ihr Benutzer-CSS trotzdem noch haben können. Ist irgendwo einsehbar, wie viele Benutzer die Gadgets benutzen? --TMg 11:40, 7. Nov. 2013 (CET)
  1. Nutzung
    • Ja, man kann einmal jährlich bei den Serveradmins eine Statistik bestellen, wer die Option in den Einstellungen hat.
    • Wir haben auch eine, ich hab aber vergessen wo.
    • Die Daten sind allerdings kaum brauchbar, weil auch alle verstorbenen und aus sonstigen Gründen inaktiven Benutzer erfasst sind, und so gut wie Null ist nach meiner Erinnerung kein Gadget angekreuzelt.
    • Wie viele Leute etwas aktiv nutzen, ist nicht bekannt; dazu bräuchte man die Abruffrequenz des Gadget-Codes aus dem letzten Monat.
  2. Legacy
    • Nicht jeder Autor ist scharf auf die allerneuesten buntesten Super-Features, sondern möchte einfach nur in der vertrauten Arbeitsumgebung Artikel schreiben.
    • So lange technisch problemlos unterstützbar, sollte man die Gewohnheiten der Altgedienten nicht umschmeißen.
    • Es sind die Menschen auch unterschiedlich geistig flexibel und mit Skins und Einstellungen vertraut.
    • Wer neu dazukommt, lernt nur den neuen Stil kennen und weiß nichts von den alten Gegebenheiten. Dann muss auch weder das Gadget noch seine Beschreibung verstanden werden.
    • Nach mehreren Jahren sind viele von denen, die das noch von früher (vorm Krieg) kennen, aus unterschiedlichen Gründen nicht mehr dabei; die anderen sind nun schon so viele Jahre dabei, dass etwas Einrichtung in den MyPages allmählich doch zumutbar wäre. Aber gerade unter denen sind auch viele, die bei jeder Gelegenheit lautstark fordern, dass die WP zu Design, Funktionalität, Struktur von 2005 zurückzukehren habe, und monobook muss auch wieder Standard werden.
    • Für das Rot-Grün-Dings ist es zurzeit noch etwas früh; es stört auch nicht, wenn das da rumsteht. So viele Gadgets bieten wir ja auch nicht an.
  3. Namensgebung
    • Jeder Name mit old, new, erweitert, Zusatz, Extra, klassisch als sinntragendem Unterscheidungsmerkmal ist Schrott.
Schönen Tag --PerfektesChaos 13:08, 7. Nov. 2013 (CET)

Zur Statistik: Es stimmt nicht, dass man nur einmal jährlich eine Statistik von Serveradmins bekommen kann. Auf dem Toolserver sind die Einstellungen anonymisiert zu finden. Ein wenig schwierig ist es durch die automatisch aktivierten Gadgets, dafür müsste man entsprechend eine Liste machen, wie oft sie deaktiviert wurden. Die Daten sehen derzeit wie folgt aus (wobei auch entfernte Gadgets da noch Datenleichen nach sich ziehen):

mysql> SELECT up_property, count(*) AS c FROM user_properties_anonym WHERE up_property LIKE 'gadget-%' AND up_value='1' GROUP BY up_property ORDER BY c DESC LIMIT 0,100;
+------------------------------------------------+-------+
| up_property                                    | c     |
+------------------------------------------------+-------+
| gadget-Rechtschreibpruefung                    | 11739 |
| gadget-Extra-Editbuttons                       | 10087 |
| gadget-toolserver-integration                  |  8020 |
| gadget-Vorlagenmeister                         |  7515 |
| gadget-bkl-check                               |  7198 |
| gadget-HotCat                                  |  6855 |
| gadget-wikEd                                   |  6699 |
| gadget-Einleitung-bearbeiten                   |  6182 |
| gadget-navigation-popups                       |  5913 |
| gadget-Suchfokus-Hauptseite                    |  4400 |
| gadget-Pfeil-hoch                              |  3805 |
| gadget-Personendaten                           |  2728 |
| gadget-WikiMiniAtlas                           |  2574 |
| gadget-PB                                      |  2207 |
| gadget-markAdmins                              |  2088 |
| gadget-revisionjumper                          |  2002 |
| gadget-revisionCounter                         |  1763 |
| gadget-contribsrange                           |  1572 |
| gadget-Rot-Gruen-Sehschwaeche                  |  1187 |
| gadget-Zeitzonenkonverter                      |  1143 |
| gadget-Doppel-s-Schreibung                     |  1010 |
| gadget-ReferenceTooltips                       |   988 |
| gadget-OpenStreetMap                           |   979 |
| gadget-editsection-right                       |   825 |
| gadget-Screenreader-Optimierung                |   801 |
| gadget-PrettyLog                               |   592 |
| gadget-imagesiblings                           |   494 |
| gadget-Persoenliche-Bekanntschaf               |   370 |
| gadget-rightsfilter                            |   364 |
| gadget-PermaPageLink                           |   290 |
| gadget-editsection-left                        |   281 |
| gadget-old-diff-style                          |   224 |
| gadget-articlefeedback                         |   213 |
| gadget-Erweiterte-Navigationsleiste-Quicklinks |   211 |
| gadget-HideVisualEditor                        |   120 |
| gadget-editsection-align-end                   |   102 |
| gadget-highlightemptysummary                   |    34 |
| gadget-TAXman-tool                             |    27 |
| gadget-InlineInterwikisInGruen                 |    15 |
| gadget-Gadgets-InlineInterwikisI               |     9 |
| gadget-Gadgets-Personendaten                   |     4 |
| gadget-InterwikisInGruen                       |     2 |
| gadget-CommonsDirekt                           |     1 |
| gadget-Quicklinks                              |     1 |
+------------------------------------------------+-------+
44 rows in set (8.56 sec)

Eine Statistik, wieviele _aktive_ Nutzer welche Gadgets aktiviert haben könnte wiederum wirklich nur ein Serveradmin erstellen. Grüße --APPER\☺☹ 23:46, 7. Nov. 2013 (CET)

Soll ich jetzt wirklich glauben, dass ich der einzige bin, der gadget-CommonsDirekt (MediaWiki:Gadget-Direct-link-to-Commons.js) aktiviert hat? Oder stimmt was mit deiner Abfrage nicht? --Patrick87 (Diskussion) 23:57, 7. Nov. 2013 (CET)
Also ich hab da auch seit Jahr und Tag einen Haken drin :) --тнояsтеn 08:36, 8. Nov. 2013 (CET)
Da das Gadget als Standard für alle Benutzer aktiviert ist, sollte eigentlich kein Benutzer dieses Gadget laut Datenbank aktiviert haben (so wie das auch für gadget-old-movepage der Fall ist), der eine Benutzer hat das Gadget wohl ganz am Anfang, wie es noch kein Standard war, aktiviert und seitdem nichts mehr an seinen Einstellungen verändert. Bei den beiden Gadgets wäre dagegen interessant, wie viele sie deaktiviert haben. (Ich kann versicheern, es ist jeweils mindestens ein Benutzer.) --Schnark 09:28, 8. Nov. 2013 (CET)
Wie in meiner Einleitung geschrieben funktioniert diese Abfrage nicht für standardmäßig aktivierte Gadgets. Dort muss man zählen, wieviele es deaktiviert haben. Also das noch nachgereicht. Die Werte sind sehr merkwürdig... vllt kennt sich ja jemand mit der Datenbankstruktur aus. Dass 2728 Personendaten einblenden, aber 45846 sie bewusst ausblenden, kommt mir merkwürdig vor. Es gibt aber viele im Bereich zwischen 40000 und 45000, ich tippe darauf, dass ein "0"-Eintrag gemacht wird, wenn man ein anderes Gadget an- oder ausschaltet. Und bei den Personendaten sind es die meisten, weil es eines der ältesten Gadgets ist. Zeigt aber auch, wie hoch die Anzahl derjenigen ist, die bereits jemals sich auf die Gadget-Einstellungsseite verirrt haben und etwas geändert haben.
mysql> SELECT up_property, count(*) AS c FROM user_properties_anonym WHERE up_property LIKE 'gadget-%' AND up_value!='1' GROUP BY up_property ORDER BY c DESC LIMIT 0,100;
+----------------------------------+-------+
| up_property                      | c     |
+----------------------------------+-------+
| gadget-Personendaten             | 45846 |
| gadget-Doppel-s-Schreibung       | 45399 |
| gadget-Screenreader-Optimierung  | 45048 |
| gadget-Rot-Gruen-Sehschwaeche    | 44955 |
| gadget-navigation-popups         | 44350 |
| gadget-toolserver-integration    | 44038 |
| gadget-HotCat                    | 43938 |
| gadget-Vorlagenmeister           | 43729 |
| gadget-wikEd                     | 43607 |
| gadget-Einleitung-bearbeiten     | 43406 |
| gadget-Pfeil-hoch                | 43197 |
| gadget-Extra-Editbuttons         | 43003 |
| gadget-Rechtschreibpruefung      | 42280 |
| gadget-WikiMiniAtlas             | 41310 |
| gadget-Suchfokus-Hauptseite      | 33502 |
| gadget-bkl-check                 | 31917 |
| gadget-contribsrange             | 24169 |
| gadget-Persoenliche-Bekanntschaf | 20743 |
| gadget-revisionjumper            | 10518 |
| gadget-OpenStreetMap             |  7527 |
| gadget-TAXman-tool               |  2253 |
| gadget-InlineInterwikisInGruen   |   349 |
| gadget-old-movepage              |   324 |
| gadget-CommonsDirekt             |   151 |
| gadget-Gadgets-Personendaten     |   121 |
| gadget-Gadgets-InlineInterwikisI |   116 |
| gadget-InterwikisInGruen         |    11 |
| gadget-gadgets-InlineInterwikisI |     3 |
| gadget-gadgets-Personendaten     |     3 |
| gadget-CleanDeleteReasons        |     2 |
| gadget-inlineInterwikisInGruen   |     1 |
| gadget-personendaten             |     1 |
+----------------------------------+-------+
32 rows in set (31.66 sec)

Grüße --APPER\☺☹ 14:23, 8. Nov. 2013 (CET)

Ist denn gesichert, dass !='1' gleichbedeutend mit ='0' ist? Ich traue MediaWiki durchaus zu, dass ein aktiviertes Gadget je nach Lust und Laune als 1, true oder 42 gespeichert wird, und dann auch noch funktioniert. --Schnark 09:29, 9. Nov. 2013 (CET)
Alles was in der Datenbank ist und für php true ergibt, ist eine aktive Einstellung ("truthy"). Ein Überblick könnte man sich über:
SELECT up_property, up_value, count(*) AS c
  FROM user_properties_anonym
 WHERE up_property LIKE 'gadget-%'
 GROUP BY up_property, up_value ORDER BY c DESC 
verschaffen. Früher war es so, das für jedes Gadget eine Zeile in der Datenbank gespeichert wurde, daher sind einige der alten Gadgets mit so vielen Einträgen vorhanden. Wenn ein solcher Benutzer die Einstellungen jetzt ändern und speichern würde, sollte sich das ganze selber bereinigen, da nur die Abweichungen zum Default gespeichert werden. Ob allerdings alte, nicht mehr vorhandene Gadgets auch aus dem Einstellungen fliegen, weiß ich nicht. Der Umherirrende 09:44, 9. Nov. 2013 (CET)
Gadget Standard = 1 ≠ 1
bkl-check 7198 31917
CommonsDirekt ja 1 151
contribsrange 1572 24169
Doppel-s-Schreibung 1010 45399
Einleitung-bearbeiten 6182 43406
Erweiterte-Navigationsleiste-Quicklinks 211
Extra-Editbuttons 10087 43003
HotCat 6855 43938
imagesiblings 494
markAdmins 2088
navigation-popups 5913 44350
old-diff-style 224
old-movepage ja 324
PB 2207
PermaPageLink 290
Personendaten 2728 45846
Pfeil-hoch 3805 43197
PrettyLog 592
Rechtschreibpruefung 11739 42280
ReferenceTooltips 988
revisionCounter 1763
revisionjumper 2002 10518
rightsfilter 364
Rot-Gruen-Sehschwaeche 1187 44955
Screenreader-Optimierung 801 45048
Suchfokus-Hauptseite 4400 33502
toolserver-integration 8020 44038
Vorlagenmeister 7515 43729
wikEd 6699 43607
WikiMiniAtlas ja 2574 41310
Zeitzonenkonverter 1143
Fazit:

Dreieinhalb Monate und 18 Kilobyte später hat sich *N*I*C*H*T*S* verändert. Klasse. -- 32X 20:07, 15. Feb. 2014 (CET)

Vorschlag für neues Gadget: projectNotice[Bearbeiten]

Wikipedia:Technik/Baustellen/projectNotice mit der Bitte um Unterstützung. Schönes Wochenende --PerfektesChaos 17:23, 30. Nov. 2013 (CET)

Symbol support vote.svg Pro Hört sich super an! Ich benutze schon lange mit Bewunderung die Variante von "fliegelfagel". -- ΠЄΡΉΛΙΟ 22:18, 17. Apr. 2014 (CEST)

UTC Zeit mit Purge-Funktion[Bearbeiten]

Auf commons:, w:en:, meta und mw: gibt es Azatoths UTCliveclock mit Purge-Funktion. Auch nett: Sandkisten-Link auf w:en:. –Be..anyone (Diskussion) 12:18, 18. Feb. 2014 (CET)

Vorschlag Syntax-Highlighter[Bearbeiten]

Besteht bereits seit nun fast 2 Jahren in der enWP als Gadget. Ich benutze es ebenso lange, ich kann es mir gar nicht mehr wegdenken. (Anfragen au gibt es auch immer wieder) Bitte einfügen.Remember the dot/Syntax highlighter -- ΠЄΡΉΛΙΟ 19:39, 17. Apr. 2014 (CEST)

Ja, war eines der ersten Benutzerskripts die ich mir zugelegt habe. Vergleicht man was sonst alles als Gadget angeboten wird, hätte der Syntax-Higlighter auf jeden Fall einen Platz verdient. Insbesondere funktioniert er in allen Wikimedia-Projekten einwandfrei und wird (falls doch mal irgendein Problemchen auftritt) von User:Remember the dot perfekt supportet. --Patrick87 (Diskussion) 20:01, 17. Apr. 2014 (CEST)
Verwende hier dieses Skript: Benutzer:Schnark/js/syntaxhighlight.js. Ist wohl ziemlich ähnlich und als Gadget ist eine Syntaxhervorhebung nur zu befürworten. --тнояsтеn 18:48, 20. Apr. 2014 (CEST)
Sehe gerade auf Benutzer:Schnark/js/syntaxhighlight, dass das Skript von User:Remember the dot diesem zugrunde liegt. --тнояsтеn 18:49, 20. Apr. 2014 (CEST)
Soweit ich weiß, ist der Hauptunterschied von Schnarks Version, dass diese auch Highlighting von JavaScript/CSS unterstützt. Da es mittlerweile den auf „Ace“ basierenden CodeEditor gibt, ist diese Funkionalität jedoch nicht mehr nötig. Grundsätzlich sollte die Version von Rmember the dot für normalen Wikitext dann besser funktionieren. --Patrick87 (Diskussion) 01:33, 21. Apr. 2014 (CEST)
@Schnark: (ist seit Anfang des Jahres inaktiv) Richtig diese Version kommt eher nicht Frage, mir sind ebenfalls ein paar Ungereimtheiten bei seiner Version aufgefallen (welche ich kurz auf seiner Diss. dargelegt habe, was es für mich unbenutzbar macht), von der er ja selber (vor über einem Jahr) sagt, dass dieses mehr Bugs als das Original besitzen könnte. -- ΠЄΡΉΛΙΟ 20:47, 21. Apr. 2014 (CEST)
Wäre es entgegenkommend, wenn eine deutsche Beschreibung vorhanden wäre? Der Autor hat mich freundlichst gebeten eine deutsche Übersetzung seiner Beschreibung umzusetzen. Kann jemand dabei behilflich sein? Eine Kurzbeschreibung gibt es bereits (einen deutschen Text hat er ebenfalls bereits im Script aufgenommen). Der Support ist auch aus meiner Sicht erstklassig (wie oben schon erwähnt), ich hatte bereits 3 Kompatibilitäts-Probleme gemeldet die alle jeweils am selben Tag umgesetzt wurden! (PS: Schnarks Version, ist ebenfalls sehr gut, mit seinen Vorzügen, allerdings zu wenig getestet.) User: Perhelion19:31, 2. Jul. 2014 (CEST)