Benutzer Diskussion:Perhelion/signing

Anleitung & Benutzungshinweise:

… befinden sich umseitig unter Benutzer:Perhelion/signing

Eröffnung des Feedbacks

Ich eröffne dann mal die Kommentare:

• Wikipedia:Technik/Skin/Werkstatt magst du auch in die RE-Liste aufnehmen? Vielleicht jede erkstatt (Kartenwerkstatt). Dann gibt es bei Admins noch allerlei mit Anfragen, SP, usw.
• Ansonsten sieht man, dass du bei der Überarbeitung des Olliminatore die Hinweise auf WP:JS betreffend veralteter Praktiken beherzigt hast. Hattu feinemacht.
• Vor Jahren wurden Funktionen offen definiert. Dies hat dazu geführt, dass mittlerweile Hunderte von Funktionen und globalen Variablen beim Benutzer herumschwirren und es zu Namenskonflikten, mindestens aber zu unübersichtlichem Debugging kommt.
  • Als Chrome-Benutzer würdest du die Erweiterung Firebug Lite benötigen, falls du diese nicht schon längst hast. Dann DOM → mw → libs, und schon unterwegs siehst du, was ich meine.
  • Bereits Olliminatore hatte bei addOnloadHook eine anonyme Funktion verwendet, die das Problem der Namenskonflikte soweit vermeidet. doSign() ist also nach außen unsichtbar.
  • Mittlerweile wird pro Werkzeug nur noch ein Anwendungsobjekt gewünscht, das auch unter mw.libs abgelegt werden kann. Alle zugehörigen Funktionen und Variablen sind danach Komponenten dieses Anwendungsobjekts. Dann weiß man bei jeder Funktion sofort, wo sie hingehört.
  • Das momentane Skript produziert drei Funktionen addEvent, removeEvent, getCaretPos und u.a. eine Variable window.editform – die Gefahr laufen, dass ein anderer Programmierer unter gleichem Namen etwas anderes vereinbart.
  • Eine Lösung wäre es, zu definieren

 if ( typeof( mw.libs.threadSign )  !==  "object" ) {
    mw.libs.threadSign  =  { };
 }

und anschließend beispielsweise

 mw.libs.threadSign.editform =
 mw.libs.threadSign.init =
 mw.libs.threadSign.ready =
 mw.libs.threadSign.addEvent = function (obj,type,fn) {
    if(obj.addEventListener) ...
 }

Deine Benutzer hätten dann die Möglichkeit, in ihrer common.js alternativ zu definieren:

 mw.libs.threadSign  =  { config: { weitereRegexp: [...],
                                    usersignature: "...",
                                    sigAccessKey:  "."
                                   } };

Vergleiche hierzu: WSTM.object

• Was genau ich mit dem Array benutzerdefinierter regexp machen soll, habe ich nicht ganz verstanden. Es scheint, dass sie wie wohl auch bei Olliminatore komplett ersetzt werden?
  • Mit arr1.concat(arr2) könnten zwei Arrays verbunden werden, also wenige zusätzliche benutzerdefinierte an die lange Standard-Liste anzugehängen wären – wenn die regpages auf jeden Namensraum angewendet werden sollen.
• In praktisch jedem WMF-Wiki hat der Projekt-Namensraum die Nummer 4. Weil alle momentanen regpages wohl damit zu tun haben, kannst du all diese ünsche, andidaten und erkstatt auf diesen WP-NR=4 beschränken. Das spart Zeit und Missverständnisse bei kuriosen Seiten-Namen. Die Benutzerdefinierten mögen mit Portalen und Redaktionen zu tun haben und könnten auch in allen geradzahligen NR>0 greifen; wenn Unsinn passiert, sind die doofen Benutzer schuld.
  • Im ANR (und theoretisch, aber nicht praktisch: Spezial=-1) sollte überhaupt nie was passieren, richtig? Nebenbei: Spezial=-1 ist ungerade (%1), kann aber nie signiert, kann ohnehin nicht editiert werden.
• Weil du nowiki gesetzt hast, brauchst du wohl keinen \ in ~~\~~ zur Verhinderung.
• signing_init() funktioniert, aber wie wäre es mit der oben beschriebenen Technik und: mw.libs.threadSign.init(regpages, usersignature, sigAccessKey)
• Statt getCaretPos() von Olliminatore gibt es inzwischen für aktuelle Browser gepflegtes und wesentlich eleganteres jQuery.textSelection() – aber nicht ganz trivial einzusetzen. Sage ich dir gern gelegentlich, wie das geht; müsste aber erstmal begreifen, was bei dir/Olli eigentlich alles passieren soll.
• Ich habe in der Schublade ein universelleres beforeSaveHook, das zur Registrierung beliebiger Funktionen gedacht ist, die ausgeführt werden sollen, bevor man eine Seite speichert, oder die beabsichtigte Abspeicherung wieder abbrechen. removeEvent(editform.wpSave,"click",doSign); wäre damit zu ersetzen. Das wird aber irgendwann in 2012.
• Betrifft Benutzer:Perhelion/signing: Zwischen é und ' in ':Café' stehen zwei unsichtbare LTR.

Genug kommentiert, rundherum gelungen; Guten Rutsch --PerfektesChaos 21:16, 29. Dez. 2011 (CET)

