Benutzer Diskussion:Schnark

Automatische Archivierung

Auf dieser Seite werden Abschnitte sonntags automatisch archiviert, deren jüngster Beitrag mehr als 30 Tage zurückliegt und die mindestens einen signierten Beitrag enthalten. Die Archivübersicht befindet sich unter Archiv. Das momentan verwendete Archiv ist Archiv 2.

Bugreport Benutzer:Schnark/js/specialinterwiki.js

Hallo Schnark. Wenn ich das Script aktiviert habe, sind beispielsweise bei der Beobachtungsliste die Links auf der Höhe des Interwikis insensitiv (nicht anklickbar). --Leyo 14:09, 13. Apr. 2011 (CEST)

Immer diese Monobook-Benutzer mit Extra-Wünschen … :-) Sollte jetzt funktionieren. --Schnark 09:12, 14. Apr. 2011 (CEST)

Tut es, danke! --Leyo 17:19, 14. Apr. 2011 (CEST)

Benutzer:Schnark/js/watchlisttags.js

Wie genau hat die Konfiguration der Tags auszusehen? Ich habe im Quelltext keine Möglichkeit gefunden, die Standardtags zu überschreiben.

Gruß --Steef ³⁸⁹ 22:57, 13. Apr. 2011 (CEST)

Im Prinzip genau so, wie du es gemacht hast, nur darf dieser Code erst dann ausgeführt werden, nachdem das Skript geladen ist. Kürzeste (und zugleich hässlichste Lösung):

importScript('Benutzer:Schnark/js/watchlisttags.js').onload = function () { //[[Benutzer:Schnark/js/watchlisttags.js]]
 watchlisttags.userinterface.tags = ['(Normal)', 'Eigen', 'Meta', 'Archiv', 'Bots'];
};

Und natürlich auch Benutzer:Schnark/js/watchlisttags#CSS nicht vergessen. --Schnark 09:21, 14. Apr. 2011 (CEST)

Das funktioniert so leider nicht, da das onload erst ausgeführt wird, sobald das Script fertig geladen ist (und somit init schon ausgeführt wurde). Wenn ich das richtig sehe, müsste es über dein Verwaltungscript und die after-Funktion möglich sein.

CSS habe ich nicht vergessen, kommt schon noch ;) --Steef ³⁸⁹ 16:02, 14. Apr. 2011 (CEST)

Habs jetzt so gelöst. Gruß --Steef ³⁸⁹ 16:08, 14. Apr. 2011 (CEST)

@}━‘━━,━━

Es ist eine stete Freude, mit Dir zusammenzuarbeiten.
Ich wünsche Dir Glück und Erfolg bis zum Optimum.
--PerfektesChaos 00:06, 14. Apr. 2011 (CEST)

Danke! Wie schwierig war es, Zeichen zu finden, die antispoof nicht anmeckert? --Schnark 09:25, 14. Apr. 2011 (CEST)

Bitte, gern geschehen. – Zwei Iterationsschritte im Sandkasten, und Erfahrung mit der Phantasie von WP-Autoren beim Nutzen deplatzierter Unicode-Blöcke. Dass nach dem Speichern das [Bearbeiten] so dicht stehen würde, hatte ich nicht bedacht und es auch nicht mehr spoof-frei wegbekommen. Gönn dir mal einen WP-freien Tag --PerfektesChaos 10:13, 14. Apr. 2011 (CEST)

Dumping

Schönen Dank.

• Falls du einen aktualisierten Dump vom Server geholt haben solltest: Mühen mit Zeichencode-Auswertungen musst du dir nicht machen; Asdert und ich haben noch Tausende zur Abarbeitung; zu Weihnachten stünde dann mal eine Erfolgskontrolle an.
• page/seite habe ich dokumentiert gefunden. Hilfe:Bilder müsste nacharbeiten, als Entdecker gebührt dir die Ehre, dies auf HD:Bilder anzuschubsen.
  Für TIFF neben DjVu (erst recht PDF) kenne ich multi-page; seit 10 Jahren wird angekündigt, man könne eine URL schreiben http://.../Langtext.pdf?page=123 oder acrobat.exe -page=123 Langtext.pdf – wäre jetzt möglicherweise realisiert? Mal erforschen.
• DEFAULTSORTKEY / DEFAULTCATEGORYSORT – bugzilla:5908 habe ich gefunden. Obwohl ich übereinstimme (2007-06-08), dass jedes dieser Wörter besser gewählt ist als DEFAULTSORT, sehe ich mich gezwungen, sie künftig mangels Verbreitung und Verständlichkeit durch die lokale Entsprechung zu ersetzen.
• Wenn du den Dump sowieso grad unterm Messer hast:
  • Zur Analyse der Großschreibungsfrage am Anfang von Artikelnamen und abzuleitender Regeln für oder gegen eine Linkziel-Kapitalisierung würde mich eine <PRE>-Liste interessieren nur mit dem Inhalt von DISPLAYTITLE/SEITENTITEL.
  • Neugierig wäre ich auf die Anzahl <references> ohne slash (ggf. group); damit Nutzung des neuen Features als ref-Block am Artikel-Ende.

Ohne Eile mit Genuss --PerfektesChaos 12:33, 18. Apr. 2011 (CEST)

Seite 3 des PDFs

MultiPage-Integration funktioniert in MediaWiki ganz gut. Du kannst page= in der URL verwenden (aber nicht mit "Media:" Bug 4198) und auch eine bestimmte Seite eines PDFs mit normaler Dateisyntax einbinden. Hier finden sich übrigends alle möglichen Aliase von Magischen Wörtern. Der Umherirrende 21:28, 18. Apr. 2011 (CEST)

[1] finde ich lesbarer; solange niemand auf die Idee kommt, die ParserFunctions einzudeutschen, steht dort ja alles relevante.

Wartungslisten: Ich habe nur ein paar von den kleinen neu erstellt, und auch gleich wieder abgearbeitet, eigentlich wollte ich nur die Leistungsfähigkeit eines 4-GB-USB-Sticks testen, da bot sich der Dump an.

Bildparameter: sub und sup sind auch nicht dokumentiert.

DEFAULTSORTKEY / DEFAULTCATEGORYSORT: Als ich die zum ersten Mal in Stefans PD-Wartungsskript sah, wäre ich beinahe wahnsinnig geworden. Totschweigen funktioniert aber zuverlässig wie man sieht.

