Benutzer Diskussion:Schnark/Archiv1

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

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/Archiv1#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Benutzer_Diskussion:Schnark/Archiv1#Thema_1

Willkommen!

Hallo Schnark. Herzlich willkommen in der deutschsprachigen Wikipedia!
Danke für dein Interesse an unserem Projekt. Ich freue mich auf deine Beiträge und hoffe auf eine angenehme Zusammenarbeit.
Die deutschsprachige Wikipedia ist eine Enzyklopädie aus freien Inhalten, die seit Mai 2001 besteht. Mit Deiner Hilfe wird sie sicherlich noch mehr wachsen. Die Wikipedia hat derzeit 2.969.599 Artikel.
Es gibt in der Wikipedia einige „Richtlinien“, die man bei der Arbeit in der Wikipedia beachten sollte. Die wichtigsten Links findest Du hier unter den folgenden Links. Anleitung für Artikelschreiber Wie man gute Artikel schreibt Weitere Hinweise für den Anfang Wenn du Fragen hast Diese Seite hier ist deine Diskussionsseite, auf der dir andere Wikipedianer Nachrichten hinterlassen können. Wenn du selber eine Anfrage an einen anderen Wikipedianer hast, schreibe ihm bitte auf seiner Diskussionsseite. Bitte füge am Ende jeder Mitteilung auf Diskussionsseiten deine Unterschrift durch Eingabe von -- ~~~~ oder durch Drücken des auf dem Bild hervorgehobenen „Knopfes“ ein. Bitte beachte aber, dass Artikel nicht unterschrieben werden.
	Wenn Du Fragen hast schau doch einfach mal auf meiner Hilfeseite vorbei. Dort findest Du noch eine ganze Menge nützliche Links.		Du kannst mir natürlich auch eine Nachricht auf meiner Diskussionsseite hinterlassen! Ich helfe Dir gerne weiter!

Freundliche Grüße, -- RacoonyRE ^{(Disk.) (+/-) ✉} 15:10, 4. Apr. 2008 (CEST)

Caspar

Hallo Schnark, ich würde von einer WP:VM gegen den Argussammler absehen. Wenn es sich wirklich um Herrn C. handelt, ist der gute Mann ja schon 67. Ich bin mir nicht mal sicher, dass er seine Disk. auch liest. Also - besser den Artikel sperren lassen. Oder? Minderbinder 12:06, 23. Apr. 2008 (CEST)

Ich hatte gerade vor, einen Antrag zur Artikelsperrung zu stellen. Wenn er dort dann nichts mehr ändern kann wendet er sich vielleicht seiner Diskussionsseite zu, übersehen kann er sie ja eigentlich nicht. Ich bin allerdings in den nächsten Tagen wohl nicht online, kann also erst einmal die Entwicklung nicht weiterverfolgen.--Schnark 12:10, 23. Apr. 2008 (CEST)

Kein Problem, bin online. Also bei der nächsten flächendeckenden Löschung wird ein VM-Antrag auf Seitensperrung gestellt - wer den Edit zuerst sieht reicht VM ein. Den User lassen wir erstmal in Ruhe, darauf ein Hinweis in der VM. Minderbinder 12:13, 23. Apr. 2008 (CEST)

Den Seitensperrungsantrag habe ich schon gestellt, bevor du geantwortet hast, die Seite wurde auch schon gesperrt, 25 Änderungen in 2 Tagen sind wirklich schon zuviel. --Schnark 12:17, 23. Apr. 2008 (CEST)

BundesUmweltWettbewerb

Ist ja ein ganz nettes Thema. Gründung und Geschichte fehlt noch. AberMussEsSoEinGrottigesLemmaSein? Wie wäre es mit Bundes-Umweltwettbewerb und meinethalben Redirect darauf? Minderbinder 11:36, 15. Mai 2008 (CEST)

Der Wettbwerb heißt nun einmal offiziell so (mit genau dieser merkwürdigen Großschreibung). Auf der angegebenen Webseite wird er im Text zwar immer abkekürzt, aber im Titel kannst du klar erkennen, dass das IPN in so nennt. Oder suche mit Google o.ä. nach Bundesumweltwettbewerb, fast alle Treffer schreiben ihn BundesUmweltWettbewerb. --Schnark 11:44, 15. Mai 2008 (CEST)

Du hast recht. Schauder. Das ist doch ein deutscher Eigenname, keine Klasse in einem Javaprogramm. Kann man wohl nix machen. Minderbinder 11:56, 15. Mai 2008 (CEST)

eleganter

if (wgCanonicalNamespace === "Special" && wgCanonicalSpecialPageName === "Contributions") { ... } statt

if (location.href.indexOf("Spezial:Beiträge")!=-1||location.href.indexOf("Spezial:Beitr%C3%A4ge")!=-1) { ... }

und sprachunabhängig ist es dann auch -- ∂ 14:14, 28. Jul. 2008 (CEST)

Danke. Ich hatte zu dem Zeitpunkt zwar ganz andere Sorgen, aber jetzt habe ich es eingebaut und der Rest funktioniert auch! --Schnark 14:53, 28. Jul. 2008 (CEST)

Schnatz

Ob Schnark, Snark oder Schnatz,
Hier ist ganz der Platz.
Schönes Wochenends, --DL5MDA 13:29, 11. Jan. 2009 (CET)

Anmerkung

Hallo Schnark, das war vorher schon ganz richtig so. In den Personendaten soll in der Regel der Name verwendet werden, der auch im Lemma steht - in diesem Fall also mit dem abgekürzten Zweitnamen. Gruß, --Scooter ^Sprich! 12:19, 16. Mär. 2009 (CET)

Danke für den Hinweis. Ich werde es in Zukunft berücksichtigen, und dann die ausgeschriebene Form als Alternativname eintragen. --Schnark 09:11, 17. Mär. 2009 (CET)

Ashikaga Yoshimitsu

Hallo Schnark auch von meiner Seite! Danke erstmal für deine Überarbeitung - aber eine Frage hab ich noch... du hast bei meinem Artikel (Ashikaga Yoshimitsu) die PD ausgebessert und bei Geburts- und Sterbedatum

|GEBURTSDATUM=25. September 1358 |STERBEDATUM=31. Mai 1408

aus

|GEBURTSDATUM= 25/09/1358 |STERBEDATUM= 31/05/1408

gemacht. Da es sich um japanische Jahreszahlen die ich aus einem buch übernommen habe, darf man NICHT davonausgehen, dass der neunte Monat unbedingt der Septemeber ist und so weiter, daher wäre es korrekter, 25/09/1358 usw. zu schreiben. Ich weiß nicht, ob das bei den PD so wichtig ist und mit Schrägstrich funktioniert bzw. hilfreich ist. Vielleicht sagst du einfach was du dazu denkst, du kennst dich hier ja schon etwas besser aus nehm ich an :) bin ja neu hier! Dake jedenfalls nochmal, mit freundlichen Grüßen,

-- RadauthaR

Hallo RadauthaR!

Die Änderung an den Personendaten habe ich vorgenommen, ohne mir Gedanken über die japanische Zeitrechnung zu machen. Wenn die Daten vom europäischen Kalender abweichen, so müsste in den Personendaten (und am besten auch in der Einleitung) das in den gregorianischen Kalender umgerechnete Datum stehen. Es sollte also so ähnlich aussehen wie bei Taichō. Allerdings habe ich vom japanischen Kalender viel zu wenig (soll heißen: gar keine) Ahnung. Kannst du die Daten umrechnen? Viele Grüße --Schnark 09:45, 8. Apr. 2009 (CEST)

PS: Man unterschreibt hier üblicherweise mit --~~~~ (am einfachsten über den 2. Knopf von rechts in der Symbolleiste über dem Bearbeitungsfeld), die Software macht dann automatisch deinen Benutzernamen und die Uhrzeit daraus. Genaueres steht auch unter Hilfe:Signatur. Außerdem habe ich mir erlaubt, oben noch eine Überschrift hinzuzufügen.

Heinz Joerk

Hallo Schnark! Ich hatte schon einmal im Artikel Heinz Joerk die Kategorie Mann mit entsprechendem Hinweis gelöscht. Da Du sie nun erneut eingesetzt hast, erkläre mir bitte den Sinn dieser Kategorie. Mir erschließt sich der Sinn nicht, denn Trainer kann nur ein Mann sein. Gruß -- Greifen 10:57, 14. Apr. 2009 (CEST)

Bei den Kategoriebezeichnungen gilt das generische Maskulinum. Also lässt sich an der Kategorie:Trainer das Geschlecht noch nicht ablesen, eine Trainerin würde ebenfalls in die Kat:Trainer, aber dafür in die Kat:Frau eingeordnet. Jedenfalls sollte jeder Personenartikel in eine Kategorie unterhalb von Kategorie:Person nach Geschlecht eingeordnet werden, vor allem um die automatische Auswertung zu erleichtern. Siehe auch Wikipedia:Formatvorlage Biografie. Viele Grüße --Schnark 11:04, 14. Apr. 2009 (CEST)

Libor Klein

Danke für die Korrektur, das kommt vom kopieren ;-) --gruß K@rl (Verbessern ist besser als löschen) 12:57, 29. Okt. 2009 (CET)

Der Fehler war in diesem Fall dank der Wikipedia:Personendaten/Wartung/Fehlerliste schnell zu finden und zu korrigieren. Viele Grüße --Schnark 09:19, 31. Okt. 2009 (CET)

Annette Berr

Geburtsdatum von AB? Nach meinen Informationen ist es das Datum des 7. Juni 1963. Hast Du andere, seriöse Quellen außer der Angabe in der DNB? Denn diese ist alles andere als immer nur richtig. Grüße -- Harm N. 23:11, 21. Nov. 2009 (CET)

Ich habe einfach nur nach deiner Änderung das Geburtsdatum aus der Einleitung auch in die Personendaten und die Kategorie:Geboren übernommen, da dadurch eine Inkonsistenz entstanden ist. Wenn du also das Geburtsdatum in der Einleitung änderst, und gleichzeitig auch in den Personendaten und der Kategorisierung korrigierst, spricht von meiner Seite überhaupt nichts dagegen. Mit dem Link "@ Korrekturanfrage" auf http://d-nb.info/gnd/123236738 kannst du natürlich auch dort auf den Fehler aufmerksam machen. Viele Grüße --Schnark 09:32, 24. Nov. 2009 (CET)

Hallo Schnark. Übernimmst Du die entsprechende Abänderung in dem Artikel bitte? Grüße -- Harm N. 05:10, 6. Dez. 2009 (CET)

Welche Änderungen? Bearbeiten kannst du den Artikel doch selber, sollte es aus irgendwelchen Gründen Probleme mit den Personendaten geben, kann ich natürlich dann nochmal danach schauen (tun aber auch genug andere). --Schnark 11:59, 8. Dez. 2009 (CET)

Ich werde die Änderungen durchführen erst dann, wenn ich eine zweite, die unabhängig von der erten Quelle ist, gefunden habe. Denn erstere erscheint mir mittlerweile als "noch zu vage" zu sein. Grüße -- Harm N. 13:08, 8. Dez. 2009 (CET)

Syntaxmigration

Danke für deine freundlichen Worte.

Die Category war mir in den Bereichen, in denen ich unterwegs bin, in den letzten Jahren nicht aufgefallen; es müssen dann schon Artikel aus 2002 oder so sein.

Wenn du realen Bedarf hast, empfehle ich das bisher noch nicht beworbene Feature Benutzer:PerfektesChaos/js/MigriereWikiSyntaxDeutsch/mehrErsetzungen

var mehrErsetzungen  =  [
   ["^\\[\\[Category:", "[[Kategorie:"]
                         ];

Ansonsten habe ich noch ein wenig mehr in der pipeline, mal sehen wie das Wetter zwischen Weihnachten und Neujahr wird. --PerfektesChaos 18:16, 15. Dez. 2009 (CET)

Hallo PerfektesChaos! Die Variable mehrErsetzungen hatte ich schon für diesen (und noch andere Zwecke) verwendet, nachdem ich erkannt hatte, dass der doppelte Backslash das Geheimnis ist. Die englischen Kategorien kommen teilweise bei übersetzten Artikeln vor, werden aber meist schnell angepasst. Mir sind sie in den letzten Jahren wohl auch erst ein, zwei Mal begegnet, sodass vermutlich doch kein allgemeiner Bedarf besteht. --Schnark 09:27, 17. Dez. 2009 (CET)

Für den Fall, dass du zufällig noch mitliest: Granado Espada ist so ein Fall. Ich musste aber auch lange suchen und da ich sowieso nichts ändern wollte, habe ich ihn in Ruhe gelassen. --Schnark 11:01, 5. Jan. 2010 (CET)

Dummy-Frage zum Theil-Index

Hallo, ich habe deinen Artikel in der Wikiversity gelesen (sehr nützlich, danke!) und auch soweit verstanden. Eine Suche nach verschiedenen Theil-Index Ländervergleichen ließ aber die Panik ausbrechen. Ich bin hier http://www.lisproject.org/publications/LISwps/438.pdf (S. 12), dort http://www.main.sssup.it/wp/200906.pdf (S. 8) und bei der University of Texas gelandet: http://utip.gov.utexas.edu/data.html (EHII). Jeweils völlig unterschiedliche Theil-Werte zur Einkommensverteilung und kein Land in Sicht. Gibt es irgendeine einfache Möglichkeit/Übersichtsseite wie man die ganzen unterschiedliche Theil-Indexe auseinanderhalten bzw. vergleichen kann? --Talann 22:11, 29. Jan. 2010 (CET)

Du verwechselst mich. Zu dem da (ohne ein ch) willst du. --Schnark 09:21, 30. Jan. 2010 (CET)

Giddings

Hallo Schnark, danke für das Richten meiner Übersetzung (Geburtstag, Todestag, Reihenfolge der Kategorien). Wenn ich wüsste, wo man das (Reihenfolge der Kategorien) vernünftig nachlesen kann, könnte ich es gleich richtig machen und nicht solche Zusatzarbeit verursachen. Kannst Du mir einen Tip geben? Danke schon mal, --Peewit 17:16, 18. Mär. 2010 (CET)

Hallo Peewit! Für Biographien gibt es die Formatvorlage Biografie, da kannst du nachlesen, wie es üblich ist. Die Kategorienreihenfolge soll man sich da wohl aus dem Beispiel erschließen, explizit steht es unter Kategorie:Person: „zuerst der Beruf, dann die Nationalität und dann Geboren/Gestorben und Frau/Mann“. Viele Grüße, --Schnark 09:18, 19. Mär. 2010 (CET)

Besten Dank, Schnark!! Man muss hier viel lernen, bis man alles richtig macht. --Peewit 21:56, 19. Mär. 2010 (CET)

Personendaten

Hallo Schnark,

danke für das Ergänzen und Korrigieren des Artikels Klaus Lindemann. Die Plazierung der Personendaten habe ich geändert!

-- TobiWanKenobi 10:44, 27. Mär. 2010 (CET)

MigriereWikiSyntaxDeutsch

Hi,

als zurzeit einziger weiterer Nutzer meines Syntaxmigrations-Skriptes (für das ich bislang wohlweislich keine Promo gemacht hatte) kann ich es mir noch leisten, jeden Anwender persönlich über vsn2 zu informieren.

In deinem Benutzer:Schnark/vector.js müsstest du aus mehrErsetzungen ein mehrErsetzungenAuchLinkziele machen, weil die Kategorien-Ausdrücke [[ enthalten. Ein vorläufiges Beispiel steht unter Benutzer:PerfektesChaos/monobook.js.

Die Version 2 soll im Lauf der Feiertage unvermutet als "r" freigeschaltet und diese Änderung dann wirksam werden. Das Wetter soll irgendwann gaga sein, und dann werde ich mich auch dransetzen und nach etwas Gamma-Testing die neue Beschreibung krei-eren. Im Moment lacht aber die Sonne. Ich denke, ich gebe an dieser Stelle Bescheid.

Die wesentliche Neuerung ist, dass die Syntax analysiert wird betreffend solcher Bereiche, in denen die regulären Ausdrücke keinerlei Ersetzungen vornehmen dürfen. Das sind z.B. <math> oder <source> oder <code>, auch Kommentare oder mit Leerzeichen eingerückter Fest-Text. Nur auf besondere Anforderung (s.o.) wird an Linkziele herangegangen, also wikilinks, http-URL, Datei:-IDs. Damit werden für den restlichen Text auch eher sichtbare Formatierungen möglich, die ansonsten in einer URL oder Quellcode ein Gemetzel hinterlassen würden(mehr).

Frohe Ostertage --PerfektesChaos 16:51, 25. Mär. 2010 (CET)

Hallo PerfektesChaos! Nachdem ich den Code kurz überflogen habe, freue ich mich schon auf die neue Version. Wenn ich es richtig sehe, kann ich doch einfach alles außer den Folgepunkten aus mehrErsetzungen rauswerfen, und dafür dann var WikisyntaxDeutschVieles = true; aktivieren, die englischen Kategorien werden dann ja übersetzt und die Leerzeichen sah ich auch irgendwo. Was mir noch aufgefallen ist: syntaxhighlight sollte noch analog zu source behandelt werden (ob das irgendwo verwendet wird, weiß ich nicht, aber sicher ist sicher) und ein <hiero> gibt es auch noch, wo ich mir zwar auch nicht vorstellen kann, dass etwas schiefgeht, das aber vielleicht auch besser auf die Ausschlussliste gesetzt werden sollte. Viele Grüße und schöne Feiertage --Schnark 09:58, 26. Mär. 2010 (CET)

Danke,

hiero habe ich noch nie gesehen, aber ich hatte auch noch nie das Verlangen, eine ägyptische Grabinschrift zu editieren. In jedem Fall macht darin typografische Korrektur keinen Sinn.

syntaxhighlight hatte ich schlicht überlesen, gab bei mir noch nie Bedarf dafür. Muss selbstverständlich gleich-, gar höherrangig mit source behandelt werden.

@englische Kategorien – Stimmt, deine Category wird inzwischen übersetzt; hatte ich schon völlig verdrängt, und nie benötigt.

Über Ostern hatte ich an einer runden Version gefeilt, ausgiebig getestet, aber vor allem dokummentiert.

Ich beabsichtige, dich wie bisher unter "Delta-Tester" laufen zu lassen. Die Funktionalität hat sich gegenüber dem letzten Jahr massiv erhöht, der alte Name trifft es nicht mehr so ganz. Ich plane noch ein Release 3 mit letzten Ideen unter altem Namen und nach dessen Erprobung dann eine Umbenennung sowie Reklame. Die momentane Version ist aber ein zufriedenstellender stabiler Zwischenzustand.

Bis dann --PerfektesChaos 18:34, 14. Apr. 2010 (CEST)

Auch wenn du es nicht wissen konntest: Dein Skript ist eines der nützlichsten Geburtstagsgeschenke, die ich gestern bekommen habe. Danke! --Schnark 09:08, 15. Apr. 2010 (CEST)

Sodele,

workaround 3/4 Stunde nach Problemmeldung, inzwischen auch wunschgemäß geänderte r-Version (clear your cache); Rest hier … --PerfektesChaos 00:41, 16. Apr. 2010 (CEST)

Neues Release (4) losgelassen.

Neuer Disk-Trail dazu: SyntaxMod vsn4

--PerfektesChaos 11:51, 19. Apr. 2010 (CEST)

@Hinweise auf Unartigkeit der zurzeit in Umbruch und Paradigmenwechsel (Pubertät) befindlichen Skripterei sind willkommen. Allerdings ändern sich dabei keine einzelnen Buchstaben, sondern es würde schon gleich der halbe Artikel zerlegt.

Momentan gehe ich zum Testen nur schnell auf ein Dutzend zufälliger Artikel; meinen Ansprüchen an Durchtesten und ausgereifte Versionen genügt das nicht.

@PD: vsn4 macht zu deiner Erbauung triviale fixe in den PD.

@FF: Es hat schon seinen Grund, warum ich gemächlich in den FF 3.5.* bleibe.

--PerfektesChaos 11:56, 19. Apr. 2010 (CEST)

Sichten

koenntest du das naechste mal sowas auch gleich sichten? Danke --hroest Disk 15:14, 28. Apr. 2010 (CEST)

Im Normalfall tue ich das. In diesem Fall war ich allerdings dabei systematisch einige Artikel von Fehlern in den PD zu befreien und daher nicht so ganz in der Stimmung, mir auch noch die vorhergehenden Unterschiede anzuschauen. Und gerade, wenn sich der Unterschied über zwei Versionen hinzuieht, ist oft mehr als nur ein Blick notwendig. Genausogut hättest du übrigens auch Benutzer:Inkowik32 fragen können, warum er nicht bei seiner Bearbeitung gesichtet hat. (Falls es dir übrigens vorkommt, als klänge mein Tonfall leicht genervt, dann hast du recht, das liegt aber nur an dem Computer, an dem ich gerade sitze.) Viele Grüße, --Schnark 09:43, 1. Mai 2010 (CEST)

WikisyntaxTextMod released

Hallöle,

MigriereWikiSyntaxDeutsch ist Geschichte, es lebe WikisyntaxTextMod (und mehrErsetzungen heißt jetzt Modif_Text).

Den Mai über hatte ich nichts grundsätzlich Neues eingebaut, nur Macken beseitigt, auf Seltsamkeiten wie ein leeres Link [[]] besser reagiert und abgerundet. Aus Freiburg kamen auch keine Beschwerden mehr; so hoffe ich denn, dass jetzt eine robuste Methodik vorliegt und ein Weilchen nicht geändert werden muss.

Da du offensichtlich gern mit Köpfchen an Knöpfchen spielst, schau doch mal hier rein: Manueller Start.

Nachdem alle Einbindungen von Migriere… verschwunden sind, werden die damit verbundenen Seiten gelöscht.

Eine schöne Woche --PerfektesChaos 10:34, 31. Mai 2010 (CEST)

Ich weiß nicht, ob es Absicht ist, aber Modif_Link (und vielleicht auch Modif_Text) ist zum Pflichtparameter geworden, fehlt er, so meckert FF an der Zeile if(isArray(Modif_Link)){ herum und tut nichts. Ich fände es praktischer, wenn bei fehlender Definition automatisch ein leeres Array angenommen würde. Den manuellen Start und die anderen Möglichkeiten teste ich mal, wenn ich etwas Zeit finde. Viele Grüße, --Schnark 11:26, 31. Mai 2010 (CEST)

Ooops, die Nachricht habe ich erst dieses Wochenende gelesen.

Danke für die Info; deine Kommentare sind wichtig für mich: Bei mir sind beide Modif_ immer definiert, und ich bekomme sowas gar nicht mit.

Nein, es war weder meine Absicht noch mein Stil.

Weil du selbst programmierst, kurz die Erklärung und Abhilfe:

• isArray guckt sich ja gerade an, ob im Anwenderskript die Variable definiert wurde.
• Eigentlich sollte eine undefinierte Variable wie jede andere mit dem Wert undefined belegt sein.
• Nur zicken manche JavaScript-Umgebungen (und offensichtlich deine FF-Version) rum und machen das nur, wenn x als var x; deklariert wurde, andere JS dagegen auch für jeden unbekannten Variabennamen. So kann es schon zum Absturz kommen, wenn isArray(x) auch nur aufgerufen wird.
• typeof(x) geht jedoch immer.

Im Zuge der ganzen Umstrukturierung kam das irgendwie unter die Räder, stand vorher an zwei verschiedenen Stellen und ist jetzt komplett in WikisyntaxTextMod_Run() eingebaut, r=1.03 hat es gefixt.

Wohlsortierte Woche --PerfektesChaos 10:46, 21. Jun. 2010 (CEST)

toolbar.js

Nach ein paar Anlaufschwierigkeiten habe ich jetzt ein paar einfache Funktionen hinbekommen. Ist eine gute Idee und fügt sich auch gut in das neue vector ein. Was ich noch vermisse und früher öfter verwendet habe ist ein Button für <ref></ref>, könntest du das bitte noch einbauen? Grüße --Bjs (Diskussion) 21:04, 18. Jun. 2010 (CEST)

Einen Button für ref's hat die neue Leiste doch als Standard, das aufgeschlagene Buch zwischen Bild und Unterschrift. --Schnark 09:06, 19. Jun. 2010 (CEST)

Jetzt wo du's sagst, seh ichs auch. War mir noch nie aufgefallen, ist die neu? --Bjs (Diskussion) 14:43, 19. Jun. 2010 (CEST)

Der Button existiert eigentlich schon "immer". Nur auf Diskussionsseiten wird er nicht angezeigt, vielleicht hast du ihn deswegen bisher übersehen. --Schnark 09:22, 21. Jun. 2010 (CEST)

Oh das passiert auch mit anderen Buttons. Aus Artikelseiten ist der Unterschrift-Button weg, man kann also keine Löschanträge mehr unterschreiben ;-) Lieb gemeint, aber durchaus gewöhnungsbedürftig. --Bjs (Diskussion) 09:49, 21. Jun. 2010 (CEST)

Das haben die Leute von der Usability-Initiative so gemacht, damit Anfänger nicht in Artikeln unterschreiben. Da mir das auch schon störend aufgefallen ist, gehört die Signatur zu den wenigen Dingen, die mein Skript zur Verfügung stellt, obwohl es eigentlich da ist. Ein

newtoolbar_addButton('', 'sig');

in deine vector.js hinter function newtoolbar_config() {, und du hast immer einen Signaturbutton. --Schnark 09:56, 21. Jun. 2010 (CEST)

Werkzeugleiste

Hallo Schnark, nur für den Fall, dass du mich nicht mehr beobachtest (hab ja eine Weile gebraucht): Könntest du bitte noch mal vorbeischauen? Danke, Mushushu 18:14, 20. Jun. 2010 (CEST)

Hilfe mit meiner Toolbar

Hallo, danke für dein Toolbar-Skript. Ich habe unter Benutzer:Matthias M./extraedit.js auch zwei eigene Knöpfe gebastelt, die aber leider zusätzlich folgenden störenden Teil ausgeben:

truefunction () {
   $j("#wpSummary").val($j("#wpSummary").val() + zuq);
}

Die Literaturformatierungshilfe wird leider auch nicht angezeigt. Könntest du mir einen Tipp geben, wie ich das reparieren kann? Matthias 14:47, 27. Jun. 2010 (CEST)

Du musst jeweils angeben, was vorne, in der Mitte und hinten eingefügt werden soll, also 3 Strings, nicht nur einen:

newtoolbar_addMyButton('advanced', 'http://upload.wikimedia.org/wikipedia/commons/thumb/8/83/Go-next.svg/22px-Go-next.svg.png', 'export', '{{Export|OS|~~~~|ok}}', '', '', true, newtoolbar_addComment('Export'));
newtoolbar_addMyButton('advanced', 'http://upload.wikimedia.org/wikipedia/commons/thumb/f/fb/Yes_check.svg/22px-Yes_check.svg.png', 'done', '{{Erledigt|~~~~}}', '', '', true, newtoolbar_addComment('Erledigt'));

Die Hilfe hast du von mir kopiert, bei mir wird sie allerdings in die Personendaten-Hilfe eingefügt, die du bei dir wieder entfernt hast. Ein newtoolbar_addMySection('Hilfe', false); vor der addTable-Zeile sollte helfen. --Schnark 09:21, 28. Jun. 2010 (CEST)

Es klappt: vielen Dank. Matthias 16:23, 28. Jun. 2010 (CEST)

Extra Schaltflächen :-)

Da Du ja erwähnt hattest, dass du Vorschlägen gerne entgegen kommst, habe ich mal den Smiley Button - der noch unter den fehlenden zu sein scheint - als Gruppe aus {{Smiley}} gemacht. Siehe Benutzer:Perhelion/vector-smilies.js Würde mich freuen wenn Du sie in irgendeiner Form aufnehmen könntest, wenn ich sie vervollständigt habe. Ansonsten großes Lob. LG Vorlage:Smiley/Wartung/:d  -- Perhelion 20:32, 29. Jun. 2010 (CEST)

newtoolbar_addSection('SM'); bindet jetzt deine Smilies ein. Dokumentieren werde ich es, sobald ich herausgefunden habe, warum ich Benutzer:Schnark/toolbar.js/smilies.js nicht einfach nur dann einbinden kann, wenn es gebraucht wird. --Schnark 09:42, 30. Jun. 2010 (CEST)

Gerade wollte ich genervt aufgeben, da es einfach nicht wollte, obwohl der Cache gelöscht war, aber nach einem Neustart funktioniert es plötzlich.

Es gibt jetzt die gesamte Leiste als newtoolbar_addSection('SM'); und eine kleine Gruppe (mehr als Proof of Concept) als newtoolbar_addGroup('SM');. Mir wäre es am liebsten, wenn du Benutzer:Schnark/toolbar.js/smilies.js wieder zu dir übernimmst, damit du es dann selbstständig pflegen kannst. Das erste, was zu tun ist, ist das dritte Icon, das nicht will. --Schnark 10:46, 3. Jul. 2010 (CEST)

Ok, danke, das ging ja relativ fix. Natürlich unterstütze ich Dich (in dieser "Nebensache"), werde ich heute Abend erledigen. Da ich auch gerne in Commons aktiv bin würde ich gern dein Script portieren, allerdings mit ganz anderen Buttons (erstmal nur eigene Button-Sammlung). Ach was mir noch aufgefallen ist, Du legst ein klein wenig viel Augenmerk am Anfang auf die var usersignature, das ist denke ich für den geneigten Leser der Dokumention eher nebensächlich (wenn nicht gar verwirrend ) Ansonsten machst Du schon ein super Job. Vorlage:Smiley/Wartung/hammer  Vorlage:Smiley/Wartung/;)  Beste Grüße --Perhelion 14:09, 5. Jul. 2010 (CEST)

Ist es so ok, ist die function newtoolbar_extern_SMg noch von Nöten und ist das mit der iurl ok oder auch verumständlichend? Habe die Bildchen soweit gefixt. Habe ein Script gefunden was dich vielleicht interessieren könnte (und geupdated) Benutzer:Perhelion/signing.js, wegen Proof of Concept. Ach und wo hast eigentlich den <code></code> Button? Vorlage:Smiley/Wartung/:p  Viele Grüße -- Perhelion 17:51, 6. Jul. 2010 (CEST)

Die sauberste Lösung wäre vermutlich, wenn ich mein Skript in zwei Teile zerhacke, einen allgemeinen, den man in allen Projekten verwenden und ergänzen kann, und einen de-spezifischen. Das nehme ich mir mal für die nächsten Tage vor.

Die function newtoolbar_extern_SMg schadet eigentlich niemand, und vielleicht gibt es wirklich Benutzer, die nur ein paar Smileys haben wollen. Dass ich diese Gruppe auf die drei ersten beschränkt habe, ist reiner Zufall, du weißt sicher besser als ich, welche am häufigsten verwendet werden.

In Anbetracht der Tatsache, dass ich inzwischen sämtliche Formatierungen außer tt anbiete, sollte ich tatsächlich auch noch diesen letzen Button aufnehmen, bis dahin hätte ich newtoolbar_addSelect('Ort', 'CODE'); anzubieten. --Schnark 09:29, 7. Jul. 2010 (CEST)

Du hast recht Vorlage:Smiley/Wartung/8) . Ich habe dein Script ohne Portierung direkt in Commons eingebunden und schon eine Reihe von Buttons erstellt, funzt suppi Vorlage:Smiley/Wartung/grün  (hier zum schnellen schauen Commons:User:Perhelion/vector.js) Das Smilie Script habe ich auch noch ein wenig verändert, wobei mich deine function newtoolbar_extern_SMg auf eine Idee gebracht hat. Wie du sehen kannst habe ich jetzt eine Liste von Smilies, so könnte man eine Variablen übergeben die eine Gruppe von ausgewählten Smilies erstellt. (momentan habe ich eine statische, hach ich liebe die diese Dinger) Vorlage:Smiley/Wartung/:d  Beste Grüße -- Perhelion 19:35, 8. Jul. 2010 (CEST)

