Wikipedia

Wikipedia:Technik/Archiv/2012

< Wikipedia:Technik‎ | Archiv

monobook.js

Ich nutze zwar gerne diverse Scripts, habe allerdings keine Ahnung, wie man solche schreibt. Wäre es möglich, solche Änderungen per Script zu machen? Wenn ja, wie? Grüße --Brackenheim 20:38, 8. Jan. 2012 (CET)

Klingt nach autoantraege.js. Verstehe ich dich richtig, dass du beim Baustein-Setzen gleich auf der Antragsseite den Eintrag automatisch miterstellt haben willst? Wenn du hingegen nur auf einer speziellen Seite halbautomatisch (auf Anordnung, d.h. Klick) Abschnitte hinzugefügt haben möchtest, dann kann ich dir so etwas ähnliches wie hier für Buckesfelder basteln. -- ✓ Bergi 21:51, 8. Jan. 2012 (CET)
Oder vielleicht meint er über zwei Abschnitte zu editieren und trotzdem den richtigen Kommentar des Abschnitts zu haben!? Dann wäre dieses Skript für diese Möglichkeit (zu erweitern). Wikipedia:Verbesserungsvorschläge/Feature-Requests#Auto-Zusammenfassung_f.C3.BCr_neue_Diskussionsabschnitte_mit_irref.C3.BChrendem_Bearbeitungskommentar -- πϵρήλιο ℗ 22:47, 8. Jan. 2012 (CET)
Nein, ich habe gerade gesehen er will den Abschnitt löschen. Versuchs mal mit
// Skript von Bergi ([[Benutzer:✓]]) für Benutzer:Brackenheim
// Wikipedia:TSW 2012-01-09
jQuery(function($){
   if (mw.config.get('wgPageName') != "Wikipedia:Importwünsche" || mw.config.get('wgAction') != "view")
      return;
   var sts = new Date().toISOString(); // funktioniert das hier erst in es5?
   function deleteSection(uri, sum) {
      $.post(mw.util.wikiScript("api")+uri, {text:"", summary:sum, token:mw.user.tokens.get('editToken'), starttimestamp:sts, format:"json"})
         .success(function(data) {
            // aus [[mw:API:Edit]] geborgt
            if (data && data.edit && data.edit.result == 'Success') {
               window.location.reload(); // reload page if edit was successful
            } else if (data && data.error) {
               alert( 'Fehler: API returned error code "' + data.error.code + '": ' + data.error.info );
            } else {
               alert( 'Fehler: unerkannte Anwort, bitte Logfiles auf WP:TSW melden' );
               console.debug("API result", data);
            }
         })
         .error(function( xhr ) {
            alert( 'Fehler: Anfrage fehlgeschlagen.' );
         });
   }
   $("span.editsection").each(function(i, span) {
      var url = $(span).find("a").attr('href');
      span.insertBefore(document.createTextNode(" • "), span.lastChild);
      span.insertBefore($("<a>Löschen</a>").click(function() {
         if(!window.confirm("Willst du wirklich diesen Abschnitt löschen?")) // oder hast du dich nur verklickt
            return;
         var sum = "erledigt und weg"; // hier Defaultwert
         do
            sum = window.prompt("Bitte gib eine Zusammenfassung an", sum);
         while (!sum)
         deleteSection(url.substr(url.indexOf('?')), "halbautomatisch: "+sum);
      })[0], span.lastChild);
   });
});
Gerade erfolgreich auf der Spielwiese getestet. Das Skript schaut aber nicht nach, ob im Quelltext der Kommentar mit der Löschaufforderung enthalten ist, sondern löscht rigoros was gerade die richtige die richtige Abschnitts-ID hat. -- ✓ Bergi 01:15, 9. Jan. 2012 (CET)
Hezlichen Dank! Das Script ist echt genial! Und zudem eine praktische Arbeitserleicherung ;-) Ich hätte nur nicht gedacht, dass es so kompliziert aussehen würde... Grüße --Brackenheim 08:32, 9. Jan. 2012 (CET)

Noch kurz ein paar Fragen: Kann man die Frage nach der Zusammenfassungszeile auch einfach weglassen? Im Prinzip ist der im Script stehende Kommentar ja immer ausreichend. In der Zusammenfassungszeile steht leider nicht, welchen Abschnitt man entfernt hat. Könnte man das noch ändern, damit die Zusammenfassung wieder etwa so aussieht: ‎ "(→Import von it:Michele Lacerenza nach Benutzer:Si! SWamP/Artikelwerkstatt: kommt)"? Aber nur, wenn es keinen allzu komplizierten Aufwand bereitet... Grüße --Brackenheim 14:10, 9. Jan. 2012 (CET)

Ja, richtig, das fehlt noch. Ersetze dafür die Zeilen ab var sum = bis inlusive while (!sum) durch:
         var sum = "/* "+$(span.parentNode).find("span.mw-headline").text()+" */ " + "kommt"; // oder "erledigt und weg" oder …
Soo kompliziert ists gar nicht. Nach dem Laden eine Funktion ausführen, die erstmal abbricht wenn man auf der falschen Seite oder im falschen Modus ist. Dann einen aktuellen starttimestamp generieren, der hoffentlich Editkonflikte unterbindet. Die Funktion deleteSection ist erstmal nichts anderes als eine Kopie von mw:API:Edit#Editing via Ajax. Dann wird noch in jedes editsection-span erst ein Trenner und dann ein zweiter Link eingefügt, wessen Eventlistener-Funktion nach einer Absicherung deleteSection aufruft.
Etwas hacky ist dagegen die Vermischung von DOM und jQuery, das ist so kurz geschrieben wie es mir möglich erschien. Außerdem der Edit-Link: mw:API:Edit verlangt die Parameter title und section, die ich einfach als GET-Parameter mitschicke indem ich sie mir aus dem editsectionlink-href hole. -- ✓ Bergi 19:57, 9. Jan. 2012 (CET)
Nochmals Danke - jetzt ist das Script wirklich perfekt ;-) Die Infoseiten werde ich mir dann so nach und nach auch noch durchlesen. Grüße --Brackenheim 20:06, 9. Jan. 2012 (CET)
Falls zwischen dem Laden der Seite und dem Löschen des Abschnitts ein anderer Abschnitt obendrüber gelöscht wurde, dann wird das Skript einen falschen Abschnitt löschen. --Schnark 10:26, 10. Jan. 2012 (CET)
Ist dafür nicht starttimestamp:sts drin? Und es wird empfohlen das Token als letzten Parameter zu senden. -- RE rillke fragen? 12:00, 10. Jan. 2012 (CET)
starttimestamp ist hier mehr oder weniger sinnlos, da das nur dagegen schützt, dass man die Seite neu anlegt, falls sie in der Zwischenzeit gelöscht wurde. --Schnark 12:14, 10. Jan. 2012 (CET)
@Schnark: soll man denn lieber den jetzigen Zeitpunkt (bzw. den des Ladens der Seite) als basetimestamp mitschicken? Ich weiß nicht, ob das gültig wäre, ich habe die API sonst immer nur mit vorheriger info-Abfrage benutzt, die mir beide Timestamps bereitstellt.
Die mehrfache Löschung versuche ich mit location.reload() zu unterbinden, damit erspare ich mir recht elegant das Ausblenden des gelöschten Abschnitts und das Anpassen der Editsectionlinks - geklaut aus dem Beispielskript. Vielleicht wäre aber tatsächlich ein ?diff=cur nicht schlecht.
@Rillke: Wegen dem Backslash-Fehlescaping-Test? Dem sollte eigentlich die Position egal sein, auch habe ich keinen Einfluss darauf in welcher Reihenfolge Objekte serialisiert werden. Abgesehen davon übertrage ich ja eben keinen relevanten text :-) -- ✓ Bergi 14:25, 10. Jan. 2012 (CET)

Ich hätte doch noch kurz eine Frage: Kann man solche Änderungen auch per Script durchführen? Das Einfügen der Vorlage würde ja schon ausreichen... Grüße --Brackenheim 17:54, 11. Jan. 2012 (CET)

