Vorlage:Archiv Tabelle

Abarbeitung der Listen mit Sonderzeichen

In Hinblick auf [1] scheint es bald einen neuen de-Dump zu geben, sodass ich die Listen neu erstellen kann. Da Zeit in den nächsten Wochen möglicherweise ein etwas knappes Gut sein wird, kann die Dauer zwischen dem Dumpzeitpunkt und der Erstellung der Wartungslisten allerdings etwas groß sein. Falls du dir also mal eine Pause gönnen willst, wäre der Beginn der Dumperstellung ein guter Zeitpunkt dazu, falls nicht, solltest du irgendwo eine Liste der abgearbeiteten Artikel führen, damit du die dann sofort aus der neuen Liste streichen kannst. Viele Grüße --Schnark 12:10, 11. Jan. 2011 (CET)Beantworten

Danke für die Info.
  1. Ich habe erstmal eine Kopie der künftig noch relevanten Infos unter Benutzer:PerfektesChaos/Zeichencodes.2010-09 angelegt, werde das Dump-Datum beobachten, ab dann bearbeitete Artikel separieren und mich still und leise durch den Bestand knabbern; es sind lehrreiche Testbeispiele.
  2. Du kannst gern den Server von einigen Dutzend MB an Zwischenversionen entlasten und ersatzlos löschen:
    Das macht auch deine Unterseiten übersichtlicher – und verwischt Spuren, wenn jemand seinen Strichelchen oder römischen Zahlen nachtrauern sollte.
  3. Betreffend der verbreiteten Brüche ⅓ ⅔ ⅛ ⅜ scheint niemand mehr Darstellungssorgen zu haben; es bleibt allenfalls ein sprachliches Problem, dass man im ganzen Satz besser „ein Drittel“ schreiben sollte. Ich führe sie deshalb nicht mehr auf.
  4. Erstellung von Wartungslisten hat gaaaanz viiieeel Zeit; wenn der Bestand jetzt einmal grundgeflöht wurde, reicht einmal jährlich eine Durchsicht. Längerfristig sollten narrensichere Zeichen wie etwa PrivateUse oder auch FigureDash dem checkwiki von SK aufgeschwatzt werden.
    A propos SK: Danke für die Info vor ein paar Tagen. Benutzer:S.K. kam mir öfters mit Programmierung und Vorlagen unter, und er/sie tauchte wohl auch im Umfeld von Syntax, Syntaxkorrektur (oder PD?) auf, so hielt ich das für einen abgelegten Zweitaccount zu SK. Dass es einen völlig anderen SteKrueBe oder so gibt, hatte ich hingegen begriffen.
Bekomm’ mir keine nassen Füße --PerfektesChaos 13:17, 11. Jan. 2011 (CET)Beantworten
Also: Ungewöhnlich ist aufgeteilt in Benutzer:Schnark/Wartung/Unerwünscht, Benutzer:Schnark/Wartung/Striche und Benutzer:Schnark/Wartung/Zahlen (ohne Drittel, mit Achteln), falls dir dieses alte Zeugs zu langweilig ist, gibt es unter Benutzer:Schnark/Wartung/Unsichtbar (ohne SHY, RLM, LRM) genug zu tun. Weitere Listen unterhalb von Benutzer:Schnark/Wartung werden vermutlich morgen folgen. Viel Spaß damit --Schnark 09:34, 17. Jan. 2011 (CET)Beantworten
Na, auf alle Fälle: Danke schön.
Sonnige Zeiten --PerfektesChaos 12:15, 17. Jan. 2011 (CET)Beantworten

[[Kategorie:Xxx|Xxx]]

wird in der augenblicklichen Version des Skripts zu [[Kategorie:Xxx]], was früher nicht so war, und eigentlich auch nicht so sein sollte (wird halt von einer falschen Variante in eine andere falsche Variante korrigiert). Viele Grüße --Schnark 10:36, 18. Jan. 2011 (CET)Beantworten

Ah, ich kapiere: Es ist die Entfernung des Sortierschlüssels, wenn dieser mit dem Lemma übereinstimmt. Sollte in diesem einen Fall aber dennoch nicht erfolgen. --Schnark 10:58, 18. Jan. 2011 (CET)Beantworten

Äh, grad eingeloggt.
  1. Danke grundsätzlich für die Info.
  2. Offenbar kein Fehler im Sinne von „Bug“, aber eine „nicht beabsichtigte Funktionalität“?
  3. Was ist denn „dieser eine Fall“? [Du bist so fleißig gewesen, viele Kat.sort-fix] Irgendwie Lemma=Kat=SORTIERUNG anscheinend? Allgemeine Bedeutung? Ich hatte vor einiger Zeit über irgendeine Nebenwirkung nachgedacht, weiß aber nicht mehr das vorstellbare Problem und ob nachteilig.
Neugierig --PerfektesChaos 11:41, 18. Jan. 2011 (CET)Beantworten
Dieser eine Fall sollte heißen Lemma = Kategorie = Sortierschlüssel (hinter der Kat.). Die nachteilige Nebenwirkung ist die Tatsache, dass ich so etwas wie Internetfernsehen per Dump-Scan nicht mehr finden würde, wenn vorher jemand mit deinem Skript vorbeikam und die Sortierung entfernt hat. Eigentlich könnte man in diesem Fall gefahrlos automatisch ein Leerzeichen als Sortierung einfügen. --Schnark 11:49, 18. Jan. 2011 (CET)Beantworten
Würde heißen:
Wenn   Kat==Lemma und keine SORTIERUNG und kein KatSortierschlüssel   dann   Einfügen KatSortierschlüssel=Leerzeichen
Kann ich ggf. machen nach Reorganisation in Version 3.0, wenn ich ohnehin die „machinenlesbare Endsektion“ Sort+Kat+PD+Link+Interwiki angehen will. Wartet aber auf 1.17 und Abwanderung in die en:WP.
Ist kategorischer Imperativ erfüllt?
Im vorliegenden Fall gab es ja das Leerzeichen schon mal, bevor Shadak kam. Dann nahm AWB das raus.
Um also deine bewundernswerte Dump-Analyse zu unterstützen, würde ich eher künftig den KatSortierschlüssel bei Identität von Kat mit Lemma/SORTIERUNG nicht entfernen, obwohl er ja funktional überflüssig ist? Kein Problem.
--PerfektesChaos 12:36, 18. Jan. 2011 (CET)Beantworten
Hört sich gut an. Dann hoffen wir mal, dass hier die rote Linie endlich mal die Null erreicht, sodass dann 1.17 kommen kann. Viele Grüße --Schnark 12:49, 18. Jan. 2011 (CET)Beantworten
Umsetzung im Quellcode erfolgt: Redundanter KatSortierschlüssel wird nicht entfernt, wenn Kat-Name./.Kat-Titel darauf schließen lässt, dass zuvor ein |]] gestanden haben könnte. Erfolgreichen Tag --PerfektesChaos 09:01, 19. Jan. 2011 (CET)Beantworten