Eigentlich wollte ich ja den allgemeinen Teil auslagern, aber irgendwas funktioniert nicht und ich bin gerade nicht in der Stimmung zu schauen, was es ist (wenn es bei dir in Commons klappt, Benutzer:Schnark/toolbar-basic.js einzubinden, kannst du das trotzdem tun). TT gibt es inzwischen auch

und auch ich wegen der toolbar

Betreffs: Wikipedia:Usability-Initiative/Feedback#Bearbeitungsoberfläche mit weit auseinanderliegenden Werkzeugleisten

Hallo Schnark, vielen dank für deine Antworten und die Lösungsvorschläge dazu! Wollte die auch mit größter Vorfreude ausprobieren, nur stieß ich da an die Grenzen meiner Programmier"kenntnisse". Vor Urzeiten war mir mal Turbo Pascal 6.0 und html ein bisschen geläufig, aber leider vieles wieder vergessen und von .css oder .js hab ich Null Ahnung. An vielen Stellen wird in Wikipedia über monobook oder vector gesprochen, im sinne von "ja, dass musst du nur in dein monobook.js (oder vector.css oder doch .js:|) einbauen", aber wie das so richtig geht oder wie so ein Standard Aufbau eines .css oder .js aussieht, hab ich nirgends gefunden. Was ist überhaupt der Unterschied? Bisher hatte ich damit nur einmal zu tun, und zwar als ich danach gesucht hatte, wie man Admins kenntlich machen kann. Inzwischen hab ich zwar rausgefunden, dass es dafür ausgereicht hätte, in meinen Einstellungen ein Häkchen zu machen. Damals wusste ich das allerdings nicht. Hatte schließlich ein Modul von Benutzer:PDD gefunden. Da ich noch kein monobook hatte, hab ich das neu angelegt. (siehe hier) Das hat funktionier, aber wie/warum? Wie kann es sein, dass mein monobook nur aus einem Modul besteht und trotzdem mein wikipedia wie ein komplettes monobook aussieht.

Meine Idee/Vermutung dazu: zuerst schaut der Browser, welches skin hat Benutzer gewählt, anschließend lädt er von einer zentralen Stelle das Original-Skin und schaut nach, ob der Benutzer noch eine eigene Seite/Datei mit gleichem Namen hat. Wenn ja, dann schaut er, ob es da eine andere Versionen von Modulen der Originalversion gibt. Wenn ja, dann benutzt der Browser diese anstelle der gleichnamigen in der Originalversion.

Das ist jetzt einfach mal so meine Vorstellung von einer Sache, die funktionier, ich aber nicht weiß wie. Nach dieser Theorie müsste es doch Regeln geben, wie dann die einzelnen Module in meinem monobook oder vector von einander zu trennen sind damit der Browser sie erkennt, oder? Da ich das aber nicht weiß, hab ich einfach dein Script von der Feedbackseite zu meinem Admin-Mark-Modul in meinem monobook.js kopiert. (siehe hier) Das hat nicht funktioniert (davor natürlich Cache geleert und Firefox neugestartet). Somit überlegt: Hmm..., du schreibst "in der eigenen monobook.css (bzw. vector.css oder welches Skin auch immer)". Ich habe monobook.js. Etwas weiter oben auf der Feedback seite bietest du ein Script für vector.js an. Ist das vielleicht das richtige für mich? Wonach muss ich gehen, um das rauszufinden. (also das vector.js für mein monobook.js oder das monobook.css für mein monobook.js) Ich hab schließlich auch das andere ausprobiert (siehe hier) Aber hat leider auch nicht geklappt. Was hab ich falsch gemacht? Kannst du mir helfen? LG --W like wiki 10:59, 3. Jul. 2010 (CEST) PS.: Um meine grundlegenden Verständnisfragen zu klären, müsste man vermutlich etwas weiter ausholen. Wenn du dir das sparen willst und dazu einen passenden Link hättest, wäre mir auch sehr sehr weitergeholfen. Ich danke vielmals! PS2.:Ich vermute ja, dass ich etwas mit den geschweiften Klammern nich richtig gemacht habe, nur ein die am ende schließt aber keine die am Anfang öffnet? --W like wiki 10:59, 3. Jul. 2010 (CEST)

Hallo W like wiki! Da das alles ein bisschen kompliziert ist, versuche ich mal in der Reihenfolge zu antworten, in der deine Fragen stehen.

Der Unterschied zwischen CSS und Javascript riesig, da die beiden eigentlich kaum etwas miteinander zu tun haben: CSS gibt Regeln an, wie dein Browser ein bestimmtes Element darstellen soll, Javascript ist eine Programmiersprache, die ausgeführt wird, wenn die Seite geladen wird.

Dass du damals diese Funktion nicht unter den Helferlein gefunden hast, liegt nicht an dir, sondern daran, dass es diese Funktion dort erst seit ein paar Wochen gibt. Wenn du dort das Häkchen setzt, funktioniert es, egal welchen Skin du verwendest.

Ein Modul aus PDDs Monobook ist einfach nur eine Funktion, die etwas bestimmtes macht, in diesem Fall alle Administratoren zu markieren. Indem du dir den entsprechenden Code kopiert hast, hast du einfach diese Funktionalität hinzugefügt, ohne dass dabei etwas anderes verloren ginge.

Deine Vermutung (2. Absatz) ist im Prinzip völlig richtig, nur ist es nicht dein Browser, der nachschaut, welche Seiten gültig sind, sondern die Software, mit der Wikipedia läuft. Und wie ich bereits oben schrieb, gibt es kein Standardmodul, das Admins markieren würde, sodass diese Funktion nicht irgendeine Originalversion überschreibt, sondern einfach nur ergänzt.

Es werden also alle Funktionen, die in deiner js-Datei stehen ausgeführt, und alle Darstellungsregeln aus deiner CSS-Datei angewendet.

Der Code

importScript('Benutzer:Schnark/toolbar.js'); //importiert [[Benutzer:Schnark/toolbar.js]]
function newtoolbar_config() { //<nowiki>
  newtoolbar_addSection('SZ');
} //</nowiki>

gehört damit in die js-Datei, die zu dem Skin gehört, das du verwendest. Wenn du nach der Umstellung nicht auf den Monobook-Skin zurückgestellt hast, verwendest du jetzt den Vector-Skin, sodass der Code in vector.js gehört (einfach neu erstellen). Am einfachsten findest du die richtige Seite, wenn du in deinen Einstellungen im Reiter Aussehen hinter dem gewählten Skin auf Benutzerdefinierte JS klickst.

Die Regel

#editpage-copywarn, .mw-tos-summary {display:none; }

kannst du natürlich auch verwenden, dies ist eine CSS-Regel, die folglich in deine CSS-Seite gehört (auch dort ist es wieder am einfachsten, über die Einstellungen zu gehen und dann hinter deinem SKin auf Benutzerdefinierte CSS zu klicken).

Viele Grüße --Schnark 09:36, 5. Jul. 2010 (CEST)

Hallo Schnark, vielen vielen Dank für deine ausführliche Antwort. Alles klar (zumindest fast:). Hast mir das wesentliche sehr gut erklären können, hab jetzt nen groben Überblick über die Lage. Bin ich der einzige, dem es so ging? Ich fände das deine kompakte Zusammenfassung/Erklärung für Einsteiger auf der Seite WP:SKIN oder WP:SET#Aussehen eine gute Ergänzung wäre. Zur Zeit beschränkt sich die Erklärung hier auf den Verweis auf die dafür viel zu ausführlichen WP-Artikel JavaScript und CSS. Aber das nur nebenbei.

Habe noch mal mein monobook.js überprüft, allerdings befindet sich die wiki-syntax zeile immer noch so weit unten wie früher. Daraufhin hab ich das Admin-Mark-Modul von PDD entfernt (hab ja den Haken in meinen Einstellungen) und jetzt nur noch deine toolbar darin. Klappt allerdings auch nicht. Was mach ich falsch? Könntest du bitte noch mal helfen und evtl. nen blick auf meine .js werfen. Ich danke!!--W like wiki 20:28, 8. Jul. 2010 (CEST)

Hey W like wiki, im monobook Skin funzt das Script nicht du musst es daher hierhin kopieren s|deine vector.js -- Perhelion 20:41, 8. Jul. 2010 (CEST)

Signaturanzeige

Hallo Schnark, ich habe mich bei deiner vector.css bedient. Verbindlichsten Dank! Stefan64 13:21, 17. Jul. 2010 (CEST)

OnLoad – Das Event.

Oben ist von uns einiges etwas verkürzt und deshalb teilweise nicht ganz richtig dargestellt worden.

Um es auch später mal ausschlachten zu können (vielleicht schreiben mir zwoa Experten mal was für den ANR, sonst Hilfe:), hier vollständig:

• Mit Erreichen des </BODY> wird das Load-Event des Dokuments ausgelöst. (Genauer: Mit Erreichen des </HTML>, aber was zwischen </BODY> und </HTML> steht, ist nicht syntaxkonform und das Verhalten nicht vorhersagbar.) Das ist schon so, wie ich es ursprünglich geschrieben hatte.
• Zwischendurch wird nach und nach von <BODY> bis </BODY> das DOM populiert.

  Das lässt sich auch mit einer lokalen HTML-Datei experimentiell erproben (geht nicht mit Wikitext; zur Vermeidung von böswilligem Cross Site Scripting wird das vom Wikiparser unwirksam gemacht).

  <BODY onLoad="....message... 'Body.onLoad' ....">

  <SCRIPT>.....message... 'Hello World' ....</SCRIPT>

  <DIV>Dies und das</DIV>

  <IMG src="1.gif" onLoad="...message...1" />

  <SCRIPT>.....message.Y ... document.images.length ...</SCRIPT>

  <IMG src="2.gif" onLoad="...message...2" />

  <SCRIPT>.....message.Z ... document.images.length ...</SCRIPT>

  </BODY>

• Das DOM wächst dabei jeweils mit dem eingelesenen HTML-/XHTML-Quelltext mit.
• Im </HEAD> ist zwar die Existenz von document garantiert, weil es Komponente von window ist, aber document darf auch null sein. Es mag sein, dass FF 3.6 dies schon mit einer leeren Struktur (etwa document.images[]) belegt, aber darauf besteht keinerlei Rechtsanspruch. Dies darf erst nach Erreichen von <BODY> erwartet werden.
• Nach dem </BODY> werden über die benutzerdefinierten OnLoad-Funktionen mögicherweise Änderungen des bis dahin eingelesenen DOM vorgenommen (wie das auch schon vorher mittels <SCRIPT> möglich war).

  Deine Änderungen (Knöpfe) fügen dem DOM weitere Knoten hinzu, also zunächst Spezifikationen.

• Nachdem mit Abarbeitung des Load-Event keinerlei Änderung am DOM mehr möglich ist, erfolgt die Umsetzung des DOM als optische Darstellung (HTML-Rendering).
• Die Darstellung beginnt oben im Fenster-Bereich, also dem, was ein Benutzer normalerweise als Erstes zu sehen bekäme.
• Für das Layout der Gesamt-Seite reicht es aus, wenn zunächst die Breite, dann die Höhe eines externen Elements bekannt ist. Wird dies explizit als Größe von Bildern in Pixel oder als Breite einer Tabellenspalte in der HTML-Quelle bzw. dem DOM angegeben, muss das Bild unten noch nicht geladen sein, während oben schon der Tabellenkopf dargestellt wird; es wird ein rechteckiger Dummy-Bereich ausgespart.
• Parallel zu jedem <IMG> oder <OBJECT> usw., das in das DOM eingefügt wird, versuchen moderne Browser (seit 15 Jahren) einen parallelen Prozess zu starten.
  • Dabei wird versucht, die Ressource in der lokalen Cache-Basis zu finden, ansonsten ein Versuch gestartet, dies an der URL zu laden. Dabei können beliebig limitiert viele Verbindungen mit Webservern parallel unterhalten werden.
  • Gängige Bildformate (GIF, JPEG etc.) enthalten in den ersten 100 Byte die Breite und Höhe in Pixel, so dass schon nach Übertragen des ersten halben kB dies in das DOM für fehlende Größenangabe eingetragen werden und die optische Darstellung der Seite ggf. fortgesetzt werden kann.
  • Jedes Bild hat ein eigenes Load-Event, das die vollständige Übertragung (hier: und Darstellung) oder aber das endgültige Fehlschlagen – OnError() – bekannt gibt.
• Die Vollendung der optischen Darstellung der Seite wird nicht durch ein On...Event bekanntgemacht.
• Obwohl JavaScript alle Events allgemein als window.onLoad definiert, ist es für HTML/XHTML-Quellen an den <BODY> des document geknüpft – das selbst keine events hat. Das Verhalten bei eingebetten Ressourcen (wie Bildern) unterscheidet sich davon.
• Mit sauberem HTML4.strict kann für IMG kein Load-Event definiert werden, wohl aber mit JavaScript. Gleichwohl funktioniert seit mehr als zehn Jahren bei allen mir geläufigen Brausern (Mozilla und IE) sowohl onLoad wie auch onError – siehe obiger HTML-Beispielcode.
• Das Verändern der Fensterbreite erfordert ein neues Seitenlayout auf Basis des vorhandenen DOM. Ein Load-Event des Dokuments wird dabei nicht ausgelöst, wohl aber das window.onResize.
• Das Verändern eines DOM bewirkt nach Abarbeiten aller Events immer auch eine neue Visualisierung (Rendering) – zumindest sollte es das, aber IE hatte da früher auch schon mal geschwächelt. Ein Event gibt es dafür in HTML/JavaScript nicht, wohl aber in Java.

Schönes Wochenende --PerfektesChaos 22:33, 23. Jul. 2010 (CEST)

Irgendwie sind wir uns ständig uneins darüber, wann body.onload dran ist: The DOM Implementation finishes loading the resource (such as the document) and any dependent resources (such as images, style sheets, or scripts). [1] In folgender Beispieldatei:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head><title>titel</title></head>
<body onload="alert('body.onload');">
<img src="http://upload.wikimedia.org/wikipedia/commons/e/e5/Alberto_Contador_Paris-Nice_2007.jpg" onload="alert('img.onload');" />
</body>
</html>

wird demnach auch völlig zurecht erst img.onload ausgegeben, und erst anschließend body.onload. IE wartet dabei mit der Bildanzeige so lange, bis man das alert-Fenster wegklickt, FF zeigt das Bild bereits im Hintergrund an. --Schnark 09:43, 26. Jul. 2010 (CEST)

Problem mit toolbar

Hallo Schnark, ich weiß nicht genau, wann es passiert ist, da ich eine Woche Wikipause hatte, aber seit Sonntag kann ich mit Firefox 3.0 keine Wikipediaseiten mehr editieren. Beim klicken auf Bearbeiten fängt der Browser an zu laden und hört nicht mehr auf. Nach Deaktivieren deiner Tollbar funktioniert alles wieder. Hast du eine Ahnung, woran das liegen könnte? Ich werde aber auf jeden Fall mal meinen Firefox aktualisieren. Grüße --Bjs 09:25, 14. Jul. 2010 (CEST)

Mushushu hat die selben Probleme wie du, allerdings weiß ich nicht, woran es liegen könnte, bei mir (FF 3.6.2 unter Windows und FF 3.0 unter Linux (an einem alten Browser liegt es also vermutlich nicht)) läuft alles problemlos. Du könntest einfach eine alte Version verwenden, indem du das importScript durch ein importScriptURI('http://de.wikipedia.org/w/index.php?title=Benutzer:Schnark/toolbar.js&oldid=76572166&action=raw&ctype=text/javascript'); ersetzt und dabei einfach mal alle alten Versionen durchprobierst. Auf diese Art findest du vielleicht auch die problematische Änderung. --Schnark 09:41, 14. Jul. 2010 (CEST)

Der Fehler ist bei mir bewusst vor 2 Tagen aufgetreten (Ich benutze Chrome und FF Beta) Ich vermute nur mal es könnte daran liegen wie du die Toolbar initialisierst. Momentan wohl im laufenden Aufbau der Seite, so habe ich z.B im lokalen Test die Toolbar 3fach. -- Perhelion 12:20, 14. Jul. 2010 (CEST)

Ich möchte in diesem Fall nochmal als Beispiel auf den alten (bewehrten hier) Code hinweisen:

if ((wgAction=="edit") || (wgAction=="submit"))
        addOnloadHook(initButtons);
if(!wgIsArticle) // only if edit
	hookEvent("load", extendButtons);

-- Perhelion 12:38, 14. Jul. 2010 (CEST)

Mir ist gerade eingefallen, ich hatte Sonntag doch ein paar Edits gemacht von 18:38 bis 18:44, danach ging nichts mehr. Vielleicht hilft die info auch, den Fehler einzukreisen. Grüße --Bjs 13:05, 14. Jul. 2010 (CEST)

Ich muss auch noch ergänzen dass der Fehler nicht bei Chrome oder IE(8) auftritt. Eventuell was mit der jQuery. -- Perhelion 21:20, 14. Jul. 2010 (CEST)

Mit deinem anderen Workaround scheint es wieder zu funzen, hier [2] -- Perhelion 21:42, 14. Jul. 2010 (CEST)

Ich hab nur mal nen Debugger (Firebug) laufen lassen, im FF zeigt er in deinem Script bei Zeile 64 (xmlHttp.send(null);) ein Fehler und das b is undefined?!? Oder wohl der Fehler: document.body is null Quelldatei: http://bits.wikimedia.org/skins-1.5/common/jquery.min.js?283l Zeile: 318 Gute Nacht erstmal. -- Perhelion 22:16, 14. Jul. 2010 (CEST)

Ich habe den Aufruf des Skripts jetzt von der jQuery-Methode auf hookEvent umgestellt, vielleicht funktioniert das. Eigentlich wollte ich addOnloadHook verwenden, das tat aber einfach gar nichts (zumindest bei mir). Probiert also einfach mal aus, ob es jetzt funktioniert. (@Perhelion: Bei dir wird das erst eine Änderung bewirken, wenn du newtoolbar_delay wieder rauswirfst.)

Dass im lokalen Test einiges dreifach erscheint, ist kein Bug, sondern zeigt einfach nur, dass man niemals zwei Leisten der Toolbar den gleichen Namen geben sollte: FF speichert nicht den ursprünglichen Quelltext, sondern den per JS modifizierten, also ist bei dir die Leiste "Alle" mit der (unsichtbaren und automatischen) Gruppe "insert" bereits vorhanden. Wird das Skript jetzt ein zweites Mal aufgerufen, so wird eine zweite Leiste "Alle" eingefügt (die du niemals öffnen kannst, da immer die erste Leiste geöffnet wird), in alle Leisten mit dem Namen "Alle" eine Gruppe "insert" (die erste Leiste hat jetzt diese Gruppe doppelt), und in alle insert-Gruppen von Alle-Leisten die Buttons (das ergibt die 3 Mal).

Zu dem Fehler, den xmlHttp.send(null); erzeugt kann ich mich nur wundernd am Kopf kratzen, erstens sollte die Funktion _getstandardbar im Normalfall gar nicht aufgerufen werden, und außerdem steht die Anweisung innerhalb eines try-Blocks, sodass der Browser jeglichen Fehler ignorieren sollte. Wenn aber schon jQuery Fehler verursacht, kann man wohl nicht erwarten, dass mein Skript fehlerfrei läuft. --Schnark 09:38, 17. Jul. 2010 (CEST)

Mahlzeit, das Wetter ist herrlich, endlich mal Regen nach den Hundstagen, da ist Wohnung und Computer auch mal schön.

Ich habe die Diskussion, die Fehlermeldungen und die Experimente am Skript mitgelesen und erlaube mir, ungefragt zur Lösung beitragen zu wollen.

Nach erster Durchsicht scheint es mir am geeignetsten, den prozeduralen Ablauf darzustellen, weil du pfiffig genug bist, um dann selbst die erforderlichen Schritte vorzunehmen.

1. Wiki-Seite wird vom Benutzer aufgerufen; wikibits.js wird geladen und und und.
2. monobook/vector.js wird abgearbeitet, importScript/importPage merkt weitere Skripte vor.
3. Nach Abarbeitung ggf. weiterer wikimedia-Skripte werden die unter importScript/importPage vorgemerkten Skripte gestartet, hier z.B. toolbar.js.
4. toolbar.js wird gestartet. Es empfiehlt sich, an den Schluss eine Zeile toolbar_AutoRun(); zu setzen; alles andere außer Definition globaler Variablen sollte in function{} eingeschlossen sein.
5. function toolbar_AutoRun() {......} wird gestartet. Es darf keinerlei Aktivitäten enthalten, die Bezug auf den Dokument-Inhalt nehmen, sondern nur z.B. Aufrufe von addOnloadHook(....); sowie interne Berechnungen.
6. Nach Abarbeitung aller dieser Skripte wird das eigentliche HTML-Dokument geladen, genauer gesagt der document.body oder in der Datei <BODY>.....</BODY> – jetzt werden alle <div> und <form> definiert.
7. Nachdem dieses Dokument (erst- und einmalig) geladen ist, tritt das OnLoad-Event ein, und die unter addOnloadHook() vorgemerkten Hook-Aktivitäten werden ausgeführt. Dieses können jetzt Funktionsaufrufe innerhalb von toolbar.js sein, die Elemente im document.body modifizieren.

Die Fehlermeldung document.body = null kommt in zwei Situationen zustande:

• Browser ist doof und 15 Jahre hinterm Mond; extrem selten und hier auszuschließen.
• toolbar.js hat zum Zeitpunkt seines Ladens Elemente des document.body angefasst; diese sind aber noch nicht bekannt.

Dies als Hilfe und kleinen Ausgleich für gelegentich durch mich verursachtes Ungemach. Mahlzeit --PerfektesChaos 12:38, 17. Jul. 2010 (CEST)

<quetsch> Nr. 7 stimmt so nicht, die Programmierer hatten da seltsame Vorstellungen von Namenskonventionen: addOnloadHook() hat nichts mit dem load-Event zu tun, die addOnloadHook-vorgemerkten Funktionen werden durch ein Skript direkt vor dem </body-Tag aufgerufen, also noch im Schritt 6. Schritt 6,5 ist dann das Ende des Einlesens der HTML-Datei und das damit verbundene Abfeuern des DOMContentLoaded-Events (oder etwas Äquivalentes im IE). Dies lässt alle Funktionen ablaufen, die per $j(funktion); vorgemerkt wurden, insbesondere der Aufbau der Toolbar gehört dazu. Anschließend folgt in Schritt 7 das load-Event.

Durch die Implementation von addOnloadHook sind also Probleme mit jQuery vorprogrammiert, allerdings sollte zumindest meiner Vorstellung nach document.body bereits dann ungleich null sein, wenn das öffnende Tag eingelesen wurde. --Schnark 09:32, 19. Jul. 2010 (CEST)</quetsch>

<auchquetsch>

Du meinst die von der Skin unmittelbar vor dem </body> eingefügte Zeile

if (window.runOnloadHook) runOnloadHook();

Für vector und monobook ja; ansonsten wirkt die fast letzte Zeile von wikibits.js

hookEvent('load', runOnloadHook);

Wirkt über ->hookEvent() ->addHandler() ->addEventListener() == DOM standard-Funktion auf das Load-Event.

->runOnloadHook()

onloadFuncts[] ausführen

Beide Aktionen führen zum Ziel, die Zeile unmittelbar vor </body> sowie das Load-Event, das mit Erreichen von </body> passiert.

Gedacht ist eigentlich die Auslösung über das Load-Event -- weil es mit diesem aber besonders beim IE6 Probleme gab und nicht sauber DOM-konforme Safari-Opera-Mobiltelefon-wasweißichfürBrowser das Load-Event vielleicht nicht richtig auslösen, hatten unsere trickreichen Entwickler in die bekannten großen Skins später ein Pseudo-Load-Event durch expliziten Aufruf von runOnloadHook gesetzt. doneOnloadHook verhindert die zweimalige Ausführung.

runOnloadHook() würde ich aber deiner Lektüre anempfehlen, da stehen so komische Funktionen drin, die irgendwas mit GUI zu tun haben und dich vielleicht beeinflussen.

Unabhängig davon ist document.body erst am Ende populated, die verschiedenen Element-Arrays in document am Anfang leer oder gar null.

Wenn es nicht zwingend nötig ist, besonders komfortable jQuery-Features zu nutzen, würde ich persönlich darauf verzichten; es macht die Sache sonst störanfälliger und undurchsichtiger, vor allem in anderer Leute Browser, Betriebssystemen und Skins, und verursacht mehr Extra-Arbeit als Nutzen.

Mahlzeit --PerfektesChaos 13:15, 19. Jul. 2010 (CEST)</auchquetsch>

*noch mal widersprech*: Das load-Event wird erst ausgelöst, wenn alles da ist, insbesondere erst nachdem auch alle Bilder geladen sind. Da also eigentlich immer der runOnloadHook() im HTML schneller ist, ist die Reihenfolge: addOnloadHook(foo), $j(foo), hookEvent("load", foo). (Auch experimentell bestätigt.) Die neue Toolbar wird durch eine Funktion erzeugt, die über $j() aufgerufen wird, sodass addOnloadHook zu früh kommt. Wenn jQuery nicht das tut, was es soll, wird die neue Toolbar sowieso nicht funktionieren, sodass es in diesem Fall keine zusätzlichen Probleme bereiten kann.--Schnark 09:38, 21. Jul. 2010 (CEST)

*zugesteh*

1. Deine Beschreibung des Endruns ist korrekt.
2. Unter „Problem bereiten“ verstehe ich auch, dass die gewünschte Funktion nicht ausgeführt wird – nicht nur, dass der Seitenaufbau abstürzt.
3. Für konventionelle, direkt auf DOM zugreifende Programmierung von Toolbars ist es hinreichend, wenn auf die eine oder andere Weise runOnloadHook() die Modifikation auslöst.
4. Mit jQuery habe ich nicht gearbeitet – bin auch wenig gewillt, dies zu tun; zu Wikimedia-spezifisch für mich, und noch nicht so goldig dokumentiert.
5. Initialisiert wird jQuery(.js) unmittelbar nach wikibits.js, ist also den Benutzerskripten schon bekannt.
6. Gleichwohl sollte man die jQuery-Welt nicht mit der konventionellen Welt vermischen; ich sehe zwar zurzeit keine spezifischen zusätzlichen Gefahren in $j(), aber die können sich irgendwannmal ergeben. Also entweder DOM und addOnloadHook() oder jQuery und $j(); saubere Trennunng vermeidet ewige Fehlersuche in fremden Browsern auf wildfremden PC. Das machst du ja wohl auch.

Ich denke, du stehst im Stoff; Mahlzeit erstmal --PerfektesChaos 12:27, 22. Jul. 2010 (CEST)

Bei mir funktioniert es jetzt wieder. Grüße -- Bjs 16:16, 17. Jul. 2010 (CEST)

