Wikipedia:Technik/Werkstatt

Automatische Archivierung

Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit 10 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind.

Dauerbaustellen; Spezifikationen für wünschenswerte Werkzeuge

CSS/metadata

Hallo, ich hoffe ich bin auf dieser neuen Seite richtig, sonst bitte ich um Platzverweis ;) Wir nutzen in {{Denkmalliste Österreich Tabellenzeile}} die CSS-Klasse "metadata" aus der mediawiki:common.css um eine Spalte für den gemeinen Leser auszublenden... Leider dürfte die Mobile Version das nicht mitbekommen haben, dort sind die Metadaten immer eingeblendet (graue Spalte, zB hier). Könnt ihr helfen? LG --AleXXw •שלום!•disk 20:24, 12. Jul. 2011 (CEST)

Wobei, eine andere Lösung für die Vorlage zu finden oder mobile zu bestimmten CSS zu bewegen? Letzteres ist ziemlich unmöglich, das alte Python-Skript versteht/wartet eh kein Entwickler mehr und eine neue PHP-Version lässt auf sich warten.

Zu ersterem mal ein Denkansatz für eine (häßliche) Lösung: [1]. Funktioniert aber wohl nicht. --✓ ^Bergi 21:49, 12. Jul. 2011 (CEST)

Zweiteres, es würde schon reichen die für mobile verwendete CSS richtigzustellen... Mit den anderen metadata verwendenden Vorlagen wie etwa PD gehts ja auch (Bsp) Was du mir mit den Variablen sagen willst weis ich jetzt nicht genau ;) --AleXXw •שלום!•disk 22:08, 12. Jul. 2011 (CEST)

Ihr könntet es mal mit der zusätzlichen Klasse "nomobile" probieren. Im Quelltext des Mobile-Parsers sind die weiteren Elemente aufgeführt, die aus dem Artikel entfernt werden. Gruß --P.Copp 22:44, 12. Jul. 2011 (CEST)

Danke, hat funktioniert... Das Problem ist dass in der Konfiguration nur "table.metadata" ausgeblendet wird, richtigerweise müsste ".metadata" stehen. Kann man das irgendwo melden? LG --AleXXw •שלום!•disk 23:12, 12. Jul. 2011 (CEST)

Danke für den Hinweis, P.Copp, ich habs sogleich gemeldet. @AleXXw: Die Frage ist nur, wann das mal umgesetzt wird. Das mit den Variablen war so gedacht, dass mobile doch vielleicht für {{SERVER}} was anderes ausgeben könnte… Leider haben die aber keinen eigenen Parser. --✓ ^Bergi 12:07, 13. Jul. 2011 (CEST)

Vorlage Diskussion:Positionskarte#mobile-Version

Dort werden CSS-Skills für eine Fehlerbehebung gesucht. Edit-Kommertar dazu „inserat: suche jemand, der sich ein wenig mit CSS auskennt und die Positionskarte fixt“ --Spischot 10:57, 29. Jul. 2011 (CEST)

Es sind schon genug Anfragen gestellt wurden, dass ichs gesehen habe (3×BEO) :-)

Wegen meiner Anwort dort: Wie erreicht man table[style]:not(.klasse){width:100% !important;} so, dass es auch Browser ohne not verstehen? --✓ ^Bergi 14:56, 29. Jul. 2011 (CEST)

Hat diese Neuerung vielleicht etwas gebracht? --Leyo 17:12, 2. Aug. 2011 (CEST)

Nein, außer der Programmiersprache des Backends hat sich ja nichts geändert. --✓ ^Bergi 11:30, 3. Aug. 2011 (CEST)

Vorlagen im Editor

Gibt es eine Möglichkeit, um einige Kopiervorlagen (Wie Vorlage:Internetquelle) ausklappbar im Editor in die Urheberrechtsbox zu integrieren? --IWorld – @ 21:47, 1. Sep. 2011 (CEST)

Ja, viele.

Die Frage hat vermutlich ähnliche Zielrichtung wie oben und weiter oben?

Editor kann auch WP:WikEd sein; dann en:User:Cacycle/wikEd_customization#Custom_buttons

Dann geht noch WP:Bookmarklets.

Siehe dazu auch /GUI.

HGZH --PerfektesChaos 22:16, 1. Sep. 2011 (CEST)

Es soll nur wie folgendes Script aussehen:

// Benutzer:Mcaviglia - www.mcaviglia.ch - Zeile bitte stehen Lassen

document.write('<script type="text/javascript" src="' + 'http://www.mcaviglia.ch/gmap/get_coor_js.asp?l=de"></script>'); mediaWiki.loader.load("https://toolserver.org/~netaction/wikitrust.js");

--IWorld – @ 13:40, 2. Sep. 2011 (CEST)

Okay; habe ich jetzt grundsätzlich verstanden.

Du möchtest einen Knopf haben, und wenn du draufklickst, soll sich dieses Formular öffnen; du möchtest einen Ort etc. auswählen, klickst auf dem Formular auf, äh, irgendwohin; und dann soll sich die Vorlage in den aktuellen Artikel hineinschreiben?

Klingt machbar.

Ich muss dazu erstmal auf die Suche nach einer Bedienungsanleitung zu mcaviglia gehen; Weiteres kommt im Lauf des Wochenendes.

Offen bleibt die Frage: Sieht es auf deiner Bearbeitungsseite aus

• wie hier?
• oder so?
• Oder benutzt du WP:WikEd?

Das wäre schon nötig, um zu gucken, wo ich dir das Knöpfchen dazubauen kann.

VG --PerfektesChaos 14:18, 2. Sep. 2011 (CEST)

Nein, ich will nur eine auflappbare Box im Urherrechtshinweiskasten haben, wo die Vorlage zum Kopieren bereit liegt. Am besten wie hier. (Die 1.) --IWorld – @ 15:18, 2. Sep. 2011 (CEST)

• Mit einer aufklappbaren Box müsstest du dich noch einige Wochen gedulden; in der nächsten Version unserer MediaWiki-Software wird etwas vorhanden sein, mit dem man solche Klappboxen realisieren kann.
• Allerdings ist deine Vorstellung von Urherrechtshinweiskasten und Kopieren ziemlich ungewöhnlich. Normalerweise macht man das etwas anders:
  • Du stehst mit deinem Cursor irgendwo im Wikitext.
  • Auf der Werkzeugleiste hast du ein Knöpfchen, sagen wir mal, IQ – da klickst du drauf und bekommst die Kopiervorlage an der aktuellen Cursorposition in den Wikitext eingefügt; selbstverständlich gleich mit aktuellem ISO-Datum. Gern auch als IQk und IQv für Kurzfassung und Vollprogramm.
  • Das Ergebnis ist wohl das, was du erreichen möchtest, und lässt sich kurzfristiger umsetzen.
  • Deshalb fragte ich, welche Knöpfchen du bei dir siehst.

VG --PerfektesChaos 15:42, 2. Sep. 2011 (CEST)

(BK) Hast du schonmal den Vorlagenmeister (Einstellungen→Gadgets) ausprobiert? Der dürfte für so häufig verwendete Vorlagen wie Internetquelle sehr gut funktionieren.

Bloß eine Kopiervorlage in die Seite einzufügen ist schon fast zu einfach:

$(function() {
   var templates = [ "{{Internetquelle\n|Parameter...}}"/*, "weitere Vorlagen"*/ ];
   if (mw.config.get("wgAction") != "edit" && mw.config.get("wgAction") != "submit")
      return;
   mw.util.addCSS("#copy-paste > pre { float:left; }");
   $('#editpage-copywarn').before('<div id="copy-paste"><pre>'+templates.join('</pre><pre>')+'</pre><div class="visualClear"/></div>');
});

Die Variable templates ist dabei ein Array (Liste), das du mit mehreren Komma-separierten Strings (deinen Kopiervorlagen) füllen kannst. Jeder String wird von Hochkommata umgeben, Zeilenumbrüche schreibst du als \n. Solltest du die Kopiervorlagen wirklich in statt vor dem Copyrighthinweis haben wollen, so ersetze before durch prepend. Sollten dir die pre-Kästen nicht gefallen, kannst du ihnen neben dem float:left noch weitere CSS-Eigenschaften zuweisen, zum Beispiel keinen Rahmen. --✓ ^Bergi 16:00, 2. Sep. 2011 (CEST)

Eigentlich ist es das, was ich suche. Mit der Klappversion muss ich mich dann halt noch gedulden. Danke für euere Hilfe! --IWorld – @ 18:01, 2. Sep. 2011 (CEST)

Commons-Annotations vs. ImageSiblings

Moin, hat jemand von euch eine Idee, warum man entweder importScript('MediaWiki:Gadget-ImageAnnotator.js'); oder das bereits als Gadget verfügbare ImageSiblings nutzen kann, nicht jedoch beide? (vgl. Disk) Danke, --Flominator 11:16, 17. Sep. 2011 (CEST)

Auch wenn ich mir den Code nicht genauer angesehen habe, kann man generell sagen, dass Funktionen die das Gleiche tun, sich selten ungestört vertragen (dabei sind Variablen oder DOM Konflikte außer Acht). Vor allem bei direkten Events-Auslöser werden Funktionen einfach überschrieben, was ich hier mal vermute. -- πϵρήλιο ℗ 22:13, 18. Sep. 2011 (CEST)

Was kann man dagegen tun? --Flominator 12:16, 1. Nov. 2011 (CET)

Idee: Lagewunsch.js

Ich stelle mir folgendes vor: Ein Tool in dem ich schnell den korrekten ISO 3166-2-Code zusammen mit {{Coordinate}} oder {{Lagewunsch}} im Artikel anfügen kann. Ich stelle mir das so vor: das Tool sollte in der ersten Auswahl DACH, Afrika, Amerika, Asien, Europa sowie Australien und Ozeanien anbieten. Nach der Auswahl entsprechend ein Bundesland oder ein anderer Staat. Nach einem "ok" wird das Edit-Fenster geöffnet und oberhalb von den Kategorien die Vorlage {{Coordinate|Region=DE-NW}} hinzugefügt. Nach der Möglichkeit weitere Korrekturen am Artikel vorzunehmen, kann der Artikel gespeichert werden. Also ein wenig Ähnlichkeit mit dem HotCat.

Abgebildet sollte dann als Auswahlfeld die Struktur, die sich in der Kategorie:ISO 3166-2 wiederfindet.

Wenn man es ganz geschickt programmiert, dann könnte vielleicht aus der Kategoriestruktur des Artikels schon "erahnt" werden um welchen Staat oder Bundesland es sich handelt. --Atamari 16:19, 18. Okt. 2011 (CEST)

Damit du nicht das Gefühl hast, du würdest hier einfach ignoriert: Der Programmieraufwand an sich ist überschaubar, aber die Menge an Daten, die das Skript kennen müsste ist riesig. Man bräuchte eine Variable von der Gestalt

{
 'DACH': {
  'Deutschland': {
   '*': 'DE',
   'Baden-Württemberg': 'DE-BW',
   'Bayern': 'DE-BY',
//... 13 weitere Einträge
   'Thüringen': 'DE-TH'
  },
  'Österreich': {
   '*': 'AT',
   'Burgenland': 'AT-1',
//... 8 weitere Einträge
  },
  'Schweiz': {
//... 27 Einträge
  }
 },
 'Europa': {
  'Albanien': {
   '*': 'AL',
   'Qark Berat': 'AL-01',
//... 46 weitere Einträge
   'Kreis Vlora': 'AL-VL'
  },
//... Einträge für alle weiteren europäischen Länder
 },
//... Einträge für alle weiteren Kontinente
 'Sonstiges': {
  'Atlantik': {
   '*': 'XA'
  },
//... 5 weitere Einträge
  'Orbit': {
   '*': 'XO'
  }
 }
}

Falls du nach dieser Antwort immer noch ein solches Skript willst, und dich bereit erklärst, das obige Schema komplett auszufüllen, denke ich nochmal darüber nach, ob ich den Code dazuliefere, der dann aus den Daten eine nette Auswahl macht. --Schnark 11:20, 22. Okt. 2011 (CEST)

Im Grunde genommen existiert irgend wo alles - es kann (vielleicht) nur nicht vernünftig abgegfragt werden. Das geht mal wieder in Richtung Metadaten. Als erstes wird eine "Übersetzungstabelle" (rund 200 Zeilen) gebraucht: Lemma des Staates vs. ISO-3166-2. Also : Gambia, Vorlage:Info ISO-3166-2:GM (ähnliches gibt es auch in Vorlage:Infobox Ort in Gambia/Region zu ISO Code). Ob nun alle Staaten und alle unteren Code, die Gebietseinheiten der Staaten im selben Script sein müssen weis ich nicht, evtl. könnte man das geschickt über mehrere Tabellen lösen.

Wir sollen das mal nicht als kurzfristige Idee ansehen, sondern als eine langfristige. Danke für die Antwort. --Atamari 13:28, 22. Okt. 2011 (CEST)

Ohne programmierend tätig werden zu wollen:

Hier scheint mir die Trennung von Programm und Daten dringend geboten zu sein.

• Es sollte eine gesonderte und aktualisierbare Seite (ohne .js-Endung) geben, auf der die Inhalte durch alle Autoren gepflegt werden können:

    DE    Deutschland
    DE-BE Berlin

• Der Inhalt der Daten-Seite wird, sobald das Skript ernsthaft aktiv werden soll, per API eingelesen. Der Inhalt könnte alternativ komplett in eine JS-Objektstruktur eingelesen werden, oder aber per RegExp ausgefiltert werden und Zeichenkette bleiben, soweit nicht benötigt.
• JSON würde ich im Interesse der Allgemeinverständlicheit für Datenpfleger vermeiden und mich auf plain text beschränken.
• Neben den Kodierungen für die Inhalte mögen die Datensätze auch die PopUp-Struktur abbilden, also beispielsweise

          0 -- DACH
          0 DE    Deutschland
          0 DE-BE Berlin
          0 AT    Österreich
          0 CH    Schweiz
          1 -- restliches Europa
          2 -- Amerika
          3 -- Afrika

Viel Spaß --PerfektesChaos 19:26, 22. Okt. 2011 (CEST)

Es gibt bereits eine Wiki-Datenstruktur, die hervorragend allgemeinverständlich formuliert ist (in Vorlagensyntax :-), und sie lässt sich auch relativ passabel aufrufen. Per API nehme man als generator categorymembers von Kategorie:Vorlage:ISO-3166-1-Code, und dann revison-content. Daraus lässt sich Kontinent, ISO-Code, Name und sogar Lemma ziehen. Sowie für die nächste Abfrage (prefixindex als Generator für "Unterseiten") hat man auch gleich noch maxlevel und admtype zur Verfügung. Die Möglichkeit, DACH statt Kontinent zu nehmen steht dann erstmal allerdings nicht zur Verfügung (könnte aber hineingehackt werden).

So richtig komfortabel wären nun halt Karten als Auswahl. In der deWP gibts vereinzelt Imagemaps, aus denen man die Geodaten ziehen könnte, viel geht da aber nicht. Müsste man eher von OSM importieren. Es gibt doch auch schon Tools, die das können (wikiGetCoordinate oder wie das hieß?), könnte man sich da nicht die entsprechenden Codeabschnitte ausborgen?

Das Skript lässt sich also in 3 Teile zerlegen: Daten(struktur)aufruf (kann ich dir bauen), GUI zur Eingabe (gibts da nich schon schöne Frameworks? Sonst kann ich dir was simples Schneidern), und Einfügen in den Artikel (Von textInsert in der Bearbeitenansicht bis zu HotCat-Luxus ist ein weiter Weg).

Zu deinem anderen Vorschlag, dem Erahnen des Landes aus den Kategorien: Umpfh. Wenn du mit Kategoriestruktur sowas wie Catgraph meinst, wüsste ich nicht wie man das (in einem Schritt) abrufen kann. Ich glaube allerdings sowieso, dass der Artikeltext mehr Aufschluss darüber geben würde. Und egal welche Daten vorliegen, müsste man immer noch eine komplizierte Fuzzy-Suche implementieren, die aus dem Auftreten von „Der See liegt im ivorischen Regenwald“ die Elfenbeinküste herausrechnen kann… Mit solchen Algorithmen kann man bei Google & Co richtig Geld verdienen, glaub ja nicht dass ich das unter CC stelle :-) -- ✓ ^Bergi 21:52, 22. Okt. 2011 (CEST)

Zu kompliziert muss und soll es auch nicht sein, der Idee soll es nur ein UI sein um ein nach Staat spezifizierter Lagewunsch zu setzen. Mit Hilfe von Karten wäre man schon nahe dran am setzten der richtigen Artikel-Koordinaten. Die kann aber vielleicht nur ein Ortskundiger finden. Also es gibt rund 200 Iso-Codes für die Staaten - die ich bislang noch nicht auswendig kenne. Die Idee ist, mit einem Tool spätestens nach drei Klicks + Ok zum Ergebnis zu kommen. --Atamari 22:04, 22. Okt. 2011 (CEST)

@Bergi: Du warst ja kürzlich heldenhaft in der {{Coordinate}} unterwegs und kennst dich da besser aus.

• Daraus würde folgen: Hardcoded im Skript-PopUp den ersten Auswahl-Level (DE,AT,CH,Europa/sonst,Asien,…) anbieten.
• Nachdem der Anwender hier geklickt hat, API-queries zum Auffüllen des zweiten Levels (ISO-3166-2 bei DACH, Länderauswahl im Kontinent sonst; DE,AT,CH mögen auch „doppelt“ im sonstigen Europa auftauchen) und live das Angebot auffüllen.
• Nachdem im Non-DACH das Land ausgewählt wurde, mit erneuter query für dieses Land schauen, ob es dazu ISO-3166-2 gibt; sonst fertig.

Klingt pfiffig. Fein (Trennung von Programm und Daten). Sonnigen Sonntag --PerfektesChaos 09:28, 23. Okt. 2011 (CEST)

„Erahnen aus Kategorien“ wird kaum gehen. Da wir so pfiffig sind, systematisch die Oberkat aus den Artikeln zu löschen, steht da nicht „Ort in Hessen“, sondern „Ort im Landkreis X“, „Straße in Wien“ oder „Springbrunnen in Sachsen“.

Für die Benutzerführung wäre es auch schwieriger, zwei Level bereits aufgepoppt zu zeigen und sich die Mutmaßung bestätigen zu lassen (sowas verstehen nur die Progammierer), als die aktiv durch die Auswahl klicken zu lassen. Hinzu kommt, dass bei Fehleinschätzung völlige Verwirrung beim Anwender ausbricht.

Im vorgenannten Sinne --PerfektesChaos 09:37, 23. Okt. 2011 (CEST)

Ich habe jetzt eine funktionierende Version fertig, die aber auf meine (4) Bibliotheken aufbaut. Also nicht wirklich öffentlichkeitswirksam. Ich kann versuchen, die Bibliotheken rauszustückeln, das dauert aber und wird hässlich. Wenns nötig ist, kann ich euch die Stückelei als Userscript für FF/Opera anbieten. Allerdings merkt man schon beim Zufall-Testen, wie schlecht gewartet unsere Metadatenvorlagen sind. -- ✓ ^Bergi 22:39, 23. Okt. 2011 (CEST)

Beobachtungsliste

Wie kann ich die Beobachtungsliste durch ~luxo/gwatch/watchlist.php ersetzen? --Der Buckesfelder  ^Disk.  _bewerten  ^Email 20:33, 8. Nov. 2011 (CET)

Was meinst du mit ersetzen? Du benutzt einfach erstere nicht mehr und letztere schon. Oder geht es dir darum, (alle?) Links auf die BEO zu ändern? Oder gar von der BEO-Seite automatisch weiterzuleiten (was ich nicht empfehlen würde)? -- ✓ ^Bergi 22:27, 8. Nov. 2011 (CET)

Ich würde gerne entweder direkt von der Beo weitergeleitet werden, oder gwatch wird direkt in die Beo geladen werden. --Buckesfelder  ^Disk.  _bewerten  ^Email 07:18, 9. Nov. 2011 (CET)

Für ersteres würde ich mw.config.get('wgCanonicalSpecialPageName') == "Watchlist" als Bedingung und dann document.location.replace() verwenden. Allerdings verhinderst du dabei todsicher, ohne Ausschalten von JS auf deine Wikpedia-BEO zu kommen.

Direktes In-die-Seite laden geht mit Frames, so in etwa mw.util.content.html('<iframe src="luxo" />'); (Inlineframe). Hat aber selbiges Problem. -- ✓ ^Bergi 21:19, 9. Nov. 2011 (CET)

… so in etwa … ERROR function not found … mw.util.content.html() … suggestions: mw.util.$content or mw.html.element() … Viel Spaß, schaut spaßig aus, schönen Abend --PerfektesChaos 21:43, 9. Nov. 2011 (CET)

Äh, ja, natürlich $content. Irgendwas war mir da doch schon merkwürdig vorgekommen. Ist mw.html.element eigentlich wirklich nur dafür gedacht, innerHTML-Strings bereitzustellen? -- ✓ ^Bergi 22:14, 9. Nov. 2011 (CET)

Also – was sich da jemand gedacht hat? Das weiß ich auch nicht. Es scheint mir um Escaping zu gehen; ich wäre nicht auf die Idee gekommen, das als Bibliotheksfunktion zu vermarkten, aber irgendwer hat sowas wohl öfters für sich gebraucht und das als Utility bereitgestellt. Na dann … LG --PerfektesChaos 23:17, 9. Nov. 2011 (CET)

mw-collapsible in Navileisten

Ich habe unter Vorlage Diskussion:Navigationsleiste#Ein- und Ausklappen mal auf die Anfrage geantwortet, doch die neue Klasse mw-collapsible zu verwenden. Vielleicht fällt euch noch ein bisschen Senf zum Thema ein. -- ✓ ^Bergi 22:32, 12. Nov. 2011 (CET)

Stockphoto.js auf Commons funktioniert nicht im Internet Explorer

Auf Commons gibt es ein JavaScript welches einem bei der Nachnutzung von Bildern hilft. Leider wurde es für den Internet Explorer geblockt, da das Skript vermutlich für IE-Crashes verantwortlich war: commons:Commons:Village pump/Archive/2011/03#Internet Explorer (IE) 8.0.6 and IE 7.0.6 crash. Hat jemand Lust nach der Ursache zu forschen und auf Commons für eine entsprechende Anpassung zu sorgen? Es kann natürlich auch schon sein, das die Änderungen seit dem 17. Februar unwissend ein Fix enthalten. Das Skript wird in der Vector.js eingebunden. Ich würde mich freuen. Vielen Dank. Der Umherirrende 20:09, 11. Dez. 2011 (CET)