Nichtstandard-Flags

Hallo! Ich hätte eine Verwendung dafür, wenn ich in meinen benutzerdefinierten Ersetzungen ein y als Flag für den regulären Ausdruck durchreichen könnte. So wie ich das im Quelltext lese, ist das im Augenblick nicht möglich.

Außerdem: Gibt es eigentlich eine Möglichkeit, die Syntaxpolitur auf einen String anzuwenden (sprich eine Funktion, die einen String entgegen nimmt, mit ihm das macht, was geschieht, wenn sich dieser Text in einer Textbox befinden würde, und zurückliefert, was dann in der Textbox stehen würde)? Falls ich das mal verwenden wollte, wäre es mir nämlich zu umständlich, eine unsichtbare Textbox zu erzeugen und dein Skript dann darauf loszulassen. Das hat aber wirklich noch viel Zeit, noch habe ich keinen konkreten Bedarf für eine solche Funktion. Viele Grüße --Schnark 11:06, 21. Jan. 2011 (CET)Beantworten

  1. Flag – wird geprüft und ermöglicht; vermutlich meckere ich darüber als Benutzerfehler, kann aber jeden von irgendeiner proprietären Syntax definierten Flag durchlassen, da sie ja nur von diesem Benutzer in seinem proprietären Browser ausgeführt werden.
  2. Gibt es schon für genau diesen Zweck, ist aber noch nicht nach außen dokumentiert und lohnt sich nicht vor der Umstellung 2.9→3.0 mit 1.16→1.17 in eigene Programmierung umzusetzen.
    function wikisyntax_TextMod(…)   bekommt einen wikitext-String und weitere Parameter, gibt ggf. geänderten wikitext-String und Status zurück.
    Tücken momentan: Parameterliste wird noch zukunftsfähiger gemacht werden, unter 3.0 ist diese Funktion nicht mehr im Standard-Ladeprogramm und muss dann ausdrücklich geladen werden.
Ansonsten erfreue ich mich deiner Scans und baue etwa gerade eine neue TrimLeft-Funktion, die nicht nur das ASCII-32 entfernt, sondern auch alle anderen spacecode-Variationen, von denen ich bislang gedacht hatte, dass ihre Speicherung auf dem Server gar nicht möglich sei.
Bald ist Wochenende, freu dich --PerfektesChaos 11:22, 21. Jan. 2011 (CET)Beantworten

Sodele,
x29.js steht zum 'rumspielen bereit.

  1. Flag y müsste klappen.
    Hintergrund war: Wird als Flag angegeben Oma fährt im Hühnerstall Motorrad, dann schmiert das Brauser-JS mit kryptisch-konfuser Fehlermeldung ab, ohne nähere Einzelheiten.
  2. String-Transformator ist im vorgesehenen Zustand:
    • WikisyntaxTextMod_InhibitRun=true; (machst du schon mal irgendwo)
    • x29.js laden
    • wikisyntax_TextMod(wikitextstring) aufrufen; Aufruf und der komplexe Rückgabewert haben jetzt den Endstand.
    • Wenn du mit API arbeitest, vergiss UTF-8 nicht.
  3. katsortfix (wie zuvor) wird nicht mehr entfernt. Wartung/Katsort enthält jedoch keine geeigneten Testfälle mehr.

So ganz verstanden, was mit den spukhaften Nicht-Zeichen passiert, habe ich auch noch nicht. Teils entferne ich sie automatisiert vor Weblink, Diff zeigt sie nicht an, WikEd zeigt sie nicht, antispoof kann sie nicht sehen, sie sind aber offensichtlich dann weg und waren laut action=raw vorher da.
Schönes Wochenende --PerfektesChaos 20:18, 21. Jan. 2011 (CET)Beantworten

Eine Frage bleibt noch offen bezüglich wikisyntax_TextMod: Wo erwartet die Funktion bzw. die Folgefunktionen den Titel der Seite (wichtig bei Selbstlinks etc.)? --Schnark 09:47, 24. Jan. 2011 (CET)Beantworten
Die Frage ist berechtigt und noch völlig offen: Bisher wurde die gesamte Arbeitsumgebung aus den Umgebungsvariablen des aktuellen Artikels bezogen. In einem API-Kontext sind die natürlich nicht gesetzt. Letztendlich würde es darauf hinauslaufen, diese im kontextfreien Raum zu simulieren; dazu müsste ich mindestens dokumentieren, welche das sind. Da ich aber ohnehin die Umgebung und die LEGACY_GLOBALS oder mediaWiki.config analysiere und dann überführe in
  • WikiGlobal_ContLang
  • WikiGlobal_DBname
  • WikiGlobal_NsNumber
  • WikiGlobal_SiteName
  • WikiGlobal_Title