Vielen Dank, super Feedback, mehr als ich je erwartet hätte!! Vorlage:Smiley/Wartung/:d  An der eigentlichen Mechanik des UrsprungsSkripts habe ich ja nichts geändert. Ich habe nur – grob gesagt – die Kompatibilität und 3 kleine Features erweitert. Das wird noch ein wenig Arbeit werden, alle deine Hinweise umzusetzen, dieses Jahr werde ich wohl nicht mehr dazu kommen alles umzuschreiben, Vorlage:Smiley/Wartung/hammer  geschweige denn erstmal detailliert zu antworten.Vorlage:Smiley/Wartung/:o  Um weiteres Belesen werde ich nicht rumkommen, hört sich alles super an, ich denke die beiden Event-Funktionen können ebenso durch jQuery ersetzt werden. Also packe ich demnächst alles in threadSign, ich werde nicht drumrum kommen dich auch namentlich im Header zu erwähnen, da ich wohl nochmal hier und da auf dich zurückkommen werde. Vorlage:Smiley/Wartung/:p  Ich sehe nun es ist noch viel Platz für Optimierung und Testläufe. Guten Rutsch bis dann! -- πϵρήλιο ℗ 22:03, 29. Dez. 2011 (CET)

Na, dann bekommst du im zweiten Durchgang noch ein paar hinterher, für 2012:

• getCaretPos()

  Zusätzlich einfügen, unmittelbar nach txtarea = editform.elements['wpTextbox1'];

         mw.libs.threadSign.$txtarea = jQuery("#wpTextbox1");

Später, an Stelle der Zeile

         pos = getCaretPos(txtarea);

die Zuweisung

         pos = mw.libs.threadSign.$txtarea.textSelection("getCaretPosition");

und die gesamte Definition von getCaretPos() erstmal auskommentieren, wenn es funktioniert, kann sie raus.

Das threadSign.$txtarea lässt sich beim weiteren Umbau noch für andere Sachen benutzen.

• wikEd

  wikEdUseWikEd kommt mehrfach vor; ist auf einem Stand vor September 2010.

  Statt der Zeile

   if ((typeof wikEdUseWikEd != 'undefined') && wikEdUseWikEd) WikEdUpdateTextarea();

zunächst die längere, aber narrensichere und dabei schnelle Konstruktion

   mw.libs.threadSign.wikEd = window.wikEd;
   if (mw.libs.threadSign.wikEd) {
      mw.libs.threadSign.wikEd = (typeof window.wikEd === "object");
      if (mw.libs.threadSign.wikEd) {
         if (window.wikEd.useWikEd) {
            window.wikEd.UpdateTextarea()();
         }
      }
   }

Später gibt es

  if ((typeof wikEdUseWikEd != 'undefined') && wikEdUseWikEd) WikEdUpdateFrame();

Dafür nehmen wir jetzt

  if (mw.libs.threadSign.wikEd) {
     if (window.wikEd.useWikEd) {
        window.wikEd.UpdateFrame();
     }
  }

Merke: Auch wikEd hat seine Einzel-Variablen und -Funktionen umgestellt auf wikEd. als Anwendungs-Objekt.

• Die Gesamtstruktur habe ich noch nicht verstanden.
  • Eingebettet ist sie in ein Konstrukt

    (function($){ ... })(jQuery);

Das kann man machen, wäre aber eher üblich für eine Erweiterung, die man dann als jQuery.signing() starten möchte. Grundsätzlich geht sowas, scheint mir hier aber thematisch nicht beabsichtigt; könnte sein, dass du gemeint hast, ganz am Ende anzugeben:

         $(signing_init);

oder gleichbedeutend und verständlicher

         jQuery(document).ready(signing_init);

Was in diesem Zusammenhang gemeint ist mit Für eine Einbindung in PDD's Monobook ist eine kleine Anpassung notwendig (da unter anderem ab Version 1.61 das Skript extern gestartet wird). kann ich nicht überblicken.

• Allgemein kannst du die Initialisierungsphase zweistufig anlegen:
  1. Alles, was du schon am Anfang weißt, nämlich welcher Namensraum, und ob überhaupt irgendwas passieren soll.
     • Wenn kein Disku-Namensraum und auch kein geeigneter Seitentitel, dann kannst du sofort komplett aussteigen und musst den Benutzer keine Zeit kosten und nix weiter machen. Dazu muss das document noch nicht ready geladen sein.
     • Übrigens fällt mir auf, dass das alles nur sinnvoll ist, wenn wgAction==="edit" oder "submit". Das kann von vornherein geprüft werden; wenn nicht, dann brauchst du weder zu warten noch nach einem editform zu suchen noch mit Events zu hantieren.
  2. Wenn du in der ersten Phase entschieden hast, dass das Skript wirklich aktiv werden soll, wäre jQuery(document).ready() abzuwarten und die dortige Funktion der zweiten Stufe fasst alles an, was vom ferig geladenen Dokument benötigt wird, also editform und die Knöpfe und Events usw.

Das sollte jetzt bis 2012 reichen; Guten Rutsch --PerfektesChaos 10:07, 30. Dez. 2011 (CET)

Hallo PerfektesChaos, vielen Dank für die weiteren Hinweise. Ich habe nun alles nach langen langem Lesen und Testen und Kopieren, mehr oder weniger, so wie du es vorgeschlagen hast hinbekommen. Ich hatte mit einigen Problemen der Lade-Reihenfolge zu kämpfen. Das Einbettungs-Konstrukt habe ich von Schnark abgeschaut, ja ich dachte mir es ist sowas wie (document).ready, was er in fast allen seinen Scripten so benutzt. Ein anderes Problem war dass die funktionen als Object Variablen nicht als Funktionen akzeptiert wurden, s [1]. -- πϵρήλιο ℗ 20:16, 4. Jan. 2012 (CET)