Das Einfügen von Text am Anfang (hier: Vorlageneinbindung) ist ein trivialer API-Befehl. Wenn du jedoch zusätzlich noch Textersetzungen durchführen willst, würde ich dir einen Link in der Edit-Ansicht empfehlen, bei dessen Betätigung diese Korrekturen ausgeführt werden. Ich kenne mich jetzt nicht aus, ob man das irgendwie geschickt in deine PDD-monobook integrieren kann, prinzipiell sieht es so aus:
$(function() {
   if (!$.inArray(mw.config.get('wgAction'), ["edit", "submit"]) || mw.config.get('wgNamespaceNumber')!=2)
      return;
   $(mw.util.addPortletLink("p-tb", "#", "Importartikel", "js-handleimport", "führt häufig benötigte Änderungen an importierten Artikeln aus")).find("a").click(function(e){
      var t = document.getElementById("wpTextbox1");
      t.value = "{{Importartikel}}\n" + t.value
      .replace(/\[\[(Kategorie|Category):/gi, "[[:Kategorie:")
      .replace(/{{Reflist}}/gi, "<references />")
      .replace(/{{Main\|/gi, "{{Haupartikel|");
      // …
      e.preventDefault(); // Link (hier: Sprungmarke) nicht folgen
   });
});
-- ✓ Bergi 19:21, 11. Jan. 2012 (CET)
Kann das irgendwie bei Benutzer:Brackenheim/importwünsche-entfernen.js mit auf die Seite? --Brackenheim 14:08, 12. Jan. 2012 (CET)
Ja, einfach direkt drunter. Damit du es auch findest: Das Skript fügt im BNR im Bearbeitenmodus links im Kasten „Werkzeuge“ (im Monobook-Skin sollte der auch nicht eingeklappt sein) einen Link „Importartikel“ hinzu. Beim Draufdrücken findet im Textfenster die Ersetzung statt. Wenn du den Link woanders hinhaben möchtest, unter Wikipedia:GUI findest du die Alternativen zu "p-tb" – oder einfach hier nachfragen. -- ✓ Bergi 19:19, 12. Jan. 2012 (CET)
Ich denke, der Platz ist so ok... Wenn ich auf den Link klicke, wird die Seite allerdings nur neu geladen, ohne dass die Vorlage hinzugefügt wurde. Habe ich es falsch eingebunden oder liegt es vielleicht an dem ".replace"-Teil? "Category" steht ja nur bei Importen aus en.wiki da. --Brackenheim 20:11, 12. Jan. 2012 (CET)
Nö, ich habs falsch gescriptet – und nicht getestet. Jetzt sollte es gehen.
Die Kategorien könnte man selbstverständlicherweise aus jeder Sprachversion anpassen. Ich kann aber nur de, en und bar; außerdem ist das hier die Minimallösung mit allen Kategorie-Ausdrücken die in der deutschen WP einen Katlink zur Folge haben (en funktioniert immer, de ist "nur" lokalisiert). Keiner hindert dich daran, die replace-Kette mit weiteren regulären Ausdrücken weiter auszubauen :-) -- ✓ Bergi 20:25, 12. Jan. 2012 (CET)
Klappt noch nicht - ich versuche es später aber nochmals... Gruß --Brackenheim 21:22, 12. Jan. 2012 (CET)
Hat leider bei mir nicht funktioniert. Ich habe aber ein Script vom Hexer gefunden, das ich nehmen kann - dann sind es halt zwei einzelne Scripte... ;-) Danke für all die Hilfe und Unterstützung! Grüße --Brackenheim 13:25, 13. Jan. 2012 (CET)
Ein Grund könnte die Codestelle sein:
!$.inArray(mw.config.get('wgAction'), ["edit", "submit"])
gibt bei mir 0 zurück was als false interpretiert wird, müsste also konkret so aussehen:
$.inArray(mw.config.get('wgAction'), ["edit", "submit"]) == -1
Ist mir gerade aufgefallen, da ich den Code auch bei mir eingebaut hatte.PS. Wie sollte am besten der Code für MW 1.19 aussehen?[1] -- πϵρήλιο ℗ 14:07, 14. Jan. 2012 (CET)
Ja, das ist richtig. Ich vergesse immer, dass $.inArray trotz seines Namens keinen boolean-Wert zurückgibt, sondern auch nur simples indexOf darstellt.
@MW 1.19: ["edit", "submit"].indexOf(mw.config.get('wgAction'))>-1 funktioniert weiterhin, kürzer kann man es als mw.config.get('wgAction')!="edit" schreiben. -- ✓ Bergi 20:27, 15. Jan. 2012 (CET)

Funktioniert alles sehr gut! Ich hoffe mal, dass ich jetzt nicht einfach so eine Diskussion abbreche... Grüße --Brackenheim 15:01, 20. Jan. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Brackenheim 15:01, 20. Jan. 2012 (CET)

NavFrame standardmäßig eingeklappt funktioniert nicht

Bei Fragen von Neulingen wurde bei einem Problem an die Werkstatt hier verwiesen. Ich bitte darum mich nicht digital zu steinigen falls das hier fehl am Platz ist, ich bin selbst noch Neuling. Es geht um folgendes:

Es gibt ein- und ausklappbare Navigationsleisten, die sich mit folgendem Code erstellen lassen:

<div class="NavFrame">

Standardmäßig ist diese immer ausgeklappt. Im englischen Wikipedia lässt sie sich durch den Zusatz "collapsed" eingeklappt laden (siehe Beschreibung), also:

<div class="NavFrame collapsed">

Im deutschen Wiki funktioniert das aber nicht, wohl fehlt dazu etwas in der MediaWiki:Common.js. Wäre es möglich den entsprechenden Teil aus der en:MediaWiki:Common.js einzufügen? Spricht etwas dagegen, bzw. gibt es doch andere Möglichkeiten NavFrames standardmäßig einzuklappen? --LordOider 00:16, 9. Feb. 2012 (CET)

Wenn in einem Artikel mehr als eine Navigationsleiste ist, so werden alle eingeklappt, einzelne bleiben ausgeklappt. Die Anzahl (default eben 1) kann sich jeder selbst einstellen. Um von diesem festen Schema abzuweichen, bräuchte es schon einen gewichtigen Grund.
Ansonsten, ja, es gibt einen Hack der (bei der Defaulteinstellung von 1) eine Navigationsleiste einklappt, aber der ist nicht schön. Für Tabellen soll der Navigationsleistencode sowieso nicht missbraucht werden; wir haben hier kein Platzproblem – entweder eine Tabelle gehört in den Artikel oder sie ist überflüssig und kann raus. Wenn es unbedingt sein muss kann man auch {| class="wikitable mw-collapsible" verwenden. -- ✓ Bergi 00:58, 9. Feb. 2012 (CET)
Danke für die Information. --LordOider 14:45, 9. Feb. 2012 (CET)


Archivierung dieses Abschnittes wurde gewünscht von: LordOider 14:45, 9. Feb. 2012 (CET)

Benutzer:Iste Praetor/rollback.js

Hallo! Wenn ich das oben verlinkte Skript auf der Seite Benutzer:Iste Praetor/vector.js einbinde (Versuch 1, Versuch 2), ist es komplett funktionsunfähig – es wird weder der Text der Rollback-Links verändert, noch erscheinen die Links zum Smart rollback-Tool. Wird dagegen der Text des Skripts einfach in die vector.js kopiert (aktueller Zustand), funktioniert alles wie gewünscht. Wo liegt der Fehler bei meinen Einbindungsversuchen? Grüße --Iste (D) 11:11, 11. Feb. 2012 (CET)

<http://meta.wikimedia.org/wiki/User:Hoo_man/Scripts/Smart_rollback> ist nun mal kein gültiges Javascript, wenn das außerhalb eines Kommentars vorkommt, kann das nicht funktionieren. --Schnark 11:17, 11. Feb. 2012 (CET)
Das befindet sich doch gar nicht außerhalb eines Kommentars, sondern ist sowohl in der rollback.js als auch in der vector.js auskommentiert. Grüße --Iste (D) 11:20, 11. Feb. 2012 (CET)
Ah, ich sehe gerade, dass ich die URL vorher in der vector.js nicht vollständig auskommentiert hatte. Jetzt funktioniert es wunderbar! Vielen Dank für deine Hilfe! Grüße --Iste (D) 11:26, 11. Feb. 2012 (CET)
Archivierung dieses Abschnittes wurde gewünscht von: Iste (D) 11:41, 11. Feb. 2012 (CET)

Skript gesucht

Gnarf. Seit gestern funktioniert mein Skript nicht mehr. Ich benötige im Grunde nur folgende Funktionen:

  • Link auf "Neue Seiten"
  • einen Button, um automatisch einen QS-Antrag zu stellen (da kam bisher eine kleine Eingabemaske, welche den QS-Grund abfragte und dann wurde das automatisch im Artikel und der QS eingetragen)
  • selbiges für LA
  • ein Button für SLA
  • und meine eigene Signatur in grün hinterlegt. (also eigentlich immer wenn irgendwie "Weissbier" vorkommt)

Hat jemand von Euch sowas für mich? Büdde!!! WB Looking at things 11:11, 2. Mär. 2012 (CET) (Ich wurde von WP:FZW hierher verwiesen. Die angeratene Lösung Benutzer:Schnark/js/autoantraege.js funktioniert leider NICHT, trotz mehrfachem Strg+R.)

So sollte es funktionieren. --Leyo 11:17, 2. Mär. 2012 (CET)
Zur Signatur siehe Hilfe:Signatur#Signaturen_hervorheben, für den Link zu den neuen Seiten empfehle ich den Code
$( function() {
	mw.util.addPortletLink( 'p-Mitmachen',
		mw.util.wikiGetlink( 'Special:NewPages' ),
		'Neue Seiten',
		'n-newpages',
		'Liste der neuen Seiten',
		null, // access key
		'#n-recentchanges' );
} );
in deiner vector.js, das fügt den Link oberhalb der Letzten Änderungen ein. --Schnark 11:44, 2. Mär. 2012 (CET)
Nur so zur Info, sie nutzt Benutzerin:Weissbier/monobook.js (ein altes Bluefish-derivat, wie angekündigt von '08) :-) -- ✓ Bergi 12:03, 2. Mär. 2012 (CET)

Ich bin auch Vector umgestiegen. Es klappt wie es soll. Vielen vielen Dank!!! WB Looking at things 16:40, 2. Mär. 2012 (CET)

Ah, richtig. Wer's mag... -- ✓ Bergi 17:50, 2. Mär. 2012 (CET)
Archivierung dieses Abschnittes wurde gewünscht von: -- ✓ Bergi 17:50, 2. Mär. 2012 (CET)

Seiten verschieben

Ich hätte gerne die alte Verschieben-Seite wieder, siehe Wikipedia:Fragen_zur_Wikipedia#Verschieben. Hat jemand eine Idee, wie das geht? Grüße --Brackenheim 18:24, 2. Mär. 2012 (CET)

Versuchs mal mit folgendem Skript:
String.prototype.beginsWith = function beginsWith(s) {
// utility function (provided by Bergi), checks whether a string is the prefix of another
    return this.substring(0, s.length) === s;
};
// Stattet das Verschiebe-Formular mit automatischer Namensraum-Erkennung im Textfeld aus
// Skript von Bergi ([[Benutzer:✓]]) aus der Wikipedia:TSW, 2012-03-02
$(function() {
    if (mw.config.get('wgNamespaceNumber') != -1 || mw.config.get('wgCanonicalSpecialPageName') != "Movepage")
        return;
    var nsselected = false;
    var nsmap = mw.config.get('wgNamespaceIds');
    var $ns = $("#wpNewTitleNs").change(function(){
        nsselected = true; // verhindere ungewolltes Überschreiben eines fest gesetzten NS
    });
    $("#wpNewTitleMain").on("input keyup mouseup change", function() {
        if (nsselected)
            return;
        var v = this.value.toLowerCase();
        for (var ns in nsmap)
            if (v.beginsWith(ns+":")) {
                $ns.val(nsmap[ns]); // selects the namespace option
                this.value = this.value.substr(ns.length+1); // entferne NR-Präfix
                nsselected = true; // nur einmal ausführen
                break;
            }
    });
    // Portalseiten standardmäßig in den BNR verschieben
    $ns.val(function(i, ns){return ns==100?2:ns;});
});
hilft -- ✓ Bergi 19:39, 2. Mär. 2012 (CET)
Man könnte auch das vorhandene Ausblenden und die alte Eingabe simulieren, weil der Parameter wpNewTitle weiterhin unterstützt wird. Der Umherirrende 19:49, 2. Mär. 2012 (CET)
Och, so ein Einzeiler wär' doch langweilig ;-) Ich hingegen finde es sinnvoll, dass der NR jetzt deutlich vom Titel abgesetzt ist. -- ✓ Bergi 20:12, 2. Mär. 2012 (CET)
Danke! Kann man noch einstellen, dass im Portalnamensraum immer der Benutzernamensraum vorgeschlagen/eingestellt wird? Gruß --Brackenheim 22:24, 2. Mär. 2012 (CET)
Warum auch immer du das willst, mit dem ergänzten Einzeiler vor den letzten Klammern sollte es gehen. -- ✓ Bergi 23:09, 2. Mär. 2012 (CET)
Ganz einfach: Schau mal, wohin ich fast alles importiere ;-) Danke für das Script! Grüße --Brackenheim 23:19, 2. Mär. 2012 (CET)
Kann man denn nicht direkt in den BNR importieren? Das ist doch ziemlich umständlich so, etwa nicht? -- ✓ Bergi 23:30, 2. Mär. 2012 (CET)
Ich habe es noch nie versucht und mich immer an Hilfe:Import gehalten. Doch selbst wenn man den Artikel in den BNR importiert, muss er trotzdem auf die Benutzerunterseite verschoben werden. Die Funktion, Portalseiten standardmäßig in den BNR zu verschieben, hat leider nicht geklappt. Grüße --Brackenheim 23:44, 2. Mär. 2012 (CET)
OK, da wäre wohl mal ein Bugreport für das import-Modul fällig. Die Import-Hilfe spricht ja sogar von Portal-Diskussionen :-) -- ✓ Bergi 00:00, 3. Mär. 2012 (CET)
Der Vorlagen-Namensraum war auch mal dran, das geht irgendwie der Reihe nach durch... Ich habe mich einfach fürs Portal entschieden =) Gruß --Brackenheim 10:59, 3. Mär. 2012 (CET)
Archivierung dieses Abschnittes wurde gewünscht von: Brackenheim 14:34, 4. Mär. 2012 (CET)

MediaWiki:Gadget-Pfeil-hoch.js

Bei dem Gadget (hat auch CSS) findet sich ein Kommentar "moveEditsection not run yet" der sich auf Monobook.js/Vector.js und die Ladereihenfolge bezieht. Wenn ich jetzt den ResourceLoader auf dieses Gadget loslasse, passt das dann immer noch, oder sollte man das eleganter lösen? Eigenltich sollte das auch weiterhin passen, weil erst Gadgets, dann Site/Skin und dann User geladen wird. Kann man das gefahrlos machen? Was meint ihr? Der Umherirrende 13:19, 25. Feb. 2012 (CET)

Man sollte 2012 überhaupt keinerlei Annahmen mehr treffen, in welcher Reihenfolge was geladen wurde und was eigentlich schon hätte passiert sein müssen.
Ohne jetzt in das Detail geguckt zu haben:
  • Das Modul site enthält die standardmäßigen Mediawiki:*.js und .css – damit sollte das Gadget in jedem Fall mit .using() den definierten Ausgangszustand abwarten und erst danach tätig werden.
Dass momentan erst die Gadgets geladen würden und danach site – beobachte ich so nicht beim Belauschen des traffic.
Von der Systematik her kann es sein, dass es irgendwann einmal Gadgets geben wird, die als "top" markiert werden, andere als "bottom".
HGZH --PerfektesChaos 15:24, 25. Feb. 2012 (CET)
Soweit ich es nachvollziehen kann, werden Gadgets ohne RL-Unterstützung vor MediaWiki:*.js und Benutzer:*/*.js geladen, die mit danach. Aber verlassen sollte man sich da wirklich auf nichts. --Schnark 09:24, 27. Feb. 2012 (CET)
Das mit ±RL kann gut sein; ich habe nur wenige Gadgets und die wohl alle mit RL. Ich denke aber, dass auch von der Logik her „Gadgets nach site/user“ der geplante Endzustand sein dürfte, weil Konfigurationseinstellungen in site/user sonst keinen Einfluss mehr auf eine autorun im Gadget haben könnten. VG --PerfektesChaos 09:40, 27. Feb. 2012 (CET)
Dann erkläre das mal APPER und vor allem den Benutzern von Wikipedia:Helferlein/Revision Counter und Wikipedia:Helferlein/Begriffsklärungs-Check, die werden sich nämlich sehr freuen, wenn sich die Reihenfolge ändert. --Schnark 10:30, 27. Feb. 2012 (CET)
Wegen des Problems mit der Reihenfolge bin ich auch hier. Nach dem ich in der Monobook.js das addOnloadHook gegen $ ausgetauscht hatte, kamen auf WP:FzW die Meldung, dass der Pfeil nach oben nicht mehr da ist. Erste Maßnahme war, auch das Gadget auf $ umzustellen, weil dann wieder die alte Ladereihenfolge eingehalten wird. Der RL-Support bei den Gadgets muss eh individuell geprüft werden, da sind die Auswirkungen nicht immer erkennbar. Der Umherirrende 19:23, 27. Feb. 2012 (CET)


Also, ich fang mal mit dem RevisionCounter an:

  • Das ist ordentlich geschrieben und war Anfang 2010 auf der Höhe der Zeit, ihr sogar mit Objekt-Funktionen voraus.
  • Man wird sich darauf einstellen müssen, dass erst das user und danach die Gadgets geladen werden.
  • Bei einem schnellen asynchronen Browser kann es aber passieren, dass die Gadgets schneller fertig geworden sind (weil diese Version auf einem Proxy-Server lag), als user neu von einem Wiki-Server abrufbar waren.
  • Man darf 2012 bei Neuprogrammierungen oder grundlegenden Überarbeitungen grundsätzlich keine Reihenfolgen mehr unterstellen, sondern muss explizit eine erforderliche Synchronisation durch Deklaration von Abhängigkeiten herstellen.
  • Im Benutzerskript kann nicht mehr stehen:
    if (window.revisionCounter) revisionCounter.checkOnlyOnHistory = false;
  • Bei den 7 Benutzern muss dies künftig geschrieben werden als:
    if (! mw.libs.revisionCounter) {
       mw.libs.revisionCounter  =  { };
    }
    mw.libs.revisionCounter.checkAllPages  =  true;
  • In einem konfigurierbaren Gadget muss es heißen:
    mw.loader.using("user", mw.libs.revisionCounter.init);
  • Die (künftigen?) Gadget-defi werden erlauben, diese Abhängigkeit auch schon auf der defi-Seite anzugeben; dann mag das dort geschehen.
  • In einem über mw.loader.load() geladenen Skript hat man im Unterschied zum Gadget die Kontrolle über die Ladereihenfolge.
  • RevisionCounter ist dazu geeignet, als weltweites Gadget internationalisiert zu werden; vielleicht findet sich bereits eine msg Total für "Insgesamt".
  • Es gibt noch mehrere ähnlich aufgebaute Gadgets. Hilft nichts, man muss sowas neuen Technologien wie dem asynchronen Laden anpassen.

Nun zum "Pfeil-hoch":

  • Es ist eine Knobelaufgabe, die "Pfeil-hoch", "Bearbeiten-Links Links", "Bearbeiten-Links Rechts" und MediaWiki:Vector.js etc. samt oldEditsectionLinks so durch CSS und HTML auszutüfteln, dass der jeweils gewünschte Effekt unabhängig von Modifikationen durch die jeweils anderen Dinger eintritt, wurst wer in welcher Reihenfolge da schon dran herumgebaut hatte.

LG --PerfektesChaos 10:11, 28. Feb. 2012 (CET)

Für den RevisionCounter sollte ein eigener Abschnitt begonnen werden oder sich hier mit eingeklinkt werden. Ich hatte im Testwiki, das Pfeil-Hoch-Helferlein mal auf jQuery umgeschrieben und die Abhängigkeit an welcher Position ".editsection" ist umgegangen, indem jQuery das sucht. Ist die Lösung so in Ordnung, oder gibt es da Performanzprobleme mit? Ihr könnt das gerne anpassen, falls ihr etwas eleganteres findet. Der Umherirrende 20:27, 28. Feb. 2012 (CET)
Die Eingangsbemerkung ist ein Missverständnis? – Ich hatte nicht die Absicht, mich tiefer mit diesem Gadget speziell zu beschäftigen, sondern mit der aufgeworfenen Frage nach der Reihenfolge von Laden, Benutzerskript und tatsächlicher Ausführung eines Gadget allgemein. Liebe Grüße (1) --PerfektesChaos 21:45, 28. Feb. 2012 (CET)


Ich habe es etwas überarbeitet:
$( function () {
	for ( var level = 1; level <= 6; ++level ) {
		mw.util.$content.find( 'h' + level + ' .mw-headline' ).each( function () {
			$( document.createElement( 'a' ) )
			.addClass( 'toparrow noprint' )
			.text( '↑ ' )
			.attr( 'href', '#' )
			.click( function () {
				window.scrollTo( 0, 0 );
				return false;
			} )
			.insertBefore( this );
		} );
	}
} );

Vielleicht sollte auch noch das Leerzeichen aus dem a herausgezogen werden, weil es nicht zum Link gehört. --Fomafix 21:15, 28. Feb. 2012 (CET)


Was die "Pfeil-hoch" angeht: 'h' + level + ' ' könnt ihr vermutlich streichen, samt der level-Schleife. Soweit mir die Seiten bekannt sind, hat kein anderes Element als eines innerhalb Hn mit n=2,3,… die .mw-headline – damit findet jQuery alle Mitglieder der Klasse mw-headline und braucht das nicht zu verifizieren. Das level stammt aus der DOM-Zeit, als man nur getElementsByTagName hatte und nicht alle Mitglieder einer Klasse finden konnte. H1 bekommt jetzt keinen Pfeil (mehr?), aber da oben ist das hoffentlich wurst. Nicht vergessen: .using("mediawiki.util",) zur Sicherheit. Im Übrigen würde ich das komplette Gadget samt jQuery(document).ready und allem Drum und Dran aber in eine Abfrage auf Spezialseiten und VG einschließen. wgNamespaceNumber>=0 && "view|edit|submit".indexOf(wgAction)>=0 sollte auf Seiten beschränken, auf denen es tatsächlich eine editsection geben kann. – Das Leerzeichen im Link wird wahrscheinlich von Tidy oder dem Browser rausgeschmissen. Wenn das Leerzeichen zu irgendwas dahinter abgrenzen soll, müsste ein <span>&nbsp;</span> hinter das <a> gesetzt werden.
Liebe Grüße (2) --PerfektesChaos 21:45, 28. Feb. 2012 (CET)
Nochmal draufguckend: Ich würde vorab in der document.ready-Funktion ein var $arrow=jQuery("<a />"); bilden, dies mit den Attributen und Klasssen usw. ausrüsten, danach davor und/oder dahinter eventuell gewünschte nbsp hängen. In der .each() würde ich dann nur noch einen $arrow.clone() beim this einfügen. Schönen Abend --PerfektesChaos 21:57, 28. Feb. 2012 (CET)
Danke für die Kommentare. Ein Performanz-Problem sehe ich im Moment nicht, wenn es nichts findet, ist es wohl schnell vorbei. Es gibt so viele Situationen zu unterschieden, das die Unterscheidung auch Zeit braucht. Der Umherirrende 21:05, 7. Mär. 2012 (CET)
Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 21:05, 7. Mär. 2012 (CET)

Anzeige aller Weiterleitungen

Hallo liebe Bastler, die Toolbar enthält ja bereits einen Link „Links auf diese Seite“. Ich hätte gern für meine common.js einen Codeschnippsel, um direkt darunter die gefilterte Version zu erhalten, sprich: Vorlageneinbindungen und Links ausgeblendet, nur Anzeige von Weiterleitungen. Wikipedia:Technik/Skin/GUI#addPortletLink habe ich gelesen, aber leider hat das noch nicht mal dazu geführt, daß zwischen „Links auf diese Seite“ und „Änderungen an verlinkten Seiten“ überhaupt ein neuer Eintrag erzeugt wird (wäre ja auch zu einfach gewesen). Gruß --Schniggendiller Diskussion 22:50, 16. Mär. 2012 (CET)

<quetsch />
  • Ein Komma hinter dem vorletzten Parameter wird dir guttun, dann wird das Link schon mal sichtbar.
  • wgArticlePath liefert die konstante Zeichenkette "/wiki/$1" und ist für etwas anderes gedacht.
  • Du brauchst vielmehr für den Parameter Aktion:

"/w/index.php?title=Spezial:Linkliste/" + mw.util.wikiUrlencode(mw.config.get("wgPageName")) + "&hidelinks=1&hidetrans=1",

Ungetestet, sollte aber gehen. Ansonsten ein löblicher Versuch zur Selbsthilfe; gern wieder. Schönes Wochenende --PerfektesChaos 08:39, 17. Mär. 2012 (CET)
Erstaunlich, was ein simples Komma anrichten kann, das Fehlen führte nämlich dazu, daß die meisten oder gar alle anderen Bestandteile meiner .js ihren Dienst einstellten.
Dein Schnippsel hat geholfen, es funktioniert und scheint auch keine Nebeneffekte zu haben. Wunderbar! Vielen Dank und auch dir ein schönes Wochenende wünscht --Schniggendiller Diskussion 14:34, 17. Mär. 2012 (CET)
Trifft vielleicht nicht ganz Deine Frage, ist aber für andere Mitlesende evtl. interessant: Ich habe in meiner monobook.css die Zeile
a.mw-redirect { color:#551A8B; }
womit alle Weiterleitungen in einer anderen Farbe als die Links auf "normale" Lemmata angezeigt werden. Halte ich persönlich für sehr nützlich. --Mabschaaf (Diskussion) 23:18, 16. Mär. 2012 (CET)
Kenne ich und nutze ich schon lange, da tatsächlich sehr sinnvoll ;-) Gruß --Schniggendiller Diskussion 14:34, 17. Mär. 2012 (CET)
Archivierung dieses Abschnittes wurde gewünscht von: Schniggendiller Diskussion 14:34, 17. Mär. 2012 (CET)

a:hover

Kann mann hier inline bei den unterstrichenen Links die Linien bei Mouseover transparent/dunkelrot/weiß werden lassen? -- Cherubino 21:14, 17. Jan. 2012 (CET)

Verstehe ich jetzt nicht so restlos.
Du hast eine ständige Unterstreichung mit einem text-decoration:none kombiniert.
Wenn ich CSS wäre, wüsste ich nicht so genau, was du denn wann von mir möchtest.
a:hover {
   text-decoration: underline;
}
Was Browser meist nicht mitmachen, ist eine echte Text-Unterstreichung in einer anderen Farbe als der Text. Dies lässt sich mittels border-bottom simulieren, müsste aber in das Link einbezogen werden.
Für den Anfang einen schönen Abend --PerfektesChaos 21:50, 17. Jan. 2012 (CET)
Um die Frage zu beantworten: hover-Stile sind in Vorlagen nicht möglich. Außerdem habe ich in meinen Einstellungen das Unterstreichen aller Links aktiviert, weshalb ich immer blauen Unterstriche habe. Das lässt sich auch durch keinen Kniff ändern. --TMg 22:11, 17. Jan. 2012 (CET)
Ich hätte es gerne ständig weiß unterstrichen. So ungefähr wie hier. -- Cherubino 22:32, 17. Jan. 2012 (CET)
Schon klar. So wird es auch bei mir weiß. --TMg 22:40, 17. Jan. 2012 (CET)
Danke :-) -- Cherubino 23:17, 17. Jan. 2012 (CET)

Geht das auch so wie bei www.spiegel.de, dass der Link erst weiß ist, und bei Mouseover weiß unterstrichen wird? -- Cherubino 23:47, 17. Jan. 2012 (CET)

Ja, aber dann nur für dich persönlich. Diese oben schon mal benannten Zeilen in deine common.css schreiben; gilt dann für alle Links. Ansonsten spezifische Gelegenheiten selektieren, siehe WP:CSS.
a:hover {
   text-decoration: underline;
}
VG --PerfektesChaos 00:05, 18. Jan. 2012 (CET)
wau  |  piep  |  miau
Danke, war ja nicht für mein Skin gedacht, sondern für ein Portalbanner. -- Cherubino 00:40, 18. Jan. 2012 (CET)
Da wird’s dann schwierig. Wüsste ich nicht inline für einen beliebigen Leser, ohne sich (nachvollziehbaren) Protest bei den Hütern der globalen Common.css einzufangen. Ich les aber gerne zu morgen im allerneuesten CSS nach Tricksereien nach, ob man inzwischen ein inline-:hover zaubern kann. --PerfektesChaos 00:53, 18. Jan. 2012 (CET)
Wie ich schon sagte, das ist nicht möglich. --TMg 00:58, 18. Jan. 2012 (CET)
Schade, dachte ich mir schon nach [2] und [3] -- Cherubino 01:28, 18. Jan. 2012 (CET)
Archivierung dieses Abschnittes wurde gewünscht von: Perhelion (Diskussion) 14:47, 30. Mär. 2012 (CEST)

Extra-Editbuttons

Seit der Umstellung auf 1.19 funktioniert dieses von der de-WP nach Commons übernommene Gadget bei mir (FF 10.0.2, Win XP) nicht mehr. Auch die Umstellung auf mw.loader.load hat nichts gebracht. Kann jemand helfen? --Leyo 14:44, 29. Feb. 2012 (CET)

Ich hatte nicht gedacht dass der Fall tatsächlich eintreten würde. Die kaputte Version, die derzeit auf Commons läuft (112130) passt zu diesem Gadget. Mit der URL http://de.wikipedia.beta.wmflabs.org/w/index.php?title=MediaWiki:Gadget-Extra-Editbuttons.js&oldid=2024&action=raw&ctype=text/javascript in deinem Skript sollte es also erstmal wieder laufen – vermutlich aber nicht lange :-(. -- ✓ Bergi 18:02, 29. Feb. 2012 (CET)
Danke, ich hab's versucht. Nun bekomme ich einen einzigen Button (Redirect) angezeigt… --Leyo 23:38, 29. Feb. 2012 (CET)
Bei mir funzen noch nicht mal die standard Edittools bzw. die Erweiterte mehr ... seit heute geht's wieder aber nur sporadisch, scheint laggy zu sein. -- πϵρήλιο ℗ 00:09, 1. Mär. 2012 (CET)
machen wir unter Wikipedia:Fragen zur Wikipedia#MW1.19: Problem - Extraeditbuttons weiter, oder besser hier? --✓ Bergi 13:33, 1. Mär. 2012 (CET)
JS-Technik: Bitte hier zentral.
  • FzW-Beobachter dürften von techno genervt sein.
  • Es ist auch der zentrale Ort, um im Querschnitt zu Editbuttons auf deWP, Commons, mw.toolbar, Gadgets, MediaWiki:Commons.js zu kommunizieren.
  • Resultate werden hier archiviert.
Ich habe keine Editbuttons … --PerfektesChaos (D) 18:32, 1. Mär. 2012 (CET)
wobei Leyo ja das deWP-Script fremdnutzt – die meisten Wikis kennen nur mwCustomEditButtons zum Ergänzen von Buttons. Ich hab derzeit auch grad keine :-( --✓ Bergi 18:43, 1. Mär. 2012 (CET)

OK. Ich habe jetzt ein mMn funktionsfähiges Script auf test.wikipedia.org entwickelt. Freigegeben zum ausführlichen Testen, insbesondere mit verschiedenen Browsern. Das Gadget kann in den Einstellungen ganz unten (#testmode) mit und ohne Ressourceloader aktiviert werden. Probleme waren (und sind?):

  • Das Inline-Script wartet neuerdings auf das mediawiki.action.edit-modul, welches aber dynamisch und somit meist (üblicherweise? - ich konnte nichts anderes testen) nach $.ready lädt. Daher sind die Buttons auch nicht mehr als Array verfügbar, da von addButton() sofort ins DOM geschrieben (und nicht gespeichert).
  • Auf dem Test-Wiki läuft ein /edit.js, welches mwCustomButtons befüllt - nicht verwirren lassen. Ich kanns auch wegschalten, wenn gewünscht.
  • Das Skript jongiliert jetzt irgendwie mit den verschiedenen Button-Arrays herum. Kann da bitte nochmal jemand drüberschauen? Zustände sind (eben nicht chronologisch):
    • domReady - ändert das Verhalten von addButton, führt mw.toolbar.onReady, mw.toolbar.init (wie lange noch?) und extraEditButtons-ready aus - in irgendeiner Reihenfolge
    • mediawiki.action.edit wird geladen und ausgeführt, danach das addButton()-Feld aus dem inline-Script und extraEditButtons (in welcher Reihenfolge?)
    • das Gadget ohne RL wird immer nach dem inline-Script geladen (hoffentlich?), mit RL wohl nur vermutlich. Diese Reihenfolge beeinflusst die Listener-Registration und damit die Ausführung
    • irgendwelche anderen Scripte mögen irgendwann mwCustomButtons befüllen
    • die userscripte und site-scripte werden irgendwann geladen (dynamisch oder in fester Reihenfolge?)

Ihr könnt gerne nochmal drüberschauen. --✓ Bergi 18:43, 1. Mär. 2012 (CET)

Auf Ws und Wq läuft schon die Test-wiki version problemlos, bitte hier die MediaWiki:Gadget-Extra-Editbuttons.js‎ auch ersetzen und Danke! -- Paulis 22:14, 4. Mär. 2012 (CET)
Kopiert. Da man wohl nicht mehr kaputt machen kann, als es wohlmöglich ist, scheint mir das ausprobieren hier ungefährlich zu sein. Der Umherirrende 20:26, 5. Mär. 2012 (CET)

Jetzt funktioniert es bei mir unter Commons wieder. Vielen Dank an die „Verantwortlichen“! Nur den Redirect-Button habe ich nun doppelt (1. und 13. Position), aber das ist natürlich kein wirkliches Problem. --Leyo 19:06, 6. Mär. 2012 (CET)

FYI: Auf WP:FzW wurde auch noch etwas von doppelten Buttons geschrieben. Der Umherirrende 19:12, 6. Mär. 2012 (CET)
Nun funktioniert es wieder nur halb, d.h. ich kriege nur die 11 Standard-Buttons. --Leyo 09:58, 7. Mär. 2012 (CET)
rev:112573 wurde live geschaltet. --Schnark 11:44, 7. Mär. 2012 (CET)
Ich habe unter Benutzer:P.Copp/scripts/Extra-Editbuttons.js einen Vorschlag eingestellt, wie das Skript etwas robuster geschrieben werden kann. Entscheidend ist, dass die Manipulation der Toolbar erst nach dem Einfügen der Standardbuttons durch das Inline-Skript geschieht. Das kann sichergestellt werden, indem die Abhängigkeit von mediawiki.action.edit erst nach document.ready registriert wird. Der Rest sind Aufräumarbeiten und Vereinfachungen wo dies möglich war. Außerdem würde ich empfehlen, die Abhängigkeit zu mediawiki.action.edit aus MediaWiki:Gadgets-definition wieder rauszunehmen, da das Modul sonst auf jeder Seite geladen wird, nicht nur auf Bearbeitungsseiten. Viele Grüße --P.Copp (Diskussion) 14:05, 7. Mär. 2012 (CET)
Sollte $( '#wpWatchthis' ).val( false ); nicht eher $( '#wpWatchthis' ).prop( false ); heißen? --Schnark 10:21, 8. Mär. 2012 (CET)
Das stand schon vorher da, aber du hast Recht, richtig muss es heißen $( '#wpWatchthis' ).prop( 'checked', false );. (Und da hatte man gedacht jQuery macht einem das Leben einfacher :) Danke für den Hinweis! --P.Copp (Diskussion) 10:53, 8. Mär. 2012 (CET)
Stimmt, das checked hatte ich noch vergessen. Gerade bei booleschen Eigenschaften macht es einem jQuery leider nicht wirklich einfach ([4] ist ein sehr schönes Beispiel dafür). --Schnark 11:56, 8. Mär. 2012 (CET)
Da das kaputte höchstens schlimmer werden kann, habe ich es kopiert. Der Umherirrende 17:59, 8. Mär. 2012 (CET)
Scheint beim ersten Aufruf nach Cache-Leerung zu funktionieren, aber beim zweiten Aufruf einer Bearbeitenseite gibt es ein JavaScript-Fehler: mw.toolbar.$toolbar.children is not a function. Der Umherirrende 18:10, 8. Mär. 2012 (CET)
Ich habe es erstmal umgangen, jetzt wird sie bei jedem Aufruf komplett angezeigt, aber vermutlich funktioniert das entfernen nicht. Ich nutze die Toolbar eigentlich nicht, daher habe ich nur den Standardfall getestet. Der Umherirrende 18:23, 8. Mär. 2012 (CET)
Hm, unschön. Sehe keine andere Lösung als noch eine Schicht mw.loader.using um den ready-Hook zu legen um sicherzustellen, dass er nach dem Ready-Hook von mediawiki.action.edit ausgeführt wird. So sollte es also gehen, wenn auch sehr unelegant. Grüße --P.Copp (Diskussion) 18:52, 8. Mär. 2012 (CET)
Würde es nicht auch reichen, das innere using nach Außen zu packen? Hat den gleichen Effekt, weil das innere ja jetzt nichts mehr macht. Du kannst die Prüfung auf mw.toolbar.$toolbar auch gerne wieder rausnehmen, war nur als Notlösung gedacht, bevor ich es ganz zurücksetzen müsste. Der Umherirrende 20:26, 8. Mär. 2012 (CET)
Richtig, das sollte reichen, da das Gadget und mw.action.edit offenbar im gleiche Request geladen wird. Die Abfragen auf mw.toolbar.$toolbar würde ich sicherheitshalber drinlassen, falls sich in der Ladereihenfolge doch noch was ändert. Dann geht zumindest nicht alles kaputt. Grüße --P.Copp (Diskussion) 21:38, 8. Mär. 2012 (CET)
Ok. Der Umherirrende 21:58, 8. Mär. 2012 (CET)
Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 21:58, 8. Mär. 2012 (CET)

Lesenswert-Markierung

In der als-WP werden bei den Interwikis die lesenswerten Artikel – im Gegensatz zu den exzellenten – nicht markiert. Zu sehen ist das beispielsweise bei den in der de-WP lesenswerten bzw. exzellenten Artikeln als:Bremgarten AG und als:Preussen. Soweit ich sehe, liegt es nicht an als:Vorlage:Link GA, sondern an als:MediaWiki:Common.js/als:MediaWiki:Common.css. Wo genau das Problem liegt, finde ich jedoch nicht heraus. --Leyo 14:13, 31. Mär. 2012 (CEST)

Funktioniert bei mir. Browser? Insbesondere: Skin? -- ✓ Bergi 00:13, 2. Apr. 2012 (CEST)
Was ist denn das für ein Durcheinander dort? Versuche mal das Folgende: Lösche als:MediaWiki:If-LinkFA.js (doppelt hält nicht besser) und als:MediaWiki:LinkFA.js (da hat jemand ein If- im Titel vergessen, aber doppelt hält noch immer nicht besser), entferne "LinkFA", "LinkGA" aus window.impArr in als:MediaWiki:Common.js (damit sollte der alte Code weg sein), und schaue dann, dass der Rest so aussieht wie hier, der Code in Common.js sieht auf den ersten Blick in Ordnung aus, aber zumindest in als:Vorlage:LinkFA (das aus meiner Sicht besser mit der Weiterleitung als:Vorlage:Link FA den Platz tauschen sollte) muss die ID angepasst werden. Bei der Aktion werden sich auch die Tooltips ändern, in als:Preussen kann ich derzeit etwas von bsunders guet lesen, das sollte sich zu bsundersch glunge ändern, falls nicht gewünscht, musst du noch die Tooltips im JavaScript-Code ändern. --Schnark 10:06, 2. Apr. 2012 (CEST)
@Bergi: FF 11.0, Vector-Skin.
@Schnark: Vielen Dank für deine detaillierte Analyse. Da ich selbst in der als-WP nicht über die erforderlichen Rechte verfüge, habe ich dortige Admins darum gebeten, deine Tipps umzusetzen. --Leyo 13:31, 2. Apr. 2012 (CEST)
@Schnark: Ich habe deine Tipps versucht umzusetzen, aber jetzt wird bei mir gar nichts mehr mit FA und GA markiert. Wahrscheinlich habe ich etwas nicht angepasst (was konkret meinst du z.B. mit "der Rest"?). Das Problem bei uns und Ursache für das Durcheinander ist, dass der einzige Admin, der sich mit dem ganzen Zeug auskannte und einiges an Custom-Code eingebaut hat, schon seit geraumer Zeit inaktiv ist... --Terfili (Diskussion) 16:07, 2. Apr. 2012 (CEST)
Kopiere mal die aktuelle Version des Codes aus Mediawiki:Common.js, bei eurer Version ist eine verquere (= falsche) Logik bei LinkFA_enabled. Außerdem fehlt noch etwas CSS aus Mediawiki:Vector.css.
Davon unabhängig sehe ich noch 2 Probleme:
  1. Durch das Entfernen von LinkFA und LinkGA aus impArr haben sich die Indizes geändert, sodass bei jsImp(9); und jsImp(7); vermutlich jeweils 2 subtrahiert werden müssen.
  2. als:MediaWiki:If-hideable-portlets.js verursacht Bauchweh bei mir. Im Vector-Skin sind die Dinger ohnehin ein- und ausklappbar, da sollte dieses Skript nicht geladen werden. --Schnark 10:14, 3. Apr. 2012 (CEST)
Habe ich es so richtig kopiert? Und wie weiter? --Terfili (Diskussion) 19:14, 3. Apr. 2012 (CEST)
Das Vector-spezifische CSS fehlt noch, und die schließende geschweifte Klammer, die da ganz am Ende der Common.js steht, sollte dorthin, wo sie hingehört, nämlich ans Ende des Blocks, der mit // [[BugZilla:18704]] eingeleitet wird. --Schnark 09:51, 4. Apr. 2012 (CEST)
Da versteh ich zugegebenermassen leider nur Bahnhof. Was ist das Vector-spezifische CSS und wo muss das hin? Und wo ist das Ende von diesem Block? --Terfili (Diskussion) 17:09, 4. Apr. 2012 (CEST)
Die Zeilen aus Mediawiki:Vector.css, die mit Auszeichnung lesenswerter und exzellenter Artikel in anderen Sprachen eingeleitet werden, musst du nach als:Mediawiki:Vector.css kopieren. (Die genaue Stelle ist relativ egal, am besten ans Ende.)
In als:Mediawiki:Common.js muss die geschweifte Klammer ganz am Ende entfernt werden, dafür muss direkt vor der Zeile /** description that is displayed when cursor hovers above FA interwiki links */ eine schließende geschweifte Klammer eingefügt werden. --Schnark 10:02, 5. Apr. 2012 (CEST)
Super! Jetzt geht alles wieder. Vielen Dank! --Terfili (Diskussion) 10:27, 5. Apr. 2012 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: Leyo 00:14, 24. Apr. 2012 (CEST)

Frage zu einem Script

Guten Tag! Ich habe früher in meiner monobook.js (mit PDD's monobook) beim Bearbeiten einen Button gehabt, mit dem dieses Script ausgeführt wurde. Mittlerweile bin ich auf Vector als Skin umgestiegen und nutze einige von Schnarks Modulen. Leider ist mir durch den Umzug der Button für das Script abhanden gekommen und weil ich chronisch faul bin, vermisse ich ihn. Konkret hätte ich gerne irgendwo (links oder oben oder in der Werkzeugleiste... ?) einen Button zum Ausführen des Scripts. Könnt ihr mir helfen? Grüße --Knopfkind 18:22, 28. Apr. 2012 (CEST)

Du fügst in Benutzerin:Knopfkind/vector.js (am besten direkt oberhalb von Benutzer:Schnark/js/wikieditor.js) diese Zeile ein:
 jsmodules.load('[[Benutzerin:Knopfkind/bksfix.js]]');
und in Benutzerin:Knopfkind/wikieditor-config.js (am besten direkt oberhalb der letzten Zeile) Folgendes ein:
 wikieditor.addMyButton('advanced/search', '//upload.wikimedia.org/wikipedia/commons/thumb/2/2d/Nuvola_web_broom.svg/22px-Nuvola_web_broom.svg.png', 'Korrekturen auf Personen-BKS', '', '', '', {}, function(){if(window.BKSfix) window.BKSfix();});
Position, Icon und Tooltip des neuen Knopfes in der Werkzeugleiste kannst du natürlich je nach Geschmack anpassen.
Ein Eintrag in die linke Seitenspalte ist natürlich genauso leicht möglich, aber da müsste ich jetzt nach der Dokumentation suchen, falls dir das lieber ist, müsstest du dich etwas gedulden. --Schnark 09:32, 30. Apr. 2012 (CEST)
dankeschön :) ich werde es heute abend testen. --Knopfkind 14:54, 2. Mai 2012 (CEST)
Funktioniert. Vielen vielen Dank :) --Knopfkind 20:50, 2. Mai 2012 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: Knopfkind 20:50, 2. Mai 2012 (CEST)

Bearbeiten Drop-Down für Wikimedia Commons

 
Das magische Bearbeiten-Menü (unter #ca-edit) hätte ich gern.

Bearbeiten auf Commons kann unterschiedlich sein: Eine neue Version der Datei hochladen, ein Bild drehen, eine SVG übersetzen, die Dateibeschreibungsseite bearbeiten, das Umbenennen fordern, ...

In Vektor gibt es die p-cactions als tabbar in einem Dropdown. Aber auch das wird schnell zu unübersichtlich. Ich suche etwas wie in dieser PDF auf Seite 7 gezeigt. Gibt es da etwas oder möchte sich jemand die Mühe machen? Das wäre großartig. Es sollte natürlich in allen Skins funktionieren und am besten werden auch gleich die Coding-Conventions eingehalten werden, so dass es eventuell eine MW-Erweiterung werden kann. Wenn es als Gadget/Helferlein funktioniert, reicht mir das auch schon (da kann ich dann Abhängigkeiten hinzufügen). Eigentlich keine so riesige Aufgabe oder? -- RE rillke fragen? 13:02, 4. Feb. 2012 (CET)

Ich denke schon länger über eine besser kontrollierbare Oberfläche nach, die von allen Plugins und Helferlein benutzt werden kann. Für jeden Button/Link gibt es eine eindeutige ID, der Nutzer/das Plugin/die Defaulteinstellungen legen fest, wann/wo/wie es angezeigt wird. Falls diese Oberflächenerweiterung aber nicht geladen ist, muss ihre API dennoch verfügbar sein und auf einfacheres zurückfallen. Als solche Methode ist mir nur mw.util.addPortletLink bekannt.
In Vektor und meinem individuellen Monobook-Derivat gibt es Hover-Dropdowns, in anderen Skins nicht. Da diese mit CSS gestaltet werden sollten, kann man ihre Verfügbarkeit mMn nicht grundsätzlich vorraussetzen. Soweit ich weiß, gibt es auch für Vector noch keine utility-Funktion, mit der man Tab-Menus bauen/befüllen kann. -- ✓ Bergi 18:53, 5. Feb. 2012 (CET)
Dann sind wir uns einig darüber, dass es für javaScript-Tools eine bessere Möglichkeiten geben muss, die Benutzeroberfläche skin-unabhängig zu verändern. Da es so aussieht, als wäre die Umsetzung im Freiwilligenbereich nicht zu bewerkstelligen (man denke auch an eine Integration in MediaWiki, so dass es bespielsweise als RL-Modul verfügbar ist), sollte, denke ich ein "Feature-Request" auf Bugzilla gemeldet werden, so dass bei der nächsten Usablity-Offensive etwas nützlicheres als UploadWizard 2.0 entsteht. -- RE rillke fragen? 16:51, 8. Mär. 2012 (CET)
commons:MediaWiki:Gadget-editDropdown.js: Ich habe es selbst zusammengeschustert. Schön ist es nicht und es funktioniert mit Sicherheit auch nicht in allen Browsern, Sprachen und fliegt mir beim nächsten MW-update um die Ohren. In anderen Skins als Vektor fällt es einfach auf die Toolbox zurück.
Besonders commons:MediaWiki:Gadget-editDropdown.css bräuchte noch etwas Pflege. Vllt. schafft es ja jemand, dass es auch im IE6/7 funktioniert. Sicherlich sind dort auch einige überflüssige Style-definitionen, die entfernt werden könnten. Über Hilfe wäre ich natürlich dankbar.
✓, evtl. ließe sich Deine Monobook-Skinerweiterung nutzen, um Monobook-Nutzern ebenfalls diese Möglichkeiten zur Verfügung zu stellen?
Grüße -- RE rillke fragen? 19:41, 14. Apr. 2012 (CEST)
P.S.: Wird man einen von Euch im Juni in Berlin begegnen? Oder war schon mal jemand bei einem solchen "Hackathon"?
Ich war noch nie, wollte aber vielleicht nach Berlin kommen. Anmeldung läuft schon, oder? -- ✓ Bergi 19:19, 3. Mai 2012 (CEST)
Das Kontingent war AFAIK schon am 30.April erschöpft. Naja >100 Leute bei großer Wärme hört sich auch net so doll an. -- RE rillke fragen? 19:35, 24. Mai 2012 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: RE rillke fragen? 19:35, 24. Mai 2012 (CEST)

Wikipedia-Links in Mediawiki

Liebe Spezialisten, ich hatte bei FZW gefragt und dort den Link zu Euch bekommen :-)

In jedem Mediawiki kann man Wikipedia-Links direkt einbinden, sie erscheinen dann wie "interne Links" (obwohl sie ja eigentlich externe sind): 

[[wikipedia:de:Deutschland|Deutschland]]

Nun möchte ich gern, dass man diese Links zu Wikipedia von anderen internen und externen Links unterscheiden kann. Also im Text automatisch gekennzeichnet, beispielsweise durch ein kleines WP-Logo.

Auf FZW gab's einen Hinweis zur Klasse <a class="extiw">, und dasss man mit CSS und evtl. JavaScript etwas basteln könne. Wie mache ich das genau? Wo muss ich das dann im Mediawiki einfügen? Wo finde ich ein passend skaliertes Logo (ohne Schriftzug) für 10..12 pt-Schrift?

Danke, --Markus (Diskussion) 12:32, 19. Apr. 2012 (CEST)