Siehe dazu auch commons:MediaWiki_talk:Stockphoto.js#fix_or_disable_for_Internet_explorer._It_is_crashing_the_whole_browser. Falls diskutiert werden sollte: bitte in Commons in jenem Abschnitt - dort gehört die Diskussion hin, sonst findet man sie nicht. :-) Viele Grüße --Saibo (Δ) 22:32, 11. Dez. 2011 (CET)

Und wenn sich schon jemand die Mühe macht und das Script gründlich überarbeitet, sollte es flexibel verwendet werden können: Text der Bildbeschreibungsseite rein Objekt mit Symbolen und Captions raus. Das hätte den Vorteil, dass es etwa in der Slideshow auch funktioniert. Danke! -- RE rillke fragen? 01:02, 28. Dez. 2011 (CET)

Wie ich gerade festgestellt habe, funktioniert es jetzt auf Commons für IE (wenn auch nur IE>7, aber dürfte erstmal reichen). Vielen Dank Rillke. Der Umherirrende 21:15, 11. Sep. 2012 (CEST)

Dieser Abschnitt kann archiviert werden. Der Umherirrende 21:15, 11. Sep. 2012 (CEST)

Script funktioniert nicht überall

Hallo. Ich habe gestern das Script [2] erstellt und dabei dort per mw.loader.load das Script [3] eingebunden. Wenn ich dann dort editierte, funktioniert das zweite Script leider nicht. Es soll unterhalb von Zusammenfassungszeile kleine grüne Links erzeugen. Wenn man so einen Link dann anklickt, wird ein entsprechender Text in die Zusammenfassungszeile geschrieben. Warum klappt es nicht bei Wikibooks, obwohl es in der Wikipedia funktioniert? Komisch ist auch, daß es in der Wikipedia sogar mit dem veralteten document.write geht, während bei Wikibooks nicht mal das klappt. Die im Script verwendet ID-s wpSummaryLabel und wpSummary sind auch in Wikibooks vorhanden, so daß es wohl nicht daran liegen dürfte. Wer hätte eine Idee? Gruß --Tlustulimu 11:07, 16. Jan. 2012 (CET)

(+) Mit der Browsererweitung View Dependencies konnte ich sehen, welche js-Seiten überhaupt geladen werden. Beide Seiten werden geladen. Aber aus einem mir unbekannten Grund ist das zweite Script wirkungslos. Warum? Gruß --Tlustulimu 11:28, 16. Jan. 2012 (CET)

• Auf den ersten Blick sehe ich beim Überfliegen nichts Böses.
• Rein routinemäßig würde ich bei der Gelegenheit empfehlen, addOnloadHook zu ersetzen. Ich habe keinerlei Durchblick, wie die projektseitige Unterstützung auf Esperanto-Wikibooks gehandhabt wird und würde die zentralen Mediawiki-Funktionen vorziehen, zumal addOnloadHook eines Tages futsch sein dürfte. document.write ist wirklich keine Lösung.
• Um genauer zu verfolgen, was dein Skript in welchem Moment macht, gibt es zwei Möglichkeiten:
  • In przyciskiOpis kannst du als erstes Statement einbauen

             alert("function przyciskiOpis() Start");

und am Ende von butonetoj.js als letzte Zeile ggf. (da hast du ja bereits Ähnliches)

             alert("Uzanto:Tlustulimu/butonetoj.js Geladen");

• Alternativ könntest du dich in Debugging-Methoden einlesen. Es ermöglicht zeilenweises Verfolgen der Skript-Abarbeitung, Blick in die aktuellen Werte von Variablen und zeigt die Struktur des HTML-Dokuments. Wenn du schon mit einer Browsererweiterung View Dependencies arbeitest, dann gleich richtig.

• Du kannst übrigens Skripte zentral an einem Ort lagern und aktuell halten und mit mw.loader.load von beliebigen URL und Wikiprojekten abrufen.

Viel Erfolg für den Anfang --PerfektesChaos 12:15, 16. Jan. 2012 (CET)

Hallo, PerfektesChaos. Danke für deine Tipps. Ich habe jetzt einfach mal addOnloadHook(przyciskiOpis); durch folgenden Code ersetzt:

if (mw.config.get('wgAction') == 'edit' || mw.config.get('wgAction') == 'submit')    
{
       if (mw.config.get('wgNamespaceNumber') > -1)
      {
      jQuery(document).ready(przyciskiOpis);
      }
}

Und das funktioniert jetzt sowohl in der Esperanto-Wikipedia als auch auf Wikibooks. Der genannt Code steht nämlich im Gedget der polnischen Wikipedia. Komisch ist bloß, daß meine Änderung der Einbindung von butonetoj.js in der vector.js auf mw.loader.load nur auf Wikibooks ging. Ich habe es also in der Wikipedia gleich wieder revertiert. Warum klappt es mal und mal nicht?

Leider ist dieses "butonetoj"-Script so geschrieben, daß es die Sprache des jeweiligen Benutzer nicht analysiert, sondern die Texte einmalig festlegt. Ließe es sich überhaupt so umbauen, daß man es nur noch an einer Stelle definieren müßte? Gruß --Tlustulimu 15:50, 16. Jan. 2012 (CET)

Funktioniert mal und mal nicht: Klingt mir so, als hättest du deinen Browsercache nicht geleert.

Internationalisierung/Lokalisierung: Selbstverständlich geht das. Dazu denkst du dir für jeden Text eine Id, einen „Systemnachrichtennamen“, aus. Du erstellt nun eine globale Variable und initialisierst sie, sofern nicht bereits vorhanden, mit einem leeren Objekt. Dann fügst du diesem Objekt, sofern nicht bereits vorhanden, für jede unterstützte Sprache als Attribut mit dem jeweiligen Sprachkürzel das Objekt hinzu, das jedem Nachrichtennamen den zugehörigen Nachrichtenwert zuordnet. Das „sofern noch nicht vorhanden“ dient dazu, dass ein Nutzer das Objekt bzw. einen Teil davon auch überschreiben kann, wenn er etwas anderes wünscht. Dann benötigt man noch ein Fallback (eigentlich eine Fallback-kette), welche Sprache verwendet werden soll wenn die gewählte nicht verfügbar ist.
Bei deinem Skript sehe ich 3 benötigte Objekte: Eines mit den Texten, die eingefügt werden sollen (ausgewählt wird nach wgContentLanguage, eines mit den Texten, die angezeigt werden sollen (ausgewählt nach wgUserLanguage) und eines mit Arrays, in welcher Reihenfolge (bzw. welche Auswahl) angezeigt werden soll (ausgewählt nach wgDBname, d.h. nach Wiki auf dem das Skript gerade läuft).
meint -- ✓ ^Bergi 16:35, 16. Jan. 2012 (CET)

Hallo, Bergi. Der Browsercache war schuld. Leider verstehe ich nur Bahnhof. :-( Gruß --Tlustulimu 16:47, 16. Jan. 2012 (CET)

• Warum mw.loader.load in einem Wikiprojekt gehen solle und im anderen nicht, wäre mir auch sehr rätselhaft gewesen. Alle WMF-Projekte verwenden insoweit weltweit einheitliche Software, was bei importScript und addOnloadHook gerade nicht mehr der Fall ist.
• Wenn du dich in ein multilinguales Programmierbeispiel einlesen möchtest, könntest du hier nach fileAdm.all.fit suchen und dir die Benutzersprach- und Projektsprachspezifischen Funktionen genauer anschauen.
• Weil du mit eo und pl hantierst: Zur Vermeidung rätselhafter Phänomene solltest du in den Namen von Variablen (und damit Funktionen) nur die „englischen“ Buchstaben A-Z a-z benutzen. Ich hatte die von dir angegebenen Beispiele daraufhin durchgeguckt und keine ĝ, š oder Ł gefunden. Zwar verkündet der ECMA-Standard, dass dafür mal beliebige Unicode-Buchstaben benutzt werden dürfen, jedoch kapiert das nicht jeder aktuelle Browser. – Innerhalb von Zeichenketten ist es unproblematisch.

Viel Spaß --PerfektesChaos 17:19, 16. Jan. 2012 (CET)

Hallo, PerfektesChaos. Das Cacheproblem ist schon manchmal ziemlich nervig. Aber ohne Cache wäre die Wikipedia bestimmt nicht zu gebrauchen, oder?

Gibt es nicht ein etwas einfacheres Programmierbeispiel? - Wie könnte ich den addOnloadHook ändern bzw. entsorgen? In meinen vector.js-Seiten steht so etwas noch drin. Allerdings habe ich dort inzwischen document.write durch mw.loader.load ersetzt.

Auf das Problem mit den Sonderzeichen war die Esperanto-Wikipedia vor einigen Monaten schon mal gestoßen, als auf einmal kaum noch Skripte funktionierten. Da hatte nämlich der Server gleich die ganze js-Seite verworfen. Zum Glück konnte einer der anderen Admins den Fehler schnell beheben. Gruß --Tlustulimu 19:54, 16. Jan. 2012 (CET)

• Zu addOnloadHook wie bereits oben verlinkt: WP:JS bis hin zu Veraltet.
• Ich schreibe das, was Bergi umrissen hat und was ich zuvor mit dem einfachsten mir zu Gebote stehenden produktiven Beispiel zu erläutern versucht hatte, mal auf ein simples Gerippe um. Es gibt etliche Möglichkeiten, das zu notieren; ich nehme diejenige, die mir am übersichtlichsten erscheint:

mw.libs.TlustulimuSeinDing  =  { l10n: { } };
mw.libs.TlustulimuSeinDing.l10n.summary  =  { fine:   "fine",
                                              gossip: "gossip"
                                            };
mw.libs.TlustulimuSeinDing.l10n.ui  =  { forward:  "forward",
                                         backward: "backward"
                                       };
switch ( mw.config.get("wgContentLanguage") ) {
   case "de" :
      mw.libs.TlustulimuSeinDing.l10n.summary  =  { fine:   "prima",
                                                    gossip: "Geschwätz"
                                                  };
      break;
   case "ru" :
      mw.libs.TlustulimuSeinDing.l10n.summary  =  { fine:   "хорошо",
                                                    ......
                                                  };
      break;
}   // switch wgContentLanguage
switch ( mw.config.get("wgUserLanguage").toLowerCase() ) {
   case "de" :
   case "de-at" :
   case "de-ch" :
   case "de-formal" :
   case "als" :
   case "nds" :
      mw.libs.TlustulimuSeinDing.l10n.ui  =  { forward:  "vorwärts",
                                               backward: "rückwärts"
                                             };
      break;
}   // switch wgUserLanguage

• Was passiert dabei?
  • Du baust ein Anwendungsobjekt TlustulimuSeinDing, das an die Standardbasis für Extensionen mw.libs andockt und die globalen Variablen nicht verseucht, auch ohne Gefahr von Namenskonflikten.
  • Eine Komponente deines Anwendungsobjekts ist l10n für die Lokalisierung. Daneben können auch sämtliche anderen Funktionen und Daten abgelegt werden.
  • Zwei Komponenten von l10n sind summary und ui. Sie werden mit englischen Texten vorbelegt.
  • Nun werden für die Projektsprache und die Benutzersprache die unterstützten Fälle durchgegangen. Wenn keine Sprache bekannt ist, bleibt es bei englisch.
  • Später kann auf die Beschriftung zugegriffen werden; ist die Funktion auch angedockt, ginge this.l10n.ui.forward als Beschriftung für den entsprechenden Knopf.
  • Bearbeitungskommentare, die alle anderen im aktuellen Projekt sehen, werden in der Projektsprache wgContentLanguage geschrieben. GUI-Elemente, die nur der momentane Benutzer sehen kann, erfolgen in dessen wgUserLanguage.
  • Alles das lässt sich noch kompakter und verschachtelter schreiben, reicht aber so für den Einstieg.
  • Daten und Funktionen stehen offen und können im Debugger gesehen und überwacht werden.

Enjoy. --PerfektesChaos 22:41, 16. Jan. 2012 (CET)

Ich bin mir zu faul, um alles obendrüber durchzulesen, daher von mir nur die kleine Bemerkung am Rande, dass bei der Nennung von User:Nux ganz oben im Kommentar die magische X-Konvertierung zugeschlagen und seinen Benutzernamen verunstaltet hat. --Schnark 10:24, 17. Jan. 2012 (CET)

Könnte es sein, dass du diesen Hinweis auf eine andere Seite schreiben wolltest? Ich sehe nicht ansatzweise eine Erwähnung. LG --PerfektesChaos 13:33, 17. Jan. 2012 (CET)

Nein, wollte ich nicht, schau dir mal den einleitenden Kommentar von eo:Uzanto:Tlustulimu/butonetoj.js an. --Schnark 09:12, 18. Jan. 2012 (CET)

Okay, da ist es natürlich hilfreich, wenn man mit dem Namen Maciej "Nux" Jaros was anfangen kann; mir nicht geläufig. Ich hatte ohnehin nur die beiden Schrägstriche gezählt und mit Sternchen wahrgenommen.

„magische X-Konvertierung“ ist eine historische oder immer noch irgendwo wirksame Eingabemethode? Sowas wie "+a→ä anscheinend?

Offenbar war beim vorliegenden Problem addOnloadHook() der Verursacher gewesen. Allmählich sollten wir was in unserem MediaWiki:-Namensraum tun.

Da die en.WP nur das Lesen bei aktiviertem JS blockiert hat, rückt sie ja sogar noch den Timestamp der WikEd.js raus. Mehr ein grey-out.

Sonnigen Tag --PerfektesChaos 10:03, 18. Jan. 2012 (CET)

Beobachtungsliste: mehrfach geänderte Seiten markieren

Ich fände es praktisch, wenn in der Beobachtungsliste angezeigt würde, wenn eine Seite im angegebenen Zeitraum mehrfach geändert wurde. Möglicherweise müsste dabei die Option Erweiterte Beobachtungsliste zur Anzeige aller Änderungen aktiviert und danach alle doppelten Seiten ausgeblendet sowie die neuste Version markiert werden. Ist das mittels Script machbar? Vielleicht hätte dieses ja „Gadget-Potential“… --Leyo 15:12, 21. Feb. 2012 (CET)

Navigation-Popups bei Bildern

Navigation-Popups zeigt in der de-WP bei Bildern (praktisch) nichts an. Bei auf Commons liegenden Dateien steht nur „Leere Seite“, bei lokalen Dateien beispielsweise „425 Bytes, 4 Wikilinks, 0 Bilder, 2 Kategorien, 73 Wochen alt“ und zusätzlich vielleicht „Lizenz“. In der en-WP hingegen wird ein Teil des Seiten-/Quelltexts angezeigt, egal ob die Dateien lokal oder auf Commons liegen. Was muss getan werden, um dies auch hier zu erhalten? Kann en:MediaWiki:Gadget-popups.js übernommen werden? --Leyo 11:43, 25. Feb. 2012 (CET)

Unter mw:RL/MGU#Keep_gadgets_central findet sich eine Möglichkeit, wie man das Zentral laden könnte. Ich weiß allerdings nicht ob es damit auch bei uns funktioniert. Der Umherirrende 23:32, 25. Feb. 2012 (CET)

Würden damit MediaWiki:Gadget-navigation-popups.js/de, MediaWiki:Gadget-navigation-popups.js/de-at oder MediaWiki:Gadget-navigation-popups.js/de-ch noch immer berücksichtigt? --Leyo 10:14, 27. Feb. 2012 (CET)

Nein, aber … --Schnark 10:26, 27. Feb. 2012 (CET)

Also so:

importScriptURI('//de.wikipedia.org/w/index.php?title=MediaWiki:Gadget-navigation-popups.js/de' + '&action=raw&ctype=text/javascript');
importScriptURI('//en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-popups.js' + '&action=raw&ctype=text/javascript');

@import url('//en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-navpop.css&action=raw&ctype=text/css');

--Leyo 10:21, 28. Feb. 2012 (CET)

Statt importScriptURI würde ich mw.loader.load nehmen und die Strings direkt zu einem zusammenfassen, aber ja, so sollte es funktionieren. --Schnark 11:44, 28. Feb. 2012 (CET)

Um sicher zu sein, nicht Hunderten von Benutzern durch Einfügen des Codes in MediaWiki:Gadget-navigation-popups.js das Gadget kaputt zu machen, wäre es wohl besser, du würdest angeben, wie genau die Strings zusammengefasst werden müssten… --Leyo 11:57, 28. Feb. 2012 (CET)

Ich denke mal, es ging Schnark nur um das plus-Zeichen was eigentlich unnötig ist, aber es ermöglich, den Zeilenumbruch selber zu platzieren. Bitte auch angeben, ob man ungefährlich den ResourceLoader aktivieren könnte (Vermutlich nicht, weil FF10-Problem). Der Umherirrende 20:30, 28. Feb. 2012 (CET)

Ja, das meinte ich mit "zusammenfassen". RL wird wohl tatsächlich erst mit MW1.19 bugfrei gehen, vielleicht bietet es sich auch an, mit der Umstellung bis zum Update zu warten, dann kann man bei Problemen behaupten, dass man selber gar nicht schuld daran war ;-) --Schnark 09:12, 29. Feb. 2012 (CET)

OK, das Update sollte ja eigentlich in absehbarer Zeit kommen. --Leyo 09:34, 29. Feb. 2012 (CET)

MW 1.19 kam tatsächlich in absehbarer Zeit. :-) Schnark, wie sieht es nun mit deiner Vorhersage aus? --Leyo 17:41, 20. Mär. 2012 (CET)

Spricht etwas dagegen, die 3. Zeile in JS-Code umzuwandeln?

mw.loader.load('//de.wikipedia.org/w/index.php?title=MediaWiki:Gadget-navigation-popups.js/de&action=raw&ctype=text/javascript');
mw.loader.load('//en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-popups.js&action=raw&ctype=text/javascript');
mw.loader.load('//en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-navpop.css&action=raw&ctype=text/css','text/css');

--Leyo 10:19, 26. Mär. 2012 (CEST)

Es könnte Auswirkungen auf Benutzer haben, die in ihrer eigenen CSS-Datei einzelne Dinge überschreiben, aber darüber würde ich mir erst Gedanken machen, wenn sich jemand beschwert. --Schnark 11:23, 27. Mär. 2012 (CEST)

Mit spielt es keine Rolle, welche Variante umgesetzt wird. Aktuell wird das CSS durch MediaWiki:Gadget-navigation-popups.js mittels

importStylesheet('MediaWiki:Gadget-navigation-popups.css');

geladen. --Leyo 11:33, 27. Mär. 2012 (CEST) PS. Wie sieht es nun bezüglich MW 1.19 und RL aus?

Die Variante, alle drei Dateien per JS zu laden sollte wohl funktionieren, probier es einfach aus. Ein Bug im RL, der dabei den IE zum Absturz (!) gebracht hätte, ist seit 1.18 behoben, weitere Probleme sind mir nicht bekannt. Globale Gadgets werden zwar seit langem versprochen, aber daran glaube ich erst, wenn sie wirklich implementiert sind, so sieht es da derzeit aus. --Schnark 09:15, 29. Mär. 2012 (CEST)

Nachdem der Test in der als-WP erfolgreich war, habe ich MediaWiki:Gadget-navigation-popups.js ersetzt. Bei mir funktioniert alles bestens und die neue Version ist viel schneller! MediaWiki:Gadget-navigation-popups.css könnte nun gelöscht oder geleert werden. --Leyo 10:12, 29. Mär. 2012 (CEST)

Verlorengegangenes Feature

Auf den Hinweis von Leyo hin werde ich hier mit der Bitte vorstellig, ein beim Update verlorengegangenes, aber für mein Empfinden äußerst sinnvolles und nur schwer verzichtbares Feature wieder einzufügen: die Option, unter "Aktionen/Links auf diese Seite" sofort im selben Fenster die entsprechenden Links zu sehen und nicht erst den Link anklicken zu müssen. Es war immer äußerst komfortabel, sich diesen Arbeitsschritt beim Überprüfen von Wikilinks ersparen zu können. Dass dies nun wegfallen soll, finde ich sehr ärgerlich; daher würde ich herzlich darum bitten, dass jemand mit der entsprechenden Kenntnis da tätig wird. Noch eine Frage dazu: Ist es richtig, dass das "Beobachten/Entbeobachten" jetzt wieder im selben Fenster angezeigt wird und die vor einiger Zeit eingeführte Abfrage im neuen Fenster/Tab wieder weggefallen ist? Da gab es doch seinerzeit irgendwelche Sicherheitsbedenken, wenn ich mich recht entsinne. --Scooter ^Backstage 00:14, 31. Mär. 2012 (CEST)

Über ein kompetentes Feedback auf meine Anfrage würde ich mich sehr freuen. --Scooter ^Backstage 10:35, 6. Apr. 2012 (CEST)

Vielleicht lässt sich das lokal irgendwie übersteuern.

Was mir in diesem Zusammenhang aufgefallen ist: Bei der lokalen Beobachtungsliste passiert „nichts“, wenn man mit der Maus auf Beiträge fährt. In der en-WP hingegen bewirkt ein Hovern über contribs, dass Popups die Beitragsliste ausklappt. Wie dieser Unterschied zustande kommt, obwohl hier dasselbe Gadget übernommen wird, ist mir unklar. --Leyo 18:54, 10. Apr. 2012 (CEST)

Dasselbe Gadget, unterschiedliche Links in de und en. Zum Beispiel auf der Beobachtungsliste:

• en: <a href="/wiki/Special:Contributions/Isaidnoway" title="Special:Contributions/Isaidnoway">contribs</a>
• de: <a href="/wiki/Spezial:Beitr%C3%A4ge/Silvicola" title="Spezial:Beiträge/Silvicola">Beiträge</a>/Silvicola"

Ersetze ich in der deutschen Beo in allen Links die Vorkommen von Spezial:Beitr%C3%A4ge mit Special:Contributions klappt es. Ist bisher in Navigation-Popups.js nicht lokalisierbar, das wurde auch schon mal angesprochen unter MediaWiki_talk:Gadget-popups.js#i18_for_Special:Contributions und Wikipedia_talk:Tools/Navigation_popups#Localization_for_Special:Contributions_and_Special:WhatLinksHere. Ist aber unbearbeitet geblieben, soweit ich sehe, man müsste wohl erneut jammern nachfragen. --Ivla^Disk. 22:02, 12. Apr. 2012 (CEST)

