Was genau vor sich geht, werde ich baldmöglichst zu ergründen versuchen.
Es handelt sich um einen „Minimierungs-Fehler“. Das Skript ist menschenlesbar geschrieben und heißt dann d.js – so wird es ausgetestet, und dabei tritt das Problem nicht auf.
Anschließend werden Kommentare, Leerzeichen, Zeilenumbrüche entfernt (durch ein Hilfsprogramm von mir). Dadurch entsteht eine kleinere, schneller zu übertragende und zu ladende Version r.js – die macht grad Zicken.
GEFIXT – mit deinem 2. Edit nach 15:00 solltest du unbeschadet das Schloss besuchen können.
Mein Minimierer hatte ein Leerzeichen zuviel aus der Prozedur geklaut, die Blöcke <references>………</references> formatiert.
Zwar wird das Skript getestet, bevor ich es auf die Menschheit loslasse, aber überwiegend nicht im minimierten Zustand. Nach Bereitstellung einer minimierten Hauptversion gibt es eine kursorische Erprobung anhand einiger zufälliger Artikel, die heute morgen auch stattfand (seit heute früh ist diese fundamental neue Version 5 online), aber da war leider kein solcher Block <references>………</references> dabei.
Zur besseren Lesbarkeit eines Block <references>………</references> werden die tags <ref name="…"> und </ref> auf eigene Zeilen geschrieben.
Deine persönlichen Anweisungen PND=→TYP=p|GND= kannst du demnächst entfernen; die in der VL:ND-Disku besprochenen Transformationen sind ab heute für alle Anwender live (sofern bereits migriert, was noch bis August dauern kann).
Äh, es geht aber nicht. Ich lade das Skript von en.wikipedia.org/w/index.php?title=User:PerfektesChaos/js/WikiSyntaxTextMod/r.js , und da find ich auch nix neues in der Versionsgeschichte (Tut mir leid, wenn ich mich doof anstelle, ich kenn mich mit dem Zeug nicht aus). --AndreasPraefcke (Diskussion) 15:20, 3. Jul. 2012 (CEST)Beantworten
Sorry for confusion; ich versuche mal auseinanderzuklamüsern.
RonMeier lädt zurzeit die Entwickler-Version d.js; die ist nicht minimiert und hat die Krankheit nicht.
Das Skript aktualisiert sich, wenn man Cookies hat, automatisch mit dem 2. Edit nach jeder vollen Stunde; ansonsten um Mitternacht. Man kann sich aber eigentlich nur mit Cookies anmelden.
Dummerweise hat die engl.WP seit einer Woche zeitweilig eine Schlafmützigkeit von 2000–3000 Sekunden und verpennt meinen Aktualisierungsmechanismus. Ich habe sie jetzt grad nochmal angeschubst; beim 2. Edit bitte nochmal probieren.
Wenn da noch irgendwas hakt: Letzte Rettung WP:JS#Cache
Vor dir war Andreas Praefcke drangewesen und hatte durchgeputzt.
Die JS-Fehlermeldung von oben bekomme ich nicht.
Ich sehe drei ISBN-Fehler (in Literatur-Vorlage das Wort „ohne“ bzw. „(ohne)“ bzw. fehlt auch noch Gleichheitszeichen.) Ich bekomme aber nicht die rote Kiste dazu; irgendwas stimmt nicht.
Außerdem noch ein ASIN, aber das geht das Skript nichts an.
Lass uns das mal ein paar Tage verschieben; ich mache mir Gedanken und müsste das testwiki erstmal für die neue Situation umbauen. Wenn ich nichts finden kann, baue ich dir Diagnose-Meldungen ein.
Danke; im letzten November war auch ein gewisser RonMeier schon mal dran gewesen – aus der Zeit stammt noch eine Grundpolitur, die von den zwischenzeitlichen Edits nicht beeinträchtigt wurde.
Das Skript hatte an den drei Stellen ISBN-Vorlagenparameter gefunden, die mit absolut null Ziffern ausgewertet wurden. Darüber war es so verblüfft, dass es vor Schreck die Fehlernummer in den Text geschrieben hatte, an Stelle des WikiTom-Textes. Viel später wurde dann diese Zahl vorgefunden und die wusste im Gegensatz zum WikiTom nicht, wie sie sich selbst ersetzen kann. Das war die Bedeutung jener Fehlermeldung.
In der Sache ist beim ISBN-Vorlagenparameter nur die Zahlenangabe wünschenswert. Das „(ohne ISBN)“ ist nur selten sinnvoll; wenn 1950 oder im Selbstverlag erschienen, bedarf es dieser Info nicht. Nur bei einem Buch, das ungewöhnlicherweise wirklich ohne ISBN gedruckt wurde, könnte man das mal unter |Kommentar= erwähnen.
Das r.js wäre insofern hilfreich, weil weitere Minimierungsfehler wie vor nicht auszuschließen sind.
Ich dachte schon, ich hätte beim edit im November was übersehen, man ist ja nicht fehlerfrei ;-). Die Anmerkung "ohne ISBN" bei |Kommentar= finde ich unzweckmäßig. Der Leser sieht auch so, dass da keine ISBN ist. Wenn dies aber als Kommentar im Quelltext steht (<!-- ohne ISBN -->) fände ich das schon gut. Gruß --RonMeier (Diskussion) 12:08, 4. Jul. 2012 (CEST)Beantworten
Letzten November lief noch WSTM.3 – das hätte einen Parameter |ISBN=, dessen Wert nicht mit einer Ziffer begonnen hatte, gar nicht erst wahrgenommen.
Wenn es ein Buch ist, bei dem man normalerweise eine ISBN erwarten würde, dann fände ich einen sichtbaren Hinweis „ohne ISBN“ zumindest nicht so schlimm, dass man ihn auskommentieren müsste. Es könnte ein Indiz für Selbstverlag etc. sein, und damit zur groben EInschätzung herangezogen werden.
Wenn nach Jahreszahl eigentlich eine ISBN zu möglich wäre, aber durch Selbst-Herausgabe von Firmenschriften, Ortschroniken, Broschüren oder Dissertationen nicht so restlos klar ist, ob nun mit oder ohne ISBN publiziert wurde, dann ist der auskommentierte Vermerk eine Arbeitserleichterung für folgende Wiki-Autoren, dass bereits einmal gesucht wurde, man das Werk in der Hand hatte und es wirklich keine ISBN gibt.
Wenn sowieso klar ist, dass es keine ISBN geben kann, dann ist auch eine auskommentierte Info überflüssig.
Ich hatte das Skript heute nacht wohl so zusammengesch…taucht, dass es sich überhaupt nicht mehr getraut hatte, irgendwas zu ändern.
Nebenbei ist das eine interne Anwendung des von dir bereits herbeigesehnten change. Es lohnt sich, die Doku zu beobachten; ich bin in der Schlusserprobung der öffentlichen Freigabe des format.order – müsste aber mal das Regenwetter haben, um selbst die benutzerdefinierten Aktivitäten zu testen.
So ziemlich das gleiche Problem wie eins drüber, fürchte ich. Hättest du mal den Beispielartikel? Könnte sein, dass das Skript strahlend mitteilt, es würde null Fehler geben; oder es ist nur beim gefürchteten letzten Vorlagenparameter ein Problem.
Den ruinierten ISSN-Parameter habe ich wieder geradegebogen. Er ist eine Folge der change-Operation auf Vorlagenparameter, die seit gestern wirksam wurde, und war so noch nie getestet gewesen.
Irgendwie bin ich hier bei 30 Grad und 1000 Prozent Luftfeuchtigkeit in den letzten Tagen in etwas hineingeraten, was ich noch gar nicht haben wollte. Eigentlich möchte ich jetzt in den ersten Juliwochen die Breitenerprobung von WSTM.5 abwarten, ohne laufend neue Features in den Code einzubauen und im laufenden Betrieb erproben zu müssen. Die change-Operation auf Vorlagenparameter ist erst für August vorgesehen, nach Abschluss der Migration WSTM.4→5 und Erprobung der r-Version dazu.
Wenn du dich übrigens wunderst, warum dein common.js irgendwie nicht richtig tickt: Zwischen den {} von [Ii]nternetquelle und cite book fehlt ein Komma. cite book kann auch nur wirken, wenn es bei der Einbindung kleingeschrieben wurde.
Grundsätzlicher Auslöser war eine Leerzeile bzw. durch geschützte URL einer Leerzeile gleichkommende Situation.
Jetzt hoffentlich besser geworden? Ich kann es nicht (mehr?) reproduzieren.
Das Skript teilt den Wikitext an Leerzeilen \n\n in Segmente. Nie erwartet hätte ich Leerzeilen innerhalb einer Vorlageneinbindung; während ich früher zuerst segmentierte, habe ich jetzt zwei Zeilen im Gesamtablauf vertauscht und werte zuerst die Vorlagen aus. Zwar kann eine Vorlageneinbindung sich über mehrere Segmente→WikiTom erstrecken, aber eine Segmentgrenze innerhalb der Folge Pipe-Symbol→Parameter-Name→Gleichheitszeichen ging dann doch etwas zu weit.
besser ist es nicht geworden, aber anders: {{cite book| last=Strmiska | first=Michael | title=Modern Paganism in World Cultures: Comparative Perspectives | url=http://www.abc-clio.com/products/overview.aspx?productid=109757|1= format= | year=2006 | publisher=ABC-CLIO | isbn=1-85109-608-6 | chapter=Heathenry, the past, and sacred sites in today’s Britain by Jenny Blain }} Gruß --RonMeier (Diskussion) 13:36, 7. Jul. 2012 (CEST)Beantworten
Okay, morgen ist Regenwetter angesagt; die Nacht wird wohltemperiert, da werde ich dein clear mal übernehmen und damit experimentieren. Für weniger fortgeschrittene Benutzer passiert schon mal nichts Böses. Ursache ist offenbar die vorangehende URL und ihr Schutz, die beim clear irgendwas durcheinanderbringt.
evtl. als Hilfe: bei NK Imotski, aus: rang = 5. Platz| pattern_la1=|pattern_b1=|pattern_ra1=|leftarm1=BE0C03|body1=29459B|rightarm1=BE0C03|shorts1=BE0C03||socks1=29459B|
pattern_la2=|pattern_b2=|pattern_ra2=|leftarm2=FFFFFF|body2=FFFFFF|rightarm2=FFFFFF|shorts2=BE0C03|socks2=FFFFFF| }} wird ein:
Danke schön; aber den NK Imotski habe ich wohl mittlerweile im Griff; ich kämpfe mehr mit dem Germanischen Neuheidentum bei gleichzeitigem clear in cite.
Deinem Zitat fehlt etwas Entscheidendes: Zwischen socks1 und pattern_la2 steht eine Leerzeile; und die war bis gestern Auslöser für einen Absatzwechsel, und dies Verursacher für einen Holperer.
Das |1=| ist beabsichtigt. Diese Veränderung macht eine sinnfreie verdoppelte Pipe sichtbar. Ebenfalls Absicht ist |2=}} – auch dieses | ist sinnlos und soll entfernt werden.
Ich muss jetzt erstmal ein wenig die in den laufenden Betrieb eingeflickten Änderungen testen, bevor ich auf das neue clear eingehen kann.
Ich nehme ja an, das diese kryptischen Fehlermeldungen irgendwann in die rote Kiste kommen. Das was aber jetzt noch auffällt, sind die Zeilenschaltungen nach der Pipe vor pattern. (Schönheit!) Gruß --RonMeier (Diskussion) 18:23, 7. Jul. 2012 (CEST)Beantworten
Die rote Kiste war noch nicht in Planung; da müsste man nach den Sommerferien mal in der Vorlagenwerkstatt diskutieren, ob das Auftauchen unbenannter Parameter nach benannten Parametern regelmäßig eine Warnung auslösen soll. Ich weiß von der Geschichte überhaupt erst seit gestern vormittag; siehe der folgende Abschnitt. Grundsätzlich kann sich bei solchen Parametern jemand etwas gedacht haben; oder es wurde etwa ein Gleichheitszeichen vergessen – das hätte die gleiche Wirkung.
Ich bin schon heilfroh, die Pipe-Symbole nach vorne gezogen zu haben. Der seltsame Zeilenumbruch ist der Überrest der bisherigen Leerzeilen. Schau dir das einfach mal unangemeldet im Originaltext an, oder eine oldid-Version.
Es gibt viel zu viele Möglichkeiten, Vorlageneinbindungen zu formatieren, als dass ich ohne eine benutzerdefinierte Aktivität automatisiert an wildfremden Vorlagen hantieren werde. Den letzten Rest an Schönheit müssten sich die Autoren schon individuell nach menschlichen Gesichtspunkten arrangieren; das überfordert eine Automatik.
Letzter Kommentar: vor 11 Jahren5 Kommentare2 Personen sind an der Diskussion beteiligt
Gesehen in NK Imotski. Alle \n wurden aus der IB entfernt, außerdem haben die leeren unbenannten Parameter (was immer sie da zu suchen haben) Nummern bekommen, was in meinen Augen auch sinnlos ist (und wenn, dann müssten sie durchgehend von 1 ab nummeriert werden, nicht nach der Position). WSTM_about sagt: (r) Run=5*. --Schnark10:09, 6. Jul. 2012 (CEST)Beantworten
Sehr ärgerlich.
Eigentlich werden die in der Einbindung vorgefundenen Layout-Informationen (Zeilenumbrüche, Leerzeichen) konserviert; die Leerzeichen wenigstens sind auch brav wiederhergestellt worden.
Ursächlich ist, dass hier die Pipe-Symbole am Zeilenende stehen. Dafür gibt es eigentlich auch eine Erkennungs-Operation, die aber ersichtlich nicht in die Wieder-Ausgabe einfloss.
Was meinst du: Sollte man in solchen Fällen diskussionslos alle Pipe-Symbole vom Zeilenende an den Anfang setzen?
Unbenannte Parameter ohne Wert brauchen auch nicht eingefügt werden; ich werde versuchen, das zu unterbinden. Was die Zählung angeht: Mit der Kombination von benannten und danach wieder unbenannten hatte ich noch nichts zu tun; bisher verstand ich zumindest unseren Hilfetext so, dass die Zählung ab Anfang läuft. Muss man wohl erstmal herumexperimentieren.
Auslöser für die Bearbeitung der IB war übrigens das Anfügen des / an die Domain in homepage=.
Pipes an den Anfang stellen ist meiner Ansicht nach in Ordnung, auch wenn je nach verwendetem Diff-Algorithmus die Änderung nicht wirklich lesbar ist.
zu unbenannten Parametern:
„Das ist der erste unbenannte Parameter, auch wenn es der zweite insgesamt ist“
Die Anhängung der 4 Buchstaben an die 4 vorhandenen Buchstaben hat übrigens nicht funktioniert, allerdings war immer schon ein gleichwertiges Schlüsselwort vorhanden. --Schnark11:52, 6. Jul. 2012 (CEST)Beantworten
Erstmal gefixt und live, was die Zeilenumbrüche angeht:
Die Pipe-Symbole werden jetzt an den Zeilenanfang gestellt.
Beim Parsen der Vorlageneinbindung werden alle Layout-Infos ohnehin in Flags umgesetzt; nur war ich mir bislang unschlüssig gewesen, was ich beim Wiederausgeben eines veränderten Vorlagen-Inhalts damit anstellen soll. Bislang hatte ich auch noch kein konkretes Beispiel vor Augen.
Übrigens lassen sich für alle "^[Ii]nfobox " benutzerdefiniert über format.style Layout-Vorgaben machen, die auf alle Parameter wirken; weil diese aber für lat_ und lon_ oder hier für pattern_ bei einzelnen Parametern abweichen können, ließen sie sich für bestimmte Parametergruppen abweichend gestalten.
Die Situation „Unbenannter Parameter nach benanntem Parameter“ muss ich noch mal in Ruhe durchdenken.
Grundsätzlich halte ich sie für einen Benutzungsfehler. In einer gut programmierten Vorlage und sinnvollen Kopiervorlage kann das nicht vorkommen.
Die vorangestellte Parameternummer möchte ich jedoch nach dem Auftreten des ersten benannten Parameters zeigen (momentan würde sie wohl immer erscheinen; da muss ich ohnehin noch nacharbeiten). Damit würde auf vergessenen Parameternamen und unverständliche Einbindung aufmerksam gemacht.
Umso mehr im konkreten Fall; hier war ein unsinnig verdoppeltes Pipe-Symbol Auslöser.
Unbeschadet dessen muss ich noch mit der korrekten Zählung herumexperimentieren.
Bei nächsten Upload wird das für konfuse Fälle noch nachjustiert.
Tauchen nach dem ersten benannten Parameter noch unbenannte Parameter auf, dann wird das verdeutlicht durch Einfügen der Nummern. Damit fallen im konkreten Beispiel die sinnfreien Pipe-Symbole zwischendrin und hintendran besser auf und können manuell entfernt werden. Unbenannte Parameter noch aufzuführen mitten zwischen den benannten ist für die Autoren verwirrend und sollte bereinigt werden.
Nein; im Zusammenhang mit einer anderen Korrektur heute wurde in das Management der Vorlagenparameter eingegriffen; das hat offensichtlich Nebeneffekt auf die Personendaten-Vorlageninfos. Sollte vor Sonnenuntergang geradegerückt sein. Danke für die Info --PerfektesChaos15:04, 7. Jul. 2012 (CEST)Beantworten
Bei der heute mittag eingespielten Änderung waren noch nicht alle Varianten von Vorlagenparameter-Formaten durchgespielt gewesen.
Mit deiner 2. Bearbeitung nach 16:00 sollte sich das Problem gelöst haben.
Es kam in den letzten Tagen zu einer in dieser Form nicht geplanten Bastelei an den Vorlagenparametern und ihrer Formatierung; das dürfte die Erkennung beeinflusst haben.
Spätestens morgen sollte es wieder gehen; eine milde Nacht vorausgesetzt.
Seit heute abend nach 19:00 ging es plötzlich nicht mehr?
Mit deinem 2. Artikel-Edit nach 23:00 klappt es hoffentlich?
Falls beide ja, so ist mir der Zusammenhang unerklärlich; ich wollte eigentlich besonders sanft eine in Folge der Aktionen der letzten Tage erforderliche Ablaufänderung einspielen, die besonders ruckelfrei und unbemerkt vonstatten gehen sollte.
Das ist doof; bei mir geht es mit der Volksausgabe (r-Version).
Hättet ihr mal Beispielartikel?
Ursächlich ist dieser kroatische Fußballverein, der eine Leerzeile und damit einen Abschnittswechsel inmitten einer Vorlageneinbindung zwischen Pipe-Symbol und Parameternamen praktiziert hatte. Dessen Berücksichtigung seit Fr/Sa hat leider mysteriöse Folgewirkungen, denen ich hinterherflicke.
Die Frage nach den So-Abend-Uhrzeiten hat sich erledigt; es war der Verdacht, ob eine vorsichtshalber So 19:00 live gestellte Verbesserung irgendeinen unerklärlichen Nebeneffekt haben würde. Das ist offenkundig nicht der Fall gewesen; So 23:00 hatte ich das Gegenstück dazu nachgeschoben, das auf 19:00 aufbaut – dies ist aber offenbar überhaupt nicht beteiligt.
Gehenkt will ich sein – aber mit meiner r-Version frisch vom allgemeinen Server flutscht alles.
Sivaji Ganesan war auch vor 19:04 schon GND gewesen; jetzt könnte noch ein Strichelchen zwischen 7304 und 052 platziert werden.
Du hast recht: das DEFAULTSORT hätte sich ja auch ändern müssen und das tat es nicht. Und: Cite ist mir bisher noch nie begegnet (glaub ich). Und: mit der aktuellen r-Version gehts ja - nicht nur bei dir. WSTM-Wetter --RonMeier (Diskussion) 12:12, 9. Jul. 2012 (CEST)Beantworten
Aha. Demzufolge hatte die am Sonntag in zwei Portionen eingearbeitete Anpassung an die Sonnabend für den kroatischen Fußballverein geänderte Verarbeitungsreihenfolge ihre Notwendigkeit und Berechtigung.
@AndreasPraefcke: Bei dir jetzt auch wieder alles wie gewünscht?
Sobald das hier sauber zu funktionieren scheint, muss ich noch einmal etwas massiver eingreifen; es geht bei veränderten Vorlageneinbindungen um den möglichen Zeilenumbruch zwischen Vorlagen-Namen und erstem Pipe-Symbol; durch die Änderungen für diese dusslige Fußball-IB kann der jetzt möglicherweise doppelt auftreten und die gesamte Programmierung des Zeilenumbruch-Layouts muss geändert werden; wird dann aber auch besser und klarer sein.
Am 21. Juni war AndreasPraefcke drangewesen und hatte Klarschiff gemacht. Es gibt also eigentlich nichts zu verändern, außer die Warnmeldung anzuzeigen.
Kurioserweise kommt die rote Kiste, wenn man das alles in die Spielwiese kopiert und dort ausführt.
Die Ursache steckt irgendwo in der gigantisch ausgedehnten Infobox von 4 Kilobyte, in deren Parameterwerten sich halbe Artikel verbergen.
Wenn du irgendwann später mal änderst, kannst du nach dem Wort Abschitt suchen.
Die Autoren dazu haben in ihren seltsamen Vorlageneinbindungen bestimmte Krankheiten, die sich erst seit Freitag ergeben haben.
Ich habe eine konkrete Vorstellung davon, wo hier das Problem liegt. Ich kann im Moment noch nicht viel unternehmen, weil ich Gefahr laufe, sonst überhaupt keine halbwegs richtig tickende Skriptversion zu haben, um andere Probleme zu lösen.
Da der o.a. Herr nur bei uns beiden mit unseren benutzerdefinierten Funktionen austickt und es bei den Normalbenutzern relativ unbeschädgt davonkommt, werde ich noch einige Tage auf sonstige Reaktionen der ersten Umstellungswelle abwarten (die wirkt sich ggf. erst 7–31 Tage verzögert bei den Anwendern aus) und danach wieder eine Verzweigung einrichten auf testwiki und Normalversion. Das braucht aber noch ein paar kühle Tage, möglichst mit Regen, vielleicht übermorgen. Erst in einer unabhängigen Testversion kann ich größere Umstellungen wagen.
Ja, wir verwenden beide in dieser Woche die Normalbenutzerversion mit r.js auf enWP, aber wir haben die ganzen config.mod aktiviert. Die beeinflussen wesentlich den Ablauf, weil dadurch alle zu schützenden Bereiche abgetrennt werden. Damit werden unter anderem Teile der Vorlage geschützt, und wenn die verändert wieder zusammengebaut werden, stimmt das im Moment nicht so ganz mit der vorgefundenen Einbindung überein. Jetzt angenehme Temperatur eingetreten. --PerfektesChaos23:26, 9. Jul. 2012 (CEST)Beantworten
Letzter Kommentar: vor 11 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo,
die Ersetzung von
|FREMDVERSION=http://hu.wikipedia.org/w/index.php?title=Vuk&
bringt in der Vorschau als Ergebnis
Der Artikel Vuk (Film) basiert ursprünglich auf einer Übersetzung von Vuk (film) aus der ungarischen Wikipedia, Version vom [[[:hu:Special:PermanentLink/2465613?title=Vuk|Vuk]] 27. November 2007, 23:45].
Gruß --RonMeier (Diskussion) 10:02, 17. Jul. 2012 (CEST)Beantworten
Sowas hat wir schon mal mit der Vorlage cite web oder internetquelle; es sollen keine Links auf WMF-Projekte als URL im Wikitext stehen, wenn ein Wikilink möglich ist.
Vuk (Film) wurde erstmal in diesem Sinn angepasst.
Für die sonstigen Benutzer wäre ich in der Lage, ein Plug-In zu schreiben, das bei Vorlage:Übersetzung die Parameter automatisch anpasst.
Viel schöner: Am Sonntag habe ich wahrscheinlich einen schon längere Zeit vermuteten Bock erlegen können. Er wäre verantwortlich für das unvermutete Einfügen von 1= und den Ausfall beim inzwischen ISBN-berichtigten Spanischen Bürgerkrieg. Bereits in der Woche zuvor hatte ich eine Seltsamkeit aufklären und live stellen können.
Das neueste Fix hat an einer sensiblen Stelle der Vorlagenanalyse ein „+1“ entfernt. Das war allerdings eine Programmierung, die seit Mai bestand, und ich bin mir über mögliche Nebenwirkungen noch nicht ganz sicher. Deshalb ist das seit gestern in der Erprobung und noch nicht live. Ausschlaggebend sind Einbindungen, bei denen Vorlagen unmittelbar nebeneinander ineinander stehen; und dies war bislang leider kein Testfall gewesen.
Dämlicherweise ist seit dem Wochenende das testwiki breit und ich kann nichts hochladen, obwohl ich dort schon wieder eine neue Testumgebung aufgebaut hatte.
Ich habe deshalb eine Testumgebung im en. eingerichtet, die bei Einbindung von /d.js wirksam werden sollte. Ich bitte dich, deine common.js entsprechend r→d anzupassen und bei der Erprobung mitzuwirken; wenn es bis zum Wochenende keinen Ärger gibt, werde ich dies für fast alle Benutzer live schalten.
Eiwei, sieht ja böse aus. Hat mir trotzdem sehr geholfen.
Um das erste Pipe-Symbol zwischen Vorlagen-Name und erstem Parameter hatte sich im Skript ziemlich viel Schrott und Flickwerk angesammelt.
Wenn nun direkt auf den Namen (ohne Zeilenumbruch oder Leerzeichen) der erste Parameter folgt und dieser mehrteilig ist (hier also Verlinkung), dann verzählt der Bursche sich.
Ich habe das jetzt entrümpelt und neu geschrieben. Heute muss ich das aber erstmal austesten; voraussichtlich heute Abend live.
Weil es nur Anwender mit benutzerdefinierten Änderungen erwischen dürfte, trifft es vermutlich nur uns beide.
Sowas hatten wir schon mal; auf url=... folgt Pipe-Symbol ohne Leerzeichen. Ich dachte, den hätte ich erwischt gehabt. Weil ich die Vorlage nicht ändere, passiert bei mir nichts; da muss ich mir deinen Ersetzungsausdruck erstmal kopieren. Mache ich, nachdem ich den vorigen Bock begraben habe. LG --PerfektesChaos09:40, 18. Jul. 2012 (CEST)Beantworten
Das mit der 1= kann ich mit der von dir ausgeborgten Ersetzung nicht (mehr) reproduzieren. Das heißt vielleicht, dass es erledigt sein möge?
Moin, nein weg ist es nicht. Auch nach hartem Cache löschen wird bei den letzten beiden Vorlagen immer noch nach dem Link die 1= eingetragen und das doi nicht gelöscht. (sprich: keine Änderung) Gruß --RonMeier (Diskussion) 08:53, 19. Jul. 2012 (CEST)Beantworten
Hmmmmmmh, da muss ich mir erstmal eine Strategie austüfteln.
Erstmal bin ich ratlos. Bei mir ist alles fein.
Ich vermute, dass die URL davor irgendwas beeinflusst.
„bei den letzten beiden Vorlagen“ – danach noch treehugger.com ohne Leerzeichen, davor zwei mit URL+Leerzeichen+Pipe.
Das Vorhandensein von Leerzeichen vor der Pipe wird auch mit regulären Ausdrücken unterschieden; da gibt es hin und wieder Unterschiede zwischen Browser-Versionen.
Ich plane, an genau dieser Stelle eine Diagnostik-Meldung einzubauen, die an dieser Stelle und nur bei Uship Infos in die Konsole schreibt.
Vorher gucke ich mir genauer an, was bei den schließenden Leerzeichen oder nicht passiert.
Beiläufig deine common.js durchgeguckt:
Erledigt weil WSTM.5-Standard sind //* Zusammenziehen von <ref "name"> </ref> zu <ref name="name" /> PMID
|url| wäre Pflichtparameter bei cite web, würde ich stehen lassen; cite web ohne die Original-URL sollte an Vervollständigung erinnern.
(Jetzt) Überflüssiges aus der common.js entfernt. Da sich Cite web mit einer Fehleraussschrift meldet, wenn url oder der Eintrag bei url fehlt, lass ichs erstmal drin. Bis dann --RonMeier (Diskussion) 10:45, 19. Jul. 2012 (CEST)Beantworten
Nach längerem Gebastel habe ich herausgefunden, warum unsere Browser unterschiedlich reagieren: Bei mir ist auch config.mod.link bzw. config.mod.url aktiv, bei dir nicht. Das hat Auswirkungen auf die Steuerung und Zerlegung.
Die grundsätzliche Ursache ist auch geklärt: Das | ist legitimes Zeichen in einer URL, wie auch die Satzzeichen .,? und übrigens auch [ und ] (wenngleich nicht alle dieser Zeichen offen in einer URL erwünscht sind). Das haben wir einen Abschnitt weiter unten schon einmal.
Bei dieser Einbindung liegt die URL erstmal in der Form „ungeklammertes Weblink“ vor, und die | wird zur URL gezählt. Innerhalb der Vorlagenanalyse weiß das Skript, dass das | Parameter trennen soll, und spaltet das | von der URL nachträglich wieder ab. Dabei entsteht in diesem konkreten Fall ein einzelnes Bröckchen nur aus dem Zeichen | und das ist nicht von einem unbenannten Parameter zu unterscheiden; deshalb die 1=. Würde dort stehen |url=URL|doi= – dann wäre das Bröckchen |doi= und das würde verstanden werden; weil aber vor dem Pipe-Symbol kein Leerzeichen steht, jedoch eins danach kommt, wird die Syntaxanalyse auf die Rolle geschoben.
Konsequenzen: Heute abend werde ich die URL-Analyse umbauen mit der Maßgabe
Bei Analyse einer URL im Kontext einer Vorlageneinbindung von vornherein am | abtrennen.
Bei einem Satzzeichen als letztem Zeichen einer nicht geklammerten URL eine Warnmeldung veranlassen.
url=| – Ah, verstehe; du willst den schussligen Autoren die Fehlermeldung aufdrücken?
Aber in der Vorlage steht {{#if: {{{url|}}} | {{#if: {{{title|}}} |1}}}} ||Fehler beim Aufruf der [[Vorlage:cite web]]: Die Parameter url und title müssen vorhanden sein.
Deshalb ist es egal, ob |url=| steht oder der Parameter ganz fehlt. Für die nachbearbeitenden Autoren ist es aber eine Hilfe, wenn du ihnen das url= stehenlässt.
zu 2. ICH sehe die Fehlerausschrift. Einen fehlenden Link hatte ich m.W. noch nie, falsche bzw. verstümmelte schon öfter. Und bei fehlendem Weblink, wer soll schon wissen, was dort hin sollte, wenn nicht der Autor. Mit fehlender url würde ich die Vorlage wahrscheinlich auskommentieren. Gruß --RonMeier (Diskussion) 16:50, 19. Jul. 2012 (CEST)Beantworten
Zu 1:GEFUNDEN
Die erwähnte Programmierung im Kontext einer Vorlageneinbindung von vornherein am | abtrennen gab es schon seit über einem Vierteljahr, aber bei einer Überarbeitung war in einem Funktionsaufruf ein an dieser Stelle veralteter Parameter stehengeblieben und brachte die Versorgung mit schlauen Schaltern durcheinander. Weil dieser Irrläufer nun gerade config.mod.url gewesen war und das bei mir etwas ist und bei dir nichts, funktionierte es bei mir und bei dir nicht.
Im Nachgang kann ich jetzt weiter aufräumen und auch die Warnkiste bei seltsamen Zeichen einbasteln, schließlich testen. Morgen dann die verbesserte Version.
Zu 2: Ach, was bist du grausam. Es könnte ja ein Edit-Unfall sein; vielleicht ist beim Paste der URL das Strg+C verklemmt gewesen. Wenn der Titel der Seite und eine erratbare Publikation bei title und publisher usw. angegeben sind, lässt sich die URL ja vielleicht ergoogeln. Eigentlich müsste man einer so häufig verwendeten Vorlage eine Wartungskategorie für fehlende Parameter zuordnen und die Fehlermeldung mit class="error" darstellen; aber sie ist sowieso gesperrt. Wenn die URL also nicht ermittelt werden kann, müssten sich die ursprünglichen Autoren weiter darum kümmern; und das werden sie nicht merken, wenn das auskommentiert ist.
Ja, das Leben ist hart und ich werde keine Rücksicht auf verklemmte Strg+C-Tasten nehmen. Zeige mir den Autor, der seine Seite (wenn er es denn tut, bei einigen ist es ja Massenware) beobachtet und nicht die Diffpage auswertet, in der die Auskommentierung deutlich erkennbar ist. Gruß --RonMeier (Diskussion) 17:59, 19. Jul. 2012 (CEST)Beantworten
Tja, die Problematik ist bekannt und hier seit Jahren beschrieben.
Normalerweise ist es egal, weil es nur im Fall von Wiki-Projekt-URL zu automatischen Ersetzungen kommt. Die stehen relativ selten offen im Text, und dann noch seltener mit Satzzeichen dahinter.
Dies ist meiner Erinnerung nach der erste Fall in dieser Richtung.
Prinzipiell ist die Situation nicht eindeutig aufzuklären. Mit WSTM.5 gibt es aber die schönen roten Kisten, und bei jeder ungeklammerten URL, die auf ein Satzzeichen (+Leerzeichen) endet, werde ich irgendwann die Warnmeldung anzeigen.
Ich kann bestätigen, dass das vorangehende Semikolon das Auffinden zurzeit explizit ausschließt. Insofern hat das Skript genau das getan, was man ihm gesagt hat.
Es steht so auch bereits seit anderthalb Jahren unverändert drin.
Es sollte damals vermutlich das Zerpflücken von URL vermeiden.
Anwender ohne benutzerdefinierte Ersetzungen bekommen ihre Linkziele nicht gegen Suchvorgänge geschützt; in einer URL könnte es heißen
An gleicher Stelle schließe ich auch & und ? aus; das lässt darauf schließen, dass es mal um URL ging. & ? ; , (info) sind typische Zeichen, die vor Parameterangaben stehen können.
Den Such-Ausdruck habe ich inzwischen sorgfältiger geschrieben; wenn ein Leerzeichen oder Zeilenumbruch dazwischen sind, kann es nie eine URL sein. Ist aber noch nicht live; erst morgen, nach kursorischem rumtesten.
Wenn benutzerdefinierte Text-Ersetzungen vorliegen, dann müssen zum Zeitpunkt der Suche nach ISBN alle Linkziele (URL) gegen Suchen und Ersetzung bereits geschützt worden sein und dann darf das Semikolon sogar schon unmittelbar vor ISBN stehen.
Die ISBN wurde am 21. Juli von RonMeier gefixt; es gibt nichts mehr zu tun. Die momentane Version hat einen Zeilenumbruch ganz am Ende; irgendwas entschließt sich, überflüssige Zeilenumbrüche nach PD herauszunehmen. Diff verweigert deren Anzeige (ist bekannt). Wiedervorlage nach dem Endsieg. --PerfektesChaos20:41, 1. Aug. 2012 (CEST)Beantworten
Letzter Kommentar: vor 11 Jahren6 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo, ich bekomme benutzerdefinierte Ersetzungen nicht zum Laufen. Laut Deiner Seite soll mit
mw.libs.WikiSyntaxTextMod.config.mod.plain vor mw.loader.load definiert werden. Das gibt bei mir (common.js) immer "mw.libs.WikiSyntaxTextMod is undefined", die Sachen von Schnark weiter unten werden dann auch nicht mehr abgearbeitet. Ich habe auch probeweise Deine Beispiele reinkopiert (aber nicht abgespeichert), derselbe Fehler in der Fehlerkonsole beim Aufrufen der Vorschau. Gruß,--Half-Bot (Diskussion) 19:59, 20. Jul. 2012 (CEST)Beantworten
Willkommen im Club!
Du müsstest bitte dieses Anwendungsobjekt mit der mod-Komponente vorher definieren; am besten:
Die Wirkung ist, dass du dann die Komponenten mw.libs.WikiSyntaxTextMod.config.mod leer vorzuliegen hast; dann kannst du sie auch mit den einzelnen Ersetzungsanweisungen befüllen.
Wenn es doch noch Probleme gibt, ruhig noch mal fragen.
Nachtrag: Zu deinem BBKL müsste ich dich vorwarnen, dass es ohnhin etwas trickreicher werden wird. Du bist damit im Abschnitt Vorlagen-Ersetzung und das wird etwas anders als schnöder (plain) Text ablaufen.
Ich errate mal, dass du möchtest, dass jede Einbindung von BBKL mit den Parametern autor, artikel, band, spalten ergänzt werden soll, wenn sie noch nicht vorhanden sind.
Das ist aber frisch gelegt und noch nestwarm; steht noch nicht mal in der Doku und die genaue Wirkung muss ich übers Wochenende selbst noch einmal durchtesten. Am besten Anfang kommender Woche noch mal grünes Licht abholen.
Danke! Funktioniert noch nicht (auch nicht nach Ersetzen der äußeren {} durch [], vorher gabs Fehlermeldungen), aber da warte ich lieber auf Deine Tests. Die Kopiervorlage für die unausgefüllte Vorlage hat die Form
{{BBKL|kenner|autor=|artikel=|band=|spalten=–}}
Stattdessen ist häufig nur der Kenner ausgefüllt worden, als damit noch der Weblink erreichbar war, mittlerweile seit langem abgeschaltet. Alle ohne Bandangabe sind seit kurzem in der Wartungskategorie. Fast alle davon haben nur den Kenner:
{{BBKL|j/Johannes_arg}}
Nicht jede, erstmal nur diese Variante soll dann automatisiert geändert werden zu:
Der Rest nach den Gleichheitszeichen muss dann mit C&P rein, ich wollte mir nur das manuelle Anhängen der Parameter sparen. Mit RE an sich eine simple Ersetzung, wenn (plain) Text erlaubt wäre, in meinem Texteditor funktionierte die Erkennung u. Ersetzung prima (noch mit einfachen \ statt der elenden \\). Dein Skript betrachtet die mit {{ eingeleiteten Vorlagen aber als Schutzbereich, soweit habe ich mich inzwischen durch die Doku gewühlt. --Half-Bot (Diskussion) 22:38, 20. Jul. 2012 (CEST)Beantworten
Sorry für die eckigen Klammern; war freihändig geschrieben. Du meintest ja, diese Woche keine Zeit zu haben; ich versuche, je nach Wetter deine BBKL als Musterlösung in die Doku zu schreiben. Es funktioniert bei mir jedenfalls ganz nett. Grüße --PerfektesChaos20:41, 1. Aug. 2012 (CEST)Beantworten
Letzter Kommentar: vor 11 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
Da ich mein Screenshot-Skript gerade an sinnvollen Dingen testen wollte, kam mir in den Sinn, damit ein Bildschirmfoto von der WSTM-Warnbox über nicht automatisch behebbare Fehler zu machen. Dazu wollte ich folgenden Wikitext auf der Spielwiese deinem Skript zum Fraß vorwerfen:
Überschriften ab Byte 1 verträgt das Skript, eine Überschrift zwischendrin mit ungleicher Anzahl von Gleichheitszeichen wird korrekt gemeldet; nur bei beidem gleichzeitig springt es zurück auf Anfang und findet von neuem. An Zeile 785 werde ich heute abend etwas ändern müssen.
Bei mir auf der Festplatte gefixt, aber vorläufig nicht live.
In dem Zweig, in dem die Fehlermeldung steht, wurde der Pointer nicht weitergeschubst. Wenn der Fundstellen-Pointer aber auf Byte Nr. 0 steht, greifen andere Mechanismen nicht und er sucht wieder ab 0.
War vermutlich auch einen Tag später bereinigt gewesen.
Mir ist das Watchlist-Häkchen von dieser Seite gerutscht, keine Ahnung wie; ich hatte gedacht, das Skript läuft und alle wären im Urlaub und niemand beschwert sich, und war selbst viel an Sonnenschein und frischer Luft.
Deshalb die späte Antwort; den Bug oben hatte ich bei einem Routinetest selbst gefunden und bereits nachgebessert.
Letzter Kommentar: vor 11 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
Das Skript versucht eine merkwürdige Änderung bei falscher ISSN. Von {{ISSN|0892-3310/99}} in {{ISSN|0892-3310/99��}}. Das ZDB Opac ignoriert anscheinend ohnehin alles hinter /, ich konnte das in beiden Varianten aufrufen. Gruß,--Half-Bot (Diskussion) 20:03, 22. Jul. 2012 (CEST)Beantworten
Stimmt leider; ich weiß auch in etwa, woran das liegt. Das Format mit der /99 kommt etwas unerwartet; sonst sind es 4+4 Ziffern/X. Irgendwie bringt die /99 was durcheinander.
Ansonsten war mir diese Seite auf unerklärliche Weise vom Radarschirm geflutscht, deshalb eine ungewohnt späte Antwort.
Das ab /99 muss nicht wirklich falsch sein; es sind zwei Reserve-Ziffern in der ISSN vorgesehen für Sonderfälle. Die habe ich da wohl gerade erwischt.
Das stand aus alten Zeiten zur sauberen Programmierung in WSTM.5 noch auf meiner ToDo-List. Jetzt in dieser neuen Form umgesetzt; in meiner Testumgebung funktioniert es bereits korrekt.
Nach einem etwas längeren Prozess der Aktualisierung und Gesamttest voraussichtlich morgen im Lauf des Tages live; allerdings gehen gleichzeitig andere und komplexere Herausforderungen ans Netz, die etwas Zeit brauchen werden.
Letzter Kommentar: vor 11 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
aus:
url=http://si-pddr.si.edu/dspace/bitstream/10088/6026/1/Koepfli_2007phylogeny_of_the_procy.pdf
wird:
url=http://si-pddr.si.edu/dspace/bitstream/10088/6026/1/Koepfli 2007phylogeny of the procy.pdf Gruß --RonMeier (Diskussion) 15:48, 25. Jul. 2012 (CEST)Beantworten
Wird seltsamerweise mit einer Wiki-Bilddatei verwechselt, wegen .pdf – aber warum nur dieser? Solche URL gibt es doch am Meter? Wird sich finden lassen. --PerfektesChaos00:02, 1. Aug. 2012 (CEST)Beantworten
Zwar war dort ein Verhinderer für URL eingebaut gewesen, aber der Bindestrich in si-pddr.si.edu hatte den schlumpfigen Verhinderer geknackt. Inzwischen durch einen viel simpleren Verhinderer ersetzt, weil schon längst bekannt ist, dass es sich um eine geschützte URL handelt, und keine weitere Analyse betreffend Wiki-Dateilink mehr erforderlich; wenn dann nicht Wiki-Dateilink sein kann, brauchen auch keine Unterstreichungsstriche mehr ersetzt zu werden. Live. --PerfektesChaos20:41, 1. Aug. 2012 (CEST)Beantworten
Ja, siehe eins drunter: Die Programmierung auf meiner Festplatte hat den Fehler berichtigt (ich hatte irrtümlich zwischendurch angenommen, man könnte den letzten Parameter der Liste zur Beschleunigung ignorieren, und musste das ob dieser Erkenntnis hier zurücknehmen). Das habe ich aber noch nicht hochgeladen, weil in den 9327 Zeilen dieses Moduls auch noch mehrere andere Veränderungen enthalten sind, die noch nicht intensiver ausgetestet wurden.
Letzter Kommentar: vor 11 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Inwieweit ich mit der Änderung an meiner Konfiguration da etwas verpfuscht habe, weiß ich nicht, aber dein Skript will jetzt bei mir entweder kommentarlos nichts ändern, oder spuckt den folgenden Fehler aus:
Fehler: this.trsl is undefined
Quelldatei: https://en.wikipedia.org/w/index.php?action=raw&ctype=text/javascript&title=User:PerfektesChaos/js/WikiSyntaxTextMod/rM.js&503344441
Zeile: 358
Das könnte ein Reihenfolge-Asynchron-Fehler aus. Modul M wird schon geladen und ausgeführt, bevor L das trsl gebaut hatte oder sowas.
Dem lässt sich aber abhelfen. Wobei mir das Zustandekommen grad rätselhaft ist.
Offensichtlich ist in den neu eingefügten Ersetzungsausdrücken ein Syntaxfehler. Das Skript möchte ihn dir mitteilen und das in menschliche Sprache übersetzen (trsl). Ich verstehe nur nicht, warum bereits ausgeführt wird, bevor L das Laden abgeschlossen hat. Möglicherweise ist auch das this ein anderes als zu erwarten wäre; aber es gibt eigentlich nur normale Aufrufkontexte.
Letzter Kommentar: vor 11 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Da es oben untergegangen ist: Bei Stephan Koren (Manager) bekomme ich beim Bearbeiten des ganzen Artikels sowie beim Abschnitt Einzelnachweise (auch wenn ich meine Konfiguration entferne) einen leeren Diff angezeigt, in dem noch nicht einmal unsichtbare Zeichen geändert wurden. --Schnark09:42, 1. Aug. 2012 (CEST)Beantworten
Die ISBN wurde am 21. Juli von RonMeier gefixt; es gibt nichts mehr zu tun. Die momentane Version hat einen Zeilenumbruch ganz am Ende; irgendwas entschließt sich, überflüssige Zeilenumbrüche nach PD herauszunehmen. Diff verweigert deren Anzeige (ist bekannt). Wiedervorlage nach dem Endsieg. --PerfektesChaos20:41, 1. Aug. 2012 (CEST)Beantworten
Es brauchte auch einen leckeren Sonntagsbraten, kühles Wetter und ein entspanntes Wochenende.
Kurz gesagt: Bei der Analyse des Vorlagenwertes wurde einerseits das Gleichheitszeichen im <ref name= gefunden. Damit sah es so aus, als ob das gesamte Zitat bis zu <ref name der Name des ersten Vorlagenparameters wäre, und das ab "autobio" sei der Wert dieses ersten Vorlagenparameters. Andererseits können die Namen von Vorlagenparametern keine Zeilenumbrüche enthalten, was ihn dann wieder einen letzten Zeilenbrösel als Direkt-Wert eines scheinbar unbenannten Vorlagenparameter ausgeben ließ, von völliger Konfusion geschmissen.
Das kann eigentlich nur Anwender betreffen, die mit benutzerdefinierter Vorlagenersetzung arbeiten, und schien mir deshalb auch nicht besonders dringend. Weil dies schon seit drei Wochen unbeanstandet durchging, kommt mir die Verstümmelungsgefahr nicht sehr groß vor und ich möchte gern noch einen Tag durch die Testverfahren laufen, bevor ich diesen Fix live stelle.
Es wäre dann der letzte mir bekannte Bug abgearbeitet; wenn es jetzt eine Woche ohne Fehlermeldungen bleibt, wird WSTM.5 für alle Altbenutzer von WSTM.4 geschaltet.
Das Skript ist für den internationalen Einsatz geschrieben und liegt komplett in der enWP; alle produktiven Teile ausschließlich dort.
Um deinen Browser-Cache auszutricksen und weil die Wiki-Software das leider (noch) nicht für Benutzerskripte macht, wird an die URL jedes einzubindenden Teilskripts die Versionsnummer drangehängt, gewissermaßen als Dummy. Für die Standardsoftware der Projekte, die registrierten Helferlein und das eigene Standard-Benutzerskript passiert das immerhin schon in analoger Weise, so dass aus dem Browser-Cache immer die gültige Version eingebunden wird.
Die Versionsnummer bekomme ich automatisiert über eine API-Abfrage, mit der eine Info-Seite aktuell gehalten wird. Leider hinkt die API-Datenbasis hin und wieder teilweise um Stunden hinter der echten Datenbank hinterher; meist aber weniger als 20 Sekunden.
Mit jeder vollen Stunde schaut sich das Skript erneut an, welche Versionsnummern auf der Info-Seite stehen, und schreibt die Nummern in ein Cookie bei dir auf den Rechner. Damit ist gewährleistet, dass die bei dir ausgeführte Skriptversion immer maximal zwei Stunden alt sein sollte.
In den ersten beiden Fällen ist der Interwiki-Präfix in der Darstellung sichtbar; dann belasse ich ihn wie vorgefunden.
Im dritten Fall ist nur b sichtbar; dann standardisiere ich Groß- und Kleinschreibung auf die UpperCamelCase-Notation von 2011; etwa „Tools“ oder „OldWikisource“. Auf Spezial:Interwikitabelle sind nun neuerdings alle kleingeschrieben; aber darauf gedenke ich zu pfeifen.
Ansonsten sind die Präfixe freundlicherweise Käse-unsensibel; es hat also keinerlei Einfluss auf die Funktionalität. Dafür nehme ich in allen drei Fällen Leerzeichen nach dem Doppelpunkt heraus, während dies bei CSI: Miami unterbleibt (seufz).
Benutzerdefinierte Kleinschreibung müsste gehen; Pseudo-Interwikis werden relativ frisch in einem eigenen Zweig verarbeitet. Nach Abschluss der aktuellen Bugfixe schaue ich dort mal nach. Die Aufforderung kannst du schon mal stehen lassen, selbst wenn sie im Moment wirkungslos bleiben sollte. Ich weiß auch nicht so genau, ob es besser „Bugzilla:“ oder „bugzilla:“ heißen sollte.
Völlig richtig; bei der kürzlich erfolgten Aufteilung von .link in .wikilink und .url hatte ich pauschal Suchen+Ersetzen betrieben.
Raymond bevorzugt laut WP:NEU bei bugzilla: und gerrit: im Gegensatz zu mir die Großschreibung, während bei tools: laut Wikipedia:Helferlein und Benutzer:Inkowik/Tools die Mehrheit ebenso wie ich für Kleinschreibung ist.
Versucht hatte ich unter anderem mw.libs.WikiSyntaxTextMod.config.mod.wikilink=[[[false,'tools:(.*)','\\|'],[false,'tools:$1',false]]];, es kam aber zu keiner Ersetzung. --Schnark10:30, 1. Aug. 2012 (CEST)Beantworten
Ich hatte bei dir gesucht, aber nichts in dieser Richtung gefunden. Wolltest du das erste 'tools' nicht groß schreiben?
Momentan steht allerdings der ANR im Fokus meiner Testerei; tools sind eher auf Meta-Seiten zugange, BNR oder HNR oder WP. Erprobt habe ich auf dieser Schiene noch nicht viel. --PerfektesChaos20:41, 1. Aug. 2012 (CEST)Beantworten
Ich hatte meine Konfiguration temporär per FireBug geändert, deshalb kannst du nichts sehen. mw.libs.WikiSyntaxTextMod.config.mod.wikilink=[["^T(ools:.*)$","t$1"]]; belehrt mich aber nur:
this.wikilink.concat.concat is not a function
https://en.wikipedia.org/w/index.php?action=raw&ctype=text/javascript&title=User:PerfektesChaos/js/WikiSyntaxTextMod/rM.js&505137116
Line 513
Vielleicht sehe ich vor lauter eckigen Klammern das Array nicht, aber irgendwie bekomme ich das nicht auf die Reihe. Lass dir ruhig Zeit dabei, die nächsten Wochen bin ich ohnehin nicht online. --Schnark09:32, 2. Aug. 2012 (CEST)Beantworten
</syntaxhighlight>
nichts bringt, da der Bereich geschützt ist. Spricht etwas dagegen, diese Übersetzung zwangsweise durchzuführen, falls nicht so ein Spezialfall wie hier vorliegt? --Schnark09:46, 1. Aug. 2012 (CEST)Beantworten
Der steht schon länger auf meiner ToDo-Liste und kommt irgendwann von Amts wegen:
dann setze Beginn- und End-Tag in syntaxhighlight um.
Du kannst daran nichts machen, weil von <s bis /source> vollgeschützter Bereich, wie du dir schon gedacht hattest. Siehe dazu auch hier Anm. 1.
Nebenbei kannst du eigentlich deine ganzen \\b und \\s* in den tag-Ausdrücken durch simple Leerzeichen ersetzen, wo sie vor Attributnamen stehen; sofern dort kein \n gefunden wird, setze ich jeglichen Whitespace in exakt ein ASCII-Leerzeichen um, oder nix wo keines angebracht. Um die Gleichheitszeichen herum gibt es zumindest keinerlei Leerzeichen.
\\b durch Leerzeichen ersetzen geht nicht, wenn, dann müsste es [ >] etc. sein.
Wenn Tidy funktioniert, dann funktioniert es, das ist richtig. Wenn es nicht funktioniert (warum auch immer, und das passiert eben in letzter Zeit häufiger), dann kommt das <div /> direkt in die HTML-Ausgabe, und wird dort dann als <div> interpretiert, was zu wunderhübschen falschen Verschachtelungen führt. --Schnark09:42, 2. Aug. 2012 (CEST)Beantworten
Ich zitiere mich mal: „\\b … durch … Leerzeichen ersetzen, wo sie vor Attributnamen stehen“.
Da sollte man eher tidy reparieren statt -zigtausende von Wikitexten den temporären Launen von tidy anzupassen. Gibt es denn einen Kontext, in dem tidy nachvollziehbar spinnt? Wenn inmitten einer Tabelle ein <div /> auftaucht, könnte ich mir Irritationen vorstellen. Auf Content-Top-Level zwischen <p> sollte das hingegen klappen. Ist das reproduzierbar? Gibt es Rahmenbedingungen?
Vor den Attributnamen geht es erst recht nicht, da kann alles mögliche – insbesondere sämtliche Tabellensyntax – davorstehen, dort fügt dein Skript nämlich keine Leerzeichen ein, wie ich gerade an
a
getestet habe.
Abgesehen von der Tatsache, dass Tidy ohnehin gerne Unsinn macht (auf die Schnelle: bugzilla:38800, bugzilla:38661), wird es halt manchmal ohne erkennbaren Grund überhaupt nicht ausgeführt: bugzilla:38273. Wenn es nach mir ginge, dann würden wir Tidy einfach komplett abschalten und anfangen, unsere Texte in korrekter Syntax zu schreiben. Dass <div /> kein gültiges HTML ist und damit zu Problemen führt, ist keine Laune von Tidy, sondern einfach eine Tatsache. --Schnark11:05, 2. Aug. 2012 (CEST)Beantworten
Okay, dann schaue ich mal tiefer auf meine ToDo-Liste:
Der Attribut-Mechanismus ist als allgemeine Funktion geschrieben, wird aber zurzeit nur innerhalb von tags als <…> aufgerufen. Gleichwohl ist vorgesehen, dass diese auf \n(:+ *)?\{\| * und \n\|-+ * sinngemäß angewendet werden soll – nachdem WSTM.5 robust läuft und die noch nicht umgestellten Kopfmodule WSTM.4→WSTM.5 vollzogen wurden; das wird also eher nicht vor September live gehen.
Der Blick auf HTML5 (wie schon HTML4) gibt dir recht; ich werde demnächst alle unary div mit endtag darstellen (wobei XHTML nach meinem Verständnis unary akzeptieren würde, aber das wird mir jetzt zu philosophisch). Besser als BR clear= bin ich schon mal.
Zunächst muss ich zwei bekannte Böcke erlegen, die eher Text-Schäden verursachen könnten, und zu einer über eine Woche hinweg unbeanstandeten Version von WSTM.5 kommen. Erst ausgehend von einer robusten Version kann ich experimentieren.
1 bug gefixt; weil dabei ohnehin im tag-Bereich, 3 neue Features live:
Situation <div /> wird immer überführt in <div … ></div>
source → syntaxhighlight
Gesamt-Tabelle und Tabellenzeile werden der Attributsyntax zugeführt.
Tidy dürfte seit der Umstellung auf HTML5 ins Schlingern geraten zu sein.
@ Bugzilla:38273#c14<br clear= /> usw. wird durch WSTM (schon seit 3) in <div… umgewandelt.
Tidy einfach komplett abschalten und anfangen, unsere Texte in korrekter Syntax zu schreiben – der war gut! Allerdings geht es nicht nach uns beiden. Ich wäre dabei für das Schreiben der Wikiprojekte in HTML und nicht in Wikisyntax; entsprechende Editoren natürlich vorausgesetzt.
Letzter Kommentar: vor 11 Jahren5 Kommentare3 Personen sind an der Diskussion beteiligt
So, wer es noch nicht mitbekommen hatte: Das watchlist-Häkchen dieser Seite war mir runtergefallen, deshalb hatte ich mich bis gestern nachmittag gefreut, dass alles beschwerdefrei läuft und der Rest der Anwender wohl im Urlaub ist. Somit hatte ich ein paar nette Tage und einiges von meiner ToDo-Liste aufgearbeitet, und viel Sonne und frische Luft.
Seitdem habe ich die in den letzten zehn Tagen aufgelaufenen Böcke bis auf einen schwierigeren Kandidaten (Cursus Sacro-harmonicus) aufgearbeitet und kursorisch die Gesamtfunktion versucht durchzutesten. Dies jetzt live; wer es eilig hat, müsste Cache leeren, die enWP hat gegenüber ihrer API ein replag>1h.
Dass die Sache mit den Vorlagen herb wird, wusste ich vorher. Dass ich ein Vierteljahr am Fixen von Vorlagen-Syntax-Austrickserei sitzen würde, hätte ich allerdings nicht gedacht. Schönen Abend allerseits --PerfektesChaos20:41, 1. Aug. 2012 (CEST)Beantworten
Mittlerweile kann ich auch nachvollziehen, was diese Seite von der Beo geschmissen hat: Wenn man unerklärlicherweise beim Editieren plötzlich nicht mehr angemeldet ist, wird man in hellblau gefragt, ob man als IP speichern möchte. Das Beo-Sternchen ist dann futsch. Meldet man sich neu an und betätigt die Vorschau, um wieder Sitzungsdaten und Token zu bekommen, bleibt das Beo-Sternchen leer, das Häkchen fehlt und beim Speichern würde die Seite nicht mehr beobachtet. So gestern Abend geschehen, und vor zwei Wochen wohl auch häufiger. --PerfektesChaos10:56, 2. Aug. 2012 (CEST)Beantworten
Auch von mir vielen Dank für das so nützliche Skript. Was ich nicht verstehe: die Fehlermeldung, wenn die SORTIERUNG gleich dem Lemma ist. Die Angabe ist m. E. sehr sinnvoll, denn das heißt, dass jemand sich Gedanken über die Sortierung gemacht hat und diese dann so festgelegt hat. Wenn das ganze fehlt, kommen ja wieder garantiert irgendwelche Leute, die isländische Namen in Nachname, Vorname umsortieren, Ehrentitel wie Pascha zu Nachnamen machen usw. Kurz gesagt: Ich halte das für keinen Syntax-Fehler, sondern einen inhaltlichen Mehrwert, der auch vor Verschlimmbesserungen schützt. --FA2010 (Diskussion) 13:31, 7. Aug. 2012 (CEST)Beantworten
Danke für deine freundlichen Worte.
Zu deiner Anmerkung:
Es ist ja nur eine Warnung; die SORTIERUNG bleibt ja stehen und wird nicht entfernt; fortgeschrittene Bearbeiter werden zur Überprüfung aufgefordert.
Ob sich da wirklich jemand Gedanken gemacht hat, wäre eine im Einzelfall zu beantwortende Frage. Das Skript ist über mehrere Jahre anhand vieler Fehler in Artikeln entstanden.
Es kann im Einzelfall berechtigt sein (isländischer Name); dann sollte hinter SORTIERUNG ein Kommentar stehen, damit weniger kundige Mit-Autoren informiert sind und es nicht versehentlich ändern. Noch besser: Die ganze SORTIERUNG kann gleich durch diesen Kommentar ersetzt werden; technisch ist es überflüssig und kann entfernt werden.
Es kann schlicht Unfug sein; ein Newcomer hat gesehen, dass im Artikel über Nürnberg eine SORTIERUNG steht und meint, im Artikel über Augsburg müsse es dann aber auch so gemacht werden.
Man kann beabsichtigt haben, einen erforderlichen Sortierschlüssel anzugeben, hatte auch schon das Lemma dorthin kopiert, hat dann aber vergessen, es umzustellen; im Artikel über Petra Meier steht jetzt {{SORTIERUNG:Petra Meier}} – genau deshalb auch die Warnung.
Veraltet ist die Projektseite nicht gerade, aber etwas überängstlich. Es gab wohl auch immer mal wieder Diskussionen um diese Fragestellung.
Das Skript entscheidet nach einigen komplexen Regeln abhängig von den weiteren Parametern, ob es drinlässt oder herausnimmt.
In der langjährigen Praxis hat sich gezeigt, dass der befürchtete Verschiebungsfall dann doch relativ selten vorkommt; Hamburg und Berlin sind in der deWP wie auch auf Commons immer noch an der gleichen Stelle zu finden. In den Anfangsjahren und vor festgezurrter Ausarbeitung der Namenskonventionen gab es öfter mal Verschiebungen; inzwischen kann man sagen, dass ein Artikel, zu dem es unter identischem (also meist deutschsprachigem) Namen auch einen Commons-Eintrag gibt, weder hier noch da hinterher großartig herumgeschubst wird.
Für Köln reicht also simples {{Commons}} usw. – ich beobachte veränderte Seiten und reagiere auf Beschwerden. Du bist seit mehr als einem Jahr der erste, der überhaupt nachfragt; eine Beschwerde, dass das Skript nach einer Artikelverschiebung böse Mehrarbeit verursacht hätte, lief noch nie auf.
Was Abraham Lincoln angeht, glaube ich nicht, dass der Artikel jemals verschoben würde nach Abraham Lincoln (US-Präsident).
Letzter Kommentar: vor 11 Jahren5 Kommentare2 Personen sind an der Diskussion beteiligt
WikiSyntaxTextMod ersetzt im Abschnitt Einzelnachweise in sinnlosen, leeren <references> </references>-Konstrukten den schliessenden Tag durch <references />, lässt aber den ersten stehen. Um daraufhin einen schweren Fehler zu finden. In Oskar-Heinrich Bär: "Tag selbst-verschachtelt: <references>", dito in Andreas Cratander. Irgendwann hatte ich als Meldung auch mal bekommen:
Tag selbst-verschachtelt: <references>
End-Tag fehlt zum Ende des Textes: </references>
Die kann ich leider nicht mehr reproduzieren, entweder war das ein weiterer Artikel oder es hat sich inzwischen etwas geändert. Zugegebenermaßen ist <references> </references> ohne benannte Referenzen darin sinnlos, schadet aber nicht. Ist die Fehlermeldung Deine Methode uns zu sagen, wir sollen selbst entscheiden, ob das weg soll? --IvlaDisk.17:00, 7. Aug. 2012 (CEST)Beantworten
Nein, das soll nicht sein, und lief bislang korrekt. Am Sonntag gab es in dieser Thematik eine Änderung; möglicherweise hatte sie einen unbeabsichtigten Nebeneffekt. Es soll aus dem leeren binary ein unary werden.
Konzentrier Dich nicht zu sehr (allein) auf die Änderung letzten Sonntag, meine Bearbeitungsversuche (als Half-Bot) waren beide deutlich länger her, ich hatte in Textdatei mitgeschrieben und dann nicht gleich gemeldet. Sorry, die musste ich erst mal aufräumen. Hier gemeldete Fehler kontrolliere ich aber vorher, ob sich das Verhalten geändert hat, auch ob sie ebenfalls auftreten, wenn ich die Bearbeitung des Artikels nicht via Schnarks normdaten.js starte. Ebenfalls Zwischengruß, --IvlaDisk.19:19, 7. Aug. 2012 (CEST)Beantworten
Ich habe jetzt erst mal einen behelfsmäßigen Flicken draufgesetzt, damit die Syntax funktional bleibt; ein eingefügter Zeilenumbruch schadet nicht.
Die letzte Änderung gab es vor sechs bis acht Wochen; es hatte sich in der Erprobung nie jemand beschwert.
Während alle leeren binary-Elemente erstmal routinemäßig in kürzeres unary umgewandelt werden, schlug mitten in diesem Prozess die references-Analyse (und nur diese) zu und nahm das öffnende <references> in Beschlag, um nun den Inhalt zu analysieren. Dadurch war es für die Umwandlung in unary nicht mehr verfügbar.
Ich werde bald die Handhabung abändern, muss mich aber erstmal in mein eigenes Zeugs einlesen. Programmiert wurde es vor über einem Vierteljahr, ich weiß nichts mehr. Zwar würden in der Vorschau EN-Fehler auch schon rot hervorgehoben; ich bekomme aber die meisten davon ohnehin mit und kann in der roten Kiste am Anfang auf deren Existenz hinweisen. Außerdem gibt es Verschachtelungs- und Inhaltsfehler; references, ref, imagemap und gallery etwa können nicht ineinander selbst auftauchen; imagemap und gallery müssen einen Inhalt haben, sonst hat entweder jemand vergessen Inhalte einzubringen oder beim Löschen Trümmer übriggelassen.
Der Flicken funktioniert, soweit ich sehen konnte, danke.
Die Fälle sind eher selten, vielleicht ist das bei den anderen in der Zeit einfach nicht aufgetreten.
binary/unary: Nach Lesen Deines Links oben jetzt auch verstanden.
EN-Fehler in der Vorschau werden zwar rot hervorgehoben, IIRC aber dort wo sie auftreten (innerhalb der Nachweise) und dann gern mal über mehrere Bearbeitungen hinweg übersehen. Gedächtnis: Ich habe bei einer Bearbeitung der letzten Tage nach Beispielen für die Formatierung einer Literaturangabe gesucht, bin dabei via ISBN-Suche auf eine einzige Verwendung der BibISBN-Vorlage gestoßen und habe erst via Versionsgeschichten gesehen, dass ich Artikel und Vorlage im Januar bearbeitet hatte.
Letzter Kommentar: vor 11 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
In Karl Jaberg wird <!-- schweizbezogen -->'''Karl Jaberg''' geändert auf <!--schweizbezogen-->''Karl Jaberg''', d.h. ein ' geht verloren.
In Jakob Jud wird der folgende Text hinter schweizbezogen in die erste Zeile gezogen, Diff:
Weiteres Beispiel dafür ist Alfred Labhardt. Ist das Absicht? Da geht zwar nichts kaputt, aber schweizbezogen kann IMHO ruhig in eine eigene Zeile, ähnlich wie Normdaten etc. Zuerst dachte ich auch, die Leerzeichen an Anfang und Ende im Kommentar sollten lieber bleiben, habe aber inzwischen WP:Schweizbezogen und WP:Österreichbezogen (wieder)gefunden, wo es ohne Leerzeichen gezeigt wird. Gruß, --IvlaDisk.18:02, 7. Aug. 2012 (CEST)Beantworten
Mindestens soll nichts geklaut werden.
Absicht ist, dass
in die kompakte Form transformiert werden soll, weil jemand, der ein weniger schlaues Skript schreibt, womöglich nur nach der Form ohne Leerzeichen sucht. Deshalb die Veränderung. Übrigens wird auch beliebige Großschreibung in die auf den Projektseiten gezeigte Kleinschreibung transformiert.
Zeilenumbruch irgendwann einmal automatisch eingefügt wird; zur besseren Erkennbarkeit am Artikelanfang, grad wenn daneben in der gleichen Zeile auch noch eine Infobox oder ein Bildchen eingebunden würde. Das steht aber nur irgendwo unten auf der ToDo-Liste.
Übrigens wäre der Umstand, dass solche Hinweise im Artikeltext gefunden wurden, sogar vom Skriptbenutzer in benutzerdefinierten Funktionen auswertbar; sie werden an bestimten Stellen nachlesbar abgelegt.
Tatsache ist, dass sich das Skript im Änderungsfall (Kürzung um zwei Leerzeichen) schlicht um eins verzählt. Fix im Laufe des Abends, live bis morgen.
Eigentlich wollte ich mit BBKL und seinen Parametern prahlen und prunken, aber das verkneife ich mir jetzt einen Tag.
Aktualisierungsprozess schleicht automatisch; bei besonderer Eile heftige Cache-Löschung.
Mein Plan geht dahin, den vorgefundenen Kommentar Ösi/schw einfach einmal aus dem Wikitext zu entfernen und danach mit Zeilenumbruch dem Wikitext wieder voranzustellen, dessen führende Zeilenumbrüche zuvor entfernt werden. Wo immer das vorher gestanden haben mag, befindet es sich anschließend immer gut sichtbar als separate Zeile vor dem Wikitext.
Letzter Kommentar: vor 11 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Meldung:
"
Nicht alles lässt sich automatisch beheben. Bitte kläre die folgenden Probleme von Hand:
ISBN falsch (zu viele Ziffern [a]): 978-3-89735-445-6. 1
"
Tatsächlich steht im Text: "ISBN 978-3-89735-445-6. 152 S. mit 43 Abb., fester Einband." Reichen der Punkt u. das Leerzeichen nicht, um die ISBN für beendet zu halten? Mal abgesehen davon, dass das da wohl nicht ganz den Regeln für Literaturangaben entspricht und wg. Erscheinungsjahr noch ISBN-10 anzugeben wäre.
Übrigens wird direkt darunter whitespace entfernt, es bleibt aber nicht ein, sondern zwei Leerzeichen stehen.
Wo holt das Skript sich übrigens die Informationen, wie eine (ansonsten korrekte) ISBN zu formatieren ist, also die Position der Bindestriche für Land u. Verlag? In corr#ISBN steht das nicht. Funktioniert jedenfalls ausgezeichnet, ich habe bisher immer überprüft u. nie einen Fehler gefunden. Gruß, --Half-Bot (Diskussion) 17:02, 8. Aug. 2012 (CEST)Beantworten
Das Skript geht davon aus, dass Benutzer unerwünschte Mittel zur Gliederung der ISBN einsetzen, darunter Leerzeichen, Punkte, Bis-Strich, Minuszeichen und noch etliche Strichcodes mehr. Wenn sich daraus eine gültige ISBN ergibt, wird sie ggf. normgerecht umformatiert. Dementsprechend ist sich das Skript aber nicht ganz sicher, wenn unmittelbar anschließend noch andere Ziffern auftreten, und befürchtet Schreibfehler. Die menschliche Interpretation des Bildes ist nicht möglich. Weil aber im konkreten Fall mindestens in der deWP die genannte Formatierung ohnehin nicht WP:LIT entspricht, wäre hier eine Aufhübschung angesagt. Ein Komma hinter der ISBN beendet beispielsweise die Untersuchung, und der feste Einband weist auf WP-Laien-hafte Übernahme aus Verlagsprospekt oder von amazon hin; eigentlich sind diese Angaben redundant.
Die Definition steht auf en:User:PerfektesChaos/js/WikiSyntaxTextMod/dU.js (einfach in die Mitte der Seite scrollen, wenn nur Zahlensalat dann ISBN). Die Daten wurden zuletzt März 2011 aus den offiziellen ISBN-Unterlagen übernommen (weblink); gelegentlich schaue ich, ob es einen Aktualisierungshinweis gibt bzw. bilde eine Differenz.
Das mit dem Leerzeichen bezieht sich vermutlich auf „Münchener Studien“. An dieser Stelle stand zuvor im Wikitext ein Tabulatorzeichen (ASCII=9), welches vom Skript in ein Leerzeichen ASCII=32 umgewandelt wurde. Tabulatorzeichen erscheinen in der optischen Textdarstellung null bis acht Zeichen breit; je nach Gegebenheiten des Browser/Editors. Für HTML sind aber Zeilenumbrüche, beliebig viele Leerzeichen und Tabulatorzeichen alle gleich breit: genau ein Leerzeichen im Fließtext.
Das Skript unterhält eine Liste aller Variablen sowohl in der englischen wie auch in der eingedeutschten Version, um genau das zu verhindern. Irgendwie hat der Verhinderer hier nicht gegriffen; ich schau gleich mal und in einigen Stunden wird das auch nicht mehr passieren. Hier wurde es für den in der Syntax identischen Namen einer Vorlage gehalten und dementsprechend der Unterstreichungsstrich entfernt.
Lass den Artikel mal bitte bis morgen so stehen; danach kannst du testen.
Wie du beim zweiten Blick bereits gemerkt hattest, kann der Strich nicht einfach weggelassen werden.
Er beeinflusst die Zählung aller nachfolgenden unbenannten Parameter.
An dieser Stelle könnten ursprüngliche Autoren der Einbindung die Angabe eines Wertes beabsichtigt und das dann auch wieder vergessen haben.
Auch wenn im Moment grad kein weiterer unbenannter Parameter folgt, kann in irgendeiner Vorlagensystematik beabsichtigt sein, hier etwas hinzuzufügen.
Das Skript fügt die 1= usw. ein, wenn auf einen benannten Parameter ein unbenannter Parameter folgt.
Nebenbei ist das eine grässliche Unsitte, die sich gleichwohl in einigen Kopiervorlagen findet. Die Maschine kommt damit klar, bloß Menschen werden so ausgetrickst.
Falls bei einem |URL=| das Gleichheitszeichen abhandenkommt, wird aus URL ein unbenannter Parameterwert. Das Skript fügt nun die Nummer davor ein und macht es in der diffpage und für die Bearbeiter deutlicher.
Vorlage Normdaten:
Ich werde hier gelegentlich die Programmierung weiterentwickeln.
Ein unbenannter Parameter ist nicht definiert, könnte aber durch Schreibfehler entstehen. Bei sechsstelliger Zahl von Einbindungen kommt das hin und wieder vor.
Wenn dort TYP= vergessen wird oder GND= fehlt, so entsteht hintendran ein |1=k oder |1=1234567 als unbenannter Parameter. Das fällt den Kundigen zumindest in der Diffpage auf. Weglassen darf ich unbenannte Parameter also nicht. Menschliche Bearbeiter müssen die Bedeutung auseinanderfieseln.
Richtig ist, dass hier ein unbenannter Parameter ohne Inhalt gefahrlos entfernt werden kann. Passiert demnächst.Du darfst dann gern die anderen 5 Fälle abklappern und automatisiert fixen.
Es gab kürzlich eine Änderung, die eine unerwartete Nebenwirkung hatte und die ich gerade erforsche. Auf mir momentan unerklärliche Weise strahlt das <references> vom Seitenende (EN) nach oben aus. An der Beseitigung wird gearbeitet; heute Abend sollte es wieder laufen. Bitte einfach diese Seiten bis dahin zurückstellen.
Dafür wird inzwischen der leere | aus den Normdaten entfernt.
Ich habe erstmal einen Flicken draufgepappt und den Unsinn verhindert. Ein sensibles Schalterchen hat einen Dätscher abbekommen und klemmt; was sich genau wo zugetragen hatte, weiß ich noch nicht ganz genau. Durch massive Cache-Löschung oder beim 2. Edit nach 18:00 ist erstmal Ruhe. Weiter geht’s. --PerfektesChaos17:27, 14. Aug. 2012 (CEST)Beantworten
Letzter Kommentar: vor 11 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo,
nachdem das Skript bei mir bei keinem Artikel mehr anspringen wollte habe ich zunächste in meiner vector.js (weil ich da was geändert hatte, allerdings nicht in der Ecke) nachgesehen. Dort nichts gefunden, bei meinem Account Half-Bot läuft es ebenfalls nicht. Firebug:
SyntaxError: missing } after function body
Eine Änderung im Skript hattest Du heute ja gemacht. Schönen Gruß, u. in den restlichen Abschnitten antworte ich auch noch mal, ich hänge etwas hinterher. --IvlaDisk.20:05, 14. Aug. 2012 (CEST)Beantworten
Sorry for trouble.
Ich hatte eine Schnellschuss-Änderung aufgespielt, weil die references-Aktion von neulich unter bestimmten Umständen Unsinn verursacht; ich werde eine kühle Nacht brauchen, um auch diese Fälle sauber umzuschreiben.
Spätestens nach kräftiger Cache-Leerung sollte das Skript jetzt wieder anspringen. Meine Entwickler-Version läuft von der Festplatte, und ich bekomme bei außerplanmäßigen Änderungen nicht mit, wenn dabei auf dem Webserver ein Fehler entsteht.
In den nächsten Tagen sollte das dann aber endlich wieder rundherum sauber gehen; einstweilen danke für den Hinweis, vor allem für die Firebug-Info (außerordentlich wertvoll für mich) --PerfektesChaos21:11, 14. Aug. 2012 (CEST)Beantworten
Läuft wieder, danke. Die Firebug-Info sagt doch nicht mehr, als dass irgendwo eine schließende Klammer fehlt, dass finde ich bei längeren Skripten ja erstmal nicht soo hilfreich. Das "irgendwo" hier noch eingegrenzt durch "function body", verbunden mit letzter Skriptzeile? Im Diff war Zeile 821 bzw. 822 ja schnell gefunden. Eher verwirrend finde ich, dass an dem Link der Firebug-Meldung hinten die 506789510 ist, das ist doch die ID der Version vom 10. August, die den Fehler noch nicht hatte.
Kühle Nächte wie hier allein reichen offenbar noch nicht. Und bevor ich das wieder vergesse: Was bedeutet Portalseite auf usage#Link_auf_der_Portalseite? Ich komm auch im dritten Anlauf nicht drauf. Welche Portalseite? Ich habe es eingebunden, nach einem schlecht überlegten Fehlversuch auch richtig, und es ist da, wo die anderen Portlet-Links auch sind, z.B. die über Gadgets eingebundenen. Gruß, IvlaDisk.23:45, 14. Aug. 2012 (CEST)Beantworten
Die Firebug-Info gern regelmäßig angeben. Mir sagt sie schon mal, dass es einen Syntaxfehler gibt; welchen, finde ich notfalls selber. Das hilft mir deutlich mehr als: „Bei mir geht nichts!“ – das kann 1000 Gründe haben.
Weil das bei mir unkomprimiert problemlos von Festplatte lief, war mir auf Anhieb klar, dass die Ursache die behelfsmäßige Auskommentierung am frühen Abend gewesen sein musste. Bei der ging eine schließende Klammer mit verloren, die von meinem Minimierer in den unstatthaften Kommentar gezogen wurde. Selbst arbeite ich aber normalerweise nicht mit einer minimierten Version, außer zu planmäßigen systematischen Erprobungen.
Diese Nummer „506789510“ sagt nichts über die tatsächlich laufende Version; es könnte auch eine Zufallszahl sein oder der tagesaktuelle Heiligenname. Es soll nur irgendeine abweichende Zeichenkette sein, mit der eine unterschiedliche URL gebildet wird, damit dein Browser die Version nicht aus dem Cache nimmt, sondern neu vom Server abrufen muss.
Die Nummer kommt von der enWP und wird normalerweise automatisch bereitgestellt. Dummerweise spinnt die enWP zurzeit und liegt mit der API-Auskunft teilweise einen Tag hinter den tatsächlichen Änderungsdaten der Seiten zurück; deshalb habe ich zur Beschleunigung heute die kurzen Versionsnummern manuell eingetragen und die Automatik abgeschaltet. Die Liste dort wird von deinem Browser zu jeder vollen Stunde frisch abgerufen und die notwendigen Nummern werden in einem Cookie gespeichert.
Das eigentliche heute bemerkte Problem mit den references ist vermutlich inzwischen gefixt; es fehlte noch ein m++; an der richtigen Stelle. Ich bin aber zu müde, um eine Freigabe zu verantworten und werde morgen, äh, nachher testen; upload hat vermutlich einige Tage Zeit.
Die Portalseite guckst du dir grad an; es ist das „Wiki-Portal“, wie auf WP:GUI #Skins bunt dargestellt. Wenn ich wach bin, werde ich überlegen, ob ich meine Doku hier klarer formulieren kann. Gebaut wird das Link von WP:GUI #addPortletLink; portlet ist wikispeak für die kleinen Krimskrams-Elemente auf der „Portalseite“.
Dabei hatte ich gerade erst gestern WSTM.5 für alle Anwender geschaltet, weil eine Woche lang keine Beschwerden mehr aufliefen … seufz.
Der aktuelle Bug kann nur Benutzer betreffen, die benutzerdefinierte Text-Ersetzungen vornehmen. Das sind ziemlich wenige.
Wobei es mich fast noch mehr fuchst, dass das zweite Pipe-Symbol im Titel von wallfahrten|]] durch die Lappen ging. Muss ich bei der Gelegenheit analysieren und mindestens meckern; betrifft vermutlich nur das Ende des Titels oder so.
Der konkrete Fall hängt mit der vor drei Wochen eingeführten Tabellensyntax-Formatierung zusammen. Es wird nämlich außerdem bei |-wallfahrten|]] ein Leerzeichen nach dem Bindestrich eingefügt. Weil das vorangehende Linkziel „Wallfahrt“ wegen der von dir definierten Text-Ersetzungen als eigener Textblock geschützt ist, steht am Anfang eines Textblocks |-wallfahrten und das sieht aus wie eine Tabellenzeile. Hier fand sich auch ein Parameter name="kirschbaum1971,156" – und mit dem /> wusste das Skript dann so recht nichts mehr anzufangen. Der ganze restliche Absatz galt als Tabellenzeilen-Trennung.
Ganz am Anfang eines Artikels (Infobox) kann auch {| stehen; darauf war die bisherige Programmierung ausgelegt gewesen. Vor einem |- muss aber immer ein Zeilenumbruch kommen; in diesem Sinne habe ich das Skript bereits geändert.
Muss aber noch ausgetestet werden, zusammen mit einigen beabsichtigten weiteren kleinen Änderungen, und dem zweiten Pipe-Symbol. Vermutlich morgen live.
Ich plane für den Herbst die Neuprogrammierung der Bildeinbindungs-Analyse und -korrektur.
Vorrangig soll es darum gehen, den Bildtitel an die letzte Stelle der Parameter zu rücken; es müsste der einzige unbekannte Parameter sein. Gibt es zwei unidentifizierbare Parameter, ist einer davon ein Tippfehler (gern auch thump) und würde gemeldet.
Bis dahin werde ich HD:Bilder beobachten hinsichtlich der mini-Frage. Weil es auch nicht minature heißt, können damit sowohl die konsequenten Fichier-Franzosen leben wie auch die englischsprachigen Urväter; auch die schwedische miniatyr. Gern ändere ich dann den Zielwert um auf mini.
Zurzeit ignoriere ich noch alle nicht in der Doku benannten Parameterwerte ob ihrer ein- bis zweistelligen Einbindungszahl; sie sind mir aber durchaus bekannt.
Im Moment und wohl für die nächsten fünf Wochen läuft noch eine Migrationsphase auf die fundamental geänderte Skriptstruktur; in dieser Zeit möchte ich keine aufschiebbaren größeren Änderungen vornehmen und statt dessen den Sommer genießen.
Danke, verstehe. Immerhin schon mal 46. :-) Mal schauen, wie sich das weiter entwickelt, das mit dem Herbst klingt ja interessant, jetzt wo es erst mal etwas bekannter geworden ist. ;-) Wusste gar nicht, dass auch „thumbnail“ und noch andere Varianten gehen, schon wieder was gelernt heute. Und dass „thumbnail“ auch gleich noch relativ häufig vorkommt … ist mir wahrscheinlich noch gar nicht begegnet, erinnere mich jedenfalls nicht daran. Das finde ich jetzt tatsächlich erstaunlich. Damit haben aber dann bisher doch die nicht lokalisierten Varianten gegenüber den lokalisierten gewonnen, da man ja „thumbnail“ hinzurechnen muss. Aber vielleicht hat sich das im Herbst auch mal geändert, viel Unterschied ist es ja nicht mehr.
Und „grundlinie“, „hoch“, „tief“, „text-hoch“, „text-tief“, diese Varianten gibt’s auch erst seit Anfang April. Deshalb kann das noch nicht sehr verbreitet sein, hatte ich am 2. April im Translatewiki geändert, und dann benötigt es noch etwas, bis so was hier ankommt. Aber diese Spezialitäten werden eh so selten verwendet, dass sie mir vorher auch noch nie begegnet waren. Jedenfalls eine interessante Statistik, danke dafür. Dir ebenso was Kühles zur Belohnung :-) --Geitost00:07, 23. Aug. 2012 (CEST)Beantworten
Letzter Kommentar: vor 11 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo PefektesChaos, ich finde dein Skript sehr gut, würde aber gerne wissen, inwieweit die damit gemachten Änderungen Konsens sind. Vieles würde ich auch so machen, aber z. B. dieses Entfernen eines Zeilenumbruchs macht imho den Quelltext unübersichtlicher. Gibt es dazu irgendwo Regeln oder Empfehlungen? Steak10:39, 24. Aug. 2012 (CEST)Beantworten
Danke für das Lob.
Nur damit ich die richtige Frage beantworte: Du beziehst dich auf den Zeilenumbruch im Zusammenhang mit <br />?
Letzter Kommentar: vor 11 Jahren18 Kommentare3 Personen sind an der Diskussion beteiligt
Im Artikel Deutschland findet das Skript zwei Fehler, kann sie aber nicht beheben. Wäre es sinnvoll, eine zentrale Seite einzurichten, um solche Knacknüsse zu melden, damit sich die Experten darum kümmern können? Ich z. B. kann solche Fehler nicht selbst korrigieren. Steak10:41, 24. Aug. 2012 (CEST)Beantworten
Mittel der Wahl wäre die Disku des Artikels, auf die man die Fehlermeldung kopieren kann; sollen sich doch die anderen Autoren damit abquälen. Eine zentrale Seite gibt es eigentlich auch schon: FZW – wer von euch könnte hier helfen?
Zum konkreten Fall:
Vor der Überschrift „Liste der Länder“ steht ein einsames <noinclude> – weitere include-Versuche gibt es im Artikel nicht.
Es handelt sich vermutlich um einen C&P-Irrtum; wurde von irgendwoher mitgeschleppt.
Mit dem <noinclude> würde jemand erreichen wollen, dass der ganze obere Teil des Artikels (und nur dieser) in eine andere Seite eingebunden wird.
Ich frage mich nur, was das für ein Monster-Artikel sein sollte? „Die europäischen Staaten“? „Staaten dieser Welt“?
Andere Staaten-Artikel haben so etwas nicht. Könnte also nicht funktionieren.
Grundsätzlich gilt, dass bei includeonly onlyinclude noinclude außerhalb von Vorlagen immer ein Kommentar stehen müsste, der angibt, in welche Zielseite die Einbindung erfolgen soll (vielleicht nicht gerade bei Hans Meier – für Personen-BKS ist die Methode allgemein üblich; Zielartikel ist hier Meier (Familienname)).
Damit kann man nachgucken, ob es die einbindende Seite überhaupt noch gibt.
Außerdem würde man eher ein Paar <onlyinclude>...</onlyinclude> verwenden.
Kommentier es doch einfach aus; mal hören, ob überhaupt jemand aufschreit. Auf der Artikel-Disku kannst du ja auch den Hinweis auf diesen Abschnitt hier hinterlassen.
Es ist übrigens die gleiche Fehlerursache mit zwei fehlerhaften Auswirkungen.
Noch ein paar Rückmeldungen: In manchen Artikeln, z. B. in Liste Szegediner Persönlichkeiten, verweigert das Skript komplett die Arbeit, da tut sich einfach gar nichts. Zudem wurde hier eine doppelte Leerzeile entfernt, dort aber nicht, obwohl die Artikel genau gleich aufgebaut sind. In beiden Fällen ist die Leerzeilen meiner nach beabsichtigt und erwünscht, sodass keine Entfernung stattfinden sollte. Steak11:15, 25. Aug. 2012 (CEST)Beantworten
In Liste Szegediner Persönlichkeiten wüsste ich jetzt auch nicht, was das Skript machen soll. Es stehen ein paar Minuszeichen statt Bis-Strich zwischen den Jahreszahlen, aber das gehört nicht zu den Standardaufgaben.Das war ein anderer Artikel.
Es sollen dreifache Leerzeichen auf zwei reduziert werden, aber nicht weniger. Die Veränderung bei Grassi konnte ich reproduzieren, die Ursache ist mir schleierhaft. Es gibt irgendeinen geheimnisvollen Auslöser dafür; dazu brauche ich eine kühle Nacht und muss das schrittweise durchfummeln. Im Artikeltext konnte ich keine verborgenen Gründe finden. Wird im Laufe des Wochenendes aufgespürt und gefixt.
Danke für deine Mühe. Teilweise ist es bei mir so, dass, auch wenn es am Artikel nichts zu tun gibt, das Skript durchläuft und die Versionsunterschiede anzeigt - da nichts verändert wurde steht dann links oben "Aktuelle Version" und rechts oben "Dein Text", nur dass dann halt kein Versionsunterschied kommt, sondern gleich das Bearbeitungsfenster. Das ist aber nicht immer so, oft passiert auch gar nichts, wie in ebenjener Liste. Warum manchmal nichts passiert und manchmal das Skript läuft weiß ich aber nicht. Und zu den Leerzeichen: Das war bei weitem nicht der einzige Fall, bei dem zwei Leerzeichen auf eins reduziert wurden, bei den restlichen Fällen war es aber entweder sinnvoll oder ich habe es vor dem Abspeichern zurückgeändert. Siehe z. B. [1]. Steak20:51, 25. Aug. 2012 (CEST)Beantworten
Die unveränderte Änderungsseite kann ich aufklären: Da stand hinter dem Artikel Whitespace, insbesondere überflüssige Leerzeilen. Das Skript entfernt alles nach dem letzten Zeilenumbruch, und weil das eine Veränderung ist, wird die Diffpage angefordert. Die aktuelle Diff-Prozedur hat aber einen bekannten Bug und zeigt keine Veränderung.
Wenn du wieder sowas mit der Leerzeile hast, bitte nicht abspeichern, sondern auf deiner Arbeitsliste belassen und hier in einem frischen Abschnitt melden. Bisher ist die Tücke nicht bekannt, aber vielleicht kommst du auf BKS, die meine Stammkunden nicht aufsuchen und auf kurzen Seiten ist irgendeine Besonderheit.
Identifiziert habe ich die auslösende Programmstelle, und allmählich wird mir auch der Zusammenhang klar: Solche Doppel-Leerzeilen erwartet das Skript nur vor Überschriften oder größeren Einschüben. Hier sind beide vom Rang „normaler Fließtext“. Dabei ist das in Fettschrift gesetzte „Siehe auch“ aber eine getarnte Überschrift, jedoch für die Skript-Logik normaler Text.
Wie ich das löse, werde ich mir über Nacht überlegen; upload im Laufe des Sonntags. Vielleicht hast du andere als diese BKS auf deinen Arbeitslisten, wenn du dich langweilen solltest?
Die Programmierung gibt es seit sechs, neun, zwölf Monaten oder länger; aber es ist noch nie ein Anwender über diese Situation gefallen. Offensichtlich sind die nicht auf diesen BKS unterwegs gewesen.
Keine Sorge, ich langweile mich nicht. Wie du an der Nummerierung der Arbeitsliste erkennen kannst, hab ich noch etwa sechs andere ;-) Gute Nacht. Steak23:31, 25. Aug. 2012 (CEST)Beantworten
Ich habe nun eine Ausnahmeregel geschrieben, die Fettschrift am Beginn der folgenden Zeile wie eine Überschrift behandelt.
Eigentlich sieht unsere Typografie vor, dass es nirgendwo solche Abstände gibt. Aka streift auch durch den Bestand und reduziert das.
Im Fall dieser winzigen BKS ist es optisch okay. Die paar Zeilen verteilen sich eher besser auf dem Bildschirm.
Das Skript ignoriert vor Überschriften und großen festformatierten Blöcken (Programmcode) die Regel und lässt individuell größeren Abstand zu, damit bei langen unübersichtlichen Seiten (auch außerhalb des ANR) besser gegliedert wird. Zwischen normalen Absätzen wünscht es aber nur eine Leerzeile zu sehen.
Geschrottet nicht; du siehst nur was, was du normalerweise nicht sehen kannst.
Die Interwikis bleiben voll funktionstüchtig; du bekommst aber ein unsichtbares Zeichen zu sehen. Das liegt daran, dass hier Sprachen auftreten, die ich in dem Zusammenhang noch nicht kannte. Wenn du mit dem, was immer du zurzeit an Wartungslisten oder sonstwas abarbeitest, einfach bis morgen warten kannst, dann werde ich das in einer erfrischend kühlen Nacht mit anderen laufenden Änderungen zusammen live stellen und ich gebe morgen hier Bescheid.
Oh je; das liegt an dem Kommentar im Namen der Vorlage. Auf die Idee war bisher noch nie jemand gekommen, darauf war das Skript offenbar nicht gefasst. Legitim ist es natürlich, sowas zu schreiben. Bis das sauber und robust abgefangen wird und ausgetestet ist, kostet es eine kühle Nachtschicht; heute ist genau das richtige Wetter dafür.
Eine Bitte: Könnten wir damit diesen Thread zumachen, und deine hilfreichen Hinweise bekommen jeweils einen neuen Abschnitt? Ich finde mich sonst auf der Beo und beim Tracking nicht mehr durch, wo ich schon war und was erledigt ist, und der Archiv-Bot langweilt sich.
@PerfektesChaos: Obwohl ich wusste, nach was ich suche, habe ich ziemlich lange gebraucht um diese Dokumentation zu finden. Für den normalen Benutzer ist die Dokumentation in diesem Punkt etwas … chaotisch. --Schnark09:21, 25. Aug. 2012 (CEST)Beantworten
@Schnark: Ist mir bewusst; hatte grad die letzte halbe Stunde mit der weiteren Verbesserung der Doku zugebracht. Die Umstellung von simplen globalen Variablen auf Anwendungsobjekte wird wohl noch öfters zu Irritationen führen. Das Problem ist, dass nicht bei jeder einzelnen Zuweisung einer Komponente immer die ganze Litanei von Adam und Eva ab erzählt werden kann.
@Steak:
Du müsstest noch ganz am Anfang den folgenden, von Schnark erwähnten Block einfügen:
Damit wird ein leeres Gerüst aufgebaut, in dem du dann die einzelnen Eigenschaften ablegen kannst. Das ist gewissermassen ein leeres Bücherregal; im Moment hast du das Buch in der Hand und kannst es nicht auf dem Regalbrett ablegen.
Was prettytable angeht, nochmal zur Erinnerung: Wenn außer prettytable im Artikel nichts definiert ist, lässt es sich 1:1 ersetzen. Es gibt aber bestimmte Farbgestaltungen usw. in Tabellenkopf und Tabellenzeilen, von denen mit wikitable nichts mehr angezeigt wird. Gibt es also gleichzeitig irgendwelche speziellen Zuweisungen, muss die Vorschau mit der alten Artikelversion verglichen werden und eine erhaltenswerte Farbgestaltung notfalls eingepfriemelt werden oder aber es bleibt beim prettytable.
Letzter Kommentar: vor 11 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Die Mod ersetzt in Dateieinbindungen "right" durch "rechts". Aber Bilder sind ja standardmäßig rechts, braucht man den Parameter dann überhaupt oder kann man ihn in vielen (allen?) Fällen entfernen? Steak14:15, 25. Aug. 2012 (CEST)Beantworten
Überflüssig ist rechts/right nie, wenn es keine miniatur ist.
Wenn es eine miniatur ist, wäre rechts/right redundant, falls es die oberste Text-Ebene (Fließtext) ist.
Ist es hingegen miniatur, aber Teil einer Tabelle, Aufzählung oder in ein <div>-Konstrukt eingebettet, dann kann es trotz miniatur notwendig sein; vielleicht auch nicht. Kommt auf das Layout der Tabelle usw. an.
Weil ich die dritte Bedingung nur schwer abprüfen kann (höchstens, wenn das Bild ab dem ersten Byte der Seite stünde), macht WSTM standardmäßig nichts daran.
Auf eigene Gefahr kannst du mit der folgenden Ersetzung die typischen Verwendungen herausnehmen; musst dann aber selbst darauf achten, dass nichts beschädigt wird.
// Komma zum Anschluss an den Vorgänger ... ,["(?:(?:\\|rechts\\|miniatur\\|)|(?:\\|miniatur\\|rechts\\|))","|miniatur|"]
Letzter Kommentar: vor 11 Jahren8 Kommentare4 Personen sind an der Diskussion beteiligt
Hallo PerfektesChaos, die auskommentierte Meldung –gerade bei Aglaonike bemerkt–, die SORTIERUNGsangabe sei unnötig, kommt doch sicher durch die Einbettung dieses Scripts? Ich halte das für keine gute Idee, jedenfalls wenn es um Personenartikel geht. Da in diesen Fällen in sicher weit über 90% aller Fälle die explizite Angabe von SORTIERUNG notwendig ist, besteht bei Artikeln ohne diese Angabe immer der Verdacht, dass sie fälschlich vergessen wurde. Ich halte es daher für einen guten Brauch –dem ich auch nicht immer folge–, sie bei anderen Arbeiten am Artikel hinzuzufügen, auch wenn das nicht erforderlich ist. Vielleicht überdenkst Du diese Entscheidung noch einmal?
Der Hinweis fordert nur dazu auf, über die SORTIERUNG nachzudenken.
So könnte es sein, dass im Artkel über Petra Meier steht:
{{SORTIERUNG:Petra Meier}} – hier wurde vergessen, den Sortierschlüssel einzurichten, es wurde zunächst nur der Seitentitel kopiert. Das Skript fordert nun den Autor dazu auf, diese Angabe zu überprüfen.
Isländische Personen werden nach Vorname-Nachname sortiert. In einem Artikel über eine isländische Person sollte statt der SORTIERUNG ein Kommentar eingefügt werden, in dem auf diesen Umstand hingewiesen wird, damit die nachfolgenden Bearbeiter Bescheid wissen, und nicht etwa eine übliche SORTIERUNG:Nachname,Vorname einbauen.
Totalredundante Syntaxelemente verwirren nur die nachfolgenden Autoren. Was haben die Vorgänger sich denn bloß dabei gedacht? Wenn Aglaonike Sortierhinweise bekommen soll, dann allenfalls als Kommentar, mit einem Hinweis, dass keine SORTIERUNG erforderlich ist.
Mutmaßlich noch in diesem Jahr wird in der deWP eine bereits seit einigen Jahren international auf unseren Servern vorhandene Technologie eingeführt, die bei bloßer Umlaut-ß-Anpassung die SORTIERUNG überflüssig macht. Dies muss aber für jede Sprache einzeln konfiguriert werden.
Ich beabsichtige, spätestens dann bei Personen mit einem Leerzeichen im Seitentitel ohne Klammerzusatz explizit nach einem fehlenden SORTIERUNG nachzufragen. Das Skript weiß heute bereits, wenn es sich um eine Person handelt.
Umgekehrt wird es dann redundant werdende SORTIERUNG kommentarlos entfernen.
Zwar beabsichtigte ich, unmittelbar vor der ersten Kategorie ein fehlendes SORTIERUNG automatisch einzufügen, habe davon aber ob der absehbaren Entwicklung Abstand genommen.
Hab jetzt nicht nachgesehen bei deinem Skript, aber ihr wisst auch, dass eine Sortierung allein auf Grund von Groß- bzw. Kleinschreibung seit längerer Zeit (ca. letztem Jahr) überflüssig ist, oder? Hab ich in der Hilfeseite leider erst vor wenigen Tagen angepasst, hätte ich schon früher mal machen sollen. Grüße --Geitost17:55, 26. Aug. 2012 (CEST)Beantworten
Für die Kategorie:Abkürzung bedeutet das konkret, dass fast sämtliche Sortierschlüssel in den Seiten darin dadurch vollständig überflüssig geworden sind (also überall, wo nicht zusätzlich noch ein Umlaut, ß oder anderes Sonderzeichen vorkommt). Solche Sortierschlüssel sollten deshalb eigentlich Bots oder andere Bearbeiter wieder entfernen, sobald noch was anderes in derartigen Seiten (häufig ja BKLs) geändert wird. Vielleicht könnte man eine Liste von Seiten erstellen, bei denen dadurch die Sortierung überflüssig geworden ist. Dann kann man mal schauen gehen, ob es da nicht noch mehr zu ändern gibt. ;-) --Geitost17:58, 26. Aug. 2012 (CEST) PS: Obwohl: Wenn ich genauer drüber nachdenke, so haben dort ja alle Abkürzungen mit Großbuchstaben eh keinen Sortierschlüssel. Also ist er nur dort überflüssig, wo auch zusätzlich kleine Buchstaben enthalten sind. Könnte man derartige Seiten mal irgendwo auflisten?Beantworten
Ich weiß das; aber was hilft es, wenn ich und das Skript es wissen und umsetzen, aber dies noch nicht in den Köpfen der Anwender angekommen ist?
Das Großklein-Feature ist Bestandteil der oben erwähnten Einführung der neuen Sortier-Technologie, die aber kulturelle und sprachliche Tücken hat. Hier wurde bereits darüber diskutiert. Weil die Angelegenheit seitdem im Fluss war, hatte erstmal niemand neue Sortierregeln vorgegeben, nachdem es darum ewiges Hickhack gab.
Dieses Skript kümmert sich überhaupt nicht um Groß- und Kleinschreibung des Sortierschlüssels. Es berichtigt seit 2010 Umlaute, ß und etliche diakritisch modifizierte Buchstaben; alles, was es lateinisch-basiert so gibt. Das wird es auch weiterhin tun, bis die UCA-Technik eingeführt wurde und einige Monate robust in der deWP gelaufen ist. Danach müsste dies zu identischen Ergebnissen führen; Apostroph und ähnlicher Kleinkram wäre abzuwarten.
Anschließend wird dieses Skript diskussionslos alle redundant gewordenen SORTIERUNG aus dem Wikitext entfernen. Es entspräche aber nicht den Regeln für „kleine Änderungen“, nur deswegen Bots zu beauftragen oder Wartungslisten abzuarbeiten. Also lässt man dies gemütlich herausdiffundieren, und Skripte sind im Abgleich von Sortierschlüssel und Seitennamen jedem Menschen überlegen. Die Umstellung PND→GND hat wohl schon einige 10.000 abgearbeitet, aber noch rund 150.000 Artikel vor sich. Das kommt halt so nach und nach.
Jo, das klingt gut. :-) So wie auch mit thumb, miniatur und mini und anderem auch. Nach und nach. In die Köpfe kommt es dann wohl auch erst nach und nach logischerweise. Ist ja wie überall. Wenn die Sonderzeichenumstellung dann irgendwann erfolgt ist, sollte man noch mal nen Kurierartikel zum Thema schreiben, damit es auch etwas weiter durchdringt als bis zu den üblichen Verdächtigen. ;-) Viele Grüße --Geitost20:26, 26. Aug. 2012 (CEST)Beantworten
Letzter Kommentar: vor 11 Jahren7 Kommentare3 Personen sind an der Diskussion beteiligt
Könntest du zum Skript noch hinzufügen, dass das bei Aufzählungen mit * oder # zwischen dem Zeichen und dem ersten Wort ein Leerzeichen einfügt, falls noch keins da ist? Ich denke, das ist sauberer und leicht übersichtlicher. Steak20:01, 26. Aug. 2012 (CEST)Beantworten
Ich gebe dir völlig recht und handhabe es auch so.
Weil es dazu keine verabschiedete Richtlinie und keinen endgültigen Konsens gibt, macht das Skript dies auch nicht von sich aus. Hier steht aber die mundgerechte Ersetzungsregel.
Die bisher einzige von den benutzterdefinierten Änderungen, die ich auch mitlaufen lassen wollte. Bisher habe ich das Leerzeichen in einzelnen Abschnitten händisch eingefügt. Leider wirken sich die Ausdrücke überhaupt nicht auf Vorlagen aus, die in solchen Abschnitten wie Weblinks und Literatur ja zahlreich vorkommen. Die bewegen sich keinen Pixel, vermutlich wegen der geschützten Bereiche. Und auf der Doku zu Vorlagen sehe ich auch keine Abhilfe dafür. Gruß, IvlaDisk.23:59, 30. Aug. 2012 (CEST)Beantworten
Wohl wahr; es ist Absicht.
Du erinnerst mich an einen Punkt auf meiner ToDoList: Die BBKL als Musterbeispiel für die benannte Doku. Vielleicht komme ich nachher, nach ausgiebigem Schlaf, endlich mal zu Doku und Musterlösung. Live und funktionstüchtig ist es seit Wochen. Ach ja, und JS/API wollte ich auch schreiben. Jetzt brauche ich nur noch wen, der mir erzählt, ich würde ja gar keine Artikel schreiben.
Mit der von dir zitierten Seite hast du schon genau die richtige getroffen: replace/template #style machen exakt diese Leerzeichen-Kosmetik.
(Nochmal nachgelesen) Kann ich nicht erkennen. Die Bezeichner beziehen sich doch alle auf Aktionen innerhalb der Vorlage? Ich sehe da nichts, was auch die Umgebung der Vorlage analysiert und bei Bedarf vor die Vorlage ein Leerzeichen setzen könnte.
Irgendwann, wenn WSTM alles erledigt hat, gibt es doch sicher die Bereiche wieder frei. Könnte man dann nicht einfach die Ausführung einiger winziger, natürlich völlig ungefährlicher, rein benutzerdefinierter und (wie bei allen anderen Änderungen auch) völlig in deren Verantwortung liegender Ersetzungen laufen lassen? ;-) Gute Nacht, IvlaDisk.00:58, 31. Aug. 2012 (CEST)Beantworten
Das ist auf der zitierten Doku bereits skizziert, aber aus purem Zeitmangel noch nicht programmtechnisch umgesetzt.
Ich komme noch nicht einmal dazu, alle vorhandenen Funktionen (BBKL) abschlusszutesten und zu dokumentieren und Beispiele beizufügen.
Die von dir ersehnten Features nennen sich prolog und epilog und würden sich analog zu den gleichnamigen bei den Links verhalten: Die Zeichen vor {{ bis zum Zeilenumbruch zuvor, oder Kommentar, oder ]. Anschließend von }} bis zum nächsten Zeilenumbruch, oder Kommentar, oder [. Das gilt sowohl für detect wie auch für change. Die Stummel sind im Skript schon vorbereitet, aber weder die Benutzerdefinition noch die Umsetzung ist im Moment ausgeführt.
Momentan möchte ich mir hier etwas Ruhe und Abwechslung gönnen. In einigen Wochen, wenn sich die Umstellung von WSTM.4 auf WSTM.5 als robust erwiesen hat, wird der zurzeit 315 kB große Syntax-Hauptteil des über 730 kB großen Skripts in sechs unabhängige Teile zerlegt werden. Danach kann ich leichter an einem Teil weiterentwickeln und komme bei einem möglichen Bugfix nicht so leicht in die momentan missliche Situation, dass ich für eine kurzfristige Reparatur den frisch umgebauten und ungetesteten Teil allen Anwendern überlassen muss.
Was genau hast du denn vor? Vielleicht fällt mir was dazu ein.
Diese Funktion gibt es; sie steht auch unauffällig irgendwo in der Doku; ich rate jedoch von ihrer Benutzung ab und empfehle, sich noch etwas in Geduld zu fassen.
Letzter Kommentar: vor 11 Jahren8 Kommentare3 Personen sind an der Diskussion beteiligt
Dein Skript macht aus "#WEITERLEITUNG" "#WEITERLEITUNG:" (als plus Doppelpunkt). Das finde ich doch sehr befremdlich, da ich das weder auf den betreffenden Hilfe-Seiten finde konnte, noch die Standardvariante, die man beim Klick auf das entsprechende Kästchen der Werkzeugleiste erhält, den Doppelpunkt hat. Steak20:13, 26. Aug. 2012 (CEST)Beantworten
Es befremdet mich auch; da muss bei einer Änderung vor einigen Wochen ein +1 an die falsche Stelle gelangt sein. Soll nicht sein.
Technisch ist es übrigens korrekt, wie du gemerkt haben wirst, und wird auch so verarbeitet. Das Skript soll aber im Gegenteil diesen Doppelpunkt aus optischen Gründen entfernen, wenn es einen antrifft; diese Form war wohl mal vor zehn Jahren in Mode gewesen.
(BK) „Weiterleitung“ kann man auch einfach klein schreiben, das funzt genauso und stört mMn den Lesefluss weniger. Deshalb schreib ich es auch immer so. :-) --Geitost20:28, 26. Aug. 2012 (CEST)Beantworten
Mir wäre das auch völlig egal, aber Hilfe:Variablen sieht für alle diese Schlüsselwörter Großbuchstaben vor. Dann schreien wieder einige auf, weil sie jetzt nicht mehr verstehen und mitbekommen, dass dies ein Schlüsselwort ist, und außerdem kann man die Weiterleitungsseite jetzt nicht mehr in die koreanische Wikipedia exportieren, und deshalb muss es unbedingt #REDIRECT heißen … Wenn ich hier sowieso reparieren gehen muss, dann schau ich mal, ob eine vorgefundene #Weiterleitung nicht einfach belassen werden kann. Liebe Grüße --PerfektesChaos20:53, 26. Aug. 2012 (CEST)Beantworten
Der Doppelpunkt war irgendwann in diesem Sommer bei der Neuprogrammierung WSTM.4→WSTM.5 dort hineingeraten; keine Ahnung wann und wie und warum. Er taucht in einer formalen Sprachbeschreibung auf (sofern man Wikitext überhaupt als formale Sprache bezeichnen kann). Zukünftig wird er entfernt, wie auch zuvor.
Die Änderung wird jedoch erst in einigen Tagen live gehen, weil im Zuge anderer Arbeiten zunächst andere Module und Änderungen getestet und hochgeladen werden müssen.
Ich habe eine Nacht darüber geschlafen und vorher wie hinterher die gesamte Handhabung neu programmiert.
Wenn das Skript aus irgendeinem Grund aktiv wird, setzt es immer
#WEITERLEITUNG [[
Das Skript wird nicht aktiv, wenn exakt vorgefunden wird
#Weiterleitung [[
Wer das ummodeln möchte, kann nach eigener Weisheit ersetzen
Damit das deutlich sichtbar wird und auf der Diffpage erscheint. Gib’s zu: Du hättest das Strichlein sonst doch glatt übersehen.
Das Skript macht das nur, wenn nach dem ersten benannten Parameter noch mal unbenannte erscheinen.
Das ist in aller Regel Murks; es gibt allerdings auch grottige Kopiervorlagen, die sowas vorsehen und wo auch ungeschickt programmiert wurde.
Es kann sein, dass ein Gleichheitszeichen verlorengegangen ist. Da sollte stehen p=x und es ist jetzt p x draus geworden. Dann bekommt p keinen Wert.
Es kann sein, dass vergessen wurde, einen wichtigen Parameter anzugeben.
Gelöscht werden kann der leere Parameter nicht einfach, weil das die Abfolge weiterer vorstellbarer Parameter und ihre Nummerierung beeinflusst.
Das Skript kann im Allgemeinen nicht entscheiden, was hier passieren soll, und macht dich und die folgenden Autoren darauf aufmerksam, damit irgendwer über die 1= stolpert. Eine rote Kiste ist es aber auch wieder nicht wert; Diffpage reicht eigentlich.
Wo das Skript die Vorlage und ihre Parameter kennt, löscht es automatisch einen leeren Wert. So etwa in den Normdaten: In deren Fehlerliste von heute ist sowas bei René_Lalique: Parameter 2 mit Wert "". Wenn du den bearbeitest, geht der || hops.
Letzter Kommentar: vor 11 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Wie behandelt dein Skript eigentlich den typographisch korrekten Bindestrich, der ja vom auf der Tastatur vorhandenen Bindestrich-Minus zu unterscheiden ist? So wie ich das sehe ist der korrekte Bindestrich in der Wikipedia weder erwünscht noch sinnvoll, weil das Suchen von Textteilen damit deutlich erschwert würde. Da beide typographisch wohl ziemlich ähnlich aussehen, kann man ihn auch nicht so ohne weiteres durch das Aussehen identifizieren. Steak15:22, 27. Aug. 2012 (CEST)Beantworten
Nein, und es ist praktisch der gleiche Fall wie bei Gertrude Stein, den du gemeldet hattest, und an dem ich gestern Abend geknabbert hatte und mit der sicheren Lösung ich auch die nächste Nacht beschäftigt sein werde.
Diese Vorlagenbearbeitung gibt es unverändert seit drei Monaten, aber seit du durch den Bestand pflügst, hast du schon zwei Fälle gefunden, wo jemand einen Kommentar zwischen dem Namen der Vorlage und dem ersten Pipe-Symbol eingebaut hatte. Hier steht jetzt noch ein Zeilenumbruch dazwischen; deshalb verhält es sich anders als bei Gertrude Stein.
Bisher war diese Situation nicht aufgetreten, und das Skript erwartet hier keinen Kommentar. Die Programmiererei ist dort ziemlich heikel, und es bedarf anschließend auch eines umfangreichen Austestens, um Kollateralschäden zu vermeiden. Übrigens dürfte es in der Regel nur vorkommen, wenn man benutzerdefinierte Ersetzungen vornimmt, weil nur dann die Vorlagenanalyse greift.
Letzter Kommentar: vor 11 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
Das Verhalten in Fehrmann kann auch nicht ganz stimmen (ist jedenfalls imho nicht sinnvoll). Anstatt ein (vermutlich nicht ganz standardmäßiges Leerzeichen) einfach durch ein normales zu ersetzen, schreibt das Skript irgendwas komisches rein. Steak17:17, 27. Aug. 2012 (CEST)Beantworten
Nö, das hat zur Abwechslung alles seine Richtigkeit. Das „irgendwas komische“ kennst du als „ “ und hatte versteckt im Text gestanden. Das Skript macht es sichtbar; wählt aber eine alternative Kodierung, damit man die Situation unterscheiden kann. An der Funktion ändert sich dadurch nichts. Weil es an dieser Stelle sinnfrei ist und nur durch C&P irgendwie umhergeschleppt wurde, kann es hier durch ein einfaches Leerzeichen ersetzt werden. Beschrieben ist das hier. VG --PerfektesChaos17:42, 27. Aug. 2012 (CEST)Beantworten
bist du erst seit weniger als einer Woche zugange und findest halt neue Aspekte, jetzt gerade einiges über Zeichenkodierung und HTML;
ist es hilfreich für mich, wenn Bugs gefunden werden; der Doppelpunkt nach Weiterleitung war bisher nicht aufgefallen, die Himalaya-Sprachen kannte ich noch nicht in Sachen nullbreiter Zeichen – und ich tüftele immer noch an den Kommentaren zwischen Vorlagen-Namen und Pipe-Symbol. Bei den Mengen an Seiten, die du konsumierst, findest du Situationen, die beim Austesten noch nicht vorkamen.
Letzter Kommentar: vor 11 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Soweit ich weiß, gibt es einen Konsens, dass die Kategorien vom Allgemeinen zum Speziellen geordnet sein sollen, sodass die Lebensdaten- sowie die Geschlechtskategorie immer ganz am Ende kommt. Könntest du sowas auch noch in dein Skript einbauen? Steak13:59, 28. Aug. 2012 (CEST)Beantworten
Die Sache mit der Katsort ist ein alter Wunsch, schon seit über einem Jahr beim Weihnachtsmann auf dem Zettel.
Das Skript kennt heute schon alle Kat und Interlanguage, hätte technisch auch kein Problem, Frau/Mann/Weißnicht zu sortieren hinter Geboren-Gestorben zum Schluss.
Zuvor war die Umstellung WSTM4/5 abzuwarten, die ja relativ glatt ging und im September abgeschlossen sein wird. Die neue Technologie beeinflusst maßgeblich die Position von Verlinkungen und ihre Verschiebung.
Viel wichtiger als die Reihenfolge innerhalb der Kats wäre aber die korrekte Anordnung SORTIERUNG → Kats → PD → Link|FA/GA → Interlanguages und dazwischen möglicherweise Kommentare. Hier sollte in der deWP zunächst aufgeräumt werden. Taucht außerhalb dieses Bereichs hingegen eine Kat oder Interlanguage auf, dann hat vermutlich jemand einen Doppelpunkt vergessen und das führt zu Fehlfunktionen. Syntaktisch ist es zwar erlaubt, Kats und Interlanguages sonstwo im Artikel unterzubringen, aber die Autoren drehen durch, wenn die mitten im Artikel verstreut würden.
Bereits heute gibt es eine Fehlermeldung bei doppelten Kats und Interlanguages.
Im Übrigen habe ich Schulaufgaben gemacht und den Doppelpunkt nach WEITERLEITUNG sowie die Fixe zu Gertrude Stein und Das Wetter im Ersten live geschaltet. Das Hauptproblem und der wesentliche Aufwand ist nicht das Programmieren, – um zu vermeiden, dass unbeabsichtigte Nebenwirkungen schädigend wirken können.
Letzter Kommentar: vor 11 Jahren6 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo, in Anton de Bary passiert Folgendes (Umbrüche von mir hier eingefügt):
* {{Biolib|1=debary/kartoffelkrankheit/index.html|2="Die gegenwärtig herrschende
Kartoffelkrankheit, ihre Ursache und Verhütung"}}, Eine pflanzenphysiologische Untersuchung in
allgem. Form dargestellt'' (1861); {{Biolib|1=debary/kartoffelkrankheit
/debary_kartoffelkrankheit.pdf|2=PDF-Version}}
+
* {{Biolib|1=debary/kartoffelkrankheit/index.html|2="Die gegenwärtig herrschende
Kartoffelkrankheit, ihre Ursache und Verhütung"}}, Eine pflanzenphysiologische Untersuchung in
allgem. Form dargestellt'' (1861); {{Biolib|1=debary/kartoffelkrankheit/debary
kartoffelkrankheit.pdf|2=PDF-Version}}
Die URL zum PDF funktioniert anschliessend natürlich nicht mehr. Zunächst hatte ich diesen Effekt nur, wenn ich die Bearbeitung über Schnarks normdaten.js gestartet habe. Deswegen habe ich zunächst jsmodules.load('Benutzer:Schnark/js/templateEditor.js/wstm.js'); auskommentiert und weiter probiert. Kann aber Zufall gewesen sein, mittlerweile tritt die Änderung immer auf, egal ob ich die Bearbeitung über Bearbeiten oder über normdaten.js starte. Auffällig die einsamen '' hinter dargestellt. Gruß, IvlaDisk.11:05, 29. Aug. 2012 (CEST)Beantworten
Weil die Domain fehlt (ist ja auch völlig in Ordnung in der Vorlage, wo dies redundant wäre), wird der Vorlagenparameter nicht als Bestandteil einer URL erkannt.
den _ manuell wieder einfügen und Artikel speichern.
ein _ in das URL-Fragment einsetzen. Das Link ist dann trotzdem funktionstüchtig. Die nächsten Autoren wundern sich. Das nächste WSTM tut ihm nichts.
mittelfristig: Ich habe soeben beschlossen, eine weltweit einsetzbare Funktion zu schreiben, die beim Antreffen der dewiki:Biolib:1 automatisch den Parameterwert als Typ "URL" und nicht wie im Moment als "Wikilink:Datei:" klassifiziert. Dann wird auch nichts mehr ersetzt.
Sonstiges:
Ein Hinweis auf 22,5 MB täte der Vorlage als weiterer optionaler Parameter oder angehängt an 2= gut; so klickt der Handy-Benutzer sich unvorbereitet in ein Riesending ein.
Mit den '' habe ich nichts zu tun; die standen vorher schon drin, sind unbalanced, offenkundig das Ende einer beabsichtigten Titel-Kursivierung.
Nachtrag: In unseren Medienbezeichnern können eigentlich nie Schrägstriche auftreten. Damit können selbst bei unbekannten Vorlagen URL-Bestandteile klassifiziert werden; allerdings könnte der URL-Pfad mitsamt Schrägstrichen in der Vorlage stehen und es wird nur das letzte Segment als Vorlagenparameter angegeben. Dann ist leider die Kenntnis der konkreten Vorlagen erforderlich. Liebe Grüße --PerfektesChaos11:55, 29. Aug. 2012 (CEST)Beantworten
Live ist eine Version, nach der anhand des Schrägstrichs erkannt wird, dass es sich nicht um eine Datei:debary/kartoffelkrankheit/debary kartoffelkrankheit.pdf handeln kann, und wodurch in diesen Fällen pauschal der Unterstreichungsstrich bleibt.
In den nächsten Wochen wird das noch ausgedehnt auf die Registrierung namentlich bekannter Vorlagen, die Bestandteile von URL verarbeiten.
Danke, das sollte erst mal helfen, in dem Artikel habe ich das manuell korrigiert, mit Unterstrich, damit die nächsten Autoren sich nicht wundern. Die 22,5 MB und die '' ebenfalls ergänzt, dass letztere nicht vom Skript kamen war klar.
Wie häufig haben wir umgekehrt Vorlagen, in denen ohne umschließende [[ ]] wikilinks stehen, ohne Datei: davor? In ADB zu Wikisource, innerhalb von gallery (nachdem WSTM darüber gelaufen ist ;-), Commons(cat), weitere Schwesterprojekte, die das Skript ohnehin kennt. Mehr fallen mir auf Anhieb nicht ein. Die meisten anderen verlinken doch auf externe Ziele? Gruß, IvlaDisk.00:29, 31. Aug. 2012 (CEST)Beantworten
Es gibt sehr viele: Äußerst zahlreiche verschiedene Infoboxen und dergleichen verlinken auf das Foto, Logo, die Flaggendatei oder ein Wappen über ein Teil eines Wikilinks.
Betroffen sind ohnehin nur Link-Fragmente, die auf eine Mediendatei-Erweiterung enden, also .pdf, .jpg usw. Die Klassifizierung als Link hat übrigens zur Folge, dass der Wert vor typografischer Veränderung geschützt wird.
Der von dir aufgedeckte Fall einer URL, deren Protokoll+Domain in der Vorlage hinterlegt wurde, war übrigens nach mehr als anderthalb Jahren der erste; zumindest der erste, bei dem das auffiel.
Letzter Kommentar: vor 11 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
Beim Aufrufen des Bearbeitenfensters von Komparator (Digitaltechnik) stürzen bei mir (Win 7 64bit) die neusten Versionen von Firefox, Internet Explorer und Chrome ab, wobei nur Firefox sich wieder fängt und das Abbrechen des Skripts ermöglicht, sodass die Seite (ohne Skript) editiert werden kann. Steak13:23, 29. Aug. 2012 (CEST)Beantworten
Ich muss leider bestätigen, dass sich das Skript bei dieser Seite in einer Endlosschleife verheddert.
Die Identifizierung des Sorgenkinds wird mir voraussichtlich am frühen Abend möglich sein; die Beseitigung dürfte im Laufe des Abends geschehen sein. Bitte lass den Artikel bis dahin in Ruhe.
Auslöser sind die diversen < in diesem Artikel. Ihnen folgt ein b oder B, was so aussieht wie der Anfang eines HTML-Tags <b> für Fettschrift – weil das nicht beendet wird, werden Fehlermeldungen ausgelöst.
Weil gleich mehrere Fehlermeldungen kamen, verstolperte sich der Zähler und kam nicht mehr dazu, wenigstens um eins weiterzugehen; deshalb hing das Skript an ein und derselben Stelle fest.
Zurzeit ist ein vorläufiger Fix live, der erstmal die Endlosschleife überspringt. Der Artikel kann bearbeitet werden.
Mit den Fehlermeldungen bin ich nicht so glücklich; sie könnten noch treffsicherer sein. Beim Doppelfehler (Leerzeichen nach < und kein >) sollte die Interpretaion als vertipptes Tag abgebrochen werden können. Darüber muss ich morgen oder am Wochenende nachdenken.
Das Grundproblem ist nicht auflösbar.
Wenn der Wikiserver etwas findet, worauf er sich keinen Reim machen kann, dann schreibt er die seltsamen Zeichen einfach in die Seite.
Wenn dieses Skript halbgare Syntaxkonstrukte findet, die es nicht reparieren oder verstehen kann, reagiert es mit einer Fehlermeldung, weil das schließende > vergessen worden sein könnte.
Es geht um die beiden Konstrukte
<sub>a<b</sub>
A < B || A = B - d || usw.
Eine Lösung wäre die Verwendung von < statt < – was die nächsten Autoren nicht so freuen wird.
Der Artikel ist typografisch nicht so toll. Lange Formel einfach im Fließtext, Bindestrich statt Minuszeichen; wenn du damit gemacht hast, was du vorhast, werde ich dort nachputzen kommen.
Es geht wohl um: Infobox Eishockeyfranchise Nordamerik
Im Ausgangstext stand ein Leerzeichen zwischen {{ und dem Namen. Das wurde entfernt, aber bei irgendeiner Änderung der letzten Wochen hatte ich offenbar den Zähler beschädigt, der danach die richtige Position zuweist; jetzt einmal zuviel die weggefallene 1 abgezogen.
Fix bis heute abend, da eine diffizile Angelegenheit und vorher gründlicher auszutesten.
Uff. Das könnte eine härtere Nuss werden. Je nach Wetter morgen kommt die Reparatur mit Austesten eher Montag/Dienstag. Ich dachte, diese Krankheit wäre inzwischen überwunden. Mutmaßlich eine Nebenwirkung der Änderungen der letzten Tage.
Bug gefunden und beseitigt. Aber noch eine Weile nicht live, weil erstmal getestet werden muss.
Ging einfacher als ich dachte. Tritt nur auf, wenn jemand benutzerdefinierte Ersetzungen vornimmt und der erste Vorlagenparameter unbenannt ist und eine andere Vorlage ist.
Seltsam, dass das bisher nie auffiel; möglicherweise Nebenwirkungen oder Interaktionen, die ich noch nicht verstanden habe. Muss ich morgen noch einmal frisch im Zusammenhang draufgucken.
In Cagliari passiert mit der Vorlage Commonscat etwas ähnlich, was vermutlich die gleiche Ursache hat? Was meinst du aber mit "benutzerdefinierten Ersetzungen"? Ich habe keine Ersetzungen eingestellt, die irgendwas an Vorlagen oder geschweiften Klammern ändern. Steak22:15, 1. Sep. 2012 (CEST)Beantworten
Du hast benutzerdefinierte Text-Ersetzungen am Start. Damit die nicht einen typografisch ungeschickt notierten Vorlagen-Namen, Datei-Bezeichner, Wikilink oder URL ummodeln können, werden Vorlagen syntaktisch analysiert und in schützenswerte und freie Bestandteile zerlegt, wie auch alle Linkziele vor dir geschützt werden. Spätestens bei der Zerlegung der Vorlage findet auch eine Standardformatierung statt.
Es ist vermutlich die gleiche Tücke, die vor ein paar Tagen bei der Fehlerbeseitigung zum Thema „Kommentar“ hineingekommen ist. Kommentar sowie andere Vorlagen innerhalb der Vorlage sind isolierte Fremdkörper. Bei unbenannten Parametern guckte das Skript dumm aus der Wäche, weil es plötzlich nicht weiterging.
Wieso speicherst du das überhaupt ab? Kontrollierst du die Änderungen nicht immer vor dem Speichern? Zum Fehler: Hängt vermutlich mit welchen zusammen, dich ich bereits weiter oben gemeldet habe. Steak13:54, 5. Sep. 2012 (CEST)Beantworten
Seufz. Ich hatte gehofft, diese Krankheit wäre inzwischen besiegt, ich prügel mich jetzt schon zwei Wochen mit Kommentaren nach dem Vorlagen-Namen herum; mal vor und mal nach Zeilenumbruch … Sollte heute abend endlich mal sauber laufen.
Bitte die Unannehmlichkeit zu entschuldigen.
@Steak: Nun maul ma nich. FA2010 hatte sich halt auf die gewohte Präzision verlassen und dachte, die beabsichtigte kleine Änderung im Quelltext sei in Ordnung. Nun hat es ihm heimlich die }} reingeschoben; sowas passiert.
Der Reparaturversuch von Anfang September hatte es noch nicht ganz gebracht. Jetzt wird die Situation mit einer anderen Methode detektiert; Rumprobieren in diversen Situation war bislang erfolgreich, läuft aber zurzeit noch. --PerfektesChaos20:04, 5. Sep. 2012 (CEST)Beantworten
Dieser hier hat eine andere Konstellation, der ich mich am Wochenende widmen muss: Es geht um einen Parameterwert, der ausschließlich aus einem Kommentar besteht. Kürzlich wurden Kommentare beim Vorlagennamen und gemischte Parameterwerte aus Text und Kommentar und Vorlagen in der Vorlage robust gemacht. Was den jetzt nun wieder aus der Bahn geworfen hat? Packen wir.
Bei der Entwicklung im April/Mai waren Vorlagen und Kommentare in der Vorlage prinzipiell berücksichtigt worden, und bei der Erprobung den Juni über an Hunderten von Artikeln alle aufgetretenen Kombinationen aufgefangen. Wie du selbst nach sechs Wochen und Hunderten von Artikeln gemerkt hast, ist das kein häufiges Phänomen.
Was mich beruhigt: Nur die wenigen Fortgeschrittenen mit benutzerdefinierten Ersetzungen sind betroffen.
Letzter Kommentar: vor 11 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
In Salerno ist das Verhalten bei den Interwiki-Links komisch, die als normaler Weblinks formatiert sind. Das Skript formatiert sie zwar um, lässt den vorherigen Link aber trotzdem stehen. Steak13:53, 5. Sep. 2012 (CEST)Beantworten
Du meinst {{lang|it|Festival del Cinema di Salerno}} als Linktitel. Vorlage als Linktitel von Wiki-URL hatte ich wohl noch nicht; analysiere ich.
Gedacht ist es so wie bei Giffoni Film Festival. Das erbt vom alten Link den Titel und formatiert URL in Wikilink um. Früher waren die Vorlagen normaler Text gewesen. Wer jetzt benutzerdefinierte Text-Ersetzungen verwendet, dem wird die Vorlage gesondert eingepackt, und dann ist das auf den ersten Blick nicht mehr im Linktitel zu sehen. Bei Wikilinks habe ich das wohl inzwischen im Griff, aber hier ist das ursprünglich ein Weblink gewesen.
Ich habe heute abend eine Lösung geschrieben, deren Auswirkungen in anderen Situationen ich aber noch durchtesten muss. Alle anderen offenen Angelegenheiten sind live und beantwortet. Morgen ist schönes Wetter; Mitte der Woche geht es weiter. Schönen Abend --PerfektesChaos22:48, 9. Sep. 2012 (CEST)Beantworten
Öff; beim letzten Mal hatte ich nur die }} gefixt; nun auch die Pipe, und die Analyse der Schwesterprojekt-Vorlagen diesbezüglich grundlegend verändert. Die bisherige Programmierung basiert auf der Version vom Frühsommer, die ohne Definition benutzerdefinierter Ersetzungen auch noch analog abläuft und das alles als normale Zeichenkette behandelt. Inzwischen wird aber die Vorlage in der Vorlage unter bestimmten Bedingungen unsichtbar, und die Zeichenkette hört an dieser Stelle auf.
RonMeier ist aus dem Urlaub zurück und schon wieder fleißig. Er greift auf eine Vorabversion zu, und ich möchte ihn erst 12–24 Stunden wirbeln lassen, bevor ich eine Version für alle Benutzer freigebe.
Die Tücke ist, dass in den Browser-Cache der Benutzer sich zurzeit noch die Umstellung von WSTM.4 auf WSTM.5 vollzieht. Das wird erst Ende September abgeschlossen sein. Anschließend werde ich den mit der Syntax im Speziellen befassten Teil des Skriptes in 7 unabhängige Module zerlegen. Dann kann ich in einem Teil einen isolierten Bugfix vornehmen und diesen hochladen, während ich woanders Neuentwicklungen vornehme. Im Moment geht es aber nicht anders, als dass mit jedem Bugfix auch alle neuen Programmteile live gehen und irgendwo Ärger machen.
Das auch einige auch von Deutsch nach Englisch zurückändern war mir bisher nicht aufgefallen. Wenig sinnvoll, da gegeneinander vorzugehen, ein Meinungsbild würde ich begrüßen. Deutschtümler finde ich leicht unfreundlich, würde dort aber nicht weiter darauf rumreiten. Ich jedenfalls mache die Änderungen nicht, weil ich an diesen Stellen Deutsch bevorzuge, sondern zur Vereinheitlichung, nachdem Deutsch dort nun einmal eingeführt wurde. Bisher hatte ich Deutsch an diesen Stellen für weitgehenden Konsens gehalten.
Der Sinn ist, dass dem deutschsprachigen Autor auch in einer Thai-, japanischsprachigen oder arabischen Wikipedia die Links auf die dortigen File- und Category-Namensräume verständlich angezeigt werden. Eigentlich ist das eher für den Artikeltext gedacht; als Interlanguage sehe ich das heute zum ersten Mal. Streng genommen ist es auch kein sauberes Interlanguage und auf eine Kategorie nicht so richtig zulässig. Kannst ja mal die history flöhen; wahrscheinlich nicht von einem bot, sondern manuell eingefügt.
Es macht ja erstmal nur auf einen möglichen Schreibfehler aufmerksam. Es gibt jede Menge Fälle, wo nur eine statt zwei öffnender oder schließender Klammern stehen, oder wo URL in Doppelklammern eingeschlossen sind. Nun magst du schaun, ob das mit den drei Klammern Absicht ist oder jemand mit zittrigem Daumen auf dem ] gelegen hatte.
Im konkreten Fall ist es folgendermaßen: Die öffnende Klammer von
[[Maximilian I. Joseph (Bayern)|Maximilian [I.]]]
wird von Mediawiki verwikilinkt; die dritte schließende Klammer steht zunächst außerhalb. Anschließend wird die eigentlich hinter dem Wikilink stehende Klammer wie ein nachfolgender Buchstabe in den Linktitel einbezogen und eingeblaut. Optisch also befriedigend.
Es gäbe alternative Lösungen:
Runde Klammern mag man wohl nicht, weil alles schon in runde Klammern eingeschlossen ist. Das ist aber bereits in <small> eingeschlossen und die Besonderheit damit schon bekundet; und dann noch kursiv angefangen. Die ganzen Klammern drumrum können dann eigentlich wegfallen; man sieht auch so, dass dies nicht nur ein einfacher Name ist.
Wenn man ] schreibt, ist das Skript ruhig und die nachfolgenden Autoren fluchen.
Auf jeden Fall wäre ein vor der eingeklammerten I. sinnvoll, weil es leicht dort zum Zeilenumbruch kommt.
Letzter Kommentar: vor 11 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Es wäre schön, wenn man analog zu den benutzerdefinierten Ersetzungen auch seine eigenen Warnungen für den roten Kasten erzeugen könnte, also etwa ['((da|mu)ß)', 'Bitte prüfe, ob das Wort $1 in einem Zitat vorkommt, und ersetze es anderenfalls durch $2ss!'], um mal ein hypothetisches Beispiel zu geben. --Schnark09:26, 12. Sep. 2012 (CEST)Beantworten
Grundsätzlich möglich; und wäre durch eine neue Komponente von .config zu realisieren.
Nachdem ich das noch zwei Wochen aussterbende WSTM.4 abgeschlossen und dessen letzten Reste zurückgebaut habe; weiterhin dieses neue Feature und die dafür erforderlichen Umbauarbeiten abgeschlossen habe, das 347kB-Syntaxmodul in sieben Einzelteile gesplittet habe und auch sonst ein robuster Zustand vorliegt, kann ich Näheres prüfen.
Besonders charmant daran ist, dass die Dateinamen und Inhalte von poem bereits von einer solchen Suche ausgeschlossen wären. Ich prüfe ohnehin, ob ich in den hook für dewiki-Vorlagen auch alle Zitatvorlagen aufnehme, und dann den Wert spezifischer Parameter von Text-Ersetzungen (und damit auch Fundstellen) ausnehmen werde.
Letzter Kommentar: vor 11 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Im Moment ist es – wenn mich nicht alles täuscht – so, dass auch wenn keine automatischen Ersetzungen vorgenommen, sondern nur Warnungen ausgegeben werden, die Seite neu geladen wird. Geschickter fände ich es, wenn in diesem Fall nicht der Umweg über Kommentar im Text -> neuladen -> Kommentar in Warnungskasten umwandeln gegangen würde, sondern die Warnungen direkt angezeigt würden. --Schnark09:26, 12. Sep. 2012 (CEST)Beantworten
Das möchte ich im Moment nicht anfassen.
Die meisten Bearbeiter machen auch die erste Syntaxpolitur und es gibt dabei immer etwas zu tun, so dass es auch immer Änderungen gibt. Nach der Überarbeitung wäre eigentlich auch der Anlass für die rote Kiste beseitigt. Der Fall, dass es nichts zu tun gäbe und nur die Kiste anstünde, ist atypisch.
Der Algorithmus, der über die Diffpage, nur Whitespace-Änderungen, rote Kiste usw. entscheidet, ist verzwickt genug. Bis auf Weiteres möchte ich nicht noch die fünfte Parallel-Baustelle aufmachen. Die Generierung der Meldung erfolgt über die Interpretation und Löschung des in den Quelltext eingefügten Kommentars. Die Direkt-Anzeige müsste unmittelbar die Fehlermeldungen auswerten und wäre komplett anders und neu zu schreiben.
Wenn mw.notification einmal robust läuft und eine ausführliche und verständliche Dokumentation dafür vorgelegt wurde, könnte ich über den Ersatz der bislang mw-freien Kisteneinbindung und in diesem Zusammenhang über deinen Vorschlag nachdenken.
Ich selbst nicht; aber wir haben seit heute eine neue MediaWiki-Version. Dort gibt es unter #JavaScript eine Veränderung betreffend mw.util.$content und das würde sich so auswirken müssen, dass die rote Kiste jetzt oberhalb der Artikel-Überschrift erscheint. Darüber liegt je nach Skin ein Bereich voller Bildschirmfensterbreite, was diese Helden nicht bedacht hatten.
Wann kriegen diese Wirrköpfe es endlich in den Schädel, dass man bei einer öffentlichen und weltweit angebotenen Bibliothek die Funktionalität bestehender Elemente niemals verändert, solange diese nicht völlig obsolet sind, und für zusätzliche Funktionalitäten neue Elemente oder Parameter schafft? Man brauchte hier offenkundig für das neue mw.notification eine Ansiedelung oberhalb des Titels, und anstatt dafür ein neues Element mw.util.$body zu schaffen und für die neuen Zwecke zu benutzen, hat man flugs Bedeutung und Inhalt des bestehenden Namens umdefiniert.
Es war die {{Infobox Schacheröffnung}} – die steht in keiner Kat. Bisher kannte ich nur die Vorlagen {{Schachbrett}}, Schachbrett-10x10, Schachbrett-8x10, Schachbrett-Chaturanga, Schachbrett-klein.
Hinzugefügt und live. Matt.
Weil ich dich grad hier hab: Schau doch mal auf diese Disku, ausgelöst durch diese history seit 4. September, aber halt die Füße still, bis sich der Geisterfahrer (in den nächsten Tagen) als Erster geantwortet hat. Danach gilt: Pro Benutzer nur ein Revert ist kein Edit War.
Es ist vom Typus her der gleiche Fehler, den Steak am Freitag betreffend Universität Straßburg gemeldet hatte; nur viel schöner mit zwei Kommentaren.
Ich hatte dies gestern bereits analysiert, bin mir aber noch nicht recht über die sichere Beseitigung im Klaren. Auch die Vorgeschichte durchschaue ich noch nicht. Ich meine, dass dies eigentlich schon mal ordnungsgemäß lief, aber bei einem Bugfix Ende August eine unerwünschte Nebenwirkung hineinkam.
Zurzeit versuche ich, eine Liste von Miniatur-Testfällen zusammenzustellen mit allen erdenklichen Kombinationen von Kommentaren, mehrfachen Kommentaren, an verschiedenen Stellen, mit Restwert oder ohne, Vorlagen, Links und Leerzeilen in der Vorlage. Sonst klappt der eine Bugfix und aus dem nächsten Loch grinst mich wieder ein anderer Maulwurf an.
Letzter Kommentar: vor 11 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Wenn man die benutzerdefinierte Ersetzung aktiviert hat, dass nach Doppelpunkten am Zeilenanfang ein Leerzeichen gesetzt wird, kann es zu unschönen Effekten kommen:
Stimmt; mit zwei Doppelpunkten war mir das bislang auch nicht untergekommen. Die Doku habe ich entsprechend verbessert; die Doppelpunkte brauchen beim Suchen ein Pluszeichen (für „eins oder mehrere“) und Klammern, und damit die Anzahl gleich bleibt ein $1 als Ersetzung des Klammerausdrucks.
Wie in der dortigen Anmerkung beschrieben sollte das aber ersetzt werden durch style=; eigentlich sucht man nur nach {| am Zeilenanfang und die Doppelpunkte können aus der Bahn werfen. So lautet auch die klare und verständliche Syntax für Tabellen.
Letzter Kommentar: vor 11 Jahren10 Kommentare4 Personen sind an der Diskussion beteiligt
nach WSTM ist der commons-link (4. Einzelnachweis) nicht mehr erreichbar. aus: File:Railsgrandechaloupe.jpg?uselang=de das irritiert nur wird: File:Railsgrandechaloupe.jpg%3Fuselang%3Dde Gruß --RonMeier (Diskussion) 12:15, 17. Sep. 2012 (CEST)Beantworten
Behebung bereits auf meiner Festplatte fertig; interne Testphase läuft.
Wobei es ein simples :Datei:Railsgrandechaloupe.jpg auch schon tun würde; das ist dann genauso deutsch.
Und weil wir gerade beim Thema sind: commons:File: ist fast immer Unfug. Die Unterscheidung wäre nur interessant, wenn es unter gleichem Namen auf commons und in der deWP unterschiedliche Dateien gäbe. Das ist auf Dauer wiederum auch Unfug: Wenn sich diese Dateien absichtlich durch irgendetwas unterscheiden sollen, dann müsste sich ihr Name ebenfalls klar erkennbar unterscheiden; nur vorübergehend (während eines Transfers oder bei der Bildnachbearbeitung und Re-Formatierung) kann das mal auftreten.
Links in fremde Projekte und URL sind hingegen immer Blaulinks. Ein Fehler im Dateinamen ist so nicht erkennbar. Über die lokale :Datei: (und Media:) ist der Dateiname im Fehlerfall aber ein redlink.
Seit einiger Zeit ist standardmäßig für alle Benutzer das MediaWiki:Gadget-Direct-link-to-Commons.js aktiv. Das bedeutet: Sofern es lokal (deutsch) weder eine eigene Dateibeschreibungsseite noch eine lokale Diskussion (etwa um noch strittige Lizenzen) gibt, wird sofort nach dem Klick auf die Dateibeschreibung auf Commons weitergeleitet.
Benutzerdefiniert, weil es theoretisch möglich ist, dass die Datei sowohl lokal wie auf Commons vorhanden ist. Also muss man nach einer Veränderung zu Datei: einmal draufklicken. Wenn man dann auf Commons landet, hat es nur eine einzige gegeben. Nach meiner Kenntnis gibt es in der deWP aber eigentlich nur 30–50 Fälle von Verlinkungen commons:File: und davon möglicherweise eine Dublette, oder diese auch schon nicht mehr. Lieben Gruß --PerfektesChaos22:44, 17. Sep. 2012 (CEST)Beantworten
In Bezug auf die Commonslinks habe ich noch das Problem festgestellt, dass benutzerdefinierte Ersetzungen diese Links ändern, obwohl sie danach logischerweise nicht mehr funktionieren. Kannst du die schützen, damit das nicht mehr passieren kann? Steak09:52, 18. Sep. 2012 (CEST)Beantworten
Dir geht es um das Minuszeichen in der Commons-Vorlage? In WSTM.4 waren die jeweils ersten Parameter der Schwesterprojekt-Vorlagen geschützt gewesen; zurzeit unter WSTM.5 kenne ich die Anzahl der Zeichen und beabsichtige, diesen ersten Parameter auch wieder abzuspalten und bei Bedarf gegen Text-Ersetzungen zu schützen. Ich bin aber noch damit beschäftigt, die ganzen anderen Veränderungen alle robust auszutarieren. RonMeier testet heute beispielsweise den ultimativen Bugfix für Kommentare irgendwo in einer Vorlage. Ich kann immer nur einen Schritt nach dem anderen einfädeln und habe einen reichlichen Rückstau an Sachen, die eingeführt werden sollen.
Der ist da irgendwie im Verlauf des Septembers bei einer Aufräumaktion hineingerutscht. Auf der Festplatte bereits behoben; bis ich aber dazu komme, das qualifiziert hochzuladen, kann es später Nachmittag werden, oder erst abends. LG --PerfektesChaos13:22, 19. Sep. 2012 (CEST)Beantworten
Letzter Kommentar: vor 11 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
In Anschlag (Halver) meckert das Skript wegen dem Ref in der Überschrift. Da ich mir nicht sicher bin, ob tatsächlich was falsch ist (HTML-Ausgabe ich jedenfalls richtig), oder ob das Skript fehlerhaft ist, melde ich es lieber hier. Steak17:37, 20. Sep. 2012 (CEST)Beantworten
Tja, was will man da machen? Und was kann das Skript da tun außer warnen? Die riesige [1] in der Überschrift sieht einfach grottig aus, und im Inhaltsverzeichnis würde das auch nicht besser. Technisch ist es in Ordnung und war nur ein mahnender Hinweis. Die beste Lösung dürfte sein, das ref an das Ende des Absatzes zu schieben und einzuleiten mit „Der vorstehende Absatz basiert überwiegend auf …“ (Wenn aber jemand etwas hinzufügt, dann wäre die Aussage vom Beleg ja sonst nicht mehr abgedeckt. Deswegen sind solche Pauschal-Belege immer doof.) Oder einfach in einem Abschnitt „Literatur“ verbuchen.
Zum Thema Schach und mehr habe ich mich oben geäußert.
Sorry, da stehen an diesem Wochenende Änderungen an; ich kümmere mich erstmal um RonMeier, der den Vorkoster spielt, und anschließend um Steak und die sonstigen, die noch eine eine Woche alte Version verwenden. Bis gleich --PerfektesChaos10:57, 22. Sep. 2012 (CEST)Beantworten
Zum Bug: Da war beim Aufräumen nach meiner Erprobungsphase durch Edit-Unfall eine Zeile verlorengegangen; jetzt neuer Schub an Edits live.
Zur Lage: Seit gestern Abend ist die neue Parameteranalyse der Medieneinbindung in den Feldversuch gegangen. Die alte Technik von 2010 mit RegExp wird gerade schrittweise herausoperiert; sie war meinen Anforderungen nicht mehr gewachsen. Nebenbei heißt thumb jetzt mini, während miniatur in der Regel so bleibt.
Zu dem Artikel: Das Teil hat mal erfolgreich kandidiert und wurde syntaktisch blankpoliert und gut in Schuss gehalten; da sind keine Böcke drin.
Als Vorkoster braucht man Frustrationstoleranz. Es muss beim loader.load für die enWP mit großem S aus dem r ein d gemacht werden. Dann kommt bei jedem Edit eine maximal einen Edit alte aktuelle Version aller Module und nicht erst zu jeder vollen Stunde. Das d steht für Developer, während r für Release steht. Bevor ich eine r-Version mit nennenswerten und nicht dringlichen Änderungen freigebe, lasse ich RonMeier einen Tag blind drüberlaufen. Die d-Version des Haupt-Syntaxmoduls steht jetzt auf 5.43, während das letzte freigegebene r noch 5.37 hat und vom 12. September ist.
Sieht passend aus. Wenn du das an Stampa ausprobierst, müsste er dir die Pipes von hinter den Infobox-Parametern nach vorne ziehen und über 1= darauf hinweisen, dass ganz zum Schluss der Vorlage eine einsame Pipe steht. Nächste Antwort dann ganz unten. --PerfektesChaos12:08, 22. Sep. 2012 (CEST)Beantworten
Letzter Kommentar: vor 11 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Was hälst du von der Idee, künftigen Anwendern die Auswahl zu lassen, welche Version von WSTM sie nutzen wollen? Da die aktuelle Version immer wieder Änderungen unterworfen ist, könntest du die zurückliegende Version (aktuell wäre das Version 4) ebenfalls vorrätig halten und Nutzern ermöglichen, diese zu nutzen, ohne dass durch laufende Änderungen Bugs im Betrieb auftreten. Das wäre natürlich mit höherem Aufwand verbunden, würde aber die Einsetzbarkeit des Mods imho erhöhen. Steak11:24, 22. Sep. 2012 (CEST)Beantworten
Da halte ich leider gar nichts von.
WSTM.4 ist auf einem eingefrorenen Zustand von Mitte Juni 2012 und inhaltlich aus 2011. Ich weiß schon längst nicht mehr, was dort vorgeht.
WSTM.4 kann viele neue Funktionen nicht, so etwa die Normdatenberichtigung und vieles andere. Auch größere Teile der Doku passen nicht mehr dazu; Benutzer würden in der Doku haufenweise Behauptungen finden, die aber gar nicht funktionieren. Ich komm schon kaum dazu, die eigentliche Doku zu WSTM.5 aktuell zu halten. Wenn sich jemand beschwert, weiß ich überhaupt nicht, was da los ist.
Der Umstellungsprozess ist schrittweise erst sechs Wochen ab Anfang Juli und danach ab 20. August für die restlichen Benutzer gelaufen. Für Normalbenutzer lief er ziemlich glatt; es sind fast nur Fortgeschrittene mit benutzerdefinierten Ersetzungen von Bugs betroffen, weil dort die fortgeschrittene Syntaxanalyse abgeht. Seit gestern ist der Umstellungsprozess abgeschlossen.
Die Module von WSTM.4 sind nicht kompatibel zu denen von WSTM.5 – ich müsste permanent zwei Systeme austesten und würde selbst völlig durcheinanderkommen.
Ich versuche gleichwohl, vor einer planmäßigen Live-Schaltung möglichst alle Bugs zu finden und lasse RonMeier auch erst ein Weilchen drübergehen (siehe oben). Wenn aber eine echte Fehlfunktion für alle sofort beseitigt werden muss, geht der Quellcode im momentanen Entwoicklungszustand live.
Letzter Kommentar: vor 11 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Seit gestern oder vorgestern tut sich bei vielen Artikeln einfach nichts mehr, obwohl es was zu tun gäbe, z. B. Stampa. Hast du irgendwas verändert oder liegt das an meinem System? Steak11:27, 22. Sep. 2012 (CEST)Beantworten
Einfach früher meckern.
Eine Weiche, die euch aus der Neuentwicklung der Medieneinbindung hätte herausgeleiten sollen, hatte leider nicht angeschlagen und euch für mich gehalten, so dass vermutlich alle Artikel mit Bildern auf ein Entwicklungsproblem gelaufen sind (weil ich halt mehr Funktionen auf der Festplatte habe).
Ich mache zwar nach uploads einen Routine-Test an einem zufälligen Artikel, aber wenn der hier zufällig kein zu veränderndes Bild hatte, bekomme ich das Verhalten der Releases nicht mit. Vielmehr verlasse ich mich darauf, dass schon eine Beschwerde auflaufen würde, weil oft nur sehr spezielle Konstellationen auf Bugs laufen, die sich nicht mit dem außerdem vorhandenen Schnelltest finden lassen. Der analysiert automatisch gegen zig Mini-Artikel von 100 oder 200 Zeichen, weiß was herauskommen muss, und findet triviale Fehler durch Vergleich mit dem jeweils erwarteten Ergebnis. Komplexe Situationen packt das aber nicht. Außerdem arbeitet das lokal auf meiner Festplatte und ohne Browser.
Ich habe wegen dieses Bugs den aktuellen Status auf die r-Version hochgeladen; die Updates sehen so aus.
Im vorliegenden Fall hätte dir folgendes geholfen: Deinem eigenen Eintrag zufolge hast du Firefox. Mit Strg+Umschalt+J bekommst du die Fehlerkonsole (oder auf vielen anderen Wegen, und mit anderen Browsern analog). Wenn nix mehr läuft, dann diese einschalten, begrenzen auf Error (Kreuz auf rot) und gucken, wer warum abschmiert. Wenn ich das bin, dann einfach die ganze JS-Meldung mitsamt Zeilennummer C&P (und wie gewohnt Nennung des Artikels) hier auf die Disku und ich kann punktgenau den Fehler aufsuchen; meist reicht mir ein Blick auf die Zeile und ich ahne schon, wo es hakt.
Letzter Kommentar: vor 11 Jahren9 Kommentare3 Personen sind an der Diskussion beteiligt
Hallo, bei manchen – und nur bei manchen – Bearbeitungen will ich den automatischen Start unterdrücken. Z.B. bei Fix von Referenzfehlern wie hier und hier, Referenzfehler sind ohnehin frickelig, weil man da gleichzeitig Diffs aus der Versionsgeschichte aufhaben muss. Ein weiterer Grund könnten Edits in schwer umkämpften Artikeln sein.
Mit mw.libs.WikiSyntaxTextMod.config.load.inhibit = true; kann ich den automatischen Start verhindern. Das läßt aber auch den Portlet-Link verschwinden (obwohl portlet: true gesetzt ist), mit dem ich hinterher manuell starten könnte. Auf der Firebug-Kommandozeile finde ich dann noch WikisyntaxTextMod_IsAppropriate, WikiSyntaxTextMod_Run und WikiSyntaxTextMod_About. Letzteres läuft.
Wenn ich die automatischen Änderungen für eine Bearbeitung verhindern möchte, dann lade ich die Seite neu, nachdem mir der Versionsunterschied angezeigt wurde. Das funktioniert einfach und zuverlässig, mit dem einzigen Nachteil, dass man dann den ganzen Artikel bearbeitet, auch wenn man vorher nur einen Abschnitt bearbeiten wollte. --Schnark09:19, 24. Sep. 2012 (CEST)Beantworten
Danke, Schnark, für die Kurzfassung. Hier die Langversion:
load.inhibit und Portlet:
load.inhibit ist dafür vorgesehen, dass Anwender die volle Kontrolle mittels JavaScript übernehmen. Will sagen: API .
Es passiert tatsächlich – nichts. Und das muss auch so sein und wird auch so bleiben. Verfügbar sind dann im Wesentlichen nur die Funktionen .api.load() und auch .api.run() – vorgesehen dafür, dass ein API-Anwender nach eigenem Ermessen die weitere Ausführung steuert. Ausgeführt wird rein gar nichts.
Das Portlet-Link wird also tatsächlich nicht angezeigt und würde API-Skripten auch bös in die Suppe spucken.
Deine konkrete Aktion wäre durch WikiSyntaxTextMod_Run() aus der Konsole nachzuholen gewesen. Das macht alles das, was sonst automatisch (autorun) passieren würde.
Moderne Browser verweigern das javascript: in der URL-Adresszeile möglicherweise aus Sicherheitsgründen. Alternativen oder ein Bookmarklet für: javascript:WikiSyntaxTextMod_Run()
Generell regt mich die von dir geäußerte Frage dazu an, unten auf meiner ToDo-Liste Cookies anzuhängen.
Mit allgemeinen Browser-Werkzeugen ließe sich ein Diese-eine-Seite-nicht-auto-Cookie setzen (etwa mit dem Wert 1, true etc.), das aber das Portlet-Link generiert und nur den letzten Start der Textbearbeitung unterbindet. Ohne Belastung der Versionsgeschichte lässt sich das beliebig auf Ein und Aus schalten. Ich kann sogar eine Spezialseite anbieten, auf der ein einfacher Klick das Cookie umswitcht.
Ich selbst und Schnark steuern so unsere Skripte.
Der WikEd-Fehler kam vermutlich durch unerwartete Vorgeschichtenaktionen zustande; ähm, ich hoffe, du verwendest WikEd?? Sonst wäre das arg seltsam.
Nebenbei: Ich werde mich in diese unerquickliche Debatte zumindest mit einer kurzen Stellungnahme einbringen müssen. Die Hilfeseite ist noch drei Tage gesperrt; bis dahin wäre ein breites Votum für eine allgemeinverständliche Hilfeseiten-Empfehlung als Schlüsselwort sinnvoll. Heutzutage noch zu streiten, ob man 2008 ohne ein MB ein Schlüsselwort habe übersetzen dürfen, ist recht müßig.
@Schnark: Funktioniert bei mir aktuell nicht. Z.B. in Stift Rein, Firefox (15.0.1) fragt:
To display this page, Firefox must send information that will repeat any action (such as a search or order confirmation) that was performed earlier. [Resend] [Cancel]
Ich bin IIRC vor einer Weile noch über die History auf die Version vor dem Diff zurückgekommen, das klappt ebenfalls nicht (mehr?), wenn ich von dort aus einfach wieder einen Diff starte sehe ich die von WSTM bearbeitete Fassung.
Cookies: Abfrage nach einem händisch hier gesetzten Cookie hatte ich gestern in meiner Benutzer:Ivla/vector.js um .inhibit = true herum eingebaut, statt wie zunächst geplant um den ganzen WSTM-Start. Und dass das nur "nur den letzten Start der Textbearbeitung unterbindet" hatte ich nach der Doku zumindest erhofft. Das Portlet verschwindet aber auch, wenn ich ohne Cookie-Experiment .inhibit = true setze, extra in Half-Bots common.js probiert u. daher hier Cookie nicht erwähnt.
WikEd: Läuft hier mit, ohne häufig benutzt zu werden (klarer Fall für weiteres Cookie). War auf aus, aber mitgeladen, angefasst hatte ich es nicht. Was ist mit unerwartete Vorgeschichtenaktionen gemeint?
WikiSyntaxTextMod_Run() müsste ich dann in ein weiteres Portlet packen.
In der Doku kommt erst Automatischen Start unterdrücken, erst weiter unten noch der Abschnitt "Laden ohne Ausführung", nur da lässt sich folgern, dass nach .inhibit = true vielleicht der Portlet-Link nicht mehr ausreichend sein könnte.
MANGELSORTIERUNG: Seufz. Überflogen, aber gerade keine Zeit, wäre auch mehr was für einen eigenen Abschnitt hier. Grüße,-- IvlaDisk.16:01, 24. Sep. 2012 (CEST) P.S.: Wieso gibt es hier BK mit Ron, obwohl er einen neuen Abschnitt aufgemacht hat?Beantworten
Normales inhibit=true soll wirklich alle Eigenaktivitäten von WSTM abschalten, damit es nicht ungefragt irgendwo dazwischenfunkt. Aber beim Durchsehen des Codes fand ich eine andere Variante: Die .portlet-Details könnten leicht einen zusätzlichen Parameter erhalten, der dann bewirkt, dass das portlet trotz inhibit=true generiert werden soll.
Ich weiß nicht, ob du switch guckst; aber das erinnert an die Parodie auf Tim Mälzer, der dann leicht die Variante für muslimische Veganer mit Broccoliallergie in einem Extratopf abzweigt.
Das würde sich aber so oder so bei mir bis in den Oktober ziehen.
Für den Anfang bekommst du im FF am leichtesten ein neues Lesezeichen, wo du als URL einträgst: javascript:WikiSyntaxTextMod_Run() – dann hast du das Jodeldiplom.
Es beruhigt mich, dass du WikEd geladen hast. Sonst hätte mich die Fehlermeldung arg irritiert. Die Situation, dass WikEd geladen aber deaktiviert ist, kapiert WSTM im normalen Ablauf eigentlich. In dieser Situation ist nämlich wikEd.frameBody usw. gerade null und WSTM versucht nicht mehr, sein Ergebnis mit WikEd zu synchronisieren (sonst würdest du nämlich keinerlei Veränderung sehen können). Wenn WSTM allerdings auf unvorhergesehene Weise an das Bearbeitungsfeld gelangt (beim WSTM-Laden war WikEd aktiv; danach wurde WikEd abgeschaltet und danach WSTM gestartet), könnte WSTM durcheinanderkommen. Das durchschaue ich grad nicht.
Wenn du DEFAULTSORT-Fan bist, dann melde dich bei Gelegenheit hier; wenn du den deutschsprachigen Mainstream bevorzugst, dann auf HD:KAT.
Es gibt nur eine einzige Disku-Seite, auch wenn du nur einen einzigen Abschnitt bearbeitest. Wenn RonMeier den 10. und du etwas später den 11. Abschnitt bearbeiten würdest, dann kommt es trotzdem zum BK, weil Wiki sich die Versionsidentifikation der Seite gemerkt hat, mit der du angefangen hast zu arbeiten und RonMeier diese Version inzwischen überschrieben hat.
Portlet: Ich finde die Idee, zunächst ohne WSTM zu starten, es aber später doch laufen lassen zu wollen, nicht sooo ausgefallen. Ein weiterer Grund zu den bisher genannten wäre, zunächst mal einen Diff nur mit den eigenen Änderungen sehen zu wollen. Fernsehen habe ich nicht, das Veganerproblem ist mir aber aus dem RL bekannt, unabhängig von deren religiöser Ausrichtung. Das Portlet könnte ich mir auch selbst mit javascript:WikiSyntaxTextMod_Run() reinschreiben, je nachdem, wie Cookie gesetzt ist. Aber ich hätte auch nichts gegen eine Option, eilig ist das aber sicher nicht.
WikEd sollte nur vorgeladen, nicht aber angefasst worden sein, da kann ich nachträglich aber nicht für garantieren. Ganz sicher aber springt WikEd hier manchmal an, ohne dass ich den Button dafür gedrückt habe. Sehr, sehr selten, noch nicht näher angesehen.
Defaultsort-Fan bin ich nicht, im Allgemeinen finde ich Eindeutschung von Variablen (jetzt nicht speziell auf WP bezogen) nicht so glücklich, ziehe aber eine weitgehend einheitliche Schreibweise vor. In de-WP ist das an sich abgefrühstückt, die meisten sind deutsch, dann sollte die Änderungsrichtung wegen Einheitlichkeit auch dahin gehen. Ich kann mit beiden Varianten leben, ob ich Code oder Doku nicht verstehe hängt nicht an der Sprache. Bzw. doch, aber das Problem ist nicht Deutsch oder Englisch, das Problem ist − gelegentlich − Informatiker-Slang, also Mathematiker-Sprache. In längere Diskussionen dazu werde ich mich (hoffentlich) nicht groß einklinken, zu wenig Zeit.
Das mit den BKs beim Bearbeiten von verschiedenen Abschnitten liest sich hier anders. Immerhin werden sie wieder angezeigt, letzte Woche habe ich die teilweise nur zufällig durch Auftauchen von neuem Text in Diffs bemerkt, einzelne Andere hatten wohl auch Probleme.
Nur kurz zu BK: Werde der Angelegenheit nachgehen. Es gibt möglicherweise einen Mechanismus, die bei konstanter Anzahl/Abfolge der nur durchnummerierten Abschnitte parallele Bearbeitungen verschiedener Abschnitte ermöglicht, indem der Austausch der einzelnen Inhalte erlaubt wird. Kommt aber ein neuer Abschnitt hinzu oder wird einer entfernt, ist die Nummerierung nicht mehr eindeutig und es käme zum BK. Der Umherirrende weiß sowas. Liebe Grüße --PerfektesChaos13:16, 27. Sep. 2012 (CEST)Beantworten
Ich muss meine Anleitung präzisieren: Neuladen mit Hilfe der entsprechenden Browserfunktion führt nicht zum gewünschten Ergebnis, man muss den Cursor in die Adresszeile stellen und dort die Eingabetaste drücken. --Schnark09:34, 25. Sep. 2012 (CEST)Beantworten
Danke. Nicht intuitiv, ich seh mich schon in ein paar Wochen grübeln: wie ging das noch, ich hatte da doch mal nachgefragt... ;-). Aber was solls, es funktioniert. Dass das Verhalten bei mir mal anders war könnte auch daran liegen, dass ich da Artikelbearbeitungen fast ausschließlich über Dein Normdaten-Skript gestartet hatte. Gruß, -- IvlaDisk.12:31, 27. Sep. 2012 (CEST)Beantworten
Grummel. Da war ich etwas zu flott beim Ausputzen. Ein stiller Ruckler; gut aufgepasst! Sollte jetzt wieder alles aktuell sein.
Wenn du grad da bist: Schau doch mal hier vorbei und äußere dich als schlichter Benutzer.
Ich kann an deiner common.js nichts Unartiges finden; ich verwende die identische Regel für commons:File:→:Datei:, die hier gegriffen hatte.
Gleichwohl einige Anmerkungen dazu:
Wenn du mal einen ganz schnellen Browser erwischst, könnte es sein, dass das mw.loader.load bereits fertig ist, bevor die .config.mod. definiert sind. Kam schon vor. Ich würde das mw.loader.load eher ganz ans Ende setzen.
Die Adresse wäre mittlerweile //www.mediawiki.org/w/index.php?title=User:PerfektesChaos/js/paneMarker/r.js&action=....... usw.
Dein alter Freund Schar Kischatim ist übrigens mal wieder aufgefallen; allerdings stellt sich die Angelegenheit nunmehr in ganz anderem Licht dar (mit Unterabschnitten 1–10).
die Änderung paneMarker funktioniert so nicht. In die Diskussionsrunde werde ich mich nicht einklinken, da ich a: keine Argumente einbringen kann, und b: Art und Auftreten des mb bei mir die Galleproduktion erheblich steigern - das ist ungesund. (Er scheint viel Frust zu haben, den er glaubt, hier in der WP abreagieren zu müssen) Gruß --RonMeier (Diskussion) 22:45, 24. Sep. 2012 (CEST)Beantworten
Die ersten beiden sind so, wie ich mir das vorstelle. Danach fängt er an Zeilenumbrüche und Sternchen zu klauen und schmuggelt ein f dahinter; mysteriös. Da hätte er die ersten beiden auch gleich ruinieren können. Diese Bock packe ich heute abend nicht mehr. --PerfektesChaos23:20, 26. Sep. 2012 (CEST)Beantworten
Ausgeschlafen sehe ich jetzt wenigstens die Ursache; die gute Daniela schrieb bei den ersten beiden sinngemäß:
[[Spezial:ISBN-Suche/978-3-426-65469-9]]
Das ist korrekte Syntax und funktioniert auch; so werden unsere normalen magischen ISBN umgewandelt.
Danach heißt es
[[Spezial:ISBN-Suche/ISBN 3-502-14006-5]]
Auf die Idee war bislang keiner gekommen, und das Skript hatte hinten fünf Zeichen zuviel, die bei der Berechnung Konfusion verursachten. Es funktioniert aber (wusste ich auch noch nicht), und ich werde mir bis zum Abend etwas ausdenken, das bei beliebigen Angaben nichts versaubeutelt und die Varianten unterscheiden kann.
Danke. und gleich noch ne Frage hinterher. Ich möchte in Abhängigkeit eines Schlüsselwortes, das vor einem Wikilink steht, im Textteil des Wikilinks etwas ändern. Ist das mit WSTM5 machbar? Ich hab schon probiert, ich kriegs nicht. Gruß und bis morgen --RonMeier (Diskussion) 23:20, 27. Sep. 2012 (CEST)Beantworten
Erstmal Nachtrag zu dem Spezial:ISBN – Funktion wurde Mitte November 2011 zuletzt geändert; mindestens seit einem Jahr hatte niemand diese lustige Formatierungs-Idee.
Dann nehme ich an, es geht um den Dativ vor Wikilink; gestern um 20:00 und 12:00–14:00? Ich drösel mal deine common.js auf:
Hinter dem von Schnark kopierten .bind(........) fehlt als Abschluss ein Semikolon. Das könnte Ursache sein für einiges, von dem du vermerkt hattest, dass es in letzter Zeit nicht funktioniert habe; die common.js wird für die Übertragung komprimiert und die Zeilenenden fallen weg. Das Semikolon markiert das Ende der Anweisung.
Ja commons:File geht jetzt, es lag wohl an dem fehlenden Semikolon. aber der paneMarker will immer noch nicht so recht (keine Farbe) und auch der Dativ hakt. Nach wildem Ausprobieren läuft nun ein Teil, jedoch nur dann, wenn ich im Ersetzungsteil des Epilogs nur eine eckige Klammer einsetze. Wo ist mein Fehler? Gruß --RonMeier (Diskussion) 17:44, 28. Sep. 2012 (CEST)Beantworten
Alle diese Macken haben irgendwo eine Ursache. Diese gilt es zu finden.
paneMarker hat eine täuschend ähnliche URL. So geht das:
Die zweite Version ist eine statische URL und liefert HTML, und die Seite, auf die diese URL verweist, existiert gar nicht; statt „r.js“ heißt sie „r.js&action=raw&ctype=text/javascript&ma“...
Was den Dativ mit der eckigen Klammer angeht, werde ich dies auf den späten Abend selbst erproben. Vielleicht machst du keinen Fehler, sondern das Skript verzählt sich um eins?
An die Stirn klopf - ich hab doch wegen eines defekten Motherboards seit kurzem einen neuen Rechner und bei dem war bis eben in NoScript das Wikimedia noch nicht freigegeben. Der paneMarker läuft jetzt also. Pardon für die unnötigen Übungen. Gruß --RonMeier (Diskussion) 22:16, 28. Sep. 2012 (CEST)Beantworten
War ein Bug bei mir.
Die Ersetzung war in einem ersten Schritt ordnungsgemäß ausgeführt worden.
Nachgeschaltet ist eine weitere Phase: Wenn die Ersetzung ]] enthält, dann müssen die Begrenzungen von Linkziel und Linktitel neu justiert werden. Käme etwa anschließend ein weiterer Ersetzungswunsch hinzu, würde das zuvor vielleicht vereinheitlichte Link nicht erkannt werden. Außerdem werden intern auf die umgemodelte Verlinkung wieder Standardformatierungen angewendet.
Du hast eine Lücke gefunden: Wird das Linkziel nicht verändert (false) und beginnt das Ergebnis der Ersetzung mit ]], dann wurde irrtümlich der Schalter gesetzt „Es hat sich nichts geändert.“
Gefixt und für dich live. Deine Dativ-Erfahrungen würde ich dann gern das Wochenende über abwarten.
Die Geschichte mit NoScript würde ich gern verstehen. Ich habe den auch; wahrscheinlich meinst du die „Positivliste“? Das wäre ein Aspekt, der auf WP:JS thematisiert werden könnte.
NoScript: fürs Arbeiten mit WP müssen wikipedia.org, wikimedia.org und eben mediawiki.org (nicht wie oben von mir geschrieben wikimedia) freigegeben sein.
Dativ: viel werde ich wohl am Wochenende nicht schaffen.
War mein Fehler. Irgendwie war schon seit einem Jahr keiner mehr an dem Feature dran? Es musste das Pipe-Symbol virtuell vor den Linktitel gesetzt werden, damit es dort gefunden werden kann. Für dich live; Gute Nacht --PerfektesChaos23:17, 29. Sep. 2012 (CEST)Beantworten
Ganz gut ist es leider noch nicht. Wird der Epilog mit der Pipe begonnen, müssten die eckigen Klammern ]] ja das Ende des Suchbereichs für den Epilog sein. Jetzt wird nach anfänglicher Übereinstimmung irgendwann im Folgetext eine Ersetzung vorgenommen. Gruß --RonMeier (Diskussion) 15:18, 30. Sep. 2012 (CEST)Beantworten
Beispiel: aus: Die Spannungen im Alltagsleben in Deutschland nach dem Ersten Weltkrieg ergaben sich neben der Niederlage, dem Verhalten der Siegermächte wird: Die Spannungen im Alltagsleben in Deutschland nach dem Ersten Weltkrieg ergaben sich neben der Niederlage, den Verhalten der Siegermächte
Diesmal liegt der Ball wenigstens bei dir. Du müsstest deinen RegExp entsprechend feilen.
„Epilog“ ist alles, was auf das Linkziel folgt.
Du könntest nach der Pipe folgen lassen:
(\\|[-A-Za-zÄÖÜäöüß0-9 ]+)em\\b
Das begrenzt auf ein oder mehrere Wörter, auch 18-jährige, stoppt aber an Kommata und Satzende sowie am Ende des Linktitels.
Bin grad gekommen und muss meditieren, ob dieses Dings nun endgültig WSTM.chr.lang oder WSTM.lang.chr heißen soll. Bin mir noch nicht ganz schlüssig, aber es sollte nur eine Variante sein. Es geht um chr=Schriftzeichen und lang=Sprache.
Eigentlich scheint er der Problemstelle nach über ein HTML-Entity für ein japanisches Schriftzeichen gefallen zu sein. Ich find bloß grad keins?
Ich bin etwas zu groggy zum Tüfteln und würd gern drüber schlafen; der Bug scheint schon seit mindestens einem Monat vorhanden zu sein, das Problem taucht also nicht sehr häufig auf.
Anders herum: Unter „Publikationen“ steht bei „Nitchū yūkō no suteishi“ ein Schriftzeichen, dass es weltweit nicht gibt, sondern das nur jemand auf seinem PC hatte: Private Use Zone, Kodierung U+E93F (59711). WSTM stellt diese ungültigen Zeichen als HTML-Entity dar. Benutzer:Mps kann dir vielleicht sagen, welches Zeichen dort eigentlich stehen müsste. Aus diesem Grund ist der Artikel auch gelistet bei Benutzer:Schnark/Wartung/Privat.
Erste Diagnose: Die Bildlegende stand nicht am Schluss, sondern die 500px kamen noch hinterhergeklappert. Das sollte jetzt umsortiert werden; ging eigentlich auch schon mal. Fix im Lauf des späteren Abend. --PerfektesChaos20:04, 30. Sep. 2012 (CEST)Beantworten
Letzter Kommentar: vor 11 Jahren6 Kommentare2 Personen sind an der Diskussion beteiligt
Ich will gerade das Satzzeichen nach einer referenz-Angabe mit config.mod.url nach vorne schieben und scheitere daran, dass ich im Ersetzungsteil des Prologs nicht Teile aus dem Epilog referenzieren kann, da dort die Nummerierung ja wieder von vorn beginnt. Wie kann man das realisieren? Gruß --RonMeier (Diskussion) 21:18, 30. Sep. 2012 (CEST)Beantworten
Das geht nicht auf die leichte Tour. Mühsam ernährt sich das Eichhörnchen:
Nur im Skript ist noch aus der Umstellungszeit ein Dummy drin; die neu geschaffene Einheit, die sich mit ungeklammerten URL beschäftigt, hat noch ein provisorisches „false“ drin, weil zur Zeit ihrer Programmierung das neue .config.mod.url noch nicht so genau bekannt gewesen war. Stand nur in der Doku der Funktion, aber kein auffälliges TODO.
Zur Stunde bringe ich erstmal die URL selbst rüber; jetzt muss ich mich mit Prolog und Epilog beschäftigen.
Wenn dies fertig, dann testen und danach live.
Nebenbei lässt sich mit folgendem Konstrukt die gleiche Definition sowohl für .url wie auch für .wikilink nutzen:
Letzter Kommentar: vor 11 Jahren11 Kommentare3 Personen sind an der Diskussion beteiligt
Guten Morgen, WSTM hat mir eben in diesem Artikel alle (oder einige) thumb auf mini geändert, nicht auf miniatur. Hab ich was verpasst und diese bisher sehr seltene Variante soll jetzt immer genommen werden, oder ist das ein Fehler? Ah, oben hast Du es nebenbei erwähnt, aber eben nur nebenbei. Hilfe:Bilder zählt alle drei Varianten auf, auf der dortigen Diskussion sehe ich auf die Schnelle nichts zu mini. Ich finde es aber eher unlustig, auf die bisher am wenigsten verbreitete Version umzustellen. Die sollte man meiner Meinung nach ganz schnell wieder einstampfen. Oder auch miniatur, ist mir gleich. Aber nur eins von beiden. Ich mach die Änderungen Richtung Deutsch wegen der Einheitlichkeit, das wäre bei mini und miniatur nicht gegeben. Und da mini bei der letzten Zählung durch Schnark IIRC kaum vorkam: gerne weg damit.
Die geänderte Praxis steht in der Doku; auch mal wieder zeitnah.
Mein Ziel ist es, einen zuallererst für Menschen verständlichen Wikitext herzustellen, da der Wikitext als Quellcode von Menschen editiert wird. Wäre es ein nur zwischen Software ausgetauschtes Dateiformat, würde ich mich jeder Lokalisierung und jedem Abweichen von ASCII für Syntaxelemente widersetzen.
mini ist ein Wort, das in sehr vielen Sprachen verstanden und richtig geschrieben wird; neben Deutsch auch Englisch, Französisch, Skandinavisch, Russisch, und Inuktitut; auch Italiener und Spanier verstehen es auf Anhieb, wie sich auch Polen etwas unter dem Wort vorstellen können (siehe auch hier). Sprachspezifische Varianten wie miniatura, miniatyr, miniature werden durch die Kurzform vermieden. Ich halte mini deshalb auch für geeigneter, zu einem (lateinisch-kyrillischen) Weltstandard zu werden. Der englische Daumen mit seinem θ ist überall sonst ein Fremdkörper.
Ansonsten ist die Konvertierung von Wikisyntax zwischen Projekten unterschiedlicher Sprache eine Aufgabe für Software, nicht für Menschen.
Irgendwo muss mal irgendwer anfangen. 2008 war man bei der Lokalisierung offenbar nicht auf mini gekommen; schade.
Ein Problem ist, dass nie ein Konsens herzustellen sein wird, wie genau Wikisyntax zu schreiben ist (die Debatten, ob und wie viele geschützte Leerzeichen erlaubt wären, ob Leerzeilen nach Überschriften oder nicht, habe ich noch vor Augen). Für ein Meinungsbild ist die Angelegenheit einerseits zu läppisch, andererseits wäre nie eine Einheitsform oktroyierbar. Technisch sind englische und deutsche Variante gleichberechtigt. Es wird immer ein Dutzend Leute geben, die schon aus Prinzip das Gegenteil der Mehrheitsversion verlangen, und die Rückkehr zur bis auf Namensräume nicht lokalisierten Syntaxversion von 2007.
Es ist auch eine Illusion, dass es langfristig einen Hauptautor und Erstautor gäbe, der sich um „seinen“ Artikel kümmern würde und das Recht habe festzulegen, in welcher Syntaxgestalt dieser Artikel formatiert wäre. Hauptautoren mit Alleinbestimmungsrechten widersprächen grundlegenden Wikiprinzipien; und auch diese sind sterblich und Zeiten können sich ändern. Dass diese Hauptautoren, die „ihre“ Artikel nun pflegen würden, überwiegend auch nicht existieren, zeigen die 300.000 defekten Weblinks, darunter auch Tausende von bebapperlten Artikeln.
Im Moment kann es dazu kommen, dass in einem Artikel von einer uneinheitlichen Form miniatur+thumb umgestellt wird zu einer ebenfalls uneinheitlichen Form miniatur+mini, aber schon etwas deutscher und ähnlicher. Grundsätzlich wäre ich auch in der Lage, diese Situation zu erkennen (ich registriere es bereits zu Testzwecken), und in einem nachgeschalteten Durchgang dies innerhalb einer Seite dann komplett zu vereinheitlichen.
mini hat den entscheidenden Nachteil, dass – sobald sich jemand bugzilla:38829 annimmt – man mit der Werkzeugleiste alle Bildeinbindungen bearbeiten kann, die miniatur, thumb oder thumbnail verwenden, nicht aber die mit mini, da dies nur eine Nebenform ist. Ich weiß, dass sich eigentlich die Technik den Benutzern anpassen sollte und nicht umgekehrt, aber wenn die Technik MediaWiki heißt und sich nicht so schnell anpassen will, dann sollte sich in meinen Augen der Benutzer anpassen und miniatur verwenden. --Schnark10:16, 2. Okt. 2012 (CEST)Beantworten
Es spräche nichts dagegen, wenn du in deinem patch in Zeile 35 auch noch 'mini' aufnimmst; dann bist du auch gerüstet für Varianten von es nn no sv.
Übrigens zeigen auch pt und it, dass es keine „Hauptvariante“ gibt. wgWikiEditorMagicWords springt hier zu kurz mit dem einzelnen Wort, das müsste ein Array sein; siehe etwa die polnischen Varianten des frameless oder no-rwegisches center.
Da sich offenbar bislang niemand deines patches angenommen hat, kannst du das patch gern von jetzt auf gleich um eine europäische Lösung bereichern.
Doch, es spricht etwas dagegen: In en (und den meisten anderen Sprachen) ergibt [[File:Mini.jpg|thumb|mini]] ein Bild mit der Bildunterschrift „mini“. Hauptvariante heißt einfach das erste Schlüsselwort. Natürlich ist das nicht unbedingt das, was die Wikipedianer als Hauptvariante betrachten (in en etwas thumbnail), aber es ist das, was in den Artikel eingefügt wird, wenn man die Werkzeugleiste benutzt. Dass da kein einzelner Wert stehen sollte, sondern ein Array aus allen Werten, stimmt zwar, ändert aber nichts an der Tatsache, dass es leider nicht so ist. --Schnark09:11, 3. Okt. 2012 (CEST)Beantworten
Den kompletten Zusammenhang dieses patches überblicke ich zwar noch nicht, bekomme aber allmählich eine Ahnung.
Dein Feature existiert ja bislang noch nicht, aber es (oder dieser WikiEditor) greift zu kurz, wenn er unterstellt, man dürfe in einem Projekt nur genau eine Lokalisierungsvariante verwenden. Serbisch (sr) kennt je eine kyrillische und eine lateinische Variante (soweit ich das überblicke, ein politischer Kompromiss); Spanisch hat vier center und drei framed und drei left; Französisch drei Übersetzungen von framed; Chinesisch hat oft drei oder vier Übersetzungen; Kasachisch ist regelmäßig mit mehreren dabei; usw.
Wo steht denn mal lesbarer Quellcode für die Generierung von wgWikiEditorMagicWords?
Ach, übrigens: px heißt mindestens auf Russisch пкс, auf Nynorsk pk und in ja kk zh auch anders. Ist halt alles nicht so einfach; aber ich hatte in den letzten Wochen den analogen Parser für WSTM geschrieben und bin noch im Stoff.
Gedacht ist wgWikiEditorMagicWords ja zunächst einmal für das Einfügen. Da muss man sich für eine Variante entscheiden, da die Software ja nicht raten kann, was der Bearbeiter denn am liebsten hätte (gut, bei kyrillisch vs. latein könnte sie das vermutlich sogar). Die Beschränkung auf die erste Form ist damit durchaus sinnvoll. Dass das für das Parsen vorhandenen Wikitextes ungeschickt ist, hat wohl niemand bedacht, weil bei der Einführung niemand auf die Idee kam, den Text parsen zu müssen.
Zusammengesetzt wird die Variable in irgendeiner der .php-Dateien (die, wo auch die Module registriert werden, du wirst sie schon finden).
Bezüglich px werde ich mich hüten, einen Bugreport zu erstellen (jetzt ohnehin nicht, ich sitze nicht an meinem gewöhnlichen Browser, müsste mich daher erst mal wieder an mein Passwort erinnern, aus irgendeinem Grund bin ich gezwungen per SSH mit X-Tunneling zu arbeiten), meiner Ansicht nach sollte das eigentlich ganz schnell wieder rausfliegen, wer px nicht von Hand einfügen kann, der sollte das nämlich bleiben lassen. --Schnark10:54, 3. Okt. 2012 (CEST)Beantworten
Was dein Patch angeht, wüsste ich einen workaround. Da ich heute und bis zum Wochenende beabsichtige, geschachtelte Bildlegenden zu parsen (solche mit anderen Bildern und Links und Kommentaren und Vorlagen drin) und irgendwann korrekt einzusortieren, stehe ich grad im Stoff.
Frage doch magicWords.img_thumbnail, ob die Zeichenkette 'min' darin vorkommt. Falls ja, wäre eine Variable mini mit 'mini' zu belegen; ansonsten mit deinem escapedPipe oder null. Damit kann dann param verglichen werden.
Ein .toLowerCase() erlaube ich mir aus alter Erfahrung anzuraten.
Alternative: Formulierung aller Varianten als RegExp vorab; auch etwas wie parse.fileFloat = 'right'; if (magicWords.img_right) parse.fileFloat = parse.fileFloat + '|' + magicWords.img_right; und dann insensitv new RegExp.
Es gibt übrigens auch Einbindungen mit unerkannten oder falsch geschriebenen Parametern oder einem Pipe-Symbol zuviel; etwa diese (Ob ihnen das mit droite auch passiert wäre?) Wird das dann samt Pipe an die Caption wieder drangehängt, oder gäbe es Textverlust?
Dein Vorschlag beruht auf dem (zutreffenden?) Wissen, dass im Moment alle Sprachen, in denen ein mit min beginnendes Schlüsselwort für thumbnail existiert, auch mini ein gültiges Schlüsselwort ist. Selbst wenn das jetzt so ist, gibt es keine Garantie, dass das so bleibt. Das macht einen solchen Code völlig unberechenbar.
LINKS Ein .toLowserCase() mag für eine automatische Korrektur sinnvoll sein, für ein fehlerfreies Parsen vorhandenen Codes aber nicht.
Überflüssige Pipes wirft mein Code raus, bei unbekannten oder falsch geschriebenen Parametern gibt er auf, was dazu führen wird, dass (so wie es jetzt bei jedem Bild ist) der Dialog ohne Vorbelegung startet und dann die gesamte Markierung überschreibt. --Schnark09:26, 4. Okt. 2012 (CEST)Beantworten
Alles etwas verbastelt.
Das gesamte Konzept von WikiEditor, wie es sich mir jetzt abzeichnet, kann so nur in der enWP sicher funktionieren. Wenn man aber Syntaxelemente aus der Seite auslesen, umformatieren und wieder in die Seite zurückschreiben will, kann man dies nur machen, wenn man die Syntax der Seite vollständig kennt. In allen gültigen Varianten.
Das habe ich nach zweieinhalb Jahren WSTM oft schmerzhaft erfahren müssen.
Halb besoffen ist rausgeschmissenes Geld, sagte mein seliger Vater. Wenn dieser Editor im Moment die Infos aus der Seite zerstört, sollte ein verbesserndes Patch das vermeiden und den Wikitext konservieren.
Für dein Patch wäre es vermutlich eine Lösung, wenn du sämtliche unerkannten Parameter durch Pipes getrennt in der caption ansammelst. Sie können ja auch einfach nur falsch geschrieben sein, wie das Beispiel Paris zeigt. Es könnte auch irgendein anderer gültiger aus Hilfe:Medieneinbindung sein. Erfahrungsgemäß gibt es auch keine Garantie, dass die beabsichtigte caption der letzte Parameter ist.
Ich schlage mich gerade damit herum, eine caption zu identifizieren, in der Links und Kommentare auftreten und auf die noch Parameter folgen.
Ich wünsche dir viel Spaß mit <!--]]--> in der caption.
Eine Ansammlung unerkannter Parameter würde alle ihre Werte im Wikitext erhalten, wenn auch nicht interpretieren und irgendwelchen Feldern zuordnen können – wie das Wort „unerkannt“ signalisiert. Edlerweise könnte man sogar eine Fehlermeldung ausgeben, wenn mehr als ein unbekanntes Wesen erscheint.
Ich habe diesen WikiEditor noch nie benutzt. Vielleicht sollte ich das mal, um mitreden zu können.
Langfristig wäre es eine Lösung, wenn die aktuelle Syntax einer Seite wie diese in JavaScript mitgeliefert würde. Das muss ja nicht in jede Seite in wg**** hineingeschrieben werden, sondern eine Anfrage per .using() würde reichen und im Browser-Cache stünde dann auf Wochen ein Modul mit der aktuellen Projektbeschreibung in JSON-Art. Eine API würde aber zu lange dauern.
Zielgruppe von WikiEditor sind nicht die erfahrenen Benutzer, die jegliche komplexe Bildsyntax damit bearbeiten wollen, sondern Anfänger, die bei einem gerade eingefügten Bild nach der Vorschau auf die Idee kommen, es an den linken Rand zu verschieben. Daher lautet meine Forderung im Bug ja auch, dass das Ding die Syntax parsen können muss, die es selbst ausgibt, was darüber hinausgeht, ist nicht Pflicht, sondern Kür.
Unbekannte Parameter in caption mag für uns verständlich und hilfreich sein, für den Neuling ist es aber höllisch verwirrend.
<!--]]--> müsste mein Code korrekt parsen können, du meinst vermutlich <!--|-->, dabei würde er aufgeben. Aber es geht wie gesagt um die in der Realität vorkommende Syntax, nicht um das, was sich ein paar komische Leute ausdenken, um den Parser an die Grenze zu bringen. --Schnark10:34, 4. Okt. 2012 (CEST)Beantworten
Ich habe die Vorlage:Chaturanga Diagramm meiner Sammlung hinzugefügt und erwäge eine Anfrage beim Portal:Schach, wie viele von diesen Dingern es eigentlich noch gibt. Auswertbare Kategorien gibt es hierzu keine mehr. Die Vorlage:Schachbrett-Chaturanga hätte ich (bzw. WSTM) schon gekannt.
Live-Schaltung kann etwas dauern.
Wenn du von Fehlerlawinen überrollt werden möchtest, kannst du setzen:
mw.libs.WikiSyntaxTextMod.config.errorlimit=25;
Das Schachbrett hat acht Zeilen, das Fehlerlimit liegt standardmäßig bei sieben zur Nervenschonung im Vollprogramm.
Das weiß man im Schachportal genauso wenig wie du. Da jedoch die Chaturanga-Vorlagen redundant zu sein scheinen habe ich auf eine davon einen Löschantrag gestellt. 213.54.56.2217:23, 2. Okt. 2012 (CEST)Beantworten
Ah, danke, mein Unbekannter; ich hatte eine Minute zuvor die Vorlage begonnen zu reorganisieren und kam BK-artig über deinen LA. Ich werde trotzdem irgendwann die Schacherer anfragen; vielleicht fällt irgendwem was ein. Schönen Abend --PerfektesChaos17:37, 2. Okt. 2012 (CEST)Beantworten
Letzter Kommentar: vor 11 Jahren6 Kommentare2 Personen sind an der Diskussion beteiligt
Hier wird vor den Überschriften "Abschlüsse" und "Unterrichtszeiten" Text aus dem vorigen Absatz eingefügt. Hängt evtl. mit der Satzzeichennachreferenz-Verschiebung zusammen. Gruß --RonMeier (Diskussion) 10:32, 2. Okt. 2012 (CEST)Beantworten
Ich kann es momentan nicht reproduzieren, aber habe gestern Abend etwas Ähnliches bemerkt, was zu deiner Beschreibung passt.
Dabei geht es um die Wiederbelebung des Prolog bei ungeklammerten URL. Der bedurfte dann noch der Analyse von Spezialfällen, die mir beim ersten Hurraschrei mit einfachen Beispielen noch nicht gewärtig waren.
Meine momentane Arbeitsversion erringt hier nur einen Teilerfolg. Frühestens morgen wird das ausgereift und getestet sein.
Nimm mal bis dahin die Satzzeichennachreferenz-Verschiebung aus der .url heraus und führe sie nach Freigabe mit .concat gleichzeitig in .url und .wikilink wieder ein, wie oben beschrieben.
Noch eine gute Nachricht: Bei mir jetzt alles fein; aber über Nacht würde ich gern noch ein wenig damit herumspielen, bevor ich es für dich wieder klarmache. Schönen Abend --PerfektesChaos17:19, 2. Okt. 2012 (CEST)Beantworten
Scheint zu flutschen; live.
Gemeinschaftliche Definition; nach vorheriger Definition der beiden Definitionen für .url und .wikilink:
Es ist seltsam, dass dies genau bei Filzstift auftritt, und offenbar erst seit heute.
Ich werde mal stalken und schauen, was für Skripte er/sie/es benutzt. Möglicherweise kommt er mit einem anderen Skript oder einer Browser-Einstellung ins Gehege.
Ah, dieser Edit bringt mich weiter, und auch der BK (wäre übrigens was für dich).
Es sieht so aus, als ob bei kurzen Routinebesuchen zu Verwaltungszwecken (nach Löschungen) die Fehlermeldung wieder hineinkopiert wird; als Hinweis für die eigentlichen Bearbeiter der Seite.
Ich habe mit diesem Feature noch nicht herumgespielt, und nur vage davon gehört. Es nennt sich „LivePreview“. Wenn es auch noch LiveDiff heißen würde, wäre mir die Sache völlig klar.
WSTM erwartet, dass die Seite neu aufgebaut wird für das Diff, und startet dadurch das Entfernen des Kommentars mit den Fehlermeldungen. Offenbar bleibt man aber hier auf der alten Seite und holt sich nur Inhalte, um sie anzuzeigen. Details muss ich noch ausfummeln.
Wenn ich spitzkriege, dass dieses Feature aktiv ist und keine neue Seite aufgebaut wird, dann kann ich die rote Kiste auch direkt anzeigen – und kann mir den Umweg sparen, erst den Kommentar hineinzuschreiben und auf der Diffpage wieder zu löschen. Und welche Gadgets und Optionen aktiv sind, lässt sich meist recht einfach ermitteln.
Sieht also gut aus und hat uns weitergebracht. In der einen oder anderen Woche kommt die Lösung.
Es war kein Unsinn, und ich habe mich inzwischen etwas eingelesen. Sieht machbar aus. Für Mitleser:
Modul: mediawiki.action.edit.preview
user.option: "uselivepreview" = "1"
Auslösung: $( mw ).bind( 'LivePreviewDone');
Heißt: Ich kann feststellen, ob dieser Modus aktiv ist, und merke auch, wenn die aktualisierte Seite vom Server geholt und angezeigt wurde. Dann kann ich die Fehler direkt (ohne Kommentar im Wikitext) anzeigen, oder sie bleiben vielleicht stehen. Mal ausprobieren.
Kann sich aber einige Wochen hinziehen; der Weg ist klar, aber an diversen Stellen sind Eingriffe in das ausgetestete WSTM erforderlich.
Eine Fallunterscheidung nach uselivepreview und eine testweise Möglichkeit einer direkten HTML-Anzeige habe ich schon mal ins Blaue geschrieben. Das Problem ist aber nicht das Hinschreiben (das geht flott), sondern das Erproben; womöglich in unterschiedlichen Browsern und etlichen Konstellationen.
Letzlich ist der Weg über den Kommentar im Wikitext aber nur eine Krücke, und diese Variante einer persistenten HTML-Seite mit statischer Grundausstattung hat schon was für sich. Allerdings wäre ein optionaler Neustart auf konventionelle Art wahrscheinlich manchmal sinnvoll, weil sich im Lauf der Bearbeitung allerlei überholte Geschichten in der Seite ansammeln.
Genau in den Blöcken <references>…</references> und bei der ISBN hatte ich am Wochenende herumgeschraubt und dachte, alles richtig gemacht zu haben. Heute nachmittag dürfte ich es dann wohl hinbekommen haben; es kommen sich zwei Mechanismen zur ISBN-Behandlung in Vorlagen zusammen mit benutzerdefinierten Wünschen in die Quere. Bis dann --PerfektesChaos12:08, 8. Okt. 2012 (CEST)Beantworten
Erstmal habe ich das per sofort so zurückgesetzt, dass das Gleichheitszeichen verbleibt.
Ich habe aber festgestellt, dass ich generell ein Logik-Problem habe, wenn Vorlagen innerhalb von <references>…</references> oder <gallery>…</gallery> stehen. Die werden zurzeit vermutlich ignoriert; da muss ich genauer gucken.
Und grad habe ich noch einen draufgesetzt: Die Bereiche <references>…</references> und <gallery>…</gallery> werden jetzt nochmals gesondert der Vorlagenanalyse ausgesetzt, weil sie in einem vorherigen Schritt aus dem Gesamt-Text ausgegliedert waren.
Womöglich muss ich das für Links auch nochmal gesondert machen, während benutzerdefinierte Einfach-Text-Ersetzungen in diesen Bereichen auch so greifen. Warum, versteh ich grad selbst nicht. Ist aber alles etwas vertrackt.
Da muss ich aber noch einiges austesten, insbesondere für Leute, die keine benutzerdefinierte Ersetzungen haben.
Endlich mal ein neuer Fehler; mit den alten wurde es allmählich langweilig.
Die Leerzeichen nach der Pipe bewirken zurzeit, dass die Linktitel als Vorlagenparameter wahrgenommen werden; mangels Gleichheitszeichen halt unbenannt.
Bei den Personendaten werden die bekannten Parameter in die vorgegebene Reihenfolge sortiert. Anschließend werden die beiden unbekannten an den Schluss geschoben.
Dabei hatte ich den Zeiger auf vor-Pipe nicht aktualisiert. Das hatte zur Folge, dass bei der Analyse der Vorlagensyntax dieser Zeiger nicht auf das L von URL wies, sondern auf das R. Damit war aber das Zeichen nach dem Linkziel nicht die Pipe, sondern das L; und damit war keine Pipe-inmitten-Link zu sehen, und damit wurde es eine ganz normale Vorlagen-Pipe.
Letzter Kommentar: vor 11 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
aus mir unklaren Gründen wird in obiger Datei mit meinen Ersetzungen aus: erlag Charlie Wilson mit 76 Jahren in seinem Heimatort Lufkin einem erneutem [[Myokardinfarkt | Herzinfarkt]]. ein: erlag Charlie Wilson mit 76 Jahren in seinem Heimatort Lufkin einem erneuten Myokardinfarkt|Herzinfarkt]]. bisher lief es (und läuft auch in der Spielwiese) klaglos. Fragend --RonMeier (Diskussion) 13:33, 10. Okt. 2012 (CEST)Beantworten
Angeschlagen hatte ja wohl das gruselige Wetter. Ich vermute, die Leerzeichen um die Pipe herum bringen irgendeine Zählung durcheinander. Das Leerzeichen vor dem „H“ wird vor die beginnende Klammer verschoben; weil dort aber schon ein Leerzeichen steht, sollte es nicht eingefügt werden. Dabei müssen allerlei Zeiger neu justiert werden. Greift jetzt auch noch ausgerechnet an dieser Stelle deine Ersetzung, dann kommt offensichtlich irgendwas durcheinander. Außerdem gibt es noch ein Leerzeichen vor der Pipe; aber das hat keine optische Wirkung, jedoch muss auch dafür die Zählung angepasst werden. Außerdem enthält dein Ersetzungsausdruck öffnende eckige Klammern; deshalb wird der Beginn des Linkziels neu justiert. Kurz: Ich blick grad nicht durch.
Außerdem bin ich grad dabei, die Aufspaltung des Syntax-Moduls in sieben Einzelteile vorzunehmen. Dazu wäre zwecks Austesten gelegentlich Cache-Leerung erforderlich, damit das neue Kopfmodul aktiv wird. Dazu sage ich dann aber gesondert Bescheid.
Ja, es ist wohl das Leerzeichen nach der Pipe, das Probleme mit dem Gruseligen hat. Ein Mitleser hat den Fehler jetzt korrigiert, aber er bleibt ja nachvollziebar. - und - keinen Stress bitte. Mach weiter mit dem (Ab)spalten. Gut Holz --RonMeier (Diskussion) 14:58, 10. Okt. 2012 (CEST)Beantworten
Mmmh, und ich hab auch so eine Ahnung, wer der schachkundige Kategorienexperte ist, der zurzeit Wikipause hat.
Es gab bei diesen Link-Ersetzungen ein Koordinationsproblem, wenn mehrere Ersetzungen und Korrekturen gleichzeitig wirksam werden.
Ich habe es auf der Festplatte gefixt und möchte es erstmal ein paar Tage beobachten. Es ist ein separates Modul und unabhängig vom momentanen Zerhacken des großen Syntax-Moduls mit seinen 10800 Zeilen in 370 kB. Damit ich aber den Überblick über die Baustellen behalte, zerlege ich erstmal den großen Brocken zu Ende und schaue, wie sich das so macht.
Die Ersetzung mit „dem gruseligem Wetter“ solltest du rausnehmen; es ist redundant zu „einem schönem Tag“. Dann kommt dieser auch nicht mehr mit einer gleichzeitigen Linkkorrektur ins Gehege.
Doch ärgerlich; bewirkt Meldung falscher Folgefehler.
Ursache war Anfang Oktober ein RegExpFix, um ein anderes seltenes Problem zu beheben; hat dafür bei zweiter Zuweisung nach erster WSTM ohne Gänsefüßchen diese Macke bewirkt. Jetzt hoffentlich beide behoben und live für dich; und schon der erste Bugfix in einem heute nachmittag angelegten neuen Einzelmodul.
Na, wenn du mit Gewalt den Cache geleert hast, kann es nur die neueste Version sein. WP:JS #cite note-FF.urlbar-2 sagt, was man alles anstellen muss, um die aus Sicherheitsgründen für Normalbenutzer blockierte Möglichkeit zu nutzen. Hauptsache, Bearbeitungen sind normal möglich; dann lass ich das jetzt mal so. Schönen Abend --PerfektesChaos21:51, 10. Okt. 2012 (CEST)Beantworten
Ich weiß das, kann aber wenig dagegen machen. Es wird nur innerhalb von Parameterzuweisungen die Reihenfolge Pipe-Zeilenumbruch vertauscht. Weil es aber beim ersten Mal zwischen Vorlagenname und Parameterzuweisung steht, klappt der Kunstgriff dort nicht. Hinzu kommt, dass WSTM überhaupt nichts über die Vorlage weiß; es müsste mit .confog.mod.template für Vorlagen dieses Namens ein Layout zugewiesen werden. Ich denke, es ist aber so schon eine Erleichterung; einmal Enter und der Käs ist gegessen.
Ich habe mich übrigens selbst grad ausgetrickst; wenn du mit deinem Schub an Tagwerk fertig bist, geh doch komplett aus Firefox raus. Am besten mit Schließen aller Tabs, in denen Wikipedia zugange ist.
Letzter Kommentar: vor 11 Jahren5 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo PerfektesChaos,
ich weiß jetzt wieder warum ich diese Funktion nicht mehr benutze, da sie seit einiger Zeit bei mir nicht mehr richtig funzt, bzw die manuelle Ausführung. Also es passiert gar nix mehr.[5] Wie Du ja weißt benutze ich das Button-System (und grundsätzlich die Config) von Schnark. Also ohne load.inhibit funzt der manuelle Button! Da würde ich gleich noch ein Bsp.-Code für die Doku vorschlagen. Viele Grüße -- πϵρήλιο℗17:27, 13. Okt. 2012 (CEST)Beantworten
Du hast bisher nur eine Anweisung zum Laden der Bibliotheken mit deinem Knopf verbunden: api.load(true)
Der Wert true ist nur für interne Zwecke vorgesehen; präzise: nur beim AutoRun, wie dokumentiert. Das ist aber bei dir schon vorbei.
In deiner config kannst du also ersetzen api.load(true) → api.run()
Das sollte laufen. Falls nicht, bitte nochmal beschweren.
Mit load.inhibit verhinderst du, dass das Skript automatisch losläuft, sobald die Seite zum Bearbeiten geöffnet wird. Ich weiß ja nicht, welches Verhalten du dir vorstellst.
Hach* ich schaue immer so sparsam, aber der dortige Hinweis ist mehr als sparsam(könnte auf jeden Fall noch zu einer entsprechenden allg. Anleitung linken) ^^. Es läuft nicht. (Der Button hat an sich auch nichts mit Schnarks Scripten zu tun, also normale Einbindung) Seltsam ist nur dass die Funktion von dir, wenn ich sie denn in der Console ausführe, funzt. Also könnte es auch am Aufbau des Buttons liegen!? (Erstmal die erstaunliche 3D-Ansicht der neuen Web-Console bestaunt :-o ähm alle meine html4 tags werde/habe ich entsprechend html5 angepasst)
Ich muss leider gestehen dass ich kurzzeitig nicht Chrome benutzte. Nun sehe ich mich mit starken Fehlern konfrontiert, im Artikel St. Pölten (bei FF16 alles iO) uzw. eine Fehlermeldung gleich 4×!!!! Die da sich auf jedes Bild bezieht: Bildparameter nicht erkennbar undefined -- πϵρήλιο℗23:50, 13. Okt. 2012 (CEST)Beantworten
Ich sehe zurzeit nicht, dass du api.load(true) → api.run() ersetzt hättest. api.run() geht auch; in der Doku steht zwar WikiSyntaxTextMod_Run() – ist aber nur ein Alias. Die Doku sagt nur, dass derjenige, der seinen Button mit einer Funktion belegen möchte, den Namen dieser Funktion angibt. Was das für Buttons sein mögen, weiß WSTM nicht.
Ich verstehe jetzt nicht, in welchem Browser du das gesehen hast; „nicht Chrome“ und bei „FF16 alles iO“. Es kann durchaus sein, dass irgendein Browser spinnt, meist der IE. Wäre wichtig, dem entgegenzuwirken, und das klappt auch, wenn ich weiß wo es hakt.
Jetzt habe ich mich allmählich durch deine Edits durchgefunden. Du müsstest wohl die Klammern hinter „WikiSyntaxTextMod_Run()“ wegnehmen. Das Beispiel hat die auch nicht. Mit den Klammern kennzeichnet man allgemein den Hinweis darauf, dass es sich um den Bezeichner einer Funktion handelt. Bis dann --PerfektesChaos01:08, 14. Okt. 2012 (CEST)Beantworten
Letzter Kommentar: vor 11 Jahren11 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo PerfektesChaos, mir ist heute scheinbar zum ersten Mal ein gallery-tag mit Attribut caption untergekommen, was dein Script aber als „unbekanntes Attribut“ ausweist. Des Weiteren ist mir einmal passiert, dass eine Fehlermeldung in den Wikitext gekommen ist (obwohl diese ja irgendwie wieder vom Script entfernt wird). Warum machst du das so? ^^ (ich meine die Wahrscheinlichkeit dass das mal passieren kann ist natürlichen gegeben[6]) Ich vermute jetzt einfach mal das liegt an den technischen Möglichkeiten, Informationen beim Neuladen weiterzugeben (zugegeben hatte ich glaube etwas unorthodox editiert bei dem Fehler) Des Weiteren habe ich Probleme das Script an der automatischen Ausführung zu hindern (du weißt nicht jeder kann mit Ressourcen protzen ;-P) Nach der Option für die Namensraumeinschränkung werde ich dann wohl auch noch mal suchen müssen. LG -- πϵρήλιο℗22:04, 8. Okt. 2012 (CEST)Beantworten
Ich sortier mal:
gallery mit caption habe ich grad vorhin editiert; das ist dem Skript sehr wohl bekannt. Es dürfte ein anderer Syntaxfehler dabei vorgelegen haben; vielleicht fehlte das Gleichheitszeichen oder es fehlte der Wert oder sowas. Konkretes Link?
Fehlermeldung im Wikitext – was genau meinst du denn mit „etwas unorthodox editiert“? Normalerweise wird dies entfernt.
Warum ich das so mache, deutest du ja selbst schon an. Im Normalbetrieb wird eine komplett neue Seite vom Server abgerufen und eine völlig neue JavaScript-Umgebung damit aufgebaut, die nichts von der vorherigen Seite weiß. Ich habe keine andere Möglichkeit, die Infos zu übermitteln.
Es gibt allerdings die experimentelle Einstellung LivePreview, bei der man auf derselben Seite bleibt; hier schreibe ich auch keinen Kommentar in den Wikitext.
* Ok, dachte ich mir dann auch fast. Hier ist der Link.
** (Offtopic) Des Weiteren ist mir dort aufgefallen dass erst nach dem Laden das ASCII-Bild zerstört wird durch irgendeine nachträgliche Formatierung (jedoch nur angemeldet, müsste ich also noch mal testen).
* Des Weiteren würde ich gerne Deine anderen neuen Scripte mal testen.
* In der En. funzt der WikiSyntaxTextMod nicht mehr da er aus allen Bildern das File: in eine 6 umwandelt. Funktioniert das Script eigentlich auch auf auf Commons? (Dort gibt es ja auch ein ähnliches Script)
caption: Das Apostroph ist ein möglicher Begrenzer für einen Attribut-Wert. Es liegt also an der versuchten Kursivschreibung. In dem Block darunter siehst du unter „Grundform“, dass das mit dem caption= schon durchaus hinhaut. Guckt man sich nun Mäander (Ornamentik) #Komplexe Mäanderformen genauer an, sieht man, dass der Buchtitel auch gar nicht kursiv gerendert wird, sondern die Apostrophe stehenbleiben. Genau darüber wollte dich WSTM informieren.
Die enWP schaue ich mir an; da würde etwas aus der Synchronisation geraten sein. 6 ist die Namensraum-Nummer von File:, und das ist die Zwischenstufe, wohin auch Image: konvertiert wird, um es als File: zu normalisieren. Ansonsten ist die enWP die Heimatbasis von WSTM und hat die einfachste Syntax; das wäre seltsam, wenn das dort nicht ginge. Allerdings springt auf der enWP bei mir grad gar nix an; muss ich mal analysieren. Es gibt irgendeinen doofen Fehler von irgendeiner reftoolbarbase, der nicht von mir ist. Auf der französischen WP geht es aber.
Magog the Ogre beschäftigt sich mit Dateibeschreibungsseiten, die ja etwas simpel strukturiert sind. Es wäre etwas gefährlich, dieses Skript auf beliebige Seiten anzuwenden, da es nicht robust gegen Formatfehler zu sein scheint.
Danke der aufkläreden Antwort, werde ich gleich mal probieren. @Ach zum unorthodox: Das war glaube ich ein Copy&Paste des ganzen Textes zwischenzeitlich. Ich erfreue mich nun seit heute einiger neuer Scripte.[7] Schönen Abend. -- πϵρήλιο℗18:09, 9. Okt. 2012 (CEST)Beantworten
Die enWP zickt gerade rum und macht mir das Debuggen schwer. Die "6" kann ich aber inzwischen reproduzieren.
Und WSTM zickt auch rum, wenn es aus en in en übersetzen soll. Eigentlich ist für diesen Fall vorgesehen, dass WSTM es in der generischen Sprache beim "File" belassen soll; wird sich im Laufe des Abends hoffentlich aufklären. Habe ich schon längere Zeit dort nicht mehr probiert.
Dann siehst du ja jetzt deinen roten W-Icon wieder.
Der Bug gefixt und live; wenn es keine Übersetzung zum generischen Namensraum-Schlüsselwort gibt, dann soll das Schlüsselwort benutzt werden und nicht die Nummer des Namensraums; dummer Flüchtigkeitsfehler. Habe allerdings noch nicht intensiv auf englischsprachigen Projekten experimentiert; kannst du ja nachholen und dich melden, wenn was ist. Schönen Abend --PerfektesChaos20:09, 9. Okt. 2012 (CEST)Beantworten
Aus euren Buttons und wikieditor und dem ganzen Kram halte ich mich raus; das ist mir alles zu kompliziert und statt Buttons und Icons reichen mir simple Portlet-Links.
Genau ja, wobei wie gesagt sehr seltsam, da es vorher auch mit Klammer funzte.
Das aus deinem Munde zu hören will schon was bedeuten. Vorlage:Smiley/Wartung/shock (wobei ich dir da Recht geben muss)
Danke fürs Schmankerl, Du meinst das gilt automatisch für alle? (Betr. ich hatte mir letztens ein Button für NowCommons gebaut[8] wobei ich tatsächlich eine andere Schreibweise genommen habe Vorlage:Smiley/Wartung/:s Da ich kein Freund des ZusammenklatschensVonBegriffen bin, wie es auch eigentlich anderswo üblich ist)
Ansonsten hätte ich noch ein Schmankerl: WP:SORT Groß- /Kleinschreibung wird bei Sortierung nicht mehr Unterschieden, Vorlage:Smiley/Wartung/pacman also z.B. sowas kann komplett entfernt werden.
Wobei mir jetzt im dortigen Abschnitt ein Formartierungs-Bug aufgefallen ist (Wenn du ihn auch siehst). Der Hinweis mit den Shortcuts hängt völlig unpraktisch in den Text rein (durch ein float:right). Wie ich grad sehe hattest du in der entsp. Vorlage schon was gehändelt. Ich würde einfach ein text-align: right; vorschlagen.
Zugabe: Es werden Leerzeichen entfernt z.B. nach dem "von" in "(Ruprecht) von Monreal"
Die Geschichte mit dem verunglückten Reparaturversuch wird ausgelöst duch das Leerzeichen in:
|Eggenberg ]], wurde
Ein dafür kürzlich eingefügter Schalter für das Leerzeichen-Schubsen wurde irrtümlich nicht wieder zurückgesetzt. Das hat nun zur Folge, dass bei jedem nun folgenden Wikilink ein vorangehendes Leerzeichen auch verschluckt wird. Dies ist bei mir auf der Festplatte bereits gefixt.
Der erste Punkt ist schwieriger, den muss ich mir heute Abend in Ruhe angucken.
Nebenbei: Du warst ja über das Wochenende fleißig; wie geht es denn den roten Kisten? Alle gekommen, die kommen sollten, keine zuviel, keine mit zuviel Inhalt?
Der Bug war schon mindestens seit 31. März drin, wohl schon seit Mitte 2011, und es ist mir schleierhaft, warum er nie aufgefallen war. Er kommt nur zustande, wenn gleichzeitig im Kontext desselben Links eine benutzerdefinierte Ersetzung wirksam wird und ein Leerzeichen von vor den eckigen Klammern nach hinter den eckigen Klammern geschubst wird.
Hallo, schachkundiger Kategorienexperte, RL ist vorbei?
Das Problem war ein Ruckler bei unvollständiger Aufräum-Aktion; die fragliche Analyse wurde wegen Unverträglichkeit des Bearbeitungsstandes auf dem Server nicht vorgenommen, lief aber schon korrekt auf meiner Festplatte und war deshalb für mich unsichtbar.
Letzter Kommentar: vor 11 Jahren6 Kommentare2 Personen sind an der Diskussion beteiligt
Nur mal so eine Frage an den geehrte Konkurrenten. :-) Ist eine Möglichkeit vorgesehen, das Skript auch beim Bearbeiten älterer Artikelversionen zu aktivieren? Das kommt ja durchaus vor, dass man bei einem Revert auch gleich mal schaut, ob es sonst noch etwas am Artikel zu tun gibt. --TMg21:11, 2. Nov. 2012 (CET)Beantworten
Also, so spontan ist das Auftauchen von oldid= ein absolutes Ausschlusskriterium für automatisches WSTM, genauso wie ein Disku-Namensraum oder css/js. Wenn man eine ältere Artikelversion öffnet, soll man den unveränderten Quelltext sehen und keine automatisch veränderte. Ob das im Zusammenhang mit einem Revert steht und es die quasi-neueste Version wäre, ist mir zu heikel. Allenfalls könnte man über manuellen Start mit Flag nachdenken. Mit der API lässt sich ohnehin alles hinbekommen und overrulen. Insgesamt ist der Anwendungsfall aber wohl eher ein seltener Zufall, und dann fiele halt mal eine Politur aus. HGZH --PerfektesChaos21:34, 2. Nov. 2012 (CET)Beantworten
Das klingt alles sehr vernünftig, danke für die Erklärung. Da steht ja sogar alles, ich hätte nur mal genau hin schauen müssen. ;-) Dass sich unsere beiden Skripte in diesem Punkt deutlich unterscheiden (deins läuft in der Basisversion automatisch, meins ausschließlich auf Knopfdruck) gefällt mir sehr gut. --TMg23:11, 2. Nov. 2012 (CET)Beantworten
Ich müsste hin und wieder meine eigene Doku lesen. Das Feature wollte vor über einem Jahr mal jemand haben, es wird aber nur von einem anderen Benutzer verwendet, und ich hatte es längst verdrängt.
Deine Anfrage habe ich zum Anlass genommen, das Skript dahingehend zu ändern, dass bei fehlender Angabe des Steuerparameters und manueller Auslösung gestartet wird; wirksam vielleicht erst nächstes Jahr.
WSTM ist in der Tat vorrangig dafür vorgesehen, leise, automatisch und möglichst ohne Kollateralschäden im Hintergrund zu wirken, ohne dass die Benutzer sich mit dem Quelltext wildfremder Artikel befassen müssen.
Ich möchte bei der Gelegenheit auch nochmal meinen allergrößten Respekt für deine Programmierung aussprechen. Mein Skript besteht im Kern ja „nur“ aus einer Sammlung sorgfältig aufeinander abgestimmter regulärer Ausdrücke. Deins hat mich mal wieder in Erstaunen versetzt. Das ist ja ein regelrechter Parser. Grandios. So ergibt unsere „Doppelentwicklung“ auch aus diesem Blickwinkel Sinn. --TMg17:09, 4. Nov. 2012 (CET)Beantworten
Danke schön; sehr ehrenhaft.
Es ist ein vollwertiger Parser für die betrachteten Syntaxelemente, jedoch toleranter als der Mediawiki-Parser. Er „versteht“ die beabsichtigte Bedeutung auch falsch geschriebener Elemente oder unzulässiger Zeichenkodierungen, die irgendwie so ähnlich aussehen, und bei genügender Eindeutigkeit wird gemäß der offenkundigen Absicht korrigiert; in komplexen Situationen die diffpage ausgelöst und darüber die Möglichkeit zur Nachkontrolle gegeben.
@TMg: Kann ich nicht reproduzieren. Mysteriöserweise ist Benutzer:Elvaube der einzige, bei dem dieser Schrägstrich-Bug auftritt; auch nachdem kürzlich seine Standard-Skripte poliert wurden und die allerneueste Version benutzt wird. Ich gehe von einer Ursache in der Browser-Version aus; irgendeine Zeichenketten-Funktion arbeitet nicht so wie üblich. Das gibt es beim IE, ist mir bekannt und wird eigentlich von mir geeignet vermieden. Kann mir aber irgendwo durchgeschlüpft sein. Habe auch einen IE8 hervorgekramt; kein Fehler.
Hattest du selbst WSTM benutzt und den Fehler selbst reproduzieren können? Wenn ja: Browser? Version?
also ich kann das in dem Artikel in der aktuellen Version[9] reproduzieren, hab dabei jedoch aber auch die anderen Skripte weiterhin aktiv. Meine Firefox-Version ist 16.0.2 und mit dem IE 32-bit in Version 9.0.8 tritt das auch auf.--se4598 / ?13:40, 3. Nov. 2012 (CET)Beantworten
Danke sehr.
Ich seh schon; heut machste dir keen Abendbrot, heut machste dir Gedanken.
ach, dein Script läuft doch sonst super. Hab großen Respekt vor der Leistung. Wenn ich helfen kann, würde ich das gerne tun. JS und die Web-Konsole des FF sagen mir auch ein klein bisschen was und ich hab im Firefox Firebug installiert. Wenn du mir also ne Schritt-für-Schritt Anweisung oder ähnlich geben kannst, würde ich dir gerne helfen, den Bug zu debuggen. :) --se4598 / ?14:07, 3. Nov. 2012 (CET)Beantworten
Danke für das Lob.
Einen FF 16.02 habe ich hier auch; es ist die Entwicklungsumgebung. Er ist allerdings so hochgerüstet, dass ich grad einige Schwierigkeiten habe, mich so abzurüsten, dass es genauso läuft wie mit der Version, die ihr aus dem Netz bezieht und die ich beim Entwickeln direkt aus der Festplatte lese. Die Tücke ist, dass es im Skript eine Reihe von Baustellenumleitungen gibt, die mich wiedererkennen und der Erprobung von Weiterentwicklungen dienen; die muss ich per Cookie alle lahmlegen, um mich als Normalnutzer zu tarnen. Diese liegen im mutmaßlich fehlerhaften Bereich, und vielleicht hätte sich das nach Freigabe der internen Reorganisation von selbst erledigt.
Da ich also weiß, dass es im FF und nicht im IE auftritt, muss ich es mit dem FF reproduziert bekommen. Außerdem kann das nur von der verirrten Ergänzung einer URL nur mit domain kommen; eine falsch ausgerechnete Integer-Zahl, die auf NaN fällt oder sowas. Das wird sich schon machen lassen; ich habe konkrete Vorstellungen, aus welchen Ecken der Wind weht.
Das mit IE hast du glaub ich missverstanden. Ich hatte es in Opera reproduziert, mit der aktuellen Artikelversion. --TMg22:56, 3. Nov. 2012 (CET)Beantworten
Gefixt und Live (mit dem zweiten Edit).
Die beiden Schrägstriche waren ausgelöst worden durch die beiden
Das waren dem Skript zuviele Schrägstriche um das http: – das innere http in der geklammerten URL wurde bei einem zweiten Durchgang auf der Suche nach ungeklammerten URL erneut gefunden und das verursachte totale Konfusion.
Die Lösung war einfach: Wenn in einer URL die Zeichenkette :// vorkommt, wird eine solche URL immer unter Schutz gestellt; ein entsprechender Mechanismus ist ohnehin vorhanden. Aus Effizienzgründen erfolgt das sonst nur, wenn es benutzerdefinierte Text-Ersetzungen gibt.
Insgesamt gibt es fünf solche URL in diesem Artikel. Woran es genau lag, warum einige zum Einfügen von Schrägstrichen führten und andere nicht, wird nie geklärt werden. Es hängt mit der Position relativ zum Beginn und Ende des Abschnitts und der Länge der URL zusammen; das führte wohl teils zu negativen Zahlenwerten, woraufhin die Zählung nicht vom Beginn des Abschnitts, sondern vom Ende her erfolgte; Perfektes Chaos .
Bevor größere Veränderungen am Skript für alle live gehen, wird es teilweise eine oder mehrere Wochen unter anderem von RonMeier getestet und bei mehreren Hundert Bearbeitungen benutzt. Die Tests während der Programmierung selbst beruhen auf eher simplen, kurzen Zeichenketten sowie einigen zufälligen Artikeln.
RonMeier, Steak und ich verwenden aber während der Testphase benutzerdefinierte Text-Ersetzungen, um produktiv zu arbeiten. Dabei wird jede gefundene URL sofort vor Veränderungen geschützt, damit sie nicht typografisch „berichtigt“ wird, und wir hatten dieses Problem nie.
Ich mache nach größeren Änderungen stichprobenartig Test-Edits mit der Version, die normale Anwender benutzen, und auch ohne benutzerdefinierte Text-Ersetzungen sowie auf verschiedenen Browsern. Dabei könnte ich aber nur auf einigen zufälligen Artikeln fundamentale Fehler im Zusammenwirken entdecken.
Konfus und nicht den Regeln für URL-Zeichen entsprechend ist die Behandlung von URL durch den Mediawiki-Parser:
Hallo PerfektesChaos, das Problem scheint ja schon erkannt zu sein. Hier für Euch ein weiteres Beispiel, bei dem ein Schrägstrich eingefügt wird: Artikel Martin Gaksch, Verlinkung Heinrich Lenhardt. Für Euch zur Info: Ich benutze Opera in der Version 12.2. Liebe Grüße zum Wochenende wünscht Silke (Diskussion) 11:02, 4. Nov. 2012 (CET)Beantworten
Dein Hinweis ist wertvoll.
Auf Martin Gaksch trifft die von mir vermutete Ursache nicht zu; es muss ein anderes Problem sein, und dies besteht weiterhin (inzwischen weiß ich, was ich zum Reproduzieren machen muss).
Arbeitet man mit benutzerdefinierten Text-Ersetzungen, tritt es nicht auf. Es ist irgendein falsch gesetzter Zähler beim Durchsuchen nach ungeklammerten URL, wird sich in den nächsten Stunden finden lassen. Wenigstens ist dieser Artikel schön kurz.
Übrigens, wenn du mal wieder bei Kleinigkeiten bist, spendierst du mir ein großes S in WikiSyntaxTextMod? Wurde dieses Jahr vereinheitlicht, und ich möchte irgendwann das kleine s nicht mehr aktualisieren. Danke.
Nach einem Herbstspaziergang ein klarer Kopf – offenbar ein doofer Rechenfehler und bereits live. Das sollte es dann aber gewesen sein; mit benutzerdefinierten Ersetzungen hatte dies keine Wirkung (blieb deshalb in der Langzeit-Erprobung unentdeckt) und trat bei zwei innerhalb eines Abschnitts aufeinanderfolgenden ungeklammerten URL auf, wenn anschließend noch mehr Text auf die URL folgte als Textlänge zuvor. Martin Gaksch war genau der Richtige zum entspannten Debuggen.
Bingo! Ich habe es gerade noch an einem anderen Artikel ausprobiert, der mir heute "über den Weg gelaufen" ist. Keine zusätzlichen Klammern mehr! Danke für Deine Korrektur und Freude auf meiner Seite, dass meine Fehlermeldung helfen konnte. Meine vector.js ist nun auch korrigiert, sodass mich Dein Skript auch in Zukunft bei meinen täglichen Arbeiten unterstützen kann. Auch Dir einen schönen Abend. Liebe Grüße Silke (Diskussion) 22:14, 4. Nov. 2012 (CET)Beantworten
Da war noch eine Baustellenabsperrung, die verhindern sollte, dass aus einer Klammer dreie werden. Das sollte aber inzwischen erprobt sein und der Weg ist wieder freigegeben. --PerfektesChaos20:25, 4. Nov. 2012 (CET)Beantworten
Letzter Kommentar: vor 11 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
In: Ernst von Bandel wird aus [http://commons.wikimedia.org/wiki/File:Bandel_Ernst_Grab.jpg?uselang=de Foto:] ein [[commons:File:Bandel Ernst Grab.jpg?uselang=de|Foto:]]. Damit wird das Bild unauffindbar. Erst nach Entfernen von ?uselang=de funktioniert es wieder, aber eben in englisch. Gruß und viel Sonne --RonMeier (Diskussion) 11:58, 6. Nov. 2012 (CET)Beantworten
Arrrgh, habe ich auf der ToDo-Liste und ansatzweise schon im Skript.
Zur Sache:
Der Zugriff über URL ist Mist. Wenn das global umbenannt wird in Ernst Bandel Grab (2009).jpg, bekommen alle Wikilinks das mit und die URL werden dagegen ungültig.
Das uselang ist eine Bevormundung und relativ überflüssig.
Dabei fügt die deWP vielleicht die Sprache des Benutzers, zumindest aber deutsch ein.
Wenn dann auch unsere Helferlein (von denen wir sogar zwei haben, aber im Moment ist keins aktiv) mitspielen, wird die Anzeige der Dateibeschreibungsseite in der deWP übersprungen und direkt in der richtigen Sprache auf Commons dargestellt.
uselang= war bereits abgefangen worden bei /w/index.php – dieser hier ist ein /wiki/.
Das steht im Modul „H“.
Gleichzeitig habe ich auch das Modul „O“ aktualisiert und dort einen ausstehenden Wechsel auf WSTM.5 umgesetzt. Die beiden hängen voneinander ab, so dass ich zunächst selbst testen muss, morgen dir das neue O geben möchte, morgen abend bekommst du H und circa übermorgen wäre Ernst von Bandel für dich bereit.
Wie du gemerkt haben dürftest, nach kleinem Ruckler/Tippfehler jetzt für dich live.
Ärgerlich für mich: Baustellenampel bleibt bis 2013, weil sich das vorher nicht bis zum letzten Benutzer des Kopfmoduls herumgesprochen haben dürfte. Grummel.
Eigentlich ist das ein Syntaxfehler im Wikitext, und das Skript liegt nicht ganz falsch.
Was da hinter dem Gleichheitszeichen steht, sollte eigentlich in Gänsefüßchen stehen.
Wenn keine " oder ' vorhanden sind, gilt es bis zum nächsten Whitespace; als wirksamer Identifizierer bleibt also tatsächlich nur name="Rolling" übrig.
Dahinter stehen zwei lose Wörter, Stone Magazin – die sind syntaktisch sinnlos.
Du kannst bei dem fraglichen Artikel ja mal ausprobieren, ob ein aus Spaß eingefügtes <ref name="Rolling" /> auf die gleiche Referenz führt; müsste so sein.
Es kommt zur völligen Konfusion, wenn bei einem Identifizierer aus mehreren Worten die Gänsefüßchen weggelassen werden. Auf Spielwiese eingeben:
# aa<ref name=R>Content R</ref>
# bb<ref name=R />
# cc<ref name=R S M>Content RSM</ref>
# dd<ref name=R S M />
<references />
Im Fall 3 wird das name-Attribut völlig ignoriert und es wird dann als beliebiges (1.) unbenanntes ref gezählt, weil der Inhalt des Tags syntaktisch nicht interpretiert werden kann. Fall 4 greift daraufhin ins Leere.
Letzter Kommentar: vor 11 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Leider bekomme ich wiedermal das Script nicht zum starten, obwohl ich nichts geändert habe. Ich kann jedoch merkwürdiger Weise eine Funktion nach mehreren Minuten beobachten. Kann man da nicht irgendwas optimieren?
Fehler: TypeError: this.prefs is undefined
Quelldatei: chrome://fbblock/content/ff-overlay.js
Zeile: 154
Chrome 22
Uncaught TypeError: Object #<Object> has no method 'run' /w/index.php?title=User:PerfektesChaos/js/WikiSyntaxTextMod/r.js&action=raw&ctype=text/javascript:688
Nicht überblicken kann ich, wann auf welchen Wegen nach welchen Klicks du in diese Situation gekommen bist, ob du LivePreview benutzt und was du sonst im Firefox angestellt hast.
Ich empfehle regelmäßig, derartige Zuweisungen immer davon abhängig zu machen, ob das Objekt bereits definiert ist – wenn in einem vorhergegangenen Durchlauf auf der Seite bereits das Objekt definiert wurde, wird es jetzt überschrieben.
Dafür spricht auch, dass nur das Fehlen von .run() bemängelt wird. Wäre das Objekt völlig vergessen worden, dann wäre mw.libs.WikiSyntaxTextMod unbekannt gewesen oder aber dass bereits die Komponente mw.libs.WikiSyntaxTextMod.api undefiniert sei. In deiner config überschreibst du aber die .api mit {} und demnach hättest du deine config zum zweiten Mal ausgeführt; es ist jetzt nur ein leeres .api bekannt.
Wenn man einfacher Benutzer ist und nur in der common.js das Zeugs zu stehen hat, dann wird die common.js nur einmal geladen und ausgeführt und es genügt, vor dem loader.load das leere Objekt zu definieren – es kann keiner überschrieben haben.
Anders ist es, wenn wie bei paneMarker ein MW-Gadget vorstellbar ist; hier kann das Objekt mit den Funktionen bereits vorher existieren und es muss gecheckt werden, was da zuvor gelaufen war. WSTM soll und wird aber nie ein MW-Gadget werden; dafür ist es zu komplex.
Wie du inzwischen gemerkt zu haben scheinst, habe ich was ausgetüftelt.
Wenn eine solche Situation mit einem Gleichheitszeichen unmittelbar nach Kommentar oder anderem streng geschützten Element kommt und dann ein weiteres Gleichheitszeichen im gleichen Absatz folgt, wird jetzt erkannt, dass dies kein Zeilenanfang ist. Seltsam, dass das erst nach einem halben Jahr auffällt.
Wikinews: Ihm fehlt die Sprache; dieses Link kannte ich noch nicht, und es dürfte das einzige im ganzen ANR sein. Gucke ich mir zu morgen an, und wikidata und wikivoyage haben grad heute Abend Interwiki-Kürzel bekommen. Danke --PerfektesChaos23:53, 10. Nov. 2012 (CET)Beantworten
Die URL-Struktur in Paris kommt etwas unerwartet; hatte ich noch nie gesehen:
//wikivoyage.org/de/Parissteht auf der Seite; wird am Ziel umgewandelt
//de.wikivoyage.org/wiki/Parishatte ich erwartet
Die Dinger gibt es ja noch keine Woche; mal sehen was da noch kommt. Ich werde es umsetzen. Das gibt es in der Form bei keinem anderen Projekt; ist offenbar eine Folge der Integration.
Die waren ein fremdes Projekt gewesen und hatten ihre eigene URL-Struktur, mit dem /de/ und nicht wie wir mit //de. – was ja völlig okay ist. Nur taucht jetzt wikivoyage.org als WMF-Domäne auf, und die haben geeignete Umleitungen gebaut. Da WSTM erwartet, dass bei mehrsprachigen Schwesterprojekten vorne die Sprache steht und es hinten mit /wiki/ oder /w weitergeht, wurde WSTM ausgetrickst.
Ja, dass ich mich seit dem Wochenende nach Monaten wieder mit Vorlagen beschäftige und mir rätselhaft ist, warum das bei Sarabande nicht passiert.
Das Problem ist, dass ich die Sache mit diesen Pipes wohl im Juli programmiert hatte und ich völlig vergessen habe, wann und wo das wie geschieht. Deshalb kann ich es im Moment auch nicht debuggen. Wenn, dann war es ausgesprochen kitzlig.
Dafür habe ich auf meiner Festplattenversion soeben die Textersetzung von Parameterwerten, die bereits vorgezeichnet gewesen war, realisiert und muss sie heute abend auf der Spielwiese ausprobieren; dann schalte ich sie vielleicht morgen zur Erprobung live.
Im Moment sind es aber vier Änderungen gleichzeitig im Vorlagen-Bereich, und eigentlich filtriere ich die lieber nach und nach in die Erprobung, damit ich bei Bugs eher weiß, welche Änderung ursächlich war.
Letzter Kommentar: vor 11 Jahren6 Kommentare3 Personen sind an der Diskussion beteiligt
ab Zeile 36 ein fehlgeschlagener Korrekturversuch Roman aus [Inzest|inzestuösen]] Familienstrukturen wird zu: Roman aus [[inzest Familienstrukturen Bis morgen --RonMeier (Diskussion) 22:38, 16. Nov. 2012 (CET)Beantworten
Ja, wenn sich der Zusammenfassungs-Algorithmus für Wikilinks darauf verlässt, dass ein Wikilink immer mit zwei Klammern anfängt und hier nur eine vorhanden ist, dann verzählt er sich halt um eins.
Dies war sogar schon testweise vorbereitet gewesen und ist jetzt durchgeschleift, nachdem die anderen Module das auch entsprechend berücksichtigen.
Bei mir bereits gefixt; für dich schon teilweise live, Rest kommt, nachdem du etwas editiert hast.
Hm das ist ja alles schön und gut, aber für meine Begriffe ufert das langsam völlig aus!? Also ich meine damit vollkommen offensichtlich und wirklich sehr seltene Fehler sollten immernoch per Hand gefixt werden und nicht in eine Abfrage rein die dann bei jedem Edit den ich machen möchte (mit meinem schwachen Netbook, ladetechnisch wie rechnerisch) alles und alle belasten. Daher möchte ich hier eine Abwägung der Nutzen-Kosten klar zu Gunsten des Optimums zu überbedenken. Es sei den die Abfrage ist keine große Sache oder zusätzlicher Umstand. LG -- ΠЄΡΉΛΙʘ21:18, 17. Nov. 2012 (CET)Beantworten
Es ist keine zusätzliche Mühe; das Skript sucht den sichtbaren Teil des Textes danach durch, wo eine öffnende eckige Klammer steht. Hat es eine gefunden, guckt es, ob das, was (abgesehen von ein paar Leerzeichen) unmittelbar dahinter steht, zu einer URL passen würde (// oder http); oder ob eine zweite öffnende Klammer folgt (abgesehen ggf. von ein paar Leerzeichen), dann ist es vermutlich ein Wikilink; wenn das auch nicht, dann schaut es, ob nun in Sichtweite (gleiche Zeile) ohne weitere öffnende Klammern zwei schließende folgen. Das Skript steht also sowieso schon an der Stelle, und in den meisten Fällen verweisen öffnende eckige Klammern auf die bekannten Syntaxelemente. Gelegentlich setzt mal jemand eine Anmerkung oder im Zitat ein […] in eckige Klammern; wenn das nicht mit zwei Klammern schließt, ist der Fall klar und das Skript springt weiter.
Zwar sind die von RonMeier angetroffenen Fälle ein seltener Zufallsfund. Allerdings öffnet das Projekt Syntaxkorrektur gezielt solche Seiten mit genau diesem Fehler, um ihn zu fixen.
@Perhelion: Du verstehst hier etwas falsch - ich meckre nicht über irgendwelche seltenen Fehler, sondern ich mach den Vorkoster für die Sachen, die nach und nach in WSTM5 eingebaut werden und SOLL jede erkennbare Fehlfunktion hier zu Papier bringen. Mir wärs lieber gewesen, wenn der Dialog zu den Fehlern irgendwo auf einer Extraseite ablaufen würde, weil ich genau mit solchen Anmerkungen irgendwann (eigentlich schon viel früher) gerechnet habe. Also, trotzdem schönes Restwochenende --RonMeier (Diskussion) 00:01, 18. Nov. 2012 (CET)Beantworten
Wenn ich jetzt noch auf dem Laufenden bin, müsste der Fix für RonMeier nun live sein.
Was die Seiten angeht: Es ist schon ganz okay, wenn die Entwicklungsdoku hier offen abläuft und von allen verfolgt werden kann. Geheime Extraseiten braucht es nicht, und manchmal ist es ja eine Woche ruhig.
Sofern kein häufig zu vermutendes und Seiten beschädigendes Problem auftritt, laufen neue Module oder deren größere Verbesserungen teilweise wochenlang für RonMeier und Steak im Probebetrieb, bevor sie für alle Nutzer hochgeladen werden; Mitteilungen über beobachtete Fehler sind dabei ausdrücklich erwünscht, weil nicht jede erdenkliche Kombination in den Standard-Testfällen auftritt und teilweise nur durch bloßen Zufall in irgendeinem verworren formatierten Artikel auftritt. Hier war es die Kombination aus einer fehlenden Klammer und gleichzeitig einem vereinfachten Linktitel.
Danke für die Info; und sorry, Aufhängen und Browser-Absturz ist immer misslich.
Auch schön war die Zeilennummer 1400.
Ich kann es reproduzieren.
Ursache ist vermutlich, dass der Artikel nur aus der SLA-Vorlage bestand und mit der schließenden Klammer endet. Inzwischen hat jemand etwas ergänzt, und es sollte in diesem Artikel nicht mehr abstürzen, solange er noch nicht gelöscht ist; machte es auch nicht mehr. Äh, ja, zu spät. Gut mitgedacht, den ehemaligen Text hier mit einzukopieren.
Es ist aber natürlich legitim, dass eine Seite nur aus einer Vorlageneinbindung besteht.
Der Fix wäre an einer diffizilen Stelle vorzunehmen, wo ich keine Kollateralschäden anrichten möchte. Deshalb bräuchte ich eine Weile an Erprobungs- und Testphase, während ich schon recht genau weiß, was zu ändern wäre.
Ich bin mir relativ sicher, den Bug bei mir auf der Festplatte gefixt zu haben, möchte es aber trotzdem gern erst einige Tage testen.
Es kann nur auftreten, wenn schon am Beginn der Seite eine Vorlage beginnt und diese den gesamten Artikel ausmacht und man keine benutzerdefinierten Ersetzungen verwendet.
So wie es aussieht, hat seit 4. Juli 2012 kein WSTM-Benutzer einen Artikel mit vorhandenem SLA erneut geöffnet; also kein alltägliches Phänomen.
Letzter Kommentar: vor 11 Jahren5 Kommentare2 Personen sind an der Diskussion beteiligt
Warum werden die Bindestriche in der Infobox nicht durch Bisstriche ersetzt, obwohl ich das in meiner Vector.js so definiert habe? Steak21:47, 19. Nov. 2012 (CET)Beantworten
Weil ich zurzeit mit der Anwendung von Text-Ersetzungen auf die Werte von Vorlagen-Parametern noch etwas zurückhaltend bin.
Ich hatte jetzt aber zwei Monate Ruhe vor diesen dämlichen verschachtelten Vorlagen und wieder Kraft, mich damit auseinanderzusetzen. Nachdem ich heute darin einen Bugfix machen musste und ohnehin in den letzten Tagen noch ein Feature zu Vorlagen aufpoliert hatte, schaue ich mir auch diesen Wunsch gern genauer an.
Mittelfristig ist es so gedacht, dass die Text-Ersetzungen auch auf die Zuweisungswerte der Parameter angewendet werden sollen. Mal sehen, wie lang der Abend noch so wird.
Wird schon noch; ohnehin nur mit der d-Version. Ich hatte RonMeier heute nachmittag versehentlich rausgehauen wegen der für die Anwendung der Text-Ersetzung auf Parameterwerte erforderlichen Umbauten. Bei mir von der Festplatte geht das seit heute; ich guck mal. „Für dich“ meint immer: d-Version; für die Allgemeinheit sind mir das einstweilen zu viele Veränderungen in einer zu kniffligen Ecke. --PerfektesChaos20:16, 20. Nov. 2012 (CET)Beantworten
Ein Patient, der Läuse hat, kann auch Flöhe haben.
Es war ein anderes apply is undefined in einem anderen Modul, das ich gefixt hatte.
Bei mir geht der Artikel glatt durch, aber ich habe auch die Einstellungen für meine Weiterentwicklung – von denen müsste ich erstmal runterkommen. Der Fehler tritt in einem veralteten Zweig auf, der aber eigentlich schon seit einem halben Jahr unverändert ist.
Oder ich schalte meine Weiterentwicklung, die jetzt sechs Wochen glatt lief, mal für dich frei.
Äh, nein, ist eine andere Änderung in einem anderen Modul, dessen Reihenfolge ich für Steaks Wünsche gestern geändert hatte; da musste ich die Definition vorziehen, damit es für die Änderung der Vorlagenparameter passt. Deshalb ist es auf meiner Festplatte nicht undefined/undefiniert. Bei dir müsste es auch gleich passen. Puuuh, das wird ein längerer Akt, die ganzen Änderungen der Reihe nach für alle Anwender freizuschalten.
Statt einer Zahl wurde gefunden: für Eintragungen eines Flugbuchs
Leerzeichen wird als teils zulässige Syntax, teils falsch getipptes Gleichheitszeichen interpretiert.
Muss ich denken.
Wenn kein Gleichheitszeichen, sondern Leerzeichen, und danach auch keine Zahl, dann soll es wohl kein Bildparameter werden, sondern die Bildbeschreibung.
Miniatur eines Gemäldes von Rembrandt hätte womöglich ähnliche Probleme.
Es wird keine Fehlermeldung mehr kommen, wenn nicht
entweder Ziffern folgen oder
weder Gleichheitszeichen, Doppelpunkt noch Unterstreichungsstrich nach dem Schlüsselwort folgen.
<nowiki /> hilft in uneindeutigen Fällen.
Bei mir schon mal umgesetzt; weil seit Monaten unbeanstandet über -zig Artikel gelaufen, als nicht dringlich in die laufenden Aktualisierungen eingetaktet. Muss ich erstmal selbst erproben.
P.S.: Zwischen Weblink und Domain muss man weder „auf“ noch „Auf“ schreiben; wenn der Titel des Weblinks kursiv steht, kann die Domain oder der Name des Anbieters gerade stehen und ist dann deutlich unterscheidbar; folgt kommentarlos auf das Weblink.
Den haste dir vermutlich selber gebaut, wenn auch auf eine Empfehlung von mir hin.
In deinen benutzerdefinierten Ersetzungen machst du wohl etwas mit refSatzzeichen. Bei denen ist aber aus gutem Grund die < ausgeschlossen. Übrigens waren es vorher schon drei ref; also scheinen es bei dir dann vier zu sein. Kommentiere doch mal ganz unten .url.concat(refSatzzeichen) aus.
Zwischen dem zweiten und dem dritten ref steht ein Zeilenumbruch. Der wird benutzerdefiniert entfernt, und deshalb erscheinen jetzt drei in einem Absatz, vorher zwei im ersten und einer in weiterer Zeile. Richtig? --PerfektesChaos13:01, 22. Nov. 2012 (CET)Beantworten
Der Zeilenumbruch wird entfernt und alle vier refs stehen in einer Zeile. Nach auskommentieren von .url.concat(refSatzzeichen) wird der Zeilenumbruch nicht entfernt und es tritt auch keine Verdopplung auf. Gruß --RonMeier (Diskussion) 13:25, 22. Nov. 2012 (CET)Beantworten
Also, ich zähle im derzeitigen Zustand des Artikels zwei in derselben Zeile, die enWP als [20]=URL#39 und danach als [21]=URL#40 die www.alstom.com/press-centre/2008/11/The-Municipality-of-Istanbul-exhibits-the-new-metro-delivered-by-Alstom-20081107/.
In der Zeile danach kommt die gleiche URL noch einmal als [22]=URL#41 und verwirrt dich? Abschließend der Punkt.
Sowieso ein konfuser Artikel; die EN 1,2,3,4,5,6 und 12 verweisen auf die gleiche URL.
Es liegt hier daran, dass das Innere des references nicht analysiert wird.
Könnte das auch bei den anderen von dir beobachteten Fällen der Fall gewesen sein?
Ist eine kitzlige Angelegenheit mit Verschachtelung; muss ich heute abend mal in Ruhe meditieren. Irgendein Nebeneffekt einer Änderung der letzten Monate, dem entgegenzuwirken wäre.
Die Pfahlwurzel ist so schön kurz; lass sie mir mal zum Spielen.
War kein Nebeneffekt, sondern mit WSTM.5 ist der Inhalt des Blocks references vom unmittelbaren Artikeltext isoliert worden. Analysen und Änderungen, die dort gelten sollen, müssen gesondert gestartet werden.
Für ISBN und einiges mehr inzwischen live; die Pfahlwurzel mag gedeihen. Ich muss nochmal nachschauen, ob die wenigen analogen include-Blöcke und benutzerdefinierte Text-Änderungen auch erfasst werden.
Ob die anderen nicht erkannten auch im references-Block waren, weiß ich nicht mehr. Benutzerdefinierte Änderungen gehen - jedenfalls habe ich nichts Auffälliges entdecken können. Erstmal Danke. Ertragreiches Wetter - Gruß --RonMeier (Diskussion) 12:43, 29. Nov. 2012 (CET)Beantworten
ist die normale Verarbeitung und Formatierung eingeschränkt, weil besondere Syntaxregeln gelten.
Das war schon im Mai konzeptionell angelegt gewesen und der Ansatz programmiert worden; auf deinen Hinweis hin habe ich dies nun neu strukturiert und für Ersetzungen vervollständigt. Wobei Typografie nix für imagemap ist. Probiere ich jetzt mal selbst aus.
Letzter Kommentar: vor 11 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
oder jeder andere Artikel mit der Infobox Schiff: Es ist nicht direkt ein Fehler und auch beabsichtigt, aber mir gefällt nicht, dass das Skript in die Tabelle der Infobox diverse 1=, 2= usw. einsetzt. Hab mich nich näher damit beschäftigt und weiß nicht, ob die Pips nötig sind, ich vermute aber schon. Steak22:07, 27. Nov. 2012 (CET)Beantworten
Muss ich bei Gelegenheit drüber nachdenken, ob und wie ich das jetzt für diese IB abschalte. Das Problem ist die etwas unübliche Anordnung der Parameter bei der Einbindung. Normalerweise schreibt man bei einer Vorlage erst alle unbenannten (teils Pflicht-)Parameter an den Anfang und hinterher die optionalen benannten Parameter. Hier will man die benannten mit Kategorie, Name, Bild zuerst auf der Seite sichtbar haben (weil sie sonst untergehen, blubb) und kommt danach erst mit den unbenannten Unter-Boxen. --PerfektesChaos22:39, 27. Nov. 2012 (CET)Beantworten
Letzter Kommentar: vor 11 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
Wenn ich z. B. mit dem Skript Weiterleitungen korrigieren will (z. B. soll [[USA|irgendwas oder auch nix]] zu [[Vereinigte Staaten|irgendwas oder auch nix]] werden), kannst du mir bitte dafür die Syntax geben? Steak22:12, 27. Nov. 2012 (CET)Beantworten
Kein Webserver ist gezwungen, die Prozentzeichen-Syntax zu entschlüsseln. In der Frühzeit (aus der noch einige Software online ist) war das auch nicht üblich gewesen. WSTM hat im Unterschied zu normal editierenden Benutzern keine Möglichkeit, um auszuprobieren, ob das mit Prozentzeichen geklappt hat. Deshalb escaped WSTM nur die Wiki-Klammern so, dass sie genau die Klammern zum fremden Webserver schicken, wie sie dort selbst in der URL geschrieben werden.
WSTM kennt sie und analysiert den Parameter auf Sinnhaftigkeit.
Es gibt mir genug Trouble um deutsche und englische Syntax, als dass ich allen Benutzern hier noch eine Ersetzung aufzwingen möchte. Ich kann aber über eine Benutzeroption nachdenken, die das Ersetzen veranlasst; wie du hier sehen kannst, ist die Übersetzung WSTM bekannt. Für die knapp 4000 Verwendungen mache ich mir aber keinen zu dicken Kopf, zumal einige Hundert auch Quatsch sind.
Letzter Kommentar: vor 11 Jahren11 Kommentare2 Personen sind an der Diskussion beteiligt
Nun bin ich auch gerade dabei auf Commons zu testen und dabei auf Schwierigkeiten gestoßen. Mit dem Sprachkürzel En hat es schonmal funktioniert, allerdings ist dieser dort unbrauchbar (da ja :en: in Links entfernt). Nun habe ich "commonswiki" benutzt allerdings kommt nun dieser Fehler (welcher wohl im direkten Zusammenhang zu stehen scheint):
Uncaught TypeError: Cannot call method 'toLowerCase' of undefined https://en.wikipedia.org/w/index.php?action=raw&ctype=text/javascript&title=User:PerfektesChaos/js/WikiSyntaxTextMod/rM.js&520404609* :557
Kann ich notfalls im Lauf des Wochenendes auf Commons ausprobieren; allerdings musst du gar nichts machen.
Was du mit dem Sprachkürzel möchtest, habe ich nicht verstanden. WSTM findet eigentlich selbst die Projektsprache und müsste von selbst auf en kommen. Das hat aber keine Bedeutung für dich. Die Fehlermeldungen bekommst du auf deutsch, wenn du es auf Commons als Benutzersprache gewählt hast.
Lass einfach das .lang.accept weg; das ist dazu gedacht, dass du innerhalb der deWP ein anderes Projekt simulieren möchtest.
Gleichwohl sollte WSTM nicht abschmieren.
Die Fehlermeldung verstehe ich sowieso nicht; rM hat nur 457 Zeilen, in Zeile 557 steht nichts.
Ich habe wohl diesen Fehler gefunden; war ein banaler Schreibfehler/Wortvertauscher.
Es empfiehlt sich, dass du deinen Browser-Cache löscht.
Ansonsten läuft bei mir alles brav.
Zu der Geschichte mit dem .lang.accept – du brauchst commonswiki nicht zu sagen, dass Commons englisch verstehen soll; das weiß WSTM schon und en wird in jedem Projekt verstanden. Aber du kannst im commonswiki vereinbaren: .lang.accept="de" und außerdem "File:" bzw. (dewiki) "Datei:" in deine page.include aufnehmen, dann wirkt es auch auf Dateibeschreibungsseiten.
Danke (und fürs schneller fixen), nachdem ich die Angaben entfernt habe funzts. Allerdings im Angesicht damit als Pionier durch Commons zu wandeln, bleiben wohl der ein oder andere weitere Bug nicht aus. ^^
Der Link, dessen Fehlen du oben beweint hast, bekommst du wieder mit
libs.WikiSyntaxTextMod.config.portlet = true;
Problem mit der 50-Byte-Dateibeschreibung:
Es hängt anscheinend zusammen mit dem gleichzeitigen Ablauf von Standard-Tools in Commons. Namentlich solche auf Special:Preferences#mw-prefsection-editing.
Es kommt zu einem Wettrennen zwischen dem Aufbau irgendwelcher Buttons und WSTM, etwa bei "Enable enhanced editing toolbar" zu beobachten; es hätte aber auch das Nayaram-Schema sein können.
WSTM will eigentlich nichts weiter unternehmen, aber dieses "enhanced editing toolbar" will mit seinem Server kommunizieren (steht eigentlich schon alles im Browser-Cache) und hängt sich dabei auf.
Vielleicht weil dieser Text so extrem kurz ist, läuft WSTM wahrscheinlich auch besonders schnell durch.
Ich kann den Effekt reproduzieren, jedoch nur, wenn ich nach Cache-Löschung vom Server lade. Von Festplatte passiert nichts dergleichen.
Probier mal aus, was bei dir passiert, wenn du "Enhanced editing toolbar" und dessen Fortsertung wegklickst. Was ist mit anderen sehr kurzen Dateibeschreibungen?
Hallo PerfektesChaos, die obigen Fehler sind soweit behoben, danke! :) Jedoch stellt sich ein anderer schwerer Fehler der die Benutzung unmöglich macht: alle Links mit w: oder :en: (at beginning) werden geschröpft. :-/ (wobei ich noch einen anderen Fehler beobachtet habe, der mir aber gerade nicht einfällt ^^) LG -- ΠЄΡΉΛΙʘ17:38, 25. Nov. 2012 (CET)Beantworten
Schau ich mal. Bisher war ich nur auf fremdsprachlichen Wikipedien (w) und Wikisource (s) testweise unterwegs; Commons ist ein Sonderfall und hat wahrscheinlich ein Identitätsproblem. Klingt so, als ob Commons sich selbst für die englischsprachige Wikipedia hält. Wird sich einfach beseitigen lassen, und in der Ecke wollte ich sowieso ein neuartiges Feature einbauen. Liebe Grüße --PerfektesChaos17:55, 25. Nov. 2012 (CET)Beantworten
Wurde gefixt; die geänderten Module gehen zurzeit testweise unter den scharfen Augen meiner Vorkoster entlang. Bis Weihnachten sollten sie bei dir angekommen sein; das kann ich nicht vorhersagen.
Ursache war, dass das Projekt von sich selbst wusste, dass seine Projektsprache en ist. Findet es nun ein Link auf en, dann hält es das Sprachkürzel für überflüssig.
Mir war bislang noch gar nicht so aufgefallen, dass auf Commons :en: direkt in eine WP verlinkt.
Ich habe angefangen, Commons und Meta als sprachunabhängige aber englischsprachige Projekte zu kennzeichnen. Mittelfristig werde ich dies umkehren; war bislang der Regelfall ein sprachdifferenziertes Projekt wie WP, books, versity, source und Commons war die Ausnahme, wird dies künftig umgedreht und die Handvoll Projektarten mit Sprachversionen werden als solche markiert und alle anderen werden englischsprachige Zentralprojekte.
Hartes Schicksal: WSTM möchte wissen, wie es nach der ISBN weitergeht und welches nicht-Leerzeichen oder nicht-Trennzeichen danach kommt. Hier ist das letzte Zeichen des Textes der Punkt nach der beanstandeten ISBN. Ich schau mir mal an, ob sich da etwas machen lässt. Die gleiche Situation entsteht vermutlich, wenn nach der ISBN ein Kommentar käme.
Nach Blick in den Quellcode: Ohne den Punkt hätte es geklappt; der momentane RegExp erwartet, dass entweder mit der letzten Ziffer der ISBN alles vorbei ist oder aber es nach einem Punkt noch weitergeht. Ich denke drüber nach und lasse das gelegentlich in den Bestand einfließen. Was es nicht alles gibt --PerfektesChaos23:05, 23. Nov. 2012 (CET)Beantworten
Letzter Kommentar: vor 11 Jahren6 Kommentare2 Personen sind an der Diskussion beteiligt
Ich möchte in z.B. der Vorlage Literatur im Parameter Seiten= bei bis-Angaben den Strich zwischen den Seitenangaben normieren. Unter WSTM4 war das möglich, mit den Vorgaben der Doku zu WSTM5 ist es (noch) nicht machbar. Wie geht es? Gruß --RonMeier (Diskussion) 15:44, 24. Nov. 2012 (CET)Beantworten
Es gibt zwei Fälle:
Allgemeine Text-Ersetzungen
Gerade mit dem heutigen Tag habe ich das letzte Paket Bugfixes im Vorlagen-Bereich auf alle Benutzer losgelassen. Da will ich erstmal ein paar Tage abwarten, dass hoffentlich keine Reaktionen kommen.
In diesem Paket ist jetzt ansatzweise bereits eingebaut, dass nun die allgemeinen Text-Ersetzungen (.mod.plain) auf schlichte Zeichenketten als Parameterwert angewendet werden sollen. Bei mir funktionierte das testweise. Steak meinte vor ein paar Tagen, dass sich das in der d-Version noch nicht ausgewirkt hätte. Muss ich mal gucken; vielleicht erfolgt zwar die Änderung am Parameterwert, aber dem Gesamt-Text wird noch nicht deutlich genug gemeldet, dass sich dieser Parameterwert geändert habe. Dies aber erst, wenn die letzte Änderung stabil ist.
Vorlagen-spezifische Text-Ersetzungen
Vorgesehen ist, dass man spezifizieren können soll, dass nur bei einer bestimmten Vorlage nur ein ganz bestimmter Parameterwert geändert werden soll.
Dabei könnten möglicherweise auch die aktuellen Werte anderer Parameter in die Bildung des neuen Wertes einbezogen werden.
Hierfür gibt es zwar schon ein präzises Konzept, aber noch keine Implementierung für Benutzerdefiniertes.
Was du brauchen würdest, wäre der zweite Fall. Die allgemeine Text-Ersetzung sieht nur isoliert die Zahlen. Was sie nicht weiß, ist, dass es sich um den Parameter Seiten der Vorlage Literatur handeln würde. Das muss sie aber wissen, wenn sie nicht jedes beliebige Vorkommen zweier Zahlen mit Bindestrich dazwischen ummodeln wollte.
Nun ist die Vorlage Literatur aber eine -zigtausendfach eingebundene Standardvorlage. Hier könnte ich für alle Benutzer von Amts wegen diese Formatierung intern sehr viel leichter einbauen, so wie bereits Normdaten und Personendaten immer auch hinsichtlich der Parameterwerte standardisiert werden. Grundsätzlich ist das intern leicht möglich. Mal sehen.
Für dieses Wochenende habe ich mir vorgenommen, endlich mal den mehrmonatigen Rückstand der von dir genannten Vorlagen-Doku aufzuarbeiten, wenn auch Daniel mit seinen Straßen glücklich geworden sein sollte.
Wenn du denn demnächst mit dem Einbau in die Vorlage Literatur loslegst, kannst du dann auch die hoffentlich austerbenden Vorlagen cite book, cite web usw. mit berücksichtigen? Danke fürs Werden der Doku und für demnächst. Gruß --RonMeier (Diskussion) 20:28, 24. Nov. 2012 (CET)Beantworten
Die cite werde ich nicht von Amts wegen für alle anfassen. Das kannst du dann hübsch alleine machen. Allerdings bedarf es hier meiner Erinnerung nach des Komponierens des Namens aus den Vor-, Mittel- und Familiennamen, und das ist zurzeit noch nicht benutzerdefiniert programmiert. Grundsätzlich ist das Umschreiben von einer Vorlage auf eine andere aber möglich. VG --PerfektesChaos21:25, 24. Nov. 2012 (CET)Beantworten
Soweit vorpreschen wollte ich ja gar nicht. Aber wenn change dann auch geht, und dokumentiert ist, versuch ich mich natürlich daran. Ich wollte erstmal nur pages= in den entsprechenden englischen Vorlagen berücksichtigt wissen. Gruß --RonMeier (Diskussion) 21:34, 24. Nov. 2012 (CET)Beantworten
Letzter Kommentar: vor 11 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
und viele andere Artikel: Das Skript macht irgendwas mit dem ml-Interwiki-Link. Mag sein, dass es richtig ist, ich finde es jedoch sehr unschön, wenn zwischen den fremden Zeichen plötzlich ein "zwnj" oder sowas steht. Steak22:09, 27. Nov. 2012 (CET)Beantworten
Habe ich heute auch bemerkt und bereits entsprechend eingefügt. Malayalam ml war bislang nur bekannt durch ‍ und kommt von alleine mit der Berichtigung, sobald andere Änderungen ausgetestet sind. Schaden wird nicht angerichtet. Irgendwie ist offenbar das ml-wiki wach geworden und schmeißt plötzlich massenhaft IW-Links auf den Markt. VG --PerfektesChaos22:27, 27. Nov. 2012 (CET)Beantworten
Öh, das liegt daran, dass mir die Existenz dieser Vorlage bis eben unbekannt war. Gibt es erst seit August 2011. Danke für die Info.
Wikiatlas ist in dem Sinn kein klassisches eigenes Schwesterprojekt, sondern eine Art Shortut wie Commonscat. Dort auch soeben eingetaktet; wird in mittlerer Zukunft genauso gehandhabt.
Äh, ja, mein Klick auf „nächste 500“ war nicht schnell genung ausgeführt worden; ich war schon bei den 287 Einbindungen; also pro aktuelles/historisches Land eine. Der Globus war mir nie aufgefallen. --PerfektesChaos10:50, 30. Nov. 2012 (CET)Beantworten
Die gleiche Situation wurde bereits einmal im September-Archiv thematisiert.
Es geht um benutzerdefinierte typografische Ersetzungen.
Der erste Parameter der Schwesterprojekt-Vorlagen ist ein Linkziel; dahinter verbirgt sich ein Seitenname im Schwesterprojekt. Davon weiß WSTM.5 aber bislang noch nichts; bislang ist das ganz normaler Text.
Wenn ich irgendwann mal dazu komme, schütze ich den ersten Parameter dieser Vorlagen als Linkziele, damit Steaks typografische Apostrophe nicht mehr drankommen. Allerdings fallen sie dann auch unter Link-Ersetzungen, und das ist etwas sorgfältiger an das Interwiki anzupassen und etwas aufwändiger.
Gelegentlich habe ich einen Akt vor, mit Linkzielen innerhalb von Commons und weiterem Interwiki-Verlinken. Irgendwann auch dieses.
Gefixt und für dich live zur Nachkontrolle. Hoffentlich keine Folgefehler an anderer Stelle dadurch.
Sobald da mal etwas Ruhe und Stabilität eingekehrt ist, muss ich das ganze Thema „URL als Wikilink“ mal komplett neu und mit den jetzigen Erkenntnissen angereichert strukturiert schreiben. Das kleine Unterprogramm hat inzwischen zu viele Ausnahmeregeln erfahren; für Vor-WMF-Wikivoyage, Old Wikisource und nicht sprachendifferenzierte Zentralprojekte bis hin zu wikispecies und Spezialseiten. Und es gibt eine bunte Vielfalt, wie man eine URL umgestalten kann und trotzdem nur das banale Wikilink dabei herauskommt. Ursprünglich mal hatte das nur für eine Handvoll Schwesterprojekte statische /wiki/-URL in Wikilinks umgewandelt.
Können ja woanders aufpoppen; so wie mit den Maulwurfshügeln … Irgendwann halt mal neu programmieren. Übrigens hattest du da ein neu gebildetes Wikilink species:Chelicerata in die enWP verlegt; vielleicht findest du den enWP-Artikel spannender als das Wikispecies, aber dann solltest du das Wort species: da rausnehmen, das unser Server witzigerweise ignoriert. Ich muss ja auch nicht immer alles verstehen. Schönen Advent --PerfektesChaos16:00, 8. Dez. 2012 (CET)Beantworten
Sorry, ungeahnter Nebeneffekt zweier vertauschter Zeilen; da hatte ich mich hintenrum selbst rechts überholt. Gut, dass es euch zwei Vorkoster im Inkubator gibt; das war noch nicht für die Normalanwender wirksam geworden.
Weil das schon eine Generation weiter gefixt ist, bitte einmal Browser-Cache wirksam löschen.
Äh, ja, ich erprobe ein neues Feature (formale Zulässigkeit von DNB, DOI, ISBN, ISSN, PMC, PMID) und hatte eine Negation vergessen. Was WSTM dir sagen wollte: Mit diesen DNB ist alles in Ordnung; wenn du die DNB formal falsch machst, bekommst du keine Meldung und das wäre die Fehlererkennung … ignorieren, klärt sich im Lauf des Abends, wenn auch einige andere Module ausgebaut worden sind. Sorry --PerfektesChaos12:10, 11. Dez. 2012 (CET)Beantworten
Letzter Kommentar: vor 11 Jahren5 Kommentare2 Personen sind an der Diskussion beteiligt
Bei diesem Artikel hängt sich mein Firefox auf, sobald ich Editieren will. Unangemeldet geht's. Ich glaube, es muss wohl an WikISyntaxTextMod liegen, habe aber keine Ahnung, ob das stimmt und woran es liegt. --FA2010 (Diskussion) 13:24, 11. Dez. 2012 (CET)Beantworten
Stimmt leider.
Wenn ich bei WSTM die benutzerdefinierten Ersetzungen abschalte, geht es; wenn wie bei dir wohl keine Ersetzungen aktiviert sind, hänge ich auch.
Eigentlich fehlt der Seite nichts als ALTERNATIVNAMEN; vielleicht irritiert das irgendwo.
Lass die Seite mal links liegen; heute im Lauf des Nachmittag dürfte das Problem identifiziert = gefixt sein, und am Abend oder morgen müsste es gehen.
Während ich zuvor das Problem reproduzieren konnte mit der gleichen Konfiguration, die du auch benutzt, gab es gegen 15:00 oder so einen Server-Streik (Adventszeit; spendet! spendet! Alle Jahre wieder im Dezember vermehrter Server-Ausfall) und seitdem bekomme ich das Problem nicht wiederhergestellt.
Meine Vermutung: Es gab irgendeine Beschädigung an irgendeiner Seiten-Komponente, die auf mysteriöse Weise mit irgendwas in WSTM interagierte; vielleicht war der besonders kurze und einfache Artikeltext durch schnelle Zeitabläufe im Minimal-Modus beteiligt. (FF 17.1) – BKL-Check und Rechtschreibprüfung waren unterwegs.
Witzig, jetzt geht's auch bei mir, ganz ohne Browser-Cache-Löschen. Das Problem war bei mir noch nie irgendwo aufgetaucht, und ist es auch seither nicht. Ich melde sowas halt immer gleich, vielleicht hilft es ja größere Probleme schneller zu erkennen. An sich ist es ja nicht schlimm, wenn alle paar tausend Artikel mal ein Fehlerchen auftritt, der sich zudem nicht im Wiki auswirkt, sondern nur auf meinem PC... --FA2010 (Diskussion) 10:02, 12. Dez. 2012 (CET)Beantworten
Melde ruhig weiter.
Es kommt ganz gelegentlich zu unerklärlichen Effekten dieser Art; auffällig ist, dass es sich um sehr kleine Artikel ohne besondere Schwierigkeiten handelt. Mein Verdacht ist, dass es unter bestimmten Umständen zu einer Kollision mit noch eintreffenden Ergebnissen kommt; während WSTM schon eine Diffpage auslöst, wollen vielleicht API-Resultate noch irgendwas machen. Moderne Browser sind vielleicht zu schnell und verarbeiten zu viele Sachen gleichzeitig. Zu reproduzieren ist das extrem schwer, wenn es dann wie hier auch noch von selbst verschwindet. Es gibt auch von MediaWiki allerlei Prozesse, die vor sich hinrödeln; so auch die Werbebanner.
Seeteufel hatte bei der Anlage die Klammern vergessen (und den Schrägstrich hinter references; nebenbei ein Grund, sich den immer deutlich mit Leerzeichen abzusetzen).
Bei mir passiert nichts weiter. Die Klammern werden auch nicht ergänzt, weil zumindest eine schließende erforderlich ist. Ich habe auch allerlei Varianten durchprobiert.
Letzter Kommentar: vor 11 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt
Kleiner Vorschlag 〈brennt bei mir noch vor dem Weltuntergang auf dem Herzen〉, der Präfix “Datei:” sollte nicht gänzlich gelöscht werden, sondern zumindest als Leerzeichen erhalten bleiben. Bei größereren Galerien leidet die Übersichtlichkeit erheblich, selbst wenn man wie ich den Syntaxhighlighter benutzt. VG -- ΠЄΡΉΛΙʘ18:28, 20. Dez. 2012 (CET)Beantworten
Leerzeichen haben aber eine Funktion. Vielleicht nicht innerhalb von Galerien, aber ich fände sie da ein wenig irritierend. Viel eher würde ich dafür plädieren, das „Datei:“ einfach immer stehen zu lassen. Mir erscheint es viel besser verständlich, wenn die Syntax der normalen Bildeinbindungs-Syntax soweit wie möglich gleicht. --TMg19:47, 20. Dez. 2012 (CET)Beantworten
WSTM rückt seit 2010 alle Zeilen gleichmäßig anhand der meisten vorgefundenen Leerzeichen am Zeilenanfang ein.
Du müsstest deinen Vorschlag erstmal unter H:gallery #Standard editieren; wenn das dann eine Weile so allgemein akzeptiert bleibt und es offensichtlich konsensfähig wäre, brauche ich bloß das Minimum auf 1 oder 2 zu setzen.
Einrücken ist bei vielen Autoren üblich; ich sehe es nicht als problematisch an und finde dadurch auch die Übersichtlichkeit des gallery-Bereichs erhöht. Gleiches kann ich mir für imagemap vorstellen. Das war mir aber bislang zu selten.
Wenn da kein Schlüsselwort steht, kann sich niemand darüber aufregen, ob es File oder Image oder Datei oder Bild heißt. Allgemein bevorzuge ich eine kurze und von redundanten Informationen befreite Syntax, wenn es dadurch nicht zu kryptisch wird. Die normale Dateieinbindung verwendet meist Parameter, gallery nicht.
Auslösend war die 1:1-Flaggeneinbindung in die Infobox-Vorlage.
Zurzeit erprobe ich neue Analysen der Bildparameter bei komplex verschachtelten Bildlegenden, aber so ganz ohne irgendwas war dafür zu einfach, und so griff er irrtümlich in das Pipe-Symbol der Vorlage.
Letzter Kommentar: vor 11 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Aus dieser Version Heo_Mok&oldid=106098930 entfernte das Tool fälschlicherweise den Paramter lang=en aus der Wikisource-Vorlage. Nun war das Ding auch alles andere als wohlformatiert, aber funktioniert hat's vorher, und nachher stimmt der Link nicht mehr... --FA2010 (Diskussion) 16:05, 26. Dez. 2012 (CET)Beantworten
Hmmm, schwierig.
Das Skript erwartet nur maximal drei Parameter. Durch die doppelte Pipe erscheint das an Position vier, und was immer dort steht, existiert nicht und verschwindet.
Ich kann als Sofortmaßnahme (heißt: 2013) eine Warnung auf fehlformatierte Schwesterprojekt-Vorlage anzeigen (Keim dafür soeben gepflanzt).
Die Programmierung für Schwesterprojekte ist noch in der alten Zeichenketten-Analyse von 2011 geschrieben. Im Lauf der Zeit soll und wird das auf die modernere Vorlagensyntax-Analyse umgeschrieben werden, und dann kann ein benannter Parameter auch an 17. Stelle stehen. Ob das aber noch 2013 wird?
In den letzten mutmaßlich 100.000 Artikeln, die das Skript verdaut hatte, wurde dieses Problem zumindest nicht bemerkt.
Wert mit Gleichheitszeichen 82xxx=Südliche Frankenalb
Das ist nicht schön und bringt Textverlust.
Hintergrund ist ein mistiges Verhalten von JavaScript, weil das Zeugs (im Unterschied zu anderen Sprachen) den Beginn einer Zeichenkette und Zeilenumbrüche innerhalb dieser Zeichenkette nicht auseinanderhalten kann. Da muss ich jedes Mal doll denken und drumrumbauen.
Bitte bis nächstes Jahr stehenlassen; ich werde ein Momentchen brauchen.
Auf der Festplatte bereits gefixt, aber muss erst noch auf mögliche Nebenwirkungen untersucht werden.
Ursache war das Video mit |thumbtime=1.5| – hoffentlich hatten die das nicht mit dem |hochkant=1.5| in den beiden Dateien darunter verwechselt. Das Bild sieht aber stimmig aus. Eigentlich sollen die Minuten mit Doppelpunkt davor angegeben werden, und auf deren Fehlen war WSTM noch nicht gefasst gewesen.
thumbtime ist die Angabe der Minuten, Sekunden, Sekundendezimalbruchteile, zu der aus dem Video ein Standbild als Miniaturvorschau entnommen werden soll.
Letzter Kommentar: vor 11 Jahren18 Kommentare2 Personen sind an der Diskussion beteiligt
Jetzt ist mir zum ersten Mal ein Interlanguagelink mit einem nullbreiten Trennzeichen (U+200B) begegnet. Und ich dachte – gestützt durch die Praxis vieler anderer Skripte – dass das gelöscht werden dürfte. Irrtum. Du hast diesen Themenbereich schon sehr schön aufgearbeitet, davon werde ich mich wohl inspirieren lassen. ;-) Zwei kleine Fragen dazu:
Wäre es nicht konsistenter, in Links mit %-Kodierung zu arbeiten, in diesem Fall also mit %E2%80%8B? Im Wikitext spielt es keine Rolle, aber es ist die Kodierung, die auch der Webbrowser in der Adresszeile anzeigt, nachdem man einen solchen Link angeklickt hat.
Du schreibst, dass du geschützte Leerzeichen durch   ersetzt. Bedeutet das nicht, dass du einen Text schlimmstenfalls mit zwei Kodierungen für das selbe Zeichen hinterlässt? Warum nicht ?
Nein; das soll keine Änderung in der diffpage bewirken. Autoren sollen durch das Aufpoppen nicht verwirrt werden. Ich bekomme sonst massenhaft Beschwerden, dass WSTM sich irgendwelche Zeichen ausgedacht und neu in die Seite eingefügt haben soll; Steak hat es inzwischen gelernt.
Ob das überhaupt mit % ginge, weiß ich nicht; ich nehme die sicheren Entities. Die werden in der ersten Phase dort ersetzend eingebracht und hinterher bei den dafür zugelassenen Sprachen wieder einkodiert.
Firefox zeigt sie nicht in der Adresszeile; ich müsste die URL mit c&p irgendwo reinplumpsen lassen.
Über kurz oder lang erledigt sich diese Frage ohnehin von selbst; entweder kommt Wikidata oder der Weltuntergang.
 
Wenn sie vorher als Leerzeichen im Wikitext gestanden hatten.
Sie werden damit in der diffpage sichtbar. Bearbeiter können sich dann überlegen, ob sie es dort haben wollen oder es durch normales Leerzeichen überschreiben. Sie könnten unbeabsichtigt durch c&p irgendwohin verschleppt worden sein, wo es schädlich ist. Normale Bearbeiter haben sonst keine Möglichkeit, dies zu erkennen.
Bei einem weiteren Lauf von WSTM würden sie wie fast alle numerischen Entities umgewandelt (nämlich zu ).
Wenn ich es nicht zunächst als   darstellen würde, könnte man es bei der Bearbeitung nicht von den vorher schon vorhandenen unterscheiden.
Die Funktionalität der Seite verändert sich aber durch WSTM nicht.
Ach so, danke für die Erklärung. Ich dachte, die &-Kodierung würde stehen bleiben. Die Sache mit dem   ist ehrlich gesagt nicht schlüssig. ;-) Beim ersten Speichern bleibt es im Artikelquelltext, aber bei einer nachfolgenden Bearbeitung wird es doch zu einem „normalen“ ? Man müsste den Artikel also – hypothetisch gesprochen – zweimal bearbeiten, um die WSTM-Säuberungen zu vollenden? Das wundert mich etwas, wo du doch sonst so viel Wert auf Klarheit legst. --TMg18:36, 23. Dez. 2012 (CET)Beantworten
Da sie zuvor unsichtbar gewesen waren, wie auch der Titel des Threads nahelegt, muss ich dem Bearbeiter die Möglichkeit geben, sie durch normale Leerzeichen zu ersetzen, weil sie völlig unbeabsichtigt durch C&P überall ausgestreut worden sein können. Dazu müssen sie aber im Quelltext unterscheidbar sein. Demgegenüber ist die Zwischenstufe bei Unsichtbar → numerisch → nbsp auf dem Weg der fortschreitenden Verbesserung zu verkraften. Wenn vom ersten Bearbeiter in der automatischen Analyse die ungefragt aufpoppenden Dingsdas ignoriert wurden, hat ein anderer Autor dann auch ohne Skripte die Gelegenheit, sie systematisch dort durch normale Leerzeichen zu ersetzen, wo sie Unfug sind. VG --PerfektesChaos18:50, 23. Dez. 2012 (CET)Beantworten
U+200E und U+200F haben mich immer verwirrt. Irgendwie erscheint es logischer, Steuerzeichen zu verwenden, die von ihrer Position ausgehend in Leserichtung gesehen die Leserichtung umkehren. Dass das mehr verwirrt als hilft, sieht man schon an meinem Erklärungsversuch. ;-) Deshalb funktionieren die Zeichen anders: Sie werden vom Algorithmus wie ein Buchstabe mit der jeweiligen Leserichtung behandelt und bewirken nur etwas, wenn sie irgendwo zwischen Zeichen stehen, die selbst keine vorgegebene Leserichtung haben. Umkehrschluss: LRM (U+200E) ist wirkungslos und kann entfernt werden, wenn es direkt links oder rechts neben einem LR-Zeichen steht. Das wäre mein Erweiterungsvorschlag für dich.
Über U+200B habe ich mir ebenfalls Gedanken gemacht, aber keine so klare Antwort gefunden. Momentan gehe ich davon aus, dass das Zeichen allenfalls in exotischen Schriftsystemen Sinn ergibt, jedoch nie, wenn es direkt neben einem Zeichen aus einem der Latin-Unicodeblöcke steht. Oder strenger: Das Zeichen ist immer dann sinnfrei, wenn es direkt neben einem Zeichen steht, das sowieso einen Umbruch erlaubt (U+0020 usw.). --TMg20:13, 22. Jan. 2013 (CET)Beantworten
Danke, aber die Teilchen sind erfahrungsgemäß äußerst selten. In weniger als einem von 10000 Artikeln kommen sie lose und sinnlos vor, weil irgendwie mit C&P verstreut. Siehe Wartungsliste, die alle verbliebenen losen nullbreiten Zeichen und unerwünschte Spezial-Leerzeichen im Artikelbestand auflistet, Scan von 2011.
Häufig ist die Situation, dass von der Beo usw. kopiert wird und dann die lrm am Ende des Linktitels stehen. In diesem Fall entfernt WSTM automatisch und still.
Bei den Sprachen, die nullbreit im Linktitel auf fremde Projekte enthalten müssen, verstecke ich sie wieder wie vorgefunden; ansonsten mache ich als Entity sichtbar.
In allen anderen Fällen mache ich die verborgenen Zeichen als Entity greifbar, lasse sie auf der diffpage erscheinen, und falls dort keine Reaktion den späteren Autoren zugänglich.
Es gibt Kombinationen von hebräischen Buchstaben und lateinischen Ziffern oder englischen Ausdrücken. Ich werde den Teufel tun und hier ins Blaue raten. Wenn etwas unerwünscht ist, sieht jeder Bearbeiter das Entity im Quelltext und kann selbst entscheiden, ob arabisch, hebräisch oder malaiisch davor oder dahinter kommt oder nicht.
Abgesehen von der Sache mit den Latin-Unicodeblöcken war das kein Raten. Ich bin mir sicher, dass
U+200E unter allen denkbaren Umständen wirkungslos ist, wenn links oder rechts daneben sowieso ein Zeichen steht, das im Standard als links-zu-rechts gekennzeichnet ist.
U+200B wirkungslos ist, wenn daneben sowieso ein Zeichen steht, das gemäß Standard als mögliche Umbruchstelle gilt.
Mag ja sein, dass du dir da sicher bist; aber mir sind bei den exotischen Schriftsystemen bereits Linkziele begegenet, die mit einem nullbreiten Trennzeichen begonnen haben und beginnen mussten; als ich sie entfernt hatte, war das Interlanguage kaputt. Es hat auch Auswirkung auf die Darstellung des ersten oder letzten Buchstabens. Da es nur um die 20 verseuchte Artikel unter anderthalb Millionen gibt, jagen wir diese lieber gezielt mittels Dump-Analyse durch Fachleute, machen die Entities sichtbar, und löschen sie dann unter Beachtung des Kontextes manuell. --PerfektesChaos22:08, 22. Jan. 2013 (CET)Beantworten
Du unterstellst, dass der Wikitext perfekt arrangiert ist und alle Zeichen genau dort stehen, wo man sie erwarten würde. Dem ist nicht so. Genauso, wie wir Zitate haben, die mit einem " anfangen und einem “ beendet werden, oder von einem ASCII-Apostroph ' bis zu einem Akut ´ reichen. Es gibt aber beispielsweise hebräische und arabische Texte, bei denen etwa in Autokennzeichen oder Adressen ASCII-Ziffern auftauchen oder englische Namen zitiert werden. Hier steht das Bidi-Zeichen an einer Stelle, wo wir es von uns aus nicht setzen würden, und wo man es besser formatieren könnte. Lasse ich das nun wie von dir vorgeschlagen weg, kommt der gesamte Text linksrum. Außerdem gibt es mit C&P eingeschleppte komplexe POP-Bidis, die Anfang und Ende der Schreibrichtungen kompliziert genug machen. Schließlich können Wörter über Vorlagen zusammengesetzt sein.
Die ZERO-WIDTH-* können in Sprachen wie ml oder fa am Anfang oder Ende von Wörtern und Einzelbuchstaben stehen und sind auch Bestandteil der Links und Seitentitel. Sie können nicht weggelassen werden, wie du oben angedeutet hattest. Bei einem Dutzend Seiten mit einem möglicherweise vielleicht weglassbaren ZERO-WIDTH-* unter anderthalb Millionen Artikeln werde ich keine automatisierten Experimente lostreten, da ich beim Edit der hierdurch überforderten Anwender auch nicht daneben stehe. Für die Benutzer erschiene in der Diffpage nur eine unsichtbare Nicht-Änderung; vielleicht ein Leerzeichen entfernt?
Die Wiki-Software entfernt die LRM und RLM am Beginn und Ende neu angelegter Seitentitel, sonst nichts. Tauchen diese nun an den entsprechenden Steleln von Wikilinks auf, entferne ich sie automatisch.
WSTM arbeitet in allen Wikiprojekten aller Sprachen, Schriftsysteme und Schreibrichtungen.
Ich werde ansonsten keine unsichtbaren Zeichen löschen, sondern wie bisher nur als Entitiy sichtbar machen, wenn ihre Position nicht plausibel ist. Es kann dann manuell entschieden werden, ob es dort sinnvoll ist, entfernt werden oder an eine andere Position in der Zeile verschoben werden kann. --PerfektesChaos16:45, 27. Jan. 2013 (CET)Beantworten
Ich scheine irgendwie den Eindruck vermittelt zu haben, dich unbedingt von meinem Standpunkt überzeugen zu wollen. He, das war nur ein Vorschlag. Dein Skript, deine Entscheidung. Ich möchte es nur gern verstehen, weil ich deinen Antworten entnehme, dass ich irgend etwas übersehen oder falsch verstanden habe. Leider erkenne ich kaum eine Schnittmenge zwischen deinen Gegenbeispielen und meinen Ideen, deshalb leuchtet mir nicht ein, wie sich daraus ein Widerspruch ergibt. Ich vermute, dass ich auf meine letzte E-Mail aus dem selben Missverständnis heraus keine Antwort mehr erhalten habe. Schade.
„Du unterstellst, dass […] alle Zeichen genau dort stehen, wo man sie erwarten würde.“ Das spielt für die beiden Ideen meiner Ansicht nach keine Rolle. Es geht ja im Gegenteil genau darum, wirkungslose Zeichen dort zu entfernen, wo sie nicht hin gehören.
„Ziffern“. Ziffern haben keine feste Richtung. Das lässt meine Idee unangetastet.
„Komplexe POP-Bidis […] Wörter über Vorlagen zusammengesetzt“. Meinem Verständnis nach spielt nichts davon für meine Idee eine Rolle.
„ZERO-WIDTH-* können in Sprachen wie ml oder fa am Anfang oder Ende von Wörtern […] stehen“. Mit diesem Gegenbeispiel kann ich etwas anfangen, danke. Meine aktuelle Logik entfernt U+200B fälschlicherweise, wenn es am Ende eines solchen Wortes steht. Da war ich mir wie ich oben schrieb ohnehin nicht sicher.
„Ziffern haben keine feste Richtung. Das lässt meine Idee unangetastet.“ Doch. Das Kölnisch Wasser im arabischen Text würde zu 1174, wenn mit den Bidi herumgespielt wird; das Kfz-Kennzeichen oder die Passnummer ginge auch baden. Bei dem Dutzend in Frage kommender Seiten muss man sich einzeln anschauen, was da los ist. Die Zeichen sind nicht zwangsläufig wirkungslos.
Links und rechts von Wörtern können }} und {{ stehen und die Wortbestandteile trennen; es können eckige Klammern der Linksyntax im vereinigten Wort stehen. Das sind ASCII-Zeichen und wären für das Verständnis von ZERO-WIDTH-* diese anscheinend ignorierbar machen; tatsächlich müsste aber die Syntax analysiert und der geparsete Wikitext betrachtet werden. Für ein Dutzend überflüssiger Vorkommen lohnt sich das nicht.
Ich hantiere jetzt seit über zwei Jahren mit den Dingern im Wikitext und werde nach den gemachten Erfahrungen nichts über die mir bekannten Situationen hinaus löschen, sondern lediglich unsichtbare Zeichen als Entity sichtbar machen, wenn sie anscheinend verzichtbar sind. EOD.
Bin ich wirklich so katastrophal unfähig, nachvollziehbare Erklärungen abzuliefern? Was mache ich falsch? Ich will doch gar nicht, dass du WSTM änderst. Ich möchte nur gern verstehen, wo mein Denkfehler ist? Idee 1 lautet, LRMs nur dann zu entfernen, wenn sie direkt neben Zeichen stehen, die selbst LR-Zeichen sind. Äquivalent für RLMs neben RL-Zeichen. Ziffern sind keins von beidem. In keinem der Beispiele würde es entfernt werden. Im Beispiel „<arabischer Text><LRM>ABC123<LRM><arabischer Text>“ würde nur das erste LRM entfernt werden, da das „A“ bereits die Richtung vorgibt und das LRM nichts daran ändert. Idee 2 lautet, das unsichtbare Trennzeichen nur zu entfernen, wenn es direkt neben einem anderen Trennzeichen steht, typischerweise neben dem normalen Leerzeichen. Klammern sind keine Trennzeichen. In den Beispielen würde es nicht entfernt werden. --TMg21:07, 27. Jan. 2013 (CET)Beantworten
Es heißt oben: „ist wirkungslos und kann entfernt werden, wenn es direkt links oder rechts neben einem LR-Zeichen steht. Das wäre mein Erweiterungsvorschlag für dich.“ Diesen Vorschlag habe ich nun mehrfach und immer weniger dankend abgelehnt.
Die Zeichen sind, wenn sie nicht von einem Interwiki-Bot stammten, meist ohne Wissen der Autoren in den Wikitext eingeschleppt worden. Sie kommen aus C&P irgendwelcher Webseiten oder PDF-Dokumente oder sonstwoher; kaum ein Autor kann sie sehen oder weiß auch nur von der Existenz im gerade geschriebenen Wikitext. Ob sie in welchem Zusammenhang gleichwohl sinnvoll wären oder nicht, muss manuell geklärt werden; es kann nicht davon ausgegangen werden, dass sie an den richtigen Stellen stehen, und dass es überhaupt R-T-L-Textsequenzen gäbe – diese gehörten ohnehin immer in eine Vorlage.
Es gibt auch noch U+202A, U+202B, U+202C, U+202D, U+202E, die mit den banalen LRM und RLM zusammenwirken und im Text vorhanden sein können. Was das alles soll und welchen Effekt die Entfernung in der konkreten Situation hätte und wie es eigentlich aussehen soll, muss man sich im konkreten Einzelfall angucken. Menschlich, nicht automatisiert.
„Diesen Vorschlag habe ich […] abgelehnt.“ Ich verstehe wie gesagt nicht, warum du meinst, das immer wieder betonen zu müssen? Das war mit deiner ersten Antwort geklärt und akzeptiert. --TMg21:46, 27. Jan. 2013 (CET)Beantworten
Du bist nun schon zum dritten Mal über ein EOD hinweggegangen.
Du befindest dich auf einer Seite, auf der die korrekte oder nicht korrekte Funktionalität von WSTM thematisiert wird, und sonst nichts.
Du hast jedes Mal darauf bestanden, du könntest aus dem Umstand, dass links oder rechts eines Bidi ein ASCII-Zeichen stünde, aber keine potentielle Wikisyntax-Klammer, jedoch bei einer Ziffer, mit absoluter Sicherheit schließen, dass dieses Bidi gefahrlos entfernt werden könne.
Nein, das ist schlicht falsch. Auch ein lateinisches Schriftzeichen kann in einem R-T-L zitiert sein und würde vom Zitat-Ende zum Zitat-Anfang katapultiert werden; Browser können sich unterschiedlich verhalten und den Bidi-Algorithmus mehr oder weniger schlau umgesetzt haben; maßgeblich ist auch, welche anderen Bidi noch anhängig sind, um welches Schriftsystem es geht (FF ist bei hebräisch tückischer als bei arabisch) und welches Attribut dir="rtl" gilt.
Hinzu kommt, dass mindestens neun von zehn Bidi in den Wikitexten unbeabsichtigt und ohne Wissen der Autoren herumgeistern. Welche notwendig und beabsichtigt sind, ist aber nicht offenkundig.
Wenn automatisch ein unsichtbares Zeichen entfernt wird, haben Normal-Autoren keine Möglichkeit, dies herauszufinden; vorher war es unsichtbar, jetzt ist es weg. Der einzige Unterschied auf der Diffpage wäre, dass ein angenzendes Wort ohne ersichtlichen Grund fett dargestellt wird; vielleicht ist was mit einem Leerzeichen.
Letzter Kommentar: vor 11 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Ich hab hier eine Fehlermeldung Ende des Tag fehlt / '<' <ref name="Kimes (1985) die mir nichts nützt, da Referenzen mit diesem Anfang weit mehr als 100 enthalten sind. Kannst du zum besseren Finden die Zeichenkette verlängern? Gruß --RonMeier (Diskussion) 15:38, 22. Jan. 2013 (CET)Beantworten
p.s. evtl. auch Zeilennummer/Gesamtzeilenzahl angeben?
Die erlaubte Anzahl der Zeichen liegt schon bei 100. Mehr rauszuhauen würde wohl auch nicht helfen; der Schnipsel ist da schlicht zu Ende, mehr gibt es nicht.
Ich nehme an, dir geht es um Liste von Automobilmarken? Dort gibt es zwei gleiche Definitionen (eine also schon mal überflüssig) wie
<ref name="Kimes (1985)<ref name="Kimes (1985)473, 1298">Kimes (1985), S. 473, 1298.</ref>
Letzter Kommentar: vor 11 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo,
ich habe WikEd zwar geladen, aber deaktiviert (oben rechts grau). Nun wollte ich WSTM mal manuell ausführen, doch da ist dann beim editform aktualisieren eine JS-Error geflogen.
Browser: Firefox 18.0.1
aufgerufen Funktion: mw.libs.WikiSyntaxTextMod.api.load(true); auf meiner Benutzerseite (zur Umgehung des Seitenchecks in api.run())
Zustand vor aufgerufener Funktion: wikEd.disabled = true;
Zustand nach aufgerufener Funktion: wikEd.disabled = false;
Es muss also irgendeinen Seiteneffekt (bei mir) geben, der beim Aufruf von .api.load(true); die Variable so verändert, dass deine features()-Funktion (?; per Stacktrace) fälschlicherweise annimmt, dass wohl doch wikEd aktiviert ist, sodass du bei [11] Zeile 385 durchrutscht und dann in Zeile 387 die wikEd-Funktion window.wikEd.UpdateTextarea(null); aufrufst. Kannst du dir darauf ein Reim machen? Liebe Grüße--se4598 / ?20:27, 1. Feb. 2013 (CET)Beantworten
ah, ich könnte mir vorstellen, dass das von Zeile 383: (window.wikEd.disabled=false;) kommt. Wenn ich aber in Firebug ein Breakpoint (Haltepunkt) bei Zeile 589 aktiviere (WSTM.main.full=function(){) und nach Auslösen/Halt weiter fortfahre tritt das Problem nicht auf.--se4598 / ?20:38, 1. Feb. 2013 (CET)Beantworten
Ich schreib mal Brösel dazu:
Grundsätzlich müsste WSTM mit der von dir beschriebenen Situation klarkommen. Du hasr präzise und detailliert geschildert, so dass ich mir darunter etwas vorstellen kann.
WikEd wird öfters umgebaut; im Lauf der vergangenen Woche klimperten mir ein paar Syntax-Fehlermeldungen über die Konsole, und gerade von heute habe ich mir eben einen frischen Quellcode runtergezogen. Ich werde mir am Wochenende mal anschauen, ob sich dort etwas Relevantes geändert hat.
Verkompliziert wird die Geschichte dadurch, dass sich das asynchron und zeitabhängig abspielt. WikEd braucht ein Weilchen, bis er sich seine Objekte aufgebaut hat. Ich versuche die verschiedenen Phasen mitzubekommen und aus dem Vorhandensein der Objekte und Startup-Prozeduren schlau zu werden, und WSTM prüft eigentlich die Existenz der Objekte oder wartet die Startup-Prozedur von WikEd ab und tritt sie notfalls selbst los.
Diese Logik habe ich schon dreimal der Weiterentwicklung von WikEd angepasst, notfalls ist da mal wieder eine Verfeinerung nötig.
Fies ist, dass WSTM versucht, die Aktivierung von WikEd zu verzögern und im automatischen Betrieb die Maschine für sich allein zu haben, bis klar ist, ob jetzt sowieso die Diffpage kommt und WikEd auch nicht mehr nötig ist, oder ob WikEd bereits mit einem minimal von WSTM veränderten Text gestartet werden soll. Die von dir schon gefundene WSTM.main.features() aus en:User:PerfektesChaos/js/WikiSyntaxTextMod/d.js schaltet WikEd beim automatischen Betrieb erstmal ab; in der von dir geschilderten manuell gestarteten Situation sollte man tunlichst nicht durcheinanderkommen.
Gut, dann werde ich wohl einfach vorerst wikEd deaktivieren, da ich es eig. nie brauche. Gewundert hat mich, dass du die wikEd-Variable window.wikEd.disabled änderst (PS: visuell wird das Tool dadurch nicht sichtbar). Wo setzt du den Wert wieder zurück? der wird doch anscheinend in IAEXT.wikEd.disabled zwischengespeichert. Auch das nach dem Sprung zu wikEd kommende window.wikEd.disabled = true; wird ja nicht ausgeführt, da ich ja den if-Zweig ausführe.--se4598 / ?22:37, 1. Feb. 2013 (CET)Beantworten
Letzter Kommentar: vor 11 Jahren5 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo PerfektesChaos, ich bin ein seltener Gast hier geworden, da das Skript mittlerweile sehr zuverlässig läuft. Deshalb freu ich mich fast, dass mal wieder ein Fail passiert und ich hier vorbeischauen kann ;-). In obigem Artikel wird ein Bild samt Bildbeschreibung komplett zermahlen. Steak18:19, 13. Feb. 2013 (CET)Beantworten
Hallo zurück;
Ursache ist das Auftauchen eines Bildparameters hinter einer verlinkten Bildbeschreibung.
Das Skript versucht, die miniatur nach vorn zu sortieren, und verheddert sich.
Eigentlich hatte ich sowas schonmal ausprobiert gehabt; nun habe ich einen Testfall zum Debuggen. Von unverlinkten Bildbeschreibungen weiß ich aber wenigstens, dass es momentan wohl läuft.
Ich habe meine Strategie betreffend nicht-trivialer Texte als Bildbeschreibung grundlegend geändert. Es scheint jetzt in einer neuen Programmierung zu laufen; vermutlich morgen früh oder übermorgen für euch live.
Bei mir auf der Festplatte gefixt. Heute nacht für euch beide und nächste Woche für alle live.
Vor einem Dreivierteljahr war das schon mal erprobt gewesen, aber zwischenzeitliche Zusatzfunktionen hatten diesen Zeigefinger auf den richtigen Anfang untergebutttert.
Letzter Kommentar: vor 11 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
In obigem Artikel erfolgt die Syntaxkorrektur bei der ersten Bearbeitung fast komplett, aber offensichtlich nicht ganz, denn bei der zweiten Bearbeitung direkt danach wird noch ein Dateiname korrigiert. Das könnte doch auch in der ersten Bearbeitung schon erfolgen. Steak16:40, 14. Feb. 2013 (CET)Beantworten
Da hast du völlig recht.
Die in 2010/2011 programmierte schlichte Lösung, die das schon so gemacht hatte, habe ich seit einigen Wochen durch ein komplexeres Modell mit viel mehr Möglichkeiten ersetzt. Dabei schaue ich erstmal noch misstrauisch auf mögliche Fehler; „Architektur in Heilbronn“ von zwei Abschnitte drüber ist einer davon – der erste.
Zurzeit sind noch Notausgänge zur alten Programmierung vorhanden, die ich in diesen Wochen abbaue und die Baustellenumleitungen restlos entferne. Danach werde ich auch die von dir angeregte Verbesserung umsetzen.
Da war ich bei Gustav Theodor Fechner über das Ziel hinausgeschossen. Jetzt bei mir auf der Festplatte feinfühliger die Situation mit den Leerzeichen und Zeilenumbrüchen davor und danach gehandhabt; muss heute Abend und zum Einschlafen noch einmal eine Artikelserie damit herumprobieren. Dann morgen früh für euch live.
Oh, sorry; gestern nacht war ich mit der internen Testserie noch nicht durch und in die Heia und heute morgen vergessen; jetzt nachgeholt und hochgeladen. --PerfektesChaos21:48, 18. Feb. 2013 (CET)Beantworten
Letzter Kommentar: vor 11 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Das <ref> schließe ich ohne Leerzeichen an das Vorhergehende (meist einen Punkt) an. Soweit ist es klar.
Aber nach dem <ref> setze ich gerne ein Leerzeichen, also z.B. so:
... gehen.<ref> Dietrich Bonhoeffer: ...
Weil ich es im Bearbeitungsfenster übersichtlicher finde, wenn der Text einer Fn. etwas abgesetzt ist. So ein Leerzeichen würde doch niemanden stören? Es wird aber dann bald von einem Benutzer oder einem Programm "ausgebessert". –– Franz Graf-Stuhlhofer, 13:13, 26. Feb. 2013 (CET)Beantworten
Es wird durchaus zum Problem für andere Autoren: Nimm das Beispiel unter Hilfe:Einzelnachweise #Formatierung einfacher Einzelnachweise. Wenn jemand die Seitenvorschau sieht und irgendwo mitten in der Seite nach der Zeichenkette >Ma oder im obigen Fall >Di sucht, kann er nach deiner Methode nichts finden. Dass du dort ein Leerzeichen eingebaut hast, kann niemand ahnen.
Ich schon habe viele Tausend Seiten Wikisyntax analysiert, und ich bin mir sehr sicher, dass das außer dir persönlich niemand systematisch so handhabt.
Immer dann, wenn wir auf einfacher Textebene (inline) etwas in Tags einschließen, umgeben wir es nie mit Leerzeichen: durchstreichen hat hinterher auch keine. Das kann doch niemand ahnen.
Wenn überhaupt, dann fügen wir bei block-level Elementen (die auch im Ergebnis an genau dieser Stelle eine neue Zeile im Layout bewirken) einen Zeilenumbruch nach dem Tag ein; oder in anderen Fällen, in denen Zeilenumbrüche zur optischen Gliederung den Autoren helfen. Das ist jedoch mitten im Artikeltext (Fließtext) unerwünscht und stört dort massiv den Versionsvergleich.
Die Wikitexte bieten eine breite Vielfalt an inhaltlichen Möglichkeiten und auch etliche Varianten an Formalitäten. Aber für die anderen Autoren, für Newcomer, für Suchvorgänge, für Skripte, für Bots, für Dump-Analysen ist es nicht wünschenswert, jede erdenkliche private Notation zu verwenden, wenn nur hinterher die Seite irgendwie so dargestellt wird, wie man sich das denkt.
Aber mit der beschriebenen benutzerdefinierten Textersetzung bekomme ich das nicht hin. Weil der Text in Vorlagen enthalten ist und das Skript gar nicht erst anspringt? Oder weil ich zu doof dazu bin? Kann ich so etwas einfach in meine js einbauen? --FA2010 (Diskussion) 13:48, 26. Feb. 2013 (CET)Beantworten
Die gute Nachricht: Du bist nicht doof.
Die Antwort hast du auch bereits herausgefunden: Weil eine Vorlage beteiligt ist, greift die banale Textersetzung nicht. Der Name der Vorlage ist geschützt.
Die im Moment weniger gute Nachricht: Zurzeit geht das nicht.
Es wäre hier die Prolog-Funktionalität, die sich in der Doku auch bereits leise abzeichnet (es wird change.prolog from→to; ggf. mit detect.prolog).
Bei den Links läuft das schon seit über zwei Jahren.
Für die Vorlagen ist das auch vorgesehen; intern wird es bereits praktiziert.
Nachdem die Vorlagenparameter von Mitte 2012 inzwischen robust funktionieren, und die Jonglage mit Bildparametern hinter Links im Legendentitel offenbar auch in den nächsten Tagen vom Stapel laufen kann, sollte ich die Prolog/Epilog-Aktion mal langsam angehen.
Weil du grad auftauchst: Ich prüfe seit einiger Zeit weltweite Identifizierer. Das kann ganz banal sein, etwa ob eine PMID tatsächlich nur aus Ziffern besteht und sich nicht irrtümlich Text eingeschmuggelt hat; so auch schon ISSN und DOI und DNB.
Nun die Frage: Welche Anforderungen könnte man an LCCN und VIAF stellen?
Danke für die Erläuterung. Zu LCCN: das weiß Benutzer:APPER sicher am besten. Ist eigentlich aber nicht unbedingt nötig, da er täglich Listen erstellt, die auch von Normdaten-Kennern abgearbeitet werden, siehe Kategorie:Wikipedia:Normdaten-Wartung. VIAF sind m. W. einfach Zahlen unbestimmter Länge, alles andere darin wäre falsch. Wenn ein Bindestrich oder ein X auftaucht, wäre ein VIAF-Identifier wohl mit einer GND verwechselt worden, wenn n auftaucht, wohl mit einer LCCN. --88.130.207.13407:20, 27. Feb. 2013 (CET)Beantworten
@LCCN/VIAF:
Naja, Normdaten-Vorlage ist gut und schön; aber WSTM checkt die Parameterwerte bei weltweit jeder Vorlage, die einen Parameter mit Namen LCCN/lccn hätte (sofern man nicht projektspezifisch bestimmte Vorlagen-Namen auf eine Ausnahmeliste setzt) und desgleichen auch alle PMID=, pmid=, DOI= usw. usw. Und das betrifft beispielsweise auch Vorlage:Literatur und Vorlage:cite book – ohne sie ausdrücklich kennen zu müssen.
VIAF habe ich schon mal als Nur-Ziffern-Anforderung eingebaut; wird irgendwann mal live.
Alle diese Identifizierer und Schlüsselnummern zur Verbindung mit anderen Datenbanken sollten wie Wikilinks und URL möglichst fehlerfrei funktionieren und nicht darunter leiden, dass irgendwem ein Pipe-Smbol abhandenkam.
Die LCCN hat keine feste Form, sondern hat drei unabhängige Bestandteile, die sogar die LoC selbst für Links etc. zusammensetzt, wie es ihr gerade beliebt. Wir (und en.wikipeda in der Vorlage Authority files und die Commons) trennen diese drei Teile durch Slashes, anderswo mag eine bestimmte Repräsentation direkt in einer Vorlage oder in Links verwendet werden. Da kann man global eigentlich nichts dazu sagen. --FA2010 (Diskussion) 12:44, 2. Mär. 2013 (CET)Beantworten
Oho; ich kann nur völlige Irrläufer detektieren. Auf solche sollte allerdings gleich beim Editieren aufmerksam gemacht werden.
Mal sehen. Vielleicht lässt sich auf eine Mindest- und Maximallänge kommen, wenn nicht völlig leer; und Beschränkung auf ASCII und sogar eine Teilmenge davon. Ein oder drei durch Leerzeichen getrennte Blöcke bestimmter Längenbereiche filtern schon mal die gröbsten Syntaxfehler heraus, und nur um diese kann es gehen.
Oh, das ist ein falscher Fehler; da muss ich nochmal ins Detail gucken.
Wikisyntax (und damit WSTM) unterscheiden zwei Typen von DOI:
DOI, die Sonderzeichen enthält wie: < > [ ]
Diese sind in Vorlage:DOI möglich; auch bei allen anderen Vorlagenparametern DOI=, bei denen unterstellt wird, dass eine Vorlage:DOI intern aufgerufen wird.
DOI, die kein solches Zeichen enthält.
Dann ist auch das „Pseudo-Interwiki“ [[doi:10.1126/science.286.5439.509]] möglich.
WSTM kennt beide Anforderungen und ging mit Heiko offensichtlich zu hart ins Gericht. Da muss ich nur den richtigen Level fordern.
Lösung voraussichtlich im Lauf des Vormittags; Danke für den Hinweis.
Ja, das zweifache border = 1 border="1" hat ihn irgendwie aus der Bahn geworfen, und WSTM hat alles vergessen. Kleine Gehirnerschütterung. Tut WSTM und mir leid.
Schön dass grad Wochenende ist; wird sich kurzfristig beheben lassen. Bin grad vom Sonnenbaden zurückgekommen und bester Laune. Nach Kaffeetrinken werde ich mal gucken. --PerfektesChaos16:27, 3. Mär. 2013 (CET)Beantworten
Gefunden, und vermutlich gefixt.
Die Attribut-Analyse wird eigentlich von den <tags> benutzt.
Hier wird sie ausnahmsweise auch vom Tabellen-Beginn mitbenutzt.
Die <tags> sind langwierig ausgetestet gewesen, und können korrekt mit kaputten Attributen umgehen.
Der Tabellenkopf war wohl weniger intensiv erprobt, und setzte sich im Fehlerfall auf NixMehr, statt den vorgefundenen Wikitext nach der Fehlermeldung einfach zu ignorieren.
Bis circa morgen früh interne Test- und Bedenkzeit; danach für euch live.
Erste Wahrnehmung seit der Programmierung am 22. August 2012.
Was dann verbleibt, ist die Sortierung nach Familiennamen oder wenn das Lemma mit einem Artikel (hier: „Der“, „Ein“, „The“) beginnt.
WSTM bewegt sich im Hintergrund bereits in die Richtung, eine Person zu erkennen sowie Zugehörigkeit zu isländischen oder asiatischen Namen. Wenn letzteres nicht der Fall ist, würde ein fehlender Sortierschlüssel angemeckert werden; jedoch nur, wenn die Person anhand des Lemmas vermutlich einen Familiennamen hat. Loriot nicht und Pontius Pilatus #Name auch nicht; auch wenn letzterer eigentlich im Moment den falschen Schlüssel hat. Vielleicht mache ich erst bei Geburtsdatum nach 1600 was.
Letzter Kommentar: vor 11 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo,
aus:
Leichtigkeit [[Sebastián de Yradier|Sebastian Yradier]]s bis zur schmerzvoll philosophischen Tiefe eines [[Astor Piazolla]]"'' schreibt Dmitri Dragilev 1998 [http://dragilew.webs.com/oskarstrock.htm]</ref>.
wird:
Leichtigkeit [[Sebastián de Yradier|Sebastian Yradiers]] Gruß --RonMeier (Diskussion) 09:22, 6. Mär. 2013 (CET)Beantworten
Das hängt mit einer benutzerdefinierten Ersetzung zusammen.
Da du diese vermutlich von mir abgeschrieben hast, ich die zumindest auch habe, darfst du dich als unschuldig betrachten.
Mein montanes Problem: Ich weiß im Moment noch nicht, welche und warum. Du kannst ja auch mal schauen, was da in Frage kommt. Es steht auch ein Leerzeichen nach dem <ref>, was aber wohl nichts zu bedeuten hat.
es scheint das Verschieben des Punktes nach </ref> vor die Referenz zu sein.
Das stimmt.
Es ist die Regel mit mw.libs.WikiSyntaxTextMod.config.mod.wikilink.concat(refSatzzeichen);
Die ist in Ordnung; da war ein Wikilink und eine URL, die hätten geschützt sein müssen und nicht verloren gehen können.
Auslöser ist zwar der Punkt nach </ref>, aber die Ursache ist ein Skriptfehler.
Die Datenstruktur ist in diesem Quelltext ziemlich verzwickt; es gibt das Leerzeichen nach <ref> und den Punkt nach </ref> und Wikilink und URL. Erstaunlich ist, dass die Regel anschlägt. Der Fehler besteht schon seit mindestens Dezember 2012; da weiß ich spontan nichts, was durch irgendeine Programmiererei der letzten Wochen beschädigt sein könnte. Vor morgen früh ist mit keiner Intensiv-Diagnostik zu rechnen.
Den Bug gab es seit mindestens Mitte November 2012, wahrscheinlich Mitte 2012.
Ein Größer-Zeichen stand an einer Stelle, wo die Konsequenz unmöglich wurde; ich habe jetzt erstmal ein Kleiner-Zeichen draus gemacht und muss noch erproben.
Schön, dass die Normalos davon nichts mitbekommen haben.
Doppelte Pipe in Verbindung mit einer Bildlegende, die mit Wikilink anfing, war für die neue Technik zuviel gewesen.
Jetzt für euch beide live.
Wenn ihr zwei grad dabei seid und mitlest: Bitte ausnahmsweise einmal Cache massiv löschen; das Kopfmodul wurde bei der Gelegenheit verfeinert und soll demnächst ausgeliefert werden.
Ist wohl noch nicht ganz erledigt: In Augustus wird aus "upright=1.2|" "hochkant=1.2||". Cache hab ich schon mehrmals geleert, daran kanns also eher nicht liegen. Steak21:51, 8. Mär. 2013 (CET)Beantworten
Wenigstens hatte das zusätzliche | die Darstellung nicht zerschossen.
Da war noch eine übervorsichtige Baustellenumleitung aktiv gewesen, mein Fix bei Berlin mit zusätzlicher | in manchen Situationen war sinnlos und ist wieder entfernt; Baustellenabsperrungen sind jetzt hoffentlich alle abgebaut.
Cache-Leerung sollte nicht mehr nötig sein; der Netzwerk-Schluckauf hat sich wohl erledigt.
Nix ernstes, da hat nur wer vorübergehend Schnupfen. Die enWP; oder uns hat gerade jemand ein wundersames Stückchen Software eingefädelt (auf der Beo steht plötzlich „Wikidata ausblenden“, und ich sehe nicht, wo das nun wieder herkommt, MediaWiki:Common.js/watchlist.js ist unverändert); oder bei deinem FF-upgrade ist was durcheinandergekommen. Mal maximale Cache-Bereinigung versucht?
Letzter Kommentar: vor 11 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Ausschnitt aus der roten Box:
Satzzeichen am URL-Ende verdächtig
http://www.spiegel.de/panorama/justiz/0,1518,675823,00.html|
Satzzeichen am URL-Ende verdächtig
http://www.badboyuli.de/4.html|
Satzzeichen am URL-Ende verdächtig
http://www.stuttgarter-nachrichten.de/inhalt.mord-im-rockermillieu-hells-angels-hinter-gittern.86bca977-3510-4411-8e45-8b6f5f638c3a.html| das sind alles url in Vorlagen, also nichts falsches. Kollateralschaden? Gruß --RonMeier (Diskussion) 11:24, 9. Mär. 2013 (CET)Beantworten
Ja, scheint eine Nebenwirkung einer Zuordnung der geschützten Blöcke zu sein.
Mir war in diesem Zusammenhang auch schon eine andere Seltsamkeit aufgefallen, bei der ebenfalls der geschützte Bereich nicht die richtige Ausdehnung hatte.
Ich hatte mir für dieses Wochenende bereits eine Detektivarbeit vorgenommen, aber bislang noch keinen rechten Ansatzpunkt gehabt. Jetzt sind die Hells Angels auch mal zu was gut.
Im normalen Seiten-Bereich werden zuerst die Vorlagen analysiert; innerhalb jeder einzelnen Vorlage die darin vorkommenden Links, danach Links außerhalb von Vorlagen.
Hier gab es im references-Block noch seit etlichen Monaten ein Überbleibsel, von dem es mich wundert, dass es erst jetzt auffiel: Es wurden erst alle Links analysiert und danach alle Vorlagen. Damit war beim Lesen der URL noch nicht bekannt, dass diese Pipe zu einer Vorlage gehört, und löste die Warnmeldung aus.
Ich möchte dies am Wochenende gern selbst erproben und plane die Freischaltung für Montag abend.
Der Rest der Welt hat mutmaßlich dieses Problem noch nicht gesehen; davon wird abhängen, wie schnell ich das nach draußen bringe.
Eine mir erstmal völlig unbegreifliche Nebenwirkung irgendeines Fixes; und ich durchschaue noch nicht einmal welches. Ich habe nach und nach alle Neuerungen der letzten Wochen zurückgesetzt und der Murks ist immer noch; bin schon in 2012. Schlimmer noch: Er passiert mit der Version für alle.
Den Bug gibt es seit mindestens Anfang November 2012, wahrscheinlich schon seit deutlich mehr als einem halben Jahr wirksam.
Auslöser ist das Zusammentreffen von:
Nur domain, ohne Ressourcen-Schrägstrich dahinter
Kommentar im Titel; hier „Automatisch generierter titel“.
Bei mir gefixt; muss ich aber erstmal drüber schlafen. Wenn das nach einem halben Jahr das erste Auftreten ist, scheint es nicht so häufig zu sein, und ich möchte den Rest der Woche selbst erproben.
Vor der Menge an Konstellationen und Kombinationen streikt mein Sammelsurium an kleinen Testfällen.
Ich habe zurückgesetzt auf die Version, in der dieser Fehler hier bereits seit einem halben Jahr enthalten ist.
Grund: Die Beseitigungsversuche hatten deutliche Nebenwirkungen; siehe folgende Abschnitte.
Das fragliche Unterprogramm ist vielfach erweitert worden und umfasst mittlerweile um 500 Zeilen. Damit ist es viel zu komplex und unübersichtlich geworden für die vielen Konstellationen. Es stammt noch aus der Periode vor WSTM.5 mit einfacher Zeichenkette. Das gehört zu den Angelegenheiten, die mir schon seit einer Weile ein Dorn im Auge sind.
Ich werde im Lauf der kommenden Woche dieses Unterprogramm durch ein komplett neues Objekt ersetzen, das intern untergliedert ist und sehr viel sicherer die verschiedenen Aufgaben lösen kann.
Scheint mit ein Nebeneffekt des Fixes zu WinsenLuhe (eins drüber) zu sein; der steht seit kurzer Zeit auf der Spielwiese. Hier gibt es ein doppeltes Leerzeichen zwischen URL und Title, und das könnte in der geänderten Berechnung untergegangen sein.
Es ist definitiv die gestern wegen Analyse der kommentierten Weblinks in Winsen/Luhe geänderte Berechnung. Es wird jetzt um die Länge des Linktitels zu weit nach hinten verschoben.
Eine differenziertere Berechnung in allen Konstellationen bräuchte bis heute Abend einige ruhige Stunden; im Moment ist mir alles zu hektisch.
Bei mir nicht, aber vielleicht hat sich schon wieder die Version geändert. Welche Uhrzeit genau warst du dran, welche URL in etwa? Da wird ja im Minutentakt dran gebaut.
An den Weblinks bin ich dieser Tage sowieso dran, siehe eins und zwei drüber.
Z. B. in der von 00.00 Uhr, aber auch schon in der von 23:29 Uhr. Bei mir wird "{{Internetquelle | url=http://de.radiovaticana.va/news/2013/03/11/letzte_generakongregation:_bertone_berichtet_%C3%BCber_vatikanbank/ted-672177 | titel" zu "{{Internetquelle| titel". Steak00:02, 14. Mär. 2013 (CET)Beantworten
Danke; bei mir immer noch nicht.
Damit liegt eine Wechselwirkung mit deinen benutzerdefinierten nahe; muss ich mir heute Abend mal näher ansehen.
Im Moment werde ich nichts dran machen; aber wenn das ganze Wikidata-Theata vorbei ist, will ich alle Interlanguages suchen, die vermutlich im Text ohne Doppelpunkt rumgeistern, und mir was überlegen, was ich mit noch nicht auf Wikidata übertragenen Interlanguages fehlermeldungsmäßig oder optional machen werde. In dem Zusammenhang kann ich mir was ausdenken, dass nd ein korrekter Sprachcode ist, aber nd:WP zurzeit nicht existiert.
Skript/Firefox hängt beim Bearbeiten des Abschnitts "Partner", nicht jedoch beim Bearbeiten des ganzen Artikels. Zeilennummer der FF-Meldung des hängenden Skriptes wechselt, z.B.:
rH.js&530440912*:1235
rH.js&530440912*:905
rO.js&533820004*:1370
Edith: Beim Editieren der ganzen Seite wird bei den Partnern z.B. nur bei Microsoft (1. Link) der abschließende Slash angehängt, nicht aber bei den anderen URIs
--se4598 / ?18:54, 25. Feb. 2013 (CET)Beantworten
Danke für den präzisen Fehlerbericht, vor allem für die Zeilennummern.
Ich habe eine konkrete Vorstellung davon, woran das liegt und was ich tun muss.
Es passiert auch nie, wenn der Textbereich nicht so kurz ist wie hier der einzelne Abschnitt, wo dann die URL ungeklammert sehr zu Beginn vor anderen wichtigen Elementen stehen.
Außerdem passiert es nicht, wenn benutzerdefinierte Ersetzungen aktiv sind, weil dann jede gefundene URL in einem Textschnipsel separiert wird.
Ursächlich ist, dass die URL nur zwei Zeichen voneinander entfernt im Text stehen, und der Weitersuch-Mechanismus dann die erste URL erneut findet.
Hier muss an geeigneter Stelle ein +1 eingetütet werden, aber ich müsste mir heute noch tiefere Gedanken machen, unter welchen Bedingungen das angemessen ist, ohne Kollateralschäden anzurichten; also dass andere URL künftig nicht mehr gefunden würden.
Allerdings brauche ich intensives Testen, das ich wohl erst Richtung Wochenende hinbekomme.
Tückisch ist, dass das normale Beta-Test-Verfahren nicht greift: Sowohl ich wie meine beiden Versuchskaninchen arbeiten mit benutzerdefinierten Ersetzungen. Dabei passiert aber nichts.
Nebenbei habe ich auch das WikEd-Problem von ein paar drüber identifiziert.
WikEd verwendet inzwischen drei Schalter, um die Aktivität oder Inaktivität anzuzeigen:
wikEd.disabled
wikEd.turnedOn
wikEd.useWikEd
Die hatte ich letztes Jahr nur teilweise ausgewertet; inzwischen nimmt der Bursche wohl eine andere Abfrage. Ich hoffer, Cacycle blickt da selbst noch durch.
Letzter Kommentar: vor 11 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt
friert beim Öffnen des Edit-Fensters meinen ganzen Firefox ein. (Scheint am WIkiSyntaxTextMod zu liegen, ich bin aber natürlich nicht sicher; ausgeloggt geht es jedenfalls). --FA2010 (Diskussion) 18:54, 29. Mär. 2013 (CET)Beantworten
Meine Analyse dazu:
aktuelle Version (oldid=116151579) läuft und lädt diff
@se4598: Danke fürs Debuggen und auch die präzisen Angaben; du hast es genau erfasst.
Wie bei einer Vinyl-Platte mit Kratzer sprang WSTM in dieser Situation irrtümlich wieder auf die alte Stelle zurück, von der aus die gleiche „URL“ erneut gefunden wurde.
Ansonsten wäre „http://“ innerhalb des URL-Pfades nicht das Problem; Archivlinks enthalten das regelmäßig in der URL. Bloß ein paar Zeichen für die Domain wären nicht schlecht gewesen, damit dieser Suchausdruck sich nicht mehr selbst findet.
Ich habe erstmal einen mutmaßlich wirksamen Fix eingebaut, der im Lauf der kommenden Woche eingespeist wird.
Zufällig arbeite ich seit einiger Zeit am vollständigen Ersatz der noch aus 2010/2011 stammenden Programmeinheit für Weblinks. Sie wird im Endstadium deutlich robuster sein und auch mehr verdächtige URL finden und melden und ein zusätzliches Feature bieten. Erst nach rund 6–8 Wochen Erprobungszeit wird das neu geschriebene Programmstück an alle Anwender gegeben.
Bislang war die Situation mindestens im letzten halben oder Dreivierteljahr nie aufgetreten (ich hatte das auch nicht in meiner Sammlung von Testfällen). Da sich sogar ein Bot darum kümmert, wird sich das jetzt hoffentlich nicht wiederholen.
ähnliche oder gleiche Version, kann ich nicht genau sagen
rE.js&543882921*:169
rM.js&527902771*:260
sind wohl mal wieder so Spezialfälle, wo man falsche Formatierungen aber auf den Blick erkennen kann. Lass dir Zeit :) Viele Grüße--se4598 / ?13:45, 11. Apr. 2013 (CEST)Beantworten
Wenn du mit „Abschnittsdeklaration zu Beginn“ den Umstand meinst, dass der Artikel mit einer Überschrift beginnt, die noch nicht einmal korrekt in der Zeile beendet wird, dann hast du das Problem genau erkannt: Genau wegen dieses Zusammentreffens kreist in rE.js zwischen Zeile 160 und 199 der Sinnsucher.
Wenigstens ist das völlig unabhängig von meinem momentanen Sorgenkind; dem Nachfolger der URL-Analyse von 2010/2011.
Dementsprechend kommt ein geeigneter Fix unauffällig in den nächsten Tagen in die Erprobung und wohl im Lauf der kommenden Woche in die Produktiv-Version. Einen ersten Flicken habe ich auf der Festplatte gesetzt; ob der Stubser gegen die Nadel in allen Situationen ausreicht oder sonst Nebenwirkungen hätte, muss ich erst noch durchspielen. Ganz am Anfang geht es jedenfalls zwangsweise drei Byte vorwärts; wenn er erstmal über die erste Zeile hinweg gekommen ist, sollte es laufen.
Letzter Kommentar: vor 11 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Ich beabsichtige, heute Abend die neue Programmeinheit für Weblinks zur Erprobung durch euch zu aktivieren.
Ich hatte in den letzten Wochen keine Fehlfunktionen mehr gefunden. Die Analyse betrifft URL mit und ohne Klammern; auch benutzerdefinierte Ersetzungen im Zusammenhang mit URL können noch Überraschungen bieten.
Die alte Programmierung stammt aus 2010/2011 und ist mittlerweile völlig überfrachtet durch zahlreiche Anbauten und Sonderfälle. Die Neuentwicklung soll robuster und stabiler auch zukünftige Weiterentwicklungen ermöglichen.
Ja, äh, mit einer Länge von 277 Zeichen wurde das momentane Warn-Limit von 255 gesprengt. Ich habe es gerade bei mir auf 384 erhöht. Mal sehen, wer das als nächstes knackt.
Für WSTM sieht das Zeugs wie ein Syntaxfehler aus; wie ein konfuses Wikilink mit Pipe und falschen oder vergessenen Klammern.
Das ist eine ziemlich krude Mischung aus Block-syntaxhighlight und Wikisyntax-Nummerierung.
Funktionieren wird folgende Struktur:
# Erster nummerierter Punkt
#: <syntaxhighlight enclose="none" ......... </syntaxhighlight
# Zweiter nummerierter Punkt
#: <syntaxhighlight enclose="none" .........
Auf der einen Seite soll syntaxhighlight ohne enclose einen eigenen Block darstellen und ist so für mehrere Zeilen gedacht; auf der anderen Seite darf die Wikisyntax-Nummerierung nicht durch eine Zeile ohne # unterbrochen werden. Das beißt sich hier. WSTM hatte Zeilenumbrüche eingefügt, weil Blöcke ohne enclose abgesetzt erwartet werden.
Dazu wäre dann noch etwas style ratsam, damit die Rahmen um die eine Zeile nicht so knallen; etwa so:
Gut aufgepasst; die fragliche Situation war in den letzten Jahren noch nie jemand aufgefallen.
Natürlich soll die optische Darstellung nicht verändert werden.
Die zusätzliche Bedingung habe ich bereits in den Quellcode eingefügt. Weil im selben Modul aber gleichzeitig eine Neuentwicklung zum Thema Weblinks abläuft, kann es noch bis nach dem letzten Frost dauern, bis das bei allen wirksam wird. Allzu häufig scheint das nicht vorzukommen.
Hilfe:Links #Wikilink ist da auch noch sehr unpräzise; ich werde ihm gelegentlich einen zusätzlichen Abschnitt verpassen. Auch die Geschichte mit dem [[Mond]]<nowiki />kalb gehört hier sauberer dargestellt.
Anmerkung: Mir war das natürlich durchaus aufgefallen. Da gemäß Hilfe:Links #Wikilink solche Links verkürzt werden sollen (d. h. [[Mond]]kalb statt [[Mond|Mondkalb]]) hab ich darin keinen Fehler gesehen und die Änderung des Skriptes belassen. Wenn ich jetzt noch wüsste, wo das aufgetreten ist.... Steak19:49, 9. Mai 2013 (CEST)Beantworten
Letzter Kommentar: vor 11 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Das Skript meldet Wikilink-'[[' seltsam [Borrazópolis]] um. Am 21. April 1958 wurde Braz d – und das sieben Mal (und 9 weitere Fehler festgestellt. Ich kann an dem Wikilink nichts seltsames finden, und schon gar nicht 16 mal... ;-) --AndreasPraefcke (Diskussion) 19:01, 2. Mai 2013 (CEST)Beantworten
Ich kann bestätigen, dass unter bestimmten Umständen der von dir beschriebene Fehler genau so gemeldet wird.
Der Fehler ist ein falscher Fehler, ein Phantom.
In der näheren Umgebung stehen zurzeit Baustellenabsperrungen und Umleitungen. Ich hatte den April über ein komplett neu geschriebenes Verfahren zur Analyse von Weblinks erproben lassen und seit 1. Mai live geschaltet, da es keine Beschwerden gab.
Aus den Schwierigkeiten, die ich bei der Reproduktion hatte, schließe ich auf eine Inkompatibilität bei den freigeschalteten Einzelteilen; in meiner Entwicklungsumgebung bekomme ich den Fehler überhaupt nicht ausgelöst.
Zurzeit lanciere ich einmal am Tag ein aktualisiertes Einzelteil. Was hier die Ursache ist, würde mich interessieren; und warum ausgerechnet dieser Wikitext in der Lage ist, das Problem zu verursachen.
Ich vermute, dass sich das im Lauf der nächsten Tage vielleicht unerklärlich von selbst lösen wird.
Gibt es mindestens seit November 2012, mutmaßlich seit bald einem Jahr.
Ursächlich war {{"|Fetzen Papier}}<ref und der Versuch, das Komma von hinten zwischen die Vorlagenklammern und das <ref zu schieben. Hier war aus einem Größer-Zeichen ein Größer-gleich-Zeichen zu machen. Im letzten Jahr ist diese Situation offenbar nicht aufgetreten, oder zumindest nie bemerkt worden. Normal-Anwender ersetzen nichts, und waren nicht betroffen.
Fix ist für Erprober live.
Die 15 Fehlermeldungen ließen mich zunächst nach einem weiteren Fehler suchen, bis ich dahinterkam, dass das auch 15 Ursachen hatte. Es bringt mich auf die Idee, wiederholte gleiche Fehlermeldungen zu filtern; aber als Korrigierer muss ich auch wissen, dass das mehrmals vorkommt und wie oft. Sonst fixe ich das einmal und der Bock ist beim nächsten Bearbeiten immer noch da.
Ja, ist mir schon öfter passiert, als ich noch kein WSTM hatte (fehlerhafte ISBN sowohl im Abschnitt Literatur als auch in den Referenzen). Ich hab ja die Anzahl der anzeigbaren Fehler erhöht, so dass ich meist keine Probleme damit habe.
Letzter Kommentar: vor 11 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
"* ''[[Shrine Auditorium| The Shrine Civic Auditorium]]'' " wird zu "* '' [[Shrine Auditorium|The Shrine Civic Auditorium]]'' " (das Leerzeichen wird also aus dem Link gezogen und zwischen Link und Kursivzeichen gesetzt). Kommt mir spanisch vor. Steak19:19, 9. Mai 2013 (CEST)Beantworten
Ich muss das Leerzeichen nach vorne schieben, damit die Lücke nach dem aaaa erhalten bleibt.
Dass das in dem Fall doof aussieht, weil vor den Kursiv-Apostroph noch mal Leerzeichen steht und es eigentlich da am Aufzählungszeichen überhaupt keine braucht, kann ich auch nicht ändern.
Du könntest es doch einstellen, dass das Leerzeichen standardmäßig noch an der Kursiv- bzw. Fettformatierung vorbeigezogen wird? Steak21:52, 9. Mai 2013 (CEST)Beantworten
Letzter Kommentar: vor 11 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Ich hatte schonmal gefragt, damals hast du mit "fehlender Konsens" eine generelle Implementierung abgelehnt. Den brauche ich auch nicht, um Kategorien am Artikelende in eine bessere Reihenfolge zu bringen. Krieg ich das irgendwie mit deinem Tool hin? Steak19:20, 9. Mai 2013 (CEST)Beantworten
Allgemein kannst du nix machen.
Ich habe auf meinem Wunschzettel zu stehen, bei dewiki-Personen zu sortieren: Geboren, Gestorben, Frau/Mann/Weißnicht ganz zum Schluss. Das dann für alle.
Das gesamte Thema am Schluss der Artikel habe ich auf Eis gelegt, bis das Wikidata-Theata vorbei ist.
Danach soll gemeckert werden, wenn doch noch ein Interlanguage gefunden wird, womöglich mitten im Text (vergessener Doppelpunkt); Sortierung von SORTIERUNG und Kat und Normdaten und Personendaten und die Link-Vorlagen.
Ich wüsste aber kein Schema, wie benutzerdefiniert eine Kat-Sortierung sicher laufen soll.
Letzter Kommentar: vor 11 Jahren5 Kommentare2 Personen sind an der Diskussion beteiligt
Die Bildeinbindung "Alexander der Nederlanden 1851 - 1884.jpg" wird verfälscht (Bindestrich nach Bisstrich), obwohl doch eigentlich Dateieinbindungen geschützt sind?! Steak19:34, 9. Mai 2013 (CEST)Beantworten
Schön, dass du wieder live bist.
Ich kann es leider reproduzieren.
Kurios. Hier ist es eine gallery, und innerhalb deren Bereich wäre immer alles in einer Zeile bis zur Pipe oder sonst Zeilenende ein Dateiname und geschützt. Muss ich mich in Ruhe durchgraben.
Ich habe die Ursache inzwischen identifiziert und bei mir auf der Festplatte geändert:
Die Behandlung der Tags gallery, imagemap und references stand hinter der benutzerdefinierten Text-Ersetzung.
Der Zeilenanfang der gallery-Zeilen bis zur Pipe war damit brav geschützt worden – allerdings erst, nachdem das passiert war, wovor geschützt werden sollte. Genauso mit imagemap.
Das ist natürlich Quark. Ich muss mich aber noch durch meine Geschichte wühlen, ob das irgendwelche Nebenwirkungen hat. Bei den references war es irgendwie wichtig, in welchem Moment sie behandelt wurden; das habe ich aber schon wieder vergessen. Die Reihenfolge dieser Groß-Operationen in der zentralen Steuerung hatte ich schon ein paar Mal geändert, und dann ging oft etwas schief.
Arrgh, recht verzwickt. Da beißt der Hund in die Katze vom Schwanz. Ich habe es jetzt so umgeschrieben, dass in der gallery jede Bildunterschrift einzeln die benutzerdefinierte plain-Ersetzung bekommt.
Das wird aber noch ein paar Tage dauern, bis ich es auch getestet habe und für euch bereitstellen kann. Etwas Geduld und Adleraugen braucht es also noch.
Letzter Kommentar: vor 11 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
"[http://www.chronik-der-mauer.de/index.php/de/Media/VideoPopup/day/9/field/audio_video/id/19225/month/November/oldAction/Detail/oldModule/Chronical/year/1989 Bundeszentrale für politische Bildung: Video mit dem ARD-[[Tagesschau (ARD)|Tagesschau]]-Bericht vom 9. November 1989] – "
wird zu
"[http://www.chronik-der-mauer.de/index.php/de/Media/VideoPopup/day/9/field/audio_video/id/19225/month/November/oldAction/Detail/oldModule/Chronical/year/1989 Bundeszentrale für politische Bildung: Video mit dem ARD-][[Tagesschau (ARD)|Tagesschau]]-Bericht vom 9. November 1989 – "
Wenn innerhalb des Weblink-Bereiches ein inneres Wikilink steht, könnte man dieses nicht anklicken. Deshalb splittet die MW-Software die Linktitel und schafft zwei unabhängige Links. WSTM macht das exakt genauso; durch das Verschieben der Klammer taucht es auf der Diffpage auf.
Bei mir auf der Festplatte gefixt, im Lauf des Wochenendes für euch.
Bei normalen Wikilinks hat eine Leerzeile zur Folge, dass das Link kaputt geht. Bei Dateieinbindungen ist das offenbar nicht so. Dies wusste ich auch noch nicht. Dementsprechend habe ich auch keinen Testfall dazu gehabt. Es war nun als scheinbarer Kommentar oder Vorlage aufgefasst worden, und dann war dahinter aber gar keiner.
Ich muss mir noch ausdenken, wie ich die Leerzeile aus der Legende herauslösche. Die hat da nix am Suchen.
Letzter Kommentar: vor 11 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
<ref>[http://www.alt-katholisch.de/meldungen/neuheiten.html?tx_ttnews[tt_news]=624&cHash=588e70a44c87d8024b719c66b2688b40 Mitteilung] auf www.alt-katholisch.de</ref>
wird zu
<ref>[http://www.alt-katholisch.de/meldungen/neuheiten.html?tx_ttnews[tt_news]=624&cHash=588e70a44c87d8024b719c66b2688b40meldungen/neuheiten.html?tx_ttnews[tt_news]=624&cHash=588e70a44c87d8024b719c66b2688b40 Mitteilung] auf www.alt-katholisch.de</ref>
Das ist ein Bug; das zweite Anhängen von =624&cHash= ist ein Irrläufer. Schade, die URL geht kaputt, aber es gibt nur weniger als 100 ohnehin nicht funktionstüchtige Weblinks dieser Art. Du bist ja mal wieder fleißig. --PerfektesChaos13:51, 10. Mai 2013 (CEST)Beantworten
Saudummer C&P-Fehler.
Bei mir auf der Festplatte gefixt, ist aber das identische Modul wie das eins drüber. Kommt deshalb zeitgleich mit.
Letzter Kommentar: vor 11 Jahren5 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo PerfektesChaos,
eine dumme Frage, deren Beantwortung mir aber viel Arbeit erspart: Wie bekomme ich mit Hilfe dieser Skripte aus einem Stück Text (String, raw Wiki markup) einen Baum aus WikiTom-Objekten? Welche Methode und welche Unterskripte werden dafür benötigt? Wie kann ich diesen Baum manipulieren? Es geht mir nun nicht mehr nur um Vorlagen, sondern um einen kompletten Baum, wie ich ihn erhalte, wenn ich in de:Benutzer:P.Copp/scripts/preprocessor.jsvar o = Wiki.preprocessToObject( wikitext ); ausführe und wie ich ihn zurückverwandele (analog var wikitextNew = Wiki.ppFrame.expand(o);). Es geht hier auch nicht ausschließlich um Ersetzungen; manchmal muss ich auch wissen, ob es eine entsprechende Vorlage oder Kategorie gibt etc. Ist Dein Debug-System irgendwo erklärt?
Verwenden möchte ich es u.a. zum Ersetzen, Hinzufügen oder Entfernen von Kategorien in Cat-A-Lot, Ändern von Vorlagenparametern oder deren Werte im RotateLink, Einlesen der Liste der zu ersetzenden Dateien auf commons:User:CommonsDelinker/commands/filemovers, …
WikiSyntaxTextMod soll selbstständig keine Änderungen durchführen.
Deinen raw string kannst du hier reinschmeißen. #Stapelverarbeitung steht eins drunter.
Du kannst grundsätzlich nicht verhindern, dass der Text standardisiert wird, aber du müsstest ihn ja nicht abspeichern. Die Standardisierung ist aber harmlos und fällt unter die berühmten „kosmetischen Änderungen“. Verhindern lässt sie sich nicht, weil jedes eingelesene Element sofort in seine Normalform gemäß seinem Nutzinhalt überführt wird und dieser Inhalt die Eigenschaften der jeweiligen WikiTom bildet. Heraus bekommt man dann nur noch die Standardform dieser Eigenschaften.
Die Standardisierung bewirkt, dass Category:X und kategorie:X und Kategorie: X gleich behandelt werden.
Der Syntaxbaum steht anschließend unter mw.libs.WikiSyntaxTextMod.text.
Debugger nehmen und durchbrowsen.
Die Segmentierung hängt von den äußeren Umständen ab und von einiger innerer Struktur der Seite. Benutzerdefinierte Änderungswünsche (auch ein Null-Wunsch) bedürfen einer feinen Granulierung; ansonsten wird dieser Aufwand gespart und es bleiben längere Zeichenketten.
Die Kategorien stehen zusätzlich informativ unter mw.libs.WikiSyntaxTextMod.w.encountered.cats[]
Ich lasse alles offen.
Wenn du einfach nur die Kats zu einer Seite wissen möchtest, kannst du auch abfragen (view, nicht edit)
Es gibt noch mehr Funktionen, die bereits seit einem halben Jahr brav funktionieren, zu denen ich bislang noch keine API freigegeben hatte oder die schlichtweg noch nicht dokumentiert sind.
PerfektesChaos, Danke für die ausführliche Beschreibung. Ich konnte die Schritte nachvollziehen, doch es scheint mir, dass die Skript-Suite eher für ein vorgefertigtes "Ersetzungsregelset" geschrieben wurde, als dafür gemacht zu sein, dynamisch zu entscheiden, wo eingefügt, ersetzt oder gelöscht werden soll. Auf Commons gibt es z.B. eine Seite, auf der mehrere gleiche Vorlagen stehen, die sich nur in ihren Parameterwerten unterscheiden (commons:MediaWiki:WatchlistNotice). Wenn ich nun noch eine gleiche Vorlage an einer Stelle, die von einem der Parameterwerte abhängt, auf der Seite einfügen möchte, scheint das mit WikiSyntaxTextMod sehr kompliziert (oder ist es das nicht?) so dass ich denke mit den relevanten Teilen von de:Benutzer:P.Copp/scripts/preprocessor.js in diesem Fall besser beraten zu sein… Außerdem müsste ich, wenn ich es auf Commons allgemein aktivieren würde, dorthin kopieren (am besten als RL-Modul), denn ein Laden aus dem Benutzernamensraum kommt nicht in Frage… -- RE rillkefragen?23:11, 12. Jun. 2013 (CEST)Beantworten
Ich habe ehrlich gesagt die Konstellation noch nicht verstanden, in der dein Problem auftritt.
Wenn du deine Problemkonstellation etwas breiter beschreiben kannst, fällt mir möglicherweise etwas dazu ein. Im Moment fragst du nach detaillierten Einzelkomponenten eines Lösungswegs, der dir vorschwebt; aber ich sehe das Ziel zu diesem Weg nicht.
massenhafte automatische Veränderung mit menschlicher Sichtkontrolle Eben. -- Es sollte möglichst ohne menschliche Sichtkontrolle gehen (und in diesem Fall ist es tatsächlich "nur" eine Einzeländerung). Man hätte hier sicher auch die API nach dem XML-Baum fragen können, wenn ich aber ohnehin schon ein JavaScript auf Commons habe, das einen JS-Objektbaum erstellt, brauche ich die API nicht zu quälen. Parsoid wäre für diese konkrete Anwendung auch noch eine Möglichkeit; diese steht auf Commons aber leider nicht zur Verfügung. Die Personen (Administratoren, Dateiverschieber, …), für die es gedacht ist, haben auf Commons einfach keine Zeit noch eine Vorschau oder eine Diff anzugucken. Das gilt dann ganz besonders, wenn es auch für Kategorieänderungen in Cat-A-Lot genutzt wird. Ich war auf der Suche nach einem Script, das ich universell einsetzen kann und dass mir eine unkomplizierte API zur Verfügung stellt. Das habe ich nun.
Letzter Kommentar: vor 11 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
Guten Abend PerfektesChaos. Schau Dir einmal die Syntaxkorrektur beim ersten Dateinamen aufgrund meiner Änderung an. Bild war natürlich futsch, da der Dateiname verändert wurde?! Ich hoffe, dass Du nicht allzu lange Suchen musst, da dieses merkwürdige Zeichen ziemlich exotisch wirkt :-) Liebe Grüße --Silke (Diskussion) 19:45, 3. Jun. 2013 (CEST)Beantworten
Ui!
Die Ursache war schnell gefunden und beseitigt.
Normalerweise werden bei dir die Linkziele nicht geschützt, um Zeit zu sparen; das geschieht regelmäßig eher bei mir und meinen Vorkostern, die benutzerdefinierte Ersetzungen machen. Ich weiß aber, dass ein solches Zeichen gefunden wurde und muss nur neben ein paar anderen auch in diesem Sonderfall den Schutz der Linkziele (hier: Bildname) auslösen.
So bereits geschehen und auf den Dienstweg gebracht; in ein paar Tagen bei dir wirksam.
Die Geschichte hat leider noch einen inhaltlichen Haken:
Die kleinen Kuller sind das Zeichen für Grad und das Zeichen für den spanischen männlichen Ausdruck Numero drei; also 3rd oder 3eme. Weil die beiden Zeichen öfters verwechselt werden, berichtigt WSTM das. Hier war das Zeichen aber völlig richtig benutzt worden; es kommt mir doch sehr spanisch vor, und es hat keinen Winkel von 3°. Da werde ich diese automatische Korrektur abschalten müssen, oder WSTM muss Spanisch lernen; zweifelsfrei als Grad erkannt werden dann nur noch °C. Da muss ich aber noch denken.
Ich gehe zukünftig so vor, dass ich nur bei Minuszeichen oder Komma/Punkt an der Zahl durch das Gradzeichen ersetze, wenn der spanische Kuller hinter Ziffern steht. LG --PerfektesChaos20:18, 4. Jun. 2013 (CEST)Beantworten
Hallo PerfektesChaos, wieder etwas dazu gelernt. Den spanischen Kuller kannte ich noch nicht, hast Du aber hervorragend erklärt! Ganz lieben Dank für die Korrektur, die dann ja irgendwann auch bei mir wirksam wird. Liebe Grüße --Silke (Diskussion) 20:20, 5. Jun. 2013 (CEST)Beantworten
Das {{{WIDTH|x16}}} muss irgendwie aus den flagicons mitkopiert worden sein. Weil der Vorlagenparameter WIDTH nicht definiert ist, fällt er auf den Wert x16 zurück. Das kann WSTM natürlich nicht auflösen und verbucht das Ganze als eine Vorlageneinbindung im Rahmen der Bildlegende.
Auf Festplatte habe ich seit einem Vierteljahr eine Version, die mit dieser Situation zumindest ohne Absturz umgehen kann. Die lag noch in Erprobung, und ich hatte das kleine Detail längst vergessen und die Weiterentwicklung schlummerte fehlerfrei.
Letzter Kommentar: vor 10 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Bei mehreren Dateien wird per benutzerdefinierter Ersetzung der Bindestrich in einen Bisstrich umgewandelt. Eigentlich sollten doch Dateinamen geschützt sein? Steak16:38, 22. Jun. 2013 (CEST)Beantworten
Nett, dass du wieder live bist.
Grumpfff. Natürlich soll das geschützt werden.
Da war leider eine Debugging-Anweisung scharf geblieben. Sobald mehr als 555 geklammerte Links gefunden wurden, hatte das zur Vermeidung von Endlosschleifen die Analyse und den Schutz der Links abgeregelt und war aus diesem Programmteil ausgestiegen.
Datei:Flag of Romania (1965-1989).svg ist das Link Nr. 848 und Datei:Flag of Georgia (1990-2004).svg hat die Nummer 861.
Die Entwicklung in diesem Bereich ist seit zwei Monaten vorbei. Ich habe vor einigen Minuten begonnen, die Reste der vorherigen Implementierung aus 2010 komplett und geordnet auszubauen.
Sobald die Temperaturen in die Nähe von 20° kommen, werde ich entsprechende Updates hochladen. Müsste morgen irgendwann live sein.
Letzter Kommentar: vor 10 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Elvaube nutzt unsere beiden Skripte, so dass auch deines in Frage kommt, aber ich kann es nicht nachvollziehen. Vielleicht hast du eine Idee? Für mich sieht es wie das Resultat eines Skripts aus, das in Bildeinbindungen alle Whitespaces vor und hinter Pipes entfernt und erst bei } damit aufhört. Nur eine Mutmaßung. --TMg19:40, 4. Jul. 2013 (CEST)Beantworten
Letzter Kommentar: vor 10 Jahren7 Kommentare2 Personen sind an der Diskussion beteiligt
werden noch bemängelt, wenn ein X das letzte Zeichen ist. Beispiel: * Alfred Rosenberg: Gold und Blut. Rede am 28. November 1940 in der französischen Abgeordnetenkammer zu Paris. Franz-Eher-Verlag, München 1941, DNB36218724X. Gruß --RonMeier (Diskussion) 21:38, 18. Jun. 2013 (CEST)Beantworten
Gerade erst gesehen. Von einem X am Ende wussten ich und WSTM bislang niX. Scheint eine Prüfziffer zu sein; mal sehen, ob ich die nachrechnen kann. Leider kenne ich keinerlei Doku zu DNB.
Ich hatte übrigens in den letzten Tagen allerlei im Bereich ISBN und iSSN neu programmiert, was im Verlauf kommender Woche auf dich zukommen soll. Hoffentlich ohne falsche Fehler.
Das heißt: Im Lauf der Woche gibt es zusätzliches Gemecker über ungültige GND und ZDB und die DNB werden auch korrekt gecheckt. Im Rohzustand programmiert; muss ich aber erstmal selbst durchprobieren.
Unwahrscheinlich (Gemecker). Wer GND, DNB, ZDB verwendet, hat im allgemeinen das Kopieren drauf. Vielleicht kann auch jemand eine Liste der Artikel erstellen, in denen die Nummern fehlerhaft sind. Ich glaub aber nicht, dass die umfangreich wird.
Die Liste wird sich demnächst von selbst als Wartungskat erstellen, sofern es Vorlagenparameter sind. Aus dem gleichen Hause stammt: WP:Lua/Modul/URIutil/de – die kann dann nahe Null gehalten werden, so wie es auch kaum Seiten mit Einzelnachweisfehlern gibt. Du kannst ja dann die defekten ISBN abonnieren. Übrigens kommt es ab und an vor, dass jemand schreibt: DNB=München und sich schlicht mit dem C&P vertut.
Letzter Kommentar: vor 10 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
In der Zeile [[Datei:Horex_Regina_Sport_-_Motor_(2011-09-24_Mayen,_Foto_Sp).JPG|mini|offener Einrohrrahmen mit Geradwegfederung hinten ([[Horex Regina]])]] wird nach mini die Pipe entfernt. Gruß (22°C) --RonMeier (Diskussion) 12:12, 17. Jul. 2013 (CEST)Beantworten
Uumpf.
Sieht nach einer Nebenwirkung des Eingriffs von eins drüber aus.
Ich werde mich um einen Blitzfix bemühen, da Quelltext-schädigend. Und das bei der Hitze hier.
Letzter Kommentar: vor 10 Jahren10 Kommentare4 Personen sind an der Diskussion beteiligt
Hallöchen. Ich bin über diese bemerkenswerte Edit-Kette gestolpert, die wie es aussieht mit deinem Skript zusammenhängt: 1, 2, 3, 4. Nur als Hinweis, vielleicht magst du etwas damit anfangen. Zumindest die ungewollte Verdoppelung, die der Benutzer mit jedem seiner Edits verursacht, erscheint mir untersuchenswert. --TMg23:31, 17. Jul. 2013 (CEST)Beantworten
Dazu fällt mir leider nichts mehr ein.
In seiner Diffpage sieht der User ja, dass mit dem Attribut (class=;"NavFrame") was nicht stimmt. Deshalb schreibe ich drei Fragezeichen für die Diffpage, und es gibt auch einen großen roten Kasten am Kopf der Diffpage, in dem ebenfalls auf dieses Problem hingewiesen wird. Ich fürchte, auch wenn ich da fünf oder zehn Fragezeichen hinmale und die Kiste blinken oder rotieren lasse, ändert sich nichts. Aber irgendwann bekommt das ein anderer Autor mit und beendet den Spuk. Und dann haben wir ja mehr als zehn Fragezeichen. Machen kann ich da nix; es ist immer noch unerkannte Attribut-Syntax.
Da war neulich jemand bei dir, der wunderte sich über den roten Kasten, der unterschrieben ist mit WikiSyntaxTextMod PerfektesChaos, und fragte dich nach autoFormatter.
Nicht jeder (auch ich nicht) kann mit derartigen HTML? Zeilen etwas anfangen. Auf den Hilfeseiten fand ich dazu bisher nichts, SELFHTML hat mir auch nichts gebracht. Gruß --RonMeier (Diskussion) 11:21, 18. Jul. 2013 (CEST)Beantworten
„Sortierung nicht nötig“ weist auf einen potentiellen Fehler hin:
Wenn im Artikel Thomas Mann drinsteht {{SORTIERUNG:Thomas Mann}} – dann ist das ein wirklicher Fehler.
Gemeldet wird dies, weil ein dem Lemma gleicher Sortierschlüssel sich sehr oft als Hinweis auf einen vergessenen Umbau nach C&P erwiesen hatte.
Ich kann auch die rund 130 Fehlermeldungen einzeln benutzerkonfiguriert ausblendbar machen. Der eine interessiert sich nicht die Bohne für kaputte ISBN, der nächste will sie unbedingt haben.
Erfahrungsgemäß ist das dann aber zu mühsam, und am Ende konfiguriert ohnehin niemand.
Oh wei, was hab ich denn da angerichtet. Tut mir leid. Zu meinem Fundstück hätte ich drei ganz konkrete Vorschläge.
Im ersten Schritt erkennt dein Parser offenbar, dass es sich bei der ersten Hälfte von style="stilangaben attribut="wert" um ein CSS-style-Attribut handelt und ergänzt ein Semikolon und ein Leerzeichen. Du könntest die Tatsache, dass das style-Attribut mit einem Gleichheitszeichen endet, als Ausschlusskriterium nutzen und die Fundstelle in dem Fall entweder ganz überspringen oder von dort ausgehend per Backtracking zurück zum Leerzeichen gehen.
Im nächsten Schritt erkennt dein Parser in <element xyz"> wie es scheint ein Attribut mit dem Namen xyz" und ergänzt xyz"="???" als Hinweis für den fehlenden Wert. Auch da wäre eine simple Ausschlussregel denkbar: Attributnamen dürfen keine Anführungszeichen enthalten.
Ab da wiederholt es sich und wird jedes mal verdoppelt. Spätestens das würde ich wie schon erwähnt als Bug betrachten. Gut möglich, dass sich das mit Punkt 2 von selbst erledigt.
Wie gesagt nur meine Gedanken dazu. Falscher Code ist falscher Code da hast du Recht. Ich finde aber, dass unsere Skripte so etwas nicht noch schlimmer machen dürfen. --TMg12:20, 18. Jul. 2013 (CEST)Beantworten
Es fehlte das " hinter dem bereits vorhandenen Semikolon.
Es gibt unendlich viele Kombinationen, wie man mit fehlenden " oder ' oder Gleichheitszeichen (oder verdoppelt) oder Schrägstrichen oder Kommata und rgb() ungültige Syntax generieren kann. Dies hier ist ein Einzelfall, den ich noch nie vorher so gesehen hatte. Es wird keine Interpretation kaputter Attribut-Syntax geben; das ist schon im Wikitext nervig genug.
Die style-Analyse erfolgte später, und ist völlig unabhängig. Ihr war nicht mehr bekannt, dass der Attributwert aus dem vorher schon durch fehlerhafte Paare von " defekten Tag entstanden war.
CSS3 erlaubt so mannigfache Syntax, dass ich hier keine weiteren Analysen und Rätselraten anstellen werde, was gemeint sein könnte.
Die Fehlermeldungen bei ungültiger Attribut-Syntax werde ich in Kürze verbessert haben und klarer fassen.
Das einzige, was ich bei der weiteren Abarbeitung tun kann, ist bei einem unauflösbaren Syntaxfehler ein Flag zu setzen, das die gesamten weiteren Interpretationen bekannter Attributwerte unterdrückt.
Im Artikel war das Tag schon vor dem Eingreifen von WSTM wirkungslos. WSTM hat an der Funktionalität des Artikeltextes nichts verändert.
Auch solche Kuriositäten werden WSTM weiter verfeinern; insofern ist diese Disku durchaus produktiv.
Die style-Analyse sieht das Gleichheitszeichen am Ende. Das muss nicht unbedingt falsch sein. Aber es ist sehr, sehr wahrscheinlich, dass das Hinzufügen eines Semikolons die Sache nicht besser macht. Ebenso macht ein Reparaturversuch eines Attributs, das mit einem einsamen Anführungszeichen endet, die Sache wahrscheinlich nicht besser. Wie gesagt, nur meine Sichtweise. --TMg23:01, 18. Jul. 2013 (CEST)Beantworten
Wie schon gesagt; mein Parser arbeitet völlig anders. Das Grundproblem ist das fehlende " und damit die Verschiebung von Innen und Außen; von Parametername und Parameterwert. Das Weitere sind Folgefehler. --PerfektesChaos18:04, 3. Aug. 2013 (CEST)Beantworten
Wird inzwischen systematisch aufgearbeitet und die fehlerhaften serienweise falsch abkopierten Konstrukte werden wohl demnächst per Bot berichtigt; möglichst samt der fehlerhaften Kopiervorlagen. Dann sind sie schon sauber, bevor sie zufällig WSTM in die Hände fallen. --PerfektesChaos18:04, 3. Aug. 2013 (CEST)Beantworten
Das war insofern folgerichtig von WSTM, als bei der automatisierten Bearbeitung dieses ½MB-Monsters offenbar irgendwas schiefging, und die zugehörigen Klammern sich nur öffneten. WSTM hatte das mutmaßliche Ende zu raten versucht. Ich habe es gerade repariert.
Nebenbei: Hier waren deiner geschätzten Aufmerksamkeit die ??? in Zeile 14 entgangen; aber das repariere ich, wenn ich wieder zu frieren anfange. Habe noch mehr davon.
geschätzte Aufmerksamkeit hört sich sehr gut an. Aber - auch ich bin nicht fehlerfrei. Wenn du eine Liste derartiger Mängelartikel in meinen BNR stellen könntest, wärs nicht schlecht. Ich kann ja mit der Suchfunktion nur nach reinem Text suchen - oder?
mit der Heizung muss auch was schief gelaufen sein, draußen ists plötzlich wärmer als drinnen - nanu!?
Beispiel: Daniel Dargent. WSTM bemängelt, dass die DOI in der Vorlage DOI mit 10. beginnt. Das funktioniert doch aber wunderbar, wieso sollte sie denn nicht mit 10. beginnen dürfen? Oder bemängelt WSTM etwa, dass eine DOI NICHT mit 10. beginnt? Das sollte dann aber in der Fehlermeldung zum Ausdruck kommen (die DOI JGYN-06-2005-34-4-0368-2315-101019-200503203 - die ja auch wirklich nicht funktioniert, aber dummerweise bei Elsevier wohl so angegeben ist ([13]) --FA2010 (Diskussion) 11:20, 15. Aug. 2013 (CEST)Beantworten
WSTM ist in seinen Sprachkünsten nur eingeschränkt; über ein „Vorlagenparameter fehlerhaft“ kommt es nicht hinausgestottert.
Anschließend bemüht es sich zu verdeutlichen, dass es sich um eine DOI-Vorlage handelt, und der Fehlertyp wäre leading '10.' – ich kann gern schauen, ob ich zu dem Fehlertyp noch eine ausführliche mehrsprachige Beschreibung fabriziert bekomme. Es ist ein größeres Paket an Kodierungssystemen, Vorlagen und Regelverletzungen.
Als Sofortmaßnahme habe ich soeben den Fehlertyp umgetextet zu leading '10.' missing – das spricht sich irgendwann ’rum.
Was da irgendwo anders angegeben wurde, war keine DOI. Die 0368 und die 2315 meinen die gleiche Systematik; aber das ist vielleicht eine Elsevier-interne Kodierung.
Wenn ich mal Langeweile habe, baue ich diese Abfrage in die Vorlage ein und bereinige still und leise per Wartungskat den Bestand. Ich sag dir dann auch gern Bescheid.
Danke. Also fehlte das "missing" - mehrsprachig ist mir egal, nur in irgendeiner Sprache sollte es halt stimmen. :-) DOIs kommen mir sehr selten unter, das ist wohl auch wieder so eine gescheiterte Standardisierung ähnlich wie die unsäglichen URN. Das funktioniert doch eh nie, wenn man es wirklich mal braucht... Mit Googeln nach "Autor Titel" kommt man jedenfalls auch zum Ziel, wenn der standardisierte Mist mal wieder nicht funktioniert... --FA2010 (Diskussion) 13:49, 15. Aug. 2013 (CEST)Beantworten
Mir grad schleierhaft, was genau da passiert ist (hatte wohl mal rumgepfuscht, ohne erneut intensiv zu testen). Im Mai ging’s, jetzt für dich auch wieder. In deinem Hafen dümpeln ja hübsche Schiffchen. --PerfektesChaos20:39, 9. Aug. 2013 (CEST)Beantworten
Letzter Kommentar: vor 10 Jahren8 Kommentare2 Personen sind an der Diskussion beteiligt
ich hab da mal was gebastelt. Es erreicht seinen vorgesehenen Zweck, ist aber noch nicht ganz perfekt für eine längerfristige Zukunft. Daher hab ich ein oder zwei Fragen:
Ist es gefahrlos, falls das WSTM-Skript zwei mal geladen wird? Überschreibt es sich dabei selber oder ist da eine entsprechende Erkennung eingebaut?
Darauf teilweise aufbauend: auf mw.libs.WikiSyntaxTextMod kann ich die Existenz nicht wirklich gut prüfen, könnte ja auch ein Config-Objekt sein. Was wäre der erste Teil, der vorhanden ist? (bb?)
auf den beiden aufbauend: Ich würde ja im wstm_run-Clickhandler auf mw.libs.WikiSyntaxTextMod.api testen, damit ich beim folgenden Aufruf garantiert nicht im leeren lande...
falls du jQuery so gut kennst: Wie ist das mit dem $.ajax( ...WSTM-Skript... ).done(mw.libs.WikiSyntaxTextMod.api.load(true);): Ist das zuverlässig an diesem Punkt? Eigentlich hätte ich ja der Konsistenz wegen den mw.loader genommen, aber der mag ja für externe Skripte soweit ich gesehen habe habe keine Callbackfunktionen. Oder soll ich lieber per eingeschleustem config.load.after() versuchen?
und so ganz klein eine mini-Performance-Frage aus Interesse: Würde es was bringen den document.ready-Kram nur um das var$toolbox zu legen? Ist mir zwar egal und wahrscheinlich nur ein nicht wahrnehmbarer Unterschied, aber wenn ich gerad schon hier bin. ;-)
Wäre nett, wenn du mir diese Fragen beantwortet könntest. Die Fragen sind eigentlich für mich zurzeit nicht relevant, da das bei mir bisher schnell genug verarbeitet ist, es also so schon den Wünschen entsprechend funktioniert. Viele Grüße und einen schönen Wochenstart --se4598 / ?09:25, 12. Aug. 2013 (CEST)Beantworten
So ganz verstanden habe ich den Kontext noch nicht; aber ich kann erstmal Einzelfragen beantworten:
Das mehrfache Laden des Kopfmoduls schadet sich nicht.
Es gibt im Kopfmodul in WSTM.autoRun() ein .main.lockAuto – und das verhindert beim mehrfachen mw.loader.load (=“auto”) unerwünschte Doppelausführung. Es passiert beim zweiten Mal aber auch gar nix mehr.
Es gibt dort auch noch ein WSTM.main.ready() für Genießer.
WSTM ist auch dazu geeignet, mit eigenem mw.loader.implement(ID,URL) und .using() gestartet zu werden. Wird aber nur beim ersten Mal ein AutoRun auslösen; wie zuvor.
Eine hackige Trivialprüfung auf Ladung wäre neben dem offiziellen mw.loader.getState("user:PerfektesChaos/WikiSyntaxTextMod") die Existenz von mw.libs.WikiSyntaxTextMod.vsn – wie du richtig erkennst, kann der Benutzer ja auf Vorrat ein mw.libs.WikiSyntaxTextMod.config permanent angelegt haben.
Für die Zusammenarbeit mit der WSTM-API würde ich zu den dokumentierten Methoden raten. Ansonsten müsstest du auf mw.loader.getState("user:PerfektesChaos/WikiSyntaxTextMod/*") warten.
Warum du aber überhaupt zur WSTM-API greifst, ist mir nicht klar. Wenn ich das, was bislang da steht, richtig kompiliert habe, dann wärst du mit dem manuellen Start besser bedient; WikiSyntaxTextMod_Run oder auch mw.libs.WikiSyntaxTextMod.api.run() verarbeiten den Inhalt des TEXTAREA. Run steht im Kopfmodul zur Verfügung.
Die Frage mit Ajax habe ich nicht so restlos verstanden, und dieses Konstrukt zu dem hier mutmaßlich angestrebten Zweck noch nie gesehn. Eher nicht. Außerdem bypasst du damit deinen Cache; das erinnert mich irgendwie an ein getScript().
Performance und document.ready: Ist in diesem Fall wohl ziemlich egal; solange du keine DOM-Elemente anfasst, sind es nur Deklarationen auf Vorrat. Sie können auch außerhalb deklariert werden.
Überlegungen in dieser Richtung sind dann sinnvoll, wenn sich Asynchronität herstellen lässt: Ressourcen möglicherweise schon über das Netzwerk anfordern, während noch lokal im Prozessor am DOM gebaut wird. Immer .using() vor .ready lostreten.
Im Zweifelsfall kann man die fraglichen Deklarationen außerhalb von document.ready anordnen, weil parallel zum DOM-Aufbau ein anderer Kern auf deiner Festplatte nach dem Cookie suchen könnte. Wie parallel JS dann ist, weiß ich nicht; bei Google Chrome soll das intensiver so gehandhabt werden.
Für die Performance interessanter wäre die Frage nach Namensräumen und dann nach wgAction (edit/submit). Spart auch überflüssige Knöpfe in der Toolbar.
Und weil du grad hier bist: Für übermorgen früh habe ich einen kleinen Anschlag auf dich vor; einen Alpha-Test. Ich habe über das verregnete Wochenende ein neues Produkt beendet, und schreibe grad an der Doku.
Es soll mir eine Möglichkeit geben, WSTM auszuschalten (praktisch würde dabei wohl im einfachsten Fall ein config.load.inhibit=true reichen; Bandbreite spielt aber auch eine Rolle), dabei aber auch jederzeit auf allen Seiten die manuelle Ausführung möglich sein. Das Laden selber könnte man in der Tat dann auf action=edit und submit beschränken.
api.run() hat ein Kindersicherung in Form von api.isAppropriate, was das nicht erlaubt (Anscheinend tut das auch was mit if (typeof(WSTM.config.page.oldid) !== "boolean") aber das hab ich einfach mal weggelassen; was anderes als danach .load(true) aufzurufen macht es ja nicht). (nicht das ich dich falsch verstehe: api.load() ist eine dokumentierte Funktion). Eine versehentliche Ausführung an ungeeigneten Stellen wie action=view bleibt (bisher) praktischerweise funktionslos still.
Das mit dem $.ajax ist laut Doku praktisch ein $.getScript, nur mit cache=true verhindere ich das Anhängen des zufälligen Parameters zur Cacheumgehung und vertraue auf den Browser. Die Frage bezieht sich darauf, ob beim (deferred) .done() dein Skript immer durchgelaufen ist, sodass es safe ist, den api.load-Aufruf zu tätigen. (Nachladen ist erforderlich, wenn durch Cookie verhindert)
Für das (Nach)laden des Skriptes und Warten auf Ausführung hast du wertvolle Hinweise gegeben.
Aha. Na, du bist wohl alt genug, um dich über sämtliche Kindersicherungen hinwegzusetzen. Das ist in der Tat der Unterschied zwischen dem API-Aufruf und Run. Ich selbst benutze diese Mimik, um mich vor mir zu schützen.
Die API-Abfragen übermitteln möglicherweise, dass sie volatil sind und nicht in den Browser-Cache sollen; als Datenbank-Abfragen sind sie ohnehin keine statischen Ressourcen und können keine Timestamps oder ETags enthalten, sind somit immer neu abzufragen.
Was dabei cache=true bringen soll, leuchtet mir grad nicht ein.
Wenn du einen HttpFox hast, dann lass ihn doch bei der Aktion mal laufen.
Es ist ja eine URL mit index.php und nicht api.php – ich war auf der falschen Schiene durch Ajax→mwAPI→revision-content.
Die Anweisung nimmt sich aber nicht viel mit getScript und mw.loader.load und alle Varianten miteinander haben das identische Problem, das du mit Zeit und deferred ansprichst. Das done() kommt nach dem Eintreffen auf deiner Festplatte, nicht nach Abschluss der Ladeprozedur.
Deswegen steht am Ende des Ladens der WSTM-Untermodule der Start mit .after() usw.; nur dadurch wird gesichert, dass der Ladevorgang abgeschlossen wurde: Das Modul bestätigt von sich aus, dass es fertig geladen und initialisiert ist, und sendet entsprechende Botschaften aus.
Das gehört sich auch so für die Synchronisation aller parallelen Vorgänge.
so, aktualisiert mit einem schönen $.extend(true, mw.libs, WSTM_config_inhibit_runAfter);. Damit kann ich auch beliebig die WSTM-Konfiguration ändern, ohne an dem Abschnitt wieder rumzufummeln. Find ich schöner als selbst jede Objekt-Ebene auf Existenz zu prüfen und ggf. zu erstellen. Grüße --se4598 / ?20:08, 15. Aug. 2013 (CEST) PS: Wer Race Conditions findet, darf sie behalten ;-)Beantworten
Fein.
Mit $.extend() kann ich in meinen Bedienungsanleitungen niemand kommen; da muss das schon nachvollziehbare Elementarprogrammierung sein.
Du hast mich übrigens dazu angeregt, eine in der d.js schon verfügbare, in r.js demnächst aufschlagende Komponente zu definieren:
.config.load.api – Lade zusammen mit dem Kopfmodul auch alle API-Funktionen, wenn vor dem .loader.load() definiert.
Inzwischen kennt das Kopfmodul einen noch nicht dokumentierten Parameter .config.load.api = true; – vor dem .loader.load() gesetzt, bewirkt es von vornherein das Laden aller Untermodule. Nach Laden des Kopfmoduls ist dies wirkungslos.
Weil das Kopfmodul sich selbst nicht aktualisieren kann, müsstest du dafür deinen Cache leeren oder eine Woche warten.
Danke für die Info; Behebung wird in den nächsten Stunden live.
Die eigentliche Programmierung ist in Ordnung. Mein selbstgeschriebener Minimierer, der aus dieser zuvor eine Weile ausgetesteten Version schließlich ein auf 40 % der Größe reduziertes kompaktes Skript macht, hat hier leider ein Leerzeichen gemopst. Durch eine leicht andere Formulierung kann ich das aber vermeiden.
Läuft, vielen Dank für die prompte Erledigung. In die Fassung vor Minimierung hatte ich gar nicht mehr geguckt, nach dem Kontext ohnehin nicht. Es müssen Leerzeichen sein, whitespace (\s) reicht nicht? Was immer das Skript da tut… Grüße, IvlaDisk.16:27, 18. Aug. 2013 (CEST)Beantworten
Es könnte\s im RegExp benutzt wrden; aber es gibt im Wikitext an dieser Stelle nur noch Leerzeichen. Umgekehrt wären aber Zeilenumbrüche jedoch hier in diesem Vorlagenparameter unerwünscht, die aber noch von \s getroffen würden.
Du hattest mich einmal was mit BBKL gefragt, was ich aber schon längst wieder vergessen habe. Hier gibt es ein Beispiel, das hinsichtlich des Layouts der Vorlageneinbindung noch weiter ausgebaut werden kann. Die umgebenden Zeichenketten prolog und epilog habe ich aber immer noch nicht realisiert.
Ich finde auf den ersten Blick auf der Spielwiese (sind das alle, die du meintest?):
Eine zusätzliche Klammer hinter „errichtete“
war der 1988 errichtete] [[Le Nordais#Éole|Éole
Eine gemopste beim nächsten Weblink
wiatraki na świecie!''] [http://epoznan.pl/ epoznan.pl] (polnisch).
Ein Fix sollte heute Abend für dich live sein; muss ich aber noch gründlicher denken und testen. Insbesondere ist mir noch nicht ganz klar, ob es ein oder zwei Bugs waren, und was es dabei zu bedeuten hat, dass beim zweiten Problemkind eine schließende und eine öffnende Weblink-Klammer unmittelbar aufeinander folgen.
Und irgendwo in dieser Jonglage mit Zeilenumbrüchen und </ref> und fehlenden schließenden eckigen Klammern klappt grad irgendwas nicht. Braucht wohl eine ungestörte Gespensterstunde. Es sieht im Moment so aus, als ob die jüngste Veränderung zum Erkennen unescapter Klammern in der URL einen Nebeneffekt gehabt hätte; aber nur bei </ref>. Muss ich nochmal sorgfältig aufarbeiten.
Es sieht so aus, als ob das ein spezifisches Problem war, das ausgelöst wird, wenn nur das fehlerhafte Weblink innerhalb eines <ref> steht. Dann lief der Code Amok; diese Weichenstellung war nicht programmiert und es wurde versucht, woanders eine Klammer zu setzen; die Steuerung war aber durcheinander.
Diesen Pfad habe ich inzwischen bei mir ergänzt.
Bevor ich das hochlade, muss ich aber am Wochenende in Ruhe und mit etwas geistigem Abstand durchtesten. Es ist offenbar das erste Vorkommen seit dem Frühjahr.
Letzter Kommentar: vor 10 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
seit einiger Zeit werden einige Fehler in ihrer Anzahl verdoppelt. Z.B. jetzt Hans-Olaf Henkel: Nicht alles lässt sich automatisch beheben. Bitte kläre die folgenden Probleme von Hand:
Ja, da experimentiere ich schon seit letztem Wochenende dran; jetzt läuft es schon geschmeidiger. Auslöser waren Umstellung zur automatischen Korrektur von Klammern in der URL; das brachte ihn etwas durcheinander. Ich manövriere zwischen gar keiner und zwei Fehlermeldungen … Korrigieren kann ich in dieser Situation ohnehin nicht; nur melden.
Letzter Kommentar: vor 10 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Saw this tool via another tool via another one. You guys should get together to create one Unified Law of Javascript Fixers.
I've been moving Checkwiki from toolserver over to WMFLabs. The new loaction is at: http://tools.wmflabs.org/checkwiki/cgi-bin/checkwiki.cgi. It is in production mode. AWB now uses it. WPCleaner will use it by default on the next release. The new code is catching errors the old code didn't. I've also been fixing outstanding errors in the program. I'm about to turn on new ISBN code and it will catch more errors for error #69. The details are at en:Wikipedia talk:WikiProject Check Wikipedia. Fill free to requesting anything or if you have any errors in the code to be fixed.
You might wait a couple of weeks until I wrote some more doc pages on WSTM.
Some of the remedies are not global built-in, but relying on user defined modifications. English doc pages about modifications are not written yet.
I am also going to integrate the ultimate administrative gadget into the main module, which should be present when you have broadcasted this beast (I will crack the 1MB with that feature).
The German pages are rather exhaustive and I managed only to describe the en:flow during the last weeks. However, some redlinks should be filled with a bit of life.
Meanwhile you may run it yourself and gain some experience.
There might be some formats and customs on enWP not common in deWP. The tool has acquired a German taste beside of syntax. If there are widely used practices (or bad habits) perhaps some error messages need to be suppressed, or will need more explanation.
Der ISBN-Parameter wird schon mal nicht klein, sondern groß geschrieben.
Natürlich gehört da nur eine ISBN hinein. Wenn man schon (unzulässigerweise) eine zweite hineinschreibt, muss auch ISBN vor die zweite geschrieben werden, damit das Link funktioniert.
Mittelfristig kann es dazu kommen, dass derartige ungültige Belegungen des Vorlagenparameters erkannt und zurückgewiesen werden. Nur eine ISBN ist erlaubt, und nur Ziffern, Bindestriche, X.
Auf den ersten Blick sehe ich den Fehler (Verdopplung der Prüfziffer) nicht, es kommen mehrere automatische Berichtigungen aus verschiedenen Programmeinheiten zusammen. Muss ich in Ruhe über Nacht experimentieren.
Scheint ein isolierter Spezialfall und kein flächendeckendes Problem zu sein?
Die ISBN sollte trotzdem nicht beschädigt werden.
Weil wir grad dabei sind: Du hast ja testweise ein Direktlink auf DNB usw.
Funktioniert das?
Mein behelfsmäßiges Link über test.wikipedia.org kann ersetzt werden durch:
ja der Fehler ist nur das eine mal aufgetreten. Ist auch eigentlich nicht schlimm, da ja sofort die ISBN als fehlerhaft gemeldet wird.
Direktlink: funktioniert. aber: für Anwender sollte er schon etwas ausgebaut werden, und wenn es nur der Text ist "Suchen im Katalog der Deutschen Nationabibliothek" usw.
gut finde ich, dass er automatisch ein neues Fenster aufmacht. (also kein CTRL nötig)
das Anhängen der ISBN macht aus meiner Sicht keinen Sinn. Wenn ich die andersformatige ISBN benötige, bin ich im Bearbeiten-Fenster - da will ich nicht erst hochrödeln, um die ISBN anklicken zu können. Ein Tag mit Sonne - bis dann. --RonMeier (Diskussion) 17:15, 11. Okt. 2013 (CEST)Beantworten
Eine berichtigte Version ist für dich bereit.
Da hatte sich eine vorwitzige Minus-Eins breitgemacht. Ich habe sie rausgenommen und weiß auch nicht, was ich mir dabei mal gedacht hatte. Hoffentlich hatte es nicht doch einen verborgenen Sinn.
Den Fehler gibt es seit über einem Vierteljahr bei Vorlagenparametern, bei denen außer der ISBN noch weiterer Text vorkommt. Ist offenbar nicht sehr häufig.
dass er automatisch ein neues Fenster aufmacht. (also kein CTRL nötig)
Ja, und er merkt sich, welches Fenster aufgemacht wurde; für die nächste DNB kein neues, sondern alle DNB in ein Fenster, alle LCCN in immer dasselbe andere. Oder (konfigurierbar) alle Abfragen in genau einem Fenster. Das erspart das Schließen von dauernd neu aufgemachten Fenstern.
Formatierungsvarianten:
Du bist ja nicht alleine auf der Welt.
Zwei Lösungswege:
WP:WikEd verwenden. Damit werden die ISBN im Bearbeitungsfeld zu anklickbaren Weblinks. (Klappt im Moment noch nicht, weil dort englich und hier im Moment nur deutsch.)
Nach dem Öffnen der Seite beim Klick auf [Bearbeiten] die Umschalttaste oder [Strg] gedrückt halten. Dann hast du zwei Tabs oder Fenster nebeneinander; kannst in einem die ursprüngliche Variante sehen und die ISBN anklicken, und hast in einem anderen Fenster deine Bearbeitung.
Letzter Kommentar: vor 10 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
am hellichten Tage springt WSTM bei mir einfach nicht mehr an. Trotz Browser-Cache-Leerungen, Versuch mit anderem Browser: die Schnark-Module funktionieren, nicht aber WSTM. Woran könnte das liegen? --FA2010 (Diskussion) 10:01, 22. Okt. 2013 (CEST)Beantworten
Vermutlich habe ich bei einem turnusmäßigen Update was verbockt; sicher etwas, das sich nur im komprimierten Modus bemerkbar macht und nicht in meinem Entwicklermodus. Ich habe da auch so einen Verdacht.
Geht vermutlich nach 11:00 wieder, und sei es per Revert der gestrigen Aktion.
Mit der komprimierten Version (nur 40 % der Größe), die du und die Normalanwender benutzen, habe ich nur selten zu tun, und bekomme das nicht mit.
Seit einer Weile macht mein Kompiemierungssystem das noch eine Kleinigkeit kleiner und effizienter. Dabei hatte ich den Fall des Zeilenumbruchs nicht sorgfältig berücksichtigt. Am Sonntag zu 22:00 kam nun erstmals eine Programmeinheit damit angeschlichen (vermutlich das einzige Vorkommen), und wurde syntaktisch falsch und damit das WSTM-System nicht mehr vollständig geladen.
Da gab es vor Monaten mal eine Beschwerde, und ich hatte daraufhin etwas umgestellt. Es war irgendwas mit einem Auto, wo hintendran noch ein Buchstabe kam. An mehr kann ich mich spontan nicht erinnern; werde aber am Wochenende nachgraben und ggf. reaktivieren, was es zu reaktivieren gäbe.
Nebenbei gefragt: Was siehst du eigentlich auf der Seite Spezial:Helferlein?
als erstes sehe ich die Buttons für paneMarker und WikiSyntaxTextMod. Auffällig ist, das die Seite keine Versionsanzeige erlaubt. (gehts auch konkreter?) Schönen Tag auch. --RonMeier (Diskussion) 13:15, 25. Okt. 2013 (CEST)Beantworten
Aber es ist eine nette Idee, die Werkzeuge auch noch ihre Versionsnummer dahinter schreiben zu lassen; werde ich mal gelegentlich angehen. Obwohl du das vermutlich nicht gemeint hattest.
Was sich unter den Buttons am Ende verbirgt, hattest du aber schon mitbekommen?
Wenn du das sehen kannst, ist es fein; ich habe das heute Abend mal freigegeben für alle enWP-Einbinder.
Letzter Kommentar: vor 10 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
bei dem Artikel Liste der Gemeinden in Minas Gerais vorbei? Deine Syntaxkorrektur löscht in der Vorlage:Nts einen geraden Strich, welches dann dazu führt, dass die Weblinks auf GeoHack z.T. mit BKL hinterlegt sind. Ich habe die Änderungen nicht abgespeichert, sodass in dem Artikel selber noch kein "Schaden" entstanden ist :-) Lieben Dank für Deine Mühe und viele Grüße von --Silke (Diskussion) 12:56, 25. Okt. 2013 (CEST)Beantworten
Hinweis: Lieber PerfektesChaos, ne daran kann es eigentlich nicht liegen, Deine Korrekturen fangen erst ab Zeile 616 an, die BKL-Anzeige erfolgt aber schon ab Zeile 12. Könnte es sein, dass mir einfach nur die "Vorschau" einen Streich spielt? Liebe Grüße zum Wochenende, --Silke (Diskussion) 19:30, 25. Okt. 2013 (CEST)Beantworten
Ich halte WSTM auch für unschuldig.
nts soll die Sortierung von Zahlen bewirken; das hat nichts mit Koordinaten zu tun.
Zur Vorlagensyntax: Es ist in der Vorlagenprogrammierung einerlei und wirkungsgleich, ob
{{nts|}}
{{nts}}
{{nts|1=}}
Diese Vorlage nts habe ich sowieso grad gefressen.
Sie ist ohne Parameter sinnlos und kann ohne Zahlenwert entfernt werden.
Ohne Zahlenwert kommt es intern zu einem Syntaxfehler, den du bloß nicht sehen kannst.
Sie ist völlig überflüssig, wenn in dieser Spalte ausschließlich ganze Zahlen (Einwohner) oder nichts steht.
Die mehrhundertfache Verwendung bringt nur die Seiten zum Abstürzen. Sie müssen bei den Einwohnerzahlen alle entfernt werden.
Da war wohl durch Edit-Unfall eine halbe Zeile verlorengegangen.
Einmal Cache-Leerung, dann sollte es wieder gehen.
Die gute Nachricht: Außer dir war niemand betroffen.
Ich selbst musste erstmal meine Konfiguration aktualisieren, um genau deine Situation zu simulieren; ich lese ja schon seit langer Zeit direkt von meiner Festplatte und nicht vom Server, und musste die Test-Kombination erst wieder zusammenfrickeln. Deshalb hatte ich bei meiner einwöchigen Erprobung nichts von dem Fehler gemerkt, weil er genau da dazwischen saß.
Wenn du beim Artikel auf das manuell-WSTM-Auslösen-Link zeigst: Welche Versionsnummer erzählt denn der da so? Sollte mit (d)Run=-5.18999 anfangen; der Rest wäre egal.
Ich habe eine Reihe von Meldungen für die Fehlerkonsole geschrieben. Welche ist denn die allerletzte davon?
Da muss unterwegs irgendein Server geschlafen haben, oder der Firefox-Cache hat dich beschummelt.
5.17 ist die Version von gestern Abend, mit der fehlenden halben Zeile.
5.18 war die berichtigte Version von heute, 12:03 gemeldet.
5.18999 ist die gleiche, mit Konsolen-Meldungen.
Bei den Meldungen hatte ich einen Denkfehler. Ich kann sie sehen, weil ich der MediaWiki-Methode mw.log() erzählt habe, dass sie auf die Fehlerkonsole umgeleitet werden sollen.
Normalbenutzer bekommen den Aufruf von mw.log() überhaupt nicht mit, und das ist volle Absicht. Nur Entwickler verarbeiten Aufrufe von mw.log() dahingehend, dass sie sich solche Meldungen anzeigen lassen. (Übrigens meist auch nicht in der Stufe „Fehler“, sondern in der Stufe „Log“, also rein informativ.) Wahrscheinlich würdest du etwas sehen, wenn du an den URL-Aufruf &action=edit noch dranhängst &debug=true – damit wird dieser Meldungsapparat allgemein aktiviert.
Zurzeit wird genau dieses Management des Einbindens der Untermodule M, W, C, E, I, H, T, X, L, U, S, O umgestellt; mit dem Ziel, es Ende des Jahres anders zu handhaben.
Das soll die Zusammenarbeit von „WSTM für WSTM“ erweitern auf „WSTM-Bibliothek für andere“.
Ein weiterer Effekt ist, dass ich dann beliebig und spontan Versionen der Untermodule im Entwicklungsstadium unter die fertigen Versionen mischen kann.
Dazu müssen nach und nach die Untermodule leicht umgestellt werden, was sukzessive erfolgt. Da, wo du jetzt eine 6.01 als Versionsnummer siehst, ist das bereits passiert.
Eigentlich soll das ruckelfrei und unbemerkt erfolgen; durch die verlorene halbe Zeile gestern hat das doch nicht so ganz geklappt.
Letzter Kommentar: vor 10 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo PerfektesChaos, ich habe im Artikel Denis Diderot die Referenzen in einen references-Block verschoben. Es sind mehr als 300, maximale Übersichtlichkeit ist also anzustreben. Mir schien die Form
<ref name =...>
Text Text Text</ref>
<ref name =...>
Text Text Text</ref>
<ref name =...>
am übersichtlichsten. Wenn ich den Artikel jetzt aber bearbeite, setzt mir Deine Bearbeitung die </ref> in eine neue Zeile. Das ist wesentlich unübersichtlicher, da man die Text-Zeile nicht mehr 'freischwebend' sieht. Es handelt sich im genannten Artikel allerdings fast ausnahmslos um einzeilige Texte, von denen wohl zwei Drittel bei einem durchschnittlichen Bildschirm auch ohne Umbruch dargestellt werden. Das ist also anders, als bei Referenzen mit mehrzeiligen Literaturvorlagen, bei denen eine neue Zeile sinnvoll sein dürfte.
Vielleicht kannst Du noch einmal überlegen, ob das momentane Verfahren verfeinert werden kann? Etwa: Bei weniger als 10 Referenzen wie bisher, bei mehr nur, wenn mehr als die Hälfte mehrzeilig sind. Ich selbst werde mit einem Hack das Problem umgehen, Dir jedenfalls noch vielen Dank für das Script, es grüßt, --Griot (Diskussion) 22:54, 13. Nov. 2013 (CET)Beantworten
Bedaure, aber solche Regeln sind kaum umsetzbar.
Schließlich kann es ja auch bei längeren Listen 25 % unübersichtliche Blöcke geben.
Und: „mehrzeilig“ und „einzeilig“ hängt von der Anzahl der Zeichen und ihrer Breite (zurzeit in den Bearbeitungsfeldern meist monospace) ab, und damit von der aktuellen Bildschirmbreite. Smartphone?
Insbesondere wenn mehrere (und zum Teil arg lange Blöcke, mit Literaturvorlage und langen URL und Sammelwerk) refs mehrzeilig werden, sollen ja die kurzen </ref> einen sichtbaren Einschnitt vergrößern und die Abgrenzung verbessern.
Für die anderen Benutzer sieht es aus wie ein Bug, wenn willkürlich und nach nicht erkennbaren Regeln mal dies, mal das passiert und es unerklärlich ist, warum sich das mal so und mal anders verhält. Nun ist ein Artikel auch gerade an der von dir vorgeschlagenen Grenze, und es kommt ein kurzer oder langer Block zu den refs hinzu. Also werden plötzlich alle refs anders in den Zeilen angeordnet. Nun wird eine ref wieder gelöscht; schwupps! werden wieder sämtliche ref anders formatiert. Lieber nicht.
Aber wenn du grad hier aufschlägst:
Du hast eine Steuer-Variable WikisyntaxDeutschVieles in deinen JS-Seiten zu stehen. Die ist mittlerweile obsolet; kannst du zur besseren Übersichtlichkeit auch löschen oder müsstest auf das Anwendungsobjekt migrieren.
Deine wirksamen Aufrufe verwenden alle ein WikiSyntaxTextMod mit großem S. In Kommentaren stehen noch veraltete Formen mit kleinem „s“. Die möchte ich mit dem Jahreswechsel weniger unterstützen und wäre glücklich, wenn deine JS-Seiten nicht in den Suchergebnissen auftauchen; dann wäre ich beruhigter.
Danke, PerfektesChaos, für die Antwort. Zu den letzten Punkten: WikisyntaxDeutschVieles war gerade entfernt worden, myskin.js ist jetzt gelöscht, WikiSyntaxTextMod mit kleinem 's' verschwindet bei der nächsten Änderung.
Ja, mein konkreter Vorschlag (=erster Gedanke) war unbrauchbar. (Mit einzeilig meinte ich natürlich, ein Newline enthaltend.) Vielleicht behältst Du nur in Erinnerung, dass diese Änderung jedenfalls nicht in jedem konkreten Fall auf Zustimmung stößt. Vielleicht passiert das doch häufiger? Für mich ist es, wie gesagt, unproblematisch, ich ändere es zurück. Gruß und gute Nacht, --Griot (Diskussion) 00:23, 14. Nov. 2013 (CET)Beantworten