Aber nur 2-3 mal, jetzt hängts wieder :-( -- Bjs 16:20, 17. Jul. 2010 (CEST)

Um das Problem einzugrenzen: An welcher Stelle genau hängt es? Beim Aufruf einer Bearbeiten-Seite sollten folgende Dinge passieren:

1. Die Titelleiste des Browsers zeigt "Bearbeiten von..." an, die Seite selbst ist komplett leer.

2. Die Seite erscheint, noch ohne die Toolbar.

3. Die Toolbar erscheint.

4. Die Toolbar wird mit deinen benutzerdefinierten Wünschen gefüllt.

Bei welchem dieser Schritte ist das Problem? --Schnark 09:32, 19. Jul. 2010 (CEST)

Ganz am Anfang, noch bevor die Seite geleert wird. Es bleibt also die Seite stehen, bei der ich auf Bearbeiten geklickt habe. --Bjs 11:55, 19. Jul. 2010 (CEST)

Eine wirkliche Idee habe ich keine, aber ersetze einfach einmal das importScript('...'); durch importScriptURI('http://de.wikipedia.org/w/index.php?title=Benutzer:Schnark/toolbar.js&oldid=76072402&action=raw&ctype=text/javascript'); oder importScriptURI('http://de.wikipedia.org/w/index.php?title=Benutzer:Schnark/toolbar.js&oldid=76260441&action=raw&ctype=text/javascript');. Das sind ältere Versionen. --Schnark 12:11, 19. Jul. 2010 (CEST)

Funktioniert mit beiden. Grüße --Bjs 21:01, 19. Jul. 2010 (CEST)

Dann äußere ich mal einen konkreten Verdacht: Funktioniert es, wenn du wieder über importScript('Benutzer:Schnark/toolbar.js'); die aktuelle Versionen verwendest, und du die fehlerhafte Zeile newtoolbar_addSelect('main', 'sig'); durch newtoolbar_addButton('main', 'sig'); ersetzt? --Schnark 09:38, 21. Jul. 2010 (CEST)

Bingo! So gehts's, vielen Dank. --Bjs 22:17, 23. Jul. 2010 (CEST)

:-( Wie letztes mal: Gestern Abend gingen ein paar Edits, heute nicht mehr. Gestern gab es auch einen Unterschied zwischen bearbeiten der ganzen Seite, was sofort aufging, und Abschnitt bearbeiten, was lange dauerte. Auch heute gab es einen Unterschied: Bearbeiten der Seite zeigte zuerst eine weiße Seite und hing dann, Abschnitt bearbeiten hing gleich, solang noch die alte Seite angezeigt wurde. Bearbeiten von Vector.js ging aber ohne Probleme. Grüße -- Bjs 10:24, 24. Jul. 2010 (CEST)

Nach einmal hin- und hereditieren gehts jetzt wieder, vielleicht Cache-Probleme? Ich werd noch ein bisschen rumexperimentieren.-- Bjs 11:17, 24. Jul. 2010 (CEST)

nein, auf Dauer funktioniert das so nicht. ich habe wieder auf diese Version zurückgesetzt, gibt es eine jüngere, die ich probieren könnte? -- Bjs 17:42, 26. Jul. 2010 (CEST)

Ich habe die Änderungen, die ich vorgenommen habe, jetzt in drei einzelne Skripte aufgeteilt, teste bitte mal, welche der folgenden Skripte funktionieren: importScript('Benutzer:Schnark/toolbar-return.js'); funktioniert -- Bjs 08:18, 15. Aug. 2010 (CEST)
importScript('Benutzer:Schnark/toolbar-code.js'); hängt sich auf -- Bjs 10:42, 15. Aug. 2010 (CEST)
importScript('Benutzer:Schnark/toolbar-init.js');
--Schnark 09:40, 27. Jul. 2010 (CEST)

Ich hatte gestern und heute zum ersten Mal selber die beschriebenen Probleme, allerdings nur vereinzelt, und nach dem Leeren des Caches war wieder alles in Ordnung. Ich werde aber die nächste Woche nicht da sein, danach auch nur sporadisch, sodass ich der Sache im Augenblick nicht weiter nachgehen kann. --Schnark 12:23, 29. Jul. 2010 (CEST)

Hat ja Zeit, mit der alten Version funktionierts ja, ich bin auch noch nicht dazu gekommen, die anderen Skripte auszuprobieren, werds wahrscheinlich am Wochenende machen. Grüße -- Bjs 17:02, 29. Jul. 2010 (CEST)

Soweit ich es inzwischen sehen kann, liegt das Problem irgendwo beim Nachladen der Standardknöpfe. Warum die Probleme machen, weiß ich nicht, du verwendest sie nichteinmal und geändert habe ich daran auch nichts. Aber die Methode, die ich bisher verwende, gefällt mir sowieso nicht, also werde ich mir Gedanken über eine Alternative machen und die dann programmieren, sobald ich wieder da bin. --Schnark 11:38, 7. Aug. 2010 (CEST)

---

Was das genaue Problem ist (bzw. hoffentlich: "war"), weiß ich noch immer nicht, aber es scheint wohl Folgendes der Fall zu sein:

• In einer Version des Skripts habe ich eine Möglichkeit hinzugefügt, auch die Schaltflächen zu verwenden, die standardmäßig vorhanden sind, und dabei auf einen (positiv ausgedrückt) sehr trickreichen Mechanismus zurückgegriffen, der offensichtlich manchmal funktioniert, aber hin und wieder irgendwelche Probleme in Verbindung mit dem Browsercache verursacht. Das störte so gut wie niemand, da die entsprechende Funktion nur bei Bedarf aufgerufen wurde.
• Durch einen Rechtschreibfehler wurde in einer späteren Version des Skripts diese Funktion versehentlich immer ausgeführt, was dann ein Problem für alle bedeutete.
• Diese Funktion habe ich nun komplett ersetzt, die Funktion wird zwar weiterhin immer ausgeführt (auch wenn sie nicht benötigt wird), dies sollte aber nun keine Probleme mehr verursachen.
• Wer eine alte oder andere Version des Skripts verwendet, kann wieder auf die normale Version umstellen.
• Ich bedanke mich bei allen für ihre Geduld mit meinem Skript.
• Wenn weitere Probleme auftreten, werde ich natürlich auch versuchen, diese zu beheben, ich bin aber wieder nur für ein paar Tage da, um dann gleich wieder in computerlose Ferien (so was ähnliches zumindest) zu verschwinden. --Schnark 09:27, 20. Aug. 2010 (CEST)

Alles bestens jetz, vielen Dank -- Bjs 13:59, 24. Aug. 2010 (CEST)

Wer ist da?

Hallo Schnark. Ich habe mal vor nicht so langer Zeit deinen Script Benutzer:Schnark/letzteredit.js im monobook ausprobiert, fand ich gut. Jetzt sehe ich, dass er in meinem vector.js nichts tut (man kann ja einiges von monobook auch im vector verwenden, einiges nicht, denke ich). Hast du möglicherweise irgendwo eine Anpassung für vector? Erstmal Gruß, -jkb- 23:14, 19. Jul. 2010 (CEST)

*fluch* es funzt plötzlich. Vielleicht brauchte es Zeit sich im neuen .js heimisch zu machen. Also erledigt und danke trotzdem, -jkb- 23:19, 19. Jul. 2010 (CEST)

WP:Cache? --Schnark 09:38, 21. Jul. 2010 (CEST) Ich habe mir erlaubt, oben ein nowiki-Tag zu ergänzen, bin selber gerade darübergestolpert.

Ja, wohl so. Das Sternchen habe ich auch gleich gesehen, wollte deshalb aber nicht editieren. Also, danke. -jkb- 09:43, 21. Jul. 2010 (CEST)

- - - - -

Ich bin's nochmals. Ich bekam die Idee, ob dein Script auch auf anderenProjekten funktioniert - dauernd sehe ich ja, dass sich Leute ihre globalen Scripte überall reinpflanzen lassen. Auf der Oldwikisource (oldwikisource:User:-jkb-/monobook.js) versuchte ich ein paar Varianten

importScript(':w:de:Benutzer:Schnark/letzteredit.js');
importScript('http://de.wikipedia.org/wiki/Benutzer: ... .js');
importScriptURI('http://de.wikipedia.org/wiki/Benutzer: ... .js');
importScriptURI('http://de. ... .js&action=raw&ctype=text/javascript');

aber ohne Erfolg. Enthält der Script doch welche de.wiki-spezifische Teile oder wo ist der Fehler zu suchen? Danke für die Mühe, -jkb- 16:23, 31. Jul. 2010 (CEST)

Das Skript enthielt einen de-spezifischen Teil, den ich gerade ausgetauscht habe. Nach dem Leeren des Caches sollte es funktionieren. Sei dir aber immer bewusst, dass ich keine Ahnung habe, was bei verschiedenen Zeitzonen geschieht. --Schnark 09:16, 7. Aug. 2010 (CEST)

Prima. Ich habe dann versucht es irgendwie zu importieren, irgendwo war da ein Fehler, also habe ich mit Verlaub das Script dort installiert (oldwikisource:User:-jkb-/active.js) mit Quellenangaben usw. und es läuft. Daher danke für die Mühe! Gruß -jkb- 17:02, 14. Aug. 2010 (CEST)

- - -

Danke! -jkb- 09:55, 8. Sep. 2010 (CEST)

Danke schön + PDfix news

• Ich wähnte dich in computerferner environment und wollte dich nicht belästigen, sonst hätte ich eine Kurzinfo zu 1.2 gegeben – mich hat aber wohl ein watchdog verbellt.
• Komma ohne Leerzeichen
  Die Idee entsprang schon vor längerer Zeit mal PD#14, aber Dr. Scissors und Stiletto (Künstler) hatte ich nicht mehr präsent, als ich kürzlich jemand beim PDfix in einer KURZBESCHREIBUNG sah und daraufhin den RegExp einfügte.
  • Dazu denke ich jetzt an je zwei Zeichen, die weder Ziffer noch Leerzeichen sein dürfen, sowohl links wie auch rechts vom Komma
  • für alle Felder.

  Würde dies deiner Erfahrung nach ein sicherer Weg sein?

  • Mit 1.3 noch ergänzt um Leerzeichen vor dem Komma sowie um zwei Kommata in Folge.
• Ein Punkt am Ende wird mit der gebotenen Vorsicht (Sängerin bei Boney M.) entfernt.
• Weiterhin Leerzeichen nach Semikolon, sofern nicht Entity (von denen ja eh’ kaum was übrig blieb), in ALTERNATIVNAMEN und KURZBESCHREIBUNG
• Kurzbeschreibung ohne Leerzeichen vor der Klammer
• low priority gibt noch viele denkbare RE-Anregungen, die ich nach und nach einzuarbeiten beabsichtige, sobald ich sie verstanden habe.
• Aus einem ganz anderen Grund gibt es aber bald die 1.3 auch mit diesem verfeinerten PDfix.
• Übrigens bin ich jetzt auch unter die Knöpfchenbastler gegangen, ToolboxAddItems liefert dir ein Backlink vom Artikel zurück zum PDfix-Detail.

Sonniges Gemüt wünscht --PerfektesChaos 23:00, 23. Aug. 2010 (CEST)

• zu Kommata: es wird sicher irgendwann einen Künstler geben, der meint sich ab,ab nennen zu müssen, aber solange der nicht relevant ist, muss man sich darum keine Gedanken machen. Er wird sowieso in der Fehlerliste auftauchen, dann ist immer noch Zeit dafür sich über ein differenzierteres Vorgehen Gedanken zu machen. Von meiner Seite also grünes Licht für all die Kommakorrekturen.
• zu Punkten: Kann es sein, dass der RegExp auch auf "jun." und "sen." anschlägt? Bei Alternativnamen sehe ich sowieso keinen Grund, warum versehentlich ein Punkt am Ende stehen könnte, das passiert eigentlich nur in der Kurzbeschreibung, wo er evt. nach C&P aus der Einleitung stehen bleibt. (Falls jemand Sänger bei einem Junior war, müsste die Anzahl der Nicht-Whitespaces vielleicht auch hier auf 4 hochgesetzt werden.) Viele Grüße --Schnark 10:32, 8. Sep. 2010 (CEST)

Danke schön, Quelltext bereits offline geändert wie folgt:

• Punkt nur noch nach Kurzbeschreibung und nach 4× non-whitespace entfernt, jun. und sen. sind jetzt sicher.

Bei Alternativnamen habe ich schon ein nach Aufräumerei vergessenes schließendes Semikolon gesehen; auch die anderen Satzzeichen zusammen mit der Kurzbeschreibung ggf. mit zu entfernen, ist kein Akt.

Spannenden Tag --PerfektesChaos 09:19, 9. Sep. 2010 (CEST)

mea culpa, mea ∞ culpa

Betrifft: Deine Recherchen nach Leerzeichen als Sortierschlüssel: Ich war’s.

• Du hattest Arbeit und Mühe gehabt, detektivisch dem Kategorie-Bug nachzugehen, und Benutzer andiskutiert. Sorry und danke.
• Leider war das flag iwcat, das den Sortierschlüssel schützen soll, in den fraglichen Fällen zu spät/garnicht gesetzt worden, so dass der Klammerinhalt im weiteren Verlauf als normales Wikilink einer Rasur schließender Leerzeichen zum Opfer fiel, weil ja whitespace folgt. Es sind deshalb nur die Fälle betroffen, in denen der Sortierschlüssel ein einzelnes Leerzeichen ist. Weil damit die Situation [[xyz:abc|]] entstand, die durch göttliche Interpretation unseres Parsers eine Abkürzung für [[xyz:abc|abc]] ist und ich dies zur besseren Verständlichkeit danach expandiere, steht dort jetzt jeweils [[Kategorie:Kkkk|Kkkk]].
• Du warst ja vor einem knappen Jahr mal auf der Suche nach einer Kategorie:Mann|Mann – darf ich davon ausgehen, dass du einen Dump zur Hand hast, in dem du die fraglichen Artikel identifizieren kannst? Da du ja auch die Benutzer identifizieren konntest? Wenn du mir eine Liste verdächtiger Artikel aufschreiben könntest, analysiere und berichtige ich die fraglichen Artikel natürlich selbst.
• 1.4 uploaded (Cache) … nach kurzem Anlauftest werde ich auf die Suche nach den Benutzern gehen und informieren.

sorry for trouble and inconvenience --PerfektesChaos 16:44, 12. Sep. 2010 (CEST)

Du bist überhaupt nicht an allem Schuld. Vielleicht an den zwei Fehlern, die Jodo passiert sind, aber der Rest waren Altlasten von WikEd, ein Modul aus PDDs Monobook oder Unkonzentriertheit menschlicher Bearbeiter. Bei mir trat dieser Fehler übrigens noch nie auf (das hatte ich auch mal explizit getestet) und auch jetzt ohne den Cache zu leeren, tut dein Skript bei mir genau das, was es soll. Meine Liste, nach der ich vorgehe, entstand natürlich mit zgrep und dem XML-Dump, ist aber inzwischen fast leer, sofern dir nicht die Nebenflusstiefe von Arroyo San Martín bekannt ist, gibt es nicht viel, wo du noch helfen könntest. Wenn es dir nur ums Analysieren geht, kannst du einfach meine Bearbeitungen vom Samstag durchgehen. Viele Grüße --Schnark 09:24, 13. Sep. 2010 (CEST)

Du darfst natürlich trotzdem die verbliebenen Seiten anschauen: Lucca ([[Kategorie: Lucca| Lucca]]), Dili (Distrikt) ([[Kategorie:Dili|Dili]]), Charles de Gaulle (R 91) ([[Kategorie:Charles de Gaulle|Charles de Gaulle]]), Kategorie:Bremer Organisation ([[Kategorie:Organisation (Freie Hansestadt Bremen)|Organisation]]), Star Wars (Arcade-Spiel) ([[Kategorie:Star Wars|Star Wars]]), Wikipedia:WikiProjekt Himmelskörper ([[Kategorie:WikiProjekt Himmelskörper|WikiProjekt Himmelskörper]]), Vorlage:Navigationsleiste Eparchien der Bulgarisch-orthodoxen Kirche ([[Kategorie:Bulgarisch-Orthodoxe Kirche|Bulgarisch-Orthodoxe Kirche]]), Arroyo San Martín ([[Kategorie:Flusssystem Río Uruguay|Flusssystem Río Uruguay]]), Kategorie:Person nach Person ([[Kategorie:Person|Person]]) Es sind aber auch einige dabei, bei denen das alles so passt. --Schnark 10:50, 13. Sep. 2010 (CEST)

• Na, da bin ich ja beruhigt und erleichtert.
• Zu der kuriosen Geschichte:
  • Mittlerweile habe ich herausgefunden, dass in bestimmten Situationen mein schützendes iwcat-Flag fehlerhaft die Kategorie nicht semantisch als solche markierte, dies aber keinerlei Folgen für den Wikitext hatte, weil diese Situation gerade nur die ohne Angabe eines Sortierschlüssels oder eines leeren Sortierschlüssels war. Mit einem Leerzeichen als Sortierschlüssel aber passierte von meiner Seite aus nix.
  • Deshalb bekommen wir zwei beiden von der Geschichte auch garnichts mit.
  • A: Jodo hat eine Kopie der PDD:monobook, in der steht importJavascriptL('BLueFiSH.as/JS/markup' und führt die vor mir aus – kam also ohne Leerzeichen bei mir an.
  • Weil ich das semantisch nicht richtig klassifiziert hatte, behandelte ich es als normales Wikilink und expandierte auch [[foo:bar|]] zwecks Verdeutlichung zu [[foo:bar|bar]] statt meiner Gewohnheit nach auch noch das überflüssige Pipe-Symbol eines leeren Sortierschlüssels einzukassieren.
  • B: Es ist aber Gewohnheit des Servers (nicht von WikEd, Test als IP auf der Spielwiese), zur Verständlichkeit (intern bereits in der Diffpage sichtbar) Wikitext mit [[foo:bar|]] als [[foo:bar|bar]] abzuspeichern (habe ich zumindest nicht gewusst, war wohl Anfang des Jahres auch noch nicht so).
  • Ich hätte es also doch nicht verhindern können, weil nicht das schon fehlende Leerzeichen wiederbringen können – trotzdem eine Fehlfunktion.
    Auswirkung wäre aber zurzeit nur gewesen:
    • Jede Kategorie beginnt auf neuer Zeile wäre nicht repariert worden.
    • Zukünftig wäre nicht repariert worden: Kategorie doppelt
    • und in ganz ferner Zukunft die Anordnung in Blöcken

      {{SORTIERUNG}}

      [[Kategorie:

      {{PD}}

      {{Link}}

      [[interwiki:

      identifizieren und ggf. umsortieren

  • C: Ursache für meinen bug war ein mir zwar irgendwie im Hinterkopf waberndes JavaScript-Phänomen: Eine leere Zeichenkette s=""; gilt in C, C++, C#, Java als "allokiert und Speicherplatz beanspruchend", damit liefert die Abfrage if (s) in den mir noch länger vertrauten Sprachen "wahr", in JavaScript unter dem gegenwärtigen Firefox "falsch". Die Standards zu JavaScript/ECMA erwähnen dieses Phänomen nicht. s selbst ist damit aber nicht null oder '\0', denn s.length gibt es noch und s.concat("a") ergibt s="a" – s ist allokiertes Objekt, aber halt vom internen JavaScript-Spezialtyp String. Anfang des Jahres hatte ich diesen Mist schon mal. s2=new String(); ist dagegen auch nichts anderes als "", aber if (s2) ist in meinem Firefox "wahr". Das verstehe wer will.
  • D: Deine Wochenend-Edits und Benutzer-Anfragen hatte ich bereits Sonntag abend analysiert gehabt und ziemlich gerätselt – die Bearbeiter hatten mein Skript nicht eingebunden und (falls nicht gelöscht) noch nie ein js-Benutzerskript. Außerdem hatte ich im Juli eigentlich mit über 1000 Artikeln getestet, in der vorangegangenen Entwicklung war der leere Sortierschlüssel (wie auch das einzelne Leerzeichen) ein expliziter Testfall und führte damals planmäßig zur Entfernung des Pipe-Symbols; der bug stammt wohl aus dem August.
  • Als ich Sonntag nachmittag hurtig auf Fehlersuche war und den iwcat-Fehler fand, hatte ich das Problem erstmal bei mir selbst gesehen; beim Austesten mit Jodos wallonischem Schlagzeug kam ich wohl mit den diversen Versionen und vorher/nachher durcheinander.
• Wieviele Leichen haben wir denn noch im Keller?
  • E: Es wäre dienlich, wenn du vorbeugend deinen Dump durchgrabbelst nach: \[\[Kategorie:.+\|\]\]
  • Das wären dann die ehemals einzelnen Leerzeichen, die schon irgendwie abhanden kamen und mit der nächsten Abspeicherung expandiert würden (falls es ein halbes Jahr unbearbeitete Artikel gäbe).
• F: WikEd
  • Hier würde ich Dich um Aufklärung bitten – gibt es irgendwelche verborgen ablaufende automatisierte Syntaxkorrektur? Das wäre für mich als Entwickler fatal, wenn klammheimlich parallel ein anderer Algorithmus den wikitext zwirbelt; das [[foo:bar|]] ist schon confusing genug.
  • Die WikEdFix*** habe ich mit kollegialem Interesse gelesen. Das sind ja offenbar die Buttons zwischen Suchen/Ersetzen und Textarea, und wenn die manuell lokal unter optischer Kontrolle ausgeführt werden, sind sie sicher sinnvoll – Select-All und dann global anwenden wäre jedoch unweise, wovon ich ein 230kB langes Lied singen kann. Ich halte dieses und die anderen Button-Blöcke mit Ausnahme der Basisformatierung und Suchen/Ersetzen allerdings ausgeblendet, um mehr Platz zu haben.
  • Den anscheinend inzwischen beseitigten Fehler in WikEd habe ich nicht mehr auffinden können.
• G: Zu Charles de Gaulle (R 91) fällt mir auch nichts mehr ein, da Flugzeugtrager oder Schiff hinzuschreiben, reißt es ja wohl auch nicht 'raus. Da du nunmehr in der Materie eingearbeitet bist, wäre es wohl besser, wenn du noch zu Erledigendes selbst perfektionierst.
• H: Wenn du dir freundlicherweise in vier bis sechs Wochen mal den dann frischen Dump zur Nachsorge vornimmst?

Jetzt wieder mit gutem Appetit, dir gleichfalls --PerfektesChaos 12:59, 14. Sep. 2010 (CEST)

Ich habe mal Buchstaben in deine Bemerkungen eingefügt, um mich besser darauf beziehen zu können:

A: Grrr, wie kann man nur zwei Skripte verwenden, die das gleiche Problem behandeln?

B: Nein, nein, das war schon immer so. includes/parser/Parser.php Stichwort "Context links".

C: In Anbetracht der Tatsache, dass mein Toolbar-Skript auch im IE funktioniert, behandelt auch dieser Leerstrings als false. Ich bin zu sehr Perl-belastet um irgendein Verhalten dabei merkwürdig zu finden ...

D: Da die meisten Fehler wohl wirklich noch von WikEd stammen (Fehlerbehebung war am 21. Juli), kann man als Ausenstehender keine Skripte finden.

E: Siehe B, würde der Ausdruck irgendetwas finden, dann wäre irgendwo ein dicker Fehler in Mediawiki. Ich habe mit \[\[Kategorie:(.*)(,.*)?( \([^\)]*\))?\|\1\]\] gesucht, alles was dabei durch die Lappen gehen kann, sind Kategorien mit （）als Klammern, wovon ich hoffe, dass es sie nicht gibt. Und natürlich Kategorien, die von einem Bot umbenannt wurden, bevor der Fehler bemerkt werden konnte, aber die kann man nicht per RegExp finden.

F: Automatisch tut WikEd soweit ich weiß nichts. Allerdings läuft die Whitespace-Korrektur, in der der Fehler wohl saß, bei jeder manuell eingeleiteten Autokorrektur (die lila Knöpfe) ab. Der Programmierer hat den Bug aber nun endlich so ca. ein Jahr, nachdem er darauf aufmerksam gemacht wurde, behoben.

G: Der Artikel tauchte schon länger in der Liste auf, sowohl Benutzer:Asdert als auch ich tun nichts damit, also bleibt es wohl so, wie es ist.

H: Ob ich Lust habe, das ganze schon wieder in ein, zwei Monaten zu wiederholen, weiß ich nicht, aber irgendwann werde ich die Liste sicher wieder aktualisieren. So dringend ist es ja nun auch wieder nicht.

Viele Grüße --Schnark 09:43, 15. Sep. 2010 (CEST)

ad B) – Dass es immer schon so dargestellt wurde, glaube ich ohne Weiteres; diese Syntax-Eskapade fügt sich wunderbar in die spontane Entwicklungsphase Anfang des Jahrtausends ein. Nur meine ich, während der Skript-Entwicklung im Frühjahr dieses Jahres im Quelltext ein |]] vorgefunden zu haben, seine Darstellung bestaunt hätte und erst daraufhin in der Hilfe nachgesehen zu haben, was das bedeutet. Erst dann hatte ich das Konstrukt auf meine ToDo-List gesetzt, um es subito zu expandieren. Möglicherweise hat aber zwischenzeitlich jemand eingesehen, dass dieses Strichlein von Menschen und dem nachfolgenden Autor zu leicht übersehen wird und es bei einer Wartung in der gesamten Datenbank expandiert. Egal. – Übrigens ist es immer anregend, mit dir zu kommunizieren; in der Parser.php ist ein [[|name]] erwähnt, über das ich erstmal tiefer nachdenken muss. Habe ich noch nie in einem Quelltext gesehen. Wenn es aber in keiner Hilfe steht und (jetzt?) bei Abspeicherung schon expandiert wird, kann ich es weitgehend ignorieren; ich analysiere ein [[]] ebenfalls nicht weiter, und das ist die gleiche Situation.

ad C) – Na, nur zur Warnung, dass diese Syntax nicht eindeutig definiert ist und das Verhalten sich in Opera Safari FF-4 IE-10 spontan ändern kann, was dann extrem mühsam zu debuggen ist.

s1=""; s1 ist leere Zeichenkette, if (s1) → falsch

s2=new String(); s2 ist leere Zeichenkette, if (s2) → wahr

s3="ABC".substr(10); s3 ist leere Zeichenkette, if (s3) → … ?? … zurzeit falsch (FF3.6.9)

Das muss früher oder später schief gehen.

ad X) – Version 1.5 in Vorbereitung, die die Erfahrungen und Erkenntnisse des Wochenendes aufarbeiten wird, aber nach restloser Aufklärung zuvor noch ein paar Tage zu testen wäre.

Mahlzeit --PerfektesChaos 12:38, 15. Sep. 2010 (CEST)

B: Nicht umsonst steht im Quelltextkommentar ein "Pre-save transform helper function" darüber, und das schon jahrelang und noch länger. Es kann eigentlich nirgendwo im Quelltext ein [[foo|]] vorkommen.

C: Ursprünglich konnte an der einen Stelle, wo ich es verwende, sowohl ein Leerstring als auch ein undefined übergeben werden. Da das undefined inzwischen nicht mehr möglich sein sollte, hast du recht, dass es besser wäre, wenn ich es mal umstellen würde.

Y: Hast du dir eigentlich davon schon den Appetit verderben lassen? --Schnark 09:20, 16. Sep. 2010 (CEST)

• Danke für die Info.
• 0) Ich war's doch. Aber wir zwei Profis konnten gar nicht geleimt werden, wir beide waren gefeit ... unser Modif_Text blockierte das als Nebenwirkung. r=1.6 launched, please clear cache. Ich werde systematisch im Schlicht-Modus austesten müssen; bisher war bei mir fast immer Modif_* aktiv.
• B) Ja, dann mag das so sein; ich habe nur nebelhafte Erinnerungen, wie ich mal auf das Konstrukt gestoßen war.
• P) (neu): PDfix wie gewünscht verfügbar. g-Flag allerdings nur sinngemäß, tatsächlich plumpe Wiederholung: Weil der RegExp nach |name=val sucht, kann das nur genau einmal gefunden werden und kommt im Rest der Vorlageneinbindung nicht mehr vor. g-Flag ist erst möglich, wenn ich mal die Implementierung von allgemeines verschachtelbares Syntax-Objekt fertig habe; dann kann in der Liste der Tupel name=val der Inhalt von val separat analysiert werden; dann können die val Vorlagen (und Links neben nowiki und Kommentar) enthalten. Dieses Objekt wäre neben konkret benannter Vorlagen auch für gallery und Datei:-Einbindungen verwendbar. Also vorläufig nur 3 Pseudonyme und nur je 2 vollständige/wirkliche Namen.
• R) (neu): Re-Engineering steht aber vorrangig auf der Agenda. Die Funktion, die das Wikilink-Format analysiert, hat 660 Zeilen und ist definitiv zu lang; nicht mehr robust zu warten und zu entwickeln. Hier wird es einen objektorientierten Ersatz geben müssen. Macht aber Spaß.
• Y)
  1. Ich schaue mal, wie sich das dann auf mich auswirken würde und ob überhaupt; dazu muss ich aber die konkret generierte HTML-Seite lesen. Von den Deprecations sehe ich nur eine banale Ersetzung mediaWiki.loader.load() statt importScript() -- wobei das wohl in PHP steht, also noch ein paar Zeilen abzukopieren wären. Aber da wird wohl jemand eine Kopiervorlage liefern, oder es bleibt eine initiale Wrapperfunktion für triviale Fälle erhalten.
  2. Ich habe die Projektneuheiten auf meine Beobachtungsliste gesetzt, du warst mal wieder hilfreich.
  3. Den Appetit hat es mir nicht verdorben; im Gegenteil erfreulich wird werden das von mir schon still ersehnte feature Vom Benutzer angelegte JavaScripte werden beim Aufruf im script-tag der HTML-Seite um die Revision-ID ergänzt: User:Foo/common.js&action=raw&2138018 – dadurch wird der Browser-Cache angewiesen, das aktuellste JavaScript vom Server zu laden und abzuarbeiten; damit entfiele das Cache-Rumgedödel.

--PerfektesChaos 20:52, 25. Sep. 2010 (CEST)

P) Danke für den schnellen Einbau. Zwei Mal wirklicher Name sollte eigentlich reichen, und wenn einer vier abgekürzte Pseudonyme hat, muss ich eben eines von Hand ändern oder einmal auf Syntaxkorrekutur-manuell-durchführen-Knopf klicken.

Y) Ich habe mir das Ding mal näher angeschaut und kam zu folgenden Schlüssen:

1. Die meisten Änderungen (insbesondere die meisten Verbesserungen) betreffen nur Mediawiki-Programmierer, vom automatischen durch JS-Minify Jagen über das automatisch Abhängigkeiten auflösen bis hin zum Browser-Cache gezielt aushebeln profitieren wir nur bei unseren vector.js/monobook.js & common.js, Unterseiten sind davon nicht betroffen, wer modular programmiert, hat in diesem Fall einfach Pech. Einen guten Überblick, was sich eigentlich verbessert, bietet [3]. Der Code, insbesondere der clientseitige, ist trotzdem lesenswert und hat mich zu einem eigenen kleinen Experiment angeregt.
2. Wie das Ganze aussehen wird, kannst du dir schon auf Translatewiki ansehen, wo die persönliche vector.js/... geladen wird, weiß ich nicht, vermutlich irgendwo in der Gegend, wo das mediaWiki.user.options.set steht. Evt. anmelden und ausprobieren.
3. Einzige Verbesserung für den gewöhnlichen Skriptbastler ist in meinen Augen, das Vorhandensein von jQuery (das ist jetzt schon der Fall) und bei Bedarf alle möglichen UI- und sonstigen Plugins (Liste: [4], Demos: [5]) Wobei das von optischem Schnickschnack abgesehen nur dem Vorteile bringt, der für DOM-Manipulationen von Hand zu faul ist. (Mir zum Beispiel.)
4. Eine weitere Änderung ist die Tatsache, dass die Skripte nun erst am Schluss aufgerufen werden, dort wo bisher das runOnloadHook(); steht, das bei der Gelegenheit wegfallen wird. Das kann bedeuten, dass ein addOnloadHook oder was auch immer man als Ersatz nehmen will die Funktion nicht auf die Wartebank setzt, sondern sie eventuell direkt ausführt, weil das Load-Event bereits abgefeuert wurde. Dann käme jegliche benutzerdefinierte Konfiguration, die danach kommt, zu spät. Ob das tatsächlich passieren kann, weiß ich nicht, verlassen würde ich mich aber auf nichts mehr.
5. Zu den Deprecations gehört nicht nur die komplette Wikibits.js, sondern auch alle globalen Variablen wgWasWeissIch, die man in Zukunft über mediaWiki.config.get('wgWasWeissIch'); aufrufen sollte. Sollten die Programmierer jemals auf die Idee kommen importScript zu entfernen, wird es einen ganz großen Aufschrei geben, den ich mir lieber nicht vorstellen will, aber zutrauen tu ich es ihnen schon.

Viel Spaß beim Programmieren aller notwendigen und freiwilligen Änderungen, --Schnark 09:41, 27. Sep. 2010 (CEST)

Z) Nachtrag, da ich gerade Benutzer:PerfektesChaos/css#Seiten-interne Verlinkungen gelesen habe. Je nach Wert von wgIsArticle hat das Body-Tag die Klasse ns-subject oder ns-talk. Damit ist im Prinzip eine reine CSS-Lösung möglich. --Schnark 11:35, 27. Sep. 2010 (CEST)

Alle ausgewählten Gadgets temporär deaktivieren

Hallo Schnark. Ich habe gerade deine JS-Scripte bemerkt. Unter MediaWiki Diskussion:Gadgets-definition#alle ausgewählten Gadgets temporär deaktivieren wird etwas ähnliches gefragt wie du mit modulverwaltung.js anbietest. Vielleicht kannst du da (oder ggf. auch bei meinem Change-Tab-Wunsch) ja helfen. --Leyo 11:40, 11. Okt. 2010 (CEST)

Bei den Gadgets kann mein Skript nicht wirklich weiterhelfen, da die Einbindung der js-Dateien auf dem Server geschieht und ich darauf per Javascript keinen Einfluss habe. Außerdem kann man bei mir Skripte auch nur einzeln aktivieren und deaktivieren. Für dein Problem könntest du deine vector.js ersetzen durch etwas wie

importScript('Benutzer:Schnark/js/jsmodules.js'); //[[Benutzer:Schnark/js/jsmodules.js]]
function jsmodules_init() {
  jsmodules.register('[[Benutzer:Jonathan_Haas/vector.js]]');
  jsmodules.register('[[Benutzer:Leyo/monobook.js]]');
  jsmodules.load('[[Benutzer:Schnark/js/modulverwaltung.js]]');
};

Dadurch würde zunächst einmal kein Skript aktiv sein, auf [6] könntest du dann aber beide nach Belieben aktivieren. (Unter der Annahme, dass alles was in deiner monobook.js steht auch unter Vector funktioniert.) Das wären dann beim Wechsel natürlich immer zwei Klicks und ließe sich nur auf dieser Seite oder einer deiner Unterseiten durchführen, aber immerhin. --Schnark 12:00, 11. Okt. 2010 (CEST)

Vielen Dank für deine ausführliche Antwort! Ich werde das demnächst ausprobieren. --Leyo 12:02, 11. Okt. 2010 (CEST)

Mir ist – etwas spät – aufgefallen, dass dein Script ja nur den Vector-Skin unterstützt. Momentan möchte ich aber beim Monobook-Skin bleiben. --Leyo 15:57, 17. Okt. 2010 (CEST)