Aha, ich sehe es mit Wohlwollen. Getestet habe ich nichts, aber beim Drüberlesen fiel mir noch etwas auf:

• if ((typeof wikEdUseWikEd != 'undefined') && wikEdUseWikEd) UpdateTextarea();
  • Das wäre zum einen überaltert, weil wir wikEdUseWikEd als veraltet rauswerfen. Zurzeit schlägt es trotzdem noch an, aber mit dem Fehler: Unbekannte Funktion "UpdateTextarea". Weil: window.wikEd.UpdateTextarea()
• Den scope von editform, txtarea, txtOld, txtOldEnd, $tmpNode durchschaue ich grad nicht; wohler wäre es mir mit var.
  • Zu überlegen ist, ob dies nur innerhalb der Funktion doSign vorkommt oder Komponente von libs.threadSign sein soll.
  • Zu jeder einzelnen Variablen (oder Funktion, was aufs Gleiche hinausläuft) sollte man sich überlegen, in welchem scope sie benötigt wird, und diesen immer so klein wie möglich zu halten.
  • Auf MediaWiki gibt es Anwandlungen, JS so zu schreiben, dass Funktionen/Variablen „privat“ und damit völlig unsichtbar und vom Benutzer auch nicht aufrufbar sind. Das kann man machen, wenn man eine weltweite Basis-Software schreibt und Benutzer in der ganzen Welt da draußen daran hindern will, dass sie interne Funktionen benutzen, die man nicht dauerhaft im Sinne einer API unterstützen mag, und die man ohne Vorwarnung verändern möchte. Allerdings hindert man sich dadurch als Entwickler auch selbst am schnellen, einfachen und jederzeitigen Debuggen. Solange dies als Komponente von mw.libs.threadSign aber nicht im globalen Namensraum herumsteht, ist das in deinem Fall weniger dramatisch. Wer auf eigenes Risiko interne Funktionen oder Variablen aufruft, die nicht in der Beschreibung als benutzerverwendbar ausgewiesen sind, handelt auf eigenes Risiko und kann sich nicht beschweren, wenn sich später etwas ändert.

Viel Spaß weiterhin damit --PerfektesChaos 09:48, 5. Jan. 2012 (CET)

Danke nochmals, tatsächlich fehlte da was (war mir eigentlich sicher alle WikE-Aufrufe ersetzt zu haben) bzw. war zuviel. Nun habe ich alle 3 Helfer-Funktionen durch jQuery ausgelagert und die wunderbare API query Funktion eingefügt (natürlich sollte diese Ressourcen schonend eingesetzt werden, vielleicht sollte diese standardmäßig deaktiviert). Ich habe einiges gelernt und verstehe das Skript nun ganz. Ich glaube die Funktion doSign könnte gleich ans Formular onsubmit übergeben werden und nicht an alle Buttons einzeln. Wenn es jemand als Gadget vorschlagen würde, müsste ich wohl die Option für die eigene Signatur entfernen!? Ich warte immer noch auf Benutzer-Bug-Meldungen, selber werde ich es nicht tun. PS. Habe jetzt ein weiteres ähnliches Skript neu erstellt bzw. adaptiert: sectionSummary.js Lieben Gruß -- πϵρήλιο ℗ 22:45, 7. Jan. 2012 (CET)

Vor einem Vorschlag als Gadget würde ich empfehlen, es als Benutzerskript noch weiter reifen zu lassen. Auf anderen Browsern, mit anderen Skins ergibt sich im Lauf der Zeit oft noch etwas von den ersten Benutzern im Real-Einsatz. Viel Spaß damit --PerfektesChaos 10:32, 8. Jan. 2012 (CET)

Bei Vorschau nicht unterschreiben

Ist es denn Absicht, dass die Signatur schon eingefügt wird, wenn man nur die Vorschau aktiviert?

Ich sehe mir, wenn ich einen längeren Beitrag schreibe, durchaus öfters die Vorschau an und setze (oder vergesse ;) ) die Signatur nur ganz am Schluss. Ich persönlich würde es deshalb vorziehen, wenn das Skript nur beim Speichern aktiv wird.

Lässt sich das einbauen oder ist das explizit unerwünscht? --Patrick87 (Diskussion) 06:57, 19. Mai 2013 (CEST)

Hallo Patrick, erstmal freut es mich dass Du das Script verwendest und auch noch Feedback gibst. Ja das ist beabsichtigt, da es leider keine 100%ige Garantie gibt dass eine Signatur-Platzierung gefunden wird. Leider hängt daran ein weiterer Bug des Scripts, die Warnfunktion funktioniert nämlich nicht. Daher muss ich wohl auch hier in der Werkstatt nachfragen. (Ansonsten könnte man deinen Wunsch über einen Parameter sicherlich bewerkstelligen.) -- ΠЄΡΉΛΙΟ 11:32, 12. Jun. 2013 (CEST)

Vorhandene Signatur in unbenannten nummerierten Vorlagenparametern nicht erkannt.