Wie das bei "normalen" externen Links gemacht wird, kannst du unter http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/skins/monobook/main.css?revision=113566&view=markup#l132 sehen. Am einfachsten fügst du in die Mediawiki:Common.css deines Wikis folgende Zeilen ein:
#mw-content-text a.extiw {
    background: url(//www.url.zu/deinem/lieblingsicon.png) center right no-repeat;
    padding-right: 16px; /* je nachdem wie breit das Bild ist */
}
Wobei je nach Mediawiki-Version der Selektor #mw-content-text weggelassen oder durch anderes ersetzt werden müssen kann. -- ✓ Bergi 19:04, 19. Apr. 2012 (CEST)
Ergänzung zum Logo-Teil deiner Frage:
Viel Spaß --PerfektesChaos 20:28, 19. Apr. 2012 (CEST)
Herzlichen Dank für die umfassende Antwort! Ich habe sie weitergegeben und hoffe dass nach der Umsetzung WP-Links zunehmend genutzt werden. Falls etwas nicht funktioniert melde ich mich nochmal. Gruss, --Markus (Diskussion) 22:03, 24. Apr. 2012 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: Fomafix (Diskussion) 19:24, 24. Mai 2012 (CEST)

Edit API

Hallo, MediaWiki bietet ja selbst inzwischen ein JS-modul, das halte ich aber für vollkommen unzureichend (das token könnte doch gleich mit mw.user.tokens... befüllt werden). Außerdem sollen ja von Zeit zu Zeit Fehler vorkommen, die vom JS selbst behandelbar sind:

  • Edit conflict bei prepend&appendtext
  • Serverfehler (treten leider ziemlich häufig auf Commons auf)
  • Übertragungs- und Verbindungsfehler (besonders bei Nutzern mobiler Geräte)

Ähnliches gilt für action=move, action=delete

Hat jemand schon eine fertige Lösung parat, die die Fehler selbst behandelt, Daten vor dem Senden validiert, ...?

Wie wäre es am besten implementiert? Als Funktion (wie $.ajax) oder als "Klasse" (wie mw.Api)? -- RE rillke fragen? 23:14, 25. Apr. 2012 (CEST)

Ja, ich habe eine eigene Implementation von mw.Api() - leider ein wenig inkompatibel zur jetzigen. Ich habe aber vor, das MediaWiki-JS neu zu schreiben :) Mit der zugrundeliegenden Promise-Implementation lassen sich auftretende Fehler auch leicht abfangen. In erster Linie war sie für action=query gedacht (das Modul ist eigentlich schon vorzeigbar), wo Abfragen mit vielen [geschachtelten] continues so ganz-und-garnicht serverfreundlich rausgehauen werden - Ergebnisse und teils Code manchmal zu bewundern auf Wikipedia:B/A.
Aber anmelden und bearbeiten kann das Ding natürlich auch - wenn auch vllt. nicht ganz so konfortabel. Tokens holt es automatisch, maxlag berücksichtigen kann es und sowohl Server- als auch Verbindungsfehler meldet es als solche (ohne nochmal zu probieren). Was meinst du mit Editconflict bei prepend&appendtext, ich dachte da treten keine auf? Welche Daten sollen vor dem Senden wie validiert werden? -- ✓ Bergi 17:42, 26. Apr. 2012 (CEST)
Wenn du ein Revisiontimestamp mitgibst, kann ich mir vorstellen, das dort ein Bearbeitungskonflikt auftritt/ausgelöst wird. Die Paramter sollen ja nur bei der Reduzierung des Datenvolumens helfen. Bei section=new kann kein Bearbeitungskonflikt auftreten. Der Umherirrende 17:59, 26. Apr. 2012 (CEST)
Hallo. Danke für die Antworten. Maxlag ist mir meist egal, ist ja für JavaScript. Ich kann dem Nutzer wohl kaum melden: "Sie können diese Datei nicht zur Löschung vorschlagen, weil die Server ein Replication-Lag haben." Die MW-Devs/Techs sehen das natürlich anders (hatte das Vergnügen via IRC).
Ja, es können edit-conflicts auftreten und das passierte regelmäßig auf [[:commons:Commons:Deletion requests/2012/<month>/<day>]] (da gehen manchmal mehrere pro Sekunde ein) bis ich dem Script gesagt habe es solle solange probieren, bis kein edit-conflict auftritt.
Ich denke, dass folgendes passiert: Edit request geht beim Server ein -> Server sperrt edits für die Seite (oder was auch immer) -> (jetzt eingehende requests erzeugen einen conflict) Server prüft den Request gegen alle Hooks, ... -> Server speichert und gibt sie wieder frei.
Natürlich kann ich auch beweisen, dass es edit-conflicts beim Anhängen von Text gibt: s. automatisch generierte Fehlerberichte. Und nein timestamps werden nicht mit übergeben. Ja, ich war auch überrascht und habe es unter bugzilla:34580 gemeldet.
Wichtig zu wissen ist, dass auf Commons die API sehr intensiv genutzt wird, einfach weil wir mit so vielen Dateien zu kämpfen haben, mit denen es häufig Probleme gibt.
Außerdem haben wir mehrere Stapelverarbeitungswerkzeuge. Bei denen sollte dann natürlich auch sichergestellt werden, dass nicht 200mal action=edit innerhalb einer Sekunde zum Server geschickt werden (was bei IPs dann mit Sicherheit fehlschlägt, weil es da irgendein rate-limit gibt), wie es momentan von Cat-a-Lot getan wird.
Bei all diesen Operationen braucht man dann nicht bei jeder 10. Aktion einen Fehler; das Script sollte sie intelligent behandeln (wenn nötig in den Benutzerbeiträgen nachsehen, ob der edit durchgeführt wurde oder nicht, denn action=query - zeigt die Erfahrung - leidet wesentlich seltener an Fehlern, als Dinge, die Inhalte verändern, wie edits, moves, deletions)
Vor dem Senden soll geprüft werden, ob der Nutzer der Funktion/Klasse gültige Werte übergeben hat; d.h. es ist eine Prüfung durchzuführen, ob required Parameter wie title/pageid gesetzt sind und ihr Datentyp soll geprüft werden, um einfach besser vor unvorhergesehenen Ergebnissen zu schützen.
Evtl. ist es auch mal wieder zu speziell Commons; dann mache ich mich selbst an die Arbeit. Entschuldigt die grauenvolle Deutsch-Englisch-Mischung. Grüße -- RE rillke fragen? 18:55, 26. Apr. 2012 (CEST)
MediaWiki nutzt eigentlich Optimistic Logging und prüft daher den übergebenden Revisiontimestamp gegenüber den aktuell vorgefundenen Timestamp. Wenn das nicht übereinstimmt gibt es ein Editconflict. Wenn man also den Revisiontimestamp nicht angibt, sollte man eigentlich keine Editconflicts bekommen können, sondern überschreibt eventuell die vorher gemachte Bearbeitung. Daher bin ich über deine Aussage etwas erstaut, muss aber gestehen, das ich nicht versucht habe, in einer Sekunde mehrere Request abzufeuern. Vielleicht hat sich ja in der letzten Zeit auch etwas getan.
Zum Ratelimit: Das kann man auslesen (meta=userinfo glaube ich) und könnte es dann behandeln. Ist nur doof, wenn die Anwendung minutenlang steht, weil es nicht schneller geht, da wäre ein Warnhinweis wohl sinnvoller. Der Umherirrende 19:06, 26. Apr. 2012 (CEST)
Danke. Und die Captchas sollte man auch nicht vergessen. Der Grundstein ist gelegt.
Archivierung dieses Abschnittes wurde gewünscht von: RE rillke fragen? 19:31, 24. Mai 2012 (CEST)

MediaWiki:Vector.js

Bitte meine vorgeschlagene Änderung unter MediaWiki Diskussion:Vector.js#topicon bei RTL prüfen. --Fomafix (Diskussion) 14:39, 2. Mai 2012 (CEST)

Ich habe meinen Änderungsvorschlag etwas angepasst:

In MediaWiki:Vector.js wird 

 $( function() {
    if (typeof dontShowTopicons != 'undefined' && dontShowTopicons) return;
    var h1 = document.getElementById("firstHeading");
    var bc = document.getElementById("bodyContent");
    if (!h1 || !bc)
      return;
    var icons = getElementsByClassName(bc, "div", "topicon");
    for (var j = icons.length; j > 0; --j) {
      var icon = icons[j-1];
      h1.parentNode.insertBefore(icon, h1);
      icon.style.cssFloat = icon.style.styleFloat = "right";
      icon.style.marginLeft = "3px";
      icon.style.display = "block";
    }
 });

ersetzt durch 

$( function () {
	if ( mw.config.get( 'dontShowTopicons' ) ) return;
	mw.util.$content
	.find( 'div.topicon' )
	.insertBefore( '#firstHeading' )
	.show();
} );

In MediaWiki:Vector.css wird folgendes hinzugefügt: 

div.topicon {
	float: right;
	margin-left: 3px;
	font-size: 0.8em;
}
#firstHeading {
	overflow: visible;
}

Bitte meinen Vorschlag prüfen. --Fomafix (Diskussion) 10:51, 6. Mai 2012 (CEST)

Wie sieht das dann ohne JavaScript aus oder kann man das vernachlässigen? Du setzt hier bewusst auf das automatische Flippen, damit es in RTL passt? Wie sieht das mit den anderen Definitionen in Vector.css bezüglich #coordinates aus? Der Umherirrende 16:37, 26. Mai 2012 (CEST)
Ohne JavaScript sind die Topicons deaktiviert. Das war bei Vector schon immer so. Die Koordinaten werden mit #coordinates bereits automatisch geflippt. --Fomafix (Diskussion) 11:57, 27. Mai 2012 (CEST)
Dann versuchen wir mal unser Glück. js/css. Der Umherirrende 19:21, 27. Mai 2012 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: Fomafix (Diskussion) 09:46, 31. Mai 2012 (CEST)

Nachsichten

Möglicherweise hier völlig falsch, dann bitte verschieben

Die Beobachtungsliste "highlighted" ja inzwischen Seiten, auf denen seit dem letzen Besuch Änderungen vorgenommen wurden. Wäre ein Gadget o.ä. denkbar, das

  • eine näher definierbare Artikelliste (also beispielsweise alle Artikel innerhalb einer bestimmten Kategorie einschließlich Unterkategorien) anzeigt, die ungesichtete Versionen haben und
  • innhalb dieser Liste jene Artikel mit Fettschrift hervorhebt, die seit dem letzten eigenen Besuch geändert wurden?

Hintergrund: Ich pflege nur innerhalb "meines" Fachbereichs nachzusichten (andere würden es auch "inhaltlich prüfen" nennen). Bestimmte Änderungen sichte ich bewusst nicht, weil ich sie inhaltlich nicht beurteilen kann. Bei einer vollständigen Liste der nachzusichtenden Artikel werden mir diese aber immer wieder angezeigt - effektiver wäre aber natürlich, wenn ich eine einmal begutachtete Änderung nicht mehr (oder nur in veränderter Aufmachung nochmals) angezeigt bekommen würde, damit ich mich auf die neu hinzugekommenen Änderungen fokussieren kann.--Mabschaaf 15:55, 28. Jun. 2012 (CEST)


  1. Du bist hier völlig richtig.
  2. Ein solches Gadget ist nicht nur denkbar, sondern auch technisch möglich und wünschenswert.
  3. Ein analoger Vorschlag wurde kürzlich unter #"Eigene" Artikel gemacht.
  4. Es wäre zunächst eine allgemeinere Spezifikation für eine universelle Programmierung zu entwickeln, die festlegt
    • in welchem Format eine oder mehrere Steuerseiten aus expliziter Auflistung, Kategorien, womöglich Unterkategorien (da wird es dann hakelig; könnten viele sein) auszuwerten wären
    • welche Folgen genau diese Fundstellen konfigurierbar auf unterschiedlichen Zielseiten haben sollen, etwa auf BEO oder als Links irgendwo anders.
Liebe Grüße --PerfektesChaos 16:59, 28. Jun. 2012 (CEST)

<Kopie von Wikipedia:GSV>

  • Deep out of sight von Magnus Manske durchsucht eine Kategorie und deren Unterkategorien nach Artikeln, bei denen die aktuelle Version ungesichtet ist. Interessant für Themenautoren.

</Kopie>

Das kennst du schon, oder? Aber das ist nicht, was du suchst? LG, --Drahreg•01 17:17, 28. Jun. 2012 (CEST)

Ja, danke, damit arbeite ich bisher. Ich wollte nur gerne noch einen Schritt weiter gehen.--Mabschaaf 17:24, 28. Jun. 2012 (CEST)
Die Information, ob eine Seite seit deinem letzten Besuch geändert wurde, liegt nur für Seiten auf deiner Beobachtungsliste vor. Daher kann eine Markierung wie du sie dir vorstellst, nur dann funktionieren, wenn du alle Seiten aus der gewünschten Kategorie auch auf deiner Beobachtungsliste hast.
Da aber besuchte Links (je nach Browsereinstellungen) eine andere Farbe haben als unbesuchte Links, müsste doch deep out of sight funktionieren, alle dunkelgefärbten Links hast du schon einmal angesehen und wolltest sie damals nicht sichten, sodass du sie beim erneuten Durchlauf ignorieren kannst. --Schnark 09:20, 29. Jun. 2012 (CEST)


  • Schnark hat recht, was den Umstand angeht, dass du dann alle Artikel des Themengebiets auch auf der Beo haben musst – was sich mit der ASCII-Import-Funktion und irgendwelchen Basteleien ab und an händisch machen ließe; auch ein selbst zu schreibendes Skript kann dir einmal pro Woche alles auf die BEO setzen, was es in den fraglichen Kat+Unterkat so an Neuigkeiten gibt.
  • Mit der Farbe des Links ist das allerdings so eine Sache. Auf der BEO steht nur das allgemeine (statische) Link zum Artikel, keine curid-URL. Wenn du zufällig vor drei Wochen die Seite besucht hast und dein Browser erst nach vier Wochen die visited-Eigenschaft vergisst, dann ist auch dieses Link verfärbt.
  • Ich kann das Begehren nach Hervorhebung besonders interessanter Seiten auf der BEO gut verstehen; etliches beobachtet man nur aus den Augenwinkeln, lauscht auf Neuigkeiten oder besondere Vorkommnisse; vorangegangene Edit-Wars usw. Für den simplen Fall der Präfixe habe ich die auf Wikipedia:CSS #Beobachtungsliste dargestellten Anweisungen zu laufen; Änderungen an meinen eigenen (Benutzer-)Seiten, meiner Benutzerdisku nebst Unterseiten und alles aus Wikipedia:Technik/Skin (auch diese Werkstatt) knallt mir ins Auge.
  • Grundsätzlich ist es machbar, für alle Seiten (oder nur Artikel) auf der aktuellen BEO eine API-Abfrage zu starten und abzugleichen, in welche Kategorien sie unmittelbar eingeordnet sind; dementsprechend bestimmte Farben usw. zuzuordnen. – Unterkat werden sich aber kaum dynamisch rekursiv zurückverfolgen lassen. Wenn es nicht allzu arg viele im Themengebiet gibt, müssten alle Unterkat explizit in der Skript-Konfiguration aufgezählt sein.
Soviel bis hierhin, beste Grüße --PerfektesChaos 21:12, 30. Jun. 2012 (CEST)
Danke für die Antworten. Schade, dass es offenbar keine einfache Lösung gibt. Ich werde es einfach mal mit den besuchten Links in den Browsereinstellungen versuchen und setze hier mal auf erledigt. Falls jemand noch weiter diskutieren will, kann man die Erle gerne wieder ausrupfen.--Mabschaaf 20:56, 10. Jul. 2012 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: --Mabschaaf 20:56, 10. Jul. 2012 (CEST)

Hashcode auf //upload.wikimedia.org/

Hallo zusammen,

gibt es eigentlich irgendwo dokumentiert den Algorithmus, der den 8-bit-Hashcode generiert, mit dem eine Datei auf //upload. verteilt gespeichert wird, am liebsten schon vorgekaut als JavaScript; ersatzweise eine Liane im PHP-Dschungel?

LG --PerfektesChaos 14:22, 8. Jun. 2012 (CEST)

Du meinst den Bestandteil des Pfades? Also bei //upload.wikimedia.org/wikipedia/de/b/bc/Wiki.png das "b/bc"? Das ist der erste bzw. die ersten beiden Buchstaben des MD5-Hashes des Dateinamens. Der Umherirrende 14:37, 8. Jun. 2012 (CEST)
(BK) mw:Manual:$wgHashedUploadDirectory sollte weiterhelfen. md5-JS-Implementationen findet man wie Sand am Meer, Empfehlungen aussprechen dafür kann ich nicht. -- ✓ Bergi 14:48, 8. Jun. 2012 (CEST)
Danke. Oje; ui!
Ich hatte eigentlich was Simpleres erhofft. Es ging ja seinerzeit nur darum, den Bestand gleichmäßig auf 256 buckets zu verteilen (Streuwertverfahren); das kann man auch einfacher haben.
MD5 in JS bekommt man wohl nicht unter 5 kB; das ist mir dann etwas zu rechenintensiv. Hätte ich mir eigentlich denken können: Viermal durchgequirlt, und von den kaum knackbaren 128 Bit 120 wegschmeißen, und das mühsam errechnete Geheimnis danach öffentlich machen.
Wobei moderne DB-Software das verborgen aus dem eigentlichen Dateinamen als URL errechnet und dann Server-intern auf 256, 1024 oder 4096 buckets verteilt, ohne dies dem Benutzer preiszugeben. Zum Jahreswechsel war ja auch irgendwann an der Architektur der Dateispeicherung etwas erneuert worden.
Schönes Wochenende --PerfektesChaos 15:28, 8. Jun. 2012 (CEST)
Wenn ich die MD5-Funktion aus Benutzer:PDD/godmode-light.js in den ersten mit Google gefundenen Online-Closure-Compiler werfe, komme ich auf 3 kB runter. --Schnark 09:45, 9. Jun. 2012 (CEST)
Eigentlich ist es unsinnig den Endnutzer zu zwingen den MD5 zu errechnen oder die API zu quälen. Zumal ja bei den Thumbs das selbe rauskommt
-- RE rillke fragen? 10:23, 9. Jun. 2012 (CEST)
Stellt sich die Frage, was PerfektesChaos vor hat. Es gibt da noch Spezial:Filepath/Wiki.png/Medium:Wiki.png und {{filepath:Wiki.png}}, falls es um die Verwendung im Wikitext gehen sollte, wobei man bei filepath wohl noch die Thumbgröße angeben kann. {{fullurl:Special:Filepath|width=100px}}/{{filepath:Wiki.png|100px}} Der Umherirrende 11:25, 9. Jun. 2012 (CEST)


  • Das ist ein Überbleibsel aus den Kindertagen der Wikis; es ist wohl bald ein Jahrzehnt her, dass man die Dateien nicht mehr auf einer einzelnen Festplatte unterbringen konnte oder so. Man griff zur erstbesten Hash-Funktion, die grad in der Netzbibliothek aufpoppte, und verfiel unglücklicherweise auf MD5.
  • Es ist völlig in Ordnung, Server-intern eine große Datenmenge in physische Einzelteile aufzuspalten; hier: unabhängige Datenbanken einzurichten. Die Datensicherung passt besser auf die Speichermedien, man kann eine Festplatte für die ersten 30 und eine für die nächsten 35 Körbchen nutzen, gar mehrere Dateiserver zusammenschalten. Gegen 256 oder 4096 einzelne Datenbanken ist nichts zu sagen.
  • Nur: Man darf solche Interna nie nie nie nie nie nie nie nie und nimmer nach draußen geben, gar in einer URL exponieren. So muss man für die nächsten Jahrzehnte die URL pflegen, auch wenn die technischen Bedingungen sich ändern. Siehe Tim Berners-Lee: Cool URIs Don’t Change.
  • Um eine gleichmäßige Streuung über die buckets zu erreichen, hätte es gelangt, den UCS/UTF jedes Zeichens des echten Dateinamens zu addieren, jeweils multipliziert mit der Zeichenposition 1,2,3,… Dann gibt es auch keine Ausreißer wegen .jpg .png .svg, weil sich je nach Namenlänge andere Produkte ergeben. Integer-Überlauf ist auch bei 5000 Zeichen langen UTF-Dateinamen nicht zu befürchten, und soviele ganzzahlige Multiplikationen wie der Name lang ist sind auch kein Drama; diese Arithmetik ist zumutbar schnell, um on the fly ausgeführt zu werden. Abschließend ein Mpdulo über die Anzahl der buckets.
  • Wahrscheinlich hat man den hashcode extra in die URL geschrieben, weil die MD5-Berechnung so unverschämt lange dauert.
  • Für eine mittlere Zukunft (nachdem es erst vor einem halben Jahr reorganisiert wurde) wünsche ich mir redundanzfreie URL wie
  • Konkret greife ich auf rund 20 Dateien zu, deren Name sich nur geringfügig unterscheidet. Also werde ich wohl oder übel→über 20 redundante hashcodes dazuschreiben und pflegen müssen (momentan "##"), da mein eigener Code weniger als 4 kB hat:

Danke für die Unterstützung --PerfektesChaos 21:56, 9. Jun. 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 15:07, 14. Jul. 2012 (CEST)

gadget purge cache?

Könnte jemand bitte [5], nach meinen Kenntnisstand veralteten (oder redundanten), Code auf Aktualität prüfen!? -- πϵρήλιο ℗ 20:32, 30. Jun. 2012 (CEST)

Diese Angelegenheit ist bereits erledigt.
Ohne irgendeine weitere Diskussion.
Trotzdem gut aufgepasst; angenehmes Wochenende noch --PerfektesChaos 20:50, 30. Jun. 2012 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 15:07, 14. Jul. 2012 (CEST)


Wikipedia:Technik/Skin/GUI#Aufbau_einer_Wiki-Seite

In besagtem Abschnitt steht Ausführliche Liste siehe meta:Hilfe:Eigene Stylesheets #Referenz, aber die verlinkte Seite existiert nicht. Was muss ich denn in meine css schreiben, damit auch noch der Drucken/Exportieren Link verschwindet? --Seidenpferd (Diskussion) 13:20, 12. Jul. 2012 (CEST)

Die auf meta: haben anscheinend ihre deutsche Übersetzung Hilfe: des Namensraums gestrichen; das heißt bei denen jetzt nur noch Help: – ich habe das Link angepasst; danke für die Info.
Es hätte dir ohnehin nicht geholfen; es gibt Hunderte und Tausende solcher Bezeichner – dort steht aber heutzutage auch nur noch eine Auswahl; es war wohl schon mal mehr.
Im Zweifelsfall hilft es, sich im Browser den Quelltext der Seite anzugucken und sich durchzuhangeln; es gäbe sogar komfortable „Entwicklerwerkzeuge“ dazu.
Du müsstest wohl glücklich werden mit:
#p-coll-print_export {
   display: none;
}
Liebe Grüße --PerfektesChaos 21:28, 13. Jul. 2012 (CEST)
Funktioniert, vielen Dank :) --Seidenpferd (Diskussion) 11:09, 14. Jul. 2012 (CEST)
Im neuen Firefox kannst du einfach mit Rechts auf ein Element klicken und es "untersuchen". Das ist auch in Chrome (glaube auch Opera) möglich. Firefox zeigt dann sogar die CSS-Selektoren an. -- RE rillke fragen? 19:32, 14. Jul. 2012 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 15:07, 14. Jul. 2012 (CEST)

Farbige Hervorhebung, wenn die Zusammenfassung fehlt

Hallo, ich hatte vor einigen Monaten eine Anfrage bezüglich der farbigen hervorhebung einer leeren Zusammenfassung hier gestellt und einige Antworten bekommen. Ich habe mich an diesem Wochenende mit dem Thema beschäftigt und war über eure Ideen dankbar. Daraus ist das Gadget highlightemptysummary (js/css) geworden. Ich habe es auch schon in den Einstellungen aktivierbar gemacht, allerdings mit einem Hinweis auf "TESTPHASE". Ich würde mich über Kommentare zur Implementierung freuen. Vorallem hinsichtich Browserkompatibiltät. Das große Ziel sollte sein, es eines Tages auch als default-Gadget zu aktivieren, weil es immer wieder Diskussion um die Zusammenfassungszeile gibt. Siehe auch WP:EZ oder Wikipedia:Missbrauchsfilter/Anträge #10. Der Umherirrende 21:24, 15. Apr. 2012 (CEST)

Fein; vom ersten Drübergucken:
  • Das $() sollte als allererstes Statement stehen. Die ganze Aktion kann zeitlich vertagt werden, bis die Seite aufgebaut ist, zumindest aber das DOM fertig ist.
  • Danach sollte alles Weitere eingerahmt werden in ein
    wgAction ./. "edit" || "submit"
    (sei es per RegExp oder schnelles indexOf() oder ===||===)
  • Zwei bis drei Kommentarzeilen zuvor wären nicht schlecht.
  • Ansonsten sieht es erstmal Browser-neutral aus.
Liebe Grüße --PerfektesChaos 21:55, 15. Apr. 2012 (CEST)
Nachtrag: Kleine Textkorrektur wär noch; 4× „einen Bearbeitungskommentar“, 2× „gebe“→„gib“; Englisch:
  • Please enter an edit summary here.
  • Please write an edit summary into the colored text field.
Textkorrekturen gemacht. Abfrage auf edit/submit eingebaut. Die messages habe ich dort oben gesetzt, weil ich es so auch bei MediaWiki:Gadget-ImageSiblings.js gesehen habe. Macht die Sache einfacher, wenn Gadget/RL2 kommt. Natürlich kann man das noch etwas schieben, aber das ist so ein großer Brocken, der dann mitten drin steht, macht es auch nicht übersichtlicher. Der Umherirrende 22:18, 15. Apr. 2012 (CEST)

Test. Nö, geht nicht. Was soll da passieren? Und wieso gibt es das als Helferlein, wenn es die Einstellung „Warnen, sofern beim Speichern die Zusammenfassung fehlt“ gibt? Ist das nicht zweimal das Selbe? PS: Na gut, in einigen ausgewählten Namensräumen (warum gerade die und wieso ist das nicht konfigurierbar?) macht es etwas. Allerdings empfinde ich es als extrem verwirrend (gerade für Neulinge), dass man augenblicklich, sofort nach dem Klick auf „Bearbeiten“, mit einem riesengroßen roten Balken begrüßt wird (die rot hervorgehobene Zusammenfassungszeile). Ich halte das für sehr ungeschickt. Die Zeile ist wichtig, nachdem man mit seiner Bearbeitung fertig ist, nicht gleich als erstes, noch bevor man irgendwas gemacht hat. Genau das leistet aber schon die erwähnte Einstellung. Also wenn, dann sollte diese Einstellung standardmäßig aktiviert werden (was sicher noch einmal gesondert zu diskutieren ist und vermutlich einem Meinungsbild bedarf). Die Einstellung erlaubt aktuell leider keine Unterscheidung zwischen den Namensräumen. Das könnte sicher nachgerüstet werden. --TMg 01:20, 16. Apr. 2012 (CEST)

  • Richtig ist, dass eine Veränderung des Textarea noch gecheckt werden sollte vor einer Aktivierung der Hervorhebungen. Es gibt Möglichkeiten zum Vergleich von .val() mit .props() oder so ähnlich, um den Ausgangszustand zu ermitteln. Besser wäre es, wpTextbox1.change() zum Auslöser der Aktivitäten zu machen; so lange dort nichts geändert wurde, würde die summary-Hervorhebung usw. nicht aktiviert. OnChange wird auch erst nach dem Verlassen des Bearbeitungsfelds wirksam und nicht gleich beim ersten Tastendruck.
  • Die Konfiguration der Namensräume ist sicher interessant.
  • Aktueller Anlass ist wohl diese Diskussion.
    • Das vorhandene Gadget/userpref wird von vielen Autoren abgelehnt und bewusst nicht eingeschaltet, manchen mag das Häkchen unbekannt sein, bei IP-Edits greift es derzeit womöglich nicht?
  • Der mit dem neuen Gadget erzielte Effekt soll so mild sein, dass er die Default-Vorgabe auch für IP und alle Benutzer ermöglicht. Das CSS ist etwas zu heftig in seiner optischen Darstellung.
  • Statt namenloser Funktion läuft es wohl eher auf ein konfigurierbares Anwendungsobjekt hinaus.