Prinzipiell ließe sich das Skript vermutlich auch unter Monobook zum Laufen bekommen, allerdings habe ich das noch nicht versucht. Warten wir am besten auf MediaWiki 1.17, da ist es für mich dann kein Problem mehr, das Ganze unter allen Skins zum Laufen zu bringen. --Schnark 09:05, 18. Okt. 2010 (CEST)

Und wann kommt das voraussichtlich? Funktioniert Benutzer:Schnark/js/extratabs mit Google-Übersetzung in anderssprachigen WPs? --Leyo 11:05, 19. Okt. 2010 (CEST)

Auf Glaskugeleien zu MediaWiki-Versionen will ich mich irgendwie nicht einlassen, ich meine mich daran zu erinnern, dass irgendein Optimist mal den November erwähnte (also vielleicht im März nächsten Jahres?). Die Extratabs funktionieren – wenn man sie mit importScriptURI einbindet (Bsp.: [7], [8] – auch in fremdsprachlichen Projekten, man hat allerdings dann gleich alle Extratabs und ich habe gerade festgestellt, dass diese in anderen Projekten nicht einmal alle funktionieren. Im Vector-Skin ist es natürlich einfach, diese anderen Tabs zu ignorieren, ich kann aber auch eine Option einbauen, dass man bei Bedarf alle Tabs außer der Google-Übersetzung ausschalten kann. --Schnark 11:19, 19. Okt. 2010 (CEST)

Ich hab's mal in der fr-WP ausprobiert. Bei mehreren Extratabs bewirkt „wikipédia“ das Problem. --Leyo 11:31, 19. Okt. 2010 (CEST)

Bitte einmal den Browsercache leeren. WikiLint als spezielles de.wikipedia-Tool funktioniert natürlich noch immer nicht, aber die anderen Dinge laufen jetzt auch in fr. --Schnark 11:50, 19. Okt. 2010 (CEST)

So ist es, danke! Nur die Google-Übersetzung ist nicht bei den übrigens Tabs dabei. In der es-WP hingegen funktioniert alles. --Leyo 11:53, 19. Okt. 2010 (CEST)

(ausrück, da keine Lust, Doppelpunkte zu zählen) Die Google-Übersetzung wird nur dann angezeigt, wenn sich die Inhaltssprache von deiner Benutzersprache unterscheidet. Du verwendest in fr als Interface-Sprache vermutlich Französisch, also musst du ein var nach_sprache='de'; am Anfang deiner vector.js einfügen (wie ich in en). (Oder die Sprache dort auf Deutsch umstellen.) --Schnark 12:03, 19. Okt. 2010 (CEST)

Bingo, danke! --Leyo 12:04, 19. Okt. 2010 (CEST)

Uppss...

...sorry, hatte mich eben verklickt und dabei eine PDD-Einfügung durch Dich rückgängig gemacht. Habe das natürlich sofort korrigiert. Möchte Dich nur informieren, dass es keinen Grund dafür gab. Ich muss mal meine Bildschirmauflösung neu anpassen; derzeit stehen sehr häufig die Links "Versionen" und "Zurücksetzen" exakt übereinander; wenn ich dann auf dem Mauspad verrutsche... Nix für ungut. Gruß, --CC 10:51, 16. Okt. 2010 (CEST)

Gibt es hier irgendjemand, dem das noch nicht passiert ist? Ich habe, nachdem es mir das erste Mal passiert ist, ein

.mw-rollback-link { display:none; }       /*Zurücksetzen weg, zu gefährlich*/
.diff-ntitle .mw-rollback-link { display:inline; background-color:#FFC0C0;}
                                             /*nur bei Diffs, rot unterlegt*/

in meiner vector.css, was die Zurücksetzen-Links an den meisten Stellen ausblendet und sonst rot hinterlegt. Falls du es übernehmen willst, muss der Code in Spezial:Meine Benutzerseite/vector.css (oder Spezial:Meine Benutzerseite/monobook.css, falls du beim alten Skin geblieben bist). Ansonsten kann ich noch safe-rollback.js von Revolus empfehlen. Viele Grüße --Schnark 11:00, 16. Okt. 2010 (CEST)

Herzlichen Dank, freundliches Angebot. Ich schätze meinen Skin aber tatsächlich "nackt", s.h. ohne Erweiterungen, wesentlich mehr. Freundlicher Gruß, --CC 11:30, 16. Okt. 2010 (CEST)

Personendaten.js

Hallo Schnark, hast Du an dem Script irgendwelche Änderungen vorgenommen? Irgendwie verhält sich das Script seit HEUTE merkwürdig! Am Ende der Personendaten wird der Zeilenumbruch gelöscht und der darunterliegende Interwiki-Link in die letzte Zeile der Personendaten verschoben. Da ich aufgrund Deiner Empfehlung auch das Script von "Perfektes Chaos" benutzt habe, hatte dieses zur Konsequenz, dass dieses Script das Interwiki zwar wieder in eine gesonderte Zeile verschoben hat, allerdings die einführenden eckigen Klammern gelöscht wurden :-). Damit war dann das Chaos perfekt. Magst Du einmal nach der Ursache forschen? Besten Dank --Silke Ewering 22:23, 19. Okt. 2010 (CEST)

Ich habe tatsächlich eine Änderung vorgenommen, dabei aber an den Zeilenumbrüchen nichts geändert und war deswegen kurz davor zu schreiben, dass ich dein Problem nicht nachvollziehen kann. Dann stieß ich in deinen Beiträgen auf Chum Mey. Ich habe jetzt einen zusätzlichen Zeilenumbruch eingebaut. Leere also einmal deinen Browser-Cache. Sobald ich dazu komme, werde ich eine bessere Lösung für die Zeilenumbrüche einbauen, bis dahin kann es passieren, dass da jetzt ein Zeilenumbruch zu viel eingefügt wird, aber besser einer zu viel als einer zu wenig. Die Tatsache, dass die eckigen Klammern gelöscht werden, leite ich gleich an PerfektesChaos weiter. Falls dir weitere Fehler auffallen, nennst du mir am besten immer einen Artikel, damit ich es direkt am Beispiel nachvollziehen kann. Viele Grüße --Schnark 09:25, 20. Okt. 2010 (CEST)

Danke für Deine Mühe! Klar, unsere EDV-Experten wollen auch immer eine Regel oder ein Beispiel wissen, wenn ich mal wieder einen Fehler gefunden habe. Hätte ich auch gleich dran denken können... Der "Fehler" kommt leider immer noch vor. Zum Hintergrund: ich habe Dein Script in meine vector.js gespeichert (das Script von PerfektesChaos ist gelöscht). Nach dem Ändern der Personendaten siehst Du im "Bearbeitenmodus", dass der Interwiki-Link direkt hinter die geschweiften Klammern der Personendaten verschoben werden. Beispiel: Hucbald. Soweit zu Deinem Script. Viele Grüße --Silke Ewering 13:40, 20. Okt. 2010 (CEST)

Und nun das Beispiel, wenn das Script "Wikisyntax..." gearbeitet hat: Karl-Heinz Radschinsky :-) Viele Grüße --Silke Ewering 14:08, 20. Okt. 2010 (CEST)

Sowohl ich als auch PerfektesChaos haben neue Skriptversionen erstellt, du musst also noch einmal deinen Browsercache leeren. Du kannst übrigens ruhig die Fehler, die unsere Skripte machen, vor dem Abspeichern korrigieren, ich kann direkt die alte Version untersuchen, sodass ich das Problem auch so nachvollziehen kann. Und noch ein Tipp: Du kannst auch das Skript von PerfektesChaos auf die selbe Art einbinden wie meines, in deiner vector.js sähe das dann so aus (inzwischen weißt du ja auch, dass du die source-Tags nicht mitkopieren darfst):

importScript('Benutzer:Schnark/js/jsmodules.js'); //[[Benutzer:Schnark/js/jsmodules.js]]
function jsmodules_init() {
  jsmodules.load('[[Benutzer:Schnark/js/personendaten.js]]');
  jsmodules.load('[[Benutzer:PerfektesChaos/js/WikisyntaxTextMod/r.js]]');
};

Das hat einen Vorteil: Wenn ich immer daran denke, dann musst du in Zukunft nicht mehr bei jeder neuen Version deinen Browsercache leeren. --Schnark 09:31, 21. Okt. 2010 (CEST)

Danke für die Mühe. Nun ist ALLES wieder in Ordnung und beide Skripte erleichtern die Arbeit wirklich erheblich. Es macht wieder Spaß. Beste Grüße--Silke Ewering 20:57, 21. Okt. 2010 (CEST)

ResourceUpdater

1. Wenn der ResourceLoader sich seinen Namen verdienen will, sollte er für alle Benutzer-js/css die curid der Benutzerdatei dranhängen. Das ist innerhalb einer ProjektDB machbar und den Entwicklern zuzumuten. –
   Grummel – er macht das nicht, und selbst für das Skin-Benutzerskript kommt das angehängte &lfdnr erst von der skinxx.php, und wird mit dem RessourceLoader wohl wegfallen.
2. Das triggerte mich, meinen eigenen Mechanismus zu schreiben und künftig einzusetzen. Die Anregung zum Cookie stammt aus deinen jsmodules, du darfst dich auch gern bei mir bedienen, ist eh’ weltweit quelloffen.
   Typos Benutzer:Schnark/js/jsmodules:
   * ("du" fehlt) Aufruf erfolgt also immer wie die Seite
   * erhälst
3. Süß ist: Wenn man sich auf MediaWiki einloggt, erhält man stapelweise Fehlermeldungen vom mediawiki-Objekt und anderen: addEvent() missing etc. etc.

Schöne Woche --PerfektesChaos 13:15, 1. Nov. 2010 (CET)

1. Mit dem ResourceLoader sollte die eigne vector.js/monobook.js/… mit geeigneter Versionsnummer ausgeliefert werden (loader.php?modules=user&version=...), und ich meine mich daran zu erinnern, dass es bei einem Test bei mir sogar funktionierte.
2. Typos darfst du gerne selber korrigieren, in diesem Fall war aber sowieso noch ein Update in der Dokumentation nötig.
3. Für meine eigene Mediawiki-Installation habe ich auch mehrere Anläufe gebraucht, bis ich zufällig eine Version erwischte, die nicht ständig irgendwelche obskuren Fehlermeldungen produzierte.

Viele Grüße --Schnark 09:35, 2. Nov. 2010 (CET)

Jajaja – aber – welchen konkreten Wert N soll ich denn nun jetzt gerade (09:51, 3. Nov. 2010 (CET)) bei &version=N angeben? Dies wenigstens innerhalb der eigenen Projekt-DB automatisch und standardmäßig selbst herauszufinden, eigentlich auch bei Schwester-DB – das fehlt und wird nach der robusten Umstellung auf RessourceLoader durch meinen ResourceUpdater geleistet werden müssen.

--PerfektesChaos 09:51, 3. Nov. 2010 (CET)

Für die eigene monobook.js etc. wird die Version automatisch ermittelt (Zeitpunkt der letzten Änderung oder so), für alle anderen Skripts funktioniert der RessourceLoader sowieso nicht, er kann nur ausliefern, was vorher in PHP registriert wurde. Dass mediaWiki.loader.load auch URLs akzeptiert, ist das einzige Zugeständnis der Mediawiki-Programmierer an uns arme Skriptbastler, um den Rest müssen wir uns selber kümmern (was wir ja auch tun). --Schnark 09:13, 4. Nov. 2010 (CET)

Aha – dann hatte ich die Intention von RessourceLoader und dessen anscheinende Fokussierung auf die PHP-Welt (Server-seitig orientiert, User nicht im Blick) bislang so nicht wahrgenommen. Ich ging davon aus, dass eine Ressource so wichtig ist wie die andere.

Das hieße aber, deine jsmodules und mein ResourceUpdater wären nach robuster Einführung des mediaWiki-Objekts breiter zu propagieren. Bis dahin gucken wir mal, dann sehn wir schon.

Entspannt --PerfektesChaos 09:36, 4. Nov. 2010 (CET)

Ich nehme alle meine Anschuldigungen gegen die Programmierer zurück, sie wären nicht freundlich zu uns: resources/mediawiki.util/mediawiki.util.js Sogar eine neue addPortletLink-Funktion gibt es! --Schnark 12:19, 4. Nov. 2010 (CET)

1. Wie gesagt, ich hatte das alles auch nicht so eng wahrgenommen.
2. Es ist müßig, über ein künftiges Produkt zu rechten, das eigentlich erst in irgendeiner Zukunft eingeführt werden soll, und zurzeit in Test- und Entwicklungsphase steckt.
3. Jedoch ist es auch schon irgendwie halb (monobook) im Einsatz, und es wird bereits auf mw:ResourceLoader nach außen kommuniziert. Dafür ist die externe Kommunikation mit der weltweiten Gemeinde allerdings recht ungeschickt, und eine weitergehende Übersichtsdarstellung für Benutzer in Projekten nach Art eines WP:Kurier wäre angebracht gewesen. Mit Publikation der Deprecated-Liste wäre gleichzeitig die vorläufige Veröffentlichung einer Dokumentation von Public User-Funktionalität angezeigt. Solange man in irgendeiner Ecke als Developer-Test-Preliminary herumexperimentiert, ist das nicht notwendig. Gestaunt hatte ich über die Nutzung von GoogleDocs als verborgene gemeinschaftliche Austauschplattform – wo bin ich denn hier??
4. Ansonsten habe ich mir die Requirements und Quellcodes recht genau angeguckt; sie haben auf mich einen sehr guten Eindruck gemacht. Die Konzeption ist schlüssig, die Umsetzung lege artis. Das seit 2005 herangewachsene Gewirr auf dem Server, mit Wikipedia-en-de-Projekten, Wiki-Schwestern, und Installation von Mediawiki auf beliebigen freien Webservern nebst Skins und Toolbars und Stewards und Gadgets und Extensions hat die Funktionalität gegenüber 2005 exponentiell vergrößert. Die Software dürfte kaum noch wartbar und robust zu halten sein. Die Ziele der Neuerer gehen hier genau in die richtige Richtung, und ich habe Vertrauen in deren Kompetenz.
5. Ob alle Funktionalität der Version 1.0 jeden Wunsch von uns Skriptbastlern erfüllt, werde ich erst nach Einführung bewerten (vgl. #2). Wenn da von Anwenderseite noch Wünsche offenbleiben (wikiGetlink() mit eckigen Klammern, jede Ressource mit der jeweils aktuellen curid wenigstens innerhalb derselben Projekt-DB), die die momentane wikibits ja auch nicht leistet, kann man nach einer Verschnaufpause darauf zurückkommen.
6. Deprecated heißt nur, dass die derartig gebrandmarkten Features bei Neuentwicklungen nicht mehr verwendet werden sollen. Wann die alten features tatsächlich abgeschaltet würden, liegt bei uns in der Hand der dewiki-Chefadministratoren; mediaWiki.legacy stellt die „alten“ Funktionen weiterhin bereit und lassen sich über Projekt-PHP-Variable (wie LEGACY_GLOBALS) als aktiv konfigurieren.
7. Wenn einige dewiki-Bastler murren und stöhnen, ist das vermutlich verfrüht, völlig unnötig oder auf ohnehin unglückliche und wacklige Programmierpraktiken zurückzuführen.
8. WikisyntaxTextMod und ResourceUpdater benötigen bereits keine GLOBALS mehr, versuchen mediaWiki.config.get() und fallen sonst auf klassische GLOBALS zurück; ResourceUpdater kommt ganz ohne wikibits aus. Übrigens macht mediaWiki.loader.load() nach erstem Augenschein auch nichts anderes als im DOM an das <body> ein <script> anzuhängen; wenn's weiter nichts ist: ResourceUpdater_wiki_load_DOM() kann das auch, aber bis auf Weiteres noch am <head>.
9. In Zeile 96 von mediawiki.util.js stehen noch wgServer + wgArticlePath :-)) Die sind aber im globalen namespace wohl künftig nicht mehr vorhanden, müsste vielleicht this.Server und this.ArticlePath heißen. Wir üben das noch.
10. Deine cookies habe ich gestern in meiner monobook.js zum Ein- und Ausschalten von Testversionen und UDF eingesetzt, nachdem nur dafür Dutzende von Server-Versionen draufgingen.

Milden Tag--PerfektesChaos 09:21, 5. Nov. 2010 (CET)

2. Ich habe mit einem halben Auge die Diskussionen auf der Mailinglist verfolgt, wie schnell wir hier auf 1.17 (und damit auf den ResourceLoader) umsteigen sollen und es ist nicht so recht zu durchschauen. Es scheint mir aber so, als wären viele der Ansicht, dass der RessourceLoader so schnell wie möglich kommen sollte.

3. Da wikibits.js etc. von offizieller Seite bisher gar nicht dokumentiert war (zumindest habe ich nichts dergleichen gefunden), ist der RessourceLoader doch deutlich besser dokumentiert. Die Liste der Deprecations wird tatsächlich mit den neuen Funktionen aktualisiert, wer bisher rausfand, dass es addPortletLink gibt und wie es funktioniert, wird auch die neue Version finden. Vielleicht …

4. Eine der größten Verbesserungen in meinen Augen ist die Tatsache, dass man sich nicht mehr durch eine kilometerlange Liste von verschiedensten Javascript-Dateien kömpfen muss, wenn man in Firebug sein eigenes Skript zu Debuggen sucht.

5. mediaWiki.loader.load als Ersatz für importScript zu bezeichnen ist eine verdammt große Frechheit und mit der Tatsache, dass mwCustomEditButtons zu Gunsten der Wikieditor-Erweiterung als deprecated gelten wird, wird auch nicht alle glücklich machen.

6. Immer wenn ich den Kommentar This will not change until we are 100% ready to turn off legacy globals lese, höre ich die Betonung nicht auf 100%, sondern auf we. Ich mag mich täuschen, aber wenn man auf den hinterletzten Benutzer im hinterletzten Projekt warten will, bis er seine Skripte umprogrammiert hat, dann wird man LEGACY_GLOBALS nie auf false setzen. Andererseits ist auch Mediawiki:Monobook.js seit 4 Jahren offiziell deprecated und wird voraussichtlich bis in alle Ewigkeit unterstützt.

7. Volle Zustimmung.

9. Die Usability-Initiative hat noch mehr so alte Variablen. Es ist mir im Moment noch keinen Bugreport wert, irgendjemand wird schon nochmal über den Code gehen und bei der Gelegenheit solche Kleinigkeiten verändern. Krinkle schreibt hier genug Benutzerskripte, in denen er noch die globalen Variablen nutzen muss, wie soll er sich für Mediawiki jetzt so schnell umgewöhnen?

Wenn dein Tag mild wird, freut mich das für dich, hier tendieren die Temperaturen (zumindest für November) gegen schwül-warm. Viele Grüße --Schnark 10:12, 5. Nov. 2010 (CET)

3. Bisher war die Server-seitige Software grassroot-Gewuschel aus einem Projekt, bei deren Entwicklung anfangs keiner wusste, was daraus wird, und einige Enthusiasten eine Umsetzung versuchten. Nun ist klar, dass das Baby groß und stark geworden ist, und mit 2010 muss das auch in Fragen der Schnittstellendokumentation professioneller werden. Auch die innere Struktur der Server-Software muss künftig deutlicher überblicksmäßig dokumentiert werden, um das Projekt durch weltweit verteilte und immer wieder neue Mitstreiter wartungsfähig zu halten. Für alte Entwicklungen (wikibits) ist das gelaufen, aber Neuentwicklungen sind dann auch gleich bei Entstehung (sonst passiert das erfahrungsgemäß nie) auf wenigen Seiten sauber darzustellen. Die JS-Quellcodes enthalten javadoc-Syntax (@param); das ist für die Dokumentation innerer Funktionen hinreichend, aber die HTML-Seiten müssten auch generiert und auf einem gewissen Stand in die Projektseiten eingebunden werden. Für die Server-seitige Entwicklung (Skin etc.) genügt das auch; Benutzer-Funktionen müssen als Public (gibt es in JS nicht, aber man kann so tun als ob) markiert und diese dargestellt werden. Da wäre das Niveau von mw:API zu erreichen. Die Deprecated-Liste ist ein akzeptabler Startpunkt. Wenn im Projekt gigabyteweise Löschdiskussionen geführt werden, lassen sich auch ein paar Seiten Doku schreiben.

5. Software lässt sich verändern.
en:Shnark kann nach einigen Wochen als Troll auf mw:Talk:ResourceLoader aufschlagen und in die gleiche Tute tuten. Konstruktiv und das Anliegen verdeutlichend wäre, Code wie unten beizugeben. Ob das degoutiert wird oder als Bevormundung / mangelndes Vertrauen in das Können aufgefasst werden würde, kann ich nicht absehen. Du kannst ja auch mw:User und Developer werden, dies zumindest anbieten, und auf verständliche en/de Dokumentation der Public Funktionen für Benutzer achten.

