Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise
[[Benutzer Diskussion:Schnark/Archiv2#Thema 1]]
oder als Weblink zur Verlinkung außerhalb der Wikipedia
Befindet sich der Großbuchstabe „B“ am Anfang eines Suchbegriffs, wird er beim Ersetzen nicht entfernt. Sucht man beispielsweise nach dem Begriff „Baum“ und hat als Ersetzungsbegriff „Haus“ eingetragen, so erhält man im Resultat „BHaus“. -- ζ18:30, 12. Mär. 2011 (CET)
Da die Suchen-und-Ersetzen-Funktion kein Bestandteil meines Skripts ist, habe ich damit nichts zu tun. --Schnark09:04, 14. Mär. 2011 (CET)
Entschuldige. Ich hatte vergessen, dass der Button erst dann in der Editor-Leiste eingebunden wird, nachdem in den Einstellungen die Funktion „Dialoge für das Einfügen von Links, Tabellen usw. aktivieren“ aktiviert. Weißt du zufällig wo man Fehler melden kann? -- ζ09:21, 14. Mär. 2011 (CET)
Gemach, gemach; es könnte April werden, bis das auffällt. Vielleicht mögen sich noch weitere PDler tummeln; mir tanzen Pelz und Graphikus über den Schirm.
Das zerlegte Skript hat das Beta-Testing hinter sich. Wenn du deine Knöpfchen ausprobieren möchtest, brauchst du bloß de gegen en zu tauschen. Bislang verwaiste Infos hier.
Hallo Schnark,
ich habe im letzten Monat ein paar Artikel in die Wikipedia gestellt, in denen ich aus typographischen Gründen schmale Leerzeichen verwendet habe. Ich weiß, dass die Wikipedia-Empfehlung im Moment noch ist, diese nicht zu benutzen, da einige Uralt-Browser sie nicht korrekt anzeigen, habe mich darüber im Sinne von "Sei mutig!" aber bewusst hinweggesetzt, weil:
1. es meine Überzeugung ist, dass übertriebene Rücksichtnahme auf alte Browser nur dazu führt, dass die noch länger in Benutzung bleiben
2. ich selbst jedenfalls später nicht mehr die Zeit und Muße finden werde, die Artikel durchgängig typographisch korrekt umzugestalten, wenn denn schmale Leerzeichen wirklich nirgendwo mehr Probleme machen, und ich nicht will, dass die Artikel als Erblast ewig typographisch verhunzt sind, nur weil das jetzt hier und da noch Probleme macht.
Wie auch immer, jedenfalls hast Du (oder vermutlich ein Skript von Dir) in einem meiner Artikel alle schmalen Leerzeichen zurückgesetzt, entweder auf nbsp oder gelöscht (wobei nicht immer die beste der beiden Varianten benutzt wurde), in den anderen aber nicht. Gibt es dafür einen Grund, oder hatten meine anderen Artikel nur Glück und sind Dir "entwischt"? Und: falls ich jetzt Deine Änderungen wieder zurücksetze, fangen wir dann einen Edit-War an (was ich keinesfalls will), oder wäre das OK für Dich? --Uli19:12, 27. Mär. 2011 (CEST)
Auf den Artikel gestoßen bin ich durch Hilfe:Personendaten/Wartung/Fehlerliste, da auf Grund der schmalen Leerzeichen Geburts- und Sterbedatum nicht im Artikel gefunden wurden und der Artikel daher als möglicher Fehler gemeldet wurde. Ich und auch die anderen Abarbeiter dieser Fehlerliste sind ziemlich stur, wenn du also im Einleitungssatz die schmalen Leerzeichen wieder einfügst, kannst du dir sicher sein, dass es jemand wieder zurückändern wird. Bei den anderen Stellen dagegen wird es wohl niemand (zumindest nicht mir) auffallen, wenn du wieder schmale Leerzeichen einfügst.
Aber: Wikipedia lebt davon, dass jeder – auch und gerade jemand, der mit Computern nicht so viel zu tun hat – sich einbringen kann. Normaler Wikitext ist schon abschreckend genug, ein erst recht, aber mit einer gehäuften Verwendung von so kryptischen Dingen wie   schreckt man Neulinge effektiv ab und verhindert damit das, was zum Erfolg von Wikipedia beiträgt: Dass jeder auch ohne (oder zumindest mit nur minimalem) technisches Verständnis Artikel bearbeiten kann. --Schnark09:17, 28. Mär. 2011 (CEST)
Danke für die Antworten! Schnark, verstehe ich das richtig, dass irgendein Skript versucht, Geburts- und Sterbedatum einer Person anhand des Einleitungssatzes zu ermitteln? Warum das denn, wenn es extra am Ende die normierten Personendaten gibt?? Gerade nach dem * und dem † ist ein normalbreites Leerzeichen schaurig anzusehen, und in jedem Fall müsste hier ein Umbruchschutz rein! <Seufz> Wenn das momentan mit dem Skript so ist, dann sehe ich das natürlich ein, aber eigentlich sollte es doch kein Problem sein, das Skript intelligent genug zu machen, dass es mit nbsp und #x202F umgehen kann … Und, wie gesagt, wozu überhaupt den ersten Satz auslesen, wenn es PND gibt?? Die Überlegung mit dem lesbaren Quellcode kann ich gut verstehen; ich hatte das Problem vor allem an anderer Stelle: meine Artikel handeln alle von Ungarn, oftmals mit englischsprachigen Quellen, das heißt, ich wechsle permanent, manchmal alle zwei, drei Worte, zwischen Deutsch, Ungarisch und Englisch. Ich habe mir viele Diskussionen pro und contra der Verwendung der Vorlage:Lang zu Gemüte geführt und für mich am Ende beschlossen, sie zu verwenden, da barrierefreies Lesen mir wichtiger erscheint als einfaches Schreiben. Aber der Quelltext der Artikel ist dadurch in der Tat oft kaum noch lesbar (Fußnoten tun dazu noch ihr übriges hinzu ..…). Andererseits muss ich als jemand, der jetzt erst zur Wikipedia (ernsthaft) dazugestoßen ist, sowieso sagen, dass die Lernkurve mittlerweile am Anfang sehr steil ist; die Pionierzeiten, wo man spontan mitmachen konnte, scheinen mir definitiv vorbei. Das liegt doch aber auch an den inhaltlichen Qualitätsansprüchen, die enorm gestiegen sind (Belegpflicht, etc.). Naja, anderes Thema … Ich würde, nach dem, was Du geschrieben hast, es jetzt so halten, dass ich die schmalen Leerzeichen wieder einfüge, aber nicht in dem Einleitungssatz. OK? (Nur zur Sicherheit: Verstehe ich das richtig, dass dieses Skript auch an einem normalen nbsp scheitern würde, ich also wirklich schlichte Leerzeichen im Einleitungssatz verwenden muss?)--Uli22:26, 28. Mär. 2011 (CEST)
Ich wollte dir eigentlich gerade zustimmen, aber dann habe ich Wikipedia:Meinungsbilder/Typographie (Zwischenräume)#Browser-Unterstützung (aktueller siehe Perhelions Link) gefunden und deine Artikel mal mit dem Internet Explorer 8 (man kann – zu recht – viel schlechtes über den IE sagen, aber nicht, dass die Version 8 veraltet sei) angeschaut: Deine schmalen Leerzeichen werden dort als Quadrate dargestellt. Solange also bei über einem Drittel aller Benutzer die Darstellung völlig fehlerhaft ist, kann dieses Zeichen nicht verwendet werden.
Das Skript prüft (unter anderem) ob das Datum, das in den Personendaten angegeben ist, auch im Text vorkommt, nur so lassen sich halbwegs zuverlässig Fehler finden. Was du tun könntest ist 1. Januar zu schreiben, damit würde das Skript das Datum finden, angezeigt würde aber ein nbsp. --Schnark09:25, 29. Mär. 2011 (CEST)
Die Links von Dir bzw. Perhelion habe ich mir natürlich auch angesehen, aber Du hast die missverstanden: Das Problem ist nämlich nicht der Internet Explorer 8, sondern ein oder mehrere nicht korrekte Fonts in Windows XP (die eben ein Quadrat enthalten, wo ein schmales Leerzeichen sein müsste). Deshalb haben alle unter Windows XP laufenden Browser dieses Problem (in der Tabelle noch aufgeführt sind Safari und Chrome). Unter Vista oder Windows 7 stellt der Internet Explorer 8 (und auch der Internet Explorer 7) schmale Leerzeichen wunderbar dar (habe ich ausprobiert), Safari und Chrome natürlich sowieso. Und ehrlich, auf ein 10 (?) Jahre altes Betriebssystem Rücksicht zu nehmen, habe ich keine Motivation. Danke für den Trick mit der Datumsschreibweise, der klingt gut! 2 Fragen noch dazu: 1. Der Trick muss doch genauso mit #x202F gehen (wenn ich es denn verwenden will), oder übersehe ich da irgendwelche Skript-Allergien? 2. Verstehe ich das richtig, dass nur das "falsche" Leerzeichen zwischen Tag und Monat das Skript stört, oder stört auch ein "falsches" Leerzeichen zwischen * oder † und dem Datum (was man dann mit Deinem Trick halt nicht weg bekäme)? Danke für Deine Hilfe!--Uli15:19, 29. Mär. 2011 (CEST)
Auch wenn ich deine Haltung zur korrekten typographischen Darstellung grundsätzlich befürworte, so muss dir ich dennoch in einigen Punkten widersprechen. Windows XP wurde mit dem SP3 zuletzt im Mai 2008 aktualisiert. Zu diesem Zeitpunkt war der Support für die von dir angesprochene 10 Jahre alte Ursprungsversion und sogar für die Version mit SP 1(a) bereits schon längst beendet. Die letzte XP-Version ist somit nicht älter als 3 Jahre. Zudem hatte ich extra hierfür eine XP-Installation gestartet, mit dem Ergebnis, dass das Problem nicht alle Browser unter diesem System betrifft. Lediglich der IE 8 stellt diese Zeichen nicht korrekt dar. Mit FF 4 und Opera 11.01 sieht alles problemlos aus. -- ζ16:17, 29. Mär. 2011 (CEST)
Hm, vielleicht rechnen Mac-Nutzer wie ich da anders; das Alter eines Betriebssystems richtet sich für mich nach dessen Release-Datum, nicht nach dem Datum des letzten Updates. Und so ist Windows XP jetzt (fast) 10 Jahre alt und ganz sicher keine 3 – da gab es ja schon Vista! Und das Problem ist ziemlich sicher der Font; nach allem, was ich weiß, sieht ein RTF-Dokument mit schmalen Leerzeichen mit diesem Font in Word genauso fehlerhaft aus. Kann gut sein, dass FF4 und Opera da halt spezielle Workarounds für Windows XP eingebaut haben.--Uli18:30, 29. Mär. 2011 (CEST)
Wenn man deine Rechenmethode auf MacOS übertragen würde, dann arbeitest du auch auf einem 10 Jahre alten System, da MacOS X fast auf den Tag genau vor 10 Jahren veröffentlicht wurde. -- ζ19:20, 29. Mär. 2011 (CEST)
Ob es einem nun passt oder nicht, nach en:Usage share of operating systems ist Win XP mit über 40 % das am häufigsten verwendete Betriebssystem, und der Anteil der Benutzer, die den Internet Explorer verwenden, aber wissen, wie sie ihn davon überzeugen können, vernünftige Schriftarten zu verwenden, ist wohl gering. Damit verursachen schmale nichtumbrechende Leerzeichen (noch) mehr Probleme als sie lösen. --Schnark09:31, 30. Mär. 2011 (CEST)
40% mag ja der höchste Einzelanteil sein, ist aber insgesamt unter 50%. Aus meiner Sicht ist es ein größeres Problem, 60% der Leser auf Dauer (denn ich werde keine Zeit mehr haben, das später zu ändern) typographischen Murks zuzumuten, als 40% (die zudem definitiv nicht mehr zu-, sondern stetig abnehmen werden) für begrenzte Zeit ein paar Quadrate. Diese Auffassung musst Du ja nicht teilen, aber ich würde das gerne so halten. Deshalb sei doch bitte so nett und beantworte mir noch kurz meine beiden oben mit 1 und 2 markierten Fragen, damit ich sicherstellen kann, dass Deine Skripte keine Probleme haben. --Uli14:14, 30. Mär. 2011 (CEST)
Ein normales Leerzeichen anstelle eines schmalen ist ganz bestimmt keine Zumutung (ich bezweifle, dass es viele Leser gibt, die überhaupt einen Unterschied wahrnehmen), wohl aber Quadrate an Stellen, wo Leerzeichen stehen sollten. Mir persönlich ist das völlig egal, ich verwende Firefox, und sehe daher auch die schmalen Leerzeichen so, wie sie gemeint sind. Insofern gilt:
Wenn nach dem Stern oder Kreuz in der Einleitung kein normales Leerzeichen steht, gibt Stefans Skript eine Fehlermeldung aus, und irgendjemand wird das sicher ändern.
Wenn das Geburts- oder Sterbedatum nicht inklusive eines normalen Leerzeichens im Text gefunden wird, gibt Stefans Skript eine Fehlermeldung aus, und irgendjemand wird das sicher ändern.
Wenn ein Leser mit dem IE unter Win XP auf so einen Artikel stößt, wird er sich über die Darstellung ärgern – zurecht.
Wenn ein Leser, der weiß wie man Artikel bearbeitet, mit dem IE unter Win XP auf so einen Artikel stößt, wird er die Leerzeichen ändern. --Schnark09:19, 31. Mär. 2011 (CEST)
Danke für die Antworten! Was man als Zumutung empfindet, differiert halt; ich empfinde es vor allem als Zumutung, dass Leute 10 Jahre alte Betriebssysteme benutzen und erwarten, dass mit denen das Web noch funktioniert, denn das ist der größte einzelne Verzögerungsfaktor in der Fortentwicklung. Wenn nach dem Stern oder Kreuz in der Einleitung kein normales Leerzeichen steht, gibt Stefans Skript eine Fehlermeldung aus, und irgendjemand wird das sicher ändern. – Völlig unabhängig von der Frage mit den schmalen Leerzeichen würde an diese Stellen aus meiner Sicht aber mindestens ein nbsp gehören. Kann man dieses Skript auf Dauer nicht ein wenig flexibler machen? Das ist doch nur ein Aufwand von ein paar Minuten, da eine Gleichbehandlung für Leerzeichen, nbsp und #x202F einzubauen; ein Skript sollte sicher nicht aus technischen Gründen stilistische Zwänge ausüben … Kannst Du mir sagen, um welchen Stefan es sich bei dem Autor handelt – dann kann ich ihn direkt kontaktieren? Wenn ein Leser mit dem IE unter Win XP auf so einen Artikel stößt, wird er sich über die Darstellung ärgern – zurecht. – Oder es ist der letzte Anstoß, den er noch braucht, um endlich auf einen vernünftigen Browser oder ein aktuelles Betriebssystem zu wechseln … Mir hat übrigens noch in keinem meiner anderen Artikel irgendjemand ein schmales Leerzeichen wegeditiert. --Uli10:59, 31. Mär. 2011 (CEST)
Wie von Zwiebelleder ausgeführt ist ein Betriebssystem, das 2008 zum letzten Mal aktualisiert wurde, und bis Ende 2008, teilweise sogar bis 2010 verkauft wurde, ganz bestimmt nicht veraltet (es veraltet dann, wenn ein weiteres Service Pack nötig wäre, das aber dann nicht kommt). Viele können auch gar nicht das Betriebssystem wechseln, etwa in Unternehmen, an Universitäten, etc. Und Benutzer:Stefan Kühn relativ wenig Zeit, sodass ich dir nicht allzu viel Hoffnung machen will, dass er das Skript ändert. --Schnark11:15, 31. Mär. 2011 (CEST)
Nun, es wäre ja ein weiteres SP nötig (das den/die defekten Font(s) ersetzen würde), das offenbar seit 10 Jahren nicht kommt … Insofern ist XP schon seit 10 Jahren veraltet. ;-) Ich kenne wirklich niemanden außer Dir (und Zwiebelleder), der behaupten würde, Windows XP sei nicht veraltet – na, egal. Danke jedenfalls für die Adresse von Stefan, ich schau da mal vorbei, je nachdem kann ich das Skript ja auch selbst fixen. --Uli12:51, 31. Mär. 2011 (CEST)
CSS und Modulverwaltung
Hallo Schnark. Kann man mit der Modulverwaltung auch CSS-Scripte ein und ausschalten? Geht es mit einem JS-Hilfsscript, das die CSS-Script aufruft? Konkret geht es um die Markierung von lokalen Dateien und Links auf (nach)zusichtende Artikel. --Leyo20:10, 1. Apr. 2011 (CEST)
Nein. Ja. Soll heißen: Wenn du ein Skript mit dem Inhalt
erstellst (also den CSS-Code als String an die Funktion mw.util.addCSS übergibst), und dieses Skript über meine Modulverwaltung mit jsmodules.load einbindest, dann lässt es sich an- und ausschalten.
Eine Markierung von ungesichteten Artikeln benötigt ohnehin JavaScript,
in deiner JS-Datei zusammen mit einer (dauerhaften) CSS-Anweisung für die Klassen flaggedrevs-unreviewed und flaggedrevs-unreviewed2 tut das Gewünschte. --Schnark09:19, 2. Apr. 2011 (CEST)
Vielen Dank für die ausführliche Antwort! Nur den letzten Teilsatz habe ich nicht ganz verstanden. Die Markierung der lokalen Dateien klappt nun und auch die Links auf nachzusichtende Artikel werden markiert. Dass Links auf ungesichtete Artikel nicht markiert werden, ist von P.Copp wohl so vorgesehen. In der Modulverwaltung (die ich per Tab erreiche) ist dieses Script nun übrigens separat aufgeführt. --Leyo12:36, 2. Apr. 2011 (CEST)
War eine Kombination von Denkfehler bei mir und veraltetem Code bei P.Copp: Der Code fügt Links auf ungesichtete Seiten die CSS-Klasse flaggedrevs-unreviewed bzw. flaggedrevs-unreviewed2 hinzu. Für beide Klassen war mal Code in der allgemeinen CSS-Datei vorhanden, der für einen farblichen Hintergrund sorgte. Das funktioniert in zwei Fällen nicht: Die Seite befindet sich in einem Namensraum, in dem nicht gesichtet wird (ungesichtete auf der Hauptseite verlinkte Artikel werden nicht markiert), zum anderen wurde irgendwann einmal die Klasse flaggedrevs-unreviewed2 umbenannt, sodass seit diesem Zeitpunkt dafür keine Hintergrundfarbe mehr definiert ist. Um beide Probleme auf einmal zu lösen, solltest du in Benutzer:Leyo/monobook.css irgendwo einfügen:
Danke für die wiederum ausführliche Antwort! Der veraltete Code in Benutzer:P.Copp/scripts/markunreviewed.js könnte ja aktualisiert werden, falls das nicht viel zu tun gibt. Kann man dieses Feature per Modulverwaltung an- und ausschalten, auch wenn es in meiner normalen monobook.css drinsteht? --Leyo10:19, 4. Apr. 2011 (CEST)
Die veraltete Klasse im Code auszutauschen sollte für P.Copp eine Sache von ein paar Sekunden sein, was aber nicht das Problem löst, dass Links aus Namensräumen, in denen nicht gesichtet wird, nicht hervorgehoben werden.
Ein- und ausschalten kannst du die Markierung auch dann, wenn der Code dauerhaft in deiner monobook.css steht, da die Klassen ja über JavaScript hinzugefügt werden, das du ein- und ausschaltest. --Schnark10:34, 4. Apr. 2011 (CEST)
Ich muss die Änderungen wie immer erst noch testen, die nächste Version wird dann auch die neue Kategorie als Geschlechts-Kategorie akzeptieren. --Schnark09:34, 4. Apr. 2011 (CEST)
Danke Schnark, ich werde es einmal ausprobieren. Die obskuren Fälle habe ich im Auge bis SK sein Skript geändert hat. Ich möchte verhindern, dass diese in seiner Fehlerliste auftauchen und dann unbedarft wieder korrigiert werden... Beste Grüße --Silke Ewering10:08, 5. Apr. 2011 (CEST)
Bevor die Änderungen bei dir wirksam werden, musst du entweder bis morgen warten oder einen beliebigen Artikel aufrufen und dort einmal deinen Cache leeren. --Schnark10:12, 5. Apr. 2011 (CEST)
Könntest Du bitte einmal ...
Hallo Schnark, vor ein paar Tagen und dann gestern ist mir ein ganz komisches Phänomen bei den unter Weblinks verzeichneten Verweisen auf den Bestand der DNB aufgefallen. Wie bei Erna Döbele wird diese Vorlage PND in die Vorlage Normdaten umgewandelt. Dieses passiert aber nur ganz, ganz selten und ich finde leider im Moment kein Beispiel, bei denen die PND unter Weblinks nicht geändert werden. Ich hoffe, ich habe mich Verständlich ausgedrückt :-) Wäre nett, wenn Du einmal einen Blick auf Erna und die Vorlagen werfen könntest. Besten Dank --Silke Ewering10:17, 5. Apr. 2011 (CEST)
Ich vermute, dass ich das Problem an PerfektesChaos weitergeben kann. Im Idealfall übernimmst du mit meinem Skript die PND aus der PND-Vorlage, woraufhin automatisch die VIAF-Nummer ergänzt wird, hakst das Kästchen für „nicht individualisiert“ an. Damit wird schon einmal eine PNDfehlt- und die Normdaten-Vorlage erzeugt. Wenn das Skript von PerfektesChaos dann die PND-Vorlage in Ruhe lässt, musst du dann selbst entscheiden, ob du sie löschen oder in die DNB-Portal-Vorlage umwandeln willst. --Schnark10:27, 5. Apr. 2011 (CEST)
Hallo Schnark. Wenn ich das Script aktiviert habe, sind beispielsweise bei der Beobachtungsliste die Links auf der Höhe des Interwikis insensitiv (nicht anklickbar). --Leyo14:09, 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):
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.
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 --PerfektesChaos10:13, 14. Apr. 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. --Abrisskante12: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. --Schnark09:11, 21. 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.
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 Umherirrende21:28, 18. Apr. 2011 (CEST)
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.
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 Umherirrende19: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. --Schnark09: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.
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. --Schnark10: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.
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. --Schnark10: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.
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 --PerfektesChaos21: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. --Schnark09: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.
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. --Schnark10: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 --PerfektesChaos12: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. --Schnark09: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.
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. --Schnark10: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:
Ligaturen als Einzelzeichen belassen
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. --PerfektesChaos10: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. --Schnark11:04, 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. --Schnark11: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. --PerfektesChaos12: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(n7)-Algorithmus gefunden hat, wo es eigentlich auch einen O(n*log(n))-Algorithmus gäbe, stört einen das nicht weiter. --Schnark12: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 Umherirrende19: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. --PerfektesChaos21:23, 26. 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. --Leyo01: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. --Schnark09:10, 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. --Schnark09: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? --Schnark12: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. --Schnark12: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:
Cache leeren, javascript:alert(jsmodules.version) muss 1.1 anzeigen
Die Zeile jsmodules.load('[[Benutzer:Schnark/js/modulverwaltung.js]]'); ändern in jsmodules.load('[[Benutzer:Schnark/js/modulverwaltung.js/ff4.js]]'); jsmodules.default_cookie='';
Allen Göttern, denen man einen positiven Einfluss auf solche Dinge unterstellt, geeignete Opfer darbringen (Dieser Schritt ist optional, aber sehr zu empfehlen.)
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. --Schnark09: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.”
Sollte .async=false die einzige praktibale Lösung sein, werde ich wohl die Programmierer um einen Parameter zu mw.loader.load anbetteln. --Schnark11: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. --Schnark11:31, 5. 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). --Schnark09: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.
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)
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 + 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.
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
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.
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. --Schnark10: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.
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. --Schnark09: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. --Schnark09:16, 10. Mai 2011 (CEST)
Die Modulverwaltung ist jetzt in jsmodules.js integriert, der Übergang sollte schmerzlos verlaufen und ist sogar in FF 4.0.1 getestet. --Schnark09:31, 16. Mai 2011 (CEST)
Hallo Schnark. Ich habe gerade erfolglos versucht, dein Script in meiner vector.js in der en.wikipedia einzubauen. Liegt es an mir oder läuft das Script nur lokal? --Leyo09:51, 13. Mai 2011 (CEST)
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.
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.
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.
Als ich mich etwas umgeschaut habe, bevor ich meinen eigenen Diff programmiert habe, bin ich auf [4] gestoßen, das – wenn man auf eine Anzeige von Blockverschiebungen verzichtet – ziemlich gut aussieht. --Schnark09:22, 28. Apr. 2011 (CEST)
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.)
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.
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.
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.
en:AWB würde eine auf Wikidiff2.cpp basierende Weiterentwicklung benutzen, die whitespace besser handhaben würde.
Verbesserungen innerhalb der momentanen Implementierung:
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.
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. --PerfektesChaos17: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 Umherirrende20: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.
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.
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.
Das ist ja schlimmer als eine axiomatische Mengenlehre … Die Tabelle sieht in meinen Augen gut aus, nur fehlen mir an einer Stelle ein paar Fälle (die vielleicht nicht auftreten können, aber dann müsste ich überlegen, warum): op[i]==copy/change, from[i] und to[i] virtuell, op[i+1]==add/del. Dort sollte doch ebenfalls op[i]=change werden, from[i]=from[i]+from[i+1], to[i]=to[i]+to[i+1] (mit null interpretiert als Leerstring) und alle [i+1] gelöscht werden. Beim Aufsplittern in Sätze bist du zu eurozentrisch, 。 muss auf jeden Fall für die Chinesen beachtet werden. --Schnark09:28, 12. Mai 2011 (CEST)
Ich wusste doch, dass ich den Richtigen frage. Nur wenige wache Stunden nach der Anfrage in diesen Quark hineingefummelt und schon eine qualifizierte Antwort – Chapeau! Mir hatten sich beim Aushacken auch die Gehirnwindungen gekräuselt.
Du hast vermutlich recht; zumindest weiß ich jetzt auch nicht mehr, was ich mir vor einer Woche dabei gedacht hatte. Die Situation tritt auf, wenn beim Edit exakt der Satz gelöscht wurde, den sich der Algorithmus für virtuellen Zeilenumbruch ausguckt:
Before reconstruction
#
op
from
to
i
copy
Virtually terminated sentence.
Virtually terminated sentence.
i+1
del
Deleted line of any termination …
null
i+2
any
And now …
… something completely different.
After reconstruction
#
op
from
to
i
change
Virtually terminated sentence. Deleted line of any termination …
Virtually terminated sentence.
i+1
any
And now …
… something completely different.
Das spräche dafür, dass es nur bei copy-copy beim copy bleibt und sonst immer change herauskommt; nochmal denken.
Ich werde bei meinem nächsten Edit heute abend/nacht auf die Problematik eingehen.
CJK: Tja, das wäre nach einer Probe-Implementierung auszuprobieren. Auf der anderen Seite sind in CJK die 100 und 250 bytes auch nach UTF8-Drittelung etwas reichlich; die sollen ja mit wenigen Schriftzeichen auskommen. Grundsätzlich ist das find(". ") ein allererster Schritt; man könnte auch einfach nach jedem x-beliebigen Leerzeichen suchen, oder auch zusätzlich nach Fragezeichen oder Ausrufezeichen suchen. Das liefe dann auf Regexp hinaus; wenn es die Performance dann hergibt, gerne.
Grad läuft ja irgendso'n Schlagerwettbewerb, das bringt mir einige Stunden Befreiung vom Minnedienst – und die nächsten Tage soll es regnen, das heißt Trackball statt Volleyball. Also müsste nach dem Wochenende die Sache rund sein.
So, ich habe den vorgeschlagenen Code nunmehr fertig geschrieben, muss mir aber einiges nochmal anschauen und halte noch etwas banalen Kram in der Pipeline.
Die wesentlichen Teile des Codes, an denen sich ablesen lässt, wie ich mir das vorstelle, habe ich erstmal auf BD:Umherirrender eingeparkt – vor allem aber die Beschreibungen aller Ziele und bewirkte Verbesserungen.
Auf Ebene des Projektmanagements wäre jetzt zu tun:
Projektseite (am liebsten MW:Wikidiff3) einrichten; sobald dies jemand getan hat, würde ich von der BD in sortierter Form dorthin kopieren und Unterseiten bilden.
Jemand suchen, der eine Testumgebung in C++ aufbaut und beim vermutlich notwendigen Debugging tüftelt.
Ein Bugzilla kann folgen, wenn eine Projektseite eingerichtet wurde, und die Angelegenheit umreißen und werben.
Aus einem Bugzilla-Patch wird nichts werden; wikidiff2.cpp ist zu 100% umgekrempelt, mehrere andere Dateien sind auch beteiligt, eine ist hinzugekommen, eine wäre umzubenennen. Die Veränderungen sind so ausgedehnt, dass es als Nachfolgemodell Wikidiff3 bereitgestellt werden müsste.
Für technische Rückfragen auf Ebene der Codierung stehe ich weiterhin gern zur Verfügung. Um Diskussionen, Bugzilla, Kontakt zu den Entwicklern müsste sich aber zur Abwechslung jemand anders kümmern.
Es gehört offenbar dazu, spaltet sich aber vorher vom Baum der Diffs ab:
Es ist in PHP geschrieben.
Wikidiff3@SVN ist nur die sogenannte „Engine“ (ohne Anzeige des Ergebnisses). Das ist grundsätzlich (falls in C++) mit dem vereinbar, was ich gemacht habe; ich habe die Zeilenstruktur vor dem Start der austauschbaren „Engine“ verändert und bereite deren Ergebnis modifiziert auf.
Diese Engine und das Projekt mw:Visual Diff zielt auf eine andere Art der Darstellung ab. Es gibt:
Zeilenweise (wie jetzt, gelb/grün)
Inline (wie WikEdDiff) so auch Visual Diff
Beides ist ein möglicher Weg mit Vor- und Nachteilen (Übersichtlichkeit, etwa verschobene Blöcke). Ich bin bei der einer Masse der Autoren vertrauten zeilenorientierten Darstellung geblieben.
„Wikidiff3“ ist als Name halt besetzt; dann nehme man eben „WikidiffL2“ oder „WikidiffLX“ für Line-OrientedDiff.
Wird includes/diff/WikiDiff3 eigentlich irgendwo verwendet, oder ist das Ding versehentlich übrig geblieben, als Visual Diff entfernt wurde? --Schnark10:14, 21. Mai 2011 (CEST)
Soweit ich das mit meinem bescheidenen Überblick feststellen kann, ist dies zwar nicht eigenständig lauffähig, jedoch über Konfiguration jetzt oder künftig in jeder geeigneten auch lokalen Implementierung einbindbar. Eine Standard-Implementierung durch WMF ist nach Einstellung von Visual Diff nicht mehr erkennbar.
Gleichwohl ist der Bezeichner "Wikidiff3" damit vergeben und ein für allemal „verbrannt“.
Ich habe mich deshalb inzwischen umbenannt in WikidiffLX für Line approach – eXtended.
Hallo Schnark. Wäre es aufwändig, bei LA-/QS-Abschnittsüberschriften _ durch Leerzeichen zu ersetzen? --Leyo18:23, 26. Mai 2011 (CEST)
Überhaupt nicht. Ich muss allerdings noch darüber philosophieren, was wgPageName noch für weitere Codierungen vornimmt, die man nicht sehen möchte. (Andererseits, PDD ersetzt auch nur die Unterstriche.) Aber ich bin ja schon stolz darauf, dass Vorlagen-LAs im richtigen Abschnitt landen (was ich nie wirklich getestet habe) und sogar der Abschnittslink in der Zusammenfassung zur richtigen Stelle führt (was ich nicht nur nicht wirklich, sondern überhaupt nie getestet habe). Ich versuche, die neue Version übers Wochenende fertig zu bekommen. --Schnark09:14, 27. Mai 2011 (CEST)
Danke, aber eilen tut's nicht. Beim DÜP-Script ist mir übrigens gerade ein Tippfehler aufgefallen: „mehrer ohne Leerzeichen hintereinander“. --Leyo11:19, 27. Mai 2011 (CEST)
Den Tippfehler habe ich auch schon gesehen, und in meiner lokalen Version auch schon behoben. Ich plane auch ein paar Benutzerdisk.-bausteine mit einzubauen, falls du da irgendwelche Wünsche hast, kannst du sie nennen. --Schnark11:24, 27. Mai 2011 (CEST)
Das klingt sinnvoll. Spezielle Wünsche habe ich momentan nicht. {{subst:Hallo}} nutze ich wohl am meisten, ist aber auch schnell getippt. Ein paar häufige Texte/Codes habe ich mir in die Extra-Editbuttons gepackt. --Leyo22:59, 30. Mai 2011 (CEST)
Benutzervorlagen sind jetzt drin, allerdings sehr experimentell. Deshalb habe ich sie noch von einer automatischen Speicherung ausgenommen. Ich hoffe, dass ich beim Umräumen nichts kaputt gemacht habe, falls doch, gleich hier beschweren. --Schnark10:02, 31. Mai 2011 (CEST)
Komisch. Es hat definitiv mit dem "Als erledigt markieren" zu tun, vermutlich in Kombination mit dem Verschieben der Abschnitt-Bearbeitn-Links direkt an die Überschrift. Ich habe die Funktion vorläufig deaktiviert, evt. Cache leeren. --Schnark09:25, 7. Jun. 2011 (CEST)
Überhaupt nicht komisch. Was habe ich mir denn da bloß gedacht, als ich diesen Code verbrochen habe? Korrektur kommt demnächst. --Schnark12:27, 7. Jun. 2011 (CEST)
Danke fürs Debuggen und die temporäre Lösung! Etwas anderes: IMHO sind die Eingabefelder bei LA+, SLA+ usw. etwas gar klein geraten. Magst du diese etwas breiter machen? --Leyo13:52, 7. Jun. 2011 (CEST)
Was heißt hier Debuggen? Ich habe – ich gebe es ja zu – nach deiner Meldung zum ersten Mal das Skript hier überhaupt für mich aktiviert, gesehen, dass ich den Fehler nachvollziehen kann, versucht ihn auf andere Skripte abzuschieben, nur um dann festzustellen, dass ich einfach völligen Unsinn programmiert habe. Die Felder breiter machen sollte auch kein Problem sein, mit ein bisschen Glück schaffe ich das noch vor Pfingsten. --Schnark15:17, 7. Jun. 2011 (CEST)
Ich könnte zwar jetzt eine neue Version einstellen, traue mich aber nicht so ganz, da sie sich beim Testen teilweise sehr komisch verhalten hat. Ich würde das Problem zwar gerne auf Firebug schieben, aber so ganz sicher bin ich mir nicht. Da ich die nächsten paar Tage nicht da bin, könnte ich auch nicht schnell genug auf Fehler reagieren. Also warte ich lieber bis Mitte nächster Woche. --Schnark10:04, 9. Jun. 2011 (CEST)
Wikieditor-Button um <source>-Tags einzufügen
Der Wikieditor hat leider nur einige rudimentäre Buttons. Wie kann man sich am elegantesten einen Button hinzufügen, der mir die <source>-Tags einfügt?
So, wie du das Skript verwendest, einfach ein SC in die customEditButtons aufnehmen. Das fügt zwar keinen Button ein, dafür aber eine Auswahlliste, in der unter anderem <source lang=""></source> vorhanden ist. Ich selbst verwende dafür Benutzer:Schnark/js/edithelper mit der Tastenkombination StrgStrg<s bzw. StrgStrg>s. --Schnark09:12, 31. Mai 2011 (CEST)
Dass mit SC eine Auswahlliste dafür hinzugefügt wird, hab ich leider (auch in der von dir verlinkten Seite) nirgends gefunden. Ebenso die Funktion des Edithelper-Scripts, da ich mich nicht erst durch den Code durchlesen wollte. Aber es scheint mir dafür ohnehin etwas überdimensioniert, zumal der Editor durch diese Scripte sowieso schon träge genug ist und ich keine zweite Compose-Funktion benötige. Die Auswahlliste ist genau richtig. Vielen Dank! :) -- ζ10:42, 31. Mai 2011 (CEST)
Da ich nie damit gerechnet habe, dass der Kompatibilitätsmodus zum Gadget ernsthaft verwendet wird, habe ich nirgends dokumentiert, welche Kürzel funktionieren, und welche ignoriert werden. Irgendwo habe ich eine kryptische Liste, mit der selbst ich nur mit Mühe etwas anfangen kann. Dass edithelper.js so etwas macht, ist mehr oder weniger dokumentiert. Es gibt übrigens noch die Sonderzeichen unterhalb des Bearbeitungsfensters, wenn du dort WikiSyntax auswählst, hast du auch die source-Tags. --Schnark10:59, 31. Mai 2011 (CEST)
An diese Liste unterhalb des Bearbeitungsfensters hätte ich jetzt im Leben nicht gedacht (viel zu versteckt). Aber die Auswahlliste passt schon. Immerhin gibt es dort wenigstens das <pre>-Tag, was ich bisher auch immer von Hand eingegeben hatte. So nebenbei: Gibt es eigentlich auch einen funktionalen Unterschied zwischen <code> und <code> oder liegt das eher im semantischen Charakter, ähnlich wie bei <b> und <strong>? (Hat sich geklärt. Ist eher ein semantischer Unterschied.[5]) -- ζ12:55, 31. Mai 2011 (CEST)
Du hattest recht. Die Verwendung dieser Buttons mit dem Wikieditor ist wirklich nicht sonderlich praktikabel. Ich hab den Wikieditor und die erweiterte Bearbeiten-Werkzeugleiste nun gänzlich deaktiviert und verwende nun nur noch das Extra-Editbuttons-Helferlein. Der Editor reagiert schneller und steht auch deutlich schneller zur Verfügung. Dauert jetzt nur noch ca. 1–2 Sekunden. Vorher das 2–3-fache – mindestens; jedoch nur auf dem alten Laptop. Schade eigentlich, da ich die Integration in den Vector-Skin ganz angenehm empfand und es zudem aufgeräumt war. Aber so ist es wohl doch etwas nervenschonender. ;) Dennoch vielen Dank. -- ζ10:26, 7. Jun. 2011 (CEST)
Mir sind die Überschriften etwas zu schwammig, ohne dass ich im Moment bessere Vorschläge machen könnte: Ist mein Personendaten-Skript nun ein die allgemeine Bedienoberfläche betreffendes Skript oder ein Skript zur Textbearbeitung? Mit meinen eigenen Überschriften bin ich auch nicht ganz zufrieden, vielleicht findest du ja irgendwas in der Mitte. --Schnark09:11, 20. Jun. 2011 (CEST)
Danke erstmal; steht ja noch ganz am Anfang, und erst nach Ansammlung (temporäre Tabelle „unsortiertes“) würden weitere Überschriften naheliegend – ansonsten in die en.WP schielen. Für PD vielleicht eine eigene Tabelle: „Inhalte und Daten“; würde auch Geo-Infos abdecken. Eine Tabelle „Darstellung und Hervorhebungen“ könnte einiges rein optische abdecken. autoantraege wäre etwas für, sagen wir, „Verwaltungsaufgaben“. „Textbearbeitung“ und „Bedienoberfläche“ (→wikieditor.js) meint themenunabhängig die Textarea und GUI. A propos letzteres … --PerfektesChaos10:30, 20. Jun. 2011 (CEST)
Ich kenne niemand, der sich so kompetent und verständlich zu Knöpfchen, Menüs und GUI äußern könnte. Magst du in der nächsten Zeit Wikipedia:Technik: Skin/GUI ausgestalten und dich als Bearbeiter in die Baustellenabsicherung eintragen? --PerfektesChaos10:30, 20. Jun. 2011 (CEST)
Da ihr beide ziemlich aktiv am Skin-Basteln und -Erklären seid, ein Vorschlag: WP:MBW bzw. das Redirect-Ziel in den WP-NR (Unterseite von Wikipedia:Technik: Skin?) verschieben und damit die „Helferseite“ für alle öffnen? Ich wollte euch mal fragen, bevor ich DerHexer den Vorschlag unterbreite. --Leyo10:10, 22. Jun. 2011 (CEST)
Das ist etwas tückisch; Vorschlag ist registriert, aber in etwa vier Wochen wird man da klarer sehen.
Was die DerHexer/monobook.js zunächst benötigen würden, wäre eine Anleitung und Funktionsbeschreibung sowie Konfigurationshinweise; die habe ich zumindest nicht gefunden. Danach wäre Wikipedia:Technik: Skin/Benutzerskripte der richtige Ort für die Verlinkung einer Doku-Seite.
Die ersten Jahre der Skript-Bastelei hatten notgedrungen Experimente und Schnipsel produziert. Man ging dann dazu über, sich (mit Erlaubnis) gegenseitig die monobook.js komplett abzukopieren. So Bluefish, PDD, DerHexer. Hier wurde aber auch inzwischen gesehen, dass Modularisierung und Anpassung an die individuellen Bedürfnisse mit wachsender Komplexität erforderlich wird. Links auf Doku-Seiten einzelner solcher unabhängiger Module kann DerHexer sehr gern jederzeit eintragen.
Ein Redir/Shortcut WPNR→BNR sehe ich ohne Ansehen des Benutzers mit großem Vorbehalt.
Danke für die Antwort. Ich bin aber nicht ganz sicher, ob ich mich klar genug ausgedrückt habe: Ich meinte die Skin-Wünsche-Seite. So wie es jetzt ist, ist DerHexer der einzige der sich um die Wünsche kümmert. Nach einer Verschiebung könnten dies auch andere technisch versierte Benutzer (wie ihr beiden) sein. --Leyo15:21, 22. Jun. 2011 (CEST)
Ich hatte es in der Tat nicht ganz verstanden. Die „Wünsche-Seite“ war mir völlig neu, erst recht der Shortcut.
Wie schon oben – etwas früh; in einigen Wochen wäre der richtige Moment für eine Service-Plattform. Zur Stunde tragen die neuen Seiten ja noch die Baustellenabsicherung und sind noch gar nicht ganz geboren.
Ich kann mir durchaus nach dem Muster der erfolgreichen Vorlagenwerkstatt ein Forum an dieser Stelle vorstellen. Die Vorlagenwerkstatt ist als WikiProjekt organisiert; das braucht es nicht. Denkbar ist eine analoge Seite Wikipedia:Technik: Skin/Werkstatt, in der Fragen und Wünsche zu CSS und JS geklärt werden und die von möglichst vielen hilfsbereiten Kundigen beobachtet wird.
Hallo Schnark. Wie wäre es, in der Dokumentation der Modulverwaltung von vector.js auf common.js umzustellen? Oder hast du dies nicht gemacht, weil deine Scripts (oder einige davon) nur unter vector und monobook korrekt laufen, nicht aber unter den exotischeren Skins? --Leyo08:34, 30. Jun. 2011 (CEST)
Es gibt zwar einige Skripte, die in den uralten Skins (d. h. vor Monobook) nicht funktionieren, das sollte aber kein Hinderungsgrund sein. Der im wesentlichen einzige Grund, warum ich noch auf vector.js verlinke, ist meine Faulheit. Wenn ich das nächste Mal eine Dokumentation ohnehin ändere und dabei daran denke, werde ich es umstellen. Falls dir mal langweilig werden sollte, darfst du aber natürlich auch gerne überall (oder dort wo du Lust hast) vector durch common ersetzen. --Schnark09:15, 30. Jun. 2011 (CEST)
FF4 etc.
Hi,
du hattest oben schon mit FF4-Aufrufen zu tun; hattest du irgendwelche Erkenntnisse gewonnen, was ich ggf. anpassen müsste? Wobei ich mit der Untergliederung in Laden des Kopfmoduls, Cookies, Versionsnummern und erforderlichenfalls Nachladens von englischen Arbeitsmodulen eine für asynchrone Störungen zugegebenermaßen anfällige Ablaufstruktur habe. LVB berichtet gerade ein Problem. Ich selbst möchte zurzeit möglichst ein Upgrade in meinen intensiven Umgebungen vermeiden, bzw. ich muss. – Relativiere alles Vorgehende: Elvaube berichtet soeben Workaround; somit erstmal zur Info, Beobachtung und Analyse.
Die Vorlagen werden je nach Wetterlage in der kommenden Woche angegangen. Etwas aufpassen muss ich bei der Umsetzung schon; {{UNTERSEITE_URL}} oder {{JETZIGER_MONAT_1}} würde der Unterstreichungsstriche beraubt: {{JETZIGER MONAT 1}} ist nicht 4.
Wenn sich die Probleme in Luft auflösen, wenn man importScript durch mw.loader.load ersetzt, dann waren es allenfalls irgendwelche Cache-Probleme, die durch das Bearbeiten der vector.js verschwanden, denn die beiden Funktionen funktionieren in diesem Fall völlig gleich.
Das Einzige, wobei man für FF4 aufpassen muss, ist es, wenn man (auf welche Weise auch immer) zwei Skripte nacheinander lädt, die aufeinander aufbauen. In diesem Fall darf man nicht davon ausgehen, dass das zuerst eingebundene Skript auch das zuerst ausgeführte ist. Somit ist dein asynchrones Nachladen eher hilfreich als schädlich.
Wenn dir irgendwas Probleme bereiten wird, dann die internen Änderungen am RessourceLoader, die mit MW 1.18 wohl wirksam werden, wenn ich richtig gelesen habe, verlässt du dich auf mw.loader.implement mit String-Parameter, da muss (soweit ich weiß) in Zukunft der String in einem Array übergeben werden, allerdings verstehe ich dazu weder dein Skript noch den internen Aufbau des RL gut genug.
Ich selbst verwende übrigens immer noch FF 3.6.16, nur in meiner Testumgebung habe ich auf 4.0.1 aktualisiert, aber da verwende ich dein Skript nicht. --Schnark09:20, 6. Jun. 2011 (CEST)
Danke für die Infos.
Ich hatte zumindest vor einigen Wochen/Monaten gesehen, dass importScript im HEAD eingefügt wird, jedoch chronologisch erst nachdem am Ende von BODY diese Einbindung mit load() ausgelöst worden war. Was daraus irgendwelche Brauser machen, überblicke ich nicht.
mw.loader.implement benutze ich nicht in WSTM_*, sondern habe dort eine eigene Verwaltung, die mitzählt, ob alle L, U, W brav geladen worden sind. loader.implement verwende ich nur in meinem RL-Test, bislang erfolgreich. Das WSTM-Kopfmodul deklariert allerdings für sich den loader.state "ready" – das sollte es ganz streng genommen erst nach ggf. erforderlichem Nachladen der Untermodule tun; hier werde ich nacharbeiten, wohl durch einen zusätzlichen Identifizierer "WSTM*" oder so. Bislang macht von diesem loader.state jedoch niemand Gebrauch.
Ich war wohl gestern nicht so ganz bei der Sache, vergiss bitte die Hälfte von dem Unsinn, den ich von mir gegeben habe, so schnell wie möglich.
importScript und mw.loader.load verhalten sich unterschiedlich, zumindest dann, wenn man sie vor dem document.ready-Event aufruft, letztere Funktion lädt das Skript per document.write, solange es noch früh genug ist. Insbesondere wird ein per importScript angefordertes Skript in FF4 asynchron geladen, per mw.loader.load nicht. Dass ich noch immer keinen Grund sehe, warum das einen negativen Einfluss haben sollte, heißt überhaupt nichts, da auch meine Aussage darüber, was sich mit FF4 ändert so nicht stimmen kann, die oben beschriebenen Probleme mit der Modulverwaltung lassen sich nämlich damit nicht erklären. Wenn du den RL nur so minimal ausnutzt, kann man die Probleme auch nicht auf den (für MW 1.18 behobenen, aber hier noch vorhandenen) Bug schieben, dass Callback-Funktionen zu früh ausgeführt werden, wenn man ein Modul nach document.ready anfordert.
Bevor ich noch mehr so Unsinn wie gestern erzähle, bin ich jetzt lieber still, und widme mich mal anderen JavaScript-Problemen. --Schnark09:18, 7. Jun. 2011 (CEST)
Kein Problem, das war ganz klar ein Sonnenstich am heißesten Ort des Landes, kurz bevor dich der Blitz getroffen hatte.
RL hatte Pech; unmittelbar nachdem er geschlüpft war kam FF4 mit seinem async und hat ihn aufgemischt. Das nächste Drama steht schon vor der Tür: HTML5 lässt weitere Irritationen durch geänderte Brauser-Implementierung erwarten.
importScript wird von der de.WP eingebunden. Sollte es hier verbreitet zu ähnlichen Problemen kommen, ließe sich die historische Implementierung lokal und ohne WMF zu fragen durch einen .load()-Wrapper ersetzen, auch etwa so.
In HTML lernt man nie aus, obwohl ich mich dahingehend keinesfalls für einen Anfänger halte. Wie bist Du auf die Lösung gekommen? Scheint mir ja kein WP-"Spezial" zu sein, sondern doch eher HTML-lösungsbasiert. In SELFHTML habe ich dazu (ohne Weiteres) jedenfalls nichts gefunden. Hast Du einen Tipp (Weblink) für mich, wo ich Deine Lösung ergründen / geistig nacharbeiten kann? Sieht mir irgendwie nach "HEX"-Schreibweise aus...
Doch, doch, das ist schon ein Wikipedia-(bzw. MediaWiki-)spezifischer Trick: MediaWiki erstellt für jede Überschrift automatisch einen Anker. Wie das genau funktioniert, ist nicht so ganz leicht zu durchschauen, wie du richtig erkannt hast, werden Sonderzeichen URL-kodiert, allerdings mit Punkten statt Prozentzeichen. Am einfachsten findet man den richtigen Ankernamen heraus, indem man direkt in den HTML-Quelltext schaut. Und sobald man dann weiß, welche ID der Anker hat, kann man diese dann natürlich direkt in Links verwenden. --Schnark09:14, 2. Jul. 2011 (CEST)
Ach, doch WP-"Spezial". ;-) Besten Dank für Deine Erläuterungen und den Link. Auf die Idee, in den HTML-Quelltext zu schauen, war ich gar nicht gekommen (ich hatte "nur" in den Sourcetext geschaut, also den, den man bearbeitet). Da ich jetzt im HTML-Quelltext etwa beim Buchstaben "P" das hier
Schon mehrfach hatten wir ergebnislos die Frage gewälzt:
Wenn WSTM schwere Syntaxfehler oder andere gravierende Probleme in einem Artkel findet – wie soll das Skript dies dem Anwender begreiflich machen?
Bereits abgelehnt hatten wir
Aufpoppende MsgBox mit kryptischen Hinweisen; unverstanden weggeklickt und verärgernd.
Exzessive Dekoration des Artikeltextes mit Kommentaren.
Nun bin ich geistig auf einem neuen Trip und wüsste gern deinen Kommentar.
Bislang gibt es über zwei Dutzend Stellen, an denen ein gravierender, beseitigungspflichtiger Fehler vom Skript bemerkt wird. In zwei Fällen am Artikel-Ende wird ein Kommentar eingefügt, der in der Diffpage bemerkt werden und die unmittelbare Beseitigung ermöglichen soll.
Künftig könnte, wenn am Anfang des Artikeltextes nicht bereits die Zeichenkette <!--WikisyntaxTextMod steht, ein Kommentarblock eingefügt werden wie folgt:
Zwangsweise erfolgt dann die diffpage als action=submit – wobei das Skript im Regelfall zwar kurz aktiv wird, aber zurzeit keine Aktivitäten im Wikitext entwickelt. Künftig könnte es wie folgt verfahren:
Der soeben eingefügte Kommentar wird gelesen und wieder aus dem Wikitext entfernt.
Unter der Überschrift der diffpage wird eingefügt:
<divclass="error"style="border: solid red 2px"><h2>WikisyntaxTextMod: ERROR in PAGE</h2><ul><li>Doppelte Kategorie: Songwriter</li></ul></div>
Die diffpage samt Wikitext-Bearbeitung sind im Überblick vorhanden; nach den Fehlern kann in Ruhe gesucht werden.
Sollte bei submit das Skript nicht aktiv sein, würde halt der Sammelkommentar im Wikitext verbleiben. Auch kein Totalschaden. (Vor einem Jahr hatte ich empfohlen, das große Skript nur bei edit zu laden. Mit Einführung des Kopfmoduls hatte ich diese Empfehlung wieder entfernt; sie war ohnehin nie umgesetzt worden.)
Wird der Fehlerbericht auf der diffpage nicht umgesetzt, ist es auch nicht mein Problem.
Andere Möglichkeiten, eine Information von der Seite edit auf die diffpage zu transportieren, wüsste ich nicht.
Die diffpage muss in der vertrauten Abfolge zwingend erscheinen, auch um sonstige Veränderungen darzustellen.
Ich stimme dir in allen Punkten zu, da du gerne alles von Hand machst, muss ich dich vermutlich auch gar nicht auf die Funktionen jsMsg (aus wikibits.js) bzw. mw.util.jsMessage (ab MW 1.18) aufmerksam machen. Falls du in den =-Balken noch irgendeine kurze charakteristische sonst nirgends auftauchende am besten reine ASCII-Zeichenkette einbaust, würde ich die Suche nach dieser auch in meine Wartungslisten übernehmen. --Schnark09:20, 4. Jul. 2011 (CEST) PS: Meine Modulverwaltung bindet dein Skript nur bei edit ein, allerdings wird vorher submit in edit übersetzt, nicht dass du dich deswegen wunderst.
mw.util.jsMessage hatte ich bislang so verstanden, dass er in dem div wirksam wird, in dem hidesnmessage greift. Da ich dieses kategorisch ausblende, würde ich das nie sehen.
Die charakteristische sonst nirgends auftauchende reine ASCII-Zeichenkette lautet: WikisyntaxTextMod ** ERROR in PAGE ** – ich kann aber noch die * gegen # austauschen, um regexp-Suchen zu entlasten.
Ich muss dann jetzt erstmal jsMessage und autoedit lesen; heute Mittag weiß ich mehr.
Du hast es völlig richtig erkannt; die paar Zeilen, die in jsMessage stehen, schreibe ich lieber selbst oder chatzimarkaki sie – auch aus eigenen Beständen. Ich plane, mich an das #top anzuhängen; wird dieses nicht gefunden, an das erste und mutmaßlich einzige h1.
Okay, „sn“ steht für id="siteNotice"; also die vorweihnachtlichen Spendenaufrufe.
Offensichtlich hantiert jsMessage() mit #mw-js-message als einziger Verankerung. Zwar kann man innerhalb von div#mw-js-message mehrere className verwenden, möglicherweise sogar mehrere messages verwenden (replace/add the message on top legt eher replace nahe), aber das Verhalten bei konfligierenden Botschaften ist mir nicht klar.
Zum Benachrichtigungsbalken .usermessage liegt mir zurzeit kein Ankerpunkt vor; du kannst mir ja mal eine Blindnachricht aufschreiben. Mein Eindruck ist, dass er an #mw-js-message aufgehängt sein dürfte. Vielleicht hast du grad noch einen Tab mit Balken zu Hand? Sonst melde ich mich ohnehin in Kürze zu Benutzer:Schnark/js/dialog.js.
Ein Nachrichtenhasser oder automatisches Neuladen einer Seite nach Lesen der Benutzerdisku könnte mw.util.jsMessage(null); auslösen. Damit wären alle Nachrichten unsichtbar.
Da komme ich lieber unerwartet mit einer eigenen Lösung aus dem Gebüsch gebrochen.
Die charakteristische Zeichenkette ist jetzt festgelegt als
WikisyntaxTextMod ## ERROR in PAGE ##
id="WSTM-page-error"
und wird in der Skript-Programmierung Dump-sicher zerstückelt.
Der Du-hast-neue-Nachrichten-Balken ist völlig unabhängig von jsMessage, wo das Ding hängt, kann ich gerade nicht sagen, wenn ich mich recht erinnere, irgendwo unmotiviert innerhalb von #bodyContent. Als charakteristische Zeichenkette wäre mir eigentlich irgendwas kürzeres lieber, wie es im Skript aussieht ist mir egal, Benutzerseiten sind nicht im Dump (zumindest nicht in dem, den ich benutze), wichtiger ist, dass sie nicht in Diskussionen auf Wikipedia:-Seiten vorkommt. Für den Normalanwender wäre eine textreichere Meldung vermutlich hilfreicher, also so nach der Art: "Im Text wurden leider Fehler gefunden, die sich nicht automatisch beheben lassen. Bitte behebe die folgenden Fehler von Hand und entferne den entsprechenden Kommentar im Quelltext." Oder sogar "…, der entsprechende Kommentar im Quelltext wurde bereits automatisch entfernt." --Schnark09:59, 5. Jul. 2011 (CEST)
Der einführende Hinweis „… Fehler gefunden, die sich nicht automatisch … von Hand …“ wird in der roten Kiste vorangestellt werden, wie auch der Nachsatz „… entsprechende auf dieser DiffPage sichtbare Kommentar wurde bereits automatisch entfernt.“
Als charakteristische Zeichenkette gibt es in WP:+WD: ein halbes Dutzend Vorkommen von „WikisyntaxTextMod“ – tMod ## ERR wäre deutlich kürzer und müsste treffen.
kannst Du da bitte MyDiff rausnehmen, weil es bei sehr vielen (im Chat gefragten) Leuten unter Helferlein bei Zusätzliche Karteireiter für externe Werkzeuge schon eingebunden ist? Vielen Dank. -- ianusius✆ Disk.✪ (Art.)23:31, 2. Jul. 2011 (CEST)
Ich glaube, er möchte gern, dass du ['action_history','mydiff'] mit .concat anhängst, wenn mediaWiki.user.options.get("gadget-toolserver-integration") auf undefined kommt. LG --PerfektesChaos12:14, 3. Jul. 2011 (CEST)
extratabs ist nicht unbedingt dazu konzipiert gemeinsam mit dem Gadget verwendet zu werden. MyDiff ist ganz bestimmt nicht die einzige Überschneidung. Nenn mir lieber die Tools, die das Gadget bietet, in meinem Skript aber fehlen. (@PerfektesChaos: Eher möchte ich, dass er mydiff per slice selber rausschneidet …) --Schnark09:23, 4. Jul. 2011 (CEST)
Die Dokumentation ist seit Jahren veraltet und ich bin der Ansicht, dass mein Skript alle Tools des Gadgets enthält, die sinnvoll sind. Nur wenn jemand anders ein ganz bestimmtes Tool vermisst, kümmere ich mich drum. --Schnark10:01, 5. Jul. 2011 (CEST)
Flo sucht jquery.hasClass() – ich sehe keinen Grund, warum sowas Elementares nicht geladen sein soll.
Schaust du bitte mal in Vorlage Diskussion:Bilderwunsch #Programmierung mit Kollaps – irgendwas mit Ladereihenfolge, .using oder sowas? Du kannst dich dann dort direkt anhängen; ich bin bekanntlich DOM-Schreiber, und wenn, dann hatte ich hasClass() immer zur Hand.
Zwei Minuten bevor ich diesen Abschnitt begonnen hatte, sah auch ich erneut die Fehlermeldungen in der Fehlerkonsole. Commons.js war aber offenkundig brav im Zehn-Sekunden-Raster aktualisiert woden, sonst wäre die Fehlermeldung nicht ausgelöst worden; warum auch immer hasClass erst eine Viertelstunde nicht und dann doch gefunden wurde, bleibt rätselhaft.
Ich merke mir also: Für einen jquery-Bugfix genügt es, hier auf dieser Disku ein Wehklagen zu hinterlassen, und Minuten später ist das Problem durch deinen starken Geist weggezaubert.
Da zu keinem Zeitpunkt jQuery.hasClass verwendet wurde, sondern immer nur eine globale Funktion mit diesem Namen, die beim ersten Kopieren nicht mitkopiert wurde, war es ausnahmsweise kein Ladereihenfolgenproblem. Ich habe trotzdem meinen Senf auf der Diskussion hinterlassen, und hoffe, dass der Code so schnell wie möglich wieder verschwindet, bei addHandler(ButtonLink,"click",newFunction("evt","collapseTable("+tableIndex+" ); return killEvt( evt );")); dreht sich mir einfach der Magen um. --Schnark09:57, 13. Jul. 2011 (CEST)
Danke erstmal für deine sinnliche wie übersinnliche Mitwirkung.
killEvt sprang mir auch ins Auge.
Auf en:Common.js ist ja sogar markiert @deprecated: Use $(element).hasClass() – dass Flo das noch kopiert hatte, war mir in dieser Viertelstunde irgendwie entgangen. Ich hatte es natürlich für jquery etc. gehalten und das fehlende $. nicht bemerkt.
Die Ablösung durch Krinkle läuft in der en:WP wohl parallel im Testbetrieb: en:MediaWiki:JQuery-makeCollapsible.js – soweit ich mich da eingelesen habe, ist das die allgemeine Nachfolgefunktion gleichzeitig für Navileisten, die von dir beanstandeten Tabellen und möglicherweise auch TOC. Sobald dies in MW eingeführt ist, sollten in der Tat alle entsprechenden Abschnitte aus der de:Common.js wieder entfernt werden. Da es aber offenbar irgendwie funktioniert und nur in einer einzigen Vorlage steht, sollte man nicht ein iota daran ändern und geduldig das Aussterben abwarten; bis dahin haben wir auch etwas zum Exprimentieren.
Nebenbei: Hast du gelesen Bugzilla:29595#c2? Das ist ja wohl der Gipfel. Es darf keinerlei wirksamen Unterschied geben zwischen komprimierter und debug-Version; höchstens einen Steuerparameter debug=true/false. Da sucht man sich ja dämlich, wenn das im einen Modus funktioniert und im anderen nicht.
Zum deprecated killEvt kommt noch die Tatsache, dass new Function ein implizites eval ist, und eval grundsätzlich böse ist.
Der Einklapp-Code ist nicht fürs TOC zuständig, das ist weiterhin eine Funktion in mediaWiki.util.js, da der Status noch zusätzlich in einem Cookie gespeichert wird. Auch Navi-Leisten kann man nicht so ohne weiteres durch den neuen Code ersetzten, da diese noch die Funktionalität haben, sich bei benutzerdefiniert vielen (Standard: viele = 2 oder mehr) einzuklappen.
Wenn du Bug 29595 für den Gipfel hältst, dann hast du bugzilla:29107 nicht gelesen (gut, ersteres ist mehr oder weniger erwünschtes Verhalten, letzteres war ein Bug). --Schnark09:15, 14. Jul. 2011 (CEST)
Ersteres ist überhaupt kein erwünschtes Verhalten, zumindest nicht von mir. Mit debug=false tritt Fehler A auf. Nun schalte ich debug=true, um ihn zu finden. Jetzt tritt Fehler A nicht mehr auf. Aber Fehler B.
Ja, ja, ich weiß schon, warum ich an meinem Komprimierer eine ganze Weile getestet hatte. Gleichwohl würde ich ihn keinem Dritten überlassen, weil von mir nie benutzte Syntax-Elemente wie leeres RE-Literal als Kommentar interpretiert werden könnte.
Das collapsible ist übrigens heute nacht nach Protesten kollabiert und zurückgerollt; dann eben in ein paar Wochen mit MW1.18.
Der einzige Unterschied zwischen Debug- und Produktionsmodus ist die Tatsache, dass in letzterem $ immer, in ersterem nur dann, wenn es nicht überschrieben wurde (was man niemals tun sollte) ein Alias für jQuery ist. In einem Live-Wiki muss man nicht debuggen (zumindest nicht die MW-Programmierer), und in seinem privaten Testwiki kann man es vermeiden $ zu überschreiben. Daher: Alles halb so schlimm. --Schnark10:22, 14. Jul. 2011 (CEST)
Signatur -- Variable?
Hallo Schnark, einige deiner Skripte verwenden signierte Vorlagen – ich denke da beispielsweise an die autoantraege.js. Lässt sich der Signatur-default mittels einer Variable in der vector.js überschreiben? Ich meine, irgendwo etwas in der Richtung gelesen zu haben … kann allerdings auch bei jemand anderem gewesen sein. Konkret hätte ich meine Anträge gerne mit --Nirakka statt mit -- Nirakka signiert. Gruß, --Nirakka23:39, 17. Jul. 2011 (CEST)
Für mich stellt sich jetzt natürlich die interessante Frage, wieso mein Skript überhaupt ein Leerzeichen da einfügt. Vermutlich auch nur, weil PDD mal irgendwann der Ansicht war, dass ihm das besser gefällt. Die meisten Skripte (und nicht nur meine) horchen auf die globale Variable usersignature, mit
Hier wäre auch dem Vorschlag von Leyo betreffend, zumindest für Schnarks Skripte, ein Lösungsansatz diese Variable einfach bei betreffenden Namensraum nur die Standardmäßige (Signatur-default) einzufügen. PS: Für mich ist das Leerzeichen „eigentlich“ korrekt (s.WP:SIG). -- πϵρήλιο℗15:39, 18. Jul. 2011 (CEST)
@ Perhelion: Was du mit (s.WP:SIG) aussagen willst, ich mir nicht so ganz klar, dort steht eindeutig, dass der Standard ohne Leerzeichen ist (und auf diesen Standard werde ich es wohl mit der nächsten Version auch stellen, überschreiben per usersignature wird natürlich weiterhin möglich sein). --Schnark09:21, 19. Jul. 2011 (CEST)
@Schnark: Das war mir nach deinem ersten Kommentar schon klar. Dort stand es bis vor „Kurzem“,mit Leerzeichen nicht schon sehr lange sondern von Anfang an[7] (wurde erst ein halbes Jahr vorher überhaupt eingefügt). Der Standard ist einfach der von MediaWiki vorgegebene und da sich niemand muckiert hat ist es halt so. Auf der Diss ist der Grund für das Leerzeichen angegeben (auf welche ich eigentlich zielen wollte). -- πϵρήλιο℗01:26, 20. Jul. 2011 (CEST)
Passt jetzt zwar nicht ganz zum Thema, aber könntest Du bitte nach der Vorlage:Gelöscht noch eine Signatur einsetzen? Alle anderen Vorlagen haben keine Probleme. Grüße -- ianusius✆ Disk.✪ (Art.)21:33, 19. Jul. 2011 (CEST)
Ich verstehe zwar nicht, wieso eine Vorlage, die ohnehin gesubstet wird, keine automatische Unterschrift hat, aber ich werde sie sobald ich kann ergänzen. --Schnark09:32, 21. Jul. 2011 (CEST)
Einfach mal Danke
Rote BlumeEin dickes Dankeschön … … und zwar dafür! Das ist klasse! Liebe Grüße, Sir Gawain
Großes +1! Dafür gebührt dir Dank und Respekt. Hatte noch keine Gelegenheit, das intensiver zu testen – sieht auf den ersten Blick aber wirklich sehr nützlich aus. Gruß, --Nirakka14:39, 26. Jul. 2011 (CEST)
Anfrage wegen automatischem Sichterrecht
Hallo. Ich habe gehört das du mir vielleicht weiterhelfen kannst. Ich frage mich warum ich noch keinen passiven Sichterstatus bekommen habe ? Du sollst dich damit auskennen :-) -- -=??=- --08:54, 27. Jul. 2011 (CEST)
So auf den ersten Blick sehe ich nicht, was deine automatische Beförderung bisher verhindert hat. Da Sargoth dir ja inzwischen Sichterrechte gegeben hat, ist es auch nicht mehr so dringend, nach der Ursache zu forschen. Am ehesten habe ich das Kriterium "7 Bearbeitungen mit einem Abstand von jeweils mindestens 3 Tagen" im Verdacht, das bei dir (wenn ich mich nicht verzählt habe) zwar erfüllt ist, aber nur knapp. Ich schaue in den nächsten Tagen noch einmal genauer hin, ob sich dann etwas ändert. Viele Grüße --Schnark09:44, 28. Jul. 2011 (CEST)
Verbessertes Diff
Hallo Schnark, bei all den Verbesserungen und Neuerungen (die Neue Ansicht gefällt mir) ist mir eine Manko aufgefallen, woher das kommt kann ich nicht sagen (oder ob es nur ein Ausschluss eines anderen benutzerdefinierten Scriptes ist), es lassen sich dort sämtliche Links nicht mehr benutzen (also aus dem Text wie Vorlagen, WL, Webl. ). -- πϵρήλιο℗00:22, 4. Aug. 2011 (CEST)
It's not a bug, it's a feature. Die Verlinkung stammte aus Cacycles Diff, ist aber so buggy, dass ich sie in meine diff.js gar nicht erst übernommen habe. --Schnark09:05, 4. Aug. 2011 (CEST)
Einmal zur Sicherheit den Cache leeren und wenn es dann immer noch auftritt mir die genaue Browserversion mitteilen. --Schnark09:09, 30. Jun. 2011 (CEST)
Cache geleert, diverse Reinungsprogramme drübergelaufen — nichts. Wie gesagt, Vector, Firefox 5, Windows 7 64-bittig. Und dann fiel es mir auf: man muss die Seite bearbeiten, und dann klicken! Auf Commons ging das ohne, deshalb war ich verwirrt. Grüße -- ianusius✆ Disk.✪ (Art.)15:27, 30. Jun. 2011 (CEST)
Nö, auf Seite bearbeiten muss man nicht klicken, mein Skript funktioniert auch direkt aus der Artikelansicht. Zeigt denn die Fehlerkonsole (Strg+Shift+J) irgendwas an (foo.dialog is not a function wäre mein Verdacht)? --Schnark09:12, 1. Jul. 2011 (CEST)
Im Idealfall (bei mit ist das so), sollte true, function, true, function herauskommen, falls nichts, undefined, true, function herauskommen würde, würde ich auf Firefox schimpfen und wüsste, was ich tun muss, falls true, undefined, true, function herauskommt, wäre ich ratlos. --Schnark09:29, 2. Jul. 2011 (CEST)
Da muss ich mal einige Zeit drüber meditieren. @PerfektesChaos (du liest doch ohnehin mit, oder?): Hast du eine Idee, wieso zur Hölle jquery.ui.dialog nicht auf Anhieb geladen wird, obwohl
Guten Morgen; da muss ich mich erstmal in deine .js einlesen. Spontan tippe ich auf async und empfehle .using() oder explizites callback. --PerfektesChaos10:08, 4. Jul. 2011 (CEST)
Ich würde immer nur mit .using() arbeiten.
Die javascript:alert sind nicht aussagekräftig. Wenn, dann müsste ein debug-alert unmittelbar vor dem Aufruf innerhalb der js-Seite stehen, damit in genau dieser Tausendstelsekunde der Ist-Zustand berichtet wird.
Die javascript:alert geben den Zustand nach Pasten in die Adresszeile wieder, Sekunden später, dann wegklicken, dann weiteres javascript:alert in die Adresszeile einfügen ...die Ausgabe zu diesem Zeitpunkt schließlich ist nichtssagend. Bei dir wird es funktionieren; mit FF4/async muss es das nicht.
Firefox 5, Windows 7 64-bittig. (seit 21. Juni 2011) klingt flott.
In js/dialog.js Zeile 212 heißt es: vardialog=
Ich würde (wie andere auch) immer schreiben: vardlg=
Grund: Bei einer Fehlermeldung illegal token dialog weiß ich nicht, ob meine Variable oder die Funktion gemeint ist.
jqueryui.com liest sich (noch nie im Leben gesehen):
A call to $(foo).dialog() will initialize a dialog instance ...
und weiter danach beispielsweise
$(foo).dialog({ autoOpen: false })
Bei dir sehe ich keine Initialisierung; Zeile 217 dialog.dialog({buttons: geht sofort ins Eingemachte.
Dies erklärt jedoch nicht dialog.dialog is not a function.
Gleichwohl könnte dies in manchen JS-Umgebungen trotzdem laufen, in anderen abstürzen.
Zu 1.) zeitlicher Ablauf: Es scheint so, dass zurzeit das .load(ui.dialog) gestartet wird, wenn die GUI gestaltet wird; die Benutzung von ui.dialog jedoch erst einige Sekunden später erfolgen kann, nachdem der Anwender zu dem Untermenü gelangt ist und dort angeklickt hatte. Das ist zwar methodisch nicht ganz blitzsauber (lahmes Netzwerk), müsste aber pragmatisch voll ausreichen (Cache).
4.) Etwas anderes fiel mir zu FF5 auf (ich habe noch nicht mal FF4): Man proklamiert „Geschwindigkeit und Stabilität“. Sowas wird üblicherweise auch durch Abspaltung von Kind-Prozessen erreicht; Stichwort „thread“ – Google Chrome macht das auch. Daher auch das neue async.
Ich durchschaue noch nicht ganz, wann und wo es von deinem js/auto*.js zu js/dialog.js geht. Das bekomme ich aber nach dem Frühstück auch noch 'raus.
Spätestens wenn ein Dialogfenster abgespalten wird, macht auch schon FF3 einen eigenen thread auf.
Nur Objekte, die an window angehängt wurden, sind „thread-safe“; also so, dass jeder thread auf dasselbe Objekt zugreift und nicht auf das gleiche (eine beim Start angelegte Kopie).
Es könnte also grundsätzlich sein, dass der Mutter-thread vom Eintreffen des .load(ui.dialog) erreicht wird, der unabhängige Kind-thread dies aber schon nicht mehr mitbekommt.
5.) Betreffend der letzten vier Statements in autoantraege.js:
Mit $(); wird die Ausführung von autoantraege.init() in eine Warteschlange gestellt und zur späteren Ausführung vorgemerkt: Nach document.ready, oder sonst demnächst; tendenziell nachdem die Ausführung des momentanen Skriptes beendet wurde; auch von der Abarbeitung eines entsprechenden Events in dessen Warteschlange abhängig.
In der darauffolgenden Zeile wird autoantraege.zeige_menu||autoantraege_menu geprüft. Diese werden aber unter bestimmten (mir noch nicht näher bekannten) Umständen erst von autoantraege.init() belegt.
Nachvollziehbar wäre für mich im Innern von autoantraege.init nach Um-/Erstdefinition das
if (autoantraege..._menu) { .load(ui.dialog); }
OT: Die prinzipielle Möglichkeit, die Standard-Skriptausführung um benutzerdefinierte Objekte zu ergänzen, erhöht Flexibilität und Akzeptanz. Dass sich die Ausgestaltung eines solchen Objekts kompliziert gestalten und dem Anwender mit Extrawurst nur mittels Hilfe des Entwicklers möglich sein könnte, zeigt Benutzer:Schnark/js/autoedit. Gleichwohl wäre ein solches .concat potenziell vorgefundener Benutzerdefinitionen ein klarer Mehrwert gegenüber dem Toolserver-Gadget.
using vs. load: Ich brauche jquery.ui.dialog erst, wenn der Benutzer auf einen der Links klickt, solange das Laden also nicht Stunden dauert, gibt es keinen Grund für eine Callback-Funktion. Die GUI-Initialisierung kann ja erfolgen, solange noch nicht alle abhängigen Dateien da sind.
3. $(foo).dialog() initialisiert einen Dialog mit Standardwerten, $(foo).dialog({parameter: wert}) initialisiert ihn mit vom Standard abweichenden Werten; wenn man eine Weile mit jQuery programmiert hat, gewöhnt man sich an sowas.
Das alles erklärt nicht, wieso es im Bearbeiten-Modus funktioniert. Der Hauptunterschied zwischen Lesen und Bearbeiten besteht (mit der neuen Werkzeugleiste) darin, dass jquery.ui.dialog geladen wird. Das legt irgendwie den Schluss nahe, dass aus irgendeinem Grund jquery.ui.dialog nicht geladen wird, zwar geladen wird, das Laden aber fehlschlägt, oder erfolgreich geladen, nachträglich aber überschrieben wird. Den ersten Fall meine ich ausschließen zu können, er führt die Zeile direkt davor aus, die Bedingung ist wahr, also wird er das Ding laden. Der zweite Fall könnte durchaus eintreten, wenn man sich Adblock Plus entsprechend absurd konfiguriert (da muss man sich aber wirklich anstrengen und das wirklich wollen), Noscript bekommt das sicher auch auf die Reihe. Der dritte Fall könnte bei einigen Benutzern auftreten, die bedingungslos jQuery überschreiben und dabei natürlich alle geladenen Plugins wieder rauswerfen, ich sehe aber in Benutzer:Ianusius/common.js nichts dieser Art.
Fazit: Ich werde gleich eine neue Version einstellen (die auch Punkt 5 betrifft). Ich glaube nicht, dass diese das Problem lösen wird (dazu ist sie gar nicht gemacht), aber vielleicht hilft sie ja doch. Ich habe verschiedene Versionen das Skripts mit verschiedenen Konfigurationen in verschiedenen Browsern getestet (FF 3.6, 4, 5; sowohl Linux als auch Windows), Leyo hat ebenfalls keine Probleme. Ianusius, starte Firefox mal im abgesicherten Modus, also ohne Addons etc. Falls dann alles funktioniert, liegt es an einem solchen. Wenn das nichts hilft, dann entferne mal testweise alle anderen Skripte aus deiner common.js (kann eigentlich nichts helfen, bei mir funktioniert sie problemlos). --Schnark09:47, 5. Jul. 2011 (CEST)
Ha! Alle Scripte bis auf hoo's siehe m:User:Hoo man/smart_rollback.js. Fragt mich nicht warum. Leyo scheint es nicht zu haben … Durch einen Informaten bin ich informiert worden, dass folgende Zeile schädlist:
Ich sehe zwar in dem Skript das Problem noch immer nicht, aber das musst du mit Hoo man klären. Wenn du deinen Cache leerst, bekommst du übrigens eine Version meines Skripts, in der man die Benutzerbenachrichtigung bei SLA sogar sinnvoll (jedenfalls sinnvoller als vorher) verwenden kann. --Schnark09:55, 7. Jul. 2011 (CEST)
So, habe mich jetzt selbst nochmal dem Problem angenommen und etwas probiert, es ist in der Tat der Fall, das jQuery dialog Modul fehlt. Ein funktionierender Workaround ist:
Wie man das richtig lädt weiß ich nicht, bin kein großer jQuery Fan und benutze meine eigene dialog Funktion ;). Ich hoffe aber, dass du damit trotzdem irgendwie einen fix basteln kannst - Hoo man (Diskussion) 00:52, 31. Jul. 2011 (CEST)
Da es auch Benutzer gibt, bei denen sich beide Skripte vertragen, vermute ich, dass auch noch Firefox 5 eine entscheidende Rolle spielt. Wenn jemand Probleme hat, sollte er sich also überlegen, ob ein Bugreport für Mediawiki oder einer für Firefox aussichtsreicher ist, ich sehe jedenfalls keine Veranlassung, irgendwelche Workarounds aufzunehmen. --Schnark09:17, 1. Aug. 2011 (CEST)
Da ich mitlese und weiter oben schon mal die Skripte analysiert hatte:
Es ist vermutlich ein generelles Problem, mit dem wir und international noch weitaus öfter zu tun bekommen werden.
Mein Tipp ist, dass durch die in FF5 und auch bereits in Chrome vorgenommene Verzweigung in parallele, asynchrone threads für dieselbe Seitendarstellung Probleme mit eintrudelnden Ergebnissen weiterer asynchroner Prozesse ergeben.
FF5 und Chrome nehmen eine Verzweigung und Bildung eines neuen Threads vor, wenn ein setTimeout() ausgelöst wird. Ich erinnere mich, sowas bei Hoo man gesehen zu haben.
Schnark hatte ordnungsgemäß das Laden der jquery.dialog abgefordert. Macht der Browser nun einen neuen Thread für das Timeout auf, wird die Umgebung (geladene Funktionen und Variablen) in den neuen Thread kopiert, der nach Zeitablauf weiter ausgeführt wird. Trifft jetzt die Definition des asynchronen jquery.dialog ein, wird die Umgebung des alten thread bereichert. Der wird aber nicht mehr ausgeführt.
Zurzeit habe ich selbst keine Notwendigkeit, von FF3.6.18 auf FF5 umzusteigen; vielmehr laufen noch nicht alle meine Add-Ons mit FF5. Ich habe keine Lust, einen gesonderten Rechner nur für diese Aktion mit FF5 zu versauen, um das zu testen. Nachdem ich das Upgrade gemacht habe, werde ich mir die Geschichte erneut anschauen. Vielleicht hat sie sich bis dahin durch Weiterentwicklung von FF oder MW oder jQuery von selbst erledigt. Eine Bindung an das window-Objekt wäre thread-safe.
Ich habe gestern ein bisschen mit FF5 und setTimeout rumprobiert, sodass ich deine Vermutung so lange als unzutreffend verwerfe, bis du mir ein beweisendes Beispiel lieferst. Eher vermute ich einen sehr subtilen Bug in mediawiki.js, der aber mit 1.18 schon wieder verschwunden sein kann, da der Code inzwischen nur noch geringe Ähnlichkeit mit dem aktuellen Code hat. Testen kannst du mit einem portablen Firefox, unter Linux mit Wine. --Schnark09:43, 4. Aug. 2011 (CEST)
Danke für das Link, aber ich werde in den nächsten Wochen keine Analysen in dieser Richtung vornehmen. Ich baue darauf, dass sich das im Herbst durch MW+FF geradegeruckelt haben wird; falls nicht, werde ich krötig. – Ob diese Simulationsbedingungen unter Ux den Anwendern unter Windows in diesem Punkt exakt entsprechen würden, weiß ich nicht; gerade Timing ist in Ux und MS grundverschieden konzipiert.
Den Tipp mit dem Timeout hatte ich gerade aus dem entfernten Kollegenkreis bekommen, wo man nach drei Tagen Suche mit mehreren Leuten genau dies identifizieren konnte.
Unbeabsichtigt ist bei Hoo man irgendwas. Zwei Leute hatten nach Umstieg auf FF5 dort ein Problem, und als sie sein Skript ’rausnahmen, lief es. Interessant wäre es schon, den Auslöser zu identifizieren, um künftig fehlerträchtige Praktiken zu vermeiden. – Aber vielleicht ist es ja in ein paar Wochen Geschichte.
Ich nutze in meinen Scripten setTimeout und zwar aus dem einfachen Grund, das ich auf meine Wiki Funktionen warten muss (hoofr), ohne die geht in meinen Scripten gar nichts (und ich glaube es gibt hier auch keine wirklich alternative, selbst wenn jQuery da was für hat, am ende wird auch das mit timeouts arbeiten müssen). Während meiner Tests habe ich übrigens gesehen, das jQuery dialog nur dann geladen wird, wenn ich den Cache frisch geleert habe, anderweitig wurde das Modul bei mir gar nicht erst vom Server angefordert (egal ob mit oder ohne mein Script, FF5). - Hoo man (Diskussion) 13:55, 5. Aug. 2011 (CEST)
Ok, mir kam inzwischen doch noch eine Idee um auf die Timeouts zu verzichten, die Scripts werden jetzt mit onload des script Tags mit meinen Wiki-Funktionen gestartet. Ich hoffe das ist so sauberer, schneller etc. (Kann sein, dass ich es wieder entfernen muss, falls es Probleme gibt, hoffe aber es funktioniert) - Hoo man (Diskussion) 15:53, 5. Aug. 2011 (CEST)
Naja, explizites Einbringen von script-Tags ist nicht gerade Wiki-Politik.
Deinen Ansprüchen an professionelle Software dürfte doch eine der in solchen Fällen übliche Lösungen näher kommen, auch das Trommeln im 50ms-Rhythmus ist für den Benutzer war nicht glücklich. Ich würde hier Callback empfehlen:
Im benötigenden Skript statt oben und setTimeout(hitCount.main, 50); bzw. als hitCount.load_hoofr()
Danke, für diese nette Idee, hab das so fast 1:1 umgesetzt :) (da merkt man, dass ich doch noch relativ unerfahren mit JS bin). Meine Idee sah übrigens so aus - Hoo man (Diskussion) 01:37, 6. Aug. 2011 (CEST)
Schnarks Lieblingslösung mit trigger() und bind() ist edel; sie zeugt von einem Jahr Blut, Schweiß und Tränen? Die jQuery-Basisfunktionen sind seit einiger Zeit auf unseren Wiki-Seiten verfügbar; bei den höheren Funktionen weiß ich aber nicht immer so genau, ob sie diese Woche von unserer Wiki-Zentrale standardmäßig ausgeliefert werden oder ob ich sie vorher extra anfordern muss – deshalb bin ich dieses Jahr da etwas zurückhaltend.
Meine selbstgestrickte Variante würde auch auf anderen Webseiten funktionieren, in denen jQuery nicht verfügbar ist; Schnark bemerkte zutreffend, dass dann eine globale Variable hinzukommt.
Übrigens habe ich oben noch eine kleine Unsauberkeit drin; load() soll nur einmal aufgerufen werden:
Hallo Schnark, musste gestern etwas schmerzlich feststellen (Fehler), dass dieses nette Feature gar nicht für Dateien vorgesehen ist. Lässt sich da noch was arrangieren? Viele Grüße -- πϵρήλιο℗16:50, 23. Jul. 2011 (CEST)
Du hättest halt den Haken bei der Option „Autor informieren“ entfernen müssen. Falls es irgendeine Standard-Vorlage für Benutzer-Benachrichtigung bei Logo-Ersetzung etc. gibt, kann ich die natürlich auch einbauen, aber von so einer Vorlage weiß ich nichts. --Schnark09:11, 25. Jul. 2011 (CEST)
Script-Sicherheitslücken
Hi, Danke nochmal für den Hinweis. Beim nächsten Mal gerne erst private Notiz an mich, und erst wenn ich nicht reagiere öffentliche Notiz. Bei de-wiki Scripten kann ich zwar nicht direkt helfen, aber ich würde wohl schon einen Admin finden, der einen Patch aufspielt. Grüße, Amalthea213:20, 4. Aug. 2011 (CEST)
Hi Schnark! Dein Skript liefert mit dem Artikel Salsa (Tanz) keine Ergebnisse, bzw. mir scheint, als liefe es in einen Timeout. Ich frage ich deshalb gerade, ob das ein vor dir vorgesehener (also im Skript) eingebauter Timeout ist, oder ob die Wikipedia-Server einfach nicht schnell genug sind und das Skript deshalb zu keinem Ende kommt, oder ob möglicherweise mein Browser (Firefox 5.0) die Ausführung des Skripts einfach irgendwann abbricht, weil nicht schnell genug Ergebnisse zurückkommen. Hast du eine Idee? -- Gruß Sir GawainDisk.09:44, 27. Jul. 2011 (CEST)
Du hast die Schwachstelle meines Skripts entdeckt. Ich probiere das jetzt nicht aus, da ich an Mexiko schon genügend rumprobiert habe. Ich bin mir ziemlich sicher, dass es nicht zu einem Timeout kommt. Bei Mexiko konnte ich nach einer Viertelstunde geduldigen Wartens, in der scheinbar nichts passierte, schließlich daran feststellen, dass mein Skript doch noch etwas tat, dass Windows mir mitteilte, der Arbeitsspeicher wäre jetzt voll. Gerade bei langen und alten Artikeln frisst mein Skript Unmengen an Arbeitsspeicher, sodass es dort (zurzeit) nicht einsetzbar ist. Ich will dir keine Hoffnung machen, dass mir in nächster Zeit eine geniale Idee kommt, dieses Problem zu beheben, aber ich schaue mal, was sich machen lässt. --Schnark09:50, 28. Jul. 2011 (CEST)
Ok, ist jetzt ja auch nicht so immens wichtig. Ich wollte nur sicher gehen, dass es nicht an mir resp. meinem Rechner liegt. -- Gruß Sir GawainDisk.11:30, 28. Jul. 2011 (CEST)
Ups. Dass das Skript teilweise ineffektiven Code enthielt, stimmt schon, der Hauptgrund für das Scheitern lag aber an einem ziemlich dämlichen Programmierfehler. Mexiko habe ich jetzt in ca. einer 3/4-Stunde analysieren können (man kann sogar mit etwas Mühe in einem anderen Browsertab an anderen Dingen arbeiten), und musste dabei nur vier Mal Firefoxens Frage, ob er das nicht antwortende Skript abbrechen soll, verneinen. Die Chancen stehen also gut, dass du jetzt auch beim Salsatanz in endlicher Zeit ein Ergebnis erhältst, ob es sinnvoll ist, ist eine andere Frage, Mexiko jedenfalls sieht etwas merkwürdig aus. --Schnark10:06, 29. Jul. 2011 (CEST)
Nachtrag: Salsa (Tanz) ist im Vergleich zu Mexiko ein ziemlich kleiner Artikel, entsprechend schnell und problemlos tut die neue Version meines Skripts jetzt ihre Arbeit. Also: Browser-Cache leeren und dann selbst ausprobieren. Allerdings stört die Vandalismus bedingt lange Versionsgeschichte einzelner Textstellen teilweise stark, da sollte ich mir eine bessere Darstellung einfallen lassen. --Schnark11:11, 29. Jul. 2011 (CEST)
Das Script ist eine sehr gute ergänzende „Alternative“ zum wikitrust-script von NetAction, wobei ich eine Frage hätte, da es ja schon relativ lange dauert bis ein Ergebnis erscheint (bei Google Chrome ~ 10min, also dem Artikel, bietet sehr int. zu einem best. Benutzer), wurde ein Faeture zum Abspeichern wirklich nicht schlecht sein (oder eine Hilfe). Des Weiteren ist die Link-Bezeichnung im Tab ziemlich redundant (bis auf Bindestrich) mit einem anderen externen Tool (von dir?). (Nur am Rande Betr Tab: "Alle Seiten" würde ich auch umbenennen bzw auf allen Seiten aktivieren!? Wie wäre ›Unterseiten‹?) -- πϵρήλιο℗14:01, 24. Aug. 2011 (CEST)
Schnark hat sich am 11. August auf zwei Wochen abgemeldet; ich hoffe, du kannst mit der verbleibenden Antwortzeit leben. --PerfektesChaos15:14, 24. Aug. 2011 (CEST)
Wenn man halt C&P von einer alten Version macht und dabei nicht bemerkt, dass man ein altes Datum mitkopiert …
Abspeichern lässt sich das Ergebnis wie jede Webseite über Funktionen, die dein Browser bieten sollte. Mein Extratabs-Skript führt so viele Reiter ein, dass eine Kollission in Bezeichnungen nicht zu vermeiden ist, sodass ich gar nicht erst versuche, sie zu vermeiden; „Alle Seiten“ verwende ich persönlich nur bei Benutzerseiten, sodass ich keinen Grund habe, das auch in anderen Namensräumen zu aktivieren. --Schnark09:17, 26. Aug. 2011 (CEST)
Danke...
...für diese hilfreiche Information. Habe wohl mit enwiki und plwiki zuletzt zwei mit 10 Edits erwischt. Gut zu wissen auch, dass zhwiki sogar 50 braucht. Gestolpert bin ich über dieses lästige Feature, weil ich einen Bot in anderen Wikis einsetzen möchte, es ist schade, dass dies nicht über SUL außer Kraft gesetzt wird. Viele Grüße --Cactus2613:21, 27. Aug. 2011 (CEST)
Wenn man ohne Computer Urlaub macht, hat man die Möglichkeit, mal sorgfältig offline zu programmieren. Und da ich die API-Dokumentation nicht auswendig kann, kamen dabei halt vor allem Dinge raus, bei denen ich auf die API verzichten konnte (für Benutzer:Schnark/js/skriptstatistik.js hat es grade so gereicht). --Schnark10:21, 31. Aug. 2011 (CEST)
Solange es sich nicht um ein Skript handelt, bei dem ich von Fehlermeldungen überschwemmt werde (und das betrifft eigentlich nur Benutzer Diskussion:Schnark/js/personendaten.js), ist diese Diskussionsseite hier der beste Ort. Habe den Tippfehler (auch in der englischen Lokalisierung) korrigiert, wie üblich ist bei dir noch eine Cache-Leerung notwendig, damit die neue Version aktiv wird. --Schnark09:07, 31. Aug. 2011 (CEST)
Ich sitze gerade an der Reorganisation und möchte dir eine neue API-Funktion WikisyntaxTextMod_Edit() zur Verfügung stellen. In diesem Zusammenhang würde ich gern einheitlich jQuery in WSTM verwenden.
Bislang schrieb ich mit DOM
var button = document.getElementById("wpDiff");
if (button !== null) {
button.click();
}
Das funktionierte fein.
Nun schreibe ich mit jQuery:
var $button = WSTM.ia.$editform.find("#wpDiff");
if ($button.length) {
$button.click();
}
Das funktioniert grundsätzlich auch; ich gelange hinterher auf die Diffpage.
Nur erscheint bei jQuery vorher die MsgBox „Warnen, wenn eine zur Bearbeitung geöffnete Seite verlassen wird,
die nicht gesicherte Änderungen enthält“ – die ich in den Vector-Einstellungen aktiviert habe und auch behalten möchte. Verursacher: w/extensions-1.17/Vector/modules/ext.vector.editWarning.js
Andere haben das gleiche Problem: FzW – dem Zeitpunkt nach jQuery/1.17-mäßig bedingt.
Der editwarner ist professionell, robust und unangreifbar geschrieben. Er wird aber offensichtlich durch das onUnload-Event ausgelöst.
Warum wird beim DOM.click() kein Unload ausgelöst?
Warum wird beim jQuery.click() ein Unload ausgelöst?
Wie fischt man in jQuery das onbeforeunload aus der Queue, bevor es aufgetreten ist, damit es danach der editwarner nicht mitbekommt?
Alternativ: Wie kriegt man ein $form.submit("wpDiff") hin, um mitzuteilen, welchen der drei Submit-Knöpfe man gedrückt hat?
Sollte den HotCat-Autor eigentlich auch interessieren.
Jetzt nochmal mein obiges Geschreibsel lesend, fiel mir auf: Der Warner wird ja nur ein einziges Mal beim .ready ausgeführt und hinterlässt sich in window.onbeforeunload – das hatte ich ursprünglich anders interpretiert.
var $button = WSTM.ia.$editform.find("#wpDiff");
if ($button.length) {
window.onbeforeunload = null; // stop editwarner
$button.click();
}
Das killt allerdings auch jeden anderen Handler; aber ich kenne keinen anderen und müsste das erstmal in Kauf nehmen. Das ist der Nachteil an anonymen Funktionen: Hieße das Ding editwarner, könnte ich ihn gezielt aus der Händlerliste streichen.
Der editwarner ist professionell, robust und unangreifbar geschrieben.*räusper*
Dass sich $jQuery.click() irgendwie komisch verhält, musste ich auch sonst feststellen, sonst hätte ich in Benutzer:Schnark/js/gestures.js bei gesture-→ auch einen kürzeren Code verwendet. Mit dem click von jQuery folgt der Browser dem Link jedenfalls nicht.
Es müsste gehen, wenn du ein input mit name und value wpDiff zum Formular hinzufügst und anschließend submittest, ansonsten bleib einfach bei DOM, niemand zwingt dich jQuery zu verwenden, wenn das schlechtere Ergebnisse liefert als herkömmliche Methoden. --Schnark09:18, 6. Sep. 2011 (CEST)
Okay, der Quellcode des editwarner las sich unangreifbar – dass er versucht, so gut wie möglich ein irrtümliches Verlassen zu verhindern. Irgendwie mag es immer mal Situationen geben, in denen man sich in manchen Browsern dran vorbeischmuggelt. Unangreifbar meinte, dass man ihn außer späterer Nullsetzung nicht explizit umgehen kann.
Halb besoffen ist rausgeschmissenes Geld, sagte mein Herr Vater. Mischkonstruktionen wie aus DOM und jQuery mag ich nicht. Deshalb ist mir auch das momentane addPortletLink nicht recht geheuer; ein kompatibler Aufruf hat gefälligst historische Syntax und jQuery zu akzeptieren und intelligent zu analysieren – also beim ersten Parameter zu gucken, ob er mit # anfängt, ansonsten # voranzustellen. Wenn man schon beim letzten Parameter jQuery-Format einführt.
Ich muss mich korrigieren: Unter FF4/Linux mit aktuellem jQuery löst das click() auf einer Checkbox auch den change-Handler aus, nur FF3/Win mit der hier verwendeten jQuery-Version tat das nicht. Frag mich nicht, woran es liegt. --Schnark09:06, 7. Sep. 2011 (CEST)
Hi, du hattest dich erkundigt, „ob ein Admin einen von dir gestellten SLA in meinem BNR ausführt“. – Ja, wurde gemacht; meine Löschbegründung war bewusst kurz „erl.“ gehalten; der Admin beschäftigte sich wohl damit, „Leere Wartungsseite“ ist von ihm; allerdings hatte ich die Seite selbst angelegt und war der einzige Bearbeiter. Ich hatte vorhin meinen Notizzettel in eine Aufräumaktion umgesetzt. Schönen Sonntag --PerfektesChaos00:20, 11. Sep. 2011 (CEST)
Äh, nein; war mir auch nicht wirklich aufgefallen. Ich muss den Vorgang heute Abend noch mal in Ruhe nachvollziehen; WSTM war es mutmaßlich nicht, ich arbeite zurzeit aber per Skinwechsel an anderen Skripten, die jedoch im BNR nicht anspringen sollten. Direkt eingegebene nbsp heißt \xA0 – das könnte die Handschrift eines meiner Skripte sein. WSTM wird bei mir ausschließlich in Vector tätig; andere Sachen in anderen Skins. Danke für den Hinweis und sorry for confusion; werde den beabsichtigten Zustand herstellen. P.S.: Dein niedliches Infokästchen erscheint grad zweimal --PerfektesChaos10:53, 12. Sep. 2011 (CEST)
Auf Wartungsseiten ist es völlig egal, ob du irgendwelche Leerzeichen zerstörst oder nicht, für sowas hat man ja ein vernünftiges Diff-Skript. Firefox 2 war bekannt für diesen Fehler, aber das sollte seit 3.0 kein Problem mehr sein. --132.230.1.28 (Schnark abgemeldet, um zu sehen, ob er es schafft, den Infokasten auch doppelt zu sehen, bei dem aber alles ganz normal ist) 11:00, 12. Sep. 2011 (CEST)
Ich bin nicht besoffen und sehe trotzdem zwei Kästen. – Anfang des Tippens, jetzt nur noch einer in der Vorschau.
Ich habe einen FF 3.6.22 benutzt und höre zum ersten Mal von einer FF2-U+00A0-Ersetzung; war mir nie aufgefallen und wäre grundsätzlich in meinem Sinne. Funktionen, die Whitespace und vor allem Tabs in HTML-Quelltext (und anderen Quelltexten) in Leerzeichen wandeln, habe ich seit Jahrzehnten an allen Ecken und Enden zu laufen; auch schließende Blanks außer in Whitespace schmeiße ich mit Vergnügen beim Abspeichern weg. Insofern blicke ich nicht immer ganz durch, ob, wann und wo ich das war, und werde gleichwohl forschen, ob FF oder ein JS von mir hier aktiv war; falls Letzteres – wieso im BNR, WSTM hätte Entities draus gemacht.
Ich habe gut geschlafen, sehe gleichwohl bei action=edit zwei Kästen.
Betreffend des umgewandelten Leerzeichens habe ich WikEd im Verdacht.
FF3.6.22 + Chrome12 erscheinen unschuldig. – IE8 hängt sich auf der Bearbeitungsseite auf und muss abgeschossen werden.
WSTM lässt sie im freien Text standardmäßig unverändert, ändert/löscht sie allerdings kommentarlos innerhalb von Links (und manchen Tag-Konstruktionen). Empfohlen wird eine benutzerdefinierte Ersetzung als .
Beim jüngsten Edit waren sie (abweichend vom BK) offenbar erhalten geblieben ("Lucky Star").
Bei WikEd erinnere ich mich, kürzlich entsprechende Transformationen gesehen zu haben, wenn Text aus der Textarea in die bunte Darstellung und von da aus wieder in die Textarea konvertiert wird.
diff@MW zeigt an, dass es eine Änderung gibt, aber bekanntlich noch keine Whitespace-Unterschiede. diff@Cacycle behauptet, es gäbe keinen Unterschied. diff@Schnark kann es anscheinend sehen?
Es wäre eine relativ neue Änderung in WikEd, die bisher jedenfalls nie aufgefallen war.
Ich werde in der nächsten Zeit auf der Seite eindampfen und dabei in unterschiedlichen Konstellationen auf "Lucky Star" achten.
Wenn du nicht den Standard-Kasten „Bitte beachte unsere Richtlinien für Diskussionsseiten und beende deinen Beitrag mit deiner Signatur“ meinst, der immer zu sehen ist, kann ich es immer noch nicht nachvollziehen. Wie sieht es denn z. B. bei BD:Leyo aus?
WikEd ist natürlich alles zuzutrauen.
Mein Diff zeigt mir Dinge wie „dieses 1,80m hohen, 1,60m breiten und 130kg schweren Mikoshi“. Du musst antispoof abschalten, um es hier zu sehen. Was für Leerzeichen es sind, kann ich aber nur mit antispoof im normalen Diff sehen.
Ich kann es nicht nachvollziehen, weder abgemeldet noch unter anderem Namen angemeldet, weder im Firefox noch im Internet Explorer. Nach dem „Größe der Seite bzw. des bearbeiteten Abschnitts: 6 KB.“ kommt sofort das Editfenster. Falls du es weiter untersuchen willst, die Magie geschieht durch MediaWiki:Editnotice-3 und Benutzer Diskussion:Schnark/Editnotice. Falls du den Kasten einfach nicht mehr sehen willst (für dich ist er ohnehin nicht gemacht), kannst du dich in der letztgenannten Seite in der switch-Anweisung zu mir gesellen. --Schnark10:48, 13. Sep. 2011 (CEST)
Der doppelte Kasten, ebenso wie die doppelte Anzeige von Seitenschutzwarnungen, hängt mit WikEd zusammen. Bei aktivierter automatischer Vorschau beim Bearbeiten, ist der erste Kasten über, der zweite unter der Vorschau. Bei deaktivierter Vorschau gibt es halt dann 2 Kästen direkt hintereinander. Gruß --Steef38912:41, 13. Sep. 2011 (CEST)
Das erklärt natürlich auch im Nachhinein [9]. WikEd-Bugs gehören nicht zu dem, auf das ich Rücksicht nehmen kann und will, falls sich einer von euch mit Cacycle rumärgern will: Vielleicht liest er die Fehlermeldungen auf seiner Diskussionsseite ja wieder in 2½ Monaten … --Schnark12:53, 13. Sep. 2011 (CEST)
WikEd ist an allem schuld.
Bei "Lucky Star" werden ohne WikEd keine Leerzeichen ersetzt.
Es erscheint beim Beginn dieses Edit nur ein Kasten, oberhalb „Größe der Seite bzw. des bearbeiteten“.
Ansonsten sind id="editnotice-ns-3" eingefügt:
nach <div id="wp_talkpagetext" class="wp_intro">...</div>
nach <form id="editform">
Der untere stammt offenbar von WikEd; Ursache hat sich mir noch nicht erschlossen, gelegentlich mal den (ansonsten durchaus anregenden) Quellcode lesen.
Irgendwie drängt sich mir die Frage auf, ob WikEd überhaupt Features hat, oder ob das alles nur Bugs sind … Zu was ein mit position: absolute; gespickter Quelltext anregen kann, will ich eigentlich auch nicht so genau wissen … --Schnark10:16, 14. Sep. 2011 (CEST)
Och, nun zürne mal nicht.
Der arme Junge hat wohl inzwischen >¾ MB Quellcode an der Backe. WSTM kommt momentan nur auf ~440 kB, und die so nebenher zu pflegen und weiterzuentwickeln ist schon nicht ohne.
Dass ich mir Anregungen hole, heißt ja nicht, dass ich workarounds übernehme, und Sachen, die „ja erstmal irgendwie funktionieren“.
Problematisch ist halt nur, dass der Bursche mit der Fehlerbeseitigung und Anpassung an sich ändernde Rahmenbedingungen kaum nachkommt. Nach einem guten Monat sollte man geantwortet haben, möglichst auch schon gefixt. Das ist natürlich weniger sexy als neue Features zu kreieren.
Ich habe jedenfalls in den letzten Tagen gemerkt, das ich bei abgeschaltetem WikEd schon gar nicht mehr editieren kann.
Ich zitiere einfach mal aus dem Hinweiskasten, der da nicht umsonst steht: „Bei allgemeinen Fragen, die nichts mit meinen Skripten zu tun haben, wird dir unter Wikipedia:Technik/Skin/Werkstatt sicher schneller geholfen als hier.“ --Schnark09:09, 19. Sep. 2011 (CEST)
Hi, du hast bzgl. meines Tools geschrieben, dass $('ul#pagehistory li'); unperformanter ist als $('#pagehistory').find('li');. Hast du dafür eine Quelle? War immer fest der Meinung, dass die find-Methode recht ressourcenfressend ist, aber ich lasse mich gerne eines besseren belehren :) Ansonsten - danke für die Tipps. Besonders mein Fauxpas mit der nicht geschlossenen XSS-Lücke.. --Nightfly85 | Disk09:45, 7. Okt. 2011 (CEST)
Lies mal weiter, die Kommentare behaupten nämlich das Gegenteil (auch wenn ich das eigentlich nicht glauben kann) :). --Schnark10:26, 7. Okt. 2011 (CEST)
Ich kann mir auch nicht vorstellen, dass .each schneller sei, höchstens wenn .length in jeder Iteration neu benutzt würde. Ein weiterer Test kam zu einem ähnlichen Ergebnis: Der Unterschied ist minimal, aber er ist da. --Nightfly85 | Disk10:29, 7. Okt. 2011 (CEST)
Nein. Bei LA ist ein noinclude unnötig, da der Baustein das selbst setzt, bei SLAs auf Vorlagen tut mein Skript dies bereits, SLAs auf Seiten, die irgendwo anders noch eingebunden sind, sind ohnehin nicht regelkonform. --Schnark09:20, 10. Okt. 2011 (CEST)
Es macht es (übrigens genau wie PDDs Skript) dann, wenn der Name ein "Vorlage:" enthält. Und ich schrieb auch nicht, dass irgendwelche Einbindungen nicht regelkonform wären, sondern SLAs auf noch eingebundene Seiten. --Schnark10:40, 10. Okt. 2011 (CEST)
Hi Schnark, seit ein paar Tagen laufen einiger Deiner Erweiterungen auf meiner commons.js. Gerade habe ich zum erstenmal ge-la-t. Great!!! Was für 'ne Vereinfachung! Andererseits ist mir der comment auf der BD etwas zu betulich. Wie könnte ich das ändern = customizen? Dank und Gruß F.01:46, 12. Okt. 2011 (CEST)
Meinst du die Option beim LA, den Erstautor gleich auf diesen hinzuweisen, oder meinst du die Menüeinträge auf Benutzerdiskussionsseiten, um diesem mehr oder weniger nützliche Hinweisvorlagen auf die Disk. zu knallen? Ersteres ließe sich bereits jetzt konfigurieren, letzteres müsste ich noch einbauen, wäre aber im Prinzip kein Problem. --Schnark09:10, 12. Okt. 2011 (CEST)
Ich meine diesen von Deinem Skript erzeugten Text auf der BD des Benutzers, der den inkriminierten Artikel geschrieben hatte. Den ersten Absatz finde ich super, weil nüchtern und trocken, den zweiten würde ich persönlich lieber weglassen - habe aber natürlich nix dagegen, wenn andere ihn verwenden, nur würde ich selbst so niemals formulieren, das ist nicht meine Wellenlänge ;-)
Noch zwei weitere Erfahrungen mit Deinen scripts, falls es Dich interessiert:
Seitdem ich damit arbeite, bin ich von Firefox zu IE gewechselt, denn im IE wird mir die verbesserte Werkzeugleiste immer angezeigt, während ich sie in Firefox nach jedem neuen Seitenaufruf aufs Neue erst wieder mit STRG + R aktivieren muss, was leider lästig ist (und mich nach mehr als einem Jahrzehnt IE-Abstinenz dorthin zurückgetrieben hat)
SLA mach ich lieber händisch, da formuliere ich gerne Wort für Wort
Wenn es dir um die Formulierung des Hinweises geht, suchst du die Diskussion zu Vorlage:LD-Hinweis etc. Falls du den Hinweis in Einzelfällen nicht setzen willst, musst du nur jeweils das Kontrollkästchen "Autor informieren" abwählen.
Beim SLA gibt es am Ende der Liste den Punkt "Sonstiger Grund", wenn du den auswählst, kannst du deine eigene Begründung formulieren.
Hallo Schnark, habe gerade festgestellt, daß eines deiner von mir verwendeten Scripte (Autoanträge?) bei Diffs neuerdings einen Link „verbessertes Rückgängig“ produziert. Ich habe es gleich ausprobiert, dabei aber zwei Fehler gefunden. Nach Klick auf „verbessertes Rückgängig“ geht ein pop-up auf, in einem Fall hatte ich mich dann für den Vandalismushinweis entschieden, in zwei anderen Fällen für „sonstiges“. In beiden Fällen bin ich nach dem Klick auf ok auf Undefined gelandet und der Revert wurde jeweils auch nicht gesichtet. Kannst du bitte mal nachsehen, was da schiefläuft? Gruß --Schniggendiller Diskussion 15:53, 7. Sep. 2011 (CEST)
Ich bin schon einmal begeistert, dass die Bearbeiten-Logik funktioniert. Wie du danach zu Undefined kommst, verstehe ich zumindest, wie ich das am besten beheben kann, weiß ich noch nicht. Eine Möglichkeit wäre, dass du dich zusätzlich dazu entscheidest, den Benutzer anzuquatschen, indem du das Kontrollkästchen aktivierst und seinen Namen einträgst.
Warum die Reverts nicht automatisch gesichtet wurden, kann ich nicht sagen, ich hatte zwar eine Vermutung, aber die konnte ich mir gerade widerlegen (es ist verdammt schwer um diese Zeit eine ungesichtete Änderung zu finden, die man rückgängig machen kann, wir brauchen entweder weniger Leute in der Eingangskontrolle oder mehr vandalierende IPs). Da muss ich mir also erst die Dokumentation (haha) bzw. vermutlich eher den Quelltext der gesichteten Versionen durchlesen.
In der Zwischenzeit kannst du mir ja mal eine Handvoll Standardbegründungen fürs Revertieren liefern, die vier, die ich genommen habe, sollten erst einmal nur ein Platzhalter sein, ich habe keine Ahnung, was man alles brauchen könnte.
Die Platzierung der Links ist übrigens auch etwas, an das du dich noch nicht allzu sehr gewöhnen solltest, bzw. etwas, bei dem du mir gerne Vorschläge machen kannst, wo sie besser geeignet wären. --Schnark09:40, 8. Sep. 2011 (CEST)
Das erste Problem hätte ich nicht einmal bemerkt, wenn ich das Skript in meiner privaten MediaWiki-Installation so gründlich getestet hätte, wie man Skripts eigentlich testen sollte, da es nur mit der MediaWiki-Version 1.17 auftritt. Jetzt sollte es aber behoben sein.
Das andere Problem war etwas komplizierter, sodass ich schließlich eine völlig neue Bearbeiten-Funktion programmieren bei Ireas abschreiben musste. Sie ist gefühlt 100 Mal langsamer, sollte dafür aber genau das sichten, was gesichtet werden soll. Getestet habe ich das natürlich nicht, so verrückt auch noch die gesichteten Versionen installiert zu haben bin ich dann doch nicht.
Falls nach dem Leeren des Caches weitere oder neue Probleme auftreten, beschwerst du dich bitte wie üblich sofort. --Schnark09:38, 9. Sep. 2011 (CEST)
Hallo Schnark, ich hatte leider völlig vergessen, hier durchzumelden, daß sich das Problem bzgl. Undefined und nicht-sichten des revertierten Artikels gelöst hat (= deine Reparatur erfolgreich war). Bitte entschuldige meine sehr späte Reaktion. Gruß --Schniggendiller Diskussion 02:51, 16. Okt. 2011 (CEST)
Da ich ja einerseits (auf Grund meiner Genialität ;-)) wusste, dass meine Änderung den Fehler behoben hat, und ich andererseits annehme, dass du dich schon melden wirst, wenn ein Bug unerwartet länger bestehen bleibt, ging ich schon die ganze Zeit davon aus. Außerdem besitze ich sowieso eine ziemlich ausgereifte Spionage-Ausrüstung, um Benutzern meiner Skripte auf Schritt und Tritt über die Schultern zu schauen, was sie so mit meinen Skripten treiben, da hatte ich auch genug Bestätigungen, dass alles wieder funktioniert. --Schnark10:36, 17. Okt. 2011 (CEST)
Ich finde dein Script nützlich zum Revertieren des/der letzten Edits. Bei Spezial:Beiträge/… finde ich es aber überflüssig. IMHO reicht es, wenn verbessertes Rückgängig in Diffs mit aktueller Version und in der Versionsgeschichte zuoberst sowie ggf. bei Spezial:Letzte Änderungen angezeigt wird. Oder übersehe ich da etwas? --Leyo20:34, 18. Okt. 2011 (CEST)
Da ich weder RCler bin, noch mein Skript selbst verwende, weiß ich natürlich nie, was eigentlich gebraucht wird, und was nicht. Wenn es niemanden gibt, der in Spezial:Beiträge ein Rückgängig braucht, kann ich das natürlich wieder rauswerfen, wenn es nur wenige sinnvoll finden, für diese ein Opt-In einrichten, ansonsten ein Opt-out. Gleiches gilt natürlich für alle anderen Möglichkeiten des Skripts auch.
Bei den Letzten Änderungen gibt es das riesige Problem, dass die Seite je nach Einstellung „Erweiterte Darstellung der „Letzten Änderungen““ vollkommen anders aufgebaut ist, was mich beim ersten Versuch soweit in Verzweiflung getrieben hat, dass ich es zunächst bei einem TODO-Kommentar im Quelltext belassen habe. --Schnark09:18, 19. Okt. 2011 (CEST)
Das Script funktioniert ja nur dort, wo auch Rollback funktioniert. In Versionsgeschichten also nur bei der/n letzten Änderung(en) eines Benutzers. Ist wiederherstellen auch von deinem Script? Wenn ich richtig verstehe, sollte diese Option gerade bei den anderen Edits angezeigt werden als verbessertes Rückgängig. Ein RCler bin ich auch nicht. Allein durch meine Beo und Nachsichtungslisten sehe ich genug Vandalismus. :-( --Leyo10:36, 19. Okt. 2011 (CEST)
Mit Rollback hat mein Skript nichts zu tun, die Links sind im Wesentlichen das normale Rückgängigmachen (das, wenn mich nicht alles täuscht, im Moment Entfernen heißt), und das Bearbeiten einer alten Version (wiederherstellen, entspricht Revert mit Begründung). Ohne es jetzt zu testen vermute ich, dass das Wiederherstellen in vollkommen sinnloser Weise auch bei der neuesten Version angeboten wird, aber bei allen anderen Einträgen in der Versionsgeschichte sind prinzipiell beide Links sinnvoll: Man kann auf die alte Version zurücksetzen (wenn alles andere danach Vandalismus etc. war), oder eine Änderung rückgängig machen (wenn nur diese Änderung schlecht war).
Sobald sich mein Skript etwas stabilisiert hat (irgendwann in nächster Zeit ist noch mit einer einfachen Möglichkeit für Fach-QS zu rechnen), werde ich mir die Mühe machen, alle Möglichkeiten ordentlich zu dokumentieren, bis dahin hilft nur ausprobieren, solange im Tooltip irgendwas von "Dialog" steht, kannst du ja gefahrlos einmal daraufklicken (andererseits hilft das auch nicht wirklich etwas, da du ja immer noch nicht siehst, was passieren wird). --Schnark10:54, 19. Okt. 2011 (CEST)
Hallo! Seit heute Vormittag platzieren verschiedene Benutzer deines Autoanträge-Skripts unbeabsichtigt den Inhalt {{ers:undefined}} auf der Seite Benutzer Diskussion:Undefined. Bei mir selbst trat das Problem auf, als ich über „verbessertes Rückgängig“ mit einem eigenen Grund revertiert habe, obwohl die Option „Benutzer verwarnen“ gar nicht aktiviert war – offenbar liegt ein Fehler im Skript vor. Viele Grüße --Iste (☎ • ±)17:57, 8. Okt. 2011 (CEST)
Du hast auch den Cache geleert? Was zeigt denn ein javascript:alert(schnark_dialog.version) in die Adresszeile eingegeben an? --Schnark10:32, 10. Okt. 2011 (CEST)
Mittlerweile funktioniert es wohl, jedenfalls bin ich nicht mehr auf BD:Undefined gelandet. Den Cache von meiner common.js hatte ich nach deinem Hinweis hier geleert – und seitdem keinen Fehler mehr gehabt. Meintest du überhaupt meine .js? Für mich als Laien ist es sehr rätselhaft, warum das das Problem gelöst hat, schließlich steht da doch auch bloß drin, daß er sich Code aus deinen js-Seiten holen soll. Oder macht ein Browser das nur einmal pro Sitzung? Gruß --Schniggendiller Diskussion 02:58, 16. Okt. 2011 (CEST)
Die Zeile importScript('Benutzer:Schnark/js/dialog.js'); führt dazu, dass dein Browser das Skript von //de.wikipedia.org/w/index.php?title=Benutzer:Schnark/js/dialog.js&action=raw&ctype=text/javascript lädt. Damit er das nicht bei jedem Seitenaufruf von neuem tun muss, speichert er es eine Weile im Cache auf deiner Festplatte, und wenn er es wieder laden soll, dann holt er es nicht vom Server, sondern eben von der Festplatte. Dabei bekommt dein Browser aber natürlich nicht mit, wenn das Skript sich hier geändert hat, deswegen musstest du den Cache leeren, damit er alle zwischengespeicherten Dateien (und damit insbesondere dieses Skript) neu vom Server angefordert hat. Früher bestand das gleiche Problem auch mit der eigenen common.js, sodass man auch immer seinen Cache leeren musste, wenn man daran etwas geändert hat. Das ist schon längere Zeit nicht mehr so, da inzwischen die URL, mit der deine common.js geladen wird, sich ändert, wenn du etwas an deiner common.js änderst. Dadurch findet dein Browser nach einer Änderung die Datei nicht mehr im Cache und lädt sie automatisch neu vom Server. Etwas Ähnliches für andere JavaScript-Dateien bietet meine jsmodules.js. --Schnark10:46, 17. Okt. 2011 (CEST)
Dateinamen mit problematischen Zeichenkodierungen
Hallo Schnark. PerfektesChaos hat vorgeschlagen, dass ich dich betreffend Suche nach Dateinamen mit problematischen Zeichenkodierungen frage. Es wäre schön, auch für Commons eine solche Liste zu haben. --Leyo14:41, 13. Okt. 2011 (CEST)
Wenn man Commons auswählen könnte, wäre ja nichts mehr zu tun. Ich habe ein bisschen damit rumgespielt, der Quelltext ist ja verlinkt; um an die richtige Datenbank (commonswiki_p) zu kommen, müsste man als Sprache commons wählen (geht nicht über die Auswahlliste, aber über die URL) und als Wiki entweder wiki oder wikipedia. Damit würden zwar die Links nicht stimmen, aber so weit kommt es gar nicht, weil das Skript dann den richtigen Server nicht findet, dafür müsste man als Sprache Englisch und als Wiki commons angeben. --Schnark11:26, 14. Okt. 2011 (CEST)
Ups, ich habe deine Aussage wohl nicht ganz richtig verstanden. Ich habe Nikola auf seiner Diskussionsseite um Aufnahme von Commons gebeten. --Leyo13:40, 14. Okt. 2011 (CEST) PS. Bei deinem Hinweis im gelben Kasten oben wäre es vielleicht sinnvoll, dass auch bei einem Klick auf den Pfeil der Text ausgeklappt wird.
Nein, das Skript ist (im Moment) nur für die allgemeine QS gedacht. Fach-QS steht auf meiner Todo-Liste, aber automatisch wird da nichts gehen, woher soll ein Skript denn auch wissen, welchem Portal ein Artikel zuzuordnen ist. --Schnark09:11, 17. Okt. 2011 (CEST)
Dann kann das Skript immer noch nicht wissen, dass ein niederländischer Schauspieler mit {{QS-FF}}, aber nicht {{QS-NL}} versehen werden sollte. --Schnark09:25, 18. Okt. 2011 (CEST)
Bei den ersten Verwendungen solltest du übrigens immer nochmal nachkontrollieren, ob alles stimmt, ich habe zwar stichprobenartig überprüft, ob der QS-Baustein jeweils einfach so oben in den Artikel gesetzt werden und auf der entsprechenden QS-Seite unten ein neuer Abschnitt angefügt werden kann, aber ob das auf alle Portale zutrifft, weiß ich nicht. Eine kleine Ausnahme sind etwa die Biologen, wo eigentlich nur fachübergreifende Artikel unten eingetragen werden sollten.
eine Knacknuss, die dir als Erfahrenem im Umgang mit Gigabytes und 300.000-fach eingebundenen Vorlagen Spaß machen könnte: BD:Asdert #Sortierschlüssel (2)
Guten Morgen, in personendaten.js benutzt du ein simuliertes Edit-Formular, das sich mit dem Bezeichner commitForm durch verschiedenste Skripte anderer Benutzer zieht. (Um ein solches geht es, nicht um PD) Auf irgendeiner Disku hier hattest du schon einmal kurz angeschnitten, warum du das editform und nicht den API-edit benutzt. Könntest du bitte deine Gründe benennen? Ich brüte zurzeit über stillschweigenden BK mit unbemerktem Datenverlust sowie fehlender Rückmeldung an den Anwender, in welchem Moment der Artikel auf dem Server geändert worden ist.
Würde ich die API nutzen, dann würde ohne weitere Interventionsmöglichkeit des Benutzers gespeichert. Indem ich ein Edit-Formular und einen Klick auf "Änderungen zeigen" simuliere, zwinge ich einerseits den Benutzer dazu, sich einen Diff anzuschauen, und gebe ihm andererseits noch die Gelegenheit, weitere Dinge am Wikitext zu ändern. Ursprünglich stammt der Code aus HotCat. So wie ich das mit den Zeitstempeln mache, ist das etwas gefährlich, da der eine aus der Uhrzeit auf dem Clientrechner gebildet wird, was mit der Zeit auf dem Server nicht unbedingt etwas zu tun haben muss. Dieser Zeitstempel wird aber, wenn ich alles richtig verstehe, nur benutzt, um festzustellen, ob der Artikel in der Zwischenzeit gelöscht wurde, was mir bei PD (und auch in HotCat) egal sein kann. --Schnark10:20, 27. Okt. 2011 (CEST)
Vielen Dank, das hat mir weitergeholfen.
Überzeugend sind der Zwang zur Diffpage nach der immer leicht riskanten automatischen Interpretation menschlicher Texte sowie die Möglichkeit, ohne Belastung der VG weitere Textänderungen vorzunehmen.
Die Jonglage mit den Zeitstempeln war mir auch schon aufgefallen; richtig ist, dass bei der PD in der Zwischenzeit der Artikel wohl kaum bearbeitet, erst recht nicht gelöscht worden wäre.
Der Zeitstempel hat auch den Zweck festzustellen, ob der Wikitext zwischenzeitlich verändert wurde. Eine Löschung ließe sich per API auch durch nocreate abfangen. – Leider hat man es vor knapp zehn Jahren versäumt, beim Speichern (interaktiv/API) auf die lastrevid abzuheben; dies wäre ein von Format und Zeitzonen unabhängiger Weg zur Detektion von BK gewesen.
Es sind zwei Zeitstempel: wpStarttime (bei mir gerade 20111027085432) und wpEdittime (20111027085235) Letzterer ist die Zeit der letzten Bearbeitung und wird für Bearbeitungskonflikterkennung verwendet, ersterer der Zeitpunkt, zu dem man mit dem Bearbeiten begonnen hat, dieser wird verwendet, um zu testen, ob der Artikel in der Zwischenzeit gelöscht wurde. Warum das zwei Zeitstempel sein müssen, weiß ich nicht, aber so genau will das keiner wissen, wie der warnende Kommentar in EditPage.php zeigt. Und beim Bearbeiten von PD hatte ich schon mehr BKs als man glauben sollte. --Schnark11:00, 27. Okt. 2011 (CEST)
Dem Gesundheitsminister ist nicht zu widersprechen.
Ich meinte den zweiten; die zwischenzeitliche Löschung ist ein eher exotischer Zufall.
Das Gefummel mit Zeitstempeln hatten im Wortsinn liebevolle Amateure in den frühen 2000ern verbrochen; wenn man schon eine kürzere Versions-ID hat, braucht man nur die revid zu vergleichen (0 oder -1 wenn gelöscht) und fertig. Die Idee war gewesen, eine detaillierte Meldung auszugeben: „Deine Bearbeitung, begonnen um soundsoviel Uhr, kollidiert mit der letzten DB-Version von soundsoviel Uhr“ – ich erinnere mich dunkel aus meiner IP-Zeit, dass ich sowas mal gesehen hatte.
Wenn man sich per API den Quelltext holt, kann man sich den Revisiontimestamp gleichzeitig holen und dann an die Edit-API zurück geben, dann passt es immer sekundengenau und die Bearbeitungskonflikterkennung funktioniert. Beim GUI-Formular passiert das ja voll automatisch.
Die Versions-Id gibt es noch nicht so lange, und früher wurde daher alles mit Timestamps gemacht. Auch heutige trifft man an einigen Stellen noch dadrauf. Der Umherirrende18:00, 27. Okt. 2011 (CEST)
Das Problem ist eher der andere Zeitstempel, der laut API-Dokumentation ja der Zeitpunkt sein sollte, zu dem man das Edit-Token erworben hat. Wenn man nun kein Edit-Token erwirbt, weil man entweder gar nicht speichern will oder weil man es per mw.user.tokens.get( 'editToken' ) ausliest, dann fehlt einem dieser Zeitstempel. --Schnark09:05, 28. Okt. 2011 (CEST)
Stimmt, wenn man den Token über die API holt, bekommt man den Timestamp direkt mitgeliefert, bei der GUI hat man ihn nicht. Ich brauche ihn nicht, aber da kann man sicher ein Bug aufmachen und dann darauf hinweisen. Vielleicht gibt es dann ein tokens.get( 'starttimestamp' ) oder so. Der Umherirrende10:30, 28. Okt. 2011 (CEST)
Klingt sinnvoll: bugzilla:32017. In den meisten Anwendungen (von SLA-Skripten mal abgesehen) wird es letztendlich egal sein, da es auch nicht so häufig vorkommen sollte, dass die Seite während der Bearbeitung gelöscht wird. --Schnark10:48, 28. Okt. 2011 (CEST)
Ceterum censeo: Das Gepfriemel mit den timestamps zur Konflikterkennung sollte abgeschafft werden.
In den ersten Jahren, als noch niemand ahnen konnte was aus dem wiki-Kind für ein Monster werden würde, war das ein verständlicher Hack (Revisions-Identifkation aus Artikel-ID+Timestamp).
Mit Einführung der revid gehört das sowohl interaktiv wie per API umgestellt, wobei letztere für eine unendliche Übergangsperiode beide Methoden unterstützen müsste:
Die revid, auf der ein interaktiver oder automatisierter Edit basiert, ist bei der Speicherung mitzuliefern.
Beim neu erstellten Artikel mag das 0 oder -1 sein.
Wenn die revid auf dem Server nicht mit der revid des Speicherwunsches zusammenpasst, liegt der Konfliktfall vor.
Die Timestamp-Methode unterstellt, dass es niemandem gelingt, in weiter Entfernung binnen einer Sekunde manuell eine Bearbeitung auszuführen. Für einen Bot in Server-Nähe muss das aber nicht gelten; hier sind 1000 ms eine Ewigkeit.
Wenn man einen eineindeutigen Primary Key zur Verfügung hat, nutzt man diesen und keine Oberschüler-Basteleien.
Wer sich auf Bugzilla damit beliebt machen möchte, hat meine Anerkennung; ich teile vorwegnehmend Zweifel, ob unser Dino sich bewegt. Liebe Grüße --PerfektesChaos12:33, 28. Okt. 2011 (CEST)
Ich hatte die protokoll-relativen Ankündigungen unserer Großen Weisheit so verstanden, dass dies für alle wikimedia.org gelten würde, und WSTM zur routinemäßigen Entprotokollierung angewiesen. Ohne daraufhin die Links probehalber anzuklicken, geschah dies; du machtest auf die Ausnahme bei noc.wikimedia.org aufmerksam. Gibt es irgendeine allgemeingültige Regel? Ich beginne gerade dahingehend zurückzurudern, dass das nur bei den klassischen Schwesterprojekten gelten soll, sowie upload; außerdem wohl meta? Grollend und hilfeflehend --PerfektesChaos12:43, 28. Okt. 2011 (CEST)
Danke; werde mich dort einlesen, native-https-support-enabled-for-all-wikimedia-foundation-wikis meint offensichtlich nur „wikis“ und nicht beliebige subdomains.
Das verschwundene „w“ geht in der identischen Programmeinheit verloren; es ist ein vorgestern eingebauter Mechanismus, der unnötiges /index.php? mit title= als einzigem Parameter von der URL in ein simples Wikilink überführen soll, /w/index.php?title= → /wiki/ – das .org/wikipedia/de ist von dieser w-Erkennung nicht wiederhergestellt worden. Sollte heute Abend behoben sein; danke für die Info.
Das Einzige dort sind ein halbes Dutzend pauschale Aussagen, dass https nun bei allen URL möglich wäre.
Der Bearbeiter von meta:Interwiki map hat hoffentlich gewusst, was er tut. Ein grep auf " //" liefert Plausibles, was ich nicht in jedem Einzelfall nachklickte, jedoch inzwischen als Konfigurationsvariable zur expliziten Begrenzung eingebaut habe.
Danke schön; mit der momentan eingeführten Positivliste liege ich da ganz passend.
Was der weltweiten Wiki fehlt, ist eine übersichtliche Seite, auf der die SecureServer-Geschichte präzise aufgelistet wird, und nicht ein Blog mit pauschalem Geschwurbel.
Mit Apachisch hantierte ich schon, als die noch NCSA httpd hießen.
Da steht aber unter anderem blog auf der schwarzen Liste, was ja offensichtlich nicht mehr der Fall ist. Falls ich mal Zeit dazu finde, werde ich wohl einen Bug aufmachen, mit der Bitte, das mal ordentlich zu dokumentieren. --Schnark09:10, 31. Okt. 2011 (CET)
Man kann das Blog zwar über https aufrufen, es lädt aber die Bilder nicht darüber. Keine Ahnung, ob das ein upstream-Problem ist oder nur ein Konfig-Problem. Eine (automatische) Dokumentation unterhalb von noc.wikimedia.org wäre nicht schlecht, wikitech:SSL scheint etwas veraltet zu sein. Der Umherirrende18:25, 31. Okt. 2011 (CET)
Mit quasi-Freifahrtschein zum Bug erstellen: Sofern möglich, sollen alle Services über https aufrufbar sein. Also weg mit der Blacklist … Der Umherirrende19:43, 31. Okt. 2011 (CET)
Es kann gute technische (etwa download/dumps) und manchmal organisatorische Gründe geben, https bei einigen sites nicht zuzulassen.
Das hindert aber nicht, dies möglichst übersichtlich auf einer manpage auffindbar zusammenzustellen – und dort auch ein Änderungsprotokoll anzuhängen, damit jeweils nachvollziehbar ist, welche Informationen sich im letzten Vierteljahr geändert haben.
bugzilla und ticket sind über http aufrufbar, aber eine Angabe protokoll-relativ oder mit http ist unwillkommen und diese beiden wären gesondert auszuweisen.
Für alles andere gilt, dass der Regelfall protokoll-relativ sein sollte. Das hilft auch der Systembetreuung: Je mehr Ausnahmen es gibt, man sich merken muss, desto häufiger sind Fehler, bug reports; desto größer der Aufwand.
Die großen Systembetreuer haben ja dazu eingeladen, bugs zu melden – wer’s mag …
meta:Interwiki map listet für SVN: http auf. (ABC-Folge Sv, Sw verwackelt; offenbar manuell)
Dieser Tage geht auch nur http://svn.mediawiki.org. Soweit okay.
Unter https://www.mediawiki.org (!) gibt es auf gecacheten Seiten (noch kein purge) übriggebliebene protokoll-relative Auflösung von SVN: – wie es vor einer Weile möglich war.
Kraft meines Nicks verleihe ich dieser Aktion den Ehrentitel „PerfektesChaos“.
Für alle Seiten, die wie bugzilla mit Code operieren, wäre https angezeigt, auch wenn man sich nicht einloggen kann; der böse Mann in der Mitte könnte Schadcode hineinschreiben …
Hi Schnark, ich benutz Teile Deiner common.js. Ich nehm einmal an, es ist nicht ihre Hauptaufgabe, Typo-Fehler zu tilgen, aber einiges erledigt sie automatisch ja sehr schön. Vorhin konnte sie allerdings bei dieser zerschossenen Infobox keine Lösung anbieten und ich hab den Fehler auch nicht gefunden. Benutzer:Rosentod war gründlicher und fand den Fehler ... Ich wollte Dich hiermit nur drauf hinweisen, vielleicht ist es für Dich einfach, solche Fälle auch noch in den „Typokorrektor“ einzubauen. Gruß F.18:01, 7. Nov. 2011 (CET)
Ich hatte bereits schmunzelnd mitgelesen, wollte aber ausnahmsweise mal nicht zu vorlaut auf andrer Leut Benutzerdisku sein.
Tatsächlich hatte mein Skript still leidend die unausgewogene Anzahl der eckigen Klammern bemerkt, sich jedoch nicht getraut, die fehlende vierte automatisch hinzuzufügen. Das macht es nur, wenn die Situation eindeutig ist; bei einem betitelten kaputten Wikilink dagegen soll es die fehlende Klammer ergänzen, weil es dann in der richtigen Reihenfolge zwei öffnende, eine Pipe und eine schließende sieht. Genauso werden bei Weblinks mit zu vielen Klammern die überzähligen automatisch entfernt, da anhand des URL-Beginns die beabsichtigte Syntax zweifelsfrei erkannt wird.
Für 2012 plane ich einen Fehlermeldungs-Mechanismus, der bei schwerwiegenden und nicht automatisch reparierbaren Syntaxfehlern die Benutzer informiert.
Tipp: Mit WikEd lässt sich die Syntax bei der Bearbeitung hervorheben und das defekte Link (bzw. in diesem Fall: Nicht-Wikilink) fällt optisch auf.
Danke. Die von Schnark herüberkopierten Skripte funktionieren bei mir nur mit IE, WikiEd funzt laut Einleitung gerade nicht mit IE. Ich versteh nix davon. Aber solange es Rosentode gibt, geht es sich ja letzten Endes aus, auch ohne Skript-Unterstützung. ;-) Gruß F.00:38, 9. Nov. 2011 (CET)
Ich warte geduldig zwischen Nikolaus und Weihnachtsbaum, und dann gucken wir still und stumm auf dem leeren Gabentisch herum.
Am Anfang des bugzilla thread bin ich erstmal mit der Jahreszahl entgleist. Daran werde ich mich wohl gewöhnen müssen. Nö, danke, mir muss dazu nichts mehr einfallen. sufficient feedback ist etwas anderes. Lassen wir das mal ruhig ungelöst weiter köcheln. So kommen die Verwalter immer mal wieder dran vorbei, wie man jetzt gesehen hat.
Ich habe auch eine gewisse Zeit gebraucht, bis ich den Grund gefunden hatte (noch verstärkt durch den Winterschlaf der Hamster). Es ist schon erstaunlich, was so ein einzelner Strich für interessante Effekte haben kann. --Schnark10:21, 11. Nov. 2011 (CET)
Nach einigem Rumprobieren und dem Versuch den Parser-Code zu verstehen, habe ich beschlossen, dass das ein Bug in MediaWiki ist, und als solchen bugzilla:32373 gemeldet. --Schnark09:32, 12. Nov. 2011 (CET)
Naja, bei fehlerhaftem Wikitext ist die Frage, was gewollt ist und was nicht, nicht so ganz klar. Der Parser könnte durchaus die Tabelle schon früher schließen, wenn er feststellt, dass keinerlei Tabellensyntax mehr folgt. Sollen sich die Parser-Kundigen damit rumschlagen, es ändern oder als WONTFIX schließen, oder es ignorieren oder sonst was damit tun. --Schnark11:36, 12. Nov. 2011 (CET)
Das ist klar. Akutuell schließt der Parser am Ende der Seite alle offenen Tabellen. Das ist eine defensive Methode und auch wohl die beste, weil du nie weißt, was die Benutzer in ihre Tabellen packen. Tabellen werden auch häufig zu Layoutzwecken missbraucht, dann kommt lange Zeit auch keine Tabellensyntax. Aber lassen wir mal die Entwickler drüber schauen. Ich wollte auch nur klarstellen, das htmlTidy der Grund ist, warum das ganze im HTML-Quelltext nicht mehr an der richtigen Stelle steht. Aber da der Browser es genauso darstellt, ist es kein Problem mit htmlTidy. Der Umherirrende11:42, 12. Nov. 2011 (CET)
vector.js
Hallo Schnark,
nachdem es ca. ein halbes Jahr lang problemlos lief, sind die Extra-Buttons jetzt alle nicht mehr sichtbar.
Ich hatte mir Dein Skript leicht modifiziert, siehe hier:
http://de.wikipedia.org/wiki/Benutzer:LS/vector.js
Könntest Du es mir evt. updaten, so dass es wieder läuft (mit Firefox 8.0)? Vielen Dank im voraus. Grüße--LS13:07, 17. Nov. 2011 (CET)
Ich frage mich jetzt natürlich, wie ein so dummer Fehler meinerseits so lange unentdeckt bleiben konnte, jedenfalls ist er jetzt behoben. Du musst noch deinen Browsercache leeren, dann sollte es wieder funktionieren. --Schnark09:15, 18. Nov. 2011 (CET)
Meiner Ansicht nach ist das Skript ohnehin schon viel zu überladen mit Funktionen, dass ich nicht noch irgendwas hinzufügen will. --Schnark09:11, 21. Nov. 2011 (CET)
Archiv Problem in Arbeit
Hallo Schnark! Ich denke mir so, Du beobachtest meine Diskussion nicht mehr. Deshalb hier zur Info: xqt wird den pywikibot so erweitern, dass Archive ausgeschlossen werden. Danke nochmal fuer Deinen Hinweis! GLG --Hedwig in Washington(Disk?)•B20:48, 24. Nov. 2011 (CET)
Hallo,
auch wenn ich deine Antwort oben gesehen habe, wäre es evtl. trotzdem möglich beim Revertieren den zusätzlichen Grund unbelegte Änderung mit dem Hinweis in der Zusammenfassungszeile "Revert: Bitte die Änderungen Belegen, siehe WP:Q" oder so ähnlich zu ergänzen. Ich arbeite sehr gerne mit der Erweiterung aber für die Nachsichtung wäre diese Ergänzung noch sehr nützlich und ich denke, es sollte den Umfang nicht allzusehr erhöhen. Danke. Gruß. --Tavok08:58, 9. Dez. 2011 (CET)
Prinzipiell ist das bereits möglich, du solltest eigentlich auch beim Betrachten eines Versionsunterschieds die Option "Verbessertes Rückgängig" haben, das dir mit dem Punkt "Quelle" die Zusammenfassung "Bitte inhaltliche Änderungen mit Fundstellen/Belegen/Quellen begründen (siehe auch WP:BLG) und künftig den Hinweis „Zusammenfassung und Quellen“ nutzen." liefern sollte. Aus irgendeinem Grund funktioniert das bei mir aber nicht zusammen mit meiner diff.js, die du auch verwendest. Sobald ich dazu komme, schaue ich mal, was da schiefläuft. --Schnark09:20, 9. Dez. 2011 (CET)
Habe die diff rausgenommen und es lief. Diff wieder rein und es läuft immer noch. Oh Wunder der Technik! Vielen Dank. Gruß. --Tavok10:01, 9. Dez. 2011 (CET)
Es hatte höchstwahrscheinlich mit der Reihenfolge zu tun, in der der Browser die beiden Skripte lädt und ausführt. Inzwischen ist der Fehler aber auch behoben, sodass es in Zukunft auch ohne Glück funktionieren sollte. --Schnark10:16, 9. Dez. 2011 (CET)
autoanträge.js
Dritte Frage ;-) Hab ich bei mir eingebunden, die Buttons erscheinen, aber es tut sich nichts wenn man draufklickt. Was stimmt da nicht?--Antemister18:49, 9. Dez. 2011 (CET)
Ich habe jetzt gerade keine Zeit, aber da du ja meine .js-Dateien bearbeiten darfst (und auch schon bearbeitet hast), tausch doch einfach selber aus, irgendwelche Besonderheiten gibt es nicht, die du dabei beachten müsstest. --Schnark09:48, 12. Dez. 2011 (CET)
Deine js-Dateien sind etwas unübersichtlich, sodass ich den Fehler dort vermute, räume da mal so weit auf, dass du nur die Skripte einbindest, die du auch verwendest, und diese maximal einmal. Beispielsweise bindest du Benutzer:Schnark/js/personendaten.js/test.js doppelt ein, es würde mich aber sehr wundern, wenn du es verwendest (und soweit ich es erkennen kann, kann es so, wie du es einbindest gar nicht funktionieren). Bei mir und auch bei vielen anderen funktioniert das Skript. Eventuell hilft auch ein Blick in die Fehlerkonsole des Browsers. --Schnark10:26, 15. Dez. 2011 (CET)
Inzwischen habe ich eine Vermutung, woran es liegt. Das bedeutet aber umso mehr, dass du dir überlegen solltest, ob du das Skript wirklich einbinden willst, denn offenbar benötigst du es für das, was du dich in Wikipedia interessierst, nicht. Wie dem auch sei, mit der nächsten Version wird es dann wohl auch bei dir funktionieren. --Schnark09:09, 16. Dez. 2011 (CET)
Ich schrieb ja: mit der nächsten Version. Wenn du das Skript so einbinden würdest, wie in der Dokumentation beschrieben, hätte ich dich sogar auf diese neue Version hingewiesen. --Schnark11:36, 20. Dez. 2011 (CET)
Ich glaube, dass ich immer noch durchkomme, aber mehr dazu morgen, heute habe ich keine Zeit mehr. --Schnark09:52, 19. Dez. 2011 (CET)
Klingt ja spannend – und seltsam: Ich freue mich schon drauf. Ist ja wie Weihnachten.
Ob der dräuenden Gefahr habe ich vorbeugend nachgearbeitet. Gleichwohl wäre ein Lückenschluss im Status quo ante willkommen, um free() als robuste Bibliotheksfunktion für vergleichbare Fälle oder Minimierer vorrätig zu haben.
Nach dieser Änderung muss ich mich vermutlich geschlagen geben, davor wäre ich wohl noch mit Nicht-Standard-Zeugs im IE durchgekommen, da – in der Annahme, dass die @cc_on-Stelle in en:MediaWiki:Gadget-JSL.js etwas sinnvolles tut – man auch Code in Kommentaren einschmuggeln kann.
Wenn ich unterm Baum aber dann die Lust verspüre, doch noch ein wenig zu basteln, schaue ich aber mal, ob ich nicht doch noch ein Schlupfloch finde. Und wenn nicht: Es ist vermutlich sehr viel leichten einen en-Admin zu finden, der Skripte mit Sicherheitslücken benutzt, und dein Skript so durch die Seitentür anzugreifen. --Schnark10:49, 20. Dez. 2011 (CET)
@cc_on – ach du ahnst es nicht. Sowas habe ich ja noch nie gesehen. Okay, ich les auch nicht viel im MSDN, und wenn, dann nichts über Web und IE und JS.
Bei einem gehackten Admin, egal aus welchem Projekt, ist alles mit jedem Skript und jeder Systemnachricht möglich. Da aber selbst versteckte Versionen in der BEO erscheinen und alle JS von ihren Autoren beobachtet werden sollten, dürfte zumindest uns zwei beiden das recht schnell auffallen.
Du weißt, dass deine konstruktiven Bemerkungen stets willkommen sind.
Wenn ich einen Admin auf en angreife und dir so das Skript ändere, dann lasse ich ihn selbstverständlich auch Code in deine common.js einfügen, der diese Änderung überall ausblendet. Wobei ich meine Seiten auf en über das RSS-Feed beobachte, und das damit trotzdem noch mitbekommen würde. --Schnark11:10, 20. Dez. 2011 (CET)
Jetzt verstehe ich erst enWP. Nein, das ist hier nur meine Testumgebung, um unabhängig von der deWP etwas zu simulieren; die Inhalte werden jeweils direkt aus meiner lokalen Entwicklungsumgebung auf die Wikis hochgeladen. Wenn ich außer debugging-Einschüben etwas im Wiki editieren würde, wäre das nicht mehr konsistent mit meiner Festplatte. Ein enWP-Admin darf das WPST ruhig häckseln, das ist nur eine Sackgasse. Seit einigen Tagen baue ich auch in der test.WP eine entsprechende Unterseiten-Struktur auf. Wenn natürlich jemand die Produktivversionen von WSTM verändert, könnte das dauern – bis zum nächsten Update, oder weil ich sie ja auch selbst benutze und Folgen merken müsste, wenn man mich nicht ausnimmt – aber wer hätte von diesem immensen Aufwand welchen Nutzen, mit wackligen Erfolgschancen? --PerfektesChaos11:25, 20. Dez. 2011 (CET)
Es hätte schon etwas faszinierendes einen Javascript-Virus zu programmieren, der durch Admins über MediaWiki:Common.js und Benutzerskripte übertragen wird, und womöglich dank einiger Skripte, die man aus fremden Projekten einbindet sogar quer durch alle Projekte … Dazu lohnt sich aber eher WikEd oder NavigationsPopups. --Schnark11:33, 20. Dez. 2011 (CET)
__parent__ nennt man auch ein magic word, wie es auch hier gerade erschöpfend diskutiert wird.
Schön gemacht; werde auch dem noch entgegenzuwirken wissen. Beruhigend, dass ich im standardkonformen JS schon mal dicht zu sein scheine. Offenbar muss ich noch expliziter die WSTM-Syntax der beiden Anweisungen einfordern.
Gegenzug gemacht. Allmählich ist das ja nur das blanke Gerippe aus Klammer und Komma und den Strings. Dass das dermaßen ausartet, hätte ich nicht erwartet. Ich habe was gelernt. Und dazu Syntaxkonstrukte, die ich nie angefasst hätte. Dir besten Dank --PerfektesChaos20:21, 21. Dez. 2011 (CET)
Sieht fast gut aus. Du solltest dir bewusst sein, dass ich per
noch immer allen globalen Variablen in beliebig tief verschachtelten Objekten, die selbst etwas vom Typ object enthalten ein beliebiges Array aus Strings zuweisen kann. Sollte der Benutzer also ein Skript einbinden, dass der Ansicht ist, seine in globalen Variablen gespeicherten Arrays wären sicher, kann es Probleme geben.
Und du bist dir hoffentlich auch der Tatsache bewusst, dass free bei der ersten Division durchdreht, und daher nur verwendet werden kann, wenn Divisionen wie hier weder zulässig noch zu erwarten sind. --Schnark10:51, 22. Dez. 2011 (CET)
Dem werde ich nachgehen; diese __parent__-Aktion ist lästig. Da muss ich mich erstmal einlesen. Es ist doch nicht zu fassen.
Die Division dachte ich eigentlich in free() ignoriert zu haben; ein / ohne folgendes / oder * und ohne vorangehendes \ soll er skippen, genau wie ein / als Begrenzer eines RE-Literals. Muss ich also nochmal checken.
Es bedarf schon eines kompetenten advocatus diaboli, um sowas zu entwickeln. Schade, dass es wenig zuverlässige Bibliotheksfunktionen gibt; jQuery ist eine neue Erfahrung für mich. Bislang hatte ich außer für banales Klickibunti einen großen Bogen um JS-Quell-Seiten im Web gemacht.
Mit einem gewissen Zeitverzug greift aber inzwischen eine dritte Verteidigungslinie in produktiven URL, wenn du dir die Anfangskommentare mal genauer anschaust.
Die Eigenschaft __parent__ liefert einfach den umgebenden Kontext, was hier halt window ist und mir Zugriff auf alle globalen Variablen verschafft.
Wenn nach einer Division in der selben Zeile ein String beginnt, wird er das öffnende Anführungszeichen nicht für den Stringbeginn halten, sondern für Inhalt eines regulären Ausdrucks, versuche es mal mit
a=b/c;d="///";e=f;
Den Fingerprint habe ich schon gesehen, da ich mir alle Änderungen an den r.?\.js-Dateien ansehe. --Schnark11:51, 22. Dez. 2011 (CET)
Das String-Literal nach Division mit enthaltenden Schrägstrichen hatte ich dann heute vormittag auch schon auf dem Schirm; bin zurzeit bei einer inneren Schleife im String-Literal und tüftele noch an einem sicheren Weg, um zwei Divisionen von einem RE-Literal unterscheiden zu können. In einem Punkt bin ich mir sicher: Eine Analyse über RE wäre PerfektesChaos. Über Nacht mehr. Jetzt: Guten Appetit --PerfektesChaos13:19, 22. Dez. 2011 (CET)
Es ist mehr eine geistige Herausforderung und übt in JS, hier eine robuste Standard-Funktion zu finden, die Kommentare und sonst nichts strippt.
Für das Objekt-Problem sollte die neue Version hinreichen, die nur noch ein WSTM-Statement jeder Sorte akzeptiert und Kommata einfordert.
Ansonsten ist es eine beglückende Aussicht, bei langweiligen Pflichtbesuchen der Verwandtschaft glasigen Auges in die Unendlich-Ecke starren zu können, einen Spekulatius zur Schrägstrich-Form zu zerkauen und heimlich Syntaxfragen zu verdauen.
Vor einem Divisionsstrich muss ein 0-9.a-zA-Z)]_$ stehen, auch mit Leerzeichen/Zeilenumbruch voran.
Nach einem Divisionsstrich muss -0-9.a-zA-Z(_$ folgen, auch nach Leerzeichen/Zeilenumbruch.
Dann hätten wir noch /= als Zuweisung.
Vor Beginn eines RE-Literals kann nur [;,{}:=( oder nichts stehen, auch nach Leerzeichen/Zeilenumbruch. Eignet sich auch als bedröhnter Smiley.
Ich werde mal ganz vorsichtig in die Quelle des MW-Minimierers schmulen, so zur Appetitanregung und um meinen eigenen Minimierer zu tunen.
P.Copp hat da wohl einen ganz guten Minifierer geschrieben, zumindestens läuft der im Gegensatz zu JSMin/jsminplus aktuell noch. Das einzige Problem in der letzten Zeit war der Umgang mit Exponenten, da hat er den Zeilenumbruch zu früh eingebunden, soweit ich das richtig mitbekommen habe. Der Umherirrende21:24, 22. Dez. 2011 (CET)
Das interessante Beispiel für RegExp vs. Division ist übrigens bugzilla:27528#c3. ä / ö sollte eigentlich eine gültige Division sein. Der filter scheint jetzt aber sicher zu sein. Die Assoziation zu Schach hatte ich auch, nur dachte ich eher an so Schachprobleme wie Matt in 5 Zügen, bei denen man aus der unüberschaubaren Menge von Zügen, die alle nicht zu funktionieren scheinen sich den raussuchen muss, der so absurd ist, dass er funktioniert. --Schnark10:04, 23. Dez. 2011 (CET)
Sodele, die aktuelle Angelegenheit kann man dann als beendigt ansehen.
Den Kommentar-Abschneider werde ich mir als Denksport für die Feiertage vornehmen.
Einen aktuellen und von den Browsern übereinstimmend akzeptierten JS-Standard kenne ich nicht. Ich kann mich da nur an ECMA 2009 halten, und der erlaubt für Bezeichner alles, was Unicode gestattet als “Uppercase letter (Lu)”, “Lowercase letter (Ll)”, “Titlecase letter (Lt)”, “Modifier letter (Lm)”, “Other letter (Lo)”, or “Letter number (Nl)”. – Über diese Brücke werde ich nicht gehen. Im Sinne der Kompatibilität auch mit älteren Browsern nehme ich mir die künstlerische Freiheit, für Bezeichner klassisches Englisch vorzuschreiben. Das gilt auch für allerlei Varianten von Zeilenenden, und nicht-arabische echt-arabische Ziffern. Einen Konflikt melde ich kurzerhand als nicht-kompatibles JS, und fertig. Ich muss damit nicht jedes beliebige Skript weltweit unterstützen.
Eine Bibliotheksfunktion in JS, die erstmal die Kommentare entfernt, wäre in diversen Zusammenhängen vorstellbar und auch die halbe Miete auf dem Weg zu einem JS-JS-Minifier. Wenn man nicht versucht, den letzten Zeilenumbruch herauszuquetschen, ist es dann schon nicht mehr weit.
The characters in the specified categories in version 2.1 of the Unicode standard must be treated as in those categories by all conforming ECMAScript implementations; however, conforming ECMAScript implementations may allow additional legal identifier characters based on the category assignment from later versions of Unicode.[12]
Dass aller mögliche Unicode-Schrott in Variablennamen erlaubt ist (etwas, was ich nie tun würde), weiß ich auch nur, weil ich mich daran erinnere, dass mit MW1.18 eo plötzlich kein Javascript mehr ausgeliefert bekam, weil eine Variable ein š im Namen hatte. --Schnark09:25, 27. Dez. 2011 (CET)
Ein Grund mehr, zur Kompatibilität mit älteren Browsern und zur Lesbarkeit für Programmierer, die kein Thai oder Arabisch auf dem Schirm haben, ASCII-Bezeichner einzufordern. (Ich würde nur algerisch reagieren, wenn es das letzte Zeichen des Identifizierers ist). Die Zeichenketten dürfen ja inhaltlich gern sonstwas enthalten. Die Schlüsselwörter sind ohnehin Englisch; rein laotisches JS geht sowieso nicht. Angenehmen Jahresendspurt --PerfektesChaos09:59, 27. Dez. 2011 (CET)
Das zeigt wie schlecht Javascript ist, im nächsten Standard sollte man unbedingt die Syntax ergänzen: Zumindest Latein sollte doch wohl möglich sein … --Schnark10:11, 27. Dez. 2011 (CET)
Mit vsn4/2012 werde ich meine Testumgebung auf der enWP abbauen und bei allen Skripten deWP/.../x.js -> testWP/.../d.js verlagern.
Außerdem habe ich inzwischen herausgefunden, was ich alles anstellen muss, um in eine http-Wikipage JS direkt aus meiner Festplatte einzubinden. Erschwerend kam hinzu, dass bei mir sowohl unter Linux wie Windows die Browser im Prozess eines Gast-Accounts gestartet werden.
Planst du eigentlich, automatische Tests für das Skript zu schreiben? Qunit steht ja inzwischen zur Verfügung, Handgebasteltes sowieso, und mit der API deines Skripts zusammen sollte das nicht allzu schwierig sein. --Schnark09:07, 28. Dez. 2011 (CET)
Danke für den Hinweis.
Nein, QUnit verwende ich nicht; es war mir auch nicht bekannt, habe es aber gebookmarked und werde es gelegentlich genauer lesen; das simple loggen von assertions könnte interessant sein.
Ähnliche Werkzeuge hatte ich im Lauf der Zeit schon woanders genutzt.
Mein Problem sind nicht so sehr die Zeichenketten.
Wenn, dann sind es Konstellationen von richtiger oder fehlerhafter Wikisyntax, auf die ich bisher nicht gekommen bin. Hier würde mir auch QUnit nicht helfen.
Der weitaus überwiegende Aufwand für Testen und Fehlersuche geht in volatile Situationen, bei denen WikEd, Konfigurationseinstellungen, editform, mögliche Abweichungen von Browsern, Ladereihenfolge eine Rolle spielen. Hier kann mich QUnit wohl nicht weiterbringen.
Für Zeichenketten gehe ich anders vor: In Nachfolge dieser Seite habe ich seit etwa anderthalb Jahren ein ellenlanges Skript, in dem drei Zeichenketten mit Wikisyntax definiert sind und immer weiter ausgebaut werden.
Die erste ist eine fehlerhafte und auch richtige Wikisyntax, die zweite ein erwartetes Ergebnis bei Standardfunktionalität ohne benutzerdefinierte Ersetzungen, die dritte ein erwartetes Ergebnis nach einigen banalen benutzerdefinierten Ersetzungen.
Das Hauptproblem ist hier, Kombinationen und Konstellationen von Wikisyntax zu finden, die Probleme aufzeigen.
Der Rest ist klar: Nach größeren Veränderungen im Skript werden lokal die Zeichenketten-WSTM angeworfen, die aktuellen Ergebnisse werden jeweils abgeglichen.
Die Eingabe ist durch Doppel-Leerzeile in Absätze gegliederter Wikitext, zurzeit rund 100. Stimmt anschließend ein Byte nicht mit den Erwartungen überein, werden die beiden „Absätze“ gezeigt, die Positionsnummer des unterschiedlichen Byte im Absatz sowie die ersten 20 Zeichen des Ausgangstextes.
Dummer- oder besser glücklicherweise schlägt das nur sehr selten an. Erst durch Fehlfunktionen beim realen Artikel lerne ich Kombinationen kennen, die in dieser Test-Zeichenkette bislang nicht enthalten waren und natürlich angefügt werden.
Ausgelöst wurde die lokale Lösung, nachdem sich jemand darüber beschwerte, dass die Testseite Kategorien enthielt (und Category:). Das spart auch Serverversionen, Hochlade-Aktivitäten, Browsercache-Aktualisiererei und flutscht sofort nach Änderung im Zeichenkettenbereich.
Ich habe ja mit Benutzer:Schnark/js/personendaten.js/test.js etwas Ähnliches, mit der Zusatzschwierigkeit, dass ich als Eingabe ganze Artikel brauche, die ich also per AJAX holen muss. Bei mir funktioniert das inzwischen erstaunlich gut, Hauptproblem bei mir ist, dass der "Soll"-Text teilweise Fehler enthält, die ich noch gar nicht bemerkt habe. --Schnark11:12, 28. Dez. 2011 (CET)
mir ist beim Normdaten/Personendaten-Skript ein kleiner "Bug" aufgefallen. Das Skript prüft (soweit ich das verstehe) nur auf das Vorhandensein vom Sortierschlüssel SORTIERUNG, aber nicht auf das Vorhandensein von DEFAULTSORT. Deshalb wird in Artikeln in denen noch DEFAULTSORT genutzt wird, die Normdaten-Vorlage zwischen DEFAULTSORT und den Kategorien eingefügt statt darüber. Gruß, --Kam Solusar15:14, 19. Jan. 2012 (CET)
Du hast Recht. Das stammt noch aus der Zeit, zu der man das Normdatenskript nicht ohne das Personendatenskript verwenden konnte, letzteres übersetzt DEFAULTSORT ja automatisch. Sobald ich die Zeit zum korrigieren und testen finde, kümmere ich mich darum. --Schnark09:05, 20. Jan. 2012 (CET)
Die Behebung des Bugs war dann doch sehr einfach, das Testen habe ich mal großzügig ignoriert, aber es sollte jetzt so funktionieren, wie es soll. --Schnark09:07, 21. Jan. 2012 (CET)
In monobook.js hätte es auch klappen sollen, zumindest, wenn du Monobook als Skin verwendest. Wenn du dagegen Vector verwendest, entsprechend vector.js, etc. Aber mit common.js funktioniert es in jedem Skin. --Schnark11:52, 31. Jan. 2012 (CET)
ROLF (Nikolaus), Dump + mehr
Den „Nikolaus“ hatte ich damals aufgrund der vagen Angabe (Anfang Dezember) geraten; offenbar gut getroffen. Ja, mach nur einen Plan … („Heute ist“ … habe ich irgendwas Unauffindbares übersehen?)
Wenn du sowieso grad nach tumben Toren suchst: Syntaktisch missverstandene Exoten im Dutzend-Bereich, also thumb= / thumbnail= sollten bei der Gelegenheit eliminiert werden, bevor sie noch jemand abkopiert; die eckigen Klammern verschwinden ja auch zusehends aus den URL.
Ansonsten liegen in den Wartungslisten noch Tausende von Zeichenkodierungen mit Arbeit für mehr als ein Vierteljahr auf Halde. Neu-Auswertungen lohnen sich einstweilen nicht, weil das Abgleichen mit den Ausnahmelisten mehr Arbeit macht als die Aktualisierung bringt.
ad 1. Bei Wettbewerben ist es doch üblich, dass Gewinner von Hauptpreisen vor den anderen Teilnehmern informiert werden. Daher ist es nicht so verwunderlich, dass du noch von nichts weißt. --Schnark09:08, 30. Jan. 2012 (CET)
Als Zugabe gibt es noch Lötschental mit {{ImageAnnotations|thumb=show}}. Scheint irgendwas mit dem Gadget:ImageAnnotations zu tun zu haben, was hier nicht installiert ist.
Allerdings: In irgendeiner Form scheint thumb= noch immer zu funktionieren. In meiner Installation funktioniert es halbwegs, nur ersetzt das manuell gesetzte Vorschaubild das richtige Bild vollständig (ein Klick führt zum Vorschaubild, nicht zum Original). Insgesamt also mehr Bug als Feature, aber vermutlich behebbarer Bug, wenn ihn jemand meldet. (@Umherirrender: Wenn du hier mitliest und gerade nichts zu tun hast, kannst du das gerne übernehmen). --Schnark10:29, 31. Jan. 2012 (CET)
Das sollte eigentlich ein Feature sein, man kann nämlich thumb= auch eigenständig übersetzen. Es wird unter manualthumb geführt (Steht in Linker.php). Ich habe es noch nicht gebraucht und ich denke auch, das es im Artikelnamensraum nichts zu suchen hat. Wo allerdings der Klick dann hinführen sollte, weiß ich gerade auch nicht. Das kann natürlich ein Bug sein, weil so macht es gerade irgendwie wenig sinn, wenn nur der Vergrößeren-Button auf das eigentliche Bild zeigt und man das Bild nicht skaliert bekommt … Der Umherirrende21:20, 31. Jan. 2012 (CET)
Ich habe mal ein paar Sachen aufgelistet: Bug 34194 (bevor das ganze wieder in Vergessenheit gerät, schreib ich es lieber sofort auf, auf die Gefahr hin, das es dort vergessen wird, aber da kann ich dann nichts mehr für). Falls euch noch mehr auffällt, könnt ihr es gerne ergänzen. Der Umherirrende20:57, 3. Feb. 2012 (CET)
frame – Diesen weiteren undokumentierten Bildparameter hatte ich vor Monaten mal in irgendeinem Artikel gesehen; möglicherweise hatte er sogar funktioniert? Gemeint war framed gewesen; könnte öfters passieren, von wegen Englisch und L10n.
thumb= ist ja ein lustiges Feature für den internen Gebrauch, aber in der Tat nichts für den ANR. Aber wenn er sowieso nicht (mehr) funktioniert, weg damit.
frame ist ein gültiger Alias für framed, ebenso wie enframed. Lies [13] und staune.
thumb= könnte durchaus sinnvoll verwendet werden, wenn es denn funktionieren würde, nämlich um manuell optimierte Vorschaubilder zu zeigen, wenn das Standardvorschaubild nicht gut aussieht. --Schnark10:17, 3. Feb. 2012 (CET)
Ich bin nicht so der Bebilderer, aber das ginge wohl über eine px-Vorschau mit verweis= kontrollierter einzurichten. --PerfektesChaos21:43, 3. Feb. 2012 (CET)
Zur Hölle mit diesen ganzen Alias-Varianten. Das ist doch keine Syntax, das ist ein Sündenpfuhl. Okay, das wussten wir schon länger. Aber kein Artikel-, Skript- oder Parser-Autor blickt da noch durch und kann fehlersicher etwas schreiben. Für das Lehrbuch Wie sollte ich eine Syntax nicht definieren?
Habe meine L10N-RE angepasst; danke für das Link. Die Varianten upright $1 und page $1 waren mir neu; es wird hier sprachunabhängig demnächst zwangsweise ein Gleichheitszeichen geben, und seite_$1 desgleichen.
Wenn du deinen Dump gelegentlich durchguckst: Das exotische hiddentext hatte jemand mit Excel-Gadget und obendrein falschem Schrägstrich benutzt; gibt es noch eine überschaubare Anzahl von Verwendungen, die man aus dem ANR eliminieren könnte?
Per API lässt sich das auch auslesen, das einzige Problem dabei ist, das dort auch Magische Wörter auftreten, die aktuell nicht nutzbar sind (Bug 30836), aber sonst brauchbar. Der Umherirrende19:37, 3. Feb. 2012 (CET)
Danke schön; veraltete Syntax macht überhaupt nix. Es geht ja grade darum, unerwünschte (ungebräuchliche, vielleicht sogar falsche) Syntax aus den Artikeln oder sonstigen Seiten zu filtrieren und in aktuell verständliche Konstruktionen zu überführen. Diese API kannte ich noch nicht; ich werde sie durchsehen, ob da noch mehr ist, was irgendwo lauern könnte und mir bislang nicht auffiel. Es schleppen auch immer wieder Leute aus anderen WP oder von anno Tobak irgendwelche Gebilde ein. Schönen Abend --PerfektesChaos21:43, 3. Feb. 2012 (CET)
Hallo Schnark, eine Frage zu deinem Skript Benutzer:Schnark/js/artikel-statistik.js: Wie kann ich mir das Auswerten der Versionen vorstellen (dauert ja teilweise recht lange)? Werden die einzelnen Versionen von meinem Browser alle abgerufen oder läuft das auf dem Toolserver oder...? Eine kurze laienverständliche Antwort genügt ;-) --Thgoiter15:46, 8. Feb. 2012 (CET)
Es werden alle Versionen von deinem Broser abgerufen (im Idealfall jeweils 500 Stück auf einmal, können aber auch weniger sein bei viel Text), erkennbar an der Zahl hinter dem Schrägstrich (Anzahl der bisher vom Server geholten Versionen, mit einem + hintendran, wenn noch welche fehlen) und dann der Reihe nach so eine Art Versionsunterschiede gebildet, um herauszufinden, was wann eingefügt oder wiederhergestellt wurde, erkennbar an der Zahl vor dem Schrägstrich. Der Toolserver ist nicht daran beteiligt, was insbesondere heißt, dass das Skript in jedem mit Mediawiki betriebenem Wiki läuft. Vor der Art her ist es vergleichbar mit Benutzer:APPER/WikiHistory (und von der Geschwindigkeit auch). --Schnark10:18, 9. Feb. 2012 (CET)
ich habe versucht, dein Addon autoantraege zu benutzen, jedoch scheint es bei mir nicht funktionieren. Die verschiedenen Möglichkeiten sind zwar links unter Werkzeuge angezeigt, jedoch passiert nichts, wenn ich sie anklicke. Kannst du dir meine vector.js mal anschauen, vielleicht findest du ja den Fehler. Liebe Grüße -- Hepha!±ion?19:54, 7. Feb. 2012 (CET)
Da ja da was von skins.vector steht wird es schon etwas damit zu tun haben. Ich fände es wirklich schade, wenn das nicht ginge, denn neben den anderen Sachen die ich mir so in die vector.js gezogen habe ist autoantraege wirklich hilfreich. Grüße -- Hepha!±ion?10:31, 8. Feb. 2012 (CET)
@Hephaion: Die von dir genannte Fehlermeldung mag häufig sein, hat aber nichts mit dem aktuellen Problem zu tun (mit skin=vector auch nicht, auch wenn das in der URL auftaucht). Hast du noch andere; insbesondere solche, in denen das Wort "Schnark" auftaucht, und die eine rote Marke haben und nicht nur ein gelbes Dreieck? Wenn du zwischendurch nach denen guckst, findet Schnark sie hier vor, wenn er wieder online ist.
Danke für den Einwurf, aber an Fehlern (gegenüber Warnungen) gibt der Firefox nichts aus. Ich werde nachher mal versuchen, alle anderen Skripte auf meiner vector.js zu entfernen, um zu prüfen, ob autoantrege sich vlt. mit einem anderen ins Gehege kommt. Grüße -- Hepha!±ion?11:40, 8. Feb. 2012 (CET)
Also alles funktioniert wunderbar, wenn ich mal allen überflüssigen Kram aus vector.js rausschmeiße. Ich werde jetzt nach und nach wiederherstellen und dir dann mal sagen, mit welchem addon es sich nicht verträgt. Grüße --Hepha!±ion?15:30, 8. Feb. 2012 (CET)
Also, relativ schnell wurde klar, dass sie die autoantraege nicht mit Benutzer:PerfektesChaos/js/WikisyntaxTextMod vertragen. Ich habs rausgenommen und alles funktioniert. Wenn euch der Hinweis noch hilft: Beim Laden von Seiten (insbes. Diskussion) kam der Browser nie zum Ende (so als Zusatzinfo zum Fehler). Danke für eure Hilfe, Grüße -- Hepha!±ion?15:45, 8. Feb. 2012 (CET)
Uih! Na holla.
Da bist du ja an die Richtigen geraten. Völlig klar, dass wir kurzfristig eine Lösung zaubern werden, so dass du künftig beide Werkzeuge parallel nutzen kannst.
Ich kann mir schon vorstellen, dass es zu Bearbeitungskonflikten kommen kann, weil beide Skripte gleichzeitig versuchen, den gerade zum Bearbeiten anstehenden Wikitext zu verändern. Irgendwie gab es sowas schon mal mit Normdaten?
Ne, nee, wir sind das gewohnt, und wir haben schon viel zusammen gewuppt. Schnark ist der dienstälteste Kunde von WikisyntaxTextMod (seit 2009), und wir koordinieren unsere Skripte gegenseitig. Wenn ich an WikisyntaxTextMod irgendwas ändern müsste, damit autoantraege harmonisch funktioniert, dann wünscht sich Schnark das, und morgen steht es live. Keine Sorge --PerfektesChaos18:30, 8. Feb. 2012 (CET)
(TL;DR) 'important' erwartet, aber 'ie' gefunden. ist gewollt, da nur auf diese Art auch im IE <= 7 Hintergrundbilder angezeigt werden. Das Problem erinnert mich sehr an dieses, daher wäre es sehr interessant, ob du auch die Fehlermeldung dialog.dialog is not a function bekommst. @PerfektesChaos: Ich nehme mal an, dass du dir sicher bist, jQuery nicht versehentlich irgendwo zu überschreiben? --Schnark10:34, 9. Feb. 2012 (CET)
Mh, vielleict liegts ja wirklich an mir, aber wie gesagt, er lädt in der alten Version viele Seiten nie zu Ende. An meinem Rechner/Internet liegt es nicht, ist beides schnell. -- Hepha!±ion?11:43, 9. Feb. 2012 (CET)
Schalte mal mit Strg+Umschalt+K die Web-Konsole ein (ich nehme mal an, dass du eine halbwegs aktuelle Firefox-Version verwendest), und stelle einfach mal das komplette Ergebnis, das sich auf einer Seite zeigt, die Probleme macht. --Schnark11:48, 9. Feb. 2012 (CET)
@Schnark
Zu deiner Beruhigung habe ich eben noch mal den Debugger rangesetzt, weder auf edit noch auf submit wird jQuery ein Haar gekrümmt (die Zeichenkette wäre bei mir auch extrem selten, es gibt nur jQuery.browser jQuery.isArray jQuery.cookie und jQuery(document).ready). Hephaion verwendet über en.WP wohl auch einen WSTM.4.
Die Geschichte aus dem letzten Sommer erinnert mich an dieses frame-scope-Problem. Die MW-Leutchen achten ja sehr darauf, dass sie dieselbe Instanz von $/jQuery in ihren gekapselten Blöcken bekommen, und in irgendeinem RL-Text steht auch eine kryptische Andeutung, dass sonst jedes Modul eigene Objekte hätte.
@Hephaion
Welche FF-Version hast du denn? Vielleicht der neue 10er, oder der schon einige Male unangenehm aufgefallene 9.01?
Zur Version: Ich habe bisher den 5er genommen, weil ich viele Addons benutze und die noch nicht kompatibel waren. Ich habe nun die final version des neues 10ers istalliert, aber das gleiche Problem:
Fehlermeldungen (in hoher Zahl):
Warnung: 'important' erwartet, aber 'ie' gefunden. ';' oder '}' zum Beenden der Deklaration erwartet, aber 'ie' gefunden. Deklaration ignoriert.
Ich schaue da wie ein Schwein in Uhrwerk, aber vielleicht sagt es euch ja etwas. (Manche Warnungen beziehen sich auf die aktion edit (dieser Seie) aber ich hab die mal mit reingenommen. Grüße -- Hepha!±ion?12:53, 9. Feb. 2012 (CET)
Alles was mit Warnung anfängt, ist irrelevant. Da alle ähnlichen Fehler, inklusive diesem mit viel JavaScript zu tun hatten, vermute ich irgendeinen absurden Bug in FF4+. So absurde Dinge wie maximal 32 CSS-Dateien pro Dokument erwartet man zwar nur im IE, aber wer weiß, vielleicht hat FF auch solche Bugs. Firefox 3.6 ist eine immer noch unterstützte Version, die viel weniger Probleme macht als alle anderen Browser. --Schnark09:24, 10. Feb. 2012 (CET)
Bei mir hat sich am mit dem Update auf FF 10 nichts verbessert, d.h. die unendlich langen Ladezeiten kann ich nur umgehen, wenn ich einige Script deaktiviere. Wenn ich beispielsweise Benutzer:Ireas/Gadget-Commonsverschiebung.js aktiviere, wird es wieder langsam. Autoanträge habe ich standardmässig aktiviert. Irgendetwas ist wohl in diesen Scripten drin, was sich nicht mag… --Leyo11:10, 10. Feb. 2012 (CET)
Also bei Ireas/Gadget-Commonsverschiebung.js läuft es mir eiskalt den Rücken herunter: Der Code in den ersten Zeilen ist eine ganz furchtbar schreckliche Zeitbombe. Ich kann mir zwar nicht vorstellen, dass die jetzt schon hochgeht, aber trotzdem: Ersetze alle $j durch $ und lösche die Zeilen
if (typeof($j) == "undefined")
document.write('<script type="text/javascript" src="http://bits.wikimedia.org/skins-1.5/common/jquery.min.js?270z54"></script>');
So? Leider hat es keine merkliche Verbesserung bezüglich Ladezeiten gebracht. Es ist übrigens nicht das einzige Script, das ich wegen dieser Probleme deaktiviert hatte. --Leyo13:18, 10. Feb. 2012 (CET)
Dass deine Änderung eigentlich nichts geändert haben kann, habe ich ja schon angekündigt, aber jetzt kann ich es immerhin lesen, ohne mich schütteln zu müssen (nun ja, laut Versionsgeschichte konnte ich das auch vorher shcon). JSHint beschwert sich noch über einige Stellen, aber nichts wirklich Relevantes (zumindest nicht im Firefox, es würde mich wundern, wenn das in Opera läuft). Wirklich hilfreiche Antworten wirst du von mir erst dann bekommen, wenn ich nicht mehr den guten alten Firefox 3.6 verwende. --Schnark09:31, 11. Feb. 2012 (CET)
Hallo! In der Annahme, dass du deine Bugreporte hier annimmst: Dein nettes Skript funktioniert nicht bei mehr, nachdem der Umherirrende die MediaWiki-Systemnachrichten verändert hat. Der Pfeil und die Links in den <sup>s werden jetzt von einem <span class="mw-cite-backlink"> eingerahmt – das sollte es deinem Skript eigentlich sogar einfacher machen. Nur funktioniert der bisherige Algorithmus mit dem Link-filtern natürlich nicht mehr. Die Nachrichten scheinen ein wenig Zeit zu benötigen, bis sie in den Cache wandern; ich hatte gerade den Fall, dass nur bei mehrfach-Referenzen mit group-Attribut, wie sie etwa im Artikel Cocktail#Bekannte Cocktails vorkommen (und natürlich extrem selten sind :-), die neue Systemnachricht verwendet wurde, sodass ich schon an ein neues, noch verbuggtes Feature dachte… -- ✓Bergi00:33, 16. Feb. 2012 (CET)
Ich hatte eigentlich gehofft, einfach abwarten zu können, bis die Klasse als Standard zur Verfügung steht, und dann das hässliche DOM-Rumgemache, das ich eigentlich gar nicht verstehe, durch jQuery ersetzen kann, aber nun gut. Jetzt sollten Backlinks gefunden werden, auch wenn sie irgendwo tief in childNodes verschachtelt sind. Dein Beispiel sieht bei mir wieder so aus, wie es soll. --Schnark10:23, 16. Feb. 2012 (CET)
Danke! Ich hätte gedacht, du steigst gleich auf die Klasse um, kann man die beiden Filteralgorithmen nicht parallel laufen lassen? -- ✓Bergi11:21, 16. Feb. 2012 (CET)
Wie gesagt, dazu müsste ich verstehen, wie man ohne jQuery DOM-Manipulationen vornimmt, oder einen komischen Mischmasch aus reinem DOM und jQuery schreiben, beides wollte ich nicht, insbesondere nicht, ohne das vorher ausgiebig in meinem privatem Wiki zu testen (wo ich mir alle peinlichen Programmierfehler erlauben kann, ohne dass das hier jemand auffällt). --Schnark11:37, 16. Feb. 2012 (CET)
Aufgrund des Seiten-Caches zieht die Nachricht natürlich erst, wenn dieser aktualisiert wurde. Da für die Printversion aber meistens eine eigene Version erstellt wird, fällt dies dort natürlich nicht auf und das Ausblenden sollte immer funktionieren.
Da es sich bei der Änderung nur um eine Systemnachricht handelte, hatte ich gedacht, das könnte man auch sofort machen. Vorallem stand es auch noch auf Raymond's Diskussionsseite als TODO-Punkt, der ist jetzt schon erledigt. Der Umherirrende 16:52, 16. Feb. 2012 (CET)
Neue Lektüre
Hallo,
zwei neue Seiten: RL und jQuery – mit der Bitte um Durchsicht, Korrektur, allfällige Ergänzungen und andere Formen kollegialer Kritik.
Ich bezweifle deine Behauptung, innerhalb anonymer Funktionen ließen sich keine Haltepunkte setzen. Bist du dir da wirklich sicher? --Schnark09:19, 27. Feb. 2012 (CET)
Das Problem ist lediglich, in eine anonyme Funktion hineinzukommen; Firebug listet sie nicht im DOM und in den Skripten sind sie auch nicht zugänglich. Oder gibt es irgendeine kryptische Einstellung, die ich noch nicht gefunden hätte? Auf jeden Fall wäre selbst eine Liste von Dutzenden anonymer Funktionen mit irgendwelchen 72A8C1073D auch nicht grade übersichtlich, und beim Reload werden die Nummern anders verteilt und im nächsten Durchlauf wären alle zuvor gesetzten Haltepunkte wohl futsch, während die Haltepunkte in benannten Pfaden noch vorhanden sind. Grüße --PerfektesChaos09:35, 27. Feb. 2012 (CET)
Ich kann es zwar gerade nicht ausprobieren, aber ich meine, dass ich schon oft genug problemlos einen Haltepunkt innerhalb anonymer Funktionen gesetzt habe. --Schnark09:41, 27. Feb. 2012 (CET)
Okay, wenn man über den Quelltext des Skriptes hinmanövriert, geht es; insofern wäre die getroffene Aussage ggf. anders zu formulieren oder zu streichen. Ich navigiere immer über das DOM, und da stehen sie wohl irgendwann, wenn man allen möglichen Müll zuschaltet, zwischen kryptischem weil anonymem Zeugs. Im Debug-Mode hat man dafür das Vergnügen mit etlichen einzelnen MW-Skripten. Es ist halt alles nicht mehr so einfach und übersichtlich wie vor zehn Jahren. --PerfektesChaos10:05, 27. Feb. 2012 (CET)
Im Debug-Modus hat man so viele andere Probleme, dass die Unzahl der Skripte, aus denen man sich dann das Richtige rauspicken muss, eigentlich nicht das Hauptproblem darstellen. Ich bin am überlegen, ob ich nicht einen Bug aufmachen will, mit der Bitte, den Debug-Modus abzuschaffen und dafür die Möglichkeit zu bieten, die Skripte wie üblich zusammengefasst, aber nicht komprimiert zu laden. --Schnark10:11, 27. Feb. 2012 (CET)
Na, grüß schön von mir. debug=true legt zwar eine zweiwertige Logik nahe, aber ich wäre schon mit einem standardmäßigen Kompromiss zufrieden: Aufhebung dieser unsäglichen Zeilenlänge 1000 beim Minifying. Die paar Dutzend eingesparter \n machen es auch nicht schneller, aber dann kann man ad hoc in jQuery reinklicken, weil sich plötzlich eine Fehlersituation aufgetan hat. Seit Wochen flimmert uns ein wikis is undefined oder bannerList is null über die Konsole, als Folgefehler in jQuery. Die Ursachen sind zwar bekannt und therapieresistent, aber ich könnte ihn sonst nicht analysieren. VG --PerfektesChaos10:32, 27. Feb. 2012 (CET)
Danke für die Erweiterung extratabs, find ich sehr nützlich.
Ich hab beim rumbasteln damit aber nen Fehler gefunden:
Im Abschnitt tools steht etwas weiter unten
Wäre es ev. sinnvoll extratabs mit dem Toolserver-Integrations-Gadget zusammenzuführen? Letzteres wird von weniger erfahrenen Benutzern bestimmt deutlich häufiger verwendet, wird aber wenig gewartet.
Oder gäbe es eine Möglichkeit bei „Doppeleinsatz“ entstehende Redundanzen zu eliminieren, beispielsweise durch identische Benennung derselben Tabs? --Leyo09:45, 24. Feb. 2012 (CET)
Eben weil das Gadget von weniger erfahrenen Benutzern verwendet wird, sollten diese tunlichst von meinem Skript verschont bleiben, der gewöhnliche Benutzer würde wohl wahnsinnig, wenn er mit einer solchen Vielzahl an Reitern konfrontiert würde, im Monobookskin kann das außerdem die Bildschirmbreite sprengen (habe ich nie ausprobiert). Ein Doppeleinsatz ist nicht vorgesehen, da ich eigentlich anstrebe, eine Obermenge an Tools anzubieten (abzüglich der Tools, die ich für völlig unsinnig halte). --Schnark10:08, 24. Feb. 2012 (CET)
Bei mir ist es tatsächlich sehr breit… ;-) Gibt es im Gadget einen Tab, der bei deinem Script nicht enthalten ist?
Aber ginge es technisch überhaupt, wenn ich beiden Scripts ein Tab „ca-beispieltab“ genannt wird? --Leyo10:19, 24. Feb. 2012 (CET)
Wenn ich nur auf die ersten Zeilen des Gadgets schaue, und die Reiter meines Skripts nur aus dem Gedächtnis zitiere, dann fehlen bei mir FIST (hat in all meinen Versuchen niemals überzeugende Ergebnisse geliefert), Gallery, orphans, Untagged (Bilder gehören nach Commons, also sehe ich keinen Grund, warum man diese Tools hier braucht) und NaviLinkCheck (wird bei Navigationsleiten ohnehin auf der Vorlagenseite angezeigt, ist also völlig redundant). Alle bis auf letzteres sollte man aber mit einer benutzerdefinierten Konfiguration zu haben sein.
Mein Skript könnte zumindest feststellen, dass das Gadget aktiviert ist und sich entsprechend verhalten – wenn ich dafür einen Grund sähe. --Schnark10:27, 24. Feb. 2012 (CET)
Danke für die ausführliche Antwort! Gerade weil die Bildern – mit Ausnahme der nicht commonsfähigen – nach Commons gehören, ist IMHO Gallery nützlich um transferierbare Dateien zu finden. Im Unterschied zu Spezial:Dateien liefert das Tool Zusatzinfos wie ob ein NowCommons- oder DÜP-Baustein enthalten ist. Mit FIST habe ich schon Bilder gefunden und hochgeladen, auch wenn ich das Tool nicht so oft benutze. --Leyo10:36, 24. Feb. 2012 (CET)
Ok, vielen Dank für die Rückmeldung. Ich hatte mit meinem fachspezifischen Admin hier darüber schon mal diskutiert. Bislang ist die Verlinkung von Kurzzitaten in der deutschsprachigen WP jedenfalls äußerst stiefmütterlich gehandhabt worden, im Vergleich zur englischen. Je früher man das System umstellt, um so besser, würd ich mal aus Sicht des wissenschaftlichen Zitierens sagen. Ich will das jetzt aber auf der Feature-Request-Seite nicht allzu lang ausdehnen, auch wenn ich mir eine Lösung wünschen würde, ohne die Unterstreichung der Artikel-Links generell abzustellen. Grüße,--LS12:33, 27. Feb. 2012 (CET)
personendaten.js
Hallo schnark, in meiner monobook.js funktioniert seit kurzem deine personendaten.js nicht mehr. Gibt es irgendeine Änderung in der Wikimedia-Software? Fragenden Gruß --1971markus(☠):⇒ Laberkasten ...02:21, 6. Mär. 2012 (CET)
Hallo Schnark! Ich bin heute auf deine js-module umgestiegen (die sind voll toll, vielen Dank dafür! :). Dazu habe ich eine Frage: mit den autoantreagen bekommt man auch diese verbessertes Rückgängig-Links. Ist es irgendwie möglich, das abzustellen? Eigentlich brauche ich nur die Autoanträge in der Werkzeug-Liste. --Knopfkind19:44, 1. Mär. 2012 (CET)
Darf ich einen Vorschlag zur Verbesserung der Usability machen? Beim Stellen von DRs auf Commons (Löschung vorschlagen bzw. Nominate for deletion) lässt sich die Box beliebig breiter machen. Zudem erhält man eine Vorschau des Begründungstexts mit gerendertem Wikisyntax. Diese beiden Features wären auch hier ganz nett. Was meinst du? --Leyo14:37, 2. Mär. 2012 (CET)
Ich habe genug andere Dinge zu tun, sodass ich zwar einfach mal sage, dass ich das auf meine ToDo-Liste setze, dir aber nicht allzuviel Hoffnung machen will, dass das irgendwann in absehbarer Zeit kommt. Ich habe gerade einen kleinen Fehler behoben, aber ansonsten hoffe ich eigentlich noch immer, dass irgendjemand einen Fork des Skripts startet, und mir damit die Arbeit abnimmt. --Schnark09:11, 3. Mär. 2012 (CET)
Ich konnte/kann den zeitlichen Aufwand für eine Implementierung nicht abschätzen und habe deshalb einfach mal gefragt. Vielleicht kann man ja ein Gadget draus machen, an welchem dann verschiedene Benutzer mitwirken können. --Leyo18:25, 4. Mär. 2012 (CET)
Noch zur Klarstellung: Die gerenderte Vorschau ist natürlich nur ein Nice-to-Have. Dass man bei einer langen Begründung nur einen Teil davon sieht, empfinde ich hingegen als echten Schönheitsfehler in deinem sonst supertollen Script. Ich hätte gedacht, dass es für dich nicht allzu schwierig wäre, beim Eingabefeld Zeilenumbrüche zu erlauben oder die feste Breite zu entfernen. Dass du wenig Zeit hast, verstehe ich aber selbstverständlich. :-) --Leyo10:56, 26. Mär. 2012 (CEST)
Konflikt bei Erledigt-Funktion
Hallo Schnark, mir ist grad bei der Erledigt-Funktion ein Konflikt entstanden. Könntest Du da evt. einen zusätzlichen Check einbauen ob schon etwaige Vorlage gesetzt wurde!? Danke und Gruß -- πϵρήλιο℗19:30, 10. Mär. 2012 (CET)
Wenn alle die Vorlage mit einem Großbuchstaben schreiben würden, wäre das nicht passiert. Ist der Hinweis auf meiner Diskussionsseite Beginne bitte für jedes Thema einen neuen Abschnitt am Ende der Seite, selbst dann, wenn es bereits einen Abschnitt zu einem ähnlichen Thema gibt. eigentlich so schwierig zu verstehen? --Schnark09:08, 12. Mär. 2012 (CET)
Danke. Als DAU hab ich keine Ahnung, wie du das gezaubert hast, aber mein Interesse ist mit der Liste befriedigt. Recht spannend. Viele liebe Grüße --Julius1990Disk.Werbung12:27, 12. Mär. 2012 (CET)
So schwer wie es möglicherweise aussieht, war es gar nicht; ich hatte schon vor einiger Zeit ein kleines Skript geschrieben, das genau das macht. Und für den Fall, dass jetzt jemand nachfragt, ob ich dieses Skript veröffentlichen kann: Nein, das Skript kümmert sich nicht um irgendwelche Opt-ins, und ich habe keine Lust, deswegen lange Diskussionen zu führen, daher halte ich das lieber ein wenig geheim, bin aber gerne bereit auf Anfrage das Skript auch für andere Benutzer laufen zu lassen (außer vielleicht bei aka, aber der wird selber wissen, wie man so etwas macht). --Schnark09:20, 13. Mär. 2012 (CET)
Wenn du das bei Aka machst, würden vermutlich in deiner Heimatstadt sämtliche Lichter ausgehen *g*
Könntest du für mich auch diese Abfrage laufen lassen? Mir würden eigentlich schon die Top 10 im ANR reichen, Soxreds Editcounter behauptet nämlich, ich hätte im Artikel 0 die meisten Bearbeitungen getätigt (36, tatsächlich war es nur eine einzige) ... Gruß --Schniggendiller Diskussion 14:53, 17. Mär. 2012 (CET)
Top 10 ANR ist nicht zu machen, ohne dass ich den vorhandenen Code umschreibe, sodass ich nur die 6 häufigsten liefern kann. Dort stimmt meine Liste mit soxred überein, mit dem Unterschied, dass mein Programm keine Zahlen verunstaltet, und der Artikel, der mit 36 Bearbeitungen an der Spitze steht, korrekt 2009 ist. --Schnark09:19, 26. Mär. 2012 (CEST)
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 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.
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. --Schnark09:27, 7. Apr. 2012 (CEST)
Hallo und Danke allerseits für die Antworten, die Tage werde ich wohl das Problem nicht genauer ergründen können (ich hatte insgeheim gehofft, dass das Problem kein allg. ist und sich konkret hier finden lässt). Ich bin mir aber sicher (nach euren detaillierten Antworten) wir werden die Ursache finden. Daher hier noch eine kurze Analyse: ein Problem-Bsp-Link: WP:TEX#Text; ja der Ankerlink wird aus der URL entfernt; auf Commons und En. gibt es den Effekt nicht; Firefox ist das Selbe; ich vermute daher einfach, dass irgendein Neuladen im Vector-Skin die Ursache ist (monobook ist alles in Ordnung, im Vector-Skin habe ich nur per jsmodules alle Skripte abgestellt), welches vielleicht sogar direkt im Zusammenhang mit dem Verschwinden des Redirect-Links steht. Allen angenehme sonnige Osterfeiertage. PS.: Redirects zu bearbeiten ist mir ohne den händischen Zusatz redirect=no nicht möglich.(Den Topic habe ich mal konkretisiert) -- πϵρήλιο℗14:48, 7. Apr. 2012 (CEST)
Du bekommst noch ein virtuelles Geschenk dazu – du darfst nachstehend die Ziffer 5 als das S von Schnark interpretieren.
In Vorbereitung von WSTM.5 habe ich heute die Version 4.5 gebranched – zu deinen Ehren das Datum verewigt.
Es werden folgende Neuerungen verwirklicht:
Das lineare stringDOM aus den 1990ern wird durch WikiTom ersetzt, das verschachtelte Syntax-Elemente ermöglicht. – Damit kann dieser alte Menschheitstraum erfüllt werden: Vorlagen innerhalb von Vorlagen.
Alle bekannten tags werden jetzt gefunden, syntaktisch analysiert und formatiert.
Wurden bislang Dutzende von Durchläufen mit regulären Ausdrücken über den ganzen Text gescheucht, gibt es zukünftig nur noch je eine Suche nach den Zeichenketten "<", "{{", "[", "://", "\n ", "&" in den jeweils noch verbleibenden Textbereichen; an der Fundstelle wird dann lokal analysiert und erforderlichenfalls gehandelt. Damit wird der Ablauf wieder etwas beschleunigt.
Die Schachtelung der Syntaxelemente ist bereits fertig implementiert; nur die Analyse beliebiger Vorlagen nach Parameternamen und beliebigen Parameterwerten mit Vorlagen/Kommentaren/Links und Vorlagen-Layout ist zu heute noch nicht fertig geworden. In alter Tradition sind die Personendaten der Testfall, namentlich wäre es der oben genannte Jan Jonker Afrikaner geworden, der aber inzwischen keine Vorlage in der Vorlage mehr enthält.
Der Syntaxbaum ist im Debugger unter WSTM.text nachlesbar.
Die Testversion steht hier, einfach en gegen test tauschen.
Hallo Schnark, ich habe mal dein Gadget vom Testwiki kopiert. Sollte man dort nicht auch noch die Border und padding wieder richtig stellen? Oder reichen die Farben? Es hat sich ja seit dem Versuch in 1.19 noch etwas getan. Der Umherirrende 16:55, 14. Apr. 2012 (CEST)
Stimmt, da hat sich inzwischen nochmal einiges geändert. Da ich vermute, dass diejenigen, die das alte Aussehen wollen, wirklich das alte Aussehen wollen, braucht es wohl folgendes:
In Anbetracht der Tatsache, dass im Testwiki die Gadgets gerade mal wieder nicht wollen, ist es nur halbwegs getestet, eventuell braucht es noch ein body vor allen Regeln.
Drüben aktualisiert, mit debug=true tut es, was es soll, ob es auch ohne debug geht, erfahren wir, wenn der Cache aktualisiert wird. --Schnark12:28, 17. Apr. 2012 (CEST)
Ja, der Cache war da zwischenzeitlich mal besser. important sieht aber nicht so schön aus oder ist die Ladereihenfolge da unschön? Bei inherit bin ich mir auch nicht ganz sicher, aber ältere IEs vertrugen das nicht, oder? Der Umherirrende 17:49, 17. Apr. 2012 (CEST)
Tatsächlich, IE <= 7 kennt kein inherit. Wenn man also die Regeln ohnehin aufsplitten muss, kommt man auch ohne important aus (was meiner Ansicht nach nicht so schlimm wäre, wenn man eine Eigenschaft auf jeden Fall überschreiben will, dann sollte es einen nicht stören, dass man sie auf jeden Fall überschreibt).
Klingt schon fast philosophisch. Ich habe dein Vorschlag mal rüber kopiert. Vielen Dank für das zusammenstellen. Der Umherirrende 19:19, 18. Apr. 2012 (CEST)
Ich hatte irgendwie angenommen, dass border: none; das miterledigt, aber du hast natürlich Recht, der border-radius wirkt sich auch auf den Hintergrund aus. Oben und im Testwiki ergänzt. Testen kann ich das allerdings nicht, da ich hier einen FF3.6 habe, der nur auf -moz-border-radius hört. --Schnark09:13, 19. Apr. 2012 (CEST)
— Sichtungswettbewerb (Disk.) – mach mit! 21:57, 14. Mai 2011 (CEST)
Sir Gawain Disk. 09:44, 27. Jul. 2011 (CEST)
Sir Gawain Disk. 11:30, 28. Jul. 2011 (CEST)
Überarbeiten statt Löschen! 
Überarbeiten statt Löschen! 
, komisch den sehe ich jetzt erst, liegt wohl an deinem fullscreen-script 
-- πϵρήλιο ℗ 14:59, 17. Mär. 2012 (CET) -- πϵρήλιο ℗ 15:02, 17. Mär. 2012 (CET)