VG --PerfektesChaos 13:28, 16. Apr. 2012 (CEST)
Die Einstellung "forceeditsummary" (wie sie technisch heißt) war schon mal nach einem Meinungsbild standardmäßig aktiviert worden und war dann heftig umstritten und wurde wieder deaktiviert. Da das Meinungsbild allgemein gehalten wurde und sich nicht auf diese Einstellung bezog, sondern die Umsetzung offen ließ, wurde ein Missbrauchsfilter aktiviert, mit dem ähnliches erreicht werden sollte. Dieser hat sich aber Aufgrund der hohen Trefferzahl selber deaktiviert (Ein Schussmechanismus im Missbrauchsfilter) und seit dem wurde es nicht wieder weiter verfolgt (Keine alternative technische Umsetzung). Das Problem an der Einstellung "forceeditsummary" ist, das es erst nach dem Abschicken des Formulars aktiv wird. Das erfolgreiche Speichern in MediaWiki lässt sich ja nur daran ableiten, das der Artikel in der neuen Fassung aufgerufen wird. Viele Benutzer aber schauen nach dem Klick auf Speichern garnicht, was die neue Seite zeigt, weil in den meisten Fällen das Ergebnis ja bekannt ist. Aus diesem Grund geht die Bearbeitung verloren. Früher war die Umrandung der Zusammenfassungszeile bei forceeditsummary noch garnicht vorhanden, was die Benutzer noch mehr verwirrt hatte, weil sie garnicht wussten, wo die Zusammenfassungszeile zu finden ist. Da hat man (Raymond, glaube ich) eine CSS-Klasse mit Style ergänzt, was die Benutzerführung sicher (etwas) verbessert hat.
Auch schon 2009 kam die Idee auf, das ganze per JavaScript auf der Clientseite zu machen, um dem Benutzer eine direkte Rückmeldung zu geben. Ich hatte auch schon einen Entwurf vorgeschlagen, aber es hat sich aber kein JS-Admin gefunden, der das ganze dann weiterverfolgt. Ich wollte das damals nicht fertigstellen, weil ich es unschön finde, wenn man in einem Fehlerfall nicht selber einschreiten kann. (An der Situation der JS-Admins hat sich aber in der Zwischenzeit auch noch nicht viel geändert)
Ich hatte das ganze in der letzten Zeit aber immer geschoben, nur war jetzt das Thema wieder etwas präsenter, daher habe ich das gemacht. Ich persönlich finde das Konzept weiterhin auch garnicht so schlecht.
Zu den Namensräumen: Da habe ich mir einfach gedacht, wo es am meisten Sinn macht, wenn man eine Zusammenfassungszeile angibt und da fallen Diskussionsseiten beispielsweise aus. Ansonsten lässt sich auch da noch drüber reden.
Die Idee, die Zeile erst farbig zu machen, wenn auch Text geändert wurde, finde ich gut und habe ich soeben auch eingebaut. Nachträglich allerdings mit der Ausnahme, das in Vorschau oder Änderungen zeigen, das Highlighting sofort aktiv wird, weil ansonsten das dort wieder "normal" ist, bis man etwas ändert, aber das Highlighting sollte sich ja mit übertragen. Der Umherirrende 18:42, 16. Apr. 2012 (CEST)
Ich denke, das ist okay so.
  • Wenn man die Seite gerade erst aufmacht (action=edit), muss man nicht schon mit der Reklame begrüßt werden. Vielleicht will man sich ja nur den Quelltext angucken. Verändert man bei action=edit den Quelltext und verlässt das Bearbeitungsfeld, werden die Erinnerungs-Highlights aktiv; blieb der Text unverändert – ist Ruhe.
  • Kommt man dann auf Unterschiede anzeigen oder Vorschau, dann üblicherweise deshalb, weil man ja den Quelltext verändert hat – action=submit kann deshalb unterstellen, dass der Quelltext modifiziert ist. Ich wüsste auch keinen Weg, Browser-unabhängig clientseitig die Änderung bzw. den unveränderten Text auszulesen; den kennt normalerweise nur der Server.
Viel Spaß --PerfektesChaos 21:32, 16. Apr. 2012 (CEST)
Tut mir leid, aber ich zweifle stark an daran, dass es der richtige Weg ist, noch mehr hervorzuheben und fett und rot zu markieren. Unangemeldete Benutzer werden jetzt schon mit viel zu vielen Informationen zugekippt, die dummerweise alle gleich wichtig sind. Dazu kommen merkwürdige Kinderkrankheiten: Warum wird z.B. die Schrift auf dem Speichern-Button rot? Warum wird die Zusammenfassungszeile rot, wenn man einfach nur den Mauszeiger darüber bewegt, ohne etwas geändert zu haben? (Browser: Opera, aktuelle Version.) Und das Gadget ist wie schon gesagt redundant zur bereits vorhandenen Option, die doppelte Markierung der Zusammenfassungszeile ist wenig hilfreich. Darüber hinaus nimmt das Gadget keine Rücksicht darauf, ob eine Änderung beispielsweise nur im Hinzufügen eines fehlenden Satzzeichens besteht. Man kann sicher trefflich darüber streiten aber ich gehe davon aus, dass es viele Benutzer (unangemeldete wie angemeldete) gibt, die einen Bearbeitungskommentar in solchen Fällen (für als klein markierte Änderungen) für überflüssig erachten.
Kurz zusammengefasst: Ich halte das hier nicht für den richtigen Weg, mehr Wikipedia-Einsteiger und Gelegenheits-Bearbeiter vom Sinn und Zweck eines aussagekräftigen Bearbeitungskommentars zu überzeugen. Im Grunde läuft die Idee des Gadgets darauf hinaus, die Zusammenfassungszeile rot darzustellen. Dazu braucht man aber kein JavaScript, das nach einer fragwürdigen Logik vorgeht und auch sonst potentiell fehleranfällig ist. Die Logik der bereits existierenden Einstellung ist immerhin simpel: Sie schlägt an, wenn man auf "Speichern" drückt. --TMg 23:15, 16. Apr. 2012 (CEST)
PPS: Ich habe gerade das System in pl: getestet. Das finde ich sehr simpel und einleuchtend. Zusammengefasst: Der erste Klick auf "Speichern" umrahmt die Zusammenfassungszeile rot. Die Markierung wird also in genau dem Moment vorgenommen, den ich für sinnvoll erachte. Per simplem Doppelklick kann man das übergehen, der Hinweis steht also so wenig wie möglich im Weg. Warum nehmen wir nicht einfach das? --TMg 23:21, 16. Apr. 2012 (CEST)
Es soll ja Leute geben, die mit mehr als einem Tab arbeiten und dann gar nicht bemerken, dass der erste Klick gar nicht das gewünschte bewirkt hat (Strg+Tab etc...). --Steef 389 00:50, 17. Apr. 2012 (CEST)
Die Einstellung forceeditsummary hat dieses Problem wirklich, weil die Seite neu lädt, wie man es erwartet. Wartet man die Antwort nicht ab, übersieht man wirklich leicht, dass kein Speichern stattfand. Das polnische Skript hat dieses Problem nicht. --TMg 02:29, 17. Apr. 2012 (CEST)


  1. @TMg: Es ist schon mehrfach und dir auch vom Umherirrenden erläutert worden, warum hier ein neuer Anlauf genommen wird; deshalb bleibt mir nichts als die Gründe zusammenfassend zu wiederholen:
    • Die momentan vorhandene Option ist eine frei wählbare und ganz offenkundig nicht von allen und anscheinend auch nicht von jeder IP benutzte Variante.
    • Alle ansonsten in der deWP verfügbaren Varianten würden erst nach dem Klick auf Speichern tätig.
    • Die Initiative des Umherirrenden zielt darauf ab, zu einer Lösung zu kommen, die bereits vor dem Speichern wirkt und so mild und so wenig bevormundend und so verständlich ist, dass sie zu einem Standard für alle IP werden kann, der von angemeldeten Benutzern abwählbar wäre.
  2. Freilassen des Bearbeitungskommentars, wie von TMg für den Fall einer kleinen Änderung für sinnvoll gehalten:
    • Der Bearbeitungskommentar richtet sich an die anderen Beobachter und Mit-Autoren sowie RCler usw., die durch einen Kommentar ihren Aufwand verringern können.
    • Das einfache Offenlassen des Kommentars, wie von TMg propagiert, gibt den Kollegen Rätsel auf: War nur versehentlich der Kommentar vergessen worden? Ging es um einen Tippfehler? Wurde der Sinn verändert? Ist eine inhaltliche Änderung die Folge?
    • Gibt man hingegen ein schlichtes k oder t an, ist es in Verbindung mit der Zahl geänderter Zeichen (+1 oder -2, 0 oder 4?) und einem halbwegs bekannten Benutzernamen (der offenbar zumindest Sichterrechte hat) den Kollegen möglich, auf den Versionsvergleich zu verzichten, um herauszufinden, was sich hinter dem unkommentierten Edit verbirgt. Natürlich wäre es fies, inhaltlich bedeutende Veränderungen hinter einem t zu verstecken; das fliegt aber irgendwann auf, und entsprechende Kommentare auf der BD und zukünftig penible Nachprüfung aller Edits wären die Folge. Mit einem explizit angegebenen k oder t gibt man auch die Zusicherung, dass der Sinn nicht verändert wurde.
    • Soweit ich die etwas verschwommenen Vorstellungen der MBF10-Vertreter richtig interpretiere, soll es zukünftig in den fraglichen Namensräumen technisch unmöglich sein, eine Bearbeitung zu speichern, ohne irgendeinen Bearbeitungskommentar anzugeben.
  3. Effekt nach dem Speicher-Klick:
    • Wie Steef389 schon richtig bemerkt hatte, kann man leicht übersehen, dass das Auslösen des Abspeicherns nicht die gewünschte Endwirkung hatte.
    • Wenig erfahrene WP-Benutzer wie Newbies und IP rechnen überhaupt nicht damit, dass nach dem Speicher-Klick die Abspeicherung vielleicht nicht erfolgt wäre.
    • Ich persönlich arbeite parallel an vielen Browser-Tabs und Bildschirm-Fenstern. Nachdem ich mit dem Speichern-Klick eine Angelegenheit soweit beendet habe, wechsele ich unmittelbar zu einer anderen Aufgabe. Das funktioniert in aller Regel. Es passiert aber hin und wieder, dass ich nach Absenden eines Diskussionsbeitrages für eine Viertel- oder ganze Stunde zum Tab zurückkehre, um nach möglichen Antworten zu gucken – und meinen nicht wirksam gewordenen Beitrag nach Bearbeitungskonflikt vorfinde. Auch im ANR passiert das gelegentlich; so wurde zwischenzeitlich in einem Artikel eine URL auf die Spam-Blacklist gesetzt, während ich nun das Weblinkformat oder Ähnliches korrigierte und ich irgendwann beim Tab-Aufräumen überrascht den nicht gespeicherten Artikel fand. Immerhin bin ich so routiniert, dass ich die Tabs nicht unmittelbar nach dem Speichern-Klick schließe. Den Bearbeitungskommentar gebe ich jedoch routinemäßig in 999 von 1000 Edits von selbst an und werde somit nur äußerst selten von forceeditsummary an das Fehlen erinnert.
  4. Die .pl-Lösung läuft auf ein (temporäres) Deaktivieren des Buttons hinaus.
    • Das steht momentan nicht in Rede.
    • Ich bin offen für Lösungen auf diesem Weg; jedoch müsste der genaue Ablauf präzisiert werden.
    • Insbesondere wäre zu klären, wie genau sich das dann bei Nicht-Eingabe der summary auswirken würde.
    • Ein Eingriff in die Aktionskopplung eines Buttons birgt immer das Risiko, dass in manchen Browser-Versionen die gewünschte Wirkung überhaupt nicht mehr zu erreichen ist.
    • Es ist auszudiskutieren, ob diese Art der Benutzerführung dazu geeignet wäre, zum Standard für alle IP sowie alle angemeldeten Benutzer zu werden, die kein opt-out gesetzt haben.
  5. Das Design wäre abschließend noch mild und augenverträglich, aber gleichwohl auffallend zu gestalten.
    • Es ist für die JS-Entwicklung zunächst unerheblich, welche Rottöne verwendet werden, wieviel px ein Rahmen breit ist, welche Elemente in ihrer Farbgestaltung verändert werden.
    • Die momentane Gestaltung ist sicher noch in der Testphase.

--PerfektesChaos 09:27, 17. Apr. 2012 (CEST)

  1. Das polnische Skript leistet genau das.
  2. Das ist Bevormundung. Widerspruch zu 1.
  3. und 4. Ja, und? Probier bitte die .pl-Lösung aus. Genau so muss das sein. Minimal-invasiv. Man wird augenblicklich (also ohne dass irgend etwas nachlädt, das ist ganz wichtig und der entscheidende Unterschied zum existierenden forceeditsummary) daran erinnert, dass man die Zusammenfassung vergessen hat und kann das im selben Augenblick wegklicken, sogar ohne die Maus zu bewegen.
  5. Jede Formatierung nervt, stört und bevormundet, wenn sie an irgendwelche willkürlich festgelegten Events gebunden und zu für die Benutzer kaum nachvollziehbaren Zeitpunkten plötzlich zugeschaltet wird. Das ist praktisch eine Animation, die grundsätzlich dann von der Artikelarbeit ablenkt, wenn man das überhaupt nicht gebrauchen kann, weil man noch mittendrin ist. Das lenkt ab und zählt damit für mich zur Kategorie Bevormundung. Wenn es einfach nur darum geht, das Feld hervorzuheben, dann macht das bitte per CSS.
Das hier diskutierte Skript entspricht in seinem Effekt einem Popup, in dem steht „Achtung, du hast gerade ein Zeichen geändert. Bitte begründe deine Änderung zuerst, bevor du fortfährst.“ Dass das kein Zwang ist, weiß ich. Das ändert nichts am Effekt, dass man von der Farbänderung der Zusammenfassungszeile abgelenkt wird wie von einem Werbepopup, das Sekunden nach dem Laden einer Seite erscheint und um Aufmerksamkeit buhlt, während man gerade dabei ist, den ersten Satz auf der Seite zu lesen. Zu dem Zeitpunkt, in dem man das erste Zeichen ändert, weiß man sehr wahrscheinlich überhaupt noch nicht, was man noch alles ändern und welche Quellen man noch heranziehen wird, ehe man abschließend auf „Speichern“ drückt.
Das Eingeben eines Zeichens in einem Textfeld ist nicht nur eine Aktion, bei der ich nicht damit rechne, dass sie ein Ereignis auslöst, es ist eine Aktion, von der ich erwarte, dass sie kein Ereignis auslöst.
Die Mitteilung der .pl-Lösung lautes dagegen sinngemäß „Achtung, du willst gerade eine Änderung ohne Bearbeitungskommentar speichern. Bist du dir sicher?“ --TMg 22:14, 18. Apr. 2012 (CEST)
Was ich an der pl-Lösung nicht gut finde, ist dass die aktuelle Benutzerführung verändert wird. Der Autor hat einmal mehr zu Klicken zum den alten Effekt (Speichern ohne Zusammenfassung) zu erreichen. Ich fände das auch schon Bevormundung und wäre genervt, weil ich mit meiner Maus nicht mehr über den Speicherbutton bin, sondern vermutlich gerade zur Tableiste navigiere (Mit Shortcut vielleicht schon den Tab gewechselt habe). Natürlich kann man sagen, das Formulare häufig so aufgebaut sind, das die bei einem Klick die nicht gefüllten "Pflichtfelder" kenntlich machen, aber da es Jahre lang nicht so war, ist es schwierig dies einzufordern (Hat mit forceeditsummary auch nicht geklappt).
Mein Ansatz ist so gestrickt, das die alte Benutzerführung erhalten bleibt, der Autor nur weitere Informationen bekommt und die Benutzerführung unterbrechen kann. Er weiß vor dem Klick auf Speichern, was er noch zu tuen hat, damit das Speichern im Sinne des Wikis in Ordnung wäre. Technisch in Ordnung ist es ja immer (Abgesehen von hinzugefügten Weblinks).
In der Zwischenzeit ist das Gadget auch soweit abgeändert, das es nur noch eine Hervorhebung macht, wenn man etwas im Textfeld geändert hat und das Textfeld anschließend verlassen wurde (Fokus verloren). Der Umherirrende 21:30, 19. Apr. 2012 (CEST)
Zum Einwand, dass auch die .pl-Lösung bevormundend ist: Ich gehe ganz selbstverständlich davon aus, dass das für angemeldete Benutzer abschaltbar sein wird. Im Idealfall für jeden Namensraum einzeln. Ich würde die .pl-Lösung gern verwenden, denn forceeditsummary, was ich jetzt verwende, nervt dadurch, dass es jedes mal die Seite neu lädt.
Zum aktuellen Entwicklungsstand des Gadgets: Zuerst einmal Danke dafür, dass meine Einwände Gehör gefunden haben. Leider ist das Gadget dadurch endgültig nutzlos geworden, denn wenn man jetzt auf „Seite speichern“ klickt, während der Cursor noch im Textfeld steht (was der Normalfall sein dürfte), wird man nie über die vergessene Zusammenfassung informiert.
Ich wiederhole mich, aber ich sehe ganz ernsthaft nur zwei Lösungswege: Entweder, das Eingabefeld wird gleich beim Aufruf des Editors stärker hervorgehoben (als reines CSS-Gadget, eventuell eingeschränkt auf bestimmte Benutzergruppen oder an Bearbeitungszähler gebunden). Oder so wie die .pl-Lösung, die den ersten Klick auf den Speichern-Knopf abfängt (was für angemeldete Benutzer wie gesagt unbedingt abschaltbar sein muss). Die aktuelle Version des Gadgets zeigt ganz deutlich, dass Mittelwege zwischen diesen beiden Lösungen nicht funktionieren. --TMg 22:58, 19. Apr. 2012 (CEST)
Daher hatte ich daran gedacht, das es direkt sichtbar ist, sehe aber ein, das es vielleicht zu früh schon aufdringlich ist. Wenn man aber nach dem Bearbeiten direkt speichern drückt (wird wohl am meisten gemacht), dann merkt man es natürlich nicht, weil ich das ganze nach Einwand wieder zurückgebaut hatte. Man könnte das Highlighting noch machen, wenn die Maus den Speicherbutton "entert", wobei man das auch nicht umbedingt mehr wahrnehmen muss, wenn man sofort drückt. Wenn mit Shortcuts gearbeitet wird, hat das Gadget garkeine Chance. Der Umherirrende 21:09, 25. Apr. 2012 (CEST)

Ich werde mir mal zum Wochenende Gedanken machen und dann eine separate Seite zu der Entwicklung aufmachen. Es läuft auf eine vielschichtige individuelle Benutzerkonfiguration bis hin zum kompletten opt-out für angemeldete Benutzer hinaus. --PerfektesChaos 23:03, 19. Apr. 2012 (CEST)

Ich nutze wie oben erwähnt die Einstellung „Warnen, sofern beim Speichern die Zusammenfassung fehlt“, aber die nervt wie gesagt, weil die Warnung serverseitig erzeugt wird und erst nach einem Neuladen der Seite erscheint. Ich habe mir deshalb jetzt mein eigenes Helferlein geschrieben, so wie es meiner Meinung nach sein sollte: Benutzer Diskussion:TMg/forceEditSummary.js. --TMg 02:28, 12. Jun. 2012 (CEST)


Archivierung dieses Abschnittes wurde gewünscht von: --PerfektesChaos 22:41, 28. Jul. 2012 (CEST)

Klickbarer Permalink für Zusammenfassungszeile

Ich fände ein Script praktisch, das in die Zusammenfassungszeile eingegebene Permalinks der Form http://de.wikipedia.org/w/index.php?oldid=12345678#Abschnitt automatisch in [[Spezial:Permanenter Link/12345678#Abschnitt]] umwandelt. Dadurch würde der Link klickbar. Ev. könnte diese Funktionalität in MediaWiki:Gadget-PermaPageLink.js integriert werden. --Leyo 13:22, 20. Feb. 2012 (CET)

Mit dem Gadget hat das überhaupt nichts zu tun.
Die Idee ist gut, sollte aber für sämtliche Zusammenfassungsfelder aktiviert werden (edit, move, delete, etc.). Gibt es eine Möglichkeit, diese zu einfach zu erkennen (anstatt für jede Seite die jeweilige input-id rauszusuchen)? Ich würde auch noch vorschlagen, dass (solange der Platz reicht) ein Alternativtext ([[Spezial:Permanenter Link/12345678|Version 12345678]]) generiert wird. -- ✓ Bergi 19:13, 20. Feb. 2012 (CET)
Vielfach hat in der Ausgangs-URL auch title enthalten. Dies könnte beim Alternativtext berücksichtigt werden. --Leyo 19:17, 20. Feb. 2012 (CET)


  • Man kann alle input suchen; damit fallen die textarea weg.
  • Das jQuery-Spezial input:text sollte lieber nur nach Quellcode-Analyse (Sizzle) benutzt werden, ist mir zu analog zu CSS3. Dem traue ich erstmal nicht, könnte Browser-abhängig sein.
  • Der type müsste text (oder undefined[?] – WP arbeitet da aber eigentlich sauber) sein.
  • Danach bleiben normalerweise eigentlich nur zwei Felder übrig, das Suchfeld oder die Zusammenfassung, egal welche. Wenn jemand in das Suchfeld eine URL eingibt, möge er das machen. Ansonsten wäre es die summary beim rollback etc. – völlig egal, auf welcher Seite wozu, die angedachte Umwandlung Weblink→Wikilink kann in keinem Feld <input type="text"> schaden.
  • Das wäre dann ein neues Gadget, das ja als opt-out konfiguriert werden kann.
  • Es müsste auf keydown change mouseup reagieren (neulich hatte der Umherirrende mal mit einem Warn-mich-wenn-fehlt angefangen, da wurde das schon mal getestet.), damit noch während der Bearbeitung die eingesparten 8–15 Zeichen für mehr Inhalt genutzt werden können; beim Abspeichern wäre es dafür zu spät.
  • Wenn man schon eine solche Zeichenkette inspiziert, kann man auch gleich führende und mehrfache Leerzeichen/Whitespace eindampfen. Das schadet auch keinem Upload-Feld oder was immer wir an Formularen hätten, und führende und mehrfache Leerzeichen brächten auch das Suchfeld nicht weiter.
  • Weil es auf gleichen Feldern tätig werden würde wie der Vergessen-Warner, könnte es vielleicht ein einziges Gadget mit Optionen werden.

VG --PerfektesChaos 17:14, 21. Feb. 2012 (CET)


Übernommen in
Archivierung dieses Abschnittes wurde gewünscht von: --PerfektesChaos 19:04, 4. Aug. 2012 (CEST)

"Eigene" Artikel

Unter Benutzer:Drahreg01/vector.js steht relativ weit unten ein Skript (?), das *mir* Nobelpreisträger (nach Kategorie) markiert. Ist es möglich, eine ähnlich Markierung nach einer Liste zu machen, zB nach Benutzer:Drahreg01/Showroom?

Viele Grüße, --Drahreg•01 18:00, 24. Jun. 2012 (CEST)

  1. Ja, es ist möglich.
  2. Ein solches Skript hätte Potential, ein Renner unter den Benutzerskripten bis hin zum Gadget zu werden: Viele Leute möchten auf ihrer BEO eine besondere Hervorhebung, wenn sich auf den von ihnen selbst angelegten (oder sonst auf einer „Ganz-Besonders-Beobachten-Liste“ vermerkten Seite stehend) Artikeln etwas tut.
Nur munter zu --PerfektesChaos 18:23, 24. Jun. 2012 (CEST)
Wenn ich irgendeine blasse Ahnung davon hätte, wie soetwas geht, hätte ich hier nicht gefragt. *Meine* Vorstellung ist, dass diese Markierung auf "normalen" Wikipedia-Seiten wirksam wird. Ob das auch auf Spezialseiten wie der Beo wirksam wäre, wär mir jetzt egal. --Drahreg•01 18:30, 24. Jun. 2012 (CEST)
*g* Das war mir schon durchaus klar. – Das „nur munter zu“ war auch an die mitlesenden Werkstatt-Kollegen gerichtet.
Deine Präzisierung ist gleichwohl hilfreich – es gibt zwei Anwendungsfälle:
  1. Auf Listen-Seite vorkommende Seiten auf der BEO hervorheben.
  2. Diese Links auf beliebigen Seiten hervorheben.
Wie ich die Arbeitsbelastung und den Rückstau an Programmieraufgaben deute, könnte die Realisierung etwas dauern; es sei denn, jemand möchte das auch erstmal für sich selbst haben.
Liebe Grüße --PerfektesChaos 18:54, 24. Jun. 2012 (CEST)

Ich habs mal versucht: Benutzer Diskussion:TMg/userHighlight.js. Man kann eine Liste angeben (oder irgend eine x-beliebige Seite) und alle Links von dieser Seite werden geladen und dann überall (!) hervorgehoben (hellblauer Hintergrund). Das Skript ist längst nicht fertig, aber wer es testen und mir Rückmeldungen geben möchte, ist herzlich eingeladen. --TMg 22:54, 24. Jun. 2012 (CEST)

Das sieht schon supergut aus, vielen Dank! Während o.g. Skript (Nobelpreisträger) allerdings für Weiterleitungen sensibel ist (sie also auch anzeigt), "verschluckt" dein Skript sie. Kannst du das noch nachbessern? Viele Liebe Grüße, --Drahreg•01 23:16, 24. Jun. 2012 (CEST)
Noch was: Mousover entfärbt die Markierung. LG, --Drahreg•01 23:22, 24. Jun. 2012 (CEST)
Ich habe dort geantwortet. --TMg 00:00, 25. Jun. 2012 (CEST)


Wikipedia:Technik/Skin/Werkstatt/Baustellen/Hervorhebung bestimmter Wikilinks – die volle Umsetzung wird sich etwas hinziehen.

Archivierung dieses Abschnittes wurde gewünscht von: --PerfektesChaos 20:58, 4. Aug. 2012 (CEST)

Link auf Commons-Dateiliste

Ich möchte bei Spezial:Dateien/Benutzername einen Link auf commons:Special:ListFiles/Benutzername ergänzen. Ist MediaWiki:Listfiles-summary die passende MW-Seite? Ist der Benutzername in $1 gespeichert? --Leyo 14:35, 6. Jun. 2012 (CEST)

Ja, nach Test und Doku ist es die richtige Seite. Aber nein, afaik wird der Nutzername nicht als Parameter übergeben. -- ✓ Bergi 18:01, 6. Jun. 2012 (CEST)
Bedeutet dies, dass es nicht geht? Oder kann der Benutzername aus der URL herausgelesen werden? --Leyo 18:42, 6. Jun. 2012 (CEST)
Vermutlich müsstes du mit den gleichen Einschränkungen leben, die auch bei MediaWiki:Emailpagetext auftreten beim einbinden der /E-Mail-Hinweis-Benutzerunterseite. Der Umherirrende 19:57, 6. Jun. 2012 (CEST)
Besser als nichts wäre das IMHO noch lange. --Leyo 20:37, 6. Jun. 2012 (CEST)
Ich habe mal etwas eingebaut. Den Text kannst du gerne noch ändern. Der Umherirrende 21:20, 8. Aug. 2012 (CEST)
Toll, vielen Dank! Ich habe den Text etwas geändert und unnötige Leerzeilen bei unbekanntem Benutzernamen vermieden. OK? --Leyo 10:23, 9. Aug. 2012 (CEST)
Ja, sieht auch gut aus. Hat zwar keinen uselang mehr, aber das dürfte dort nicht so wichtig sein. Der Umherirrende 10:55, 9. Aug. 2012 (CEST)
… dafür die vom Benutzer eingestellte Sprache. Bei einigen ist das ev. dort bewusst Englisch, bei mir ist es de statt de-ch (nicht überall auf dem neusten Stand). --Leyo 11:02, 9. Aug. 2012 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 10:55, 9. Aug. 2012 (CEST)

diffpage * IE * scrollbars

Hi all,

hier lief grad eine Beschwerde auf.

  • Ich erinnere mich, beim IE8 diesen Effekt gesehen zu haben.
  • Ich hatte kurz und vergeblich nach der Ursache gesucht.
  • Es geht um eine minimale Differenz; womöglich ein Rundungsfehler oder nicht einberechnetes padding bzw. border-width.
  • Weil das weltweit zur Verbesserung beitragen könnte, wäre eine Fahndung in bugzilla und/oder mit IE-Versionen hilfreich. Ich habe IE nur zwangsweise gelegentlich, wo vorinstalliert.
  • Es ist fraglich, ob sich die scrollbars nur durch den Farbwechsel „Lesehilfen → Stellt Versionsunterschiede in den bisherigen Farben dar“ beseitigen ließen.

Liebe Grüße --PerfektesChaos 13:58, 26. Jun. 2012 (CEST)

Zwischenstand Nachforschungen:
  • Es geht offenbar nur um ein Pixel.
  • Mit Variation der Gesamtfensterbreite lässt sich für den gleichen Absatz der horizontale Scrollbar (im IE8) mal produzieren, dann verschwindet er, dann taucht er wieder auf. Sieht nach Rundungsfehler aus.
  • Selten gibt es auch vertikale Scrollbars, die natürlich bleiben.
  • Analyse der Kaskade zeigt an Verdächtigen:
     TABLE.diff TD DIV
        word-wrap: break-word
        overflow: auto
        TD.diff-context
           white-space: pre-wrap
  • Wenn ich die beiden entscheidenden Direktiven umpole, verschwindet der Effekt in meinem IE:
TABLE.diff TD DIV {
   overflow: visible;
}
TD.diff-context {
   white-space: normal;
}
  • Wobei overflow der Hauptverantwortliche für Scrollbars wäre. Das auto erbt irgendwas von irgendwoher; in der Hierarchie drüber habe ich keine explizite Zuweisung finden können. Demnach wäre das Verhalten von der allgemeinen Browser-Konfiguration abhängig, und dem Glauben an CSS-Standards.
Andere Erfahrungen? Browser? Meinungen? Bugzilla? Projekt-lokaler workaround?
Liebe Grüße --PerfektesChaos 18:43, 26. Jun. 2012 (CEST)


Übernommen in
Archivierung dieses Abschnittes wurde gewünscht von: --PerfektesChaos 21:28, 8. Aug. 2012 (CEST)

Shortcut für Signatur