Nach 14 Tagen ohne weiteren Beitrag in diesem Thread erlaube ich mir mal nachzufragen, ob jemand an entsprechender Stelle "gejammert" hat und ob es Erfolg gezeitigt hat. --Scooter ^Backstage 10:51, 26. Apr. 2012 (CEST)

• Ich habe mir das mal kurz angeschaut.
• Eine derart komplexe Angelegenheit von 7766 Zeilen lässt sich nicht in einer Viertelstunde durchschauen, erst recht nicht wenn ich dieses Tool noch nie benutzt habe und das auch nicht beabsichtige.
• Ich vermute, dass ich weiß woran dies liegt und wie es zu beheben wäre. Zur gefälligen Weiterverbreitung setze ich in englischer Sprache fort.

• When accessing pages in non-English basic language URLs are localized. E.g. "/wiki/Special:Contributions/" is accessed by "/wiki/Spezial:Beitr%C3%A4ge/" which has the title Spezial:Beiträge.
• On the first glance it appears to me that in editPreviewTable() the col3url= should be assigned to something like

 mw.util.wikiUrlencode(
      mw.config.get('wgFormattedNamespaces')[pg.nsSpecialId]
      + ':'
      +  popupString('contributions')
   ) + '&target='

• .re.contribs. has been built by setRegexps() by using mw.config.get('wgFormattedNamespaces')[pg.nsUserId] – it seems to me that this needs to be URLencoded also, best mw.util.wikiUrlencode(). While in German the words Spezial or Benutzer do not require escaping, that might happen in some language around the world.

Greetings en:User:PerfektesChaos 20:41, 26. Apr. 2012 (CEST)