DISPLAYTITLE/references: Lässt sich machen. --Schnark 09:35, 19. Apr. 2011 (CEST)

Direkt ins SVN zu schauen geht auch, aber das translatewiki hat auch eine Oberfläche dafür (steht natürlich noch einiges mehr dabei). Die API hat aber den Vorteil das dort direkt dabei steht, ob case-sensitive oder nicht, und man nicht erst die Zahl interpretieren muss und sie zeigt alles an, was gerade online ist. SVN/translatewiki ist ja manchmal zu modern. Der Umherirrende 19:32, 19. Apr. 2011 (CEST)

Die Anzeige von translatewiki ist auch nett. Der Vorteil von MessagesDe.php ist die Tatsache, dass man diese Datei „höchstwahrscheinlich“ auch im lokalen Dateisystem hat, und nicht unbedingt online sein muss.

Zu den gewünschten Zahlen und Listen:

bzgrep -c '<\s*references[^/]*>' /media/disk/dewiki-20110410-pages-articles.xml.bz2 ergab 6998, die Liste der DISPLAYTITLEs ist unter Benutzer:Schnark/Wartung/Displaytitle, nachdem du gezählt hast, was du zählen wolltest, kann irgendjemand bei Interesse die Fälle abarbeiten, wo offenbar jemand keine Ahnung hatte, wie DISPLAYTITLE funktioniert. --Schnark 09:23, 20. Apr. 2011 (CEST)

Besten Dank.