Wenn man die Signatur in einer Vorlage als unbenannten nummerierten Parameter benutzt, etwa {{Erledigt|1=~~~~}}, dann wird die Signatur nicht als solche erkannt und eine zusätzliche Signatur eingefügt (was natürlich meist nicht erwünscht ist). Bei benannten Parametern, sowie unbenannten Parametern ohne explizite Angabe der Parameternummer wird die Signatur übrigens problemlos erkannt.

Lässt sich das beheben? --Patrick87 (Diskussion) 22:27, 11. Jun. 2013 (CEST)

Hallo Patrick, ja schon. Diese Änderung hatte ich erst vor kurzem eingefügt. Da aus mir unbekannten Gründen die Signatur nicht gesetzt wird in der Grafikwerkstatt. durch dieses {{Erledigt|1=~~~~}} in einem Kommentar (welcher eigentlich alle Signaturen ignorieren lässt). Also ein Regexp-Problem. Da müsste ich in der Werkstatt nachfragen. Ich nehme meine Änderung erstmal wieder raus. PS.: tatsächlich habe ich deinen vorherigen obigen Beitrag übersehen. -- ΠЄΡΉΛΙΟ 11:26, 12. Jun. 2013 (CEST)

Ah, ich sehe das Problem. Das es in der Grafikwerkstatt nicht funktionierte, war mir selbst schon aufgefallen. Allerdings bin ich auch recht schnell drauf gekommen, dass es an der Signatur im HTML-Kommentar liegen muss, was in meinen Augen keinen Fehler im Skript darstellt (solche Spezialfälle trotzdem unterstützen zu wollen ist natürlich lobenswert!).

Ohne von JavaScript allzu viel Ahnung zu haben oder mich mit dem aktuellen Code des Skripts auszukennen: Sollte es nicht einfach sein HTML-Kommentare und Text zwischen <nowiki> Tags schlicht zu ingorieren? Mit einem einfachen RegEx müsste man die betreffenden Textabschnitte doch einfach löschen können? --Patrick87 (Diskussion) 11:45, 12. Jun. 2013 (CEST)

Ja genau, das Problem sollte Dank der Hilfe der JS-Werkstatt nun gelöst sein (so einfach war die Angelegenheit nicht, s. dort).Vorlage:Smiley/Wartung/:)  -- ΠЄΡΉΛΙΟ 10:49, 13. Jun. 2013 (CEST)

Super, vielen Dank!

Tatsächlich hätte ich einen ganz anderen Ansatz gewählt um das mit den Kommentaren zu lösen (Wohlgemerkt habe ich keine Ahnung ob das überhaupt funktioniert und wenn ja, ob es wirklich besser funktioniert. In meinem Kopf kommt es mir aber sehr viel einfacher und weniger Fehleranfällig vor. Verstehe das deshalb einfach mal als Denkanstoß):
Ich würde die Erkennung in zwei Schritte unterteilen. Im ersten Schritt werden die Teile im vorliegenden Wikitext, welche z.B. zwischen <!-- --> oder <nowiki> </nowiki> stehen, komplett aus dem String gelöscht. Im zweiten Schritt wird dann ein (dadurch vermutlich deutlich einfacherer) RegEx verwendet um zu überprüfen ob im verbleibenden Wikitext noch eine Signatur vorhanden ist. --Patrick87 (Diskussion) 11:31, 13. Jun. 2013 (CEST)

So mache ich es auf Commons auch mit commons:MediaWiki:Gadget-libWikiDOM.js/nowikiEscaper. Nur dort muss man den Text allerdings hinterher wieder zusammenflicken können, weshalb das ziemlich komplex ausschaut. -- RE rillke fragen? 15:38, 13. Jun. 2013 (CEST)

Bei dieser Änderung wurden gerade eben wieder zwei Signaturen eingefügt (einmal manuell im {{Erledigt|1=~~~~}} und eine zusätzliche durch das Sktipt). Irgendeine Idee was da schief gelaufen ist? welche Ironie, dass es hier (hatte das <nowiki /> im ~~~~ vergessen) jetzt gerade wieder wie gewünscht funktioniert hat. --Patrick87 (Diskussion) 18:21, 21. Jul. 2013 (CEST)

Vielen Dank für die Fehlermeldung. Fix ist live! PS: Danke Rillke auch für Code-Vergleiche. -- ΠЄΡΉΛΙΟ 17:14, 25. Jul. 2013 (CEST)

Graue Signaturen

Hi Perhelion,

ist es Absicht, dass seit Spezial:Diff/131278717 Signaturen von einem <span style="white-space:nowrap;color:#789"> umschlossen werden? Wäre kein Problem (ist ja konfigurierbar), wollte nur nachfragen ob du hier bewusst auf die Standard-Signatur ohne jegliches Styling verzichtest, oder ob das aus versehen in den Code gerutscht ist.--Patrick87 (Diskussion) 16:38, 17. Jun. 2014 (CEST)

Hej Patrick,

danke fürs Feedback. Ja, das war sozusagen ein frecher Vorstoß bzw. Anstoß als Empfehlung. Für Meinungen bin ich natürlich offen. Ich finde es eine sinnvolle Ergänzung mit Wiedererkennungswert! Übrigens habe ich mir das nicht ausgedacht sondern einfach von der mw:Extension:LiquidThreads bereits lange Zeit eingesetztem Style übernommen (den Leerraum Zwischen Name und Zeit finde ich ebenfalls sehr ansprechend, habe ihn aber nicht standardmäßig gesetzt). Ich hoffe mit der neuen Version ist das merkwürdige Problem auf Commons verschwunden, wenn irgendwas ist, ruhig melden. → User: Perhelion   17:22, 17. Jun. 2014 (CEST)