• "Beiträge" benötigt Escaping auch in pg.re.contribs. Gerade hat jemand dort eine nahezu gleiche Lösung vorgeschlagen, in dem Fall mit einer neuen Variablen 'Contributions'. Ich hatte auch schon experimentiert, an sich reicht schon die Veränderung der RE, ohne die URL im Menü zu ändern (Diff).
• 'contributions' zu nehmen geht vielleicht nicht in allen Fällen, darin steht ja die Übersetzung fürs Menü von Navigation-Popups, könnte in einigen Sprachen vom Namen der Spezialseite abweichen. Und wo es keine Übersetzungen für die Menüs gibt greift das gar nicht.
• Noch lieber würde ich den lokalisierten Seitennamen irgendwie auslesen. {{#speciale:contributions}} liefert Spezial:Beitr%C3%A4ge; in http://sv.wikipedia.org/w/api.php?action=query&titles=Special:Contributions&prop=pageprops ist Special:Bidrag immerhin enthalten. Kommt man mit JavaScript irgendwie da ran? mw.?, jQuery?
• Um auch noch auf Scooters What links here einzugehen: das ist fürs Menü wohl durch eine Änderung in der Groß/Kleinschreibung letztes Jahr kaputtgegangen (funktionierte jetzt auch auf en-WP nicht mehr), der RE ein ignore-case mitzugeben reichte schon. @Scooter: Wurden da auch früher schon nur 10 Links angezeigt? --Ivla^Disk. 01:41, 29. Apr. 2012 (CEST)

Sorry, dass ich erst jetzt antworte. Ja, das war früher auch schon so. Wäre sonst auch vermutlich etwas unübersichtlich bei sehr stark verlinkten Artikeln. Die zehn reichen ja oftmals schon aus. --Scooter ^Backstage 19:18, 11. Mai 2012 (CEST)

• In der /de steht in der Zeile drüber schon ein contribs="Beiträge" – so wie mir das aussieht, wäre dieser für sichtbare Beschriftungen zu verwenden, das bereits vorhandene contributions="Beiträge" dagegen für die Identifikation von URL. Umbenennung in etwas aussagekräftigere Identifikatoren wäre hilfreich.
• Eine Liste der Namen für Spezialseiten gibt es nicht im mw-JS, nur die projekt-lokalen Namen der Namensräume. Ist aber auch nicht erforderlich, weil ja ohnehin bereits eine L10N-Seite für das GUI vorhanden ist, wo man die spezifischen Namen reinschreiben kann; notfalls kann man switchen, wenn Wikisource und WP unterschiedliche Bezeichner innerhalb derselben Sprache verwenden würden. Glaub ich aber nicht.
• Ich würde empfehlen, in die L10N-Unterseiten menschenlesbare Seiten-Bezeichner hineinzuschreiben (man findet Schreibfehler leichter) und das Encoding vom Skript erledigen zu lassen; das kann das besser. Beachte, dass mein o.a. Vorschlag gleichzeitig auch den Namensraum encoded; wie ich schrieb, hat das zwar für de keine Bedeutung, spätestens aber bei Internationalisierung im Russischen oder Arabischen.
• Bei einem Gebilde dieser Größe wäre eine Programmierer-Doku unvermeidlich; ich hatte danach geguckt, konnte aber keine finden.

Vänliga hälsningar --PerfektesChaos 09:44, 29. Apr. 2012 (CEST)

@Ivla: Anstatt dies kann ich dies empfehlen. Dann hast du alle Spezialseitennamen auf einmal. en:User:Lupin/popups scheint auch schon älter zu sein. Ob es eine Entwicklerdoku gibt, kann ich auch nicht sagen. Ich habe mir das ganze nie angeschaut. Der Umherirrende 16:41, 29. Apr. 2012 (CEST)

Hätte die unter en:MediaWiki talk:Gadget-popups.js#i18 for Special:Contributions diskutierte Änderung unser Problem nicht (teilweise) lösen sollen? Ich sehe keinen Unterschied. --Leyo 23:43, 14. Mai 2012 (CEST)

• Man hat ein neues 'Contributions' mit großem C eingeführt für die URL.
• /de liefert noch das 'contributions' mit kleinem c.
• Wofür jetzt noch 'contributions' mit kleinem c gut sein soll, steht dahin. Es wird nirgends mehr benutzt.
• Als dritte Variante gibt es 'contribs' für Beschriftungen.
• Dokumentation wäre mal nicht schlecht, zentral auf *en. Ein //Comment würde ja reichen.
• Ich merkte bereits an, dass
  • der aus der Site-Konfiguration ausgelesene Namensraum [pg.nsSpecialId] noch nicht encoded ist; könnte Spéciale heißen und dann stimmt die URL wieder nicht. Erst recht auf Russisch.
  • Soweit ich das verstanden habe, wird das Ding tätig, falls die vorgefundene URL exakt mit den Erwartungen übereinstimmt. Dann würde ich sicherheitshalber routinemäßig und der Klarheit halber dazu raten, mw.util.wikiUrlencode() statt mw.util.rawurlencode() zu verwenden. Damit lässt sich auch Title.prototype.urlString() eleganter schreiben. Weil .wikiUrlencode() den Doppelpunkt in Ruhe lässt, kann man damit den ganzen Ausdruck ...[pg.nsSpecialId]+':'+popupString('Contributions') dann in einem Stück encoden.

Enjoy --PerfektesChaos 09:28, 15. Mai 2012 (CEST)

Danke für deine Analyse! IMHO wäre es wohl am zielführendsten, wenn die Punkte gleich unter en:MediaWiki talk:Gadget-popups.js#i18 for Special:Contributions eingebracht würden. Mir fehlt leider das Fachwissen dazu. --Leyo 11:55, 16. Mai 2012 (CEST)

Tja, und mir fehlen Nerv und Zeit und Lust, um auf der enWP über ein Tool zu talken, das ich noch nie benutzt habe und wohl nie benutzen werde.

• Oben hatte ich mich schon mal ins Englische übersetzt; daraufhin hieß es, da hätte schon jemand die gleiche Idee gehabt.
• Ich kann’s hier auch wieder zum statement für’s C&P umschreiben; aber die enWP beobachten und drängeln usw. macht bitte jemand anders.

Schönen Abend --PerfektesChaos 20:42, 16. Mai 2012 (CEST)

Ich würde es begrüssen, wenn Benutzer:Ivla, der sich gut mit Popups auskennt, diese Sache gelegentlich angehen könnte. --Leyo 01:11, 19. Mai 2012 (CEST)

Gibt es irgendeine neue Entwicklung zu diesem Thema? Am Status quo hat sich ja leider nichts geändert. --Scooter ^Backstage 23:48, 29. Mai 2012 (CEST)

Probleme mit dem IE 8

Atamari meldete, dass seit der Umstellung auf die aktuellen Version der en-WP im IE 8.0 Probleme auftreten: der gelbe Hintergrund sei nicht mehr vorhanden, die Menüs funktionierten nicht, würden komplett dargestellt und verschwänden nicht mehr. Das sieht nach einem CSS-Problem aus, zumindest teilweise. --Leyo 00:20, 3. Apr. 2012 (CEST)

Könnte es das Problem lösen, wenn das CSS nicht mittels JS, sondern direkt mittels

@import url('//en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-navpop.css&action=raw&ctype=text/css');

(siehe weiter oben) geladen wird? --Leyo 23:29, 9. Apr. 2012 (CEST)

Es gibt wohl einen jQuery-Bug, der auftritt wenn im IE Stylesheets mit relativen URLs geladen werden([4]). Als Workaround kann entweder eine absolute URL oder importStylesheetURI benutzt werden:

mw.loader.load(location.protocol + '//en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-navpop.css&action=raw&ctype=text/css', 'text/css');
// oder
importStylesheetURI('//en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-navpop.css&action=raw&ctype=text/css');

Gruß --P.Copp (Diskussion) 01:35, 10. Apr. 2012 (CEST)

Vielen Dank für deine Analyse! Siehst du bei einer Variante mehr Vorteile? --Leyo 01:47, 10. Apr. 2012 (CEST)

Persönlich gefällt mir zwar die kürzere Variante besser, aber so viel ich weiß gibt es Bestrebungen, die veraltenden Funktionen aus wikibits nicht mehr in Gadgets zu verwenden, daher ist wohl die erste Variante die zukunftssicherere. --P.Copp (Diskussion) 18:32, 10. Apr. 2012 (CEST)

Danke für die Antwort! Ich hab's übernommen. --Leyo 18:46, 10. Apr. 2012 (CEST)

Danke für den Hinwies. Das Tool verhält sich im IE8 nun wieder so, wie ich es gewohnt war. Danke für die Analyse und Bugfix. --Atamari (Diskussion) 20:46, 10. Apr. 2012 (CEST)

Halbautomatische Sichtungen

Hallo zusammen! Gibt es ein Skript, mit dem ich mehrere Bearbeitungen desselben Benutzers auf einmal als gesichtet markieren kann, ohne dass ich mir dabei die Versionsunterschiede anschauen muss? Grüße --Iste (D) 16:50, 10. Mär. 2012 (CET)

Hallo, das sollte wenig Sinn machen, daher glaube ich wohl nicht.Vorlage:Smiley/Wartung/:p  (Es sei denn ich habe falsch verstanden wie du das meinst...) -- πϵρήλιο ℗ 12:52, 11. Mär. 2012 (CET)

Na ja, ich bin hier schon mehrmals auf IPs oder neu angemeldete Benutzer gestoßen, die viele gleichartige konstruktive Bearbeitungen getätigt haben. Es gibt Fälle, in denen man mE nicht jeden Edit einzeln kontrollieren muss, um die Versionen als offensichtlich vandalismusfrei markieren zu können. Grüße --Iste (D) 19:27, 11. Mär. 2012 (CET)

Commonsfähige Logos

Gibt es eine Möglichkeit, commonsfähige Logos per Script mit „|Commons=Ja“ zu markieren (siehe WD:LFB)? Grüße Brackenheim 18:00, 12. Mär. 2012 (CET)

MediaWiki Diskussion:Gadget-toolserver-integration.js#Neue Programmierung

Zur Kenntnis. --Leyo 11:41, 23. Mär. 2012 (CET)

Hilfe bei Benutzer:TMg/autoFormatter.js

Hallo. Obiges Benutzerskript, das auch von anderen mitbenutzt wird, geht nicht mehr richtig. Ich war besonders stolz darauf, dass ich es geschafft hatte, in allen Skin- und Werkzeugleisten-Kombinationen einen Button in die Werkzeugleiste zu bringen: Es funktionierte sogar unabhängig davon, ob man im Vector-Skin die alte oder die neue Toolbar aktiviert hatte (das ist der Teil mit isSupported). Jetzt fällt alles auf den Fallback zurück, der einen Textlink unter dem Bearbeiten-Fenster erzeugt.

Die Hilfeseite mw:Extension:WikiEditor/Toolbar customization ist voll von „das Folgende funktioniert nicht mehr“-Hinweisen. Klar ist, dass ich $j.fn.wikiEditor in $.fn.wikiEditor ändern muss, und weiter? Wie fange ich den Fall „Vector mit alter Werkzeugleiste“ ab? --TMg 10:27, 30. Mär. 2012 (CEST)

Sieht nach Problemen mit der Ladereihenfolge aus, versuch es mal mit

$(function () {
  if ($.fn.wikiEditor && $.wikiEditor.isSupported($.wikiEditor.modules.toolbar)) { //WikiEditor
    $('#wpTextbox1').wikiEditor('addToToolbar', {
     'section': 'main', /* oder advanced */
     'group': 'format',
     'tools': {
       'autoFormatter': {
         'label': 'Auto-Format',
         'type': 'button',
         'icon': '//upload.wikimedia.org/wikipedia/commons/thumb/2/2c/Broom_icon.svg/22px-Broom_icon.svg.png',
         'action': {
            'type': 'callback',
            'execute': function() { return doAutoFormat(this); }
         }
       }
     }
    });
  } else if (mw.toolbar) { //alte Werkzeugleiste
    mw.toolbar.add('//upload.wikimedia.org/wikipedia/commons/2/2e/Button_broom.png',
                   'Auto-Format',
                   '', '', '',
                   'mw-customeditbutton-autoFormatter');
    $('#mw-customeditbutton-autoFormatter').click(function() { return doAutoFormat(this); })
  } else { //Fallback
		var f = document.getElementById('editform');
		if (f) {
		var a = document.createElement('A');
		a.href = '#';
		a.onclick = function() { return doAutoFormat(this); }
		a.appendChild(document.createTextNode('Auto-Format'));
		var s = f.getElementsByTagName('SPAN');
		for (var i = s.length - 1; i >= 0; i--) if (s[i].className === 'editHelp') { s = s[i]; break; }
		s.appendChild(document.createTextNode(' | '));
		s.appendChild(a);
		}
  }
});

Das ist immer noch etwas leichtsinnig, aber so viel Leichtsinn erlaube ich mir selbst auch.. --Schnark 11:14, 30. Mär. 2012 (CEST)

Ich seh jetzt irgendwie keinen Unterschied. $.fn.wikiEditor, $.wikiEditor und $('#wpTextbox1').wikiEditor sind komplett undefiniert zu dem Zeitpunkt, zu dem der Code aufgerufen wird. Sogar mw.toolbar ist undefiniert. Es fällt also alles zurück auf den Fallback, was in gewisser Weise sogar besser ist als meine bisherigen Versuche, die (jedenfalls bei der alten Toolbar) in einem disfunktionalen Button endeten. --TMg 11:25, 30. Mär. 2012 (CEST)

Ach wäre dieser Computer hier doch nur auch so schnell, wie deiner sein muss … Dann halt

function init_wikieditor () {
  if ($.wikiEditor.isSupported($.wikiEditor.modules.toolbar)) {
    $(function() {
      $('#wpTextbox1').wikiEditor('addToToolbar', {
       'section': 'main', /* oder advanced */
       'group': 'format',
       'tools': {
         'autoFormatter': {
           'label': 'Auto-Format',
           'type': 'button',
           'icon': '//upload.wikimedia.org/wikipedia/commons/thumb/2/2c/Broom_icon.svg/22px-Broom_icon.svg.png',
           'action': {
              'type': 'callback',
              'execute': function() { return doAutoFormat(this); }
           }
         }
       }
      });
    });
    return true;
  } else {
    return false;
  }
}

function init_toolbar () {
  mw.toolbar.add('//upload.wikimedia.org/wikipedia/commons/2/2e/Button_broom.png',
                 'Auto-Format',
                 '', '', '',
                 'mw-customeditbutton-autoFormatter');
  $(function() {
   $('#mw-customeditbutton-autoFormatter').click(function() { return doAutoFormat(this); })
  });
}

function init_fallback () {
	var f = document.getElementById('editform');
	if (!f) return;
	var a = document.createElement('A');
	a.href = '#';
	a.onclick = function() { return doAutoFormat(this); }
	a.appendChild(document.createTextNode('Auto-Format'));
	var s = f.getElementsByTagName('SPAN');
	for (var i = s.length - 1; i >= 0; i--) if (s[i].className === 'editHelp') { s = s[i]; break; }
	s.appendChild(document.createTextNode(' | '));
	s.appendChild(a);
}

function init () {
  if (mw.user.options.get('usebetatoolbar') {
     mw.loader.using('ext.wikiEditor.toolbar', function () {
        init_wikieditor() || mw.loader.using('mediawiki.action.edit', init_toolbar);
     });
  } else if (mw.user.options.get('showtoolbar') {
     mw.loader.using('mediawiki.action.edit', init_toolbar);
  } else {
     $(init_fallback);
  }
}

init();

Ich habe nicht die Sytax geprüft, fehlende geschweifte Klammern sind nicht auszuschließen. --Schnark 11:45, 30. Mär. 2012 (CEST)

Hilft mw.loader.getState("jquery.wikiEditor") in Kombination mit mw.loader.using weiter? -- ✓ ^Bergi 14:17, 30. Mär. 2012 (CEST)

Das mw.loader.using und die dazu benötigten Parameter waren für mich ausschlaggebend. Vielen herzlichen Dank, darauf wäre ich nie gekommen. Auch die Abfrage der options war mir neu. Dafür habe ich das isSupported entfernt (keine Ahnung, wo ich das mal her hatte), das scheint redundant zu sein. In meinem Opera scheint es jetzt in allen vier fünf relevanten Konstellationen zu funktionieren: Mit Monobook- und Vector-Skin jeweils mit alter und neuer Toolbar sowie ganz ohne Toolbar. --TMg 21:41, 30. Mär. 2012 (CEST)

Das isSupported ist wichtig, falls jemand die Werkzeugleiste aktiviert hat, aber einen Browser verwendet, der nicht kompatibel ist. --Schnark 10:26, 31. Mär. 2012 (CEST)

Hast Recht, Stichwort IE6. Ich arbeite sowieso an einer komplett neuen Version, da werde ich das wieder einbauen. Danke für den Hinweis. --TMg 14:26, 31. Mär. 2012 (CEST)

Tab Beschriftung

Gibts eine Möglichkeit die Beschriftung der Tabs zu ändern? Beispiel:

• anstatt "Abschnitt hinzufügen", hätte ich da lieber ein schlichtes "+"
• anstatt "Versionsgeschichte", wäre mit ein "Autoren" lieber

Ich bräuchte einfach mehr Platz, da über meine vector.js noch andere Tabs eingebunden werden.

Gibts da was?

LG Lady Whistler (Disk|Bew) 11:56, 4. Apr. 2012 (CEST)

Füge in deine vector.js folgenden Code ein:

$(function() {
 $('#ca-addsection a').text('+');
 $('#ca-history a').text('Autoren');
});

Ich kann aber nicht erkennen, wie diese Umbenennung im Vector-Skin zu irgendeiner sinnvollen Platzersparnis führt. --Schnark 12:10, 4. Apr. 2012 (CEST) PS: Was soll das heißen, dass meine imagepopups.js nicht funktionieren soll?

Oh, danke, das ging aber schnell ;-)

Da ich noch weitere eigene Tabs nach "EX" und "MA" in meiner Leiste hinzufügen will, ergibt sich dafür nach der Umbeschriftung einfach mehr Platz.

Warum Imagepopups nicht funktioniert weiß ich nicht, richtig eingebunden habe ich es wohl?

LG Lady Whistler (Disk|Bew) 12:28, 4. Apr. 2012 (CEST)

Ah, das addPortletLink ('p-namespaces', ... sehe ich erst jetzt, netter Trick.

Wie äußert sich denn das Nicht-Funktionieren von imagepopups.js? Früher gab es mal einen MW-Bug, der dazu führte, dass das Skript den IE zum Absturz brachte, außerdem gibt es einen recht verzwickten Fehler, der in sehr speziellen Situationen dazu führt, dass nur noch weiße Seiten angezeigt werden, und sämtlicher Inhalt fehlt. Aber ansonsten sind mir keine Fehler bekannt, bei mir funktioniert es. --Schnark 12:40, 4. Apr. 2012 (CEST)

Ich nutze FF 10.0, es gibt keine Fehlermeldung, es verhält sich als hätte ich das Script einfach nicht eingebunden, evtl. "beißt" es sich mit irgendeinem anderen Script?

LG Lady Whistler (Disk|Bew) 12:49, 4. Apr. 2012 (CEST)

Stell mal die ganzen document.writes um auf importScript (einfach den title nehmen), dann bin ich vielleicht bereit, das morgen zu debuggen, alles andere läuft bei mir ohne Probleme zusammen. --Schnark 12:56, 4. Apr. 2012 (CEST)

Sooo? Lady Whistler (Disk|Bew) 13:06, 4. Apr. 2012 (CEST)

Ja, [5] funktioniert bei mir (FF3), bis auf:

• Benutzer:Euku/Mentorenprogramm.js ist veraltet, produziert daher Fehler und verhindert damit das Funktionieren anderer Skripte (insbesondere imagepopups.js). Mach dir nicht allzuviel Hoffnung, dass sich daran etwas ändern wird, die Fehlermeldung wurde unbearbeitet archiviert.
• Benutzer:APPER/fr check gibt es nicht mehr, stattdessen könntest du Benutzer:P.Copp/scripts/markunreviewed.js verwenden.

--Schnark 09:56, 5. Apr. 2012 (CEST)

Habe die beiden Scripte auskommentiert und Imagepopup funktioniert jetzt - allerdings funktioniert jetzt das eingebundene Benutzerin:Lady Whistler/export.js mit meinen Extra-Buttons nicht mehr ;-(

LG Lady Whistler (Disk|Bew) 06:42, 6. Apr. 2012 (CEST)

(hier könnte ein sehr lauter Entsetzensschrei stehen) Das Skript sollte so aussehen:

mw.loader.using('mediawiki.action.edit', function () { //<nowiki>
  mw.toolbar.addButton(
    'http://images1.wikia.nocookie.net/central/images/b/b4/Button_category03.png',
    'Kategorie',
    '[[Kategorie:',
    ']]',
    ''
  );
  mw.toolbar.addButton(
    'http://upload.wikimedia.org/wikipedia/commons/4/47/Button_redir.png',
    'Weiterleitung',
    '#REDIRECT [[',
    ']]',
    ''
  );
//usw.
}); //</nowiki>

--Schnark 09:50, 7. Apr. 2012 (CEST)

"hier könnte ein sehr lauter Entsetzensschrei stehen" --> halt nur ein DAU bin und da es ja funktioniert hat ...

Ich habe die Benutzerin:Lady Whistler/export.js jetzt wie von dir beschrieben geändert, aber irgendwie ist immer noch der Wurm drin, Imagepopup funktioniert, aber alles aus export.js wird nicht angezeigt, vielleicht hab ich noch irgendwo einen Tippfehler drin?! *heul*

LG Lady Whistler (Disk|Bew) 13:12, 7. Apr. 2012 (CEST)

Vor zwei Jahren war deine Methode auch noch die einzig mögliche (auch wenn die Probleme, die heute damit auftreten auch damals schon möglich waren). Was ich dir empfohlen habe, funktioniert erst seit ein paar Monaten problemlos. Mein Entsetzensschrei war daher auch nicht so ganz ernst gemeint.

Bei Export fürs Vereins-Wiki hast du einfach nur vergessen, die erste Zeile zu ändern, das führte dann natürlich zu Syntaxfehlern und dazu, dass gar nichts mehr funktionierte. --Schnark 09:28, 10. Apr. 2012 (CEST)

Eigener Zeichensatz; helpwindow-Text

Hallo Werkstatt,

ich hab 2 Fragen zur CSS-Formatierung.

1) Ist es möglich einen eigenen Zeichensatz zu definieren, der Standardmäßig unten angezeigt wird?

2) Ich habe mit A[target="helpwindow"] die Bearbeitungshilfe ausgeblendet, sehe aber immer noch den Text "wird in einem neuen Fenster geöffnet" - wie bekomme ich den weg?

Vielen Dank --Carlos-X 14:01, 8. Apr. 2012 (CEST)

Hallo Carlos,

ich hab 2 Antworten:

1. Ich vermute, du meinst etwas, wie es hier beschrieben ist. Um welchen Zeichensatz ginge es denn?
2. Bei mir funktioniert es; ich vermute, du hast das aus WP:CSS #Hinweise und in deiner Benutzer:Carlos-X/vector.css steht es auch korrekt drin.
   • Du bist auch in vector?
   • A[target="helpwindow"] benötigt einen aktuellen Browser, der „CSS3“ kann – welchen hast du?
   • Setz mal den Block mit A[target="helpwindow"] ganz an den Anfang. Ich kann keinen Syntaxfehler entdecken, aber wenn vorher einer drinsteckt, geht das restliche CSS baden.

Frohe Feiertage --PerfektesChaos 15:06, 8. Apr. 2012 (CEST)

Nachtrag zu 2.):

Wenn du das links daneben stehende Link "Abbrechen" (es führt einfach auf die normale Seite zurück) nicht brauchst, kannst du es zusammen mit der Bearbeitungshilfe ziemlich sicher wegbekommen:

   .editHelp {
      display: none;
   }

Das Link auf "Bearbeitungshilfe" ist leider zurzeit nicht besser einzeln zu selektieren als mittels des neumodischen CSS3.

Schönen Tag --PerfektesChaos 20:43, 8. Apr. 2012 (CEST)

Redirect-Probleme

Von BD:Schnark#Ungewünschter Effekt Weiterleitung:

Hallo Schnark, ich wollte Dich nur mal kurz Fragen (als Fachmann sozusagen) ob Du eine Idee hast welches Skript die Weiterleitungslinks nach dem Weiterleiten oben links auf den Seiten entfernt? Des Weiteren kann ich beobachten, dass nach Weiterleitungen (und Shortlinks) mit Ankerlink die Seite beim Laden wieder nach oben springt. Das alles ist ungefähr seit mw.v.1.19 ich habe schon einige Zeit keine neuen Skripte bei mir hinzugefügt (ausgeloggt erscheint der Effekt nicht). Besten Gruß -- πϵρήλιο ℗ 14:11, 5. Apr. 2012 (CEST)

Schnark hat 24 Stunden nicht geantwortet; er dürfte offwiki sein, Ferien machen, und ich wünsche ihm viel Schnee.

So rücke ich mal stellvertretend einige Infos rüber:

• Es gab kürzlich vielleicht dewiki-Änderungen im Zusammenhang mit der in MW 1.19 neu eingeführten wgRedirectedFrom – siehe MediaWiki Diskussion:Gadgets-definition #Benutzer:Flominator/Weiterleitungshinweis.js und Vorlage und CSS?.
• Es gibt einen Mechanismus redirectToFragment() in der wikibits.js welcher in dieser Situation tätig wird. Der ist allerdings nicht auf der Höhe der MW-Entwicklung. Grundsätzlich liefert er das bei WL (Shortcuts sind immer WL, daher der Name) zunächst fehlende Fragment an die umgebastelte URL wieder dran. Tatsächlich sieht man die Zielseite (und nicht die WL-Seite wie mit redirect=no), aber die URL in der Adresszeile wird umgeschmiedet auf die URL der WL-Seite, und danach wird dahinter ein ggf. vorhandenes Sprungziel mit redirectToFragment() wieder drangebastelt. Mit dem IE gab es da vor Jahren auch schon mal Probleme. Insgesamt kann ich mich dumpf daran erinnern, dass mir diese Methodik grundsätzlich nicht gefällt und hatte schon mal irgendwo darüber diskutiert.
• Mit deinen schnellen PC und dem asynchronen Chromium ist es gut möglich, dass die wikibits zu spät geladen werden, um einen fundamentalen Eingriff rechtzeitig für dein Rendering zu bauen, oder der Aufruf wird irgendwie verschlafen. In einem Paket mit mediawiki.user und mediawiki.util wird mediawiki.legacy.wikibits geladen, zusammen mit mediawiki.page.ready – was meiner Erfahrung nach ziemlich spät ist.
• Ich beobachte mit FF3 keine Probleme; Maschinchen sind Büro-Durchschnitt.
• Du kannst ja mal mit einer präziseren Problemschilderung (was steht in der URL?) in der TSW aufschlagen; vielleicht ist es sinnvoll, weltweit den mw.-Nachfolger von redirectToFragment in der mediawiki.page.startup unterzubringen und dies per Bugzilla anzuregen.
• Im Moment durchschaue ich grad noch nicht, wer wann dieses redirectToFragment eigentlich wo aufruft. Vielleicht muss man mal ins PHP gucken.

So, zurück jetzt an die frische Luft; Frohe Feiertage allerseits --PerfektesChaos 15:33, 6. Apr. 2012 (CEST)

Im Falle einer Weiterleitung wird in Article::showRedirectedFromHeader das InlineScript redirectToFragment("<fragment>"); hinzugefügt. Ob man da noch auf die Ladereihenfolge achten muss, kann ich nicht sagen, eine Modernisierung täte aber gut, da stimme ich dir zu. Der Umherirrende 16:11, 6. Apr. 2012 (CEST)

Mehr als hinzuzufügen, dass eine Bugzilla-Meldung zu redirectToFragment (und weiterem wikibits-Schrott) schon lange auf meiner Todo-Liste steht, kann ich nach den obigen ausgiebigen Ausführungen wohl nicht. --Schnark 09:27, 7. Apr. 2012 (CEST)

Hallo und Danke allerseits für die Antworten, die Tage werde ich wohl das Problem nicht genauer ergründen können (ich hatte insgeheim gehofft, dass das Problem kein allg. ist und sich konkret hier finden lässt). Ich bin mir aber sicher (nach euren detaillierten Antworten) wir werden die Ursache finden. Daher hier noch eine kurze Analyse: ein Problem-Bsp-Link: WP:TEX#Text; ja der Ankerlink wird aus der URL entfernt; auf Commons und En. gibt es den Effekt nicht; Firefox ist das Selbe; ich vermute daher einfach, dass irgendein Neuladen im Vector-Skin die Ursache ist (monobook ist alles in Ordnung, im Vector-Skin habe ich nur per jsmodules alle Skripte abgestellt), welches vielleicht sogar direkt im Zusammenhang mit dem Verschwinden des Redirect-Links steht. Allen angenehme sonnige Osterfeiertage. PS.: Redirects zu bearbeiten ist mir ohne den händischen Zusatz redirect=no nicht möglich.(Den Topic habe ich mal konkretisiert) -- πϵρήλιο ℗ 14:48, 7. Apr. 2012 (CEST)

Ich übertrage mal von BD nach WP:TSW#Redirect-Probleme und empfehle in diesem NR EOD. --PerfektesChaos 21:33, 9. Apr. 2012 (CEST)

• @Schnark: Bugzilla-Nr.?
• @Perhelion: Du müsstest in deinen Fehlermeldungen eigentlich irgendwo eine function not found: redirectToFragment haben?

Die Situation ist relativ klar: Auf dem asynchronen Chromium wird bereits das nachfolgende inline-Skript ausgeführt, während oben noch an dem Paket mediawiki.util+…+…+ mediawiki.legacy.wikibits herumgekaut wird; erst wenn dort zuletzt auch das redirectToFragment definiert worden wäre, könnte es ausgeführt werden. Dann ist der Renderer aber wohl schon durch.

• In vorherigen MW-Versionen wurde das addInlineScript auch in die Nähe des </BODY> geschrieben. Mit dem Gewusel um das zu späte Laden wurde in MW 1.19 alles nach oben in den </HEAD> verschoben, um mit dem Laden der Standardfunktionen früher zu beginnen. Fein. Dafür wird jetzt das redirectToFragment so früh ausgeführt, dass es das Ende des BODY noch nicht gesehen hat, und dass es auch die legacy.wikibits noch nicht kennt, wenn ein schneller Browser asynchron lädt. Perhelions Beobachtung betreffend MW 1.19 trifft also zu.
• Da das zeitabhängig ist, mag es auch in monobook und vector und mit mehr oder weniger Skripten in den Projekten zusammenhängen. Das ist letztlich egal weil bloßer Zufall.

Die Lösung liegt auch auf der Hand:

1. In dem generierten Inline-Skript darf nicht eine externe Funktion aufgerufen werden, sondern die paar Statements müssen direkt in das Inline-Skript aufgenommen werden, wobei der aktuelle Wert für fragment ja bekannt ist.
   • Also nicht mehr: $wgOut->addInlineScript( "redirectToFragment(\"$fragment\");"
   • addOnloadHook ist dem wikibits zwar schon bekannt, darf aber nicht inline stehen; aus dem gleichen Grund.
2. Wenn der Ort der Inline-Einbindung an das Ende des BODY verlegt wird, kann man sich auch die Aktion mit dem addOnloadHook sparen.
   • addInlineScript() stammt aus svn:trunk/phase3/includes/OutputPage.php OutputPage.php und $this->mScripts geht nicht mehr zwingend in die getScriptsForBottomQueue() sondern in den HEAD.
3. Der Grund, warum gemäß dem Bug von 2009 Mozilla nicht springt, ist, dass zu diesem Zeitpunkt das Fragment im BODY noch nicht gelesen worden war. Dann sagt Mozilla verständlicherweise, dass die Aktion sinnlos sei, weil das Fragment im document nicht existieren würde, und verweigert die Ausführung. Steht man aber unmittelbar vor dem </BODY>, dann wäre ein existierendes Fragment auch bekannt, und nur dann ist ein Scroll überhaupt sinnvoll. Was anderes macht das olle hook auch nicht. Das gilt für alle Browser; bevor sie da unten angekommen sind, können die anderen auch nicht scrollen.
   • Es muss also von OutputPage::showRedirectedFromHeader der Mechanismus für das Inline-Skript benutzt werden, der auch runOnloadHook() in unmittelbare Nähe des </BODY> schreibt/schrieb.
4. @Perhelion: Was war jetzt mit dem händischen Anhängen von redirect=no an die URL? Ursache in gleicher Ecke oder kommt das von irgendwo anders?

Angenehme Woche --PerfektesChaos 21:57, 9. Apr. 2012 (CEST)

wikibits wird synchron geladen, daher kann das wohl nicht die Ursache sein. Ich denke eher, dass die folgenden Zeilen in Benutzer:Perhelion/vector.js schuld sind:

/* Redirect to the Commons File description page. Idea from [[WP:TSW]] */
$("head link").each(function () {
	if($(this).attr("rel") === "canonical")
		document.location.href = $(this).attr("href");
});

Dort fehlt noch eine Bedingung, dass nur weitergeleitet wird, wenn man sich auf einer Bildbeschreibungsseite befindet. Grüße --P.Copp (Diskussion) 23:23, 9. Apr. 2012 (CEST)

Wow Respekt! Vorlage:Smiley/Wartung/facepalm  Das ist mir gerade auch aufgefallen, Schande über mich, ich hatte nicht wirklich getestet. Ebend mit einen frischen Benutzer getestet und so die Gewissheit erhalten, dass meine vector.js schuld sein muss.Vorlage:Smiley/Wartung/:s  Nach Einbau der Bedingung geht wieder alles! Aber vielleicht hat das alles doch irgendwas bewirkt (wie Modernisierung...). Danke trotzdem! @PerfektesChaos: tut mir leid, ansonsten sieht das alles wirklich recht kompliziert aus... vielleicht war alles etwas zu zweideutig von mir beschrieben; wegen Letzterem hatte ich H:WL#Ändern einer Weiterleitung befolgt. -- πϵρήλιο ℗ 07:42, 10. Apr. 2012 (CEST)

• Die Geschichte ist natürlich völlig richtig, und das erklärt auch den monobook/vector/en/Commons-Unterschied. Für die Differenz monobook/vector war ich gestern Abend leider zu müde, sonst hätte ich dort noch nachgeguckt. P.Copp war da fitter.
  • Perhelion hat sicher in seiner Smiley-Sammlung noch eine knallrote Birne mit in-Grund-und-Boden-schäm?
• Ungeachtet dessen ist die Konstruktion mit dem Zugriff auf das veraltete wikibits und das noch veraltetere addOnloadHook sanierungsbedürftig; und das Inline-Skript sollte keinerlei Zugriff auf externe Skripte voraussetzen, sondern mit intrinsischen Browser- oder DOM-Funktionen auskommen. Schnark Beschreibung als „Schrott“ trifft zu.
• Dass im Moment versucht wird, synchrones Laden des betreffenden Pakets zu erzwingen, war ein last-minute-Notbehelf (oder eigentlich sogar später), der während der Umstellungsphase noch in MW 1.19 hineingeflickt wurde. Robust ist das nicht, und der nächste Bearbeiter, der hier in bester Absicht etwas an der Ladeprozedur macht, läuft sonst Gefahr, das oben beschriebene Problem unbemerkt wieder wachzuküssen; oder die nächste Chromium-Version setzt sich über das synchrone Laden hinweg. Immer noch wird auch mit document.write gearbeitet, dessen Nebenwirkungen nicht mehr zu kalkulieren sind.
• @Schnark: Die laufende Bugzilla-Nummer wäre?

Ruhige Teilwoche allerseits --PerfektesChaos 09:27, 10. Apr. 2012 (CEST)

"schon lange auf meiner Todo-Liste" = "noch immer nicht in Bugzilla". Falls mir jemand zuvorkommen will bitte als Blocker für bugzilla:33836 kennzeichnen. --Schnark 12:39, 10. Apr. 2012 (CEST)

Dass wikibits und diverse andere Skripte synchron geladen werden ist weder ein Notbehelf noch Zufall sondern zwingend notwendig dafür, dass zigtausende Benutzerskripte (nämlich so gut wie alle) weiterhin funktionieren. Daher wird sich daran auch in absehbarer Zeit nichts ändern. Ich gebe dir aber Recht, dass das Inline-Skript bei Gelegenheit ersetzt werden sollte => bugzilla:35858. Grüße --P.Copp (Diskussion) 18:28, 10. Apr. 2012 (CEST)

MediaWiki:Common.js/watchlist.js

Ich habe MediaWiki:Common.js/watchlist.js unter Benutzer:Fomafix/watchlist.js neu programmiert. Neben der Ersetzung veralteter Funktionen habe ich versucht das Ausblenden der Boxen während des Ladens per CSS zu erreichen, damit die Seite nach dem Laden nicht nochmal verrutscht. Allerdings weiß ich nicht, wie ich diese Funktion nun während des Ladens testen kann. Ich habe gerade gesehen, dass ✓ unter http://de.wikipedia.beta.wmflabs.org/wiki/MediaWiki:Common.js/watchlist.js bereits fast die gleiche Ersetzung der veralteten Funktionen vorgenommen hat. --Fomafix (Diskussion) 23:17, 9. Apr. 2012 (CEST)

Nur mal drübergeschaut: Mir fehlt da noch ein loader.using mit mediawiki.util und jquery.cookie. Mit Großbuchstaben beginnende Variablennamen sind mir persönlich nicht so lieb. Der dritte Parameter undefined wirkt überflüssig. Man könnte das CSS auch vereinfachen, wenn man die Rules kombiniert und dann nur noch ein display:none hat. Vielleicht komplett auf jQuery umsteigen? Du nutzt einmal setAttribute mit style und einmal obj.style. Auch wenn das letzter für nur ein Attribut einfacher ist, könnte man es einheitlich gestalten. Alles unverbindlich und nur wenn du es auch sinnvoll findest. Der Umherirrende 19:54, 11. Apr. 2012 (CEST)

Meine Überarbeitungen sind noch nicht abgeschlossen. Der Rahmen ist die Empfehlung von mw:Manual:Coding conventions/JavaScript#Closures, die restliche Programmierung ist noch nicht überarbeitet. Ich wollte zuerst Testen, ob CSS hier die gewünschte Verbesserung bringt. --Fomafix (Diskussion) 20:06, 11. Apr. 2012 (CEST)

Je nach Ergebnis von bugzilla:37187 würde ich statt dem Cookie lieber eine Benutzereinstellung sehen. --Schnark 10:21, 29. Mai 2012 (CEST)

Ja, wenn das inzwischen möglich ist, wäre das eine feine Sache. Vielleicht lässt sich das auch mit der neuen Funktion der Änderungen seit dem letzten Besuchen auch realisieren. Das wäre noch eleganter, denn das kommt ohne zusätzliche Speicherung von persistenten Daten aus und ist universeller. --Fomafix (Diskussion) 10:27, 29. Mai 2012 (CEST)

Kann über die API angefragt werden, was die letzte besuchte Revision einer Seite ist? Wenn ja wie? Den Besuchszähler kann man auf die aktuelle Revision setzten, indem man eine Seite besucht. Geht das auch über die API? --Fomafix (Diskussion) 09:51, 31. Mai 2012 (CEST)

Die Hilfe zu action=query&list=watchlist führt unter wlprop den Wert notificationtimestamp an: Adds timestamp of when the user was last notified about the edit, ein Update ist wohl über $.get('/w/index.php?title=...') möglich. Allerdings müsste man dazu alle Benutzer zwingen, eine bestimmte Seite zu beobachten; da man außerdem auf die Antwort der API warten müsste, würde es zudem zu sichtbaren Verzögerungen beim Ausblenden kommen. (Außer man blendet erst mal auf Verdacht aus, und dann je nach Antwort der API wieder ein.) --Schnark 10:08, 31. Mai 2012 (CEST)

Soviel habe ich inzwischen auch herausbekommen. wl_notificationtimestamp existiert nur, wenn die Seite in mw:Manual:Watchlist table ist. Zuerst müsste die Seite per API auf die Beobachtungsliste gesetzt werden, um das notificationtimestamp verwenden zu können. Das bringt mich auf eine andere Idee. Wäre es möglich das Einblenden und Ausblenden der Nachrichten über Einträge in der Beobachtungsliste zu steuern? Ich mache mir ein paar Gedanken. Auch das verzögerte Ein- oder Ausblenden ist ein wichtiges Thema. Derzeit geschieht Ausblenden auch etwas verzögert, weil JavaScript erst nach dem vollständigen Laden der Seite ausblendet. Ein zusätzlicher Request ist aber eine deutliche längere Verzögerung. --Fomafix (Diskussion) 16:05, 31. Mai 2012 (CEST)

Über notificationtimestamp wird das "Fette" auf der Beobachtungsliste oder die E-Mail-Benachrichtigung gesteuert. Dort steht der Timestamp der ersten Änderung, die man noch nicht gesehen hat. Per API kann man das aktuell nicht zurücksetzen (Bug 18758). Der Umherirrende 16:18, 31. Mai 2012 (CEST)

Toolbar

Hallo. Ich würde gerne einige Elemente außerhalb des Hauptfelds (Monobook-Skin), z.B. in der linken Spalte und die persönliche Leiste ganz oben, als Toolbar darstellen. Gibt es dazu schon Skripte ? ÅñŧóñŜûŝî (Ð) 14:13, 28. Mai 2012 (CEST)

Toolbar? Wie meinst du das?

Klingt erstmal nach reinem CSS. Auch die Leisten oben sind in der linken Spalte eingeordnet und werden bloß nach oben verschoben. -- ✓ ^Bergi 20:45, 28. Mai 2012 (CEST)

Nun, ich möchte z. B. statt der Menüpunkte im DIV-Tag class="portlet" id="p-personal", also die Links zu meiner Benutzerseite, D-Seite, Einstellungen Beo-Liste, etc. grafische Buttons ähnlich denen wie über dem Editfenster haben. Im Moment habe ich den Linktext mit einem Zeichen aus einem Symbole-Font ersetzt, aber das ist nicht so schön wie ich es mir wünsche. Ähnlich möchte ich es mit den Links in der linken spalte machen. ÅñŧóñŜûŝî (Ð) 21:08, 28. Mai 2012 (CEST)

Ich würde content:url(...); empfehlen. Damit kannst du per CSS statt dem Text eine Grafik anzeigen lassen, etwa:

#ca-history {
    content: url('http://upload.wikimedia.org/wikipedia/commons/thumb/d/d2/History.svg/20px-History.svg.png');
}

Dann noch (line-)height, padding und margin anpassen, für die linke Leiste vermutlich display:inline;. -- ✓ ^Bergi 22:46, 28. Mai 2012 (CEST)

Das überschreibt leider die Verlinkung (das A-Tag). Ich habe es mit

#ca-history a {
  content: url('http://upload.wikimedia.org/wikipedia/commons/thumb/d/d2/History.svg/20px-History.svg.png');
}

probiert. Das scheint zu funktionieren. ÅñŧóñŜûŝî (Ð) 23:50, 28. Mai 2012 (CEST) ÅñŧóñŜûŝî (Ð) 22:54, 28. Mai 2012 (CEST)

Sorry, bei mir hat das a-tag die Id gehabt - hätte ich doch mein Monobook ausschalten sollen :-) Schön wenns geht, -- ✓ ^Bergi 00:09, 29. Mai 2012 (CEST)