• 7000 references-Blöcke sind gut zu wissen; auf WP:EN / WP:LIT gibt es (geisteswissenschaftliche?) Diskutanten, die behaupten, dass dieses den Quelltext entlastende Feature ja sowieso von niemandem benutzt wird.
• Die TITLE werde ich syntaktisch analysieren und Unsinn aus Artikeln löschen.
• In meinem Quelltext sehe ich künftig vor, zunächst nach {{DEFAULT statt bisher {{DEFAULTSORT zu suchen und gefundenes Element danach differenziert zu betrachten. Damit kommt es für die Skript-Anwender nicht zu zeitlichen Verzögerungen beim Durchsuchen des gesamten Wikitextes nach etwas, was ohnehin nullmal vorkommt. In Projekten, in denen die nachträglichen Varianten nicht propagiert werden, wird auf die jeweilige Standard-Syntax umgestellt.
• Das seite/page im Bildchen ist ja durchaus sinnvoll zu benutzen.
  • Seit langer Zeit steht in der Adobe-Werbung, man könne aus einer PDF-Datei Seiten/-bereiche extrahieren. Vor einigen Jahren kämpften Kollegen mal vergeblich damit, den Server-acrobat davon zu überzeugen, nur ein page=123 oder page=210-217 über das Netz auszuliefern statt des halben GB; oder die Browser-Plugins verstanden noch nicht, was der Server generierte? Ich wurde hinzugebeten und hatte es auch nicht hacken können.
  • Was die Bildchen-Parameter sub und sup bringen sollen, ist mir rätselhaft. Lieber verschweigen, bevor jemand damit Unsinn anstellt.

Sonne für alle --PerfektesChaos 09:51, 20. Apr. 2011 (CEST)

Auf Grund der Dinge, die bei der von Umherirrender verlinkten translatewiki-Seite in der Nähe von sub und sup stehen, behaupte ich einfach mal ohne es zu wissen, dass es sich um die vertical-align-Eigenschaft handelt. --Schnark 10:00, 20. Apr. 2011 (CEST)

• vertical-align assoziiere ich mit top und bottom – ein Grund mehr, es nicht zu kommunizieren, erst recht so lange niemand eine sinnvolle Layout-Anwendung dafür beschrieben hat.
• Ich plane, über die Osterfeiertage mein Skript dahingehend zu erweitern, dass bei kodierungsmäßer Identität von DISPLAYTITLE/etc. und wgPageName unter Respektierung notwendiger Escapes der DISPLAYTITLE aus dem Wikitext entfernt wird, und die Experimentalversion an deiner Liste zu erproben; vermutlich auch Kursiv-Formatierung zu entfernen.

--PerfektesChaos 10:25, 20. Apr. 2011 (CEST)

Die kursiven Lemmata sind in der Biologie so üblich, bei power-on self-test dagegen Unfug. Ob man sich Freunde macht, wenn man in Fällen wie Arch+ den DISPLAYTITLE entfernt, weiß ich nicht, zwar bewirkt er sowieso nichts, aber Eigenschreibweisen sind ein Minenfeld. Bei Fällen wie Alliance (Anwendung) kann man das Ding aber eindeutig entfernen. --Schnark 10:37, 20. Apr. 2011 (CEST)

Ack – dass es offenbar in Chemie und Bio Sonderwege gibt, legt die Masse der Benutzung nahe, auch wenn das unmöglich bereits einheitlich die gesamte Biologie sein kann. Beim Lesen chemischer Bezeichnungen mag einem das irgendwie weiterhelfen. Automatisches kursiv ist wieder vom Tisch, war nur der allererste Eindruck.

Das + (URLencode) wie auch _ und : neben []<> und & hatte ich zu respektieren beabsichtigt. Sinnvolle HTML-Tags unterscheiden sich ohnehin vom wgPageName und wären punktuell manuell auszulichten; alle <sub> sind pauschal okay.

--PerfektesChaos 10:54, 20. Apr. 2011 (CEST)

Sodele, die Liste ist soweit analysiert. Allerdings gibt es noch einige seltsame Kandidaten, die ich dich bitte zur vorbeugenden Bekämpfung potentieller Langeweile gelegentlich im Dump aufzufischen; diese Titel stehen möglicherweise über den falschen Artikeln.
Andere suchen Ostereier von Bugs Bunny, wir suchen Osterbugs --PerfektesChaos 21:57, 20. Apr. 2011 (CEST)

„Neuer Artikelname“ habe ich mit der Suche gefunden: Wikipedia:Bots/Anfragen/Archiv/2007-2#Vorlage:Korrekter Titel ersetzen durch MagicWord DISPLAYTITLE (zurückgezogen), die anderen verstecken sich besser, sollten aber ähnlich interessant sein. Zu deiner Preisfrage: Bei Capgemini sd&m AG weicht der DISPLAYTITLE vom Titel ab, deswegen wird der Titel angezeigt. Eine Verschiebung auf den Titel ohne AG wäre durch WP:NK#Unternehmen gedeckt, wenn du es nicht tust, werde ich es irgendwann tun. <span style="text-transform:lowercase">e</span>Rockit ist wirklich hübsch. Was du unter „Legitim“ aufgelistet hast, gehört da meist nicht hin, bei Film & TV Kameramann funktioniert es auch ohne DISPLAYTITLE, bei den meisten anderen kann es einfach nicht mit DISPLAYTITLE funktionieren, was bedeutet, dass man den Artikel entweder verschieben muss, oder {{Korrekter Titel}} notwendig ist. Irgendwie habe ich das Gefühl, dass einige hier meinen, DISPLAYTITLE sei dazu da, gegen WP:NK zu verstoßen. abgegangene Burg kleinzuschreiben ist auch Unfug, erstens sieht man das bei einer Weiterleitung ohnehin nicht, außerdem gibt es keinen Grund dafür. --Schnark 09:35, 21. Apr. 2011 (CEST)

• „Legitim“ meint nur, dass mein geplanter Skript-Umbau es in Ruhe lassen soll, ohne Aussage über die inhaltliche Sinnhaftigkeit.
• Ich plane ein, dass es eines Tages eine bessere Funktionalität von DISPLAYTITLE geben könnte, die die momentane Beschränkung aufhebt (Hilfe:Variablen#Funktionen „Hierbei arbeitet die Parserfunktion aber nur, wenn der Seitenname nur in Groß- und Kleinschreibung oder von Formatierungselementen vom angegebenem Namen abweicht.“). Ich halte dies für Quatsch; wollte mal sehen, ob du aufpasst.
• Aus diesem Grund nehme ich potentielle Syntax-Sonderbedeutungen von automatisierten Manipulationen durch meine vorgesehene Skript-Erweiterung grundsätzlich aus. Sie müssten allerdings auch immer zu einer Abweichung von DISPLAYTITLE führen, aber das halbe Dutzend Ausnahmen nehme ich hin.
• Wenn allerdings Großschreibung vorliegt und DISPLAYTITLE buchstabengetreu mit wgPageName übereinstimmt, ist es Totaldummfug.
• Mein erster workaround-Versuch erzielte immerhin einen Teilerfolg; scheitert aber zurzeit am content-Attribut in CSS und dessen Wirkung primär auf :before und :after.

Einen neuen Sandkasten entdeckt, ich hatte schon immer ein Faible für Förmchen --PerfektesChaos 10:42, 21. Apr. 2011 (CEST)

Eine DISPLAYTITLE-Version, die auch Änderungen an der Groß-/Kleinschreibung im Inneren zulässt, ist einfach Unfug: Wer meint (unabhängig von den Konventionen und davon, dass hier noch Klammerzusätze für die BKL nötig wären), dass Arch+ eigentlich ARCH+ heißen sollte, der soll es dahin verschieben und nicht darauf hoffen, dass irgendwann einmal das Verhalten von DISPLAYTITLE geändert wird. Dass ein display:none zulässig ist, ist auch ein Bug und kein Feature. --Schnark 10:57, 21. Apr. 2011 (CEST) PS: Übrigens danke für diese Änderung, ein netter Testfall für Diff-Algorithmen, die Blockverschiebungen erkennen sollen. Sowohl wikEdDiff (zumindest soweit ich mich erinnere) als auch mein eigener Diff-Algorithmus scheitern im Augenblick noch daran.

@Block-DIFF: Tja, das war das alphabetische Sortieren der Einzelzeichen in Vorbereitung auf das Strukturieren und Ergänzen; die bisher wilde Ansammlung vorbereitend auf das, was ich dazu noch in der Pipeline habe. Ob das Diff im zweiten Iterationsschritt eher konveniert? Frohe Ostern --PerfektesChaos 12:10, 24. Apr. 2011 (CEST)

Mein Diff-Algorithmus wird zwar durch deine letzte Änderung sehr strapaziert (er erkennt mehr verschobene Blöcke, als es CSS-Definitionen gibt, was sich etwas ungünstig auf die Darstellung auswirkt), aber er scheint korrekt zu sein. Falls du gerade WikEd aktiviert hast, würde es mich schon interessieren, was dessen Diff tut. --Schnark 09:42, 26. Apr. 2011 (CEST)

WikEd sieht irgendwie so aus, als ob man es nachvollziehen könnte, wenn man es wollte. Allerdings sind Mensch und Maschine am Limit.

Mit CSS-Definitionen meinst du vermutlich die Block-spezifische Farbfolge blasspink-hellblau-violett-gelb-… der Zuordnung von inhaltsgleicher Löschung-Einfügung?

Ich arbeite gerade die Doku zu den diversen Skript-Änderungen einschließlich der Feiertage auf. Zu den DISPLAYTITLE äußere ich mich in einem neuen Fädchen, wenn ich mitdemDenken fertig geworden bin.

Hab’ Frühlingsgefühle --PerfektesChaos 09:57, 26. Apr. 2011 (CEST)

Die Tatsache, dass WikEdDiff nur Überschriften als verschoben markiert, spricht irgendwie dafür, dass da ein Wurm im Diff steckt. Und ich meinte die Block-spezifische Farbfolge, wie du richtig erkannt hast. Aber für so etwas hat man ja die Web-Developer-Erweiterung mit der Style-Informationen-anzeigen-Funktion. Wer braucht schon Farben, wenn der span eine eindeutige Klasse hat. --Schnark 10:12, 26. Apr. 2011 (CEST)

Danke für die Mühe beim Nachvollziehen meiner Edits; um Maschine durch Mensch zu ersetzen – es haben sich neben der Sortierung nur geändert:

1. Ligaturen als Einzelzeichen belassen
2. Apostroph statt allerlei Strichelchen – Kleinvieh

Ich plane, diese Seite gelegentlich noch um einige Abschnitte zu ergänzen und danach eine synchronisierte .js-Seite zu schreiben, die ich selbst in mein Standardprogramm includen kann, aus der aber auch andere mit C&P herausschneiden können und die eine verantwortbare load-Version für schlichtere Benutzer wäre. --PerfektesChaos 10:53, 26. Apr. 2011 (CEST)

Es geht mir weniger darum, deine Änderungen nachzuvollziehen, als vielmehr darum, Bugs in meinem Diff-Algorithmus zu finden. Aber die Tatsache, dass Benutzer:Schnark/js/artikel-statistik.js jetzt sogar bei Artikeln mit über 200 Versionen plausible Ergebnisse liefert, spricht dafür, dass ich inzwischen die Bugs gefunden und beseitigt habe. --Schnark 11:04, 26. Apr. 2011 (CEST)

Beeindruckend. core.js enthält eine Kopie von Cacycle's diff.js und das ist der Algorithmus, den ich von WikEd kenne? --PerfektesChaos 11:40, 26. Apr. 2011 (CEST)

Cacycles Skript besteht aus einem mir völlig unverständlichen Frontend und einem Backend. Kopiert habe ich nur eine Funktion (nämlich die einzige, deren Korrektheit ich ihm einfach mal glaube, die ich aber nicht so gut verstehe, dass ich sie selbst schreiben wollte). Aufgefallen, dass sein Diff-Algorithmus in einigen Fällen fehlerhaft ist, ist mir beim Programmieren von Benutzer:Schnark/js/artikel-statistik.js, seine Reaktion auf meine Fehlermeldung ist (wie ich eigentlich auch nicht anders erwartet habe) sehr träge. Also musste ich meinen eigenen Algorithmus schreiben und hoffen, dass er weniger Fehler hat. --Schnark 11:52, 26. Apr. 2011 (CEST)

Mein Respekt. Zu Zeiten, als man noch auf Papier ausdruckte, gab es über Diff-Algorithmen ganze Regalwände; heute sind es wohl TB. Anspruchsvoller dürfte allenfalls SORT sein; damit müsste man einen eigenen Raum einer klassischen IT-Bibliothek füllen können. --PerfektesChaos 12:22, 26. Apr. 2011 (CEST)

Das ist der Vorteil, wenn man Mathematik, aber nicht Informatik studiert: Man hat eigentlich keine Ahnung, welche Algorithmen es gibt, sondern bastelt halt nach eigenem Gutdünken das Ding so zusammen, wie man denkt, dass es passt. Außer Heckels Algorithmus habe ich eigentlich nichts gelesen, und in dieser Beschreibung ist das Ende irgendwie sehr abrupt. Der größte Nachteil, der dadurch entsteht, wenn man als Mathematiker einen Algorithmus entwickelt, ist die Tatsache, dass man sich über die Komplexität kaum Gedanken macht. Wenn es überhaupt einen Algorithmus gibt, ist es gut, wenn er polynomiale Laufzeit hat, perfekt. Und wenn man einen O(n⁷)-Algorithmus gefunden hat, wo es eigentlich auch einen O(n*log(n))-Algorithmus gäbe, stört einen das nicht weiter. --Schnark 12:32, 26. Apr. 2011 (CEST)

Wenn ihr schon über Diffs auslasst (wo ich interessiert mitlese, aber keine Ahnung von habe), habt ihr euch mal die Bugs zu wikidiff2 (der von WMF verwendeteten Extension) angeschaut? Ich hatte mal vor langer Zeit Bug 23704 erstellt, aber hat sich noch keiner dran getraut. Wie sieht das bei euch aus? Wenn man mit Whitespaces gut umgehen kann, dann ist (für mich) viel gewonnen, da es nervig ist, solche Änderungen zu suchen. Bug 21351 zielt auch in die Richtung von Whitespace-Änderungen. Der Umherirrende 19:53, 26. Apr. 2011 (CEST)

Ich fühle mich pudelwohl auf Schnarks Disku-Sofa, lümmele mich zurecht und mache mal einen neuen thread auf, bevor diese Dumpanalyse-Displaytitle-Diff völlig zerfranst. --PerfektesChaos 21:23, 26. Apr. 2011 (CEST)

Diff

Zu eben ein paar Anmerkungen:

1. Wenn in Schnarks .js neue Probleme auftreten sollten oder es bei Mediawiki Anlass zur Unzufriedenheit gibt:
   • Mal die üblichen Verdächtigen, OpenSource-Libraries usw. flöhen, ob da etwas Besseres lauert. Ich weiß grad nicht, wo die Implementierung auf unserem PHP herkommt, aber ich wäre nicht überrascht, wenn sich dessen Quelle da irgendwo wiederfindet – und wir haben natürlich auch brav der Herkunft credits gegeben; für Cacycle desgleichen.
   • Vielleicht gibt es aber eine simplere Lösung bei WMF; möglicherweise ist der mit GCC übersetzte Kram auf dem Server ein bekannteres Werkzeug, zu dem es Dokumentationen gibt, und wo sich dann vielleicht eine der 50 Optionen besser an Wikitext anpassen lässt. Ich finde mich mangels HTML-durchbrausbarer Strukturschemata und Dokumentation überhaupt nur mit Mühen in unserer Server-Software zurecht und freue mich, wenn ich mal wieder den aktuellen PHP-Quelltext nachvollziehen kann. Any links?
   • Ich bin im Lauf der Jahre immer mal wieder durch GNU u.v.a.m. gestolpert und meine, hin und wieder in Libs passable Algorithmen gesehen zu haben, die auch WP-kompatible Rechte hätten; natürlich bringen wir mit Dank irgendwelche copyleft unter.
   • Als Sprachen für einen wirklich guten stuff kämen C++, Java, JS und PHP in Frage. Die Programmlogik ist meist kompatibel, die formale Syntax sehr ähnlich, und mit einigen beherzten regexp-replace lassen sich Funktionsaufrufe und overloading in die grad passende Zielsprache konvertieren. Ansonsten müsste eine gute Implementierung ja gekapselt und modular sein.
   • Aus der Vielzahl bereits erdachter Algorithmen (ich erfinde ungern das Rad neu) müsste man was auswählen, was gut zu den Bedingungen von Wikitext und dessen Versionen passt (etwa die whitespace-Frage); es gibt auch welche spezifisch für Binärdaten. Trickreich wäre eine Anpassung an Wikisyntax, etwa Leerzeilen-Absatz und Überschriften zur Gliederung von Chunks.
   • Für die WMF ist eine Alternativ-Implementierung eine international zu lösende Frage; mir eine Nummer zu groß, und ich habe weder die Ressourcen noch die Dev-Einbindung (noch nicht mal bugzilla-account), um hier eine führende Rolle zu spielen.
   • Eine Alternativ-Implementierung lässt sich ja als externes diff einbinden und mit simplen Benutzerrechten praktisch erproben, bis es so toll ist, dass man mit Rückgrat auftreten kann und sagt: Schaut her, wir haben etwas Besseres!
   • Das Farbschema des Gelb- und Grüntons ist exakt von GNU Emacs übernommen.
2. Feuchte Augen bekam ich, als mein Blick in der zweiten Spalte der PDF auf „DEC's FILECOM“ fiel; vor so einer Maschine hatte ich auch mal vorübergehend gesessen, kann mich aber grad nicht mehr an FILECOM erinnern.

Schönen Abend --PerfektesChaos 21:23, 26. Apr. 2011 (CEST)

wikidiff2 ist in C oder so geschrieben, da php wohl zu langsam ist. Die Sourcen finden sich im WMF-SVN, ist HTML durchklickbar, aber nicht durchsuchbar (es gibt aber tools:~krinkle/wikimedia-svn-search). Ein (kompletten) Rewrite des Diff-Tools oder auch von MediaWiki wird man wohl mangels Ressourcen nicht umsetzen können. Der Umherirrende 22:19, 26. Apr. 2011 (CEST)

Ja, C++. Dass es zur Beschleunigung in einer effizienteren Sprache als PHP geschrieben wurde, ist nicht ungewöhnlich. Mit nur 450+70 Zeilen ist das ja sehr überschaubar (mein Skript hier hat 12377). Es ist wohl keiner von den bekannten großen Algorithmen; die Kernaktivität hat 102 Zeilen. Könnte in irgendeinem Lehrbuch stehen, locker 30 Jahre alt. Wenn ich mal Zeit habe, schaue ich, ob mir zu deinen bugzillas etwas einfällt – Space/Zeilenumbruch ließe sich erkennen, überspringen und anders mit CSS versehen.

Durch die Kürze ist die magere Funktionalität plausibel; der in WikEd benutzte mit Block-Tracking spielt in einer anderen Liga.

Schönen Abend erstmal --PerfektesChaos 23:14, 26. Apr. 2011 (CEST)

Als ich mich etwas umgeschaut habe, bevor ich meinen eigenen Diff programmiert habe, bin ich auf [2] gestoßen, das – wenn man auf eine Anzeige von Blockverschiebungen verzichtet – ziemlich gut aussieht. --Schnark 09:22, 28. Apr. 2011 (CEST)

wikidiff2

1. Analyse:
   • Alter: etwa 1970er
   • Typ: Zeilenorientiert; das heißt, dass das '\n' zur Gliederung in chunks genutzt wird:
     ::explodeLines()
   • Algorithmus: schlicht; völlig okay
     (Vorsicht: wesentlicher Teil steht getarnt in DiffEngine.h – wobei .h eine kleine Header-Datei anzeigt; es müsste DiffEngine.cpp heißen.)
2. Hauptproblem:
   • Füge ich eine Zeile ein (etwa == Leben ==), und unterscheidet sich der (unmittelbar ?) nachfolgende Block auch nur durch ein Leerzeichen, findet er seinen Wiederaufsetzpunkt nicht. Das Resultat sind die scheinbar immensen Unterschiede, die durch anscheinend überzählige Blöcke links und fehlende Blöcke rechts suggeriert werden.
   • Ursächlich ist die (erleichternde) Grundannahme, dass der Text zeilenweise abgeglichen werden kann. Die Methodik war mal gedacht für Programmzeilen von 80 Zeichen Länge; Wikitext-Zeilen enthalten aber ganze Absätze mit allerlei Sätzen, die schnell auf 500 bis 1000 Zeichen kommen können.
3. Mein Vorgehen:
   • Das Resultat gibt mir einen ersten Überblick.
   • Wenn es mir zu chaotisch ist, genügt ein Klick auf das grüne Delta und ich sehe WikEd.
   • Ich untersuche Feinheiten bei den Auswirkungen meines Syntax-Skriptes und benötige daher präzise Infos über jedes einzelne Leerzeichen, das mein Skript geklaut oder hinzugefügt hat.
4. Alternativ-Algorithmen:
   • Der momentane Algorithmus ist kurz, simpel und schnell.
   • Ein Austausch des Kerns gegen einen lizenzmäßig zulässigen robusten anderen ist nicht übermäßig schwer; mehr Mühe macht die optische Darstellung des Ergebnisses in HTML.
   • Jeder pfiffigere Code wäre langsamer, würde die Antwortzeiten und Serverlast erhöhen.
   • Deshalb wäre es verständlich, die Kernprozedur mit ihren Unzulänglichkeiten zu belassen.
   • Für den ersten Eindruck der Hunderttausende von Autoren täglich mag es weltweit genügen.
   • Anspruchsvollere Nutzer trennt nur ein Häkchen auf Einstellungen von WikEd.
   • Außerdem gibt es Hilfe:Einstellungen/Externes Diff-Programm verwenden – ist aber eine größere Aktion.
   • en:AWB würde eine auf Wikidiff2.cpp basierende Weiterentwicklung benutzen, die whitespace besser handhaben würde.
5. Verbesserungen innerhalb der momentanen Implementierung:
   1. Bei Zeilen mit mehr als etwa 100/150 Zeichen könnte eine Unterteilung nach Satzzeichen+Leerzeichen erfolgen; der Absatz müsste aber darstellungstechnisch wieder zu einer geschlossenen Zeile zusammengefasst werden.
      Kleine Fummelei, aber machbar; ein kurzer Vektor müsste Buch führen, wo virtuelle Zeilenumbrüche eingefügt wurden, und nach dem Diff im Lichte der gefundenen Unterschiede der bisher genutzte echt zeilenweise Vektor für die Ergebnisanzeige wiederhergestellt werden.
      Vorteil wäre, dass Wiederaufsetzpunkte des unveränderten Textes gefunden würden und die nächste kleine Änderung keine blockweise Darstellung scheinbar dramatischer Veränderungen auslösen würde. Weil die Prüfung auf Gleichheit der kürzeren Zeilen schneller liefe, könnte die Performance im Mittel unverändert bleiben.
   2. Die Darstellung von Leerzeichen-Unterschieden (und nullbreite) könnte ohne größere Beeinträchtigung der Performance verbessert werden. Sie beträfe nur die Darstellung der bereits gefundenen Unterschiede und würde deshalb die Ausführungszeit nur geringfügig erhöhen.
      Dazu habe ich einige Zeilen an CPP-Code skizziert, mit denen ich aber nicht Schnark, sondern demnächst BD:Umherirrender vollmüllen werde.

Käthchen wird selig und der Papst heiratet, dazu soll es regnen; ich werde mich die nächsten Tage in eine stille Ecke verziehen und geduldig tüfteln. --PerfektesChaos 17:59, 28. Apr. 2011 (CEST)

Von C++ und Diff-Tools habe ich keine Ahnung, du kannst gerne die Bugs patchen, vielleicht wird es in den Standard übernommen, darüber würde ich mich schon freuen, vorallem weil ich solche Whitespace-Diffs häufiger produziere. Der Umherirrende 20:18, 28. Apr. 2011 (CEST)

Tja; aber du hat diese Diff-Kiste oben losgetreten, und nun wirst du mit den Folgen auf deiner Disku leben müssen … es hilft ja nicht nur dir, sondern allen Autoren weltweit.

• Du bist bestens in der Techno-Szene vernetzt.
• Du hast einen bugzilla-Account, ich nicht.
• C++ brauchst du nicht; nur Verbündete, deutschsprachig wie international.
• Du bekommst 3 Verbesserungsmöglichkeiten, unterschiedlich intensiv ausgearbeitet, auf Englisch. Bis zum Patch ist es noch ein Stück.

Dann hast du eine konkrete Basis, auf der du mit Gleichgesinnten diskutieren kannst. --PerfektesChaos 22:16, 28. Apr. 2011 (CEST)

Nein, ihr hattet euch darüber unterhalten und habe ich mich (unhöflich) dazwischen gezwängt und damit vielleicht losgetreten, das stimmt.

• Man kennt dort meinen Nick und ich verfolge ab und an die Änderungen/Bugs, ich weiß aber nicht ob ich einen guten oder einen schlechten Eindruck hinterlassen habe, vorallem weil ich sprachlich nicht sehr überzeugen kann.
• Ein Bugzilla-Account ist schnell angelegt, E-Mail-Adresse eintragen und fertig, man muss nur überlegen, welche E-Mail-Adresse, da die, im Gegensatz zu MediaWiki, für angemeldete Benutzer sichtbar ist.
• Ok, da muss man mal schauen
• Ok, wobei ich dir aber nichts wegnehmen möchte, da die (anfängliche) schöpferische Leistung ja bei dir lag.

Der Umherirrende 15:15, 29. Apr. 2011 (CEST)

Meine „(anfängliche) schöpferische Leistung“ neigt sich dem Ende zu. Eine Methode in C++ müsste ich noch austüfteln, aber heute nicht mehr.

@Schnark: Du bist doch so ein Fuchs im Denksport – wenn du Zeit hast, schaust du mal auf die Tabelle dekonstruierter virtueller Zeilenumbrüche und prüfst, ob ich das auch richtig gemacht habe? – Die Umsetzung dieser Tabelle wäre der letzte Baustein vor dem nächsten Schritt im Projektmanagement.

Genug für heute --PerfektesChaos 23:20, 11. Mai 2011 (CEST)

Duarte Silva

Sag mal, was war das denn??? Ich habe den Weblink gefixed, der war tatsächlich kaputt. Dann der Bearbeitungskonflikt. Ich habe meine Änderung in den oberen Editor übertragen. Lt. Änderungshistoire hätte ich aber angeblich die Sortierung geändert. --Abrisskante 12:28, 20. Apr. 2011 (CEST)

Bearbeitungskonflikte sind das Lästigste, was einem passieren kann. Was genau passiert ist, lässt sich ohnehin nicht mehr rekonstruieren. Da ich bei meiner Bearbeitung neben dem Einfügen der Personendaten ebenfalls den Weblink korrigiert habe, war es für mich am einfachsten, deine Änderung rückgängig zu machen, da ich ja wusste, dass sie in meiner schon enthalten war. --Schnark 09:11, 21. Apr. 2011 (CEST)

Firefox 4.0.1

Hallo Schnark. Seit ich auf die neue Firefox-Version umgestellt habe, funktioniert die Modulverwaltung nicht mehr richtig. Auf der Konfigurationsseite werden rote „X“ angezeigt, was nicht geändert werden kann. --Leyo 01:14, 2. Mai 2011 (CEST)

Schließe mich an. Wollte es schon ein paar mal ansprechen, aber irgendwie ist das Thema dann immer wieder in den Hintergrund gerückt. -- ζ 05:00, 2. Mai 2011 (CEST)

Hättest du es einen Tag früher gesagt, so hätte ich gestern, wie ich mal zufällig mit einem FF 4 gearbeitet habe, danach geschaut. Ich werde wohl noch einige Zeit bei FF 3.6 bleiben, aber falls ich das Problem an Hand eines Screenshots und den Ausgaben der Fehlerkonsole (wird wohl noch immer Strg+Umschalt+J sein) nachvollziehen kann, kann ich natürlich versuchen, den Fehler schon vorher zu beheben. --Schnark 09:10, 2. Mai 2011 (CEST)

Kein Problem: http://min.us/mvfQ4Jg -- ζ 09:38, 2. Mai 2011 (CEST)

Was passiert bei einem Klick auf „Aktivieren“? Bei den Meldungen der Fehlerkonsole interessieren mich nur die Fehler (Klick auf das „Durchfahrt verboten“-Schild), die Warnungen über das nicht valide CSS müllen nur alles voll. --Schnark 09:42, 2. Mai 2011 (CEST)

Optisch passiert rein gar nichts. Das Modul wieder zwar aktiviert, aber es wird eben nicht angezeigt. Ein Klick auf das Durchfahrtsverbotssymbol zeigt keine Hinweise. Ich hab noch einen Screenshot der Web-Konsole hinzugefügt. Vielleicht ist dieser hilfreicher. -- ζ 09:54, 2. Mai 2011 (CEST)

Was gibt javascript:alert(jsmodules.modules['[[Benutzer:Schnark/js/wikieditor.js]]'].status.called) aus, wenn man es in die Adresszeile eingibt? (Sollte bei dir true sein.) Ändert sich das Ergebnis, wenn man diesen Befehl im Bearbeitenmodus aufruft? --Schnark 12:06, 3. Mai 2011 (CEST)

Falls du mit „Bearbeitenmodus“ die Seitendarstellung bei Klick auf „Bearbeiten“ meinen solltest: Nein. Es wird immer „true“ angezeigt. -- ζ 12:30, 3. Mai 2011 (CEST)

Damit lässt sich das Problem recht eindeutig auf die Ladereihenfolge schieben. Ich muss mir die Sache durch den Kopf gehen lassen, weil das auch zu bedeuten scheint, dass FF 4 da etwas ziemlich Absurdes tut. --Schnark 12:35, 3. Mai 2011 (CEST)

(aufgerückt) Ganz so trivial dürfte das nicht sein. Das Problem tritt mit Chromium 11 ebenfalls auf und beim einzigen Browser, der mir die Konfigurationsliste derzeit korrekt darstellt – Opera 11.10 – wird mit obigem JS-Code im Bearbeitungsmodus ebenfalls true angezeigt. -- ζ 12:56, 3. Mai 2011 (CEST)

Probiert mal Folgendes:

1. Cache leeren, javascript:alert(jsmodules.version) muss 1.1 anzeigen
2. Die Zeile jsmodules.load('[[Benutzer:Schnark/js/modulverwaltung.js]]'); ändern in jsmodules.load('[[Benutzer:Schnark/js/modulverwaltung.js/ff4.js]]'); jsmodules.default_cookie='';
3. Allen Göttern, denen man einen positiven Einfluss auf solche Dinge unterstellt, geeignete Opfer darbringen (Dieser Schritt ist optional, aber sehr zu empfehlen.)
4. Schauen, ob es dann geht

Falls meine Ferndiagnose stimmt, sollte das klappen, ich empfehle aber dringend, beim ersten Versuch kein weiteres Tab mit ungespeichertem Text offen zu haben. --Schnark 09:14, 5. Mai 2011 (CEST)

Nur zur Dokumentation:

“In Firefox 4.0, the async DOM property defaults to true for script-created scripts, so the default behavior matches the behavior of IE and WebKit. To request script-inserted external scripts be executed in the insertion order in browsers where the document.createElement("script").async evaluates to true (such as Firefox 4.0), set .async=false on the scripts you want to maintain order.”

– script – MDC Docs: https://developer.mozilla.org/en/html/element/script

Dazu müsste ich aber die Skripteinfügung von Hand basteln, wozu ich keine Lust habe. --Schnark 11:13, 5. Mai 2011 (CEST)

Gleichwohl informativ.

Wieder was gelernt --PerfektesChaos 11:22, 5. Mai 2011 (CEST)

Sollte .async=false die einzige praktibale Lösung sein, werde ich wohl die Programmierer um einen Parameter zu mw.loader.load anbetteln. --Schnark 11:25, 5. Mai 2011 (CEST)

@ Zwiebelleder: Ich sehe gerade, dass dir bei extratabs.js und letzteredit.js die schließenden eckigen Klammern fehlen, was zwar erst einmal nicht stört, aber zu sehr merkwürdigen Effekten führen könnte. --Schnark 11:31, 5. Mai 2011 (CEST)

Ich habe das Vierpunkteprogramm oben angewendet. Leider führte es nicht zum Erfolg, sondern nach dem Neuladen von Benutzer:Schnark/js/modulverwaltung#Konfiguration zum Beinahe-Absturz bzw. zu einer Meldung bezüglich nicht antwortendem Script. --Leyo 01:20, 6. Mai 2011 (CEST)

Neuer Versuch: Cache leeren, dass javascript:alert(modulverwaltung.version) (funktioniert nur im BNR) 1.1a anzeigt, noch mal versuchen (eventuell doch Schritt 3 beherzigen). --Schnark 09:09, 6. Mai 2011 (CEST)

Um mich mal einzumischen:

Bei while (!jsmodules.done) {} war mir ausgesprochen unwohl. Auch wenn es zufällig irgendwo funktioniert, feuert while permanent Aktionen. Firefox geht damit vielleicht gelassen um; andere Brauser machen nichts anderes mehr als while zu fragen, und jsmodules. war auch noch kein Objekt; der Zugriff auf .done ist dann auch ein Syntaxfehler.

Just another Perl hacker mag setTimeout(modulverwaltung.zeigeTabelle schreiben.

Klassisch wäre

if (typeof(jsmodules) == "object") {
   WeiterGehts();
} else {
   var jsmodules_afterinit = WeiterGehts;
   mw.loader.load(...jsmodules...);
}
return;

und in jsmodules.init()

if (typeof(jsmodules_afterinit) == "function") {
   jsmodules_afterinit();
}

Beste Grüße --PerfektesChaos 10:59, 6. Mai 2011 (CEST)

Sieht ganz gut aus. Funktioniert auch mit Chromium und Opera. Danke auch für den Hinweis mit den eckigen Klammern. :) Allerdings wird mir mit allen drei Browsern bei javascript:alert(jsmodules.version) lediglich „1.1“ angezeigt; nicht „1.1a“. -- ζ 13:13, 6. Mai 2011 (CEST)

Bei mir funktioniert es – bis auf die Extra-Editbuttons – auch wieder. Vielen Dank! --Leyo 00:03, 7. Mai 2011 (CEST)

Kann eigentlich jemand was zu dem (oben gezeigten) Fehler sagen (der erst mit v1.17 auftrat):

Warnung: 'important' erwartet, aber 'ie' gefunden.  ';' oder '}' zum Beenden der Deklaration erwartet, aber 'ie' gefunden.  Deklaration ignoriert.

Quelldatei: [3] Ist das ein Hack für den IE?? --91.42.169.204

@ PerfektesChaos: Mir war bei der leeren while-Schleife auch unwohl, aber es war ja nicht mein Browser, da kann man schon mal andere testen lassen, was passiert … FF tut irgendetwas parallel, ich wollte wissen, wie viel. Offensichtlich schafft er es aber trotzdem nicht, neben einer while-Schleife noch etwas anderes zu tun. Andere Browser sollten damit kein Problem haben, da jeder Browser, der Skripte brav in der Reihenfolge behandelt, in der sie eingebunden wurde, die Stelle erst erreichen kann, wenn jsmodules.done bereits true ist. jsmodules.js ist in allen Fällen bereits geladen (bzw. ich kann natürlich niemand davon abhalten, modulverwaltung.js separat einzubinden, aber so jemand ist selber schuld), ein erneutes Laden würde alles nur viel, viel schlimmer machen.

@ Zwiebelleder: jsmodules.version=1.1, modulverwaltung.version=1.1a

@ Zwiebelleder + Leyo: Da andere Benutzer noch eine gecachete Version von jsmodules.js verwenden, kann ich die Änderungen der Firefox-Version erst in etwa einem Monat in die normale Version übernehmen, ich melde mich dann, wenn ihr modulverwaltung.js/ff4.js wieder in modulverwaltung.js zurückändern könnt.

@ 91.42.169.204: Das kommt aus der Datei vector/screen.css und ist in der Tat ein Hack für IE 6, der eine Anweisung mit !ie einfach akzeptiert, während alle anderen Browser die Zeile als fehlerhaft erkennen und ignorieren.

--Schnark 09:33, 7. Mai 2011 (CEST)

Na, jsmodules ist ja so was wie eine Basis-Bibliothek; und das gängige Verfahren, diese einzubinden, ohne dass es zu Folge-Aufwand für Fehlersuche und Debugging bei fremden Browsern anderer Leute kommt, wäre:

• In jsmodule.js unmittelbar am Anfang nach <nowiki>:

if (typeof(jsmodules) == "object") {
   return;
}

• In jedem anderen Skript (hier momentan modulverwaltung.js) wie oben schon beschrieben als letzte Zeilen

if (typeof(jsmodules) == "object") {
   modulverwaltung.init();
} else {
   var jsmodules_afterinit = modulverwaltung.init;
   mw.loader.load(...jsmodules...);
}
return;

• Dann kann statt den beschriebenen 4 Zeilen von neuen Anwendern einfach modulverwaltung.js direkt eingebunden werden.
• Die Intelligenz liegt dann in den Skripten und nicht bei den Anwendern; die Skripte finden selbsttätig, robust und sicher heraus, was in welchem Moment zu tun ist, und es läuft eine saubere und synchronisierte Ausführungskette ab. Wenn jsmodule.js bereits geladen war, ist fein; wenn nicht, macht’s auch nix; wenn es im Laufe der Sitzung schon mit Daten belegt wurde, wird es nicht zerstört (mindestens beim FF bleibt die JS-Umgebung innerhalb der Seite und URL bei [Vorschau] und [Änderungen] erhalten).
• Sollten mehrere Skripte jsmodule.js als Basis-Software benötigen, wäre jsmodules_afterinit als Array zu gestalten; im Übrigen vor Ausführung der Elemente zu klonen und auf false zu setzen; für ganz komplexes asynchrones Zusammenspiel.

Fiel mir nur so auf --PerfektesChaos 10:34, 7. Mai 2011 (CEST)

Die Dinge sind alle ein wenig historisch gewachsen: Ursprünglich funktionierten jsmodules.js und modulverwaltung.js nur im Vector-Skin, sodass ich nicht einfach jemand das aufzwingen konnte, der es nicht wollte. Warum es überhaupt zwei Skripte sind, weiß ich eigentlich selbst nicht, denn die beiden gehören ohnehin zusammen, die obigen Probleme wären auch nicht entstanden. Tatsächlich ist es so, dass jsmodules.js in den meisten Fällen von sich aus modulverwaltung.js lädt, sodass man in der Regel nur dieses einbinden muss, wenn man beide haben möchte. Letztendlich will ich mit Änderungen warten, bis bugzilla:27561 implementiert ist, dass ich nur noch eine Schnittstelle zum RL zur Verfügung stelle und mich ansonsten um nichts mehr kümmern muss. --Schnark 10:45, 7. Mai 2011 (CEST)

Na, ist doch hübsch so.

Wenn du eines Tages mal jsmodules anders einbinden möchtest, ist alles parat.

Im Übrigen genügt es sogar dem Java-Standard, nach der jede Definition eines komplexen Objektes einzeln in einer gleichnamigen Datei erfolgt.

Die Bugzilla-Vorschläge sind nicht so restlos ausgereift; die innere Logik der Abhängigkeiten und der zu ihrer Befriedigung erforderlichen Ladevorgänge wird deutlich komplexer, als dort vorgeschlagen. Aber da halte ich mich einstweilen raus.

Sonne! Luft! Dir auch --PerfektesChaos 12:43, 7. Mai 2011 (CEST)

Wobei ich gerade mit dem Gedanken spiele, jene Konvention aufzugeben, und die Definition von modulverwaltung nach jsmodules.js zu verschieben. Ist aber ein etwas größeres logistisches Problem, wenn ich nicht mit allen Ärger will, die noch irgendeine alte Version in ihrem Browser-Cache haben. --Schnark 09:20, 9. Mai 2011 (CEST)

Ist das Leeren des Browsercaches wirklich ein derart großen Unterfangen, was Benutzern nicht zugemutet werden kann? Ich finde diese Rücksichtnahme etwas überzogen, schließlich ist das bei nahezu allen scriptbeinhaltenden und regelmäßig gewarteten Seiten irgendwann einmal erforderlich. Wenn jemand in der Lage ist, seine eigene Skin.js zu bearbeiten, um solche Scripte einzubinden, dann dürfte die Cacheleerung wohl das kleinste Problem sein. Notfalls kann man ja an passender Stelle darauf hinweisen und sogar noch auf Seiten wie diese hier verweisen. -- ζ 10:07, 9. Mai 2011 (CEST)

Zumindest müsste ich alle Benutzer darauf hinweisen, dass sie den Cache leeren müssen, da ich mir sicher bin, dass nicht alle, die meine Skripte verwenden von selbst auf diese Idee kommen. Wenn man mit irgendeiner Tastenkombination seinen Cache leeren will, dann ist es immer ein heiteres Raten, bei dem bisweilen auch ich scheitere, da sie sich im Firefox irgendwann vor kurzer Zeit einmal geändert hat. Außerdem ist ein Hintergedanke von jsmodules.js, dass der Benutzer sich eben keinerlei Gedanken mehr um den Cache machen muss. Alles in allem ziehe ich daher eine Lösung, die ohne Cache-Leerung auskommt, einer eventuell für mich etwas einfacheren Lösung, die eine Leerung brauch, deutlich vor. --Schnark 09:16, 10. Mai 2011 (CEST)