Nach if ( typeof modules === 'string' ) { wäre in den 810er Zeilen einzuarbeiten:

// ++   tolerating superfluous whitespace
modules = modules.trim();   // JavaScript 1.8.1 alternatively
if ( modules.substr( 0, 2 ) == '[[' && modules.substr( -2, 2 ) == ']]' ) {
   modules = modules.substr( 2, source.length - 4 );
   modules = modules.trim();   // JavaScript 1.8.1 alternatively
   modules = modules.replace( / /g, '_' );
   if ( modules.indexOf( '%' ) < 0 ) {   // avoid encoding of encoded
      modules = encodeURIComponent(modules);
      modules = modules.replace( /%2F/ig, '/' ).replace( /%3A/ig, ':' );
   }
   modules = mediaWiki.config.get( 'wgScript' ) + '?action=raw&title=' + modules;   // actually this.config.get() ?
}
if ( typeof type === 'undefined' ) {
   if ( modules.substr( -3, 3 ).toLowerCase() == '.js' ) {
      type = 'text/javascript';
   } else if ( modules.substr( -4, 4 ).toLowerCase() == '.css' ) {
      type = 'text/css';
   }
}
// ++  added absolute path on the current server
if ( modules.substr( 0, 7 ) == 'http://'
  || modules.substr( 0, 8 ) == 'https://'
  || modules.substr( 0, 1 ) == '/' ) {
  // ... ... ... ... as is right now, around line 820
}

String.prototype.trim() defined in mediawiki.js (lines 6...11) and JavaScript 1.8.1

Das entspricht in etwa der Funktionalität von importScriptStyle, erzwingt aber bewusst eckige Klammern mit dem Hintergedanken WhatLinksHere.

Das eigene Projekt ist damit benutzerfreundlich abgedeckt. Mit anderen Sprachen und Schwesterprojekten ist das tückischer; hier sind je nach http/https die Pfade unterschiedlich, zu anderen Sprachen desselben Projekts wird man zurzeit noch weitergeleitet.

6. Es ist Usus, mit „deprecated“ nur zu entmuntern, tatsächlich aber die Funktionalität nie abzuschalten. Manchmal passiert es dann aber doch, ätsch. In Java gibt es Funktionen usw., die schon seit 1.1 (also seit über zehn Jahren) deprecated sind. Außer dass man beim Kompilieren abschaltbare Warnungen flimmern sieht, hat das keine Folgen. Bei gelegentlicher Überarbeitung des Codes stellt man das dann auf die aktuelle Logik um.
Bei uns gibt es auch noch Zigtausende von Artikeln mit prettytable, und selbst cologneblue wird behelfsmäßig unterstützt.
Wenn LEGACY in 1.7 Vorgabe ist, in 1.8 noch als Projekt-Konfiguration eingestellt werden kann und mit 2.0 aus dem Code herausgenommen wird, weil die Wartung von Ruinen zu viel Aufwand nach sich zieht, ist das völlig okay. Man kann sich immer noch eine weltweite Wrapper-Emulation schreiben, die wikibits simuliert, und sie in Einzelprojekte einbinden.

Schönen Sonntag --PerfektesChaos 19:05, 6. Nov. 2010 (CET)

5.: Der richtige Weg wäre bugzilla:, jetzt habe ich gerade keine Zeit dazu, aber falls ich mal dazu komme, und du oder sonstwer es nicht vorher schon gemeldet hat, werde ich es demnächst als enhancement vorschlagen.

6.: Das einzige in Mediawiki, bei dem ich weiß, dass es mal als deprecated gekennzeichnet wurde und dann wirklich entfernt wurde, ist die query.php, der Vorläufer von api.php. Man könnte natürlich jetzt Nachforschungen anstellen um daraus Schlüsse zu ziehen, wie freudig die Programmierer beim Entfernen solcher Dinge sind, aber andererseits, wir gehören zu denen, die ziemlich schnell den modernen Ersatz verwenden, und ob andere damit Probleme bekommen, ist zumindest mir ziemlich egal.

Viele Grüße --Schnark 09:33, 8. Nov. 2010 (CET)

PS: Kannst du mir bitte selbst dann antworten, wenn es nichts zu antworten gibt? Ich muss nach der Farbänderung des Kackbalkens mein CSS verändern, dass er zumindest etwas auffällt, dazu brauche ich aber eine neue Nachricht auf meiner Diskussionsseite.

Die erwünschte Null-Antwort. Ansonsten passt das schon, was du schreibst. Bunte Grüße --PerfektesChaos 21:06, 9. Nov. 2010 (CET)

Mein Neuer-Nachricht-Balken sieht jetzt so aus, wie ich mir das vorstelle und ad 5.: bugzilla:25845. Viele Grüße --Schnark 09:08, 10. Nov. 2010 (CET)

Dieser Mike M. hat mir aus der Seele gesprochen. Nun schau'n wir mal, was sich in den nächsten Wochen tut, und dann gibt es notfalls den Quellcode auf die Talkpage. (2px solid red) Mehr als das kann man zum Wohl der weltweiten Community nicht tun. --PerfektesChaos 16:12, 10. Nov. 2010 (CET)

Ein Diff, der direkt für patch verwendet werden könnte, wäre den Programmierern sicher lieber als ein gerahmter Quellcode auf der Disk … --Schnark 11:10, 11. Nov. 2010 (CET)

toolbar.js

Für alle, die mein toolbar.js-Skript eingebunden haben und zufälligerweise hier noch mitlesen, oder gerade hierher gekommen sind, um sich darüber zu beschweren: Ich habe gerade eine etwas größere Umstellung vorgenommen, die aber eigentlich keine negativen Auswirkungen haben sollte. Falls irgendetwas wider Erwarten nicht funktionieren sollte, bitte zunächst einmal den Browser-Cache leeren, wenn das noch nicht hilft, evt. den Browser neustarten (war bei mir einmal aus irgendeinem Grund hilfreich) und wenn das auch nichts hilft hier beschweren. --Schnark 10:25, 16. Sep. 2010 (CEST)

Nochmal ein Nachtrag: Es sollte sich eigentlich gar nichts geändert haben durch meine Aktion gerade eben, falls doch, bitte sofort melden. --Schnark 10:09, 14. Okt. 2010 (CEST)

Hallo erstmal Schnark, ich weiß ja nicht ob du es wusstest aber es gibt jetzt scheinbar ein offizielles Pendant (Alternative?) zu deinem Script auf Commons. Beste Grüße -- Perhelion 22:39, 9. Nov. 2010 (CET)

Das was dieses Skript tut, kann meines auch, nur mit <, >, " und & hat meines noch Probleme. Wie jenes Skript auf Commons das tut, verstehe ich gerade nicht, ich habe aber das Gefühl, dass es sich um einen ganz üblen Hack handelt, der bei mir gar nicht das tut, was er tun soll, und auf de sowieso nicht funktionieren würde. --Schnark 09:29, 10. Nov. 2010 (CET)

Nachdem ich das entsprechende Skript auf pt.wikibooks betrachtet habe: Die Commons-Lösung tut bei mir nicht das, was sie soll (ich kann nicht zwischen verschiedenen Sonderzeichengruppen wählen) und hat einen mir immer noch unverständlichen Quelltext. Die pt.wikibooks-Lösung ist ein Hack, der zufällig funktioniert, auf de vermutlich nur mit einigen Mühen funktionieren würde und auch ansonsten nicht wirklich empfehlenswert ist. --Schnark 11:08, 11. Nov. 2010 (CET)

Also ich habe mir das auch noch nicht genau angeschaut, jedenfalls waren die Edittools das Menue unter dem Textfenster wo (auf Commons) User:DieBuche (mit Unterstützung von Krinkle) mitzuspielen scheint. Vielleicht wurde ganz grob gesagt nur das Menue einfach nach oben versetzt (ohne es vollständig anzupassen oder zu integrieren). Ich würde mal schätzen da dies erst diese Woche passiert ist, dass es über kurz oder lang auch hier (live) eingesetzt wird.Vorlage:Smiley/Wartung/hammer  Bis denne -- Perhelion 13:43, 11. Nov. 2010 (CET)

Auf Commons habe ich jetzt keine Auswahl mehr, ich kann nur auf die Zeichen zugreifen, die bisher unter Standard waren. (Bei pt.wikibooks dagegen funktioniert es.) Wie das Ganze funktioniert, verstehe ich immer weniger, da nirgendwo pages['foo'].characters belegt wird. Um das zu übernehmen, müsste man einigen Code in Common.js aufnehmen und zusätzlich Edittools.js komplett umschreiben. Ich hoffe, dass hier kein Admin bereit ist, das zu tun. Persönlich halte ich diese Änderung für den größten Unfug. --Schnark 09:57, 12. Nov. 2010 (CET)

PDler

Hi, please check the talk page of en:shnark@wp. --PerfektesChaos 19:43, 21. Nov. 2010 (CET)

Keine Eile, ggf. 15k abwarten. Siehe a.a.O. --PerfektesChaos 13:12, 22. Nov. 2010 (CET)

see summary --PerfektesChaos 22:13, 5. Dez. 2010 (CET)

Personendaten und Kategorien werden vollständig verschoben

Hallo Schnark, ich versuche es jetzt einmal bei Dir, da der von mir beobachtete Fehler nur auftritt, wenn die Personendaten bearbeitet werden. Ganz, ganz selten beobachte ich, dass die Personendaten und die Kategorien entweder an den Anfang des Artikels oder an eine für mich noch willkürliche Stelle innerhalb des Textes verschoben werden. Als Beispiel schaue Dir bitte einmal den Artikel von Dulce von Barcelona an (ich habe diesen Artikel nicht abgespeichert). Viele Grüße --Silke Ewering 08:28, 25. Nov. 2010 (CET)

Den Fehler mit den Kommentaren hinter Kategorien habe ich inzwischen behoben. Bei Dulce von Barcelona ist das Problem das kleingeschriebene [[bild:. Mein Skript hält das fälschlicherweise für einen Interwiki-Link, setzt also die Personendaten direkt obendrüber. Das gleiche Problem tritt immer auf, wenn am Anfang einer Zeile ein kleingeschriebener Link mit Doppelpunkt vorkommt. Das sollte eigentlich nicht so häufig vorkommen, aber ich setze es mir auf meine Todo-Liste. Viele Grüße --Schnark 10:19, 25. Nov. 2010 (CET)

Ich möchte dir ja nicht die Freude am Tüfteln nehmen, knacke aber schon längere Zeit an dem gleichen Geraffel.

1. Hinten anfangen.
   • Solange die letzte Zeile angucken, ob sie
     1. nicht mehr: [[iw: oder <!-- oder {{Link
     2. oder schon deutschsprachige [[Kat ist,
     3. oder nichts davon.
   • Es gibt öfters die falsche Anordnung: erst IW, dann Kat; obige Regel greift narrensicherer.
   • Ein nagelneuer Artikel ohne PD hat möglicherweise weder IW noch Kat; wird auch erfasst.
2. Ich musste auch leiden unter [[doi: und [[bd: -- du kannst ja testen, ob function Utl_isO_639_1() bekannt ist. Seitdem kann mich auch die re:publica nicht mehr aus der Bahn werfen.

Viel Spaß --PerfektesChaos 17:05, 25. Nov. 2010 (CET)

Der letzte Tip hilft nicht, da ich und Silke dein Skript nur beim Bearbeiten einbinden, für die anderen danke ich. Sehr spaßig sind auch Weblinks mit versehentlichen doppelten eckigen Klammern, die man sehr gut als IW-Links zur Sprache http deuten kann … Verschneite Grüße --Schnark 09:13, 26. Nov. 2010 (CET)

1. Du kannst gern die Funktion aus d.js herauskopieren, solange du die Kommentarzeile mit dem Datum etc. drinlässst.
2. Wenn du Updates wünscht, kannst du auch 31kB importieren.

Von hinten angefangen, wäre dies aber nicht nötig; hier ist "\n *(\\[\\[ *[a-zA-Z][a-zA-Z][a-zA-Z]?[-:]|<!--|{.Link\\b|\n)" ein zuverlässiger Indikator, noch eine Zeile nach oben zu gehen, sonst die PD einzufügen (Punkt gegen Doppelklammer). – Wenn ich noch nicht dran war, gibt es vereinzelt Großbuchstaben in den Sprachen. – bat-smg:Žemaitiu kalba wäre auch IW.

Eine umfassende Analyse vom Artikelanfang her ist recht aufwändig, function wikiobject_Wikilink_Language() zeigt die Komplexität, ist aber Objekt-Methode und nicht wie Utl_ ein freies Utility.

Wenn dir das Leben Steine in den Weg legt, bau was Schönes draus. Wenn ein paar Schneeflöckchen rieseln, bau ein Schneemännchen damit. --PerfektesChaos 14:08, 26. Nov. 2010 (CET)

Ich versuche es mal mit /(?:\{\{Link [FG]A\|[^}]*\}\}|\[\[(?:[a-z]{2,3}(?:-[a-z]+)?|simple):[^\]]*\]\]|<!--(?:[^-]|-[^-]|--[^>])*-->|\s)*$/, mal sehen, ob sich das so verhält wie es soll. --Schnark 10:13, 2. Dez. 2010 (CET)

1. Stimmt, simple gibt es auch noch (steht auch in wikiobject_Wikilink_Language)
2. Sollte flutschen, wenn von hinten (lastIndexOf("\n", previous)) auf jeden Zeilenbeginn angewendet – leider kennt JS kein searchBackwardInverted. Von vorn hängt er am ersten [[doi: fest. Gleichwohl würde ich ein i flag anhängen, aus leidvoller Erfahrung.

--PerfektesChaos 12:46, 2. Dez. 2010 (CET)

Mein Hauptproblem ist die Tatsache, dass ich weder weiß, wie reguläre Ausdrücke in Javascript offiziell funktionieren sollten, noch, wie sie in den einzelnen Browsern funktionieren. Alles, was ich sagen kann, ist, dass der obige Ausdruck in Perl das täte, was ich will, das er tut, und dass er bei mir im Firefox sich ebenfalls so verhält, wie er sollte. Bei allem anderen warte ich einfach mal auf die erste Beschwerde. --Schnark 09:06, 3. Dez. 2010 (CET)

1. Die erste Beschwerde wird kommen, sobald bd: oder [[doi: in einem Artikel stehen.
2. Es ist noch nicht ganz Nikolaus, aber ich habe da mal was vorbereitet …

function findePDeinfuegepunkt(artikel) {
   // Finde geeigneten Platz zum Einfügen der Vorlage:Personendaten.
   // Precondition:
   //    artikel  -- Gesamter Quelltext eines Artikels (string)
   // Postcondition:
   //    Gibt Punkt (Zeilenende) zurück, wo PD eingefügt werden soll
   //    (PD beginnend mit Leerzeile und Zeilenumbruch einfügen).
   // 2010-12-03 PerfektesChaos@de.wikipedia
   var k  =  artikel.length;
   if (k > 0) {
      var j;
      var re  =  "\n[ \t]*(\\[\\[ *([a-z][a-z][a-z]?[-:]|simple:)"
                 +       "|<!--"
                 +       "|\\{\\{ *Link +[FG]A"
                 +       "|\n)";
      re  =  new RegExp(re, "i");
      if (artikel.charCodeAt(k - 1)  ==  10) {
         k--;
      }   // artikel endet mit \n
      j  =  k;
      while (j > 0) {
         j  =  artikel.lastIndexOf("\n",  k - 1);
         if (j >= 0) {
            if (artikel.substr(j).search(re) == 0) {
               k  =  j;
            } else {
               j  =  -2;
            }   // entspricht Zeilenbeginn Interwiki etc.?
         }   // noch ein Zeilenumbruch zuvor
      }   // while
   }   // artikel existiert schon
   return k;
}   // findePDeinfuegepunkt()


//  Um Zeile 540
var index = findePDeinfuegepunkt(personendaten.text);
personendaten.text = personendaten.text.substr(0, index) + kat
   + "\n\n" + pd
   + '<!--Ende der Personendaten-->' + personendaten.text.substr(index);
// Kosmetik mit Leerzeilen vorher/nachher sollte erst anschließend folgen.

3. Die Freunde von der {{cite-Fraktion fügen gern mal ein {{link für mongolische Artikel ein. Obiger Code müsste narrensicher sein, auch bei leerem Artikel und mit ohne alles. Auch 10 Jahre alte Brauser werden es verstehen. Schönes Wochenende --PerfektesChaos 17:12, 3. Dez. 2010 (CET)

Danke für das Beispiel unter 1, den Code unter 2 und die Rechtschreibfehlerkorrektur auf der Beschreibungsseite, ich werde es mir übers Wochenende anschauen. Falls du dich übrigens für ein paar konkretere Glaskugeleien zum RessourceLoader interessierst, werden auf mw:MediaWiki roadmap/1.17 möglicherweise ernst gemeinte Daten genannt. Viele Grüße --Schnark 10:03, 4. Dez. 2010 (CET)

• Am Anfang mangelhafter und rudimentärer Artikel steht oft [[wp:belege]] usw. – auch unmittelbar am Zeilenanfang.
• Ich habe die obige Funktion nochmal überschlafen und im Traum verfeinert – für den Fall, dass am Artikelende ein \n und ein Leerzeichen stehen.
  Das Doofe ist, dass JS-Regexp kein "End-of-buffer" kennt, im Unterschied zu POSIX-Regexp, Elisp etc. Zwar gibt es "$", das verhält sich aber bei multi-line strings unvorhersagbar.
• roadmap/1.17 liest sich spannend; ich plane mit meiner Skriptversion 3.0 auf die en:WP umzuziehen. Dazu sollte gern schon der RL alive und zum Real-Test verfügbar sein.
• Auf bugzilla und RL:Talk haben die developer nicht geantwortet; hatten ausreichend Zeit und Gelegenheit dazu gehabt.
  Oben schriebst du: „Ein Diff, der direkt für patch verwendet werden könnte, wäre den Programmierern sicher lieber als ein gerahmter Quellcode auf der Disk“ – Äh, wie hast du das rein technisch gemeint? Ich habe von dem Procedere keine Ahnung. Vielleicht kriegst du ja noch was bewegt in diesem Jahr; mw:MediaWiki roadmap/1.17#Niceties / possibly important in real deployment klingt träge: Would not be a big problem if deferred to 1.18 – das ist 2012. Herzlich lachen musste ich über we've been structuring R-L the same way since forever; in deutschen Behörden und Betrieben bekannt als das haben wir schon immer so gemacht, da könnte ja jeder kommen …

Enjoy --PerfektesChaos 16:23, 4. Dez. 2010 (CET)

function findePDeinfuegepunkt(artikel) {
   // Finde geeigneten Platz zum Einfügen der Vorlage:Personendaten.
   // Precondition:
   //    artikel  -- Gesamter Quelltext eines Artikels (string)
   // Postcondition:
   //    Gibt Punkt (Zeilenende) zurück, wo PD eingefügt werden soll
   //    (PD beginnend mit Leerzeile und Zeilenumbruch einfügen).
   // 2010-12-04 PerfektesChaos@de.wikipedia
   var k  =  artikel.length;
   if (k > 0) {
      var j;
      var re  =  "\n[ \t]*(\\[\\[ *([a-z][a-z][a-z]?[-:]|simple:)"
                 +       "|<!--"
                 +       "|\\{\\{ *Link +[FG]A"
                 +       "|\n)";
      re  =  new RegExp(re, "i");
      j   =  artikel.charCodeAt(k - 1);
      while (j <= 32) {
         k--;
         if (k > 0) {
            j   =  artikel.charCodeAt(k - 1);
         } else {
            j  =  99999;
         }
      }   // artikel endet mit \n (+whitespace)
      j  =  k;
      while (j > 0) {
         j  =  artikel.lastIndexOf("\n",  k - 1);
         if (j >= 0) {
            if (artikel.substr(j).search(re) == 0) {
               k  =  j;
            } else {
               j  =  -3;
            }   // entspricht Zeilenbeginn Interwiki etc.?
         }   // noch ein Zeilenumbruch zuvor
      }   // while
   }   // artikel existiert schon
   return k;
}   // findePDeinfuegepunkt

Solange $ auch in Multi-Line-Strings nur das String- und nie das Zeilenende matchen, funktioniert mein Ausdruck so wie er soll, auch wenn zwischendurch mal etwas auftauchen sollte, das wie ein IW-Link aussieht. Zumindest FF 3.6 und IE 8 antworten auf javascript:alert('a\nb'.match(/a$/)) wie gewünscht mit null. Bei deinem Code bin ich mir auch nicht ganz sicher, ob er sich bei mehrzeiligen Kommentaren korrekt verhält.

ad Patch: Man nehme den aktuellen Code, ändere ihn so, wie man es gerne hätte, erzeuge mit diff (vermutlich am besten -u) einen Diff, und füge dem Bug diesen als Attachment und als Keyword patch zu. Falls du keinen Bugzilla-Account hast und keinen anlegen willst, kannst du den Patch natürlich auch hier auf die Diskseite packen, dann überführe ich ihn nach Bugzilla. Allerdings hieß es vor ein paar Wochen einmal ([9]), dass es "bald" eine völlig neue mediaWiki.loader.load-Funktion geben soll, die keine Strings, sondern Objekte übernimmt und alles, worauf man sich bisher eingestellt hat über den Haufen wirft. Siehe auch bug:25962.

Viele Grüße --Schnark 09:30, 6. Dez. 2010 (CET), Nachtrag des Mailinglistenposts --Schnark 09:52, 7. Dez. 2010 (CET)

1. ad Patch: Um deine Disku nicht völlig zuzumüllen, siehe Benutzer_Diskussion:PerfektesChaos #loader.load() mit freundlicher Bitte um Bugzilla.
2. Bei einem mehrzeiligen Kommentar in der IW-Liste würde mein Algorithmus zuerst finden: \nLetzte Zeile--> und an dieser Stelle stoppen, wenn man nicht ganz bösartig \n<!--\n[[xx:qwerty]]--> schreibt. In diesem Fall würde er jedoch einfach weitermachen und hätte den ganzen Kommentar übersprungen. Nur bei einem entsprechend trickreichen dreizeiligen Kommentar würde er innerhalb des Kommentars landen und die PD wären somit auskommentiert. Mehrzeiliger Kommentar hat in der IW-Liste aber nichts zu suchen; hier wäre manuell aufzuräumen.
3. $ und Multi-Line: Leider eine der wackligsten Angelegenheiten mit Nebenwirkungen.
   • $ bedeutet "Zeilenende", wenn multiline "wahr"; Buffer-Ende=String-Ende, wenn multiline "falsch". Siehe mozilla.org
   • Vorgabe (Default) für RegExp.multiline war früher global "falsch", ändert sich scheinbar mit JS 1.7/1.8 auf "wahr".
   • Beliebige andere zuvor ablaufende JS-Software (Mediawiki) kann die globale Vorgabe umdefinieren.
   • Neben dem globalen RegExp.multiline hat jede RE-Instanz inzwischen eine eigene multiline property mit geerbter Voreinstellung. RegExp/multiline – Global wird trotzdem unterstützt, ist aber "deprecated".
   • Das "m" flag wurde von IE 6/7 nicht verstanden; IE7 kam mit String-Ende nicht klar.
   • Die Interpretation, ob bei fehlendem "m" flag nun multiline gilt oder nicht, ist also unklar; es gibt auch kein explizites "-m" zum Abschalten, sondern nur .multiline=false.
4. Neue Sauereien
   • Du kanntest meta:Interwiki map vielleicht schon, ich habe es schreckgeweiteten Auges am Sonntag entdeckt und bei mir in einen Konfigurationsparameter gewandelt.
   • wg Aew BLW Dcc DOI IRC rev RFC svn WMF Wqy ZUM
     Sie funktionieren case-insensitiv; mindestens RFC, ZUM sind neben DOI ANR-fähig, einige wenige dieser anderen 2/3-Buchstaben-Codes könnten gelegentlich im ANR auftauchen. Mir war zuvor schon ein Mineralienatlas: untergekommen.
   • bugzilla: gehört auch dazu, bug:25962 ist Buginese.

Viele liebe Grüße --PerfektesChaos 20:52, 7. Dez. 2010 (CET)

1. Patch hinzugefügt, ich hoffe, ich hab alles richtig gemacht, wir werden sehen, was damit passiert.
2. Mehrzeilige Kommentare zwischen Interwikis könnten durchaus vorkommen, bei Liste von Erdbeben könnten die beiden auskommentierten Links durchaus in einem Kommentar zusammenstehen.
3. Ich überlege derzeit, ob ich, da ich ja sowieso nur an der Position interessiert bin, mit einem .replace(/\n/g, ' ') zwischendrin alle Probleme mit Multiline umschiffen kann.
4. Immer aktuell: http://de.wikipedia.org/w/api.php?action=query&meta=siteinfo&siprop=interwikimap
5. Da für den durchschnittlichen Wikipedia-Benutzer Bugzilla und Buginese ungefähr gleich gut zu verstehen sind, passt es doch … Viele Grüße --Schnark 09:38, 8. Dez. 2010 (CET)

@2) Mehrzeilige Kommentare – das würde die IW-bots möglicherweise irritieren; das Format, auf das du mich freundlicherweise aufmerksam machtest, sah einzelnes IW-Auskommentieren vor. Meinen Code-Vorschlag würde es hingegen nicht stören, weil dabei jede Zeile übersprungen wird, die mit IW oder <!-- beginnt.

@3) Also – durch Leerzeichen ersetzen, würde das Problem der Fehlplatzierung bei Suche von vorn noch verschärfen; damit würden noch mehr an [[wp: und [[bd: und [[doi: gefunden werden. Wenn du schon unbedingt nach Oberschüler-Art hacken möchtest, dann ersetze durch \f oder \v – die werden von Wikimedia nicht ausgeliefert, und du kannst dann wenigstens nach diesem Zeichen i.V.m. \f *[[xxx?: suchen. Du kannst aber auch in den Nikolaus-Stiefel greifen und die o.a. Funktion einkopieren, sie liefert schon den bestmöglichen Index.

@4) A script copies the list below into the database fairly regularly (usually once in several months). – meta:Interwiki map ist die Quelle, Last known interwiki database update: 13 November 2010 ist die daraus generierte DB@API.
Im Übrigen ist das ganze technische Konzept dieser Pseudo-Interwiki außerhalb der wikimedia.org ziemlicher Mist, weil hierfür Vorlagen besser geeignet und die URL leichter zu pflegen sind. Für wenige international anerkannte DOI, RFC, arXiv, IMDb mag es angehen, aber da wurde auch jede Menge Müll registriert.
Ich muss aber jetzt in meinem Skript die Linkziele der dynamischen URL vor Veränderung schützen. Grrr. Zumindest im ANR der de:WP ist dieser Murks wenigstens selten.

--PerfektesChaos 20:06, 8. Dez. 2010 (CET)

Marcel Arland

Danke für die Verbesserungen. Der Fehler im Weblink zur DNB war mir schon aufgefallen, nur wußte ich nicht, wie ich an die korrekte Kennziffer komme. Vielleicht kannst du mich aufklären. Und: welche Bewandtnis hat es denn mit den Norm- und Personendaten, die du eingefügt hast? Gruß --Datschist 14:43, 18. Dez. 2010 (CET)

Hallo Datschist! Die Personendaten sind Metadaten, die vor allem für die automatisierte Auswertung gedacht sind, so wurde der Artikel beispielsweise von einem Bot in die Liste der Biografien aufgenommen. Weitere Informationen und Anwendungen findest du unter Hilfe:Personendaten. Ähnlich dienen die Normdaten zur Verknüpfung mit anderen Personendatenbanken, besonders mit Bibliotheken. Die Verlinkung durch die DNB auf den Wikipedia-Artikel beruht beispielsweise auf diesen Daten. Auch hier gibt es eine Hilfeseite: Wikipedia:Normdaten. Wie du die PND zu einer Person findest ist unter Hilfe:PND#Wie findet man die PND? erklärt, ich persönlich bevorzuge die zweite Variante über die VIAF, da man dabei auch die anderen Nummern für die Normdaten gleich mitgeliefert bekommt. Viele Grüße --Schnark 09:18, 20. Dez. 2010 (CET)

Zu Weihnachten ...

... viele Wünsche nach Freiburg, laß es dir ruchig ergehen, mit vielen Grüßen -jkb- 17:22, 24. Dez. 2010 (CET)

Danke! Ich hoffe, du hattest auch schöne Weihnachten. Viele Grüße --Schnark 10:01, 27. Dez. 2010 (CET)

Finder

Danke für den neuen Link auf userregfinder, hab's total vergessen dass ich dort noch das alte Tango-tool habe. Hat eigentlich jemand schon die Idee gehabt, solche Tools irgendwie zentral oder als Benutzergruppe zu pflegen, damit nicht immer wieder irgendwelche Tools weg sind weil "account expired"? Gruß und auch danke für deine Wünsche, -jkb- 11:14, 27. Dez. 2010 (CET)

Wenn ich mich recht erinnere, dann stehen inzwischen alle Tools unter einer freien Lizenz, sodass beim Weggang eines Toolbetreibers ein anderer das Tool übernehmen kann. Früher war das nicht so, und wenn ich mich recht erinnere, war das auch einer der Gründe, warum diese Tools abgeschaltet wurden. Viele Grüße --Schnark 11:25, 27. Dez. 2010 (CET)

's gibt wichtigeres zu verbessern, dennoch beruhigend :-). Danke, -jkb- 11:28, 27. Dez. 2010 (CET)

Commons:Commons:Forum#Neues Gadget fuer automatische Uebersetzung

Hallo Schnark. Viellicht interessiert dich diese Diskussion (wo ich dein extratabs.js erwähnt habe). --Leyo 09:41, 7. Jan. 2011 (CET)

Hab dort meinen Senf hinterlassen. --Schnark 09:51, 7. Jan. 2011 (CET)

fullscreen.js

Hallo Schnark, ich muss dir mal ein Würdigung für deine Skripte aussprechen. Das fullscreen.js ist klein aber sehr fein.(für Netbooks ausgezeichnet) LG -- Perhelion 22:13, 9. Jan. 2011 (CET)

Als Warnung: Beim Schreiben des Skripts ist mir mein Browser oft genug abgestürzt. Ich glaube zwar, dass jetzt alles so funktioniert, wie es sollte, aber ein bisschen Vorsicht ist in der Anfangszeit geboten, zumal ich das Skript im Augenblick selber nicht verwende und so Fehler nicht selber finden kann. --Schnark 09:36, 10. Jan. 2011 (CET)

Ok, danke der Warnung. Ich benutze hauptsächlich den FF, manchmal noch IE oder Chrome, bist jetzt nichts aufgefallen (verschiedene PCs). Eine kleine Inkompatibilität zum "Monobook" Frame von (Benutzer:)PDD besteht jedoch, das liegt aber eher an diesem. Da dieses eine absolute Position hat, könnte man es auch durch ein Mouseover ein- und ausblenden lassen. (das wär noch das Wenigste). Vorlage:Smiley/Wartung/:)  Momentan will ich auch wieder etwas JS basteln. LG -- Perhelion 16:52, 10. Jan. 2011 (CET)

wikieditor.js

Hallo Schnark, ich teste gerade deine Module weiter. Jedoch ist bei der neuen Werkzeugleiste ein Bug (wie ich meine) aufgetreten. Sie erscheint erst wenn ich auf die Standard/Erweitert/Debug klicke. :(. Meine Konfiguration scheint auch gänzlich ignoriert zu werden. :( Und die Erklärung ist (wie ich meine) ein klein wenig verwirrend. Vorlage:Smiley/Wartung/:s  LG -- Perhelion 18:04, 11. Jan. 2011 (CET)

Du bindest mein Skript zweimal ein, zuerst mit meiner, dann mit deiner Konfiguration. Da meine Modulverwaltung aber Doppeleinbindungen ignoriert, wird deine Konfiguration ganz zu Recht nicht beachtet. Wenn du die Zeile jsmodules.load('[[Benutzer:Schnark/js/wikieditor.js]]', {before: '[[Benutzer:Schnark/js/Wikieditor-config.js]]'}); entfernst, dann könnte/sollte/müsste es funktionieren. --Schnark 09:09, 12. Jan. 2011 (CET)

Danke und sorry (habe dich gar nicht gesehen in meiner Beo). Ja, hätte ich auch drauf kommen können Vorlage:Smiley/Wartung/hm . Funzt jetzt problemlos! Also ich muss sagen deine neue Bar ist wirklich sehr vielversprechend und toppt alle meine Erwartungen.Vorlage:Smiley/Wartung/anbet  Dann hätte ich noch die kleinen Fragen, die sich mir bei der Anleitung gestellt haben. Stimmt es dass ich die alten Befehlsnamen hätte nicht ändern brauchen? Mit der doppelten Modul-Einbindung war jetzt auch nicht ganz so eindeutig. Die modulisierte persönliche Konfiguration ist ebenfalls was ganz neues (bin mir nicht ganz sicher über einen wirklichen Anwendervorteil, deshalb nehme ich noch etwas Abstand davon). Ich habe einfach mal dein vector übernommen, dabei ist mir aufgefallen dass diese noch(?) auf dich persönlich zugeschnitten sind (oder sind diese noch nicht als allg. Module freigegeben)!? PS: stelle grad fest dass den Smilies ein Semikolon; angehengt wird. Beste Grüße PS: Somit fehlt nicht mehr wirklich viel für den Monobook-Ersatz von PDD -- Perhelion 20:19, 14. Jan. 2011 (CET)

Die alten Befehlsnamen musstest du ändern, nur wenn du um meine jsmodules.js einen großen Bogen gemacht und einfach importScript('Benutzer:Schnark/js/wikieditor.js'); geschrieben hättest, wären Befehle für die (fast vollständige) Abwärtskompatibilität eingebunden worden. Der Hintergrund ist der, dass Benutzer, die nichts ändern wollen, einfach nur die Zeile für die Einbindung ändern müssen, die anderen aber nicht den alten Ballast mit sich schleppen müssen. Was in meiner vector.js steht, hat nicht unbedingt viel mit dem zu tun, was bei mir an Skripten wirklich eingebunden wird, da ich (was du auch kannst) per Cookies unter Benutzer:Schnark/js/modulverwaltung#Konfiguration deiner Skripte alles mögliche ein- und ausschalte. (Einer der Vorteile meiner Einbindungsfunktion.) Das Semikolon sehe ich im Quelltext auch, sobald ich ein bisschen darüber meditiert habe, wie es da rein kam, werde ich es entfernen. --Schnark 09:34, 15. Jan. 2011 (CET)

Ein Wochenende im Spukschloss

Was habe ich gelernt?

1. Bislang kein Erröten, steht aber in den Scans, kein WikEd; nur HexEdit von raw half:
   • 200B;ZERO WIDTH SPACE
   • 202C;POP DIRECTIONAL FORMATTING
   • U+2715 wird rot, U+2716 nicht.
2. Neu: 2044;FRACTION SLASH   Nur in: Vorlage:Bruch sinnvoll
3. U+2122 ™ TradeMark ist zulässig nach lateinischen und beliebigen Buchstaben
4. NBSP sollte als U+00A0 hellgrauen statt rötlichen Hintergrund bekommen, analog zu office.org
5. Benutzer:Schnark/Wartung/Unsichtbar/Ausnahmeliste#MacArabic editieren und über letzte Zeile staunen; in den nächsten Tagen werde ich hier etwas forschen
6. lrm und rlm sollte vom js und künftigen Scans ignoriert werden, wenn links bzw. rechts davon ein Zeichen U+0590--08FF oder (seltener) U+FB50--FDFF U+FE70--FEFF U+10800--10FFF steht; eigentlich reicht auch umgekehrt positiv U+0007--U+058F. Siehe Liste der Unicode-Blöcke
7. Die beiden nullbreiten Zeichen zw*j sind innerhalb U+0590--109F okay. Was zwj (8205) am Ende der Zeichenkette macht, so in Links auf ml:WP üblich und notwendig, müsste mal ein Sprachexperte erläutern. Eigentlich müsste man die zw*j am Anfang/Ende einer Zeile (auch vor und nach Leerzeichen) doch löschen können? Traue ich mich aber nicht.

Wenn ich keinen Widerspruch lese, werde ich deine Wartungsseiten allmählich etwa wie folgt umstrukturieren:

/Wartung --+-- /LeerNull --+-- /Dump.2011-01
                           +-- /Ausnahmen
                           +-- /Nichtlat
                           +-- /Gesperrt

bzw.

/Wartung --+-- /Strich --+-- Dump.2011-01

Hintergrund ist, dass die Dumps und Scans irgendwann überholt sind und gelöscht werden sollten; die Ausnahmelisten enthalten jedoch Infos, die bleiben sollten. Dann müssen die bleibenden Seiten aber im "Pfad" zuerst stehen.

Eine begeisternde Woche wünscht nach Ende der Gespensterstunde --PerfektesChaos 01:20, 24. Jan. 2011 (CET)

1. 200B und 202C stehen eindeutig in unerwuenscht drin, muss ich mal genauer utnersuchen, 2716 fehlt tatsächlich (vermutlich dachte ich, dass so etwas wirklich niemand verwendet)
2. Eben weil es in Vorlage:Bruch sinnvoll ist, ist 2044 nichts für antispoof, nur für den nächsten Dumpscan.
3. Steht derzeit noch drin, da TradeMark von vielen als nicht unbedingt enzyklopädie-geeignet angesehen wird. Ich denke mal darüber nach.
4. In Kürze
5. HTML-Quelltext sieht auch sehr interessant aus <naps/> Warum können die Araber nicht auch einfach von links nach rechts schreiben?
6. In Kürze
7. In Kürze und auch keine Ahnung
8. Da ich Ausnahmen teils schon vorher von Hand rausfiltere, halte ich eine Umstrukturierung für unnötig, löschen kann man auch Seiten, ohne dass Unterseiten betroffen sind, aber ich gebe dir freie Hand. Bei Portalen bin ich übrigens keineswegs der Ansicht, dass sie grundsätzlich nach Gesperrt gehören, solange es sich nicht um einen sehr internen Arbeitsbereich handelt. --Schnark 09:22, 24. Jan. 2011 (CET)

1. 200B​200B und 200C‌200C werden eindeutig markiert, nur dann, wenn dummerweise weder links noch rechts davon etwas steht, sieht man die Markierung nicht. 2716 steht jetzt in meiner TODO-Liste.

4. Der Monitor hier ist vollkommen unkalibriert, nenn mir also einfach mal den Hex-Farbcode, den du haben willst (kann auch für jedes Zeichen ein eigener sein)

6. und 7. Stehen jetzt in meiner TODO-Liste. --Schnark 09:47, 25. Jan. 2011 (CET)

1. Die tauchten wohl auch jeweils im Artikel vor einem \n oder zwischen zwei \n auf. In der Scan-Liste standen sie zwischen den > und < der nowiki und waren deshalb dort sichtbar. Weil ich aber erst durch antispoof auf die Existenz solcher Biester kam, sind sie jetzt dem ASCII-Space gleichgestellt worden und werden nach und nach bei Trim-Operationen mit entfernt.

2. Ja; es war Dumpscan gemeint, nicht aber dargestellter Text.

3. TradeMark ist ein juristisches Merkmal. Das mag bei der Diskussion irgendwelcher Verwertungsrechte im Artikel sinnvoll und notwendig sein; ansonsten ist es stilistisch sicher unschön, von Microsoft® Windows® 7® zu schreiben – aber kein Syntaxfehler.

4. #C0C0C0 wäre ein Grauton für NBSP, der bei unterschiedlichen Lichtverhältnissen und Monitoreinstellungen deutlich von Weiß zu unterscheiden sein müsste, aber noch nicht als schwarzer Block wirken würde.

6./7. Die User Community dankt.

8. naja, ich stelle mir die erste Listen-Ebene ggf. als eine Übersichtsseite zum Thema vor, von der aus auf umfangreiche Listen-Seiten (blieb anfänglich wegen Zeitüberschreitung bei zuviel Spukzeichen hängen) als Blätter verzweigen. So plane ich für irgendeine schwache Stunde eine kleine Ausarbeitung zum Thema /RechtsLinks und deren Sinn im Wikitext. – Das Löschen hängt vom Biorhythmus und sonstigem Zustand des Admins ab; ich habe es schon erlebt, dass in dieser Situation auch ungefragt alle Unterseiten mitgelöscht werden: die haben anscheinend auch einen Knopf oder Einstellung für „/Archiv sowie /Archiv/2007 mitlöschen“. – Portale hatte ich mir angeguckt; es waren teils Disku-ähnliche Passagen, teils längst erledigte Bastelarbeiten. Die Portal/Redaktion-Leute reagieren mitunter arg allegorisch, wenn wildfremde Leute aufschlagen und in diesem Bereich unverständliche edits machen. Ändern würde ich (ggf. per Disku), wenn aktuelle Kopiervorlagen etc. im Portal stünden, deren Weiterverbreitung in den ANR zu befürchten wäre. Ansonsten agiere ich lieber diskret und rufe mir ungern schlafende Hunde an den Hals.

Einen angenehmen Tag noch --PerfektesChaos 14:15, 25. Jan. 2011 (CET)

3. Da ich offensichtlich ® erlaube, überlege ich es mir nochmal. Bei einem Zeichen, das nicht auf der Tastatur ist, ist auch so was nicht zu befürchten.

4., 6., 7. NBSP etc. werden wie korrekte RLM etc. angegraut. Viele Grüße --Schnark 09:14, 26. Jan. 2011 (CET)

Nachtrag: Gewöhnungsbedürftig auf der Beobachtungsliste --Schnark 09:16, 26. Jan. 2011 (CET)

Guten Morgen; danke für die NBSP.

Zu Beobachtungsliste und RLM äußere ich mich gerade auf Benutzer:Schnark/Wartung/RechtsLinks.

C U L8er --PerfektesChaos 09:43, 26. Jan. 2011 (CET)

Guten Morgen mal wieder,
ich muss einfach mal loswerden, dass antispoof+highlight eine echte Bereicherung für typografisch sorgfältig arbeitende Autoren sind.
Den Dumpscans konnte ich entnehmen, dass es im Artikelbestand Non-ANSI (Windows-)Zeichen 128–159 gibt, die der Server heutzutage nicht mehr akzeptieren würde. Meine Doku werde ich anpassen müssen.
Weiter so --PerfektesChaos 09:26, 27. Jan. 2011 (CET)

• War Zeit (ANR=19979). Würde statt auf der Disku versteckt besser auf die Benutzerseite passen.
• @Beobachtungsliste – bei mir ist nichts Auffälliges; aber wir arbeiten ja nicht statisch, sondern mit eingebauter Intelligenz; notfalls die Anwendung bestimmter Regeln auf ns≥0 begrenzen.
• Habe die unsichtbaren Zeichen ausgewertet; werden künftig (mit x29.js) als Entities zur Entfernung sichtbar gemacht.
• Auch die türkischsprachige WP kann ab 3.0 im Vollprogramm gleich behandelt werden.

Have a wonderful day --PerfektesChaos 01:34, 28. Jan. 2011 (CET)

2. Ich habe in meinen Einstellungen unter „Letzte Änderungen“ den Punkt „Erweiterte Darstellung der „Letzten Änderungen“ (benötigt JavaScript)“ aktiviert, damit wird die Beobachtungsliste mit vielen geschützten Leerzeichen gestylt. Da auf den Spezialseite, auf denen antispoof sinnvoll ist, (also hauptsächlich Spezial:Alle Seiten) geschützte Leerzeichen keine Rolle spielen, werden die wohl bald in ns == -1 rausfliegen. --Schnark 10:44, 28. Jan. 2011 (CET)

betr. Auszeichnung

Hallo Schnark,

wenn Du mit auf der Urkunde zeichnen möchtest muss Du es hier machen: Benutzer:Graphikus/Fleißige Biene Gruß --Graphikus 10:45, 28. Jan. 2011 (CET)

Habe im Dschungel der HTML-Tags die richtige Stelle gefunden. --Schnark 10:52, 28. Jan. 2011 (CET)

och, wenn Du sie nicht genau gefunden hättest, hätte ich die Seite wieder aufgestellt. Brauchte ja nur Deine Signatur. Und weil das ja wirklich ein Dschungel auch heute noch für mich an völlig kryptischen Zeichen ist, habe ich extra diese Unterseite angelegt. Danke Grüße --Graphikus 10:57, 28. Jan. 2011 (CET)

WikisyntaxTextMod 2.94

Hallöchen,

1. dass nach zwei Monaten ein Bug in WSTM gefunden wurde, hast du ja selbst schon mitbekommen. Allerdings mache ich routinemäßig erst mal einen längeren Abschlusstest mit der komprimierten r-Version, bevor ich dich ohnehin informiere. (Inzwischen erneuert; ich weiß nicht, ob du dazu deine Versionsnummer nochmals hochsetzen müsstest.)
2. Perhelion fand ein Problem mit dem URL-RegExp für wikimedia.org (unbekannte Subdomain stats. wurde zerwurstet); ein kleines "^" behob dies.
3. Somit sind alle für 3.0 vorgesehenen Kleinigkeiten bereits allgemein verfügbar, wie der y-Flag im RegExp (deine Anwendung werde ich versuchen noch im Laufe des Abends zu verstehen), und das Sichtbarmachen ausgewählter Spezial-Zeichen als Entities.
4. Zu sonstigen Neuerungen habe ich mich dort geäußert, wo kürzlich Edelmetall-Tierchen für fleißige Tierchen thematisiert wurden.

Viel Spaß --PerfektesChaos 18:28, 30. Jan. 2011 (CET)

1. Da ich das Skript auf meiner Beobachtungsliste habe, bekomme ich alle Änderungen auch ohne deinen Hinweis mit, zumindest wenn nicht ein ganz bestimmter Benutzer meint, die Archivierung auf allen von mir beobachteten Diskussionen umzuändern.
2. Aus 1. folgt, dass ich das auch mitbekommen habe.
3. Ich empfehle dir, nicht zu verstehen zu versuchen, was es macht, ich verstehe es nämlich selbst nicht. Das y verhält sich nicht so, wie ich es erwartet habe, und ich konnte auch nicht herausfinden, wie es sich tatsächlich verhält. Ich werde den Ausdruck daher gleich noch einmal umändern – ohne y.

Viele Grüße --Schnark 09:13, 31. Jan. 2011 (CET)

3. Irgendwie verhielt sich der Ausdruck in meiner Testumgebung so wie sollte, hier stellt er aber den größten Unfug an. Also am besten noch nicht versuchen zu verstehen und vor allem nicht verwenden. --Schnark 12:45, 1. Feb. 2011 (CET)

Die Behandlung von Anführungszeichen ist jetzt zwar eine komische Bastellösung, funktioniert aber bis jetzt gut. --Schnark 12:49, 3. Feb. 2011 (CET)

Wie kommen die Spoof-Zeichen in den Wikitext?

Du hast ja einen guten Namen im Community-Bereich; vielleicht lässt man dir einen Edit durchgehen:

• Hilfe:Textgestaltung
  geschützten Bindestrich (Unicode-Zeichen Nummer 8209 bzw. (hex) 2011): Müller&#x2011;Lüdenscheid, Regenhose und &#8209;jacke verwenden.

Besonders pfiffig ist, das -jacke zu schützen.
Es wird Frühling. --PerfektesChaos 09:43, 1. Feb. 2011 (CET)

Bist du sicher, dass es keinen Browser gibt, der die Zeile zwischen dem Bindestrich und der jacke umbricht? Einem IE 6 würde ich so etwas nämlich zutrauen. Und solange sich sowieso keiner an die dort formulierten Regeln zur Textgestaltung hält, habe auch ich keine Lust bei 175 − 1 Leuten aufzufallen. --Schnark 09:56, 1. Feb. 2011 (CET)

Hat nichts mit obigem zu tun, aber zu deiner Information: [10]. --Schnark 10:24, 1. Feb. 2011 (CET)

Hm*, dies wurde auch ohne Konsens eingefügt auch wenn es praktisch erscheinen mag. Es ist doch nur eines von zwei Entities die wirklich zu gebrauchen sind? Vielleicht sollte man doch auf breiterer Fläche fragen? Zudem ist das Bsp. wirklich schlecht, wann sollte man ihn überhaupt verwenden? Und warum stört es? -- Perhelion 11:14, 1. Feb. 2011 (CET)

Man könnte es vielleicht durch ein sinnvolleres Beispiel wie 5‑jährig ersetzen. --Schnark 11:42, 1. Feb. 2011 (CET)

Danke für techblog (was du alles für Seiten kennst), ich habe die zweite Februarwoche für eine erfolgreiche Einführungsphase vorgemerkt; war dies problemlos und ohne Rückfall auf 1.16 verlaufen, werde ich mediaWiki.config und mediaWiki.loader in unserem Kontext testen, ResourceUpdater einführen und dann WSTM auf 3.0 hacken.

Geschützter Bindestrich munkelt etwas; ich kann mich erinnern, dass vor vielen Jahren mal irgendwas Seltsames geschah, was aber auch wieder gefixt wurde. Umgekehrt beschert es aber allen anderen das Risiko, statt eines Strichs ein Quadrat zu sehen oder vor dem Strich am linken Rand noch ein Leerzeichen. Grundsätzlich ist es eine unkluge Taktik, die temporär möglichen Schwächen einer einzelnen früheren Software-Version dadurch auszutricksen, dass man den gesamten Datenbestand dauerhaft mit Krücken-Konstruktionen verseucht, und dazu auch noch „offiziell“ aufzufordern.

Das Beispiel „Müller-Lüdenscheid“ ist ja ebenfalls typografischer Unsinn, weil hier ganz normal getrennt wird, wie auch Lüden- scheid im normalen Text. Fordert man regelwidrig ein Zusammenhalten, würde es am rechten Rand eine übermäßige Lücke reißen. Der geschützte Bindestrich gehört zu sehr kurzen Bestandteilen (ein oder zwei Zeichen) wie in dem Artikel erwähnt, ansonsten etwa zu der chemischen Formel.

Ansonsten ist in HTML eine gesonderte hartkodierte Zeichenverwendung sinnlos, weil dies von den für Umbruch zuständigen Algorithmen im Browser übernommen wurde oder mittelfristig wird; die Spezialzeichen gehören weder nach HTML noch in den Wikitext, sondern in persönliche Textverarbeitung und Schriftsatz/DTP.

--PerfektesChaos 12:58, 1. Feb. 2011 (CET)

Nach Perhelions Eingriff hat es sich ja erledigt, und aufs techblog bin ich auch nur über die Mailingliste gestoßen. --Schnark 09:16, 2. Feb. 2011 (CET)

@Perhelion: Danke schön; ich gestehe, diese Seite seit mehr als fünf Jahren nicht mehr gelesen und auch nicht beobachtet zu haben. Der Hilfetext soll prägnant einen Überblick über häufige Syntaxelemente insbesondere in Wikisyntax geben, vor allem Newcomer anleiten – und keine umfassende Darstellung aller denkbaren und in bestimmten Zusammenhängen sinnvollen typografischen Feinheiten geben. Juja mit 333 edits (wohl vom Schiller-Gymnasium Pirna) war dazu wohl nicht berufen. --PerfektesChaos 09:50, 2. Feb. 2011 (CET)

Trotzdem werde ich mich zukünftig weniger in dieses Thema involvieren, bei dem Wort „5-jährig“ konnte ich mich nicht mehr beherrschen. Um den typografisch richtigen Bindestrich scheint es sich ja nicht zu handeln, s. Hilfe:Sonderzeichen#Satzzeichen unterschiedliche Größe? Nach nochmaligen Test stell ich fest das die Breite des Striches sich irgendwie verändert -- - (geschützt‑ist‑breiter?). Was in de:Wiki diesbezüglich eventuell noch fehlt ist dies: en:Wikipedia:Line break handling. -- Perhelion 10:27, 2. Feb. 2011 (CET)

Was ich jetzt festgestellt habe (ohne weiter zu recherchieren) ist, dass auf einem anderen PC die Bindestriche doch gleichlang sind (Win7, nicht gleichlang XP vermutlich einfach der Font) jedoch auch nicht optisch gleich, marginal sieht der geschützte weicher aus (am besten würde das wieder ein Screencopy zeigen, verblüffend).

-

‑

-- Perhelion 19:20, 2. Feb. 2011 (CET)

Tatsächlich bricht der IE6-8 am Bindestrich um (aber wen störts?) und beim IE6 sieht der Bindestrich auch tatsächlich gleich aus, beim IE8 ist er allerding doppelt so lang wie der geschützte!? -- Perhelion 09:56, 3. Feb. 2011 (CET)

Bei mir (FF, Arial) ist der geschützte Bindestrich etwas kürzer als der normale. --Schnark 10:03, 3. Feb. 2011 (CET)

Es gibt im resultierenden Text keinerlei Bedeutungs-Unterschied zwischen dem Allerwelts-ASCII-Bindestrich-Minus und den beiden Unicode-Varianten. Leser des dargestellten Textes brauchen keine Lupe, um aus einem Pixel oder dot Breitenunterschied irgendwelche Schlüsse zu ziehen. Es ist ins Belieben der Font-Designer gestellt, auch alle drei Strichelchen exakt deckungsgleich zu vereinbaren. Mindestens die beiden nicht für HTML, sondern für feinere Typografie gedachten Unicode-Striche sollten immer die identische Glyphe verwenden. Mahlzeit --PerfektesChaos 12:52, 3. Feb. 2011 (CET)

Wikieditor – Leiste entfernen

Hallo Schnark, erst mal vielen Dank für die tollen JS-Möglichkeiten, die du hier zur Verfügung stellst! Ich habe mal anhand deiner Anleitungen versucht, die Hilfeleiste im Bearbeiten-Fenster zu entfernen, es ist mir jedoch nicht geglückt. Könntest du einen raschen Blick auf meine vector.js werfen und mir sagen, woran es scheitert? Ist alles noch recht übersichtlich … Gruß, --Nirakka 19:02, 2. Feb. 2011 (CET)

Hallo nochmal, sieht alles ok aus von hier. Leere mal komplett den Cache vom Browser (manchmal funzt es nicht die einzelne Seite zu renewen), welchen benutzt du denn? (Vielleicht sieht Schnark den Fehler doch gleich) LG -- Perhelion 19:35, 2. Feb. 2011 (CET)

Ich leere den Cache grundsätzlich, nachdem ich Änderungen am JS vorgenommen habe. Ich verwende gerade den neusten Firefox (Stable). Gruß, --Nirakka 19:37, 2. Feb. 2011 (CET)

Drücke mal Strg+Umschalt+J, steht dort diesbezüglich ein Fehler? -- Perhelion 19:49, 2. Feb. 2011 (CET)

Hier mal ein Screenshot. --Nirakka 19:53, 2. Feb. 2011 (CET)

Problem behoben. Habe das Firefox-Addon userChromeJS mal deaktiviert und wieder aktiviert und im Zuge dessen natürlich den Browser neu gestartet. Auch wenn ich jetzt nicht weiß, ob das Deaktivieren oder der Neustart des Rätsels Lösung war – die Leiste ist jedenfalls weg. Gruß, --Nirakka 20:00, 2. Feb. 2011 (CET)

Oha* :) Das "fremde" Script wars jedenfalls (und stoppte wohlmöglich dein komplettes vector.js). Ich würde dir raten alle weiteren Scripte mittels Schnarks Modulverwaltung einzubinden (das fängt Fehler ab oder wie in der Anleitung beschrieben kannst du Module ohne zu editieren ausschalten). Die Scripte bei dir schaue ich mir auch mal an ;). bb -- Perhelion 20:07, 2. Feb. 2011 (CET)

Benutzer:TMg/autoFormatter.js

Hallo, ich würde gerne nach wie vor den o. g. autoFormatter benutzen. Leider funktioniert er nicht mehr, seit ich deine Module verwende, weder so noch so. Kannst du dir das mal angucken? Gruß, --Nirakka 01:23, 3. Feb. 2011 (CET)

Da im oben verlinkten Screenshot ein Fehler in autoFormatter.js zu sehen war, habe ich das Problem einfach mal weitergereicht. Falls das noch nicht hilft, wäre wieder die Ausgabe der Fehlerkonsole (sowohl im Bearbeiten-Modus als auch beim Lesen) wie oben hilfreich (Beschränkung auf „Fehler“ statt „Alle“ reicht). Hast du schon vorher die neue Werkzeugleiste verwendet? Funktioniert es im abgesicherten Modus? --Schnark 09:51, 3. Feb. 2011 (CET)

Ich habe im Zuge der JS-Änderungen meine Einstellungen unberührt gelassen. Unter Beta-Funktionen ist bei mir die erweiterte Werkzeugleiste aktiviert, die meinst du vermutlich. Im abgesicherten Modus funktioniert es ebenso wenig. Hoffentlich kann TMg da etwas machen! Gruß, --Nirakka 12:52, 3. Feb. 2011 (CET)

Was zeigt denn die Fehlerkonsole (Strg+Umschalt+J) an? --Schnark 12:53, 3. Feb. 2011 (CET)

Zu welchem Zeitpunkt? Im Bearbeiten-Fenster? Im abgesicherten Modus? --Nirakka 12:53, 3. Feb. 2011 (CET)

Für den Anfang würden mal die Fehler reichen, die beim Bearbeiten angezeigt werden. --Schnark 12:54, 3. Feb. 2011 (CET)

Wenn ich das richtig sehe, tritt nur der folgende Fehler auf:

Fehler: invalid range in character class
Quelldatei: http://de.wikipedia.org/w/index.php?action=raw&ctype=text/javascript&title=Benutzer:TMg/autoFormatter.js
Zeile: 122

Gruß, --Nirakka 13:10, 3. Feb. 2011 (CET)

Und nach Abschicken des Beitrags außerdem dieser:

Fehler: wgWikiEditorEnabledModules is not defined
Quelldatei: http://de.wikipedia.org/w/index.php?action=raw&ctype=text/javascript&title=Benutzer:TMg/autoFormatter.js
Zeile: 226

--Nirakka 13:11, 3. Feb. 2011 (CET)

Ich habe das Script mal bei mir eingebunden, funktioniert auch, nur ich glaube nicht wie es sollte. Es staucht den gesamten Text zusammen indem alle Leerzeilen einfach gelöscht werden!? -- Perhelion 16:51, 3. Feb. 2011 (CET)

War bei mir jedenfalls nie so, als es noch funktioniert hat. --Nirakka 17:12, 3. Feb. 2011 (CET)

Aja, stelle auch gerade fest, dass es zufällig (momentan) nur der erste Artikel ist den ich getestet habe: Plants vs. Zombies was sagt der bei dir? -- Perhelion 17:20, 3. Feb. 2011 (CET)

Funktioniert bei mir gerade auf allen Seiten! War das des Rätsels Lösung? --Nirakka 17:22, 3. Feb. 2011 (CET)

Das ganze Durcheinander ist durch eine Schusseligkeit von mir verursacht worden. Ich hoffe, dass alle Folgefehler repariert sind. Ggf. Umschalt+Neu Laden klicken, um den Webbrowser zum Aktualisieren zu zwingen. Wenn es noch Probleme gibt, gebt mir bitte Bescheid. --TMg 17:52, 3. Feb. 2011 (CET)

(@TMg:) Wenn es bei euch funktioniert muss es im Zusammenhang mit einem Modul von Schnark sein!? Der Fehler tritt bei mir (immernoch) in mehreren Artikeln mit FF 3.6-4.0 Win XP,7 auf jedoch nicht in Chrom, den IE (6,8) konnte ich nicht testen da er von den Scripten scheinbar nicht unterstützt wird. @Nirakka das 2. Script von dir funktioniert nun seltsamer Weise auch nicht mehr (ajax_request undefinied, nun deaktiviert). @Schnark Modulkonfiguration funktioniert auch nicht mehr (Warnung: Leerer String an getElementById() übergeben.) -- Perhelion 22:35, 3. Feb. 2011 (CET)

Was genau tritt beim autoFormatter für ein Fehler bei dir auf? Bei mir bestand das Problem ja ausschließlich daran, dass sich der Button nicht anklicken ließ. Das Script macht im Übrigen das, was es soll (Feuerfuchs). Und was für ein 2. Script von mir meinst du? Den Nutzerstatus? Der hat bei mir nie Probleme gemacht. Gruß, --Nirakka 00:08, 4. Feb. 2011 (CET)

Dass der Fehler im autoFormatter erst nach der Umstellung auf mein Skript auftrat, lag einfach am Browsercache, der davor noch die alte Version ohne Fehler hatte. @Perhelion: Da du das Skript nur beim Bearbeiten einbindest, musst du den Browsercache komplett leeren, bei einigen der üblichen Cache-Leerungs-Tastaturkürzeln wird nämlich nur das aktualisiert, was in der augenblicklichen Seite eingebunden ist.

Zu "2. Script": Ich werden Benutzer:Steef389 gleich erklären, worin das Problem besteht, ab Dienstag wären vermutlich sowieso alle betroffen, die sein Skript verwenden.

Modulkonfiguration: Auf welchen Seiten tritt der Fehler auf (Nur Benutzer:Schnark/js/modulverwaltung, alle Benutzerseiten, …)? Erscheint die Tabelle gar nicht, oder nur fehlerhaft, oder tritt der Fehler beim aktivieren oder deaktivieren auf? Welcher Browser (insbes.: Ist er zu jQuery kompatibel)? --Schnark 09:24, 4. Feb. 2011 (CET)

Modulkonfiguration funktioniert bei mir einwandfrei, FF 3.6.13. Ist es denn generell sinnvoll, den wikieditor nur beim Bearbeiten einzubinden? --Nirakka 12:48, 4. Feb. 2011 (CET)

Bleibt jetzt noch ein Problem übrig, bei dem ich tätig werden sollte? --TMg 15:13, 4. Feb. 2011 (CET)

@Nirakka: Meine jsmodules.js kümmert sich (mehr oder weniger) automatisch darum, dass ein Skript nur dann geladen wird, wenn es gebraucht wird, insbesondere wird wikieditor.js nur beim Bearbeiten eingebunden, ohne dass man sich als Benutzer darum kümmern muss.

Die Nachfrage zur Modulkonfiguration richtete sich an Perhelion, der noch irgendwelche Probleme hat.

@TMg: Dein Skript scheint bei allen zu funktionieren, die sich hier zu Wort gemeldet haben und es verwenden, sodass du wohl gerade nichts daran tun musst. --Schnark 09:22, 5. Feb. 2011 (CET)

Anmerkung: Mein Script sollte jetzt auch wieder funktioieren. --Steef ³⁸⁹ 17:17, 7. Feb. 2011 (CET)

Seltsam der Fehler ist bei mir immernoch (wie gesagt FF 3.6-4.0-Beta auf verschiedenen Systemen), muss also eine Kombination von Modulen sein, wenn niemand anderes den Fehler hat (wie gesagt nur bestimmte Artikel - z.B. Laokoon) Ich kann ja mal verscuhen dies zu ergründen mit abschalten. Grüße -- Perhelion 19:43, 7. Feb. 2011 (CET)

Kleine JS-Frage

Gibt es so etwas bei JS? Gruß, --Nirakka 13:40, 4. Feb. 2011 (CET)

Meinst du das? --TMg 15:11, 4. Feb. 2011 (CET)

Genau! War also schon fast richtig, jetzt funktioniert es. --Nirakka 18:18, 4. Feb. 2011 (CET)

Bitte um einen Dump-Scan

Hi, wenn du vor dem großen 1.17-Testen und Experimentieren noch etwas Langeweile verspürst, würde ich dich um zwei Auswertungen bitten. Wenn du gerade Wichtigeres zu tun hast, hat es aber auch einige Wochen Zeit.

1. Gibt es bei uns ein Wort in galicischer Sprache, das eines der Zeichen Ẁ,ẁ,Ẅ,ẅ,Ỳ,ỳ = \x1E80 \x1E81 \x1E84 \x1E85 \x1EF2 \x1EF3 enthält; falls ja welches und wo; ersatzweise in einer anderen Spanisch-nahen Sprache?
   Es scheint sich um Zeichen zu handeln, die zwar nicht originär im Galicischen vorkämen, jedoch durch Abbildung von Fremdwörtern oder auswärtigen Namen einzubeziehen wären.
   Dies würde mir eine bessere Illustration eines neu zu kreierenden Artikels ermöglichen.
2. Gibt es bei uns überhaupt Artikel, die Zeichen im Bereich 1–31₁₀=\x1F mit Ausnahme der bekannten 9 und 10₁₀ enthalten?
   Es ist heute mit normalem Brauser nicht mehr möglich, diese Zeichen dem Server unterzuschieben, aber vielleicht über API. Mit den CP1252-Zeichen geht das ebenfalls nicht; gleichwohl hast du über ein halbes Hundert unmögliche Zeichen 127–159₁₀ aufgespürt. So könnten sich noch irgendwo CP850 bzw. CP437 verbergen.
   Falls ja und es sind nur eine Handvoll, wäre interessant, welche Artikel – wenn es dir zuviele sind, hätte die Liste konkreter Artikel auch noch Zeit und ich würde zunächst mein Skript den neuen Erkenntnissen anpassen.

Schönes Wochenende --PerfektesChaos 10:08, 5. Feb. 2011 (CET)

Ich habs mir mal notiert, da ich bisher nur bei einem Skript ein 1.17-Problem gefunden habe (wenn man halt versehentlich einen Bug in jQuery 1.3.2 ausnutzt, der in 1.4.2 behoben wurde, muss man sich nicht wundern), finde ich vielleicht sogar Zeit dazu. Viele Grüße --Schnark 10:13, 5. Feb. 2011 (CET)

1. Da du dich weder für Vietnamesisch, noch für alte Transliterationen des kyrillischen Ischizas, noch für Tuwinisch, für Akan im Allgemeinen, Twi im Besonderen oder andere Sprachen mit Zeichen aus dem Afrika-Alphabet, auch nicht für Kobaianisch, nicht für die Tsimshian, nicht für Transliterationen, nicht für das Tschechische, das auch ab und zu ein ỳ kennt, interessierst, kann ich dir nur MediaWiki:Onlyifediting.js anbieten, das zwar kein Wort, aber immerhin unter Galicisch die Zeichen enthält.
2. Da der Bereich auch schon bisher (zusammen mit den anderen unsichtbaren Zeichen) gescannt wurde, musste ich nur noch mal durch die bereits gefundenen Artikel gehen: Diese Zeichen kommen nicht vor. --Schnark 09:21, 7. Feb. 2011 (CET)

Danke für Deine Mühe.

1. MediaWiki:Onlyifediting.js kannte ich. Die Angaben dort sind die einzige Fundstelle dafür, dass diese Zeichen in der galicischen Sprache vorkommen sollen.
   • Zuvor hatte ich einen HTML-Krabbler eine Weile durch die Domain gl.wikipedia.org laufen lassen; der konnte aber keinerlei Vorkommen detektieren.
   • Möglicherweise steckt in dem .js also TF, Missverständnis oder eine Ente; das ist aber nicht meine Baustelle und ich kam nur durch einen Zufall drauf – das mögen Muttersprachler der erst wenige Jahrzehnte wieder erlaubten Sprache herausfinden.
2. Das ist ja äußerst beruhigend.

Mahlzeit --PerfektesChaos 12:59, 7. Feb. 2011 (CET)

Benutzer:Schnark/js/extratabs.js

Hallo, nachdem ich das Script via Cookie in der Modulverwaltung aktiviert habe, finde ich keine Unterschiede. An welchen Stellen sollten die neuen Reiter denn eingeblendet werden? Gruß, --Nirakka 16:15, 9. Feb. 2011 (CET)

Im Dropdown-Menü neben dem Beobachten-Stern, dort wo auch „Verschieben“ zu finden ist. --Schnark 09:06, 10. Feb. 2011 (CET)

Alles klar, vielen Dank. Die Zusatzreiter sind ja total nützlich, gute Arbeit! :-) --Nirakka 11:33, 10. Feb. 2011 (CET)

antispoof

1. Ich habe soeben mit Lustgefühl dein antispoof entdeckt.

   Die gelisteten Codes werde ich durchgehen und mein Skript ggf. entsprechend ausbauen.

   Eigentlich müsste man antispoof so ausbauen können, dass es ohne WP und sogar fast außerhalb von Brausern funktioniert.

2. Die erste Zeile verlinkt auf sich selbst; vermutlich ist das Link ohne .js gemeint.
3. Ich erlaube mir anzuregen, für den ANR unerwuenscht um \u2028 zu erweitern; auf Spezialseiten (unsichtbar) kommt es vor und darf es auch.

   Er taucht gelegentlich auf (Silke, nebenbei statt 14k 15,8) und stört auch Suchvorgänge.

   Wenn ein Darstellungsprogramm spontan weiche Zeilenumbrüche einfügt, etwa um eine mehrzeilige Tabellenzelle umzubrechen, wird es durch C&P eingeschleppt. So wohl auch Sargoth von toolserver.org/~emijrp/imagesforbio hier.

   Gleiches gilt für den paragraph separator \u2029.

4. Das LRM \u200E kommt auf Versionsunterschieden hinter Links vor; wer von dort ein Wikilink kopiert und in einen Artikel einfügt, schleppt es in das Linkziel ein. Ich lösche es dann wieder heraus. Im deutschsprachigen ANR wäre es meist unerwuenscht.
5. Unicode-Block Dingbats würde ich empfehlen gesondert zu bannen.

   Zwar sind die grafischen Zeichen als Windows-Font mit Codes von 161 bis 255 usw. bekannt, aber nicht mal aktuelle Windows-Version-Fonts verstehen sie mit der Codierung U+2700...27BF. Unixoide Systeme kennen noch nicht mal ein Glyph.

   Vor allem aus dem Einleitungssatz ersetze ich zurzeit die "Gestorben-Zeichen" 271D,271E,271F, die Autoren zur besonders schnuckligen Ausschmückung verwenden.

   Wenn du nächstes Jahr mal einen dump hast und dein grep einen regexp kann, der von \x2700-\x27BF geht, wäre ich gelegentlich an einem Überblick interessiert, wie häufig Dingbats im Wikitext vorkommen und ob es sich lohnt, einzelne davon ebenfalls automatisiert durch normale Zeichen zu ersetzen.

   U+2160...217F sind unlesbare Römische Zahlen (!), die ich bereits durch ASCII ersetze. Was die Leute auf ihren Rechnern so alles ausgraben …

6. WikEd gibt seinen kleinen orangen Quadraten ebenfalls ein tooltip mit (siehe hier), auf dem eine Beschreibung des Zeichens steht.

   Gleichwohl muss ich mir den Artikel mit &action=raw holen und lokal speichern, um den Wikitext im HexEditor zu lesen.

Habe einen wunderschönen Tag, möglichst an einem prasselnden Kaminfeuer, ansonsten Sonne im Herzen --PerfektesChaos 13:09, 15. Dez. 2010 (CET)

1. Die meisten Dinge sind relativ ausgereift, wo vermutlich noch Verbesserungsbedarf besteht, ist das Chaos, das die unüberschaubare Menge an umgedrehten kleinen e anrichtet. Vergleiche Wikipedia:Fragen zur Wikipedia/Archiv/2010/Woche 15#umgedrehtes kleines e. Da müsste ich aber mal die Zeit finden mir durchzulesen, welches e eigentlich wofür gedacht ist.
2. Ja
3. +
4. Ich vermute, dass du die Klammer im Kommentar falsch interpretiert hast, (nur für Spezialseiten) bezieht sich nicht auf unsichtbar, sondern auf außer ... LRM. \u2028, \u2029 werden immer, \u200E auf Nicht-Spezialseiten markiert.
5. Ich werde demnächst alle Dingbats, die missbraucht werden könnten, in unerwuenscht stecken, die römischen Zahlen kann ich zwar fast alle lesen, aber auch diese werden dort landen.

   Die Ausdrücke mal über den gesamten Dump laufen zu lassen hatte ich sowieso vor, bisher scheiterte es daran, dass ich keine Ahnung habe, wie ich in bash Zeichen jenseits von \x00FF als Code eingebe und zu faul war, diese Zeichen mir alle aus der Zeichentabelle zu kopieren.

6. Der Code steht übrigens in en:User:Cacycle/wikEd.js ganz unten, \u3000 fehlt also noch bei mir.

Ein völlig überheizter Computerraum ist ja fast ein prasselndes Kaminfeuer (zumindest im Vergleich zu Hörsälen, in denen übers Wochenende immer die Fenster aufstehen) --Schnark 10:01, 16. Dez. 2010 (CET)

grep hat von Unicode leider keine Ahnung, aber in all solchen Krisenfällen rettet einen ja Perl. Hier das Ergebnis (Stand September): Dingbats werden vor allem in Unterschriften, in einem Fall auch als Benutzername genutzt, sodass die FzW-Archive etc. voll davon sind. In Artikeln gibt es folgende Gruppen:

• Artikel über Zeichen: Unicode-Block Dingbats, Raute, Sternchen (Schriftzeichen), Davidstern, Pfeil (Symbol), Herz (Symbol), Victory-Zeichen, Malzeichen, Liste lateinischer Abkürzungen, Aldusblatt, ♁, Häkchen (Schriftzeichen), Kreuz (Christentum), MacArabic, Dickes Ausrufezeichensymbol, Kreuzchen, ✘, Herz (Farbe)
• Verwendung in Legenden: Brobergen, Toszek, Holzstoff, Stromverdrängungsläufer, Refiner
• Häkchen, Kreuze und Xe: Blutgruppe (✕), Leerzeichen, Cc65, Verfahren nach Quine und McCluskey, Reign in Blood, Interferenz (Linguistik) (✓✗), Master-Theorem (✔✘)
• Sonstiges: Stella Matutina (Orden) (❐), LM.C (❤), Hansa-Bauprogramm (✠)
• fehlerhaft: Mons, Lanškroun, Grafen von Freiburg (✝)

--Schnark 09:20, 18. Dez. 2010 (CET)

Ein viel größeres Problem als Dingbats sind Zeichen aus dem Block zur privaten Verwendung (Benutzer:Schnark/privat), unsichtbare Zeichen (obwohl ich das LRM rausgelassen habe ist es immer noch eine gigantisch große Liste), und anderer Zeichenunfug (♰ wird wesentlich häufiger missbraucht als ✝, gefühlt jede zweite Schule nummeriert ihre Gebäude für die römisch nummerierten Sekundarstufen römisch). Was ich im Augenblick noch als Liste (vor allem für SLAs …) zu bieten habe ist solches Zeug in Titeln (Benutzer:Schnark/titel). Wie ist deine Meinung zu ⅓ etc. ? --Schnark 09:29, 20. Dez. 2010 (CET)

1. First of all – Danke für Deine Mühe.
2. Also, an die privaten Zeichen als Gesamt-Block hatte ich noch gar nicht gedacht; da muss ich mich erstmal 'reinlesen.
3. Allgemein sollten alle die Zeichen ersetzt werden, die nicht weit verbreitet sind, und für die es auf ASCII/ANSI-Ebene einen Ersatz gibt. Auf Windows sind die exotischen Codes teils nur in Arial/Times zugeordnet, unter Mac und unixoid sind sie noch viel seltener in den Fonts.
   • Wenn in Hebräisch, Kyrillisch, Farsi, IPA etwas dargestellt werden soll, können es eben nur diejenigen lesen, die solche Schriften installiert haben. Das ist schon okay und nicht zu ändern.
   • Artikel über Zeichen, die nun gerade selbstreferentiell diese Unicode-Zeichen beschreiben, dürfen sie selbstverständlich enthalten.
     Aus genau diesem Grund lässt meine Skript-Automatik sowas auch in Ruhe.
   • Von den hochgestellten Ziffern sind nur 1,2,3 ANSI; daneben gibt es die hochgestellten Zeichen 4–9,0 und alle tiefgestellten Ziffern, die i.A. unlesbar und durch HTML-tags zu ersetzen sind.
   • Von den Brüchen sind nur ¼ ½ ¾ ANSI. Alle anderen sind zurzeit vielfach unlesbar und im laufenden Text als numerische Angabe meist problemlos manuell durch 1/3 ersetzbar (Vorsicht mit 1⅓), wenn das auch typografisch nicht ganz so schick ist – besser als ein ￭ allemal. Im Artikel-Titel wird man es wohl belassen müssen, auch in künstlerischem Zusammenhang.
   • Dass die römischen Zahlen gaga sind, darüber waren wir uns wohl oben schon klar. Konsequent ASCII; Verschiebereste SLA; würde ich glatt machen.
   • Bei Brobergen, Holzstoff, Refiner hat sich ein Autor viel Mühe gegeben; wenn man ihm die Fummelei wegnimmt, fließen Tränchen. Bei Stromverdrängungsläufer ist es nur eine, da tut es eine ASCII-(1). In Toszek habe ich noch nichts gefunden; muss mir dringend ein antispoof installieren.
   • Ein Kreuz bei Blutgruppe lässt sich ja wohl ohne Bedeutungsverlust durch ein ASCII-X ersetzen.
     • A propos: Ich erinnere mich aus deinem PD-Bereich an gekreuzte Schwerter als genealogisches Zeichen, das viele nicht lesen können und wo ein X-Kreuz auch keinen befriedigenden Ersatz gab.
     • Beim ✠ muss man also aufpassen, ob es „gefallen“ bedeuten soll oder einfach durch ein dagger-† ersetzt werden kann.
   • Die Ja-Häkchen mit Nein-Kreuz in Tabellen sollten durch eine Mini-Version unserer grün-roten Ja/Nein-Vorlage ersetzt werden und alles Weitere in der Vorlage geklärt werden. Vor einem Dreivierteljahr hatte ich mal damit angefangen, das Projekt nach widerständig-indifferentem Gebrummel nicht weiterverfolgt und mich auf SyntaxTextMod fokussiert. Ein X lässt sich aber auch in ASCII schreiben.
   • Zum Hansa-Bauprogramm hatte ich das Link vorhin einem maritim interessierten Kollegen geschickt; der meint, dass das zwar die richtig schöne Original-Darstellung von diesem Germanischer Lloyd #Die Klassenangabe des Germanischen Lloyd wäre, aber weil man seit Einführung von Schreibmaschine und Computer mit Ersatzzeichen leben gelernt habe, würde jeder vom Fach auch ein ASCII-Pluszeichen kapieren. Hier werde ich beide Artikel sinnreich ergänzen und verlinken.
   • Herzchen werden sich nicht vermeiden lassen, wenn ein Herz gemeint ist.
   • Zu Stella Matutina (Orden) habe ich kein Ersatz-Quadrat gefunden; ein wenig zusätzliche Kryptik täte diesem Artikel aber keinen Abbruch.
   • Dann fallen mir noch Ligaturen ein, die außer in diesem Artikel selbst und über Buchdruckerkunst nichts in allgemeinen Texten zu suchen haben. C&P kann aber auch ein Fluch sein; wenn die Leute ihre Artikel selbst an der Tastatur tippen würden, statt sie aus professionellen Texten zu klauen, könnte sowas nicht vorkommen.
   • Die weichen nicht-umbrechenden Trennstriche im Artikel-Titel sind natürlich C&P-gaga und sollten durch exerziermäßige Artikel-Verschiebung aus dem WP-Bestand gelöscht werden, bevor das noch jemand mit C&P weiterschleppt.
   • Die em-Dash in Titeln sind wohl alle typografisch falsch und wären gleichfalls durch Verschiebung zu eliminieren.
   • Die kombinierenden Akzente können in ihrem Sprachkontext durchaus legitim und unvermeidlich sein, wenn es keinen kombinierten Glyph gibt – müsste im Einzelfall analysiert werden.
   • U+20E0=COMBINING ENCLOSING CIRCLE BACKSLASH ist ja wohl ein Witz; das musste ich erstmal in der Unicode-Tabelle nachschlagen. Da hätte man den Artikel-Titel aber auch gleich noch in color=red setzen können. Als Kuriosität drinlassen. Kein ANR verlinkt darauf.
   • Die Preußen werden wohl auch unter Commons mit einer Verschiebung ohne ein U+009F=<control>APPLICATION PROGRAM COMMAND besser zu finden sein, spendieren wir also mal ein scharfes s.
   • FF5E;FULLWIDTH SPACING TILDE – weil ja:WP und ko:WP auf D.C. – Da Capo verlinken, kann ja wohl problemlos eine normale Tilde gesetzt werden oder die WL auch gleich ersatzlos gelöscht werden.
   • Zu allem anderen kann ich im Moment nichts sagen, weil ich nur ￭ sehen kann.
4. Tja, in den historischen Original-manpages zu grep ist [\x2700-\x27BF] auch nicht beschrieben; aber einen Versuch war's wert. Manchmal packen die Implementierungen es trotzdem.

Liebe Grüße, einen angenehmen Tag und gelegentlich eine besinnliche Verschnaufpause --PerfektesChaos 13:09, 20. Dez. 2010 (CET)

Nachdem ich auf Grund der unglaublichen Menge teils nur Stichproben analysieren konnte, weiß ich nicht mehr, ob ich verzweifelt sein soll oder amüsiert, jedenfalls ist alles wesentlich schlimmer, als du es dir vorstellst. Ein paar Beobachtungen:

Drittel sind als Bruch so häufig vertreten, dass es unmöglich ist, sie auszumerzen, zumal sie in der neuen Bearbeitungsleiste (ebenso wie Achtel, was wirklich Unfug ist) zum Einfügen per Klick stehen.

Weiche Trennstriche werden per C&P in Massen eingeschleppt, ganz dringende Bitte, dass dein Skript sie automatisch löscht, es gibt genau einen Fall, wo ein weicher Trennstrich sinnvoll ist: Weiches Trennzeichen, dort steht er als &shy;. Alles andere: Raus.

Geschützte Leerzeichen können sinnvoll sein, aber nicht, wenn man sie direkt (also nicht als &nbsp;) einfügt (was ebenfalls unübersichtlich häufig vorkommt), und ganz bestimmt nicht (du wirst es nicht glauben, aber es ist die bittere Wahrheit) wenn sie auch noch als Name eines benannten Einzelnachweises verwendet werden.

ad Toszek: gut versteckt im Bild befindet sich ein Davidstern für die Synagoge.

ad Ligaturen: was einem so begegnet, wenn man sich eigentlich gerade um PD kümmern wollte

grep scheint bei mir Byte-weise zu arbeiten, wenn ich von Hand UFT-8 kodiere und in Zeichenklassen keine Mehrbyte-Zeichen verwende, geht es. --Schnark 09:29, 21. Dez. 2010 (CET)

Ich habe mit Zufällige Artikel auch schon allerlei Gegurke gefunden, und ich nehme dir unbesehen ab, dass Vieles gaga ist. Mit debugmsg hatte ich mich über allerhand Auffälligkeiten informiert und daraus Anregungen bezogen.

• Drittel etc. wird man wegen des Formatierungsproblems 1⅓ auch nicht automatisch durch 1/3 ersetzen können; wer sowas sieht und es 'rausschmeißen möchte, muss es eben manuell tun. Und wenn die Bearbeitungsleiste es jetzt vorsieht und sich kein gewaltiger Protest erhebt, scheint es bei der Mehrzahl der Fonts inzwischen zu funktionieren; es war über viele Jahre ein Problem. Hören wir mal auf die Resonanz.
• Ich habe den Quelltext meines Skriptes soeben dahingehend geändert, dass aus URL und Wikilinks Weiche Trennstriche ersatzlos gelöscht werden.
  Was den Mengentext angeht, bin ich mir nicht schlüssig. Das Thema ist seit 15 Jahren in der weltweiten Diskussion. Früher waren Browser mit der schnellen Worttrennung bei der Darstellung powermäßig überfordert, und man trennte die Zeile am Leerzeichen. Heute wird die Option „Darstellung mit Worttrennung“ ernsthaft diskutiert, und sinnvoll gesetzte Kann-Trennmarken shy würde ich deshalb nicht pauschal löschen wollen. Leistungsmäßig ist es bei heutigen PC durchaus machbar, bei der Textdarstellung automatische Worttrennung vorzunehmen. Vielleicht ist das in wenigen Jahren wikitext-Standard. Im allgemeinen Skript würde ich das deshalb nicht weltweit und projektübergreifend vorsehen wollen, aber es gibt eine benutzerdefinierte Ersetzung, mit der du löschen kannst was immer du magst:

Benutzer:Schnark/js/Wikisyntax-config.js (siehe unten)

(Ich hebe das \xAD nicht als Entity hervor, das normale Editierfenster zeigt es gar nicht und WikEd ja wohl als türkisigen Strich).

• Das mit „Geschützte Leerzeichen“ habe ich nicht verstanden, hättest du ein wikilink für action=raw? Mein Skript wird künftig im wikitext aufgefundene \xA0 durch Entity   ersetzen. Damit würden sie der normalen Bearbeitung zugänglich, und es kann menschlich entschieden werden, ob sie sinnvoll sind.
  Schon vor Jahren hatte ich mal am Server herumgespielt, und hatte wohl die Erfahrung gemacht, dass ein in den Wikitext mit C&P oder über Skript-Zuweisung eingefügtes \xA0 bei der Abspeicherung oder beim Retrieval in normales \x20 verwandelt wurde. Deshalb habe ich hier auch nicht mehr detaillierter nachgeforscht, weil ich davon ausging, dass keine vorhanden sein können. Bei betitelten Wikilink-Zielen und Bild-Namen ersetze ich   meiner Erinnerung nach bereits durch normales Leerzeichen, werde das aber nochmal checken.
• ad Toszek Davidstern – ah, ich hatte nach eingekreisten Ziffern gesucht. Das ist ja dann ganz sinnvoll; einen besseren Ersatz haben wir nicht, und es gäbe Sicherlich-Ärger.
• Unicode-„Privater Bereich“: Da scheinst du etwas missverstanden zu haben. Dies sind Kodierungen, die man sich privat mit eigenen Glyphen belegen und etwa in einer PDF-Datei durch eingebettete Fonts mitliefern kann, die ansonsten nur auf dem privaten PC einen Sinn hätten. In einem weltweiten Projekt sicher nicht. U+E000-F8FF sowie PUA, Ebenen 15+16, siehe Liste der Unicode-Blöcke.
• grep – Ich habe noch nie einen Dump unterm Messer gehabt, und ich verzichte dankend. (Es reicht mir, wenn du einen an der Backe hast) Es kann aber deiner Schilderung nach gut sein, dass diese Datei nicht in UCS, sondern in UTF kodiert ist (es steht kein ä sondern ä). Das ist auch sinnvoll, wenn die DB überwiegend lateinischschriftige Texte enthält; es spart mehrere 100 MB ein.
  Vielleicht mal grep --help angucken; es kann sein, dass dein grep sogar ein --encoding=UTF oder sowas kennt. Standardmäßig arbeitet es meist nach dem 25 Jahre alten POSIX, es gibt aber etwa auch ein --perl-regexp, das dir gelegen kommen mag. Weil vor 25 Jahren das Byte und das Zeichen noch 8bit hatten, wird weder in der durchsuchten Datei noch im regexp etwas anderes erwartet. --text könnte bereits ausreichen, die Interpretation als UTF zu erzwingen, falls grep irrigerweise der Meinung war, es sei eine binary Datei und solle Byte für Byte betrachtet werden.

--PerfektesChaos 19:27, 21. Dez. 2010 (CET)

Gegen &shy;s habe ich nichts, nur gegen die im Normalfall unsichtbaren \xAD.

\xA0 in Titeln werden in \x20 umgewandelt (also auch in Bildern), im Text bleiben sie, Beispiel hab ich grad keines.

Was soll ich beim privaten Bereich falsch verstanden haben?

Mit der Hilfe zu grep konnte ich mich nie anfreunden, da sich grep sowieso immer anders benimmt, als es dort steht. Nach Experimenten tut grep das, was grep tun soll, aber dass bzgrep sich wie egrep verhält steht nirgends.

Zwei weitere Listen: komische Zeichen: Benutzer:Schnark/ungewöhnlich; griechisch-nicht-griechische Kombinationen: Benutzer:Schnark/griechisch. --Schnark 09:42, 22. Dez. 2010 (CET)

• nur gegen die im Normalfall unsichtbaren \xAD – Kleines Weihnachtsgeschenk:

Modif_Text = Modif_Text.concat(
             [ [String.fromCharCode(173),  "­"] ]);

Benutzer:Schnark/js/Wikisyntax-config.js

if (wgTitle != "Ligatur (Typografie)") {   // !RL!
   Modif_Text = Modif_Text.concat(
                 [ ["ff",
                    "ff"],
                   ["fi",
                    "fi"],
                   ["fl",
                    "fl"],
                   ["ffi",
                    "ffi"],
                   ["ffl",
                    "ffl"],
                   ["st",
                    "st"]
                            ]      );
}   // Ligatur (Typografie)

(Den Code zuvor oben habe ich entfernt, weil nicht funktionsfähig und dazu gefährlich)

• Was soll ich beim privaten Bereich falsch verstanden haben? Du schreibst oben: „Zeichen aus dem Block zur privaten Verwendung (Benutzer:Schnark/privat)“. Das ist aber feststehender Begriff für andere Blöcke ab 57344₁₀. Bei Benutzer:Schnark/privat liegst du aber unter 10000₁₀, und du könntest wohl auch keine "privaten Zeichen" sehen. Ich nahm dies aber zum Anlass, solche Zeichen in Entities zu wandeln.
• Ich werde versuchen, \xA0 im Text unterzubringen, bleibe auch dankbar für Artikelbeispiele.
• An einigen der von dir aufgefischten Artikel werde ich mich im Weihnachtsurlaub erproben, Danke dafür.
• Mittelfristig wäre das eine Sache für SK und sein checkwiki.

Falls wir nichts mehr voneinander hören, mach dich unterm Tannenbaum schön lang! --PerfektesChaos 18:11, 22. Dez. 2010 (CET)

• Deinen Code werde ich bei Gelegenheit übernehmen, danke dafür!
• Alle unter /privat aufgelisteten Texte enthalten ein Zeichen aus E000–F8FF, die in den meisten Fällen als Ersatzzeichen in Einzelfällen aus Dreck und in wenigen Fällen gar nicht zu sehen sind.
• Ich werde wohl über Weihnachten dazu kommen, ein paar Beispiele für \xA0 direkt im Text zu finden.

Auch dir frohe Weihnachten! --Schnark 09:17, 23. Dez. 2010 (CET)

/privat: Aaaah – frei nach dem Motto: „Ein Patient, der Läuse hat, kann auch Flöhe haben.“ Jetzt habe auch ich sie gefunden.
Die Experimentalversionen -2.91 (x24.js) enthalten u.a.:

• \xA0 im freien Text würde immer &nbsp; – dazu debugmsg "charRemoveUndesired" aufpoppend (ungetestet)
• Private Use Zeichen werden numerisches Entity (funktioniert)
• shy wird immer aus Linkziel entfernt (ungetestet)

Lass es dir gutgehn --PerfektesChaos 12:52, 23. Dez. 2010 (CET)

Falls du ein paar Test-Artikel mit \xA0 brauchst: Anime, BASIC, Freie Hansestadt Bremen, Bettina von Arnim, Bibel, Bulgarien, Baden (Land), Candela, Coulomb, Sprachelemente von C-Sharp, Compact Disc, Estnische Sprache. Statistisch gesehen macht das etwa 10700 Artikel mit einem \xA0 (estnische Sprache hat ID 1313). Viele Grüße --Schnark 10:07, 27. Dez. 2010 (CET)

Danke schön, ich kümmere mich drum.

Zurzeit räume ich noch mit Römischen Zahlen auf /privat und /ungewöhnlich auf, ein Fan ostasiatischer Pkw scheint viele Fonts auf seinem Rechner gehabt zu haben. Die Sekundarstufe II ist schon Geschichte; lass mich dieses Jahr da noch ein wenig eindampfen.

Bisher hat mir das schon neue Erkenntnisse über den HYPHEN gebracht; bin aber mit dem Denken noch nicht ganz fertig.

Wir sehen voneinander --PerfektesChaos 10:44, 27. Dez. 2010 (CET)

1. Zu den Zeichencodes habe ich mich zwischenzeitlich hier bzw. dort weiter geäußert. Benutzerdefinierte Möglichkeiten stehen da.
2. Die Römischen Zahlen habe ich soweit aus den Titeln herausgeätzt. An den ungewöhnlichen Zeichen knabbere ich weiter; in Dortmund sitzt offenbar ein Fan, auf dessen watchlist ich möglicherweise unangenehm auffalle. Bewusst kombiniert werden hier die Römischen Zahlen mit Ligaturen „Seite 14ff“.
3. Danke für die \A0; ich werde ggf. einige Reguläre Ausdrücke überdenken müssen.
   Zur Estnischen Sprache fällt mir ein Schwank ein: Eine sehr ähnliche Sprache beginnt mit F., das Quasi-Nachbarland auch. Dazu gibt es ein WP-Portal, das von jemand mit charakteristischem P im Namen dominiert wird. Dieser duldet in "seinem" Portal keinerlei &nbsp; und ersetzt sie alle in jedem Artikel durch einfache Leerzeichen, weshalb es im Lauf der Zeit zu mehreren Edit-Wars kam und wohl auch einige Autoren dieses Portal verließen (auch wegen anderer Herrschaftsallüren). Es kann sein, dass im Zuge einer Software-Änderung Autoren des Portals einen Dreh fanden, unsichtbare geschützte Leerzeichen unbemerkt in Artikel einzuschmuggeln. Vielleicht gibt es ja thematische Häufungen. Von meiner Seite aus lasse ich sie unverändert, hier zu ändern ist selbst zu definieren.
4. Die Erkennung unerwarteter Strichelchen konnte ich durch deine Analyse ausbauen; auch etwa in PD werden sie jetzt als solche verstanden.

Guten Rutsch --PerfektesChaos 00:58, 31. Dez. 2010 (CET)

Frohes Neues erstmal!

• Ich beichte einen bug auf WikisyntaxTextMod/usage/typogr, von dir übernommen in Wikisyntax-config.js
  Ich kaufe ein E, äh, nein, ich klaue ein e. Statt

["([a-z])['´`]ne?\\b", "$1’n"],

muss es heißen

["([a-z])['´`](ne?)\\b", "$1’$2"],

… ich hatte nachträglich noch ein fakultatives e endeckt und vergessen, es in die Ersetzung aufzunehmen.

• Nicht verstanden habe ich bei dir:

['(ISSN(?:\\s|\\|)\\d\\d\\d\\d)–(\\d\\d\\d\\d)', '$1-$2'],

Die ersetzte zweite Klammer ist in der ersten enthalten; ich würde annehmen, es sei '$1-$3' gemeint (C&P von der vorangehenden Zeile).
Ich mache sowas Ähnliches, wandle aber gleich in die Vorlage:

var dashes = String.fromCharCode(45,173,8208,8209,8210,8211,8212,8213,8722);
["\\bISSN(:|:?( | )+)([0-9]{4})[" + dashes + " ]?([0-9]{3}[0-9xX])\\b",
 "{"+"{ISSN|$3-$4}}"],

• antispoof habe ich mittlerweile zu laufen und erfreue mich daran.
  Im Normalfall sollte der n-Dash (Geviertstrich, U+2014, 8212) jedoch nicht angemeiert werden; er ist absolut unproblematisch und steht auch auf der CP1252.
  m-Dash ist computermäßig ebenfalls unbedenklich, gehört aber nicht in die deutsche Typografie. Falls du den nDash weiter als bemerkenswert einschätzt, würde ich bitten, einen "heftig"-Modus auf die ToDo-List zu setzen, der standardmäßig nicht eingeschaltet ist.
• Auf die Gefahr hin, dass ich etwas blind bin: Bei Estnische Sprache finde ich weder aktuell noch August 2010 noch 2006 ein eigenständiges \xA0, sondern nur als UTF-Bestandteil in den Interwikis. Weder Hexedit noch antispoof (Statistik unter Titelzeile) finden es als Zeichen.
  In anderen Artikeln sah ich aber das \xA0 und glaube grundsätzlich an seine Existenz.
• Dir vermutlich bekannt? Sicherheitshalber commons:MediaWiki:Titleblacklist + MediaWiki:Titleblacklist

Bis dennele --PerfektesChaos 18:40, 4. Jan. 2011 (CET)

Das e habe ich übernommen, danke für den Hinweis. Bei der ISSN-Korrektur stimmt meine Zählung, mit ?: eingeleitete Klammern zählen bei der Zählung nicht mit (zumindest FF weiß das).

Einen n-Dash sollte mein antispoof eigentlich nicht hervorheben, nur mit einem Tooltip versehen – andernfalls könnte man hier nicht die 3 – 1 = 2 Fehler sehen −, was in meinen Augen sinnvoll, aber nicht störend ist. Der Gedankenstrich und das Minus sind in der Sonderzeichenleiste unten einfach so nahe, dass solche Fehler an der Tagesordnung sind. Den m-Dash hebe ich wirklich nur auf Grund der Tatsache hervor, dass er in deutscher Typographie nicht vorkommen sollte.

Beim nbsp hatte ich etwas geschummelt, der Ausdruck hatte auch nach thinspace gesucht, solche kommen ein paar direkt im Wikitext vor.

Hier verkümmert die Titleblacklist nur zu einer Benutzernamen-Verbietungsliste, daneben gibt es noch mw:Extension:AntiSpoof, die das Nebeneinander griechischer und lateinischer etc. Buchstaben verhindern sollte, und mindestens ein Missbrauchsfilter verhindert auch irgendwelche Benutzernamen (Nummer 14, ist aber privat, sodass nur Admins sehen können, wen sie damit eigentlich aussperren).

Viele Grüße --Schnark 09:40, 5. Jan. 2011 (CET)

1. non-capturing parentheses – Du hast recht.
   Die Konstrukte mit (? stehen bei mir allerdings auf der schwarzen Liste der gebannten RegExp-Eweiterungen etwa gegenüber JavaScript 1.3 – weil regelmäßig Ursache von Inkompatibilitäten, dazu auch mit Posix, grep, Lisp; und durch andere Formulierung vermeidbar, deshalb mir geistig nicht so präsent. JScript kennt es aber mittlerweile auch schon.
2. nDash – Ah, ja, ich arbeite mich erst allmählich in die rosarot gesprenkelten Artikel ein. Sorry for confusion.
3. Was mich aber auf eine Anregung bringt:
   • \u00A0 (und ggf. nur im dargestellten Artkel &#160;) hellgrau (wie in OpenOffice.org) oder pastellgelb oder hellblau unterlegen
     Test: 4 % und «Guillemets» bzw. « Guillemets »
   • Schmales Leerzeichen in jeglicher Kodierung in entsprechend unterscheidbarem Pastellton unterlegen
   • Und von dieser Idee dann auch noch WikEd zu überzeigen, Realisierung zu erwarten für etwa 2013.
4. Und weil ich gerade bei Anregung war:

count + ' verdächtige' + (count==1 ? 's' : '') + ' Zeichen gefunden!</span>'

• Weiche Trennstriche habe ich dir für einen gelegentlichen Lauf des autoedit.js-Niedermetzelns übriggelassen.

(PS: Den Schwesterprojekten nach sperren sich die Admins u. a. ihre Benutzernamen, auch solche, die den Stewards, Checkuser etc. zum Verwechseln ähnlich sehen – also etwa ein Raymοnd; und wohl allerlei Varianten von 18 etc. – wird ja wohl sinnvoll sein)

Einen sonnigen Tag --PerfektesChaos 13:52, 5. Jan. 2011 (CET)

Mahlzeit!

1. Im Nachgang zu meiner vorherigen Bemerkung über Sichtbarmachung von nbsp möchte ich dir meinen Lernerfolg nicht vorenthalten: Vorlage:ArS
   • Bei Umwandlung von Vorlagen zum Cache-Schnipsel wird   nbsp→#160
   • Rot für \xA0 wäre dann im Allgemeinen etwas übertrieben, hellgelb würde reichen. Zig Vorlagen verwenden irgendwo nbsp an Seitenzahlen, Paragrafenzeichen etc.
   • Im konkreten Fall ist rot allerdings mal angesagt, denn wenn wie hier der arabische Text etwas länger ist, machen die nbsp typografisch überhaupt keinen Sinn; höchstens wenn nur ein paar wenige Buchstaben dargestellt werden sollten. Hingegen wäre RLM...LRM angebracht. Why ever.
   • Zu den Ur-Autoren gehört nebenbei ein gelöschter S.K., der mit einem bekannten SK identisch sein dürfte.
2. PD-technisch überfordert bin ich vom sachgerechten Umgang mit den ALTERNATIVNAMEN bei Wilhelm von Rubruk#Namensvarianten.

Have a nice day --PerfektesChaos 12:52, 6. Jan. 2011 (CET)

2. In Zukunft wird ein Geviertstrich übrigens nur noch in Artikeln bemängelt, auf Diskussions- und anderen Seiten haben ihn zu viele in der Signatur.

3. Da ich in weiser Voraussicht für color in highlight.js bereits eine Funktion zugelassen habe, wäre eine farbliche Hinterlegung definitiv kein Problem, da ich durch meine Modulverwaltung eine Standardkonfiguration leichter überschreiben kann als du, liegt es an dir, für die Zeichen, die derzeit in benennen stehen, eine Farbe (einschließlich transparent) zu bestimmen. Was WikEd angeht bist du zu optimistisch, es hat ja schon ein Jahr und mehrere Beschwerden auf Cacycles Disk gedauert, bis er mal den Fehler ein einzelnes Leerzeichen in der Kat.-sortierung zu enfernen behoben hat.

4. Perfektionist

5. Im Prinzip könnte man tatsächlich auf der Basis von autoedit.js einen Bot programmieren (und mit der neuen Version, die es gleich gibt, erst recht), aber ich habe es eigentlich nicht vor.

6. Inzwischen sollte die Antispoof-Extension das Anlegen eines Benutzers Raymοnd verhindern, wenn es einen Raymond gibt, so was stammt also noch aus der Urzeit.

1. Geschützte Leerzeichen stehen übrigens automatisch auch vor jedem Satzzeichen (Plenk#Sonderfall_Französisch), wo sie die Software ebenso wie vor das Prozentzeichen setzt. Jener S.K. hat übrigens nur eine gelöschte Benutzerseite und ist immer noch aktiv. Und dass eine Person nicht innerhalb von 10 Sekunden erst diesen und dann jenen Edit macht, bezweifle ich sehr stark.

2. Im Prinzip: alle in ALTERNATIVNAMEN aufnehmen. In der Praxis: so lassen wie es ist.

Viele Grüße --Schnark 09:38, 7. Jan. 2011 (CET)

Diesbez. würde ich gerne für das antispoof.js einen manuellen Button vorschlagen, da es auf Low-Systemen doch etwas Performance kostet (bzw. gestern einen Stopfehler erzeugte wegen Überlastung, warum auch immer) VG

antispoof.js -- Perhelion 20:17, 10. Feb. 2011 (CET)

Warnungen über nicht endende Skripte gibt es auch bei schnellen Computern, diese haben aber vermutlich weniger mit den einzelnen Ausdrücken zu tun, als vielmehr mit der Größe der betrachteten Seite. Über einen manuellen Start bei großen Seiten denke ich schon etwas länger nach, hat aber für mich geringe Priorität. --Schnark 09:08, 11. Feb. 2011 (CET)

Moin

Könntest du bitte einen (String) überprüfen bzw. korrigieren ? :) -- Gary Dee 11:41, 11. Feb. 2011 (CET)

Wenn du mir sagst, um welches Skript es geht, kann ich natürlich mal einen Blick darauf werfen. --Schnark 11:59, 11. Feb. 2011 (CET)

Es geht hierum: Ich wurde von Dispenser heute angesprochen in Bezug auf die Übersetzung des Dab Solver. Ich habe insofern das übersetzt was ich auf den ersten Blick für nötig hielt. Bloss unten unter Server messages weiss ich nicht richtig zu sagen was Sache ist. Und auch weiss ich nicht ob der template "de" zielführend ist. Hier der Script:

// Submitting a page, without changing the text
var NoChangesMsg    = 'Der Text ist unverändert. Fortfahren?';
// If user opens a dialog before it finishes loading
var NotLoadedTryAgain = "Du warst schneller als der Server. Versuche es nochmal.";
// User leave the tool without saving
// +Typically appears sandwiched between text on a Ok/Cancel dialog
var QuitWithoutSaving = "Falls du diese Seite jetzt verlässt, gehen ungespeicherte Änderungen verloren.";
// Disambiguation needed/"Ich finde keinen geeigneten Link" tag (blank to remove)
var dn_template = ""; //not used in de

// Edit Summary
// When adding templates such {{dn}}
var RequestHelpMsg  = ''; //not used in de
// Link which were removed or unlinked
var RemovedLinksMsg = 'Entlinkt: ';
// Links which were fixes
var SolvedLinksMsg  = 'Weiterleitung(en) aufgelöst: ';
// Number of links fixes, if above is too long
var SolvedCountMsg  = '$1 Weiterleitungen aufgelöst';
// Summary feedback link when commonfixes is active
var UsingToolMsg    = ' mit Hilfe des [[tools:~dispenser/view/Dab_solver|Dab solvers]]';

// Interface text
var TabRead     = "Lesen";
var TabEdit     = "Bearbeiten";
var TabHistory  = "Versionsgeschichte";
var TabClose    = "Schließen";
var OptRedlinks = "Zeige Rotlinks";
var OptForcelink= "Link auf Begriffsklärungsseite";
var OptTaglink  = ""; //not used in de
var OptUnlink   = "Entlinken";
var OptReset    = "Zurücksetzen";

// Server messages
// Database revision does not match page revision, usually caused by replication lag
OutOfSync = u'Achtung: Die Datenbank ist nicht aktuell. Siehe <a href="http://toolserver.org/~bryan/stats/replag/">replication lag</a>.'
// Link was not found in text, usually due to replication lag
LinkNotInText = u'\03{lightred}Achtung\03{default}: [[%s]] nicht gefunden'
// No links to disambiguated (maybe cause by the above message)
NoLinksInText = u"Keine Links auf Begriffsklärungsseiten im Wikitext gefunden"
// Link not included because its transcluded from a template
LinkTranscluded = u'Die Weiterleitung [[%s]] ist über [[%s]] verlinkt.'
// Text removed for brevity and compliance with the Toolserver rules
RemovedText = "%s\n<removed>%d Zeilen versteckt (%d Zeichen)</removed>\n%s"
// Rewrite templates link text to allow matching
ReplaceTemplates = [
];

Gary Dee 12:09, 11. Feb. 2011 (CET)

Eine Vorlage wie en:template:dn haben wir hier nicht, bei Texten, die ich nicht bei einer kurzen Benutzung des Tools finden konnte, weiß ich natürlich nicht, ob es so passt, aber so mehr oder weniger sollte es stimmen. --Schnark 12:30, 11. Feb. 2011 (CET)

Vielen Dank ;-) Gary Dee 12:39, 11. Feb. 2011 (CET)

Farbenfroh

Moin Schnark. Kannst du hier mal reinschaun ? Danken & Gruss -- Gary Dee 10:38, 14. Feb. 2011 (CET)

Reicht der Hinweis bei Wikipedia:Fragen zur Wikipedia#Nummer 2 lebt (nicht) auf Vorlage:NRHP nicht aus? --Schnark 10:45, 14. Feb. 2011 (CET)

Achso; hab das schon vergessen :( Ich werde alt, Sorry --Gary Dee 10:53, 14. Feb. 2011 (CET)

DebugWikiGlobals

FYI – to be tested at simple. Greetings --PerfektesChaos 16:38, 15. Feb. 2011 (CET)

Hey, ich habe ohne eine Wartezeit von 10 Minuten die Symbolleiste bekommen, was für ein Fortschritt. Sobald sich die Sache hier etwas beruhigt hat, schau ich mir das mal an. --Schnark 11:44, 16. Feb. 2011 (CET)

Ab sofort simple und engl. Doku nicht mehr erforderlich: deutsch.

WikisyntaxTextMod zickt noch ein wenig an den globals; werde ich durchchecken und heute abend neues r.js als hoffentlich letzte Version 2.95 in der de.WP bereitstellen.

Guten Hunger --PerfektesChaos 12:23, 16. Feb. 2011 (CET)

Meine extratabs.js stolpert auch über simple, wie ich feststellen musste. Und Wahnsinn, obwohl en seit ein paar Minuten wieder mit 1.17 läuft, funktioniert hier noch immer alles! --Schnark 12:25, 16. Feb. 2011 (CET)

1. Mein Problemchen in WikisyntaxTextMod war eine ins Blaue hinein programmierte ungetestete Mutmaßung, bei der dann unter 1.17 noch einige Schalterchen richtig gesetzt werden mussten. Tauchte nicht in /r.js auf.
2. Ich habe keine Fehlersituationen an 1.17 beobachtet.
3. en.WP ächzt wohl grad ziemlich; WikEd kommt nach clear-cache nicht mehr in die Puschen. Dann eben ohne, und Abendessen bis der Spuk vorbei ist.
4. Würdest du folgende Aussage unterschreiben: "Weil das Benutzerskript erst nach abgeschlossenen Laden des DOM gestartet wird, kann die Verzögerung mittels addOnloadHook() für Benutzerskripte ersatzlos entfallen. Die in mw:ResourceLoader/JavaScript Deprecations thematisierte Ersetzung durch jQuery(document).ready() bzw. $() ist allenfalls für Server-seitige bzw. Projekt-weite JS erforderlich, die in der HEAD-Sektion eingebunden wäre."

Mampf statt Server-Kampf --PerfektesChaos 18:20, 16. Feb. 2011 (CET)

Ein „Was bisher in addOnloadHook eingeschlossen werden musste, kann jetzt problemlos direkt ausgeführt werden.“ unterschreibe ich. Da ich aber vor einem halben Jahr üble Probleme mit addOnloadHook + jQuery hatte, würde ich jedem, der jQuery verwendet ausdrücklich dazu raten, seinen Code in $() einzuschließen. --Schnark 09:07, 17. Feb. 2011 (CET)

Da ich selbst keinerlei Erfahrung mit jQuery habe, muss ich doof nachfragen:

• Gilt die zugrundeliegende Problematik weiterhin, oder hat sie sich vielleicht durch Verbesserungen in 1.17 erledigt?
• Kann man deinen Rat so formulieren: Code, der jQuery-Funktionen verwendet, sollte mittels $() (entsprechend jQuery(document).ready()) aufgerufen werden, um sicherzustellen, dass jQuery korrekt initialisiert wurde.

Rätselnd --PerfektesChaos 10:16, 17. Feb. 2011 (CET)

jQuery-Internas kenne ich auch nicht, alles was ich sagen kann, ist, dass ich übelste Probleme hatte, als ich damals jQuery-Funktionen innerhalb einer addOnloadHook-gestarteten Funktion verwendete. Und genau diese Probleme werden wohl auch jetzt auftreten, wenn man versucht, jQuery-Zeug direkt auszuführen, denn ein Direktausführen findet ja nun zu dem Zeitpunkt statt, zu dem bisher runOnloadHook dran war. Da es andererseits niemals schadet, seinen Code erst durch jQuery(document).ready() ausführen zu lassen (niemals ist ein relativer Ausdruck, nachdem ich gestern jemand helfen musste, der nur weiße Seiten sah, da er ein document.write per addOnloadHook verzögerte, würde ich das vor Leuten, die keine Ahnung haben, was sie tun also anders formulieren), würde ich empfehlen jQuery-Code immer und anderen Code dann, wenn man sich nicht sicher ist, in $() (ist ja nur die Kurzschreibweise von vorigem) zu packen. --Schnark 10:27, 17. Feb. 2011 (CET)

• Danke schön; das hilft erstmal weiter.
• Die beschriebene Situation nennt sich Deadlock und wird doch immer wieder gern genommen.
• Halt doch mal die Äuglein auf, was sich jetzt unter 1.17 betreffend jQuery und Deadlocks tut, und merk dir interessante Situationen und Effekte.

Mahlzeit --PerfektesChaos 12:39, 17. Feb. 2011 (CET)

deine high tech produkte ;)

Hi Schnark, nachdem ich jetzt etwas rumgetestet hab, wollte ich nur mal kurz danke! sagen für deine schicken high-tech-Produkte für die Vector.js! (Ich weiß zwar nicht ganz genau eigentlich gar nicht, was ich da mache und warum es funktioniert - aber es funktioniert ;) Herzliche Grüße --Rax post 10:14, 17. Feb. 2011 (CET)

Bitte

Nachspiel zu http://de.wikipedia.org/wiki/Wikipedia:Fragen_zur_Wikipedia/Archiv/2010/Woche_14#.28Unterschied_.7C_Versionen.29: http://de.wikipedia.org/wiki/Wikipedia:Fragen_zur_Wikipedia#Wieder_.28Unterschied_.7C_Versionen.29_statt_.28Versionen_.7C_Unterschied.29_in_Beitragsliste

Bei letzterem mal bitte vorbeischauen. Gruß, --Asthma und Co. 12:34, 18. Feb. 2011 (CET)

Hat sich auch ohne mich erledigt? --Schnark 09:15, 19. Feb. 2011 (CET)

fullscreen

Im Rahmen der 1.17-Analysen kam ich auf monospace dazu, mal probeweise fullscreen.js zu testen.

Versteckt werden müssten noch

• <div class="portlet" id="p-logo">
• <div class="portlet" id="p-search">

Bereits zufriedenstellend untergepflügt sind:

• <div class='generated-sidebar portlet' id='p-navigation'>
• <div class='generated-sidebar portlet' id='p-Mitmachen'>
• <div class="portlet" id="p-tb">

Unter vector heißen die nur class="portal", bei monospace hingegen class="portlet".

Nebenbei: Dieser JS-Komprimierer heute war ja oberpeinlich. Das Teil trägt zwar die Jahreszahl 2005, war aber offensichtlich nie längere Zeit im produktiven Einsatz gewesen und wurde jetzt mit debug=false erstmals aktiviert. Mit meinem selbstgebauten Emacs Lisp kann er sich auch nicht messen; das angegebene Beispiel:

	Chars
Unkomprimiert	72865
Mediawiki	51519
Ich	41524

Schönes Wochenende --PerfektesChaos 21:44, 18. Feb. 2011 (CET)

Da ich fullscreen weder selbst verwende noch besonders mag, hat das eine sehr geringe Priorität für mich. Zum JS-Komprimierer: Das kommt halt dabei raus, wenn man sich um vertikalen Leerraum (siehe auch die vielen, vielen, vielen folgenden Posts) streitet und nicht auf die Qualtiät achtet, sondern sowas (siehe auch die vielen, vielen, vielen folgenden Posts) tut. --Schnark 09:21, 19. Feb. 2011 (CET)

O Schreck o Graus!

• Das kommt halt dabei 'raus, wenn man im ganzen Stress der 1.17-Einführung am 20. Januar noch schnell die Syntax-Analyse einer komplexeren Sprache einschiebt und mit ein, zwei Beispielen von ein oder zwei kB „austestet“.
• Mein Komprimierer wirkt gesichert nur auf meinen eigenen Programmierstil. Da ich beispielsweise keine RegExp-Literale verwende, wäre ich mir nicht zu 100,00 % sicher, ob dies in jeder Situation abgefangen würde – obwohl sie natürlich berücksichtigt werden, aber bei /wegdamit// könnte man schon mal auf die Idee kommen, dass // der Beginn eines Kommentars sei.
• Deshalb hatte ich meine r-Skripte im komprimierten Zustand immer noch einige Tage als x.js laufen lassen, um prinzipiell mögliche und syntaktisch unauffällige Böcke zu erjagen.

Halb besoffen ist ’rausgeschmissenes Geld. Entweder man komprimiert – dann richtig und bis zum Anschlag. Oder man lässt es ganz bleiben. Wenn ein Fehler auftritt und man debuggen muss, schaltet man eben in die zugehörige funktionsgleiche Debug-Version.

fullscreen verwende ich auch nicht – war nur zur Info, weil ich grad mal in die monospace geswitcht war und herumspielte.

Einen schönen Tag --PerfektesChaos 10:57, 19. Feb. 2011 (CET)

Besonders lustig war ja auch, dass mein erster Bugreport dazu (ein Tag vor dem ganz großen Chaos) mit der Bemerkung geschlossen wurde, man hätte die neue Version jetzt an jQuery.js getestet, sie würde sich wie die alte verhalten. Dass sie das von mir gelieferte Beispiel genauso falsch behandelte wie die Vorversion hat niemand gestört, dass es noch mehr Fehler gab, hat man auch erst einen Tag später bemerkt. Wohl denen, die in ihrer vector.js nur einfachen Code stehen haben. Benutzer:P.Copp hat den Bug ja auch wieder neu geöffnet, da dieser ver* Sch* immer noch üble Fehler produziert. --Schnark 11:03, 19. Feb. 2011 (CET)

*Staun* Also – jeder, der sich in dem Gewerbe auskennt (und unsere Entwickler gehören zweifelsfrei dazu) kann doch hier nur auf eine Weise handeln: Den Komprimierer jetzt sofort deaktivieren, weil nicht zwingend erforderlich; erstmal die vielen sonstigen kleinen Wehwehchen bereinigen, die sich unvermeidlich mit so einem Quantensprung in der Technologie ergeben; in der Zwischenzeit den Komprimierer weiterentwickeln; an Dutzenden viele kB großen JS-Quellen vieler verschiedener Programmierer austesten; nach einigen Wochen ganz still und leise den Komprimierer wieder einführen. Wenn dann immer noch eine gültige JS-Syntax misshandelt werden sollte, kann man das in Ruhe weiter verbessern – und nicht ausgerechnet jetzt, wo alles aufgescheucht umherflattert und flucht. --PerfektesChaos 12:49, 19. Feb. 2011 (CET)

Wie man den JS-Komprimierer umgeht: Debug-Modus. Schönen Abend --PerfektesChaos 19:28, 19. Feb. 2011 (CET)

wikieditor.js: Funktion „Korrigiere Einheiten“ suboptimal

Beim Testen des Skriptes ist mir aufgefallen, dass die Einheitenkorrektur zwar gut gemeint, aber eigentlich unbrauchbar ist. Derzeit werden zwischen Zahlen und nachfolgenden Begriffen die Abstände auf genau ein Leerzeichen korrigiert. Allerdings werden falsch geschriebene Temperaturangaben (z. B. 10° C statt 10 °C) nicht berücksichtigt. Außerdem sollte das Zeichen zwischen Betrag und Einheit korrekterweise kein Leerzeichen, sondern ein geschütztes Leerzeichen ( ) sein, um Zeilenumbrüche zu vermeiden. Inwiefern das Skript dann allerdings noch zwischen Einheiten und normalem Textfluss (z. B. „11 mal …“, „12 verschiedene …“ usw.) unterscheiden kann, um das richtige Zeichen einzusetzen, ist dann natürlich die andere Frage und wäre vermutlich ziemlich aufwendig zu implementieren.

Dennoch: Ob eine Einheit nun direkt an eine Zahl angehängt (10cm) oder mit einem Leerzeichen abgetrennt wird, kommt auf das Selbe raus: Beides ist falsch. Die Funktion sorgt damit also nicht für eine Korrektur, sondern im Prinzip sogar für eine „Verschlimmbesserung“. Denn es wäre eigentlich besser wenn man direkt angehängte Einheiten nicht mit dieser Funktion bearbeiten lässt, da der Fehler dann offensichtlicher ist und man bei einer manuellen Bearbeitung gleich „richtig“ korrigieren kann.-- ζ 23:44, 18. Feb. 2011 (CET)

Mir ist gerade völlig unbegreiflich, von was du sprichst, da es in meinem wikieditor-Script keinerlei Korrekturfunktionen gibt und auch keines meiner anderen Skripte irgendetwas mit Leerzeichen oder Zahlen tut. --Schnark 09:14, 19. Feb. 2011 (CET)

Dasselbe Thema in einer differenzierteren Betrachtung – was wohl gemeint ist. --PerfektesChaos 09:23, 19. Feb. 2011 (CET)

Nach einigem Nachdenken: Es geht vermutlich nicht um meine wikieditor.js sondern um WikEd. Einfach unter den eigenen Einstellungen im Reiter Helferlein deaktivieren, dass sämtliche Korrekturfunktionen dieses Skripts mehr Probleme machen als sie lösen ist bekannt, interessieren aber den Autor Cacycle nicht wirklich, um schlimme Fehler korrigiert zu bekommen, muss man ihn über ein Jahr lang regelmäßig ansprechen, danach habe ich es aufgegeben mit ihm über Korrekturfunktionen zu diskutieren. --Schnark 09:31, 19. Feb. 2011 (CET)

Ach du lieber Himmel! Natürlich ging es um wikEd. Hab die beiden Sachen heute Nacht offenbar miteinander verwechselt. Entschuldige vielmals. Dennoch vielen Dank dafür, dass du dir trotzdem darüber Gedanken gemacht und deine Erfahrungen mit dem Autor hier mitgeteilst hast. So kann ich mir möglicherweise einiges an Frust sparen.

Allerdings muss ich auch dazu sagen, dass es erst dazu kam diesen auszuprobieren, nachdem ich den Wikieditor nach dem Einbinden in die vector.js nicht zum Laufen bekam; will heißen: Die Bearbeitungsleiste blieb unverändert, weswegen ich testweise derzeit eine Kombination aus dem Extra-Editbuttons-Helferlein und wikEd verwende. Lieber wäre es mir natürlich, wenn man auf beides Verzichten könnte, da beides nicht an den Vector-Skin angepasst ist. Aber um den Wikieditor (mit ähnlichen Funktionen) überhaupt zum Laufen zu bekommen, muss ich wohl noch etwas herumprobieren. -- ζ 10:13, 19. Feb. 2011 (CET)

Hast du unter deinen Einstellungen auch wirklich den Punkt „Erweiterte Bearbeiten-Werkzeugleiste aktivieren“ ausgewählt (und eventuell den Browser-Cache geleert, obwohl das inzwischen überflüssig sein sollte)? Denn dann müsste sich die Leiste wie in Datei:Script-Schnark-wikieditor.png ändern. --Schnark 10:18, 19. Feb. 2011 (CET)

Genau das habe ich gemacht – gerade eben erneut – und zur Sicherheit noch einmal mit einem anderen Browser kontrolliert und das Extra-Editbuttons-Helferlein und wikEd wieder deaktiviert. Doch das Ergebnis ist das Gleiche: Keine Wikieditorleiste, sondern die schnöde Standard-Bearbeitungsleiste. Irgendwie wird die wikieditor.js bei mir vollständig ignoriert, obwohl ich es genau nach Beschreibung in meine vector.js eingebunden habe.-- ζ 11:35, 19. Feb. 2011 (CET)

Ups. Einmal den Cache leeren. Warum müssen sich undefinierte Dinge in JavaScript auch immer gleich so bösartig verhalten? --Schnark 11:43, 19. Feb. 2011 (CET)

Das erklärt natürlich einiges. Sieht schon deutlich anders aus. Vielen Dank! ^^ -- ζ 11:54, 19. Feb. 2011 (CET)

ResourceLoader vsn 2.0 * Bugzilla

Hi,

bugzilla:25845 (27535, 27561) ist aufgewacht.

Da ich zu träge für einen Account bin, sei so lieb und bringe die Interessen doofer User und auch deine Meinung ein.

1. Das für normalsterbliche Skriptler verständliche Format "[[User:Me/myscript.js]]" sollte im lokalen Projekt unterstützt werden, auch wegen WhatLinksHere.
2. Benutzer:Krinkle mault. Dabei könnte er die PDD/monobook oder Vergleichbares kennen.
3. Es spricht ja nichts gegen load([ "[[User:Me/a.js]]", "[[User:Me/b.js]]", ... ]) und eine Einzelauswertung; load() kann sogar durchaus gemischt Module und allerlei Benutzer-Ressourcen enthalten und geht sie dann Element für Element durch.
4. Es kann unterstellt und von Benutzern verlangt werden, dass beim Format in Klammern [[User:Me/...]] der Seitenname immer auf .css oder .js endet; bei externem http wäre dies hingegen sonst explizit anzugeben.
5. Für Benutzer sollte die Schnittstelle möglichst simpel sein. Alles Zeugs mit user.w:de:User/... und dann registry und .using ist für einfache User viel zu kompliziert. Es ist außerdem völlig redundant; bei Auswertung der Liste von Wikilinks kann dies einmalig von Profis innerhalb des .load() in die passende komplexe Form gebracht werden, nach .js und .css sortiert. Das .load() muss hinterher die gleiche Einfachheit haben wie bisher importScript()+importStylesheet() – gerne mit dem Mehrwert von WhatLinksHere und einer Liste von Ressourcen.
6. Wenn die das nicht hinkriegen, dann mache ich das: loadResource
7. Krinkle sorgt sich um seinen Minimierer.
   • Das ist jetzt grad ein ungünstiger Zeitpunkt, den zu erwähnen.
   • Er will eine gemeinsam minimierte Datei aller bei dem einen load()-Aufruf genannten Ressourcen.
   • Wie ist das eigentlich mit dem Cache-Purging dabei, wenn sich nur User:Me/b.js zwischenzeitlich ändert? Bekommen die das eigentlich mit? Oder kriegt man dann die nächsten anderthalb Jahre die veraltete Version ausgeliefert, in minimierter Form?
   • Wenn das vernünftig läuft, wäre nichts gegen ein stets aktuelles minimiertes Caching der Benutzer-Ressourcen zu sagen. Mit Zeitstempel an der URL.
   • Momentan werden die Benutzer-load() ohnehin noch nicht minimiert, nur die common/skin.js/css jeweils gemeinschaftlich.
8. Ah ja, einen aktuellen Bock hätte ich auch noch zu melden:
   • Bindet man ein externes CSS ein, etwa

     mediaWiki.loader.load("https://secure.wikimedia.org/wikipedia/de/w/index.php?title=Benutzer:PerfektesChaos/shared.css&action=raw", "text/css");

   • so bekommt man eine wunderhübsche Firebug-Fehlermeldung: Die Quelle von diesem URL ist kein Text:: https://secure.wikimedia.org/wikipe..... etc.
   • Zwar wird das HTML-Dokument wunderhübsch generiert:

     <link rel="stylesheet" type="text/css" href=".....

   • Nur liefert leider das HTTP des Servers offenbar den MIME-Type text/javascript dazu. Ohne text/css von der URL schmeißt zumindest Firefox eine Meldung auf die Fehlerkonsole, und das CSS wird auch nicht bei der Seitendarstellung berücksichtigt.
   • Wir sind ja nicht nur doof: &ctype=text/css an die URL angehängt, und, oh Wunder! auf einmal geht's.

Schau mal, was du machst; schönen Sonntag einstweilen --PerfektesChaos 16:03, 20. Feb. 2011 (CET)

Okay, laut Hilfe:URL#RAW war ich der Depp und text/x-wiki hätte ich selbstverantwortlich vermeiden müssen.

• Hatte Krinkle nicht mal was mit Usability zu tun?
• Wieviel Normalo-Skriptler denken denn daran und kennen diese Falle?
• In das o.a. loadResource ist das mitdenkend eingebaut. So erwarte ich auch die MW-Software.

--PerfektesChaos 16:23, 20. Feb. 2011 (CET)

Mit Usability hat Krinkle nichts zu tun, er ist nur für das JavaScript zuständig, das mit dem ResourceLoader kam. Warum er selber irgendwelche Vorschläge macht, wie mw.loader.load zu funktionieren hätte, und es nicht einfach programmiert, ist mir unverständlich, jegliche Erweiterung der Syntax von load wäre eine Verbesserung, selbst wenn sie nicht direkt Links setzt. (Eigentlich sollte Krinkle ja die sortierbaren Tabellen auf jQuery umschreiben, aber da tut sich auch nichts.) Und solange die Qualität des Minimierers nicht steigt, bin ich ganz froh, dass nur meine vector.js davon betroffen ist. Ich habe die Hoffnung, dass en:User:MarkAHershberger vernünftige Vorstellungen hat, was die Programmierer jetzt tun sollten, und das denen auch unmissverständlich klar macht. --Schnark 09:28, 21. Feb. 2011 (CET)

wikEdDiff-Anzeige noch vor Speichern des Edits

Ich verwende ganz gerne den autoFormatter. Doch es kann passieren, dass dieser Änderungen vornimmt, die nicht gewünscht sind, was man allerdings erst nach dem Speichern eines Beitrages bemerkt (so hat er mir vorhin versehentlich einen Link ungültig korrigiert, indem er einen Bindestrich gegen einen Gedankenstrich ersetzt hatte). Beim vollständigen wikiEd-Helferlein kann man sich das Delta schon vor dem Abspeichern anzeigen. Doch wenn man nur das Script verwendet, funktioniert das leider nicht. Lässt sich da etwas machen? -- ζ 16:14, 21. Feb. 2011 (CET)

Wenn du auf „Änderungen zeigen“ gehst, müsste eigentlich unter dem angezeigten Diff auch WikEds Delta vorhanden sein. --Schnark 09:13, 22. Feb. 2011 (CET)

Glaubst du‘s? Ich bin echt betriebsblind. Den Button hab ich (eigentlich) noch nie gebraucht und im Laufe der Zeit ist mir überhaupt nicht mehr bewusst gewesen, dass er überhaupt da ist. Vollkommen übersehen. Damit geht es – natürlich. Danke. :) -- ζ 10:59, 22. Feb. 2011 (CET)

Knappe

Hi Schnark, ist denn dieser Edit korrekt? Ich schrieb "2001 oder später", Du änderst das in "nach 2001". Knappe ist womöglich 2001 verstorben. Denmach müsste es doch "nach 2000" heissen. Gruß --tsor 10:17, 23. Feb. 2011 (CET)

Hilfe:Personendaten#Datum: „nach: schließt hier immer das angegebene Datum mit ein“ Klingt zwar irgendwie komisch, aber so wird es halt gemacht. Viele Grüße --Schnark 10:23, 23. Feb. 2011 (CET)

Tatsächlich. Widerspricht zwar meinem Sprachgefühl, und meine Oma würde das wohl auch anders verstehen, aber wenn es denn so sein soll ... Wieder was gelernt. Gruß --tsor 10:26, 23. Feb. 2011 (CET)

Deine Oma sieht ja auch die Personendaten nicht, insofern hat zumindest sie kein Problem damit. Viele Grüße --Schnark 10:28, 23. Feb. 2011 (CET)

Also ich finde diese Definitiv auch etwas obskur und hätte diese Formulierung in der Form wohl auch nie gewählt, denn wenn er – mal angenommen – tatsächlich 2001 gestorben wäre, dann ist die Formulierung „nach 2001“ im Prinzip vollkommen falsch. Mit dem Wort „(da)nach“ wird die Folge eines vorangegangenen Ereignisses impliziert und die unmittelbare Folge (das Jahr 2002) kann erst nach (dem Jahresende) 2001 beginnen; zumindest wenn man die Ereignisse als Ganzes betrachtet.

Wenn man bei etwas differenzierter Betrachtung allerdings von dem Beginn des vorangegangenen Ereignisses (in dem Fall der Jahresanfang 2001) ausgeht, dann stimmt es wieder. Beispielweise findet man auch rechtlich eindeutige Formulierungen wie beispielsweise „Rechnungen sind innerhalb von 30 Tagen nach Rechnungsdatum fällig“. Damit wird eine Zahlung am Tag des Rechnungsdatums wohl kaum ausgeschlossen. Andererseits kann man auch damit argumentieren, dass die Formulierung unglücklich gewählt wurde und es korrekterweise „Rechnungen sind innerhalb von 30 Tagen ab Rechnungsdatum fällig“ heißen sollte.

Wie auch immer: Manchmal muss man zwar nicht alles verstehen, aber da es mich selbst interessiert wieso diese Definition festgelegt wurde, hab ich das Thema einmal angesprochen. -- ζ 13:12, 23. Feb. 2011 (CET)

Quelltext anzeigen (bug?)

Hallo Schnark, mir ist letzte Woche schon, aufgefallen dass beim "Quelltext anzeigen" (Bspw zum übernehmen deiner Scripte [11]) die Sonderzeichen nicht angezeigt werden!?! Und somit nicht funzen Vorlage:Smiley/Wartung/shock Vorlage:Smiley/Wartung/???  VG -- Perhelion 14:22, 25. Feb. 2011 (CET) Desweiteren stelle ich gerade fest, dass die Modulverwaltung spinnt!? (Alles steht auf deaktiviert, eventuell temporär?) -- Perhelion 19:02, 25. Feb. 2011 (CET)

Es wurde mal kurzzeitig auf HTML 5 umgestellt, falls dein Browser damit und mit Unicode Probleme hat, dann solltest du deinen Browser wechseln. --Schnark 09:04, 26. Feb. 2011 (CET)

Aja, jetzt gehts wieder (ich benütze übrigens FF4.0Beta) -- Perhelion 20:28, 27. Feb. 2011 (CET)

Doppelte Menüpunkte bei extratabs.js im Artikelnamensraum

Im Artikelnamensraum werden mir die neuen Tabs teilweise doppelt aufgeführt. Wenn auch mit leicht abweichenden Bezeichnungen (Fehlersuche/WikiLint oder Weblink-Check/Weblink-Checker), verlinken sie dennoch auf die selben Ziele. In der Versionsgeschichte eines Artikels wird der Tab „Diff zu mir“ auch mit identischer Bezeichnung verdoppelt. Die Menüpunkte „Kategorienbaum/Kategorien-Graph“ haben zwar minimal abweichende Ziel-URLs, was jedoch für das Ergebnis unrelevant ist. -- ζ 19:20, 25. Feb. 2011 (CET)

Wenn du sowohl meine extratabs.js als auch unter deinen eigenen Einstellungen das Gadget Wikipedia:Helferlein/Toolserver-Integration auswählst, musst du dich nicht wundern, dass manche Punkte doppelt vorkommen. --Schnark 09:06, 26. Feb. 2011 (CET)

Oha. Danke. :) -- ζ 09:16, 26. Feb. 2011 (CET)

Tjaja, für die nächste schlaflose Nacht merken wir uns dann if(mediaWiki.user.options.get("gadget-toolserver-integration")!=null) vor … --PerfektesChaos 15:28, 26. Feb. 2011 (CET)

Personendaten und Kategorie:Mann

Hallo Schnark, da Du Dich mit den Personendaten und den Kategorien so gut auskennst, möchte ich Dich bitten, einmal Deine Meinung zu dieser Diskussion auf meiner Disk zu schreiben. So mutig wie PerfektesChaos es wünscht bin ich noch nicht. Lieben Dank --Silke Ewering 21:42, 2. Mär. 2011 (CET)

Änderung von Personendaten

Sorry, ich hatte übersehen, einen Betreff einzusetzen. Hier noch mal meine Bitte:

Hallo Schnark, ich hatte auf der Seite des Tenores James Gilchrist das Geburtsjahr entfernt. Selbst wenn 1970 als DNB-Eintrag und in Konzertprogrammen auftaucht vorhanden ist, ist dies dennoch eine Falschinformation, wie mir von Mr. Gilchrist persönlich bestätigt wurde. Mir ist auch das richtige Geburtsjahr bekannt, doch da er selbst extrem zurückhaltend mit persönlichen Angaben ist und diese nur auf rein privater Basis mitteilt, halte ich es für einen Vertrauensbruch, so etwas öffentlich zu machen. Kannst Du Dein Rückgangigmachen meiner Änderung wiederum rückgängig machen? Gruß Turbolette (nicht signierter Beitrag von Turbolette (Diskussion | Beiträge) 19:15, 5. Mär. 2011 (CET))

Hallo Tubolette! Da in der verlinkten Kurzbiografie ein anderes Jahr angegeben war, habe ich das Geburtsjahr nun wieder aus dem Artikel herausgenommen. Sollte ein anderer Benutzer das anders sehen und wieder ein Geburtsjahr eintragen, dann hilft eine Email (am besten von der betroffenen Person selbst) an das Wikipedia:Support-Team weiter. Viele Grüße --Schnark 09:13, 7. Mär. 2011 (CET)