Monobook ausschalten ? Bei mir ist der Monobookskin aktiviert und die ID im Li-Tag. Jetzt bekomme ich nur die Reiterleiste ( #p-cactions) nicht richtig hin, weil ich gerne größere Icons möchte. während ich vertikal und die Höhe ganz gut einstellen kann, weis ich nicht, wie ich die Breite der Reiter und deren einzelne Position einstellen kann. ÅñŧóñŜûŝî (Ð) 00:11, 31. Mai 2012 (CEST)

Mein Monobook-Script, meinte ich – das schraubt nämlich gehörig an den Menüleisten rum und setzt schonmal ne id woandershin :-)

Die Breite passt sich doch automatisch an die Icons an? Zurzeit scheinst du #p-cactions-Icons aber eh nicht aktiviert zu haben. Außerdem würde ich empfehlen, das margin-top von div#content noch etwas zu erhöhen. -- ✓ ^Bergi 01:57, 31. Mai 2012 (CEST)

GeSHi für Wikitext

Bekanntlich gibt es noch keine Möglichkeit mit Hilfe:Syntaxhighlight MediaWikis Wikitext etwa auf Hilfeseiten mit einer Syntaxhervorhebung zu versehen. Das hat nur zum Teil etwas damit zu tun, dass es beinahe unmöglich ist, hauptsächlich liegt es aber daran, dass sich einfach noch niemand die Mühe gemacht hat, die entsprechende Syntaxhervorhebung zu programmieren. Deshalb habe ich jetzt mal einen Anfang gemacht, würde mich aber über Mithilfe sehr freuen. Wer helfen will, sollte sich zunächst einmal die Datei für HTML5 ansehen, dann die Dokumentation lesen. Zum Testen muss man MW+mw:Extension:SyntaxHighlight GeSHi installiert haben, das folgende als mediawiki.php bei den anderen Dateien speichern; dann funktioniert <syntaxhighlight lang="mediawiki">. Gleich als Vorwarnung, unser Wikitext hier ist keine Sprache, sondern ein großes Chaos, man sollte also nicht erwarten, dass die Syntaxhervorhebung wirklich gut funktioniert, man kann nur versuchen, dass es einigermaßen stimmt. Verbesserungen können gleich in den Code eingefügt werden, wenn dann alle hier zufrieden sind, schaue ich mal, dass ich den Entwickler von GeSHi davon überzeugen kann, das in die nächste Version aufzunehmen, und dann jemand bei MW finde, der unsere Erweiterung entsprechend aktualisiert. --Schnark 11:28, 1. Jun. 2012 (CEST)

<?php
/*************************************************************************************
 * mediawiki.php
 * ---------------
 * Author:
 * Copyright:
 * Release Version: 
 * Date Started: 
 *
 * MediaWiki wikitext language file for GeSHi.
 *
 * CHANGES
 * -------
 *
 * TODO
 * -------------------------
 *************************************************************************************
 *
 *     This file is part of GeSHi.
 *
 *   GeSHi is free software; you can redistribute it and/or modify
 *   it under the terms of the GNU General Public License as published by
 *   the Free Software Foundation; either version 2 of the License, or
 *   (at your option) any later version.
 *
 *   GeSHi is distributed in the hope that it will be useful,
 *   but WITHOUT ANY WARRANTY; without even the implied warranty of
 *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 *   GNU General Public License for more details.
 *
 *   You should have received a copy of the GNU General Public License
 *   along with GeSHi; if not, write to the Free Software
 *   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 *
 ************************************************************************************/

$language_data = array (
    'LANG_NAME' => 'Wikitext (MediaWiki)',
    'COMMENT_SINGLE' => array(),
    'COMMENT_MULTI' => array(),
    'CASE_KEYWORDS' => GESHI_CAPS_NO_CHANGE,
    'QUOTEMARKS' => array("'", '"'),
    'ESCAPE_CHAR' => '',
    'KEYWORDS' => array(
        1 => array( // allowed HTML tags
            'abbr', 'b', 'bdi', 'big', 'blockquote', 'br',
            'caption', 'center', 'cite', 'code',
            'dd', 'del', 'dfn', 'div', 'dl', 'dt', 'em',
            'font', 'h1', 'h2', 'h3', 'h4', 'h5', 'h6', 'hr',
            'i', 'ins', 'kbd', 'li', 'ol', 'p', 'pre', 'q',
            'rb', 'rp', 'rt', 'ruby', 's', 'samp', 'small',
            'span', 'strike', 'strong', 'sub', 'sup',
            'table', 'td', 'th', 'tr', 'tt', 'u', 'ul', 'var'
            ),
        2 => array( // standard tags and common extensions
            'gallery',
            'ref', 'references',
            'poem',
            'categorytree'
            ),
        3 => array( // attributes for HTML tags
            'class', 'dir', 'id', 'lang', 'style', 'title'
            ),
        4 => array( // attributes for other tags
            'group', 'name' // for ref
            )
        ),
    'SYMBOLS' => array(
        '/', '=', // in tags
        '[', ']', '{', '}', '|', '|-', '|+', '!' // other (mainly tables)
        ),
    'CASE_SENSITIVE' => array(
        GESHI_COMMENTS => false,
        1 => false,
        2 => false,
        3 => false,
        4 => false
        ),
    'STYLES' => array(
        'KEYWORDS' => array(
            1 => 'color: #000000; font-weight: bold;',
            2 => 'color: #000000; font-weight: bold;',
            3 => 'color: #000066;',
            4 => 'color: #000066;'
            ),
        'COMMENTS' => array(
            ),
        'ESCAPE_CHAR' => array(
            0 => ''
            ),
        'BRACKETS' => array(
            0 => 'color: #66cc66;'
            ),
        'STRINGS' => array(
            0 => 'color: #ff0000;'
            ),
        'NUMBERS' => array(
            0 => 'color: #cc66cc;'
            ),
        'METHODS' => array(
            ),
        'SYMBOLS' => array(
            0 => 'color: #009900;'
            ),
        'SCRIPT' => array(
            0 => 'color: #000000;', // nowiki
            1 => 'color: #808080; font-style: italic;', // comments
            2 => 'color: #500000;', // nowiki-like tags (math, syntaxhighlight)
            3 => 'color: #aa8000;', // &abc;
            5 => 'color: #000000; font-weight: bold;', // headlines
            7 => 'color: #000000; text-decoration: underline;', // weblinks
            8 => 'color: #009900;', // lists
            9 => 'color: #000099;', // bold, italic
           10 => 'color: #000099;' // magic words
            ),
        'REGEXPS' => array(
            )
        ),
    'URLS' => array(
        1 => '',
        2 => '',
        3 => '',
        4 => ''
        ),
    'OOLANG' => false,
    'OBJECT_SPLITTERS' => array(
        ),
    'REGEXPS' => array(
        ),
    'STRICT_MODE_APPLIES' => GESHI_ALWAYS,
    'SCRIPT_DELIMITERS' => array(
        0 => array(
            '<nowiki>' => '</nowiki>'
            ),
        1 => array(
            '<!--' => '-->'
            ),
        2 => array( // nowiki-like tags, may have attributes
            '<math' => '</math>',
            '<syntaxhighlight' => '</syntax' + 'highlight>',
            '<source' => '</source>'
            ),
        3 => array(
            '&' => ';'
            ),
        4 => array(
            '<' => '>'
            ),
        5 => array( // headlines
            "\n======" => '======',
            "\n=====" => '=====',
            "\n====" => '====',
            "\n===" => '===',
            "\n==" => '==',
            "\n=" => '='
            ),
        6 => array( // tables, wikilinks, templates
            '{|' => '|}',
            '[[' => ']]',
            '{{' => '}}'
            ),
        7 => array( // weblinks
            '[http://' => ']',
            '[https://' => ']',
            '[//' => ']',
            '[ftp://' => ']'
            ),
        8 => array( // lists (yes, this is a hack)
            "\n*" => ' ',
            "\n#" => ' ',
            "\n:" => ' ',
            "\n;" => ' '
            ),
        9 => array( // bold, italic
            "'''''" => "'''''",
            "'''" => "'''",
            "''" => "''"
            ),
       10 => array( // magic words
            '__' => '__'
            )
    ),
    'HIGHLIGHT_STRICT_BLOCK' => array(
        0 => false,
        1 => false,
        2 => false,
        3 => false,
        4 => true,
        5 => false,
        6 => true, // to highlight symbols inside
        7 => false,
        8 => false,
        9 => false,
       10 => false
        ),
    'TAB_WIDTH' => 4,
    'PARSER_CONTROL' => array(
    )
);

?>

Zeile „Abbrechen | Bearbeitungshilfe | wikEd help (wird in einem neuen Fenster geöffnet)“ entfernen

Hi! Schön wäre es, wenn man folgende Zeile unter dem Bearbeitungsfenster entfernen könnte:

Abbrechen | Bearbeitungshilfe | wikEd help (wird in einem neuen Fenster geöffnet)

Diese „hilfreichen Links“ habe ich nach einmaligen ausprobieren nie wieder gebraucht. Zurzeit nutze ich /vector.css. Eingegeben habe ich folgende Zeile:

.editHelp { display:none; }

Habe den Text auf meiner Unterseite Benutzer:Rechtschreibkontrolle/vector.css abgespeichert, Cache geleert, nur leider funzt es nicht, die Zeile bleibt stehen. Mach ich was falsch? Gruß, Rechtschreibkontrolle ^(Disk) 23:58, 24. Jun. 2012 (CEST)

Die Zeile ist richtig, bei mir geht sie. Hast du Vector aktiv? Wenn du dir nicht sicher bist (oder willst, dass es in allen Skins gleich ist), nimm statt der vector.css lieber die common.css. --TMg 00:03, 25. Jun. 2012 (CEST)

Unter Einstellungen ist folgendes angehakt: Vector (Voreinstellung | Vorschau | Benutzerdefinierte CSS | Benutzerdefiniertes JavaScript). Vielleicht habe ich was falsch auf der Seite Benutzer:Rechtschreibkontrolle/vector.css eingegeben? Gruß, Rechtschreibkontrolle ^(Disk) 00:16, 25. Jun. 2012 (CEST)

Nö, da ist alles richtig. Was mich wundert ist das mit dem wikEd. Ich dachte, der geht unter Vector gar nicht? Welche Gadgets hast du aktiv? --TMg 00:23, 25. Jun. 2012 (CEST)

Na, wenn oben in der Überschrift WikEd auftaucht, scheint WikEd aktiv zu sein.

WikEd verschiebt sämtliche normalen Elemente ins Dunkel und baut seine eigene GUI, mit eigenen class und ID.

Wikipedia:Technik/Skin/CSS #Hinweise listet für diese Situation

DIV.mw-tos-summary,
DIV#editpage-copywarn,
A#mw-editform-cancel,
.editHelp,
A[target="helpwindow"],
SPAN.wikEdHelpSpan {
   display: none;
}

• SPAN.wikEdHelpSpan wäre für routinierte Benutzer von WikEd sinnvoll; allen anderen schadet es nicht.

Gute Nacht --PerfektesChaos 00:37, 25. Jun. 2012 (CEST)

Beta-Tester für Screenshot-Skript gesucht

Es würde mich sehr interessieren, ob mein neues Skript Benutzer:Schnark/js/screenshot.js tatsächlich benutzbar ist, und in welchen Browsern. Die Einbindung funktioniert so wie immer, die Bedienung ist in meinen Augen selbsterklärend, aber beides ist auch nochmal kurz unter Benutzer:Schnark/js/screenshot skizziert. Wer dabei Erkenntnisse über Kompatibilität mit verschiedenen Browserversionen gewinnt, darf sie gerne direkt in der Dokumentation eintragen. --Schnark 10:21, 30. Jun. 2012 (CEST)

Die Vorschau des geparsten Wikitexts ist größer als das Browserfenster. IMHO wirst Du also den Inhalt beachten und die Fenstergröße und wenn der Inhalt größer ist, die Dialoghöhe verkleinern.

Auf die Schnelle behoben, das ist ja furchtbar, dass man Dokumentationen sowohl lesen als auch befolgen muss.

Das Browserfenster springt nach dem Einfügen des Screenshots nach rechts unten.

Der Screenshot des Browserfensters ist naturgemäß größer als das Fenster selbst, und der Browser meint wohl, nach dem Einfügen so springen zu müssen, dass die rechte untere Ecke zu sehen wäre, wenn sie sichtbar wäre. Ich habe keine Ahnung, was ich dagegen tun kann.

Der Pfeil (cursor) sieht ziemlich unscharf aus.

Eigentlich ist es [6] (vielleicht auch eine andere Größe, weiß ich nicht mehr), ich habe auch keine Ahnung, warum das so unscharf wirkt.

Beim Klick auf die Enter-Taste wird der Dialog geschlossen, erwarten würde ich, dass es weiter geht.

War im Prinzip das Problem eins drunter, der Fokus lag auf dem ersten Button, was du aber nicht gesehen hast. Jetzt nicht mehr.

Wenn man mit TAB versucht durch den Dialog zu navigieren, sieht man nicht welcher Button den Fokus hat. Das ist ein generelles Problem mit den farbigen Buttons.

Warten wir mal, ob sich in bugzilla:37743 irgendwas tut.

Ansonsten mag ich solche Anstrengungen. IHMO fehlt noch ein Script, das den Nutzer ein Element auswählen lässt (wie Firebug, aber evtl. hover-highlighting) und dann einen HTML-dump anfertigt (zur Fehlerberichterstattung). -- RE rillke fragen? 10:39, 30. Jun. 2012 (CEST)

Habe meine Antworten eingeschoben. --Schnark 11:16, 30. Jun. 2012 (CEST)

Ein Upload direkt nach Commons funktioniert nun: Beweis. --Schnark 09:19, 4. Jul. 2012 (CEST)

Mhm, tolle Idee - das Proxy-Script. Das konnten wir den Wikipediae anbieten, um unsere Dateilöschwarnungen auf die Benutzerdiskussionsseiten anderer WMF-Wikis zu kopieren. Die könnten einfach eine "Message" erhalten 1)Typ der Warnung 2)Nutzer und der Rest wird vom lokalen Skript erledigt. So kann jedes Wiki die Vorlagen, die es liebt, verwenden.

Nun soll es demnächst aber auch CORS geben. Weist Du, ob man damit auch Tokens bekommt? -- RE rillke fragen? 14:27, 11. Jul. 2012 (CEST)

Ich fürchte, dass der Unterschied zwischen CORS ist prinzipiell möglich und CORS wird aktiviert ziemlich groß ist (und dann warte ich auf den ersten Hacker, der irgendwelche Sicherheitslücken in der Common.js von xyz.wikipedia findet und sie ausnützt um sich von einem Stewart auf Meta Checkuserrechte geben zu lassen). An Tokens kommt man per CORS problemlos, einfach mit der selben Anfrage wie sonst auch, nur halt an den fremden Server. --Schnark 09:20, 12. Jul. 2012 (CEST)

Tatsächlich. Gerade getestet. Danke. -- RE rillke fragen? 19:39, 14. Jul. 2012 (CEST)

Für meinen Geschmack enthält das Screenshot-Skript noch zu viel Text. Mehr als 10 Worte kann man den Nutzern heutzutage nicht mehr zumuten ;-) Denk' außerdem an die armen Übersetzer. -- RE rillke fragen? 19:39, 14. Jul. 2012 (CEST)

Die Ausführungen zum Bearbeiten im Schritt 3 sind wirklich umfangreich, aber allen anderen Text halte ich irgendwie für nicht verzichtbar. Und wenn ich nicht schon an die Übersetzer gedacht hätte, dann wäre das Skript überhaupt nicht übersetzbar ;-) --Schnark 12:09, 17. Jul. 2012 (CEST)

Fehler beim Zusammenspiel zwischen HotCat und bkl-check

In dem Artikel Flugplatz Schwenningen werden fälschlicherweise ganz unten die Kategorien Kategorie:Verkehrslandeplatz und Kategorie:Flugplatz (Baden-Württemberg) als Link auf eine Begriffsklärungsseite markiert. Die Ursache liegt in dem Zusammenspiel zwischen von MediaWiki:Gadget-bkl-check.js mit MediaWiki:Gadget-HotCat.js. Zum Eingrenzen der Ursache habe ich den Artikel unangemeldet geöffnet und dann die beiden Gadgets mit folgenden Bookmarklet in dieser Reihenfolge geladen:

javascript:void( importScript( 'MediaWiki:Gadget-HotCat.js' ) )
javascript:void( importScript( 'MediaWiki:Gadget-bkl-check.js' ) )

Wo liegt hier der Fehler in den Gadgets? --Fomafix (Diskussion) 14:13, 30. Jun. 2012 (CEST)

Anscheinend schreibt HotCat den Sortierschlüssel der Kategorien in das title-Attribut. Für die Kategorien Kategorie:Verkehrslandeplatz und Kategorie:Flugplatz (Baden-Württemberg) ist das im obigen Beispiel Schwenningen. Bkl-Check erwartet im title-Attribut den Wikinamen des Ziels und überprüft, ob das eine Begriffsklärungsseite ist. Weil Schwenningen eine Begriffsklärungsseite ist, werden nun die Kategorien fälschlicherweise als Begriffsklärungsseite markiert. Beide Gadgets verlassen sich darauf, dass beim Start im title-Attribut der Wikiname ist und verändern anschließend das title-Attribut. Damit der Wikiname nicht verloren geht, sollte der ursprüngliche Wert des title-Attribut gesichert werden. Hier bietet sich einer Speicherung per .data() an. Wie kann man aber sinnvoll den neuen Wert des title-Attributs steuern, so dass mehrere Gadgets sich nicht stören? --Fomafix (Diskussion) 23:18, 30. Jun. 2012 (CEST)

1. Glückwunsch zur Detektivarbeit.
2. .data ist für die Zukunft zweifelsfrei der optimale Weg.
   • Nur ist mir nicht so ganz klar, was die Altbrauser da anstellen würden. Tun die das ins DOM? Kann das aus dem DOM wieder ausgelesen werden? Ich habe hier nur frische Brause in Reichweite stehen; ich weiß sowas immer nicht.
3. Mittel der Wahl ist dann JSON/encode; das macht jQuery aber automatisch zusätzlich zum DOM.data.
   • Da müssten sich dann weltweit alle gadget-Programmierer absprechen.
   • In der Form .data(key,value):
     • key="bklCheck", value="BKS"
     • key="HotCat", value="sortkey"
   • In der Form .data(obj): Es wird ein { bklCheck: {...}, HotCat: {...} } oder so draus. (wenn bklCheck nur einen einzelnen String loswerden will, dann eben nur den; oder Array oder was immer)
   • Wer mit seinem Gadget ankäme, für den merkt jQuery, dass in .data schon was drinsteht, und packt seins dazu – sonst schreibt er sich in ein leeres {} hinein. Anschließend wird encoded+geschrieben – was jQuery für den Benutzer gleich miterledigt.
   • Ob man sich für eine der beiden Techniken entscheiden müsste, weiß ich nicht so genau. Mir scheint es so, als ob jQuery sowieso intern alle key=value zusammenschmeißt.
   • Das ist aber alles Zukunftsmusik; müsste jedoch schon Jahre im voraus in der MW-Welt propagiert werden.
4. Für von jetzt auf gleich:
   1. bklCheck soll Kategorien in Frieden lassen, fertig.
      • Der wäre in deutscher Reichweite, solange er nicht disambigCheck heißt.
   2. HotCat mag dann in Kategorien schreiben, wozu sie Lust haben.

Gute Nacht --PerfektesChaos 01:30, 1. Jul. 2012 (CEST)

Bei meinem Gadget Benutzer:Fomafix/Gadget-redirecttitle.js habe ich das gleiche Problem. Dort habe ich es gelöst, indem ich vor dem überschreiben des title-Attributs den Inhalt gesichert habe per $( object ).data( 'title', object.title ). So kann mein Gadgets mehrfach ausgeführt werden und der korrekte Wikiname wird verwendet. Der ursprüngliche Wikiname ist eine gemeinsame Information und sollte von allen Gadgets gleich behandelt werden. Die von den Gadgets erzeugten Informationen könnten ebenfalls per .data() gespeichert werden. Aber wie kann die Erzeugung des neuen Titels bei vielen Gadgets sinnvoll gestaltet werden? --Fomafix (Diskussion) 14:31, 1. Jul. 2012 (CEST)

Ich war zum erste Mal mit der Frage von .data() unter Wiki-Bedingungen konfrontiert worden. Was ich dazu sagen wollte, wäre ausgeschlafen und zum zweiten Mal drüber nachgedacht:

1. .data() wird dann wohl noch viele, viele Jahre warten müssen, weil offenbar die Altbrauser noch nicht mitspielen. Zumindest verbreitete Werkzeuge wie BKL-Check müssten noch eine Weile traditionelle Wege gehen.
2. Wenn irgendwo .data eingesetzt wird, dann sollte weltweit eine MW-Konvention geschaffen werden:
   • In .data wird mit key=GadgetID und value=gadgetDataCollection geschrieben.
   • Grundsätzlich entspricht das dem Andocken an mw.libs, wobei die GadgetID pfiffig gewählt werden sollten.
   • value= kann ein einzelnes Datenelement sein, wenn das Gadget damit auskommt. Ansonsten ist es ein Objekt, das nach Belieben mit unterschiedlichen Komponenten gefüllt werden kann, spezifisch für das Gadget.

     Beispiel: key="HotCat", value="Schlussel"

   • Es darf nicht dazu kommen, dass die data verseucht werden mit unspezifischen key wie name oder count oder found oder so. Aus diesem Grund sähe ich auch title kritisch.