PS: Ich muss die Dokumentation etwas updaten, bzw ist das Vorgehen noch undokumentiert. So einfach wie mit der normalen „var usersignature“ geht es nicht mehr, da globale Variablen unerwünscht sind im modernen Wiki-Scripting. Du musst config.sigText: "", beim gegebenen Bsp. setzen (ich habe es selber noch nicht :-/). Bin erstmal off. VG → Benutzer: Perhelion   18:53, 17. Jun. 2014 (CEST)

OK, danke… das bekomm' ich hin. Meine Meinung in der Sache willst du vermutlich eher nicht hören, denn die geht so ziemlich in die entgegengesetzte Richtung:

• Erstes Ziel wäre für mich nämlich Einheitlichkeit, d.h. alle Signaturen sollten gleich aussehen (erstmal ganz egal wie). Dann weiß man wie sie aussehen und was man wo zu erwarten hat und muss nicht z.B. erst den Link zur Diskussionsseite hinter einem kryptischen Zeichen suchen (wenn überhaupt vorhanden, bei dir fehlt er ja z.B. Vorlage:Smiley/Wartung/;) ). Dem laufen vom Standard abweichende Signaturen wie sie das Skript produziert natürlich grundsätzlich entgegen.
• Grauen Text mag ich absolut nicht. Das ist anstrengend zu lesen, während es sich doch nicht deutlich vom umgebenden Text abhebt. Wenn, dann lieber eine kleinere Schriftart (siehe unten)
• Das nowrap stört den Textfluss, weil mitunter ein großer Teil der vorigen Zeile leer bleibt. Wenn jede Signatur in einer eigenen Zeile stehen würde, wäre das kein Problem. Da sie das in der Regel aber nicht tun, hat sich zumindest mein Gehirn daran gewöhnt, dass Signaturen auf der gleichen Zeile stehen und „stolpert“ nun über Signaturen die getrennt vom Rest des Beitrags alleine auf einer Zeile stehen.

Wenn ich entscheiden dürfte gäb's deshalb nur „Standard-Signaturen“ (die jedoch vermutlich in ein <span> mit Klassennamen verpackt, sodass sich jeder seine Signaturen so anpassen kann wie er sie mag). --Patrick87 (Diskussion) 20:27, 17. Jun. 2014 (CEST)

@Patrick87:

Wenn das so ist und ich deiner Meinung doch ein höhres Gewicht gebe, würde ich es so machen, dass ich deinen maximalsten Kompromiss als die minimalste Änderung fürs Script setze!? So dass du an deiner Sig gar nichts ändern musst!? (PS: habe gestern noch bemerkt dass die Umgehung mit config.sigText so noch nicht funzt, fix ist schon da aber noch nicht on)

@Grau: Nun wie wäre es wenn ich das Grau einfach dunkler mache (genau genommen ist es ja kein Grau :P), siehe meiner jetzigen Signatur. Mich wundert deine Ansicht in dem Hinblick, dass im LiquidThreads ja sogar noch ein gar nicht so heller grauer Hintergrund ist…

@Smaller: da bin ich mir nicht ganz sicher, dass ist doch eine „größere“ Änderung (dann könnte man gleich aus dem span ein small machen)

@Textfluss: Man könnte es auch gleich so machen (wie im LiquidThreads), dass die Sig immer eine eigene Zeile bekommt!? PS: übrigens entfernt das Script bei kurzen Zeilen das nowrap

An sich wäre es besser wenn dies noch mehr Augen entscheiden würden. (nur nebenbei, in der En. ist Monospace-Schrift z.B über das Tag kbd größer)

PPS: Seit wann gibt's denn bitteschön eine globale.js ?? → Benutzer: Perhelion   10:57, 18. Jun. 2014 (CEST)

Was meinst du mit „maximalem Kompromiss“? Falls du wissen willst was ich „ertragen kann“ Vorlage:Smiley/Wartung/;) : Auf jeden Fall kein Grau, keine variierte Schriftart und keine zusätzlichen Abstände. Bleibt also eigentlich nur die Schriftgröße übrig, sorry…

@Grau: Wer hat denn gesagt, dass ich LiquidThreads und deren Signatur gut finde (und Flow ist sogar noch schlimmer falls du das als nächstes fragst)? Ich finde grauer Text hat eigentlich so gut wie nie eine Daseinsberechtigung (falls du in mein Benutzer-CSS schaust wirst du sogar sehen, dass ich den Body-Font explizit auf #000 festgenagelt habe) und stört ungemein im Fließtext.

@Smaller: War nur ein Vorschlag, weil das in meinen Augen die einzige Variante ist, die den Lesefluss im Vergleich zu einer Standardsignatur nicht stört. „font-size:smaller“ hatte ich nur verwendet weil das „span“ sowieso schon da war und lustigerweise „font-size:small“ größer ist als <small> (was mir zu dem Zeitpunkt nicht bewusst war).

@Textfluss: Wenn du es hinbekommst, dass alle Nutzer ihre Signatur umstellen, dann können wir darüber reden Vorlage:Smiley/Wartung/;) . Selbst dann halte ich das aus Platzgründen jedoch noch für unvorteilhaft. Bezüglich „nowrap“ stört es auch wenn nach einem zehnzeiligen Post die letzte Zeile halb leer ist und die Signatur dann in der nächsten folgt und damit „aus der Reihe fällt“.

