MediaWiki Diskussion:Gadgets-definition/Archiv 2012

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[MediaWiki Diskussion:Gadgets-definition/Archiv 2012#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/MediaWiki_Diskussion:Gadgets-definition/Archiv_2012#Thema_1

Abhängigkeiten von mw.util deklarieren

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

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

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

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

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

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

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

Sollte im Moment alles passen. Sonst bitte einzelne Abschnitte bei den Gadgets. Danke. Der Umherirrende 20:01, 9. Okt. 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 20:01, 9. Okt. 2012 (CEST)

AceEditor

Es gibt zwei interessante Erweiterungen, die ich gerne vorschlagen würde. Sie basieren beide auf dem Ace (Texteditor) und könnten sich Code teilen.

CodeEditor

mw:Extension:CodeEditor von Brion Vibber ermöglicht Echtzeit-Syntaxhervorhebung im Bearbeitungsfeld für CSS und JavaScript. Ist also für Entwickler von Wikipedia:Helferlein interessant.

WikiEditor

Den Wikipedia:Technik/AceWikiEditor habe ich aus der norwegischen Wikipedia / Github kopiert und übersetzt. Es handelt sich um einen Fork des CodeEditors, der Wiki-Syntax in Artikeln hervorhebt.

Gruß Matthias (Diskussion) 15:34, 5. Okt. 2012 (CEST)

• Es wäre nett, wenn du die Vorteile eines zusätzlichen Skriptes gegenüber WP:WikEd herausarbeiten würdest. (Ich sag ja nicht, dass ich mir keine vorstellen könnte.)
  • Insbesondere ist eine Information entsprechend Wikipedia:Technik/Skin/JS/wikEd #Synchronisation erforderlich, damit alle anderen Skripte, die mit $('#wpTextbox1').val() arbeiten, sich mit einem weiteren Werkzeug synchronisieren können.
• Für Hinweise zum weiteren Vorgehen siehe auch Wikipedia:Technik/Skin/JS #Benutzerskript ./. Gadget.
• Ich denke, dass eine solch komplexe Aufgabe eine längere Entwicklungs- und Erprobungsphase erfordert, bis sie stabil unter administrativen Schutz gestellt werden könnte.
• Da du das ja offenbar ausarbeiten möchtest, stelle doch bitte auf deinen Benutzerseiten eine entsprechende Suite aus Doku, Code und externen Ressourcen zusammen.

Viel Spaß dabei --PerfektesChaos 16:14, 5. Okt. 2012 (CEST)

Die Extension wird mittelfristig im Rahmen der Einführung der Skriptsprache Lua auch hier aktiviert werden. Im MediaWiki-Wiki ist die Funktion für den Namensraum Module schon aktiv: mw:Module:Table demo. Einfach mal auf Bearbeiten klicken und staunen :-) — Raymond ^Disk. 16:31, 5. Okt. 2012 (CEST)

Raymond, woher schöpfst Du all diese Weisheiten? Gibt es da eine Seite von der ich nichts weiß? Auf mw:MediaWiki talk:Gadget-CodeEditor.js ist ja keine Antwort zu haben. -- RE rillke fragen? 18:58, 5. Okt. 2012 (CEST)

Ich glaube ehrlich gesagt bin ich mit der Weiterentwicklung des Skriptes überfordert. Nutzes es selbst auch erst seit ein paar Stunden. Eine Synchronisation als Workaround wie bei wikEd meines Wissens nicht möglich. Ich habe unter Wikipedia:Technik/AceWikiEditor #Bekannte Probleme nun deutlicher darauf hingewiesen. Gruß Matthias (Diskussion) 20:12, 5. Okt. 2012 (CEST)

Dann würde ich erstmal empfehlen, die neue Seite zu verschieben nach Wikipedia:Technik/AceWikiEditor – neu angelegte Seiten würde ich gern ein wenig unter „Technik“ gesammelt sehen und nicht zwischen Stammtischen herumfliegen. erl.; oben angepasst --PerfektesChaos 09:59, 6. Okt. 2012 (CEST)

Den CodeEditor habe ich unter mw: auch schon benutzt; das Einbinden hier in der deWP war etwas mühsam, weil ihm in der Experimentalphase irgendwelche Bibliotheksskripte fehlten oder denen irgendeine Konfiguration. Seitdem habe ich es nicht weiter verfolgt.

Ich vermute, Raymond meinte erstmal den primär ausgetesteten Teil für JS/CSS. Wenn die Basis-Software schon routinemäßig eingebunden ist, fein.

Wie das mit Ace + Wikitext läuft, kann man sehen.

Die Beschränkung auf Gecko würde ja wohl gegen WikEd wegfallen; mag also etwas bringen. Und eine Gemeinschaftsentwicklung könnte, muss aber nicht Vorteile bringen gegenüber einem einzelnen Skriptautor hinsichtlich zeitnaher Bugfixe.

Bis dann --PerfektesChaos 20:56, 5. Okt. 2012 (CEST)

Ja, ich meinte den Teil für Lua/JS/CSS. — Raymond ^Disk. 00:03, 6. Okt. 2012 (CEST)