Hi, gibt es eine Möglichkeit, die Signatur (also --~~~~) im Edit-Fenster auch über einen Tastatur-Shortcut zu erzeugen, also bspw. mit Alt Gr + ~? Ich verwende Monobook, falls von Bedeutung. --Mabschaaf 11:28, 31. Jan. 2012 (CET)

Mit Werkzeugen wie AutoHotkey ist das gar kein Problem. Aber global für alle Wikipedia-Benutzer? Mit JavaScript ist so etwas zwar technisch möglich, aber extremst fragwürdig. --TMg 02:03, 6. Feb. 2012 (CET)
Also ich erzeuge die Tilde per Alt Gt++ und wüsste nicht wo ich da noch einen Hotkey unterbringen sollte… Ja, ist mit JS möglich, aber m.W. von System/Tastatur und Browser abhängig und daher unangenehm zu programmieren. -- ✓ Bergi 07:39, 6. Feb. 2012 (CET)
Bei mw.util.addPortletLink kann man bereits ein Accesskey angeben und dieser erhält dann auch das browserspezifische Präfix. Vielleicht könnt ihr ja damit etwas basteln. Ich weiß allerdings nicht, ob das überhaupt funkioniert, da ich damit kaum arbeite. Der Umherirrende 12:08, 11. Feb. 2012 (CET)
Tatsächlich, mit der alten Toolbar funktioniert mw.util.updateTooltipAccessKeys($('img[title="Unterschrift mit Zeilenumbruch"]').attr({accesskey:"u", title:function(i, t){return t+" ["+this.accessKey+"]"}}));. Dann hat man hat man halt das browserspezifische Kürzel + u statt das gewünschte Alt Gr + ~, aber es funktioniert immerhin. -- ✓ Bergi 19:16, 11. Feb. 2012 (CET)
Vielen Dank schon mal soweit. Kann man mir als DAU noch erläutern, wohin dieser Code-Schnipsel muss, damit er funktioniert? --Mabschaaf 13:35, 13. Feb. 2012 (CET)
Als erstes nochmal die Nachfrage: Hast du die neue Bearbeitungswerkzeugleiste aktiviert oder arbeitest du noch mit der alten? Obiger Code funktioniert nur mit der alten, für die neue kann Schnark den Code hoffentlich ummodeln?
Ansonsten benötigst du noch etwas zusätzlichen Code, der Schnipsel soll nur im Editmodus und erst nach dem Laden ausgeführt werden.
// Stattet die (alte) Toolbar mit Accesskeys aus
// Skript von Bergi ([[Benutzer:✓]]) aus der Wikipedia:TSW, 2012-02-13
mw.loader.using("mediawiki.util", function() {
   if (mw.config.get('wgAction') != "edit" && mw.config.get('wgAction') != "submit")
      return;
   jQuery(function($) {
      if (!mw.toolbar || !mw.toolbar.$toolbar)
         return alert("Toolbar nicht gefunden, wird vielleicht die neue benutzt?");
      var conf = { // Schlüssel ist die LOKALISIERTE Beschreibung (auch im Tooltip) des jeweiligen Buttons, leider haben die keine ids
         "Deine Signatur mit Zeitstempel": "g"
      };
      var selectors = [];
      for (var k in conf)
         selectors.push('img[alt="'+k+'"]');
      var $updated = mw.toolbar.$toolbar.children(selectors.join(", "))
      .prop('accessKey', function(){
         return conf[this.alt];
      })
      .attr('title', function(i, t){
         return t+" ["+this.accessKey+"]";
      });
      mw.util.updateTooltipAccessKeys($updated);
   });
});
… in deine monobook.js.
An alle anderen: Wie kann ich auf Vorhandensein von mediawiki.action.edit absichern, ohne es zu laden? -- ✓ Bergi 14:49, 13. Feb. 2012 (CET)
mw.loader.getState("mediawiki.action.edit")
Sollte immer durch Startup registered sein; wenn auch geladen dann ready.
HGZH --PerfektesChaos 15:30, 13. Feb. 2012 (CET)
Ach, ja, getState() hab ich selbst geschrieben… Wie in Bug 28995 angesprochen, hätte ich mir eigentlich ein onload("m.a.e") gewünscht :-( -- ✓ Bergi 16:27, 13. Feb. 2012 (CET)
Ich nutze noch die alte Toolbar, habe den Schnipsel in die monobook.js kopiert, sehe aber leider noch kein Erfolgserlebnis :-( --Mabschaaf 15:00, 13. Feb. 2012 (CET)
Nicht den Schnipsel solltst du kopieren, sondern den großen Block :-) Mit dem conf-Objekt kannst du dir auch für weitere Buttons accesskeys festlegen. -- ✓ Bergi 16:27, 13. Feb. 2012 (CET)
Hmm, der große Block führt bei mir dazu, dass die Toolbar gar nicht mehr angezeigt wird - und eine Shortcut-Funktion kann ich nicht erkennen. (Übrigens: FF 10.0.1)--Mabschaaf 16:49, 13. Feb. 2012 (CET)
Keine Anzeige der Toolbar kann ich jetzt leider nicht nachvollziehen, auch nicht in FF. Ansonsten habe ich drei Bugs identifiziert, die bei mir nicht auftreten:
  • Du hast vermutlich die normalen Editbuttons, ich habe mit dem Extra-Editbuttons-Gadget (bzw. meiner lokalen Version davon) dran rumgedreht. Daher heißt der Button bei dir anders, ersetze den String Unterschrift mit Zeilenumbruch durch Deine Signatur mit Zeitstempel.
  • Der Accesskey „u“ ist schon für den „Upload“ reserviert (hatte ich bei mir aus Versehen deaktiviert). Ich schlage „g“ wie in „signieren“ vor, du kannst natürlich auch etwas anderes wählen. Aber Vorsicht, es ist bereits viel belegt! Eine Übersicht erhältst du in Opera per Shift+Esc :-)
  • Ich bin mir nicht sicher, ob sich FF und Opera unterscheiden, aber setAttribute mag sich oft nicht auf das tatsächliche Verhalten auswirken. Daher sicherer mit direktem Zugriff auf die Property.
Obiges Skript sollte dann funktionieren (Veränderungen). Wenn die Toolbar aus unerfindlichen Gründen verschwinden sollte, schau mal unter Wikipedia:JS#Fehlermeldungen nach. -- ✓ Bergi 19:21, 13. Feb. 2012 (CET)
Ja, danke, jetzt gehts. Von meiner Seite damit hier erledigt. --Mabschaaf 20:07, 13. Feb. 2012 (CET)
Dazu passend eventuell noch das signing-Script. Unterstützt Signatur per Shortcut auch seit über einem Jahr. -- πϵρήλιο ℗ 00:12, 20. Aug. 2012 (CEST) -- πϵρήλιο ℗ 00:12, 20. Aug. 2012 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 23:22, 19. Aug. 2012 (CEST)

Datei-Duplikat-Anzeige verschwindet

Hi, ich nutze PDDs monobook features - siehe Benutzer:JuTa/monobook.js. Seit einigen Tagen verschwinden bei mir die Datei-Duplikat-Anzeigen; z.B. hier. Ohne PDDs monobook bzw. unangemeldet erscheint die Anzeige ganz unten. Mit sollte dies in einen "Kasten" oben rechts geschoben werden. Nur seit ein par Tagen verschwindet die Anzeige komplett, also sie steht kurz unterm Bild und verschwindet dann nach Sekundenbruchteilen, anstatt wie gewohnt in den Kasten oben rechts zu springen. Ich habe bereits meine monobook.js auf PDDs aktuelle Version gebracht und versuchsweise die Variable imgdupecheck auf false gestellt. Hat aber nichts geholfen. Könnten Java-Script kundige Helfer mir vielleicht einen Tip geben woran das liegen könnte bzw. was ich ändern müsste um die alte Anzeige wieder zu bekommen. An meiner Benutzer:JuTa/monobook.css kann es nicht liegen, oder? Vielen Dank im Vorraus. Gruß --JuTa 00:15, 23. Mär. 2012 (CET)

Ich kann es nachvollziehen, beschwer dich am besten bei PDD, damit er Benutzer:PDD/checkDupes.js debuggt. --Schnark 09:37, 26. Mär. 2012 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 23:23, 19. Aug. 2012 (CEST)

Helferlein Extra-Editbuttons nicht kompatibel mit 1.20wmf9

Schnark hat es unter Wikipedia:NEU#15._August angekündigt und nach Wikipedia Diskussion:Helferlein/Extra-Editbuttons#rmEditButtons tut nicht mehr scheint es auch zu stimmen, das die Extra-Editbuttons eine Anpassung brauchen. Die verursachende Änderung in MediaWiki war wohl gerrit:16238, wobei dort auch etwas von "b/c" steht, aber da weiß man ja nie, für welchen Bereich. Ich glaube, es würden sich viele Benutzer freuen, wenn es hier eine entsprechende Anpassung geben wird. Ich kenne mich mit dem Helferlein nicht aus und nutze es nicht, aber beim letzten Mal waren es schon einige Benutzer, die sich gemeldet hatten. Quelltext des Helferleins. Der Umherirrende 20:32, 19. Aug. 2012 (CEST)

Ich muss mich hier leider auch ausklinken. Ich habe die Dinger noch nie benutzt, und den Quelltext und das ganze Drumrum noch nie angefasst; scheint aber eine komplexere Angelegenheit zu sein. Wer sich mutmaßlich am besten damit auskennt, wäre Schnark; aber der ist seit über zwei Wochen off und rennt vermutlich grad den Eisbären davon, oder er brät sich in Freiburg oder sonstwo die grauen Zellen schwarz. Bedauernd --PerfektesChaos 23:21, 19. Aug. 2012 (CEST)
mw.toolbar.$toolbar ist jetzt privat. Diese Änderung sollte das Problem beheben. Grüße --P.Copp (Diskussion) 14:34, 23. Aug. 2012 (CEST)
Ich habe das mal so eingespielt, und es scheint zu funktionieren. Danke!! --Krd 14:50, 23. Aug. 2012 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 15:46, 24. Aug. 2012 (CEST)

Problem mit MediaWiki:Gadget-markadmins.js auf eowp

Hallo, Es gibt ein Problem mit MediaWiki:Gadget-markadmins.js in der Esperantowikipeda. Dort wird ein Admin, nämlich Umbert' nicht markiert. Wer hat da vielleicht eine Idee? Das ' im Namen habe ich zwar im Skript per \ markiert. Es hilft aber leider nicht. Warum? Gruß --Tlustulimu (Diskussion) 16:35, 26. Aug. 2012 (CEST)

Das \' war erstmal erforderlich, um syntaktisch korrektes JavaScript daraus zu machen. Aber probier doch mal Umbert%27 aus. Liebe Grüße --PerfektesChaos 17:10, 26. Aug. 2012 (CEST)
Danke für deinen Vorschlag. Aber Benuzter:Hoo man war schneller. Es funktioniert jetzt richtig. --Tlustulimu (Diskussion) 17:25, 26. Aug. 2012 (CEST)
Wie schon bemerkt, habe ich das Gadget stark verändert und an aktuelle Standards angepasst (diff). Außerdem wird es jetzt über den ResourceLoader geladen (diff). Grüße, Hoo man (Diskussion) 17:28, 26. Aug. 2012 (CEST)
Danke, Hoo man. Es funktioniert jetzt richtig. Kannst du mal bei der Gelegenheit auch gleich die obersorbische Version vom Gadget aktualisieren? Ich bin dort zwar Admin, habe aber leider nicht so viel Ahnung von Javascript. --Tlustulimu (Diskussion) 17:33, 26. Aug. 2012 (CEST)

Erledigt: Gadget diff, definition diff  Vorlage:Smiley/Wartung/;)  Grüße, Hoo man (Diskussion) 17:49, 26. Aug. 2012 (CEST)

Danke, Hoo man. Jetzt habe ich doch auch noch vergessen, daß es auch noch die niederersorbische Version vom Gadget gibt. Könntest du eventuell auch noch dort aktualisieren? Gruß --Tlustulimu (Diskussion) 18:01, 26. Aug. 2012 (CEST)
Auch erledigt: Gadget diff, definition diff. Grüße,
Danke, Hoo man. Da ist aber noch ein Fehler drin, denn es heißt zwar Wužywaŕ ("Benutzer"), aber Wužywarka ("Benutzerin"). Die weibliche Form hat also keinen Strich auf dem r, nur die männliche. Dies gilt aber nur für das Niedersorbische. --Tlustulimu (Diskussion) 18:46, 26. Aug. 2012 (CEST)
Hab ich gar nicht gesehen... geändert. Grüße, Hoo man (Diskussion) 18:53, 26. Aug. 2012 (CEST)
Danke, Hoo man. :-) --Tlustulimu (Diskussion) 19:07, 26. Aug. 2012 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: --Tlustulimu (Diskussion) 19:07, 26. Aug. 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 389 22:23, 31. Aug. 2012 (CEST)
Danke! --intforce.aka.weltforce 22:37, 31. Aug. 2012 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: Leyo 22:19, 6. Sep. 2012 (CEST)

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)

Übertragen nach Wikipedia:Technik/Skin/Werkstatt/Baustellen/Erweiterte Beobachtungsliste komprimieren.
Archivierung dieses Abschnittes wurde gewünscht von: --PerfektesChaos 21:36, 19. Sep. 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 Wikipedia: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)
Archivierung dieses Abschnittes wurde gewünscht von: --PerfektesChaos 21:44, 19. Sep. 2012 (CEST)

Container

Moin, es gibt ja die Möglichkeit, einzelne Links in den "Containern" (p-cactions etc) durch addPortletLink() zu erstellen. Gibt es auch die Möglichkeit, neue Container einzurichten, z.B. in der Toolbar zusätzlich zu den Gruppen "Mitmachen", "Werkzeuge" noch einen eigenen Container (z.B. "Meine Links")? Danke, --weltforce (Diskussion) 19:25, 17. Sep. 2012 (CEST)

Bei Monobook wird doch genau dies erzeugt. Aber du verwendest wohl Vector, hast aber vergessen, es zu erwähnen. --Leyo 19:36, 17. Sep. 2012 (CEST) PS. Ev. wäre meta:User:Hoo man/Scripts/Useful links etwas für dich.
Stimmt, ich verwende Vector, hab's vergessen zu erwähnen. Hm, bei dem Skript werden die Links unter den Benutzerlinks hinzugefügt. Ich würde sie aber gerne in der Toolbox haben. Hab irgendwo was von portletArea gelesen, kann aber damit leider nichts anfangen. --weltforce (Diskussion) 19:39, 17. Sep. 2012 (CEST)
Man kann einfach einen neuen Kasten dazubasteln. Die Click-Handler zum Ein- und Ausklappen funktionieren dabei automatisch:
$("#mw-panel").append('<div class="portal" id="p-custom"><h5><a>Meine Links</a></h5><div class="body"><ul></ul></div></div>');
Soll der Kasten ständig angezeigt werden, neben portal die Klasse persistent einfügen. Soll er eingeklappt sein, collapsed verwenden und style="display:none;" neben den body einfügen; für ausgeklappten Zustand expanded und display:block; verwenden.
addPortletLink("p-custom", …) funktioniert dann wie immer, nur halt mit anderen Container-Id. -- ✓ Bergi 21:02, 17. Sep. 2012 (CEST)
Danke, funktioniert super! --weltforce (Diskussion) 07:32, 18. Sep. 2012 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: Leyo 19:08, 28. Sep. 2012 (CEST)

NOEDITSECTION übersteuern

In Vorlage:Archiv ist __NOEDITSECTION__ enthalten. Zum Linkfixen wäre es aber teilweise praktisch, einzelne Abschnitte bearbeiten zu können. Wie lässt sich dies übersteuern? --Leyo 10:12, 14. Sep. 2012 (CEST) 

if (0 === $('.editsection').length) mw.util.$content.find('h2').not('#toctitle h2').each(function(i, el) {
    var $el = $(el);
    $('<span>', { 'class': 'editsection' }).append(
        '[',
        $('<a>', {
            title: "Abschnitt bearbeiten: " + ($el.find('span:first').text() || $el.text()),
            href: (mw.util.wikiScript() + '?' + $.param({
               title: mw.config.get('wgPageName'),
               action: 'edit',
               section: i+1
            })),
            text: "Bearbeiten"
        }),
        ']'
    ).appendTo($el.append(' '));
});
Noch nicht ausgiebig getestet (etwa was passiert wenn Nutzer <h2> HTML tags verwendet oder Einbindungen von Überschriften aus Vorlagen erfolgen. -- RE rillke fragen? 11:47, 15. Sep. 2012 (CEST)
Vielen Dank! Ich hätte nicht gedacht, dass es dazu so viel JS-Code braucht. Ehrlich gesagt dachte ich sogar, dass es sich mit einem Einzeiler-CSS-Code machen liesse. :-)
Wenn es eh schon so gemacht werden muss, so würde ich text: "Archivierten Abschnitt bearbeiten" verwenden. Den Mouse-Over-Text (der einige Code-Zeilen benötigt) könnte man IMO weglassen, da Neulinge kaum von diesem Script Gebrauch machen würden. --Leyo 13:16, 15. Sep. 2012 (CEST)
Wo nichts ist, kann man auch mit CSS nichts einblenden (ein paar Ausnahmen gibt es, aber neue <a>-tags kann man meines Wissens noch nicht erzeugen). Sicher geht es noch irgendwie kürzer; um den vielen whitespace musst Du Dir aber keine Sorgen machen, wenn es direkt in der common.js oder der monobook/vector.js steht, denn der wird vom RL entfernt. -- RE rillke fragen? 13:55, 15. Sep. 2012 (CEST)
Ich hab's nun ausprobiert, aber ich kriege einen JS-Fehler (TypeError: mw.util.$content is null) und es funkioniert nicht. --Leyo 00:26, 18. Sep. 2012 (CEST)


Ihr seid zu früh dran. Ich würde strukturell wie folgt umschreiben und dabei das veraltete addOnloadHook rauswerfen; ohne Kommentare, nur Grundprinzip; ungetestet: 

var newrollback = true;             // Erweiter
var allowmessage = true;            // Rollback
var autowarning = true;             // Wenn die
var standardblocktime = '6 hours';
var leveltwowarning = false;        // Wenn du
var optionnames = false;            // Hier bit
var templatenames = false;          // Hier bit
// Auf '1' setzen, um mehrere, unter optionname
var rollbacktype = '3';
// Erweiterter Rollback [[Benutzer:DerHexer/rollback.js]]
if (newrollback) {
   importScript('Benutzer:DerHexer/rollback.js');
}

// WikEd-Diff
mw.loader.load("//en.wikipedia.org/w/index.php?title=User:Cacycle/wikEdDiff.js"
               + "&action=raw&ctype=text/javascript");

importScript('Benutzer:Ireas/bilderpruefen.js');

// siehe [[Wikipedia:WikiProjekt Dateikategorisierung/Werkzeug/x]]
var fileAdmin_miniatur = false;
var fileAdmin_multiWin = false;


// ----------------------------------------------------------------------