Mehr Augen nützen in meinen Augen (ui, Worstspiel…) nichts, denn auch mehr Augen werden die derzeitige MediaWiki Standard-Signatur nicht ändern können. Meine grundsätzliche Einstellung zum Thema (alle Signaturen sollten am besten gleich aussehen) ist nämlich nach wie vor die gleiche.

Achso, es fehlt übrigens auf jeden Fall ein Leerzeichen zwischen Signatur und Post sonst bleibt das letzte Wort jeweils an der Signatur hängen, wenn diese umbricht wie unter Umständen hier:--Patrick87 (Diskussion) 21:39, 18. Jun. 2014 (CEST)

PPS: „global.js“ ist eine „Erfindung“ von mir. In allen WMF-Projekten lade ich kurzerhand die global.js die ich hier auf dewiki gespeichert habe in meiner „common.js“ mittels mw.loader.load('//de.wikipedia.org/w/index.php?title=User:Patrick87/global.js&action=raw&ctype=text/javascript'); --Patrick87 (Diskussion) 21:45, 18. Jun. 2014 (CEST)

Du machst mich schwach. Ja war bisschen seltsam ausgedrückt (ich meinte dein Kompromiss ist das maximalste was geändert wird, also in dem Fall kleines Datum), habe "Farbe" und "nowrap" aus der Standard-Sig wieder rausgenommen. Das Leerzeichen ist nun standardm. drin.

@global.js: Erzähl mir doch keine Schoten! Extension:GlobalCssJs

PS: Augen: Diese Woche werde ich das alles in den Hintergrund (um nicht zu sagen in den Schatten) stellende 120 teilige Pidgin-Emotion-Set uppen!

→ User: Perhelion 12:20, 19. Jun. 2014 (CEST)

Hi Perhelion, danke fürs ändern, auch wenn immer noch ein " " drin ist Vorlage:Smiley/Wartung/:-d . Tatsächlich habe ich die kleinen Daten bereits auf allen Wikis einheitlich (bis auf dewiki) dank "Comments in Local Time".