3. Jedes Gadget muss für sich allein glücklich werden und unabhängig von anderen laufen. Wenn Benutzer sich widersprechende Aktivitäten lostreten, ist das deren Problem. Ein Gadget muss von seinem Start bis zum Ende mit seinen eigenen Daten arbeiten, und es sieht die allgemeinen Eigenschaften der Seite wie URL und mw.config – dementsprechend muss es sinnvoll arbeiten.
   • Ein Gadget darf nicht (oder nur auf allereigenste Gefahr) in die .data-key fremder Gadgets hineingucken, dort etwas auslesen oder gar ändern. Das gibt Ärger.
   • Ein Gadget kann sich den passenden title gern merken und sich in seinem eigenen .data-key ein fomafixRedir.titleSaved ablegen.
   • Wenn aber mehrere Gadgets gleichzeitig vom Benutzer aufgefordert werden, da durcheinander zu wirken, dann wird auch alles mit altem und neuem und mittlerem und endgültigem title durcheinander gehen.
4. Inzwischen habe ich mich auch in die Quellcodes zu jQuery.data() näher eingelesen. Es gibt ein zentrales Objekt, das bei jedem DOM-Element abgelegt wird. Ob sie mit .data(obj) oder .data(key,value) gefüttet werden, ist offenbar völlig egal. jQuery macht auch ein JSON-Encoding, so dass wir uns um nichts mehr kümmern müssen.

Beste Grüße --PerfektesChaos 16:26, 1. Jul. 2012 (CEST)

Für das Speichern von privaten Daten eines Gadgets per $.data() passen Deine Erklärungen. Der Wikiname ist aber ein öffentlicher Wert, den mehrere Gadgets benötigen, und das title-Attribut ist eine öffentliche Ressource, die nur einmal vorhanden ist. Zentrale Funktion der Gadgets ist es das title-Attribut zu verändern. Mein Gadget und alle anderen Gadgets, die das title-Attribut verändern, beeinflussen damit die anderen Gadgets, die auf das title-Attribut angewiesen sind. Das Problem der gegenseitigen Beeinflussung kann behoben werden, indem der Wikiname nicht im title-Attribut, sondern an einer anderen festen Stelle gespeichert wird. Dann kann das title-Attribut verändert werden, ohne das andere Gadgets gestört werden. Sinnvoll wäre natürlich, dass der Wikiname von MediaWiki selbst direkt per HTML5 in ein entsprechendes data-Attribut geschrieben wird. Die Alternative ist es, dass das erste Gadget das title-Attribut in ein $.data() kopiert und alle weiteren Gadgets von dort den Wikinamen holen. Es muss aber einen festen Namen oder eine Funktion geben, aus dem alle Gadgets den Wikinamen auslesen können. Wenn aber mehrere Gadgets das title-Attribut verändern, dann hängt das Ergebnis von der zufälligen Ladereihenfolge der Gadgets ab. Hier suche ich noch nach einer Lösung. Bei http://api.jquery.com/data/ lese ich übrigens keine Einschränkungen auf bestimmte Browser. Zumindest beim Internet Explorer 8 scheint $.data() auch zu funktionieren. --Fomafix (Diskussion) 17:49, 1. Jul. 2012 (CEST)

Ich verstehe nicht, was du noch mit dem title-Attribut willst, sobald hinreichend viele Browser .data unterstützen?

• Künftig wird dann das title-Attribut gar nicht mehr angefasst und jedes Gadget legt seine DOM-Element-bezogenen Privat-Infos ausschließlich im .data() ab.
• Wobei man auch im Moment eigentlich kein title-Attribut bräuchte.
  • Nur wer mit document.links[] arbeiten würde und befürchten müsste, dass irgendwo zusätzliche Links in die HTML-Seite eingefügt oder aber solche gelöscht werden und die Seite sich massiv dynamisch verändert. Ansonsten kann man sich die Nummern interessanter Links merken und auf JS-Ebene abspeichern als

    meins = { "17": "dies", "39": "jenes" }

  • Bei dir analog:

    Du müsstest die Elemente, die du in redirects findest, erstmal in ein laufendes Array (gadget-global) pushen:

    collection.push( this ) (bzw. collection = [ this ])

    Anschließend willst du ja wohl blockweise je 50 eine query machen; dann holst du halt von 0...<50 alle collection[i].title (oder extrahiert aus collection[i].target – siehe unten) wieder aus dem Array und verkettest sie mit |.

    Array macht sich hier glücklicher als {}.

    Wenn die query eintrudelt, gehst du durch die collection[i] und stellst mit diesen DOM-Elementen an, was immer du magst.

    Wenn es mehr als 50 redirs sind, muss halt noch ein gadget-globales m von 0 über 1 die Elemente Nr. 50–99 abfragen, usw.

    Wenn du mehrfache Aufrufe des gadgets auf derselben Seite sicherstellen möchtest, kannst du eine Klasse dranhängen: fomafix-redir-hier-war-ich-schon

    Wenn du einzelne Links identifizieren und mit der collection verbinden willst, kannst du eine ID="fomafix."+i zuweisen.

    Ansonsten begreife ich wirklich nicht, was ihr immer mit dem title habt; das ist eine optische Präsentation für Benutzer, kann jederzeit geändert werden (as see) und hat keinen Anspruch auf Schutz und Unveränderbarkeit. Zurzeit bietet es im Ausgangsstadium eine etwas freundlichere Aufbereitung des Linkziels; da muss ggf. halt am Encoding des href ein wenig geguckt werden, wie es zur query passt, und dann hast du den Original-title.

    Die Variable redirects mit dem Suchergebnis scheinst du nicht zu benötigen; dann kannst du auch .each() direkt an .find() hängen.

• Und BKLcheck wäre gut beraten, zumindest die im ANR oft zu erwartenden NR ^(Datei|Kategorie|Wikipedia): abzufangen und nicht in die query zu schieben oder title zu misshandeln; genau genommen aus den ganzen wgFormattedNamespaces!==["0"] dynamisch (oder lieber statisch) einen no-query-RegExp bauen.
  • Und wenn man schon grad dabei ist, möge BKLcheck doch bitte die href durch diesen regexp schieben, fragment wegschmeißen und sich im Erfolgsfall das Ergebnis notfalls API-geeignet umformatieren. Dann kann title in Frieden gelassen werden.
• Also, das mit den Altbrausern durchschaue ich wie gesagt nicht; ich habe nur relativ aktuelle in Reichweite, und ich mag die spitzen Schreie von Benutzern nicht, die auf irgendwelchen Altlasten arbeiten und sich über Fehler beschweren, die ich nicht reproduzieren kann. Neben HTML5 geht es wohl um DOM3 (DOMUserData) und das ist seit 2004 auf dem Markt. Ab wann für IE6 und irgendwelche Safaris das berücksichtigt wurde, durchschaue ich nicht. Damit lassen sich bereits DOM-Funktionen aufrufen und DOM-Elemente mit Werten belegen, während die Repräsentation über HTML5 erst deutlich später erfolgte.

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

Die Variable redirects brauche ich seit dem Umbau der Datenstruktur nicht mehr. Ich habe sie entfernt. Deine weiteren Hinweise zu der Datenstruktur in meinem Gadget verstehe ich nicht. Ich will nicht mehrfache Aufrufe meines Gadgets verhindern, sondern ich will erreichen, dass trotzt mehrfachen Ausführens das gleiche Ergebnis herauskommt und auch, dass andere Gadgets nicht beeinträchtigt werden.

Das Ziel meines Gadgets wie auch einiger anderer Gadgets ist es dem Anwender einen erweiterten Tooltip anzuzeigen. Daher wird das title-Attribut geändert. Dafür ist das title-Attribut auch schließlich da.

Die Gadgets benötigen den Wikinamen der Links als Basis. Mit Aufwand lässt sich der Wikiname auf dem href-Attribut extrahieren. Einfacher geht es aber, wenn man den Wikinamen aus dem title-Attribut nimmt. Beide Attribute könnten aber von anderen Gadgets verändert werden. Daher wäre es sinnvoll, wenn es eine globale Funktion gibt, die mir zu einem Link den ursprünglichen Wikinamen gibt. In meinem Gadget habe ich das ohne separate Funktion inline mit $.data() umgesetzt. Wenn das alle Gadgets so machen würden, dann gäbe es kein Problem mit einem überschriebenen Wikinamen.

Für meine eigentliche Frage, wie sich mehrere Gadgets kooperativ auf einen neuen Wert für das title-Attribut einigen können, bist Du leider nicht eingegangen. --Fomafix (Diskussion) 22:47, 1. Jul. 2012 (CEST)

Kurz vorab:

• „Einfacher geht es aber, wenn man den Wikinamen aus dem title-Attribut nimmt.“ – Ja, aber genau das ist das Problem. Der Tooltip kann von jedem nach Belieben verändert werden, und dann ist das überhaupt nicht mehr einfacher. Der Tooltip darf einfach nicht ausgewertet werden.
• „Mit Aufwand lässt sich der Wikiname auf dem href-Attribut extrahieren.“

if ( ! href.indexOf( "/wiki/" ) {
   pagename = decodeURIComponent(href.substr(6).replace(/#.*$/,"")).replace(/_/g, " ");
   bigAction(pagename);
}

oder so ähnlich, und fertig ist die Laube.

Domain-relative URL vorausgesetzt, wie sie wohl im Moment in Mode sind; sonst halt das Projekt davorsetzen.

• Ich sehe keinen Sinn darin, den title zu konservieren. Aber wer ihn unbedingt wiederhaben möchte, bekäme ihn wie vorstehend als pagename.
• Jedes Gadget, das von einem Benutzer geliebt wird, mag sonstwas in den Tooltip reinschreiben. Einigen können die sich überhaupt nicht. Wenn Benutzer sich eine Kombination aus mehreren Gadgets zusammenbauen, landet da eben das, was er mag. Man könnte auch bei jedem ANR-Wikilink den Einleitungsabschnitt des verlinkten Artikels per API extrahieren, alle Syntaxelemente herausstrippen und das dann als plain text in den Tooltip schreiben. (In Java gibt es HTML-formatierbare Tooltips, und irgendwas neues geistert bei jQuery herum, tipsy oder so, das kann das auch.)
• Das Format eines title kann sich auch mal ändern: bugzilla:542

Es ist mir schon klar, dass du das Gadget mehrmals hintereinander auf eine schon geladene HTML-Seite anwenden möchtest (es können sich eigentlich eher nur die Eigenschaften der Linkziele geändert haben, der aktuelle Seiteninhalt doch wohl weniger?). Ich schau mir auch gern demnächst deinen Quellcode genauer an; meine aber, dass es sich mit dem Verzicht auf das Auslesen von .title schon weitgehend erledigt hätte. Mir ist allerdings der praktische Arbeitsablauf und Zweck von mehrfachem Gadget-Start nicht so ganz einleuchtend; ich hätte in der Situation eher einen Inhibitor gesetzt.

Schönen Abend --PerfektesChaos 23:39, 1. Jul. 2012 (CEST)

Das mit dem mehrfachen Ausführen des Scripts war nur ein Test, ob andere Scripte, also auch das Script selbst, beeinflusst werden. Mein Script soll aber nicht notwendigerweise mehrfach ausgeführt werden. Solange mein Script den Wikinamen aus dem title-Attribut liest und danach in das title-Attribut schreibt, beeinflusst es immer andere Scripte, die auf das title-Attribut angewiesen sind. Für mein Skript konnte ich das umgehen, indem ich den ursprünglichen Wikinamen per $.data() sichere. Wenn das alle anderen Scripte auch so machen würden oder MediaWiki selbst so etwas machen würde, dann wäre der Zugriff auf den Wikinamen sichergestellt. So wie ich Dich aber verstanden habe, glaubst Du nicht daran, dass man sich auf eine gemeinsame $.data()-Struktur einigen kann und dass man sich auf den Wikinamen im title-Attribut nicht verlassen kann. Deiner Meinung nach sollte der Wikinamen aus dem href-Attribut extrahiert werden.

Ich habe es für mein Script so umgesetzt und habe das nun nicht mehr notwendige $.data() wieder entfernt. Deine oben angegebene Funktion habe ich mit wgArticlePath verallgemeinert und ist jetzt die Umkehrfunktion von mw.util.wikiGetlink(). Diese Funktion sollte in mw.util aufgenommen werden, denn das sollten dann alle Gadgets verwenden um den Wikinamen eines Links zu bekommen. --Fomafix (Diskussion) 14:23, 3. Jul. 2012 (CEST)

• Richtig; wenn man bei .data etwas saven wollte, dann müsste es ein fullTitle sein: Die wgPageName sind mit Namensraum und Unterstreichungsstrich; die wgTitle ohne Namensraum und mit dekodierten Leerzeichen.
  • Dass im Moment der Startwert des Tooltip-title-Attributs eines Links zufällig grad dieses fullTitle ist, kann ja Arbeitserleichterung sein – aber woher weiß ich, dass da noch der Startwert drinsteht?
• Du bist ja oft auf bugzilla unterwegs; ich hab da noch nicht mal einen Account: Mach doch mal höheren Ortes den Verbesserungsvorschlag samt Patch:
  • mw.util.wikiUrldecode(url)
    • Macht ein decode(), .replace(/_/,' ') und schlägt sich mit Doppelpunkten und Schrägstrichen herum; Resultat: wgTitle plus Namensraum.
    • Voraussetzung: url gehört zum gleichen Projekt
      • host-relativ, beginnt mit genau einem Schrägstrich
      • Protokoll-relativ, Domain der url ist die aktuelle Domain
      • http oder https angegeben, aber keine exakte Übereinstimmung erforderlich; aktuelle Domain
    • Zugabe zum wgArticlePath: /[?&]title=([^#&]+)([#&])?.*$/

Erfrischenden Tag --PerfektesChaos 15:32, 3. Jul. 2012 (CEST)

Ich habe mit Bug 38598 ein Vorschlag zum Befüllen der data-*-Attribute von MediaWiki gemacht. Vielleicht bekommen wir damit mal eine universelle Lösung. --Fomafix (Diskussion) 19:21, 23. Jul. 2012 (CEST)

Fein.

@bugzilla: Tja; vielleicht hätte auch gleich eine Begründung mitgeliefert werden sollen, als Motivation für Mitleser und die weltweite Gemeinde.

• The objective for these three items is to provide an easy and undisturbed access to properties of the linked page.
• Furthermore, the proposed naming scheme "data-mw-property" should be maintained by further items to avoid conflicts with attributes attached by user.
• The reason for the suggested properties in particular is to get simplified access to characteristics of the linked page. Some might be derived already from URL by pattern matching and comparison with namespace name list within the same project, requiring slight efforts. Others, like final target of redirect, disambiguation page or namespace names used in a sister project are not available by URL evaluation. However, the server has better access to such information than the local site, impatiently waiting for some API retrieval. Any link to something within a wiki may be equipped with a set of properties if deviating from the current page context.
• The "data-mw-title" property in particular is the page name of the target, while the title= attribute in HTML is a tooltip for visual display. Users might modify this by tipsy formatting or display the lead section of the article.
• On the horizon, after availability of HTML5 by majority of user browsers, a successor for evaluation of class="mw-redirect" and other workarounds is shining up. Gadgets can use the additional information for meaningful user support.

@TMg: Der Hintergrund ist im vorstehenden Abschnitt zu finden.

Schönen Tag --PerfektesChaos 09:44, 24. Jul. 2012 (CEST)

@Steef Danke für bugzilla:38598#2

oder Fomafix:

Das war eigentlich so gedacht, dass jemand mit bugzilla-account diesen Text dort direkt posted, und Wikisyntax→bugzilla.plain.text.75chars wandelt. (siehe Quelltext-Kommentar hier drunter)

Heiß. Immer noch. --PerfektesChaos 23:31, 25. Jul. 2012 (CEST)

---

Ich nutze einfach mal ganz dreist diese Möglichkeit, ein wenig Werbung für importScript('Benutzer:Flominator/BklRedir.js'); Link zu machen :) --Flominator 18:52, 1. Jul. 2012 (CEST)

Links auf bestimmte Seiten in der Wikipedia unterdrücken?

Ist es mit enem Skript möglich, Links auf bestimmte Seiten in der Wikipedia unterdrücken oder bestimmte Seiten nicht anzeigen zu lassen? Falls nicht, würde mir auch ein Fehlen des Bearbeiten-Knopfs auf individuell festgelegten Seiten genügen. Ich hoffe, ich bin hier richtig. Gruß, Vogone (Diskussion) 19:53, 13. Jul. 2012 (CEST)

Ich habe erst kürzlich ein Skript entwickelt, das genau das Gegenteil macht und es ist sogar jetzt schon möglich, es für deinen Zweck umzukonfigurieren. Schreibe die folgenden Zeilen in deine vector.js, wobei du die erste Zeile anpassen musst. --TMg 21:07, 13. Jul. 2012 (CEST)

var userHighlightList = 'Benutzer:Vogone/Ignorierliste';
var userHighlightStyle = 'visibility: hidden;';
importScript('Benutzer:TMg/userHighlight.js'); //[[Benutzer:TMg/userHighlight.js]]

Danke! Das funktioniert schon mal. Gibt es denn nun auch die Möglichkeit, ganze Seiten per Skript nicht anzeigen zu lassen? Vielen Dank im Voraus und Grüße, Vogone (Diskussion) 13:56, 14. Jul. 2012 (CEST)

Wie meinst du das? Vielleicht mit einem AdBlock-Plugin? --TMg 18:53, 14. Jul. 2012 (CEST)

Entweder die angezeigte Seite blank anzeigen, eine Fehlermeldung anzeigen lassen oder automatisch auf die Hauptseite weitergeleitet zu werden, wären für mich vorstellbare Lösungen. Ist irgendetwas von dem mit CSS oder JS möglich? Grüße, Vogone (Diskussion|Beiträge) 21:28, 4. Aug. 2012 (CEST)

Wie gesagt einfach den Werbe-Blocker deiner Wahl mit den Adressen füttern. --TMg 21:55, 6. Aug. 2012 (CEST)

Vorlage:Anker

Die Vorlage:Anker wird am sinnvollsten folgendermaßen in einer Überschrift verwendet:

== {{Anker|Alternativüberschrift}} Überschrift ==

Wird bei einer solchen Überschrift der Bearbeiten-Knopf geklickt, dann wird Zeile Zusammenfassung und Quellen mit folgendem Wert gefüllt.

/* {{Anker|Alternativüberschrift}} Überschrift */ 

Nach dem Speichern wird daraus falscher Link auf die nicht existente Überschrift #.7B.7BAnker.7CAlternativ.C3.BCberschrift.7D.7D Überschrift.

Dieses Problem lässt sich mit folgendem JavaScript-Schnipsel beheben:

if ( mw.config.get( 'wgAction' ) === 'edit' ) {
	$( function () {
		$( '#wpSummary' ).val( function ( i, val ) {
			return val.replace( /\{\{\s*[Aa]nker\s*\|[^}]*\}\}\s*/g, '');
		} );
	} );
}

Wäre das was für MediaWiki:Common.js oder besser als separates Gadget? --Fomafix (Diskussion) 20:35, 6. Aug. 2012 (CEST)

Common.js – Fein, löst ein altes Problem. Wie die hiesigen Mitleser wissen, gehört ansonsten die Vorlage:Anker zum vorherigen Abschnitt, wenn man sie nicht hässlich im BK haben möchte, und deshalb vor die Überschrift einfügt, und ist dann bei der Abschnittsbearbeitung nicht verfügbar. Setzt man sie drunter, springt der Browser natürlich zu weit. Intelligent auch, von 'edit' abhängig zu machen, weil die Ersetzung nur einmal erfolgen kann, und nicht mehr beim submit. Nebenbei: JSLINT meckert immer die geschweiften Klammern an und möchte sie \escaped haben, aber funktionieren tut’s eigentlich trotzdem. Schönen Abend --PerfektesChaos 21:41, 6. Aug. 2012 (CEST)

Bitte nicht so, das das u.U. absichtlich in die Zusammenfassungszeile Geschriebenes löscht. Außerdem sind die Kapselung und das /g unnötig. Unten mein Vorschlag. PS: Die Regex-Engines der meisten Browser kommen mit den fehlenden Backslashes klar, für höchstmögliche Kompatibilität sollte man sie aber einfügen. --TMg 22:08, 6. Aug. 2012 (CEST)

Durch die Einschränkung mw.config.get( 'wgAction' ) === 'edit' wird der Code nur beim ersten Laden ausgeführt und nicht bei der Vorschau. Eine Einschränkung auf den /* … */-Block ist aber trotzdem sinnvoll. {{Anker|…}} steht aber nicht unbedingt am Anfang, sondern kann auch am Ende oder an einer anderen Stelle der Überschrift stehen. Außerdem kann Anker auch mehrfach verwendet werden. $() stellt sicher, dass es nach dem vollständigen Laden des Dokuments ausgeführt wird. Common.js wird bereits während des Ladens ausgeführt und daher ist diese Funktion notwendig. --Fomafix (Diskussion) 22:22, 6. Aug. 2012 (CEST)

Echt? Hm, na gut. An mehrfache Anker hatte ich nicht gedacht. Dann bleiben von meinem Vorschlag nur noch die Backslashes. Ach ja, bitte in MediaWiki:Onlyifediting.js einfügen, damit es wirklich nur beim Editieren geladen wird. --TMg 22:38, 6. Aug. 2012 (CEST)

Onlyifediting steht in einer Lade-Klausel in Common.js; an genau dieser Stelle in Common.js sollte auch der Schnipsel eingefügt werden. Vielleicht kann man ja irgendwie den Wert von mw.config.get('wgAction') recyceln, dass er nur einmal abgefragt wird. Etwa so:

switch ( mw.config.get( 'wgAction' ) ) {
   case 'edit' :
      $( ... Schnipsel ... );
      // fall through
   case 'submit' :
      mw.loader.load(    MediaWiki:Onlyifediting.js   ,
                     'text/javascript' );
}

statt momentan

if ( mw.config.get( 'wgAction' ) === 'edit' || mw.config.get( 'wgAction' ) === 'submit' ) {
   importScript("MediaWiki:Onlyifediting.js");
}

Onlyifediting sollte reserviert bleiben für das Einfüge-Gadget als stand-alone.

Enjoy --PerfektesChaos 23:09, 6. Aug. 2012 (CEST)

Wieso das? „Only if editing“ = Skript-Teile, die nur im Edit- & Submit-Modus geladen werden, damit die immer geladene Common.js klein bleibt. Genau das ist hier der Fall. Und mw.config.get ist ziemlich trivial, da bringen Optimierungsversuche nicht viel. --TMg 00:47, 7. Aug. 2012 (CEST)

Ich könnt noch an Namensraum und Unterstriche denken, also etwa so: /\{\{[\s_]*:?[\s_]*(?:(?:Template|Vorlage)[\s_]*:[\s_]*)?Anker[\s_]*\|[^}]*\}\}\s*/gi ;-) Der Umherirrende 20:27, 7. Aug. 2012 (CEST)

Beim Namensraum spielt die Groß-/Kleinschreibung keine Rolle: VoRlAgE:anker. Bei dem Vorlagennamen hingegen darf nur der erste Buchstabe groß und klein sein, der Rest muss klein sein: Vorlage:AnkeR. Eine solche Vorlage wird es aber sicherlich nicht geben, so dass das i akzeptabel ist. --Fomafix (Diskussion) 17:18, 8. Aug. 2012 (CEST)

Ist eingebaut. Habe ein Satz auf WP:NEU geschrieben, Doku zu Vorlage:Anker sollte noch angepasst werden und auch ein Hinweis erhalten. Der Umherirrende 18:12, 8. Aug. 2012 (CEST)

Ein preloadtitle mit Vorlage:Anker wäre eine Situation, wo Anker eventuell nicht entfernt werden sollte: Beispiellink. --Fomafix (Diskussion) 16:00, 12. Aug. 2012 (CEST)

Könnte man umgehen, wenn man noch die "/* */" mit in das Regex aufnimmt, aber dann wird es wieder komplizierter. Der UseCase wird wohl gering sein. Der Umherirrende 18:08, 12. Aug. 2012 (CEST)

Derzeit wird preloadtitle mit Vorlage:Anker wohl noch nicht verwendet. Es wäre aber in bestimmten Situationen eine sinnvolle Kombination. Mit der Vorlage:Redundanz wird beispielsweise auch eine Überschrift mit Vorlage:Anker erstellt. Allerdings wird dort die Überschrift auf eine andere Art erzeugt. Ein Umstellen auf preloadtitle wie bei der Vorlage:Umbenennen wäre aber eine Verbesserung des Arbeitsablaufs. Damit eine solche Umstellung funktioniert, wäre es gut, wenn die Vorlage:Anker nicht fälschlicherweise entfernt wird. Eine Erkennung über die /* … */ scheint passend und ist einfach umzusetzen. Ganz einfach und ausreichend ist folgende zusätzliche Bedingung:

indexOf( '/*' ) >= 0

Alternativ durch eine Erweiterung des bestehenden Ersetzungsregel. --Fomafix (Diskussion) 10:51, 15. Aug. 2012 (CEST)

Eingebaut. Passt du noch die Doku unter Vorlage:Anker/Doku an, um diese Funktionalität überhaupt mal erwähnt zu haben? Danke. Der Umherirrende 21:09, 11. Sep. 2012 (CEST)

Eingabemaske für Benutzersperren

In der Diskussion zum Meinungsbild "Belegpflicht bei Benutzersperren" (hier) wurde die Frage aufgeworfen, ob das Ergebnis des Meinungsbildes, dass bei einer Sperre angegeben werden muss, welche Regel wo und wodurch verletzt wurde, gar nicht in die Eingabezeile für die Sperrbegründung passt und daher all das bei der VM vermerkt werden sollte und der sperrende Admin besser einen Permanentlink zur VM und einen Difflink zu seiner Sperrbegründung setzen soll.

Wenn man sich die Eingabemaske anschaut:

so wird derzeit

• a) IP-Adresse oder Benutzername eingegeben
• b) die Sperrdauer aus einer Liste gewählt
• c) der Grund für die Sperre aus einer Liste gewählt

