Benutzer Diskussion:PerfektesChaos/js/WikiSyntaxTextMod/Archiv4

Dies ist das Archiv abgeschlossener Diskussionen zum Skript WikiSyntaxTextMod und auch zu allen Unterseiten dazu. Diese Archivseite beginnt mit Version WSTM.6 ab Anfang 2014. Andere Archivseiten siehe Archiv.

Et cetera - Bildklammer

Hier geht nach dem Umwandeln der Bildeinbindung die schließende Klammer verloren [1]: [[Datei:Et_cetera_r_rotunda.svg|18px]] → [[Datei:Et cetera r rotunda.svg|18px]

Dies scheint auch zu passieren, wenn der Code einzeln dasteht. Grüße --se4598 / ? 08:37, 7. Jan. 2014 (CET)

Ja; alte Mühsal – danke erstmal.

Es kommt, wenn sowohl der Dateiname transformiert wird als auch kein Bildtitel und möglicherweise auch nur, wenn nicht in eigener Zeile. Lausig komplizierte Geschichte, weil es im Bildtitel auch Vorlagen und Tabellen und Kommentare und Links und hinter dem Bildtitel nochmals Bildparameter geben kann, und ich in jeder Situation mitzählen muss, welche Pipes und welche schließenden Klammern es gibt und welche zu welchem Syntaxelement gehören.

So habe ich einen neuen Testfall. Selten simpel, war offenbar in dieser Kombination noch nicht auf dem Radar. Code ist seit einem Dreivierteljahr unverändert; scheint also zumindest nicht sehr häufig vorzukommen.

Es wird Frühling --PerfektesChaos 10:01, 7. Jan. 2014 (CET)

Whitespace am Zeilenende

Bisher hatte ich immer das Gefühl, dass Whitespace am Ende einer Zeile automatisch entfernt wird. In diesem Fall irgendwie nicht (Den Whitespace im Diff habe ich manuell entfernt und meine ich). VG --se4598 / ? 17:44, 23. Jan. 2014 (CET)

• Das hat so seine Richtigkeit.
• Zuerst prüft WSTM, ob es wirklich etwas zu ersetzen gibt. Dazu würden auch Leerzeilen mit nur Leerzeichen und aller nicht-ASCII-32-Whitespace gehören.
• Erst wenn es tatsächlich etwas zu tun gibt, werden auch hinter nicht-leeren Zeilen ASCII-Leerzeichen entfernt.
• Grund: Es soll nicht dazu verleitet werden, nur wegen solcher Quasi-Null-Edits neue Versionen abzuspeichern. Für Normalbenutzer sind die Whitespace-Änderungen und unsichtbaren Zeichen nicht unterscheidbar.
• Dass du nach dem automatischen WSTM-Lauf noch eine Klammer ersetzen würdest, konnte WSTM nicht vorhersehen. Hätte es eine Diffpage gezeigt, wären sich die Benutzer verschaukelt vorgekommen. Wäre ohne Diffpage was verändert worden, ist das Geschrei auch groß.

Danke für die Kontrollanfrage --PerfektesChaos 20:48, 23. Jan. 2014 (CET)

ach, ich mag mal keinen neuen Abschnitt aufmachen. Seit Ewigkeiten scheint es mir so, dass, falls Einzelnachweise im References-Tag definiert werden, dort vor den schließenden Ref-Tags ein Zeileneinbruch eingefügt wird (sogar manchmal auch nach dem öffnenden; Beispiel). Ich finde das nicht sehr gelungen, da so fast nie mehr Übersichtlichkeit reinkommt, aber dafür z.B. bei nur kurzen Einzelnachweisen dies auf die doppelte Zeilenanzahl vergrößert wird und durch den wechselnenden Zeileninhalt (EN/"</ref>) schlechter zu überblicken ist. Falls da ne lange Vorlage drin ist oder auch stark wechselnde EN-Namenslängen sind, kann man drüber reden, was da besser gefällt. Für den Rest meiner Meinung nach verschlechtere Lesbarkeit. Steckt da ein mir nicht zu erschließende Intention hinter? Ansonsten würd ich doch dafür stimmen, das auszuschalten. Grüße --se4598 / ? 18:46, 24. Jan. 2014 (CET)

Ach herrje, was soll ich denn bloß mit euch machen.

• Du bist nicht der erste, der danach fragt.
• Schon richtig herausbekommen hast du, dass das Feature deshalb eingeführt wurde, um lange Textsequenzen (gerade auch bei Vorlagen ohne Zeilenumbruch nach jedem Parameter) besser abzugrenzen; und bei Vorlagen mit Zeilenumbruch nach jedem Parameter und Einrückung die einzelnen refs voneinander klarer abzugrenzen.
• Nun würde sich die Frage stellen: Was ist lang? Wie lang ist eine Zeile im Bearbeitungsfeld? Bei mir oft um die 70 Zeichen. Also müsste ein „kurzer“ Beleg auf einen Inhalt von <ref name=""></ref> 19 Zeichen Minimum plus Länge des name-Parameters (oft 20 Zeichen); also bis zu 30 Zeichen Länge eines kurzen Belegtextes. Für Kursivschreibung des Titels gehen 4 Apostrophe weg, ein Komma und ein Leerzeichen für S. und dahinter noch ein Leerzeichen; Doppelpunkt mit einem Leerzeichen ja auch noch mal 2; bleiben für Autor, Titel, Seitenzahl zusammen 20 Zeichen. Das ist nur selten der Fall. Andernfalls entstehen dann doch wieder mehrere Zeilen; dann kommt es auf eine mehr oder weniger nicht an.
• Nun müssen aber auch die Einträge gleich aussehen. Sonst wird es zum völligen Voodoo, wenn das bei dem einen Eintrag hü und beim nächsten hott ist. Das kapiert nun wirklich keiner. Okay; der Artikel hat ja nur ganz kurze Einträge. Also alle einzeilig. Nun ist ein Wiki aber dynamisch und nicht statisch. Jetzt fügt jemand einen zweifelsfrei langen Eintrag ein; also schalten sich nun sämtliche Einträge auf mehrzeilig. Das kann aber auch umgekehrt passieren: Aus dem Artikel wird eine Textpassage und der sie stützende Beleg entfernt. Das war ein langer gewesen; Juhu! jetzt schalten sich die anderen 20 alle auf einzeilig.
• Kannst du einen Algorithmus angeben, der für alle Breiten von Bearbeitungsfeldern der Autoren, alle persönlichen Geschmäcker, alle Kombinationen von teils langen, teils kurzen Einträgen für den momentanen und auch alle zukünftigen Gestalten des Artikels eine konstante Formatierung liefert, die niemanden durch konfuses und rätselhaftes Verhalten verwirrt?
• Im Übrigen sind diese Kurzhinweise ohnehin unerwünscht; es muss nur jemand aus dem Abschnitt „Literatur“ das Buch als überflüssig herauskürzen und ihn mal wieder auf fünf Einträge stutzen; schon steht irgendein Handbuch von irgendeinem Meier ohne bibliografische Angaben da. Und wenn schon unbedingt kurz, dann kann man sie auch gleich im laufenden Text einstreuen; der Block am Ende eignet sich insbesondere für die großen Vorlagen.

Schönes Wochenende --PerfektesChaos 23:18, 24. Jan. 2014 (CET)

Ich stell mir gerade so als Idee vor, nur innerhalb der Vorlage umzubrechen, aber halt nicht am Tag, sodass halt dann so etwas wie das hier:

<references>
<ref name="Buch1">John Doe: Wikipedia. Wesen, Wert und Gefahr. Wikipedia-Press, Musterstadt 2001, ISBN 3-12-123453-2, S. 53–98.</ref>
<ref name="Buch2">{{Literatur
|Autor=Max Mustermann
|Titel=Semantischer Kollaps bei Löschdiskussionen
|Sammelwerk=Journal of Wikipedianism 
|Band=Bd. 2
|Nummer=3
|Jahr=2006
|Seiten=17–67
}}</ref>
<ref name="Buch3">{{Literatur
|Autor=Max Mustermann
|Titel=Semantischer Kollaps bei Löschdiskussionen
|Sammelwerk=Journal of Wikipedianism 
|Band=Bd. 2
|Nummer=3
|Jahr=2006
|Seiten=17–67
}}</ref>
<ref name="Buch4">John Doe: Wikipedia. Wesen, Wert und Gefahr. Wikipedia-Press, Musterstadt 2001, ISBN 3-12-123453-2, S. 53–98.</ref>
<ref name="Buch_abc">John Doe: Wikipedia. Wesen, Wert und Gefahr. Wikipedia-Press, Musterstadt 2001, ISBN 3-12-123453-2, S. 53–98.</ref>
</references>

als Kompromiss-Beispielformatierung gegenüber dem wohl derzeitigen Stand

<references>
<ref name="Buch1">
John Doe: Wikipedia. Wesen, Wert und Gefahr. Wikipedia-Press, Musterstadt 2001, ISBN 3-12-123453-2, S. 53–98.
</ref>
<ref name="Buch4">
John Doe: Wikipedia. Wesen, Wert und Gefahr. Wikipedia-Press, Musterstadt 2001, ISBN 3-12-123453-2, S. 53–98.
</ref>
<ref name="Buch_abc">
John Doe: Wikipedia. Wesen, Wert und Gefahr. Wikipedia-Press, Musterstadt 2001, ISBN 3-12-123453-2, S. 53–98.
</ref>
</references>

verglichen mit für mich besser lesbar, platzsparend (gegenüber dem 3mal so langen obigen) und so oft verwendet:

<references>
<ref name="Buch1">John Doe: Wikipedia. Wesen, Wert und Gefahr. Wikipedia-Press, Musterstadt 2001, ISBN 3-12-123453-2, S. 53–98.</ref>
<ref name="Buch4">John Doe: Wikipedia. Wesen, Wert und Gefahr. Wikipedia-Press, Musterstadt 2001, ISBN 3-12-123453-2, S. 53–98.</ref>
<ref name="Buch_abc">John Doe: Wikipedia. Wesen, Wert und Gefahr. Wikipedia-Press, Musterstadt 2001, ISBN 3-12-123453-2, S. 53–98.</ref>
</references>

Ich finde, so wird jede Zeile eindeutig zuordbar zu einer Ref. und die Lesbarkeit wird gewährleistet (Refs ohne Vorlagen kann man ja meist wie Fließtext durchlesen, Vorlage mit Parameter eher nicht, dort wird es halt aufgespalten). Am Ende sieht es bedingt durch das Editerfenster sowieso wieder anders aus, wobei ja höhere Auflösungen immer verbreiteter werden. Dann da so ein Zeilen fressendes Monster zu haben, verbessert nicht gerade die Navigierbarkeit/Überblick über den gesamten Wikitext --se4598 / ? 00:32, 25. Jan. 2014 (CET) PS: Ja, ich habs auch mit schmalem Editierfenster verglichen, wobei bei mir standardmäßig bei sage und schreibe etwas mehr als 200 Zeichen pro Zeile reinpassen (Zum Editieren gut, zum konzentrierten Lesen ja eher weniger, siehe Typographie-Breitenbegrenzungs-Spielereien von der WMF).

„Du bist nicht der erste, der danach fragt.“ Ich z.B. fragte schon. Ich glaube nicht mehr, dass eine einheitliche automatische Formatierung des references-Blocks für alle geeignet ist. Eine Lösung wäre, die Einfügung von Umbrüchen nach <ref ...> und vor </ref> von einem Parameter abhängig zu machen, etwa wie mit diffPage. Eine andere – das wäre aber wohl Neuland – wäre, in den Artikeltext einen steuernden Kommentar wie etwa <!--kein automatischer Umbruch--> aufzunehmen. (Die letztgenannte Möglichkeit schützt 'momentane' Hauptautoren vor unerwünschten Änderungen durch (bezogen auf den jeweiligen Artikel) 'einmalige' Mitarbeiter, die vielleicht nur einen Schreibfehler korrigieren wollen.) --Griot (Diskussion) 16:21, 25. Jan. 2014 (CET)

• @Griot: Ja, du bist aber auch der einzige weitere Anwender, bei dem ich mich daran erinnern kann, dass ein anderes Format gewünscht wurde.
• Die Beispiele oben sind unfair, weil sie ein unendlich breites Bearbeitungsfeld auf dem Bildschirm unterstellen. Ich habe sie im Anschluss einmal so umbrochen, wie sich das mir darstellt.
• Ich persönlich hasse überlange Zeilen. Auf meinem Bildschirm gibt es nicht nur ein Wiki-Browser-Fenster, sondern verschiedene Aktionen nebeneinander. Und bei 72 bis 80 monospace geht die Wrapperei los, oder es verschwindet hinten im Unsichtbaren. Links neben dem Bearbeitungsfeld steht schließlich noch die Sidebar. Siehe dazu Leserlichkeit und Satzbreite.
• Ich bin nicht der Einzige mit diesem Geschmack; siehe etwa quer durch Dortmund und Bochum.
• Hinzu kommt die Verbreitung portabler Geräte mit beschränkten Bildschirmabmessungen; auch hier sind Zeilenbreite mit Wrapping das größere Problem.
• Eine Diffpage ist eine temporäre, virtuelle Angelegenheit. Die kann sich jeder selbst einstellen, wie er mag; niemand sonst bekommt etwas davon mit. Der Quelltext ist hingegen für alle Benutzer gleich. Individuelle Einstellungen würden dazu führen, dass jeder Bearbeiter einmal umformatiert, und der nächste dann wieder zurück; wobei die eingefügten und entfernten Zeilenumbrüche auf die Diffpages verheerende Auswirkungen hätten. Also hat jeder Dortmunder seine privaten Einstellung oder verwendet die Standard-Einstellung und modelt den Quelltext vorwärts und rückwärts und hin und her. Aus genau diesem Grund gibt es in WSTM prinzipiell keinerlei individuelle Benutzeroptionen zum Quelltext, für die man nur ein Kreuzchen machen müsste, sondern allenfalls benutzerdefinierte eigenverantwortliche Ersetzungsausdrücke, mit denen ich weiter nichts zu tun habe.
• Nochmals: Der references-Block ist für die Auslagerung langer (oder sehr häufiger) Belege vorgesehen, während kurze (und erst recht einmalige) ref besser beim laufenden Text verbleiben, damit sie auch bei der Bearbeitung einzelner Abschnitte auf Anhieb zugeordnet werden können. Somit ist der lange ref-Eintrag im references-Block der Standardfall; die Verwendung kurzer Einträge im references-Block in der Regel nicht wünschenswert, weil eine unnötige Schikanierung derjenigen Mitautoren, die nur einen einzelnen Abschnitt bearbeiten.
• Im Übrigen wird das Thema Quelltext sowieso lustig, wenn Parsoid eingeführt und der Wikitext weltweit einheitlich aus einem strukturierten XML-Format generiert wird. Aber da sollen erstmal die Kollegen der enWP drüber fluchen.
• Wer Lust hat, über ref-Formatierung zu diskutieren, mag mal auf WD:LIT #Vorlage:Literatur mitmischen; mir ist das zu gaga.
• Ansicht des obigen Quelltextes bei mir (Umbruch bei 72 Zeichen):

<references>
<ref name="Buch1">John Doe: Wikipedia. Wesen, Wert und Gefahr.
Wikipedia-Press, Musterstadt 2001, ISBN 3-12-123453-2, S. 53–98.</ref>
<ref name="Buch4">John Doe: Wikipedia. Wesen, Wert und Gefahr.
Wikipedia-Press, Musterstadt 2001, ISBN 3-12-123453-2, S. 53–98.</ref>
<ref name="Buch_abc">John Doe: Wikipedia. Wesen, Wert und Gefahr.
Wikipedia-Press, Musterstadt 2001, ISBN 3-12-123453-2, S. 53–98.</ref>
</references>

--PerfektesChaos 09:50, 26. Jan. 2014 (CET)

Ich finde das mit dem Umbruch immer noch gut zu lesen (so habe ich mir das auch in etwa vorgestellt (und mein Beispiel oben bricht halt nicht im View automatisch um)), aber das ist ja auch für jeden subjektiv und ob Syntaxhighlight oder sonstiges an ist. Zu der Denkmalliste: jeder Autor wie er mag, und ob mit Vorlage oder ohne. Im Bio-Bereich habe ich reihenweise in der kompakten Schreibweise gesehen. Könn wir nicht sagen, wir schalten einfach das _automatische_ Formatieren (konkret: die Zeilenumbrüche) im References-tag aus?--se4598 / ? 14:53, 26. Jan. 2014 (CET) PS: Dass sich kaum einer meldet hängt ja auch von der Wahrscheinlichkeit der WSTM-Benutzung und dem Vorhandensein der normal eher seltenen Deklarierung am Ende ab. Aber brauchen wir eigentlich auch nicht weiter drüber zu diskutieren, formatiert man es in den Fällen halt selbst wieder manuell zurück.--se4598 / ? 14:53, 26. Jan. 2014 (CET)

Ein guter Vorschlag. --Griot (Diskussion) 17:32, 26. Jan. 2014 (CET)

Schalter

Hallo,
es wäre schön, wenn du die Eindeutschung von Begriffen abschaltbar gestaltest, ebenso wie die Zwangsformatierung von Referenzen am Ende des Artikels. Dann würde das, was da geändert wird, auch durch mich vertretbar sein und ich bräuchte derartig primitive Anmache wie hier nicht ertragen. Gruß und schönes Wochenende --RonMeier (Diskussion) 13:59, 1. Feb. 2014 (CET)

Ich hab für ähnlich gelagerte Fälle einen einfachen Komplett-Ausschalter auf Cookiebasis in meine linken Werkzeugleiste gebastelt. Den Code findest du in meiner common.js (1. Eintrag). Grüße --se4598 / ? 14:24, 1. Feb. 2014 (CET)

ich sehe in meiner eigenen common.js kaum durch, und schon gar nicht in einer Fremden. Auch will ich ja WSTM nicht komplett abschalten. Trotzdem Danke. Gruß --RonMeier (Diskussion) 14:36, 1. Feb. 2014 (CET)

• Zum Diskussionsverlauf:
  • Du kannst durchaus damit zufrieden sein. Es sind dir mehrere Leute beigesprungen. Unterm Strich bist du sauber daraus hervorgegangen; dein Kontrahent steht nicht sehr glücklich da.
• Zum allmählichen Konvergieren der Wikisyntax und Literaturformate im allgemeinen:
  • Es gibt zweieinhalb Themengebiete, die sich konsequent als außerhalb aller Regeln und Richtlinien und projektweiter Konventionen sehen, und ihre Privatregeln und angeblichen Portalregeln in ihren Privatartikeln per Revert durchsetzen.
  • Es gibt zwischen zehn und zwanzig bekannter Namen mit fünfstelligem ANR-Count und nahezu oder mehr als zehn Jahren Mitwirkung, die auf jede Veränderung gegenüber 2004 und ihrem Privat-Stil allergisch reagieren, egal was. Ich habe es längst aufgegeben, mich darüber zu wundern oder zu ärgern.
  • Es wird lustig werden, sobald Parsoid in wenigen Jahren die Standard-Syntax spontan aus dem Datenbankmodell heraus generiert; dann sind private Quellcode-Macken und Formatierungen sowieso beendet. Ich kann mit WSTM daraufhinwirken, dass wir dann einen syntaktisch einheitlichen und sauberen Wikitext in möglichst vielen Artikeln haben, der sich problemlos konvertieren lässt. Und das übt auch schon, sich heute mit einer einigermaßen sauberen Wikisyntax anzufreunden.
• Zum Umgang mit den Sonderfachgebieten und Spezialautoren ist es tatsächlich am besten, WSTM in diesen Spezialartikeln abzuschalten.
  • Ein Weg, wie das relativ einfach durch einen Klick an und aus geht, ist Benutzer:Schnark/js/fliegelflagel. Dort ist auch WSTM registriert.
    • Ich habe keine Erfahrungen damit, ob man besondere Vorkehrungen treffen müsste hinsichtlich der vor dem Start zu aktivierenden benutzerdefinierten Geschichten. Wird sich aber herausbekommen lassen.
  • Es gibt die Möglichkeit, per CSS-Definition ein Dutzend Autoren rot einzufärben. Wenn in einem Artikel verdächtig viel zu formatieren ist und das Themenfeld passt, empfiehlt sich ein Blick in die Versionsgeschichte. Sind hier viele Benutzernamen (meist immer der gleiche) rot eingefärbt, wäre halt WSTM für diesen Artikel abzuschalten.
  • Man könnte auch ein JS-Werkzeug schreiben, das automatisch Alarm! schreit, wenn in den letzten 500 Bearbeitungen mehr als zehnmal bestimmte Benutzer erscheinen.
  • Natürlich kann man eine solche Liste von Autoren (CSS oder JS) nicht offen in die weltweit einsehbaren Benutzerseiten setzen.
    • Benutzer:PerfektesChaos/js/loadResourceFile ist dafür vorgesehen, bestimmte Teile von der Festplatte zu lesen; interaktiv oder regelmäßig automatisch.
    • Wikipedia:Technik/Browser/Greasemonkey geht in eine ähnliche Richtung. Funktioniert.
    • Einstellungen für sogenanntes userjs- würden sich ebenfalls eignen. Benutzer:PerfektesChaos/js/preferencesGadgetOptions unterstützt Programmierer dabei.
  • Langfristig stehen die Einzelkämpfer auf verlorenem Posten. Die Sitten von 2005 und Übernahmen aus der enWP oder irgendwelchen Newsticker-Formaten nehmen nach und nach ab; das breite Erscheinungsbild der deWP wird bei aller individueller Vielfalt pro Artikel kontinuierlich einheitlicher. 75 %, 80 %, 90 % der Artikel halten die Grundprinzipien ein. Wer nachwächst, orientiert sich am Standardbild und formatiert nach mainstream, so es erlernt wird und Mentoren das erklären.
• Zu WSTM:
  • Seit einem Dreivierteljahr komme ich nicht mehr dazu, größere Neuerungen zu entwickeln; ich mache nur noch Bestandspflege und Glättung der Architektur sowie Aufarbeitung veralteter und störanfälliger Prozeduren aus 2010/2011.
  • Die Ursache hat drei Buchstaben: L-u-a nebst damit verbundener Querschläger.
  • Ansonsten sehe ich auch Handlungsbedarf bei der Organisation von Projektseiten und Softwaredokumentation; hier ist die deutschsprachige Wikipedia teilweise ziemlicher Dschungel, woanders Wüste.
  • Weiterhin schreibe ich moderne Gadgets, etwa für den Umgang mit einer Viertelmillion Artkel mit einer halben Million defekter Weblinks.

LG --PerfektesChaos 22:26, 1. Feb. 2014 (CET)

Alexandre Cabanel

Hallo PerfektesChaos, ich helfe gerade bei den Klammerfehlern von Aka mit und wundere mich gerade, warum ein von mir gestern bearbeiteter Artikel wieder in der Liste landet. Aber nach genauem Hinschauen, scheint noch irgendetwas in dem Artikel zu sein, welches Dein Skript nicht richtig reagieren läßt. Nun aber von Anfang an:

1. Dieses war die Ansicht vor meiner Korrektur (keine Galerie zu sehen)
2. Dieses war die Ansicht nach meiner Korrektur (Galerie vor dem Werksverzeichnis zu sehen, jedoch mit falschen Korrekturen Difflink bei den Dateien).

Magst Du bitte mit Deinem geschulten Blick auf diese Merkwürdigkeiten schauen? Ich verstehe es nicht! :-) Liebe Grüße Silke (Diskussion) 23:09, 7. Feb. 2014 (CET)

Das ist ziemlich simpel. Erwartet wird im Wiki etwas wie:

<gallery>
Datei:Alexandre Cabanel.jpg|Bildlegende
</gallery>

Dort steht aber:

<gallery>
[[Datei:Alexandre Cabanel.jpg|miniatur|hochkant|Bildlegende]]
</gallery>

Wobei es seit einiger Zeit die Möglichkeit gibt, zusätzliche Parameter den einzelnen Galeriebildern mitzugeben; das ist hier aber mit Sicherheit nicht beabsichtigt.

Ich habe diese Art von Syntaxverirrung noch nie gesehen; WSTM dementsprechend auch nicht.

• WSTM entfernt den Namen des Namensraums, weil heutzutage redundant und damit es keinen Streit über File: und so gibt.
• Dabei werden witzigerweise die öffnenden Klammern mit entfernt, war mir so nicht bewusst.
• WSTM erwartet nach der ersten Pipe eine Bildlegende als normalen Wikitext. Dass es dort zwei überzählige schließende Klammern gibt? Naja, wer’s mag. Wer weiß, wozu es gut sein soll.

Was mich erstaunt: Dass die unerwartete Form mit normalen Bildeinbindungen überhaupt funktioniert hat.

Schönes Wochenende --PerfektesChaos 09:22, 8. Feb. 2014 (CET)

Lieber PerfektesChaos, Danke, ich wußte doch, dass es für Dich einfach sein wird, den Fehler zu entdecken. Nach Deiner guten Erklärung weiß ich auch, warum die Galerie ursprünglich gar nicht angezeigt wurde. Jetzt kann ich den Fehler in der Syntax per Hand korrigieren und alles ist gut! Auch Dir ein schönes Wochenende, Silke (Diskussion) 12:02, 8. Feb. 2014 (CET)

Ameisen

Hallo,
Das Öffnen obigen Artikels endet ohne jegliche Bearbeitung und ohne Diffpage. Erst nach dem Entfernen von [[doi:10.1038/35051]] und Starten von "Voransicht" oder "Änderungen zeigen" reagiert WSTM. Gruß --RonMeier (Diskussion) 12:25, 24. Mär. 2014 (CET)

selbst aufgerufen, bei meiner Config gehts so, zeigt brav Diffpage und formatiert. Aus RonMeier's common.js die meiste WSTM-Konfig herauskopiert und manuell im Editfenster via Firebug ausgeführt:

TypeError: got is null
https://en.wikipedia.org/w/index.php?action=raw&ctype=text/javascript&title=User:PerfektesChaos/js/WikiSyntaxTextMod/dH.js&587419723*
Line 2272

log(msg="Exception thrown by job.error", e=
TypeError: got is null
mw.libs.WikiSyntaxTextMod.bb.link/WLINK.wiki.iwMap()index....419723* (Zeile 2272)
mw.libs.WikiSyntaxTextMod.bb.Wikilink/WikiLK.prototype.adjust()index....422006* (Zeile 2220)
mw.libs.WikiSyntaxTextMod.bb.Wikilink/WikiLK.prototype.set()index....422006* (Zeile 4582)
mw.libs.WikiSyntaxTextMod.bb.link/WLINK.format()index....419723* (Zeile 457)
mw.libs.WikiSyntaxTextMod.bb.link/WLINK.fenced()index....419723* (Zeile 248)
mw.libs.WikiSyntaxTextMod.bb.link/WLINK.fire()index....419723* (Zeile 351)
mw.libs.WikiSyntaxTextMod.bb.elem/WSTM.w.elem.tags()index....419036* (Zeile 1530)
mw.libs.WikiSyntaxTextMod.bb.elem/WSTM.w.elem.fire()index....419036* (Zeile 590)
mw.libs.WikiSyntaxTextMod.bb.apiW/WSTM.api.textMod()index....423185* (Zeile 260)
mw.libs.WikiSyntaxTextMod.bb.apiM/WSTM.api.edit()index....421775* (Zeile 161)
mw.libs.WikiSyntaxTextMod.bb.mainM/WSTM.main.full()index....421775* (Zeile 1481)
der.using()load.p...022212Z (Zeile 11225)
mw.libs.WikiSyntaxTextMod.bb.main/WSTM.main.fire/<()index....e=86400 (Zeile 917)
lbacks/fire()load.p...022212Z (Zeile 974)
s/self.add()load.p...022212Z (Zeile 1020)
otype.ready()load.p...022212Z (Zeile 246)
totype.init()load.p...022212Z (Zeile 174)
jQuery()load.p...022212Z (Zeile 44)
mw.libs.WikiSyntaxTextMod.bb.main/WSTM.main.fire()index....e=86400 (Zeile 913)
lePending()load.p...022212Z (Zeile 10486)
der.state()load.p...022212Z (Zeile 11341)
()index....421455* (Zeile 3947)
	
r    =  got[1];

Grüße --se4598 / ? 15:01, 24. Mär. 2014 (CET)

• Ja; seit gestern 20:14 ist eine Programmsequenz (erstmal nur auf d) aktiv, die durch einen Schreibfehler bei einem regulären Ausdruck anderthalb Jahre untätig schlummerte.
• Sie betrifft die Kürzel exotischer Wiki-Projekte iwMap, die in Artikeln nie vorkommen sollen. Deshalb fiel das auch nicht auf; am Wochenende hatte ich aber bei Projektseiten die Nase voll und war auf Erkundung gegangen, warum diese Funktion nichts tat.
• Bei den Ameisen stolperte er nun über das [[doi: hinten bei den refs; das ist weder Sprachkürzel noch Wiki-Projekt, und da verhaspelte sich die seit gestern aktive Version.
• Fix ist live.

@se4598: Ich hatte gestern Abend / heute morgen / zur Gespensterstunde vergessen, dir auf deinen angeschlagenen Gesundheitszustand gute Besserung zu wünschen. So wie sich das hier liest, scheinst du aber wieder voll drauf zu sein.

• Mein zweiter Bananenpflücker (Steak) ist ja nicht mehr angemeldet aktiver Benutzer. Wenn du magst, kannst du zeitweise in den d-Modus switchen und Bugs melden. Seit Jahresanfang habe ich aber kaum was an WSTM gemacht und mich daran gefreut, dass es robust und beschwerdefrei lief. Bis nach Ostern werde ich mit diversem Lua und WPNR und LT gut ausgelastet sein und nur wenige Fixe angehen; aber im Sommer könnten mal wieder WSTM-Schübe kommen, wenn nichts Dringendes anliegt.

Schönen Dank und ein mäßiges Wetter allerseits --PerfektesChaos 15:19, 24. Mär. 2014 (CET)

Danke. Leben muss halt weitergehen. Wird besser. Gerade kam die Sonne raus. Ich schau mal mit "d". --se4598 / ? 15:30, 24. Mär. 2014 (CET)

noch tut sich nix. Gruß --RonMeier (Diskussion) 15:49, 24. Mär. 2014 (CET)

Probier nach Cachelöschung etc. nochmal. Um 15:54 hat PC es gerade geupdatet und seitdem funktioniert es bei mir . --se4598 / ? 16:10, 24. Mär. 2014 (CET)

Ja, danke; ich hatte vergesen, auf Speichern für die neue Version zu klicken. Habe im Moment zu viele Browser-Fenster offen und etwas den Überblick verloren und mache eigentlich grad was ganz anderes. VG --PerfektesChaos 16:29, 24. Mär. 2014 (CET)

jetzt gehts ja. Danke an alle Beteiligten. Gruß --RonMeier (Diskussion) 16:46, 24. Mär. 2014 (CET)

undefinierbares Problem

Hallo PC,
beim Öffnen von Homo floresiensis wird aus
Mike J. Morwood et al.: ''Fission-track ages of stone tools and fossils on the east Indonesian island of Flores.'' In: ''[[Nature]].'' Band 392, 1998, S. 173–176, [[doi:10.103
ein
Mike J. Morwood u. a.: ''Fission-track ages of stone tools and fossils on the east Indonesian island of Flores.'' In: ''[[doi:10.1038/32401392, 1998, S. 173–176, [[doi:10.103
Ich kann es erstmal keinem meiner js-schnipsel zuordnen. Gruß --RonMeier (Diskussion) 10:56, 3. Apr. 2014 (CEST)

Kann ich nicht reproduzieren.

Zwar hatten wir kürzlich was mit Interwiki, und ein Update dazu läuft weiterhin in der d-Quarantäne, aber ohne benutzerdefinierte Ersetzungen ist dabei nichts zu beobachten.

Wenn du dann editierst:

• Da wird expandiert 1,02  ±  0,02
• Das muss heißen 1,02 ±0,02

Sonnigen Tag --PerfektesChaos 11:18, 3. Apr. 2014 (CEST)

Ich hab bei mir erstmal den ganzen config.mod.plain-Teil auskommentiert und - das gleiche Problem. Gruß --RonMeier (Diskussion) 11:34, 3. Apr. 2014 (CEST)

Jetzt reproduziert nach einigem Konfigurationsgebastel.

1. Schalte bitte für einige Tage von d auf r.
   • Dann kann ich das in Ruhe analysieren und weiter erproben.
   • Bis auf die erweckte Interwiki-Analyse ist auch kein Unterschied zwischen d und r.
2. Deine config.mod. kann dann wieder aktiviert werden.
3. Es hat schon seinen Grund, warum sowas erstmal in Qurantäne läuft.

LG --PerfektesChaos 12:29, 3. Apr. 2014 (CEST)

ok --RonMeier (Diskussion) 12:45, 3. Apr. 2014 (CEST)