• Kleine Frage zum Code: Meinst du, es wäre möglich den lesbaren aktuellen Code auf einer separaten Seite auszulagern (beispielsweise signing_uncompressed.js und die jeweilige "komprimierte" Version direkt unter signing.js? Das macht es einfacher Änderungen zwischen den Versionen mitzuverfolgen (vielleicht gibt's dafür sogar einen Bot?).
• global.js: Erfunden habe ich das ganze natürlich nicht. Da es die von dir verlinkte Erweiterung bei uns aber noch nicht gibt, habe ich eben mit "Hausmitteln" etwas zusammengebastelt und das mw.loader.load() von oben per Bot auf alle Wikis übertragen. Irgendwann sollen aber tatsächlich auch hier globale CSS und JS kommen (hab ich mal gelesen, hab aber grad keinen Link zur Hand).
• Smileys: Cool... wirst du denn dann {{Smiley}} aktualisieren? Oder kommen die Emoticons erst mal nur optional zur freiwilligen Verwendung nach persönlicher Vorliebe?

--Patrick87 (Diskussion) 13:07, 19. Jun. 2014 (CEST)

• @Code: habe ich tatsächlich unkomprimiert und kommentiert noch woanders rumliegen. Werde gleich die Doku updaten (liegt auf dem Beta-Wiki).
• @Smileys: Ja evtl. allerdings würde ich das nicht einfach so machen sondern per kleiner (Augen-) Umfrage!?
• @Diskussions-Link: Brauche ich nicht. Ich schaue mir immer gerne erst die Benutzerseite an. Und wenn nicht habe ich noch Popups. Ich finde das ehrlich gesagt ziemlich redundant, so ist z.B. mein Sig-Code schmaler als deiner ohne Formatierung!
• Da hast du mich auf eine Idee gebracht, die mir schon einmal kurz in den Sinn gekommen war, wie wäre wenn das Script schon eine passende Reply-Einrückung vorlegt!?! Ich glaube manche Leute merken gar nicht was sie eigentlich für sinnlose archaische Sachen tun müssen um hier einfach Kommentare zu schreiben. Irgendwie ist das Script nun reif auch mal etwas mehr offensivere Promotion zu erhalten. Ich mache mal eine Anfrage auf der En. UserScript-Seite. → User: Perhelion  22:29, 19. Jun. 2014 (CEST)

@Patrick87 Dickes Leerzeichen ist nun wieder raus. Dafür ist nun neues besagtes Gimmick drin, ich hoffe es gefällt. → User: Perhelion 01:16, 24. Jun. 2014 (CEST)

Ja, gefällt mir gut! Sehr schönes Feature. Bin mal gespannt wie es sich im Praxiseinsatz bewährt und werde bei etwaigen Problemchen natürlich berichten. --Patrick87 (Diskussion) 01:38, 24. Jun. 2014 (CEST)

Automatische Einrückung

• Hi, ich denke es ist Zeit für einen neuen Abschnitt Vorlage:Smiley/Wartung/;) .
  Meinst du es wäre möglich das Eingabelfeld auch gleich bis zum Ende zu scrollen? Der Cursor wird ja bereits an der richtigen Stelle platziert, nur muss ich bei langen Abschnitten doch erst manuell bis ans Ende scrollen. (Anmerkung: Kann auch nochwas mit dem syntachighlight.js zu tun haben, denn nach dem Laden der Seite hat bei mir definitiv nicht das Eingabefeld den Fokus, wodurch ich auch nicht einfach drauflos schreiben kann. Das werde ich bei Gelegenheit nochmal genauer untersuchen). --Patrick87 (Diskussion) 02:08, 24. Jun. 2014 (CEST)

Hej,
@Scroll: das ist eine sehr gute Idee! Werde ich gleich umsetzen, dafür gibt es sogar eine mw-Variable (scrollTop) somit auch eine hauseigene JS-Funktion die ich nur irgendwie aktivieren muss! Das Verhalten ist bei mir genauso, am Syntax[]highlight[er] liegt es jedenfalls auch nicht.

@Test Einrückung: Mir ist gerade eingefallen, dass ich wieder eine Ausnahme für Seiten in der Art Grafikwerkstatt einbauen muss (kann).

Noch eine Idee, ich könnte automatisch wenn die Sig gesetzt wurde ein „@“ in den ZusammenfassungsKommentar setzen (falls leer, so wie es manche auf Commons tun)!?
Einen guten Tag, bis dann. → User: Perhelion 09:17, 24. Jun. 2014 (CEST)

Nö, lieber nicht. „@“ habe ich sowieso noch nie verstanden und wenn sich der entsprechende Nutzer nicht die Mühe macht was sinnvolles in die Zusammenfassungszeile zu schreiben, dann kann sie genauso gut auch leer bleiben. --Patrick87 (Diskussion) 13:09, 24. Jun. 2014 (CEST)

@Patrick87 Du hast Recht, neue Version ist nun live (Quelltext-Kommentare werden nun ebenfalls übersprungen, wie erwähnt). → User: Perhelion 21:19, 29. Jun. 2014 (CEST)

Super, danke! Scroll funktioniert bei mir jedoch noch nicht richtig: Das Dokument springt zwar während des Ladevorgangs mal kurz nach unten, jedoch kurz darauf wieder zurück an den Anfang. Vermutlich irgendeine Inkompatibilität mit einem anderen Benutzerskript… Werde ich bei Gelegenheit mal testen. --Patrick87 (Diskussion) 22:20, 29. Jun. 2014 (CEST)

Hm* ok, ja da muss irgendwas nachträglich dazwischen funken, habe bei mir überall getestet, da funzt es (also EN, COM, DE – FF, Chrome). Ich kann mich bei Gelegenheit ja auch mal auf die Suche machen… → User: Perhelion 10:47, 30. Jun. 2014 (CEST)

OK, Problem ist definitiv Dot's syntax highlighter. Sobald der (nach signing.js) geladen wird, springt das Eingabefeld wieder an den Anfang zurück. Kannst du das irgendwie verhindern? Ansonsten ist User:Remember_the_dot auch sehr hilfsbereit bei solchen Problemen, vielleicht kann man da auch was auf seiner Seite drehen? --Patrick87 (Diskussion) 00:00, 1. Jul. 2014 (CEST)

Aja, das kann ich jetzt replizieren. Ich habe mir das mal kurz angeschaut, Remember the dot verwendet (unglücklicher Weise?) einen Timer der eine 2. Textbox generiert. Mir fällt dazu nix ein, außer dass ich selber einen Timer generiere. Das geht doch ungeahnt tiefer in die Materie für mich (vlt. ist es auch ganz simple und eine Anfrage in der JS-Werkstatt würde es auch tun). Ich hatte ihn schon vorher auf Schnarks (Fork?) aufmerksam gemacht (wofür er sich bedankte), denn damit gibt's das „Problem“ nicht. → User: Perhelion 13:11, 1. Jul. 2014 (CEST)

@Patrick87 War eine gute Idee… „Vergiss den Punkt nicht“ hat einen Fix eingespielt. Bei mir ist das Problem nun verschwunden…

Was hältst du von einem automatischen Od bei Einrückungsbruch? → User: Perhelion 21:36, 1. Jul. 2014 (CEST)

Super… fast perfekt jetzt! Nur fast, weil das Bearbeitungsfenster nach dem Laden der Seite noch nicht den Fokus hat, d.h. man nicht direkt drauf los tippen kann, sondern erst einmal ins Bearbeitungsfenster klicken muss. Das ist bei dir aber auch so, oder habe ich hier irgendwas komisches am Laufen? Tritt nämlich auch ohne alle Benutzerskripts auf.
Was meinst du mit automatischem Outdent? Dass automatisch dir Vorlage eingefügt wird, wenn man die Einrückung manuell löscht? Wäre vielleicht nicht so super, da man ja oftmals bewusst auf „Ebene 0“ anfängt, ohne direkt auf den Vorredner Bezug zu nehmen. --Patrick87 (Diskussion) 23:06, 1. Jul. 2014 (CEST)

Du machst mir Freude Habe dieses (immer noch) undokumentierte MediaWiki eigene jQuery-Modul „textSelection“ hinzugefügt (daher Funktionen aus dem Quelltext ausgelesen, dabei auch einen kleinen Fehler im Modul entdeckt, die einzig etwas konkretere Erwähnung die ich gefunden habe, ist die von PerfektesChaos Wikipedia:Technik/Skin/JS/jQuery#jquery.textSelection). Allerdings ist es hier wie mit dem Scroll, mit der „Vergiss den Punkt nicht“ Version funzt es nicht, wiederum im Gegensatz zu Schnarks Version! Ich werde ihn wohl auch diesmal anhauen, obwohl du auch gleich Schnarks Version benutzen könntest.

@Outdent: hast du wohl Recht, habe mir überlegt eventuell einen Button dafür zu machen (ohne Template, quasi die gesubste Variante)

@Einrückung: sind mir jetzt noch 2 momentane Schwachstellen aufgefallen (die ich hier kurz festhalten möchte). 1. Im besonderen Fall der Einrückung vor einem „Versteckten“-QT-Kommentar und dieser nicht genutzt wird, wird dieser auch nicht aut. entfernt. 2. Bei einer abschließenden Einrückung ohne Text wird diese einfach (immer) entfernt, was in einem gewünschten Ausnahmefall natürlich ein (stylistisches) Problem sein könnte, nämlich einzig als Einrück für die Sig. → User: Perhelion 09:42, 2. Jul. 2014 (CEST)

┌─────────────────────────────────┘
So, jetzt muss ich doch nochmal kurz nachhaken: Das Bearbeitungsfenster sollte doch jetzt eigentlich nach dem Laden der Seite fokussiert sein (und der Cursor an der Richtigen Position stehen), richtig? Funktioniert das bei dir und wenn ja in welchem Browser? Ich habe jetzt nämlich mal alle Benutzerscripts und Gadgets testhalber deaktiviert und trotz allem wechselt der Fokus bei mir in Firefox 30 nicht zum Eingabefenster. Im Internet Explorer 11 funktioniert es hingegen. Liegt das nur an mir (keine Ahnung dann warum), oder bin ich hier auf eine Kompatibilitätsproblem im Firefox gestoßen? --Patrick87 (Diskussion) 22:52, 2. Jul. 2014 (CEST)

Tatsächlich, neue Version ist nun live mit allen erwähnten Fixes. (PS: War nicht unbedingt negativ gemeint mein letzter Kmt) → User: Perhelion 12:54, 3. Jul. 2014 (CEST)

Super, danke! Funktioniert jetzt Vorlage:Smiley/Wartung/:) . (War auch nicht negativ verstanden dein letzter Kmt). --Patrick87 (Diskussion) 23:50, 3. Jul. 2014 (CEST)

Gut . Angesichts des doch relativ großen Code-Eingriffs, ist hier eine weitere Testphase angebracht.

PS. Smiley-Set: Ich musste gerade leidlich feststellen, dass die Wikieditor-Bar eine Grenze von 50 hat. (eine Lösung wird natürlich gesucht). Das mit dem Pidgin-Set hat natürlich nicht gefunzt, etliche Schwierigkeiten (das export Script funzt auch nur mit Inkscape Beta). Ich habe es leider nur soweit geschafft dass vereinzelte (da manche einfach mit einem undefinierten Fehler abbrechen) Smileys (bei richtiger Größe) stets falsch im Koordinatensystem hinterlegt werden. → User: Perhelion 12:29, 4. Jul. 2014 (CEST)

Problem mit Zeilenumbrüchen

Hi Perhelion, in der aktuellen Version des Scripts hat sich ein Fehler eingeschlichen: Wenn man vor dem Beitrag von jemand anders etwas einfügen möchte, also z.B. folgende Situation

:: Beitrag 1
::: Hier will ich meinen Beitrag schreiben
:: Beitrag 2

dann wird beim Signieren der Zeilenumbruch vor :: Beitrag 2 entfernt, und "Beitrag 2" klebt somit direkt an meinem Einschub.

Darüberhinaus ein Verbesserungsvorschlag: Im Moment wird vor der vom Skript erzeugten automatischen Einrückung eine Leerzeile eingefügt. Ich denke hier sollte keine Leerzeile stehen, ansonsten erzwingt man ja das erzeugen einer neuen HTML-Liste. --Patrick87 (Diskussion) 01:07, 7. Sep. 2014 (CEST)

@Patrick87: Ist gefixt (hoffe ich), danke dir (ich hatte dies selber nicht bemerkt, da ich unverständlicher Weise einen Zeilenumbruch in meiner Signatur-var habe). Allerdings sollte der Fehler schon in vorhergehender Version gewesen sein. Das mit der Extra-Leerzeile war so eine Idee (seit dem ich den Syntaxhighlighter benutze ist das für mich optisch eigentlich auch überflüssig) aber ich denke du hast recht (und habe sie entfernt). Einen schönen Sonntag noch PS (FYI?): die global.js und die Smilie-Bar sind ja nun auch beide live! → User: Perhelion 16:07, 7. Sep. 2014 (CEST)

Super, danke für den schnellen Fix!
Leider habe ich direkt ein neues Problem entdeckt (oder ist das Absicht?): Die automatische Einrückung ist nun auf dem gleichen Level wie die des Vorredners? Ich antworte nämlich gerade auf dem gleichen Level wie du! --Patrick87 (Diskussion) 16:31, 7. Sep. 2014 (CEST)

erledigtErledigt Oh ja da hatte ich wohl zuviel gelöscht (tritt tatsächlich allerdings nur auf wenn die Einrückung 1 Zeichen ist, da ich auch auf Vote-Seiten eine Einrückung setze). Naja mal sehen was aus dem Script wird, es ist nun eigentlich ready für Schnarks Fliegelflagel. Das "Flow" kommt ja auch bald. → User: Perhelion 17:17, 7. Sep. 2014 (CEST)

Super,danke! --Patrick87 (Diskussion) 17:42, 7. Sep. 2014 (CEST)