function LeyoAfterLoad() {
   // Alle Aktionen, die erst nach Laden des HTML-Dokuments gehen
   var loc   = window.location,
       li,
       title = encodeURIComponent(wgTitle),
       url;
   // Anzeige Benutzername ändern
   document.getElementById('pt-userpage').getElementsByTagName('a')[0].innerHTML ...................

   if (wgNamespaceNumber === 6) {
      url = "//toolserver.org/~magnus/commonshelper.php?interface=de&language=de&project=wikipedia&commonsense=1&remove_categories=1&tusc_user=Leyo&reallydirectupload=1&image=" + title;
      mw.util.addPortletLink("p-cactions", url, "→C", "ca-tocommons", "Nach Commons verschieben");
      url = "//toolserver.org/~revolus/afterUpload/?lang=de&project=de.wikipedia.org&image=" + title;
      mw.util.addPortletLink("p-cactions", url, "?", "ca-afterupload", "Frühere Verwendung erraten");
   }

   if (wgNamespaceNumber === 10) {
      url = "//toolserver.org/~kolossos/templatetiger/template-parameter.php?lang=dewiki&template=" + title;
      mw.util.addPortletLink("p-cactions", url, "P", "ca-parameter", "TemplateTiger-Parameterauswertung");
   }

   url = "//toolserver.org/~mzmcbride/cgi-bin/watcher.py?db=dewiki_p&titles=" + wgPageName;
   mw.util.addPortletLink("p-cactions", url, "ºº", "ca-watchers", "Anzahl Beobachter");

   url = loc.protocol + '//' + loc.host + loc.pathname
         + (loc.search.length > 1
           ? ( ! mw.util.getParamValue("useskin")
               ? loc.search + "&useskin=vector"
               : loc.search.replace(/(&|\?)useskin=.+?(&|$)/g, "$1useskin=vector$2") )
           : "?useskin=vector");
   li = mw.util.addPortletLink("p-cactions", url, "V", "ca-skinwechsel", "Seite mit Vector-Skin");
   $(li).find('a').click( function() {
        this.href += loc.hash;
   }

   // Bei Archiven Abschnitte trotzdem einzeln bearbeiten
   if (0 === $('.editsection').length) {
      mw.util.$content.find('h2').not('#toctitle h2').each(
         function(i, el) {
            .........................
         }
   }
}   // LeyoAfterLoad()



// Nach Laden des HTML-Dokuments; sicherheitshalber nach Laden benötigter Module
jQuery(document).ready( function() {
      mw.loader.using(["mediawiki.util"],
                      LeyoAfterLoad);
});

Grüße --PerfektesChaos 09:09, 18. Sep. 2012 (CEST)

Danke! Ich werde es bald ausprobieren. Vorher noch zwei Fragen: Mit dem von monobook.js geladenen Code gibt es so keine Probleme? Wäre es allenfalls einfacher, die Funktion in eine eigene .js-Datei auszulagern und somit flexibler aufzurufen? --Leyo 21:44, 19. Sep. 2012 (CEST)
Nach dem Entfernen des Whitespace bleiben laut Google Closure Compiler noch ganze 399 Bytes übrig. Wegen denen einen neuen HTTP request zu starten, halte ich für übertrieben. -- RE rillke fragen? 23:45, 19. Sep. 2012 (CEST)
@Leyo: Nein, es bestehen keinerlei Bedenken.
Die Funktion ist nichts anderes als eine schlichte Definition ohne unmittelbare Wirkung
var LeyoAfterLoad = function () {...};
Sie wird von jQuery(document).ready in die Warteschlange eingereiht, wie es analog jedes einzelne addOnloadHook für seinen Brösel auch machte.
Eine Auslagerung wäre sinnfrei. Die macht man, wenn
  • großer Code nur manchmal benötigt wird (hier: immer erforderlich)
  • sehr umfangreicher Code zu unübersichtlich wird
  • eine Funktionalität mit Anderen geteilt werden soll.
LG --PerfektesChaos 09:45, 20. Sep. 2012 (CEST)
Ich bin endlich dazu gekommen, deinen Vorschlag umzusetzen. Es funktioniert, danke!
Du hast an mehreren Stellen encodeURIComponent(wgTitle) durch title ersetzt. Wirkt sich das bei Sonderzeichen nicht negativ aus? Kürzlich hatte ich eine Datei mit einem & im Namen.
Ich habe soeben einen negativen Nebeneffekt bemerkt: Auf Kategorieseiten erscheint nun bei Überschriften auch ein Bearbeitungslink. Daher sollten am besten die Namensräume auf D, PD, WD und WP eingeschränkt werden. Da es mehrere sind, geht if (wgNamespaceNumber === …) { nicht. --Leyo 16:50, 28. Sep. 2012 (CEST)


  • title ist die dritte lokale Variable der Funktion und das encodeURIComponent() von wgTitle. Hat man dies erstmal durchschaut, wird der Code übersichtlicher; auf jeden Fall effizienter.
  • Wenn du dir um & Sorgen machst, solltest du mit dem wgPageName in mzmcbride analog verfahren. Da sind zwar Unterstrichungsstriche statt Leerzeichen, aber Gold-Standard ist das noch nicht.
  • Drei Varianten gibt es, eine für recht viele mit switch lasse ich mal weg; nehmen wir mal durch Berechnung
if (wgNamespaceNumber  >  0   &&
    (wgNamespaceNumber % 2  ===  1   ||  
     wgNamespaceNumber  ===  4)) {
(Heißt auf mensch: Wenn größer Null und damit weder Artikel noch Spezialseite und außerdem entweder ungerade und damit Disku oder aber WPNR, dann)

Schönen Abend --PerfektesChaos 18:48, 28. Sep. 2012 (CEST)

Nun scheint alles zu funktionieren. Vielen Dank! --Leyo 19:11, 28. Sep. 2012 (CEST)
Doch noch nicht ganz: Bei &action=submit wird der Bearbeitungslink fälschlicherweise auch eingeblendet. So scheint's nicht korrekt zu sein. :-( --Leyo 19:38, 28. Sep. 2012 (CEST)
Dann heißt das in optimierter Auswertungsfolge:
if (wgNamespaceNumber  >  0   &&
    (wgNamespaceNumber % 2  ===  1   ||  
     wgNamespaceNumber  ===  4)   &&
    mw.util.getParamValue("action")  !==  "submit"   &&
   !   $('.editsection').length) {
Die Negation von $('.editsection').length ist wahr, wenn die Länge Null ist, also keine editsection gefunden wurde.
Grüße --PerfektesChaos 20:08, 28. Sep. 2012 (CEST)
Danke, ich werd's gleich umsetzen. Kannst du mir vorher noch sagen, was bei meinem Versuch falsch war? Etwa fehlende Anführungszeichen oder doch mehr? --Leyo 20:17, 28. Sep. 2012 (CEST)

Die Anführungszeichen fehlten mindestens; damit war es nicht eine Zeichenkette mit dem Inhalt "view", sondern ein Symbol für eine Variable mit dem Namen view. 

if (wgNamespaceNumber  >  0   &&
    (wgNamespaceNumber % 2  ===  1   ||
     wgNamespaceNumber  ===  4)   &&
    wgIsArticle   &&
    wgAction === "view"   &&
    wgTitle.indexOf("/") > 0   &&
    !  $('.editsection').length) {
   mw.util.$content.find('h2').not('#toctitle h2').each(
      function(i, el) {
         var $el = $(el);
         $('<span>', { 'class':  ...

Ich habe dir alle Vorbedingungen nach Ressourcenverbrauch sortiert in einem einzigen Term zusammengezogen; außerdem bei jeder Eröffnung einer neuen Stufe ein Stück weiter eingerückt. Schließlich eine Abfrage, ob ein Schrägstrich im Titel steht. Enjoy --PerfektesChaos 23:51, 28. Sep. 2012 (CEST)

Danke! Auch die Abfrage nach dem Schrägstrich ist eine gute Idee. --Leyo 11:01, 29. Sep. 2012 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: Leyo 11:01, 29. Sep. 2012 (CEST)

Vorlagen im Wikitext in JavaScript Objekte "konvertieren" (parsen) um auf Reguläre Ausdrücke verzichten zu können

Hallo, ich bin auf der Suche nach so etwas oder so etwas; nur eben für JavaScript. Gibt es schon eine fertige Lösung? Schreibt jemand eine? Es soll ja häufiger vorkommen, dass man beispielweise "Parameter X der Vorlage Y" gern hätte oder gar den Wert von Parameter Y austauschen würde. Ich bin gespannt. -- RE rillke fragen? 20:01, 26. Sep. 2012 (CEST)

Per API kannst du an den XML parse tree des Preprocessor kommen (action=expandtemplates/parse oder prop=revisions&rvgeneratexml=). Unter Benutzer:P.Copp/scripts/preprocessor.js und Benutzer:P.Copp/scripts/parser.js hat es aber mal ein Benutzer versucht. Das Problem ist, das ganze auch zu warten, da sich ab und an doch mal etwas ändert, entweder am Quelltext oder an den Einstellungen/Lokalisierungen etc. Der Umherirrende 20:12, 26. Sep. 2012 (CEST)
Das ist ja der Hammer. Eigentlich suche ich nur etwas, das aus
== Abschnitt 1 ==
{{Vorlage|Paremeter1}}

== Abschnitt 2 ==
{{Vorlage2|name=Umherirrender}}
etwas wie
page = {
   templates: [{
      name: "Vorlage",
      params: {
         "1": "Paremeter1"
      }
   }, {
      name: "Vorlage2",
      params: {
         "name": "Umherirrender"
      }
   }]
};
macht. Und dabei natürlich <nowikis> und andere Gemeinheiten beachtet. Das sollte recht zügig gehen und ohne API-Anfrage. Dann sollte es mir erlauben die Templates zu manipulieren (Parameter ändern, Vorlagen löschen oder ersetzen) und mir das neue Wikimarkup wieder ausgeben. Sorry für die missglückte Ausdrucksweise. Wer eine bessere Überschrift für diesen Abschnitt weiß, darf sie gern ändern. -- RE rillke fragen? 21:23, 26. Sep. 2012 (CEST)
  • Ich habe einen Vorlagen-Parser in JavaScript.
  • Einen Vorgeschmack erhältst du hier, wobei die Implementierung erheblich weiter ist als ich mit dem Dokumentieren hinterherkomme.
  • Nach einigem Fluchen beherrscht er auch Kommentare innerhalb der Vorlage, nowiki sowieso und auch Vorlagen und Links in der Vorlage.
  • „Wert von Parameter Y austauschen“ ist Routine („change“).
  • Es ist eigentlich bislang nicht so gedacht, dass Nutzer direkt auf das interne Objekt zugreifen, aber für analysierte Vorlagen gibt es ein Objekt, das den Namen der Vorlage kennt, Formatierungsinfos (whitespace) sowie ein Array für jeden Parameter; mit Parameter-Namen oder Nummer und Wert.
  • Du müsstest das aus dem Syntaxbaum greifen.
Soviel als Appetizer. Mehr, sobald ich dein Problem verstanden habe. Jetzt bin ich grad erst onwiki gegangen. --PerfektesChaos 22:06, 26. Sep. 2012 (CEST)
Nicht ganz das, was du willst, aber einfach um es auch mal zu verlinken: Benutzer:Schnark/js/Template --Schnark 09:11, 27. Sep. 2012 (CEST)

Danke. Bei Gelegenheit werde ich u.U. eines der genannten als Bibliothek auf Commons installieren. Diesem RegExp gematche werde damit hoffentlich ein Ende bereiten. -- RE rillke fragen? 11:47, 12. Okt. 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: RE rillke fragen? 11:47, 12. Okt. 2012 (CEST)

Suche nach links

Hallo, bei dem Vector-Skin hatte ich bis jetzt mit Bergis Script die Suche nach links befördert. Seit heute klappt das jedoch nicht mehr. Da Bergi zurzeit inaktiv ist, wollt ich mal hier fragen ob jemand das Script reparieren kann oder weiter weiß.--CENNOXX 16:25, 25. Okt. 2012 (CEST)

Ich habe unter Wikipedia:Fragen_zur_Wikipedia#Position_des_Suchfeldes geantwortet. --Schnark 12:43, 26. Okt. 2012 (CEST)
Danke.--CENNOXX 00:53, 27. Okt. 2012 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: CENNOXX 00:53, 27. Okt. 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)
removeAttribute("maxlength") anstattdessen sollte funktionieren. Ist jetzt kein Bugreport, sondern ein Patch geworden: gerrit:23541 -- ✓ Bergi 21:55, 12. Sep. 2012 (CEST)
Und ich habe dir ein Link dazugeschrieben, da es das ganze schonmal mit attr gab. Vielleicht war es schon damals eine schlechte Idee, oder es ist berechtigt und die Browser reagieren nur blöd? Keine Ahnung, was da richtig ist und was eigentlich der Unterschied bei prop/attr ist. Der Umherirrende 19:17, 13. Sep. 2012 (CEST)
Wobei Krinkle jetzt das ganze Module neu geschrieben hat: gerrit:23771. Der Umherirrende 11:55, 15. Sep. 2012 (CEST)
Durch die Neuimplementierung wurden auch weitere Bugs beseitigt, unter anderem Bug 35560. Durch die Änderung entsteht aber ein neues Problem: Wenn die maximale Eingabelänge größer ist als das sichtbare Eingabefeld, dann wird mit dem Cursor durch das Eingabefeld gescrollt. Wenn nun das die maximale Eingabelänge erreicht ist, dann scrollt die neue Implementierung immer an den Anfang, obwohl der Cursor wo anders steht. Das gleiche Problem besteht bereits jetzt bei der Zusammenfassungszeile, wenn über Sonderzeichenleiste dort Zeichen eingefügt werden. --Fomafix (Diskussion) 14:30, 15. Sep. 2012 (CEST)
Habe mir das nicht so genau angeschaut. Am besten dort kommentieren. Unter mw:Developer access kannst du formlos ein Konto auf Gerrit beantragen. Der Umherirrende 20:43, 15. Sep. 2012 (CEST)
Rewrite gerrit:23771 wurde gemerged.
@Bergi: Kannst dein change abandon, damit er aus der Review Queue fällt. Der Umherirrende 22:08, 5. Okt. 2012 (CEST)


[Zum angefragten Unterschied prop/attr siehe jquery.prop() – tückisch, weil auch noch .val() hinzukommt. LG --PerfektesChaos 14:59, 15. Sep. 2012 (CEST)]

Okay, da steige ich dann aus. Scheint ja nicht so einfach zu sein. Ich hoffe mal, das wird klappen. Gerne dort kommentieren, wenn einem etwas auffällt. Je früher eventuelle Probleme bekannt sind, desto unwahrscheinlicher wird es, das sie hier noch ankommen und Auswirkungen haben. Der Umherirrende 20:43, 15. Sep. 2012 (CEST)


Eine andere Frage wäre noch, wie ich ein bestehendes byteLimit überschreiben könnte? Ich wollte auf action=protect auch ein byteLimit mit callback einbauen, so dass das Freitextfeld dynamisch Zeichen zulässt oder nicht (Je nachdem wie lang der Text im Drop-Down-Menü ist). Das Problem ist nur, das in der protect.js (also dem MediaWiki-JS zu der Seite) bereits ein $( '#mwProtect-reason' ).byteLimit( 180 ); drin steht und ich jetzt nicht weiß, wie ich die 180 übersteuern kann. Kürzer wird wohl gehen, aber wie kann ich 255 Bytes erlauben, wenn nichts in dem Drop-Down ausgewählt wurde? Über Tipps würde ich mich freuen. Vielen Dank. Der Umherirrende 13:59, 28. Sep. 2012 (CEST)

Einfach drübersteuern. Vorherige byteLimit-Listener werden von der Funktion entfernt, d.h. der letzte gewinnt. -- ✓ Bergi 14:52, 28. Sep. 2012 (CEST)
Okay, also für den Fall von action=protect müsste ich ein using auf mediawiki.legacy.protect setzen, damit mein monobook.js auf jedem Fall nach protect.js ausgeführt wird. Auf Anhieb schien das aber nicht zu funktionieren. Muss ich mal weiter versuchen. Danke erstmal. Der Umherirrende 15:21, 28. Sep. 2012 (CEST)
So, mit dem Software-Update auf 1.21wmf2 vom Mittwoch sind ein paar Punkte von hier bereits geklärt und einige Bugs gefixed worden. Leider gibt es auch neue (beispielsweise Bug 41450), aber das sollte auch noch behoben werden. Danke für eure Kommentare. Der Umherirrende 09:32, 27. Okt. 2012 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 09:32, 27. Okt. 2012 (CEST)

Variable an Script übergeben

Ich hab schon vor einiger Zeit an dem englischen Gadget proveit rumgebastelt (Benutzer:Dietzel/proveit-de.js) und versuche, dem Script eine Variable zu übergeben. Also in meine vector.js eine Variable eintragen, die ich dann in dem Script wieder auslesen kann. Ich kriegs nicht hin, irgendwelche Tips? --Dietzel (Diskussion) 21:47, 14. Sep. 2012 (CEST)

Als Emacs-Benutzer bekommst du selbstverständlich jede Unterstützung; nur: Wo sollte für dich ein Problem liegen?
Du kannst ganz normal in vector.js eine Variable setzen; mit
var xyz=7;
window.xyz=7;
Die kannst du auch ganz normal auslesen.
Was dir möglicherweise widerfährt, ist das Problem, dass dein Skript schon asynchron losgerannt ist, bevor du die Variable gesetzt hast? Früher erfolgte ein Import erst nach Beendigung der vector.js, während heutige Browser beides parallel abarbeiten können.
LG --PerfektesChaos 22:06, 14. Sep. 2012 (CEST)
Danke, war ja tatsächlich ganz einfach...
Ich wollte das script mit "Vorschau" testen, gleichzeitig war es über vector.js eingebunden. Kann es sein, dass das zum Testen keine gute Idee ist? --Dietzel (Diskussion) 22:34, 14. Sep. 2012 (CEST)
Man kann auch ohne Seil Bungee-Jumping machen, aber nur einmal: Wikipedia:JS #Testen vor dem Speichern. Warum auch immer das so ist. Gute Nacht --PerfektesChaos 23:38, 14. Sep. 2012 (CEST)
Scheint erledigt zu sein. Der Umherirrende 13:02, 27. Okt. 2012 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 13:02, 27. Okt. 2012 (CEST)

Background-image einbauen

Hallo zusammen, ich habe folgendes Problem: Ich wollte dieses Bild als Hintergrund für meine Links auf dieser Seite einbauen. Versucht habe ich dies per background-image:url(http://commons.wikimedia.org/wiki/File:BG_Links_by_DraGoth.png);background-color:black;background-repeat:repeat-x;background-position:top left; innerhalb eines divs. Angezeigt wurde allerdings nichts. Ich habe es auch mit dem Dateilink http://upload.wikimedia.org/wikipedia/commons/c/c0/BG_Links_by_DraGoth.png versucht, mit dem selben Ergebnis.
Meine Fragen: Klappt das einfach nicht so, wie ich es vorhatte, oder habe ich was falsch gemacht? Wenn letzteres, was? Wie kann ich das so hinbekommen, wie ich es will? Thx in advance -- Holger (DG) Disk • Bew • WPVB 08:42, 30. Okt. 2012 (CET)

URLs werden aus Sicherheitsgründen aus dem Inline-CSS im style-Attribut herausgefiltert. Da gibt es leider keine Möglichkeit. --Fomafix (Diskussion) 09:03, 30. Okt. 2012 (CET)
Ach, verd...! Naja, kann man nix machen. Danke für die Antwort-- Holger (DG) Disk • Bew • WPVB 09:06, 30. Okt. 2012 (CET)
Archivierung dieses Abschnittes wurde gewünscht von: -- Holger (DG) Disk • Bew • WPVB 09:06, 30. Okt. 2012 (CET)

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)
Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 21:10, 2. Nov. 2012 (CET)

Scriptwunsch: Anzeige defekter Weblinks im Artikel, nicht nur auf Diskussionsseiten

Hallo, ich hätte gern ein Skript, durch das ein Hinweis auf der Artikelseite angezeigt wird, wenn die zugehörige Diskussionsseite in der Kategorie:Wikipedia:Defekte Weblinks ist. Vorzugsweise angezeigt direkt über den Kategorien (über Personendaten, wenn vorhanden), gern mit Link auf die Disku., der in neuem Tab öffnet. Das sollte per API-Abfrage nach den Kategorien der zugehörigen Diskussionsseite eigentlich gehen. Das Helferlein BKL-Check (Gadget-bkl-check.js) z.B. fragt die Kategorien aller Artikel ab, die im aktuell angezeigten Artikel verlinkt sind. Müsste wahrscheinlich nur abgespeckt/umgemodelt werden.

Hintergrund: ich sehe manchmal erst nach Bearbeitung eines Artikels, dass auf der Disku. noch Beiträge von Giftbot sind (und will auch nicht immer nachsehen müssen). Wenn ich mich richtig erinnere gab es bei den ganzen Diskussionen um den Giftbot-Lauf auch mehrfach Anfragen, ob (auch) der Artikel kategorisiert werden könnte. Das vorgeschlagene Skript ließe sich vielleicht auch als Gadget anbieten, z.B. per Default an für diejenigen, die die erweiterte Anzeige von Metadaten eingeschaltet haben.

Gruß,-- IvlaDisk. 00:37, 20. Sep. 2012 (CEST)

+1, super Idee! Könnte man vielleicht sogar idealerweise so gestalten, dass jeder defekte Weblink farbig hinterlegt wird.--Mabschaaf 07:19, 20. Sep. 2012 (CEST)
Auf dem Toolserver gibt es Checklinks: tools:~dispenser/cgi-bin/webchecklinks.py. Dort werden Weblinks überprüft. Über das Wikipedia:Helferlein/Toolserver-Integration lässt sich das Tool direkt von den Artikeln aufrufen. Eine Integration in die Artikelanzeige ist es aber nicht. --Fomafix (Diskussion) 08:18, 20. Sep. 2012 (CEST)
Danke, der Hinweis passt, bei mir aber ohnehin eingebunden. Nur ruft man das nicht oft genug auf, und bei Abarbeiten von - anderen - Wartungskats. will ich das auch gar nicht extra aufrufen müssen. Im Moment haben wir ja auch genug frische Meldungen dazu von Giftbot. Allerdings will ich genauso wenig jedesmal auf der Disk. nachsehen.
@Mabschaaf Den Zusatzwunsch hatte ich auch. Ein simples Skript ohne habe ich mittlerweile zusammengeschustert (s.u.), mehr ist bei mir aber gerade zeitlich nicht drin, das könnte bis nächstes Jahr auch so bleiben. -- IvlaDisk. 22:17, 27. Sep. 2012 (CEST)

Es sind zwei verschiedene Aktivitäten:

  1. Gibt es auf der Artikel-Disk zufällig einen unbearbeiteten Bot-Eintrag, der bei mehreren Versuchen eine unerreichbare URL festgestellt hatte; schon gleich mit Direktlink auf archive.org?
  2. Für alle URL: Momentaner Status 404/503, nicht zwingend permanente Unerreichbarkeit, vielleicht auch alte Bekannte aus dem eigenen Themengebiet dabei.
    • Per Wunschknopf Direktverlinkung auf das Tool, Übergabe der momentanen Artikel-ID, Darstellung in einem gesonderten Tab.

Zurück zum Ausgangspunkt: Gute Idee.

  • Allerdings eher Neuprogrammierung; über BKL- und Rechtschreib-Check sind inzwischen zwei bis drei Generationen hinweggegangen, und heute würde man das kompakter und übersichtlicher schreiben können. Hinzu kommt, dass BKL/RS sich mit möglicherweise sehr vielen Links oder Fundstellen / sehr vielen Zielseiten konfrontiert sehen und deshalb kompliziert blockweise abarbeiten, während hier nur eine einzige Seite nach allen Kat befragt wird und danach geschaut wird, ob einem eine davon gefällt. Routinejob.
  • Die Auslösung kann
    • gesondert manuell erfolgen und würde dann eine gute Sekunde später unterhalb der Knöpfe im Bereich der Lemma-Überschrift erscheinen, auch ohne eine Bearbeitung.
    • automatisch jeden Artikel (ANR) beim Öffnen zur Bearbeitung testen und wäre an den URL-Parameter action=edit zu knüpfen; hier würde dann eine Box im Bereich der Speichern-Vorschau-Diff erscheinen.
    • Eine Verlinkung auf den zugehörigen Abschnitt der Disku ist Standard, gleich mit target= beim selbstgeschriebenen HTML-Link.
    • Natürlich mit dazu geeigneter eigener Box und keiner, die unbemerkt nach 5 Sekunden wieder verschwunden ist.
  • Ein Rückgriff auf die Anzeige der defekten Weblinks ist etwas schwieriger; man müsste auf der Artikeldisku die in einem von den Bots in standardisiertem Format abgelegten URL aufnehmen und dann in der Artikel-Vorschau oder view oder WikEd diese URL auchen und farbig hervorheben; das ist dann schon plusplusSahne.

Amüsiert euch --PerfektesChaos 09:28, 20. Sep. 2012 (CEST)

Tja, ich hatte an sich gehofft dass sich jemand die Idee greift, der das anständig programmieren kann. Ich selbst muss bei fast jeder Skript-Zeile irgendwo nachlesen. Dass ich den BKL-Check genannt hatte liegt nur daran, dass ich nur irgendwo abgucken kann, und der fragt halt die API nach Kategorien. Ich habe mir ein relativ simples, immer noch unsauberes Skript gebastelt, das bisher immerhin noch keinen Absturz verursacht hat und die Meldung tatsächlich anzeigt. API nur nach Text-Ausgabe gefragt, weil das für mich leichter zu parsen war als das JSON-Objekt. Dass ich mich mit dem bzw. mw.api nicht auskenne weißt Du ja.
Zu den einzelnen Punkten:
  1. Per API abgefragt, für den möglicherweise vorhandenen Link auf archive.org müsste man die Disk.-Seite parsen, ich habe stattdessen den Link auf die Disku., öffnend in neuem Tab/Fenster. Die Disk-Seite müsste spätestens nach Korrektur im Artikel ohnehin geöffnet werden um die Vorlage von Giftbot rauszunehmen oder den Abschnitt ganz zu löschen (was ich persönlich nicht mag, anderes Thema).
  2. Für alle URL verstehe ich nicht ganz. Alle im Artikel (das wäre das von Fomafix genannte Tool oder Parsen des Artikels), alle gemeldeten (das wäre Parsen der Artikeldisk)? Hab ich nicht und wollte ich im ersten Schritt nicht. Unterpunkt Wunschknopf verstehe ich gar nicht. Direktverlinkung auf welches Tool?
  • Neuprogrammierung: ich brauchte, wie gesagt, einfach was zum Abgucken, habe dann noch an verschiedenen anderen Stellen nachgesehen und dann die für mich simpelste Variante genommen. Routinejob: ja, für Routiniers.
  • Auslösung:
    • Bisher immer, z.Z. nicht im Skript geregelt, sondern bei der Einbindung per vector.js.
    • Für alles im ANR, nach wgNamespaceNumber 0, egal ob Artikelanzeige, Vorschau oder Diff.
    • Oben beim Lemma-Titel, statt wie ursprünglich gedacht bei Normdaten oder Kats.
    • Verlinkung auf Disku-Abschnitt: Giftbot erzeugt zwei verschiedene Überschriften für einzelne bzw. mehrere defekte Links, ich ziele z.Z. nur auf "#Defekter Weblink", andernfalls gehts halt nur oben zur Diskussionsseite.
    • Keine Box, div-Abschnitt, da verschwindet nix.
  • Anzeige der defekten Links im Artikel ist nur mit Abruf der Diskussionsseite zu haben, Giftbots Links sind nicht großartig formatiert, aber einheitlich genug mit li, da könnte man vermutlich alles zwischen Abschnittsüberschrift u. Giftbots Signatur greifen. Nicht ich, nicht jetzt.
Das Skript bestand am vorläufigen Ende nur noch aus für mich verblüffend wenigen Zeilen. Ich habe unten noch eine Anzeige für die Wartungskat. mit defekten Einzelnachweisen rangeklatscht, die kann bei Nichtvorhandensein von Kategorien eine Exception geben, wenn ich mich richtig erinnere. War bisher kein Problem, da Skript nur über ANR lief und Artikel ohne Kats faktisch nur bei Neuanlagen vorkommen. Das muss aber raus. Die Variablen sauen im globalen Namensraum rum, ich weiß das. Müsste bei Benutzung durch andere auch raus.
In für andere Benutzer sicher nutzbare Fassung kann ich das zur Zeit nicht bringen: Zeit, Fähigkeiten etc. Mir wäre es immer noch sehr lieb, wenn sich jemand die Idee – nicht meinen zusammengefrickelten Code – greift.
Unter Umständen sogar verbunden mit dem oben von APPER gewünschten Skript für Wartungslisten. Das passt vom Thema her eigentlich ziemlich gut dazu, muss man aber auch nicht zusammenpacken. Die meiste Arbeit für einen erfahrenen Programierer wären wohl weitere Sonderwünsche, Konfigurationsmöglichkeiten und diverse Anfragen, wenn das von mehr Leuten benutzt würde. -- IvlaDisk. 22:17, 27. Sep. 2012 (CEST)
Fein, das übt.
Zu deiner Nachfrage, was ich mit Für alle URL meinte: Den Unterschied zwischen
  • den speziellen Weblinks, die sich GiftBot vielleicht vor Wochen mal ausgeguckt und mehrfach nicht angetroffen hatte, so wie sie auf der Disku stehen;
  • allen Weblinks, die jetzt im Moment in der Seite stehen und webchecklinks.py usw. übergeben werden.
Zu deinem cat-Problem:
   var catlinks = document.getElementById("catlinks");
   if (catlinks) {
      catlinks.innerHTML.match(/Kategorie:..............
   }
Hattest du ja selbst schon so ähnlich als if(!document.getElementById("giftid")) {
Ein zuverlässiges Werkzeug zur einfachen Anzeige von Fehlermeldungen kann dir Mediawiki im Moment leider nicht bieten; deshalb ist dein Weg mit der firstHeading schon genau richtig.
Schönen Abend --PerfektesChaos 22:46, 27. Sep. 2012 (CEST)

Benutzer:PerfektesChaos/js/defekterWeblinkBotVorlage für den breiten Einsatz. --PerfektesChaos 21:08, 2. Nov. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: --PerfektesChaos 21:08, 2. Nov. 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. --IvlaDisk. 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? --IvlaDisk. 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([6]). 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)
Archivierung dieses Abschnittes wurde gewünscht von: --PerfektesChaos 22:24, 9. Nov. 2012 (CET)

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, [7] funktioniert bei mir (FF3), bis auf:
--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)
Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 13:56, 9. Nov. 2012 (CET)

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)
Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 13:55, 9. Nov. 2012 (CET)

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)
Archivierung dieses Abschnittes wurde gewünscht von: --PerfektesChaos 13:48, 9. Nov. 2012 (CET)

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 Wikipedia: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)
Doku-Anpassung noch notwendig, sondern bringt das Feature nicht so viel, weil die Benutzer es wieder ausbauen könnten. Das sollte der Anfrage-Steller machen oder jemand anders, aber ich schreib es eh nicht gut, daher habe ich das bis jetzt nicht gemacht und werde es auch wohl nicht machen. Der Umherirrende 13:01, 27. Okt. 2012 (CEST)
So geschehen. --PerfektesChaos 20:56, 2. Nov. 2012 (CET)
Archivierung dieses Abschnittes wurde gewünscht von: --PerfektesChaos 13:50, 9. Nov. 2012 (CET)

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)
Ich werde dieses Skript weder in meinen BNR aufnehmen, noch dokumentieren, noch testen, noch erweitern. Wer damit was macht, ist mir vollkommen egal. --Schnark 10:07, 26. Sep. 2012 (CEST)
/**
 * Konfiguration mit
   mw.user.options.set('wartungslisten', [
    'Wikipedia:PND/Fehlermeldung/*'
   ]);
 * in [[Spezial:Meine Benutzerseite/common.js]]
 * Möglich sind * und ? als Wildcards,
 * alternativ können auch reguläre Ausdrücke angegeben werden
 */

(function ($, mw) {
"use strict";
var regEx = [];
function filter (titel) {
	for (var i = 0; i < regEx.length; i++) {
		if (regEx[i].test(titel)) {
			return true;
		}
	}
	return false;
}
function anzeige (seiten) {
	var	html = '<p>Diese Seite ist auf ' +
		(seiten.length === 1 ? 'einer Wartungsliste' : seiten.length + ' Wartungslisten') +
		' eingetragen:</p><ul>' +
		$.map(seiten, function (titel) {
			return	'<li>' +
					mw.html.element('a', {href: mw.util.wikiGetlink(titel)}, titel) +
					'</li>';
		}).join('') +
		'</ul>';
	$(function() {
		mw.util.$content.prepend($.parseHTML(html));
	});
}
function fehler (meldung) {
	mw.util.jsMessage(meldung);
}
function apiQuery () {
	$.getJSON(mw.util.wikiScript('api'), {
		action: 'query',
		list: 'backlinks',
		bltitle: mw.config.get('wgTitle'),
		blnamspace: '2|4|100', //Benutzer:, Wikipedia:, Portal:
		blfilterredir: 'nonredirects',
		bllimit: 'max',
		format: 'json'
	}, function (json) {
		var wartungsseiten = [], i;
		if (json && json.query && json.query.backlinks) {
			for (i = 0; i < json.query.backlinks.length; i++) {
				if (filter(json.query.backlinks[i].title)) {
					wartungsseiten.push(json.query.backlinks[i].title);
				}
			}
		}
		if (wartungsseiten.length) {
			anzeige(wartungsseiten);
		}
	});
}
function init () {
	var liste = mw.user.options.get('wartungslisten', []), i;
	if (liste.length === 0) {
		fehler('Du hast keine Wartungslisten konfiguriert!');
		return;
	}
	for (i = 0; i < liste.length; i++) {
		if ($.type(liste[i]) === 'regexp') {
			regEx.push(liste[i]);
		} else {
			regEx.push(new RegExp(
				'^' + $.escapeRE(liste[i])
					.replace(/\\\*/g, '.*')
					.replace(/\\\?/g, '.') + '$'
			));
		}
	}
	apiQuery();
}

if (mw.config.get('wgNamespaceNumber') === 0 && mw.config.get('wgAction') === 'view') {
	mw.loader.using(['mediawiki.util', 'jquery.mwExtension', 'user', 'mediawiki.user', 'user.options'], init);
}

})(jQuery, mediaWiki);
Danke. Funktioniert super! --APPER\☺☹ 12:54, 28. Sep. 2012 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: Schnark 11:03, 9. Nov. 2012 (CET)

MediaWiki CodeMirror Syntax Highlighting

Hallo, ich bin kürzlich über http://mwcodemirror.sourceforge.net/ des inaktiven Benutzer:JovanCormac gestolpert. Kann jemand aus dem existierenden CSS/JS ein Helferlein basteln? Ich weiß nicht wo ich anfangen soll um es in Gang zu setzen. Nachdem jemand es in MediaWiki portiert hat, würde ich gerne weitere Syntaxhervorhebungen (Einzelnachweise, Vorlage, ...) einbauen. Gruß Matthias (Diskussion) 11:56, 5. Okt. 2012 (CEST)

Dieses Skript hat das Problem, dass es nicht mit anderen Skripten kompatibel ist, die den Text in der textarea erwarten, genau wie das bei WikEd der Fall ist, wo schon üble Verrenkungen notwendig sind, um überhaupt die normale Werkzeugleiste nutzen zu können.
Ich verwende im Augenblick m:User:Remember the dot/Syntax highlighter, das diese Probleme nicht hat (dafür etwas langsam und unvollständig ist), wobei ich diese beiden Probleme (ohne bzw. mit mäßigem Erfolg) gerade versuche zu beheben, siehe en:User:Schnark/vector.js. --Schnark 12:08, 5. Okt. 2012 (CEST)
Nachtrag: Ich habe mal aus Neugierde getestet, wie die oben verlinkte Seite auf en:Barack Obama (der ultimative Parsertest) reagiert: Recht langsam, etwas mager, Verschachtelungen (Links innerhalb von Bildern, aber auch verschachtelte Tabellen) funktionieren gar nicht. --Schnark 12:17, 5. Okt. 2012 (CEST)
Nachtrag 2: Es ist durchaus möglich, das Ding zu integrieren, für JS/CSS gibt es das schon: Wikipedia:Technik/Skin/JS#Code Editor Hat aber wie gesagt den entscheidenden Nachteil, das Skripte, die $('#wpTextbox1').val() auslesen, den ursprünglichen Text bekommen und dann nicht funktionieren. Außerdem hat das Gadget es auf mw: gleich auf Anhieb geschafft, meinen Firefox zum Absturz zu bringen. --Schnark 12:52, 5. Okt. 2012 (CEST)
Stimmt, sowohl http://mwcodemirror.sourceforge.net/ als auch m:User:Remember the dot/Syntax highlighter brechen völlig zusammen wenn man Riesen-Artikel editiert. Die norwegische Wikipedia hat den CodeEditor auf MediaWiki umgebaut: no:Hjelp:AceWikiEditor (Google Translate). Er schafft den Stresstest en:Barack Obama und er lässt sich in der Toolbar abschalten. Ich werde versuchen ihn zu übersetzen und hier als Gadget vorzuschlagen. Gruß Matthias (Diskussion) 13:30, 5. Okt. 2012 (CEST)
So, ich habe es gleich mal umgesetzt und unter Wikipedia:Technik/AceWikiEditor dokumentiert und bei MediaWiki Diskussion:Gadgets-definition#AceEditor vorgeschlagen. Gruß Matthias (Diskussion) 15:36, 5. Okt. 2012 (CEST)
Also ich komme jetzt mit meinem Skript bei Herrn Obama manchmal auf 70 Millisekunden runter.
Auch die no-Variante kommt mit Verschachtelungen nicht zurecht. --Schnark 10:22, 6. Okt. 2012 (CEST)
Solange es nicht lagged während man etwas eingibt wäre mir persönlich die Ladegeschwindigkeit egal und ein Knopf zum Abschalten in der Toolbar-Leiste wäre praktisch. Gruß Matthias (Diskussion) 13:15, 6. Okt. 2012 (CEST)
Ein weiteres Problem des AceEditors: Die Rechtschreibprüfung wird deaktiviert. Mein Skript kommt langsam auf Zeiten, bei denen man vernünftig arbeiten kann, wenn ich es dann noch schaffe, all die komischen Bugs zu entfernen, die es noch hat, kann man es vielleicht sogar verwenden. --Schnark 10:31, 8. Okt. 2012 (CEST)
Für den experimentierfreudigen (dass ein wenig Experimentierfreude von Nöten ist, zeigt dieser Absatz, dem ich zur korrekten Darstellung eine Leerzeile vorangehen lassen musste) Benutzer: Benutzer:Schnark/js/syntaxhighlight. --Schnark 09:52, 9. Okt. 2012 (CEST)
Gefällt mir persönlich besser, da die Rechtschreibprüfung erhalten bleibt und der AceWikiEditor jedes Leerzeichen hervorhebt dafür aber die Zeilenumbrüche vermurkst. Es ist nur nervig lange Artikel damit zu bearbeiten vor allem da es sich offenbar erst im Notfall abschaltet, nicht wenn schon die Eingabe merklich verzögert wird. Gruß Matthias (Diskussion) 11:52, 9. Okt. 2012 (CEST)
Die Funktion zur Syntaxhervorhebung wird pauschal zwei Mal pro Sekunde aufgerufen, und schaltet sich ab, wenn sie länger als 150 Millisekunden braucht. Bei mir ist das recht flüssig (jedenfalls so flüssig wie ein portabler Firefox auf einem lahmen USB-Stick sein kann), sofern ich nicht gerade Deutschland als Ganzes bearbeiten will. An den einzelnen Werten kann man natürlich noch rumspielen, um ein besser ausgewogenes Verhältnis zwischen flüssigem Arbeiten und hervorgehobenem Text zu haben, vielleicht sogar einen abgespeckten Parser (der dann hoffentlich schneller ist) für lange Artikel.
Was für einen Browser verwendest du? --Schnark 12:12, 9. Okt. 2012 (CEST)
Firefox 15.0.1 ohne USB-Stick. Abschnittsweise editieren ist sehr flüssig. Escherichia coli geht noch, aber es laggt merklich. Ist mir aber egal, da ich gerade das Häkchen zum manuellen abschalten gefunden habe. :) Gruß Matthias (Diskussion) 12:24, 9. Okt. 2012 (CEST)
Wenn man nicht gerade die Struktur umkrempelt, dann bearbeitet man ja solche Artikel abschnittsweise, wo es dann wieder flüssig läuft. Ich werde aber mal den Artikel als Beispiel nehmen, um zu sehen, ob ich mit anderen Parametern mehr rausholen kann.
Das Kontrollkästchen ist ein bisschen versteckt, aber ich wollte mir keine Gedanken über alte, neue oder gar keine Werkzeugleiste machen müssen.
Ich weiß übrigens nicht, wie sich mein Skript mit der Syntaxhervorhebung für JS/CSS verträgt, auf den Seiten ist es nämlich (natürlich mit anderem Parser) auch aktiv. --Schnark 12:34, 9. Okt. 2012 (CEST)
Lass doch die Syntaxhervorhebung für JS/CSS weg. Dafür kommt doch bald offiziell Brions CodeEditor. Ansonsten ist mir aufgefallen, dass der Abschaltmechanismus nicht zuverlässig funktioniert. Bei mir ruckelt es weiter und es wird weiter unvollständig hervorgehoben. Das automatische Abschalten halte ich auch für unnötig, da du den Haken eingebaut hast. Die Platzierung halte ich für geeignet. Eventuell sollte man in der Dokumentation einfach deutlicher darauf hinweisen. Gruß Matthias (Diskussion) 14:50, 9. Okt. 2012 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: Matthias (Diskussion) 14:40, 9. Nov. 2012 (CET)

ChemDoodle

Ist es möglich http://web.chemdoodle.com in MediaWiki zu integrieren, damit es zum Beispiel http://web.chemdoodle.com/demos/pdb-ribbons in einer Infobox anzeigt? Gruß Matthias (Diskussion) 18:06, 11. Okt. 2012 (CEST)

Wenn wir nicht mal einen Renderer für einfache Strukturformeldateien bekommen, glaube ich nicht, dass sich die Devs überzeugen lassen diese Anwendung, die aus einer Serverkomponente (Konvertieren der Dateien etc.) und Client-Komponenten, die HTML 5, Canvas, … erfordern, zu installieren. Abgesehen davon, scheint es kein SVG Export zu unterstützen? Wie sollen die Bilder dann in den Artikel kommen? Canvas? Schön ist allerdings, dass es jQuery verwendet, GPL lizenziert ist und intuitiv bedienbar ist. Auf jeden Fall brauchen wir einen Strukturformeleditor. Ich würde mich trotz meiner schlechten Prognose auch dafür einsetzen. Und wenn es vorerst nur Labs-Tool wird. -- RE rillke fragen? 11:44, 12. Okt. 2012 (CEST)
Ich dachte man könnte ein Helferlein draus basteln, weil dort steht, dass es pures JavaScript ist. Für die interessanten Sachen bei dem Editor wie SVG-Export muss man aber Support einkaufen glaube ich und MOL-Dateien einbinden ist alles andere als intuitiv. Ich hätte gedacht für PDB wäre es brauchbar. Okay, war nur so eine Idee. Einen Wikipedia Strukturformeleditor werden wir bald mit http://toolserver.org/~ayacop/EditorApplet.html lösen. Gruß Matthias (Diskussion) 18:19, 12. Okt. 2012 (CEST)
Das "reine JavaScript"+HTML5 bezog sich nur auf die Client-Komponente. Wenn man sich das Paket herunterlädt und den Editor testet, erhält man:

Your domain is not registered to use these services. Please contact iChemLabs to register. http://www.ichemlabs.com.

Wenn man beispielsweise versucht etwas zu speichern.

Theoretisch könnte man den Web-Service aber auch kostenlos nutzen: „ChemDoodle Web Components has built in access to the entire ChemDoodle desktop API through AJAX XMLHttpRequest Level 2 (XHR2) calls to our server. XHR2 requires that our servers recognize your origins (domains). If you are an academic or non-profit organization, we will provide free access to our server resources. Just contact us to register your origins with our server.“

Bräuchte also nur einer anzufragen ;-)


Die Darstellung von z.B. Molfiles, PDB funktioniert. Die Client-Komponenten sind wie folgt ausgestattet:

  • readCIF
  • readJCAMP
  • readMOL
  • readPDB
  • readXYZ
  • writeMOL

Natürlich müssten die Dateien irgendwo gespeichert werden und auch abrufbar sein (upload.wikimedia.org setzt immer noch keine CORS headers). Bleibt eigentlich nur sie direkt in den Artikel einzubetten oder raw irgendwo in der Wikipedia zu speichern. Und das wird schnell unübersichtlich. Gibt es bessere Vorschläge? -- RE rillke fragen? 21:47, 12. Okt. 2012 (CEST)

Dennoch finde ich es nicht attraktiv auf einen Freeware Service eines kommerziellen Anbieters angewiesen zu sein. Vor allem wird die Darstellung bei Forks und Mirrors dann nicht funktionieren. Die Alternative heißt en:Wikipedia:Using Jmol to display molecular models und ist jetzt seit 6 Jahren in Entwicklung. Ich glaube nicht, dass ich das noch zu Lebzeiten miterleben werde. Gruß Matthias (Diskussion) 23:23, 12. Okt. 2012 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: Matthias (Diskussion) 14:41, 9. Nov. 2012 (CET)

Benachrichtigung zu Importen

Benutzer:✓ ist zur Zeit etwas inaktiv, deshalb frage ich hier mal nach (Benutzer_Diskussion:✓#Arbeit_f.C3.BCr_Dich). Er hat damals für mich das verlinkte Script erstelt - es gibt hier ja sicherlich Leute, die verstehen, wie es funktioniert ;-) Weiß also jemand, ob man so eine Benachrichtigungsfunktion einabuen kann und wenn ja wie? Oder evtl. eine separates Script? Grüße --Brackenheim 18:48, 27. Nov. 2012 (CET)

Grundsätzlich ja; das geht alles.
Hilfreich wäre, wenn du für uns etwas näher beschreiben würdest, was „so etwas“ präzise ist. Derjenige, der mal den Importwunsch geäußert hatte, soll auf seine Disku einen Abschnitt geschrieben bekommen, richtig?
Wobei sich mir die Frage stellt, ob du davon Gebrauch machst, dass seit Mitte des Jahres die anfragenden Benutzer das Zeugs als Unterseite ihrer eigenen Benutzerseite hineingeschrieben bekommen. Damit wäre ja nicht nur klar, wie die Seite heißt, sondern auch wer sie sich gewünscht hat.
Diesem Benutzer eine Standard-Meldung auf die Disku zu schreiben, damit er mitbekommt, dass er jetzt eine Unterseite mehr hat (die er ja noch nicht beobachtet haben kann), ist für Routiniers nicht sooo schwierig, wenn man die Namen von Benutzer und Datei kennt. Vielleicht macht Schnarks autoanträge sowas nebenbei.
Mir persönlich ist bloß gerade der Arbeitsablauf nicht so ganz klar.
LG --PerfektesChaos 19:12, 27. Nov. 2012 (CET)
Der Ablauf wäre eigentlich ganz einfach: Bei Wikipedia:IMP erscheint ja dank Bergis Script neben „Bearbeiten“ noch „Löschen“. Daneben sollte dann noch so etwas wie „Benachrichtigen“ stehen. Wenn man dann da drauf klickt, bekommt der Antragsteller eine Nachricht, dass der Artikel gleich auf die von im als Ziel verlinkte Seite importiert wird. Das Problem dabei ist, dass die Nachricht dann schon vor dem Import kommt, aber dafür ist es so glaube ich einfacher, oder? Wenn das Script auch noch für Wikipedia:IU funktionieren würde, wäre es natürlich noch besser ;-) Gruß, --Brackenheim 20:43, 27. Nov. 2012 (CET)
  • Zwischen IU und IMP besteht auf Ebene der Analyse wohl kein dramatischer Unterschied; genauer: Keiner.
  • Die Teile sind ja sehr strukturiert aufgebaut; Nachrichtenknopf wenn die enthalten
    *'''Ziel''': [{{fullurl:Benutzer:***/
  • Wenn Nachimport, dann keine BNR-Seite zu detektieren, dann auch kein Nachrichtenknopf.
  • Für erfahrene Programmierer pure und öde Routinearbeit; leider habe ich davon etliche auf Schlange.
  • Was ich noch nicht verstanden hatte: Auf welchem Weg gelangt das denn in das Import-Formular hinein? Nur mit Benutzer:Brackenheim/importwünsche-entfernen.js das hinterher zu entfernen ist ja trostlos. Eine Komplettlösung würde heißen:
    • Mache zu diesem IMP/IU-Abschnitt parallel ein Browser-Tab mit dem Import-Formular auf.
    • Fülle das Import-Formular mit den detektierten Infos aus.
    • Schreibe dem Benutzer, so einer gefunden werden kann, eine Nachricht auf die Disku, dass er schon mal anfangen kann, sich zu freuen. Wenn nichts kommt, solle man sich nochmal melden.
    • Markiere den IMP/IU-Abschnitt als erledigt.
    • Gibt es sowas schon?
  • Wie lange dauert denn so eine Aktion von Start-Klick bis neue Seite abgespeichert?
VG --PerfektesChaos 21:16, 27. Nov. 2012 (CET)
Ok, ich glaub, ich komme jetzt nicht mehr so ganz mit - ich versuch es einfach mal... Der Unterschied zwischem IMP und IU bezieht sich zum einen auf die Größe der Versionsgeschichte, zum anderen können auf IU alle Sprachversionen importiert werden. Strukturiert sind beide Seiten oder sollten es zumindest sein ;-) Deine Idee, dass bei einem Nachimport der Nachrichtenknopf weggelassen wird, finde ich super! Hatte gar nicht daran gedacht bzw. es für zu kompliziert gehalten. Öde Routinearbeit - naja, ich werde mich einfach freuen, wenn es klappt =) Mit dem importwünsche-entfernen.js erscheint die Löschen-Funktion auf der IMP-Seite, mit der man den betreffenden Abschnitt halbautomatisch entfernen kann; war mir igendwann mal zu langweilig, alles immer "von Hand" löschen zu müssen. Dieses Script und Benutzer:DerHexer/importartikel.js (fügt die Vorlage:Importartikel hinzu und klammert Kategorien bzw. Interwikis aus) sind die einzigen, die es für die Import-Arbeit gibt. Der Rest ist alles Handarbeit... Meinst Du mit Dauer der "Aktion von Start-Klick bis neue Seite abgespeichert" wird, den Zeitraum, vom Klicken, dass man anfngt, bis der Import bzw. die Seite fertig ist? Wenn ja, ist es schwierig zu beantworten: Hängt z. B. von der Anzahl der zu importierenden Versonen bzw. von deren Größe ab. Da es bei IMP oft unter 300-400 Versionen sind, geht es hier in der Regel recht schnell, eigentlich fast immer unter einer Minute, bis alles fertig ist. Bei IU dauert es manchmal länger, sofern es über ca. 600-700 Versionen sind. In so einem Fall wäre es dann doch besser, den entsprechenden Benutzern erst dann Bescheid zu geben, wenn der Import wirklich fertig ist. (Ich habe mal einen Import von 1.000 Versionen mit ca. 73 MB über den ganzen Tag verteilt, da sich WP ständig aufgehängt hat...). Solche Fälle sind jedoch eher aine Ausnahme. Ok, ich hoffe mal, das beantwortet Deine Fragen auch - sonst bitte weiterfragen ;-) Gruß, --Brackenheim 22:59, 27. Nov. 2012 (CET)
Das Skript vom Hexer liefert wieder einen fehlenden Baustein in meinem Weltbild.
Da ich kein Admin bin, habe ich die Aktion noch nie gesehen.
Für den Fall des mehrstündigen Transfers müsste man eigentlich in den IW-Abschnitt einen Stempel drücken: Import wurde gestartet am ... um ... durch ... und läuft länger; ansonsten Erle plus ggf. gleichzeitige Benutzerbenachrichtigung bei Quickies.
Eine Frage bleibt offen: Auf welche Weise gelangen die Informationen über Benutzernamen und Quellenseite in das Formular (Spezialseite) zum Ausführen des Imports?
--PerfektesChaos 23:17, 27. Nov. 2012 (CET)
Damit man es sich besser vorstellen kann: Eine Änderung durch das Script vom Hexer sieht z.B. so aus.
Wenn man einen Importantrag bei IMP stellt, wird das Formular über Wikipedia:Importwünsche/preload eingebunden. Diese Vorlage wiederum kopiert beim Abspeichern dann die ganze Vorlage von Wikipedia:Importwünsche/Wunsch bzw. die restlichen Parameter. Bei IU ist es dementsprechend: Wikipedia:Importwünsche/Importupload/preload. Gruß, --Brackenheim 06:46, 28. Nov. 2012 (CET)
Jein. Ich meinte diese Spezialseite.
Frage: Auf welche Weise gelangen zurzeit die Informationen von der Seite WP:IMP in die Formularfelder?
Thesen:
  • Von WP:IMP aus wird ausschließlich der zweite Block (Transwiki-Import) bedient.
  • „Alle Vorlagen einschließen“ wird beim Standard-Import aus WP:IMP nie benötigt.
Wenn ich oder jemand anders sich programmierend mit der Angelegenheit beschäftigt, dann sollte es ein Minimum an Spaß machen. Flickwerk ist öde.
Liebe Grüße --PerfektesChaos 09:29, 28. Nov. 2012 (CET)
Achso, Du meinst, wie die Angaben auf die Import-Spezielseite kommen? Alles copy & paste von der Antragsseite ;-) Und richtig: Transwiki-Import ist für IMP, „Alle Vorlagen einschließen“ sollte auf de.wiki nicht verwendet werden, da es sonst ein großes Chaos gibt. Grüße --Brackenheim 17:45, 28. Nov. 2012 (CET)

Na, dann schreibe ich mal auf, wie ich mir den Arbeitsstil vorstelle. Individuelle Varianten sind über Konfigurationsparameter realisierbar.

  • WP:IMP und WP:IU sind gleichwertige Ausgangspunke.
    • Detail-Unterschiede wären noch zu konkretisieren.
  • Wenn man WP:IMP/WP:IU normal anguckt, werden alle Links auf Abschnittsbearbeitung so umgelenkt, dass immer ein neues Browser-Tab/Fenster aufgemacht wird.
  • Wenn man eine Abschnittsbearbeitung öffnet, erscheint oberhalb des Bearbeitungsfeldes eine Reihe von Knöpfen/Links:
    [Starten] [✓] [Seite anpassen] [✓] [Benutzer informieren] [✓] [Erledigt.] [Löschen]
  • [Starten] öffnet die Spezialseite; in einem anderen Browser-Tab/Fenster, aber immer in demselben.
    • Nur der Transwiki-Import ist sichtbar (IMP). Und umgekehrt nur der obere Block bei IU? Das Kästchen „Alle Vorlagen einschließen“ ist deaktiviert.
    • Die Daten aus der zuletzt geöffneten Abschnittsbearbeitung wurden in die entsprechenden Formularfelder geschrieben.
  • [Seite anpassen]
    • Wäre nach abgeschlossenem Import anzuklicken; nur WP:IMP?
    • Die Benutzer-Unterseite wird angefasst, an die deWP angepasst und gespeichert. (API)
  • [Benutzer informieren]
    • Auf die Disku des involvierten Benutzers wird eine Abschlussmeldung geschrieben. (API)
  • [Löschen]
    • Alternative zur Archivierung. Kritisch, wenn mehrere Prozesse gleichzeitig ablaufen. (API) (nur IMP?)
  • Die Häkchen [✓] schreiben an das Ende der Abschnittsbearbeitung eine Zeile mit Logbuchvermerk und Zeitstempel zum Zeitpunkt des Anklickens; setzen auch den BK.
    • Import gestartet. 2012-11-28 21:38 ~~~
    • Seite angepasst. 2012-11-28 21:41 ~~~
    • Benutzer informiert. 2012-11-28 21:42 ~~~
    • {{Erledigt|1=~~~~}} sowie am Ende der Abschnittsüberschrift (erl.) (nur IU?)
  • Wenn die Sache innerhalb von ein paar Minuten abgegessen ist, kann man das Fenster mit der Abschnittsbearbeitung offenlassen und in einem Aufwasch archivieren/löschen. Wenn es sich zieht, nach dem [Starten] speichern/schließen; die Kollegen kennen den Zwischenstand. Wenn man Multitasking macht, kann man sich notfalls in das geöffnete Fenster die Stempel drücken, damit man weiß, wo man schon wie weit gekommen war. Die letzten Schritte folgen aber ohnehin dicht aufeinander.
  • Wenn die Spezialseite geöffnet wurde, ohne dass die letzte vorangegangene Aktion das Anklicken von [Starten] war, sind die Formularfelder leer und die Seite ist im Normalzustand.

So in etwa? --PerfektesChaos 21:24, 28. Nov. 2012 (CET)

Hört sich echt gut an! Auf ein paar Kleimigkeiten sollte man allerdings noch achten: Die Abschnitte sollten nur bei IMP gelöscht werden, da hast du Recht. Bei IU sollte das (erl.) immer in die Abschnittsüberschrift; {{Erledigt|1=~~~~}} kann nur bei Nachimporten im ANR gleich hingesetzt werden, sonst nicht, da die Abschnitte erst archiviert werden sollen, wenn der fertige Artikel im ANR ist. Gruß, --Brackenheim 21:52, 28. Nov. 2012 (CET)


Übertragen nach /Baustellen/importUtility.

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 23:46, 28. Nov. 2012 (CET)

Script funktioniert nicht überall

Hallo. Ich habe gestern das Script [8] erstellt und dabei dort per mw.loader.load das Script [9] 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 Benutzer: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)


Nach fast einem Jahr offenkundig erledigt.

Archivierung dieses Abschnittes wurde gewünscht von: --PerfektesChaos 21:17, 23. Dez. 2012 (CET)

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)