könnte ich auch eine Schnittstelle für Benutzer schreiben, die die erforderlichen vorab besetzt und die Umgebung nicht mehr analysiert. Das wäre der sinnvollere und robustere Weg; dazu muss ich mir mal den zeitlichen Ablauf genauer ansehen.
Eine anregende Nachfrage --PerfektesChaos 11:27, 24. Jan. 2011 (CET)Beantworten
Definitive Implementierung zur Erprobung bereit.
--PerfektesChaos 00:53, 25. Jan. 2011 (CET)Beantworten
wgSiteName ist – wie ich selbst feststellen musste – eine der Variablen, mit denen man eigentlich überhaupt nichts anfangen kann, sie enthält zwar das Projekt, aber in der dortigen Sprache, in fr: ist z. B. wgSiteName=="Wikipédia". --Schnark 09:14, 25. Jan. 2011 (CET)Beantworten
Das kann gut sein; aber sie ausschließlich wird zur Selbsterkenntnis in der Landessprache benutzt, um in Wikilinks Namensräume wie auch [[WP: oder [[Project: zu erkennen – sonst nirgends.
Liebe Grüße --PerfektesChaos 09:54, 25. Jan. 2011 (CET)Beantworten
wikisyntax_affiliated_project liest sich aber nicht so, als wäre SiteName nur für Namensräume da, für diese würde ich sowieso wgFormattedNamespaces["4"] empfehlen, sonst könntest du auf mw: Probleme bekommen. --Schnark 10:14, 25. Jan. 2011 (CET) PS: Habe auch auf meiner Disk. geantwortet.Beantworten

Danke für’s Mitdenken, aber die Logik ist hier anders: Es geht darum, dass Wikilinks auf WMF-Schwesterprojekte einheitlich und in der Kurzform formatiert werden. Dies muss aber unterbunden werden, wenn es nicht das Link auf das Schwesterprojekt ist, sondern auf den Projekt-Namensraum, den man immer auch [[Project: nennen könnte.

  • Ich bin auf de.WP, finde ein Link auf [[Wikisource: und ersetze durch [[s:en: als kurze Einheitsform.
  • Ich bin auf de.WP, finde ein Link auf [[Wikipedia: und mache garnichts, weil identisch mit wgSiteName.
  • Ich bin auf irgendeiner Wikisource, finde ein Link auf [[Wikisource: und mache nichts, weil identisch mit wgSiteName.
  • Ich bin auf irgendeiner Wikisource, finde ein Link auf [[Wikipedia: und ersetze durch [[w:en: als kurze Einheitsform.

Ansonsten interessieren mich hier die Namensräume selbst nicht, weder in der generisch-englischen noch in der lokalisierten Form.

Auf mw: wie in der en.WP heißt es [[Project: – was mich nichts angeht, weil es kein WMF-Schwesterprojekt namens „Project“ gibt, mit dem ich das verwechseln könnte.

Dein Hinweis hat mich aber an eine Sache erinnert: Innerhalb der fr.WP ist [[Wikipédia: gemappt auf [[Wikipedia: und darf nicht durch [[w:en: ersetzt werden. Bevor ich also auf der fr.WP Reklame für mich mache, müsste ich weitere Untersuchungen anstellen, insbesondere ab heute den sortkey von wgSiteName bilden.

Guten Appetit --PerfektesChaos 12:13, 25. Jan. 2011 (CET)Beantworten

Die andere Richtung gibt es auch: Bei den Türken ist wgSiteName=="Wikipedia", aber Wikipedia kann zu w:en werden, da der Projektnamensraum Vikipedi heißt. --Schnark 12:32, 25. Jan. 2011 (CET)Beantworten
  1. Jetzt pappesatt.
  2. Danke für die weitere Bereicherung meines internationalen Horizonts. Das ist ja der Sinn der WP, dass man ständig dazulernt. – Was die türkischsprachigen Freunde angeht, so richte ich dort zumindest keinen Schaden an, wie das sonst der Fall wäre, wenn wikisyntax_affiliated_project nicht den Projekt-Namensraum von der Link-Umformatierung ausnehmen würde; es bliebe halt unverändert stehen. Diese und ähnliche Sonderfälle würde ich bei Expansion in nichtdeutsche Bereiche im künftigen Modul WikisyntaxTextMod_rL.js (L=Localization) zusätzlich zum Standardprogramm abhandeln; dafür gibt es bereits eine spezielle „hook“-Logik. Sie wird gerade durch WikiGlobal_ContLang und WikiGlobal_DBname angeschubst; auch die Personendaten der „dewiki“ laufen über einen solchen hook.
  3. Nun widme ich mich deinem o.a. PS und mache auf deiner Disku weiter.
Bis gleich --PerfektesChaos 13:40, 25. Jan. 2011 (CET)Beantworten

'Falsche' Änderungen?

Hallo, ist das hier angesprochene Verhalten zu erklären? Gruß, Elvaube Disk 22:42, 22. Jan. 2011 (CET)Beantworten

Ja, sehr einfach:
Die waren vorher schon da, also bereits in der 2011-01-18 um 10:42:25 und schon länger unsichtbar mitgeschleppt.
Wie in der Doku beschrieben, werden sie von meinem Skript als HTML-Entities für dich sichtbar gemacht, damit du sie einfach löschen kannst. Wer mit WikEd arbeitet, sieht an dieser Stelle jeweils ein oranges Quadrat mit Tooltip. Nur wenn die rlm und lrm bei arabischer Sprache oder hebräischer Schrift sinnvoll sind, könnte man sie belassen, würden aber in eine Vorlage gehören. Im normalen Wikitext behindern sie Suchvorgänge und das Editieren durch seltsame Effekte.
Schönes Wochenende --PerfektesChaos 22:57, 22. Jan. 2011 (CET)Beantworten

Frage zum Zusammenfassungtext

Hallo, du formatierst in letzter Zeit diverse Artikel um. Dazu mal ein paar Fragen:

  1. Welches "unleserliches" Zeichen hast du hier entfernt [2]?
  2. Warum änderst du die Art der Einbindung von Einzelnachweisen systematisch um? Soweit mir bekannt ist gibt es keine bevorzugte Variante und Änderungen von korrekten Varianten sind in der Wikipedia eigentlich nicht gern gesehen.

Grüße --Cepheiden 18:23, 4. Feb. 2011 (CET)Beantworten

ad 1) Es handelt sich um Zeichen der Windows CP1252, die in manchen Browsern angezeigt werden, in anderen nicht. Wer sie sieht, bekommt sie möglicherweise doppelt, weil ein anderer Autor das scheinbar „fehlende“ Zeichen nochmals in Unicode geschrieben hat, oder es ist für manche sichtbar und andere sehen eine inhaltliche Lücke (also Seite 5357 statt 53–57 oder auch 53––57), oder es wird ein Ersatzzeichen (Quadrat) angezeigt.
ad 2) Ich erinnere mich, dass es kürzlich einen LA gegen die Vorlage:Literatur gab, bei dem auch die deutlich erschwerte Lesbarkeit des Wikitextes durch diese Vorlage Thema war, was auch der Admin abschließend feststellte. Insbesondere wurde hier von vielen Teilnehmern die Unübersichtlichkeit bei Verwendung mitten im Text scharf kritisiert, die künftig nur noch „mehrzeilige“ Anordnung als Bedingung für die Beibehaltung der Vorlage auch von prinzipiellen Befürwortern eingefordert wurde. Wenn ich mir also die Mühe mache, die Einbindung der Vorlage in den Block references…/references zu verschieben, dient dies der deutlichen Verbesserung der Lesbarkeit und der Arterhaltung der Vorlage beim nächsten LA.
HGZH --PerfektesChaos 18:43, 4. Feb. 2011 (CET)Beantworten
ad 1) Mhh das mit CP1252 ist mir neu, wie kann man prüfen welches Zeichen man einbaut?
ad 2) Das ist nobel. Ich bin aber nicht der Meinung, dass die mehrzeilige Form lesbarer ist, weder im Fließtext noch in den entsprechenden Abschnitten. Nun gut, dass ist wahrscheinlich Ansichtssache. Und bezüglich eines neuen LA der Vorlage, das Lesbarkeitsargument können wieder kommen, sind aber von der Bewertungsseite her abgehakt und damit nicht mehr relevant für eine Löschbegründung. Und ob er Block references…/references hier eine Verbesserung ist oder nicht, darüber scheiden sich ja auch die Geister. Nunja, danke für die Antworten. --Cepheiden 18:54, 4. Feb. 2011 (CET)Beantworten
ad 1) hast du da nicht ein Minuszeichen (−) gegen ein Halbgeviertstrich (–) getauscht? --Cepheiden 18:59, 4. Feb. 2011 (CET)Beantworten


  • (Beim angesprochenen edit handelte es sich übrigens um das \x96 „–“ zwischen 24 und 33 bei Mirza/Ayon.)
  • Prüfen kannst du es eigentlich nicht, und beim korrekt funktionierenden Browser unter Windows kann es nicht vorkommen. Windows-Browser kennen die historischen Zeichen und wandeln sie selbsttätig in korrekten Unicode um, wenn sie an den Wikiserver geschickt werden. Wie die Zeichen überhaupt in den Wikitext gekommen sind, ist mir rätselhaft; meine einzige Erklärung wäre, dass jemand unter Linux aus einer Windows-Datei mit Copy&Paste etwas in den Wikitext eingefügt hat. Weil die Zeichen 127–15910 in Unicode nicht definiert sind, werden sie teilweise mit Breite Null, also unsichtbar dargestellt. Autoren konnten dann also auch nicht wissen, was sie da mitschleppen.
  • Nach meinem Verständnis von Typografie gehört ein Minuszeichen ausschließlich in arithmetische Berechnungen; hingegen erfüllt die chemische Bindung ideal die Bedingungen für einen Bis-Strich. Sollte es in irgendeinem Portal eine abweichende Wikipedia-spezifische Haustypografie geben, bitte ich um ein entsprechendes Link, damit ich dazulernen kann.
Schönen Abend noch --PerfektesChaos 19:14, 4. Feb. 2011 (CET)Beantworten
\x96 „–“ zwischen 24 und 33 bei Mirza/Ayon. ? Das Zeichen hattest du doch gar nicht geändert, oder?
Die Zeichensetzung (mit allen Fehlern) in diesem Artikel gehen eigentlich alle auf mich zurück. Komisch
Das mit dem Minuszeichen war nur ein Hinweis für die Diskussion, die Umwandlung habe ich damit nicht angezweifelt. Die WP:Redaktion Chemie hat ja auch in ihren Richtlininen den Bis-Strich für die einfache kovalente Bindung festgelegt. (Da es sich in den Beispielen aber nicht um eine konkrete Bindung geht hab ich sie wieder entfernt. Aber das nur am Rande)
Grüße --Cepheiden 19:34, 4. Feb. 2011 (CET)Beantworten
Ich habe es geändert. Es scheint für dich unsichtbar zu sein und zu bleiben. Die einzige Möglichkeit, die du hättest, wäre action=raw/vorher und action=raw/nachher.
Ich knabbere mich aber genüsslich durch den Bestand und eliminiere sie, so dass sich das Problem hoffentlich weitgehend legen wird.
Schönes Wochenende --PerfektesChaos 20:44, 4. Feb. 2011 (CET)Beantworten

Tags ohne Parameter

Bei dir steht math unter den Tags ohne Parameter, allerdings kann das Tag mindestens ein style mitbekommen:  . Ob das irgendwo Probleme macht und welche der anderen Tags auch noch Parameter haben können, musst du wissen. Viele Grüße --Schnark 12:08, 10. Feb. 2011 (CET) PS: Kennst du eigentlich cosmetic_changes.py, das Skript, das Bots verwenden um Syntaxpolitur durchzuführen?Beantworten

Danke für's Aufpassen. „Probleme“ macht das keine; die Bereiche beginnend ab <math werden so oder so als schützenswert definiert – ich ahnte schon, warum. Lediglich eine stilistische Verfeinerung würde momentan nicht ausgeführt, wenn der style-Parameter vorhanden ist. (Dies ist soeben angeglichen worden). Wenn Hilfe:math dann noch so freundlich wäre, die Tag-Syntax zu dokumentieren …
cosmetic_changes.py kannte ich inhaltlich nicht; gleichwohl hatte ich die kosmetischen Aktivitäten und Unterlassungen der bots intensiv analysiert. Sollte mich cosmetic_changes.py auf neue Ideen für robuste Polituren bringen, werden sie natürlich umgesetzt. Schaue ich mir gern an.
Guten Appetit --PerfektesChaos 12:23, 10. Feb. 2011 (CET)Beantworten
Im Normalfall kann man immer über die Dokumentation meckern, in diesem nicht: Hilfe:Math#CSS-Styles --Schnark 12:36, 10. Feb. 2011 (CET)Beantworten
Okay, nehme ich halb zurück – ich war durch das TOC gesprungen und hatte den Hilfetext durchgescrollt, ohne eine Tag-Syntax zu finden; also zumindest nicht auffallend. Problematisch bein Aufbau dieses Hilfetextes ist, dass die lange Detailbeschreibung von universell anwendbarem La-Tex, die auch im ANR oder als Tex-Wikibook stehen könnte, verquirlt ist mit dem Thema im Hilfe:Namensraum – wie das in Wikitext eingesetzt wird, und dieses völlig erschlägt. --PerfektesChaos 12:45, 10. Feb. 2011 (CET)Beantworten

.py war aufschlussreich; danke schön.

  1. Zumindest bin ich nicht mehr allein in der Welt mit dem Schutz von Linkzielen und kodierten Bereichen. Ob es irgendwo noch ein interaktiv eingesetztes JS gäbe, wäre anlässlich meiner Auswanderung mal wieder zu suchen. Bei einer ersten Recherche in der en.WP fand sich nichts öffentlich beworben.
  2. Ansonsten mache ich fast alles bereits in der de.WP, was das py-Skript auch machen würde. In Commons bin ich noch nicht eingestiegen.
  3. Eine Anregung war die Verwechslung des Nummernzeichens mit dem Grad-Zeichen, die ich aufgreifen werde.
  4. Die weitaus überwiegende Menge an kosmetischen Änderungen wird von den mir aus der de.WP bekannten Bot-Läufen nicht vorgenommen; entweder sind das keine py-Bots oder sie haben die Kosmetik nicht aktiviert.
  5. Ich gestehe, mich aus reiner Faulheit der Formatierung usbekischer ISBN nicht ausreichend gewidmet zu haben und hole das nach, angeregt durch pywikipedia/isbn.py.

--PerfektesChaos 17:52, 10. Feb. 2011 (CET)Beantworten

Fehler in simple

Du darfst diese Fehlermeldungen gerne so lange ignorieren, wie du willst, ich habe nicht vor, dein Skript in simple: zu verwenden, nur weil dort jetzt 1.17 läuft, habe ich mal ausprobiert, ob alles funktioniert und dabei auch mal interessehalber dein Skript per Cookie aktiviert.

  1. wgContentLang (mw.config.get('wgContentLang') sollte man ja inzwischen dort sagen) ist 'en', sodass dein Skript immer an den Interwikilinks rumpfuscht.
  2. Sämtliche Namensräume und DEFAULTSORT werden durch dein Skript in Kleinschreibweise überführt.
  3. Hier wird das A in der ersten Bildbeschreibung zu undefined.
  4. Sonst sieht alles gut aus. Viele Grüße --Schnark 10:30, 11. Feb. 2011 (CET)Beantworten
Danke für die Rückmeldung; ich hatte außerhalb der de.WP bislang nur kursorisch in der en.WP herumgetestet und die fr.WP, tr.WP und simple wie auch wikisource oder wikiquote bislang nicht angefasst. Bevor ich eine Freigabe oder gar Empfehlung für irgendeines dieser Projekte geben würde, käme erstmal ein Testen und Erkunden projektspezifischer Besonderheiten.
Weil wir kürzlich das SetContext() für eine Global-Umgebung thematisiert hatten: Wahrscheinlich ist es glücklicher, den Namen der DB auszuwerten und ihm die eindeutige Kontext-Konfiguration zu entnehmen statt die Sitename und ContentLang aus den Einzel-Variablen zu verwenden. Damit würde sich auch simple auflösen.
Inwieweit ermöglichte eines deiner Skripte eigentlich XSS-Einlasspforten? Ich dachte, dass alles außerhalb der Benutzerskript-Domain immer ein eigenes Fenster (popup) benötigen würde.
Danke einstweilen --PerfektesChaos 10:42, 11. Feb. 2011 (CET)Beantworten
Da wgDBname inzwischen immer als Variable ausgeliefert wird (war früher nicht so) und außer dieser Variablen nur die URL die genaue Sprache kennt, ist es wohl am besten auf den Datenbanknamen zurückzugreifen (oder simple einfach zu ignorieren, ist auch inhaltlich am besten …). Nach einigem Nachdenken sieht zumindest kein Problem 1.17-spezifisch aus (wäre auch merkwürdig gewesen).
Ein Angreifer, der mein Skript verstanden hätte, hätte immerhin innerhalb von about:blank ein beliebiges Skript mit Zugang zu einem gültigen Edit-Token ausführen können, würde es ein Administrator ausführen, so wäre problemlos Hauptseiten-Vandalismus möglich, eine andere Möglichkeit bestünde darin, dem Benutzer dadurch ein bösartiges Skript dauerhaft in seine vector.js einzutragen. Allerdings war die Tatsache, dass das Skript einfach alle Backslashes verschluckte, gravierender als die Tatsache, dass dies irgendwelche theoretischen Angriffe ermöglicht (vor allem, da zwar zwei Leute das Skript eingebunden haben, aber noch keiner von beiden es bisher verwendet hat.) --Schnark 11:03, 11. Feb. 2011 (CET)Beantworten

Deinen Hinweisen bin ich gefolgt.

  • Die Abfrage von wgContentLanguage und wgSiteName habe ich eliminiert, wie auch ihre Abbildung als WikiGlobal_*.
  • wgDBname ist deutlich systematischer und konsistenter definiert. Sollte es irgendwann ein Spaßvogel wieder aus der Server-Software herausnehmen, würden sich Alternativen konstruieren lassen.
    • Auf simplewiktionary ist wgContentLanguage=simple. Warum auch immer.
    • Auf iswikiquote ist wgSiteName=Wikivitnun und so auch der Projekt-Namensraum. Interessiert mich nicht mehr.
    • Das Gefummel mit Accent aigu in der fr.WP fällt somit auch weg.
    • Wie bisher gibt es eine hook-Funktion, die Besonderheiten etwa der tr.WP abbildet.
    • SetContext() in der API wurde entsprechend gekürzt; hier war mir bereits die Redundanz aufgefallen.

Zu 1.) Somit erledigt.
Zu 2.) Dem werde ich Ende des Monats auf en.WP nachgehen.
Zu 3.) undefined weist auf eine fehlende Lokalisierungsdefinition. Diese Situation sollte eigentlich überall dahingehend abgefangen sein, dass dann nichts passiert; hier ist mir seit dem letzten Testen vor etlichen Monaten wohl einer durch die Lappen gegangen. Lohnt sich erst nach dem Umzug und der Neugliederung.
Schönes Wochenende --PerfektesChaos 13:19, 12. Feb. 2011 (CET)Beantworten

WP:CSS

Hallo PerfektesChaos, ich bin gerade auf Benutzer:PerfektesChaos/css gestoßen und habe mir spontan gewünscht, das nach WP:CSS zu verschieben und das zu einer CSS-Hilfe-Seite umzubasteln. Das wäre, glaube ich, eine große Hilfe für viele, die mit der Materie CSS auf Wiki nicht vertraut sind. Was denkst du? Grüße von Jón + 18:59, 15. Feb. 2011 (CET)Beantworten

Danke für deine warmen Worte – es scheint dir geholfen zu haben. So ist das gedacht.
Es steht WP:CSS (=Wikipedia:Skin) frei, darauf auffallend zu verlinken. Was jedoch auf meiner Benutzer-Unterseite steht, bleibt unter meiner redaktionellen Aufsicht. Die Seite Wikipedia:Skin ist hingegen ein buntes Potpourri und keine Hilfe-Seite. Bestimmte langjährige Erfahrungen in der Wikipedia lassen es mich einstweilen vorziehen, die bestehende Aufteilung zu belassen. Erst im Zuge einer Reorganisation der Community-Seiten und Bildung echter CSS- und JS-Anleitungen würde ich dies als Grundstock einbringen. (Kennst du schon js/Infos?)
Schönen Abend --PerfektesChaos 20:19, 15. Feb. 2011 (CET)Beantworten
Naja, aber von alleine wird das natürlich nichts. Der jetzige Zustand auf WP:SKIN ist wenig hilfreich, deswegen würde ich eben vorschlagen, dass du deinen Text nach WP:CSS kopieren könntest, und ich würde dann auch ein Intro dazu basteln. Bei der Kopie hast du den Vorteil, dass du den Text weiter in deinem BNR hast. Gerne mache ich auch die CSS-Seite, wenn du mir erlaubst, deinen Text als Grundlage zu nehmen. Zu js/Infos: ja, das habe ich auch gesehen. Und wahrscheinlich könnte man das genauso nach WP:SKIN schieben und die Beispiele eben als Beispiele darunter. Ich denke, da wird niemand etwas gegen haben. Grüße von Jón + 22:07, 15. Feb. 2011 (CET)Beantworten

Der momentane Zustand von Wikipedia:Skin hat zehn Jahre Entwicklungsprozess hinter sich und ist mir momentan zu verbastelt und konfus. Dies war auch der Grund, warum ich eigene Hilfetexte für interessierte Benutzer geschrieben habe. Anfreunden könnte ich mich mit folgender Seitenstruktur:

  • WP:Skin
    • „Einleitungsteil“ des momentanen Wikipedia:Skin
    • + dessen „Siehe auch“
    • + weiterer Überblick und Verlinkung auf Unterseiten
  • WP:Skin/Baukasten
    momentane Wikipedia:Skin #Benutzerskripte
  • WP:Skin/CSS
    Meine erwähnte Seite als Basis
    Redirect: WP:CSS
  • WP:Skin/GUI
    Einrichtung von Knöpfen usw., usability, wikieditor
  • WP:Skin/JS
    Meine erwähnte js/Infos als Basis

Die anstehende Umstellung MediaWiki 1.16→1.17 ist ohnehin Anlass, zu künftigen Anpassungen von JS Informationen zu geben.

Die Gruppierung als Unterseiten von WP:Skin gibt dem Ganzen aber eine logische und inhaltliche Klammer. Umgekehrt wäre es zu unübersichtlich, irgendwie alles auf einer einzigen Seite WP:Skin zu vermanschen.

Ich bin nur ein kleines Lichtlein und würde so einen Eingriff in Community-Seiten nicht allein unternehmen wollen; vielleicht talkt ihr Admins zunächst mal. Falls eine derartige Restrukturierung dort zumindest keinen Widerspruch findest, kannst du gerne Rauchzeichen geben; ich würde dann nach robuster Einführung von MediaWiki 1.17 die Seiten entsprechend strukturiert aufbauen.

Schönen Abend --PerfektesChaos 22:40, 15. Feb. 2011 (CET)Beantworten

Ich denke, man sollte das mal auf Wikipedia Diskussion:SKIN vorschlagen (ich verweise auf diese Disk.). Ansonsten ist man da als Admin ein ebensokleines Licht, vor allem, wenn man noch viel weniger Ahnung von der Sache hat als du ;-) - ich finde deine Strukturierungsvorschläge sehr gut. Grüße von Jón + 22:57, 15. Feb. 2011 (CET)Beantworten

Wartungslisten

Was hältst du eigentlich davon, alles unterhalb von Benutzer:Schnark/Wartung nach Benutzer:PerfektesChaos/Wartung zu verschieben? Du hast inzwischen vermutlich einen wesentlich besseren Überblick als ich, wie die Seiten organisiert sind, und außer dass ich sie erstellt habe, haben die Listen eigentlich nichts mehr mit mir zu tun. Bräuchte natürlich einen Admin, da nur die Seiten mit allen Unterseiten auf einmal verschieben können und auch noch die Weiterleitung dabei unterdrücken können, aber wenn du mir zustimmst, findet sich sicher jemand, der das macht. --Schnark 11:35, 19. Feb. 2011 (CET)Beantworten

Das kann gern geschehen.
Alternativ zu einer globalen Verschiebung kann ich die Seiten bei mir auch nach und nach einzeln anlegen, die Inhalte kopieren und auf diese Weise bei dir erledigte Seiten für einen SLA markieren, der irgendwann en bloc von dir gestellt werden müsste. Das kann sich aber durchaus noch bis in den März hinziehen.
Wahrscheinlich wäre es danach noch sinnvoll, wenn du in etwa einem halben Jahr einmal einen dann frischen Dump zu den jeweiligen Fragestellungen auswerten würdest, ob noch Reste offen sind, revertiert oder neu eingeschleppt wurde.
Auf lange Sicht will ich das aber auch nicht hosten. Nachdem einmal die Besonderheiten zu den einzelnen Zeichenkodierungen und ihr Sinn und Unsinn klar herausgearbeitet und dokumentiert wurden und der Artikelbestand grundbereinigt ist, sollte die Angelegenheit dem Projekt Syntaxkorrektur vermacht werden und SK mag in checkwiki nach garantiert sinnfreien Zeichen suchen.
--PerfektesChaos 12:32, 19. Feb. 2011 (CET)Beantworten

WSTM

Drei Fragen/Anregungen:

  1. Vielleicht bin ich gerade einfach nur zu blöd: In Benutzer:Schnark/js/Wikisyntax-config.js setze ich (auf recht komplizierte Weise, es gibt Leute, die trotz Warnung kopieren ohne selbst nachzudenken) OnRequest_WikisyntaxTextMod = ['.'], was mich bisher (wie ich es noch nicht so kompliziert gemacht habe) die Syntaxkorrektur von Hand überall aktivieren ließ, jetzt aber nicht einmal mehr in Artikeln funktioniert. Ein Aufruf von WikisyntaxTextMod_Run() tut einfach gar nichts. Hast du eine Ahnung, woran es liegen könnte?
  2. Man stößt ja beim Testen immer auf die absonderlichsten Fälle, in diesem Fall waren es die ungeklammerten Weblinks in Ophiocordyceps unilateralis. Was hältst du davon unter Benutzer:PerfektesChaos/js/WikisyntaxTextMod/usage/replace#http meine Variante
["[^=\\s] +",    "(https?://)([^:/]+)(:[0-9]+)?/?(.*)",  false],
[false,          "[$1$2$3/$4 $2]",                       false]
zu verwenden?
3. Ein <references> ohne nachfolgendes </references> ist immer falsch und erzeugt eklig schwer zu findende Fehler. Eigentlich müsste es sich doch machen lassen, es entweder durch <references /> zu ersetzen, oder – wenn <ref>s folgen –, das schließende Tag am Ende zu ergänzen.

Viele Grüße --Schnark 10:40, 28. Feb. 2011 (CET)Beantworten

ad 1a) Du bist nie zu blöd.
ad 1b) Ich bewunderte bereits das Warndreieck und hatte seine Spur verfolgt (auch die var Schnark_2.*).
ad 1c) Auf den ersten Blick müsste '.' gehen, wie auch '.*' – was mich gerade dazu anregt, auch true zuzulassen und dadurch den von dir gewünschten Effekt. Werde über Mittag herumprobieren und Genaueres mitteilen.
ad 2) So ähnlich kann ich das gerne als Anregung in die Benutzerdefinierten aufnehmen.
Persönlich verwende ich dann " *[^ |}]" als abschließenden RegExp; bin aktuell im Bereich URL gerade am Vervollkommnen.
ad 3) Möglichst nicht in der Kernkompetenz, lieber aber als Vorschlag in den Benutzerdefinierten. Mit unmittelbar nachfolgendem </references> wird es bereits automatisch zum unary tag. Über einen benutzerdefinierbaren Ausdruck müsste ich tüfteln; wenn dieser nicht sinnvoll, dann Skript-seitig, vielleicht als Kommentar-Anregung. Ich analysiere bereits öffnendes <references>, strukturiere eine ref-Liste und werde über nicht gefundenen Abschluss dabei genauer nachdenken.
Bis in Kürze --PerfektesChaos 12:48, 28. Feb. 2011 (CET)Beantworten
ad 1c) Erstes Zwischenergebnis: Bei mir verhält sich OnRequest_ wie vorgesehen und dokumentiert; er sollte auch nur die bereits durch Automatik gewünschten Möglichkeiten erweitern und hat die gleiche Ursache wie das Warndreieck. Möglicherweise vertut sich der obfuscator?
Weiter ermittelnd --PerfektesChaos 13:07, 28. Feb. 2011 (CET)Beantworten
Zu 1 = OnRequest_
  • Hier wurde Mitte Januar etwas geändert, seit 30. Januar live, erst seit heute in diesem Bereich unverändertes neues r.js – zeitlicher Zusammenhang erkennbar?
  • In der Adresszeile der URL bei bearbeiteter Seite eingeben: javascript:WikisyntaxTextMod_Run() – irgendeine Reaktion?
  • Reaktion ist nur sichtbar, wenn es auch etwas zu ändern gibt; irgendwo im Text &#8211; unterbringen und auslösen?
  • Bei mir ist "." und dessen Ein-/Ausschalten wirksam wie beabsichtigt. Obfuscator-Ergebnisse in msgbox?
  • Obfuscator-Definition würde sicherheitshalber vor dessen Aufruf gehören.
Neue Version aus anderen Gründen vermutlich im Laufe der Nacht. --PerfektesChaos 16:50, 28. Feb. 2011 (CET)Beantworten
ad 1: Es gibt ein Problem mit der Aufrufreihenfolge; wm.loader.load(), importScript(), $() und addOnloadHook() ... noch am Untersuchen ... --PerfektesChaos 22:20, 28. Feb. 2011 (CET)Beantworten
Sehr obskur, aber so obskur, dass es dir vielleicht bei der Fehlersuche hilft: Es funktioniert alles, nur nicht das, was in Modif_Text steht (Modif_Link funktioniert). Mein erster Gedanke war, dass doch Punkt 1a) gilt, und ich nicht nur andere, sondern auch mich und die Konfiguration verwirre, aber per javascript:alert ist nachvollziehbar, dass Modif_Text ein zweidimensionales Array mit genau dem Zeug enthält, das darin stehen soll. Insbesondere liefert javascript:alert(isArray(Modif_Text)) wirklich true. Meine benutzerdefinierten Ersetzungen tun aber auch dann nichts, wenn ich einen Artikel direkt zum Bearbeiten aufrufe. --Schnark 09:42, 1. Mär. 2011 (CET)Beantworten
Ich nehme alles zurück, es war doch der Fall 1a) [3] --Schnark 10:05, 1. Mär. 2011 (CET)Beantworten

Danke, aber ich bin mittlerweile auf einem anderen Trip: Bis zum Wochenende war die Ausführungsreihenfolge so, dass das Arbeiten am Wikitext zum Schluss kam, während vorher WSTM.js und danach WS-config.js in dieser Reihenfolge mit importScript geladen waren. Somit hatte ich vor einer Woche das addOnLoadHook herausgenommen und es klappte seltsamerweise. Auch bei r.js]]', {before: WS-config.js müsste das gehen. Irgendwas ändert sich mit Ereignissen und Reihenfolge; ich hatte zur Analyse der ResourceLoader-Interna meine common/vector.js allerdings so verbastelt, dass bei mir ohnehin alles voller wartender MessageBoxes war. Jetzt habe ich das Thema RL zurückgestellt, addOnLoadHook wieder drin und arbeite zunächst eine Geschichte mit Modif_Link auf – wenn an einer URL mehrere Ersetzungsausdrücke wirksam werden, muss bei http das Ende der URL zwischendurch neu justiert werden. Danach checke ich die Ereignisreihenfolge auf robust. In 3.0 wird es einen ganz hinten angestellten Ladevorgang aus der en.WP mit callback geben, der dann die benutzerdefinierten Variablen kennt. --PerfektesChaos 13:16, 1. Mär. 2011 (CET)Beantworten

ad 1: addOnLoadHook vorläufig wieder live drin. Es sollte zwar nichts ausmachen, ist mir aber im Moment zu unübersichtlich und sollte keine potentielle Fehlerquelle bieten. Durch meine RL-Experimente ist mir die neuartige Lade- und Ausführungsreihenfolge derzeit zu unübersichtlich.
ad 2: Der Abschnitt Benutzer:PerfektesChaos/js/WikisyntaxTextMod/usage/replace#http wurde massiv ausgebaut.
ad 3: wikisyntax_unit_references() bemerkt zwar, dass das Gegenstück nicht zu finden ist, aber die angemessene Reaktion (Kommentar einfügen, end-tag einfügen – womöglich an der richtigen Stelle?, messageBox) ist noch nicht ausgewürfelt.
--PerfektesChaos 12:55, 6. Mär. 2011 (CET)Beantworten

Leerzeichen-Entfernung

Wenn dein Skript in Links am Anfang oder Ende Leerzeichen entfernt, denen kein Leerzeichen vorausgeht, dann darf das Leerzeichen nicht einfach entfernt werden, sondern muss aus dem Link rausgeschoben werden. Gerade aufgefallen bei Vincent Cronin, die Leerzeichen-Entfernung in der Einleitung erfolgte automatisch, eingefügt habe ich dann das Leerzeichen von Hand. --Schnark 10:59, 4. Mär. 2011 (CET)Beantworten

Danke für den Hinweis; werde mich damit auseinandersetzen. Bei Leerzeichen am Ende des Links wird das immer schon so gehandhabt. Betreffend führender Leerzeichen hatte ich mal experimentiert und war wohl damals zu dem Ergebnis gekommen, dass diese folgenlos entfernt werden können. Möglicherweise gilt das nur für Titel von Links; vielleicht hat sich Server-seitig etwas geändert. Egal; mindestens beim Anfang unbetitelter Links wird dies baldmöglichst berücksichtigt werden.
Statusmeldung: Beim Anfassen der URL-Links hatten sich soviel aneinandergebaute Reparaturmechanismen angesammelt, dass ich mich nach einem halben Jahr selbst nicht mehr sicher zurechtgefunden hatte und ähnlich wie bei dem größeren Akt "Wikilink-Objekt" gerade eine Neustrukturierung mache mit dann deutlich erweiterter Funktionalität. Dies war mir bewusst und ich hatte es für 3.0 vor, nun ist es parallel mit RL/1.17 vorgezogen.
Guten Hunger --PerfektesChaos 11:15, 4. Mär. 2011 (CET)Beantworten
Für unbetitelte und betitelte Wikilinks gefixt und seit gestern abend kurz vor Mitternacht live. --PerfektesChaos 12:55, 6. Mär. 2011 (CET)Beantworten

Obskures Verhalten im Zusammenhang mit Schwesterprojekten

Schau dir bitte mal an, was passiert, wenn man dein Skript auf Hector Munro Chadwick in dieser alten Version loslässt. Abgesehen von der Tatsache, dass ich den Link zur englischen Wikisource ohnehin anders wollte, verschluckt dein Skript alles bis einschließlich lang_de/ im übernächsten Link. Sag ihm mal, dass es das nicht tun soll. Viele Grüße --Schnark 10:35, 5. Mär. 2011 (CET)Beantworten

Werde ich machen (REfix); sorry for trouble – Schönes WE trotzdem --PerfektesChaos 10:40, 5. Mär. 2011 (CET)Beantworten
Meine eigenen Fehler haben mir mehr Probleme gemacht als deine … --Schnark 11:05, 5. Mär. 2011 (CET)Beantworten
  • Es war nicht das Schwesterprojekt, sondern die URL-Form der s:en.
  • In der Exprimentalversion war dieser Bock bereits Anfang vergangener Woche nebenbei beseitigt worden.
  • Seit gestern abend kurz vor Mitternacht live als r.js.
  • Ursächlich für das ganze Theater war die Änderung des eine benutzerdefinierte Link-Ersetzung Modif_Link einschließenden Kontextes von einfachen Zeichenketten in reguläre Ausdrücke.
    • Dass hier irgendwas noch weiter zu verbessern ist, ahnte ich schon.
    • Dies hatte ich mir eigentlich für später (nach 3.0) aufgehoben. Durch den Hinweis des ersten externen Benutzers hatte ich das überhaupt angefasst und Ende Januar hineingepatzt. Das griff zu kurz und barg die Gefahr von Folgefehlern, wenn durch die Ersetzung die Link-Grenzen neu zu setzen waren. Auch das Zusammenwirken mehrerer greifender Ersetzungsausdrücke war noch nicht betrachtet.
    • Die Aktion kreuzte sich dann mit 1.17 und RL. Dabei kam einiges zu kurz, und die Version vom 27. Februar war nicht hinreichend getestet.
    • Die halbe vergangene Woche suchte ich nach vermeintlichen Skript-Fehlern, die tatsächlich in mangelhaften Ausdrücken in Modif_Link lagen. Erst die Ruhe des gestrigen Vormittags klärte das Chaos.
  • Jetzt ist das Thema URL-Links grundsätzlich neu gefasst, wie im letzten Herbst bereits die Wikilinks:
    • Erweiterte Funktionalität
    • Erheblich schnellere Abarbeitung von Link-Ersetzungen
    • Kürzerer, übersichtlicherer und damit robusterer Quellcode, hoffentlich halbwegs fehlerfrei

Schönen Sonntag --PerfektesChaos 12:55, 6. Mär. 2011 (CET)Beantworten

Anatolischer Hirtenhund

wieso hast du bitte überall den Räber in Raeber umgewandelt? Der heißt eindeutig Räber. Grüße aus der Eifel Caronna 09:07, 9. Mär. 2011 (CET)Beantworten

Der ist nicht „überall“ umgewandelt worden, sondern nur in den unsichtbaren maschinenlesbaren Identifikatoren der <ref>-Tags. Hier ist die Zuordnung mit ASCII-ae XML-technisch hübscher, ich hätte ihn aber auch „Li-La-Laune-Bär“ nennen können.
HGZH --PerfektesChaos 09:15, 9. Mär. 2011 (CET)Beantworten

Bei Gershom Levy in der Urversion will dein Skript (vermutlich in Zusammenarbeit mit dem von dir kopierten Modif_Link Folgendes aus dem Einzelnachweisblock machen:

<references>[
<ref name="Memoriam">
Yael Lubin, Efrat Gavish-Regev: ''In Memoriam Gershom Levy (1937–2009).'' In: Israel Journal of Entomology Vol. 38, 2008, S. 138. ([http://www.entomology.org.il/sites/default/files/pdfs/ENTOM%2008-Obit%20FINAL.pdf entomology.org.ilentomology.org.il Online])
]</ref>
</references>

Die beiden eingefügten eckigen Klammern und der gleich doppelt eingefügte Servername sind da eindeutig zu viel. Viele Grüße --Schnark 10:17, 10. Mär. 2011 (CET)Beantworten

Eher nein; dies geht vermutlich auf den Wunsch eines Benutzers zurück, der bei dem Tag <references> und fehlendem </references> eine Warnmeldung haben wollte.
Das ist hier halbgetestet gründlich schiefgegangen, hatte aber schon einmal funktioniert.
Trotzdem danke für den Hinweis; ich werde wohl Ende der Mittagszeit diesen Quatsch analysiert und beseitigt haben und r=2.999 live stellen.
--PerfektesChaos 10:24, 10. Mär. 2011 (CET)Beantworten
  1. Die erste Vermutung in der quick response, es könne mit Veränderungen bei <references> zu tun haben, hat sich nicht bestätigt; dies hätte auch keine Domain identifiziert und verdoppelt.
  2. Das Problem mit der URL konnte ich nicht reproduzieren.
    • Weder im JS noch in dem Modif_Link noch in der Doku noch im Wikitext konnte ich einen Fehler entdecken, auch nicht in der für mich sichtbaren Wikisyntax-config.js bei dir.
    • Ein vergleichbares Wirrwarr hatte ich zuletzt vor einer Woche mal in Experimentalversionen gesehen; das sollte aber nicht in eine r-Version gelangt sein.
    • Caching? r-Version aktuell? Deine Wikisyntax-config.js aktuell? Irgendwie durch den Wolf gedreht?
Please keep me informed --PerfektesChaos 14:35, 10. Mär. 2011 (CET)Beantworten
Okay, jetzt sehe ich es auch; den bug gibt es, aber einstweilen völlig rätselhaft, in welchem Bereich die Ursache zu suchen ist. Der Abend ist gerettet … --PerfektesChaos 20:40, 10. Mär. 2011 (CET)Beantworten
Identifiziert; Lösung mühsam.
Es ist das intern an das <ref> des Modif_Link angehängte $ für "Ende des vorangestellten RegExp", das bei mehrzeiligem Text zu früh bereits greift. Dies hatte ich bisher sicherheitshalber durch an die Texte und RegExp \f angehängte oder vorangestellte Pseudo-Zeichen umgangen. Wegen anderer Probleme nahm ich das letzte Woche 'raus und es traten beim Testen keine Schwierigkeiten auf, so dass ich es für unschädlich hielt.
Welche Lösung ich nun angehen werde, klärt sich hoffentlich im Lauf der Nacht. r=2.999 beobachten.
--PerfektesChaos 23:16, 10. Mär. 2011 (CET)Beantworten
Mein alter Freund .multiline=false; an jedem der fraglichen RegExp hat sich auch mal wieder als wirkungslos erwiesen. Ich mahne und warne vor ^ und $.
Ich habe jetzt die Bastelarbeit mit den \f wieder eingebaut, hoffe es richtig gemacht zu haben, werde die r-Version aber erst nach dem Testen live kopieren.
Gute Nacht erstmal --PerfektesChaos 00:13, 11. Mär. 2011 (CET)Beantworten