Um die Forderungen des Meinungsbildes umzusetzen, müsste die Eingabemaske erweitert werden, was aber nicht so leicht möglich ist ( wie mir Raymond hier erklärte).

Eingegeben sollte werden:

• A)
  • a) IP-Adresse oder Benutzername;
  • b) die Sperrdauer, aus einer Liste gewählt,
  • c) der Grund für die Sperre, aus einer Liste gewählt,
  • d) wodurch die Regel verletzt wurde.

oder

• B)
  • a) IP-Adresse oder Benutzername,
  • b) die Sperrdauer, aus einer Liste gewählt,
  • c) der Direktlink auf die VM
  • d) der Difflink auf die Sperrbegründung

Und das Rrgebnis sollte in das Sperr-Logbuch geschrieben werden.

Geht das irgendwie mit einem Script? --Ohrnwuzler (Diskussion) 02:31, 13. Aug. 2012 (CEST)

• Dass technisch einiges möglich ist, hatte Raymond schon klargestellt. Nun das Voodoo.
• Maßgeblich ist hier offensichtlich das reason-Feld in der Datenbank.
  • Die Begrenzung des reason auf 255 Zeichen wird einzuhalten sein; eine weltweite Erweiterung halte ich ebenfalls nicht für sinnvoll.
  • Es geht also darum, den Text im reason-Feld während der interaktiven Eingabe sinnvoll zusammenzustellen.
  • Das reason-Feld wird dem neugierigen Benutzer bei der Anzeige des Sperrlogs angezeigt. Es muss sich (allenfalls mit leichten Vorkenntnissen über die WP) von Menschen ohne Hilfsmittel entschlüsseln lassen.
  • Dem interaktiv sperrenden Admin soll vom vorstellbaren JavaScript eine Hilfestellung angeboten werden, mit relativ wenig Mausklicks den Text eines reason-Feldes zu komponieren.
  • Der resultierende Inhalt des reason-Feldes muss vor dem Abspeichern in seiner endgültigen Form angezeigt werden.
  • Momentan ist das offenbar das unter der Auswahl-Liste zu „Grund“ sichtbare Freitext-Feld. Es ist zurzeit für die dort möglichen 255 Zeichen etwas kurz bemessen, das lässt sich spielend vergrößern (auch etwa mehrzeilig). Endgültige Aussagen dazu könnte ich erst machen, wenn mir jemand den HTML-Quellcode einer leeren Sperr-Seite bereitstellt (nach Entfernung des Watchlist-Tokens dieses Admin aus dem Quelltext, etc. etc.; #content reicht).
  • Das Script könnte auch validieren (auf Einhaltung von Mindestinhalten prüfen), bei Fehlen von Inhalten warnen oder gar die irrtümliche grundlose Abspeicherung der Sperrung verhindern.
• Nun zur technischen Umsetzung:
  • Was immer das ist, es wird eine HTML-Seite aufgebaut, die zurzeit das weltweite Standardformular enthält.
  • Diese HTML-Seite kann man durch zusätzliche HTML-Eingabe-Elemente beliebig ergänzen, etwa Textfelder, Radiobuttons, Häkchen-Optionen oder Pull-Down-Listen.
  • Die zusätzlichen Eingabe-Elemente kennen den momentanen Inhalt des reason-Textfeldes. Sie können diesen Text verändern, löschen, ergänzen.
  • Ein Skript würde beim Start jeder von einem Admin aufgerufenen Seite mitlaufen. Es würde im Spezial-NR die wgCanonicalSpecialPageName inspizieren, ob es sich um "Block" handelt; falls nicht, würde sich das Skript sofort wieder abschalten.
• Einzelheiten zur gewünschten Präzisierung des Sperrgrundes:
  • Wegen der begrenzten Zahl von 255 Zeichen wird das mit vollständigen, anklickbaren Permanentlinks oder Difflinks schwierig werden; besser gar nicht versuchen.
  • Man kann den reason in einer standardisierten Form wie folgt aufbauen:

    Standardbegründungsphrase ; oldid=nnnnnnnnn ; Freitext

    • Dabei käme die Standardbegründungsphrase aus einem anscheinend von dir gewünschten zusätzlichen Auswahlmenü. Sobald dort etwas ausgewählt wird, wird der reason-Text entsprechend ergänzt oder aktualisiert.
    • oldid= ist die zurzeit neunstellige RevID, wie sie etwa in der URL index.php?title=Benutzer_Diskussion:Raymond&oldid=106730731 eines Permanentlinks vorkäme. Auch ohne ein klickbares Link anbieten zu können, ist diese Angabe relativ verständlich, käme aber mit 17 Zeichen von 255 aus.
    • Möglicherweise interpretiert die Sperrlog-Anzeige Wikilinks. Dann wäre auch folgendes Format in Betracht zu ziehen (ginge allerdings zurzeit nicht beim Difflink):

      [[Spezial:Permalink/nnnnnnnnn]]

  • Die HTML-Eingabemaske wäre also um ein Feld zu erweitern „URL mit Permalink auf VM oder Difflink auf dies und jenes“.
    • In dieses URL-Feld kann der interaktive Admin mit C&P eine geeignete URL hineinplumpsen lassen. Sobald dort etwas ankommt, wird der reason-Text entsprechend ergänzt oder aktualisiert; das ausgetestete Skript kann sicherer als Menschen aus einer URL die neun Ziffern herausfischen.
    • Genau analog für ein Difflink; nur das hier eine zweite RevID hinzukäme und als ; diff=nnnnnnnnn angehängt werden würde.
    • Fehlermeldung bei ungeeigneter URL wäre möglich.
• Genau analog wie ein Helferlein zum Ausfüllen der Maske ließe sich auch ein kleines (gesondertes) Hilfsmittel zum Lesen der Sperrlogs bereitstellen. Wenn interessierte und häufig mit Sperrungen befasste Benutzer ein Sperrlog angucken, würden ihnen auf dieser HTML-Seite jedes oldid= / diff= in normale, anklickbare Links umgewandelt.
  • Wer die deLuxe-Version nicht aktiviert hat, könnte sich trotzdem ein Spezial:Permalink/nnnnnnnnn zurechtbasteln; eine Hilfestellung dazu ließe sich in der Anzeige des Sperrlogs geben.

Wiedervorlage nach dem MB.

Liebe Grüße --PerfektesChaos 10:46, 13. Aug. 2012 (CEST)

MediaWiki:Group-sysop.js wäre die richtige Seite. Ich habe dir das Sperrformular mal per Mail geschickt, im wmflabs-Wiki könntest du das auch ausprobieren. Ist zwar sehr langsam, aber funktioniert. Falls du Berechtigungen brauchst, lässt sich das einrichten. Einfach mir hier dein Konto von dort nennen. Der Umherirrende 11:32, 13. Aug. 2012 (CEST)

• Danke; ich persönlich habe die Angelegenheit auf Wiedervorlage bis nach Entscheidung des MB gelegt.
• Erstmal war die technische Realisierbarkeit zu klären; ich entnehme dem, dass du sie ähnlich wie Raymond einschätzen würdest und das oben Ausgeführte umsetzbar sei.
• Was genau dann inhaltlich einzufügen sei, wäre vorher im MB festzustellen.
  • Ich kann den Wunsch nachvollziehen, aus dem Sperrlog-Eintrag eines (angemeldeten) Benutzers ein Referenz-Link auf VM, diffpage oder BSV entnehmen zu können, damit man sich im Einzelfall ein konkretes Bild von den Umständen und der Schwere des Falls machen kann.
  • Man wird sehen, wie viel von der Feldlänge dann noch übrig bliebe, um bereits im Sperrlog einige Stichworte angeben zu können.
• Wie genau wo welcher Quellcode dann liegen würde, wäre noch zu überlegen. Möglicherweise kann auch das identische Skript von nicht-sysop geladen werden, würde dann aber nur bei der Umformatierung der Sperrlog-Anzeige aktiv, während MediaWiki:Group-sysop.js vielleicht zwangsweise bei Vorliegen der NR+wgCanonicalSpecialPageName ein loader.load auf ein separat abgelegtes Gadget vornehmen würde.
• Was ich selbst in der Angelegenheit tun würde, wird man sehen.
  • Es kann sein, dass ich mich auf das Schreiben einer Spezifikation beschränke, wenn überhaupt.
  • Falls ich selbst Quellcode schreiben würde, pflege ich mir eine Dummy-HTML-Seite auf der Festplatte anzulegen und die Formular-Aktivitäten im Sandkasten zu schreiben. Das langt völlig, um das Gadget auszutesten. Zum Review würde ich es dann an beta übergeben, damit es dort jemand unabhängig von mir im Kontext erproben kann.

Viele Grüße --PerfektesChaos 20:17, 13. Aug. 2012 (CEST)

Falls die Diskussion unter Wikipedia:Technik/Skin/Werkstatt/Baustellen/Wikilink statt URL in Zusammenfassungszeile mal zu einem Gadget führt, dann würde die Aufgabe für den sperrenden Admin etwas leichter… --Leyo 15:00, 14. Aug. 2012 (CEST)

Wieviele Zeichen umfassen denn üblicherweise Difflinks oder Permanentlinks. Sind dafür 255 zuwenig ?--Ohrnwuzler (Diskussion) 20:56, 16. Aug. 2012 (CEST)

Das Problem ist die Aufsummierung. Das merkst du schon bei Bearbeitungskommentaren, wenn eine Änderung rückgängig gemacht wird und nach dem automatisch vorgegebenen Text kaum noch Platz für eine inhaltliche Begründung bleibt.

Hier geht es darum, dass die URL und eine offenbar gewünschte zusätzliche Standardbegründung den möglichen Freitext einschränkt und deshalb so kurz wie möglich gehalten werden sollte.

Ein normales klickbares Wiki-Permalink benötigt minimal 30 Zeichen; eine echte Difflink-URL 63 Zeichen. Dann muss es noch irgendwie vom Rest abgetrennt werden, wenigstens durch ein Leerzeichen. Auf das Wesentliche reduziert bei Rest-Verständlichkeit sind es 17 bzw. 32 Zeichen.

Damit blieben über 200 Zeichen für eine erweiterte Standardbegründung und noch Freitext.

Aber warte einfach das Ergebnis des MB ab – technisch ist es hier so oder so machbar; müsste nur jemand programmieren und jemand anders testen und aktivieren.

Schönen Abend --PerfektesChaos 21:15, 16. Aug. 2012 (CEST)

Es muss ja nicht im Sperrlogbuch stehen, was alles zur Sperre führte. Es genügt ja, die Sperrbegründung direkt in die VM-Diskussion zu schreiben. Weil dort aber bei einer längeren Diskussion etliche Admin posten und nicht eindeutig erkennbar ist, wer davon nun die endgültige Sperrbegründung verfasst hat, sollte EINHEITLICH im Sperrlogbuch stehen:

• der Permanentlink auf die VM-Meldung (oder Sperrprüfung oder Schiedsgerichtentscheidung
• ein Difflink auf die gültige Sperrbegründung des sperrenden Admin.

also XY wurde dort (Permanentlink) gesperrt mit dieser (Difflink) Begründung.

schön, dass das geht, wäre also das MB technisch umsetzbar. Danke ! -Ohrnwuzler (Diskussion) 15:12, 17. Aug. 2012 (CEST)

Wie schnell geht denn so eine Programmierung? Macht es Sinn, ins MB reinzuschreiben, es sollte binnen einem Monat programmtechnisch umgesetzt werden, bis dahin ist alles manuell (Permanentlink, Difflink) ohne Eingabemaske zu machen...? Arbeiten ja aller freiwillig hier mit, da kann man schlecht Fristen setzen. Eine Übergangsfrist ist auch dumm, weil dann dauert die Arbeit, wie Zeit dafür zur Verfügung steht...

Oder reicht es das Ergebnis des MB einfach mal abzuwarten und dann fügt sich hoffentlich eins ins andere? --Ohrnwuzler (Diskussion) 15:18, 17. Aug. 2012 (CEST)

Schreibt da mal lieber keine Fristen hinein, sowas braucht’s nicht. Wenn das MB klar ergibt, was man eigentlich haben möchte, und wenigstens ein Sperr-erfahrener Admin dabei mitmacht und konkretisiert, was für Eingabefelder mit welchen Texten für angenehme Bearbeitung unangenehmer Angelegenheiten erforderlich wären, ist die Programmierung durch irgendwen binnen weniger Tage erledigt. Danach laufen einige Tage Tests auf der Beta-WP, vielleicht noch irgendwas nachjustieren, fertig. Die überwiegende Zeit wird für Kommunikation und Diskussion über die Ziele und Wünsche benötigt. Liebe Grüße --PerfektesChaos 20:12, 17. Aug. 2012 (CEST)

Schriftfarbe Navigation (links) und Reiter

Ich passe gerade Mediawiki mit Vektor für eine eigene Website an. Ist mein erster Versuch.

Die Farben der normalen Links konnte ich anpassen, aber wie ändere ich die bei Navi und Reitern? Rainer Z ... 18:33, 24. Aug. 2012 (CEST)

1. Zur besseren Kommunikation empfehle ich erstmal die bunten Bildchen auf Skin/GUI.
   • Weiterhin hast du vielleicht noch nicht die Debugging-Möglichkeiten in deinem Browser entdeckt? Sie bieten auch die Möglichkeit, die HTML-Struktur hierarchisch ein- und auszuklappen; das liest sich besser als den gesamten HTML-Seitenquelltext flöhen zu müssen. Außerdem wird möglicherweise auch angezeigt, welche CSS-Statements für welches Element effektiv wirksam sind.
2. Was der Unterschied zwischen „normalen Links“ und „Navi und Reitern“ sein soll, erschließt sich mir jetzt nicht.
   • Möglicherweise hast du deine Definition nur auf den Content-Bereich bezogen. Das wäre eine Erklärung.
   • Vielleicht spielt auch eine Skin mit hinein? Möglicherweise überschreibt eine Skin die allgemeine Definition.

Der Quellcode deiner Anpassung, und auf welcher Seite du sie vorgenommen hast, wäre zur weiteren Diagnostik hilfreich. Vector-Skin?

Schönen Abend --PerfektesChaos 20:26, 24. Aug. 2012 (CEST)

Ich habe in MediaWiki:Common.css das hingeschrieben:

<head>
<style type="text/css">
body { background-color:#663333; color:#FFCC99; }
a.internal { color:#CD0000 !important;}
a.external { color:#CD0000 !important;}
a:link { color:#CD0000; }
a:visited { color:#CD5555; }
a:active { color:#FF0000; }
</style> 
</head>

Wirkt sich überall aus, nur eben nicht in den genannten Bereichen.

Ich bitte um Gnade, ich befasse mich erst seit kurzem damit. Rainer Z ... 23:05, 24. Aug. 2012 (CEST)

Zwei Dinge: Die <head>- und <style>-Tags gehören nicht in die Common.css, nur der reine CSS-Code. Zum anderen musst du zum ändern der Linkfarben in der Navigation grundsätzlich !important hinzufügen. (Falls mir jetzt jemand widersprechen will, dass !important böse sei, und nicht verwendet werden sollte, möge er bedenken, dass die Standard-Vector-CSS-Datei so lustige Selektoren wie div#mw-panel div.portal div.body ul li a enthält.) Vielleicht hilft dir auch Benutzer:Schnark/js/CSS#Linkfarben weiter. --Schnark 09:36, 25. Aug. 2012 (CEST)

Deine Angaben unter MediaWiki:Common.css sehen (abgesehen von den von Schnark schon bemängelten HTML-Anweisungen für das direkte Einbinden in HTML) erstmal gut aus. Sie gelten grundsätzlich für die gesamte Seite. Wenn sie auf alles andere, aber nicht auf den Portal-Rahmen gewirkt haben, lässt das noch einen anderen Schluss zu: Es kam anschließend jemand um die Ecke und hat es überschrieben. Und dieser jemand wäre mit großer Sicherheit die Skin.

• Beispielsweise zeigt die modern-Skin weiße Links auf blauem Untergrund – eine Skin-Definition kann also ihre eigenen Design-Schemata vorgeben.
• Dementsprechend wäre in MediaWiki:Vector.css ebenfalls zu definieren.
• Ich vermute, du möchtest das WMF-Basis-Design so modifizieren, dass Benutzer merken, dass sie nicht in der Wikipedia sind, und etwas Stolz auf die eigene Leistung und Lokalpatriotismus sind ebenfalls legitim. Demzufolge wäre jede für Benutzer verfügbare Skin.css entsprechend umzugestalten. Zu überlegen ist, ob du in die Definition deiner Spezial:Einstellungen#mw-prefsection-rendering eingreifst und die verfügbaren Skins reduzierst oder gar fest vector oder monobook vorgibst und keine Wahlmöglichkeit lässt. Umso weniger Skins musst du anpassen und pflegen.
• Ich bitte um Gnade, dass ich mangels eigener MW-Installation und Admin-Rechte nicht aus eigener Erfahrung mit der Projekt-Konfiguration berichten kann; der Umherirrende und Schnark etwa sind da geübter. Aus deiner Beobachtung ergäbe sich aber, dass die Definitionen für CSS (und wohl auch JS) mutmaßlich in folgender Reihenfolge veranlasst werden:
  1. Weltweit:Common.css
  2. MediaWiki:Common.css
  3. Weltweit:Vector.css
  4. MediaWiki:Vector.css
  5. Benutzer:***/common.css
  6. Benutzer:***/vector.css
• Etwas rumprobieren, dann klappt das schon.

Schönes Wochenende --PerfektesChaos 10:02, 25. Aug. 2012 (CEST)

Herzlichen Dank! Da habe ich ja wieder was zum Basteln ...

Ich werde tatsächlich nur den Vector-Skin zur Verfügung stellen. Der soll aber, so weit das halt geht, an das vorherige Erscheinungsbild der Website angepasst werden.

Hat jemand noch einen Tipp zum Hintergrund? Bei Vector ist das ja dieser weiß-blaugraue Verlauf. Kann man da was drann machen und wenn ja, wo?

• Um das zu tun, was du vorhast, empfahl ich oben Debugging-Möglichkeiten in deinem Browser einzusetzen. Wenn du beispielsweise Firefox hast, brauchst du nur auf einen interessanten Bereich der Seite zu gehen, mit der rechten Maustaste das Kontextmenü aufzumachen, und „Element untersuchen“ anzuklicken. Dann bekommst du die hierarchische Struktur der HTML-Seite so übersichtlich wie möglich angezeigt und auch die auf dieses Element wirkenden CSS-Definitionen, oder welche Eigenschaften in der oben beschriebenen Kette schon wieder überschrieben wurden.
• Das oben genannte Skin/GUI gibt einen Überblick über die Portalseite.
• Zur Frage des Hintergrunds gilt speziell für Vector:
  • HTML-Seite
    • body
      • #content – Inhaltsbereich
      • #mw-head – Kopfbereich („Benutzer“, ca)
      • #mw-panel – linke Spalte

  Damit ergibt sich für MediaWiki:Vector.css

#mw-head,
#mw-panel {
   background-color: #663333;
   color: #FFCC99;
}

• Vielfältige Gestaltungen sind möglich; Rahmenfarben, Hintergrundbilder, Schriftarten. mw:Manual:Gallery of user styles listet etliche Möglichkeiten.

Schönes Wochenende --PerfektesChaos 12:14, 25. Aug. 2012 (CEST)

Danke! Der Debugging-Tipp ist wirklich sehr nützlich. Mein bisheriges Ergebnis ist hier zu bestaunen: [7]. Ebenso der Weg dahin ;-)

Die Schriftfarbe in der Navi und bei den Reitern ist mir weiter ein Rätsel.

Die Rahmen/Striche an Artikeln und Reiter sind offenbar Hintergrundbilder. Ich habe es geschafft, sie auszublenden, was aber seltsam aussieht. Also habe ich mir den Bildordner von Vector vorgenommen und die betreffenden Sachen in Grustufen umgewandelt.

Rainer Z ... 16:59, 25. Aug. 2012 (CEST)

Was bromptonauten:MediaWiki:Vector.css angeht, so gibt es eine CSS-Syntax zu beachten:

• Kommentare beginnen mit /* und laufen auch über mehrere Zeilen weiter, bis sie ein schließendes */ antreffen.
  So geschehen in den ersten drei Zeilen des o.a. Weblinks.

Heißt: Ich sehe nach body{} drei Kommentar-Starts, aber nirgendwo ein Ende; das CSS ist syntaktisch falsch, auf jeden Fall aber sind die Definitionen für a.internal usw. auskommentiert.

Linktipp: WP:CSS #Einige Anleitungen

Weiterhin würde ich deinem Webmaster empfehlen, sich mw:Extension:Geshi (usw.??) anzuschaffen; dann müsste man eigentlich die CSS-Seite in bunt sehen, und alles ab /*.div#content wäre hellgrau:

/* Das folgende CSS wird für Benutzer der Vector-Benutzeroberfläche
geladen. Für allgemeingültige Benutzeroberflächen-Anpassungen
bitte [[MediaWiki:Common.css]] bearbeiten. */



body {
   background-image: none;
   background-color:#FFFFFF; !important;
}

/* div#content {background-image: none;}
/* div#footer {background-image: none;}

a.internal { color:#CD0000 !important;}
a.external { color:#CD0000 !important;}
a:link { color:#CD0000; !important;}
a:visited { color:#CD5555; !important;}
a:active { color:#FF0000; !important;}
a.new, #quickbar a.new { color:#6959CD; !important;}

.catlinks {
    border: 1px solid rgb(249, 249, 249);
    background-color: rgb(249, 249, 249);
    padding: 5px;
    margin-top: 1em;
    clear: both; !important;
}

/* div.vectorTabs { background-image: none; !important;}

Gute Nacht … --PerfektesChaos 23:47, 25. Aug. 2012 (CEST)

Ich habs korrigiert. Bin übrigens mein eigener Webmaster ... Rainer Z ... 15:27, 26. Aug. 2012 (CEST)

vector.js mit Logo

Hallo,

ich habe mir die vector.js von Jón kopiert. Dabei habe ich die Variable keeplogo = true; eingefügt, so dass das Logo angezeigt wird.

Nun wird das Logo leider von der Quickbar überdeckt, siehe Screenshot.

Hat jemand Ideen? --linveggie Bewertung Disk. 21:25, 26. Aug. 2012 (CEST)

Ja (falls Du wieder aktiv bist) da das Script für viele Leute gedacht ist, ist es ratsam sich an einen Zuständigen bzw. Betreuer des Scriptes zu wenden. Das wäre auf den erst Blck Jón, der es wahrschinlich von jemanden kopiert hat der das Script von Benutzer:PDD dem sogenannten Monobook-Script portiert hat. Daher wäre dies die Hauptanlaufstelle, wie man sieht tragen einzelen Leute Neuerungen und Vorschläge auch aktuell dort zusammen. -- 2.215.54.167 01:02, 7. Sep. 2012 (CEST)

Nervige Gruppe in der Sidebar ausblenden

Hallo, gibt es eine Möglichkeit, die Gruppe Drucken/Exportieren links in der Sidebar standardmäßig eingeklappt zu halten oder gar auszublenden? Vielen Dank --intforce.aka.weltforce 21:27, 31. Aug. 2012 (CEST)

Beim nächsten mal Intro lesen und alle Angaben machen (hier wäre zum Beispiel Skin sinnvoll gewesen). Für deine vector.css:

div#p-coll-print_export { display: none }

--Steef ³⁸⁹ 22:23, 31. Aug. 2012 (CEST)

Danke! --intforce.aka.weltforce 22:37, 31. Aug. 2012 (CEST)

Dieser Abschnitt kann archiviert werden. Leyo 22:19, 6. Sep. 2012 (CEST)

MediaWiki:Gadget-Extra-Editbuttons.js und HTML5

Das Gadget fügt einiges an HTML ein, was in HTML5 obsolet ist. Ich habe deshalb ein paar Änderungen vorgenommen (und noch einige weitere): [8] beta.wmflabs benimmt sich aber gerade so zickig, dass ich die Änderungen nicht gründlich testen konnte. Ich würde mir daher lieber erst ein paar Meinungen anhören, bevor ich einen Admin bitte, die Änderungen zu übernehmen. --Schnark 12:00, 6. Sep. 2012 (CEST)

Du beziehst dich nur auf das <tt>-tag, oder? Da gab es ja durchaus Widerstand, und ich glaube auch nicht dass Ottonormalautor auf einfaches teletype-Setzen von Textabschnitten verzichten wird. Händisches Einfügen wird sich nicht vermeiden lassen, und auch im vorhandenen Wikitext (insb. Vorlagendokumentationen) kommt es vor - wie geht MediaWikis html-Tidy da vor?

Ich glaube nicht, dass ein span mit style hilfreich ist, eher verwirrend für die meisten. Man kann aber wohl auch nicht erwarten, dass alle lerenen in welchen Fällen jetzt <code>, <var>, <kbd> oder <kbd>{{Taste}} zu verwenden ist… Eventuell könnte man aber den TT-Button durch diese 3 ersetzen?
meint -- ✓ ^Bergi 16:02, 6. Sep. 2012 (CEST)

Da gebe ich Bergi Recht. Tags sind viel praktischer und vor allem in einer WikiMarkup. Das sieht man doch schon daran dass center und font schon vor über 10 Jahren abgeschafft werden sollten. Es gibt zig Bsp. vom W3C die in der Praxis nie Bedeutung erlangt haben. Eigentlich ist das W3C ein Paradebeispiel was vorgeschriebene Theorie und was Praxis ist. Das heißt am besten sollte es nur noch ein HTML-Tag geben und der Rest soll "kompliziertes/umständliches" CSS sein. -- πϵρήλιο ℗ 17:46, 6. Sep. 2012 (CEST)

Es ist nicht nur das <tt>, sondern auch <big> und align="center". In meinen Augen sollte das MediaWiki selbst übersetzen (bugzilla:39614, für align wird das schon gemacht). Bei einigen Elementen hat der Widerstand ja auch dazu geführt, dass sie doch wieder aufgenommen wurden (<s> und <u>). Man könnte natürlich eine Vorlage:tt erstellen, die style-Attribute vor dem Benutzer verbirgt, aber auch in Zukunft die veralteten Tags zu verwenden, ist in meinen Augen wie in alter Rechtschreibung zu schreiben – nicht direkt falsch, aber eben veraltet. --Schnark 09:28, 7. Sep. 2012 (CEST)

• <tt>
  Das wäre eher was für eine Mini-Tag extension, die das tt abbildet auf ein <code style="white-space:normal;">…</code> (also explizit ohne nowrap) – vielleicht noch mit irgendwelchen class="tt" oder was. Und transparenter Hintergrund; unser momentaner code.style ist irgendwie weiß, weshalb ich auf WP:GUI vorläufig auf farbigen Flächen noch <tt> benutze.
  • Dann wäre <tt> dauerhaft im Wikitext geduldet, und HTML aller Art bekommt code ausgeliefert. Händische Autoren werden zweimal t drücken, aber nicht irgendein Gewürge.
  • Der Einfüge-Helferlein-Button soll schlicht <code>…</code> einfügen und fertig. Wobei man mal die MW:.css duchgucken müsste, ob die nowrap oder bgcolor bei code setzen und ob das ggf. gegen syntaxhighlight noch zeitgemäß wäre.
  • <kbd> & Co. möchte ich ansonsten nicht im Wikitext verbreitet sehen. Ein Universal-Element <code> deckt alle Fälle ab; die Autoren noch mit Spezialvarianten zu verwirren kann man dulden, muss es aber nicht befördern und Hilfeseiten dazu schreiben. Wer ausdrücklich Tastatureingaben darstellen möchte, soll {{Taste}} nehmen.
• style=
  Ist für das Gadget als unmittelbare Einbettung in den Wikitext ungeeignet und wird mit Sicherheit nicht goutiert werden.
• <big>
  checkwiki listet anderhalbtausend Verwendungen auf.
  • Legitim sind wohl Nutzungen wie {{lang|ja new syc th zh – da sollte man den Sprachvorlagen für asiatische Schriftzeichen mal einen Parameter big spendieren.
  • In irgendeiner Zeichen-Navi-Vorlagen-Infobox taucht sowas auch auf.
  • Weiterhin kann man versuchen, den Sportsfreunden den Wert und Unwert von Zwischenüberschriftensimulationen beizubiegen. Handarbeit.
• <blockquote>
  Soll nach einer Schnarkstatistik wohl noch um 30.000 Verwendungen haben? Wird noch über Ewigkeiten umzustellen sein auf {{Zitat}}.
• <center>
  Taucht häufig bei gallery auf, und die hatte früher kein style= – kann man manuell integrieren oder auch keck an vielen Stellen wegstreichen. Oft in Bildunterschriften als individuelle Ästhetik eines Autors von 2006; die Bildunterschrift ist aber auch linksbündig lesbar.
• <font>
  Ist auch nur was für manuelle Umstellung und wird sich noch Ewigkeiten hinziehen.

Liebe Grüße --PerfektesChaos 12:58, 7. Sep. 2012 (CEST)

Nein, <tt> durch <code> zu ersetzten geht nicht: Schon das Gadget zeigt das am Beispiel des Smilies (gut, :) ist im weitesten Sinne Code), WS nutzt <tt> für Text, der im Original in Antiqua gesetzt ist (s:Allgemeine Deutsche Biographie). Zudem hat das Gadget bereits einen Button für <code>.

Um <blockquote> geht es unter dieser Überschrift nicht, das ist nämlich vollkommen gültiges HTML5.

Um <center> und <font> geht es hier auch nicht, die kommen im Gadget zum Glück nicht vor. --Schnark 09:14, 8. Sep. 2012 (CEST)

Die Lösung ist doch ganz simpel: Wenn <big>, <center> und <tt> keine erwünschten Syntaxelemente mehr sind, dann fallen die entsprechenden Knöpfe ersatzlos weg, fertig. (Wieso gab es die überhaupt in diesem de-angepassten Helferlein?)

• Wir brauchen uns nicht zu wundern, dass der Wikitext mit unerwünschten Tags verseucht wird, wenn wir „offiziell“ Knöpfe anbieten, mit denen sie ganz einfach eingefügt werden können. Da dort keine Hilfeseite mitgegeben wird und die syntaktisch weniger beschlagenen Benutzer nirgendwo eine zugängliche Bedienungsanleitung zu diesen Fragestellungen finden können, ist hier auch kein böser Wille vorhanden. Die Leute finden die Knöpfe und ihre Wirkung und benutzen sie.
• <big> – Siehe oben. Die asiatischen Schriftvorlagen könnten nachvollziehbar einen big-Parameter vertragen. Ansonsten soll ohnehin jedes Gewusel aus für europäisch konfigurierte PC nur als Kästchen dargestellten zh, ko, ja, th gefälligst in eine Sprachvorlage eingeschlossen werden, damit man aus dem Namen oder den Parametern der Vorlage erschließen kann, was der Inhalt sein soll. In allen sonstigen Fällen erscheint mir die Verwendung Murks oder es gibt bereits eine umschließende Vorlage für Schriftzeichen, die einen entsprechenden Parameter erhalten kann. Wo es sonst noch eine sinnvolle Anwendung gäbe, kann dies ebenfalls mit einer Vorlage gelöst werden.
• <center> – Siehe oben. Gallery kann inzwischen style="text-align:center" (steht allerdings so aus gutem Grund nicht auf der Hilfeseite). Hier wird wie sonst auch nur eine persönliche Ästhetik bei der Seitengestaltung gefördert; mit dem Ergebnis, dass jeder Artikel im Themengebiet ein anderes Layout bekommt, je nachdem wer grad seine individuellen Gestaltungswünsche ausgelebt hat. Wer div/span kennt und text-align:center kennt, wird nicht daran zu hindern sein, aber man muss die Verseuchung mit überflüssigen Stilen nicht auch noch auf Knopfdruck unterstützen. Tabellenzellen können ebenfalls mit style="text-align:center" formatiert werden, wenn es denn unbedingt sein muss ("text-align:right" ist häufiger richtig sinnvoll, wenn es um Zahlenangaben geht).
• Smiley – Der kann eingebettet werden in eine ggf. angepasste Variante der {{Smiley}} mit einem zweiten Parameter code für nicht-grafische Darstellung und background:#FE3. (Ich kenn schon einen Smiley-begeisterten Diskutanten in diesem Thread, der das umsetzt.) Wer das nicht mag, soll <code> in den Text einfügen; aber um diese nicht-enzyklopädischen Dinger großes Gewese zu machen lohnt sich nicht. Ein

{{Smiley|:-)|code}}

ist jedenfalls kürzer als das bisherige

<tt style="background:#FE3">:-)</tt>

oder gar der Vorschlag

<span style="font-family:monospace;background:#FE3">:-)</span>

usw., und es täte auch:

<code>:-)</code>

• <tt> – Wir kennen keinerlei Bedeutungsunterschied mehr zwischen <tt> und <code>, und das <tt> kann gern geduldet bleiben, aber muss nicht neu eingefügt werden.
  • Früher gab es bei uns wohl mal eine Unterscheidung zwischen tt für einfachen monospace und code mit nowrap und background und irgendwas. Mit syntaxhighlight hat sich das erledigt.
  • Dass Wikisource daraus Antiqua macht, wusste ich nicht; drei Möglichkeiten, um langfristig das <tt> per Tag-Extension aus dem HTML-Output zu scheuchen:
    1. Extension bildet ab auf
       • span class="ttDingsda" style="font-family:monospace"

       Oder ein monospace-Stil wird global für span.ttDingsda ausgeliefert.

       Das halbe Dutzend Wikisource-Projekte setzt sich in der Mediawiki:Common.css ttDingsda geeignet um.

    2. Extension bildet ab auf
       • code class="ttDingsda"

       Wikisource-Projekte setzen sich mit Gewalt in der Mediawiki ttDingsda auf style="font-family:..." – könnte floppen.

       • Wie vor, aber:

       Wikisource-Projekte binden die Extension bis auf Weiteres nicht ein und lassen alles wie bisher.

Überschrift des Thread: Ich pflege etwas über den Tellerrand zu denken und nicht das Einschleppen von HTML-technisch unerwünschten Tags dadurch zu umgehen, dass ich den Wikitext mit anderweitig unerwünschten Tags verseuche. Allgemein ist dies ein Einzelaspekt des großen Themas: Welche Tags im Wikitext?

• <dfn>, <kbd> und <samp> – diese drei wurden mit HTML2+/Netscape2 Mitte der 1990er eingeführt, bevor es style=, class= und CSS allgemein gab. Damals war die einzige Möglichkeit, ein Textelement mit einem separaten Stil zu verbinden, die Definition eines neuen Tags. Heute würde man intelligenter schreiben:
  • <code class="definition">
  • <code class="userinput">
  • <code class="output-screen">
  • <code class="output-printer">

usw.

Schönes Wochenende --PerfektesChaos 12:16, 8. Sep. 2012 (CEST)

Schön zu sehen dass hier sich Zeit genommen wird und wirklich ergiebig diskutiert wird. Ich bin generell eigentlich auch für eine Vereinfachung bzw. Vereinheitlichung. So möchte ich mich einer Empfehlung von euch nicht entgegenstellen. (Die Idee mit der Smiley-Vorlage ist auch nicht soo schlecht, obwohl ich mir jetzt nicht sicher bin ob der erhöhte "Quelltext" eine Vorlageneinbindung rechtfertigt)

• Gallery: geht ebenfalls ohne Style-Angabe, nämlich mit den classes "center" / "centered", wobei Erstere alles zentriert und Zweitere nur die Galerie mit der Angabe perrow (welche vor einiger Zeit noch den Standardwert 4 hatte und daher "centered" auch ohne perrow funktionierte). Das könnten wir eventuell auf dortiger Hilfeseite ergänzen (jedoch würde ich vorher den Vorschlag auf dortiger Diss machen da center wohl nicht ganz einer breiten Empfehlung folgt). Ebenfalls schönes Wochenende -- πϵρήλιο ℗ 17:04, 8. Sep. 2012 (CEST)

Gadget-/Script-Idee

Hi. Vielleicht hat schon jemand ein entsprechendes Script rumliegen - es gibt ja ca. 1 Million Wartungslisten in der Wikipedia und für jeden sind andere interessant. Wenn man einen Artikel aufruft, will man aber oft wissen, ob der Artikel auf einer für einen persönlich relevanten Wartungsliste verlinkt ist. Die Idee des Scripts ist es also, die "Whatlinkshere" per API auszulesen und auf vorher konfigurierte Seiten zu prüfen. Wenn vorhanden, sollte das irgendwo angezeigt werden. Besonderer Schwierigkeitsgrad: Das soll auch mit Unterseiten funktionieren. Beispiel: Ich will nicht alle Unterseiten der Form Wikipedia:PND/Fehlermeldung/September 2012 hinzufügen, sondern nur Wikipedia:PND/Fehlermeldung. Ich komm derzeit nicht dazu, fänds aber cool, wenn es sowas gäbe ;) --APPER\^☺☹ 18:24, 6. Sep. 2012 (CEST)

Gegenfrage: Ist ein Artikel nicht normalerweise aufgrund von Wartungsbausteinen im Artikel auf einer Wartungsliste? --Leyo 18:32, 6. Sep. 2012 (CEST)

Nein, nicht unbedingt. Mir gehts ja entsprechend um Normdaten-Geschichten. Da gibt es z.B. Listen von Artikeln, bei denen vermutlich eine GND-Nummer vorhanden ist... Und ob ein Normdatenfehler bei der Nationalbibliothek mittels Wikipedia:PND/Fehlermeldung gemeldet wurde, wird zwar manchmal im Artikel vermerkt, aber nicht immer... Anderes Beispiel: Bei Seiten die unter Benutzer:APPER/Tn verlinkt sind, muss die GND geprüft und evtl. gemeldet werden, aber dafür gibt es erstmal kein Anzeichen im Artikel. --APPER\^☺☹ 19:03, 6. Sep. 2012 (CEST)

Die Progammierung ist ein Serienprodukt, wenn auch wegen des API-Abrufs der Whatlinkshere nichts für Anfänger. Mir geht es leider genauso; ich ersaufe zurzeit in Programmieraufgaben, aber ich bin sicher, dass dieses Gadget demnächst betriebsbereit sein wird, wenn es nicht schon jemand so ähnlich auf der Festplatte hat.

Das Konzept gefällt mir; vielleicht ist ja bis dahin schon die sagenumwobene mw.notification für die Auflistung der Treffer auf dem Markt.

Liebe Grüße --PerfektesChaos 21:06, 6. Sep. 2012 (CEST)

Mir würde sowas auch gefallen. Steak 15:09, 7. Sep. 2012 (CEST)

Ehe ich es vergesse: Von der Wunschliste sollten die Namensräume ausgelesen und nach wgNamespaceIds abgeglichen werden, um eine reduzierte Liste zu bekommen. Nur nach den gefilterten NR (Benutzer, WP, Portal) sollte dann die API-Abfrage erfolgen, also typischerweise ohne ANR. Bei einer gut verlinkten Seite könnte es einem sonst passieren, dass irgendein 500er-Limit überläuft und die Wunschlisten-Einträge beim Ergebnis nicht dabei sind. VG --PerfektesChaos 16:02, 7. Sep. 2012 (CEST)

jquery.byteLimit und sein Callback

Hallo, die Funktion byteLimit erlaubt es per Callback den eigentlich zu prüfenden Text zu beeinflussen. Man kann somit beispielsweise Namensraum vom Text entfernen oder andere Dinge tuen. (Quelltext).

Mir scheint es aber so, dass das ganze mit Callback irgendwie nicht funktioniert. Führt das nachfolgende mal auf einer js-Seite im Benutzernamensraum aus (nur Vorschaumodus, ohne Speichern)

$( function() {
 $( '#firstHeading' )
 .append( $( '<input id="wpByteLength" type="text" value="" />' ) )
 .append( $( '<input id="wpByteLengthCallback" type="text" value="" />' ) );
});

mw.loader.using( [ 'jquery.byteLimit' ], function() { $( function() {
 $( '#wpByteLength' ).byteLimit( 10 );
 $( '#wpByteLengthCallback' ).byteLimit( 10, function( input ) {
  return input;
 });
})});

Neben der Überschrift gibt es nun zwei Inputs. Das eine begrenzt seine Bytelänge auf 10, das andere erlaubt gar keine Eingabe. Aber eigentlich sollte doch der Aufruf im zweiten Beispiel das gleiche wie der erste aufruf geben, weil ich ja den Text unverändert zurückgebe. Habt ihr eine Idee, was da schiefläuft? Ich nutze IE8, tut aber auch nicht im FF13. Der Umherirrende 19:07, 12. Sep. 2012 (CEST)

Funktioniert in Opera 12. Meine Vermutung: $el.removeprop("maxLength") setzt auf 0, statt sie zu entfernen - inspizier doch mal das Element, wie der Wert wirklich ist. -- ✓ ^Bergi 19:56, 12. Sep. 2012 (CEST)

Ja, ist wohl wirklich so (getestet in FF15) - http://jsfiddle.net/Rtnj6/. Ich schreib gleich mal nen Bugreport :-) -- ✓ ^Bergi 20:11, 12. Sep. 2012 (CEST)

alert( $( '#wpReason' ).prop( 'maxLength' ) ); gibt bei IE und FF "0", im HTML sieht man es auch. Das ist ja ein sehr unschöner Effekt. Wie macht man es aber richtig? Es wäre unschön, wenn man jedesmal nach dem setzen des bytelimits noch .prop( 'maxLength', 10 ) aufrufen muss, um das maxlength wieder zu ändern. Der Umherirrende 20:14, 12. Sep. 2012 (CEST)