Offenkundig erledigt.

Archivierung dieses Abschnittes wurde gewünscht von: --PerfektesChaos 21:20, 23. Dez. 2012 (CET)

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)


Scheint erledigt zu sein.

Archivierung dieses Abschnittes wurde gewünscht von: --PerfektesChaos 21:05, 30. Dez. 2012 (CET)

CSS-Gadget Schriftgröße

Für angemeldete Benutzer mit Sehschwierigkeiten.

Unsere Skins verkleinern die Normalschrift, so dass sie dann nicht mehr gelesen werden kann:

  • monobook 95% und 90%
  • vector 80% (#bodyContent)
  • modern ? (#mw_main=130% [???] Kann nicht sein.)

Untaugliche Ratschläge:

  • Standard-Schriftgröße des Browsers erhöhen – dann sind alle anderen Websites zu groß, haben zu kurze Zeilen und von denen zu wenig.
  • Bei jedem Besuch einer Wiki-Seite auf Strg++ drücken.
  • Triviallösung, aber möglicherweise Überschriften einebnend:
* { font-size: 100% !important; }
  • MySkin ist betreffend Schriftgröße wohl passend, aber schon in der Schriftart arg reduziert, erst recht hinsichtlich Portal-Layout und Seitengestaltung bis zur Link-Unterstreichung.

In den Prefs haben wir Lesehilfen. Ziel ist es, die Seiten so auszustatten, dass sie im Regelfall nicht unter 100% dargestellt werden, wenn Benutzer dies bewusst als noch gut lesbare Schriftgröße eingestellt haben.

Wie müsste ein Browser-sicheres CSS-only-Gadget aussehen, das für alle aktuellen Skins gilt?

  • Seiteninhalt und Portal 100% Browser-Standard
  • H1,H2,H3 und BIG vergrößert
  • SMALL, Bildlegende und REF-Inhalt auf 100%
  • SUB, SUP und REF-Zeichen verkleinert, ma non troppo?
  • Sonstiges? CODE, Vorlage:FN , Infoboxen, Scan MediaWiki:Common.css

Weltweiter Einsatz; enWP hat noch nix, auch keine weiteren Gadgets/accessibility außer diff-Farben?

Heute verbessern wir mal die Welt --PerfektesChaos 10:54, 18. Sep. 2012 (CEST)


Archivierung dieses Abschnittes wurde gewünscht von: --PerfektesChaos 12:34, 6. Jan. 2013 (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)
Archivierung dieses Abschnittes wurde gewünscht von: TMg 20:03, 10. Jan. 2013 (CET)

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;
}
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: [10]. 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: Wikipedia: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)
Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 11:51, 28. Apr. 2013 (CEST)

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

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

Archivierung dieses Abschnittes wurde gewünscht von: --PerfektesChaos 21:22, 14. Sep. 2013 (CEST)

Wikipedia:WikiProjekt HTML5

Dort können sich Benutzer melden, welche bei der Umsetzung von HTML5 hier in der WP mitmachen wollen. ÅñŧóñŜûŝî (Ð) 16:02, 29. Sep. 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --PerfektesChaos 21:22, 14. Sep. 2013 (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 [11] (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)
Und nun gibt es CORS; sogar aktiv für Commons. Nur diesen blöden origin-parameter darf man nicht vergessen. -- RE rillke fragen? 22:34, 13. Sep. 2012 (CEST)

In Schritt 3 müsste noch klar gemacht werden, dass der Hintergrund das Bildschirmfoto ist. Den roten Rahmen übersieht man sonst leicht. Ansonsten ist das Bearbeiten noch verwirrend:

  • Wie geht der Farbwähler wieder zu (nochmal den Button klicken, sollte aber auch bei Klick irgendwo anders hin zu gehen)?
  • Wenn ich ein Rechteck gezeichnet habe und dann einen Mauszeiger einzeichnen will, verschwindet die Strichlinie nicht; der Cursor ist immernoch das Kreuz. Wenn man zuerst das Verwischen Werkzeug und dann ohne zu zeichnen das Rechteck Werkzeug wählt und dann den Rahmen zeichnet…

Schritt 4: Es sollte beim Dateinamen auch positives Feedback geben: „Du kannst diesen Dateinamen verwenden“. Wenn Du Lust hast, kannst Du ihn noch gegen unsere Titleblacklist und gegen Hochlade-und Erstellungsgeschützte Seiten (z.B. File:Startseite.jpg, leider kein PNG gefunden) testen.

Ad Optionen: Wikipedia-Logo sichtbar → Bitte beantworte noch folgende Fragen:

  • Das Wikipedia-Logo ist im Screenshot sichtbar
  • Im Screenshot ist Text sichtbar
  • Ein Bild ist im Screenshot sichtbar. Angaben zum Bild:

Nach einem Wechsel von lokal zu Commons sollten diese Optionen nicht zurückgesetzt werden.

Vorschau: Parsen geht mal schnell, mal dauert es länger. Es sollte angezeigt werden, dass das Script auf den Server wartet, um zu verhindern, dass mehrmals auf "Vorschau zeigen" geklickt wird. -- RE rillke fragen? 22:34, 13. Sep. 2012 (CEST)

Seit CORS aktiviert ist, verwendet das Skript dies für den Commons-Upload.
Schritt 3: Du darfst gerne Textvorschläge machen, die das klarer stellen, Platz genug ist, da Dialogfelder aus irgendeinem Grund overflow: hidden; haben und es wegen des Farbwählers also ohnehin so groß sein muss.
Der Farbwähler schließt sich im Augenblick nur mit einem zweiten Klick auf den Button. Andererseits stört es in meinen Augen auch nicht so sehr, wenn er offen bleibt.
Die Werkzeuge lassen sich, wenn sie einmal aktiviert sind, alle nicht mehr abbrechen, was zu etwas komischen Effekten führt. Ich schau mal, was sich da machen lässt. Ein Problem mit Mauszeiger nach Rechteck kann ich nicht feststellen, bei mir verschwindet der gestrichelte Rahmen nach dem Zeichnen, der Cursor wird wieder normal.
Schritt 4: Da ich eben nicht alles prüfe, will ich lieber einfach nur keine negative als eine möglicherweise falsche positive Rückmeldung geben. Den Schutzstatus könnte ich noch zusätzlich abfragen, aber für die Titleblacklist bräuchte es eine zusätzliche API-Anfrage, die will ich mir und dem Server ersparen. Zudem gibt es Dateinamen, die zwar verboten sind, für die aber meines Wissens keine Möglichkeit besteht, dies über die API zu erfragen, und nur sehr mangelhafte Dokumentation. Dies betrifft mindestens Schrägstriche im Dateinamen (die könnte ich noch so testen), könnte aber je nach Konfiguration bzw. Betriebssystem auf dem Server auch alle Nicht-ASCII-Zeichen betreffen (für Wiki(p|m)edia irrelevant, aber ich will niemandem Probleme machen, der das Skript irgendwo anders verwenden will), zudem existiert vermutlich eine undokumentierte Lägenbegrenzung, die kürzer ist als bei normalen Seiten.
Beim Wechsel des Upload-Ziels müssen zumindest die meisten Texteingabefelder zurück- bzw. neu gesetzt werden. Dass dabei auch die Checkboxen ihren bisherigen Wert verlieren, ist unschön, das werde ich ändern, aber viel besser macht es das auch nicht.
Vorschau: Irgendwelche Vorschläge, wo die Anzeige erfolgen sollte, dass man zu warten hat? Nach dem Klick auf "Hochladen" sollte wohl auch eine Anzeige erfolgen, dass im Hintergrund noch etwas passiert. --Schnark 10:01, 14. Sep. 2012 (CEST)
Vorschau: Auf Commons benutze ich entweder blockUI auf dem Dialog, das die Aktion ausgelöst hat oder öffne den 2. Dialog modal und zeige dort einen Throbber, solange etwas lädt. Den $.createSpinner gibt's demnächst auch in groß.
Titelvalidierung (aus Flinfo (von Lupo und Flominator) geklaut):
      uncleanName = uncleanName.replace(/~{3,}/g, '')
         .replace(/\s+|_/g, ' ')
         .replace(/[\x00-\x1f\x7f]/g, '')
         .replace(/%([0-9A-Fa-f]{2})/g, '% $1')
         .replace(/&(([A-Za-z0-9\x80-\xff]+|#[0-9]+|#x[0-9A-Fa-f]+);)/g, '& $1')
         .replace(/[:\/|#]/g, '-')
         .replace(/[\]\}>]/g, ')')
         .replace(/[\[\{<]/g, '(');
Titleblacklist ist nicht schwierig oder gar serverlastig (200ms oder so). Macht der UploadWizard und eines meiner Scripte auch:
	rIsOnBlackList: function() {
		var query = {
			'action': 'titleblacklist',
			'tbtitle': 'File:' + this.rNewName,
			'tbaction': 'create'
		};
		this.showProgress(this.rI18n.progress.blacklisted);
		this.queryAPI(query, 'rIsBlacklistedCB');
	},
	rIsBlacklistedCB: function(result) {
		if (!result || !result.titleblacklist || !result.titleblacklist.result) throw new Error('RenameLink: result.titleblacklist is undefined.');
		if ('blacklisted' === result.titleblacklist.result) {
			return this.rAbort(this.$txtNewName, this.rI18n.blacklisted);
		}
		return this.nextTask();
	},
Schritt 3: Textvorschlag u.U. nicht nötig vllt. kann man es auch mal kurz einfärben?

-- RE rillke fragen? 12:33, 14. Sep. 2012 (CEST)

Ich habe mal auf die Schnelle ein paar Dinge geändert: Beim Zeichnen wird der Dialog nun versteckt, sodass man nicht in die Gefahr kommt, sich zu verheddern; ebenso wird beim Warten auf die Vorschau der Button deaktiviert. Geschützte Titel werden nun verboten, die TBL teste ich aber nicht: Zum einen würde der obige Code Probleme machen, wenn die Extension nicht installiert ist (etwa in meinem Testwiki), zum anderen würde das entweder zu komplexem Code oder zwei parallelen Anfragen führen (was zwar kein Problem ist, aber zumindest offiziell nicht den Richtlinien entspricht, man solle mit einer API-Anfrage warten, bis die alte erledigt ist). --Schnark 10:43, 15. Sep. 2012 (CEST)
Sehr gut. Man könnte die Anfragen auch nacheinander ausführen. +200ms sind sicher verkraftbar. Wenn die Extension nicht installiert ist, gibt es:
{
	"error": {
		"code": "unknown_action",
		"info": "Unrecognized value for parameter 'action': titleblacklist"
	}
}
-- RE rillke fragen? 11:25, 15. Sep. 2012 (CEST)
Bei den Standard-Modulen gibt es auch eines, das auch die TBL abfragen kann. Andererseits sehe ich nicht so ganz ein, wieso ich mich um Benutzer bemühen sollte, die nicht fähig sind, vernünftige Dateinamen zu wählen. Spätestens wenn der Missbrauchsfilter einen Upload verbieten kann (du kennst den entsprechenden Bugreport ja), wird es ohnehin noch schwieriger, das sinnvoll abzufragen. Wirklich Schlimmes passiert nicht, wenn man einen verbotenen Namen wählt, nach dem gescheiterten Hochladen bekommt man das Dialogfenster zurück mit dem Hinweis, man möge einen besseren Namen auswählen. Sollte es mal dazu kommen, dass mein Skript massenhaft benutzt wird, sehe ich das sicher anders, aber im Augenblick gibt es eigentlich keinen Grund, mehr Titelvalidierung vorzunehmen. --Schnark 11:38, 15. Sep. 2012 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 23:18, 23. Dez. 2013 (CET)

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): [12] 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 Wikipedia: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
<span style="font-family:monospace;background:#FE3">:-)</span>
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.
      3. 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)
Wo steht denn nochmal wann und ob das HTML5 kommen soll? Und die Tags werden dann tatsächlich obsolet? PS: Wie es ausschaut ist es schon aktiv und trotzdem funktioniert der ganze Schladderadatsch noch!? -- πϵρήλιο ℗ 21:27, 13. Okt. 2012 (CEST)
Natürlich funktioniert alles weiterhin, so wie man auch ein Buch lesen kann, das in alter Rechtschreibung geschrieben ist, obwohl vorne drinsteht, es verwende die neue Rechtschreibung. Fehlerhaft ist es trotzdem: [13]. --Schnark 09:10, 15. Okt. 2012 (CEST)
Angesichts dass das code-Element bereits von Mediawiki mit einem Hintergrund und Rahmen vereinnahmt ist, halte ich die Löschung von tt um so mehr für fraglich. Wie steht ihr zur Löschung des Slashs bei Standalone-Tags, siehe: Wikipedia Diskussion:WikiProjekt HTML5#Void Elemente -- ΠЄΡΉΛΙʘ 17:34, 26. Okt. 2012 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 23:18, 23. Dez. 2013 (CET)

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: Wikipedia: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 Wikipedia: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.
  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 Wikipedia: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 Hilfe: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)
Da der Abschnitt hier noch steht, wenn jemand Lust hat, kann er sich gerne gerrit:94412 anschauen, dort habe ich ein eigenes Modul für redirectToFragment gebaut. Kommentare gerne, vorzugsweise dort, damit es die anderen Entwickler auch mitbekommen. Danke. Der Umherirrende 09:38, 9. Nov. 2013 (CET)
Die Funktion in wikibits.js könntest du per mw.log.deprecate als veraltet kennzeichnen, damit es auffällt, falls sie (etwa in einem Benutzerskript) noch anderswo verwendet wird, also
mw.log.deprecate( win, 'redirectToFragment', function ( fragment ) {
//Code wie bisher
}, 'Use the module mediawiki.action.view.redirectToFragment instead.' );
Falls man im Debug-Modus auf eine gecachte Seite stößt, bekommt man die Warnung zwar auch, aber einerseits stört sie ja nicht, andererseits weiß ich gar nicht, ob man im Debug-Modus überhaupt auf gecachte Versionen stoßen kann. --Schnark 10:26, 11. Nov. 2013 (CET)
Klingt gut, habe ich in Patch Set 4 gemacht. Der Umherirrende 19:10, 11. Nov. 2013 (CET)
Merged!!!! Der Umherirrende 22:27, 7. Jan. 2014 (CET)
Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 22:27, 7. Jan. 2014 (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)

Der benötigte Code müsste in Benutzer:Ireas/bilderpruefen.js und Wikipedia:WikiProjekt Dateikategorisierung/Werkzeug/x.js enthalten sein. --Leyo 22:12, 19. Sep. 2012 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: se4598 / ? 23:56, 13. Mär. 2014 (CET)

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)
Ich fände sowas auch etwa fürs Sichten von alten Dateiuploads (mit nur einer Version, so dass kein Vandalismus mitgesichtet wird) eines bestimmten Benutzers praktisch. --Leyo 21:38, 19. Sep. 2012 (CEST)
Technisch ist das nur viel Programmiererei, aber nicht allzu schwierig für Profis.
Im Einsatz ist es dann aber relativ mühsam zu bedienen und birgt Gefahr der unbeabsichtigten Mitsichtung von doch noch nicht so ausgereiften Sachen neuer Benutzer.
Machbar ist natürlich, pauschal alle ungesichteten Bearbeitungen eines Benutzers per API herauszufinden und dann per API ausnahmslos allen die Sichtung zu verpassen. Bei der Analyse der Aktivitäten eines Newcomers mag das gelegentlich sinnvoll sein, wenn man sich davon überzeugt hat, dass kein Müll gebaut wird.
Eine Alternative wäre es, statt der Einzelsichtung jeder Seite, die immer ein paar Sekunden rumrödelt, eine Sammlung auf Knopfdruck in einem Container. Anschließend alle Einträge im Container en bloc per API sichten. Der einzige allgemein verfügbare Container, der seitenübergreifend sowas sammeln kann, wäre ein session-cookie, sonst maximal eine Viertelstunde haltbar. Der müsste eine Liste von curid sammeln.
Das kann sich ziehen --PerfektesChaos 21:58, 19. Sep. 2012 (CEST)

→Wikipedia:Technik/Baustellen/Mehrfach-Sichtungen

Archivierung dieses Abschnittes wurde gewünscht von: --PerfektesChaos 20:31, 13. Jun. 2014 (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' => '

' 

           ),
       3 => array(
           '&' => ';'
           ),
       4 => array(
           '<' => '>'
           ),
       5 => array( // headlines
           "\n======" => '======',
           "\n=====" => '=====',
           "\n====" => '====',
           "\n===" => '===',
           "\n==" => '==',
           "\n=" => '='
           ),
       6 => array( // tables, wikilinks, templates
           '{|' => '|}',
           '[[' => ']]',
           '{{' => '}}'
           ),
       7 => array( // weblinks
           '=> '',
           '=> '',
           '=> '',
           '=> ''
           ),
       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(
   )

);