@Rillke: Höre ich da Ironie oder Lob bei der Frage nach der Weisheit? Konkret habe ich meine Weisheit aus der Verfolgung der Lua-Entwicklung, da ist der Codeeditor nur ein Nebenprodukt. Die Gadget-Seiten rund um den AceEditor kannte ich bisher nicht. — Raymond ^Disk. 00:03, 6. Okt. 2012 (CEST)

Danke. Neben dem Lob vor allem Neugier. Ich habe das Gefühl, dass die ganze MW-Entwicklung etwas unkoordiniert vonstatten geht oder zumindest, dass es keinen zentralen Platz gibt, in dem solche Intentionen festgehalten werden. (Außer evtl. die Mailinglists – aber die sind immer eine Mixtur aus Fragen, Antworten etc. und es gibt zig verschiedene) -- RE rillke fragen? 12:05, 6. Okt. 2012 (CEST)

Der AceEditor kann in meinen Tests nicht mit Verschachtelungen (Tabellen, Links in Bildunterschriften) umgehen. Bei Vorlagen geht eine Verschachtelung noch, aber bei der dritten schließt er zu früh. Sprich, gerade in den Fällen, wo die Syntax so komplex ist, dss man eine Hervorhebung sehr gut gebrauchen kann, versagt das Skript und verwirrt nur noch mehr. Zudem ist die Scrollleiste zu weit rechts platziert (das kann aber [1] sein). --Schnark 10:34, 6. Okt. 2012 (CEST)

Ich ziehe hier mal (zumindest für mich) ein zwischenzeitliches Fazit:

• Im Moment ist ACE noch nicht als (Häkchen-)Gadget geeignet.
• Es fehlen dazu insbesondere:
  • Deutschsprachige Dokumentationsseiten,
  • Framework,
  • Persönliche Betreuer.
• In absehbarer Zeit wird das Paket ohnehin weltweit installiert und für Lua/CSS/JS eingerichtet.
  • Dann brauchen wir uns nicht mit einer deWP-lokalen Installation abzuquälen, um die diversen Komponenten hier zusammenzuflicken.
  • Lua/CSS/JS sind Sprachen mit wesentlich strikterer Syntax als unsere Wikisyntax. Bis auf die Mehrfachbedeutung des JS-Schrägstrichs ist das relativ simpel zu parsen und in Regeln umzusetzen.
  • CSS/JS mit ACE läuft auf mw: inzwischen problemlos; wurde dort auch von den Importeuren für den Eigenbedarf optimal angepasst.
• Der Einsatz von ACE für Wikisyntax ist ersichtlich instabil, bedarf der Erprobung; sowohl auf Ebene des lokalisierten Quelltext-Markups wie auch in Fragen des GUI.
• Es bleibt jedem unbenommen, sofort im Rang eines Benutzerskripts das Framework zu verlinken und eine deWP-Testversion bereitzustellen und mit Bedienungsanleitung zu versehen. Auf die gesammelten Erfahrungen kann man dann später zurückgreifen.

LG --PerfektesChaos 15:56, 7. Okt. 2012 (CEST)

P.S.: In der Skin-Werkstatt gibt es einen analogen Thread, der vermutlich ein geeigneterer Ort für die Diskussion technischer Einzelheiten der Vorläuferphase sein dürfte. --PerfektesChaos 16:00, 7. Okt. 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Matthias (Diskussion) 18:34, 9. Okt. 2012 (CEST)

Internal link translator

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

how it works?

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

case for templates

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

case for categories;

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

case for lists

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

next features

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

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

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

Bug tracking helper gadget

Gemeldet in Bugzilla
Bug 34366 Resolved fixed

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

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

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

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

cat-a-lot

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

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

Admin-Rechte?

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 ³⁸⁹ 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 ³⁸⁹ 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.

(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

Ich möchte das genannte Gadget vorschlagen.

Beschreibungsseite:

• #WEITERLEITUNG Benutzer:PerfektesChaos/js/paneMarker

Code:

• Statische Kopie von mw:User:PerfektesChaos/js/paneMarker/r.js

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 zu verwenden oder ganz dezent (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:
  
      Bearbeiten vo…    Bearbeiten vo…    Bearbeiten vo…   

Beste Grüße --PerfektesChaos 23:58, 21. Aug. 2012 (CEST)

 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: Perhelion 19:51, 2. Jul. 2014 (CEST)

Umstellen auf ResourceLoader

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

Ich möchte das genannte Gadget vorschlagen.

Beschreibungsseite:

• #WEITERLEITUNG Benutzer:PerfektesChaos/js/resultListSort

Code:

• Statische Kopie von mw:User:PerfektesChaos/js/resultListSort/r.js

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

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

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

Folgende Skripte schlage ich zur Aufnahme in die Helferlein vor:

• unsigned.js (Diskussion)
• hideduplicatecontribs.js (Diskussion)
• wikieditor.js (Diskussion)
• autoFormatter.js (Diskussion)
• cleanDiff.js (Diskussion)
• signatureDateFormat.js (Diskussion)

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

Zoom-Voreinstellung mit Koordinaten in Kartenvorschau

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

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

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. Vorlage:Smiley/Wartung/: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)