?> </syntaxhighlight>

Das könnte man mal auf Beta-Wiki ziehen, wirklich schade drum. Ich habe den Code mal bei der Extension auf der Diss. erwähnt. → Perhelion     22:20, 9. Jun. 2014 (CEST)
  • GeSHi wurde heute durch Pygments ersetzt.
  • phab:T29828 beschäftigt sich mit dem Anliegen.
  • Nach über drei Jahren hier erstmal erl.
Archivierung dieses Abschnittes wurde gewünscht von: --PerfektesChaos 12:41, 26. Jun. 2015 (CEST)

Datei-Sichtung effizienter gestalten

Da immer schon sehr viele Dateien ungesichtet und so anfälliger auf Vandalismus sind, habe ich mir überlegt, wie die Erstsichtung effizienter gestaltet werden könnte. Dabei sind mir zwei Möglichkeiten in den Sinn gekommen:

  • JS: In der Liste der ungesichteten Dateien zusätzlich angeben, wie ob mehrere Versionen existieren oder nur eine. In letzterem Fall müsste die Versionsgeschichte nicht angeschaut werden.
  • pywikipedia: Sichtung nach Uploader (der eingegeben werden müsste), filtern auf Dateien mit nur einer Version oder nur vom Uploader bearbeitet. Bei vertrauenswürdigen Uploadern kann so Vandalismus ausgeschlossen werden und ein kurzer Blick auf die aktuelle Version des Dateibeschreibungs-Quellcodes reicht.

--Leyo 13:29, 3. Okt. 2012 (CEST)

Die Dateierstsichtung steht bei 99 %, damit sollte die Anfrage nicht mehr notwendig sein. Der Umherirrende 10:46, 31. Okt. 2015 (CET)
Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 10:46, 31. Okt. 2015 (CET)

WP:FR#Kleines Dankeschön an IPs

Ich wäre für eine Stellungnahme zur Umsetzbarkeit dieser Script-/Gadget-Idee dankbar. --Leyo 14:04, 20. Okt. 2012 (CEST)

Umsetzbar ist so ziemlich alles. Zu erarbeiten wäre:
  1. Begründung, warum das nicht mit WikiLove kompatibel sei; wenn es dort integrierbar ist, wird niemand Lust haben, es neu zu programmieren und in die Tonne zu treten, sobald WikiLove eines Tages in deWP eingeführt wird.
  2. Operationale Anweisungen in Menschensprache an Programmierer:
    • Auf welchen Seiten soll ein Portlet-Link sichtbar sein?
    • Wenn ich auf welcher Seite das Portlet-Link anklicke, soll genau was passieren?
      • Nur für IPs; oder auch angemeldete, offenbar ohne Sichterrecht?
      • Eingabeformular für Freitext
      • Vorgegebene Standardtexte zum Anklicken
      • Feste Gesamt-Struktur des Textes, mit difflink der fraglichen Änderung/en.
      • Sicherheitshalber den letzten Bearbeiter anzeigen; falls nicht grad Aka zwischendurch noch gefixt hat und sich das Lob an Land zieht.
      • Wenn „Abschicken“, dann soll dies auf Benutzerdisku des letzten Bearbeiters der aktuellen und gesichteten Seite angefügt werden, obwohl / sofern / nicht / dies eine IP ist.
      • Es soll interaktiv die Benutzerdisku editiert werden, so dass last-minute-Anpassungen des Standardvorgangs möglich sind; oder alternativ per API gedonnert werden (Signatur-Umwandlung? Ausprobieren).
VG --PerfektesChaos 16:27, 20. Okt. 2012 (CEST)

„Individual wikis may request that WikiLove be deployed to them provided the following criteria are met:“

  • Community consensus for the deployment has been reached
  • The WikiLove extension has been localized to that wiki's language on TranslateWiki (you can help here) erledigtErledigt
  • A configuration file exists on the local wiki (MediaWiki:WikiLove.js)

„Once these criteria are met, open a bug in bugzilla requesting the deployment.“

Gruß Matthias (Diskussion) 16:30, 20. Okt. 2012 (CEST)

Beim Vorschlag geht es um eine „Einklicklösung“. Es gibt ja etliche Skripte Huggle, etc., die beim Revert auch gleich einen Baustein wie {{Test}} auf der IP-Disk. absetzen. Ich stelle es mir in dieser Art vor, nur halt positiv statt negativ.
Dementsprechend könnten existierende Skripte angepasst und müssten nicht neu geschrieben werden. --Leyo 17:36, 20. Okt. 2012 (CEST)
Der Benutzer:Schnark/js/wikieditor hat seit kurzem einen Knopf für {{Willkommen}}. Ansonsten ist Benutzer:Schnark/js/autoantraege wohl das was du suchst. Auch dieses Skript kann Standardtexte auf der Benutzerdiskussionsseite hinterlassen. Gruß Matthias (Diskussion) 22:42, 20. Okt. 2012 (CEST)
Ich möchte es ja nicht nur für mich, sondern für eine breitere Anwendung, damit IPs nicht immer nur getadelt, sondern (mit geringtem Aufwand) gelobt werden. Beim obigen Kommentar hatte ich insbesondere an Benutzer:DerHexer/rollback.js, aber auch an Scripts wie Benutzer:Schnark/js/autoantraege gedacht. --Leyo 22:52, 20. Okt. 2012 (CEST)
Erstmal schönen Urlaub, oder was immer du geplant hast.
Die Geschichte ist noch nicht operational.
  1. Inwieweit deckt das existierende aber in der deWP nicht aktivierte WikiLove den Wunsch bereits ab, oder könnte es das nicht?
  2. Eine Spezifikation scheint vielleicht wie folgt zu lauten, soweit ich die nebelhaften Vorstellungen bislang durchschauen konnte:
    • Interaktive Auslösung, individuell konfigurierbar
      • Wenn auf einer Seite im ANR, dann Portlet-Link einfügen
      • oder zusätzlich: Wenn Sichtungs-Buttons auf der Seite sichtbar sind, dann füge einen weiteren Button hinzu
      • und außerdem stelle per API eine .fire()-Funktion für eigene GUI-Wünsche bereit; eine solche .fire()-Funktion wird ohnehin für Portlet-Link usw. benötigt und kann dann auch öffentlich gemacht werden.
    • Wenn ausgelöst wird, dann
      • Mache eine API-Abfrage, welcher Benutzer die RevID der aktuell angezeigten Seitenversion editiert hatte, oder lies das aus den Strukturen einer (Sichtungs-)Diffpage heraus.
      • Zeige inzwischen ein Formular zum Zusammenbau eines Textes an.
        • Vorgegebene Standard-Phrasen für alle Gadget-Nutzer, zum Anklicken.
        • Individuell konfigurierte Standard-Phrasen, zum Anklicken.
        • Feld für Freitext.
        • Buttons für Abschicken/API, Manueller Edit, Abbrechen.
      • Wenn Submit, dann bearbeite die Disku des inzwischen (per API?) ermittelten Benutzers (bzw. IP). Füge den zusammengestoppelten Text ein, zusammen mit Backlink auf die bearbeitete Seite und Signatur, Disku-Überschrift und ggf. Neuanlage einer nicht existierenden BD.
        • Ob es sich überhaupt lohnt, für diese letzte Phase ein externes Skript mit völlig anderer Methodik auch noch einzubinden (DerHexer/rollback.js, Schnark/js/autoantraege) oder ob das nicht größeren Aufwand und Probleme verursacht als das integriert selbst vorzuhalten steht dahin. Eigentlich sind das dann nur noch wenige Statements.
  3. Der Überschrift dieses Thread entnehme ich, dass IPs gemeint wären. Der sonstigen Diskussion entnehme ich, dass seit kurzem angemeldete Benutzer gemeint wären, die noch kein Sichterrecht hätten. Wie denn nun?
LG --PerfektesChaos 13:29, 21. Okt. 2012 (CEST)

IMHO ist das WikiLob für IPs UND für Benutzer ohne Sichterrechte UND für alle anderen (nicht gesperrten) Benutzer gemeint. Der Entwicklungsaufwand und ein breiter Einsatz per default ist IMHO dann gerechtfertigt. Wenn das jemand benutzt, um ausschliesslich IPs postives Feedback zu schicken - wunderbar, kein Problem :-) ! Oder nur Neulingen, super! Alle können etwas mehr positives Feedback gebrauchen... Wichtig ist in jedem Fall: schnell benutzbar mit wenigen Klicks und nicht 3 Dialogboxen. Mal 2 konkrete Anwendungsbeispiele:

  • Fall A): Ich will nur mal schnell eine IP für ihren Beitrag loben. In der Sichtungsbox (oder in meiner Beobachtungsliste oder in der Versionsgeschichte) klicke ich auf den "WikiDank"-Button  , die Dialogbox öffnet sich (ohne das ich dabei ja die Seite verlasse). Ich klicke einfach nur auf "senden" (und ignoriere das optionale Texteingabefeld), damit wird folgendes automatisch auf die IP-Diskussionsseite geschrieben (voreingestelltes Bild und der Standardtext):
  Einfach mal ein kleines Dankeschön für Deinen Beitrag in Liste der Universitäten in Ghana...

von Atlasowa (Diskussion) 16:28, 29. Okt. 2012 (CET)

Alles wichtige ist damit gesagt, nämlich wer wem wofür konkret mal Dankeschön sagt. In vielen Fällen reicht diese "Basic" Variante völlig, beide wissen worum es geht, das ist auch nicht eigentlich "unpersönlich". Die IP wird per "Kackbalken" auf den WikiDank aufmerksam. Der gesendete WikiDank wird übrigens auch in meinen Benutzerbeiträgen aufgeführt.

  • Fall B): Ich will mal schnell jemand für einen Edit Dankeschön sagen, aber auch einen persönlichen Kommentar dazu schreiben und ein passendes Bild auswählen. In der Sichtungsbox (oder in meiner Beobachtungsliste oder in der Versionsgeschichte) klicke ich auf den "WikiDank"-Button  , die Dialogbox öffnet sich. Ich schreibe etwas in das Texteingabefeld und wähle (mit dem Link unter dem voreingestellten Bild) ein bestimmtes Bild von Commons aus (so ähnlich wie bei WikiLove). Wie bei WikiLove sehe ich dann eine Vorschau meiner WikiDank-Nachricht. Ich klicke auf "senden", damit wird folgendes automatisch auf die Benutzerdisk geschrieben:
  Einfach mal ein kleines Dankeschön für Deinen Beitrag in Holsten Brauerei...

Boah, gute Arbeit mit den Koordinaten, das kriege ich immer nicht richtig hin! Prost! --Atlasowa (Diskussion) 16:28, 29. Okt. 2012 (CET)

So ungefähr stelle ich mir das vor, voreingestelltes Bild und Optionen kann man natürlich noch diskutieren. Das ist aber so technisch machbar, oder? Das könnte man dann als gadget testen und danach als default einrichten, mit opt-out per Einstellungen (wie bei WikiLove). Grüsse --Atlasowa (Diskussion) 16:28, 29. Okt. 2012 (CET)

  1. Technisch machbar ist das alles. Geistig keine Herausforderung, nur ein Haufen Routine-Programmierarbeit.
  2. Noch nicht klar ist weiterhin, warum man dies nicht über das existierende WikiLove ansteuern kann; möglicherweise haben die eine API? Eine komplette Parallelprogrammierung wird kaum passieren.
  3. Danke für die präzise Beschreibung der Vorstellungen; man nennt sowas auch Use Cases.
  4. Die Geschichte mit dem Standard-Text und Einheits-Blumenstrauß wird so zur Farce. Wenn 100 Leute das Gadget benutzen und überwiegend denselben Text schicken und alle denselben Blumenstrauß, dann haben bald etliche Empfänger den identischen Block dreimal auf der Disku; und wenn sie auf die Disku anderer Leute gehen, dann finden sie dort noch zwei identische Blümchen und Texte wie bei sich selbst. Das wirkt mehr negativ und entwertet die Aktion. Wenn schon, dann müsste zufallsgesteuert der Blumenstrauß oder andere Motive aus einem Dutzend ausgewählt werden, kombiniert mit einer zufälligen Auswahl aus einigen vorgegebenen Standardphrasen, die um selbst geschriebene Textbrösel ergänzt werden.
LG --PerfektesChaos 23:25, 29. Okt. 2012 (CET)

Ich möchte ebenfalls einen Use Case nachliefern: Bei ungesichteten Änderungen erscheinen die zwei Sichtungsbuttons. Da könnte ein weiterer hinzugefügt werden.
Sichten Sichten + IP danken Änderungen verwerfen
Ein Klick auf den neuen Button würde folgendes bewirken:

  • Diff wird gesichtet
  • Difflink und Artikelname wird gespeichert
  • Prüfung, ob Änderung durch IP User erfolgte → falls nein Abbruch
  • IP-Disk. wird auf Existenz geprüft → falls nein Prüfung auf Vorhandensein von IP-Thanks-Bausteinen → falls ja Abbruch
  • IP-Thanks-Baustein (mit Artikelname, Diff, Hinweis auf Sichtung und ggf. Zufallsbild) wird auf IP-Disk. gesetzt

Einige der Schritte sind (ähnlich) in Hexers Rollback-Script implementiert. Beispielsweise werden {{subst:Test}} oder {{subst:Benutzer:TheWolf/Quellen}} automatisch auf die IP-Disk. gesetzt. Falls diese erst kürzlich gearbeitet wurde, wird eine VM oder Sperre vorgeschlagen. --Leyo 22:52, 27. Nov. 2012 (CET)


mw:Extension:Thanks scheint diesem Wunsch hier ziemlich ähnlich zu sein. Könnte diese Extension hier übernommen und ggf. lokal angepasst werden? --Leyo 21:45, 26. Mär. 2013 (CET)

  • Dies ist experimentell, und da bin ich persönlich erstmal zurückhaltend. Wir haben mit Lua und AFT und Wikidata und etlichem anderem einen ziemlichen Rückstau und viel zu wenig Techies, um uns in Kinderkrankheiten unausgereifter Produkte anderer Leut zu stürzen.
  • Das System arbeitet mit Echo, welches ebenfalls noch nicht zu Ende entwickelt ist; noch weniger dass wir dieses ausgereift eingebaut hätten.
  • Das System versendet seine Nachrichten rein privat, so dass sie niemand anders sehen kann. Womit man auch nicht wissen kann, ob es schon durch einen anderen Wikipedianer eine Benachrichtigung gegeben hätte.
  • Das System scheint auf E-Mail zu setzen; der Thread hier heißt „Dankeschön an IP“. Wo und wie allerdings ein nicht angemeldeter Benutzer einen E-Mail- oder Echo-(=WP/SUL)-Account eingerichtet haben soll, erschließt sich mir grad nicht („no support for anonymous users“).
  • Zum System „Thanks“ gibt es außer der standardmäßig zu jeder mw:Extension abgespulten mw-Installationsroutine keinerlei Doku-Seite verlinkt; außer einem Bildschirmfoto von einem Link „Hier draufklicken“ ist nichts über Funktionalität oder Abläufe erkennbar. Mit Softwareprodukten ohne Dokumentationsseite beschäftige ich persönlich mich grundsätzlich nicht.
VG --PerfektesChaos 22:07, 26. Mär. 2013 (CET)

Thanks ist mittlerweile aktiv. Wenn auch IPs berücksichtigt wären, so wäre mein Wunsch zumindest teilweise erfüllt. --Leyo 16:29, 21. Nov. 2013 (CET)

Jetzt in den Top20 der Umfrage Technische Wünsche angenommen; damit hier erledigt. --PerfektesChaos 20:39, 3. Dez. 2015 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 20:39, 3. Dez. 2015 (CET)

OpenStreetMap-Karte bei HTTPS

Derzeit funktioniert die eingebaute OpenStreetMap-Karte nicht vollständig, wenn Wikipedia über HTTPS statt über HTTP aufgerufen wird. Beispiel: Beim Artikel Deutschland wird durch ein Klick auf den Knopf Karte folgende Seite eingebunden:

Bei HTTP funktioniert alles. Bei HTTPS fehlen das rote Overlay und die Stecknadeln für andere Artikel. Bisher hat das auch bei HTTPS funktioniert. Wo liegt der Fehler? --Fomafix (Diskussion) 14:29, 14. Sep. 2012 (CEST)

Es müsste bei HTTPS funktionieren, wenn in tools:~kolossos/openlayers/kml-on-ol.php statt
einfach protokollrelative Links verwendet werden:
  • //toolserver.org/~master/osmjson/getGeoJSON.php und
  • //toolserver.org/~kolossos/geoworld/marks.php
Kann das jemand beheben? --Fomafix (Diskussion) 14:49, 15. Sep. 2012 (CEST)
Irgendjemand hat es umgestellt. Es funktioniert nun wieder mit HTTP und HTTPS. Vielen Dank. --Fomafix (Diskussion) 11:32, 17. Sep. 2012 (CEST)

Es wäre noch schön, wenn die erzeugten Links auf die entsprechenden Wikipedia-Artikel auch protokollrelative URLs verwenden würden, damit man nicht von HTTPS auf HTTP umgelegt wird, wenn man einen neuen Artikel anklickt. Außerdem sollten die generierten URLs korrekt encoded werden. --Fomafix (Diskussion) 11:32, 17. Sep. 2012 (CEST)

Und auch sicherheitsgründen sollten die beiden eingebundenen JavaScript-Dateien ebenfalls über ein protokollrelativen Link geladen werden: Statt: 

<script src="http://toolserver.org/~osm/libs/jquery/latest/jquery-min.js" type="text/javascript"></script>
<script src="http://toolserver.org/~osm/libs/openlayers/2.12/OpenLayers.js" type="text/javascript"></script>

besser: 

<script src="//toolserver.org/~osm/libs/jquery/latest/jquery-min.js" type="text/javascript"></script>
<script src="//toolserver.org/~osm/libs/openlayers/2.12/OpenLayers.js" type="text/javascript"></script>

--Fomafix (Diskussion) 11:44, 17. Sep. 2012 (CEST)

Auch die folgenden Links sollten in protokollrelative Links gewandelt werden:

Dann werden nur noch die Bilder ohne protokollrelativen Links geladen. --Fomafix (Diskussion) 09:17, 19. Sep. 2012 (CEST)

Sieht so aus, als ob es (wieder) funktioniert, ansonsten mit Benutzer:Kolossos sprechen, der kann es entsprechend auf der Toolserver-Seite ändern. Der Umherirrende 09:34, 27. Okt. 2012 (CEST)

Die Links sind auch umgesetzt. --Kolossos (Diskussion) 17:28, 28. Okt. 2012 (CET)
Danke fürs umsetzen der Links auf protokollrelative Links. --Fomafix (Diskussion) 08:35, 30. Okt. 2012 (CET)

Eine Sorte von Links fehlt noch und zwar die Links auf die Artikel. Diese Links werden in tools:~kolossos/geoworld/marks.php erzeugt und sind derzeit HTTP-Links. Vermutlich müssten hier auch protokollrelative Links möglich sein. --Fomafix (Diskussion) 08:35, 30. Okt. 2012 (CET)

Außerdem fehlt bei diesen Links die Ersetzung von ' ' nach '_' und potentiell weiteren problematischen Zeichen. --Fomafix (Diskussion) 09:18, 25. Nov. 2013 (CET)
Die Ersetzung erfolgt bei Anchor-Elementen, Artikelnamen mit Javascript-Injection werden wohl bei der Eingangskontrolle auffallen. --Kolossos 20:49, 26. Nov. 2013 (CET)
Statt auf die Eingangkontrolle zu verlassen, sollte sinnvoller auf ein simples Encoding eingesetzt werden:
https://toolserver.org/~kolossos/geoworld/marks.php?LANG=de&thumbs=0&bbox=-4.2642046440962,45.463868737325,25.174760199654,56.338265659873 sollte statt
<a target="_blank" href="http://de.wikipedia.org/wiki/Münster (Westfalen)">
folgendes enthalten:
<a target="_blank" href="//de.wikipedia.org/wiki/M%C3%BCnster_%28Westfalen%29">
Meiner Meinung nach sollte auch das target="_blank" entfallen. --Fomafix (Diskussion) 21:26, 26. Nov. 2013 (CET)
Das Skript ist anfällig gegen JavaScript Injection. Ich lasse die Einbindung in MediaWiki:Common.js deaktivieren, bis der Encodingfehler behoben ist. --Fomafix (Diskussion) 21:54, 3. Dez. 2013 (CET)

Habs eingebaut, wenn es dich glücklich macht. Von weiterem persönlichen Kontakt bitte ich dich abzusehen... --Kolossos 21:59, 4. Dez. 2013 (CET)

Danke für das Beheben des Encodingfehlers, der JavaScript Injection ermöglichte.
Wie ich oben geschrieben habe, wäre es trotzdem weiterhin sinnvoll statt 
<a target="_blank" href="http://de.wikipedia.org/wiki/M%C3%BCnster%20%28Westfalen%29">
protokollrelative Links zu verwenden: 
<a href="//de.wikipedia.org/wiki/M%C3%BCnster_%28Westfalen%29">
damit HTTPS nicht verlassen wird, wenn ein Link angeklickt wird. --Fomafix (Diskussion) 22:12, 4. Dez. 2013 (CET)

Erledigt. --Kolossos 22:34, 4. Dez. 2013 (CET)

@Kolossos: Äh, was genau hast du behoben? Nach Fomafix Meldung habe ich selbst ein bisschen probiert und eine Möglichkeit gefunden beliebigen Code in den iframe einzuschleusen. Per Same-Origin-Policy ist das zwar kein großes Problem, aber zumindest Web-Bugs sind möglich. Und was immer du getan hast, mein Hack funktioniert noch immer. --Schnark 09:49, 5. Dez. 2013 (CET)
Was genau hast du gemacht? Rawurlencode bei den Links ist jetzt drin und auch das protokollneutrale verlinken auf Artikel. --Kolossos 12:50, 5. Dez. 2013 (CET)
Oh, ja, da sind noch viel mehr potentielle Lücken drin. JavaScript-Code sollte einfach nicht dynamisch erzeugt werden. --Fomafix (Diskussion) 13:31, 5. Dez. 2013 (CET)
Gibt es noch irgendwie konkretere Aussagen? In der marks.php wird garkein JavaScript erzeugt, sondern KML. --Kolossos 18:36, 6. Dez. 2013 (CET)
Ich hab dir eine E-Mail geschickt. --Schnark 11:04, 7. Dez. 2013 (CET)

@Fomafix, Kolossos, Schnark: Altes Thema, aber die Sicherheitslücken sollten geschlossen sein, bevor das archiviert wird. Funktioniert HTTPS jetzt oder kommt das mit dem Umzug nach Labs? Der Umherirrende 22:07, 20. Sep. 2014 (CEST)

Ich finde weiterhin Möglichkeiten von JavaScript-Injection. --Fomafix (Diskussion) 22:55, 20. Sep. 2014 (CEST)
Hast du einen Toollabs-Account? dann könnte ich dir Zugriff auf das Skript geben. Ansonsten, kann ich mit deine allgemeinen Aussage nicht viel anfangen. Du kannst mir aber gern eine Mail mit näheren Hinweisen schicken. --Kolossos 17:59, 21. Sep. 2014 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: --PerfektesChaos 00:23, 22. Nov. 2016 (CET)

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)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 15:57, 30. Nov. 2018 (CET)
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Wikipedia:Technik/Archiv/2012&oldid=234768864“