Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise
Müsste denn nicht eigentlich generell ein width="" als fehlerhaft erkannt werden? Es wird auch nur erkannt wenn es das erste Attribut hinter einem einzelnen ! ist. Merkwürdig. Das hier
würde komplett ignoriert werden. Ja nee, ich schmeiße es sowieso raus, weil es nutzlos ist, aber das ist mir halt gerade so aufgefallen. --Liebe Grüße, LómelindeDiskussion14:33, 10. Dez. 2015 (CET)
Normale Tabellenzeilen werden hinsichtlich Attributen (noch) nicht erkannt; sehen aus wie Vorlagenparameter. Zu heikel.
Wenn, dann wohl maximal die erste Spalte (erste Zelle einer Quelltextzeile), und auch nur bei bekannten Schlüsselwörtern, und nur, wenn anders als bei Vorlagenparametern üblich in " eingeschlossen.
Letzter Kommentar: vor 8 Jahren8 Kommentare3 Personen sind an der Diskussion beteiligt
Hallo PerfektesChaos, ich weiß ich hatte so etwas schon mal angesprochen aber gerade hatte ich ein sehr unschönes Anpassungsergebnis.
[[Datei:Flag of New Zealand Government Ships 1867.svg|mini|{{FIAV|historical}}Die neuseeländische {{lang|en|Blue Ensign}} von 1867.]]
[[Datei:Koru flag.svg|mini|{{FIAV|proposal}} Die Koruflagge von Friedensreich Hundertwasser (1983).]]
[[Datei:Naval Ensign of New Zealand.svg|mini|{{FIAV|000001}} Neuseeländische {{lang|en|White Ensign}}]]
[[Datei:Civil Ensign of New Zealand.svg|mini|{{FIAV|000100}} Neuseeländische {{lang|en|Red Ensign}}]]
wird
[[Datei:Flag of New Zealand Government Ships 1867.svg|mini{{FIAV|historical}}Die neuseeländische {{lang|en|Blue Ensign}} von 1867.]]
[[Datei:Koru flag.svg|mini{{FIAV|proposal}} Die Koruflagge von Friedensreich Hundertwasser (1983).]]
[[Datei:Naval Ensign of New Zealand.svg|mini{{FIAV|000001}} Neuseeländische {{lang|en|White Ensign}}]]
[[Datei:Civil Ensign of New Zealand.svg|mini{{FIAV|000100}} Neuseeländische {{lang|en|Red Ensign}}]]
Das ist einigermaßen fatal, denn dadurch werden die Flaggen (es werden mehrere angepasst) riesig. Pipe verschwindet, dadurch wird mini nicht mehr erkannt und was ist eigentlich {{FIAV}}?
Oha kommt schon manchmal vor so etwas Also konkret geht es um die Flagge Neuseelands kannst du da bitte mal reinschauen? Ich ändere es erst einmal nicht da ist eigentlich ein Parameter |sprache=en doppelt, aber ich möchte das jetzt nicht vermurksen. Oh man, das glaube ich jetzt nicht, wenn ich das allein auf der Spielwiese einfüge dann bleibt der Pipe da wo er ist, also muss es da einen weiteren Auslöser geben die Vorlage am Anfang des Artikels? Nein die ist es nicht. Das verstehe ich jetzt ganz und gar nicht. Da muss ich erst mal etwas genauer schauen. Das ist echt mysteriös. Also bei Schwerin passiert das auch Artikel öffnen und weg ist die Pipe und die Datei Flagge Schwerins wird zu hochkant=0.5 Flagge Schwerins
Was mache ich da jetzt? Du bist offline, aber das scheint mir doch irgendwie wichtig zu sein. Zumindest bei der kleinen Flagge von Schwerin fällt so etwas nicht sofort auf. Aber hochkant=0.5 hat es wohl etwas abgemildert. Auch die bleibt, allein eingefügt auf der Spielwiese, nicht in der ersten Zeile versteht sich, unverändert, wenn ich meinen Button betätige. Heute ich nicht mein Tag. --Liebe Grüße, LómelindeDiskussion17:56, 15. Dez. 2015 (CET)
So was ich schon mal feststellen konnte ist, dass Dateien innerhalb einer Galerie nicht betroffen sind, das ist ja auch zu erwarten. Beispiel Siberfarnflagge.
Ich kriege es nicht raus warum das genau passiert. Aber ich kann dir ein Szenario anbieten, vielleicht wirst du daraus schlau.
Auf der Spielwiese
Vorher mit zwei weiteren Dateien ohne Vorlagen davor
=== Wappen ===
Das geänderte Wappen wurde am 11. Februar 1991 durch das Innenministerium genehmigt und unter der Nr. 26 der Wappenrolle von Mecklenburg-Vorpommern registriert.
[[Datei:DEU Schwerin COA.svg|mini|hochkant=0.5|links|Stadtwappen]]
[[Datei:Wappen Schwerin2.png|mini|hochkant=0.5|Wappen von 1939 bis 1991]]
[[Datei:Flagge Schwerin.png|mini|hochkant=0.5|{{FIAV|100000}} Flagge Schwerins]]
Nachher Pipeschwund
=== Wappen ===
Das geänderte Wappen wurde am 11. Februar 1991 durch das Innenministerium genehmigt und unter der Nr. 26 der Wappenrolle von Mecklenburg-Vorpommern registriert.
[[Datei:DEU Schwerin COA.svg|mini|hochkant=0.5|links|Stadtwappen]]
[[Datei:Wappen Schwerin2.png|mini|hochkant=0.5|Wappen von 1939 bis 1991]]
[[Datei:Flagge Schwerin.png|mini|hochkant=0.5{{FIAV|100000}} Flagge Schwerins]]
Vorher ohne vorangestellte Dateien = Nachher ohne Auswirkung
=== Wappen ===
Das geänderte Wappen wurde am 11. Februar 1991 durch das Innenministerium genehmigt und unter der Nr. 26 der Wappenrolle von Mecklenburg-Vorpommern registriert.
[[Datei:Flagge Schwerin.png|mini|hochkant=0.5|{{FIAV|100000}} Flagge Schwerins]]
Also eine Datei davor reicht auch aber im Artikel Schwerin waren es nun mal zwei. Was genau in dem anderen Artikel der Auslöser ist, kann ich nicht ermitteln. --Liebe Grüße, LómelindeDiskussion10:07, 16. Dez. 2015 (CET)
Noch eine Seite, Weliki Nowgorod, wenn man das komplett zur Bearbeitung öffnet verschwindet Pipe aus der Datei im Unterabschnitt „Heraldik“, öffnet man hingegen nur den Abschnitt Politik, der „Heraldik“ beinhaltet, dann bleibt alles unverändert. Wenn ich wiederum den kompletten Artikel öffne und alle im Text vor diesem Abschnitt vorhandenen Dateien (Infobox nicht berücksichtigt) ausblende, bleibt Pipe dort wo er ist. Oder anders ich blicke direkt auf das Bearbeitungsfenster an der Stelle im Quelltext, wo [[Datei:Flag of Veliky Novgorod.svg|mini|{{FIAV|100000}} Flagge Weliki Nowgorods<br /> Seitenverhältnis: 3:5]] steht, klicke auf meinen WSTM-Button, Pipe verschwindet sofort aus dem Bearbeitungsfenster … ist aber nach dem Durchlauf und Neuaufbau der Seite dann wieder an Ort und Stelle. --Liebe Grüße, LómelindeDiskussion10:00, 18. Dez. 2015 (CET)
Den letzten Part habe ich nicht verstanden.
Das erste Problem war eigentlich schon mal beseitigt gewesen; scheint durch jüngste Änderungen als Zombie wieder auferstanden zu sein.
WSTM beendet beim Auftreten einer Vorlage die Textanalyse der Medieneinbindung; zumindest bei den etwas fortgeschritteneren Benutzern, die mit Textersetzungen arbeiten.
Damit kann WSTM es nicht unterscheiden, wenn eine Bildlegende mit einer Vorlage beginnt, oder wenn es ein leerer Parameter ist, der entfallen kann; also die Pipe überflüssig ist.
WSTM soll nachgucken und hat das auch schon gemacht, ob nun nur noch Leerzeichen und dann die schließenden eckigen Klammern kommen, oder ein Fremdkörper. Im ersten Fall soll die Pipe weg, im zweiten muss sie bleiben.
Wird schon wieder.
Zumindest in einigen Konstellationen wurde es deiner Beschreibung nach richtig gehandhabt; ich fürchte, das waren meine Testsituationen. Was bei den anderen Fällen jetzt anders ist und zur Kastration führte, muss ich sorgfältig analysieren. Es hat durchaus für WSTM eine Bedeutung, was für Elemente bereits verarbeitet wurden.
Hmmm, welchen Teil hast du nicht verstanden? Ich kann versuchen es nochmal anders zu erklären.
Ich weiß, dass ich mich damit manchmal etwas schwertue. Im Grunde ist es so, nur sobald sich im bearbeiteten Textabschnitt im Bereich vor der Datei [[Datei:Flagge von OZ.jpg|mini|{{FIAV}} Bildbeschreibung]] irgendeine weitere Datei (ohne Vorlage innerhalb der [[Datei:Irgendein Bild.jpg|mini|Bildbeschreibung]] befindet, verschwindet der Pipe. Ist davor keine andere über eckige Klammern eingebundene Datei (oder nur Dateien die ebenfalls eine solche Einbindung haben) im Text dann wird auch kein Pipe entfernt. Verstehen tute ich es allerdings auch nicht, warum das so ist oder welchen Einfluss ein Dateilink dabei hat.
Aus diesem Beispielszenario
Darstellung
Text
[[Datei:Flag of Gondor.svg|mini|x50px|{{FIAV|100000}} Flagge von Gondor]] → Datei mit Vorlage
[[Datei:Lothlorien.jpg|mini|x50px|Lothlóriën]] → Datei ohne Vorlage
[[Datei:Flag of Mordor.svg|mini|x50px|{{FIAV|100000}} Flagge von Mordor]] → Datei mit Vorlage
Text
Flagge von GondorLothlóriën Flagge von Mordor
wird diese Anpassung
Text
[[Datei:Flag of Gondor.svg|mini|x50px|{{FIAV|100000}} Flagge von Gondor]] → Datei mit Vorlage → Pipe bleibt erhalten
[[Datei:Lothlorien.jpg|mini|x50px|Lothlóriën]] → Datei ohne Vorlage
[[Datei:Flag of Mordor.svg|mini|x50px{{FIAV|100000}} Flagge von Mordor]] → Datei mit Vorlage → Pipe verschwindet
Text
Flagge von GondorLothlóriënx50px Flagge von Mordor
Zu gutes Gedächtnis von WSTM, und zu schlechtes Gedächtnis bei mir.
WSTM hatte sich die Eigenschaften der zuletzt mal bearbeiteten Dateieinbindung gemerkt, und das wurde anschließend nicht vollständig auf den Neutralzustand zurückgesetzt.
Deshalb war es bei der ersten Dateieinbindung immer korrekt.
Bei der nun folgenden wurde eine bestimmte Eigenschaft der vorigen verwendet, und nicht der neue Standardzustand. War die vorige Dateieinbindung oder irgendeine vorige Dateieinbindung also eine vorlagenlose, erschien das bei allen folgenden genauso.
Das betrifft die Frage, ob die Bildlegende ohne Vorlagen ein einfacher Wikitext wäre, oder aber komplexer aufgebaut ist.
Programmiert hatte ich an der zugrundeliegende Architektur zuletzt Anfang November 2012.
Als ich nun vor ein, zwei Monaten einen Parameter für nicht-komplexe Bildlegenden eingeführt hatte, hatte ich längst vergessen, was zu tun ist, um einen neuen Parameter einzuführen, und wie ich das drei Jahre vorher konstruiert hatte.
Die Parameter müssen zentral registriert sein, damit sie bei jeder neuen Wikilink-Geschichte wieder jungfräulich sind.
Fix für dich live.
„Nicht verstanden“ hatte ich die Geschichte, warum die Pipe beim Seitenaufbau weg und dann wieder dagewesen sein solle. Begreife ich immer noch nicht, und dieses Jahr wohl auch nicht mehr.
Prima, es scheint jetzt alles wieder normal zu sein, auch das Phänomen mit dem kurzzeitigen Verschwinden sehe ich nicht mehr. Ist ja nicht so wichtig zu wissen warum ich das gesehen hatte, ich habe öfter mal Halluzinationen. --Liebe Grüße, LómelindeDiskussion11:46, 22. Dez. 2015 (CET)
Automatisch generierter Titel
Letzter Kommentar: vor 8 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Nun für mein Verständnis, was soll ich eigentlich aufgrund dieses Hinweises Automatisch generierter titel, oder englischsprachige Ausgabe, genau machen. Das rauslöschen, es prüfen, och nööööö da habe ich keine Lust zu. Manchmal mache ich das natürlich wenn ich den Link, warum auch immer, sowieso aufrufen muss, aber dann benötige ich keinen Hinweis, das sehe ich ja. Was erwartet also WSTM oder der Skriptersteller, was ich da tun sollte, damit der nächste dann nicht mehr darauf reagieren muss?
OT: ich glaube das mit dem list habe ich hinbekommen, aber es hat etwas gedauert, bis ich es verstanden hatte. Ja ich lese ungern diese Manuals, aber du weißt schon, wie du mich dazu kriegst.
Beispiel: Spezial:Diff/149296401 – ich habe die URL nicht aufgerufen, sondern frei Schnauze formatiert.
Oft steht da ein passender Dokumenten-Titel drin, und dahinter Reklame für die Website und der Unterpfad zu der betreffenden Seite.
Wenn also trivial, dann einfach ein wenig nett formatieren.
Zwei Bots hatten das vor über fünf Jahren mal verteilt, oder es wurde aus der enWP importiert, und wir haben immer noch bald 2000 von diesen Dingern im Bestand.
Letzter Kommentar: vor 8 Jahren15 Kommentare3 Personen sind an der Diskussion beteiligt
vorher
Nachher
{{Internetquelle
|url=http://www.weihnachts…
|titel=Es Weihnachtet sehr
|autor=Anonymus
|werk=Himmlische Gerichte
|datum=25. Januar 2013
|zugriff=1. November 2013
|sprache=en}}
{{Internetquelle
|url=http://www.weihnachts…
|titel=Es Weihnachtet sehr
|autor=Anonymus
|werk=Himmlische Gerichte
|datum=2013-01-25|zugriff=2013-11-01|sprache=en}}
Hallo PerfektesChaos, sorry nochmal ich, es war mir schon neulich mal aufgefallen, da du aber abwesend warst habe ich es irgendwie dann wieder vergessen dich danach zu fragen. Etwas merkwürdiges passiert durch den Parameter |datum= oder |zugriff=
Ja, die Umwandlung gefällt mir, das nur nebenbei.
Eine Anpassung des Datums oder auch ein schon im gewünschten Format vorliegendes Datum zieht neuerdings nachfolgende Umbrüche und somit die darunter stehenden Parameter oder, je nachdem, schließende Klammern au der Vorlage nach oben, sofern diese untereinander angeordnet sind. Das klingt vermutlich merkwürdig daher mal wieder ‹seufz› eine Tabelle für dich. Sorry, ich wollte dich eigentlich vor Weihnachten nicht mehr stressen. --Liebe Grüße, LómelindeDiskussion14:50, 22. Dez. 2015 (CET)
Innerhalb des Artikelrumpfes soll ohnehin die Kompaktschreibweise benutzt werden. Da bin ich wenig daran interessiert, die Zeilenumbrüche zu halten. Ich könnte sie kennen, wenn ich wollte.
Spannender für tabellarische Darstellungen wäre das Innere von <references>...</references>.
Hier wünsche ich mir mal vom Weihnachtsmann 2016 ein automatisches tabellarisches Layout aller Vorlagen IQ und Lit. Im Prinzip könnte ich sowas heute schon unterstützen; müsste es nur hinschreiben und erproben. Dann natürlich mit standardisierter Reihenfolge der Parameter; zugriff zum Schluss (der 2016/17 abruf heißen würde).
Wie man oben an deiner hübschen Zusammenstellung sieht, wird die längste Zeile ob der dann kurzen codierten Datums- und Sprachangaben nicht allzu lang. Insofern kann man das überleben.
Die Standardisierung der Datums- und Sprachangaben stand übrigens dieses Jahr auf deinem Wunschzettel für den Osterhasen.
Innerhalb der references, ja genau, ich glaube dort war es mir neulich aufgefallen und das machte mich stutzig. Ich füge dir eine neue Spalte ein. Wenn du möchtest werde ich suchen wo das war. Wie schon gesagt manchmal denke ich: ‚ist das jetzt normal, soll das so? Oder ist das ein Fehler, den ich melden sollte‘. --Liebe Grüße, LómelindeDiskussion16:22, 22. Dez. 2015 (CET)
Naja, diesmal war es kein Fehler, nur eine von mir bewusst in Kauf genommene Nickeligkeit. Schaden richtet es nicht an.
Die meisten Einbindungen stehen im laufenden Text; in den references sind sie sehr selten. Oben will ich komprimieren.
Wegen der paar fehlenden Zeilenumbrüche gibt es hoffentlich keinen Zwergenaufstand.
Ich trau mich schon gar nicht mehr nochmals zu schreiben, aber könnte WSTM auch Datumsangaben ohne Punkt berücksichtigen. Es ist mir gerade aufgefallen, dass aus
| datum= 5 April 2014| zugriff= 16 April 2014 nicht auch | datum= 2014-04-05 | zugriff= 2014-04-16 wurde, was ich eigentlich erwartet hatte. --Liebe Grüße, LómelindeDiskussion17:23, 23. Dez. 2015 (CET)
So kurz vor der Bescherung noch Wunschzettel, wo doch der Weihnachtsmann schon längst unterwegs war.
Allerdings eine englischsprachige Notation; 31.247 in der enWP. Letzteres ist ausschlaggebend dafür, dass WSTM mit einer künftigen Version auch denglisch verstehen wird.
Dankeschön du bist wie ein guter Zauberer, der mich auf sicheren Pfaden durch ein scheinbar endloses Labyrinth führt.
Und ich muss irgendwie noch lernen, wie diese Sucheingrenzungen richtig funktionieren. Rund 30 Artikel wären natürlich Peanuts und der Mühe nicht wert.
Warum da dann ausgerechnet mir einer dieser Ausnahmeerscheinungen begegnet ist … mag Schicksal sein. Und eigentlich hatte ich mir wirklich fest vorgenommen dich nicht ständig zu behelligen, damit deine ToDoListe irgendwann auch mal kürzer und nicht ständig noch länger wird.
Hallo PerfektesChaos, ich mache dir schon sehr viel Arbeit, oder?
Vorhin ist mir etwas merkwürdiges aufgefallen, daher hänge ich das hier mit an, es hatte auch wieder mit Datum und Vorlage zu tun, oder eher indirekt, denn ich glaube es war Zufall, dass gleichzeitig ein Leerzeichen entfernt wurde.
Es geht um die {{Personendaten}}, bisher, meine ich zumindest, stand die doppelte Schließung }} unten, also separat. Vorhin nun war sie schwuppdiwupp zum STERBEORT gesprungen. Und zwar hier.
{{Personendaten
|NAME=Einem, Ernst von
|ALTERNATIVNAMEN=Einem, Ernst Friedrich Arnold Karl Georg von (vollständiger Name)
|KURZBESCHREIBUNG=preußischer Generalleutnant
|GEBURTSDATUM=12. Oktober 1856
|GEBURTSORT=[[Herzberg am Harz|Herzberg]]
|STERBEDATUM=6. Mai 1931
|STERBEORT=[[Braunschweig]]}}
Das finde ich etwas unpraktisch zumal ja auch die Kopiervorlage tabellarisch aufgebaut ist … Ich teste mal kurz was passiert, wenn kein Ort angegeben ist. Oups dann kommt das hier |STERBEORT=}} heraus. Ich denke das könnte leichter zu Fehleingaben führen. Ist das so gewollt? Hast du da irgendwo etwas verändert? --Liebe Grüße, LómelindeDiskussion16:35, 29. Dez. 2015 (CET)
Hallo, wenn du es nicht geschrieben hättest, hätte ich mich jetzt dabei gemacht. Also, bei mir auch heute aufgefallen. Schönen Abend --RonMeier (Diskussion) 21:51, 29. Dez. 2015 (CET)
Ich habe deshalb die Auslieferungsfolge der Volksausgabe geändert.
@ Beide
Zurzeit läuft eine Änderungsserie von 8 Einzelprogrammeinheiten durch.
Wenn man alle beisammen hat, ist man geistig gesund und WSTM funktioniert auch wie erwartet.
Ich habe nunmehr eine Version bereitgestellt, die ich im Ablaufplan erst in drei Tagen vorgesehen hatte.
Es kommt jeden Tag ein neues Einzelteil zum Vorkosten und ein bereits zwei, drei Tage unbeanstandet durchgelaufenes Massenprodukt auf den Webserver.
Ich selbst habe alle Bauteile in der frischesten Version am Start, und dann passt es schon wieder zusammen.
Das vorgestern Abend ausgelieferte Stück machte bereits eine schlafende Aktion wirksam, die erst in dem gestrigen Teil auch entsprechend korrigiert wurde; bisher war sie wirkungslos geblieben. Also muss die Normalversion das demnächst in umgekehrter Reihenfolge verfügbar machen als bei euch.
Manchmal wäre es für mich einfacher, wenn ich zumindest wüsste, dass es eine Änderung gab und ich etwas aufmerksamer schauen sollte oder wo eventuell etwas unerwartetes passieren könnte, daher Dankeschön für die Vorwarnung. :-) Nun gut jede Menge Änderungen über Silvester, ich werde wohl ab morgen Mittag erst einmal offline sein und vermutlich dann erst Sonntag oder Montag wieder zur Verfügung stehen. --Liebe Grüße, LómelindeDiskussion12:33, 30. Dez. 2015 (CET)
Ach so, alles klar, ja ich habe geschaut, ob du gestern noch etwas geändert hast nachdem ich das hier gemeldet hatte, aber nicht im Detail was, das würde ich vermutlich sowieso nicht durchschauen. Mich fasziniert es immer, wie du es schaffst diese Teilstücke in Einklang zu bringen. --Liebe Grüße, LómelindeDiskussion13:18, 30. Dez. 2015 (CET)
Autorefklammerung
Letzter Kommentar: vor 8 Jahren12 Kommentare4 Personen sind an der Diskussion beteiligt
Zwei Dinge hätte ich mal wieder
Warum funktioniert meine Refklammerung nicht wenn die Belege im Abschnitt Einzelnachweise stehen. Beispiel: Homerekords Im normalen Fließtext erfolgt eine Ergänzung unten nicht.
Es kann ja nicht an <ref name="irgendetwas"> liegen, denn das steht oben auch dran. Hat das etwas mit den automatisch eingefügten Umbrüchen zu tun?
OT: Warum wird aus „weiterleitung“ nicht immer automatisch „WEITERLEITUNG“. Beispiel WL Manchmal geht es automatisch und manchmal nicht und ich weiß nicht warum das so ist. Ich meine hier erfolgte eine Umschreibung aber dort offensichtlich nicht und ich habe es übersehen, ‹seufz› passiert eigentlich selten, ich versuche immer es umzuschreiben und das Skript nimmt mir da schon viel Arbeit ab, vorher habe ich es immer von Hand geschrieben (Ich kam nicht einmal auf die Idee den WL-Button zu betätigen). --Liebe Grüße, LómelindeDiskussion10:48, 30. Nov. 2015 (CET)
ref
Richtig, es sind die Zeilenumbrüche; die benutzerdefinierte Ersetzung wird erst nach der Standardisierung tätig.
Du müsstest \n? an den geeigneten Stellen einfügen. Die Denksportaufgabe überlasse ich dir. Beachte, dass der Inhalt einer Klammer in ein $1 übertragen wird; werden muss, soll er erhalten bleiben. $1 hatten wir ja grad erst.
Sehr ungewöhnlicher Fall; wer die schon nach hinten ausgliedert, formatiert normalerweise auch anständig.
WL
Es gab da mal jemand, der fand Großbuchstaben absolut hässlich und forderte Bestandsschutz für Weiterleitung.
In Konsequenz wird nur redirect und weiterLeitung umgeschrieben, Weiterleitung aber belassen.
Oh, man Chinesisch wäre vermutlich einfacher. Ich habe jetzt stundenlang gegrübelt ob ich deine Anweisung richtig verstehe. Für mich heißt an den „geeigneten Stellen einfügen“, es gibt mehr als eine und ich soll es nicht einfach nur überschreiben=ersetzen sondern tatsächlich zusätzlich einfügen.
Dafür muss ich aber erst einmal verstehen was da steht:
RTFM and other manuals: öffnende runde Klammer ( = alles was dahinter steht merken also <ref ^ aber nicht <> oder \n = Zeilenumbruch und * = eventuell name= group= > und schließe ref-tag bis die runde Klammer ) geschlossen ist. Danach könnten Leerzeichen folgen * oder auch nicht, falls ja, ignorieren. ,komplette URL, Komma (weiß ich nicht trennt die Anweisung, schließt den Inhalt für die Variable ein?) danach nochmals * Leer ignorieren und ein schließendes </ref>
Zweite Zeile: Setze das gemerkte <ref ref name= oder ref name= group=> wieder ein, dann eine eckige Klammer [ fülle dort ,komplette URL + Domain, hinein und schließe die eckige Klammer ] setzte ein schließendes </ref>
Vielen Dank das ist echt kompliziert immerhin habe ich schon mal die richtige Stelle im Skript gefunden. :-) Aha, darauf zielte also der zweite Hinweis Beachte, dass der Inhalt einer Klammer in ein $1 übertragen wird; werden muss, soll er erhalten bleiben ab. Ich teste mal was passiert. --Liebe Grüße, LómelindeDiskussion13:05, 1. Dez. 2015 (CET)
@Lómelinde: solche Referenzen gehören ohnehin in die Vorlage {{Internetquelle}}, nach Deinem Beispiel oben fehlen nämlich die Titelbezeichnung zum Link, Datum (falls vorhanden) und wichtig auch der Zugriff, die alle näher erläuternd in der Vorlage hervorragend Platz finden. Vielen Dank – Doc Taxon • Diskussion • Wiki-MUC • Wikiliebe?! • 08:46, 15. Dez. 2015 (CET)
Hallo Doc Taxon, nee das mache ich nicht, die Verwendung der Vorlagen Literatur und Internetquelle sind umstritten und werden teilweise rigoros abgelehnt oder meine Formatierungen dann möglicherweise zurückgesetzt. Mir geht es vordergründig dabei darum, dass nicht die manchmal ellenlange url im Artikel als solche sichtbar und zumindest ein Minimum an Formatierung gegeben ist. Ich hatte gerade erst Stress, weil ich in Ref-name-tags die Leerräume eliminiert hatte. Ich kann mich nicht um alle Formate kümmern, irgendwann drehe ich da wirklich am Rad, derartige Erlebnisse sind für mich sehr frustrierend und demotivierend.
Ich komme soweit gut mit dieser Form der Anpassung klar. Das reicht für mich erst einmal aus, wer mehr möchte kann das gern selbst erledigen, aber ich habe nicht vor zusätzlich auch noch jeden Weblink eines Artikels aufzurufen den Titel zu ermitteln zu prüfen, ob der überhaupt zielführend ist und dann das aktuelle Tagesdatum als Abrufdatum einzutragen.
@Lómelinde: Nee, das hab ich ja auch gar nicht geschrieben. Erstens: Was Du mit den Links machst, ist mir egal, ich schreib Dir das nicht(!) vor. Zweitens hab ich nur erläutert, wie das sinnvoller ist. Drittens, liebe Lómelinde, wer hat Dir eigentlich aufgetragen, Dich um alle Formate zu kümmern? Du machst ein Haufen solcher Arbeit, und das ist auch zielstrebig und bewundernswert, und zudem bedanke ich mich auch dafür. Aber bitte überarbeite oder stresse Dich nicht, wir wollen ja nächstes Jahr auch noch von Deiner guten Arbeit profitieren. Ich hatte es letztens schon gesagt, ich finde Deine Arbeit, QS-Arbeit, Aufräumarbeit, hier putzen, da putzen, sehr wichtig, und jetzt hast Du Dir auch mal ein Starlet verdient. Mach weiter so, wir brauchen Dich ... – Doc Taxon • Diskussion • Wiki-MUC • Wikiliebe?! • 09:33, 15. Dez. 2015 (CET)
Ich weiß auch so, wie es vermutlich sinnvoller wäre, (auch etwas subjektives, was ich als sinnvoll ansehe müssen andere nicht ebenso wünschen).
Zitat: „solche Referenzen gehören ohnehin in die Vorlage {{Internetquelle}}“
„Gehören ohnehin“ macht mich halt etwas stutzig, denn ich kenne Benutzer, die das durchaus anders sehen und diese Vorlagen am liebsten eliminieren würden.
Niemand sagt, dass ich das alles tun soll, ich habe es mir selbst auferlegt, und es ist zudem ein echt undankbarer Job sich darum zu kümmern. (nein ich möchte nichts von Eulen lesen, ich bin nicht glücklich damit, auf diese Wartungsarbeit reduziert zu werden)
Gibt es denn eine Möglichkeit diese zeilenweise Aufteilung der Einzelnachweise im EN-Abschnitt auszuschalten? Mir wäre es lieber die komprimierte Darstellung zu behalten sofern sie denn verwendet wurde. --Hadibe (Diskussion) 21:12, 13. Jan. 2016 (CET)
Bei diesen beiden sehr komplexen Zitationsvorlagen (Lit und IQ) mit jeweils 50–70 Parametern wird regelmäßig bemängelt, dass sie äußerst unübersichtlich wären und die Einbindungen völlig unverständlich sind.
Eben deshalb werden diese beiden, und nur diese, übersichtlich zeilenweise dargestellt; und das auch ausschließlich im references-Bereich, wo am Artikelende niemand mehr was rummachen muss und niemand rumscrollen braucht; außer ganz ganz zum Ende des Fensters, wo dann noch Kats und PD kommen. Überflüssige nicht besetzte und selten zu befüllende Felder werden eliminiert, das Ganze standardmäßig durchsortiert.
Letzter Kommentar: vor 8 Jahren8 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo PerfektesChaos, erst einmal wünsche ich dir noch ein erfolgreiches und gesundes möglichst stressfreies, produktives Jahr 2016.
Wenn ich diesen Artikel Assassin’s Creed Syndicate öffne passiert nichts. Also WSTM passt beispielsweise nicht automatisch die |sprache=englisch an und gibt erst nach manueller Aufforderung diese Zusatzinformation preis.
Bitte überprüfe die folgenden automatischen Behebungsversuche.
Vorlagenparameter wiederholt
{{Infobox Computer- und Videospiel|Engine=|Engine=[[Anvil (Spiel-Engine)#AnvilNext|AnvilNext]]}}
Das war der eigentliche Auslöser für meinen Bearbeitungsaufruf. Auch bei anderen Artikeln scheint heute kein Wille zur Unterstützung der Autorin vorzuherrschen. Ich muss beispielsweise erst die Vorschau bemühen ehe mein Button der manuellen Aufforderung nachkommt mir bei David Tennant zu verraten welcher Parameter hier wohl verdoppelt wurde. Argh, Phantome sind unterwegs, es ist nicht bei jedem Öffnen beim zweiten Versuch startete es automatisch. Bei einer anderen Seite habe ich jetzt mal die Konsole aufgerufen. Mir war nämlich heute auch bei den ersten Bearbeitungen so als wenn es nicht immer automatisch anlief aber manchmal ist das ja auch der Normalfall, es gibt ja nicht immer etwas anzupassen.
Info: Ich schreibe dir mal ein Protokoll in meinen Report.
Ich hoffe du musst nicht für 2016 mehr als ein Archiv anlegen. Das fängt in diesem Jahr dort an wo es 2015 aufgehört hat. Sorry, the little bird ist twittering like a waterfall in spring. --Liebe Grüße, LómelindeDiskussion11:24, 4. Jan. 2016 (CET)
Na, die Spezial:Diff/149766971 scheint dann aber doch geklappt zu haben und sieht so aus, wie ich mir das denke.
Es gab gestern Abend ein größeres Update mit 20kB, das ich eben nochmal auf die Lade- und Startprozedur hin gecheckt habe.
TypeError: attempt is undefined
mw.libs.WikiSyntaxTextMod.bb.dating/WSTM.util.date.full()
index.php:1069
Ich weiß grad nicht, welcher Umstand das ausgelöst haben mag, und teste diese 20kB schon eine Woche, aber den werde ich versuchen, heute noch zu erlegen; er liegt innerhalb der 20kB.
Warum es manchmal trotzdem mit derselben Seite ginge und dann fehlschlägt, wüsste ich nicht. Entweder immer oder nie.
Ich bin diese Woche (und die nächste) werktags meist offwiki, gelegentlich einen Abend mal on, und nur irgendwie am WE wikifähig.
Ich habe einen Fix bereitgestellt, der inzwischen angekommen sein müsste.
Es war ein ziemlich banaler Fehler.
Im Report steht es auch klipp und klar:
.date.formal() stellt in Zeile 593 ein Bein.
.date.full() fällt in Zeile 1069 drüber und mag nicht mehr mitspielen.
Von oben nach unten zu lesen.
Also wurde Zeile 593 (ab 591 zwei tiefer) berichtigt; und für genau solche kurzen Zeilen sind diese Diffpages eigentlich gedacht.
Ich hatte das seit mindestens 23. Dezember an realen Artikeln getestet, aber kam nicht auf eine entsprechende Seite. Deshalb lasse ich euch ja vorkosten.
Ja logisch, völlig klar. Es freut mich wenn ich helfen konnte, verstehen muss ich es nicht. Da fehlt noch ein wenig Hintergrundwissen. Es scheint aber wieder weg zu sein, seither hatte ich zumindest keine akuten Problemchen mehr. Außer dass sich gerade eine Seite versucht totzuspeichern, den Tab werde ich mal schließen, da hängt wieder irgendwo etwas im WWW fest. Will sagen gespeichert wurde sie aber die kleine Anzeige im Tab dreht dauerhaft durch. Es ist nicht immer leicht die Phantome von den wirklichen Fehlern zu trennen, wenn man so etwas auch noch dazwischen hat. Dankeschön für die Anpassung. --Liebe Grüße, LómelindeDiskussion14:51, 4. Jan. 2016 (CET)
Upps, sorry, praktisch gleichen Fehler noch woanders gemacht; Fix ist live.
JavaScript ist eine dämliche Sprache, weil man überall alles reinschreiben darf, was man will; dass es schief geht, fällt erst hinterher bei der Ausführung auf. In anderen Sprachen wäre ich sofort angemeckert worden, weil ich einen Pflichtparameter vergessen hatte.
Letzter Kommentar: vor 8 Jahren16 Kommentare3 Personen sind an der Diskussion beteiligt
Ich sollte nicht sagen es läuft schon laufe ich wieder auf.
#redirect [[Sungri Motorenfabrik#Victory Auto Plant Jaju]] [[Kategorie:Abkürzung|JAJU]]
wird zu
#WEITERLEITUNG [[Sungri Motorenfabrik#Victory Auto Plant Jaju]]
[[[Kategorie:Abkürzung|JAJU]]
Und WSTM ermahnt mich mit „Zu viele linke Klammern“, dass ich da nicht drei öffnende Klammern setzen soll. Ich war’s nicht, ehrlich. Aber ich setze die Kat normalerweise noch eins tiefer. --Liebe Grüße, LómelindeDiskussion14:23, 6. Jan. 2016 (CET)
Mitbekommen; werde dem Phänomen nachgehen. Schon seit drei Jahren ohne Beanstandung, muss also außergewöhnlich sein.
Etwas Sonstiges in der gleichen Zeile nach dem Link ging wohl früher überhaupt nicht. WSTM fügt hier offenbar einen Umbruch ein und verzählt sich; möglicherweise tritt dann kein Fehler auf, wenn nicht auch gleichzeitig das Schlüsselwort ersetzt wird.
Wenn ich da jetzt nichts falsch gemacht habe, dann ändert das leider nichts, die Klammer wird noch immer eingefügt. Ja ich habe strg F5 gedrückt, ja ich habe auch zweimal manuell den Cache geleert. Es passiert nur dort wo gleichzeitig ein Pipe in der Kat steht, warum weiß ich nicht.
Warte ich werde eine Testreihe durchführen und dir eine weitere Tabelle schreiben. Es ist etwas merkwürdig je nachdem wie ich es teste, fallen die Ergebnisse unterschiedlich und noch verwirrender aus. --Liebe Grüße, LómelindeDiskussion16:56, 10. Jan. 2016 (CET)
Szenario 1 – ohne WL davor
[[Sungri Motorenfabrik#Victory Auto Plant Jaju]] [[Kategorie:Abkürzung]]
[[Sungri Motorenfabrik#Victory Auto Plant Jaju]] [[Kategorie:Abkürzung|JAJU]]
[[Sungri Motorenfabrik#Victory Auto Plant Jaju]] [[Kategorie:Abkürzung|JAJU]]
nur die im letzten Eintrag erfolgt die Verdoppelung
[[Sungri Motorenfabrik#Victory Auto Plant Jaju]]
[[Kategorie:Abkürzung]]
[[Sungri Motorenfabrik#Victory Auto Plant Jaju]]
[[Kategorie:Abkürzung|JAJU]]
[[Sungri Motorenfabrik#Victory Auto Plant Jaju]]
[[[Kategorie:Abkürzung|JAJU]]
Szenario 2 – gemischtes
#redirect [[Sungri Motorenfabrik#Victory Auto Plant Jaju]] [[Kategorie:Abkürzung]]
#redirect [[Sungri Motorenfabrik#Victory Auto Plant Jaju]] [[Kategorie:Abkürzung|JAJU]]
#WEITERLEITUNG [[Sungri Motorenfabrik#Victory Auto Plant Jaju]] [[Kategorie:Abkürzung|JAJU]]
[[Sungri Motorenfabrik#Victory Auto Plant Jaju]] [[Kategorie:Abkürzung]]
[[Sungri Motorenfabrik#Victory Auto Plant Jaju]] [[Kategorie:Abkürzung|JAJU]]
[[Sungri Motorenfabrik#Victory Auto Plant Jaju]] [[Kategorie:Abkürzung|JAJU]]
nur die im letzten Eintrag erfolgt die Verdoppelung
#WEITERLEITUNG [[Sungri Motorenfabrik#Victory Auto Plant Jaju]]
[[Kategorie:Abkürzung]]
#redirect [[Sungri Motorenfabrik#Victory Auto Plant Jaju]]
[[Kategorie:Abkürzung|JAJU]]
#WEITERLEITUNG [[Sungri Motorenfabrik#Victory Auto Plant Jaju]]
[[Kategorie:Abkürzung|JAJU]]
[[Sungri Motorenfabrik#Victory Auto Plant Jaju]]
[[Kategorie:Abkürzung]]
[[Sungri Motorenfabrik#Victory Auto Plant Jaju]]
[[Kategorie:Abkürzung|JAJU]]
[[Sungri Motorenfabrik#Victory Auto Plant Jaju]]
[[[Kategorie:Abkürzung|JAJU]]
Szenario 3 – ohne WL davor aber mit # davor
#[[Sungri Motorenfabrik#Victory Auto Plant Jaju]] [[Kategorie:Abkürzung]]
#[[Sungri Motorenfabrik#Victory Auto Plant Jaju]] [[Kategorie:Abkürzung|JAJU]]
#[[Sungri Motorenfabrik#Victory Auto Plant Jaju]] [[Kategorie:Abkürzung|JAJU]]
#[[Sungri Motorenfabrik#Victory Auto Plant Jaju]]
[[Kategorie:Abkürzung]]
#[[Sungri Motorenfabrik#Victory Auto Plant Jaju]]
[[[Kategorie:Abkürzung|JAJU]]
#[[Sungri Motorenfabrik#Victory Auto Plant Jaju]]
[[[Kategorie:Abkürzung|JAJU]]
Ich kann es dir nicht nachmachen.
Dem Ergebnis von Szenario 2 entnehme ich, dass du alle gleichzeitig offenbar durch die Spielwiese jagst. Das ist okay; die zweite und dritte Zeile sind dann eben Aufzählungspunkte oder werden zu eigenen Aufzählungen. Soll trotzdem keine Klammern vermehren.
Ja, so teste ich das für Gewöhnlich. Ich wüsste nicht wie ich es sonst probieren könnte, so viele Artikel/Weiterleitungen wird es nicht geben, die einen solchen Fehler erzeugen. --Liebe Grüße, LómelindeDiskussion17:53, 10. Jan. 2016 (CET)
Gesundes Neues euch beiden. Habe alles mögliche ausprobiert, ich kriege die Verfälschung nicht erzeugt. Gruß und viel Erfolg bei der vorösterlichen Suche. --RonMeier (Diskussion) 18:22, 10. Jan. 2016 (CET)
Danke.
Tja, Ló, dann kannste mal der Reihe nach deine Gadgets abschalten, und dafür das mod=false wieder löschen.
WSTM war es diesmal wohl nicht, obwohl das ein durchaus typisches Fehlerbild ist. Sehe ich während der Entwicklung häufiger.
Och nööö, nicht wieder alle Gadgets austesten. ‹seufz›
O.k., ich werde es morgen mal testen wer oder was der Auslöser sein könnte, einen angenehmen Abend wünsche ich euch beiden. --Liebe Grüße, LómelindeDiskussion19:09, 10. Jan. 2016 (CET)
Info: Ich habe alles aber auch wirklich alles ausgeschaltet Fliegelfllagel alle Optionen deaktiviert außer Fliegelflagel selbst, alle Helferlein deaktiviert, Betafunktionen nutze ich auch keine, der Fehler bleibt, was nun? Es kann also nur ein Skriptkonflikt sein, oder? Wie soll ich das testen? --Liebe Grüße, LómelindeDiskussion07:52, 11. Jan. 2016 (CET)
Ich weiß nicht wo ich danach noch suchen könnte auch hier habe ich wieder das merkwürdige Phänomen, dass ich in dem ersten Augenblick wenn ich den Button anklicke zunächst die korrekte Umsetzung im Bearbeitungsfenster sehen kann und erst nach dem Durchlauf die Klammer dort steht. Ich habe auf Bildschirmfoto geklickt um sicherzugehen, dass ich nicht an Halluzinationen leide, definitiv wird zuerst alles ordentlich eine Zeile tiefer gesetzt und erst danach erscheint oben die Fehlermeldung zu viele Klammern und unten steht die Klammer. Identisch ist es auch quasi mit der Ersetzung des Zugriffsdatums, ich sehe sofort dass das Datum und die Sprache geändert werden und erst danach kommt die Meldung prüfe den automatischen Behebungsversuch …. Ich weiß nicht mehr weiter.
Du überforderst mich. WSTM-Ladung auskommentieren, ja wie soll es denn dann noch auftreten, wenn ich WSTM abschalte dann kann ich den Button doch nicht mehr betätigen um es zu testen. Das andere kann ich ausprobieren. --Liebe Grüße, LómelindeDiskussion11:12, 11. Jan. 2016 (CET)
Letzter Kommentar: vor 8 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Mir ist aufgefallen, dass der WSTM <br>s durch <br />s (mit Space) ersetzt. Wäre es möglich, stattdessen eine Ersetzung mit <br/> (also mit Space) durchzuführen? Dies erschiene mir sinnvoll, da beim Quelltextanzeigen dann weniger Umbrüche da wären. Auf das von der Wikisoftware erzeugte HTML hat es keinen Einfluss. Thoughts? MfG --Distelfinck (Diskussion) 00:04, 12. Jan. 2016 (CET)
Es gibt im Gegenteil viele Autoren, die froh darüber sind, dass es an dieser Stelle für die neue Zeile eine „Sollbruchstelle“ im Bearbeitungsfenster gibt, so dass neue Zeilen in der Darstellung auch oft zu einer neuen Zeile in der Quelltextdarstellung führen.
Es gibt sogar eine Reihe von Bearbeitern, die nach dem <br /> nochmals ein Leerzeichen einfügen, wodurch in der Regel dann auch das /> auf der vorangehenden Zeile bleibt.
Der Fehler an sich ist ein doppelter Parameter |zugriff= allerdings mit unterschiedlichem Inhalt. Wenn automatisch angepasst werden sollte, dann aber doch eher auf das jüngste Datum, oder? Hier wird aber nun dem älteren Abrufdatum ein Vorrang eingeräumt und die Parameterdoppelung bleibt zudem erhalten. WSTM sagt mir dazu etwas kurioses
Bitte überprüfe die folgenden automatischen Behebungsversuche.
Vorlagenparameter wiederholt
{{Internetquelle|zugriff=2013-04-07|zugriff=2013-04-07}}
Nicht alles lässt sich automatisch beheben. Bitte kläre die folgenden Probleme von Hand:
Vorlagenparameter wiederholt
{{Internetquelle|zugriff=2016-01-10|zugriff=2013-04-07}}
Vorlagenparameter wiederholt
{{Internetquelle|zugriff=}}
Und alles was passiert ist, ist die Umwandlung von
{{Internetquelle|zugriff=2016-01-10|zugriff=2013-04-07}} in
Der zuletzt kommende Wert hat, wie bekannt, alle Werte überschrieben.
WSTM ist genauso wenig wie die Vorlage darauf vorbereitet, dass dieser Parameter mehrfach vorkäme, und führt dementsprechend auch keinen kalendarischen Vergleich der beiden Werte aus.
So etwas hatte ich bisher noch nie, mich wundert wieso das automatisch überschrieben wird. Du kannst es dir ja mal selbst aufrufen →Vänernbanan Ich meine es anzupassen ist jetzt nicht das Problem, ich habe aber schon gestaunt als ich nach 2016-01-10 suchen wollte und das nun gar nicht mehr im Text stand. Und da kommt man eben, gerade durch die Fehlermeldung ins stolpern. --Liebe Grüße, LómelindeDiskussion16:24, 10. Jan. 2016 (CET)
So nochmal eine kleine Verständnisfrage zu den doppelten Zugriffen.
{{internetquelle | offline=ja | zugriff= 2016-01-17 |autor= |hrsg=ZAMG |url=http://www.zamg.ac.at/klima/klima_monat/wetterlagen/ |titel=Wetterlagen |werk= Klima → Monats-/Jahresübersicht |zugriff=5. Juli 2009 | kommentar= Link nicht mehr verfügbar seit 8/2012 }}
{{Internetquelle | offline=1| zugriff=2009-07-05|autor= |hrsg=ZAMG |url=http://www.zamg.ac.at/klima/klima_monat/wetterlagen/ |titel=Wetterlagen |werk= Klima → Monats-/Jahresübersicht |zugriff=5. Juli 2009 | kommentar= Link nicht mehr verfügbar seit 8/2012 }}
WSTM erkennt dass der hintere Parameter zugriff der wirksame ist und ersetzt damit den vorderen doppelten. (der hintere bleibt allerdings unverändert, das heißt WSTM erkennt zunächst nur den hinteren doppelten Parameter und liest dessen Inhalt aus, formatiert |zugriff=5. Juli 2009 automatisch zu |zugriff=2009-07-05 und ersetzt dann aber den ersten Parameter zugriff den es findet also zugriff= 2016-01-17, weil es nun mal davon ausgeht, dass der Parameter nur einmal vorkommt, richtig?
Anschließend sind beide Parameter quasi mit einem identischen Inhalt gefüllt (5. Juli 2009). Identische Inhalte würde WSTM im Normalfall aber automatisch erkennen und einen oder mehrere löschen also aus |zufriff=2009-07-05|zufriff=2009-07-05 würde |zufriff=2009-07-05. Der nächste Aufruf könnte dazu führen, wenn bespielsweise das Datum schon vorher in dieser Form |zufriff=2009-07-05 vorhanden gewesen wäre, dass diese Doppelung dann automatisch entfernt wird.
Ich denke das kann zu Ungemach führen, weil der Benutzer, der sich die Mühe machte den Link aufzurufen/zu prüfen und korrekterweise ein neues Datum für den Abruf einzufügen, aber eben leider doppelt und vor dem bisherigen Parameter, frustriert wird, weil sein Edit quasi zurückgenommen wird. O.k. ich zumindest reagiere manchmal recht empfindlich und durch den Automatismus wird dieser Revert ja nicht einmal bewusst ausgeführt und natürlich auch nicht deklariert (ja, doch WSTM gibt eine Meldung aus und der Benutzer sollte dem nachgehen). Wie soll der einfügende Benutzer dann reagieren oder verstehen, was er falsch gemacht hatte? Ich bin mit dieser Umsetzung so nicht wirklich glücklich.
OT: By the way: Warum sagst du mir denn nicht, dass ich WSTM auch über den starten kann? RTFM? Nö, ich habe das zufällig gesehen und festgestellt, dass mein kl. Spielwiesenproblem nämlich auch da eine kleine Abweichung von der Normalität aufweist. Wenn man diese aufruft (mit leerer Spielwiese starten), ist der Pfeil nämlich nicht sichtbar, somit geht auch WSTM nicht über diesen Weg zu starten und ebenso nicht über den Button, auch hier folgt einmal „Vorschau“ anklicken, dann passt alles, also Buttonstart funktioniert und WSTM-Eintrag lässt sich über den , der dann auch erscheint, abrufen. Ich käme doch nie auf die Idee dort (auf der Spielwiese) zu schauen, welche Möglichkeiten mir auf über den Reiter zur Verfügung gestellt werden. Aber als ich gerade andernorts die Artikelstatistik benötigte, um etwas zu suchen, und ich weiß, dass diese dort abrufbar ist, wenn man sie aktiviert hat, da sah ich WSTM ist da auch neuerdings, oder schon länger ‹seufz›. Eigentlich wäre es nützlich zu wissen, dass dieser Pfeil weit mehr als nur „Seite verschieben“ anbieten kann, aber ich weiß sowieso nicht wie diese Funktionen dort hinkommen. --Liebe Grüße, LómelindeDiskussion08:24, 18. Jan. 2016 (CET)
Richtig; WSTM weiß nur von einem Parameter, kennt nur einen einzigen Wert für den Datumsparameter, und kann die beiden Angaben nicht voneinander unterscheiden.
Genauer: Wenn beim Antreffen des (in der Textfolge zweiten) Wertes ein zu formatierender Wert festgestellt wird, dann kommt die Aufforderung, das in die Parameterzuweisung geändert zurückzuschreiben.
Nun wird die Liste der Parameternamen durchgegangen. In dieser Liste der Parameternamen wird der Name zuerst da gefunden, wo in der Textfolge das erste Vorkommen gewesen war, und genau dort wird der bisherige Wert überschrieben.
Genauso passiert das auch mit dem in der Textfolge ersten Vorkommen der Zuweisung; namentlich wenn das auch die einzige war.
Es gibt eine pauschale Fehlermeldung, dass ein Parametername doppelt angegeben wurde.
Was das inhaltlich bedeuten soll, welcher der beiden Werte der richtigere sein soll, darüber kann WSTM nicht entscheiden.
WSTM kann man über das Portal starten, wenn .portlet=true gesetzt wurde.
Je nach Skin fällt das unterschiedlich aus.
Wenn du mit leerer Spielwiese starten auslöst, dann bearbeitest du eine frühere Version, zurzeit &oldid=149123850 – WSTM wird aber standardmäßig immer nur auf der neuesten Version tätig und lässt alle früheren in Ruhe. Logisch, oder?
Ja, jetzt wo du es sagst, leuchtet mir das auch ein. Über was für ein Portal? Ich verstehe nicht was portlet meint. Aber ansonsten komme ich klar mit dem was ich habe. O.k. ich kann damit leben. Hatte aber vorhin etwas weit schlimmeres. Espresso diese Version, durch die fehlenden geschweiften Klammern {{LaS|expressus = ausgedrückt, ausdrücklich}}, wurden alle Parameter der folgenden Tabelle mit Nummern versehen, ne anders, jede Pipe bekam einen Zahlenwert zugewiesen, echt jetzt, warum trifft das immer mich? Kann ich auf der Spielwiese aber nun nicht mehr nachbilden da wird WSTM nicht gestartet wenn ich den Inhalt der Version dort einfüge und es kommt eine Meldung
TypeError: WSTM.util.isURL is not a function
Na toll, ich muss da noch mal nacharbeiten, ich habe scheinbar noch eine fehlende Klammerung übersehen. Daher jetzt dann diese Meldung. --Liebe Grüße, LómelindeDiskussion12:57, 21. Jan. 2016 (CET)
Ungültige Domain
TypeError: WSTM.util.isURL is not a function
Das klingt nicht so nett.
Genau daran arbeite ich gerade; ist das immer noch so?
Warte muss ich noch mal testen, ja bei der Version schon und auch wenn ich den Artikel jetzt öffne kommen etliche Meldungen zu ungültigen Domains. --Liebe Grüße, LómelindeDiskussion13:36, 21. Jan. 2016 (CET)
O.k. die ungültigen Domains kommen nicht mehr, aber nach „klick on the Broombutton“ bleibt das Ergebnis rote Meldung in der Konsole. Chache geleert, aber ich denke ich warte lieber noch ein wenig, später mag es dann ja weg sein. Also das habe ich jetzt nicht über die Spielwiese getestet, sondern normal im Artikel beispielsweise hier. --Liebe Grüße, LómelindeDiskussion14:16, 21. Jan. 2016 (CET)
LCCN
Letzter Kommentar: vor 8 Jahren5 Kommentare2 Personen sind an der Diskussion beteiligt
die LoC ändert alle paar Jahre ihre Darstellungsformate (und stellte sich bei der Vergabe ihrer Schlüsselnummern auch extrem bescheuert an, einschließlich millenium bug und konfuser Jahresüberschneidung).
Die Ausgabe und geforderte möglichst einheitliche Parametrisierung zur Auswertung durch templatetiger und Bots etc. folgt dem normalisierten Permalinkusw.
Nebenbei bist du hier bei WSTM gelandet, wolltest mich aber vermutlich zwei drüber fragen; egal.
Ja ein Frohes Neues wünsche ich dir ebenfalls. Nein, ich war hier schon richtig, denn WSTM hat ja das LCCN-Format angemeckert. Deiner Antwort entnehme ich keinen Handlungsbedarf Formate wie "a 53005224" zu unterstützen, richtig? --Cepheiden (Diskussion) 22:04, 15. Jan. 2016 (CET)
Letzter Kommentar: vor 8 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo PerfektesChaos, ruf doch bitte mal Kanye West auf wird da bei dir auch ein Parameter |zugriff= in dieses Zitat eingefügt?
{{"|Ich sehe mich nicht nur als Stimme von mir selbst oder die Stimme der Menschen. Jay-Z ist die Stimme von sich selbst, Talib Kwali [sic] ist die Stimme der Menschen und ich bin etwas von Beidem.|zugriff=}}
An dem Zitat selbst kann das nicht liegen, denn auf der Spielwiese bleibt es wie es ist. Ich stehe mal wieder vor einem Rätsel. Ich hätte sonst vermutet es läge an diesen nowikis im Zitat. Warum passiert immer mir so etwas. --Liebe Grüße, LómelindeDiskussion14:39, 15. Jan. 2016 (CET)
WSTM gab dir allerdings den entscheidenden Tipp; probiere mal die frühere Version:
Tag selbst-verschachtelt <ref>
End-Tag fehlt zum Ende des Textes </ref>
Das <npwiki> (völlig überflüssig, denn wenn da kein Protokoll oder // auf die Klammern folgt, wird es sowieso nicht als Weblink angesehen) ruinierte die Zordnung der Bereiche und das Auffinden des Vorlagen-Endes. Erst nachdem WSTM sich wieder eingekriegt hatte, wurden die zugehörigen Klammern gefunden; der Bereich dazwischen war gesperrt.
Ja ich habe den Hinweis gesehen, und letztlich ja auch darüber den Fehler gefunden, aber zunächst war ich verwirrt. Der Parameter ließ ja vermuten, dass er zu einer Vorlage Internetquelle gehören müsste, nur manchmal sehe ich den Wald vor lauter Bäumen nicht. Normalerweise wird mir durch die Syntaxhervorhebung angezeigt, dass ein schließendes Ref-tag fehlt oder etwas, was eben eine Schachtelung auslöst, aber hier war nichts außerhalb der Ref-tags rosa hinterlegt. Und es muss im Grunde mit den nowiki-tags zusammengehangen haben, denn dazwischen waren weitere Refs und Vorlagen, wie soll man denn das sehen. Der Hinweis hat mich ja auch verwirrt. Es gab da nichts offensichtliches, woran ich das festmachen konnte. Aber ich vertraue darauf wenn das Tool sagt hallo hier stimmt etwas nicht dann suche ich halt weiter. Übrigens wenn diese zweiten nowikis nicht gewesen wären, dann hätte ich das leicht ausfindig machen können, dann hätte das Tool zu mir gesagt.
Letzter Kommentar: vor 8 Jahren6 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo PerfektesChaos, mir ist aufgefallen, dass manchmal die Automatik versagt. Ja, ich weiß generell wird es nur hinter einem einfachen ! am Zeilenanfang ersetzt, aber manchmal schreiben Leute halt alles in einer Zeile und dann habe ich folgendes Dilemma. Also nicht dass es für mich schlimm wäre, ich achte ja darauf, aber andere bemerken es eventuell nicht und dann sieht eine Tabelle möglicherweise nach dem Speichern etwas merkwürdig aus.
prettytable
{| class="prettytable"
! bgcolor="#e0e0e0" align="center" | Jahr || bgcolor="#e0e0e0" align="center" | Name
|-
| 1234 || ABCDEFG
|}
Jahr
Name
1234
ABCDEFG
wikitable
{| class="wikitable"
|-
! style="background:#E0E0E0" align="center"| Jahr || bgcolor="#e0e0e0" align="center" | Name
|-
| 1234 || ABCDEFG
|}
Jahr
Name
1234
ABCDEFG
so sollte es sein
{| class="wikitable"
|-
! style="background:#E0E0E0;"| Jahr !! style="background:#E0E0E0;"| Name
|-
| 1234 || ABCDEFG
|}
{| class="wikitable"
|- class="hintergrundfarbe5"
! style="background:#E0E0E0;"| Jahr !! style="background:#E0E0E0;"| Name
|-
| 1234 || ABCDEFG
|}
Jahr
Name
1234
ABCDEFG
Jahr
Name
1234
ABCDEFG
Möchtest du das so belassen oder kann man irgendetwas tun, um die Überschrift ganz einzufärben? Also irgendwie so
ifclass="prettytable" and linestart = !// loop inline until end of line //than replace ( || ) to ( !! )and ( class="center" ) to ( nothing )and ( bgcolor="#color" ) to ( style="background:#color" )else ignore everything
WSTM weiß nicht so genau, was wann wo im Bereich einer Tabelle liegt.
{|
! Erste Zelle mit {{Vorgelegt||2.Parameter||bgcolor=blue|x=y}} || Zweite Zelle
|-
Was würde dann passieren?
Das ist für automatisierte Rumfummelei zu gefährlich.
Nebenbei ist der Hauptzweck, eines Tages veraltete prettytable aus unserer deutschsprachigen CSS-Definition entfernen zu können. Zumindest weniger schlechte Vorbilder dafür iim Artikelbestand zu haben. Eines Tages auch weniger seit 1998 veraltete HTML-Syntax zu haben ist auch ein Ziel, aber einstweilen machen die Browser das ja noch mit, wenn auch undefiniert ist, wie sich die veraltete HTML-Syntax gemischt innerhalb des ansonsten korrekten HTML auswirkt. Um das umzusetzen braucht es eine vollständige Syntaxerkennung der ganzen Tabelle, und das braucht einen Monat, in dem ich nichts anderes tun würde. Inzwischen macht es die CSS-Syntax bei menschlichen Artikelautoren bekannt, und sie können sich an den Anblick gewöhnen.
Nun ja das mit „|+“ dachte ich mir schon, aber ich hätte erwartet, dass „|- ohne Parameter“ und ohne „|+“ davor ebenso behandelt wird wie kein Pipe. Als geht es nur wenn „!“ direkt auf den Tabellenkopf folgt. muchas gracias señor
Ursächlich ist offenbar das Leerzeichen hinter DOI: – da sollte dieID nach links geschoben werden, aber die2 von vorher blieb mitsamt schließenden Klammerrn hängen.
Danke für die Info; ich werde mich in den nächsten Stunden um einen Hotfix bemühen. Ist dummerweise bereits produktiv.
Ich könnte einen Botbetreiber fragen ob er diese löscht, falls es sich um ungültige Bildparameter handelt, ich wüsste zumindest nicht was das jetzt mit dem Bild machen soll.
Kann WSTM so etwas rausfiltern und als unbekannt markieren oder hat das doch irgendeinen mir nicht schlüssigen tieferen Sinn? --Liebe Grüße, LómelindeDiskussion08:32, 2. Okt. 2015 (CEST)
O.k. ich könnte es auch selbst anpassen, es sind ja nur rund 200 Seiten betroffen.
Dankeschön werde ich mal machen. Es ging mir eigentlich auch nur um den Einbau, aber neugierig wie ich nun mal bin, nee ich wollte schauen, ob das wirklich überall so angezeigt wird, sonst ergäbe ein Einbau ja keinen Sinn, habe ich hier und dort geklickt und das hat dann Fragen aufgeworfen. --Liebe Grüße, LómelindeDiskussion07:14, 4. Okt. 2015 (CEST)
Personen-/ Folgenleiste
Letzter Kommentar: vor 8 Jahren10 Kommentare3 Personen sind an der Diskussion beteiligt
Och nöö, ich also, ich ändere es auch immer auf Personenleiste, weil ich Weiterleitungen nicht mag, aber wenn es denn sein soll, automatisch bitte nur dann wenn die auch wirklich „{{Folgeleiste}}“ heißt. --Liebe Grüße, LómelindeDiskussion10:21, 26. Jan. 2016 (CET)
Das mit den Serien war mir auch so in Gedächtnis, allerdings sehe ich in der Linkliste nur noch Personen. Anscheinend sind diese Artikel weitestgehend mit eigenen Navileisten und -boxen ausgestattet, dass es bald drei Jahre lang niemand gestört hat, dass nur noch die Personenleiste verwendet wird. Na warten wir es ab.
Dort wird gerade in WSTM gebaut; meine momentane Version macht es wieder artig und fein und fügt für die sichere Quelltextbearbeitung noch ein ‎ an den Parameterwert an.
Danke für den Hinweis; mag im Moment auftreten, aber sollte nur Rechts-nach-Links-Schriften betreffen.
Derzeit schicke ich pro Woche fünf Änderungen in die Erprobung; ob sie zumindest größere Probleme auslösen.
@Hadibe: WSTM lernt gerade aramäisch, osmanisch und syrisch als von rechts nach links geschriebene Schriften. Dabei sind die sonstigen Drei-Buchstaben-Kürzel zwischenzeitlich nicht korrekt behandelt worden; gibt sich demnächst wieder und betraf nur die Versuchskarnickel. LG --PerfektesChaos11:41, 27. Jan. 2016 (CET)
Könntest du auch gleich eine Änderung von {{lang-he}} oder {{lang-en}} zu {{heS}} bzw. {{enS}} einbauen? Wahrscheinlich gibt es noch mehr Weiterleitungen. --Hadibe (Diskussion) 17:28, 25. Feb. 2016 (CET)
@Hadibe: Interessant, den Witz kannte ich noch gar nicht.
Kommt aus der enWP, irgendwelche Faulpelze unter den Übersetzern haben diesen Mist relativ kürzlich angeschleppt. Ist nicht sehr verbreitet.
Wurde bereits programmiert; geht dieses Wochenende wohl in die Erprobung.
{{ELSneu}} wird vom WSTM zu {{elS}} umgewandelt. Die Weiterleitung ist aber genau andersherum. Der Zuordung zu den anderen fünf griechischen Vorlagen zufolge sollte {{ELSneu}} bestehen bleiben. --Hadibe (Diskussion) 21:12, 1. Mär. 2016 (CET)
Naja, der Zuordung zu 300 anderen Fremdsprachen zufolge passt das schon so.
Das war eine Aktion von 2006 gewesen, als man mal projektweit mit drei Sprachen hantiert hatte. Damals hatte man noch keine standardisierte Namensschemata für Vorlagen gehabt.
Beim Neugriechischen ist die Sache eindeutig.
Inwieweit das langfristig eine gute Idee ist, sich vier weitere Vorlagen zu leisten, ist eine andere Sache. Problem hier ist, dass es international nur einen Code grc für Mittel-, Alt- und sonstige Varianten gibt.
Es sind eigentlich zu viele Vorlagen, und die Nuancierungen bewirkt man in solchen Fällen eigentlich durch Parameter und nicht durch lauter verschiedene Einzelvorlagen, die gesondert dokumentiert werden müssen. Insgsamt sind es sogar sieben; die Ersteller haben längst den Durchblick verloren. Die Leute, die das mal angelegt hatten, kannten sich aber wohl nicht mit Parametern aus. Statt Optionen für Variationen der Grundvorlage zu setzen, hat man sich immer neue Vorlagen ausgedacht; siehe etwa Vorlage:heS mit Option modern. Aber das ist ein Thema für die nächsten Jahrzehnte und bei mir keine Baustelle mehr für dieses Jahr.
Letzter Kommentar: vor 8 Jahren5 Kommentare3 Personen sind an der Diskussion beteiligt
Hier wird etwas viel weggekürzt. Nicht nur der überflüssige Teil des Links sondern gleich noch der weitere Text dazu. (siehe Abschnitt „Biographische Elemente“) --Hadibe (Diskussion) 12:02, 17. Feb. 2016 (CET)
Also ich würde den generell ganz rauswerfen, weil Links in andere Sprachversionen nicht im Fließtext gesetzt werden sollten. Da sollte eigentlich Jean-Baptiste Cousin de Grainville stehen, damit man weiß, dass der noch keinen Artikel hat. Das nur am Rande. Natürlich sollte das Tool hier nicht alles bis … zum Satzende? herausstreichen.
Ich habe aber mal getestet woran es liegen könnte und bin auf ]s gekommen, setzt man das in die Klammer mit hinein, dann wird das hier daraus
Ich wollte nur mal testen ob das bei mir auch so ist, da sich ja gestern jemand bei mir beschwert hatte, dass ich Leerzeichenlöschungen vor ref-tags zugelassen habe. --Liebe Grüße, LómelindeDiskussion12:22, 17. Feb. 2016 (CET)
Für Verlinkungen in andere Wikis habe ich schon häufig einen <ref>-Link hinter dem Rotlink gesehen (und auch schon selbst gesetzt). Das scheint die nützlichste Methode zu sein, auf Artikel zu verweisen die es eben noch nicht gibt. --Hadibe (Diskussion) 16:52, 17. Feb. 2016 (CET)
Unabhängig davon, ob das inhaltlich erwünscht ist, soll WSTM ja nicht automatisiert irgendwas puttmachen.
Ursächlich ist offenbar, dass gleichzeitig die eckige Klammer hinter das letzte Wort im Linktitel justiert wird, und zuvor eine interne URL in ein Wikilink (unabhängig von der Art des Projekts) gewandelt wurde.
Umpfff. Völlig vergessen, wie ich das vor Jahren gemacht hatte; aber in einem Bereich modernisierungsbedürftiger Baustellen. Das kann ja was werden.
Wenigstens nicht sehr häufig; Programmierung ist unbeanstandet von 2012.
Letzter Kommentar: vor 8 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo PerfektesChaos, schaust du mal bitte wie man verhindern könnte, dass aus
<ref name="GuitarOf"{{Webarchiv|url=[http://www.prestonreed.com/releases/v_instructv.html|text=''The Guitar of Preston Reed'', Klappentext auf dem Videocover, auch im Web abrufbar (en.).|wayback=20150106224506}}</ref>
Das ist ein tag, das halt erst bei > zu Ende ist, und einen korrekten Elementnamen ref verwendet.
Für WSTM und Computer ist nicht zu begreifen, was der Schmarrn soll; das sind keine Menschen.
Es löst allerdings ein halbes Dutzend Fehlersituationen aus, von denen mindestens zwei oder drei in der roten Box landen müssten. Außerdem gibt es ein großes Loch auf der Diffpage.
Nun ja, das dachte ich mir schon, es sah mir aber nach einem Fehler aus, der recht leicht passieren kann, nämlich einfach mal beim Ersetzen mit der Webarchiv-Vorlage versehentlich das Ende mit weggelöscht. Ja natürlich gab es eine Meldung und ein Riesenloch.
Ende des Tag fehlt / '<' …
Element braucht Attribut
<ref />
Da sich ja doch recht viele an der Webinkreparatur beteiligen, dachte ich, könnte so etwas vielleicht des Öfteren vorkommen. O.k., alles klar und noch einen angenehmen Nachmittag. --Liebe Grüße, LómelindeDiskussion15:19, 20. Feb. 2016 (CET)
Problemfall background-color → background
Letzter Kommentar: vor 8 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo PerfektesChaos, es wäre hier mal dringend deine Meinung erforderlich oder eventuell eine Anpassung deines Skriptes. Siehe WP:Fragen zur Wikipedia#Pfeil in sortierbaren Tabellen. Ich weiß nicht ob es ein bug ist, ob man das anpassen kann oder ob das Skript besser diese Anpassung einstellen sollte, was ich nicht wirklich toll finden würde, weil es mir einiges an Arbeit abnimmt. --Liebe Grüße, LómelindeDiskussion08:51, 26. Feb. 2016 (CET)
Letzter Kommentar: vor 8 Jahren6 Kommentare4 Personen sind an der Diskussion beteiligt
Keine Ahnung ob ihr diesen Fall auch mit ins Skript aufnehmen wollt oder ob ihr das wegen des Seltenheitswerts unter den Tisch fallen lasst. Die Tabellenzeilen wurden immer mit einem doppelten Pipe begonnen um einen Platzhalter für die Formatierung zu schaffen. Das Skript schiebt die Pipes aber je eine Zeile nach oben und somit ist die Tabelle hinüber. --Hadibe (Diskussion) 05:29, 4. Mär. 2016 (CET)
Hallo Hadibe, da PC gerade offline zu sein scheint, ziehe ich hier mal eine Zwischenüberschrift ein, da geht es ja auch eher um ein allgemeines Phänomen, oder? Das war ja nicht explizit etwas, das mit der Umstellung von Pretty- auf wiki- zu tun hat. Nur damit es nicht in diesem Chaos untergeht was ich hier immer fabriziere. --Liebe Grüße, LómelindeDiskussion08:57, 5. Mär. 2016 (CET)
Ich kann das Problem nicht reproduzieren.
Könnte es auf selbstdefinierte Regeln zurückzuführen sein?
Ich habe soeben die alte Version in meine Spielwiese kopiert und WSTM rüberlaufen lassen. Bei mir gibts keine derartige Veränderung. Schönen Abend auch. --RonMeier (Diskussion) 20:58, 5. Mär. 2016 (CET)
Ich habe es gefunden. Schuld ist eine Eigenkonstruktion in der commons.js die eigentlich das Abschlusspipe in den Wahldiagrammen wieder in Ordnung bringt. Das klappt dort auch, nur eben bei dieser Tabelle nicht.
Mit ihr meinte ich PerfektesChaos und Lomélinde, da ihr beide anscheinend maßgeblich am Prettytable-Umbau beteiligt warr. --Hadibe (Diskussion) 14:56, 7. Mär. 2016 (CET)
Ziffern in japanischen Titeln belassen?
Letzter Kommentar: vor 8 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Sie können nicht von allen Lesern gesehen werden; viele bekommen nur Rechtecke.
Teilweise sind ganze Titel oder aber einzelne Zeichen in laufenden Texten irrtümlich oder aus Spaß an lustigem Design aus CJK gesetzt worden, obwohl normale Zeichen genügen würden.
Damit werden oft Titel in J-Pop oder K-Pop völlig sinnlos versaut, obwohl in Wirklichkeit dort nur Englisch steht.
WSTM ersetzt Sequenzen aus ASCII-Zeichen in CJK-Kodierung.
Wer im genannten Artikel keine CJK-Zeichen sehen kann, bekommt immerhin einen Eindruck und verstreute ASCII-Sequenzen.
„bestimmte Ersetzungen zu deaktivieren“
Nein; die automatische Grundausstattung ist nicht konfigurierbar.
Du kannst nur deine persönlichen Extra-Ersetzungen einführen.
In der automatischen Grundausstattung etwas individuell zu deaktivieren wäre auch wenig sinnvoll, weil der nächste WSTM-Bearbeiter es ohnehin umstellen würde.
Die individuelle Konfiguration von WSTM ist ohnehin schon komplex genug; damit kommen nur wenige klar. Noch mehr theoretisch vorstellbare Features gefährden nur die Robustheit, und ich würde es auch gern noch verstehen.
Letzter Kommentar: vor 8 Jahren9 Kommentare3 Personen sind an der Diskussion beteiligt
Hallo PerfektesChaos, wäre es in eindeutigen Fällen möglich so etwas | datum=2013-19-05 | zugriff=2013-27-06 automatisch umzudrehen? Ich habe es eben mal wieder fast übersehen.
Ich hätte noch etwas, was auch da hineinpasst und hin und wieder passiert | datum=2013-05.19 – manchmal wird, warum auch immer, ein Punkt statt eines Strichs gesetzt, was dann einen zumeist leicht aufzuspürenden →Skriptfehler erzeugt. --Liebe Grüße, LómelindeDiskussion10:40, 7. Mär. 2016 (CET)
Nein; für WSTM ist das nicht eindeutig genug, und vollautomatisch hier auch durch Bots dran zu drehen wäre nicht verantwortbar.
Es richtet ja keinen Schaden an, wenn du so eine Gemeinheit unter den bestehenden Werten übersiehst.
Was wie Febuar für Menschen eindeutig aussieht, ist es für Software mitnichten. Es muss ja der Sinn in seiner Gesamtheit und den diversen akzeptierten deutsch- und englischsprachigen Formaten erstmal erkannt werden.
Hier müsste ein Mensch auch die Plausiblität in Verbindung mit der gesamten Zitation prüfen.
WSTM weiß sehr wohl, dass da was nicht hinkommt, macht aber zurzeit nur diskret die Vorbereitung der Trivialfälle; auch, um alle Benutzer an den Anblick des ISO-Formats zu gewöhnen. In erster Linie wird Vorlage:IQ glattgezogen.
Irgendwann (Vorlage:Lit vielleicht schon nach Ostern 2016) werden alle Nicht-ISO für Sichter markiert und alle absolut falschen (nicht interpretierbaren) in Kategorie:Wikipedia:Vorlagenfehler/Parameter:Datum einsortiert; die können dann von Newbie-Wartungsameisen verputzt werden.
Skriptfehler wird meine Technik dann nicht mehr auslösen, da sie Formatfehler von vornherein unterstellt; die bisherigen Programmierungen hatten sie nicht antizipiert und nicht abgefangen.
Ich habe noch eine klitzekleine Frage, wäre es eventuell möglich, dass du für mich eine kleine Routine schreibst, die in der Vorlage:Literatur einen Parameter |Jahr= durch |Datum= ersetzt, wenn dort mehr als eine Jahresangabe steht. Also konkret meine ich so etwas.
Oder müsste da besser die Vorlage angepasst werden, denn so herum {{Literatur | Autor=Anonym | Titel=Beispieltitel | Jahr=2. Mai 2013}} gibt es kein Problem →Anonym: Beispieltitel. 2. Mai 2013..
Doch das ist ja das kuriose, es gibt sowohl Datum als auch Jahr, Monat, Tag, ich weiß gerade nicht was passiert wenn ich beides einsetze. {{Literatur | Autor=Anonym | Titel=Beispieltitel | Jahr=2013| Datum=2014-12-01}}, aha, da hat das Jahr den Vorrang ohne Jahr Anonym: Beispieltitel. 1. Dezember 2014.. Ich habe mich schon oft gefragt wer sich das
Hallo RonMeier, ich weiß mal wieder nicht, wie man da genau suchen muss aber hier ein paar Beispiele so oder so auf jeden Fall gibt es das recht häufig dafür, dass du sagst die Vorlage kenne diesen Parameter gar nicht. --Liebe Grüße, LómelindeDiskussion15:34, 7. Mär. 2016 (CET)
Auch das wird es nicht als Automatismus geben.
Der Parameter Literatur|Datum= mit vollem Tagesdatum ist ausschließlich für Tageszeitungen usw. vorgesehen.
citoid@VisualEditor gibt das auch oft für Bücher zurück, die angeblich alle am 1. Januar (gesetzlicher Feiertag) erschienen sein sollen.
Es ist menschliche Aufgabe, einzuschätzen, ob für diese Publikation überhaupt ein Tagesdatum legitim ist.
Es ist ein undokumentiertes Feature, das alternativ zu Jahr=Monat=Tag= eingesetzt werden kann. Hintergrund ist die Angleichung zur Zitation per V:Iq, die ja auch date= kennt. Der zukünftigen Lua-Programmierung ist es einerlei; tendenziell wäre langfristig Datum= zu bevorzugen, weil in Zukunft auch 2016-03 ein legitimes Format für diesen März wäre. Bei alter Vorlagenprogrammierung hatte man Schwierigkeiten gehabt und das auf einzelne Parameter aufgeteilt.
Die Falschzuweisung bei einer Jahreszahl wird zukünftig Meldung sowie Wartungskat für ungültigen Parameterwert auslösen.
Vollautomatisches Rumwirtschaften durch WSTM für alle Benutzer ist nur in eindeutigen Fällen möglich.
Ja doch, deshalb schrieb ich „für mich“, nicht für alle. O.k. ich danke vielmals, damit habe ich für heute wohl genügend von deiner Zeit beansprucht. Manchmal wünschte ich, ich könnte so etwas doch selbst umsetzen. --Liebe Grüße, LómelindeDiskussion16:30, 7. Mär. 2016 (CET)
Paragraphseperator?
Letzter Kommentar: vor 8 Jahren7 Kommentare3 Personen sind an der Diskussion beteiligt
Ich weiß nicht ob es sich lohnt da etwas zu machen, das wird vermutlich selten sein, aber das sieht etwas unschön aus. Ich habe es aber zufällig gesehen und da ein Umbruch im Titel in dieser Vorlage leider Auswirkungen hat, dachte ich ich schreibe es mal mit auf. --Liebe Grüße, LómelindeDiskussion10:42, 8. Mär. 2016 (CET)
Ich kann hier überhaupt nichts weiter machen. Es ist ein line separator hinter jedem Wort gewesen, also ein Zeilenumbruch.
Du kannnst dich an Krd oder Aka wenden und zumindest eine Grundbereinigung bei knapp zwei Millionen Artikeln organisieren. Bei deren Abarbeitung käme niemand unvorbereitet drauf, und danach wäre erstmal Ruhe.
Ähm ja o.k. auch wenn ich jetzt nicht so ganz genau weiß, wie du das meinst. Ich könnte sie doch besser hierher rufen, vielleicht ist das einfacher, als wenn ich versuche ihnen etwas auf meine etwas laienhafte Art zu erklären, was ich selbst nicht wirklich treffend bezeichnen kann. Mir wurde „Paragraph-Separator“ angezeigt, als ich mit der Maus über das komische kleine Rechteck in der Diffpage gegangen bin. Ich frage mal. @Krd, Aka: könnt ihr eventuell irgendetwas machen? --Liebe Grüße, LómelindeDiskussion14:03, 8. Mär. 2016 (CET)
Ich kann es mir irgendwann mal anschauen, wenn es mir jemand irgendwo sinnvoll notiert. --Krd14:15, 8. Mär. 2016 (CET)
LRM sind ein eigenes Geschäft; sie sind häufig und im Anschluss an eine mehr oder weniger unmittelbar vorangehende hebräisch-arabische Textsequenz sinnvoll.
U+2028 LINE SEPARATOR und U+2029 PARAGRAPH SEPARATOR
@Lómelinde: Na gut, das da oben mag paragraph separator gewesen sein; WSTM behandelt beide gleich.
U+2062 INVISIBLE TIMES
U+FEFF BYTE ORDER MARK / ZERO WIDTH NO-BREAK SPACE (außer in asiatischen Textsequenzen)
Kuriose Leerzeichen, ausgenommen auf dem zuständigen Fachartikel darüber, stören die Auffindbarkeit bei der Suche und schießen alle Skripte und Tools ab:
U+2002 EN SPACE
U+2003 EM SPACE
U+2004 THREE-PER-EM SPACE
U+2005 FOUR-PER-EM SPACE
U+2006 SIX-PER-EM SPACE
U+2007 FIGURE SPACE (höchstens in der Vorlagenprogrammierung)
U+2008 PUNCTUATION SPACE
U+200A HAIR SPACE
U+200B ZERO WIDTH SPACE
Ggf. weitere.
Die Abarbeitung muss manuell durch nervenstarke Fachkräfte erfolgen. WSTM kann den automatisierbaren Part übernehmen. Jeder Einzelfall muss menschlich beguckt werden, ob ggf. ein alternatives Syntaxkonstrukt, eine Vorlage oder nix benötigt wird.
Letzter Kommentar: vor 8 Jahren9 Kommentare4 Personen sind an der Diskussion beteiligt
Hallo PerfektesChaos, schaust Du Dir bitte einmal das Verhalten von WSTM im Bereich der Normdaten bei dieser Änderung an? Ist die Änderung von der gewohnten Großschreibung in eine für mich nun ungewohnte Kleinschreibung von Vorlage:Tp oder Vorlage:Tn gewünscht? Dem Link selber scheint die Schreibweise egal zu sein, er funktioniert :-) Vielen Dank fürs Nachschauen und liebe Grüße --Silke (Diskussion) 21:49, 8. Mär. 2016 (CET)
Vorlagen mit zwei Buchstaben im Namen, deren zweiter ein Kleinbuchstabe ist, sind bei uns zunächst mal grundsätzlich für Sprachcodes gemäß ISO 639 reserviert.
Dementsprechend wäre es bei tn die Tswana-Sprache; tp wurde bislang nicht vergeben.
Um nun den Wiedererkennungswert von beispielsweise ar zu erhöhen, werden alle Vorkommen, auch im großen Seitentitel und den Beispielen, einheitlich mit beiden Kleinbuchstaben wiedergegeben (klappt bloß in der Kat-Auflistung nicht).
Vorlage:tnS setzt das konsequent für tn um; S meint: zeige ein Link auf den Sprachnamen. Eine Notwendigkeit für eine isolierte Sprachvorlage gibt es hier – anders als bei Vorlage:ar mit Schreibrichtung von rechts nach links und Transskriptionen – nicht. Falls es sie geben müsste, würde die vielhundertfache Sprachsystematik die Tn verdrängen.
Damit jetzt die Kleinbuchstaben des Sprachcodes im Artikel-Quelltext ebenfalls gut mit der ISO 639 assoziiert werden können, schreibt WSTM bei allen den ersten Buchstaben klein. Beim ersten Buchstaben ist für die Funktionalität die Groß-/Kleinschreibung egal.
Nebenbei ist das Auftauchen von Tn und Tp im ANR etwas unvermutet, so dass ich nicht erwartet hätte, dass WSTM mit ihnen in Kontakt käme.
Lieber PerfektesChaos, aha, der Sprachcode ist Schuld. Danke einmal wieder für die tolle und umfassende Erklärung. Auch wenn die Änderung keinerlei Auswirkung auf die Vorlage hat, werde ich in Zukunft darauf achten diese Änderungen von WSTM wieder zu korrigieren. Vielleicht schaffst Du es irgendwann ja einmal, WSTM zu erklären, dass der Gebrauch dieser Abkürzungen innerhalb der Normdaten in Ordnung ist. Nochmals Danke und herzliche Grüße Silke (Diskussion) 21:59, 9. Mär. 2016 (CET)
Hm* also um es deutlicher zu sagen, die Sprachcodes haben Vorrang, da "können" die Normdaten-Templates mal ganz schnell (zwangsweise) einen anderen Namen erhalten. Ich plädiere hier für ein rejection. Stattdessen würde ich für eine völlige Großschreibung dieser plädieren, allein schon da es sich jeweils um 2 Buchstaben zweier Substantive handelt. ↔ User: Perhelion22:53, 9. Mär. 2016 (CET)
Hallo @Perhelion:, ach Du Schreck, danke für die klaren Worte! Perfektes Chaos hat zwar oben vermerkt, dass zwei Buchstaben den Sprachcodes vorbehalten sind, die Tragweite war mir jedoch nicht bewusst. Verstehe ich es richtig, dass die beiden Vorlagen Tn und Tp überhaupt nicht im Artikelnamensraum verwendet werden dürften, eventuell sogar nicht einmal auf Diskussionsseiten bzw. Funktionsseiten? Und schon entsteht die nächste Frage: auf welcher Diskussionsseite/Funktionsseite müsste über eine Korrektur dieser beiden Vorlagen (die bereits seit 2010 existieren und ca. 900 WP-Artikel betreffen) diskutiert werden? Ich betrete hier mal wieder Neuland und wäre über beratende Unterstützung dankbar. Liebe Grüße Silke (Diskussion) 14:34, 10. Mär. 2016 (CET)
Hallo Silke, wenn das geändert werden müsste, dann denke ich könnte das ein Bot erledigen.
Ich verwende es auch gern, weil man dadurch innerhalb der Normdaten einen direkten Link zu dem entsprechenden zumeist ja doppelt vorhandenen Eintrag setzen kann. Das erleichtert mir die Kontrolle. Ich habe mich eigentlich nie wirklich gefragt was diese Abkürzung eigentlich bedeutet, oder anders wofür das „T“ steht, ich dachte mir vermutlich für Typ also Typ-Name Typ-Person.
So wie ich das sehe gibt es derzeit 674 × REMARK=tp und 409 × REMARK=tn vielleicht auch mehr ich bin nicht ganz so gut in der Erstellung dieser Suchabfragen. So etwas könnte ein Bot ziemlich leicht finden und ersetzen, denke ich. Falls eine Änderung beschlossen würde, müssten zunächst einmal die Autoren von der Umbenennung in Kenntnis gesetzt und natürlich auch ein assoziativer Name für die Vorlage gefunden werden.
Wo diskutieren, hmmm ich würde vorschlagen in der →Vorlagenwerkstatt.
Ob diese Vorlagen überhaupt innerhalb der Vorlage Normdaten stehen dürfen, weiß ich allerdings auch nicht, sollte es aber der Fall sein, dass es unzulässig ist, so müsste die Dokumentation da mal angepasst werden. Wie gesagt ich finde es recht praktisch.
Schwieriger wäre es wohl es hier →Wikipedia:PND/Fehlermeldung umzustellen, da haben sich ja viele an diese Kürzel gewöhnt. Einfach nur umbenennen wird also vermutlich zu Problemen führen.
Ich finde es aber nicht sonderlich schlimm wenn Tp und Tn von WSTM in tp und tn umgeschrieben wird. Es hat ja keine funktionale Auswirkung. Ich rufe noch mal den Befürworter einer Zwagsumbenennung. Perhelion, wie stellst du dir so etwas vor ohne dass dadurch größere Probleme entstehen? --Liebe Grüße, LómelindeDiskussion12:05, 11. Mär. 2016 (CET)
WSTM ist ja nicht bescheuert und hat auf meiner Festplatte schon vor ein paar Tagen erstmal einen Sonderweg für Tn/Tp bekommen.
Dass sie überhaupt im ANR auftreten können, war seinem Herrchen nicht bewusst; hier stehen sie aber auch nicht im Artikeltext, sondern irgendwie ausgeblendet in einem Kästchen untendrunter.
Handlungs- und weiteren Diskussionsbedarf gäbe es erst in dem Moment, in dem eine verdrängende Fremdsprachenvorlage für tn oder tp auftreten würde.
Da tp von der ISO 639 bisher nicht angefasst worden ist und nur Vorlage:tnS aktiv ist, gibt es einen zart unsystematischen Bruch in der Namensgebung, weiter im Moment nix.
O.k. vielen Dank für die Erklärungen. Ich hatte es nur irgendwo mal in einem Artikel gesehen, dass da „tp“ als Parameter stand. --Liebe Grüße, LómelindeDiskussion18:21, 11. Mär. 2016 (CET)
Hallo Hadibe, ich vermute wegen des falsch platzierten Leerzeichens Beleidigung ]dar. daher wird daraus auch Beleidigungdar was für eine tolle Wortschöpfung. Da WSTM hier versuch aus den Weblink einen Wikilink zu generieren wird automatisch, das was nach einem Pipe und anschließend auf eine schließende einzelne Klammer folgt mit in den Wikilink integriert und durch zwei schließende Klammern beendet. Der Rest ist eine unschöne Nebenwirkung, die wohl nach einem Zeilenumbruch sucht. Wäre da noch mehr Text ohne Umbruch gewesen, so wäre auch dieser spurlos verschwunden. Leider gibt das Tool hier keine Meldung aus: Achtung: „Weblink lässt sich als Wikilink darstellen. Bitte prüfe den automatischen Anpassungsversuch“ oder so, damit man gezielt schauen kann. --Liebe Grüße, LómelindeDiskussion09:30, 2. Mär. 2016 (CET)
WSTM ist offlinefähig und kann auf einem Server einen Dump ohne Onlineverbindung und Browser und fremde Software verarbeiten. LG --PerfektesChaos15:57, 8. Mär. 2016 (CET)
Info: Irgendwo scheint der Wurm drin zu sein auch bei mir funktioniert manches nicht und ich bekomme heute TypeError: WSTM.w.link is undefined ich teste es spräter noch mal genauer. Eigentlich wollte ich eine halbautomatische Umstellung von cite web → Internetquelle nutzen, das ist nützlich bei den Toolübersetzungen, weil ich dann besser sehen kann ob ref-name tags doppelt mit Inhalt belegt sind und ich dann auch das Datumsformat automatisch eindeutschen kann. Nur heute streikt WSTM und lässt mich im Regen stehen. Bis später. --Liebe Grüße, LómelindeDiskussion15:21, 11. Mär. 2016 (CET)
TypeError: WSTM.util.isArray is not a function index.php:1662:17
Heute hatte ich zweimal Anlaufprobleme beim Öffnen der Seiten. Ich weiß, dass da Formatierungsaufträge für das Tool vorhanden sind, also erwarte ich einen WSTM-Anlauf.
Beispiel ich komme von der VG und klicke auf Bearbeiten, nix, im zweiten Versuch, also nochmal zurück zur VG und wieder über Bearbeiten hin, klappt es dann.
Diff wird aufgebaut, eine Meldung habe ich zwar nicht, aber es gibt eine Menge unformatierte Weblinks … daher musste WSTM auch anlaufen.
Mag sein da gibt es Probleme mit der Serververbindung, weil ich recht zeitgleich heute auch WikimediaErrors (Seite kann nicht angezeigt werden) hatte oder es gibt ein Problem mit dem anderen Tool, das mich immer an alle Fehler erinnern soll, denn das (Referenzfehler: Ungültiges <ref>-Tag; kein Text angegeben für Einzelnachweis mit dem Namen SinglesUSA.) ist der eigentliche Grund für den Aufruf auf der Seite. Da schaue ich zunächst in die Versionsgeschichte, ob ich eventuell einen Inhalt in der Vorversion finden kann.
Vermutlich sind da wieder Phantome unterwegs. Mir ist auch ein Strich (----) abhandengekommen, ich bin mir ziemlich sicher, dass er vorgestern noch in dem Kasten oben auf der BEO war, aber nun ist er weg. --Liebe Grüße, LómelindeDiskussion10:01, 24. Mär. 2016 (CET)
Aja, bei mir scheint sich dies wieder verflüchtigt zu haben, obwohl nun die Verarbeitungszeit von WSTM sich merklich erhöht zu haben scheint. Evtl. hatte dies auch etwas mit dem zeitgleichen Ausfall der Edittool-Bar (auf Commons und anderen Wikis) zu tun. Ursache war hier eine Erhöhung der JavaScript-Restriktion (allerdings nur etwas mit charinsert und inline event handler) was für den Anwendungsprogrammierer erst mal nicht so schön scheint (wurde dann auch rückgängig gemacht vgl. mw:Requests for comment/Content-Security-Policy). Wie gesagt ist das nur ein vager Verdacht. ↔ User: Perhelion16:45, 24. Mär. 2016 (CET)
Hallo Perhelion, ich habe halt ab und an mal merkwürdige Meldungen. Nur sind Phantome so leicht flüchtig. Ich habe es nur aufgeschrieben, weil es ja die selbige Fehlermeldung war, wie bei dir. Vielleicht war es Zufall, vielleicht ist es aber auch ein wirklicher Fehler und ich muss mir merken wann oder wie ich zu dem kam. Ich wünsche dir/euch angenehme Ostertage. --Liebe Grüße, LómelindeDiskussion16:57, 24. Mär. 2016 (CET)
Also bei mir sind die Fehler wieder Dauerzustand, ich muss die Seiten 2-3 laden damit WSTM anspringt und ich habe extra schon ein kleines Msg-Fenster eingebaut das mir bestätigt wenn WSTM fertig geladen wurde (was meistens positiv aufpoppt, manchmal beim ersten Mal nicht). Da es sich augenscheinlich (wohl ausschließlich) um redundante jQuery-Funktionen handelt, könnte man nicht einfach eine (Fallback-) Weiche einbauen die erkennt ob jQuery da ist oder nicht!? VG ↔ User: Perhelion12:15, 31. Mär. 2016 (CEST)
Hallo PC/ihr, ich wollte mich abschließend noch mit einem positiven Feedback der letzten Woche zurückmelden. PC hatte wohl recht, ich habe nun ein trigger-Event eingebaut, was allerdings die Methode meiner Einbindung (quasi über 3 Seiten) noch komplizierter erscheinen lässt (augenscheinlich sind jegliche Ladeprobleme weg, allerdings habe ich auch fast die komplette Config von RonMeier übernommen/okkupiert, was sich auch auf eine zweckmäßigere Ladezeit – sprich Reihenfolge ausgewirkt haben könnte. Ggf kann man sich ja mit Tipps gegenseitig kurzschließen, da mir doch so das ein oder andere aufgefallen ist, bei der Größe ist Fehlersuche/Optimierung guter Rat). Danke noch mal an Dir/euch, einen schönen Wochenstart. LG ↔ User: Perhelion14:22, 18. Apr. 2016 (CEST)
Tabellen-Syntax für Kenner
Letzter Kommentar: vor 8 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo PerfektesChaos,
da ich ab und zu und wahrscheinlich nicht selten (da womöglich Rückstände von prettytable), inline-Formatierungen der Tabellen-Köpfe sehe (in wikitable, die dieser soweit nahe identisch sind, daher überflüssig), dachte ich mir, wäre eine WSTM-Regel dafür ganz praktisch. Nun wird diese wohl etwas aufwendiger und auch nicht unspeziell, daher wollte ich erst mal den Ideen-Ansatz hier festhalten (und ggf. dann folgend als benutzerdefinierte Regel postulieren!?). Händisches Praxisbsp.: Spezial:Diff/152844793 LG ↔ User: Perhelion11:18, 1. Apr. 2016 (CEST)
Die Konstrukte und optischen Resultate sind zu vielfältig, als dass WSTM dort ohne größeren Analyseaufwand automatisierte Ersetzungen machen würde.
Ich selbst arbeite händisch mit externem Editor und einem vorbereiteten Satz an dortigen Ersetzungsregeln.
Ich transformiere dabei auch nicht zwingend 1:1, sondern gebe dem eine möglichst kürzere und modernisierte Fassung.
Nur eine Angabe von border= (egal mit welcher Zuweisung) schmeißt WSTM konsequent bei prettytable und wikitable raus.
Letzter Kommentar: vor 8 Jahren7 Kommentare2 Personen sind an der Diskussion beteiligt
(2×) Tag mit unbekanntem Attribut
<syntaxhighlight highlight=...>
Das Attribut ist in dem Fall scheinbar erforderlich es hebt zusätzlich eine Zeile im durch Syntaxhighlight eingefärbten Text hervor. So als wenn man es mit einem Textmarker anstreicht. Ich möchte es lieber nicht entfernen.
Beispiel (Liste von Hallo-Welt-Programmen/Assembler):
stringBYTE"HalloWelt!",#a,0 % auszugebende Zeichenkette (#a ist ein Zeilenumbruch,%0schließtdieZeichenketteab)MainGETA$255,string%AdressederZeichenketteinRegister$255ablegenTRAP0,Fputs,StdOut%Zeichenkette,aufdiemitRegister$255%verwiesenwird,nach''StdOut''ausgeben(Systemaufruf)TRAP0,Halt,0%Prozessbeenden
WSTM fehlte schlicht ein Gleichheitszeichen in der Syntaxbeschreibung.
Damit wäre der Parameter alleinstehend erkannt worden (so wie inline), aber die Wertzuweisung war nicht deklariert gewesen. Ohne Wertzuweisung ist die Angabe jedoch sinnlos.
Morgen müsste alles wieder gut sein.
Warum so verzagt? Mehr Selbstbewusstsein. Auch WSTM und ich haben und machen Fehler.
Ich bin nicht verzagt nur irgendwie fühle ich mich unsicher. Ja Fehler haben und machen wir wohl alle.
OT:
Vorhin hatte ich etwas merkwürdiges, gehört zwar nicht hier hin aber als ich eine Vorlage BibISBN/0720422523 zur Bearbeitung geöffnet habe, da war plötzlich die Citoidbox geöffnet und mit ??? gefüllt, ganz ohne, dass ich etwas gemacht habe. --Liebe Grüße, LómelindeDiskussion10:41, 6. Apr. 2016 (CEST)
citoidWikitext erkennt Vorlage:Bib und springt (eigentlich unerwartet) an.
Die ??? sind unhübsch; ich weiß auch grad den Kontext nicht mehr, weil an dieser Stelle der letzte Sommer ausgebrochen war und bei >30° mein Hirn in Kochwäsche überging.
Whitespace ist eine Scherz-Sprache, die genau diesen Effekt ausnutzt, weil jeder gute Texteditor sie bei der Abspeicherung wegen überflüssiger Leerzeichen am Zeilenende löscht.
Du kannst nur den Quellcode-Block aus einer oldid-Version dieses Abschnitts wieder reinkopieren.
Letzter Kommentar: vor 8 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo PerfektesChaos, ich hoffe ich nerve nicht, aber da ich gerade ein Versprechen einlöse und für einen netten Bekannten ein paar kleine Fehler behebe, die mit der ISB-Nummer im Zusammenhang stehen, hier die Frage(n).
Was ich gesehen habe ist, dass WSTM durchaus erkennen kann, wenn eine ISBN 3–7688–1546–3 mit Halbgeviertstrichen im Text steht. Probleme tauchen auf wenn hinter der Nummer ein Halbgeviertstrich erscheint oder nach einem abschließenden Punkt eine Zahl folgt.
WSTM ist dazu da, anders als MediaWiki auch falsch formatierte ISBN zu erkennen und zu korrigieren.
Deshalb betrachtet WSTM alle Punkte, alle Arten von Leerzeichen und alle Arten horizontaler Striche im Zusammenhang mit den Ziffern als nicht vorhanden.
Dementsprechend akzeptiert WSTM die Folge ISBN 3 7688.15463 mit 1000 Bildern als gültig und formatiert sie um.
Nach einer ISBN können und dürfen nur Schlusspunkt, Komma oder Semikolon stehen; anschließend wird ggf. S. erwartet.
Dementsprechend versteht WSTM nicht, was mit ISBN 3768815463. 1998 gemeint sein soll. WSTM hat keine Möglichkeit zu unterscheiden, ob das eine falsche Zahlenangabe wäre, ein Tipp- oder C&P-Fehler ist oder inhaltlich irgendwie anders interpretiert werden soll. WP:ZR entspricht es nicht.
Auch die anderen benannten Fälle wären ggf. keine interpretierbare Formatierung und ohnehin ungültig.
Manchmal verwirrt mich das Tool doch sehr, verstehen tue ich das nicht. Ich brauche eh nur eine der beiden Nummern, es ist sicherlich nicht bis gemeint. --Liebe Grüße, LómelindeDiskussion11:56, 7. Apr. 2016 (CEST)
Ein Bug?
Letzter Kommentar: vor 8 Jahren17 Kommentare4 Personen sind an der Diskussion beteiligt
Hallo RonMeier, also eigentlich ein Wunder, dass das überhaupt funktioniert. ^^ Eine Ersetzung besteht immer nur aus einem RegExp und einer Ersetzung und in Ausnahmefällen einem flag, siehe Text-Ersetzung (wobei hier für dich das flag "i" wäre). VG ↔ User: Perhelion14:50, 7. Apr. 2016 (CEST)
Ich bewundere echt, dass ihr versteht was dort steht. Ich habe es getestet und tatsächlich mag es wohl das große I nicht. Ist aber trotzdem nützlich, ich muss so etwas immer alles von Hand ersetzen. --Liebe Grüße, LómelindeDiskussion14:58, 7. Apr. 2016 (CEST)
Naja, RegExp ist wohl manchmal tatsächlich sehr kryptisch und schwer zu verstehen (am Anfang :P). Wenn ich mich nicht täusche müsste das Bsp. so aussehen (ungetestet):
(PS: Es kann tatsächlich noch wesentlich komplizierter werden, das Hauptproblem IMHO ist jedoch dass es viele unterschiedlich Interpreten und somit unterschiedlich Varianten von RegExp gibt.) ↔ User: Perhelion15:03, 7. Apr. 2016 (CEST)
@Lo: Ich verstehe nur wenig davon, aber WSTM lässt sich damit recht gut erweitern. Wenn du magst, kann ich dir helfen, einiges zusammenzubasteln. Von deiner Unterhaltung mit PC versteh ich ja meist auch nur die Hälfte (oder weniger). Gruß --RonMeier (Diskussion) 15:13, 7. Apr. 2016 (CEST)
@ Perhelion, es soll aber sowohl i als auch I erkennen. Also In: oder in: und zudem wenn nicht kursiv aber mit Komma am Ende [[Titel]], (wobei für mich auch noch ohne Klammern drum wünschenswert wäre) oder falls schon kursiv aber mit Komma ''[[Titel]]'', oder Punkt ''[[Titel]]''. außen, dann schreibe In: immer groß, setze den folgenden eingeklammerten Titel kursiv mit Punkt innen ''[[Titel]].''. Ja das steht wohl auch in diesem Teil →In: ''[[$1]].'' hmm und warum folgt da noch ein kleines "i"? Ich lerne das noch irgendwann. Hallo RonMeier, ja das wäre nett. ich habe nämlich noch ein kleines Problem mit meinen Anhängen des [if http….pdf setze (PDF) hinter den Link], manchmal gefällt mir das Ergebnis nicht. --Liebe Grüße, LómelindeDiskussion15:31, 7. Apr. 2016 (CEST)
Ich habe mal ein bisschen getestet, da normal der Fehler bei mir nicht reproduzierbar ist. Mir ist aufgefallen, dass wohl eine WSTM eigene Regel hier das " in: " ganz entfernt. Was allerdings das Ergebnis wohl nicht ganz erklärt, höchstens dass hier ein Konflikt-Potential besteht. Wenn ich mich nicht irre werden die benutzerdefinierten Regeln zuerst ausgeführt. PS: Respekt an die beachtliche config von RonMeier! :D Was allerdings auch noch mal für Konflikt-Potential spräche. @Ló das "i"-flag ist nur unter plain sinnvoll (s.d.). ↔ User: Perhelion16:57, 7. Apr. 2016 (CEST)
Ich sagte zwar, ich werde es lernen aber nicht alles auf einmal und ich lese so ungern diese technischen Seiten. Plain ist platt und leer so wie ich gerade. Gute Nacht ihr beiden. --Liebe Grüße, LómelindeDiskussion19:45, 7. Apr. 2016 (CEST)
Bei deiner eigentlichen Beschwerde ging es darum, dass die Kursivierungsstriche zu Beginn nicht mitkamen, wenn es schon ein großes I gewesen war.
Mag durchaus ein Bug sein; das ist schon drei Jahre her, extrem kompliziert und ich habe momentan zu wenig Zeit, um mich tief in die Angelegenheit einzuarbeiten, und noch Bugs für alle Anwender offen. Ich brauche mehrere Wochen mit nichts anderem am Hals, um sowas zu lösen.
Eine Erklärung für einen derartigen Effekt habe ich nicht, und keinerlei Idee dazu.
Möglicherweise wirken aber mehrere Ausdrücke hintereinander ungeplant zusammen und blockieren sich für dasselbe Textelement.
Ich hätte gern, dass ein vorhandenes Komma bleibt, egal was in ZR steht. Es hat sich allmählich bei Zeitschriften und Zeitungen eingebürgert, und das ist auch gut so; das ursprüngliche Konzept mit dem Punkt hatte mal nur sowas wie Jahrbücher vor Augen gehabt. Insbesondere kommt es dann auch zur Harmonisierung mit Websites, die an einem bestimmten Tag eine Meldung veröffentlicht hatten. Irgendwann ändern sich auch ZR ein wenig, die sind nicht vom Himmel gefallen und nicht in Stein gemeißelt, sondern können sich in Details auch weiterentwickeln.
Kursivieren kannst du trotzdem gern.
Im ersten Teil kann für das Linkziel übrigens auch false stehen (denke ich mir so).
(Nur falls es hilft, noch eine kleine Analyse) Ich kann den Bug doch bestätigen, dabei ist mir merkwürdig aufgefallen, dass dieser direkt vom 1. Ersetzungsausdruck abhängig ist (sobald man ein Zeichen ändert ist der Bug weg). Uzw. wenn dieser identisch am Anfang steht und scheinbar dadurch (irgendwie) auf false rutscht. (Dabei spielt [Ii] oder "i"-flag keine Rolle, welches man anscheinend doch auch bei .wikilink setzen kann). LG ↔ User: Perhelion00:31, 8. Apr. 2016 (CEST)
PS. @Linkziel: funzt anscheinend nicht mit false
Da bleibt nur der Nothaken (getestet): .replace(/\s+in:\s*('?)\1\[\[([^\[\]]+)\]\][,\.]?\1\1 /ig," In: ''[[$2]].'' ");// workaround
Ich wüsste nicht einmal, wo ich das jetzt einfügen müsste, aber da „The Big Boss“ sagt, „is nich gut diese Spielerei mit dem Komma“, lasse ich es lieber. KISS oder so, je mehr ich an Spielereien einbaue, desto anfälliger wird es vermutlich und ich habe ja auch so oftmals schon merkwürdige Phantomfehler. Ganz blöd wäre es dann, wenn ich hier Fragen stelle zu Fehlern, die ich quasi selbst erzeuge. Es reicht schon, dass ich manches doppelt frage. Vorlage:Smiley/Wartung/rot
Letzter Kommentar: vor 8 Jahren6 Kommentare3 Personen sind an der Diskussion beteiligt
Hallo PerfektesChaos, bist du zufällig gerade online? Wenn ich den Artikel Seide öffne wundert es mich warum nicht bei allen Parametern in der Infobox Faser die ISB-Nummern formatiert werden. Ich sehe nicht warum einige so bleiben. Hast du eine Idee? Beispielsweise
Franz Weber, Aldo Martina: Die neuzeitlichen Textilveredlungs-Verfahren der Kunstfasern. Springer-Verlag, 1. Dezember 2013, ISBN 9783709124246
P.-A. Koch: Rezeptbuch für Faserstoff-Laboratorien. Springer-Verlag, 17. April 2013, ISBN 9783662129210, S. 127
Das sind ISBN in Vorlagen, da läuft das nicht so richtig. Ich weiß nicht, ob das früher auch so war, aufgefallen ist mir das erst/schon vor etwa zwei Monaten. Gruß --RonMeier (Diskussion) 14:50, 8. Apr. 2016 (CEST)
Hallo RM, vielen Dank für die Info. Na ja, ich würde es ja verstehen, wenn es bei allen so wäre aber einige funktionieren, das finde ich doch seltsam. --Liebe Grüße, LómelindeDiskussion14:54, 8. Apr. 2016 (CEST)
Es sind ref in Vorlagenparametern, und das ist für den Arbeitsablauf von WSTM offenbar eine Ebene zuviel.
Die ISBN-Strichelung ist im Übrigen ein Lesbarkeits-Service, aber nicht unbedingt die großartige Syntaxreparatur, und ungestrichelt auch nicht falsch.
WSTM mag eine simple Struktur der Artikel. Der MediaWiki-Parser öffnet bis zu 40 Ebenen nur für Vorlagen; WSTM möchte eine schlichte Vorlage, und deren Parameter am liebsten einfache Zeichenketten. Bild, in dessen Legende Vorlagen, in deren Parameter ref, in denen Vorlagen, in denen ISBN – da ist WSTM schon froh, wenn das Ende wiederzufinden ist.
Das Ende finden, ja da wäre ich auch manchmal froh. Nee das ist nur für die Optik aber wenn ich schon einen Artikel offen habe dann versuche ich auch alle umzuschreiben. Früher habe ich das immer von Hand gemacht und zwar eher willkürlich oder immer gleich. ISBN 978-1-234-56789-0. So jetzt habe ich aber genug genervt. Nochmals vielen Dank. --Liebe Grüße, LómelindeDiskussion15:35, 8. Apr. 2016 (CEST)
Letzter Kommentar: vor 8 Jahren5 Kommentare3 Personen sind an der Diskussion beteiligt
Dieser Abschnitt könnte entfernt werden weil es nicht mehr der Rechtschreibung entspricht. Wikipedia und auch z. B. das Oxford Dictionary hängen reguläre Buchstaben an. WP:WPSK hat sogar die Kategorie 101 dafür. Solltest du die Rechtschreibung über das Zitat stellen, könntest du sogar eine generelle Ersetzung einbauen. Bisher habe ich diese Fehler in der Whitelist gesammelt. --Hadibe (Diskussion) 23:39, 8. Apr. 2016 (CEST)
Hmmm; die en-Rechtschreibung ist da wohl im Fluss. Insbesondere die US-Amerianer sind da heute zu bequem und schreiben es direkt hintendran. Zumindest bei älteren und britischen Werken ist es hingegen die Regel und korrekte Notation, und WPSK würde hier unzulässig eingreifen.
Ich nehme das mal so zur Kenntnis, habe aber viel zu viel um die Ohren, um dieses Wochenende irgendwas zu entscheiden.
Na sicher wäre es nicht in Ordnung alle Zahlen zu ändern, eben weil es früher hochgestellt wurde. Aber pauschal alle hochzustellen wäre genauso falsch. Übrigens, sogar der britische Hof hat auf die vereinfachte Schreibweise umgestellt. --Hadibe (Diskussion) 01:19, 10. Apr. 2016 (CEST)
Ich gebe es auf. Das Oxford English Dictionary nutzt anscheinend generell die Normalform. Dieses wie auch die anderen Bücher die ich habe, erwähnen die hochgestellte Form noch nicht mal. Ansonsten habe ich Schreibanleitungen von Universitäten aus USA, IRL und GB gefunden, die empfehlen die hochgestellte Form nicht zu benutzen. Aber einen offiziellen Text, dass und wann sich diese Handhabung geändert hat, finde ich nicht. Die einen schreiben kann man machen, die anderen ignorieren die alte Form. --Hadibe (Diskussion) 09:25, 12. Apr. 2016 (CEST)
Vorlagenklammern um ISB-Nummer?
Letzter Kommentar: vor 8 Jahren5 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo PC ich vermute zwar die Antwort lautet nein geht nicht, aber ich frage trotzdem, könnte WSTM das hier {{ISBN:9783662461624}} lösen? Es sind nicht wirklich viele, 4 Treffer.
Hej Ló, also bei 4 Treffer absolut, da lohnt eine Syntax nun wirklich nicht! :P Mache einfach die Klammern weg und WSTM kann es auflösen. LG PS: Wie man sehen kann sind dies auch alles auskommentierte Quelltext-Reste. ↔ User: Perhelion19:07, 18. Apr. 2016 (CEST)
Ach du, natürlich sind das Peanuts, ich kann das auch ohne WSTM, ich wollte nur wissen, ob es technisch machbar wäre, weil es ja auch reguläre ISB-Nummern innerhalb von Vorlagen gibt. Ich stelle es mir schwierig vor so etwas zu trennen. Ich habe eigentlich nur einen Grund gesucht nach der Nutzung des neuen Tools zu fragen, weil ich noch nicht so ganz verstanden habe wie ich das testen könnte. Ich werde auch dein Tool noch weiter testen, bloß ist es auf Beta immer so trostlos und einsam, wenn ihr nicht dort seid. --Liebe Grüße, LómelindeDiskussion19:21, 18. Apr. 2016 (CEST)
Aja da hast du wahrscheinlich Recht und die Frage kann nur PC wirklich beantworten (mit der Joker-Funktion würde es jedenfalls gehen). Vermutlich bin ich auch wieder gar nicht richtig im Bilde, was meinst du denn mit "neuen Tools"?
@Beta: sagen wir es ist etwas übersichtlicher und persönlicher. ^^ (deinen Vorschlag dort werde ich wahrscheinlich erst übermorgen umsetzen können). LG ↔ User: Perhelion19:38, 18. Apr. 2016 (CEST)
Letzter Kommentar: vor 8 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Mahlzeit! Wahrscheinlich hängt es mit den Sprachvorlagen zusammen, dass LÄ zu lÄ umgeschrieben wird. Als Lexikon der Ägyptologie ist die Großschreibung passender. Oder habe ich da schon wieder einen Denkfehler? --Hadibe (Diskussion) 11:51, 20. Apr. 2016 (CEST)
Passender für das elende Ding wäre Vorlage:LexÄgypt1975.
Wer soll denn durch diese Abkürzungen durchsteigen, und gibt es wirklich nur ein einziges Lexikon dazu in nur einer Sprache und nur einer Auflage auf diesem Planeten?
„LÄ“ las ich eben in der Beo als H:LÄ, und in diesem Kontext würde ich eine solche Vorlage vermuten.
85 Einbindungen im ANR; da ließe sich was dran drehen.
Letzter Kommentar: vor 8 Jahren6 Kommentare2 Personen sind an der Diskussion beteiligt
aus
* [[Mario_Vargas_Llosa|Mario Vargas Llosa]]: "Sonntag", Illustrationen von Kat Menschik Insel Bücherei 2018, Berlin 2016 [[ISBN: 9783458200185|ISBN: 978-3-458-20018-5]]
== Quellen ==
wird
* [[Mario Vargas Llosa]]: "Sonntag", Illustrationen von Kat Menschik Insel Bücherei 2018, Berlin 2016 ISBN 978-3-458-20018-5f== Quellen ==
Warum wird diese ISBN 978-3-5441-260-0 nicht moniert? Da könnte doch eigentlich eine Meldung erfolgen in etwas so ISBN falsch (Anzahl der Ziffern) [12]. Mit 11 geht es.
Zudem ist mir in dem Artikel gerade so etwas ISBN'' 978-3839218730 untergekommen, das scheint aber eher selten zu sein.
Ich bekomme bekam nichts, das wunderte mich ja. Als ich eine ISBN mit zwölf Ziffern auf der Spielwiese testete egal welche, kam da keine Meldung daher habe ich ja denn die Gegenprobe mit 11 gemacht. ‹seufz›
Nein, „da“ war kein nowiki drum, aber zunächst stand da ISBN''' 978-3-5441-260-0, klar dachte ich mir, so geht es nicht, also die Fettung raus und den Button geklickt, aber es passierte wieder erwarten nichts. Aber wenn ich es jetzt teste, dann schon. Phantom. Ich hätte das doch nicht gefragt, wenn ich es nicht zusätzlich getestet hätte. --Liebe Grüße, LómelindeDiskussion19:15, 30. Apr. 2016 (CEST)
FFFFFF → ffffff ???
Letzter Kommentar: vor 8 Jahren5 Kommentare2 Personen sind an der Diskussion beteiligt
Ich weiß nicht, wovon die Rede ist, und habe damit auch nichts zu tun, und kann nach Abspeicherung der geänderten Version auch nihts mehr nachvollziehen. LG --PerfektesChaos18:16, 30. Apr. 2016 (CEST)
Wenn ich den Artikel öffne und zwar noch immer, dann wird nach Zeile 155:
Klar habe ich es wieder auf große FFFFFF gesetzt und dann nochmals den Artikel geöffnet, und siehe da er tut es immer wieder. und zwar nur das. Warum immer ich?
Du kannst es ja mal testen, setze einfach mal das hier auf die Spielwiese und starte WSTM
Auf was für Ideen die Leute bei der Quelltextformatierung so alles kommen.
WSTM kannte bisher nur border-color und border mit Borderline-Syndrom.
Alle anderen Teile des CSS bekommen Kleinschreibung.
Probier es in ein paar Tagen nochmal.
Dann hätte ich noch weitere Pärchen in Zeile 155 und 247 anzubieten.
Die zweite Meldung war das, was ich brauchte.
In der ersten war action=submit verlinkt. WSTM wird aber nur bei action=edit tätig, und deshalb sah ich Null Änderung.
In der zweiten stand konkret style="border-left:solid #ffffff; und darunter konnte ich mir sofort was vorstellen und brauchte den Artikel gar nicht mehr anzufassen.
In ein paar Tagen ist gut eher wird es auch kaum gehen, ich bin bis nächsten Sonntag offline. O.k. Vielen Dank ich lerne das schon noch. Ich dachte es würde funktionieren wenn ich es so verlinke. Aber du hast natürlich Recht, Beispiele sind auch für mich deutlich leichter nachzuvollziehen. So dann bis demnächst wieder, ich bin nur noch kurz online. --Liebe Grüße, LómelindeDiskussion06:50, 1. Mai 2016 (CEST)
main -> Hauptartikel
Letzter Kommentar: vor 8 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Letzter Kommentar: vor 8 Jahren20 Kommentare4 Personen sind an der Diskussion beteiligt
SyntaxError: RegExp.multiline is deprecated. Use m flag instead index.php:211:4
TypeError: can't assign to properties of (new Number(29)): not an object index.php:1252:10
Kannst du bitte mal schauen ob da alles i.O. ist? Also konkret erwarte ich dass die Datumsangaben in der Internetquelle umgestellt werden, es machte mich stutzig, dass nichts passiert, weil ich zumindest einen doppelten Parameter |werk= habe der doch eigentlich auch an WSTM nicht ganz ungesehen vorbeischleichen sollte. Scheint aber am Artikel zu liegen, vielleicht habe ich den Auslöser übersehen. --Liebe Grüße, LómelindeDiskussion14:11, 10. Mai 2016 (CEST)
OT: kannst du mal bitte schauen, ob ich das svg→xml richtig gemacht habe, ich wollte erst "text" nehmen finde bunt aber schöner und "xml" war schon im Artikel.
Flavors of Entanglement – ebenfalls, the same message. Den Rest der Meldung schreibe ich in den Report, falls du es benötigen solltest. --Liebe Grüße, LómelindeDiskussion14:22, 10. Mai 2016 (CEST)
Der Artikel wirft ebenfalls die selbige Meldung aus. Ich weiß nicht genau woran es liegen könnte aber es hat definitiv etwas mit der Vorlage:Internetquelle zu tun. Wurde an der etwas verändert? Das hier ist das einzige was ich sehe, aber das heißt ja nichts. Wo steckst du? Du weißt das mich das kirre macht, wenn ich selbst nichts machen kann, um den Fehler einzukreisen. --Liebe Grüße, LómelindeDiskussion15:38, 11. Mai 2016 (CEST)
Na toll definitiv gestrichen hier war und ist zumindest für mich sichtbar keine Vorlage:Internetquelle drin, trotzdem kommt die Meldung. Ich verstehe es nicht woran es liegt. --Liebe Grüße, LómelindeDiskussion15:34, 13. Mai 2016 (CEST)
Also ich kann das jedenfalls nicht bestätigen, bei mir läuft alles super, bei beiden Artikeln (mit der teilweisen Riesen-config von RonMeier :P). Allerdings benutze ich die /d also Entwickler-Version. Schönes We ↔ User: Perhelion16:43, 13. Mai 2016 (CEST)
@Perhelion: Nun die demo-version benutze ich auch, schließlich bin ich hier als Versuchskaninchen angestellt, daher wäre mir auch wohler, wenn der Herr des Hauses sich mal melden würde.
Bei mir ist alles unverändert. Ich habe alle Artikel noch mal aufgerufen und es bleibt bei der Meldung. Perhelion kannst du bitte mal in die Konsole schauen was da bei dir steht? --Liebe Grüße, LómelindeDiskussion17:26, 13. Mai 2016 (CEST)
@Ló Tatsächlich ist die /d (= debug) version Dieselbe wie die /r . Eventuell hat es etwas mit dem Laden, wie oben schon mal mukiert, zu tun, da ich eine manuelle Auslösung definitiv bevorzuge. Allerings habe ich doch noch Ladefehler, in 2 Wochen jedoch nur zweimal. ↔ User: Perhelion17:32, 13. Mai 2016 (CEST)
Manuell startet es aber ebenfalls nicht, das ist ja das Problem, es streikt dauerhaft. Dann steht also bei dir nichts in der Konsole?
Nein. Ich habe eine Idee, das sieht nach einer allg. JavaScript Deprecation Meldung aus, also vom Browser abhängig. Welchen benutzt ihr mit welcher Nr.? ↔ User: Perhelion17:39, 13. Mai 2016 (CEST)
Ne du Chrome sagt beispielsweise beim Elektrokardiogramm auch da stimmt etwas nicht.
index.php?action=raw&bcache=1&ctype=text/javascript&title=User:PerfektesChaos/js/WikiSyntaxTextMod/…:1252 Uncaught TypeError: Cannot create property 'leap' on number '29'
Wie ich vermutete, liegt es an einem JavaScript-Update. FF und Chrome haben sich anscheinend abgesprochen (einer Art Standard-Entwicklungs-Schwelle). Denn nachdem ich meinen FF von 45 auf 46 geupdated habe, habe ich den Fehler auch (falls es dich beruhigt ^^). PS: Bug ↔ User: Perhelion18:29, 13. Mai 2016 (CEST)
also nichts weltbewegendes. Wenn es belanglos ist bitte einfach diesen Abschnitt löschen. Ich trau mich schon fast nicht mehr etwas zu schreiben. Ich kann es nicht abschätzen, was ich melden sollte und was nicht. --Liebe Grüße, LómelindeDiskussion18:30, 18. Mai 2016 (CEST)
Also, erstmal zum Thema der momentanen Woche und des Mai:
Es geht um Totalausfälle; da, wo man überhaupt nichts sieht, wo es nur noch eine englische Fehlermeldung und eine Zeilennummer geht.
Die scheinen allmählich fast alle raus zu sein.
Egal, was bei der Vorlageneinbindung angeben wird, es muss immer eine mehr oder weniger klare deutschsprachige Fehlermeldung geben, und die richtig angegebenen Parameter müssen auch dargestellt werden.
Wenn nicht, ist es ein dringlich zu behebender Bug.
Die nächste Stufe ist, dass Parameterwerte ungültig sind und zu einer Funktionseinbuße führen.
Die andere Nummer war vielleicht die DDR-Lizenznummer oder die Genehmigung der SMAD oder sowas.
Erstmal völlig egal ist es, wenn nur die Namen von Parametern veraltet sind, aber die Vorlage mit den veralteten Namen das gleiche Ergebnis produziert wie vorher.
Das wäre Titel-P (alleinstehend) oder ISBNistFormalFalsch. Die sollen zwar mittelfristig verschwinden, aber das hat keine Eile. Auch ob da nun Jahr oder Datum vor der Jahreszahl steht, macht keinen Unterschied.
Und die zurzeit noch nachpolierte Vorlagendoku muss erstmal an den Start, bevor du irgendwas kapieren kannst.
Systematische Bearbeitungen sind erst dann sinnvoll, wenn WSTM auf die neue Syntax trainiert wurde. Damit konnte ich aber erst am Montag/Dienstag beginnen.
Deshalb wird erst mit dem Juni eine serienmäßige Aufarbeitung sinnvoll.
Und dann melde ich mich schon bei den üblichen Verdächtigen, sobald WSTM und Doku und Einsatzschwerpunkte klar sind.
Bei der Fehlermeldung in der ersten Zeile dieses Abschitts TypeError: can't assign to properties of (new Boolean(false)): not an object index.php:1320:16 fehlt mir die Angabe aus der Konsole, welche Komponente daran beteiligt gewesen wäre, oder ersatzweise ein Artikel zum Reproduzieren. Die Zeilennnummer 1320 allein bringt es nicht; die habe ich öfters.
Zu DNB das funktioniert noch immer nicht mit dem Ziel, deshalb hatte ich ja auf OCLC gewechselt, weil ich dachte mit der Nummer stimmt auch etwas nicht, später merkte ich, dass man generell bei „9“ ankam: Elfriede Ulbricht: Das Flussgebiet der thüringischen Saale. 1. Auflage. Max Niemeyer, Halle (Saale) 1957, DNB455149968. nun landet man zwar irgendwo auf einem anderen Platz in der DNB aber das richtige Ziel ist
reichen dir drei, sonst schau die Einträge der Kat durch. Der Fehler ist auch auf der Spielwiese reproduzierbar wenn du den Eintrag oben kopierst und dort versuchst manuell zu starten. --Liebe Grüße, LómelindeDiskussion06:42, 19. Mai 2016 (CEST)
WSTM.lang.p.dewiki.template.literatur.fix() index.php:4601 gibt es schon nicht mehr.
Ich kann den Fehler deshalb auch nicht mehr reproduzieren.
Das Unterprogramm hatte ich seit dem Wochenende massiv umgebaut. Vielleicht war ich mal selbst in diesen oder einen analogen Fehler getappt, vielleicht ist es beim Umbau einfach so verbessert worden.
WSTM für die neue Vorlagenprogrammierung ist für Sonnabend geplant.
Ab Sonntag bin ich für ein paar Tage weg, dann muss alles weitgehend flutschen. Freitag bin ich überwiegend offwiki. Neue Doku muss ich noch formatieren und aktualisieren. Stress.
O.k. ich werde mich bemühen weniger Stress zu machen. Du siehst etwas anderes, na schauen wir mal was im Juni wird, ich hoffe ein angenehm warmer Sommer. Dankeschön. --Liebe Grüße, LómelindeDiskussion13:45, 19. Mai 2016 (CEST)
Jahr → Datum
Letzter Kommentar: vor 8 Jahren20 Kommentare3 Personen sind an der Diskussion beteiligt
Wenn jemand die Literatur tabellarisch innerhalb eines Artikels oder außerhalb von <references>…</references> setzt, dann passiert folgendes:
aus
wird
[* <ref name="…">] {{Literatur
|Autor = Hans E. Laux
|Titel = Der große Kosmos-Pilzführer
|TitelErg = Alle Speisepilze mit ihren giftigen Doppelgängern
|Verlag = Franckh-Kosmos Verlags-GmbH & Co.
|Ort = Stuttgart
|Jahr=2001
|Seiten = 612
|ISBN = 978-3-440-12408-6}}[</ref>]
[* <ref name="…">] {{Literatur
|Autor = Hans E. Laux
|Titel = Der große Kosmos-Pilzführer
|TitelErg = Alle Speisepilze mit ihren giftigen Doppelgängern
|Verlag = Franckh-Kosmos Verlags-GmbH & Co.
|Ort = Stuttgart
|Datum=2001|Seiten = 612
|ISBN = 978-3-440-12408-6}}[</ref>]
Also das Datum zieht den nachfolgenden Parameter eins nach oben. Nichts weltbewegendes, aber das war das erste was mir sofort aufgefallen ist. --Liebe Grüße, LómelindeDiskussion13:57, 23. Mai 2016 (CEST)
Sollte sich mit dem nächsten Edit wieder glattbügeln, macht jetzt einen schön auffälligen Diff; einfach ignorieren. Die Umparametrisiererei kommt erst später, nachdem das Layout schon gelaufen ist. LG --PerfektesChaos14:50, 23. Mai 2016 (CEST)
Info: Nein ich kann das doch nicht alles ignorieren schau bitte mal was du da machen kannst
{{Literatur|Titel = Verleihungen des Verdienstordens der Bundesrepublik Deutschland|Sammelwerk = Bundesanzeiger|Band = Jg. 3|Nummer = 250|Ort = Köln,|Jahr = 29. Dez. 1951, S. 4 f.|ISSN = 0344-7634}}
Verleihungen des Verdienstordens der Bundesrepublik Deutschland. In: Bundesanzeiger. Jg. 3, Nr.250, 29, ISSN0344-7634.
Das geht so auf keinen Fall. Ja ich weiß wie ich das anzupassen habe, aber WSTM weiß es scheinbar nicht. By the way, kannst du das Komma hinter dem Ort bitte an anderer Stelle irgendwie automatisch ausblenden, so etwas sehe ich nicht immer auf Anhieb. --Liebe Grüße, LómelindeDiskussion13:37, 26. Mai 2016 (CEST)
Also, was die Leute so alles für eine Jahreszahl halten …
Die irrtümliche Reduktion wurde eingeschränkt; WSTM sah sich überflutet.
Hinter Ortsname werden Komma, Semikolon und Schrägstrich geschluckt.
Sollte heute im Lauf des Abends an euch zur Erprobung gehen.
noch’n paar Jahre vielleicht sollte ich mal von Monat auf Jahr wechseln. Wenn ich so etwas Gregory Mathews öffne muss ich gefühlt einen Kilometer weit nach unten scrollen ehe der Artikelkopf sichtbar wird. Und bitte nicht wieder mit mir schimpfen wegen der Dateianfrage. --Liebe Grüße, LómelindeDiskussion20:28, 26. Mai 2016 (CEST)
Noch etwas fällt mir gerade auf. |Jahr= | Monat= | Tag= | wird nicht zu |Datum= | wenn keine Werte eingetragen sind. Also nicht dass das jetzt schlimm wäre, wie gesagt es ist mir nur gerade aufgefallen. Und könnte eventuell eine Analyse erfolgen ob eine unter |Online= angegebene url auf JSTOR vorhanden ist und einen Hinweis geben, dass der Parameter |JSTOR= genutzt werden könnte? Ich übersehe dass wenn ich nicht aufpasse. Ja iat nicht schlimm aber … --Liebe Grüße, LómelindeDiskussion14:11, 27. Mai 2016 (CEST)
Parameter ohne Wertzuweisung richten keinen Schaden an, haben meist auch noch nie viel geholfen. Da kümmere ich mich drum, wenn die Außenwirkung rundherum glatt ist.
Mit JSTOR kenne ich mich nicht aus. Bei den meisten ID meckert das Modul alle Autoren an, wenn eine kürzere Notation möglich und der Online-Parameter redundant ist. Vielleicht nächste Woche. WSTM wird hier eher nichts unternehemen, weil der Online-Parameter viel zu komplexe Formatierungen erlaubt.
Momentan liegt die Priorität beim Monats-Parameter.
Ja ich weiß meine Aufgabe ist der „Monat“, ich mach doch schon. JSTOR kenne ich auch nicht wirklich, ich weiß nur inzwischen, wie man den umbauen kann. Vielen Dank und ein angenehmes Wochenende. --Liebe Grüße, LómelindeDiskussion12:51, 28. Mai 2016 (CEST)
N, hier bin ich noch immer unzufrieden, Jahr→Datum schluckt immer „alle Leerzeichen“, und das sieht dann manchmal wirklich doof aus. Es geht nicht um den Bereich der references, der wird ja nachträglich einheitlich formatiert. Was mich stört ist das hier |Datum=1993| wenn da vorher Leerzeichen und/oder Zeilenumbrüche standen und alle anderen Parameter diese auch weiterhin haben. (Ja ich weiß, Umbrüche sollten dort nicht sein), aber es ist das, was man oftmals vorfindet)
* {{Literatur
| Autor=Wolfram Angerbauer
| Titel=Als Heilbronn noch Oberamt war …
| Sammelwerk=Schwaben und Franken. Heimatgeschichtliche Beilage der Heilbronner Stimme
| Band=39. Jahrgang
| Nummer=Nr. 3 (März/April)
| Verlag=Verlag Heilbronner Stimme
| Ort=Heilbronn
| Jahr=1993
| Seiten=
| ZDB=128017-x}}
* {{Literatur
| Autor=Wolfram Angerbauer
| Titel=Als Heilbronn noch Oberamt war …
| Sammelwerk=Schwaben und Franken. Heimatgeschichtliche Beilage der Heilbronner Stimme
| Band=39. Jahrgang
| Nummer=Nr. 3 (März/April)
| Verlag=Verlag Heilbronner Stimme
| Ort=Heilbronn|Datum=1993| Seiten=
| ZDB=128017-x}}
Und nein, das wird nicht beim nächsten Aufruf behoben das wird im Gegenteil, falls man das Format wieder herstellt erneut in die Zeile nach ober geschrieben, sobald WSTM darauf trifft, einziger Unterschied, wenn schon | Datum=1993 angetroffen wird und nicht | Jahr=1993 dann wird das Leerzeichen vor dem Datum nicht gelöscht. Die Stelle sieht dann so aus
{{Internetquelle |url=http://www.airbus.com/presscentre/pressreleases/press-release-detail/detail/first-a400m-for-the-french-air-force-takes-shape-in-seville/ |titel=First A400M for the French Air Force takes shape in Seville |hrsg=Airbus Military Press Centre |datum=2012-02-14 |zugriff=2012-02-14 |sprache=en}}
wird das hier:
{{Internetquelle |url=http://www.airbus.com/presscentre/pressreleases/press-release-detail/detail/first-a400m-for-the-french-air-force-takes-shape-in-seville/ |titel=First A400M for the French Air Force takes shape in Seville |hrsg=Airbus Military Press Centre |datum=2012-02-14|zugriff=2012-02-14|sprache=en}}
Damit wird der Quelltext sperrig und unleserlich, da kein Zeilenumbruch stattfindet. Könntest du das bitte nachbessern. Gruß. Leo. --37.120.20.4014:24, 3. Jun. 2016 (CEST)
Jeder Autor hat in jedem Artikel einen anderen Wunsch, wie bei Vorlagen die Leerzeichen um Pipes und um Gleichheitszeichen angeordnet werden.
Manche mögen Leerzeichen vor und nach der Pipe, manche anscheinend nur davor aber keine um das Gleichheitszeichen, manche ein Leerzeichen nach der Pipe und nach dem Gleichheitszeichen jedoch nicht davor, manche ein Leerzeichen vor und nach der Pipe und sowohl vor wie nach dem Gleichheitszeichen, viele Autoren verlangen so wenig Bytes wie möglich und deshalb überhaupt keine Leerzeichen nirgends nicht, damit es weniger Platz in Anspruch nimmt und dadurch die Übersichtlichkeit und Leserlichkeit verbessert würde … und dann war da noch die gluten- und laktosefreie Rindsroulade für vegane Hindus.
In Content-Management-System steht Vorlage:Internetquelle seit ewigen Zeiten ganz ohne eingebunden, um mal ein Beispiel zu nehmen, das ich grad vor einer Stunde bearbeitet hatte.
Die Kopiervorlagen sind auch keine verbindliche Vorschrift dafür, wie mit Leerzeichen umzugehen sei, sondern nur eine von vielen Varianten.
In der Doku zu Vorlage:Internetquelle gibt es auch noch eine Kopiervorlagen-Variante mit Leerzeichen vor und nach der Pipe, so auch seit Ewigkeiten in Vorlage:Literatur. Man müsste eigentlich jedes einzene Ausfüll-Muster in vier bis sechs Variationen zeigen. Es wurde hingegen mehr oder weniger zufällig mal eine Variante ausgewählt. Trotzdem ist das keine verbindliche Vorschrift.
Das Tool betreibt keine Analyse, wer der Hauptautor welches Artikel sei und wer gemäß einer Autoren-Leerzeichen-Datenbank darüber zu bestimmen habe, bei welcher Einbindung wie viele Leerzeichen wo gesetzt werden sollen; die analysierten und ggf. korrigierten Datenfelder werden einfach in die Seite zurückgeschrieben. Diese fraglichen Felder sind ohnehin kurz; es kann also auch zu keinen dramatischen „Beeinträchtigungen“ kommen.
Da ich seit Jahren Einzelnachweise formatiere, kann ich die versichern, dass es erheblich stört, wenn kein Zeilenumbruch stattfindet. Oftmals sind Einzelnachweise im Quelltext sehr lang, gerade wenn die Parameter |archiv-url= und |archiv-datum= zusätzlich genutzt werden. Innerhalb von Tabellen wird die Sache dann völlig unleserlich und erschwert das bearbeiten das Quelltextes ungemein. Daher möchte ich nochmals auf die Kopiervorlage Vorlage:Internetquelle hinweisen, und dich bitten, die Leerzeichen vor dem senkrechten Strich zu berücksichtigen. Gruß, Leo. --37.120.20.4015:17, 3. Jun. 2016 (CEST)
@PerfektesChaos, darum geht es doch gar nicht, es soll lediglich durch das Tool „keine“ Veränderung an den vorgefundenen Leerzeichen und Umbrüchen vorgenommen werden, also, wenn da „vorher“ ein Leerzeichen stand sollte es auch „nachher“ noch dort stehen und nicht bei einem Teil der Parameter plötzlich verschwinden. Es ist der Bereich um das Datum herum oder kurz nach dem Datum, du veränderst doch die anderen Angaben auch nicht. Nenn mir mal einen Grund dafür, warum um das Datum/datum einige Leerzeichen gelöscht werden sollten und alle anderen nicht. Wie gesagt es ist nichts weltbewegendes und hat auch keine hohe Priorität, aber es könnte einige Autoren stören und das wollen wir beide nicht. --Liebe Grüße, LómelindeDiskussion15:37, 3. Jun. 2016 (CEST)
* {{Literatur
| Autor=Wolfgang Kunz
| Titel=Das Eisenbahnrecht – Eine Rechtsmaterie? Ein Plädoyer für ein eigenständiges Rechtsgebiet
| Sammelwerk=Transportrecht. Zeitschrift für das gesamte Recht der Güterbeförderung
|Datum=2006}}
* {{Literatur
| Autor=Wolfgang Kunz
| Titel=Eisenbahnrecht (Kommentar)
| Verlag=Nomos
| Ort=Baden-Baden|Datum=2011 (Loseblatt)| ISBN=978-3-7890-3536-4}}
* {{Literatur
| Autor=Michael Ronellenfitsch, Ralf Schweinsberg, Iris Henseler-Unger
| Titel=Aktuelle Probleme des Eisenbahnrechts XV …
| Verlag=Kovač
| Ort=Hamburg|Datum=2010| ISBN=978-3-8300-5308-8}}
* {{Literatur
| Autor=Thomas Schmitt und Erik Staebe
| Titel=Einführung in das Eisenbahn-Regulierungsrecht
| Verlag=C.H. Beck
| Ort=München|Datum=2010| ISBN=978-3-406-60343-3}}
Da du selbst manchmal diesen Abschnitt in Tabellenform umschreibst, kann es doch nicht dein Wunsch sein, dass das dann beim Öffnen so umgeschrieben wird, sonst hättest du es doch gleich so angeordnet. Entweder alles „inline“ oder alles „line break up“ aus deiner Änderung dort würde WSTM bei mir übrigens das hier machen.
vorher Ort und Datum in je einer Zeile mit drei führenden Leerzeichen
Sorry, aber ich weiß nicht was ich dann machen soll, ich möchte das nicht alles von Hand ändern müssen, zumal es beim nächsten Öffnen mit WSTM wieder vermurkst würde. --Liebe Grüße, LómelindeDiskussion07:31, 5. Jun. 2016 (CEST)
Und noch etwas für diese Sammlung, weil es mir gerade aufgefallen ist.
aus
{{Literatur
| Herausgeber = Der Herausgeber
| Autor = Max Mustermann
| Titel = Ein Findelkind
| Sammelwerk = Das Wikiland}}
wird
{{Literatur
| Autor = Max Mustermann
| Hrsg = Der Herausgeber
| Titel = Ein Findelkind
| Sammelwerk = Das Wikiland|Datum=}}
Hast du eigentlich jetzt Datum zwangseingefügt? Das ist mir jetzt schon eine ganze Weile aufgefallen, dass ich immer mal so diese Kombination von |Datum=| Jahr = 2011| Monat = 10| Tag = 27. Montag bekomme. --Liebe Grüße, LómelindeDiskussion18:58, 6. Jun. 2016 (CEST)
{{Literatur
|Autor = Hans E. Laux
|Titel = Der große Kosmos-Pilzführer
|TitelErg = Alle Speisepilze mit ihren giftigen Doppelgängern
|Verlag = Franckh-Kosmos Verlags-GmbH & Co.
|Ort = Stuttgart
|Jahr=2001
|Seiten = 612
|ISBN = 978-3-440-12408-6}}
{{Literatur |Autor=Hans E. Laux |Titel=Der große Kosmos-Pilzführer |TitelErg=Alle Speisepilze mit ihren giftigen Doppelgängern |Verlag=Franckh-Kosmos Verlags-GmbH & Co. |Ort=Stuttgart |Datum=2001 |ISBN=978-3-440-12408-6 |Seiten=612}}
{{Literatur
|Autor = Hans E. Laux
|Titel = Der große Kosmos-Pilzführer
|TitelErg = Alle Speisepilze mit ihren giftigen Doppelgängern
|Verlag = Franckh-Kosmos Verlags-GmbH & Co.
|Ort = Stuttgart
|Jahr=2001
|Seiten = 612
|ISBN = 978-3-440-12408-6}}
* {{Literatur
|Autor=Hans E. Laux
|Titel=Der große Kosmos-Pilzführer
|TitelErg=Alle Speisepilze mit ihren giftigen Doppelgängern
|Verlag=Franckh-Kosmos Verlags-GmbH & Co.
|Ort=Stuttgart
|Datum=2001
|ISBN=978-3-440-12408-6
|Seiten=612}}
Dankeschön
pretty-wiki
Letzter Kommentar: vor 8 Jahren20 Kommentare4 Personen sind an der Diskussion beteiligt
Hat sich etwas geändert oder bin ich verwirrt. Hätte diese Anpassung nicht automatisch erfolgen müssen. Ich meine nicht das hinzufügen der class="hintergrundfarbe", sondern nur generell:
aus "prettytable float-left" + Farbangabe in den Zellen
Stationär, rückläufig
Opposition
Minimaldistanz (AE)
Maximalhelligkeit (mag)
Stationar, rechtläufig
Konjunktion zur Sonne
oder "prettytable" + Farbangabe in den Zellen
Stationär, rückläufig
Opposition
Minimaldistanz (AE)
Maximalhelligkeit (mag)
Stationar, rechtläufig
Konjunktion zur Sonne
mach automatisch "wikitable float-left" oder "wikitable"
Stationär, rückläufig
Opposition
Minimaldistanz (AE)
Maximalhelligkeit (mag)
Stationar, rechtläufig
Konjunktion zur Sonne
auch "prettytable" mit class="hintergrundfarbe7" wird nicht ersetzt
Ich stelle inzwischen den Großteil nach "wikitable zebra" um, und lege explizit keinen Wert auf die Erhaltung der Hintergrundfarben oder sonstigen Sonderformatierungen. Diese sind in den allermeisten Fällen fachlich unbegründet, sprich in den meisten Fällen sollte die Hintergrundfarbe, egal wie definiert, entfernt werden. Nur dort wo Gründe erkennbar sind, dass mehrere Zeilen die selbe Hintergrundfrabe haben sollten, verzichte ich auf "zebra". Da ich derzeit aber recht viele Tabellen umstelle, kann ich den hier skizzierten puristischen Ansatz (möglichst nur die Standardformatierung der css Klasse, und sonst nichts) nicht vollständig umsetzten. Die ausgesprochen hässliche Hintergrundfarbe im angesprochen Artikel habe ich entfernt. Frohes Schaffen — Boshomi⌨08:25, 24. Mai 2016 (CEST)
@Boshomi: Darum ging es mir aber nicht, ich riskiere doch nicht meinen Kopf wegen einer hässlichen Hintergrundfarbe. Und ich finde es auch nicht sonderlich gut aus allen Tabellen Zebras zu machen. Im Gegenteil, das sieht manchmal eher merkwürdig aus.
Ich bin auch dort für eine möglichst „sparsame“ Verwendung. Das pauschal umzustellen halte ich nicht für sinnvoll.
Zudem formatiere ich ja auch noch weitere Dinge in den Artikeln, die Klassenumstellung ist ja nur als kleine Zugabe gedacht. --Liebe Grüße, LómelindeDiskussion09:01, 24. Mai 2016 (CEST)
Die Zebras haben bei Tabellen den Vorteil, dass die Lesbarkeit von Tabellen etwas verbesserte wird. Solange die beiden Hintergrundfarben so dezent sind wie derzeit, ist das durchaus verwendbar. Zur Arbeitsweise, ich bevorzuge es möglichst nur eine gleiche Aktion pro Edit umzusetzten, etwa alle toten Links fixen oder alle Tabellen bearbeiten, wobei ich meist viele Tabs geleichzeitig öffne und dort möglichst das Gleiche mache, und auf gleiche Weise kontrolliere. Kombinierte Edits sind mir zu unübersichtlich, insbesondere wenn ich viele davon mache. Frohes Schaffen — Boshomi⌨09:27, 24. Mai 2016 (CEST)
Ich arbeite anders, mir wurde von Anfang an beigebracht „nicht“ für jede kleine Änderung auf Seite speichern zu klicken sondern gleich mehrere Dinge zu beheben, um die Versionsgeschichte nicht unnötig aufzublähen. Und ich höre auf die Ratschläge meiner Mentoren.
Zudem finde ich es etwas merkwürdig, dass du da schreibst "zebra" sei der offizielle oder gewünschte Standard, da würde ich mir aber doch einen Link auf diesen Beschluss wünschen.
Aber du musst selbst wissen, was du tust, ich kann mir so etwas nicht unbedingt erlauben, das wird mir immer sofort als BNS ausgelegt. Gibt es denn einen solchen Konsens irgendwo? Steht irgendwo dass "zebra" der Standard ist? Wenn es so wäre, warum wird es dann nicht automatisch über die Klasse "wikitable" standardmäßig also über die Software in "zebra" dargestellt, das wäre doch viel einfacher, als ein Attribut zu setzen. --Liebe Grüße, LómelindeDiskussion09:38, 24. Mai 2016 (CEST)
Bei Standard meinte ich nicht, dass dies die offiziell bevorzugte Variante sei, sondern dass es sich um eine Standard-css Klasse der Wikimedia-Software handelt. Das ist schon ein unterschied. Der Unterschied der Klasse "wikitable" zu "wikitable zebra" ist schon recht deutlich, die Umstellung muss jedenfalls manuell erfolgen, da es sonst zu Darstellungsfehlern führen würde. Beide Klassen haben ihre Daseinsberechtigung, siehe Spezial:diff/154639722.
Zum Abspeichern: wenn es sich um tatsächliche Miniänderungen handelt, die defakto ohne Auswirkungen sind (Lehrzeichen entfernen,...) mag das zusammenfassen schon mehrere Edits schon sinnvoll sein. Andererseits hat es auch Vorteile wenn man aus einem Editkommentar schon erkennen kann, was tatsächlich gemacht wurde. Je nachdem was man macht, haben beide Varianten ihre Vorteile, sodass Einzelabspeichern mit aussagekräftigen Editkommentar oder ein großer Edit mit oft zwangsweise weniger detaillieren Editkommentar. Frohes Schaffen — Boshomi⌨12:55, 24. Mai 2016 (CEST)
Da kriege ich das kalte Grausen, wenn ich so etwas sehe. Da muss ich gleich mal nacharbeiten, das kann ich so gar nicht ansehen. Sorry aber da bin ich etwas empfindlich. Wenn schon Tabellensyntaxanpassung dann bitte auch komplett. ‹seufz› Ich bin nicht wirklich davon überzeugt, ob das gut ist was du da tust. --Liebe Grüße, LómelindeDiskussion13:43, 24. Mai 2016 (CEST)
Sorry PC, das hatte jetzt weniger mit WSTM zu tun, das gehört vermutlich auf irgendeine andere Seite zur Formatierung alter Tabellensyntax.
Ich finde das so etwas halbherzig, was du da machst.
bgcolor="#abcdef" sollte durch style="background:#ABCDEF;" ersetzt werden
|align:left/right/center| zur Textausrichtung sollte |style="text-align:left/right/center"| sein
eine komplette !-Kopfzeile kann man mit einer Klasse einfärben class="hintergrundfarne[1–9]"
Bei einer Zebrazuweisung sollten die einzelnen Zeilen nicht zusätzlich auch noch Farbzuweisungen erhalten, also entweder zebra oder von Hand gefärbt das ist sonst redundant
den Text in den Zellen einer kompletten Wiki-table-Tabelle kann man mit einer Zuweisung im Tabellenkopf ausrichten, wenn der überwiegende Teil nicht links stehen soll …
+1; Wie gesagt, ich verfolge durchaus eine puristischen Ansatz, wo Sonderformatierungen nur dort vorkommen, wo dies schon auf den ersten Blick klare Vorteile bringt, und die Formatierung direkt aus dem Kontext des Artikels logisch ableitbar ist. Gelegentlich räume ich sowas auch auf, aber die angesprochene alten Formastanweisungen kommen etwa im Verhältnis 4:1 häufiger vor als prettytable. Das sehe im wesentliche als eigenes Projekt. Vielleicht kommen bald vollständig div-basisierte Tabellen, die vollständig auf die traditionellen html-Tags verzichten. Das hätte etwa für die mobile Darstellung deutliche Vorteile, erahne aber noch nicht was das für Auswirkungen auf möglichen Parameter hat. It's a wiki, ich kann sowieso nicht alles alleine machen, und das Wikiprinzip basiert sowieso auf schrittweisen Verbesserungen. Frohes Schaffen — Boshomi⌨15:08, 24. Mai 2016 (CEST)
Aber ich kann auch nicht deine halbherzigen Anpassungen alle reparieren, ich habe derzeit eigentlich eine andere Aufgabe. Und mit „it’s a wiki“ kommst du hier nicht weit. Wenn man es nicht selbst macht bleibt es so. Schau dir bitte nochmal diese beiden Versionen deine vs. meine nebeneinander an. Ich sehe da sofort, dass die Farbwerte für die Legende fehlen, zumindest werden sie mir in deiner Version nicht angezeigt, und auch, dass eine Tabelle merkwürdig aussieht, so etwas macht man einfach mit. Es reicht hier nicht wie ein Bot nur die Klasse zu ersetzen. --Liebe Grüße, LómelindeDiskussion15:36, 24. Mai 2016 (CEST)
das für die Oberfläche nicht unterscheidbare Änderung der alten html4 auf die moderneren style-Parameter ist eine Botaufgabe. Da kann eigentlich nichts schief gehen, da es sich um 1:1 Äquivalente handelt, und derzeit werden (noch) beide Varianten unterstützt. Frohes Schaffen — Boshomi⌨18:08, 24. Mai 2016 (CEST)
@Entlinkt: Oben in diesem thread wird zebra erwähnt; vielleicht magst du dazu doch noch etwas klarstellen. Auch „Da kann eigentlich nichts schief gehen, da es sich um 1:1 Äquivalente handelt“ deckt sich nicht mit meinem Kenntnisstand.
Zur Eröffnung des thread: Da war WSTM überhaupt nicht angesprungen; keine Ahnung warum.
Info@alle: WSTM macht nur dann eine Umstellung, wenn gesichert ist, dass alles glatt läuft, und belässt es bei prettytable, wenn unerwartete Syntaxelemente vorgefunden werden.
Im angegebenen Fall sehe ich erstmal keine. Wenn die Version mit nur class="hintergrundfarbe7" oder nix dort so steht und wirklich nichts anderes noch umherspukt, dann würde das auch als Trivialfall eingestuft werden und ersetzt werden. Auch ein float-left stört absolut nicht. WSTM hätte ersetzen sollen. Vielleicht irritierte das fehlerhafte und detektierte CSS in der ersten Kopfzelle, ist aber eigentlich kein k.o.-Kriterium.
Ich habe auf einer anderen Seite schon mal etwas zu der Umstellung von prettytable auf wikitable zebra (speziell zu dem zebra) geschrieben. Zugegebenermaßen ziemlich unfreundlich (hätte man sicher auch netter schreiben können), aber ich verweise trotzdem mal darauf, um hier nicht alles wiederholen zu müssen. Deshalb nur ganz kurz zwei Punkte daraus:
Bei Tabellen mit nur einer Kopfzeile und nur einer weiteren Zeile ist zebra kompletter Unfug. Dennoch wurde zebra auch in solchen Fällen eingebaut.
Wenn man zebra denn unbedingt einbauen will (was man IMHO nicht tun sollte), dann sollte man auch (fast) alle Inline-Formatierungen entfernen, da sie sich (fast immer) nicht zur Kombination mit zebra eignen. Dennoch wurde zebra auch in solchen Fällen eingebaut, in denen es zu einer komplett weißen Tabelle führt.
Und noch etwas zu der Aussage, dass veraltete HTML-Attribute 1:1-äquivalent mit Style-Anweisungen wären: Sorry, aber falscher könnte eine Aussage zu dem Thema gar nicht sein. Die Prioritätenreihenfolge der Formatierungsanweisungen ist folgende:
Inline-style-Attribute mit !important (sollten niemals verwendet werden)
Externe CSS-Anweisungen (z. B. Klassendefinitionen) mit !important
Inline-style-Attribute ohne !important
Externe CSS-Anweisungen (z. B. Klassendefinitionen) ohne !important
Veraltete HTML-Attribute
Daher stellt beispielsweise die Ersetzung von bgcolor="#ff0000" durch style="background-color:#ff0000" eine gravierende Änderung dar, die sich nicht automatisieren lässt, wenn das Aussehen erhalten bleiben soll. Demonstration:
prettytable-basierte Tabelle
Kopfzelle mit bgcolor="#ff0000"
Kopfzelle mit style="background-color:#ff0000"
wikitable-basierte Tabelle
Kopfzelle mit bgcolor="#ff0000"
Kopfzelle mit style="background-color:#ff0000"
Die Nicht-Äquivalenz sollte unschwer zu erkennen sein. Soll heißen:
Wenn die Kopfzellen einer prettytable-basierten Tabelle mit bgcolor formatiert sind und man stumpf den Klassennamen ändert, wird die Farbe deaktiviert.
Wenn anschließend in einem (hypothetischen) Botlauf das bgcolor durch style ersetzt werden würde, würde die Farbe wieder aktiviert werden.
Bei diesem (hypothetischen) Handlungsablauf würde sich das Aussehen der Tabelle also zweimal ändern, nämlich einmal vor und einmal wieder zurück. Natürlich möchte man das vernünftigerweise nicht, sondern das Aussehen soll sich höchstens einmal ändern.
Zur Klarstellung beschreib ich mal das Vorgehen von WSTM:
WSTM soll nur im Hintergrund mitlaufen, wenn man zufällig sowieso einen nach außen wirksamen Edit vornimmt.
WSTM ändert von bgcolor= in style="background: bei allen Kopfzellen sowie Tabellenzeilen |-.
Sollte zuvor ein Tabellenkopf die sortable enthalten haben, wird von da an statt dessen style="background-color: verwendet, damit die Sortierpfeile nicht untergepflügt werden.
Wenn bgcolor Hexdez enthält, jedoch kein #, was bei HTML2 möglich war, wird dieser ergänzt.
Bis hierhin mag man es als „nur mäßig sinnvoll“ einstufen; es spart aber bei späteren Ersetzungen manuelle Tipparbeit und vermeidet Fehler.
Sollte jemand kürzlich nur den Klassennamen geändert haben, ohne die Atttribute umzustellen, wird wieder der Anblick sichtbar, den es die letzten fünf Jahre auch schon gehabt hatte.
Generell ist es allmählich Zeit, uns von den seit 1998 veralteten HTML2-Attributen zu lösen, da die Parallelwirtschaft für Autoren verwirrend ist; insbesondere weil manche Resultate nicht 1:1 gelten, sondern unerwarteterweise anders auf andere Elemente wirken.
WSTM prüft alle Tabellenköpfe mit prettytable, ob sie sich risikolos und ohne Änderung des Erscheinungsbildes auf wikitable umstellen lassen.
Falls irgendwas verdächtig erscheint, wird die Ersetzung pretty→wiki blockiert.
Das war auch der Auslöser für diesen thread gewesen.
Durch manuelle Nacharbeit kann ggf. der Tabellenkopf entschlackt und die vier Buchstaben wiki drübergetippt werden, falls es jemand interessiert. Sonst später.
Es ist vorstellbar, dass bei mehrfachen Kopfzeilen die nachfolgenden nicht betrachtet werden, oder bei konfuser Syntax mit Zusatzelementen nicht alles in einer Kopfzeile verstanden wurde. Optische Nachkontrolle ist deshalb immer gut. Fehldarstellungen wurden aber nur sehr selten beobachtet.
Ist kein Problem. Die vereinfachte Darstellung oben war ja explizit als „vereinfacht“ gekennzeichnet. Ich hatte dabei vor allem an manuelle Edits gedacht (auch wenn dies die Diskussionsseite zu WSTM ist; da es in diesem Thread auch um manuelle Editaktionen ging).
Die Ersetzung der veralteten Attribute ist natürlich im Prinzip sinnvoll. („Ersetzung“ muss nicht heißen, dass das veraltete Attribut durch sein CSS-Pendant ersetzt wird, sondern kann auch die Löschung sein, falls diese sinnvoll ist.)
Ziemlich wenig sinnvoll ist es dagegen, massenhaft Artikel zwecks Ersetzung des Klassennamens zu bearbeiten und dabei systematisch Attribute wirkungslos werden zu lassen, diese aber in wirkungsloser Form stehen zu lassen. Um diesen Gegensatz geht es mir. Dadurch würde nämlich nur den zukünftigen Bearbeitern die Entscheidung aufgebürdet werden, ob man die wirkungslos gewordenen Attribute löscht oder ob man sie wieder aktiviert (was das Erscheinungsbild nach außen im Endeffekt gleich 2-mal ändert).
Wie schon oben erwähnt lege ich keinen besonderen Wert jede Farbe zu behalten, bin gelegentlich ganz froh wenn ich eine hässliche Farbe nach einem Edit nicht mehr sehe. Bei den letzen Edits die ich in diesem Zusammenhang gemacht habe, habe ich meist die Farbangaben aus den Tabellen rausgelöscht. Die Frage die es zu stellen ist, ist warum Farbe #XYZ besser sei als die von der Klasse vorgegebene Standardfarbe? Wenn die einzige Antwort lautet "Weil es auf meinem Bildschirm so besser aussieht" kann man die Farbe getrost entfernen. Da ist es besser wir verlassen uns darauf, dass die Leute die für die Skinns fachmännisch warten, hier sinnvolle Standardwerte setzten. Ästhetisch schöne, vom Standard abweichende Formatierungen sind höchst selten, in den allermeisten Fällen hat man das Gefühl, die Formatierung stammt direkt von irgend einer Tabellenkalkulation aus dem Jahr 2005. Verfolgt man den Ansatz "Form folgt Funktion", dann sollte eine besondere Farbwahl auch aus dem Kontext des Artikels heraus erkennbar sein. WSTM hat legt den Fokus darauf, das Aussehen zu behalten, was eine beachtliche Herausforderung ist. Mein Ansatz geht aber in die Richtung unnötige Farbvielfalt etwas zu reduzieren. Zebra bevorzuge ich wegen der tendenziell etwas besseren Lesbarkeit (insbesondere wenn vertikal gescrollt werden muss, bleibt das Auge leichter in der Zeile.).
@Entlinkt: Klassen für die Hintergrundfarben Gold, Silber und Bronze wären vielleicht ganz nützlich wenn diese als Standard zur Verfügung stünden, denn die werden tatsächlich recht häufig gebraucht, und sind zumindest in Sportartikeln naheliegend. Frohes Schaffen — Boshomi⌨23:09, 26. Mai 2016 (CEST)
Letzter Kommentar: vor 8 Jahren15 Kommentare2 Personen sind an der Diskussion beteiligt
Ausgangssituation: Jahr=1971 und Originaljahr=1872
{{Literatur | Autor={{lang|en|[[Walter Bagehot]]}} | Titel=Die englische Verfassung | Reihe=Politica | Band=Band 33 | Herausgeber=Wilhelm Hennis, Hans Maier | Verlag=Luchterhand | Ort=Neuwied | Jahr=1971 | Originaltitel={{lang|en|The English Constitution (2nd Edition)}} | Originaljahr=1872 | Originalsprache=en | Übersetzer=Klaus Streifthau | Kommentar=Ersterscheinung der englischen Ausgabe im Jahr 1867}}
Ulanwp macht Datum=1971 und Datum=1872
{{Literatur | Autor={{lang|en|[[Walter Bagehot]]}} | Titel=Die englische Verfassung | Reihe=Politica | Band=Band 33 | Hrsg=Wilhelm Hennis, Hans Maier | Verlag=Luchterhand | Ort=Neuwied | Datum=1971 | Originaltitel={{lang|en|The English Constitution (2nd Edition)}} | Datum=1872 | Originalsprache=en | Übersetzer=Klaus Streifthau | Kommentar=Ersterscheinung der englischen Ausgabe im Jahr 1867}}
nun komme ich weil es in der nächsten Kat aufläuft und WSTM macht Datum=1872 und Datum=1872 und ich stehe da und rätsele was jetzt das richtige Datum sein soll.
{{Literatur | Autor={{lang|en|[[Walter Bagehot]]}} | Hrsg=Wilhelm Hennis, Hans Maier | Titel=Die englische Verfassung | Reihe=Politica | Band=Band 33 | Verlag=Luchterhand | Ort=Neuwied| Datum=1872| Kommentar=Ersterscheinung der englischen Ausgabe im Jahr 1867| Originaltitel={{lang|en|The English Constitution (2nd Edition)}} | Originalsprache=en | Übersetzer=Klaus Streifthau | Datum=1872}}
Beim nächste klick auf den Button käme dann das heraus ein einzelnes Datum 1872 und eine verwirrte Nachtigall
{{Literatur | Autor={{lang|en|[[Walter Bagehot]]}} | Hrsg=Wilhelm Hennis, Hans Maier | Titel=Die englische Verfassung | Reihe=Politica | Band=Band 33 | Verlag=Luchterhand | Ort=Neuwied| Datum=1872| Kommentar=Ersterscheinung der englischen Ausgabe im Jahr 1867| Originaltitel={{lang|en|The English Constitution (2nd Edition)}} | Originalsprache=en | Übersetzer=Klaus Streifthau}}
Nein, ich habe es anders gelöst, so dass es jetzt auch sichtbar ist.
Walter Bagehot: Die englische Verfassung. Hrsg.: Wilhelm Hennis, Hans Maier (= Politica. Band33). Luchterhand, Neuwied 1971 (englisch: The English Constitution (2nd Edition) 1872. Übersetzt von Klaus Streifthau, Ersterscheinung der englischen Ausgabe im Jahr 1867).
Ich bin mir ganz sicher, dass ich genau dieses doooooofe Problem auf einer später von mir zur Löschung erbetenen Seite auf Beta „On the Might of Princes“ angesprochen hatte, dass nämlich nienichts ausgegeben wird. Aber du warst so im Stress, dass du es einfach ignoriert hattest. Und ich habe mir dann gesagt, was soll’s mehr als ansprechen kann ich das auch nicht und ich sollte nicht ständig nerven. Das war diese Sache mit dem Übersetzer und Originalsprache.
Ah, sorry, erstmal musste ich die Darstellungsfragen in Tausenden von Artikeln klären und Komplettversagen abstellen, bis ich in der Flut der Infos zu der Frage kam, ob da irgendwo hinten ein Komma oder eine Jahreszahl stünde. Kommt nur in 151 Artikeln mit Wert vor; wird letzte Woche keinem aufgefallen sein, dass da keine Zahl gestanden war. LG --PerfektesChaos17:40, 28. Mai 2016 (CEST)
Ja doch, ich weiß, und aus lauter Frust habe ich dir sogar ein kleines Gedicht geschrieben. Nein, das wurde noch nie angezeigt und ich hatte einfach erwartet, dass es nach der Neuprogrammierung irgendwie funktionieren würde. Ich bin da schon vorher dran verzweifelt. Es lag mir fern dich zu stressen. Ich weiß nicht mehr genau, ich glaube es war mehr als das Jahr.
Jess Stearn: Taylor Caldwell und das Jenseits. Die Geschichte eines parapsychologischen Experiments. 1. Auflage. Neff, Wien, Berlin 1973, ISBN 3-7014-0101-2 (englisch: The search for a soul; Taylor Caldwell’s psychic lives. Garden City, N.Y. 1973. Übersetzt von Ursula Heim).
Soweit ich mich erinnere wird auch der Originalort verschluckt. Stell dir doch den Inhalt wieder her und schau was da stand. --Liebe Grüße, LómelindeDiskussion17:58, 28. Mai 2016 (CEST)
Ja, ja, ja doch.
Als Dankeschön verrate ich dir zu deinem Dingens von oben ein paar geheime Parameter, die heute schon funktionieren:
In waaas ? Ich schaue morgen mal, ich bin zu müde, „bagehot“? Ich dachte schon das sei wieder irgendetwas technisches, es klingt zumindest irgendwie so nach Parametern und Attributen und …. Ich teste dann mal was passiert. Gute Nacht der Herr. --Liebe Grüße, LómelindeDiskussion19:55, 28. Mai 2016 (CEST)
So?
Walter Bagehot: Die englische Verfassung. Hrsg.: Wilhelm Hennis, Hans Maier (= Politica. Band33). Luchterhand, Neuwied 1971 (socserv.mcmaster.ca [PDF; 551kB] englisch: The English Constitution. 1872. Übersetzt von Klaus Streifthau, Erstausgabe: Chapman and Hall, London 1867).
Oder ohne PDF, ich warte aber erst mal, ob ich noch das O-Jahr angezeigt bekomme, damit ich weiß, wie das dann aussieht, und bei O-Ort muss ich passen, da gibt es zu viele Möglichkeiten. Das is’ja’n’halber Roman. Und by the way, was ist eigentlich mit dem „O-Verlag“ und der möglicherweise, also hier sicher nicht, „O-ISBN“? Ich meine, wenn schon … denn schon. Da wird man ja irre bei den vielen Parametern. --Liebe Grüße, LómelindeDiskussion08:50, 29. Mai 2016 (CEST)
Ahh, ohh es tut sich was. Und ja ich weiß, erst wenn alle 'Monat'-Einträge weg sind bekomme ich eine neue Aufgabe, aber ich brauche ab und zu etwas anderes dazwischen, sonst wird man betriebsblind. --Liebe Grüße, LómelindeDiskussion15:38, 30. Mai 2016 (CEST)
nil – das ist Latein, Bestandteil der edlen Programmiersprache und bedeutet: nichts, nix.
Gut aufgepasst!
Das war in der Tat ein Bug; allerdings ein mutmaßlich nur selten auftretender.
Er kam genau dadurch zustande, dass bei einer ISBN das vorhandene Datum auf die Jahreszahl reduziert werden soll.
Und wenn da keine Jahreszahl drinsteht, dann ist das eben – nix, nil.
Inzwischen im Quellcode besser strukturiert.
Die 'Monat'-Einträge können es inzwischen ruhiger angehen lassen.
Seit heute werden sie behelfsmäßig irgendwie an die Nummer drangeflickt.
Das sieht vielleicht nicht ganz so schön aus; besser es würde dann auch manuell ein Nr. vor eine vorhandene Zahlenangabe geschrieben, und der Zusatz würde vielleicht besser manuell in Klammern gesetzt, aber es wird die komplette Info erstmal im Artikel dargestellt.
Den bagehot kannst du ja spielerisch weiter ausbauen, schließlich auf die Testseite der Vorlage als Live-Beispiel schreiben.
Den O-Verlag und die O-ISBN habe ich bewusst für die Vorlage weggelassen; für das Modul wäre es keine größere Hürde, weil mit der Basisausgabe, deren Originaltext und der Erstausgabe einfach immer die identische Ausgabe-Prozedur für ein Buch aufgerufen wird. Bloß die Autoren drehen am Rad, wenn die Anzahl der Parameter dreistellig wird.
Ich soll den Artikel ausbauen? Wie soll ich denn da noch mehr Infos reinpacken die Vorlage läuft doch schon fast über?
Ja ich tue, fast alles, was immer du möchtest. Hmm … mir war so als würde vor einer Ziffer die Nr. automatisch erzeugt, aber vielleicht drehe ich auch langsam am Rad.
Argh: nur wenn nur Ziffern dort stehen? Ein Jahr. Nr.18, 2012. Ein Jahr. Nr.18, 01–12, 2012.
Ein Jahr. 18, Januar–Dezember, 2012. das ist doof. {{Literatur|Titel=Ein Jahr | Nummer=18|Monat= Januar–Dezember|Jahr=2012 }} und hier fehlt das Jahr →Ein Jahr. 18, Januar–Dezember.
Das kannst du besser.
Nein, das mit dem „nil“ war Zufall, bei mir stand, wie erwähnt, noch Apri vierstellig für die verstümmelte Datumsangabe. Ich hatte mal Latein, also nil, nihil = klein, nichtig, unwichtig, nienichts von Bedeutung. :-) --Liebe Grüße, LómelindeDiskussion17:07, 30. Mai 2016 (CEST)
O.k. ich hoffe, ich behalte das im Hinterkopf, da schwirren derzeit so viele Parameter, dass mir schwindelig wird.
Ich versuche Format und KBytes zu ergänzen wenn ich es sehe und aus | Kommentar={{ZDB|128017-x}} ein | ZDB=128017-x oder eben falls ich ein Jstor sehe JSTOR=Stabile-Nummer oder eine DOI mit gleichzeitigem Online=http://doi…-gesoxe zu vermeiden, … --Liebe Grüße, LómelindeDiskussion17:25, 30. Mai 2016 (CEST)
DISPLAYTITLE und br\
Letzter Kommentar: vor 8 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
’n Abend! Ich habe nur einen kleinen Wunsch: kannst du bitte bei passender Gelegenheit die beiden Sachen mit einbringen? --Hadibe (Diskussion) 22:42, 28. Mai 2016 (CEST)
DISPLAYTITLE war vor Jahren mal in der Diskussion gewesen; inzwischen geht die deWP in Richtung Lokalisierung und ich kann die vor fünf Jahren nicht weitergeführte Umstellung gelegentlich aktivieren.
Es geht wohl um <br \>.
Eigentlich ist der \ in WSTM zur Erkennung vorgesehen und müsste wie ein normaler Schrägstrich erkannt, dann bei der Reformatierung ersetzt werden.
{{Literatur | Typ=wl | Autor=Michel Houellebecq | Titel=Gestalt des letzten Ufers. Gedichte | Originalsprache=fr | Originaltitel=Configuration du dernier rivage | Originaljahr=April 2013 | Übersetzer=Stephan Kleiner, Hinrich Schmidt-Henkel | Verlag=DuMont Verlag | Ort=Köln | Jahr=2014 | ISBN=978-3-8321-9741-4 }}
ungültiges Originaljahr |Originaljahr=April 2013 im zweiten Eintrag
wird
{{Literatur| Autor=Michel Houellebecq | Titel=Configuration du dernier rivage | Verlag=Flammarion |Datum=Apri| ISBN=978-2-08-130316-4 | Kommentar=Gedichtband | Typ=wl}}
warum steht dort überhaupt Datum:?
und wenn ich versuche es mit Datum=2013-04 zu richten geht nichts mehr, der Monat bleibt spurlos verschwunden egal was ich auch versuche, um ihn wieder sichtbar zu machen.
+ Sammelwerk und Ort … nichts
Configuration du dernier rivage. In: Poésie (Flammarion (Firm)). Flammarion, [Paris] 2013, ISBN 978-2-08-130316-4 (Gedichtband).
oder - Kommentar und Typ + Tag … auch nichts |Datum=2013-04-01
Michel Houellebecq: Configuration du dernier rivage. Flammarion, 2013, ISBN 978-2-08-130316-4.
Woran ich mich von heute morgen noch erinnern kann, wäre, dass an diesem Wochenende die Originaljahr/Ort nicht angezeigt werden und es deshalb heute unklug ist, damit rumzumachen, weil das Ergebnis noch nicht zu sehen ist.
Den Monat gibt es nicht, wie an anderer Stelle schon ausgeführt, weil ISBN→Buch.
Den vorangestellten Hinweis Datum:, der auf das Problem unerwarteter Angaben aufmerksam machen sollte, habe ich bis zum Leeren der Wartungskat ausgeblendet.
Ja doch, ich mache doch nicht damit rum, ich habe lediglich die (4) völlig falschen, eliminiert. Nur die, wo ein Jahr, mit Buchstaben begann oder ein Ort mit Ziffer. Soviel muss drin sein. Warne mich doch einfach vor, wenn du solche verwirrenden Updates machst, du weißt doch, dass … ich sonst wieder nachfrage, weil mir etwas spanisch vorkommt. Mich macht das nervös wenn ich nicht weiß, warum etwas plötzlich anders ist. --Liebe Grüße, LómelindeDiskussion07:15, 30. Mai 2016 (CEST)
Und überhaupt warum schimpfst du mit mir, es war ja schon zu einem Unfall gekommen. Oder sollte das so bleiben?
{{Literatur| Autor=Michel Houellebecq | Titel=Configuration du dernier rivage | Verlag=Flammarion |Datum=April| ISBN=978-2-08-130316-4 | Kommentar=Gedichtband | Typ=wl}}
Was genau ist denn ein „nil“? :-) Gut das war jetzt „Zufall“, dass Kritzolina da auch diesen Artikel angefasst hat, und das zur selben Zeit wie ich, aber sonst wäre es glatt untergegangen.
Die Angabe *** Ungültig: Originaljahr ist keine Jahreszahl hätte da dann auch nicht geholfen. Die ist auch neu, oder? Nett, gefällt mir. --Liebe Grüße, LómelindeDiskussion08:01, 30. Mai 2016 (CEST)
Zwangsweise Formatierung der Vorlagen Literatur und Internetquelle mit CR
Letzter Kommentar: vor 8 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo @PerfektesChaos:, ich habe mich jetzt auch ein wenig mit dem WSTM beschäftigt und ein wenig getestet. Super Werkzeug. Ich würde es auch einsetzen, wenn da nicht die verdrahtete Formatierung der Vorlage Literatur und Internetquelle mit den Zeilenumbruch wäre. Eigentlich wäre der Konflikt, der dadurch die zwangsweise Umformatierung entsteht doch recht einfach zu lösen. Wenn das Script beim Einlesen erkennt, dass in der Vorlage ein Zeilenumbruch verwendet wird, formatiert das Script die betreffende Vorlage, wenn kein Zeilenumbruch erkannt wird, formatiert es die Vorlage nicht um. Der Delimiter "|" sollte der Lesbarkeit wegen immer von einem Space umgeben sein. Gruß -- Ulanwp (Diskussion) 21:34, 29. Mai 2016 (CEST)
Danke für das „Super Werkzeug“.
Es wird aber keine Erkennungs- und Rumrateformatierungslogik geben. Das Werkzeug ist komplex genug, und es ist schwierig genug, es auf dem Stand robust zu halten und wonotwendig auszubauen.
Es gibt viele Autoren mit vielen Wünschen, die an einem Artikel schreiben, aber nur einen gemeinsamen Artikel-Quelltext.
Der eine will alle Gleichheitszeichen untereinander, und dann noch mindestens ein Leerzeichen links und rechts daneben, der nächste auf keinen Fall Leerzeichen, weil dann die Zeile womöglich nicht mehr in einem Stück in das Textbearbeitungsfeld passt, also weder am | noch am =, der nächste will immer und überall alles in einer einzigen Zeile hintereinander weg haben.
Ich habe vor fünf Jahren ein damals schon flächendeckend gebräuchliches Format ausgewählt, mit dem im Prinzip alle leben können, und nur manche nur ein wenig jammern. Sonst jammern wieder andere.
Wozu ich stehe, ist am Ende des Artikels die zeilenweise Anordnung der heutzutage 60 möglichen Parameter der Vorlage:Literatur, und Internetquelle langfristig auch bald 50. „sollte der Lesbarkeit wegen“ schon so sein; weil da ganz hinten stört es keinen mehr. Und deine Mit-Autoren müssen das auch noch übersichtlich lesen können.
OK, I see ..., danke für deine ausführlich Antwort. Dann werde ich wohl weiter mit meinen eigenen Scripten auf meinem Mac arbeiten müssen. Gruß -- Ulanwp (Diskussion) 22:15, 29. Mai 2016 (CEST)
Personendaten
Letzter Kommentar: vor 8 Jahren5 Kommentare4 Personen sind an der Diskussion beteiligt
Hallo, PerfektesChaos, könnte es sein, dass WSTM versucht, GEBURTS-/STERBEDATUM in den Personendaten mit dem Artikelkopf abzugleichen? Wenn nein, entschuldige die Störung, dann muss der Fehler irgendwo bei mir liegen. Wenn ja, geschieht das nicht mit der gebotenen Vorsicht: Konstruktionen mit 'oder' wie in Luigi Ricci werden zerstört. Gruß, Griot (Diskussion) 17:47, 30. Mai 2016 (CEST)
Da hat sich wohl ein gefährliches Halbwissen angesammelt.
Teile von WSTM wussten, dass es dort ein Wiki der WMF gibt.
Teile von WSTM wussten das bis heute noch nicht.
Ich habe das heute im Quellcode mal überall klargestellt.
Effekt: Jetzt wird überhaupt nichts mehr geändert.
Ist nicht top, aber richtet erstmal keinen Schaden an.
Die Programmierung, die sich mit der Umwandlung von URL in Wikilinks befasst, ist fast fünf Jahre alt und völlig abgehängt.
Um sie auf heutigen Stand der Technik zu bringen, bräuchte ich mehrere Monate bei kühlerem Wetter, aber dazu lasst ihr mir ja keine Zeit. Es stapeln sich dort schon diverse Bugs.
Zu diesem Server:
Es hat Spezialitäten damit, die WSTM jetzt durcheinanderbrachten.
Neben einem normalen Wiki liegen dort gleichzeitig andere Dokumentpfade wie bei einer normalen Website.
Das irritierte WSTM.
Anders als alle anderen Server befindet sich das Ding nicht im Rechenzentrum von Wikimedia, sondern bei einem externen Dienstleister einige 100 Meilen entfernt.
Grund: Wenn das Rechenzentrum vom Tornado weggeweht wird, kann über diesen externen Server der Wiederaufbau koordiniert werden; oder bei banalem Stromausfall oder Hacker-Angriff.
Immer gern, ich wunderte mich lediglich warum der Diff anzeigte, dass ich etwas aus einem Weblink gelöscht hätte. Das hätte durchaus sein können, weil ich ja auch den ein oder anderen Link anpasse. Hier war ich aber eigentlich sicher, dass ich das nicht getan hatte.
5. Zu diesem PC
der ist auch ohne meine Anfragen schon am Limit und ächzt bei jedem neuen Ping.
Ja sorry, ich weiß, ich sollte dich nicht mit jedem PiPaPo belästigen.
Danke für die Erklärung, aber das bleibt nicht wirklich hängen. Server und wie die arbeiten sind Dinge, die mir zu fern sind. --Liebe Grüße, LómelindeDiskussion16:04, 31. Mai 2016 (CEST)
WSTM manuell starten
Letzter Kommentar: vor 8 Jahren9 Kommentare3 Personen sind an der Diskussion beteiligt
Moin Moin PerfektesChaos und hallo allen Mitlesenden, ich habe eine Frage zum WSTM. Ich teste das Tool gerade und finde es echt super, es erleichtert echt mal einiges im Quelltext. Allerdings ist es mir jetzt auch schon zwei drei Mal aufgefallen, dass es bei ein Paar Artikel nicht das gewünschte erzielte. Deswegen die Frage, ob man den WSTM auf Konpfdruck starten könnte, zum Beispiel via einem Butten in der Werkzeugleiste? Hast du da irgendwas? mfg --Crazy188017:35, 31. Mai 2016 (CEST)
Schön, dass es dir gefällt.
Es sind viele Gestaltungen nach Herzenslust möglich. Standard ist, dass beim Öffnen zur Bearbeitung im ANR automatisch gestartet wird.
Du kannst auch die Automatik unterbinden und erst auf Knopfdruck starten, dir deine persönlichen Buttons mit dem Aufruf verbinden, andere Namensräume einbeziehen und vieles mehr. Die Seiten im Umfeld dieses Links versuchen zu erklären, wie das geht.
Hallo ihr, ich habe mal ein Template-Snippet gebaut zum einfachen Einfügen (in die eigene .js, wenn genehm auch in der Doku):
// [[Benutzer:PerfektesChaos/js/WikiSyntaxTextMod/usage/advanced]]mw.libs.WikiSyntaxTextMod={api:{},config:{load:{inhibit:true,after:function(){// only for mw.user.options.get( 'usebetatoolbar' )if(mw.toolbar){$.when(mw.loader.using('ext.wikiEditor.toolbar'),$.ready).then(function(){$('#wpTextbox1').wikiEditor('addToToolbar',{section:'main',group:'format',tools:{syntax:{label:'WSTM',type:'button',icon:'//upload.wikimedia.org/wikipedia/commons/thumb/2/2d/Nuvola_web_broom.svg/22px-Nuvola_web_broom.svg.png',action:{type:'callback',execute:mw.libs.WikiSyntaxTextMod.api.run}}}});});}}}}};mw.loader.load("https://en.wikipedia.org/w/index.php?title=User:PerfektesChaos/js/WikiSyntaxTextMod/r.js&action=raw&ctype=text/javascript");
Moin Moin @Perhelion:, vielen vielen Dank, dass mit der obersten Zeile hatte ich mir schon fast gedacht, weil er ja sonst keinen Startaufruf beginnt. Ich habe es eingebaut und es läuft wie gewünscht. In die Doku sollte man es auf jeden Fall mal eintragen, damit man es schneller einbauen kann. Übernimmst du das oder soll ich es einbauen? mfg --Crazy188010:27, 4. Jun. 2016 (CEST)
Auf die Doku kommt das ganz sicher nicht.
Schon, weil ich keine Verantwortung für den Inhalt übernehme.
Maximum ist eine Fußnote mit Link auf eine anderweitige Benutzerseite, wo dann sonstwas stehen mag.
Das snippet beißt sich mit allen anderen Beispielen auf der Doku.
Wenn man es ausführt, zerstört man sämtliche anderen Beispiele auf der Doku.
Wenn man etwas anderes von der Doku macht, dann zerstört man das snippet.
Um vorbildlich zu sein, muss man das schon geschickter anstellen.
Code-Kritik:
Man schreibt grundsätzlich erst die Optionen und lädt danach den Code. Es ist zwar unwahrscheinlich, dass der Code bereits ausgeführt würde, bevor die Konfiguration gesetzt ist, aber könnte irgendwie eines Tages mal passieren. Schon um des richtigen Verständnisses willen ist aber die richtige Reihenfolge eeinzuhalten.
WikiSyntaxTextMod_Run ist nur eine Bequemlichkeitsfunktion für manuelle Aktivitäten. Wenn man schon auf mw.libs ist, dann wäre globales .run() zu nutzen, falls es zur Weiternutzung empfohlen wird.
Das ist jetzt nur ein Beispiel für eine Art von Toolbar; es gibt bei der Quelltextbearbeitung aber drei verschiedene: einfach, wikieditor und wikEd.
Info:
Im Herbst/Winter, mit der nächsten Regen- und Kältezeit, wird auf mw.hook umgestellt.
Damit kann der Weg über mw.libs entfallen, die zwar weiterhin genutzt werden und voll kompatibel sind, aber es wird deutlich robuster und übersichtlicher.
Okai PerfektesChaos, auch verstanden, wie würdest du denn das Snippet oben gestalten, dass ich es manuell starten kann? mfg --Crazy188021:48, 4. Jun. 2016 (CEST)
Für dich persönlich wird es wohl erstmal funktionieren.
Es wird dann ein Problem geben, wenn du weitere Optionen setzen möchtest und mal schnell eine Funktionalität auskommentieren oder wieder aktivieren möchtest, oder dir Beispiele von der Doku-Seite kopieren und kombinieren möchtest.
Ich weiß auch nicht, ob du grad diese Toolbar benutzt; ich selbst habe die nicht.
Deshalb ist es für Doku ungeeignet und zu speziell.
Im Übrigen müsstest du das mit dem Skriptersteller klären.
Aja so etwas in der Art habe ich schon befürchtet. ^^ Im Prinzip ist der Code nichts weltbewegendes (hier noch eine evtl. interessante Erklärung zu dem when-ready von Krinkle, das bcache ist nun wohl auch gänzlich obsolete)
Das vermeintliche Konkurenz-Produkt von TMg hat schließlich von Hause aus diesen, sogar einen Stufenweisen (mit markiertem Text).
@WikiSyntaxTextMod_Run: verwundert mich jetzt ein wenig, da du diesen Befehl ausgiebig in deiner Doku propagierst. Naja, nehmen wir ihn (hiermit) raus.
Die .js von Benutzer:Crazy1880 müsste, wenn überhaupt, Permalink sein.
Die aktuelle könnte Tausende von Zeilen enthalten, aber den fraglichen Passus nicht.
Sinnvoll ist eine .js trotzdem nicht, weil ihr die einleitenden Worte und Erläuterungen fehlen; so etwa der Hinweis, welches der drei gebräuchlichen Quelltext-Werkzeugleistensysteme bestückt wird, und wie wann wo mit weiteren auf der Doku-Seite beschriebenen Optionen umzugehen wäre, und dass hier noch mit mw.libs gearbeitet wird (während die neue Generation nur über mw.hook nach Ende der Sommerpause schon auf der Tagesordnung steht).
af@TMg ist ausdrücklich nur für die interaktive Auslösung, teils ziemlich einschneidende Änderungen mit Nebenwirkungen und zwingend erforderlicher Diffkontrolle wegen leicht möglicher unbeabsichtigter Änderung von Linkzielen usw. geeignet. WSTM hingegen ist für vollautomatischen Betrieb mit bei ausgetesteter Version in der Regel nach außen unbemerkbaren Veränderungen konzipiert. Ergo ist die manuelle Auslösung hier nicht der Standardfall.
bcache=1 könnte ja mal wieder modern werden, auch wenn Krinkle aller Welt aufzuschwatzen versucht, man müsse ausnahmslos jede in die Seite eingebundene Ressource (Bildchen, style oder Skript) bei jedem einzelnen Seitenaufruf kontrollieren, ob sie sich nicht vor ein paar Sekunden auf dem Server geändert hätten.
Jede dieser Aktualitätsabfragen für jede einzelne Ressource kosten 2 kB Netzwerktraffic.
Der Wikipedia-Ball links oben oder haben sich aber in einem Jahrzehnt nicht sichtbar geändert, und selbst wenn sie mal um drei Tage „veraltet“ wären, würde das die Seite nicht beeinträchtigen.
Ich habe ein Add-On zu laufen, das die HTTP-Atttribute der paneMarker-Icons, und weiterer Dateitypen, der beiden „Powered by“ da ganz unten, den Logo-Ball und alle URL mit bcache=1 drin von maxage=0 auf maxage=604800 umschreibt bzw. vorhandenes maxage belässt. Die Skripte haben eine Haltbarkeit von mehreren Tagen, WSTM überprüft sich mindestens einmal pro Stunde intern.
Vielleicht kommt bcache=1 also eines Tages wieder auf den MW-Server.
Letzter Kommentar: vor 8 Jahren7 Kommentare2 Personen sind an der Diskussion beteiligt
Ich weiß das ist nichts wichtiges, aber könnte WSTM bitte |Datum=TT. MM JJJJ gleich behandeln wie das beim |Jahr=TT. MM JJJJ passieren würde, dass also beide im Ergebnis zu |Datum=JJJJ-MM-TT werden? --Liebe Grüße, LómelindeDiskussion06:54, 2. Jun. 2016 (CEST)
aus
wird
soll
{{Literatur|Titel=Test|Datum=1. April 2009}}
{{Literatur|Titel=Test|Jahr=1. April 2009}}
{{Literatur|Titel=Test|Datum=1. April 2009}}
{{Literatur|Titel=Test|Datum=2009-04-01}}
{{Literatur|Autor= Zerong Wang|Hrsg= |Titel= ''Comprehensive Organic Name Reactions and Reagents''|Sammelwerk=|Verlag=John Wiley & Sons|Ort=New Jersey|Jahr='''2009'''|Seiten= 1991–1995|ISBN= 978-0-471-70450-8}}
{{Literatur|Autor= Zerong Wang|Hrsg= |Titel= ''Comprehensive Organic Name Reactions and Reagents''|Sammelwerk=|Verlag=John Wiley & Sons|Ort=New Jersey|Datum='''2|Seiten= 1991–1995|ISBN= 978-0-471-70450-8}}
{{Literatur|Autor= Zerong Wang|Hrsg= |Titel= ''Comprehensive Organic Name Reactions and Reagents''|Sammelwerk=|Verlag=John Wiley & Sons|Ort=New Jersey|Datum=''20|Seiten= 1991–1995|ISBN= 978-0-471-70450-8}}
Die abgeschnittene Fettung sollte nicht auf die nachfolgenden Parameter wirken, ebenso eine möglicherweise vorgefundene Kursivsetzung. --Liebe Grüße, LómelindeDiskussion10:46, 2. Jun. 2016 (CEST)
Ich lasse dir diese Exemplare "'Datum' mit Wikisyntax" incategory:Wikipedia:Vorlagenfehler/Vorlage:Literatur/Parameterfehler mal noch offen, sonst schimpfst du wieder, dass du keine Beispiele mehr findest. Ob es auch kursive gibt weiß ich nicht, war nur so der Spieltrieb in mir das auch zu testen. --Liebe Grüße, LómelindeDiskussion12:59, 2. Jun. 2016 (CEST)
Arrgh, der neue Parameter ist noch keinen Monat alt und wird schon wieder eingesaut.
Okay, war nur erforderlich gewesen, eine Zeile ein paar Zeilen höher zu schieben, damit Jahr, Abruf und Datumgleichermaßen interpretiert und konvertiert werden. Null Bytes Größenänderung, danke.
Den kannte ich schon; kam durch den Apri drauf.
War schon programmiert gewesen; schneidet nunnmehr erst ab, wenn die ersten vier Zeichen auch Ziffern sind und ein Bindestrich ggf. folgen würde und dann ein bis zwei Ziffern und …
Ich müsste einfach mal Zeit und erträgliche Temperaturen haben, um das austesten zu dürfen, was ich programmiere, dann könnte ich es auch freischalten.
Och menno, nichts mache ich richtig, ja Monate, ich weiß, aber ich hatte keine Lust mehr auf Monate. O.k. schon gut, ich kehre zurück an den Ort, wo ich hin soll. Warum muss hier immer alles so „gefährlich“ sein?
Letzter Kommentar: vor 8 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt
Moin Moin PerfektesChaos, ich tue hier mehr und mehr Artikel auf, die mit der Vorlage {{BibISBN}} eingebunden sind und wo das WSTM schreibt, dass das Zugriffsdatum jjjj-mm-tt sein sollte. Siehe hier. Ist das dann dort so richtig??? mfg --Crazy188019:52, 3. Jun. 2016 (CEST)
Zugriff kann man doch nicht pauschal vorgeben, ich würde sagen der Parameter müsste innerhalb der Vorlage leer sein. Da soll man wenn, dann doch eintragen wann man es selbst abgerufen hat. Das sollte ein Optionaler Parameter sein, oder? --Liebe Grüße, LómelindeDiskussion06:41, 4. Jun. 2016 (CEST)
Den Zugriff/Abruf kann man sehr wohl pauschal angeben, weil sich das auf immer denselben Weblink bezieht, der in der Vorlage angegeben ist.
Ja, in den BibISBN-Vorlagen kann oder sollte allmählich das ISO-Format für den Abruf benutzt werden.
Allerdings wird der Parametername „Abruf“ noch nicht verstanden.
In der nächsten Woche, wenn ich dann anschließend auch ein paar Tage onwiki bin, um bei Problemen eingreifen zu können, plane ich unter den vielen anzupassenden Elementen auch Vorlage:BibRecord/Literatur dahingehend umzuschreiben, dass es die Vorlage:Literatur mit den aktuellen Parameternamen und Parameterformaten einbindet. Damit verschwinden alle Meldungen, weil die BibISBN & Co. alle durch diese Vorlage laufen.
Ab Sonntag bin ich jedoch ein paar Tage offwiki.
Wenn alle Voraussetzungen geschaffen wurden und alle zwischendurch eingebundenen Vorlagen beide Arten von Parameternamen verstehen, sollen per Bot sämtliche BibISBN & Co. auf die neuen Parameternamen und Parameterformate umgestellt werden.
Upps; geklammerte Weblinks und URL sind keine einfachen Zeichenketten, sondern komplexe Gebilde, weshalb WSTM sich gedacht hatte, hier wäre gar kein Online-Parameter vorhanden und deshalb die Online-Attribute eliminierte. Gefixt. Danke --PerfektesChaos18:40, 4. Jun. 2016 (CEST)
Allerley Mekwürdiges
Letzter Kommentar: vor 8 Jahren6 Kommentare3 Personen sind an der Diskussion beteiligt
ja ich weiß persönliche Einstellung, nicht normales WSTM. Das auch nur weil ich es recht lustig fand. Da musst du nichts machen, nur mal so zum anschauen. Der Link war eh toter als lebendig.
Beispiel: Gerd Becht – Nr. 135, ISSN 0017-7296, 17/18/19.7.2015
Nach dem Titel im Archiv suchen.
Handelsblatt print hat 17.07.2015
17. war ein Freitag, der 18./19. sind Wochenende und Quatsch. Da erschien das nicht.
Der 17.7.2015 war der 198. Tag in jenem Jahr, in der 29. Woche.
Wenn es die 135. Tagesausgabe war, kann es nur ein Freitag sein. 29 Wochen minus ein paar Oster- und Pfingstfeiertage und 1. Mai lassen keinen andern Schluss zu, die erste Kalenderwoche 2015 hatte auch nur einen Erscheinungstag. Das Blatt kommt demzufolge offenbar an 5 Tagen die Woche.
ISSN und Nr. 135 kannst du tonnen, wenn Zeitung verlinkt, und die Ausgabennummer hilft genau niemandem nix weiter. Der Autor hätte den korrekten Tag angeben sollen und die Schnörkelei bleiben lassen sollen.
Handelsblatt kannst du nach diesem Muster korrigieren.
Sächsische Zeitung nur einen pro Woche, derselbe Autor.
Hallo RonMeier, was meinst du denn genau? Ich sehe nichts auffälliges. Jahr und Datum sind dort tatsächlich doppelt vorhanden, das musst du von Hand lösen.
Argh, wieso ist mir das denn nicht aufgefallen? Den Artikel habe ich doch erst vor Kurzem bearbeitet. Das wurde da aber noch nicht als Fehler angezeigt. --Liebe Grüße, LómelindeDiskussion16:17, 7. Jun. 2016 (CEST)
Beim Öffnen erscheint unter anderem "Zweite schließende Klammer gesetzt doi:10.1007/s00213-002-1250-8" Ich sehe nur, dass WSTM die letzte Klammer bei der DOI entfernt. Gruß
Bei mir steht dort nichts, weder wird eine Klammer hinzugefügt noch kommt eine Meldung. Der Eintrag sieht bei mir so aus
D. C. Turner, T. W. Robbins, L. Clark, A. R. Aron, J. Dowson, B. J. Sahakian: Cognitive enhancing effects of modafinil in healthy volunteers. In: Psychopharmacology. Band 165, Nummer 3, Januar 2003, ISSN0033-3158, S. 260–269, doi:10.1007/s00213-002-1250-8, PMID 12417966.
Im Diff steht in dem Bereich keinerlei Änderung und eine rote Meldung habe ich auch nicht. Warte ich teste das mal einzeln auf der Spielwiese. Nein bei mir passiert da nichts. Hast du da eine Anpassung in deinem Skript? --Liebe Grüße, LómelindeDiskussion16:53, 7. Jun. 2016 (CEST)
Ló: Du hattest am 12. April bearbeitet. Da standen vorher schon beide drin.
Lua gibt es aber erst seit Pfingsten, also Mitte Mai.
Erst seitdem wiird die Doppelvergabe beanstandet.
Irgendwer muss in die damalige Vorlagenprogrammierung reingeschrieben haben, dass auch Datum= ein bekannter Parameter sei. Ich weiß aber nicht, wie das damals ausgewertet worden wäre und wer gesiegt hatte, und habe auch keine Lust, es herauszufinden. Jedenfalls wurden bis Mai ohne Fehlermeldung beliebige Angaben gleichzeitig akzeptiert.
WSTM sieht übrigens Datum= inzwischen als heimlichen Pflichtparameter an und bietet immer ein Feld zum späteren Ausfüllen an; wenn aus irgendwelchen Gründen noch Jahr= drinsteht, gibt es eine Verwarnung.
Hans-Ulrich Meisch, Johannes A. Schmitt: Mycophosphatin from the Mushroom Agaricus macrosporus. In: Environmental Health Perspectives. Band65, 1986, S.29–32, PMC 1474717 (freier Volltext) – (englisch).
Hans-Ulrich Meisch, Johannes A. Schmitt: Mycophosphatin from the Mushroom Agaricus macrosporus. In: Environmental Health Perspectives. Band65, 1986, S.29–32 (englisch).
Eigentlich wollte ich heute wirklich nichts mehr hier schreiben, weil ich ein arg schlechtes Gewissen habe wenn ich dir immer so viel Zeit stehle, aber das sollte besser nicht passieren, oder? Das hätte ich fast übersehen. Hat vermutlich etwas mit der Anpassung von Originalsprache auf Sprache zu tun. Ich glaube es betrifft nur diesen einen Parameter. --Liebe Grüße, LómelindeDiskussion16:54, 7. Jun. 2016 (CEST)
Sowas (grundloser Informationsverlust) ist ja auch wichtig.
Oberlandesgericht Köln (Hrsg.): [http://www.olg-koeln.nrw.de/presse/archiv/archiv_2013/011_PM_12-06-2013.pdf ''Prämien des Miles]<!-- sic --> & <!-- sic -->More-Programms müssen frei übertragbar sein – Senat hält Einschränkungen in den Allgemeinen Geschäftsbedingungen der Lufthansa für unwirksam.''] Pressemitteilung 11/13 vom 12. Juni 2013.
Ich sehe die unsichtbaren Kommentare, WSTM sieht sie scheinbar nicht oder sagt der geklammerte Weblinktext endet vor einem <, danach erwarte ich nichts mehr. Ich kann die Sics ja entfernen, aber wer weiß, ob so etwas des Öfteren vorkommt. Ist nichts dringendes. --Liebe Grüße, LómelindeDiskussion09:17, 8. Jun. 2016 (CEST)
Offenbar sind zwei Kommentare im Linktitel zu viel, um die schließende Klammer wiederzufinden.
Mit einem geht es anscheinend, sonst hätte es viel mehr Beschwerden im Lauf der Jahre gegeben.
Weil ja auch die schließende Klammer auskommentiert sein mag, und die langjährige Wirkung solcher Konstrukte unklar ist, hat WSTM hier ein Problem.
Die Programmierung ist von 2012, und ich weiß nicht mehr so genau, was ich gemacht hatte.
Im Prinzip könnte ich nicht nur hinter den ersten, sondern hinter beliebig viele Kommentare im Linktitel gucken, um die schließende Klammer zu finden. Dafür bräuchte ich aber in der kühlen Jahreszeit mal mehrere Monate ohne andere Aufgaben, um den gesamten Bereich URL mal aufzuarbeiten und zu modernisieren.
Die Klammer steht dort, eigentlich sieht das richtig aus und ich wüsste auch nicht wohin mit der Klammer. Bis nach „Ulm“ komme ich damit hinter „und“ wäre schon zu weit weg. Jaha, ich kann es irgendwie anders machen, allein schon weil ich so ellenlange Linktitel nicht mag, aber … --Liebe Grüße, LómelindeDiskussion13:39, 20. Jun. 2016 (CEST)
maxTitle = 200;
maxURL = 150;
maxWikilink = 200;
Heißt: Wenn nach 200 Zeichen im Titel keine schließende Klammer gefunden wurde, geht WSTM davon aus, dass sie vergessen wurde und längst der normale Text fortgesetzt wird.
Genauso die maximale Länge einer URL und eines Wikilinks.
Mach einen Ersatztitel Memorandum of Understanding draus und setze diesen ganzen Quatsch kursiv außerhalb des Weblinks fort.
Ja, das MaxLänge dachte ich mir schon irgendwie. Probleme habe ich manchmal eher mit maxUrl weil ich keine kürzere finde, aber die Meldung dazu ist mir vertraut. --Liebe Grüße, LómelindeDiskussion14:00, 20. Jun. 2016 (CEST)
Info: wenn im Link ein Pagename oder Seitentitel eingebunden wird
Letzter Kommentar: vor 8 Jahren11 Kommentare3 Personen sind an der Diskussion beteiligt
Moin Moin PerfektesChaos, ich bin mir nicht ganz sicher, aber bei mir startet WSTM weder im manuellen noch im automatischen. Gibt es derzeit Probleme? mfg --Crazy188007:01, 17. Jun. 2016 (CEST)
O.k. ich stelle mal meine WSTM-Version um und schaue, ob ich etwas finden kann. Alternativ kannst du mal Strg, Shift und K drücken falls du Firefox benutzt. Oder anders welchen Browser benutzt du? --Liebe Grüße, LómelindeDiskussion07:45, 17. Jun. 2016 (CEST)
Wenn du es dringend benötigst kannst du mal kruzfristig dein WSTM auf die d-Version umstellen, dann sollte es funktionieren. Das ist allerdings nur für die Softwaretester gedacht. Schau mal die Änderung in meiner →.js an. Ich weiß nicht wann PerfektesChaos sich hier meldet. Das wäre als Überbrückung bis dahin. --Liebe Grüße, LómelindeDiskussion08:07, 17. Jun. 2016 (CEST)
Ja, die Volksausgabe (r) wurde vorgestern Abend fehlerhaft aus der Test- und Entwicklungsversion (d) generiert.
Inzwischen behoben.
Weil ich und die Vorkoster mit der d-Version und noch früher arbeiten, können wir keine Fehler in der r-Version bemerken.
Echt jetzt, ich habe versucht bei der Nummer einen Fehler zu finden, ich vermute aber es geht um etwas anderes. Redundante Parameter ISSN/ZDB. Nur, was genau mache ich damit jetzt, wenn zudem das Sammelwerk verlinkt ist?
Ja ich weiß beide Angaben rauswerfen und wie begründe ich das, damit ich keinen Ärger bekomme?
Irgendwie bin ich zwar darauf gekommen, aber kann das jeder verstehen, was er damit machen soll, wenn er „Vorlagenparameter fehlerhaft“ liest? Ich dachte vielleicht passt da etwas mit dem Format nicht oder mit der Länge der Angabe, oder …, keine Ahnung aber an redundante Parameter dachte ich dabei nicht. Jetzt weiß ich es natürlich. RTFM(s) ‹seufz›. --Liebe Grüße, LómelindeDiskussion08:15, 19. Jun. 2016 (CEST)
Es war die Länge bzw. Kürze der 1372, die WSTM misstrauisch gemacht hatte.
Die DNB hat keine detaillierten Angaben veröffentlicht, wie ihre diversen Schlüsselnummern in den unterschiedlichen Anwendungen aussehen dürfen oder müssen.
Demzufolge hangel ich mich auch nur an Beobachtungen durch.
Die bislang kürzeste gefundene ZDB-ID war ZDB-ID 94467-1 gewesen.
Eigentlich sind die Nummern bei der DNB mehr so sechsstellig plus Prüfzffer. Das ist aber irgendwie über viele Jahrzehnte gewachsen.
Ich habe den Quellcode von 2012/13 über die neuen Erkenntnisse informiert.
Gleichzeitige ZDB und ISSN sind zwar nicht erwünscht, werden aber seit den Luxemburger Archies toleriert. Wenn das ISSN-Link weniger informativ ist, mag ZDB geduldet dabeistehen. Übernächstes Jahr wird man wohl mal alle diese Fälle kontrollieren müssen, ob sie ihre Berechtigung haben. Hier steht bei der ZDB-ID deutlich mehr als bei der BKS zur ISSN.
Letzter Kommentar: vor 8 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Guten Morgen! Könntest du bitte nach der Zeile FNZBox| einen Zeilenumbruch setzen, damit auch die erste Anmerkung in eine neue Zeile kommt, nicht nur alle anderen? Danke, --Hadibe (Diskussion) 05:53, 20. Jun. 2016 (CEST)
Ich kenne diese Vorlage und ihr Spezialproblem.
Die Schiffsinfobox hat auch so ihre Meacken.
Generell ist dieser Umgang mit unbenannten Parametern eigentlich nicht erwünscht und diese Pipe am Ende einer Zeile auch nicht, aber bei der FNZBox in ihrer überlieferten Form kaum anders zu machen.
Um da was dran zu ändern, müsste ich mich tief in Code einlesen, den ich vor vier Jahren mal geschrieben hatte, und ein relativ komplexes Konzept zur sauberen Abdeckung solcher Fälle erarbeiten.
Dazu bin ich derzeit völlig überlastet und habe haufenweise Tagesgeschäft zu liegen.
Vielleicht 2017.
Momentan habe ich hitzefrei und mache möglichst nur Kleinkram und dringende Wartung, fange aber nichts Neues mehr an.
Letzter Kommentar: vor 8 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
G. Meyer (Hrsg.): Die Arabische Welt im Spiegel der Kulturgeographie. – Veröffentlichungen des Zentrums für Forschung zur Arabischen Welt (ZEFAW), Band 1, Mainz 2004. ISBN: 978-3882503302
Ich wurde etwas stutzig, weil eigentlich ISBN: erkannt, der Doppelpunkt entschwinden und die fehlenden - Trennstriche erscheinen würden, was diese geschützten Leerzeichen da zu suchen haben weiß der Geier. Das eine direkt vor dem I verhindert jedenfalls eine Anpassung. Ich schätzte mal so etwas kommt nicht wirklich oft vor. Aber ich dachte ich zeige es dir trotzdem mal. Es lohnt aber sicherlich nicht sich deshalb Gedanken zu machen. --Liebe Grüße, LómelindeDiskussion16:16, 20. Jun. 2016 (CEST)
{{Literatur |Autor=Michael Fleck |Titel=Vitalisnacht und Vitaliskreuz in Hersfeld |Sammelwerk=Zeitschrift des Vereins für hessische Geschichte (ZHG) |Band=115 |Verlag=Selbstverlag des Vereins für hessische Geschichte |Ort=Kassel |Datum=2010 |ISSN=0342-3107 Online |Kommentar=Seite 21 bis 32}}
Mal abgesehen davon, dass es eh Murks ist. Auch nur zum anschauen, ich vermute, dass ist eher ein Einzelfall.
WSTM analysiert den Wert des ISSN-Parameters und diverser anderer Codes dann und nur dann, wenn es eine einfache Zeichenkette ist.
Das hier ist aber keine einfache Zeichenkette, sondern enthält verlinkende Wikisyntax wie URL, Vorlageneinbindung oder geklammerte Links und ist damit ein strukturiertes Kompositum.
Der Programmierer von WSTM weiß, dass ein strukturiertes Kompositum durch den Programmierer von V:Lit ohnehin nicht goutiert würde und dort zu einer Fehlermeldung führt.
WSTM kann die Bedeutung des Kompositum ohnehin nicht verstehen und nichts machen. Einfache Zeichenketten werden hingegen auf Syntax analysiert.
Vermutlich auch selten aber hier geht ein > verloren
Letzter Kommentar: vor 8 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Das habe ich beinahe trotz Meldung (Fehlendes '>' als Ende des Tag <references / [[Kategorie:Neue Musik]]) übersehen, weil ich auf etwas anderes geachtet habe.
<references/>[[Kategorie:Neue Musik]]
<references /
[[Kategorie:Neue Musik]]
Ob so etwas mehr als einmal vorkommt, kann ich nicht sagen ich bin einfach zu ungeschickt mit diesen Parametern für die richtige Suche. Manchmal ist es wirklich lustig WSTM mopst heimlich ein > und sagt dann zu mir hey Kleines, pass auf! Da fehlt etwas, nämlich ein >. --Liebe Grüße, LómelindeDiskussion14:19, 24. Jun. 2016 (CEST)
Das liegt an der Abfolge der Verarbeitungsschritte; der Analysierer für die Tags geht nach dem von der Kat durch und findet das selbst verschluckte > als Unstimmigkeit.
Von diesem Fehlertyp lese ich in den 4 Jahren der aktuellen Programmierung zum ersten Mal; soll sicher nicht passieren, aber im Stapel der in der kalten Jahreszeit zu beseitigenden Bugs kommt es wohl ziemlich weit nach unten.
Es geht wohl um das gleichzeitige Einfügen des Leerzeichens vor / und Sicherung eines obligatorischen Zeilenumbruchs nach jedem references und Sicherung eines obligatorischen Zeilenumbruchs vor jeder Kategorisierung; da hat sich irgendwas verzählt.
Nee, es geht auch mit einem </references>, da wird es auch weggeschluckt. Du weißt doch, ich bin ein Spielkind und habe das auch mal probiert. Ich dachte auch erst, dass es an dem eingefügten Leerzeichen liegt.
Es könnte auch jedes andere schließende Tag sein.
</ref></small></code> oder </div> völlig egal, es darf da kein >[[Kategorie: stehen. Das macht die Fehlersuche möglicherweise einfacher. --Liebe Grüße, LómelindeDiskussion13:06, 25. Jun. 2016 (CEST)
Könnte das auch bei den Sueben URL gekostet haben?
Im Übrigen beabsichtige ich langfristig, ein JavaScript- und WSTM-freies Tool zur Verfügung zu stellen, das cite in die hiesige Vorlagen konvertiert, wobei WSTM das sogar automatisiert könnte, und was, so es denn einmal liefe, weniger fehlerträchtig wäre als manuelles Umschreiben.
Korr.: rote Box kommt nach fehlerhafter ISBN nicht in der Diff-page, sondern in der Seitenvorschau. aber alles funktioniert nur manchmal. Gruß --RonMeier (Diskussion) 11:47, 29. Jun. 2016 (CEST)
Da scheint mehr komisch zu sein, ich bekomme beispielsweise meine Bearbeitungsumgebung mit den Werkzeugleisten nur ab und zu angezeigt, ich vermute das hängt zusammen. Die Meldung dazu steht im Report falls das hilft. Falls ich so einen Fehler auch finde kann ich ja mal schauen ob auch eine WSTM-Meldung dort steht. --Liebe Grüße, LómelindeDiskussion11:44, 29. Jun. 2016 (CEST)
Report habe ich gesehen. Aufschlussreich.
Ich habe damit eher nichts zu tun.
Gestern Abend gab es ein neues MediaWiki.
Die Meldung, die im Report steht, ist sehr verräterisch. Ich weiß, wer da letzte Woche was gemacht hatte; dürfte ein weltweites Problem sein. Werden sich rund um den Globus viele beschweren; habe nicht die Zeit, dem nachzugehen.
+1 Moin auch, ich habe auch keine Probleme feststellen können, habe sogar bis nach Mitternacht getestet. Bei 4 Leuten kann man schon mal einen Verdacht äußern, Crazy1880 benutzt die /r. ↔ User: Perhelion01:42, 30. Jun. 2016 (CEST)
Letzter Kommentar: vor 8 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Da ich mich gerade durch Artikel über Schiffe manövriere, ist mir nun endlich aufgefallen wann diese nicht von WSTM beanstandet werden. Ich weiß nicht, ob das irgendwie wichtig ist. Aber ich habe mich manchmal darüber gewundert, warum manche keine kleinen Zahlen vor die Untervorlagen bekommen. Ich habe das nie wirklich verfolgt, aber nun weiß ich zumindest, dass es scheinbar mit dem eingebundenen Bild zusammenhängt. Ist kein Bild vorhanden, dann ignoriert WSTM diese Boxenkombination. Beispiel Batavia (Schiff, 1870). Wenn man dort eine Datei einfügen würde, dann würde WSTM das anmeckern, wie bei allen anderen Schiffsboxen mit Bild. Ich weiß nicht, vielleicht kennst du diesen Auslöser schon und ich quassele dich unnötig voll, aber mir war das bisher nicht bewusst. Vielleicht ist es aber auch nur eine Kleinigkeit, die sich beheben ließe, damit dieses Phänomen ein für allemal verschwindet und ich diese Ziffern nicht immer wieder löschen muss. --Liebe Grüße, LómelindeDiskussion10:56, 7. Jul. 2016 (CEST)
Ausschlaggebend ist der Umstand, dass hier nach benannnten Parametern nochmals unbenannte Parameter auftreten.
Das deutet auf einen Einbindungsfehler hin.
Die Schiffsbox ist die einzige jemals bekanntgewordene Vorlage, die konzeptionell und für Einbindungen diese eigenwillige Konstruktion vorsieht.
Die Dateieinbindung kann nur als zusätzlicher Auslöser wirken; ohne Datei hat WSTM keinen Grund, die Vorlageneinbindung genauer zu analysieren, während bei Dateieinbindungen innerhalb von Vorlageneinbindungen die Pipes zugeordnet werden müssen und deshalb die Vorlage genauer angeguckt wird.
Um mich mit Schiffsbox+WSTM genauer zu beschäftigen, bräuchte ich mal einen Monat Ruhe, in dem ich nichts anderes vorhabe.
Den gibt es aber in 2016 nicht.
Vermutlich sollte man die unbenannten aliasmäßig zukünftig benennen als Teilbox1= usw. und die Einbindungen nach und nach umstellen; ich habe aber absolut keinen Nerv, dazu zwischen den mehreren Hundert Punkten auf meiner ToDo-Liste eine Diskussion mit dem Vorlagenersteller einzutakten.
Ich weiß dass du keine Zeit dafür hast, aber für mich ist es wichtig das irgendwie einordnen oder ansatzweise verstehen zu können. Dankeschön für die Erklärung. Ich bin eh soweit durch mit den Schiffen auf meiner Liste. --Liebe Grüße, LómelindeDiskussion11:54, 7. Jul. 2016 (CEST)
Rote Box verwenden
Letzter Kommentar: vor 8 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Ich möchte in der roten Box eine Info, wenn die ISBN *(978-?)?1-?159 im Text vorkommt. In der WSTM-Anleitung finde ich nur Spezialfälle. Was muss ich tun? Gruß --RonMeier (Diskussion) 11:49, 7. Jul. 2016 (CEST)
„Es ist geplant, das auch nach und nach zu implementieren“
Du kannst die fragliche ISBN ersetzen durch sich selbst plus einen HTML-Kommentar „Das ist ja ein dickes Ding“ – den siehst du dann in der Diff, und am Ende des Monats kannst du mit Cirrus suchen nach den Artikeln, wo der Kommentar übrigblieb.
Letzter Kommentar: vor 8 Jahren8 Kommentare2 Personen sind an der Diskussion beteiligt
Beispiel:
* {{Literatur
|Autor=Slaughter, A.-M. mit K. Raustiala
|Hrsg=Walter Carlnaes, Thomas Risse und Beth Simmons
|Titel=
Considering compliance. In Handbook of International Relations
|Ort=Thousand Oaks, CA: Sage Publications.
|Datum=2001}}
* {{Literatur
|Autor=Slaughter, A.-M. mit K. Raustiala
|Hrsg=Walter Carlnaes, Thomas Risse und Beth Simmons
|Titel=Considering compliance. In Handbook of International Relations
|Ort=Thousand Oaks, CA: Sage Publications.
|Datum=2001}}
Kannst du den Umbruch entfernen lassen? Oh, ich sehe gerade in dieser Ansicht, da muss ich auch noch ein Sammelwerk ergänzen. --Liebe Grüße, LómelindeDiskussion07:08, 17. Jul. 2016 (CEST)
Gleich noch etwas merkwürdiges, warum wird aus |Band=VI → |Band=vi das finde ich doooof. Ich schreibe Lateinische Ziffern immer groß. Band V, Band X und nicht Band v, Band x. Ich vermute mal das soll mir sagen: ‚Kleines siehst du denn nicht, dass das keine vernünftige Ziffernfolge ist, schreib da bitte selbständig Band davor‘. Nein im Ernst, es passiert nur bei VI, LI, MI, nicht hingegen bei XI, DI, CI oder I, die bleiben wie sie sind. Ich dachte eben schon ich spinne langsam. --Liebe Grüße, LómelindeDiskussion07:50, 17. Jul. 2016 (CEST)
Die beliebigen Texte (Autor, Hrsg, Titel, Sammelwerk, Ort usw.) fasse ich/WSTM nicht an; nur die kodierten mit einer bestimmten Syntax. Letztere werden dafür auch getrimmt.
WSTM schreibt werksseitig keine Bandnummern klein, soweit ich das sehen kann.
Nee, danke, bin bedient; da muss ich in irgendeiner kühlen ruhigen Nachtstunde mal forschen gehen. Völlig rätselhaft, wodurch das ausgelöst werden könnte. Verdächtig ist allerdings, dass das genau wie gültige Sprachcodes aussieht, und die werden in der Tat kleingeschrieben. Vielleicht ist da was falsch zugeordnet worden. LG --PerfektesChaos13:16, 19. Jul. 2016 (CEST)
Es war der Sprachcode.
Zwischen der Verarbeitung von Band/Nummer und den Sprachcodes hätte ein break; stehen müssen.
Letzter Kommentar: vor 8 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Ebenso wie hier habe ich das heute bereits schon einmal gesehen. Der Linktext (Frontale) des ersten Links in der Bildbeschreibung wird dort entfernt und oben bei den Parametern eingefügt. WSTM bemängelt dann natürlich den unbrauchbaren Parameter und der Link beschädigt. --Hadibe (Diskussion) 21:10, 17. Jul. 2016 (CEST)
Ja, sorry, dumme Geschichte.
WSTM ist in einer Phase, wo die öffnenden doppelten eckigen Klammern analysiert werden und die dazu gehörenden Pipes und schließenden eckigen Klammern gefunden werden sollen.
Hier öffnet sich vor der Tabelle nochmals ein Wikilink und schließt sich wieder; weil die öffnenden doppelten eckigen Klammern erst noch analysiert werden und dieses Wikilink später kommt, ist es noch nicht richtig als Wikilink verstanden worden.
Nun folgt eine Tabelle mit jeder Menge weiterer Pipes und Wikilinks.
WSTM kann zwar behelfsmäßig vorläufig entweder ein Wikilink oder eine Tabelle in der Bildlegende kapieren, aber das hier ist momentan zuviel.
Zumindest meckert es seinen eigenen Bock dick rot als Fehler an.
Insgesamt ein eher seltenes Phänomen. Bildlegenden sollen kurz und knackig sein, keine Romane.
Es gäbe eine robustere Programmierung, die aber mehrere Monate erfordern würde. Ich erinnere mich mit Schrecken an die verschachtelten Vorlagen, die ein halbes Jahr gedauert hatten. Hier kann jede Bildlegende wieder neue Dateieinbindungen mit Bildlegenden und Tabellen enthalten, in denen wieder Dateieinbindungen mit Bildlegenden vorkommen können. Das lässt sich zwar sauber aufarbeiten, aber zurzeit erkenne ich Tabellen noch nicht als Ganzes, zumal Tabellen wieder andere Tabellen und Dateieinbindungen enthalten können.
Vorlagenparameter fehlerhaft {{Literatur|DOI=10.5675/HyWa_2015,5_2 *** bad selector 'HyWa_2015,5_2' *** bad selector 'HyWa_2015,5_2 *** bad selector 'HyWa_2015,5_2''}}
Ich meine, das Problem kann ich wohl irgendwie lösen [2], aber warum fügt das Tool oder ist es die Vorlage, diesen Hinweis in den Fließtext ein? Ist das Absicht? --Liebe Grüße, LómelindeDiskussion14:54, 19. Jul. 2016 (CEST)
Natürlich nicht.
Der Teil der Fehlermeldung für die rote Box ist mit in den Parameterwert geraten.
Dieses jetzt gefixt.
Ärgerlich obendrein: Es ist eine Falschmeldung.
Lua und WSTM müssen angepasst werden.
Das Komma war von 2014 bis heute pfui baba, muss aber ab sofort erlaubt werden.
O.k. das ist sowieso eine doofe Adresse mit zwei http’s da hätte ich dann aber ein Darstellungsproblem. Ich möchte nur wissen, ob das an meiner Sondereinstellung liegt. Aufpassen müsste dann ja allein ich. Das ist eh eine Krücke dieser Link kommt bei mir nicht weit, weil ich Umleitungen nicht erlaubt habe. Ich tausche den Link sowieso aus. --Liebe Grüße, LómelindeDiskussion12:17, 20. Jul. 2016 (CEST)
Ja, da braucht es noch mehr Technik, um URL in URL sicher zu identifizieren.
Die gibt es bei meist bösen Umwegen über neugierige Fremdserver öfters, aber auch Archivierungen.
Das ist ja süß, ich habe doch erst recht keine Ahnung wie „mir“ das gelingt, es funktioniert soweit ja sehr gut, es war megaumständlich das manchmal für gefühlt hundert Links in einem Artikel umzustellen, weil ich da ja nicht mit „Suche und Ersetze“ arbeiten kann. Ich erwische auch nicht alle, wenn der Link nicht am Anfang steht also irgendein Zeichen davor steht, dann muss ich mir die noch mal ansehen und es von Hand Klammern. Ist aber kein Ding, ich komme damit klar und wie gesagt sah ja auch der Link anschließend ziemlich defektiert aus. Immerhin habe ich ihn so mal spontan angeklickt und habe, denke ich zumindest, eine bessere Lösung(ganz unten) gefunden. --Liebe Grüße, LómelindeDiskussion13:24, 20. Jul. 2016 (CEST)
Vorlagenweiterleitung auflösen
Letzter Kommentar: vor 8 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Ich würde ja tippen, man müsste es hier einbauen, so:
break;
case "GER" :
case "ger" :
r = ["DEU", false, false];
break;
case "GER-ESC" :
case "ger-ESC" :
case "Ger-ESC" :
case "GER-esc" :
case "GER-Esc" :
r = ["DEU-ESC", false, false];
break;
case "Folgenleiste" :
case "folgenleiste" :
case "Folgenleiste multi" :
case "folgenleiste multi" :
r = ["Personenleiste", false, false];
Der Code wurde grundsätzlich richtig verstanden.
Was die GER angeht, werde ich das auch einfach so per C&P übernehmen.
Hingegen wurde die eigenmächtige Umbenennung der „Folgenleiste“ (meinte ursprünglich: Fernseh-Episoden) in „Personenleiste“ noch nie akzeptiert.
Die kann man auch einsetzen für die Rheinbrücken von Basel bis Remagen, oder für Möbel-Stile von Barock über Louis bis Jugendstil. Und dafür klingt „Personenleiste“ doch arg seltsam.
Vielmehr soll der universell programmierte Nachfolger von „Folgenleiste“ heißen: „Folgeleiste“ – und dann passt es zu Star-Wars-Fortsetzungen, Beatles-Alben und auch Personen.
Moin, ah okai, danke für die Erklärung zur Folgenleiste, dann machen wir das wie immer. Danke für die Vorlage GER. mfg --Crazy188007:46, 21. Jul. 2016 (CEST)
Buchstaben-Umwandlung im WMST innerhalb von SORTIERUNG
Letzter Kommentar: vor 8 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Moin Moin PerfektesChaos zum Zweiten, mit ist bei folgendem Namen "Ngọc Sơn" aufgefallen, dass das "ọ" nicht zu einem "o" wird. Könntest du da bei Zeiten mal schauen? Ist nichts mit Prio kritisch, hoch oder mittel. Danke dir --Crazy188019:22, 20. Jul. 2016 (CEST)
Ah, Kleinigkeit.
Liegt in einem etwas abseitigen und sehr speziellen Unicode-Block, soweit war ich noch nicht.
Zusanmmen mit 93 Spießgesellen jetzt zur Erprobung eingepflegt, und Lua auch schon für die hiesige Erweiterung bereit.
Wird im Lauf der kommenden Woche für dich wirksam.
Letzter Kommentar: vor 8 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Warum bleibt sowohl das als auch das als auch das gemeint ist |[sS]prache=eng unbeachtet? Das Literaturbeispiel habe ich nur zugefügt, weil es scheinbar einer ähnlichen Zitationsroutiene folgt eng. würde auch dort merkwürdigerweise erkannt und ersetzt, allerdings geben Englisch English und eng dann wiederum lediglich die Fehlermeldung „Sprachcode ungültig“ aus.
Beispiel:
{{Internetquelle |url=http://chgs.umn.edu/histories/otherness/otherness2.html |titel=University of Minnesota |zugriff=2015-09-27 |sprache=eng}}
{{Internetquelle |url=http://chgs.umn.edu/histories/otherness/otherness2.html |titel=University of Minnesota |zugriff=2015-09-27 |sprache=Englisch}}
{{Internetquelle |url=http://chgs.umn.edu/histories/otherness/otherness2.html |titel=University of Minnesota |zugriff=2015-09-27 |sprache=eng.}}
{{Internetquelle |url=http://chgs.umn.edu/histories/otherness/otherness2.html |titel=University of Minnesota |zugriff=2015-09-27 |sprache=English}}
== Weblinks ==
* {{Internetquelle
|url=http://chgs.umn.edu/histories/otherness/otherness2.html
|titel=University of Minnesota
|zugriff=2015-09-27
|sprache=eng}}
* {{Internetquelle
|url=http://chgs.umn.edu/histories/otherness/otherness2.html
|titel=University of Minnesota
|zugriff=2015-09-27
|sprache=Englisch}}
* {{Internetquelle
|url=http://chgs.umn.edu/histories/otherness/otherness2.html
|titel=University of Minnesota
|zugriff=2015-09-27
|sprache=eng.}}
* {{Internetquelle
|url=http://chgs.umn.edu/histories/otherness/otherness2.html
|titel=University of Minnesota
|zugriff=2015-09-27
|sprache=English}}
* {{Literatur
|Online=http://chgs.umn.edu/histories/otherness/otherness2.html
|Titel=University of Minnesota
|Datum=
|Abruf=2015-09-27
|Sprache=eng}}
== Einzelnachweise ==
<references>
<ref name="DreiFragezeichen">
{{Internetquelle
|url=http://chgs.umn.edu/histories/otherness/otherness2.html
|titel=University of Minnesota
|zugriff=2015-09-27
|sprache=eng}}
</ref>
<ref name="DreiFragezeichen1">
{{Internetquelle
|url=http://chgs.umn.edu/histories/otherness/otherness2.html
|titel=University of Minnesota
|zugriff=2015-09-27
|sprache=Englisch}}
</ref>
<ref name="DreiFragezeichen2">
{{Internetquelle
|url=http://chgs.umn.edu/histories/otherness/otherness2.html
|titel=University of Minnesota
|zugriff=2015-09-27
|sprache=eng.}}
</ref>
<ref name="DreiFragezeichen3">
{{Internetquelle
|url=http://chgs.umn.edu/histories/otherness/otherness2.html
|titel=University of Minnesota
|zugriff=2015-09-27
|sprache=English}}
</ref>
</references>
{{Internetquelle |url=http://chgs.umn.edu/histories/otherness/otherness2.html |titel=University of Minnesota |zugriff=2015-09-27 |sprache=eng}}
{{Internetquelle |url=http://chgs.umn.edu/histories/otherness/otherness2.html |titel=University of Minnesota |zugriff=2015-09-27 |sprache=en}}
{{Internetquelle |url=http://chgs.umn.edu/histories/otherness/otherness2.html |titel=University of Minnesota |zugriff=2015-09-27 |sprache=en}}
{{Internetquelle |url=http://chgs.umn.edu/histories/otherness/otherness2.html |titel=University of Minnesota |zugriff=2015-09-27 |sprache=en}}
== Weblinks ==
* {{Internetquelle
|url=http://chgs.umn.edu/histories/otherness/otherness2.html
|titel=University of Minnesota
|zugriff=2015-09-27
|sprache=eng}}
* {{Internetquelle
|url=http://chgs.umn.edu/histories/otherness/otherness2.html
|titel=University of Minnesota
|zugriff=2015-09-27
|sprache=en}}
* {{Internetquelle
|url=http://chgs.umn.edu/histories/otherness/otherness2.html
|titel=University of Minnesota
|zugriff=2015-09-27
|sprache=en}}
* {{Internetquelle
|url=http://chgs.umn.edu/histories/otherness/otherness2.html
|titel=University of Minnesota
|zugriff=2015-09-27
|sprache=en}}
* {{Literatur
|Titel=University of Minnesota
|Datum=
|Sprache=eng
|Online=http://chgs.umn.edu/histories/otherness/otherness2.html
|Abruf=2015-09-27}}
== Einzelnachweise ==
<references>
<ref name="DreiFragezeichen">
{{Internetquelle
|url=http://chgs.umn.edu/histories/otherness/otherness2.html
|titel=University of Minnesota
|zugriff=2015-09-27
|sprache=eng}}
</ref>
<ref name="DreiFragezeichen1">
{{Internetquelle
|url=http://chgs.umn.edu/histories/otherness/otherness2.html
|titel=University of Minnesota
|zugriff=2015-09-27
|sprache=en}}
</ref>
<ref name="DreiFragezeichen2">
{{Internetquelle
|url=http://chgs.umn.edu/histories/otherness/otherness2.html
|titel=University of Minnesota
|zugriff=2015-09-27
|sprache=en}}
</ref>
<ref name="DreiFragezeichen3">
{{Internetquelle
|url=http://chgs.umn.edu/histories/otherness/otherness2.html
|titel=University of Minnesota
|zugriff=2015-09-27
|sprache=en}}
</ref>
</references>
Wäre es für dich eine Option da, ich weiß das ist eigentlich kompliziert, weil man nie weiß wie jemand etwas abkürzen könnte, den punktlosen Eintrag irgendwie mit abzufragen. Das ist ja lustig, ich habe eben noch mal getestet was passiert wenn ich in der Vorlage:LIT Sprache=ENG einfüge, dann wird es einfach klein zu Sprache=eng Ja ich weiß, Sprache immer klein, aber bei einem punktlosen Engl würde es in beiden Vorlagen groß bleiben, mit Punkt nur in der Lit. Da schließt sich dann auch der Kreis zu meiner Frage von heute Morgen bezüglich des Punktes bei Hrsg=Boston [Mass.]. Einen angenehmen Abend. Dankeschön für die Bd Anpassung. --Liebe Grüße, LómelindeDiskussion18:57, 21. Jul. 2016 (CEST)
WSTM verwendet für Lit und Iq den identischen Programmcode.
Die Darstellung im Artikel ist im Moment unterschiedlich und wird hoffentlich nächstes Jahr ebenfalls identisch, mit demselben Programmcode.
WSTM (und Lua) haben ein grundlegendes Problem:
Was zwei oder drei Kleinbuchstaben sind (und nur das) gilt als Code gemäß ISO 639.
Hier ist eng bereits der fertige Code.
Wobei eng in der ISO 639 ebenfalls für „Englisch“ steht, aber die Wiki-Software für „Englisch“ nur en kennt.
Was mehr als zwei oder drei Kleinbuchstaben sind, gilt als verirrt und normale Sprache und wird versucht zu verstehen und in Code zu übersetzen.
Was zwei oder drei Großbuchstaben sind, gilt als irrtümlich in Großbuchstaben notierter Code nach ISO 639 und wird in Kleinschreibung konvertiert.
Vorlage:Literatur erwartet externe Verlinkungen eigentlich ausschließlich unter Online=.
Da kein Online= gegeben ist, eliminiert WSTM auch gnadenlos die davon abhängigen |Format=|KBytes=|Abruf=. Aus dem gleichen Grund wird auch nichts davon angezeigt.
Arg, ich war wohl blind, du hast Recht. Manchmal sehe ich das gar nicht, daher wäre so eine Meldung auch für Titel=http irgendwie wünschenswert. Sorry dann war das natürlich ein dusseliger Fehler meinerseits. --Liebe Grüße, LómelindeDiskussion15:43, 23. Jul. 2016 (CEST)
Ein gezieltes Meckern bei |Format=|KBytes=|Abruf= ohne Online= ist zwar eingebaut; aber war auf diesem Zweig bislang nicht aktiviert. Mangels Online= kam das Modul nicht dorthin, wo es den Konflikt hätte bemerken können, und an der anderen Stelle stand bis heute nur ein Erinnerungskommentar.
Titel=http ist hingegen bis auf Weiteres nicht schädlich. Es wird ja noch an über 5000 Seiten rumgemäkelt.
Ja, ja, ja, ich weiß, erst mal die wichtigen Meldungen. Aber es ärgert mich, dass ich das nicht gesehen habe. Ne, das ist oberpeinlich. Aber irgendwann sieht man nur noch Buchstabensalat. :-) Danke auch für die MB’s. Und Crazy ist echt Crazy, er schafft weit mehr als ich. < 5300. --Liebe Grüße, LómelindeDiskussion16:57, 23. Jul. 2016 (CEST)
Vorlage Person
Letzter Kommentar: vor 8 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo PC, könntest du mir das hier irgendwie automatisieren?
Es ist durch nichts nachgewiesen, dass das alles Personen wären, wo die Dinger dranstehn.
Es ist auch nicht gesagt, dass das sinnvoll ist, so einzuschließen. Wird auch überflüssige Reklame damit gemacht; gerade bei Übersetzungen aus der enWP. Wir schließen in Artikeln nur biologische Forscher so ein.
Die class="Person" wird auch oft missbraucht, um dekorative Kapitälchen zu erzeugen; was jedoch unerwünscht ist.
Ist mir in den letzten fünf Jahren nicht als Massenphänomen aufgefallen.
Der backslash \ ist nicht vergessen, aber ich hatte noch keinen Kopf, um danach zu suchen. Wäre hingegen sofort Kandidat für Ersetzung, und war irgendwie vor Jahren schon mal.
Letzter Kommentar: vor 8 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
O.k. das ist jetzt nicht wirklich wichtig und kommt auch nur ein einziges mal so vor, dass es nahezu gar nicht auffällt, aber könnte man
refname irgendwie als auch Fehler ausgeben? Im Normalfall würde man es wohl sofort sehen, dass da etwas nicht stimmt weil es nicht als Ref-Tag erkannt und als Klartext ausgegeben würde.
Beispiel:
<refname="occ">Text</ref>
<refname="occ" />
Im obigen Artikel Born in the U.S.A. steht dieses Tag aber in einer Vorlage
Alles was man sieht ist {{{5}}} kein Ref, keine Fehlermeldung aus der Vorlage, keine Meldung durch WSTM, keine irgendwie ins Auge springende Anzeige, dass dort etwas nicht stimmen würde. Ja ich habe gerade mit der Suche herumgespielt und bin irgendwie da gelandet. Also nur, wenn das keinen großen Aufwand bedeutet und auch nur, wenn du denkst, so etwas sei wichtig genug behoben zu werden. Ich neige nämlich auch so manchmal zu dusseligen Schreibfehlern, aber wenn ich versuchen würde <ref nane="irgendetwas" /> einzugeben, dann würde mir das schon ordentlich an den Kopf gehauen, wenn ich auf die Vorschau klicke Referenzfehler: Ungültige Verwendung von <ref>: Der Parameter „name“ ist ungültig oder zu lang.
Das würde voraussetzen, dass WSTM eine Liste aller erlaubten Tag-Namen führt, und das würde angesichts der Vielfalt von HTML und ständig neuer MediaWiki-Elemente nicht gut gehen.
Auch spanstyle und divstyle und divalign und divclear können nur durch Abgleich mit einer Liste erkannt werden.
Mediawiki lässt die nicht erkannten Elemente <refname> offen im Text stehen.
Hier ist das allerdings in einen Vorlagenparameter eingebaut und schießt den vorher ab; das liegt am Gleichheitszeichen, der einem Parameter namens <refname den Wert "occ"/> zuweist. Das würde nur vermieden, wenn das Element zur MediaWiki-Software gehört und vorher abgefangen wird.
Nur eine Analyse in der Vorlage:Infobox Chartplatzierungen/Werk auf ihr unbekannte Parameternamen oder undefinierten Pflichtparameter 5= könnte das sinnvoll melden.
Sonst ginge auch nicht <Beispiel> oder <ironie> und auch nicht: a < X und c > Y a <X und c> Y
Ich weiß jetzt nicht wirklich was von einer neuen DOI-Meldung, aber vor einigen Tagen gab es bei WSTM-DOI irgendeine Aktualisierung und Verfeinerung, deren genaue Auswirkungen ich schon längst wieder vergessen habe.
Ich dachte mir schon, dass es viel zu kompliziert wäre Ich kann ja diesen einen Fall leicht reparieren, wollte es aber erst nach deiner Antwort tun. Dir ebenso einen sonnigen Tag. --Liebe Grüße, LómelindeDiskussion12:17, 31. Jul. 2016 (CEST)
Noch mal Murks
Da sitze ich und staune, was manche immer wieder, als Ref-namen sich ausdenken.
Nun ja das allein ist schon toll aber, weißt du was meine persönliche WSTM-Version daraus macht? Genau, formatierte Weblinks im Falle eine Mehrfachzitation ab dem zweiten Auftreten. Anstatt es in <ref name="http://numberworld.org/digits/E/">numberworld.org</ref> zu ändern bleibt dieser Eintrag wie er ist. Die Ref-name-Wiederholungen <ref name="http://numberworld.org/digits/E/" /> werden hingegen zu
Tertiary Education, Skills and Employment. [[Department of the Prime Minister and Cabinet (Neuseeland) |1=Department of the Prime Minister and Cabinet]], abgerufen am 5. Januar 2015 (englisch).
|1=Department of the Prime Minister and Cabinet]], abgerufen am 5. Januar 2015 (englisch).
Ich bin da über die Klammern gestolpert, die im Text sichtbar waren. Auch das habe ich repariert, wollte es aber mal mit auflisten. --Liebe Grüße, LómelindeDiskussion07:26, 4. Aug. 2016 (CEST)
Soso, unser neuseeländischer Freund mal wieder.
Inwieweit eine Lösung innerhalb von WSTM möglich ist, weiß ich nicht so genau.
Es kann sein, dass ich nur einen Schalter umlegen müsste, und jede Vorlageneinbindung wird gesondert eingepackt und ihre Pipes damit der weiteren Analyse entzogen.
Dieser Modus ist für die Bearbeiter allerdings deutlich ressourcenfressender; dauert länger, beansprucht den Rechner mehr. 2012 hatte ich mich nicht getraut, das für alle vorzugeben. Heutzutage sind die Rechner leistungsfähiger; möglicherweise als Opt-In für Power-User.
Vielleicht geht es aber gar nicht so trivial; im Vorlagenparameter eine Verlinkung und in der eine Vorlage. Dann bräuchte es ein halbes bis ganzes Jahr frei von allen anderen Aktivitäten, und die sind derzeit nicht drin.
Insgesamt sehr seltene Fälle, und nach fünf Jahren erstmals aufgetreten.
Vorlageneinbindung im Linktitel blockiert alle Auswerteskripte und Bots. Deine Lösung mit der Vorlage um die Verlinkung herum ist deutlich glücklicher.
Es wäre besser, wenn du um Artikel zu bestimmter Insel oder anderen Honigtöpfen einen Bogen machst und die Meldung dort einfach ignorierst.
Sobald die reichlich 3000 anderen Meldungen aus dem Altbestand einmal abgearbeitet wurden, werden alle Fehlermeldungen dauerhaft auf rot geschaltet, und die Hauptautoren können sich um ihr Geraffel in ihrem persönlichen Eigentum selbst kümmern.
Ich weiß doch vorher nicht was ich anklicke und wer da der HA ist. O.k. ich werde versuchen einen Bogen um NZ zu machen, wenn ich daran denke. Dankeschön. --Liebe Grüße, LómelindeDiskussion12:47, 4. Aug. 2016 (CEST)
Jahr mit unsichtbarem Kommentar
Letzter Kommentar: vor 8 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Compassion in World Farming (Hrsg.): Laying hen case study Austria 1. o.A. 2010 (ciwf.org.uk [PDF]).
Compassion in World Farming (Hrsg.): Laying hen case study Austria 1. o.A. (ciwf.org.uk [PDF]).
Das Jahr geht verloren, wenn das im Parameter |Jahr= steht, stünde dort bereits |Datum= würden sowohl der Kommentar als auch die Jahresangabe erhalten bleiben.
Kleiner Test für Monat und Tag mit Kommentar, warum auch immer so etwas vorkommen sollte
Die Programmierung in WSTM ist schlicht und zum Wegwerfen; wenn irgendwann bestimmte Parameterkonstellationen aus dem Bestand entfernt wurden, wird auch die Programmierung dazu wieder zurückgebaut.
Deshalb wäre es mir lieber, wenn der Bestand bereinigt wird; WSTM kann hier ohnehin nichts automatisiert tun.
Ist eine Geheimnotation mancher Geisteswissenshaftler.
Hier obendrein vermurkst – wenn man das schon so macht, gehört die Auflagennummer vor die Jahreszahl und nicht dahinter. Kommt davon, wenn man sich als Konifere großtun will.
Letzter Kommentar: vor 8 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo PC,
wäre es möglich
{{Infobox Unternehmen
| Name =
| Logo =
| Unternehmensform =
| Gründungsdatum =
| Sitz =
| Leitung =
| Mitarbeiterzahl =
| Umsatz =
| Branche =
| Homepage =
}}
in
{{Infobox Unternehmen
| Name =
| Logo =
| Unternehmensform =
| ISIN =
| Gründungsdatum =
| Auflösungsdatum =
| Auflösungsgrund =
| Sitz =
| Leitung =
| Mitarbeiterzahl =
| Umsatz =
| Stand =
| Branche =
| Homepage =
}}
umzuwandeln? Wenn es zu aufwendig ist, die fehlenden Parameter hinzuzufügen, wäre ich allein über die eingefügten Leerzeichen auch schon froh.--kopiersperre (Diskussion) 11:32, 10. Aug. 2016 (CEST)
Das kannst du dir seit mehreren Jahren alles selbst konfigurieren und verantworten.
Insbesondere würden deine Wünsche durch zwei Features erfüllt:
.format.order = [.....]
.format.style.lineup = true
Du kannst mal bei Benutzer:Daniel749/common.js für ein weiteres praktisches Beispiel reinschauen; dort ist genau sowas für eine andere Infobox realisiert worden.
Bei "| ISIN = nicht vorhanden" das "nicht vorhanden" löschen
Paul J. Hälg <br>(Vorsitzender der [[Geschäftsleitung]])<br> Ulrich Graf <br>([[Verwaltungsrat (Schweiz)|VR-Präsident]]) →
* Paul J. Hälg (Vorsitzender der [[Geschäftsleitung]])
* Ulrich Graf ([[Verwaltungsrat (Schweiz)|VR-Präsident]])
Alle nicht existierenden Parameter (auch die, die ich nicht kenne) löschen.
Letzter Kommentar: vor 8 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo PC, ich habe ein kleines Problem.
aus
Führungsrunden
irgendetwas
hier folg jeweils nur die betroffene Zeile NavHead
wird
Führungsrunden
um die Farbe wieder gray/grau zu setzen muss ich auf style ausweichen
Führungsrunden
Zumindest kriege ich das nicht anders hin. In der Pseudo-Infobox ist es auch fett, obwohl ich nicht sehe warum dort und hier nicht. Kann man das auch anders lösen? Abgesehen davon, dass ich diese Klappmöglichkeit für unnötig halte. --Liebe Grüße, LómelindeDiskussion11:57, 21. Aug. 2016 (CEST)
Das Problem, weswegen WSTM eingreift, ist das doppelte Vorhandensein von class=.
Es ist völlig undefiniert, was ein Browser tun soll, wenn er dies antrifft:
Beide so in einer class= hintereinander anordnen, wie WSTM das auch tut.
Die zweite Zuweisung überschreibt die erste. Das merkt man daran, dass die Fettschrift verlorengeht, wie in deinem Beispiel oben beim Firefox.
Die erste Zuweisung gilt; jede weitere wird ignoriert.
Das nächste Problem ist, dass die Spezifiktion von div.NavHead in MediaWiki:Common.css bereits eine Definition von background in einem Grauton enthält.
Die zusätzliche Forderung nach einem Grauton als background-color per Klasse hintergrundfarbe5 ist Quatsch.
Zusammenwirken der beiden Klassen:
nur hintergrundfarbe5
nur NavHead
hintergrundfarbe5 NavHead
NavHead hintergrundfarbe5
In jedem Fall muss, damit das syntaktisch richtig und unabhängig vom Browser wird, die doppelte class= verschwinden.
Wenn tatsächlich ein abweichender Grauton unbedingt sein muss, dann muss dies über style= gesetzt werden.
Weil div.NavHead die generelle Eigenschaft background verwendet, setzt sie sich wohl gegen das speziellere background-color der hintergrundfarbe5 durch.
Kurz: Die Artikelsyntax ist Murks von vorn bis hinten und in sich widersprüchlich. Was will der Autor denn eigentlich?
Was er will weiß ich, dass die Farbe an die anderen Boxeneinträge angeglichen ist und eigentlich auch noch dass es eingeklappt sein sollte vermute ich mal. Wozu man das wegklappen muss, weiß ich nicht, aber es gibt andere Beispiele bei denen das dann eingeklappt wäre, weil es unten auch noch eine Nayibox gibt.
→ Formel-3-Masters 2013
O.k. es liegt also nicht an mir, dass es nicht funktioniert hat, ich habe auch versucht es innerhalb der Klasse umzutauschen. --Liebe Grüße, LómelindeDiskussion12:51, 21. Aug. 2016 (CEST)
lang|bo
Letzter Kommentar: vor 8 Jahren6 Kommentare2 Personen sind an der Diskussion beteiligt
In deinem Skript wird {{lang|bo| in {{bo| umgewandelt. Das ist zwar in der Fremdsprachenunterstützung konsistent, leider aber noch falsch. Die Vorlage:boS hieß bis vor einer halben Stunde nur bo. Mit der Skriptbearbeitung wird dann aber gar nichts mehr angezeigt, natürlich. Ich werde mal versuchen, die falschen bo's in boS zu ändern. Bis dahin bitte die Automatik rausnehmen. --Hadibe (Diskussion) 12:18, 26. Aug. 2016 (CEST)
Nachtrag: wie bei den türkischen Fußballartikeln hätte man auch in diesem Fall sicher einen Bot beauftragen können, aber so kann ich die Artikel wenigstens komplett durchforsten und fand eben fehlerhafte Einbindungen bei denen gar kein tibetischer Text mehr angezeigt wurde. --Hadibe (Diskussion) 21:30, 27. Aug. 2016 (CEST)
Uijuijuijöh.
Ich weiß nicht recht; du hattest in allerbester Absicht gehandelt, aber ich fürchte, du wolltest mal mein PerfektesChaos übernehmen.
Die Vorlagen habe ich mir angesehen; das müsste jetzt vermutlich funktionieren.
Was du im ANR gemacht hattest, überblicke ich nicht.
Die Tücke war der Parameter language= gewesen.
Er bewirkt, dass nach der hier in den letzten Jahren entstandenen Programmierung Vorlage:bo und Vorlage:boS dasselbe sind.
Das Ding ist ein völliges Unikat.
Um das aktuelle Problem zu lösen, hätte es völlig ausgereicht, in der damaligen Vorlage:bo aus den {{{t}}} ein {{{1|{{{t|TEXT FEHLT}}}}}} zu machen.
Alle anderen Vorlagen verwenden den unbenannten Parameter 1 für den Text in der im Focus stehenden Sprache und Schrift.
Nur diese hier hatte den Parameter t= genannt.
Dass diese bo aus der Reihe tanzt, wusste ich, und hatte sie mir als besonders komplizierten Fall für den Schluss der Sprachvorlagen-Standardisierung aufgehoben. Die von dir bemängelten Einzelheiten waren mir so nicht klar.
Die langfristige Gestaltung der jetzt beiden Vorlagen ist dubios; das muss mit den einschlägigen Sprachleuten abgestimmt werden und passiert erst nächstes Jahr.
De facto habe ich nur die Vorlage:bo in boS umbenannt und dafür Tibetische Schrift in Vorlage:bo. Die zweite ist vorher wie nachher ein Bestandteil der ersten und ist somit ein ähnliches Konstrukt wie die Vorlagen he und heS. {{{t}}} ist zugegebenermaßen nicht so schön wie {{{1}}}, das könnte man ändern; {{{t|TEXT FEHLT}}}}}} sollte man sicher ändern. Schon weil nicht jedes Gerät Text anzeigen kann und somit der Fehler nicht sofort auffällt.
Naja, wir lassen es hoffentlich für dieses Jahr dabei.
Die eine Sache ist, in der Vorlage zu programmieren, dass t= jetzt 1= heißen würde. Die andere ist – die Fernostfans, die fast ein Jahrzehnt lang t= geschrieben hatten, sollen jetzt lernen, dass sie 1= schreiben sollen, was erfahrungsgemäß nicht klappt. Also steht ein Jahrzehnt mit Alias an, wodurch beides unterstützt wird, bis die bisherige Variante in Vergessenheit geraten ist.
Für die reine Schrift gab es bei mir schon längst einen Nachfolger: Vorlage:Tibt – ISO 15924.
Letzter Kommentar: vor 8 Jahren9 Kommentare3 Personen sind an der Diskussion beteiligt
Hey, ist es möglich, dass das Tool nicht automatisch Anführungszeichen hinzufügt oder sie nach Möglichkeit sogar entfernt? Wegen der Leerzeichen ist es zwar einfacher automatisch überall Anführungszeichen zu setzen, aber in manchen Artikel wird ja auch bewusst drauf verzichtet, wegen der Lesbarkeit und der geringeren Kürze. Grüße, Amtiss, SNAFU ?15:30, 29. Aug. 2016 (CEST)
Jaja, und bis vor kurzem brachen die refs sogar ab, wenn mittendrin ein ä vorkam, und ref=Jäger ist dasselbe wie ref=J.
Den Grund hast du bereits genannt: Es können Leerzeichen im Bezeichner vorkommen, es könnten Sonderzeichen seltsam interpretiert werden, und deshalb werden alle Attributwerte in " eingeschlossen.
Jemand anders fängt dann auch an, style=text-align:left für korrekt zu halten, und der nächste wundert sich, warum style=border: #FF00FF 1px solid nicht funktioniert. Oder class=toptextcells wikitable nicht die gewünschte Tabelle ergibt.
Der XML-Standard sieht vor, dass immer alle Attributwerte in " (bzw. ') eingeschlossen sind:
Es ist nur ein behelfsmäßiges Erraten, dass bei fehlenden " diese vom System wieder ergänzt werden; soweit die als Bezeichner zugelassenen Zeichen reichen.
+1 Es ist Quatsch diese Zeichen wegzulassen (wegen der Kürze). Ich nenne mal als Vergleich das Weglassen von schließenden HTML-Tags, das hat auch in der Vergangenheit gefunzt, ist aber unkonform und führt jetzt spontan zur völligen Ignorierung dieser (oh welch Wunder, Stichwort: Wir bauen auf Fehlertoleranz). ↔ User: Perhelion16:15, 29. Aug. 2016 (CEST)
Wir mussten schon ziemlich oft das gesamte Projekt nacharbeiten, weil irgendwelche Schlaumeier gemerkt hatten, dass im Monat m im Jahr j die Wiki-Software diesen oder jenen Effekt bewirkte, wenn man die Syntax anders als dokumentiert nutzte. Bloß dass dann regelmäßig im Monat m+n das überall korrigiert werden musste, weil sich die Software nun eben so verhielt, wie es eigentlich auch zu erwarten war. Wir haben noch etliche Hundert Seiten mit solch tickenden Zeitbomben offen, die in Kürze hochgehen werden. Und du errätst es nicht: Ursache ist regelmäßig, das ein ganz Oberpfiffiger irgendwas weggelassen hatte, was da hingehört hätte, weil es im Moment ja trotzdem funktioniert. Der Wikitext ist dann korrekt verwendet, wenn er so benutzt wird, wie er dokumentiert ist; was passiert, wenn man irgendwas weglässt, ist nirgendwo zugesichert und es ist nirgendwo versprochen, dass auch dieses Verhalten bis in alle Ewigkeit unterstützt würde. VG --PerfektesChaos17:24, 29. Aug. 2016 (CEST)
Krisenrhetorik ... PS: Mein 2. Beitrag / Widerwort kam v.a. wegen der Art und Weise deiner Antwort. 3x weglöschen führte zu dieser neutralen Antwort. Make the wiki software great again! Grüße, Amtiss, SNAFU ?17:46, 29. Aug. 2016 (CEST)
OT: Es kann sein dass PC den Anschein macht leicht genervt rüberzukommen, allerdings sollte man nicht zu viel darauf geben, vor allem wenn man eine so ausführliche Antwort bekommt. Evtl. neigt man bei entspr. Lage dazu etwas direkter zu werden und sich Floskeln zu sparen, vor allem wenn man sich (Du) hier mehr oder weniger kennt. PS:[3] Ich hatte auch den ein oder anderen Disput mit PC und er ist für mich immer Rahmen geblieben (wie gesagt würde ich hier überhaupt nicht viel hineininterpretieren, vor allem bei dem trockenen Thema). VG ↔ User: Perhelion23:08, 29. Aug. 2016 (CEST)
Hallo RonMeier, ich kann dies reproduzieren, allerdings nur weil ich eine sehr ähnliche config habe wie du. Wenn mod.plain leer ist, tut hier WSTM nichts falsches. Ich suche mal nach dem ursächlichen Regexp. ↔ User: Perhelion21:44, 10. Sep. 2016 (CEST)
Verstehe ich nicht warum man das Thema irgendwohin wegtragen musste. Dort stand nur: "ja das ist 1= zuviel", das Gleiche was du hier geschrieben hast. Gute Nacht ↔ User: Perhelion22:36, 10. Sep. 2016 (CEST)
Ersetzungen → Vorlagen
Letzter Kommentar: vor 7 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Was ich unter replace/template vermisse ist die normale Ersetzung wie beim plain nur eben auf die Werte der Vorlage (Paramter ist erstmal sekundär). Also normaler Text soll nicht betroffen sein, ist das möglich? ↔ User: Perhelion21:27, 10. Sep. 2016 (CEST)
Das steht seit 2012.
Die Programmierung ist wahnsinnig komplex, weil der bisherige Wert auch Links, URL, Vorlageneinbindungen, Bildeinbindungen, Kommentare enthalten kann.
Maximal wäre Ersetzung eines einfachen Textwertes durch einen anderen einfachen Textwert vorstellbar. Die Option ist ja als „geplant“ gelistet.
Wegen völliger Überlastung, Rückstau über mehrere Jahre keine Realiierung solcher Großprojekte (mit Erprobung) in Sicht.
Letzter Kommentar: vor 7 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
K. I. Bender, O. V. Gerasimova: Relationship between the pain-relieving action of narcotic analgesics and their effect on respiration. In: Farmakologiia I Toksikologiia. Band39, Nr.5, Oktober 1976, ISSN0014-8318, S.552–556, PMID 18367.
Guten Morgen, nun ja das mit 888- sieht halt anders aus und ich hatte ja explizit 88- eingegeben. Da kippt dann irgendwo ein Schalter um und sagt, da stimmt etwas nicht. Sonst wäre es mir wohl auch nicht aufgefallen, aber ich hatte nur diese eine ISB-Nummer wegen eines Tests auf der Spielwiese. Daher lag das im Fokus.
OT: Mein Buttonanzeigeproblem besteht übrigens noch immer, es wird aber kein Fehler ausgegeben, irgendwo sagt etwas „is feddisch“ und es ist noch nicht komplett auf dem Schirm, aber mein FF spinnt ja sowieso rum. --Liebe Grüße, LómelindeDiskussion06:33, 12. Sep. 2016 (CEST)
Neee, das ging gestern nicht, deshalb hatte ich ja versucht es anzupassen. Heute funktioniert der Link über eine Umleitung gestern kam eine Fehlermeldung. Grmpf. Echt manchmal glaube ich, ich habe Halluzinationen. --Liebe Grüße, LómelindeDiskussion10:39, 12. Sep. 2016 (CEST)
@Lómelinde: Das wolltest du vermutlich zum Abschnitt eins drüber schreiben.
URN geht mit resolver erst wieder seit heute vormittag halb elf; hatte ein Problem mit den Versionen der neu erstellten Progammbibliothek. Deshalb der Difflink; du hattest keine Halluzinationen. LG --PerfektesChaos14:03, 12. Sep. 2016 (CEST)
Info:
David Mallia: The Church of St Cecilia on the Island of Gozo. Wirt Għawdex, Malta 2012, ISBN 978-99957-0212-0.
Letzter Kommentar: vor 7 Jahren7 Kommentare2 Personen sind an der Diskussion beteiligt
Moin Moin PerfektesChaos, ich bin diese Seite nicht ganz durchgestiegen. Du prüfst ja HTML-Zeichen ab und ersetzt diese durch MediaWiki-Syntax. Mir ist gerade im Bereich Chemie und Physik aufgefallen, dass einige HTML-Zeichen nicht drinnen sind. Könntest du zum Beispiel &le bzw. &ge mit aufnehmen? Danke dir schon mal. mfg --Crazy188008:50, 17. Sep. 2016 (CEST)
Durchläuft eine Testphase, vermutlich zum Wochenende allen bekannt.
Achtung: Es gibt in HTML5 sehr exotische Zeichen als Entity:
Sie können nicht durch ein einzelnes momentanes Unicode-Zeichen dargestellt werden, sondern es müssen zwei überlagert werden (rund 100 Stück).
Diese bleiben besser bestehen, bis es auch ein richtiges Unicode-Zeichen gibt; die Browser wissen, was sie tun müssten.
Es werden teilweise mehr als 16 Bit für ein Zeichen benötigt.
Damit können viele Bots und Skripte nicht umgehen.
Als Entity bleiben sie pures ASCII und machen keine Probleme in unseren Quelltexten.
WSTM wird nur einen Teil der erkannten Entities ersetzen, wenn man das danach auch auf normalen Rechnern als Zeichen erkennen kann; es insbesondere keine späteren Probleme nach sich zieht.
Das Syntaxkorrekturprojekt sollte nicht mit Gewalt Entities auflösen, und das auch dort kommuniziert werden.
Letzter Kommentar: vor 7 Jahren4 Kommentare3 Personen sind an der Diskussion beteiligt
Wieso wird aus „w“ „en“? Der Critische Musicus → Der Critische Musicus eigentlich war hier wohl das „s“ Der critische Musicus gemeint. Ist nur eine Frage, weil mir nicht klar ist woran das festgemacht ist, dass „w“ generell erst einmal „en“ sein soll. Wäre es da nicht sinnvoller nur einen Hinweis auszugeben, wenn keine Sprachkennung dabeisteht. Ich weiß auch nicht wie ich das umschreiben soll, aber ich finde es merkwürdig. Nicht alle diese werden dort richtig aufgehoben sein.
Anmerken möchte ich noch (erinnernd), dass die Baustelle [[:en:Wikipedia:...]] zu [[w:en:...]] auf Commmons immer noch etwas nervt (Bsp). FG ↔ User: Perhelion21:45, 20. Sep. 2016 (CEST)
Letzter Kommentar: vor 7 Jahren6 Kommentare2 Personen sind an der Diskussion beteiligt
Ungültig: 1972, siehe auch: David B. Dickens, Elizabeth Miller: ''[http://blooferland.com/drc/images/05DkMill.rtf Michel Beheim, German Meistergesang, and Dracula] ([[Rich-Text-Format|RTF]]; 51 kB)'', in englischer Sprache
verschwindet spurlos samt Jahresangabe.
Vorher
{{Literatur
| Autor=Michel Beheim, Hans Hermann Karl Gille, Ingeborg Spriewald
| Titel=Die Gedichte des Michel Beheim: Nach der Heidelberger Hs. cpg 334 unter Heranziehung der Heidelberger Hs. cpg 312 und der Münchener Hs. cgm 291 sowie sämtlicher Teilhandschriften, Band 60
| Verlag=Akademie-Verlag
| Jahr=1972, siehe auch: David B. Dickens, Elizabeth Miller: ''[http://blooferland.com/drc/images/05DkMill.rtf Michel Beheim, German Meistergesang, and Dracula] ([[Rich-Text-Format|RTF]]; 51 kB)'', in englischer Sprache}}
Nachher
{{Literatur |Autor=Michel Beheim, Hans Hermann Karl Gille, Ingeborg Spriewald |Titel=Die Gedichte des Michel Beheim: Nach der Heidelberger Hs. cpg 334 unter Heranziehung der Heidelberger Hs. cpg 312 und der Münchener Hs. cgm 291 sowie sämtlicher Teilhandschriften, Band 60 |Verlag=Akademie-Verlag |Datum=}}
Ja das dachte ich mir schon, dass es da zu Verwicklungen kommen kann.
OT kannst du eventuell irgendwie in der Vorlage Literatur zulassen, dass man auch so etwas wie Neuauflage einfügen kann, ohne dass als Ergebnis Neuauflage Auflage daraus wird? Ist nicht wirklich tragisch und man kann [nN]eue schreiben, aber andererseits finde ich es unpraktisch, wenn man einen Parameter Auflage hat, dass man auf Kommentar ausweichen muss, um Neuauflage zu schreiben. Ist nur so ein Gedanke, der mir →gerade durch den Kopf ging. --Liebe Grüße, LómelindeDiskussion12:06, 23. Sep. 2016 (CEST)
Erstens ist jede 2. und 3. Auflage immer auch eine neue Auflage.
Zweitens ist die 2. Auflage nicht neu, sondern veraltet, wenn die „3. aktualisierte Auflage“ herauskommt.
Wo es möglich ist und eine Auflagennummer bekannt ist, kann das Wort „neu“ weggelassen werden.
Wenn nicht bekannt ist, als welche diese Version gezählt wird (es muss ja nicht die 2. sein), dann kann man das Wort „neue“ reinflicken, falls es sprachlich unvermeidlich wäre.
Letzter Kommentar: vor 7 Jahren8 Kommentare2 Personen sind an der Diskussion beteiligt
erkennen, wenn die Vorlage Literatur irgendwo innerhalb einer Vorlage IQ steht?
Sphagnum warnstorfii Russow Warnstorfs Torfmoos. In: Website des Projekts "Die Moose Deutschlands". Abgerufen am 4. August 2011 (nach Angaben aus Dr. Ludwig Meinunger und Wiebke Schröder: Verbreitungsatlas der Moose Deutschlands. Band 1. Regensburgische Botanische Gesellschaft, Regensburg 2007, OCLC635348854.).
… Punkte erkennen? Ich hätte da einen kleinen Wunsch.
I. A. Wolodin, O. G. Iltschenko, S. W. Popow: Песчанки: содержание и демография популяций разных видов в неволе [Rennmäuse: Haltung und Populationsentwicklung verschiedener Arten in Gefangenschaft]. Moskauer Zoo, Moskau 1996 (Microsoft-Word-Kopie, 4.214 KB – 228 Seiten).
|KBytes=4.214 KB → |KBytes=4214 Und diese Mausartikel sind … … nur Murks, und ich bin ein wenig faul und lasse das Tool gern für mich die Bytes anpassen. Und da wunderte ich mich warum es nicht … --Liebe Grüße, LómelindeDiskussion14:34, 27. Sep. 2016 (CEST)
WSTM ist blind und kann Kommata nicht von Pünktchen unterscheiden und hat keine Vorstellung davon, was sinnvolle Zahlen wären.
Nächstes Jahr können wir mal eine Kat aufmachen, was KBytes kleiner 10 auswirft.
Letzter Kommentar: vor 7 Jahren5 Kommentare3 Personen sind an der Diskussion beteiligt
Gibt es irgendeine Möglichkeit, WSTM beizubringen, dass [[Link]]<nowiki/>s als [[Link]]s dargestellt werden können? Ganz ulkig wird diese Konstruktion bei [[Wien|Wie]]<nowiki/>n. Und ja, es war wieder einmal der VisualEditor am Werk und es häuft sich. --Hadibe (Diskussion) 00:53, 28. Sep. 2016 (CEST)
Ich denke eher nicht, weil das <nowiki /> ja auch bewusst von manchen, sogar von WSTM, falls dort vorher ein <b />, <s />, <u /> stand, gesetzt wird.
[[Gruß]]<b/>wort → [[Gruß]]<nowiki />wort – Grußwort – wo soll man da den Unterschied festmachen wann das erwünscht ist und wann nicht?
Bei Teilwörtern kann das vorkommen, aber vielleicht kann man das auf ein oder zwei Buchstaben hinter den geschlossenen Klammern begrenzen. --Hadibe (Diskussion) 07:36, 28. Sep. 2016 (CEST)
Für WSTM ist ein <nowiki /> heilig und führt sehr früh dazu, dass der Quelltext an dieser Stelle aufgeteilt wird und auch nicht mehr als geschlossener Text wahrgenommen würde.
Der Code ist international kompatibel, und ich werde den Teufel tun und da irgendwelche gefährlichen Verrenkungen für ein deutsches „s“ einbauen.
Du kannst dir auf eigenes Risiko eine Joker-Funktion basteln, aber damit will ich nichts zu tun haben.
Nur ein Bot könnte für die deWP entsprechende Ersetzungen automatisch vornehmen und einen entsprechenden Anti-VE-BK schreiben. Oder vielleicht eine Aka-Hilfsbrigade.
Letzter Kommentar: vor 7 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo, ich habe gerade gesehen, dass es im Fliegelflagel mit Bandersnatch ein mächtiges Tool zur Textersetzung gibt, das auch dein WSTM einbinden kann, allerdings stelle ich mich da zu blöd für an… Offensichtlich ist es mit dem Laden und alleinigen Einfügen von neu = mw.libs.doWSTM(oldText, title); nicht getan, aber ich stehe auf dem Schlauch, was die Fehlerkorrektur betrifft. Kannst du mir helfen? --Sjöflygplan (Diskussion) 18:07, 23. Sep. 2016 (CEST)
Bedaure, ich bin kein Benutzer von fliegelflagel, erst recht nicht bandersnatch, und habe nur vor einigen Jahren mal gesehen, dass es eine doWSTM() gibt.
Ich kenne aber jemanden, der sich mit sowas auskennt.
Letzter Kommentar: vor 7 Jahren10 Kommentare3 Personen sind an der Diskussion beteiligt
Kann ich Änderungen in diesem Bereich abschalten? Ich bin mit den vielen Zeilenumbrüchen, die dort eingefügt werden nicht einverstanden. Herzliche Grüße, --Drahreg01 (Diskussion) 07:50, 22. Okt. 2016 (CEST)
TL;DR: Nein.
Das Skript weiß nichts davon, welche Formatierung im vorgefundenen Quelltext von Menschen beabsichtigt wurde.
Es schneidet die gesamte Einbindung aus dem Quelltext heraus.
Anschließend erfasst es die wirksame Bedeutung der Wertzuweisungen.
Diese werden ggf. nach bestimmten Regeln berichtigt, aktualisiert oder veraltete Teile entfernt.
Abschließend wird in einem konstanten Format der Nutzinhalt zurückgeschrieben. Das ist für alle Artikel gleich.
Vergleichen lässt sich das, um nicht den Verdauungsprozess bemühen zu müssen, mit der Metamorphose von der Raupe zum Schmetterling: Die Gestalt vorher/nachher hat nichts miteinander zu tun; der Inhaltsbrei wird komplett durchgequirlt und nur die kleinsten Elemente werden wiederverwendet.
Das zeilenweise Format wird seit über fünf Jahren sich immer weiter ausbreitend von vielen Autoren benutzt, die darauf schwören.
Grund ist die wesentlich bessere Lesbarkeit ähnlich den Infoboxen.
Nun können auch besser Parameter identifiziert werden, die offenkundig niemals mehr mit einem Wert belegt werden, wie ein leeres ISBN= in einem Buch von 1837, und diese Zeilen aus dem Artikel gelöscht werden.
Beispiel-Disk eines vehementen Befürworters der zeilenweisen Darstellung. Dieser möchte obendrein noch links und rechts Leerzeichen um jedes Gleichheitszeichen und Pipe-Symbol, die er auch nicht bekommt. Das wäre anderen wieder zu, äh, flüssig verdaut.
Ich habe mich deshalb entschlossen, für den Schreibvorgang am Ende des Artikels die zeilenweise Formatierung zu wählen, ansonsten aber möglichst kompakt.
Wenn es dich tröstet: Oben, also im Fließtext, wird alles in eine Zeile geschrieben. Das hätten manche ebenfalls gern zeilenweise. Es allen recht machen zu wollen hat irgendwo Grenzen.
Entschuldige Bitte, ich habe von deiner Antwort überhaupt nichts verstanden. Daher bin ich mir nicht sicher, ob ich meine Anfrage überhaupt verständlich gestellt habe. Ich versuche es nochmal.
Nach einer Bearbeitung wird aus folgendem Quelltext
Ah, dann habe ich oben eine andere Frage beantwortet.
Hier geht es im Grunde genommen auch um Quelltextlesbarkeit.
Dein Vorschlag würde auf die konventionelle Form hinauslaufen, bei einem längeren Passus im ref also etwa:
<references>
<ref name="Lehmann-36">Lorem ipsum dolor sit amet, consectetur adipisici elit, sed eiusmod tempor incidunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquid ex ea commodi consequat. Quis aute iure reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.</ref>
<ref name="Meier-52">Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquid ex ea commodi consequat. Quis aute iure reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint obcaecat cupiditat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</ref>
<ref name="Schulz-48">Et harum quidem rerum facilis est et expedita distinctio. Nam libero tempore, cum soluta nobis est eligendi optio, cumque nihil impedit, quo minus id, quod maxime placeat, facere possimus, omnis voluptas assumenda est, omnis dolor repellendus. Temporibus autem quibusdam et aut officiis debitis aut rerum necessitatibus saepe eveniet, ut et voluptates repudiandae sint et molestiae non recusandae.</ref>
</references>
Das Problem dabei ist, dass bei einer längeren Liste solcher separierter ref die einzelnen Schlüsselwörter name="" schwer wiederzufinden sind, und vor allem je nach den Zeilenlängen auch kaum noch zu erkennen ist, wo ein ref aufgehört hatte und ein neues begann, und dabei eines scheinbar auf myseriöse Weise vershwunden sei.
Deshalb stellt das Skript eine Art Kamm-Struktur her:
<references>
<ref name="Lehmann-36">
Lorem ipsum dolor sit amet, consectetur adipisici elit, sed eiusmod tempor incidunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquid ex ea commodi consequat. Quis aute iure reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.
</ref>
<ref name="Meier-52">
Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquid ex ea commodi consequat. Quis aute iure reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint obcaecat cupiditat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
</ref>
<ref name="Schulz-48">
Et harum quidem rerum facilis est et expedita distinctio. Nam libero tempore, cum soluta nobis est eligendi optio, cumque nihil impedit, quo minus id, quod maxime placeat, facere possimus, omnis voluptas assumenda est, omnis dolor repellendus. Temporibus autem quibusdam et aut officiis debitis aut rerum necessitatibus saepe eveniet, ut et voluptates repudiandae sint et molestiae non recusandae.
</ref>
</references>
Nun sind die Blöcke klar getrennt, und die Bezeichner Meier-52 treten an den Lücken deutlich hervor.
Wenn zwischendrin mal ein ref-Text recht kurz ausfällt, dann ist das trotzdem erforderlich.
Wenn alle ref-Texte ultrakurz sind und immer auf eine Zeile (je nach individueller Bildschirmbreite) passen würden, dann könnte man mit etwas Glück die Bezeichner auch so gut ablesen. Problem: Das Skript weiß nicht, wie breit bei den nachfolgenden Bearbeitern das Bearbeitungsfenster eingestellt sein wird, und was zukünftig von nachfolgenden Bearbeitern ohne WSTM noch dazwischen an ref eingefügt werden wird.
Deshalb wird es im Interesse aller Bearbeiter immer so gehandhabt.
Hallo, Drahreg01, Du bist nicht der einzige, der WSTM liebt (Dank dafür an PerfektesChaos), nicht aber diese Eigenschaft. Man kann sich davor schützen, indem man vor dem Laden von WSTM den Referenzblock maskiert, so dass WSTM ihn nicht erkennt, möglichst so, dass beim Speichern die Maskierung automatisch wieder entfernt wird. Das geht etwa durch die Ersetzungen
Ich habe in Benutzer:Griot/monobook.js ein Script geschrieben, das dies ermöglicht. (Es ist unnötig umständlich, da schnell aus einem längeren extrahiert, aber es funktioniert. Allerdings werden "references groups" noch nicht berücksichtigt.) Meine aktuellen Bearbeitungen von Wilhelm Quade und Rudolf Harnisch erfolgten damit. Sie zeigen, dass WSTM auch die Referenzen bearbeitet, wie gewünscht. Leider kann ich nach einer Reihe von Tests das Verfahren doch nicht empfehlen, ich verwende es zwar mit der nötigen Vorsicht weiter, aber das Beispiel Rudolf Harnisch deutet schon das Problem an: die Referenzen werden zwar nicht in der für den Referenzblock üblichen WSTM-Form formatiert, dafür aber in der für den Haupttext üblichen – es wird alles in eine Zeile geschrieben. Eine vorliegende Referenz in der üblichen WSTM-Form wird also zerstört, eventuell enthaltene vielzeilige Vorlagen 'Literatur' und 'Internetquelle' werden mit allem anderen in eine Zeile gequetscht. Das ist natürlich nicht tolerierbar. Eine Verwendung ist also höchstens für Spezialfälle angebracht. Dazu müsste eine (evtl. verbesserte) Kopie meines monobook.js in eine ansonsten unbenutzte Benutzeroberfläche (also etwa nach cologneblue.js, modern.js oder monobook.js) übertragen werden (etwas tricky, da das System die subst-Ausdrücke ersetzen will…) und im Bedarfsfall auf diese Oberfläche umgeschaltet werden. Du müsstest wohl auch den Aufruf von WSTM aus Deiner common.js nach etwa vector.js verschieben. Ich vermute, es wird sich für Dich leider nicht lohnen. --Griot (Diskussion) 01:36, 23. Okt. 2016 (CEST)
Letzter Kommentar: vor 7 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Wäre es sinnvoll so etwas |Seiten=165 sqq., was für mich völlig unverständlich ist, eventuell automatisch in |Seiten=165 ff. zu ändern oder bedeutet das irgendwie etwas komplett anderes? Es gibt nicht so sehr viele Artikel (falls meine Abfrage so stimmt) →sqq. oder →sq. in denen das vorkommt aber … ich wollte trotzdem mal fragen. --Liebe Grüße, LómelindeDiskussion11:06, 24. Okt. 2016 (CEST)
Die werden alle von nur drei Autoren stammen, die in höheren geisteswissenschaftlichen Sphären schweben.
Es bedeutet natürlich das, was die Abschnittsüberschrift schon andeutet. wikt:la:sequor
Sie haben sich über ein Dutzend Jahre hinweg angesammelt.
Falls du die gaaanz langsam und nicht alles vom selben Autor auf einen Schlag weggeputzt haben würdest, kämen vielleicht nie wieder welche hinterher oder mal einer pro Jahr.
Von meiner Seite lohnt das nichts, weder für alle Anwender in WSTM noch in Lua.
Das hatte ich schon vermutet, weil es ja nur so wenige sind. Ich musste wirklich erst suchen, was das bedeuten soll. :-) Mal schauen, vielleicht wenn da noch einige in der Wartung sind, dann mache ich die mit. Trotzdem vielen Dank. --Liebe Grüße, LómelindeDiskussion16:24, 24. Okt. 2016 (CEST)
Band, BandReihe → Schwund?
Letzter Kommentar: vor 7 Jahren7 Kommentare2 Personen sind an der Diskussion beteiligt
Schaust du bitte mal was da los ist? Wenn ich WSTM das formatieren lasse ist eine Bandangabe auf nimmerwiedersehen weg.
{{Literatur |Autor=Walter von Hueck |Titel=Adelslexikon |Band=Band 15: ''Tre–Wee'' |Reihe=[[Genealogisches Handbuch des Adels]]|BandReihe=Band 134 d. Gesamtausgabe |Ort=Limburg a.d. Lahn |Datum=2004 |Seiten=349–350}}
'Kursiver Text'Walter von Hueck: Adelslexikon, Band 15, Tre–Wee (= Genealogisches Handbuch des Adels. Band 134 d. Gesamtausgabe). Limburg a.d. Lahn 2004, S. 349–350.Fehler in Vorlage:Literatur – *** Parameterfehler; Band= meint BandReihe=
Gemeint ist dieses OCLC955565369, ich wunderte mich schon warum es so
{{Literatur| Autor=Walter von Hueck |Titel=Adelslexikon, Band 15, Tre–Wee|Reihe=[[Genealogisches Handbuch des Adels]]| Band=Band 134 d. Gesamtausgabe|Ort=Limburg a.d. Lahn|Jahr=2004|Seiten=349–350}}
Walter von Hueck: Adelslexikon, Band 15, Tre–Wee (= Genealogisches Handbuch des Adels. Band 134 d. Gesamtausgabe). Limburg a.d. Lahn 2004, S. 349–350.Fehler in Vorlage:Literatur – *** Parameterfehler; Band= meint BandReihe=
Band wird beim Sammelwerk erwartet; da dieses nicht angegeben ist, dafür aber Reihe vorhanden ist, ordnet WSTM momentan die Bandangabe der Reihenangabe zu.
Es wäre bei diesem Monster mal zu klären, was unter „Gesamtausgabe“ zu verstehen ist.
Wenn es Band 134 von Genealogisches Handbuch des Adels meint, dann ist das ja okay.
Somit ist das Band 15 von Titel/Sammelwerk=Adelslexikon identisch Band 134 von Reihe=Genealogisches Handbuch des Adels.
Mangels des erwarteten Sammelwerk kommt WSTM momentan wohl durcheinander. Ich schau mir die Logik mal an.
Die Zitation müsste heißen:
von Sinnen. In: Adelslexikon, Band 15 (=Genealogisches Handbuch des Adels, Band 134).
Literaturangaben mit oder ohne Vorlage erwarten bei einem Zugang zu Digitalisaten ein simples archive.org ohne irgendwelche Erläuterungen und Rumgeschwafel; abgesehen von technischem Format und ggf. Abrufdatum (bei weniger bekannten Websites).
Ja ich bin nahe an der Verzweiflung, ich weiß das ja aber … ich möchte keinen Streit.
Ähm ja schön wäre es ja wenn Band vor der Klammer stünde, aber da spielt die Vorlage nicht mit die klatscht es immer hinten dran, aber ich wollte deswegen nicht rummaulen, aufgefallen ist mir das schon. Und nee du, warte, es liegt nicht am „fehlenden Sammelwerk“
Walter von Hueck: König Alfons der Viertel-vor-Zwölfte. In: Adelslexikon (= Genealogisches Handbuch des Adels. Band134 d. Gesamtausgabe). Band15: Tre–Wee. Limburg a.d. Lahn 2004, S.349–350.
Walter von Hueck: König Alfons der Viertel-vor-Zwölfte. In: Adelslexikon (= Genealogisches Handbuch des Adels. Band15: Tre–Wee). Limburg a.d. Lahn 2004, S.349–350.
Heißt: Wenn Reihe und nicht Sammelwerk … und Band und nicht BandReihe → Setze BandReihe auf den Wert von Band und eliminiere Band.
Das ist eigentlich die korrekte Logik.
Haste mal den Original-Artikel?
Bleibe standhaft; der hat häufiger völlig abstruse plötzliche Eingebungen, die dann aber wenig taugen und nicht zu Ende gedacht sind und zu völligem Murks führen. Sieht momentan danach aus, als ob du dich durchsetzen kannst.
Letzter Kommentar: vor 7 Jahren7 Kommentare2 Personen sind an der Diskussion beteiligt
Ja ich weiß, so etwas sollte nicht sein Zitat: „Das ausgegebene Format eignet sich nicht für die Angabe von Belegen in Einzelnachweisen, siehe Wikipedia:Zitierregeln und Wikipedia:Belege.“ Ich frage mich gerade wozu man dann einen Parameter ref eingeführt hat.
<ref>{{Wikisource|Preston, John (1587-1628) (DNB00)|John Preston|X|lang=en|ref=ja}}</ref>
Das sollte eher so aussehen
<ref>[https://en.wikisource.org/wiki/Preston,_John_(1587-1628)_(DNB00) John Preston] auf Wikisource</ref>
Aber durch den merkwürdigen Parameter X passiert da etwas sehr unschönes
<ref>{{Wikisource|Preston, John (1587-1628) (DNB00)|John Preston|X|lang=en|ref=ja}}</ref>
<ref>
{{Wikisource|Preston, John (1587-1628) (DNB00)|John Preston|X}}
</ref>
[[s:en:Preston, John (1587-1628) (DNB00)|John Preston]]
{{Wikisource|Preston, John (1587-1628) (DNB00)|John Preston|X|lang=en|ref=ja}} mit X
{{Wikisource|Preston, John (1587-1628) (DNB00)|John Preston|lang=en|ref=ja}} ohne X
wird zu
{{Wikisource|Preston, John (1587-1628) (DNB00)|John Preston|X}} – tot da Sprache weg
WSTM kennt kein ref nirgends, in keiner Schwesterprojektvorlage, und auch keine wirren X-Strahlen.
Und dieser ref-Parameter ist auch dummes Zeug vor dem Herrn.
Das verkompliziert die Sache nur maßlos.
Dem Scherzbold, der das 2013 eingefügt hatte, sollte man sämtliche Einbindungen außerhalb seiner Repubik stillschweigend demontieren, falls das überhaupt jemand mitbekommen hat.
Und in solch einer Verlinkung soll auch nicht stehen en.wikisource.org/wiki/ sondern [[s:en:Preston, John (1587-1628) (DNB00)|John Preston]].
Und wenn DNB die enDNB sein soll, dann heißt das:
{{DictNatBiogr|Verfasser=Alexander Gordon|Lemma=Preston, John (1587-1628)|Band=46|SeiteVon=308|SeiteBis=312}}
Was du so alles für Vorlagen kennst. Dankeschön, ich werde es mal eliminieren, ja klar müsste es dann s:en:… sein, aber da bin ich dann faul und lasse es umschreiben. Doof ist aber, dass die Vorlage die du mir da anbietest keinen vernünftigen Bisstrich (1587–1628) kennt, denn ich neige dazu diese immer alle zu ersetzen. --Liebe Grüße, LómelindeDiskussion15:03, 9. Nov. 2016 (CET)
Mit - kannst du das schützen. Und wenn dir mal nach Anpflaumen ist, dann kannst du mal den Bastelkönig fragen, warum er seine superkomplizierte Blaue-Icon-Ausblendeaktion verbrochen hat und welche von den beiden wohl kürzer und einfacher und verständlicher und bekannter ist; und ob er mit projektweitem Rückbau einverstanden wäre:
[[s:en:Preston, John (1587-1628) (DNB00)|John Preston]]
{{Wikisource|Preston, John (1587-1628) (DNB00)|John Preston|X|lang=en|ref=ja}}
Bist du … noch bei Trost. Damit ich dann wieder anecke? Ne, … … oder ich muss mal schauen wer das war, vielleicht frage ich doch mal. Sind das denn sehr viele? Ich bin mal wieder zu ungeschickt, um das richtig zu suchen.
Ich möchte aber kein - sondern einen richtigen Bisstrich – in der Ausgabe, das sieht doof aus und geschützt ist es nicht besser als so - ich bin da sehr mäkelig. --Liebe Grüße, LómelindeDiskussion16:16, 9. Nov. 2016 (CET)
Dann muttu englischsprachiges Wikisource von typografischen Nöten überzeugen und für den Fall der Fälle eine WL anlegen.
Weniger als 46, wobei Zitatvorlagen auch so einen Parameter haben.
Erstmal Rückbau; hinterher wegen Nichtverwendung auf der Vorlagendisk ankündigen und nach einer Woche ohne Protest Rückbau.
Öhm das wird ja noch schwieriger, die verstehen mich da sicherlich nicht einmal. O.k. ich schaue mal wie viele es wirklich sind. --Liebe Grüße, LómelindeDiskussion17:00, 9. Nov. 2016 (CET)
Miniatur in Mini ändern
Letzter Kommentar: vor 7 Jahren4 Kommentare3 Personen sind an der Diskussion beteiligt
Nö; aber mini ist nun mal mit >300.000 die bevorzugte Variante, weil auch auf Englisch, Französisch und Spanisch verständlich – während miniature nur Englisch/Französisch und miniatur nur Deutsch ist. Danke für die Info, LG --PerfektesChaos10:16, 11. Nov. 2016 (CET)
Es geht in obiger Diskussion ja eigentlich um Leute die nichts ändern als diese automatischen Edits. Ich könnte mir aber vorstellen, dass die Wahrnehmung teilweise falsch ist. Wenn ich bspw. nur einen Tippfehler korrigiere, und WSTM sich bei der Gelegenheit so richtig austobt, sieht man den eigentlichen Edit vor lauter Bäumen nicht mehr. Auf Arbeit (bei CVS/SVN geführtem Quelltext) löse ich solche Fälle regelmäßig indem ich zwei direkt aufeinander folgende Änderungen mache (Eine mit den Copy&Paste Änderungen eine mit der inhaltlichen Änderung), hier würde man dafür wahrscheinlich auch wieder angemeckert. --Windharp (Diskussion) 14:24, 11. Nov. 2016 (CET)
Ja, solche Diskussionen kommen alle halbe Jahre wieder; solange dabei auch eine inhaltliche/wirksame Änderung gemacht wird, gibt es da aber wenig zu meckern. Und wenn WSTM nach fünf oder zehn Jahren erstmals über einen Artikel gekommen war, dann ist ja eine Weile wieder Ruhe.
Die Variante „thumb“ (auch nur ein Alias von eigentlich richtig softwareseitig „thumbnail“) hat international eine gewisse Berechtigung, das international verständliche „mini“ (2012 eingeführt) hat über 300.000 Verwendungen in Artikeln und ist die hiesige bevorzugte Variante; das 2006 eingeführte „miniatur“ kommt noch in 230.000 Artikeln vor und ist am Aussterben, damit es statt drei nur zwei Varianten geben möge.
Letzter Kommentar: vor 7 Jahren8 Kommentare3 Personen sind an der Diskussion beteiligt
Schachbretter, wie hier zeigen bei mir alle eine Fehlermeldung. Selbst die Beispiele aus der Vorlagendoku werden angemeckert. Wenn ich die Archiv-Dikussion richtig verstehe sollte das eigentlich nicht mehr sein, oder?
Warnung durch Benutzer ausgelöst:
2× Unerwartetes Format: {{Schachbrett|a b c d e f g h
Auf den ersten Blick kommt mir das {{Center| verdächtig vor.
Ich habe aber alles vergessen.
Wenn das Schachbrett regulär verwendet wird, müsste Ruhe sein.
Vielleicht hat aber irgendwas den Schachbrett-Algorithmus von WSTM beeinträchtigt; muss ich heute Nacht mal in Ruhe nachforschen und an regulären Beispielen ausprobieren.
Die Normalbenutzer führen eine „r“-Version aus, die nur knapp ein halbes MB hat. Das wird dadurch erreicht, dass Kommentare, Leerzeichen und Zeilenumbrüche wegfallen, die nur die doofen Menschen wegen Lesbarkeit brauchen.
Bei der Komprimierung gingen seit einem halben Jahr acht Leerzeichen für Schachbretter verloren, was bislang wohl niemandem auffiel. Ich hatte eine Reihenfolge im von mir selbst gebauten Komprimierungalgorithmus vertauscht, und diese Konsequenz nicht vorhergesehen.
Der Code ist inzwischen in Quarantäne geändert und sollte im Lauf des Wochenendes für alle Benutzer wieder ordnungsgemäß funktionieren.
Hey, du weißt dass ich das gern tue, mir hat das gewiss keine Umstände gemacht und unangenehm ist es für mich nie mit dir gemeinsam zu arbeiten. Es freut mich wenn ich etwas zur Lösung beitragen konnte. --Liebe Grüße, LómelindeDiskussion11:35, 12. Nov. 2016 (CET)
Ich habe widerwillig die vier konkreten WL auch noch eingebaut.
Ich schrieb oben bereits, dass ich ein Jahr abwarten möchte, ob die Olympioniken es merken und meutern, bevor ich damit weitermache.
Bis dahin möchte ich nicht die gesamte ISO-3166-1-Kodierliste auf meiner BD wiederfinden.
Später würde ich eine effiziente Abfrage gestalten, die bei drei ASCII-Großbuchstaben in einer übersichtlichen Tabelle nachguckt, ob und wie das zu ersetzen sei, und das dann für das gesamte korrupte IOC.
Jetzt habe ich über 50 Zeilen extra quer durch den ganzen Code verstreut, weil ich jede einzeln und individuell wie jede andere Einzelvorlage mit möglichen Besonderheiten auswerten muss.
CyRoXX
Die Liste ist mir geläufig, und sie wird seit 2012 in WSTM für ANR-Vorlagen verwertet.
Etliche der momentanen redlinks gehen auf WSTM-Aktivitäten zurück.
Moin Monin PerfektesChaos, ich habe die Liste gestern Abend aktualisiert und einige Vorlagen waren mir direkt aufgefallen, die schon lange Zeit leer waren, deswegen habe ich dann auch direkt löschen lassen. Der Weg mit einer einheitlichen Tabelle zum nachschauen finde ich eine super Idee. Ich biete gerne meine Hilfe an, wenn ich helfen kann. mfg --Crazy188010:24, 15. Okt. 2016 (CEST)
An den Aargauer Parlamentariern scheinst du ja schon dran gewesen zu sein.
Navileisten sind aber spannender als das versumpfte IOC.
Hatten wir vor ein paar Jahren schon mal, mit 400 WL, und ich habe noch auskommentiert die Infrastruktur dafür. Diese beabsichtige ich zu reaktivieren.
Was du schon mal tun könntest: Zu allen die Linkliste anschauen, bei null oder einem oder zwei Artikeln freihändig fixen und SLA stellen, ansonsten das Linkziel hinten eintragen (2=).
Ein noch undokumentierter Parameter 3= könnte festhalten, wo es nur wenige Dutzend Artikel gäbe, also eine momentane Anzahl; die könnte man dann nächstes Jahr vorrangig aufsuchen und niedermachen.
Eigentlich ist mein Hauptschwerpunkt aber seit einem halben Jahr die Literaturvorlage, seit Jahresbeginn die Sprachvorlagen und für zwischendurch TemplateData; nächster Kunde sind DNB und Normdaten. Insofern bin ich über plötzliche Extraeinlagen, die nach und nach laufen können, nicht sehr begeistert.
Jupp, an der war ich dran und auch andere konnte ich heute schon löschen lassen.
Ich schaue die Navi-Leisten gerne mal roh durch, anschließend schaue ich mir deine Tabelle an, aber wahrscheinlich müsste die dann noch mal aktualisiert werden.
Ich kenne das mit der Arbeit, die einen überfällt, bzw. sich rechts und links stapelt.
Ich habe es auf meiner Festplatte nach WSTM kopiert.
Eine Teilmenge war bereits in der Erprobungsversion.
Irgendwann diese Woche oder so wird es auch für alle produktiv werden.
Danach sollte man die Angelegenheit bis Ende des Jahres beiseite tun und in Ruhe köcheln lassen.
Die Seiten mit einer Navileiste werden alle von denselben Leuten beobachtet, und die reagieren algerisch, wenn man serienmäßig über ihre Artikel geht.
Der Witz bei WTM ist ja grad, dass die Umstellung so allmählich nebenbei reintröpfelt.
Irgendwann im nächsten Jahr kann man die mal nach der mutmaßlichen Anzahl ordnen, und die mit den einstelligen Nummern durchgucken, wie viele noch übrig sind, und wenn es dann nur noch zwei oder drei wären – dann denen gezielt den Rest geben.
Und wenn die einstelligen alle sind, dann mal die Restmengen der zweistelligen aktualisieren.
Moin Moin PerfektesChaos, folgende Vorlagen {{SUI}} → {{CHE}} funktioniert momentan augenscheinlich umgedreht. Hatte jetzt einen Artikel, wo WMST aus CHE dann SUI gemacht hatte. Das ist ja eigentlich nicht richtig. Könntest du da mal schauen? Danke dir schon mal --Crazy188020:52, 27. Nov. 2016 (CET)
Och Menno, ich wollte dieses Jahr den ganzen Mist doch überhaupt nicht haben. Für nächstes Jahr war eine übersichtliche Tabelle geplant, in der die ganze ISO-3166-1-Kodierliste abgebildet wäre, wo erforderlich. Jetzt habe ich wohl ein Dutzend Fitzelchen alphabetisch irgendwo zwischen den anderen Vorlagen und -WL rumzufliegen, und weiß doch auch nicht auswendig, wie das heißen müsste. LG --PerfektesChaos10:19, 28. Nov. 2016 (CET)
Umbruch mit Vorlage Absatz ersetzen
Letzter Kommentar: vor 7 Jahren4 Kommentare3 Personen sind an der Diskussion beteiligt
Moin Moin PerfektesChaos, ich hätte da mal eine Frage. Wenn ein alter Umbruch in einem Artikel ist <br style="clear:both;" />, wird ja mit WSTM daraus <div style="clear:both;"></div>, was dann allerdings hier (ID 85) wieder Einträge erzeugt. Nun gibt es ja die Vorlagen {{Absatz}} und {{Absatz-L}}, könnte man diese WSTM zum Ersetzen der alten Umbrüche beibringen? mfg --Crazy188009:41, 18. Nov. 2016 (CET)
Da die beiden Vorlagen (wieso überhaupt zwei verschiedene, das macht besser eine mit Parameter, zwei verschiedene Vorlagen für den praktisch gleichen Zweck hatte man 2005/2006 konstruiert, bevor die Auswertung der Vorlagenparameter eingeführt wurde) keine Namen haben, der ihren Zweck verständlich wiedergibt, vielmehr einen Namen haben, der etwas völlig anderes suggeriert als sie tatsächlich bewirken, werde ich diese Dingse nicht anfassen.
Im Übrigen sollte das Tool die Klappe halten, wenn Elemente mit Attributen versehen sind; auch <span id="Hierher"></span> ist leeres aber mitnichten wirkungsloses Element.
Und das Tool könnte sich bei leicht angehobener Intelligenz denken, dass ein style="clear durchaus eine Wirkung nach außen hat, selbst wenn es keinen Text enthält.
Japp, dass man dies nicht mit Parametern gelöst hat, verstehe ich auch nicht so recht! Danke für die Info, ich spreche das noch mal auf der Fehlerseite an, vllt. kann man da noch irgendwas im Skript optimieren. mfg --Crazy188010:27, 18. Nov. 2016 (CET)
Die Vorlage {{Absatz-L}} war notwendig, weil sonst die erforderliche Parameterabfrage mit im Artikelquelltext gelandet wäre. Die Vorlage soll laut Doku erst seit Juli dieses Jahres nicht mehr ersetzt weden. Das ist mir heute früh aufgefallen, eben weil durch den Vorlagenquelltext ersetzt wurde. Wenn jetzt noch jemand eine Parameterübergabe für eine Weiterleitung von -L auf Absatz einbaut, hätte man wirklich alles in einer Vorlage.
Letzter Kommentar: vor 7 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
{{Internetquelle |hrsg=[[Amt für Flugsicherung der Bundeswehr]] |url=http://www.mil-aip.de/pams/aip/ad/ET_AD_2_ETHC_1_en.pdf |format=pdf |sprache=en |titel=Militärisches Luftfahrthandbuch Deutschland: ETHC – Celle |werk=www.mil-aip.de |datum=13. März 2008/18. Dezember 2008/12. März 2009 |zugriff=2009-09-07}}
Nur als Info, ich habe keine Ahnung was man mit so etwas machen soll. Vermutlich hätte ich diesen Link nehmen sollen, um ein sinnvolles Ziel anzubieten, aber mir geht es mehr um die dusselige Datumsangabe. --Liebe Grüße, LómelindeDiskussion14:46, 23. Nov. 2016 (CET)
In den Kommentar mit dem Mist. Ein Datum ist ein Datum ist ein Datum. Ende 2017 gibt es das dann gleich in roter Farbe, und gut ist. LG --PerfektesChaos14:54, 23. Nov. 2016 (CET)
Ja doch, das habe ich ja :-) nur bin ich nicht zufrieden mit ich hätte das komplett löschen sollen, der Link als solcher ist so nicht sonderlich hilfreich. Man kommt nicht einmal wirklich auf ein PDF sondern auf eine Sammeloberseite. --Liebe Grüße, LómelindeDiskussion15:22, 23. Nov. 2016 (CET)
Es ist der Umstand, dass mitten in einem CSS-Code irgendeine Vorlage auftaucht, was syntaktisch ungeschickt gelöst ist.
Ich hatte gehofft, dass das weniger wird, aber die Ausbreitung der Vorlage nimmt wohl eher zu.
Verlinkt wird auf Wikipedia:Spaltensatz, und da heißt es „kann Spaltensatz aber mehr Probleme schaffen als lösen, weshalb er in Wikipediaartikeln meist vermieden werden sollte“.
Die momentane Vorlage wurde erforderlich, weil es dieses Feature eigentlich überhaupt nicht richtig gibt, und deshalb browser-abhängig rumgepfriemelt wird.
Sollte das irgendwann mal allgemein unterstützt werden, kann man es an den Stellen, wo es wirklich nötig ist, durch eine kurze direkte Ansage in CSS ersetzen.
Jetzt sorgt es für nicht beurteilbaren Quelltext und legt jede Quelltext-Analyse lahm.
Das ist doch genau dasselbe wie auch hier. Warum kann man denn nicht alles in eine Vorlage stecken, das wäre doch überschaubarer? Und irgendwie werden wir uns mit dieser Vorlage grundsätzlich abfinden müssen, das englische Pendant liegt schon bei 390.000 Einbindungen. --Hadibe (Diskussion) 23:15, 26. Nov. 2016 (CET)
Es ist genau die Frage, ob es nicht heutzutage ausreichen würde, column-width:15em direkt und ohne Vorlage und Gedöns direkt als CSS-Code offen hinzuschreiben.
Dann könnte ein Bot die Vorkommen der Vorlage überall durch diesen kurzen Code substituieren.
Und die Vorlage kann gelöscht werden.
Kannst du ja mal herausfinden; insbesondere mit Safari. Firefox versteht das vermutlich in allen eingesetzten Versionen.
Die enWP ist stolz darauf, alle Wiki-Syntax und alles und jedes noch mal einzeln in eine Extra-Vorlage zu packen. Die gehen mir sonstwas sonstwo vorbei. Wir schreiben hier offen und direkt.
Ich hätte es nicht gewagt danach zu fragen, weil mir klar ist, dass ich es nicht einsetzen sollte, ich es aber doch tue und dann immer aufpassen muss, dass WSTM es mir nicht um die Ohren haut. Und deswegen. Vorlage:Smiley/Wartung/rot
Hintergrund ist ja eigentlich, dass in der deutschsprachigen Wikipedia eine mehrspaltige Aufzählung in der Form column-moz, oder wie das heißt, nicht erwünscht ist. Viele behelfen sich dann mit einer Tabelle, was aber mindestens ebenso verpönt ist. Man muss sich immer wieder anhören „Tabellen sollen nicht zur optischen Anpassung verwendet werden“. Auslöser war eine Anfrage zur Mehrspaltigkeit und na ja ich habe die zufällig auch gesehen. --Liebe Grüße, LómelindeDiskussion10:14, 28. Nov. 2016 (CET)
So verkehrt finde ich die Vorlage nicht. Einen Vorlagennamen kann ich mir merken, die komplette jetzige Befehlszeile sicher nicht. Sonst könnte man die Fremdsprachenunterstützungs-Vorlagen auch alle aus einzelnen {{lang}} {{IAST}} und sonstwas zusammenbasteln. --Hadibe (Diskussion) 06:39, 29. Nov. 2016 (CET)
Die „komplette jetzige Befehlszeile“ wird im Lauf des Jahres 2017 ihren Geist aufgeben können.
Sie wurde 2010 mal konstruiert, weil es damals experimentell in manchen Browsern erprobt wurde.
Erst später wurde es in den Standard CSS3 aufgenommen und jetzt allmählich in den Browsern wahrgenommen.
Da die fraglichen Browser zur laufenden Aktualisierung auffordern, wird der Anteil verbleibender alt-Browser rapide abnehmen.
WSTM wird 2017/18 die Vorlageneinbindung durch column-width: substituieren.
Wenn es mal nicht greift, was bei allen IE vor IE11 der Fall ist, dann ist es auch kein Schaden für den Leser, und es kommt halt eine einspaltige Tabelle, wie auch bei allen, diee ein schmaleres Bildschirmfenster haben. Es ist nur ein Tipp zum möglichen Layout, mehr nicht.
Da column-width: noch nicht mit dem FF funktioniert und die {{Spaltenbreite}} gerade erst zum Standard erhoben wurde, könntest du dann bitte einen Workaround einbauen? Ich bekomme das nur mt dem autoFormatter hin. --Hadibe (Diskussion) 08:02, 1. Dez. 2016 (CET)
Ein Workaround ist nicht möglich. Der CSS-Quelltext ist und bleibt illegal, da es an dieser Stelle keine {{ und so Zeugs geben kann, und kein Überprüfungswerkzeug für den Quelltext im ANR kann auflösen, was das bedeuten soll.
Der mehrspaltige Satz ist und bleibt unerwünscht und ist offiziell missbilligt. Wenn sich irgendein Klub darüber hinwegsetzt und regelmäßig sein privates Ding dreht, werde ich dafür nicht eine Minute, geschweige denn viele Stunden opfern, und erst recht nicht für etwas, das in ein paar Monaten für die Katz sein wird.
Letzter Kommentar: vor 7 Jahren6 Kommentare4 Personen sind an der Diskussion beteiligt
Schon wieder ich. Hier wurde bemängelt, dass aus MiB das gebräuchlichere MB wird. Der Wert zeigt in diesem Fall aber wirklich MiB. Gibt es eine offizielle Regelung welches Präfix in der WP verwendet werden soll? --Hadibe (Diskussion) 10:41, 2. Dez. 2016 (CET)
Die Angaben sind grobe, ungefähre Schätzwerte, die jemanden mit langsamem oder teurem Internet vor großen Dateien warnen sollen, auch wenn man von seinem einen GB pro Monat inklusive nach 3 Wochen schon 900 MB runter hat und die letzte Woche über mit rund 100 MB auskommen muss.
„MB“ ist eine laienverständliche und wie auch „kB“ seit anderthalb Jahrzehten in der Wikipedia flächendeckend eingesetzte Bezeichnung für diese näherungsweise Abschätzung.
Die „KiB“ und „MiB“ sind hochpräzise Angaben für Nerds, die berücksichtigen, dass die Berechnungsgrundlage nicht 1000, sondern 1024 wären, und somit die Zahlenangaben eine Ungenauigkeit von 2,4 % haben könnten. Was bei einem Verkaufsprospekt für eine Festplatte eine Rolle spielen könnte, für unseren Zweck hingegen völlig wurscht ist.
Die Beschriftungen in gängigen Betriebssystemen, bei Tools und überall sonstwo sind alle in kB und MB und damit laientauglich; „KiB“ und „MiB“ kapiert keine Sau. Die enWP schreibt durchgängig nur „KB“.
Naja, das ist auch mehr oder weniger eine persönliche Sicht von PeCh (würde ich jedoch fast sagen Kakophemismus, da negativ und einseitig, allein auch weil hier Leute die Missverständnissen entgegenwirken wollen und sich an internationale Standards halten möchten als Nerds bezeichnet werden, auch wenn dies wohl im schlimmsten Fall zutreffend ist) jedoch wohl auch zugegeben die gängigste Meinung . Im Groben kann ich diese Ansicht für Wikipedia nachvollziehen. "Ergänzend:" Bei MB sind es allerdings schon 4,86 % und bei TB schon 10 % (normale Festplatteneinheit), jedoch für den Gebrauch in WP wohl tatsächlich irrelevant. Und auch das mit den Betriebssystemen habe ich anders gehört, einzig Microsoft tanzt hier noch auf alten Brettern. ↔ User: Perhelion15:12, 2. Dez. 2016 (CET)
PS: Genauigkeit: Die Nerds haben es auch erfunden und verbreitet. Bei einer gängigen 4 MB Größe (für PDF) kommen wir hier somit schon auf eine Ungenauigkeit der Nachkommastelle im ungünstigsten Fall von ±2, ab 10,5 MB schon auf ±5, was dann bei vollem Aufrunden ein Ganzes ausmachen kann.
Ich sehe das wie Umgangssprache, ist gängig, versteht fast jeder aber trotzdem schreibt man formell einen Standard. In der Tat ist dieser Standard unglücklicher Weise sehr spät entstanden, was natürlich für eine Verbreitung bzw. Akzeptanz in den breiten Sprachgebrauch gegangenem Begriff überaus schwer ist. Für eine Normierung hier in Wikipedia sehe ich allerdings den Zeitpunkt auch noch etwas zu früh, bzw. fällt dann unter, beides ist richtig.
Hallo Perhelion, soll ich ehrlich sein? Mir sagen weder KiB oder MiB noch GiB oder TiB irgendetwas, auch wenn ich genau weiß, dass PC mir das schon mal erklärt hat, ist es mir völlig fremd und ich stolpere jedes Mal wieder über diese Angaben. Und mir hilft das auch so gesehen nienicht weiter. Wenn ich sehe 100 MB, dann denke ich, ja das könnte deinen Rechner etwas überfordern, der ist sehr Anfällig bei langen Ladezeiten und der FF schmiert mir regelmäßig ab. Unter Kibibytes kann ich mir nichts vorstellen und bin eigentlich froh darüber, wenn ich mir darüber keine Gedanken machen muss, was genau mir das sagen soll, oder ob das 5% größer wäre als kB. Ich hatte mal eine Festplatte an meinem Atari und die hatte sage und schreibe 30 MB Speicherplatz, sie ist nie voll geworden und kam mir immer megamäßig groß vor. Heute hingegen wäre sie unvorstellbar klein. --Liebe Grüße, LómelindeDiskussion19:31, 2. Dez. 2016 (CET)
Anker erkennen?
Letzter Kommentar: vor 7 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo PerfektesChaos, wäre es möglich bei der Formatierung die Anker zu erkennen und gegebenenfalls zu ignorieren?
* {{Literatur
|Autor=Bernhard Bruder
|Titel=Geschönte Steine. Das Erkennen von Imitationen und Manipulationen bei Edel- und Schmucksteinen
|Verlag=Neue Erde
|Datum=1998
|ISBN=3-89060-025-5}}
* {{Anker|Bruder}}{{Literatur |Autor=Bernhard Bruder |Titel=Geschönte Steine |Verlag=Neue Erde Verlag |Datum=2005 |ISBN=3-89060-025-5}}
* {{Literatur
|Autor=Bernhard Bruder
|Titel=Welcher Heilstein ist das? 155 Heilsteine, 485 Varietäten.
|Verlag=Kosmos
|Ort=Stuttgart
|Datum=2015
|ISBN=978-3-440-13551-8}}
Warum in anderen NR irgendwas anders sein soll, weiß ich grad nicht; wobei WPNR und HNR keine Sichtungsnamensräume sind, sondern nur ANR und das, was darin eingebunden wird, nämlich Bilder, Vorlagen und Module.
Das „Früher war alles besser“ ödet nur an. Zu Weihnachten haben sich alle an die neuen Farben gewöhnt, nächstes Jahr kann sich keiner mehr erinnern, dass es jemals andere gegeben hatte, aber die WP von 2005, in der man mal angefangen hatte, an der darf kein Knöpfchen und kein Strichelchen verändert worden sein.
Die auffälligere Rötlichfärbung war Benutzerwunsch, damit Sichtungsbedarf besser ins Auge fallen solle.
Es gibt neben den Versionen einer Seite auch Farbmarkierung in den Benutzerbeiträgen von Newbies.
Zur 600 hatte ich einen Block von Hilfeseiten zur Überarbeitung als Lockerungsübung vorgesehen. Das wird mir momentan zu viel HNR zu schnell auf einmal; wir schieben dann eine kleine Zitationsvorlage mit Generierung von Seitendigitalisat-URL zwischen.
Ja groß ist schon klar, habe ich drüben auch schon geändert mit anders meinte ich dass ich „blau“ mit einbauen sollte. Bis später. --Liebe Grüße, LómelindeDiskussion11:14, 4. Dez. 2016 (CET)
Bearbeitungskommentar
Letzter Kommentar: vor 7 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
Kann man im Kommentar auch Variablen verwenden oder übernimmt WSTM ausschließlich den Text so wie er dort eingetragen ist? --Hadibe (Diskussion) 22:31, 4. Dez. 2016 (CET)
Der Text kann die aktuelle Mondphase enthalten, um die Quersumme der momentanen Uhrzeit ergänzt, mitsamt dem Resultat einer API-Anfrage, dazu an Variablen alles, das auf WP:JS/V erwähnt ist.
Oh, das ist mir zu hoch. Eigentlich wollte ich den Kommentar abhängig von der Tageszeit belegen, vormittags den, abends den. Oder betriebssystem- oder browserabhängig. Eines von beidem gilt immer und da mache in der Regel das gleiche. Aber da ich auf deiner verlinkten Seite schon nichts verstehe, muss ich das wohl seinlassen. --Hadibe (Diskussion) 20:48, 5. Dez. 2016 (CET)
Wenn du solche Wünsche hast, wirst du dich minimal mit WP:JS #JavaScript lernen beschäftigen müssen.
Es geht nicht an, dass auf einer Seite, die nur du bearbeiten kannst, für die Änderung jedes Kommas jemand anders dir aufschreiben muss, was zu tun ist.
Nachfolger ist in Erprobung; erwähnte ich schon mal.
Wenn ihr nicht so gedrängelt und auf 2016 bestanden hättet, wäre die Verwechslung nicht passiert.
Richtet keinen Schaden an. Keine Eile.
Das ist Absicht.
Die Website heißt: weltfussball.de
Der Name der Vorlage ist unerwünscht. Drei-Buchstaben-Abkürzungen sind außer bei Flag-Icons nicht erwünscht; und wenn, dann nur mit drei Großbuchstaben. Kleinbuchstaben sind für potenzielle Sprachcodes reserviert. Vorlage:WFB gibt es aber gar nicht.
WFB ist keine Abkürzung, die man kennen oder verstehen muss, sondern blanke Schreibfaulheit in einer Universal-Enzyklopädie aller Themen. Es ist eine WP-private Abkürzung für eine private Website, deren Abkürzung hundert andere genauso wichtige Bedeutungen haben könnte.
In irgendeinem Jahrzehnt wird irgendwer WL und Programmierung miteinander tauschen.
War Betriebsunfall von 2008, als es wenige Hundert Vorlagen gegeben hatte, die alle Benutzer noch alle beim Namen kannten.
Die Sportler mit ihrem unbelehrbaren prettytable gehen mir aber sowieso auf den Sender; ich habe weder Lust noch Zeit noch Nerven, mit denen rumzudiskutieren.
Ich weis, ich weis, dass ich drängle, ich wollte nur keine zusätzlichen Fehler in die Artikel einbauen, welche dann später wieder behoben werden müssen. mfg --Crazy188010:48, 8. Dez. 2016 (CET)
Migrationshilfe?
Letzter Kommentar: vor 7 Jahren7 Kommentare2 Personen sind an der Diskussion beteiligt
Moin, ich hatte mich hier an einer Ablösung meines alten Skriptes versucht, komme aber nicht so richtig weiter.
Wie erreiche ich, dass [[Schauspielerin]] zu [[Schauspieler]]in wird und nicht zu [[Schauspieler]]?
Wie erreiche ich, dass [[USA]] zu [[Vereinigte Staaten|USA]] wird und [[USA|amerikanische]] zu [[Vereinigte Staaten|amerikanische]]?
Letzter Kommentar: vor 7 Jahren7 Kommentare2 Personen sind an der Diskussion beteiligt
Moin Moin PerfektesChaos, ich bräuchte noch mal kurz Hilfe und ich glaube, du kannst es mir schnell beantworten. Ich habe folgendes, was ich in meine js schreiben möchte:
Habe ich es allerdings so eingebaut, startet WSTM gar nicht mehr. Kann es sein weil alles Internetquelle, dass er dann damit nicht klar kommt? Oder mache ich einen Denkfehler? Danke dir schon mal. mfg --Crazy188015:48, 12. Dez. 2016 (CET)
Der Ausdruck { detect: ist etwas, das auf der rechten Seite eines Gleichheitszeichens stehen müsste.
Ich weiß nicht, ob die nowiki im JS-Quellcode stehen oder nur hier überflüssigerweise am pre dranstehen (in den sind die sowieso eingebaut) – falls ja, müssen sie mit // auskommentiert werden, und das zweite kauft ein i.
Jetzt hat sich ja erstmal die linke Seite vom Gleichheitszeichens angefunden, und das Gleichheitszeichen auch.
Nun das nächste Problem: Vor dem autor/i fehlt im Minimum ein Schrägstrich, damit es wenigstens syntaktisch richtig wird.
Eigentlich meinst du wohl /^autor$/i – das ist etwas, das mit a anfängt und mit r aufhört, und bei dem Groß- und Kleinschreibung egal ist.
/autor/i gäbe es auch; das ist jeder Parametername, der irgendwie irgendwo autor enthalten würde.
var Internetquelle ist nicht so das Problem; außer, es gibt bei dir noch ein Skript von irgendwem, der eine Variable mit Namen Internetquelle benutzt. Dem zerschießt du dann ggf. seine Funktion, oder er vielleicht dir, je nachdem, wer wann unter welchen Umständen zum Zuge käme.
Zumindest ist es jetzt syntaktisch richtig, sollte dich nicht mehr abstürzen lassen, und vom einfachen Draufgucken her macht es vermutlich das, was du erwartest. LG --PerfektesChaos16:57, 12. Dez. 2016 (CET)
Letzter Kommentar: vor 7 Jahren8 Kommentare2 Personen sind an der Diskussion beteiligt
Moin Moin PerfektesChaos, ich weis, dass ich viel Nachfrage. Heute mal in den Bereich Vorlagenersetzung. Kann ich das im JS mit einer Massentabelle machen? Den Punkt habe ich schon im JS drinnen, allerdings möchte ich nicht für alle Vorlagen ein einzelnes detect setzen, sondern eher eine Tabelle definieren. Wäre das möglich? mfg --Crazy188017:24, 14. Dez. 2016 (CET)
Ich verstehe die Frage nicht; insbesondere das Wort „Massentabelle“.
Was es gibt, ist der Umstand, dass die detect ein regulärer Ausdruck sind und damit auf viele Vorlagen passend gemacht werden könnten, die gleiche Struktur haben.
Was mir nebenbei bemerkt missfällt, ist dein Vorgehen gegen IOC-Flagicons als Weiterleitungen.
Davon gibt es Hunderttausende Einbindungen, und die richten keinerlei Schaden an.
Als mögliche Weiterleitungen werden sie auch bestehen bleiben, bzw. sollen das auch.
Ich finde es auch dämlich, für denselben Sachverhalt zwei verschiedene Drei-Buchstaben-Codes zu haben. Obendrein, was von vornherein der schlauere Weg gewesen wäre, womöglich noch einen Zwei-Buchstaben-Code, wie er von den Internet-Domains bekannter sein dürfte – aber dafür ist es zu spät, das hatte man vor einem Jahrzehnt versemmelt.
Ich bin auch nicht glücklich darüber, wenn bei Städtepartnerschaften obskure abweichende unbekannte Drei-Buchstaben-Codes auftauchen, und unterstütze es, die Dinger langfristig – in einem Jahrzehnt – aus den Köpfen und Städte-Artikeln zu drängen. In sportlichen Angelegenheiten wirst du die Dinger aber so schnell nicht loswerden.
Die Sportler hatten sich mal ausdrücklich die IOC-Codes als gleichberechtigte Alterntive gewünscht, weil sie mit denen vertrauter wären.
Ich sehe viele andere Wartungsaufgaben als dringlicher an; inbesondere habe ich nach mehr als einem halben Jahr die Nase voll von der Lit-Vorlage und ihren Einbindern.
Also was du da bebsichtigst, macht WSTM zu einem geeigneten Zeitpunkt 2017 für alle Anwender von Amts wegen für die ganze ISO.
Sportler kennen möglicherweise nur „ihren“ Code und keinen anderen. {{Niederlande}} und {{NED}} sind legitime WL auf {{NLD}}. Nicht jede WL ist böööööse, auch nicht bei Vorlagen.
Grundsätzlich ja alles richtig, aber dann können wir auch noch tausende Vorlagen anlegen und am Ende kann jeder machen, was er/sie will. (Ich weis, leidiges Thema)
Wenn jemand etwas möchte, kann/darf er mich gerne ansprechen und wir versuchen einen Konsenz zu schaffen. Wir sind ein Wiki.
Naja, im Prinzip darf jeder dauernd neue Vorlagen anlegen, und bestehende mit unpassendem Namen auf bessere Namen verschieben, wodurch neue WL entstehen, zumindest zeitweise.
Die IOC sind halt 100–200 am Stück mit einem Jahrzehnt Bestand und mehrere-1000-facher Einbindungen; die können nicht im Hauruckverfahren eliminiert werden, sondern nur ganz allmählich in Vergessenheit geraten. Haben auch eine Art Bestandsschutz, bis auf Weiteres.
Falsches Komma im Datum von Personendaten führt zu Informationsverlust
Letzter Kommentar: vor 7 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo PerfektesChaos, es scheint, dass bei der Bearbeitung des Datums in Personendaten WSTM in gewissen (syntaktisch inkorrekten) Fällen Information tilgt. Es kommt recht oft vor, dass Benutzer fälschlich intuitiv naheliegende Reihen wie '1793, 1798 oder 1805' eintragen. In einer derartigen Reihe scheint alles zu klappen, nicht aber in der komplizierteren Reihe
WSTM ist offensichtlich überfordert, ein tagesgenaues Einzeldatum in Verbindung mit einer auch noch absteigenden Reihe pauschaler Jahreszahlen zuzuordnen. Hier kommt aber immerhin wohl das erste Jahr (1750) oder das letzte (1759) noch an, und der Zeitraum bleibt erhalten. Ob die Anwender das nun so gemeint hatten, dass auch für die Jahre 1756 und 1750 der 4. April gelten soll, bleibt im Vorlagenparameter im Dunkeln; für die Ziele der PD ist das sowieso kaum verwertbar.
Zukünftig wird aber die neue Vorlagenprogrammierung (BETA) die Bearbeiter sofort auf den Fehler aufmerksam machen, und ich denke damit ist für genügend Aufmerkamkeit gesorgt.
Letzter Kommentar: vor 7 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Gibt es zufällig einen Modus, der auch neu eingegebene Texte gleich prüft/bearbeitet/ersetzt, sobald eine neue Vorschau geladen wird o.Ä.? Gruß, --Flominator14:56, 15. Jan. 2017 (CET)
Es gibt nur ein „Ersetzen“, und den durch submit automatisch auszulösen wäre tödlich, weil du dann keine Chance mehr hättest, eine beabsichtigte ausnahmsweise abweichende Angelegenheit sinnvoll abzuspeichern.
Letzter Kommentar: vor 7 Jahren15 Kommentare3 Personen sind an der Diskussion beteiligt
Beim Verschieben der Kategorien in eine neue Zeile hängt das Script eine zusätzliche schließende Klammer an die vorhergehende Kategorie, wenn beide ohne Leerzeichen direkt hintereinander geschrieben wurden, Beispiel. --Hadibe (Diskussion) 05:58, 30. Jan. 2017 (CET)
#REDIRECT [[Groß-Siegharts]][[Kategorie:Ort im Bezirk Waidhofen an der Thaya]] [[Kategorie:Ehemalige Gemeinde in Niederösterreich]]
1. Durchlauf WSTM Autostart
#WEITERLEITUNG [[Groß-Siegharts]
[[Kategorie:Ort im Bezirk Waidhofen an der Thaya]]
[[Kategorie:Ehemalige Gemeinde in Niederösterreich]]
WSTM sagt: Zweite schließende Klammer gesetzt Groß-Siegharts]
stimmt aber nicht es wurde eher eine Klammen gemopst
zweiter manueller Start
#WEITERLEITUNG [[Groß-Siegharts]]]
[[Kategorie:Ort im Bezirk Waidhofen an der Thaya]]
[[Kategorie:Ehemalige Gemeinde in Niederösterreich]]
WSTM sagt: Zweite schließende Klammer gesetzt Groß-Siegharts]
nun sind es drei
vorher ohne Leerzeichen zwischen den Kats
#REDIRECT [[Groß-Siegharts]][[Kategorie:Ort im Bezirk Waidhofen an der Thaya]][[Kategorie:Ehemalige Gemeinde in Niederösterreich]]
1. Durchlauf WSTM Autostart
#WEITERLEITUNG [[Groß-Siegharts]
[[Kategorie:Ort im Bezirk Waidhofen an der Thaya]
[[Kategorie:Ehemalige Gemeinde in Niederösterreich]]
WSTM mopst an den Berührungspunkten die zweiten schließenden Klammern
zweiter manueller Start
#WEITERLEITUNG [[Groß-Siegharts]]]
[[Kategorie:Ort im Bezirk Waidhofen an der Thaya]]]
[[Kategorie:Ehemalige Gemeinde in Niederösterreich]]
WSTM sagt: Zweite schließende Klammer gesetzt Groß-Siegharts] Zweite schließende Klammer gesetzt Kategorie:Ort im Bezirk Waidhofen an der Thaya]
jeweils 3
Selbiges würde auch Interwikilinks betreffen, die aneinandergereiht wären. Kurzzeitig sehe ich auch, dass tatsächlich zunächst eine Klammer angehängt wird, aber wenn WSTM fertig ist fehlt sie dann.
Beispiel
[[Kategorie:Ehemaliges Kloster in Oberösterreich]][[Kategorie:Ehemaliges Karmelitenkloster]][[Kategorie:Erbaut im 15. Jahrhundert]][[Kategorie:Zerstört im 19. Jahrhundert]]
kurz sichtbar oder einmal über Browser zurück (ich weiß soll ich nicht)
[[Kategorie:Ehemaliges Kloster in Oberösterreich]]]
[[Kategorie:Ehemaliges Karmelitenkloster]]]
[[Kategorie:Erbaut im 15. Jahrhundert]]]
[[Kategorie:Zerstört im 19. Jahrhundert]]
und im Artikel stünde
[[Kategorie:Ehemaliges Kloster in Oberösterreich]
[[Kategorie:Ehemaliges Karmelitenkloster]
[[Kategorie:Erbaut im 15. Jahrhundert]
[[Kategorie:Zerstört im 19. Jahrhundert]]
Kannst du dir auch mal Parlamentsbibliothek öffnen und schauen was dort merkwürdiges passiert?
Beim ersten Artikel wird eine Klammer gestohlen, bei den anderen ergänzt. WPSK verzeichnet aktuell 88 Artikel bei denen die Kategorie in eine neue Zeile geschoben werden muss, zu den von dir verlinkten 20 würden also noch ein paar dazukommen. --Hadibe (Diskussion) 14:08, 30. Jan. 2017 (CET)
Mutmaßlich den ersten Bug in Fistritz scheine ich erlegt zu haben. Bin ich mir aber noch nicht ganz sicher.
Heute spät abends in die d-Erprobung.
Nächste Woche für alle live.
@Hadibe: Bist du eigentich Vorkoster im d-Klub oder arbeitest du wie das gemeine Volk auf r? Ich habe völlig den Überblick verloren. Nebenbei sind drei Kleinbuchstaben als Name einer Vorlage nur etwas für exotische Sprachcodes; wenn man sie nicht alle selbst tippen muss, ist der selbsterklärende volle Name vorzuziehen.
d.js. Bei etwaigen Fehlern – es sind sehr wenige – muss ich allerdings zuerst meine eigenen Frickeleien im Script verdächtigen. Deshalb kommen auch nur selten Meldungen meinerseits.
Am Wochenende hatte ich schon einige Fälle gefunden, allerdings ausschließlich bei Weiterleitungen österreichischer Orte. Deshalb habe ich mich auch nicht beschwert. Heute früh tauchte dann ein anderer Artikel auf, deshalb wollte ich mich mal melden. Können die Orte abgearbeitet werden, wenn ich darauf stoße? Oder lieber warten? --Hadibe (Diskussion) 17:45, 30. Jan. 2017 (CET)
Mit d.js kannst du morgen drangehen.
Ich will erstmal die Auswirkungen des einen Fixes stabil überschauen, bevor ich womöglich weitere Probleme angehe.
Der fragliche Code war von 2012, hat jahrelang keinen Ärger gemacht, und ich habe alles vergessen, was ich vor fünf Jahren mal programmiert hatte.
Parlamentsbibliothek ist soweit erwartungsgemäß; wenn man eine Kategorisierung ohne Doppelpunkt unter Weblinks aufführt, dann macht die sich bemerkbar.
Ja das dachte ich mir schon, aber da wird ja auch eine Klammer weggenommen und zwar am Ende des Weblinks. Deshalb sagte ich ja „schau mal da rein“. Ich finde es nicht normal, wenn anschließend der Weblink doof und unformatiert daherkommt, dass das ganze so wie es da eingefügt wurde Murks ist, ist mir schon klar gewesen. --Liebe Grüße, LómelindeDiskussion19:51, 30. Jan. 2017 (CET)
Es kommen bei mir aber noch etwas verwirrende Meldungen an.
Im Text wurden schwere Fehler gefunden.
Nicht alles lässt sich automatisch beheben. Bitte kläre die folgenden Probleme von Hand:
Wikilink-'[[' seltsam
[Kategorie:Ehemaliges Karmelitenkloster]][[Kategor
Wikilink-'[[' seltsam
[Kategorie:Erbaut im 15. Jahrhundert]][[Kategorie:
Wikilink-'[[' seltsam
[Kategorie:Zerstört im 19. Jahrhundert]]
Von den ehemals 28 Artikeln sind noch 14 übrig, zwei davon Fußballer, die mache ich morgen früh. Die restlichen sind entweder die hier verlinkten Artikel oder die Kategorien sind auskommentiert. Diese muss ich am PC kontrollieren. --Hadibe (Diskussion) 23:19, 31. Jan. 2017 (CET)
Alle bis auf den Fußballtrainer bereinigt. Den wirst du aber vernachlässigen können, denn wie groß ist die Wahrscheinlichkeit, dass erneut jemand die zweite schließende Klammer der Kategorie in eine neue Zeile verschiebt? Damit kann das Skript nicht klarkommen. --Hadibe (Diskussion) 08:30, 1. Feb. 2017 (CET)
Ich sage jedenfalls „Danke“, hatte das auch schon heute morgen erfreut festgestellt.
Ob nun Grand Tour selbst seine letzten Regimenter abgezogen hat, ist mir nicht so ganz klar.
Jedenfalls habe ich mir bereits ein Zeitfenster ausgeguckt, um die nächsten beiden Updates der Programmierung hier live zu schalten. Das könnte womöglich neue Fehlersituationen auslösen, ist allerdings tendenziell eher duldsam betreffend gewisser Umstände. Allerdings der richtige Moment, um neue Merkwürdigkeiten zu detektieren; darüber muss ich noch sinnieren. Mein Problem ist, dass momentan wesentlich mehr schwierige Programmiergeschichten auf mich einprasseln, als ich qualifiziert abarbeiten kann. Ich muss jetzt erstmal einige Sachen zu Ende bringen.
Alles kein Problem, wenn du das Thema schon kennst bin ich ja beruhigt. Solange ich das vor dem Abschicken merke, stört mich das auch nicht. Dafür sorgen momentan eher Kommas, Klammern und Anführungszeichen innerhalb von Wikilinks. --Hadibe (Diskussion) 16:10, 10. Feb. 2017 (CET)
Immer noch Datumsschwund wenn ISBN leer
Letzter Kommentar: vor 7 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo PerfektesChaos, irgendwann hatte ich das schon einmal angesprochen und dachte es sei behoben aber öffne bitte mal Selma Al-Radi, schau auf die erste Literaturangabe zu The New York Times da geht mal wieder Monat und Tag verloren weil |ISBN=|, der VE fügt bevorzugt diese ISBN (auch leer) mit ein, wenn man die nicht ausdrücklich aus der oberen Liste des Dialogfeldes entfernt. Jeder Aufruf mit Bearbeitung an diesem Eintrag, wir die vermutlich wieder hinzufügen, da sie ein erwünschter/vorgeschlagener Parameter ist. Das macht es zu einem Lotteriespiel, selbst wenn ich die also jetzt von Hand rausnehme und das Datum wieder ergänze könnte es zwei Edits weiter wieder dazu kommen, dass nur das Jahr übrig bleibt. Ich habe das in der Vorschau getestet und die ISBN, die ich zuvor gelöscht hatte, war wieder dort, da der Artikelersteller den VE benutzt … muss ich da sehr aufpassen, dass mir das nicht durch die Lappen geht. --Liebe Grüße, LómelindeDiskussion16:08, 8. Feb. 2017 (CET)
Ich bin auf so vielen Hochzeiten tänzelnd, dass ich nicht mehr genau weiß, was wann an welcher Software war.
Den fraglichen Passus erneut programmiert; scheint dann jetzt besser zu laufen.
Ja das scheint besser zu sein, wobei jetzt aber bei vorhandener ISB-Nummer Tag und Monat erhalten bleiben. Ich finde das nicht so schlimm, das ist zumindest mal besser, als wenn etwas verloren geht. --Liebe Grüße, LómelindeDiskussion08:43, 9. Feb. 2017 (CET)
PMC, warum?
Letzter Kommentar: vor 7 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Nachsatz: Ich denke mal, dass es nur in 10%-Schritten geht - dazu hab ich aber unter Hilfe:Bilder nichts gefunden.
Steht doch dort: Die Breite der so berechneten Vorschaubilder wird immer auf den nächsthöheren 10er-Wert aufgerundet.129.13.72.19812:27, 13. Feb. 2017 (CET)
Es war in der Tat ein Bug in WSTM, wo Werte bei =0.0 nicht erwartet wurden.
Es wurden fälschlich die Nachkommastellen als ganzzahlig betrachtet; somit die führende Null eliminiert.
Jetzt wird alles, was unterhalb von 0.1 liegt, auf Minimum =0.1 hochgesetzt.
Ansonsten die zweite Nachkommastelle usw. radikal abgeschnitten.
Fix ist live zur Erprobung.
Im Artikel war sowieso Unsinn angestellt worden:
Die 85×85 Pixel großen Symbole sollten mittels exotischer hochkant-Werte als entartete superschlanke Fernsehtürme dargestellt werden, damit die richtigen Breiten und Höhen in Pixeln herauskämen.
Das jetzt durch explizite 16px sauber geregelt.
Außerdem mit Tabelle robust zu den lateinichen Buchstaben synchronisiert: Spezial:Diff/162635820
Na, dann mach doch – WSTM würde da jetzt überall hochkant=0.1 draus machen; aber das muss ja durch jeweils angemessene px ersetzt werden. VG --PerfektesChaos13:52, 15. Feb. 2017 (CET)
End-Minus bei ALTERNATIVNAMEN wird gelöscht
Letzter Kommentar: vor 7 Jahren5 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo Perfektes Chaos, WSTM scheint fehlerhafterweise ein die ALTERNATIVNAMEN der PD abschließendes Minus zu löschen, s. z.B. bei Az-Zāhir bi-amr Allāh. Das ist falsch, wenn korrekterweise der Artikel arabischer Namen (mit dem Strich) an das Ende gestellt wird. Dies kommt zwar häufiger bei NAME vor, wo der Fehler nicht auftritt, aber auch bei den ALTERNATIVNAMEN, deren Bildung ja (mindestens theoretisch) ebenso erfolgt wie die von NAME. Es grüßt, --Griot (Diskussion) 18:44, 20. Feb. 2017 (CET)
ALTERNATIVNAMEN auf - endend
Das war mir so als unerwünscht aufgetragen worden.
WSTM für PD geht jetzt ins achte Jahr.
Ich habe nunmehr einen Fix in Erprobung.
Wenn endend auf " al-" oder " az-", so wird - wieder angehängt. Noch mehr Silben?
Die ALTERNATIVNAMEN sind wesentlich länger und unübersichtlicher als NAME. Es wird auch nach bürgerlich eigentlich richtigen vollen Namen gesucht und ersetzt, und durch die Aufzählung von allerlei Kombinationen kommt es häufiger zu C&P-Schrott. Deshalb gibt es hier eine intensivere Analyse als bei NAME.
Sortierung
Ich habe es nicht vergessen, und den Lua-Code zur Einbindung auch bereits verändert; teilweise schon auf BETA sichtbar.
Letzten November war ich im Flow gewesen; es hätte sofort umgesetzt werden können.
Die mehrmonatige Unterbrechung hatte der Angelegenheit nicht gutgetan.
In der Zwischenzeit hatte ich nicht untätig auf Sortierung gewartet, sondern habe mehrere Baustellen akut offen, die erstmal beendet werden müssen, bevor ich mich wieder in die PD-Sortierung einarbeiten kann, deren Details ich zwischenzeitlich völlig aus meinem Hirn geräumt habe.
Da die allgemeine Sortierung synchron zu PD läuft und wegen des Wartens auf die PD-Sortierung ebenfalls abgebrochen werden musste, eilt es ja nun auch nicht mehr.
ad-, adh-, al-, an-, ar-, as-, asch-, at-, ath-, az-, wobei aber die gleichen Formen auch mit 'A' möglich sind.
(aḏ-, aḍ-, aṣ-, aš-, aṯ-, aṭ-, aẓ- könnten zwar auch vorkommen, wären jedoch nicht regelgerecht; in diesen Fällen hielte ich es für tolerierbar, wenn das '-' gestrichen wird.)
2. Zum Abschluss des Codes zur Sortierung brauche ich irgendwann noch Deine Entscheidung, wie Du die Resultate haben möchtest – das Problem war, dass es mehr als eine römische Zahl in einem Namen geben kann. Inzwischen habe ich eine Routine geschrieben, die fehlerhafte NAME-Ansetzungen erkennen soll. Bisher findet sie etwa 850. Die Hauptschwierigkeit ist, dass die Regeln sehr vage, teils gar direkt widersprüchlich sind, teils auch einfach fehlen. Ich versuche gerade, in die Regeln für arabische Namen etwas mehr Klarheit zu bringen. Es grüßt, --Griot (Diskussion) 02:18, 21. Feb. 2017 (CET)
Die weiteren Namenspartikel habe ich gerade WSTM verklickert.
Zur Sortierung habe ich nur in Erinnerung, dass ein drittter Rückgabewert anstand; an der Stelle brach es aber ab.
Deine Namensfunktion kannst du ebenfalls in das Plugin einbauen; allerdings unter einem anderen Funktionsnamen.
Im Plugin müssten wir dann auf diverse Bibliotheksfunktionen statt Eigenbau übergehen; aber wenn du sowieso da grad dran bist, dann mach einstweilen.
Letzter Kommentar: vor 7 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Hat schon einmal jemand den Fall gehabt, dass ein Linktext entfernt und als Parameter in einem völlig unabhängigen Bild eingefügt wird? Hier wird |Dornberg vom Abschnitt Verkehr nach Geschichte verschoben. --Hadibe (Diskussion) 20:00, 2. Mär. 2017 (CET)
Bitte überprüfe deine eigenen Ersetzungsregeln, sofern du solche hast.
Ich habe gerade den noch unbearbeiteten Artikel geöffnet, und es wurde nur eigentlich nur im Literatur-Abschnitt umgebaut; auch zwei Leerzeichen vor <ref weggenommen und eins bei "gov"/> eingefügt.
Letzter Kommentar: vor 7 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Moin Moin PerfektesChaos, ich habe da mal eine kurze Frage zum Style in deiner Beschreibung. Es dreht sich mir um den Parameter .linebreak. Wie wird denn "sonst" angesprochen. True und false sind mir geläufig, aber "sonst" kann ich nicht interpretieren. Kannst du mir helfen, danke schonmal. mfg --Crazy188012:48, 7. Mär. 2017 (CET)
Mh, irgendwie funktioniert das bei mir nicht so richtig. Ich habe ein bisschen experimentiert, bekomme aber nichts vernünftiges hin. Entweder es zieht alles zusammen oder klappt alles auseinander. Eigentlich möchte ich doch nur, dass das Format, wie es war beibehalten wird (also im Bereich Literatur z.B.). Gibt es noch einen Trick den ich versuchen könnte? Ansonsten danke für deine Zeit. mfg --Crazy188018:31, 7. Mär. 2017 (CET)
Caret
Letzter Kommentar: vor 7 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo PerfektesChaos, mir ist dbzgl. eine kleine Unannehmlichkeit aufgefallen. Die Cursormarke springt immer ans Ende bei mir, könnte man da was machen?Z.B. -- User: Perhelion13:12, 7. Mär. 2017 (CET)
Ich weiß weder, was du von mir willst, noch was ich mit dem Link anfangen soll.
In dem Link geht es darum, dass jemand das Feld nicht mit .val() anfassen will, wenn der Inhalt nicht verändert wurde.
WSTM schreibt auch nichts in das Textfeld zurück, falls der Wikitext absolut unverändert blieb.
WSTM muss aber den ursprünglichen Inhalt auslesen, und das geht nur mit .val().
Merke: WSTM ist dazu konzipiert, automatisch bei ersten Öffnen zur Quelltextbearbeitung gestartet zu werden, und ggf. den Inhalt zu ändern und zu diffen.
Wenn du irgendwo eine vorherige interaktive Cursorposition behalten möchtest, musst du dich selbst darum kümmern.
Im Moment nur die, die auf der Doku stehen, und die habe ich auch längst vergessen.
Wenn ihr mir mal ein paar Monate Ruhe geben würdet, käme die nächste Serie an Ausbau dran; das ist mir aber zu heikel, um das mal so eben zwischendurch zu machen.
Letzter Kommentar: vor 7 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Moin, hast du vielleicht Lust, statt <ref name=''faz_10102015''> => <ref name="???????" faz_10102015''> (wie hier) für <ref name=''faz_10102015''> => <ref name="faz_10102015"> zu sorgen? Gruß, --Flominator08:37, 12. Apr. 2017 (CEST)
Danke für den Hinweis, aber das ist mir zu heikel.
Für Menschen ist trivial zu erkennen, was gemeint ist.
Eine veränderte Programmierung in WSTM würde sich aber massiv auf alle tags auswirken und hätte schwer abzuschätzende Konsequenzen.
name='' ist erstmal legitime Syntax. Dem Parameter wird eine leere Zeichenkette zugewiesen, das ist in Ordnung.
Danach kommt ein allein stehendes Schlüsselwort faz_10102015 – gibt es hin und wieder bei einigen unserer XML-Elemente.
Zum Schluss kommt ein seltsam lose rumstehendes '' und löst das eigentliche Problem aus.
Für Software ist nicht klar, was gemeint ist.
Mediawiki interpretiert zurzeit den Bezeichner übrigens nicht als faz_10102015, sondern als ''faz_10102015'' identisch mit name="''faz_10102015''". Wenn das an anderer Stelle so verwendet wird und ich manipuliere den Bezeichner, dann ist auch wieder nicht reht.
Da es wohl insgesamt nur sehr wenige Artikel betrifft (und wenige verursachende Benutzer über die Jahre hinweg), ist die manuelle Beseitigung besser geeignet.
Ein zukünftiger besserer Parser könnte bei sowas vielleicht direkt meckern, statt irgendeine Interpretation hinzunehmen.
Letzter Kommentar: vor 7 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt
Moin Moin PerfektesChaos, das neue Einzelnachweis-TAG wird momentan massenhaft vom InkoBot in die Artikel gebracht (<references responsive />). Daraus macht WSTM momentan <references responsive="???" />, weil wahrscheinlich nicht bekannt, oder? Bekommt man das angepasst? Danke im Voraus --Crazy188009:11, 18. Mär. 2017 (CET)
Die fraglichen 11 Bytes hatte ich schon vorgemerkt, auch schon mit Do/Fr auf meiner Festplatte eingefügt.
Ich warte aber meist um die zehn Tage mit Liveschaltung und Doku, weil das öfters mal ein rollback gibt.
Konnte ja nicht ahnen, dass das hier lawinenmäßig eingebaut wird.
Testversion geht heute abend live; werde nachmittags mal ein wenig spielen.
Auf H:EN gibt es mittlerweile einen lustigen Edit-War.
Völlig klar ist, dass die existente Software-Funktionalität zu dokumentieren ist.
Da kann man ja dranschreiben, dass dies zurzeit nicht erwünscht sei.
Die üblichen Verdächtigen scheinen zu glauben, dass die Software-Funktion verschwindet, wenn man die Doku darüber löscht, und Probleme durch Totschweigen zu lösen wären.
Letzter Kommentar: vor 7 Jahren7 Kommentare2 Personen sind an der Diskussion beteiligt
Sollte doch sicherlich nicht im Text eingefügt werden, oder? *** bad selector '/0022-3514.80.5.766' *** bad selector '/0022-3514.80.5.766 *** bad selector '/0022-3514.80.5.766 und das verviefacht sich mit jedem Aufruf von WSTM. Schaust du bitte mal in diesen Artikel. Diederik Stapel --Liebe Grüße, LómelindeDiskussion18:44, 28. Apr. 2017 (CEST)
Strange.
Es ist schon so gedacht, dass WSTM sich in schweren Fällen auf diese Weise bemerkbar macht. Damit sehen das dann nachfolgende Autoren nach dem Abspeichern, und eigentlich WSTM-Bearbeiter vorher auch in der Diffpage.
Verblüffend ist, dass diese komische ID mit einem Schrägstrich beginnend tatsächlich „richtig“ ist.
Trotzdem Quatsch bei der Registrierung gelaufen, der gehört da nicht hin.
WSTM beanstandet ihn.
Lua winkt ihn durch.
Wenn’s geht, lass mir den Artikel mal bis nächsten Monat.
Ich habe es jetzt noch mal ohne diesen doppelten Slash getestet: doi:10.1037/0022-3514.80.5.766 = doi:10.1037//0022-3514.80.5.766. Das ginge auch. Ist mir nicht einmal wirklich aufgefallen, weil ich mir gar keine Gedanken über die Zusammenstellung dieser Nummern mache. Danke fürs anpassen, es ist jetzt jedenfalls weg. Das geht aber gewiss nicht generell überall mit doppeltem //. --Liebe Grüße, LómelindeDiskussion07:34, 29. Apr. 2017 (CEST)
Was ist hier falsch?
Chemical and isotopic … In: Cenozoic volcanism in the Mediterranean area (= Geological Society of America, Special Paper. Band418). 2006, S.171–202, doi:10.1130/2007.2418(09).
Chemical and isotopic … In: Cenozoic volcanism in the Mediterranean area (= Geological Society of America, Special Paper. Band418). 2006, S.171–202, doi:10.1130/2007.2418(09). *** bad selector '2007.2418(09)'
Das „Problem“ ist durchaus bekannt; gehört allerdings zu denjenigen, die sich mit der Zeit von alleine lösen werden.
Die Vorlage macht nichts anderes, als die Spaltenbreite-Angaben in den privaten Experimentalformaten verschiedener Browser anzugeben.
Das liegt daran, dass diese Eigenschaft relativ neu in den Standard aufgenommen wurde.
Nun war im März der Firefox der letzte Browser, der in seinen Serienversionen die Standard-Eigenschaft erkennt. Da in der Regel bei jedem Benutzer die Firefox-Version automatisch auf den letzen Stand gebracht wird, sind die expermentellen Angaben der Vorlage eigentlich nicht mehr nötig.
Wenn du es nur selten und gelegentlich anderer Bearbeitungen machst, könntest du die Vorlageneinbindung durch column-width:30em; ersetzen (oder ganz wegmachen, falls du es unpassend fändest).
In der deutschsprachigen Wikipedia möchten wir in Artikeln unmittelbar verständliche Syntax einsetzen; und die Korrektheit des Quelltextes lässt sich dadurch auch besser überwachen.
Vermutlich ab nächstem Jahr wird dann WSTM alle Einbindungen der Vorlage automatisch auflösen, die noch angetroffen werden.
Diese Vorlage wird auch irgendwann als „veraltet“ markiert werden.
Zeilenumbrüche in Vorlagen Literatur und Internetquelle
Letzter Kommentar: vor 7 Jahren9 Kommentare4 Personen sind an der Diskussion beteiligt
Hallo PerfectChaos,
bin nach meinem Eintrag auf Technische Wünsche hier auf deine Disk verwiesen worden.
Auch wenn ich mich hiermit hier wiederhole, möchte ich dich gerne noch einmal herzlich bitten, die Regel in dem WikiSyntaxTextModule dahingehend zu ändern, dass das Teil vorher prüft, ob es Zeilenumbrüche in den Vorlagen gibt, die dann auch nach Bearbeitung des Artikels wieder erstellt werden, aber wenn es keine Umbrüche gibt, diese dann auch nicht zwangsweise erzeugt werden. Ich bin nicht der Einzige hier, der die bestehende Regel für etwas unsinnig und nervig hält. Wenn es Leute gibt die die Umbrüche mögen, gerne, ebenso gibt es aber auch Leute, die die Zeilenumbrüche in den von ihnen betreuten Artikeln nicht mögen. Dem sollten wir mit der von mir vorgeschlagenen Regel Rechnung tragen. Vor der Einführung dieser Regel in den Tool ging es doch auch...
LG Ulanwp (Diskussion) 16:07, 8. Jun. 2017 (CEST)
Moin Moin Ulanwp, theoretisch könnte es jeder Benutzer des Tool selber einstellen, wie er es gerne hätte (siehe hier). Du würdest es aber gerne, so lese ich es hier, für alle als default haben wollen, richtig? mfg --Crazy188020:56, 8. Jun. 2017 (CEST)
Wir haben doch derzeit das Problem, dass wenn jemand mit dem Tool einen Artikel bearbeitet, zwangsweise der Zeilenumbruch generiert wird. Die editierenden Person, weiß u.U. garnicht was das Tool da anrichtet. Zum anderen kann man von den Nutzern dieses Tool doch nicht verlangen sich mit der nicht ganz einfach zu verstehenden Parametrisierung des Werkzeugs zu beschäftigen, um dann das gewünschte Ergebnis mit den Zeilenumbrüchen zu bekommen. Auch dann würde, wenn ich das richtig verstanden habe, die betreffende Person für jeden Artikel präjudizieren ob CRLF oder nicht, was im Ergebnis zu dem gleichen Problem führt, wie bereits geschildert. Es wäre aus meiner Sicht das Beste, wenn das Tool in Bezug des CRLF nichts unternimmt und die Vorlagen in diesem Punkt unverändert läßt. LG -- Ulanwp (Diskussion) 23:30, 8. Jun. 2017 (CEST)
WSTM kennt nur die Werte der Parameter, nicht aber die Dekoration im Quelltext und was ein Mensch mit den gleichwertigen Quelltextformatierungen vielleicht gemeint haben könnte.
WSTM verdaut alle Inhalte und Parameterwerte, und generiert daraus neue, ggf. korrigierte oder zusammengefasste oder aufgeteilte Parameterwerte.
Falls du dich etwas mit Bio auskennst, hast du vielleicht schon mal was von Metamorphose gehört: Die Innereien der Raupe werden komplett auseinandergenommen, die Moleküle zerlegt, von der ursprünglichen Anatomie bleibt nichts mehr übrig, alles Brei. Aus den Komponenten wird ein neues Tier gebastelt; es entschlüpft ein strahlender Schmetterling.
WSTM kann nur das Ausgabeformat des neuen Parametersatzes entscheiden.
Es gibt eigentlich einen recht soliden Kompromiss:
Im Kernbereich des Artikels wird alles in eine Zeile zusammengeschoben.
Das kommt den späteren Bearbeitern entgegen, die sich über Unübersichtlichkeit des Fließtextes und zu lange Abschnitte und zu umfangreiche Einschübe zwischen Haupt- und Nebensatz beklagen.
Der sogenannte „Hauptautor“ ist nicht der einzige Bearbeiter des Textes; auch andere Wikipedianer müssen damit arbeiten können.
Im hinteren Bereich, also bei Werklisten, Literatur, Weblinks und Einzelnachweisen wird es zeilenweise gegliedert.
Das kommt den späteren Bearbeitern entgegen, die sich im Detail mit den bibliografischen Angaben beschäftigen, dauerhaft überflüssige Parameter entfernen, die Schlüssigkeit und Richtigkeit einzelner Angaben nachprüfen und ggf. korrigieren oder verfeinern.
Wenn alles in eine Zeile geklatscht wird, geht dieser Überblick völlig verloren und ist eine Bearbeitungsbarriere.
In den Schlussabschnitten ist auch des Scrollen in einer Auflistung nicht das Drama; jede Infobox macht es genauso, aus den gleichen Gründen.
Der sogenannte „Hauptautor“ ist nicht der einzige Bearbeiter des Textes; auch andere Wikipedianer müssen damit arbeiten können und für ihre Bemühungen zur Verbesserung des Artikelbestandes Unterstützung erhalten.
Nun gibt es einen Kompromiss, der sich bemüht, den Interessen aller momentanen und zukünftigen Bearbeiter weitmöglichst Rechnung zu tragen, und dann ist es auch irgendwann gut.
Nimmt man die Gesamtheit der Mitautoren aller mit WSTM bearbeiteten Artikel, dann scheint das weitaus überwiegend keine schrecklichen Probleme zu bereiten.
Du musst dir übrigens auch keine Sorgen um deine Neueeland-Artikel machen.
Die werden inzwischen projektweit gemieden; ob der überbordenden Fülle der lang-Vorlageneinbindungen sowie deiner Reaktionen, wenn jemand wagt, „deine“ Artikel anzufassen.
Nebenbei bemerkt kennt textverarbeitende und vorlesende Software durchaus Wörter wie New York oder Washington, wohl auch Sydney und Wellington oder Auckland oder Bridge oder irgendwas, das mit the anfängt und dann vielleicht in einem anderen Wörterbuch nachzuschlagen wäre. Die wissen heutzutage, dass das Englisch ist, und wie es auzusprechen wäre und welche Rechtschreibung in Frage kommt. Deine lang-Vorlageneinbindungen sind überwiegend überflüssig, machen aber den Quelltext völlig unlesbar. Äh, worüber hattest du dich in Sachen WSTM beschwert?
in dem Matsch, der in der jetzigen Diffpage nach der Bearbeitung durch WSTM angezeigt wird, kann niemand die wirklichen Korrekturen des Bearbeiters herauslesen. Da braucht sich keiner zu wundern, wenn die Bearbeitung revertiert wird und die Revertierer ihren Frust in der Zusammenfassungszeile rüberbringen. Ansonsten ist es mir völlig egal, ob da Zeilenumbrüche rein oder rausmontiert werden. Gruß --RonMeier (Diskussion) 21:37, 10. Jun. 2017 (CEST)
SchnarkDiff oder die Mobil-Diffpage nehmen; die kommen damit prima klar und stellen die (Nicht-)Unterschiede nachvollziehbar dar. Wer nur die traditionelle Diffpage kennt, ist natürlich mager dran.
Einmalig umgewandelt und die Reihenfolge belassen, und dann ist auch Ruhe.
Erst einmal vielen Dank für deine Mühe, die komplizierten Sachverhalte zu erklären. Das mit den Lang-Vorlagen lassen wir mal, das ist ein anderes Thema, wozu ich, wenn gewünscht, an anderer Stelle etwas beitragen könnte. Aus deinen obigen Ausführungen kann ich entnehmen, dass die Entscheidung CRLF ja oder nein eine gewollte Entscheidung war und nichts mit der Arbeitsweise des WSTM zu tun hat. Ein Satz dazu hätte genügt. Dass in den Abschnitten Literatur, Weblinks und Einzelnachweisen die CRLF mit Übersichtlichkeit und Wartungsfreundlichkeit argumentiert wird, dies im Artikeltextfluss dann aber nicht mehr so wichtig ist, stellt ein Widerspruch dar, der im Letzteren dann wohl mit der Unübersichtlichkeit des Textes begründet werden wird. So einfach kann es sein ... ;-) Deine Ausführungen wollen heißen: ich muss damit leben, oder? Gruß -- Ulanwp (Diskussion) 00:50, 11. Jun. 2017 (CEST)
@PerfektesChaos Du verstehst es immer noch nicht. Es geht nicht darum was ich verwende, sondern das der Standardnutzer, so er denn nichts anderes verwendet, mit der Standard-Diffpage zurande kommen muss. Und das funktioniert eben so, wie oben beschrieben. Gruß --RonMeier (Diskussion) 19:25, 11. Jun. 2017 (CEST)
ref name ohne "…" aber mit Leerzeichen
Letzter Kommentar: vor 7 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
<ref name=hallo wo bin ich>Text</ref>→<ref name="hallo" wo bin ich="???">Text</ref> Und dazu werde ich angemeckert. Wenn da jetzt ein kompletter Satz stünde, manche Leute tun so etwas, dann käme eine Meldung für jedes Wort, das durch ein Leerzeichen getrennt ist und nicht in "…" verbucht war.
Falsches Attribut-Format im Tag
<ref name=hallo wo bin ich
(2×) Tag mit unbekanntem Attribut
<ref wo>
(2×) Tag mit unbekanntem Attribut
<ref bin>
(2×) Tag mit unbekanntem Attribut
<ref ich=...>
Nicht, dass ich damit nicht klar käme, aber … ich soll nicht fragen, nur was mach ich, wenn mir so etwas auffällt. Viele schreiben Leerzeichen in ref-namen. Toll, ich weiß wieder nicht, wie man das suchen müsste. Und ja ich weiß, WSTM kann nicht wissen, ob da ref name="Bezeichnung" group="Gruppe" oder eben ref name="Bezeichnung group=Gruppe" gemeint wäre, falls jemandem so etwas einfallen sollte zu schreiben. Das ist nur eine Info. --Liebe Grüße, LómelindeDiskussion12:09, 28. Jun. 2017 (CEST)
Doppelpipe zwischen Parameterangaben
Letzter Kommentar: vor 7 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Ich vermute dort müsste eigentlich nur ein Pipe stehen, weil das ja eine Parameterauflistung ist und keine Tabellensyntax, oder? Ob so etwas häufig vorkommen mag, weiß ich nicht. Für Höchstwerte →20-1, weil ich es dort entferne. Aber möglicherweise wären ja auch andere Vorlagen betroffen, ich weiß es nicht. Stecknadeln in Heuhaufen. Nur zum anschauen. --Liebe Grüße, LómelindeDiskussion08:20, 3. Jul. 2017 (CEST)
DOI: bad selector
Letzter Kommentar: vor 7 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Auslösend ist die ungewöhnliche schließende Klammer am Ende des Bezeichners.
Bereits im Mai des Jahres gab es einen solchen Hinweis anhand eines ähnlich seltsamen DOI, weshalb ich auf meiner Festplatte damals den Code angepasst hatte, aber durch Arbeitsüberlastung ging die Bereitstellung nach interner Erprobung irgendwie unter. Jetzt Prozedur angeschoben.
Hätt ich auch gern halbjährlich, aber mein Statistiker hatte seit einiger Zeit Probleme auf der Festplatte mit den GigaBytes für Dumps, und seit VE steht Syntaxvereinheitlichung und Quelltext auch nicht mehr so hoch im Kurs. Müsstest du direkt anhauen. LG --PerfektesChaos13:23, 19. Jul. 2017 (CEST)
Kannst du da bitte mal schaue, dass das nicht passiert. Ich habe gestern eine komplette Seite ruiniert, ohne es zu merken, da ich die Seite über den Lintlink geöffnet und vorher nicht angesehen hatte. Es ist mir nicht aufgefallen, da die Bilder sofort weg waren und ich nicht wusste und vielleicht auch weil meine Aufmerksamkeit etwas nachgelassen hatte. --Liebe Grüße, LómelindeDiskussion07:29, 1. Sep. 2017 (CEST)
Ja das wird es wohl sein, wenn ich es nach hinten tausche, wird lediglich das Leerzeichen zwischen Pipe und Bildbeschreibung entfernt. Es eilt nicht. --Liebe Grüße, LómelindeDiskussion11:56, 1. Sep. 2017 (CEST)
Die Programmierung gibt es seit mindestens November 2015, wahrscheinlich auch schon länger.
Ich habe da mal was gemacht, kann aber noch nicht so recht die Nebenwirkungen einschätzen und habe nach zwei Jahren alles vergessen.
Ach sooo. Es ist, was dir natürlich bewusst sein wird, nicht Vorlagenabhängig, sondern hängt direkt an der mindestens doppelten {{}} auch bei if expr switch [[Datei:Psilocybe aztecorum 106872.jpg|{{#expr: (220 * 429 / 486) round 0}}px|alt=]] oder {{{Variablen}}}. Es könnte also eigentlich sehr viele Fehler verursachen, überall wo diese Klammen direkt auf .jpg| .svg| … folgen, wie {{Center}} oder {{Lang}}. Nicht, wenn sie {einzeln} steht.
So genug davon. Auch ich wünsche dir ein angenehmes Wochenende. Gestern lief es ganz gut, habe wieder etwas gefunden wo man mehr als eine Seite wegkicken kann. --Liebe Grüße, LómelindeDiskussion13:48, 1. Sep. 2017 (CEST)
Ob die {{ zu einer Vorlage oder if expr switch gehören, ist für WSTM nur sekundär und hier nicht weiter maßgeblich. An dieser Stelle beendet WSTM grundsätzlich die Analyse, weil unbekannt ist, was da rauskäme. LG --PerfektesChaos15:21, 1. Sep. 2017 (CEST)
Ich schrieb doch dir ist das klar, mir nicht zwingend. Daher teste ich halt immer alles mögliche. <> ist beispielsweise sauber. --Liebe Grüße, LómelindeDiskussion16:54, 1. Sep. 2017 (CEST)
Aber das Berechnungsverfahren wurde in diesen Listen durchaus sinnvoll angewendet, und mag so auch in ähnlichen Fällen gehandhabt werden. Die Alternative ist nicht zielführend.
Oha, es scheint schlimmer geworden zu sein. Das mit der Bildgröße scheint zu funktionieren aber
[[Datei:William Hogarth 021.jpg|mini|links|{{center|Ölbildversion der ersten Szene}}]]
[[Datei:William Hogarth - A Rake's Progress - Plate 1 - The Young Heir Takes Possession Of The Miser's Effects.jpg|mini|{{center|Bild 1 als Kupferstich}}]]
----
[[Datei:William Hogarth 021.jpg|mini|links{{center|Ölbildversion der ersten Szene}}]]
[[Datei:William Hogarth - A Rake's Progress - Plate 1 - The Young Heir Takes Possession Of The Miser's Effects.jpg|mini{{center|Bild 1 als Kupferstich}}]]
Ich hielt es eigentlich für eine ganz sinnvolle Lösung anstelle von <center>…</center> die Vorlage {{Center}} einzufügen, weil das kürzer und für meine Begriffe auch einfacher ist als <span style="text-align:center">…</span> Du kannst nicht zufällig für bestimmte Vorlagen eine whitelist anlegen und WSTM sagen halt hier keine Pipes entnehmen? Und heute fühle ich mich völlig nutzlos. --Liebe Grüße, LómelindeDiskussion15:21, 9. Sep. 2017 (CEST)
Dann muss ich da heute nacht nochmal nachdenken.
Diese dämliche Zentrierung der Bildlegenden ist überflüssig wie nur was, aber manche Autoren sind ganz wild auf ihren persönlichen Stil. Entweder alle zentriert oder alle normal. Es gibt keinen Grund, warum Artikel A das von Autor X zentriert bekommt und Autor B es im Artikel Y einfach in Ruhe lässt.
Na ja aber es könnten ja auch andere doofe Vorlagen dort stehen, {{Lang}}{{Nowrap}}{{ArS}} was weiß ich, den Leuten fallen die merkwürdigsten Dinge ein. tja, der könnte es auch sein. Ich stelle es mir nicht gerade einfach vor solche Skripte zu warten und auf alle Eventualitäten gefasst zu sein. --Liebe Grüße, LómelindeDiskussion17:27, 9. Sep. 2017 (CEST)
miniatur
Letzter Kommentar: vor 6 Jahren4 Kommentare3 Personen sind an der Diskussion beteiligt
Hi, aus [[Datei: Dietfurt bei Treuchtlingen (1).JPG|miniatur|Wappen des Klosters St. Walburg wird [[Datei:Dietfurt bei Treuchtlingen (1).JPG||iniatur|Wappen des Klosters St. Walburg Gruß --RonMeier (Diskussion) 15:56, 13. Sep. 2017 (CEST)
Hallo RonMeier, das kann ich zwar bestätigen, aber das scheint irgendwie an dem Link zu liegen
[[Datei: Dietfurt bei Treuchtlingen (1).JPG|miniatur|Wappen des Klosters St. Walburg zu Eichstätt am Zehentstadel zu Dietfurt]]
versuch doch mal
[[Datei:Dietfurt bei Treuchtlingen (1).JPG|miniatur|Wappen des Klosters St. Walburg zu Eichstätt am Zehentstadel zu Dietfurt]]
Die Zahlen sind bedauerlich, aber ich kann nichts dagegen machen.
WSTM hat den Eindruck bekommen, dass hinter den Pipes Parameter der Infobox stehen würden, weil die Vorlageneinbindung die Erkennung des Wikilinks und die Zuordnung der Pipe zum Wikilink abgeschossen hat.
Es greift irgendwie um sich, dass ein paar Leutchen jedes Fitzelchen fremdsprachlichen Textes mit der lang-Vorlage dekorieren, obwohl das eigentlich fast nie irgendjemand was bringt. Macht nur das HTML-Dokument länger, den Quelltext komplizierter, aber solange das lateinsche Buchstaben sind, kann niemand was damit anfangen und bleibt wirkungslos.
Repariert halt vorsichtig das, weswegen es auf den Wartungslisten aufschlug, merkt euch die Bearbeiter und ihre Themen, und mehr ist nicht zu tun.
Beim Ló-Beispiel hatte es ja wenigstens eine WSTM-eigene Fehlermeldung ausgelöst.
Dachte ich mir schon, ich kann diese Lang-Vorlage nicht ausstehen. Gut, es hätte ja sein können, dass auch das irgendwie ein Nebeneffekt einer Änderung wäre oder, dass es an einer „meiner“ (ähm ja übernommenen) WSTM-Konfigurationen liegen könnte. Ja es hat zumindest die Zahl in der Internetquelle bemängelt. Ich finde es ziemlich witzlos innerhalb einer Verlinkung eine Langvorlage zu setzen. Ich vermute anders herum würde es keine Probleme bereiten.
Das ist mindestens deutlich kürzer als die ursprüngliche Fassung, die das Ahmet Türk zweimal schrieb; einmal als Linkziel und nochmals als Vorlagenparameter.
Letzter Kommentar: vor 6 Jahren4 Kommentare3 Personen sind an der Diskussion beteiligt
Warum wird eigentlich in Freiheit statt Angst in der Quelle 35 (Jahresbericht 2012 – Was haben wir gemacht?) der Kommentar entfernt? Zugegeben, in der Artikelansicht sieht man ihn momentan sowieso nicht. --Hadibe (Diskussion) 22:58, 28. Sep. 2017 (CEST)
Letzter Kommentar: vor 6 Jahren6 Kommentare4 Personen sind an der Diskussion beteiligt
Warum meckert WSTM Unerwartetes Format: {{Schachbrett|| Beschreibung=? Ich sehe keinen wirklichen Fehler. Wurde etwas verändert? Ich habe schon lange keine Schachbretter mehr gehabt, aber ich erkenne nicht, was ich da tun sollte. Es gab doch früher mal so einen Parameter |Brett= oder irre ich mich jetzt komplett? Vielleicht hängt es damit zusammen. --Liebe Grüße, LómelindeDiskussion15:30, 22. Okt. 2017 (CEST)
Da ist irgendeine Schrägstrich-Notation zugange, die ich nicht verstehe; es müssten Pipes zwischen allen Figuren stehen; sind aber nur noch acht Parameter mit einem Satz von acht Feldern pro Reihe.
Hmm ja, so hatte ich das auch eher in Erinnerung. Ich wüsste nicht einmal was ich da fragen soll. Scheinbar funktioniert es mit beiden Versionen. Mich hat halt vorhin zufällig dieser Fehlertext erwischt und ich war verwundert was da los sein könnte. Wer das war siehst du doch etwa an der →Vorlage:Schachbrett/Konvertieren, es lässt sich sicherlich nichts mehr ändern und ich habe auch nicht vor da nachzufragen, ob das abgesprochen war oder diskutiert wurde. Ich wollte es dir nur mitteilen. Mich stört es nicht ich kann so etwas ignorieren. --Liebe Grüße, LómelindeDiskussion16:49, 22. Okt. 2017 (CEST)
Das wird die VWS nicht tun, bevor nicht die Schach-Redaktion darüber und über alle technischen Einzelheiten diskutiert und Konsens hergestellt hat.
A popo Schach-Redaktion: Wann und wo hatte eigentlich die Schach-Redaktion über die Format-Änderung von Januar 2017 diskutiert und Konsens hergestellt?
Und warum ist in den von der Schach-Redaktion betreuten und verantworteten Schachbrett-Vorlagen so hundsbeschissen dokumentiert, dass das ein Dutzend Jahre und in vielen Hundert Artikeln verwendete Schachbrett-Format verändert wurde? Warum wird nicht auffällig auf diee Änderung hingewiesen? Warum wird nicht das bisher in den Artikeln verwendete Format der Neuerung gegenübergestellt? Warum ist in den Doumentationen so schwammig-nebulös von einem „alt“ und „neu“ die Rede, statt präzise von „bis 2016“ und „ab 2017“ zu schreiben? Die einzige Jahreszahl, auf die sich ein „neu“ beziehen könnte, ist 2005. Kompatibilität mit anderen Wikis ist ja anscheinend nicht mehr erwünscht.
In einer Werkliste etwa ist das durchaus eine sinnvolle Direktangabe, und die Möglichkeit, sich das in irgendwelchen Nationalbibliotheken zusammenzusuchen, wäre unangemessen.
Den Quelltext würde es ohnehin nicht kürzer machen.
Moin Moin RonMeier, darf ich mal nach dem Warum fragen? Neugierde. PS.: Ich kopiere mir mal zwei/drei/vier Dinge aus deiner Commons.js. mfg --Crazy188016:47, 6. Nov. 2017 (CET)
Wenn ISBN/DNB/OCLC vorhanden ist, handelt es sich um eine redundante, sprich unnötige Angabe. Siehe auch Hinweis zu Umfang in der Vorlage Literatur. Gruß --RonMeier (Diskussion) 18:01, 6. Nov. 2017 (CET)
Grundsätzlich richtig, dass es redundant sei, aber schöner, meine Meinung, finde ich es, wenn ich auf einen Blick ersehen kann, ob es sich um einen dicken Wälzer handelt oder doch nur einen Flyer. Ich werde es also in den nächsten Angaben weglassen. mfg --Crazy188017:27, 8. Nov. 2017 (CET)
Wie könnte ich …
Letzter Kommentar: vor 6 Jahren5 Kommentare2 Personen sind an der Diskussion beteiligt
… automatisch Zitat immer an den Zeilenanfang setzen. Beispielsweise dort wo, es innerhalb von poem-Tags steht. Ich weiß, dass ich so etwas (poem mit Zitat geschachtelt) auch manchmal gemacht habe, weil Zitat nun mal alles ver-inline-t. Anders herum gehen aber immer die Anführungszeichen ins Nirgendwo.
Zitat ohne poem
„Das ist
[k]ein Gedicht“
Zitat außen um poem
„
Das ist
[k]ein Gedicht
“
Zitat innerhalb von poem
„Das ist
[k]ein Gedicht“
sollte aber besser so aussehen, falls überhaupt
<poem>
{{Zitat|Text=Das ist
[k]ein Gedicht}}
</poem>
Das war immer eine kleine Notlösung, um nicht hundert <br />s setzen zu müssen, zumal man mir davon abgeraten hatte <br /> in Artikel zu setzen. Ein Gedicht ist aber zumeist eben auch ein Zitat. Noch besser wäre vielleicht ein zusätzlicher Parameter, der es erlaubt ein Gedicht oder ähnliche Textblöcke zu zitieren, ohne dass es ein Bandwurmsatz wird. --Liebe Grüße, LómelindeDiskussion11:24, 8. Nov. 2017 (CET)
Es ist üblich:
In Hamburg lebten zwei Ameisen,
die wollten nach Australien reisen.
Bei Altona, auf der Chaussee,
da taten ihnen die Beine weh,
und da verzichteten sie weise
dann auf den letzten Teil der Reise.
Anführungszeichen um Gedichte finde ich doooof; Kursivschrift mit Einrückung reicht, um herauszustellen, dass das was anderes ist, und der umgebende Text oder die Abschnittsüberschrift sollten das klarmachen.
Einleitender Satz wäre nicht schlecht, um <ref> unterzubringen.
Es geht mir nicht unbedingt um ein Gedicht sondern um zitierte Blöcke. Zitate sollen doch möslichst so wiedergegeben werden, wie man sie antrifft. Ich habe mich etwas ungenau ausgedrückt, nur dann wenn Anführungszeichen erforderlich wären. Klar kann man die auch im Text selbst setzen. Ich weiß nur, dass ich mich jedes Mal verbiegen musste um so etwas darzustellen. Vor diesem Problem stehe ich seit November 2011. Ich habe bisher noch keine wirklich gute Lösung gefunden. Es geht ja nicht nur um mich, ich kann mir behelfen, aber nicht alle dieser Seiten sind von mir so formatiert worden. Egal, ich schau mir die paar mal eben an. Ich war eigentlich über etwas anderes gestolpert nämlich center-tags um Vorlage:Zitat. --Liebe Grüße, LómelindeDiskussion12:40, 8. Nov. 2017 (CET)
Ist schon o.k. du hast mir auch so geholfen. Was ich 2011 wollte war eine Vorlage die etwas als Block zitieren sollte und Anführungszeichen drum setzt. Ich weiß es nicht mehr genau wofür. Ich gehe die paar eben mal durch, meine eigenen kann ich anders lösen. Ich bin halt gerade darüber gefallen und da erinnerte ich mich, dass ich meinen Mentor einstmals fragte wie man etwas zitiert. Da war ich noch ganz neu hier, aber es blieb in meiner Erinnerung, dass ich damit Probleme hatte, wenn es nicht inline sein sollte. --Liebe Grüße, LómelindeDiskussion14:06, 8. Nov. 2017 (CET)
Ö oder Math, das ist die Frage
Letzter Kommentar: vor 6 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Ich wurde darauf angesprochen dass ich unbemerkt ein ⌀ (= arithmetisches Mittel) durch →ø (skandinavisches „ö“) ersetzen würde. Ist das von WSTM eingefügte Zeichen nun ein „ö“ oder ein mathematisches Formelzeichen? Falls es ein korrektes Formelzeichen darstellt, würdest du dann mal beim Nordlicht vorbeischauen, oder wenn es tatsächlich ein „ö“ ist bitte mal schauen, ob du das abfangen kannst. Ich wünsche noch einen schönen Feiertag. --Liebe Grüße, LómelindeDiskussion06:54, 26. Dez. 2017 (CET)
Das Zeichen 21610 wurde in den 1980er Jahren mit ANSI breit eingeführt und ist allen Computern bekannt.
Das Zeichen U+2300 (Durchmesser) kam in den 2000ern hinzu und ist lange nicht in allen bei unseren Lesern installierten Zeichensätzen definiert gewesen, zeigt also nur Kästchen.
Ob sich das mitttlerweile flächendeckend geändert hat, weiß ich nicht. Mein Rechner eins vorher hatte das standardmäßig auch nicht anzeigen können.
Weil es jahrzehntelang das einzig verfügbare Zeichen war, ist das weiterhin gängige Praxis, im Textbestand vorhanden und wird richtig verstanden und geduldet; deshalb ausdrücklich in Ø#Verwendung als Ersatzzeichen genannt.
Die Differenzierung nach Leere Menge und Durchmesser ist jüngeren Datums.
Es kann jedes HTML-Element nur eine id="" erhalten.
|- ist ein <tr> und kann 1× id="" bekommen, aber keinerlei zu <span> expandierende Anker.
Das |…| ist ein <td> und kann 1× id="" bekommen, aber keinerlei zu <span> expandierende Anker. Für das erste Feld müsste das ähnlich wirken wie bei |-.
In das allererste Textfeld kannst du beliebig viele weitere Anker schreiben, aber wenn das kein vertical-align:top hat, könnte es in die Mitte scrollen.
Einfach in den Schmerz reinatmen, und danach schon mal auf Vorrat herzlich lachen. Irgendwann wird es Frühling, irgendwann lacht die Sonne, und in meiner Glaskugel sehe ich viele babyrosa Streifen am Horizont.
Letzter Kommentar: vor 6 Jahren6 Kommentare2 Personen sind an der Diskussion beteiligt
Der Zeileneinzug für Vorlagenzeilen wird offenbar auch auf die schließenden geschweiften Klammern "}}" angewandt. Dies wird implizit von Vorlagendokumentationen regelmäßig anders empfohlen, zum Beispiel auf Vorlage:Literatur/Doku#Kopiervorlagen. Gibt es irgendwo style guidelines für whitespace in Vorlagen? Ich denke es wäre gut, diesen Zeileneinzug unberührt zu lassen oder eine Steuerungsmöglichkeit über mw.libs.WikiSyntaxTextMod.config.mod.template.format.style zu geben!? --Marsupium (Diskussion) 14:36, 14. Jan. 2018 (CET)
Das hier hätte ich gern unauffällig revertiert bekommen.
Das ist schon durchaus so gemeint gewesen.
Es ist ein Beispiel, das sich explizit auf eine vorlageBBKL und deren Parameter bezieht.
Wenn du eine andere Vorlage und andere Parameter vor Augen hast, musst du auch deiner Situation entsprechende reguläre Ausdrücke bilden.
Das von mir angegebene Beispiel standardisiert die Situation, dass jemand Autoren= oder Autorin= oder BBKL-Autor= angegeben hätte; das würde nach deinem Eingriff nicht mehr funktionieren.
Es gibt keine „guidelines für whitespace in Vorlagen“, sondern unterschiedliche Vorstellungen verschiedener an demselben Artikel beteiligter Autoren.
In der Situation „inline“ im Fließtext bei wenigen Parametern hat sich {{Vorlage |A=5 |B=7 |C=55}} bewährt, weil es guten Zeilenumbruch liefert und hier übersichtlich und platzsparend ist.
Außerhalb des Fließtextes und bei vielen Parametern ist „block“ optimal, wie es etwa Infoboxen machen, also jeder Parameter auf einer Zeile.
Quelltextformatierung wird zunehmend von VE und Skripten übernommen; dagegen manuell anzufechten ist gaga.
Wenn alles eingerückt wird, dann wird auch }} eingerückt, weil es dann um Tabellenzellen, Aufzählungslisten oder Verschachtelungen von Vorlagen in Vorlagen geht.
Ansonsten hänge einfach }} direkt an den letzten Parameter an.
Entschuldigung für mein Hineinpfuschen, ich habe es revertiert!
Ich verstehe, dass einfach alles eingerückt wird. Es ist ein wenig lästig, weil ich bei den meisten Fällen in einer Blockvorlage die Einrückung manuell wieder entferne, eben um nicht eine etwaige explizite Vorstellung des Autors, der ihn vor "}}" nicht gesetzt hat, zu missachten. Nun gut, es ist immer noch eine große Erleichterung. Bei dieser Gelegenheit tausend Dank für WSTM! --Marsupium (Diskussion) 20:58, 14. Jan. 2018 (CET)
Ist schon okay, danke.
Ich schrub oben „unauffällig revertiert“ – das meint, ein „Ach ne doch nicht“ im BK hätte es auch getan. Aber egal, diese VG liest eh keiner.
Es ist ja auch durchaus Absicht, wirre Abfolgen von Parametern und allzu viele Leerzeichen und Zeilenumbrüche wieder einzukassieren und zu vergleichmäßigen. Es kann halt nicht jeder in allen „seinen“ Artikeln einen individuellen Stil für Leerzeichen durchsetzen, und für die von ihm persönlich eingefügten Vorlageneinbindungen verlangen, dass alle Mitautoren dies nun auf ewige Zeiten zu respektieren hätten – zumal das in aller Regel überhaupt keine Absicht war, sondern nur irgendwie reinkopiert und ausgefüllt wurde, wie es gerade kam.
Skripte und VE wissen nicht, was für Leerzeichen-Ästhetik dahinter stecken soll. Sie haben einen Satz Parameterwerte und schreiben die Vorlageneinbindung damit neu an die gewünschte Stelle und in einem vorgegebenen Layout und in vorgegebener Reihenfolge. Mit zunehmendem Einsatz des VE wird sich Quelltextdesign ohnehin erledigen, weil weder jemand dem hinterherputzen kann noch viele in den Quelltext gucken müssen.
Der VE ist da offenbar doch bemüht, siehe den format-Wert von TemplateData. Soweit ich sehe, beherrscht das nicht das mw.libs.WikiSyntaxTextMod.config.mod.template.format.style.lineup und umgekehrt dieses Möglichkeiten von TemplateData nicht, u. a. die hier angesprochene. So kann man munteres Quelltextformatierungspingpong mit den beiden spielen durch Setzen von mw.libs.WikiSyntaxTextMod.config.mod.template.format.style.indent oder .lineup … Natürlich sind es nur marginale Unterschiede, nur wenn es um Bearbeitungen en masse geht, liegt es nahe, sich darüber Gedanken zu machen, auch um Vermeiden der Diff-Vermüllung willen … --Marsupium (Diskussion) 18:41, 21. Jan. 2018 (CET)
Das ist noch gar nichts gegen das, was menschiche Bearbeiter an Leerzeichenkosmetik so anstellen.
Das VE-Feature kenne ich sehr genau. Gleichwohl lässt sich mit WSTM noch flexibler arbeiten. So werden Zitationen im Fließtext kompakt, am Seitenende zelenweise aufbereitet.
Welche VE-Möglichkeit WSTM angeblich nicht beherrschen würde, wäre mir grad nicht geläufig.
Die verschiedenen Formatierungen in Kopiervorlagen, VE- und WSTM-Definitionen sollten einander angeglichen werden, sofern möglich. Trotzem gibt es Autoren, die das in „ihren“ Artikeln entweder mit zusätzlichen Leerzeichen und Zeilenumbrüchen extra garnieren, oder aber diese alle wieder herausnehmen. Gute Diff-Darstellungen stört das aber nur marginal.
Weil Vorlagen-Titel aus zwei Zeichen, deren zweites kein ASCII-Großbuchstabe A–Z ist, bei uns praktisch ausschließlich für die Sprachcodes nichtlateinisch verschrifteter Sprachen verwendet werden.
Diese Vorlagenbezeichnung hier ist maximal unverständlich und unentschlüsselbar und sollte langfristig geändert werden.
Für die Zwischenzeit habe ich das zur Kenntnis genommen.
Danke. Ich kann sowas lesen, Schnark und ggf. APPERR auch. Beim Rest weiß ich es nicht. Was immer da ausdiskutiert wird: Es muss hinterher zusätzlich in eine für Autoren taugliche Darstellung gebracht werden. Für Algorithmen sind BNF&Co. natürlich ideal.
Letzter Kommentar: vor 6 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
WSTM moniert das [[Datei:PyeongChang 2018 Winter Olympics.svg|rahmenlos|rand|rechts|hochkant=0.5]]
mit dem Kommentar
Widerspruch von Bildparametern
rand ./. frameless (Datei:PyeongChang 2018 Winter Olympics.svg)
An und für sich würde ich dem nicht widersprechen, rahmenlos und mit Rand hört sich widersprüchlich an (obwohl Rand = einfache Umrandung und Rahmen = gerahmt, doppelte Umrandung mit Bildlegende, etwas unterschiedliches meint). Aber genau so ist das ganze als Beispiel auf Hilfe:Bilder#rand vorgegeben.
rand und hochkant=0.5 (wirkungslos)
rahmenlos und hochkant=0.5
rahmenlos, rand und hochkant=0.5
Um das selbe Ergebnis nur mit rand zu erhalten müsste man von |hochkant=0.5 auf eine feste Pixelgröße, sagen wir 110px ausweichen
rand und 110px
rahmenlos 110px
rahmenlos rand 110px
Mir scheint da irgendwo der Wurm drin zu sein. Ich hatte gerätselt, wie ich das anders lösen sollte. Der eigentliche Fehler scheint mir aber nicht bei WSTM zu liegen sondern bei den Bildparametern. Würdest du das als Bug ansehen? Das ist absolut unwichtig, es ist für mich nur einfach unlogisch, nicht nachvollziehbar, rahmenlos setzt also vermutlich gerahmt = Originalgröße außer Kraft, um das Bild skalieren zu können benötigt es also rahmenlos oder für einen alleinigen Rand immer eine Pixelgrößenangabe, wenn es nicht Originalgröße haben soll. Manche Dinge hier sind einfach nur verwirrend. Ich wollte WSTM ja folgen, aber es war nicht so leicht wie gedacht, da ich den Rand behalten wollte. So genug für heute. --Liebe Grüße, LómelindeDiskussion19:45, 15. Feb. 2018 (CET)
Danke für den Hinweis.
Du hast völlig recht.
Bilder sind nicht so meins.
Tatsächlich wirkt es, und es wird class="thumbborder" generiert, was border: 1px solid #EAECF0; bewirkt.
Wovon ich aber nichts sehe, oder nur bei bestimmten Lichtverhältnissen nach Aufforderung.
Und diese Kombination rahmenlos+rand scheint mir immer noch wenig sinnvoll und selten.
Ja doch, für gerahmt steht das auch so auf H:B: „Durch den Parameter gerahmt bekommt das Bild einen Rahmen, wird auf jeden Fall in Originalgröße dargestellt (alle Skalierungen werden ignoriert) […]“ Was der Sinn davon ist erschließt sich mir zwar nicht, aber … ich muss nicht alles verstehen. Dankeschön. --Liebe Grüße, LómelindeDiskussion10:45, 16. Feb. 2018 (CET)
Danke, Lómelinde. Das kann leider nicht als Lösung gelten. 'unsicher:' (mit Doppelpunkt!) gehört nur vor Angaben, die eine über eine oder/zwischen/etc.-Angabe hinausgehende Unsicherheit aufweisen. In anderen Fällen, wie hier, ist 'unsicher:' falsch. Zudem werden die PD-Angaben bei jeder Änderung am Artikel verfälscht, bei der der Bearbeiter nicht extrem aufpasst. Wie hier z.B. bei der Bearbeitung durch Crazy1880 am 24.9.17. Es grüßt, --Griot (Diskussion) 11:25, 8. Jan. 2018 (CET)
Das ist mir schon klar, es sollte nichts verschwinden, es wird aber sicherlich einen Grund dafür geben, dass es sonst nicht als „korrekt formatiert“ erkannt wird. Zumindest wird es so verhindert. Man muss halt aufpassen. Ich habe es getestet und es verschwand wenn dort nicht unsicher steht. --Liebe Grüße, LómelindeDiskussion11:36, 8. Jan. 2018 (CET)
Gewiss. Aber füge bitte kein 'unsicher' ein, denn das ist inhaltlich falsch und wenn es erst einmal drin steht, ist die Wahrscheinlichkeit groß, dass es nie mehr verschwindet. Es grüßt, --Griot (Diskussion) 11:49, 8. Jan. 2018 (CET)
PD + WSTM: Die Programmierung ist von 2010; zumindest die letzten fünf Jahre nicht mehr verändert worden.
Ich hatte nur brav das gemacht, was die PDler sich gewünscht hatten.
Die Programmierung entsprach damaliger Doku und angegebener Beispiele.
Möglicherweise hat sich zwischenzeitlich daran was geändert?
Sobald ich das nächste Mal Zeit zum Denken habe, werde ich anhand der dann aktuellen Doku den Sachverhalt nachvollziehen und ändern, was zu ändern ist.
Heute habe ich keinerlei Quelltexte gelesen.
PD + Lua: Da haben wir noch was offen. Ich habe es nicht vergessen.
Ich habe mich drei oder vier Mal rangemacht, an Weihnachten, Ostern, Brückentagen, und jeweils zwölf Stunden drangesetzt, um mich einzuarbeiten und es nachzuvollziehen.
Lua ist dermaßen unübersichtlich programmiert, dass die Ruhezeit und Gelegenheit vorbei war, bevor ich mich reingraben und Konkretes draus machen konnte.
Ich habe allmählich die Knackpunkte gelernt, und wenn ich das nächste Mal Luft und Freiheit bekomme, werde ich detailliert die Problemee auflisten.
@Griot: Im Frühjahr 2016 gab es den Wunsch nach genauerer Analyse und Korrektur verschiedener adverbialer Aufzählungen, die durch „oder“ aufgereiht waren.
In diese mehrgliedrigen adverbialen Angaben fällt auch „zwischen“; wobei ich übersah, dass hier das Fügewort „und“ lautet und nicht „oder“.
Das habe ich nunmehr nachgebessert; und dafür gibt es jetzt eine Fehlermeldung, wenn auf das „zwischen“ nicht genau ein „und“ folgt.
Es geht baldmöglichst online, zunächst für intensive Testnutzer; allerdings mit einer größeren Zahl gleichzeitiger Veränderungen, weshalb die Auslieferung an alle Anwender noch etwas dauern wird.
Sagst du mir bitte wenn es online ist? Es gäbe da rund 2000 Testfälle, wobei das eigentlich nur passiert, wenn da ein Datum. zwischen TT. MM JJJJ und TT. MM. JJJJ steht, soweit ich das überblicke. Homer wäre unkritisch Thales ebenfalls während sich Elisabeth Volkmann oder Papst Clemens besser einen festen Tag ausgesucht hätten. Franz Kerber hätte auch bisher kein Problem gehabt. Sorry, ich wollte nicht drängeln, es sollte nur die Bitte um eine kleine Info sein. --Liebe Grüße, LómelindeDiskussion18:10, 11. Jan. 2018 (CET)
Deine Hinweise eben waren durchaus hilfreich.
Ein Update wird es frühestens am So abends geben, weil ich mit der geistigen Verdauung und dem Philosophieren noch nicht fertig bin.
Hier hatte Crazy das Problem wohl bemerkt, es dann aber versehentlich an GEBURTSDATUM manuell wieder angeflickt.
Ich habe noch nicht alle Situationen durchgespielt.
Eigentlich suchte ich nach Formaten wie 01. Mai 1837 oder 29. Okt. 1912 zur Korrektur, oder vielleicht mal einen 31. Februar. Neben Monatsnamen wäre aber auch Frühjahr 58 erlaubt, so dass ich die sonst gängigen strikteren Regeln nicht anwenden kann.
Ich könnte auch die richtige Reihenfolge von Einzeldaten prüfen, da ich v. Chr. als negative Jahreszahlen kenne und somit Herrn Thales im Prinzip auf sinnvolle Anordnung analysieren könnte.
Ich hatte schon vor Jahren in Betracht gezogen, Geburts- und Sterbezeit zu vergleichen; aber wegen möglicher ungenauer Zeiträume wäre das auf konkrete Monate oder Tage oder Jahre zu begrenzen, da Überlappungen auftreten könnten.
Funktioniert soweit ich es getestet habe. PD bleiben unverändert. Wobei der 30. bis unendlichste Februar noch immer ein valides Datum wäre. Die Umstellung von 0Ziffer. oder Mär. Okt. Dez. funktioniert nur wenn es auch ein Jahr (mindestens vierstellig nicht das Jahr 500 oder 27 N) dahinter gibt. zwischen 03. Februar 400 und 1. März 400 wäre Müll.
Auf meiner ToDo-Liste für den heutigen Sonntag stand „Bescheid“ für diesen Abschnitt hier.
Zu den Testfällen:
Janu versteht WSTM grundsätzlich nicht; nur volle Monatsnamen oder bekannte Abkürzungen Jan., allenfalls vielleicht mal englisch Oct oder 28.1.2018 oder ISO. Das weitere Raten bedarf der Menschen; WSTM kann da nichts automatisiert ändern.
Die Abfrage nach der Zahl der Tage im Monat ist zwar eingebaut, aber noch nicht mit einer Fehlermeldung verbunden. Zurzeit bemerkt WSTM zwar, dass das ein ungültiges Datum wäre, ignoriert das jedoch schweigend, da es nicht automatisiert korrigiert werden kann.
Ein 29. Feb. 2017 würde wohl nicht verändert werden, ein 29. Feb. 2016 müsste hingegen in 29. Februar 2016 geändert werden. Daran siehst du, dass WSTM sehr wohl von Schaltjahren weiß.
Hier geht es mir erstmal nur um automatische Korrektur des Formats gültiger Daten.
Es laufen ja auch andere Auswertungen und Bots, die fachkundige Menschen gezielt herbeirufen.
WSTM sind Jahreszahlen kleiner als 100 suspekt, weil auch gemeint sein könnte, dass John Lennon anno 70 erschossen wurde. Genauso ist v. Chr. nicht im Fokus.
zwischen 3. Januar 1323 v. Chr. und 1300 v. Chr. – das wäre für WSTM ein Reihenfolge-Fehler.
Es gäbe eine komplexe Logik, nach der sich aus den Zahlenwerten und der Position des v. Chr. bei einer Ellipse rückschließen ließe, welche Jahreszahlen v. Chr. oder n. Chr. gemeint wären.
Gleichwohl müsste dein Beispiel lauten: zwischen 1300 v. Chr. und 3. Januar 1323 v. Chr.
Der Frage v. Chr. in Verbindung mit zwischen werde ich jedoch noch einmal nachgehen. Der Schreibmodus fordert nur die drei numerischen Werte, muss aber immer unaufgefordert ein v. Chr. mitliefern. Die Technik stammt aus der Zitation gedrucker Bücher und Internetquellen.
Es nimmt immer das v. Chr. weg, wenn aus einem 03. Januar 1323 v. Chr. etwas umgeformt würde auch wenn da kein zwischen steht, als reines Datum aber eben nicht korrekt formatiert in der Ziffer oder beim Monat. Auch ein 3. Feb. 1323 n. Chr. würde seinen Glauben verlieren und zu einem 3. Februar 1323 ein klitzekleiner Unterschied. Das mit dem Reihenfolgefehler check ich nicht, liegt denn 1323 v. Chr. nicht zeitlich vor 1300 v. Chr.? Ich hätte es sorum geschrieben, man schreibt doch auch 1978 und 1988, also das was weiter zurückliegt zuerst. Na egal. --Liebe Grüße, LómelindeDiskussion18:22, 28. Jan. 2018 (CET)
Hallo Lómelinde, PerfektesChaos, Respekt für Eure Arbeit zu den Daten. Aber das Wichtigste scheint es mir zur Zeit nicht zu sein. Ich kontrolliere (und korrigiere) seit Jahren in gewissen Abständen (z.Zt. jährlich, mit dem Programm Benutzer:Griot/analyse-datum.py von 2010) diese Daten auf formale Korrektheit, incl. Überlappung von Zeiträumen. Im Dump vom 1. Januar waren 184 Angaben auffällig, darunter ein paar falsch positive. Statistik (nicht Artikel, sondern Einzelangaben werden gezählt; einige z.Zt. noch nicht zugelassene Formen werden akzeptiert):
Eine Gefahr, dass sich diese Fehler sukzessive anhäufen, besteht daher vorerst nicht. Wichtig ist vor allem, dass formal korrekte Angaben nicht beschädigt werden. (Viel wichtiger als die formale Korrektheit wäre natürlich, die Angaben mit dem Text zu vergleichen. Leider keine einfache Aufgabe.) Es grüßt, --Griot (Diskussion) 21:20, 28. Jan. 2018 (CET)
@Griot:
Ich sehe die Aufgabe von WSTM nur darin, triviale zweifelsfrei aufklärbare Formatierungsprobleme automatisiert durch den nächsten WSTM-Bearbeiter geradezubiegen, damit sie keinen Pflegeaufwand durch Fachpersonal nach sich ziehen. Das wären etwa:
08.09.2024
Jänner → Januar
29. Jan. 2018
n. Chr. ist redundant und störend.
Ich kenne zwar aus der Formatierungsglättung die Einzeldaten, kann sie auf logische Beziehungen überprüfen, will aber auf WSTM-Ebene nicht allzu tief in Details und kryptische Fehlermeldungen an alle WSTM-Bearbeiter einsteigen.
Die inhaltlichen Zusammenhänge sind für WSTM ohnehin nicht durchschaubar, und die Angaben sind mir viel zu schwammig und ungenau: ganzes Jahrhundert oder drei Termine zur Auswahl ./. ein konkretes Datum mit einem anderen einzelnen Tag vergleichen, und aus die Maus.
Was ein Komma oder Schrägstrich bedeuten soll und wodurch es zu ersetzen wäre, begreift WSTM nicht.
Der Einleitungsabschnitt ist auch nicht zwingend bekannt, erst recht nicht von WSTM zu analysieren und daraus Korrekturen abzuleiten.
v-Chr-Bug:
Ist eingekreist, Fix in lokaler Erprobung
Funktion stammt aus der Zitation nach Erfindung des Buchdrucks
{{Personendaten
|NAME=Ayrer, Jakob
|ALTERNATIVNAMEN=Ayrer, Jakob der Ältere
|KURZBESCHREIBUNG=deutscher Dramatiker und Autor von Fastnachtsspielen
|GEBURTSDATUM=März 1544
|GEBURTSORT=[[Nürnberg]]
|STERBEDATUM=24. März 1605
|STERBEORT=[[Nürnberg]]
}}
Hier ist ein oder Datum |STERBEDATUM=24. März 1605 oder 24. März 1625 verschwunden. Muss da auch ein zwischen hin, wäre für mich unlogisch. Weil hier ja scheinbar nur das Jahr nicht genau bekannt ist. --Liebe Grüße, LómelindeDiskussion15:41, 12. Feb. 2018 (CET)
Die Angabe sieht für mich aber korrekt aus siehe →oder. Oder übersehe ich hier etwas? Es betrifft dabei wieder nur Datumsangaben, die vierstellige Jahreszahlen aufweisen. Das selbe Beispiel aber mit dem Jahr 8-hundert/9-hundert bliebe unverändert. Ebenso wenn es dort nur Jahreszahlen und Monatsangabe gäbe, also ohne Tag, dann wird nichts entfernt
Ist aber verquickt mit vielen anderen Änderunngen, die noch in der Erprobung stecken.
Hängt in einem endlosen Rückstau von Sachen, die ich mal machen müsste, wenn ich richtig wach bin.
Jetzt bin ich müd.
OT: Auf BETA gibt es zwei neue Einstellungen, die VE/Quelltext zum Standard machen. Die müsstest du wieder ausknipsen. Wenn das ungefragt in der echten genauso läuft, wird die Community den Aufstand proben.
Im Prinzip ja, aber für dich wäre es arg kompliziert, weil ja auch die Parameter berücksichtigt werden müssen.
Du könntest dich besser warnen lassen, dass sie verwendet wird, und sie dann einfacher händisch eliminieren.
Im Moment möchte ich um diese Angelegenheit keine Dramen; irgendwann wird WSTM für alle die Vorlage mitsamt den richtigen Parameterwerten auflösen. Das eilt niht, und es gibt einen langen Rückstau wichtigerer Sachen.
OK, danke. Ich dachte da an was einfaches halbautomatisches wie bei Prettytable, aber wenn es zu aufwendig wird, ist es auch ok ( sind laut "insource:/Spaltenbreite/" ja nur noch etwas mehr als 3800 Verwendungen (mit prettytable nicht zu vergleichen). --Jmv (Diskussion) 21:23, 8. Mär. 2018 (CET)
Merkwürdige Zeichen
Letzter Kommentar: vor 6 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Ich schreibe es jetzt doch mal hier hin, da ich es sonst nie wieder finde. Vorhin hatte ich eine für mich merkwürdige Ersetzung.
2008: Ausstellung Carl Malchin. Ein Maler aus Mecklenburg auf Schloss Ludwigslust, Juli – September 2008.
wurde zu
2008: Ausstellung „Carl Malchin. Ein Maler aus Mecklenburg“ auf Schloss Ludwigslust, Juli – September 2008.
Im Quelltext kannst du sehen, dass dort merkwürdige Würfel stehen, ich sah diese jedoch nicht da WSTM sie schneller ersetzt hatte als sein Schatten. Ich wunderte mich zunächst über die Ersetzung, die der Diff anzeigte, aber noch mehr über die Anzeige in der Vorschau. Kann man solche Zeichen, ich meine jetzt den Ersatz also „ und “ irgendwie suchen? Falls jemand die Ersetzung nicht mitbekommen hätte, könnte ja so etwas sichtbar in Artikeln stehen und niemand, zumindest ich nicht, versteht was die bewirken sollen. Was sollte das eigentlich sein Anführungszeichen? Habe ich das schon mal gefragt? Ich hoffe nicht. --Liebe Grüße, LómelindeDiskussion15:57, 26. Mär. 2018 (CEST)
Aha, lies das Handbuch Kleines. Dankeschön, das hätte ich so nie gefunden. In dem Fall habe ich sie einfach nur entfernt weil es sonst auch nirgendwo Zeichen gab. --Liebe Grüße, LómelindeDiskussion18:11, 26. Mär. 2018 (CEST)
Fehlermeldung anklickbar machen
Letzter Kommentar: vor 6 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo PerfektesChaos, wenn dieser Wunsch schon mal aufkam, sorry, hab mir das Archiv nicht durchgelesen.
Ich fänd's schön, wenn man in der roten Fehlermeldung oben auf der Seite die einzelnen Punkte anklicken könnte und es dann zu der entsprechenden Stelle im Quelltest springen würde. Wäre sowas technisch machbar? Grüße, -- Jonaes/Diskussion17:01, 16. Apr. 2018 (CEST)
Nein, der Quelltext ist für WSTM ein einzelnes großes Element in HTML, in dem es keine Sprungziele gibt, wohin gesprungen werden könnte.
Theoretisch könnte WSTM wissen (weiß es aber de facto nicht), am wievielten Zeichen in der wievielten Zeile die beanstandete Stelle gefunden wurde. Theoretisch könnte man sich daraus was zusammenreimen.
Das hilft aber auch nicht, denn WSTM verändert im weiteren Verlauf ja den Quelltext, und die Position, wo das mal gestanden hatte, kann zum Schluss nach vorn oder hinten verschoben worden sein, und dann würde eine Fokussierung auch nichts helfen.
Im übrigen gibt es auch Mehrfachfehler gleicher Meldung, die nur nach Anzahl gemeldet werden.
Noch was (ich schreibs einfach mal hier mit rein): Der Parameter {{Internetquelle|archiv-bot=}} wird bei IAB-Einträgen immer als fehlerhaft erkannt. -- Jonaes/Diskussion19:00, 17. Apr. 2018 (CEST)
Ja, danke, ist bekannt; die Programmierung weiß bereits von dem neuen Parameter, aber diese ist noch nicht hinreichend getestet und nicht online für alle. LG --PerfektesChaos12:31, 18. Apr. 2018 (CEST)
Diverses April 2018
Letzter Kommentar: vor 6 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Moin Moin PerfektesChaos, mir gehen irgendwie die kreativen Überschriften aus, deswegen so. Ich hätte da "Divereses":
schau mal bitte bei Spezial:Diff/176527372 in den Quelltext, da steht in einer Vorlage Literatur |Format=Google-Books , kann/sollte man soetwas als falsches Format anzählen lassen?
gerne noch mal der Wunsch, den Parameter |KBytes= zu schärfen im Sinne von nur Ziffern
Deinem Wirken bei dem IQ-Datum, dessen Bereinigung zu einem Großteil auf dich zurückgeht, sehe ich seit Monaten interessiert zu.
Die genannten Vorlagen habe ich mir angeguckt.
Eine ist eine reine Testprogrammierung für die mittlerweile aktive, da könntest du auf der Diskussionsseite auf das Problem aufmerksam machen und {{{zugriff|}}} mit einer Pipe hintendran anregen; das sollte das Problem eigentlich lösen.
Die anderen beiden kenne ich, sind teilweise Kandidat für eine Komplettsanierung aus unterschiedlichen Gründen, und aus noch unterschiedlicheren Gründen möchte ich da nicht ran.
Man sollte sich daran gewöhnen, alles was nicht ANR ist einfach zu übersehen.
Vielleicht kommt ja mal jemand, der nicht Lómelinde ist, da beiläufig drüber und säubert einige Nicht-ANR. Haben wir nix am tun mit.
Eine Möglichkeit wäre, die Analyse/Kat nur im ANR auszulösen. Das hatte ich auch routinemäßig so gemacht, aber neulich fiel so ein Schelm über 60 Vorlagen her und löschte alle meine dortigen Namensraum-Einschränkungen.
An die Internetquelle möchte ich in den nächsten Monaten ohnehin nicht mehr ran. Zu viel wirres Zeug geht da ab. Insofern entfällt auch die Variante, die Fehlermeldung immer überall zu zeigen, aber das gibt Ärger im ANR und die sonstigen betroffenen Seiten sieht sich niemand an.
Schärferes |Format=Google-Books und |KBytes= möchte ich nicht anfassen, sondern etwas Ruhe einkehren lassen. Das gibt immer Dramen, und ich werde auf Monate gebunden.
Erstmal müssen sich die Autoren ein paar Jahre an die Umstellung von 2016 gewöhnt haben. Nachdem die Internetquelle auch ein rein numerisches |kbytes= eingeführt haben wird, könnte das für alle wirksam werden, weil auch beide ein und dieselbe Programmierung benutzen, und für das Vokabular von |format= gilt das Gleiche.
ja, schaue ich mir an, und werde mal die Diskussionsseiten bemühen
mit dem nicht ANR ist schon eine Idee wert, gerade weil ich auch einige Benutzer angesprochen hatte und doch auch der Wunsch vorhanden war, die Entwürfe momentan nicht zu verändern. Vllt. sollte man das nochmal aufrollen.
zu dem Punkt "keine Aufgaben" mehr sei gesagt:
prettytable > wikitable
LintErrors
verschiede CSS-Fehler
eigene Abfragen zu "Unzulänglichkeiten" innerhalb der Vorlage Literatur
ISBN-fixe
und es stehen noch mal neue Artikel an
Vorbereitung einer Präsentation über Wikipedia/Wikidata etc.
Ich glaube somit, langweilig solte es nicht werden ;)
Die Seite mit den Vorlagenweiterleitungen schaue ich mir noch mal an
Aber: Leider kennt class="NavHead" da keine Verwanten und unterdrückt den Farbwunsch mal eben. Klar es war vorher auch Murks, weil so class="NavHead" nicht aktiv war und man da dann die Überschrift von Hand gefettet hatte, nur wenn ich es nicht behoben hätte hätt ich mir wohl Ärger eingehandelt.
Hast du eine Idee wie man diese Klassen so verschmelzen könnte, dass auch die Farbe erkannt würde? Hier wie es im Artikel stand →Spezial:PermaLink/176728185
Regimentsstruktur der sächsischen Armee vom 20. Juni 1717
Das was WSTM daraus gemacht hat doppelt fett und ohne Farbe
Regimentsstruktur der sächsischen Armee vom 20. Juni 1717
Und mein Versuch es auszubügeln damit ich keine blauen Bohnen einfange und der nächste nicht in diesen Hinterhalt gerät.
Regimentsstruktur der sächsischen Armee vom 20. Juni 1717
Es ist vom Browser abhängig, ob er beide Klassen berücksichtigen möchte oder nur die letztgenannte; der Standard empfiehlt die letztere Variante und alle vorherigen Definitionen als fehlerhaft zu ignorieren.
WSTM geht davon aus, dass die Autoren alle Klassen wirksam haben wollten.
Ja ne is klar, nur ist es in diesem Falle halt so, dass es eben nicht wirksam wird. NavHead „will“ klassenmäßig wohl nur so aussehen, wie es ihm mal vorgegeben wurde. Grauer Hintergrund und fette Schrift, andere Klassen sieht es nicht, nein falsch, es legt sich vermutlich darüber. Ich kenne nicht so viele Klassen, als dass ich da viel testen konnte. Ich vermute aber das war wirklich die Stecknadel im Heuhaufen.
OT: Schade, dass das mit den Bildchen nicht 100 %ig geht, gerade sind sie mal alle anwesend bei der nächsten Vorschau dann wieder nur ein Teil, na egal, ich habe mich auch schon an die dicken Schaltflächen gewöhnen müssen, es ist wie es ist, man muss sich arrangieren. Aber trotzdem ein dickes Dankeschön, dass du das für mich gebastelt hast. --Liebe Grüße, LómelindeDiskussion11:00, 25. Apr. 2018 (CEST)
Hilfe
Letzter Kommentar: vor 6 Jahren6 Kommentare3 Personen sind an der Diskussion beteiligt
Erstmal danke, aber je nachdem wo ichs hintue, läufts trotzdem automatisch, oder es kommt ein Knopf, der macht aber nichts. Kannst du mal in meine meta:User:Jonaes02/global.js schauen und mir sagen wo ich das hinpacken muss? (Ja, gerade hab ich es auskommentiert) -- Jonaes/Diskussion10:16, 13. Mai 2018 (CEST)
@Jonaes02:, da könnte noch die Deklarierung fehlen. Kannst du den Abschnitt mal bitte in deine lokale commons.js packen und schauen? Ansonsten mit einer Funktionsdeklarierung kannst du mal bei Benutzerin:Lómelinde/common.js schauen, ob dir das weiterhilft. mfg --Crazy188010:53, 13. Mai 2018 (CEST)
Meine wird nicht helfen, denn ich habe es auf Automatik stehen, also sobald ich einen Artikel öffne läuft WSTM einmal drüber, erst im Anschluss lässt es sich dann nochmals manuell starten, beispielsweise wenn man etwas verändert hat, um das nochmals checken zu lassen. Bitte nicht meine WSTM-Einbindungssequenz kopieren, da ich eine Testversion verwende, die anders reagieren kann, als die gültige WSTM-Version. --Liebe Grüße, LómelindeDiskussion20:15, 13. Mai 2018 (CEST)
Ich hab keine Ahnung wie, wo, was, aber so wie ichs jetzt habe funktioniert es (und wahrscheinlich stirbt jedes mal, wenn ich eine Seite aufrufe, ein Hamster) Danke für die Hilfe. -- Jonaes/Diskussion20:30, 13. Mai 2018 (CEST)
Unerlaubtes Tag
Letzter Kommentar: vor 6 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Sorry nochmal ich, wo wir gerade bei unerlaubter Syntax waren, rufst du bitte mal diese Seite auf SAS Scandinavian Airlines. Ich denke es ist nicht so toll, dass dort diese Tagöffner in < geändert werden. Ja, es steht dick und fett in der roten Kiste drin, dass etwas nicht i.O. ist und vermutlich ist es Absicht, dass so etwas
dann sichtbar in der Seite steht, … oder anders, wenn das durch WSTM ersetzt wurde, und jemand es dann nicht aus dem Quelltext löscht, fällt es dem nächsten nicht mehr auf die Füße, wäre es da nicht sinnvoller es nur anzumeckern und nicht automatisch umzuschreiben? --Liebe Grüße, LómelindeDiskussion17:22, 15. Mai 2018 (CEST)
Hier hatte jemand ein durchgeknalltes Skript verwendet, einen Sortierschlüssel und eine Kategorisierung rausgeworfen (das Skript heißt vermutlich VE).
Wenn ich sowas nicht deutlich sichtbar mache, bleibt das einfach unsichtbar drin und die Info geht verloren. Passt scho.
Letzter Kommentar: vor 6 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Moin Moin PerfektesChaos, ich wurde gerade darauf aufmerksam gemacht, dass die Reihenfolge von WSTM umsortiert worden ist, in eine Reihenfolge, wie sie nicht laut Dokuseite sein soll. Ist nichts wichtiges, erstmal die 30°C überleben. mfg --Crazy188013:47, 22. Jul. 2018 (CEST)
Na ja meine Hoffnung, dass irgendwann die knapp 16000 Restfälle mal eliminiert worden sein könnten, gebe ich noch nicht auf. Aber es gibt Benutzer, die absichtlich diese Tabellenzellensyntax abrücken, so etwas habe ich beispielsweise im Bahnbereich des Öfteren gesehen, das stört mich (weil Schnarks Syntaxhighlighter es nicht dunkelgelb markiert) und scheinbar stört es auch den Ablauf von WSTM. Könntest du das mit berücksichtigen, falls das nicht zu viel Aufwand wäre? Ich komme aber auch so klar, wollte es nur anmerken, weil ich mich wunderte. Ich weiß auch nicht ob das überhaupt so oft vorkommt, dass sich eine Anpassung lohnen würde. --Liebe Grüße, LómelindeDiskussion14:05, 5. Aug. 2018 (CEST)
Für WSTM ist das Vorhandensein ab Spalte 1 existentiell für die Erkennung, weil es auch ein Codeblock sein kann:
Diese Einrückerei war mal eine Marotte der Kindergartenzeit, hatte den Erfolg einer größeren Übersichtlichkeit nicht gebracht und nur zu viel mühsamer Extra-Tipperei geführt.
Es ist weitgehend aus dem ANR eliminert.
Einige Einzeltäter mögen das weiterhin pflegen, oder Fachgebiete. Kann ich nicht zweifelsfrei erkennen, somit auch nicht korrigieren.
PS.: Vllt. kannst du bei den Eishockey-Leuten ein gutes Wort einlegen, dass sie ihre Artikel umwandeln. mfg --Crazy188018:53, 5. Aug. 2018 (CEST)
Ne ich mag nicht mehr fragen, meistens interessiert das eh niemanden, ich habe schon so manches Mal irgendwo um Mithilfe gebeten, es kam meist nur Unverständnis ala „wieso funktioniert doch“ oder „wen stört’s“? Ich weiß, dass du da dran bist. Und wo sie mir unterkommen, da ändere ich es ja auch gleich. Ich wünsche euch einen erfrischenden, ruhigen, angenehmen Abend. --Liebe Grüße, LómelindeDiskussion19:02, 5. Aug. 2018 (CEST)
@Crazy1880:
Mach erstmal alles außer Sport, und dann kann man ganz zum Schluss, nachdem alles außer Eishockey, Fußball, Handball oder was dann noch übrig wäre ausnahmsweise Bot-Läufe mit den Redaktionen und Portalen absprechen.
Wichtig ist erstmal, dass da nicht viel neue wieder in das Projekt eingeschleppt werden, aber außer Wintersport und einigen sehr verkalkten 2005ern schreibt das niemand mehr, und ausnahmsweise ein Bot für Syntaxkosmetik in bestimmten Portalen wird sich schon machen lassen. Erfreulicherweise ist es aber bei den allermeisten langjährigen Autoren angekommen oder die jüngeren wissen überhaupt nichts mehr davon.
Dann sollte man grundsätzlich mal früher als später anfragen, du kennst ja mittlerweile meine Einstellungen, "einfach mal wegarbeiten und den Weg für Neues bereiten".
Letzter Kommentar: vor 6 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo PerfektesChaos/js/WikiSyntaxTextMod/Archiv5, ich würde gerne das Skript WikiSyntaxTextMod automatisch nach Bearbeitungen laufen lassen, wenn ich eine Ersetzung mit Bandersnatch von Schnark durchgeführt habe; dafür gibt es einen Lade-Button, ich verstehe nur leider nicht, wie ich die beiden Codes (meine replace-Ersetzung und die Ersetzung über WSTM) kombinieren kann… Kannst du mir da helfen? Danke! Raspi Fly (Diskussion) 11:17, 3. Sep. 2018 (CEST)
Ich verstehe jetzt nicht so restlos, was du möchtest, kenne mich aber auch mit bandersnatch nicht aus.
Grundsätzlich ist so ein automatischer Start jedoch möglich; musst du aber ein wenig programmieren. Aber wenn du bandersnatch kannst, dann wirst du das auch hinbekommen.
Dort gibt es unter #Stapelverarbeitung eine Beschreibung, die wohl auch auf deinen Fall passt.
Du müsstest einmalig das Kopfmodul laden, dann den Rest dazu. Dann wäre WSTM für dich als Bibliothek einsatzbereit. Die Spezial:bandersnatch weiß danach, wer und was WSTM ist. In den Browsern gibt es auch die Möglichkeit, JS-Code in einer Seite auszuführen; das könntest du manuell von außen losjagen, und weißt dann, dass es getan ist. Da brauchst du dann kein Callback mehr.
Danach kannst du für jeden Artikel in der Serie die bandersnatch-Prozedur ablaufen lassen.
Es könnte pfiffig sein, WSTM zuallererst über den nackten Artikel laufen zu lassen. Dabei werden eine Reihe von Standardisierungen vorgenommen, und du musst bei deinen sonstigen geplanten Aktivitäten nicht alle Varianten der Syntax berücksichtigen.
Du wirst ja vermutlich etwas ersetzen wollen. Das kannst du meist auch schon im selben Arbeitsgang robust von WSTM erledigen lassen; siehe Benutzer:PerfektesChaos/js/WikiSyntaxTextMod/usage/replace. Im Unterschied zu den normalen Ersetzungen lässt das Kommentare, nowiki, Bildeinbindungen ggf. in Ruhe und ersetzt nur in Situationen, in denen das wirklich beabsichtigt wäre.
Punkt 5 der Stapelverarbeitung musst du irgendwie aus bandersnatch herauslesen. Vielleicht geht eine Textfläche auf der Spezialseite, oder bandersnatch stellt dir ein fertiges Objekt mit sowas bereit. Würde ich bei Schnark dringend vermuten.
Dann rufst du von WSTM die .api.textMod() auf.
Diese Funktion gibt dir auch den geänderten Wikitext zurück, falls sich etwas getan hatte.
Diesen ggf. geänderten Wikitext musst du dann wohl wieder an bandersnatch zurücktransferieren. Wie das ginge, weiß ich auch nicht.
Wenn ich aber so den bandersnatch-Code durchscrolle, dann steht da was von mw.libs.doWSTM und außerdem der vollständige Code, der erforderlich wäre, um eine über Benutzer:PerfektesChaos/js/WikiSyntaxTextMod/usage/replace konfigurierte Veränderung komplett umzusetzen. Wenn du also auf irgendeinen Knopf drückst, dann kann bandersnatch das mit dem WSTM alles schon von selbst. Mehr weiß ich nicht. Das Interface sieht jedenfalls danach aus, als ob es so einen Knopf geben würde.
Letzter Kommentar: vor 6 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
WSTM entfernt beim Start aus der Vorlage Wikisource den Parameter lang= und meckert mich dann an, dass diese defekt sei oder der Parameter dort nicht hingehört.
{{Wikisource|Author:Thomas D'Urfey|Thomas d’Urfey|Autoreneintrag|lang=en}} Ok eigentlich, denn da sollte es hin.
Schwesterprojekt-Vorlage defekt
Wikisource ... lang=en
{{Wikisource|Author:Thomas D'Urfey|Thomas d’Urfey|Autoreneintrag}} N Diese Seite existiert nicht, das aber würde WSTM akzeptieren
Tatsächlich ist sie aber nach diesem Eingriff dann auch defekt. Warum tut es das? Vorlage:Wikisource#Kopiervorlage sagt verwende lang=. Genau das habe ich ja auch getan.
OT: Und wo ich gerade am „rummaulen“ bin, wann bekomme ich denn die Citoid-Schaltfläche zurück? Es ist sehr umständlich ohne. --Liebe Grüße, LómelindeDiskussion08:27, 4. Sep. 2018 (CEST)
Ja, das ist ein sehr selten auftretendes Problem, weil die handgestrickte Programmierung von 2012 von vier Parametern gleichzeitig überfordert ist. Eine Neuprogrammierung mit heutigen Mitteln ist wegen Arbeitsrückstau von mehr als 20 Monaten nicht in Aussicht.
Ich sehe den Citoid-Button auch in dem von dir verwendeten 2010-WikiEditor wieder, nachdem es tatsächlich kürzlich mal einen von mir nicht verursachten Ruckler gab; probier mal die Werkzeugleiste von 2006 aus. Mehr kann ich da nicht machen; ich habe mit diesen Werkzeugleisten nichts zu tun.
Letzter Kommentar: vor 5 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt
Hallo, im Moment versuche ich mich an ein paar Regex, zur whitespace-Regulierung um Überschiften auf Commons-Dateibeschreibungsseiten. mw.libs.WikiSyntaxTextMod.config.page.include = [ "File:" ]; ist gesetzt. Das einfachste Beispiel, dass schon nicht funktioniert, ist das Einfügen von Leerzeichen zwischen "=" und Überschrift. Übersehe ich einen Fehler im Folgenden?
Nunja, das wird als Template-Code ausgeschlossen (war tatsächlich nicht immer so). Davon abgesehen, wer sagt dass das jetzt die gewünschte Notation ist (außer Leyo)? Bei einer Template-Einfügung erübrigt sich die eigtl. Intention der Abgrenzung vom Text vollends (hier mit 8 Zeichen, sollte wohl genügen). In fast allen Scripten (auch von WM) die ich kenne werden dort keine Leerzeichen gesetzt, welches auch erst durch einen Hack in den Edittools möglich wurde (vorher immer revertiert).
Was mich viel mehr stört (der seit Jahren bekannte Bug), dass WSTM immer noch korrekte Interwiki-Links in falsche Links ändert [[:en:Wikipedia:Text]] (oder auch nur :Wikipedia:Text) → [[w:en:Text]] -- User: Perhelion11:37, 11. Sep. 2018 (CEST)
Ist nicht völlig narrensicher, wird aber wohl gut laufen.
Ich schiebe seit Jahren einen Berg von Programmieraufgaben vor mir her, und um tiefer in WSTM einzugreifen und irgendwas von 2012 neu zu programmieren würde mich mehrere freie Monate der Wiedereinarbeitung und Erprobung kosten, die ich schlicht nicht habe und statt dessen alltäglichen Kleinkrieg hier mache, und nichts beginne, was ich nicht in einem Dutzend Stunden zu einem robusten Ende bringen kann.
Letzter Kommentar: vor 5 Jahren9 Kommentare2 Personen sind an der Diskussion beteiligt
Soweit ich weiß ist das bei mir nicht aktiv. Trotzdem wundere ich mich gerade, dass ich keine Diffanzeige bekomme, wenn Dinge wie Herausgeber→Hrsg oder Band→ReiheBand beim Öffnen der Seite ersetzt werden. Ist mir das nur bisher nie aufgefallen oder hat sich da etwas geändert? Ich mag es nicht wirklich, wenn Änderungen an mir vorbei erfolgen. Beispiel Am Neuen Wasserturm 1 (Mönchengladbach). So etwas verunsichert mich. Also das ist nicht generell so, nur bei Seiten der Temp4 meine ich, aber ich denke dass etwas verändert wurde, da ich mich nicht erinnern kann, so etwas schon einmal bemerkt zu haben. --Liebe Grüße, LómelindeDiskussion12:08, 16. Sep. 2018 (CEST)
Das ist seit Sommer 2016 so.
Änderungen an den Lit-Parameternamen werden als geringfügig=whitespace-ähnlich klassifiziert. Da in 150.000 Artikeln Änderungen Herausgeber→Hrsg Jahr→Datum Zugriff→Abruf auf der Agenda standen und die Anwender von den teilweise dutzendfach im Artikel vorkommenden Ersetzungen nicht genervt werden sollen, wird erst bei Änderung des Parameterwertes Diff ausgelöst. Wegfall überflüssiger leerer Parameter übrigens genauso, und Internetquelle ebenfalls, nur dass da nicht so viel mit den Namen passiert.
Ne ich weiß nicht irgendetwas ist einfach anders, auch wenn ich auf meine Schaltfläche klicke kam sonst „immer“ automatisch so ein Diff. Irgendetwas ist heute anders. Ich weiß nicht was aber es verhält sich merkwürdig. Das bin ich so nicht gewohnt. Bist du sicher, dass sich nichts geändert hat? --Liebe Grüße, LómelindeDiskussion14:56, 16. Sep. 2018 (CEST)
Hmmmh, geändert hat sich schon gestern Abend etwas, aber dahingehend dass WSTM etwas schneller wurde.
Mal beobachten; dazu ist die d-Version ja da.
Ich hatte das auch ausprobiert; bei mir kam Diff wie zu erwarten wenn zu erwarten. Ich achte mal drauf.
Diff müsste jedenfalls kommen, wenn größere Änderungen.
OT: Die Klasse BoxenVerschmelzen haben wir bereits seit 2004 in dieser Form; scheint also irgendwie wichtig zu sein.
Umstellungen innerhalb der Vorlage Literatur, auch Formatumstellungen lösen kein Diff mehr aus, es sei denn, ich füge einen fehlerhaften Parameter ein, also statt Sammelwerk nur werk oder so, dann kommt ein Diff, weil das eben grundfalsch ist und WSTM das wohl aussortiert. Andere Umstellungen, Positionswechsel, Parameternamenskorrektur, gehen ohne Diff durch.
Benutzerspezifisches [http://irgendetwas.web] → [http://irgendetwas.web irgendetwas.web] im Parameter |Online= oder sonstwo löst hingegen einen Diff aus.
Ich teste mal kurz |Jahr=JJJJ|Monat=MM|Tag=TT (ohne Datum) wird ohne Diff zu |Datum=JJJJ-MM-TT das bestätigt mein Empfinden. ABER: Dumm ist, dass
* {{Literatur |Autor=Mark Swed |Titel=Max Reger a crowd pleaser at a full and festive Disney Hall |Sammelwerk=[[Los Angeles Times]] |Datum=2014-11-30 |Jahr=2014 |Monat=11 |Tag=30 |Online=[http://www.latimes.com/entertainment/la-et-cm-la-phil-dudamel-review-20141201-column.html latimes.com]}}
ohne Korrektur der Parameter und ohne Diff zu
* {{Literatur
|Autor=Mark Swed
|Titel=Max Reger a crowd pleaser at a full and festive Disney Hall
|Sammelwerk=[[Los Angeles Times]]
|Datum=2014-11-30
|Jahr=2014
|Monat=11
|Tag=30
|Online=[http://www.latimes.com/entertainment/la-et-cm-la-phil-dudamel-review-20141201-column.html latimes.com]}}
wird. Das ist nicht gut, denke ich und so sicherlich auch nicht geplant, oder? Es ist also etwas überraschend, was da passiert. --Liebe Grüße, LómelindeDiskussion16:52, 16. Sep. 2018 (CEST)
Du hast aber schon gesehen, dass Jahr Monat und Tag einfach nur mit umgetsellt und nicht mehr entfernt werden? Und ich bin mir sicher, dass das vorher, auch bei kleinen Änderungen immer einen Diff ausgelöst hatte. Auch wenn ich für gewöhnlich eh noch mal den Vergleich aufrufe, mir ist es lieber ich sehe alle Änderungen auch die minimalsten und sei es nur ein Leerzeichen hinter |- Na es ist dein Tool du wirst schon wissen, was es tun soll und was nicht. Ich habe gern im Blick was da passiert, denn verantwortlich bin ich, wenn ich es speichere. --Liebe Grüße, LómelindeDiskussion17:29, 16. Sep. 2018 (CEST)
Zitatumwandlung
Letzter Kommentar: vor 5 Jahren16 Kommentare5 Personen sind an der Diskussion beteiligt
Das ist eine nette Idee, aber … Nach meiner Meinung sollte bevorzugt der Parameter |Quelle= eingesetzt werden und nicht der Parameter |Autor=
O.k. WSTM kann es nicht wissen, doch halte ich es für besser Dinge wie Filmlexikon nicht als Autor sondern als Quelle zu bezeichnen, leider sind einige Mitautoren daran gewöhnt unbenannte Parameter zu verwenden und dadurch seht dann seit Jahren so etwas in Artikeln.
{{Zitat|Geschäftlich geht Fler also …<ref>Rappers.in: [http://www.rap.de/reviews/87-review/8386]</ref>|Auszug aus der Rezension von Rap.de}}
Das sieht, für mich, aufgrund der Kapitälchen immer sehr unschön aus zumal es explizit in der Vorlagendokumentation heißt
Autor = Autoren (Vorname Nachname, Vorname Nachname …)
Quelle = Angaben zur Quelle, in der das Zitat zu finden ist
Obiges wäre für mich also die Quellangabe hier = Auszug aus der Rezension von Rap.de
Nun wandelt aber WSTM diese in einen Autor, so etwas möchte ich nicht wirklich. Denn dadurch wird, meiner bescheidenen Meinung nach, die falsche Formatierung als gewünschtes Format übernommen. Ich bemühe mich eigentlich schon immer darauf zu achten so etwas wie
{{Zitat|Schlöndorffs brillant inszenierte, weitgehend werktreue Verfilmung des Romans von Günter Grass. Eine opulente Bestseller-Verfilmung voller sinnlicher Kraft.|[[Lexikon des internationalen Films]]<ref>{{LdiF|26375|zugriff=2017-03-02}}</ref>}}
WSTM macht daraus
{{Zitat
|Text=Schlöndorffs brillant inszenierte, weitgehend werktreue Verfilmung des Romans von Günter Grass. Eine opulente Bestseller-Verfilmung voller sinnlicher Kraft.
|Autor=[[Lexikon des internationalen Films]]<ref>{{LdiF|26375|zugriff=2017-03-02}}</ref>}}
zu korrigieren
{{Zitat
|Text=Schlöndorffs brillant inszenierte, weitgehend werktreue Verfilmung des Romans von Günter Grass. Eine opulente Bestseller-Verfilmung voller sinnlicher Kraft.
|Quelle=[[Lexikon des internationalen Films]]
|ref=<ref>{{LdiF|26375|zugriff=2017-03-02}}</ref>}}
denn ein Lexikon ist nicht der Autor sondern die Quelle.
So hilfreich diese Ersetzung auch ist, wenn ich es nicht zufällig bemerkt hätte, dann hätte ich das im Vertrauen auf dein Tool, so übernommen. Spezial:Diff/182019175
Ich weiß nicht, wie man das sinnvoll automatisch ersetzen könnte.
Derzeit jedenfalls wäre es mir lieber, wenn es nur den Parameter |Text= setzen würde, aber natürlich sehe ich auch das Problem, wenn man dann die anderen Parameter unbenannt lässt kommt Murks heraus …
{{Zitat
|Text=Geschäftlich geht Fler also …<ref>Rappers.in: [http://www.rap.de/reviews/87-review/8386]</ref>|Auszug aus der Rezension von Rap.de}}
Daher wäre es mein Vorschlag, |Text= und |Quelle= zu verwenden, und, wenn nicht vorhanden, zusätzlich die Parameter |Autor= und |ref= leer mit einzufügen, damit man die Zuordnung anpassen kann, mir wäre es lieber ein Autor steht mal als Quelle da, als umgekehrt.
Ne das reicht mir nicht, WSTM setzt da einen benannten Parameter ein und das sollte zuvor „menschlich“ geprüft werden. Ich weiß sehr wohl, dass da nur eine Umschreibung erfolgt, aber die stört mich. Denn, wenn ich etwas „bewusst“ anpasse dann tue ich das in der Absicht etwas „geprüft“ umzustellen, wenn dein Tool mir aber eine Umstellung auf benannte Parameter unterschiebt und mir möglicherweise nicht einmal mehr einen automatischen Diff dazu liefert, dann stört mich das doch sehr. Ich möchte ungern auf WSTM verzichten. --Liebe Grüße, LómelindeDiskussion10:50, 22. Okt. 2018 (CEST)
Bitte nicht mit Drohungen und Erpressungen kommen.
Wir stellen ganz allgemein und allmählich die unbenannten Parameter der ersten Jahre auf benannte um, damit die tatsächliche Funktion deutlich wird. Gerade du forderst das immer wieder.
Nichts anderes geschieht hier, und Bearbeiter, die bislang nur irgendwie eine Herkunft als ersten Parameter nach der Pipe ohne Nachdenken reingeklatscht hatten, sehen jetzt erstmals die wirkliche Bedeutung.
Nachdem das nunmehr von WSTM verdeutlicht wird, steht es allen frei, die immer schon falsche Zuordnung zu korrigieren, wo halt kein menschliches Wesen als Autor vorkommt; geschieht das nicht schon bei der ersten WSTM-Umwandlung, dann stolpert vielleicht später mal jemand drüber.
Wenn WSTM das nicht deutlich macht, wird die falsche Nutzung der Parameter niemals korrigiert werden können.
Ich drohe doch nicht, mich stört es nur, wenn ich es nicht bemerke, ich schrieb schon zuvor, dass mir die Umstellung auf kl. Änderungen tätigen ohne einen Diff anzuzeigen, nicht gefallen hat. Du hast gesagt da muss ich mit leben, aber solche Dinge sollten nicht „heimlich“ laufen. Es gibt extra diese Einstellung, die ich auch absichtlich nicht verwende, denn ich möchte immer, das wiederhole ich nochmal sehen was das Tool geändert hat. Vertrauen ist gut, Kontrolle ist besser. Wieso meinst du denn drohen oder erpressen, ich verwende das Tool wirklich sehr gern. Was geschieht sehe ich, dass ich damit aber nicht glücklich bin, darf ich doch wohl anmerken. Ich zumindest tue so etwas und schalte nicht einfach das Tool ab. Denn es erleichtert wirklich sehr vieles. Wie kannst du nur so etwas sagen? Ich möchte eine Anzeige, wenn da schon etwas passiert ohne dass ich darüber eine Info bekommen hätte. --Liebe Grüße, LómelindeDiskussion11:25, 22. Okt. 2018 (CEST)
Gegen das Umstellen gibts nichts einzuwenden, aber uns machst du damit mehr Arbeit, denn "Autor=Berliner Zeitung" eindeutig falsch, wogegen "Quelle=Roland Gerber" nicht falsch ist. Wenn also beim Zitat zum Text nur ein Parameter angegeben wurde, sollte er als Quelle benannt werden. Gruß --RonMeier (Diskussion) 14:32, 22. Okt. 2018 (CEST)
„Ich möchte ungern auf WSTM verzichten.“ – Das ist nichts anderes als eine zuckersüße Verpackung von „Wenn du WSTM nicht so änderst, wie ich das will, dann werde ich WSTM nicht mehr benutzen, und aus der WSTM-Kooperation aussteigen.“
Das ist eine Methodik, auf die ich grundsätzlich allergisch reagiere.
Auch ich darf ab und zu wenigstens mal Gefühle haben.+* Dies insbesondere, als der inhaltliche Anlass geringfügig ist: Verantwortlich für die falsche Benutzung des Parameters sind diejenigen Bearbeiter, die das mal vermutlich gedankenlos so hingeklatscht hatten, obwohl sie immer schon dann eine Doppel-Pipe hätten setzen müssen. Dieses jetzt zu verdeutlichen und ohne Änderung an der Wirkung der Vorlage den tatsächlichen Zweck der Parameter im Klartext hinzuschreiben ist keine inhaltlich zu verantwortende oder vorwerfbare Handlung der WSTM-Nutzer.
Grundsätzlich lasse ich mich nie zu etwas zwingen, sondern allenfalls durch schlüssige Argumente überzeugen.
WSTM stuft generell die Korrektur von Namen der Vorlagenparameter nicht als gravierend ein.
Ob und wie ich vielleicht in diesem Fall eine Ausnahme mache und einen gesonderten Erkennungsmechanismus programmieren kann und eine Diffpage erzwinge, muss ich gelegentlich sehen; momentan habe ich für meine ruhigen Programmier-Stunden haufenweise teils dringliche Sachen abzuarbeiten.
„Umgewandelt“, wie der Name des Abschnitts suggeriert, wird nebenbei überhaupt nix. Es erhalten lediglich die Parameter ihre Klarnamen, statt ihre Bedeutung und Auswirkung hinter einer nackten Pipe zu verstecken.
WSTM kann es, wie schon richtig bemerkt, nicht anders auflösen.
Es ist genauso falsch für die Publikation, wenn dort 2= oder Autor= steht, denn beides wird in Kapitälchen geschrieben und bezeichnet den menschlichen Verfasser.
Es ist genauso falsch für den Menschen, wenn dort 3= oder Quelle= steht, denn beides soll das Werk bezeichnen, in dem das veröffentlicht wurde. Dem Menschen würden hingegen Kapitälchen zustehen.
WSTM kann es weder bei Nur-Pipes belassen noch sonst irgendwas.
Irgendjemand muss früher oder später entscheiden, dass der Tagesspiegel kein Mensch ist, und ein Lexikon ist auch keiner. Das gilt für die Zitat-Vorlagen genauso wie für die Internetquelle oder Literatur oder sonstwen; auch dort gibt es als Autor-Parameter explizit falsche Zuweisungen.
Ob ihr das jetzt sofort bemerkt und korrigiert, oder erstmal speichert und irgendwer später mal kommt wer vorbei, ist einstweilen wurscht.
Das langfristige Ziel ist es bei allen Zitatvorlagen, diese unseligen unbenannten Parameter mindestens erstmal von 2 an aufwärts aus dem Bestand zu eliminieren.
Das kann noch ein Jahrzehnt dauern, aber mit der zunehmenden Verwendung des VE wird auch der Widerstand der Auswendig-Nur-Tipper gegen Parameternamen und längere Namen von Vorlagen allmählich abnehmen.
Bis dahin sind es halt die Hinterlassenschaften des Vorlagenwesens der allerersten Jahre, als alle Autoren noch auswendig die Bedeutung und Reihenfolge aller unbenannter Parameter aller Vorlagen kannten – oder aber die Herkunft gnadenlos hinter die erste Pipe nach dem Text geklatscht hatten und sich einen Dreck drum scherten, was das bedeuten würde und wie es dargestellt wird.
Ich habe niemals versucht dich zu etwas zu zwingen. Ich schreibe aber nun mal offen und ehrlich was ich denke, du weißt ebensogut wie ich, dass ich WSTM immer verteidigt habe, dass ich trotz massiver Kritik das Tool fast in der Konfiguration verwende, wie es von dir ausgeliefert wird, dass ich jeden Fehler melde, der mir auffällt.
Keine Ahnung weshalb du gerade so sauer auf mich bist. (ich möchte ungern auf WSTM verzichten erwähnte ich nur, weil mir durch den Kopf ging, dass Silke neulich so etwas schrieb Zitat: „Tools von PerfektesChaos nicht aktiviert, da dieses Tool in der Zwischenzeit Änderungen durchführt, die ich nicht verstehe“ womit ich zumindest vermutete, dass sie WSTM gemeint hat, und das hat mich verdammt noch mal sehr traurig gemacht! Weil für mich all deine Tools, die ich benutzen darf, einen sehr hohen Wert haben.) Ich würde niemals etwas so wertvolles wie eine Kooperation mit dir aufkündigen. So gut solltest du mich eigentlich kennen. Ich würde auch nicht von dir verlangen, dass du etwas gegen deine Überzeugung änderst. Ich habe auch nicht WSTM die Schuld an dieser Misere gegeben. Ich möchte so etwas jedoch nicht versehentlich übersehen, was ist daran falsch? --Liebe Grüße, LómelindeDiskussion15:50, 22. Okt. 2018 (CEST)
„schreibe aber nun mal offen und ehrlich was ich denke“ – naja, wäre nett, wenn du auch berücksichtigst, was das auslösen kann.
Ich habe dir die Stelle zitiert, die du besser nicht getextet hättest.
Die Bemerkung von Silke hatte ich auch zur Kenntnis genommen, aber sie muss von sich aus bei mir anfragen, warum WSTM dies oder jenes machen würde, oder wenn es ihr zu viel damit wird dann halt lassen.
WSTM kann nur den unbenannten Alias durch den Klarnamen ersetzen, nicht aber die Bedeutung von Parametern eigenmächtig vertauschen.
Wir sind die gekniffenen kleinen Putzerfische, die jetzt mühsam aufarbeiten, was die Schnelltipper als Vorlageneinbindung in die Artikel gedroschen hatten, und wir berichtigen halt seufzend alle unangemessenen Autor-Parameter in Vorlage:Internetquelle wie auch bei Zitat oder Literatur. Wenn der WSTM-Bearbeiter es nicht richtigstellt, dann halt irgendwann einer der folgenden Bearbeiter, nachdem jetzt der Parametername deutlich wurde. Passiert mit vielen anderen Nickeligkeiten auch, die WSTM erstmal sichtbar macht, aber die nicht von jedem dann sofort komplett bereinigt werden.
Ja sorry, ich mag es aber nun mal nicht etwas falsch (und Autor = Lexikon ist für mich falsch) im Artikel zu belassen, nur weil ich diese Änderung möglicherweise „nicht gesehen habe“.
Darauf zu hoffen, dass es dann andere tun, das habe ich mir schon lange abgeschminkt. Ich möchte nicht, dass jemand denkt, ich würde so etwas wie „Autor = Lexikon“ bewusst oder gar absichtlich in Artikel einfügen.
Es ist schon schlimm genug, dass Zotero diesen Müll in die Internetquelle oder Literaturvorlagen klatscht und ich das ständig prüfen muss, aber da sehe ich, was ich tue, weil ich für eine Zitation eine Auswertung mache, wenn aber ein Tool etwas umstellt „ohne dass es mir angezeigt wird“, dann stört mich das.
Ich akzeptiere, was immer du tust (selbst die Widerherstellung meiner gelöschten Benutzerunterseite), es ist dein Tool und ich muss mich anpassen. Mir aber gibt das ein „ungutes Gefühl“.
Ich kann nichts dafür, dass ich persönlich damit ein Problem habe, wenn andere dann denken könnten, dass ich so etwas „bewusst“ umgestellt hätte. Das ist mein Problem und das weißt du auch. --Liebe Grüße, LómelindeDiskussion06:28, 23. Okt. 2018 (CEST)
Darf ich mich als Unbeteiligter (und Unverständiger) einmischen? Verstehe ich richtig, dass die Umwandlung eines (falschen) unbenamten Parameters in einen (falschen) benamten Parameter inhaltlich richtig und insofern WSTM nicht „anzukreiden“ ist? Verstehe ich weiter richtig, dass Lómelinde unglücklich damit ist, dass sie diese Änderungen nicht angezeigt bekommt, weil sie gerne den falsch benamten Parameter in einen richtig benamten Parameter ändern würde? Kann man dann nicht an der Festlegung, ob diese Änderung angezeigt wird, etwas drehen? Viele Grüße zu Morgen, --Drahreg01 (Diskussion) 07:01, 23. Okt. 2018 (CEST)
Ja das verstehst du richtig. WSTM macht eigentlich nichts anderes als die bisher unbenannten Parameter mit Namen zu versehen, soweit ist das auch gut, nur gibt es eben auch Verwendungen wie hier bei der Vorlage Zitat, wo die einfügenden Benutzer diese falsch bestückt haben (oder es so machen, wie sie es an anderer Stelle gesehen haben. Insbesondere im Bereich Film und Fernsehen, gibt es gefühlt hunderttausende Artikel mit eigentlich falsch ausgefüllten Zitatvorlagen). Die Idee an sich, das durch die Benennung sichtbar zu machen, wird aber, so meine ich, nicht dazu führen, dass nun andere daherkommen und das korrigieren, sondern eher dazu, dass auch das dann als korrekt (habe ich da und dort gesehen) angenommen und weiter verbreitet wird. Ich fürchte die wenigsten schauen in der Doku nach, es wird eher aus anderen Artikeln übernommen.
Ja ich würde es gern bemerken, wenn das Tool das umstellt, dann könnte ich gezielt die Parameter prüfen. Ähnliches wird mir auch angezeigt, wenn in einem Artikel eine veraltete prettytable oder ein blockquote steht, so etwas ist für mich hilfreich. Ich würde es eben gern anpassen und nicht übersehen.
WSTM kannst du das natürlich nicht ankreiden, denn es ersetzt nur unbenannt zu benannt, der Fehler liegt eindeutig davor bei der Person, die die Vorlage falsch ausgefüllt hatte.
Durch diese Änderung im Hintergrund kann es dann aber so wirken, als wenn der Benutzer, der WSTM verwendet, diesen Fehler erzeugt hat und das möchte ich schlichtweg nicht, ich bin das sehr empfindlich. --Liebe Grüße, LómelindeDiskussion07:38, 23. Okt. 2018 (CEST)
Ich hatte oben geschrieben, dass ich eine besondere Auslösung der Diffpage für die nächsten Tage anstrebe.
Dies habe ich mittlerweile eingebaut.
Grundsätzlich sieht WSTM die Auflösung von Weiterleitungen des Vorlagen-Namens, die Standardisierung der Namen von Parametern und die Reihenfolge der Parameter sowie Parameter-Layout als geringfügig und sicher an, weshalb von der automatischen Diffpage regelmäßig abgesehen wird.
Ich weiß, dass es die Hälfte der 50.000 ANR-Einbindungen betrifft, und dass sich ein allmählicher Migrationsprozess über mindestens ein Jahrzehnt hinziehen dürfte, aber irgendwann sollte mal damit begonnen werden.
In welchem Umfang der Parameter korrekt oder inadäquat zugeordnet wurde, wird sich zeigen.
Generell ist der Einsatz mehrerer unbenannter Parameter in Folge eine Kinderkrankheit der ersten Jahre der Vorlagerei bis etwa 2010, die in vielen Fällen zu Verwechslungen führt, und welche unentdeckt bleiben, wenn sie keine besonders augenfällige Wirkung haben.
@Lómelinde: Wenn man die Artikel suchen würde, über Cirrus, welche Varianten hat man? Ich würde gerne die 50.000 Einbindungen irgendwie untermauert sehen und vllt. kann ich sie in die täglich Arbeiten aufnehmen. mfg --Crazy188021:10, 23. Okt. 2018 (CEST)
Es gibt insgesamt 50.160 aus der Familie im ANR.
Von denen sind nicht unbenannten alle abgedeckt, aber für eine erste Abarbeitung hinreichend viele durch die hier im Angebot.
Dann muss es doch an mir liegen. Ich bekomme noch immer manchmal keinen automatischen Diff dafür. Ich weiß nicht, was ich falsch mache. Beispiel Abschnittsbearbeitung mit Umstellung ohne Diff (kein Grund zu erkennen, fehlende Leerzeile über/unter der Vorlage?) ebenso kein Diff aber eine Umstellung (möglicherweise, weil die Vorlage nicht am Zeilenanfang steht?).
Das ist uneinheitlich hier bekomme ich eine Diffansicht. Und SORRY ich wollte dich nicht unter Druck setzen, wirklich nicht, ich habe jetzt wieder wochenlang ein schlechtes Gewissen deswegen. Es tut mir leid, dass ich das so gedankenlos schrieb. --Liebe Grüße, LómelindeDiskussion08:35, 24. Okt. 2018 (CEST)
Zitatumwandlung 2
Letzter Kommentar: vor 5 Jahren5 Kommentare2 Personen sind an der Diskussion beteiligt
Diesmal muss ich aber um eine Anpassung bitten. Physikum hier wird das Zitat zerlegt = unbrauchbar, wenn ich so etwas übersehen sollte gibt das Ärger und das möchte ich doch vermeiden.
aus
„P.[latner] gehörte zu den vorzüglichsten akademischen Lehrern seiner Zeit. Er leistete Ausgezeichnetes auf dem Gebiete der Philosophie sowohl, als auf dem Gebiete der Med.[izin], und zwar besonders in den Fächern Anthropol.[ogie], Physiol.[ogie], gerichtl.[iche] Med.[izin], Staatsarzneikunde und Psychol.[ogie.] Er verstand es, in seinen Vorlesungen die philos.[ophische] Darstellung in ein gefälliges Gewand zu kleiden, und hat sich namentlich auch durch Anregung des Studiums der Psychol.[ogie] und deren innige Verbindung mit der Med.[izin] verdient gemacht, wobei er mit grösster Entschiedenheit die Wahrheit vertheidigte und Vorurtheile bekämpfte.“
wird
„P.[latner] gehörte zu den vorzüglichsten akademischen Lehrern seiner Zeit. Er leistete Ausgezeichnetes auf dem Gebiete der Philosophie sowohl, als auf dem Gebiete der Med.[izin], und zwar besonders in den Fächern [[Anthropologie
|Autor=Anthropol.[ogie]]], Physiol.[ogie], gerichtl.[iche] Med.[izin], Staatsarzneikunde und Psychol.[ogie.] Er verstand es, in seinen Vorlesungen die philos.[ophische] Darstellung in ein gefälliges Gewand zu kleiden, und hat sich namentlich auch durch Anregung des Studiums der Psychol.[ogie] und deren innige Verbindung mit der Med.[izin] verdient gemacht, wobei er mit grösster Entschiedenheit die Wahrheit vertheidigte und Vorurtheile bekämpfte.“
Das kann so nicht gewünscht sein. Ich muss wirklich sehr aufpassen, auch wenn WSTM in diesem speziellen Fall eine merkwürdige Klammerung Wikilink-'[[' seltsam
]]] anmahnt, ohne die nicht maskierte [ogie], oder eben mit einer Maskierung [ogie], wäre es scheinbar o.k. Magst du mal schauen, ob du das abfangen kannst, oder kommt so etwas zu selten vor und ich habe nur wieder die Stecknadel im Heuhaufen erwischt? --Liebe Grüße, LómelindeDiskussion07:39, 5. Nov. 2018 (CET)
Da gibt es nichts abzufangen.
Die Syntax war vorher schon kaputt und die Darstellung falsch.
Bei Fächern [[Anthropologie|Anthropol.[ogie]]], Physiol. wird nur die öffnende Kalmmer verlinkt, die schließende bleibt unverlinkt draußen.
Der Folgefehler hat nichts mit der Zitatvorlage selbst zu tun; das ist Zufall, auch wenn ein Blockzitat besonders lange Texte abbekommt und deshalb häufiger sowas auftreten mag.
WSTM hatte bereits auf das Problem aufmerksam gemacht und dies in der roten Box vermerkt. Weil die Pipe nicht zuzuordnen wäre, wäre bei unbenannten Parametern das analoge Problem aufgetreten.
Ich verstehe nicht, was du mir mit diesem endlosen Bandwurm sagen willst und was du von mir erwartest.
Blockzitat wäre ob der Länge dringend angebracht, das erst englisch und dann übersetzt im Fließtext hintereinanderzujagen ist ohnehin eine Zumutung für jeden Leser. Siehe die dortige Begründung, auch um das Ende eines Zitats absehen zu können.
Vorlage:Zitat-en wäre hier angemessen, und im Quelltext jeder Parameter auf einer neuen Zeile, statt mit Vorlage:" alles in einer Zeile hintereinander.
Und {{"-en}} ist ohnehin obsolet und wird allmählich eliminiert, besser schnellvergessen.
Nein, ich verwende es als Hilfe, Tippfaulheit. Was man machen könnte ist nicht ausschlaggebend, ich fass diesen Artikel nicht noch einmal an, ich hatte arge Probleme zu erfassen was wo wie als Zitat gemeint sein soll. Um aber wenigstens die korrekten Anführungszeichen einzusetzen behelfe ich mir mit "-en und klicke WSTM an um das dann ordentlich zu formatieren, da ich eh zu Tippfehlern neige lasse ich das lieber automatisch umstellen, nur da waren auch wieder [] in Links drin waren kam auch da mUrks heraus. Da es inline gewünscht war kann ich auch nicht alles einrücken und daher muss es eben {{"}} sein.
O.k., wenn du sagst „pass halt auf“ muss ich eben aufpassen, aber solche Artikel komplett zu überarbeiten, das tue ich mir nicht an. Der hat mich auch so mehr als eine Stunde Zeit gekostet. --Liebe Grüße, LómelindeDiskussion13:45, 5. Nov. 2018 (CET)
Letzter Kommentar: vor 5 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Mal ganz dumm gefragt weil es mir mehrfach unterkam, was genau ist da falsch? Oder anders
mir ist als hätte vor einiger Zeit WSTM automatisch aus |[Aa]lternativtext= ein |alt= gemacht, irre ich mich da?
Zumindest tut es das nicht und wirft es mir stattdessen als „Bildparameter nicht erkennbar alternativtext=“ an den Kopf. 3216 Artikel 888 davon mit leerem Parameter, (was wohl zu dem Fehler führt) Habe es getestet, wenn das ein Inhalt stünde würde es umgewandelt.
Und noch etwas, was nicht so wirklich toll ist. Eine Kombination Link in Vorlage + Vorlage in Link erzeugt |1= |2= und das wird dann im Text sichtbar. Ich weiß so etwas ist absoluter Murks aber ich kann nichts dafür ich bau so etwas nicht ein. Konkret geht es um die Vorlage:Infobox Flughafen bei der im Parameter Nahverkehr die Bahnlinienorlagen innerhalb einer Verlinkung eingefügt wurden. Du siehst hier, wie das dann aussieht.
{{Infobox Flughafen
|Name={{nowrap|Flughafen Köln/Bonn<br />„Konrad Adenauer“}}</span>
|Nahverkehr=[[Liste der SPNV-Linien in Nordrhein-Westfalen#Linien 1–9|Regional-Express]]:<br />[[Liste der SPNV-Linien in Nordrhein-Westfalen#Linien 1–9|1={{Bahnlinie NRW|RE|6}}]] [[Liste der SPNV-Linien in Nordrhein-Westfalen#Linien 1–9|2={{Bahnlinie NRW|RE|8}}]]<br />
[[S-Bahn Köln|S-Bahn]]: [[S-Bahn_Köln#Linien|3={{Bahnlinie NRW|S|13}}]] [[S-Bahn_Köln#Linien|4={{Bahnlinie NRW|S|19}}]]<br />
Bus: [[Kölner_Verkehrs-Betriebe#Buslinien|5={{Buslinie|161|white|#00BFFF|transparent}}]] [[SWB_Bus_und_Bahn#Buslinien|6={{Bahnlinie|RB||SB60|white|#7C8D54|#7C8D54}}]]<br />
[[#Fernbusbahnhof|Fernbusterminal Köln]]
|Straße={{RSIGN|DE|A|59}} {{RSIGN|DE|B|8}}
}}
Nicht sonderlich toll. Wenn so etwas dann möglicherweise ohne Diffanzeige passiert, dann weiß ich nicht hier gab es eine Diffansicht, weil ja andere Fehler (alternativtext und span) vorhanden waren. Möglicherweise hätte ich es sonst übersehen oder erst nach dem Speichern bemerkt. Das alles sind nur Infos, weil es mir gerade aufgefallen ist. Ob man da etwas tun kann, sollte oder muss, weiß ich nicht. Ausgangsszenario war diese Version →Flughafen Köln/Bonn ich habe alles gelöscht, ob das nun so gut ankommen wird, da bin ich mir nicht sicher. --Liebe Grüße, LómelindeDiskussion07:52, 20. Nov. 2018 (CET)
style
Letzter Kommentar: vor 5 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
<refname="http://gw1.geneanet.org">[http://gw1.geneanet.org/genroy?lang=en;p=germaine;n=de+foix ''Stammbaum der Germaine de Foix unter http://gw1.geneanet.org]''</ref>
So etwas ist nun leider keine Ausnahme, an sich wäre es nur ungewöhnlich wenn daraus nicht automatisch folgendes würde.
<refname="[http://gw1.geneanet.org">[http/://gw1.geneanet.org/genroy?lang=en;p=germaine;n=de+foix gw1.geneanet.org">[http] ''Stammbaum der Germaine de Foix unter http://gw1.geneanet.org/]''</ref>
Nun bin ich mir nicht sicher, ob das an mir = meiner Konfiguration des WSTM liegt, oder ein generelles Problem wäre.
Ich denke, dass WSTM eigentlich nicht innerhalb der ref-namens-tags Klammern für Weblinks einfügen sollte. Ich hatte solche Dinger auch früher schon und meine zumindest mich zu erinnern, dass so etwas bisher nicht passierte. Sicher weiß ich es aber nicht.
Das ist grundsätzlich Mist und macht auch die Artikel instabil.
WSTM sucht zuerst nach nowiki, syntaxhighlight und so Zeugs und nimmt das aus der normalen Bearbeitung heraus.
Dann werden magische Wörter, und dazu zählen auch syntaktisch vollständige http/ftp-URL, aus dem Syntax-Fluss herausgenommen und isoliert; so auch diese zwischen den "" und damit ist das nicht mehr als ref-Syntax erkennbar.
Es müsste eigentlich auch heftige rote Fehlermeldungen geben??
Es haben grundsätzlich keine anklickbaren Verlinkungen etwas im name="" zu suchen; das kann auch eines Tages die Artikel aus den Socken hauen.
Momentan werden auf dem Server die ref-Tags von einer Extension zu einem recht frühen Zeitpunkt der weiteren Verarbeitung entzogen. Das ist schon seit einem Dutzend Jahren so und führt auch dazu, dass gesteigerte WikiSyntax-Phänomene nicht mehr innerhalb der ref-Bereiche interpretiert werden, hält aber auch diese URL außen vor.
Eines Tages kann die Parser-Ausführung auf dem Wiki-Server aber auch mal anders aussehen, und dann fliegen einem diese Dinger um die Ohren.
Hintendran im eigentlich als Linkbeschriftung gemeinten Bereich des Beispiels findet sich dann nochmal eine anklickbare URL; da weiß der Server auch nicht so genau was er damit machen soll. Bei Wikilinks bricht er den Weblink ab und macht ein zweites separat anklickbares Wikilink daraus; die URL lässt er jetzt im Moment als Beschriftungstext stehen. Das ist aber undefiniert und nicht gesichert und kann sich auch jederzeit ändern, so dass die URL dann separat anklickbar draußen stünde. Halt Murks, sowas.
Mir musst du das nicht erklären, dass so etwas da nicht hingehört, heftige Meldungen na ja es gab schon eine:
Ungültige Domain gw1.geneanet.org">[http:
aber die kam ja quasi erst durch WSTM’s Änderung zustande. Ich ersetze solche Namenstags für gewöhnlich, wenn ich sie bemerke. Dass es Murks ist weiß ich schon. Ich habe schon komplette Zitationswiderholungen aus "…" entfernt.
Letzter Kommentar: vor 5 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Irgendwie merkwürdig was ich da angezeigt bekomme. Im Diff ist nichts, was automatisch dazu passen würde. Ich bin wegen der doppelten Parameter dort, das ist richtig, aber es verwirrt mich jetzt wirklich, dass außer Leerzeichen nichts verändert wurde obwohl die Meldung sagt
Bitte überprüfe die folgenden automatischen Behebungsversuche.
Vorlagenparameter wiederholt
{{Charteintrag|WO_AT5=7|WO_AT5=7}}
| Titel = Hamma Heyah Ho (Coming Home)→
| TitelErg = Two in One
…
| Anmerkung = Erstveröffentlichung: 10. April 2015 <br />Verkäufe: + 7.500
…
| Anmerkung = Erstveröffentlichung: 24. April 2016 <br />Verkäufe: + 15.000
Wie mag das zustande kommen? Ich hätte jetzt erwartet, dass ein |WO_AT5 = 7 entfernt worden wäre. Spinnt der Diff oder spinne ich? --Liebe Grüße, LómelindeDiskussion14:53, 5. Dez. 2018 (CET)
Da steht ja auch nur was von „Behebungsversuche“.
Ob und wie das dann durch WSTM echt wirksam wird oder nicht ist eine andere Frage.
Wenn es zu heikel ist, weil doch ein Detail nicht passt, dann halt nicht.
Das überrascht mich, normalerweise wäre dann kein Versuch angezeigt. Aber egal. Wenn du sagst das ist normal spinne ich vermutlich. --Liebe Grüße, LómelindeDiskussion15:26, 5. Dez. 2018 (CET)
Letzter Kommentar: vor 5 Jahren9 Kommentare3 Personen sind an der Diskussion beteiligt
Moin Moin PerfektesChaos, ich wollte WSTM bei obigen Artikel laufen lassen, aber WSTM startet nicht, allerdings sehe ich auch nicht warum nicht. Eine Korrektur habe ich jetzt von Hand fertig, trotzdem merkwürdig. Wenn du später mal schauen kannst (also bitte nicht gleich), vielen Dank. (Komisch ist, dass es häufiger USA-Artikel trifft.) mfg --Crazy188019:23, 12. Dez. 2018 (CET)
Das liegt an den offenbar in den USA durch kategorisierende Infoboxen oft fehlenden Kategorien.
Klingt komisch, ist aber so.
Tabellen können auch sortierbar sein, und dann sind andere Regeln betreffend Hintergrundfarbe zu beachten.
Deshalb ist das Antreffen einer Kategorie der Auslöser für WSTM, den Artikel als komplett gesehen festzustellen, und erst danach werden bestimmte Veränderungen an Tabellen vorgenommen.
Wenn du mir ein Beispiel benennst, wo irgendwas Unerwartetes sei, muss die Seite im Originalzustand verbleiben. Wenn du sie ohnehin schon umgebaut hast, kann ja auch nichts mehr passieren, wenn ich die Seite öffne.
Ich finde diese Art von Edits überhaupt nicht gut.
Insbesondere in den USA möchte ich Ruhe haben.
Sowas kann dann auch irgendwann mal ein Bot machen, wenn das weiter abgeschmolzen ist. Damit werden die Beos nicht angepiekst.
Bis dahin richtet es keinen Schaden an, und wenn es nicht gleichzeitig eine wesentliche sichtbare Änderung gibt, dann bitte sowas unterlassen. Wenn du gleichzeitig noch was netter gestaltest, dann kann Syntax so nebenbei mitlaufen, selbst wenn sie der eigentliche Anlass war.
Mal dranhäng: Hab ich das richtig verstanden, dass WSTM zwingend mindestens eine Kategorie erwartet und sonst nicht läuft? Ich hab immer mal Artikel wo ich es nicht gestartet bekomme und die es brauchen könnten. Jetzt hab ich natürlich grad keinen zur Hand, ich lese nur gerade hier. Wenn "fehlende Kategorie im Artikel" der Auslöser wäre, ließe sich das ja temporär von Hand "korrigieren" um es trotzdem ausführen zu können. --Windharp (Diskussion) 13:52, 17. Dez. 2018 (CET)
Nein, nicht richtig verstanden.
Die allgemeine Syntaxtätigkeiten laufen bei Fragmenten jeder Größe ab.
Tabellen sind eine eigene Sache, riesige Dinger, können vielfach verschachtelt sein. Und Abschnitte enthalten, die wiederum separat bearbeitet werden könnten.
Und sortierbar.
Tabellen werden aus Sicherheitsgründen erst zum Schluss bearbeitet, und zwar dann, wenn per Kategorien offenbar das Ende der Seite erreicht worden ist und auch eine komplette Seite bearbeitet wird.
Moin PerfektesChaos, hoffe du hattest schöne Weihnachtstage. Ich habe gesehen, du hast bei den Weiterleitungen von Navileisten eine Seitenverschiebung gemacht. Interessant das. Ähm, ich habe mal einen Artikel gefunden, war nicht aus den USA, aber ich bekomme ihn mit WSTM r nicht gestartet: Samuel Gold. (PS.: Diesmal habe ich auch nichts verändert.) mfg --Crazy188009:54, 27. Dez. 2018 (CET)
Verursacher sind die unerwarteten }} von Webarchiv; an der Stelle macht WSTM das Schachbrett wieder zu, ohne das Schachbrett gesehen zu haben.
Hatte es die letzten fünf Jahre nicht gegeben.
Fix vermutlich morgen auf d online.
Diese Schachbretter gehen mir sowieso massiv auf den Sender.
Das hier ist noch das Format aus den 2000er Jahren mit bald 100 Parametern.
Jetzt ist ein anderes mit nur noch einem Dutzend Parametern in Mode.
Wobei man schlauerweise das noch häufig vorhandene bisherige Format spurenlos von der Vorlagendoku getilgt hat und noch nicht mal den Sachverhalt unterschiedlicher Formate erwähnt. Aber das regt mich bloß wieder auf.
Letzter Kommentar: vor 5 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Nen Gesundes Neues Jahr. Eigentlich nur auffälig, nichts Tragisches: style="background:#f0f0ff;" wird (mehrfach) nicht auf Großbuchstaben umgesetzt (im Gegensatz zu den anderen Zeilen). Ich habs nicht korr. Gruß von der stürmischen Ostseeküste --RonMeier (Diskussion) 17:47, 1. Jan. 2019 (CET)
Etwas abflauendes und entspanntes 2019 zurück.
Das ist reguläres Verhalten; WSTM greift nur in Zeilen ein, die zweifelsfrei als Tabellensyntax erkennbar wären.
Dazu gehören am Beginn {| oder ! und ggf. |-.
Eine einfache Pipe irgendwo zu Beginn ist zu gefährlich.
Durch Tabellenkopf-Vorlagen, Abschnitte innerhalb einer Gesamt-Tabelle und die Möglichkeit der abschnittsweisen Bearbeitung ist es für WSTM extrem schwierig, eine Tabelle nur aus dem Quelltext einer einzelnen Seite und eines bearbeiteten Abscnitts zu erkennen. Das geht eigentlich erst, wenn vorher sämtliche Vorlagen expandiert wurden, und das weiß nur der Parser.
{{nowrap|Blatt,<ref>Für Knoten <code>struct node *K</code> der Schwarzhöhe 0 gilt in der vorgeschlagenen Implementierung die Äquivalenz:
:{| style="text-align:left"
|-
| <code>K != NULL</code> ||style="width:2em"| || <math>\Longleftrightarrow</math> ||style="width:2em"| || <code>*K</code> ist rot.
|}
In den Diagrammen bei den Fällen erkennt man die Knoten, die eine Schwarzhöhe 0 haben können, am Fehlen einer kleinen oder großen Kreisscheibe unterhalb ihres Knotensymbols.</ref>}}
Und das war das Ergebnis der automatischen Umstellung
{{nowrap|Blatt,<ref>Für Knoten <code>struct node *K</code> der Schwarzhöhe 0 gilt in der vorgeschlagenen Implementierung die Äquivalenz:
:{| style="text-align:left"
|2=-
|3= <code>K != NULL</code> |4=|style="width:2em"|5= |6=|7= <math>\Longleftrightarrow</math> |8=|9= |10=|11= <code>*K</code> ist rot.
|12=}
In den Diagrammen bei den Fällen erkennt man die Knoten, die eine Schwarzhöhe 0 haben können, am Fehlen einer kleinen oder großen Kreisscheibe unterhalb ihres Knotensymbols.</ref>}}
optisch das hier<br />
{{nowrap|Blatt,<ref>Für Knoten <code>struct node *K</code> der Schwarzhöhe 0 gilt in der vorgeschlagenen Implementierung die Äquivalenz:
:{| style="text-align:left"
|2=-
|3= <code>K != NULL</code> |4=|style="width:2em"|5= |6=|7= <math>\Longleftrightarrow</math> |8=|9= |10=|11= <code>*K</code> ist rot.
|12=}
In den Diagrammen bei den Fällen erkennt man die Knoten, die eine Schwarzhöhe 0 haben können, am Fehlen einer kleinen oder großen Kreisscheibe unterhalb ihres Knotensymbols.</ref>}}
{{FNBox|1=
{{Anker|so}}
<references />}}
Du musst mir nicht erklären, dass das absoluter Murks ist und man so etwas nienicht tun sollte. Es ist nur eine Info. Ich habe es entfernt. --Liebe Grüße, LómelindeDiskussion08:40, 12. Jan. 2019 (CET)
Letzter Kommentar: vor 5 Jahren9 Kommentare3 Personen sind an der Diskussion beteiligt
Bis zum ersten "nowiki/" wird WSTM nicht ausgeführt. Erst wenn ich die Vorlage "Belege fehlen" entferne, werkelt WSTM im kompletten Artikel. Gruß --RonMeier (Diskussion) 18:12, 22. Jan. 2019 (CET)
Bedaure, aber das kann ich nicht reproduzieren.
Bei mir werden auf Anhieb vier getarnte geschützte Leerzeichen gefunden, und zweimal Hg. in Hrsg. umgewandelt.
Ein nowiki/ finde ich überhaupt nicht. Richtiger Artikel?
Die Belege fehlen ist auch unspektakulär. Allenfalls würde ich in ihren Vorlagennamen wnadeln, aber da sie ja schon mit richtigem Namen drinsteht, wird sie ignoriert.
Ich hatte es auch angesehen und ja ich hatte es ähnlich „empfunden“ wie RonMeier (Leerzeichenumwandlung ging automatisch, die Schaltfläche brachte aber erst nach entfernen des Bausteins einen Diff, lässt sich nun natürlich nur noch schwer testen, nee geht nicht mehr wirklich), auffällig ist nur eine Fehlermeldung in der Konsole, ehe man den Artikel bearbeitet, also nur im Lesezustand. Irgendein Sicherheitsprotokollkram (scheinbar bei allen Wartungsbausteinen, Belege fehlen, Lückenhaft, Nur Liste).
Ich muss da eh noch mal reinschauen, das war so vermurkst, dass ich mich zurückhalten musste, um es nicht gleich anzupassen. Ich teste noch mal. Was nicht ginge wäre aber so etwas.
Danke, dass du da doch noch reingesehen hast, ich hatte nicht damit gerechnet, sonst hätte ich es stehen lassen. Wenn du da ne Idee hast, die alte Version steht bei mir in der Spielwiese. Gruß --RonMeier (Diskussion) 08:52, 23. Jan. 2019 (CET)
Ne, ich habe keine Idee, das hilft mir auch nicht wirklich, denn meine Konfiguration ist so eingestellt, dass ich das Tool auf fremden Benutzer[unterseiten] nicht starten kann. Ich denke, WSTM hatte auch in der Version schon alle erkennbaren Fehler behoben, nur eben kein Diff angezeigt. Das verwirrt mich auch immer wieder, weil ich denke ‚huch, hätte da nicht etwas passieren müssen‘. Aber PC sagte Kleinstveränderungen ohne Diff ist besser.
Ich habe so meine Probleme damit und klicke dann immer manuell auf Änderungen zeigen, denn ich möchte nicht versehentlich etwas speichern, das ich nicht gesehen habe. --Liebe Grüße, LómelindeDiskussion10:04, 23. Jan. 2019 (CET)
WSTM fasst aber nur ISBN-Gedöns an, wenn es zu einer Zitation gehört, weil sonst die Gefahr besteht, dass es übergriffig wird und anders gelagerte Fälle, etwa Formatierungsbeispiele, geplättet würden.
Das verstehe ich jetzt nicht wirklich, ist das beabsichtigt? Ich frage nur weil ich in meinem Bearbeitungskommentar etwas wie Darstellungsfehler HTML5 span durch kursiv im Parameter |w= der Vorlage:faS schreibe das wäre aber verwirrend, wenn ich das w= zugleich entfernen lasse. --Liebe Grüße, LómelindeDiskussion17:49, 1. Feb. 2019 (CET)
Die Fett-Kursiviererei ist an dieser Stelle unangemessen.
Es ist noch nicht einmal ein Weiterleitungsziel, was vielleicht eine Fettung begründen könnte; es ist einfach nur die Umschrift der davor stehenden arabischen Buchstaben, und die bekommen überhaupt keine Apostrophe und werden von selbst kursiv.
Generell werden alle diese Aliasse allmählich zurückgebaut, um den für 250 Vorlagen einheitlichen Parametersatz zu unterstützen.
Ggf. könnte sich jemand für faS noch einen „neu“-Schalter als prefix=1 wünschen. War aber noch keiner dagewesen. So irgendwie Textbrösel vor eine Vorlage zu schreiben, ist riskant, weil das nicht der Bestimmung der Vorlage entspricht und die sich auch anders verhalten könnte.
Letzter Kommentar: vor 5 Jahren5 Kommentare2 Personen sind an der Diskussion beteiligt
Moin Moin PerfektesChaos, weil es mir auffällt eine Kleinigkeit für WSTM. Die Vorlage "Quellen" wird ja automatisch zu "Belege fehlen" umgebaut durch WSTM. Aber "quellen" als Vorlage bleibt unberührt. Kannst du "[Qq]uellen" prüfen und ersetzen lassen? Danke dir und schönen Abend noch --Crazy188018:36, 12. Feb. 2019 (CET)
Hmm, dann scheint es an meinem Opera zu liegen. Tatsächlich macht Firefox es. Ich geh nochmal auf die Suche. Danke --Crazy188006:57, 13. Feb. 2019 (CET)
Okai, Fehler gefunden, die Vorlage heißt nicht "Quellen" sondern nur "Quelle" und verweist auch auf "Belege fehlen". Was die Leute sich so alles einfallen lassen. mfg --Crazy188019:18, 13. Feb. 2019 (CET)
War mein Fehler, sorry.
Dass es vier WL auf den richtigen Namen gibt, war mir und WSTM seit bald einem Jahrzehnt bekannt gewesen.
Als ich vor einigen Wochen das Vorlagenumbenennungswesen durch ein effizienteres und übersichtlicheres System ersetzte, ist mir die Quelle mit ohne n bem Umkopieren irgendwie runtergefallen.
Ich würde anraten, die [typo:] Läd WSTM manuell hinter sämtliche Konfigurationseinstellungen zu verschieben; irgendwann ist dein Browser schneller als du denkst.
Kann es sein, dass da auch nichts durch WSTM zu ändern wäre. Was passiert denn genau nicht? Bei mir springt es an, da ich noch Klammern um Weblinks setzen lasse, das aber wären die einzigen Änderungen, die mir der Diff dann anzeigt.
Okay, Du scheinst Recht zu haben. Ich dachte ich hätte es schom getestet, aber wenn er was zu ändern hat springt die Ansicht auch um. Ich hätte gedacht, er schaltet auch die Ansicht um, wenn er gar nichts zu ändern hat, und zeigt ein "leeres" Diff... Macht er das standardmäßig nicht (mehr)? --Windharp (Diskussion) 07:53, 22. Feb. 2019 (CET)
Ja seit einiger Zeit werden selbst kleinste Änderungen nicht mehr im Diff angezeigt, auch ich habe das moniert, aber der „Chef“ sagte, es ist dadurch schneller. --Liebe Grüße, LómelindeDiskussion09:03, 22. Feb. 2019 (CET)
Letzter Kommentar: vor 5 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Wenn ich an eine fehlerhafte ISBN direkt oder nach Leerzeichen einen Bis-Strich (–) anhänge, erkennt WSTM den Fehler nicht mehr. Gruß --RonMeier (Diskussion) 11:01, 26. Feb. 2019 (CET)
Es wird dann überhaupt keine ISBN erkannt; das Suchmuster für ISBN springt nicht alles und jedes an.
Letzter Kommentar: vor 5 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Moin Moin PerfektesChaos, irgendwie bekomme ich WSTM heute nicht zum Laufen. Verschiedene Artikel, verschiedene Browser, verschiedene Betriebssysteme. Die Artikel weisen alle "Probleme" auf. Ich habe WSTM so konfiguriert, dass es nicht automatisch startet, sondern auf Klick. mfg --Crazy1880 06:54, 22. Mär. 2019 (CET)
Nachtrag: r.js funktioniert nicht, d.js funktioniert. --Crazy188007:15, 22. Mär. 2019 (CET)
@Crazy1880: Da war beim Komprimieren von d zu r ein Bug drin; müsste jetzt raus sein.
Die Streik-Zeit hatte ich tatsächlich für offline-Programmierung genutzt, insofern stimmt die Abschnittsüberschrift schon.
Letzter Kommentar: vor 5 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Moin Moin PerfektesChaos, ich habe mal das Quarry von 2016 aktualisiert und habe hier die aktuelle Liste aufgebaut. Da sind wieder einige Navi-Leisten dabei. Können wir die wieder an dieser Stelle einbauen, damit man sie wegarbeiten kann? mfg --Crazy188011:07, 23. Mär. 2019 (CET)
Ich bin überhaupt nicht glücklich damit, wie in den letzten Monaten mit diesen Listen umgegangen wurde.
Es wurden sehr oft Edits gemacht, die ausschließlich den Namen der Vorlage geändert hatten.
So ist das nicht gedacht.
Es wurde auch nicht WSTM oder anderes Werkzeug benutzt, um bei diesem Mini-Edit dann wenigstens die Syntax einmal geradezuziehen.
Ich werde das auf der fraglichen Unterseite mit der bisherigen Tabelle sicher nicht fortsetzen.
Nebenbei macht die Betreuung und das Nachsteuern der Programmierung einen Haufen Arbeit. Dabei ist das eines der schlichteren Probleme, es gibt verwirrende Vorlagenkonstrukte als so eine dusslige Navileisten-WL.
Eine geeignete Strategie für die Zukunft muss ich mir erst noch austüfteln.
Ich kann das in WSTM einbauen und primär stillschweigend mitlaufen lassen.
Das kannst du unterstützen, indem du mir den Programmcode aufbereitest. Schreibe in Benutzer:PerfektesChaos/js/WikiSyntaxTextMod/flow/template/dewiki/temp nach folgendem Muster:
"ŠK Slovan Bratislava":"Kader des ŠK Slovan Bratislava","„Die Griswalds“":"„Die Griswolds“",
Wobei der letzte schon wieder Gegenstand für eine erneute Verschiebung wäre; um sowas setzen wir nicht nochmal Anführungszeichen.
Ein Stück weiter oben schrieb ich dir, dass du deine vector.js abrüsten könntest. Die Anweisungen greifen ins Leere.
Letzter Kommentar: vor 5 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Du scheinst etwas verändert zu haben, ist mir neulich schon mal aufgefallen.
eigentlich ist es gut wenn die Tags verdunsten, aber es bleibt manchmal ein merkwürdiger Rest zurück. Beispiel:
{{laS|''pascha'', auch ''Festum paschale''}} → {{laS|pascha'', auch ''Festum paschale}}
Ja, ich weiß, ist eh Murks, weil das „auch“ da nicht hineingehört. --Liebe Grüße, LómelindeDiskussion17:06, 31. Mär. 2019 (CEST)
Uff, auf was für Quark die Leute so alles kommen. Apostroph-Rausschmiss unterbunden wenn innendrin ein weiteres Apostroph vorkommt. Danke für den Hinweis --PerfektesChaos21:05, 31. Mär. 2019 (CEST)
Vorlage:Zitat klein und in derselben Zeile
Letzter Kommentar: vor 5 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Ruf bitte mal die Jungfer#Etymologie auf und beobachte was dort mit der Vorlage:Zitat passiert. Da lobe ich mir Schnarks Syntaxhighlighter, der mir sofort anzeigt, dass aus zwei Vorlagen-Schleifenklammern {{ (hellgelb) Parameter-Schleifchen {{{ (orange) werden. --Liebe Grüße, LómelindeDiskussion19:02, 31. Mär. 2019 (CEST)
Stöhn.
Gleichzeitig klein und ohne neue Zeile und mit Parametern ist rätselhafterweise irgendwie zu viel auf einmal.
Ich gedenke bald eine Behelfslösung zu starten; erstmal Großschreibung, in einem weiteren Schritt dann die Normalisierung vertagt.
Zumindest heute abend kein Durchblick mehr, was da wen überfordert.
Letzter Kommentar: vor 5 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Öffne bitte mal →Präfektur Kanagawa#Politik das darf nicht passieren. Diese Pipe muss immer in der Zeile am Ende stehen bleiben, weil das Diagramm sonst zerstört dargestellt wird. Bei mir wird es aber eine Zeile tiefer gesetzt, so dass diese dann mit || LDP = 49 beginnt. --Liebe Grüße, LómelindeDiskussion07:32, 15. Apr. 2019 (CEST)
Stöhn.
Diese süße Altlast aus vergangenen Quelltext-Zeiten darf wirklich mal jemand durch eine Lua-Programmierung ersetzen. VE-tauglich ist das auch nicht.
Ich habe nachgesehen; es gibt keine realistische Chance, WSTM hiervon abzuhalten, weil grundsätzlich keine Pipes am Zeilendende erlaubt sind.
Vorlage:Sitzverteilung #Beispiel nennt den von WSTM bewirkten Zustand ausdrücklich als legal, und in der ganzen Doku ist der Fall auch nicht erwähnt.
Ich habe aber eine Nase, welche Situation in der Vorlage das ausgelöst hatte, und werde dies versuchen robuster zu machen. Das kommt dann allen Anwendern in allen Artikeln zugute, mit oder ohne VE, und WSTM stört dannn auch nicht mehr.
Es ist wohl der Spezialfall, dass OTH Farbe = AAA explizit individuell definiert wird, und bei der Bildung dieses Parameters aus 6=OTH stört der Zeilenumbruch.
Ich repariere es zwar immer wieder, aber es wäre natürlich besser, wenn es an der Ursache behoben werden könnte. Es gibt vieles, was in die Jahre gekommen ist. Das doofe Klimadiagramm nervt auch ab und an mit Fehlermeldungen (nicht WSTM-bedingt) die durch ausblenden eines Teildiagramms unsichtbar im Seitenelement stören. Hatte ich gerade wieder einmal, aber auch das ist mir viel zu komplex, als dass ich es anfassen möchte. --Liebe Grüße, LómelindeDiskussion13:29, 15. Apr. 2019 (CEST)
ISBN in Vorlage in ref …
Letzter Kommentar: vor 5 Jahren5 Kommentare2 Personen sind an der Diskussion beteiligt
Ich wunderte mich nämlich, weil da eine Nummer war, die merkwürdig aussah und ich erst dachte da stimmt etwas mit dem Format nicht. Ich musste sie erst aus der Vorlage nehmen, um sie zu formatieren. Schade eigentlich. --Liebe Grüße, LómelindeDiskussion16:04, 17. Apr. 2019 (CEST)
Ich kann dir geistig nicht folgen und finde a.a.O. keine derartigen Zeichenketten.
WSTM würde aber im offenen Text von Parameterwerten formatieren, falls „ISBN“ davorsteht und es kein HTML-Kommentar ist.
Diese Programmierung ist von 2012/13; ich kann mich kaum noch an was erinnern.
Erkannt würde, wenn der Vorlagenparameter ISBN= oder isbn= heißt.
Im Inneren von Parameterwerten wird dann vermutlich keine neue Suche nach ISBN mehr gestartet, weil diese dann schon gekapselt wurden. Es gibt da was, aber anscheinend nicht mehr ISBN.
War bislang noch nie aufgefallen; vielleicht auch hier ein Sonderfall, dass ein Parameterwert eine weitere Vorlageneinbindung ist.
Ist auch nicht so wichtig. Ich wünsche dir angenehme Ostertage. Bin von Fr. Mittag bis So. nicht online. Na ja ich dachte es ist zu tief ineinander geschachtelt. --Liebe Grüße, LómelindeDiskussion17:24, 17. Apr. 2019 (CEST)
Bitte entröllen
Letzter Kommentar: vor 5 Jahren5 Kommentare2 Personen sind an der Diskussion beteiligt
Ja aber ich kann trotzdem nicht einfach Artikel vermurksen. Auch diese Britannica müsste neu aufgestellt werden. Gerade suche ich aber nach Band erste Seite letzte Seite. --Liebe Grüße, LómelindeDiskussion16:03, 19. Apr. 2019 (CEST)
Letzteres habe ich schon bemerkt; danke soweit.
Kannste dir aber sparen, weil wenn ich irgendwann mal wach bin, werde ich mindestens alle |Band| durch die modernisierte Neuprogrammierung dieser Vorlage detektieren, und auch alle problematischen Seitenzahlen über zentrale Auswertung auf Plausibilität auffinden; das mache ich aber einmalig für zukünftig über 1000 Einbindungen.
Roell-1912 (zeno-Schreibweise) kommt demnächst zurück; vielleicht zusätzlich auch als Röll-1912 bzw. dann besser als RöllEnzEisenbahn. Ist aber ein zurückgestelltes Fachgebiet; nicht dran rühren, hinten anstellen, einfachere zuerst wirksam werden lassen.
finde ich zumindest. Und wenn wir schon mit annähern gleichen Parameternamen arbeiten können die doch auch in der selben Reihenfolge stehen oder? --Liebe Grüße, LómelindeDiskussion18:37, 6. Jun. 2019 (CEST)
Du hattest wohl selbst die |Autor= zur ursprünglichen Vorlagenprogrammierung hinzugefügt. WSTM wusste nichts davon und schiebt Unbekanntes an das Ende.
Die Runebergs stehen da nur noch zur Vollendung der Migration drin. Danach wird WSTM mit den Runeberg-Vorlagen nichts mehr anfangen können und die Programmierung wird aus der aktiven Wirkung entfernt.
Salmonsen ist bei mir schon längst raus.
Bei mir auf der Festplatte bin ich deinem Wunsch nachgekommen.
Du könntest ein wenig an der Vereinfachung der Vorlagenprogrammierung und von WSTM mitwirken, indem du gaaaanz laaaangsaaaam die folgenden Treffer einebnest: HandlexikonJ + Familjebok Ok – auf die wartet WSTM noch.
War das hier mit „auf die wartet WSTM noch“ gemeint. Es läuft nämlich auf den Seiten (familjebok) nicht an und wirft mir Meldungen an den Kopf, die ich nicht verstehe. --Liebe Grüße, LómelindeDiskussion13:18, 8. Jun. 2019 (CEST)
SvensktBioHandlexikon habe ich mal auf Schnüffelkat gesetzt; andere NR und verborgene Gemeinheiten und so.
Kann dann abschließend mit Doku auf Null zurückgebaut werden.
WSTM kennt SvensktBioHandlexikon bei mir jetzt nicht mehr.
Bei template.nordFamilje.fetch hatte ich eine vermeintlich überflüssige Funktion zu früh auskommentiert, danke für den Hinweis.
Kommt je nach Wetter und inner-außer-Schädel-Temperatur vermutlich über Nacht d-live.
Bei über einem Dutzend langjähriger Migrationsprozesse verliere ich allmählich den Überblick, was alles mit welchen Parametern wie noch von WSTM unterstützt werden müsse; wird allmählich Zeit zum Abschluss einiger Umstellungen und radikalen Vereinfachung.
Ich tu was ich kann. Leider brauche ich doch mehr Zeit für jeden Edit als ich dachte. Andere Namensräume fürs Handbuch, das habe ich schon abgearbeitet, dachte ich. --Liebe Grüße, LómelindeDiskussion15:35, 8. Jun. 2019 (CEST)
„Ich tu was ich kann. Leider brauche ich doch mehr Zeit für jeden Edit“ – hetz dich nicht, das kommt alles aus derselben Thematik, und gut möglich dass jemand die alle auf der Beo hat. Dann ist es günstiger, wenn du da nicht in 20er- oder 10er-Blöcken am selben Tag aufschlägst.
Ich habe d von dem Vorlagenzeugs live geschaltet; alle mir bekannten Bugs und updates wirken damit erstmal.
Ich schaue mal was passiert. 1. es sind nicht so arg viele Fälle. 2. ich ändere ja nicht nur die Vorlage das wäre nicht wirklich zeitaufwändig. Aber wenn ich das schon anfasse, dann kann ich ja auch gleich schauen ob sonst noch etwas geht. Der letzte Fall gestern war aber wirklich kurios. --Liebe Grüße, LómelindeDiskussion06:17, 9. Jun. 2019 (CEST)
WSTM-Format der Vorl.Internetquelle in "Weblinks"
Letzter Kommentar: vor 5 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Hi PC, ich habe seit mehreren Wochen WSTM in meiner .js und genieße die Vorteile bei meinen <ref>-Pflegearbeiten, vielen Dank für dein Werk :)
Ich wundere mich allerdings darüber, dass WSTM die Vorlage:Internetquelle mit unterschiedlichen Einrückungen formatiert, abhängig davon, ob sie im Artikelabschnitt "Weblinks" steht oder unter "Einzelnachweise":
"Weblinks": |autor=… = größerer Leerabstand
<references>: |autor=… = kleiner Abstand
Problem: Das Format mit größerem Abstand kann nicht kopiert und als Beleg unter <references> benutzt werden, bzw. bewirkt eine Formatumwandlung bei einer folgenden Bearbeitung des Artikels.
Gleiches betrifft das WSTM-Format der Vorlage:Literatur: unterschiedlich in den Abschnitten "Literatur" und "Einzelnachweise".
Ich kann keinen Vorteil in der unterschiedlichen Abstandsformatierung erkennen… Gruß --Chiananda (Diskussion) 16:57, 12. Jun. 2019 (CEST)
Ich verstehe deine Ausführungen nicht vollständig, aber das Pipe-Symbol steht immer unter der zweiten öffnenden geschweiften Klammer; der erste Buchstabe jedes Parameternamens immer unter dem ersten Buchstabe des Vorlagentitels. So auch oft bei Infoboxen.
Weil in den durch Aufzählungspunkten gegliederten Abschnitten wie „Literatur“ oder „Weblinks“ jeweils ein Sternchen und ein Leerzeichen erwartet werden, stehen vor dem Pipe-Symbol drei Leerzeichen.
In den ref-Blöcken des Abschnitts „Einzelnachweise“ beginnt der Eintrag mit der geschweiften Klammer; somit ist vor dem Pipe-Symbol genau ein Leerzeichen zu erwarten.
Wenn du irgendwas kopierst, ist Reihenfolge der Parameter und Leerzeichenerei eh wurscht. Der nächste WSTM-Bearbeiter wird es schon richten. WSTM ist für automatischen Start ausgelegt; es gibt aber verschiedene Möglichkeiten, zusätzlich oder alternativ eine manuelle Auslösung bereitzustellen.
aber … ist das wirklich ein Grund für diese mysteriöse Reduktion? Ich habe es nur bemerkt, weil ein anderes Tool plötzlich ein URL/Pfad ungültig bemängelt hat. Wenn es an mir liegen sollte muss ich mal irgendetwas aus meiner .js streichen, so etwas darf nicht passieren. --Liebe Grüße, LómelindeDiskussion08:46, 15. Jun. 2019 (CEST)
Guten Morgen. Weiß ich auch grad nicht so genau.
Ich weiß jedoch: Wer auch immer die schwachsinnige Idee hatte, beim url-Parameter sieben Buchstaben einzusparen, und damit die Syntaxanalyse des URL-Parameters abzuschießen, und auch jeden abzuschießen, der im gesamten ANR nach allen Vorkommen von http://www.dillingen-saar.de/ suchen würde, der hat dem Gewurstel mit dieser Vorlagenprogrammierung keinen Gefallen getan. Das gesamte Umfeld um Internetquelle und URL und Archiv-URL ist in den letzten fünf Jahren durch inkompetentes Rumgeflicke massiv geschädigt worden. Je mehr versponnene Extrawürste man in eine zulässige Parametersyntax einbaut, desto schwieriger wird das auch nur zu dokumentieren und richtig von den Autoren anzuwenden, außerdem eine den Hunderttausenden an Bestandseinbindungen gerecht werdende Programmierung über die nachfolgenden Jahrzehnte noch zu unterstützen.
Ich habe kurz in die WSTM-Programmierung geguckt und sehe dort nichts, was dafür verantwortlich sein könnte.
Gemäß offizieller Doku ist eine Verwendung ohne Protokoll unerlaubt, und war das auch schon immer gewesen, und war schon immer als vollständiger „Weblink“ (inkompetent für „URL“) vorgeschrieben. Irgendeine Nuss hat sich da abweichend von der Doku ein privates Sahnehäubchen einprogrammiert.
Es passiert „nur dann“, wenn das ein PDF ist und zugleich auch noch _ oder 20% vorkommt, wenn ich das richtig sehe. Beispiel: Josef Weiser (Politiker, 1881) macht Murks
Würde man nun im hinteren Bereich also zwischen dem letzten / und .pdf irgendwo ein _ oder 20% einbauen, sprich
/hrh_cv.pdf → {{Webarchiv |url=hrh cv.pdf |wayback=20141105154428 |text=CV of Hans Robert Hansen auf wu.ac.at}} oder
/hr%20h-cv.pdf → {{Webarchiv |url=hr h-cv.pdf |wayback=20141105154428 |text=CV of Hans Robert Hansen auf wu.ac.at}}, dann würde es wieder zerbrechen. --Liebe Grüße, LómelindeDiskussion19:31, 15. Jun. 2019 (CEST)
War ein WSTM-Bug gewesen; die URL die keine URL war mit Endung als Mediendatei hatte die Klassifizierung des Parameterwerts durcheinandergebracht weil unerwartete Situation.
Nein, das ist noch Folgefehler von nicht korrekt angegebenen URL, zusammen mit dem fehlenden eigentlich als Pflichtparameter einzufordernden text=.
Es ist das konfuse Gebastel der in den letzten fünf Jahren mit Webarchivierung herumwurstelnden Leutchen in diesem Bereich, die die Vorlagen, ihre Programmierung, Dokumentation und ANR-Verwendung an die Wand gefahren haben.
Zero-width non-joiner und Parameter-spezifische template styles
Letzter Kommentar: vor 5 Jahren5 Kommentare2 Personen sind an der Diskussion beteiligt
Einmal mehr vielen Dank für all die nützlichen Ersetzungen und Einstellungen! Ich habe zwei Fragen:
Lässt sich die Ersetzung von Zero-width non-joinern irgendwie abstellen? Ich benutze das WSTM auf Commons und bearbeite immer mal wieder Seiten mit persischem Text, die Ersetzung muss dann immer manuell wieder zurückgeändert werden …
Benutzer:PerfektesChaos/js/WikiSyntaxTextMod/usage/replace/template#format style lautet: „Das Objekt format.style macht detaillierte Vorgaben zum Layout. Es wird standardmäßig auf alle Parameter angewendet, sofern nicht einzelnen Parametern ein eigener style zugewiesen wurde.“ Wie lässt sich denn Parametern ein eigener style zuweisen? Wenn ich in {{foo}} nur für |bar= ein indent oder linebreak haben will, nicht aber für die anderen Parameter? Ich finde es jedenfalls nicht beschrieben, wie das geht.
Die Sache mit den unsichtbaren Nullbreiten und wann man sie ganz unsichtbar haben will und wann nicht ist so eine Sache. WSTM selbst macht sie innerhalb von Verlinkungen wieder unsichtbar; eigentlich finde ich es aber gar nicht so schlecht wenn man die Dinger sehen kann. Ich kann kein Arabisch schreiben, aber mir ist nicht ganz klar, wie man das schreiben kann, wenn man es weder eingeben noch korrigieren könnte.
Die Parameter und ihre einzelnen Stile sind leider 2012 steckengeblieben. Du findest auf der beschriebenen Seite ein Element params mit dem Zusatz (geplant). Dies wurde mangels Zeit und Bedarf (du bist nach sieben Jahren der erste, der nach einem style für einen einzelnen Parameter fragt) nicht mehr in der Schnittstelle nach außen weitergeführt. Da das zukünftige Layout stark vom VE bestimmt werden wird und der nur durchgängiges Quelltextformat kennt, plane ich hier auch keinen weiteren Ausbau mehr. 2012 hatte es noch Sitten gegeben, für lat_ und lon_ je drei Hexagesimalkomponenten in eine Zeile zu schreiben, während der Rest einen Parameter pro Zeile hatte. Dafür war das eigentlich mal vorgesehen gewesen.
Klar, zwischen lateinischen Buchstaben ohne Ligaturen kann man die ZWNJs nicht sehen. Im Persischen stehen zwischen Buchstaben die normalerweise ligiert werden sollen, hier aber nicht, die ZWNJs lassen sich dann durchaus sehen. Eingeben kann man sie auf der iranischen Standardtastatur mit shift+space, sonst mit anderen Tastenkombinationen je nach Betriebssystem und Tastatur. Aber die "‌"s im Text sind nicht nur nicht so nützlich, sondern sehr störend, weil sie die RTL-Ordnung zerstören, es steht dann da mutatis mutandis "KLMNO‌FGHIJ‌ABCDE" statt "ABCDEFGHIJKLMNO" – und das innerhalb eines Wortes (auch hier zu sehen). Am angenehmsten wäre es natürlich, wenn die Funktion an Stellen innerhalb arabischer und hebräischer Schrift (und vielleicht anderen?) automatisch abgestellt würde. Aber wenn man die Funktion für ein internationales Projekt wie Commons ganz abschalten könnte, wäre es auch gut.
Okay, das war für mich nicht ganz klar geworden, ob sich die Stelle auf eine geplante Funktion bezieht oder ich nur nicht kapiere, wie man es konfiguriert. VE ist nicht nicht zuletzt der Grund, warum ich nachfrage. Ich würde gern einen Stil entsprechend {{_\n |_ = _\n}} in VE definieren. Aber es ist wohl nur {{_\n |_ = _\n }} möglich, mit gleichem indent für Parameter und schließende }}. (Ich fürchte ich war deswegen schon einmal hier.) Ich dachte ich könnte den Parameter-spezifischem style als Workaround benutzen. Aber wenn es ihn nicht gibt, dann geht es nicht, dann weiß ich Bescheid.
WSTM ermöglicht wohl auch heute einen Stil mit anders behandelter schließender Klammerung, aber der nächste VE-Bearbeiter würde das wieder einebnen.
Damit würde ich das bei den persönlichen Geschmacksfragen einsortieren, und da zukünftig der Wikitext ohnehin seltener vor menschliche Augen kommt, ist das kein lohnendes Ziel.
Zum ersten, nullbreit:
WSTM weiß von dem Problem.
Die Tücke ist, dass zwischen zwei Schriftzeichen der speziellen Schrift das Zeichen nicht als Entity auftauchen solle; aber an allen anderen Stellen, wohin es irrtümlich kopiert wurde, sichtbar sein muss.
Das gilt für sämtliche Projekte, nicht nur Commons.
Für die Bearbeiter aller anderen Seiten, die jedoch überhaupt nichts damit zu tun haben, darf es aber nicht zu Verzögerungen kommen, weil jetzt ganze Texte nach überhaupt nicht vorhandenen Entities und nichtlateinischen Schriftzeichen gesucht würde. Das darf nur geschehen, wo „linker“ und „rechter“ Nachbar des nullbreiten Zeichen zum speziellen Schriftsystem gehören würden.
WSTM weiß davon, macht aber keinen Gebrauch in unverlinktem Text bei:
WSTM weiß nicht, welche Unicodes welches Schriftzeichen links und rechts haben dürfte, um die Entities unsichtbar zu machen. WSTM weiß auch nicht, welche Sprache der Text haben solle.
Insofern würde ich nicht auf eine baldige Lösung hoffen; ausgeschlossen ist das hingegen nicht.
2) In der Tat ist ein anderer Stil möglich, aber ein gleicher Stil ist nicht möglich in besagtem Fall.
1) "WSTM weiß davon, macht aber keinen Gebrauch in unverlinktem Text bei" verstehe ich nicht, das scheint ja nicht der Fall zu sein. Ja, am besten wär’ es wohl wenn es sich je nach Bedarf des Benutzers konfigurieren ließe. Aber es lässt sich auch ohne ganz gut leben.
Vielen Dank für die Antworten, es ist ja auch beides für den Gesamtdienst, den WSTM leistet, verschmerzbar, sind pro betroffenem Edit wenige Sekunden zum Zurückändern, kein Drama. --Marsupium (Diskussion) 04:35, 22. Jun. 2019 (CEST)
Vorlage Internetquelle
Letzter Kommentar: vor 5 Jahren4 Kommentare3 Personen sind an der Diskussion beteiligt
@PerfektesChaos: In der Vorlage wurde/wird wohl der Parameter |zugriff durch |abruf ersetzt. Leider ändert dein Skript das immer wieder zurück auf |zugriff. Kannst/Willst du das ändern?--Bungert55 (Diskussion) 08:49, 7. Jun. 2019 (CEST)
eine Vorab-Testversion zur Erprobung durch einige Versuchskarnickel
eine kleinere, robuste, effiziente Version für den Volksgebrauch
Zurzeit ist die Erprobungsversion noch nicht stabil und kann noch nicht an alle online gestellt werden.
Die bisherige Allgemeinversion erkannte abruf= und Abruf= als Irrtümer aus Vorlage:Literatur und korrigierte auf das ein Dutzend Jahre geforderte zugriff=.
Die Erprobungsversion weiß schon von abruf= und stellt in diese Richtung um.
Wenn jetzt jemand mit WSTM-allgemein nach einer schon neu ausgestatteten Einbindung kommt, dann schreibt er das bedauerlicherweise zurück. Es gibt jedoch eine Drittelmillion umzustellender Artikel, und irgendwann ist das momentane Geruckel vergessen.
Nebenbei bemerkt beobachte ich zumindest meine eigenen Unterseiten; hier brauchst du mir kein Ping zu senden. Die meisten Leute beobachten Seiten, auf die sie einen Beitrag geschrieben hatten, noch eine Weile und brauchen auch kein Ping.
Mir hat User:Punkt64 in der Diskussion gleiches berichtet. Der Editor scheint den Parameter abruf in zugriff zu ändern, was nicht korrekt wäre. Gruß -- Ulanwp (Diskussion) 09:10, 3. Jul. 2019 (CEST)
Letzter Kommentar: vor 5 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
Ruf mal bitte diese Seite Sietas Typ 81 auf und schau mal ob da bei dir auch oben in der IB eine Leerzeile eingefügt wird direkt über dem Pipe auf das die nächste IB dort folgt. Bei mir zumindest wird bei jedem Aufruf eine weitere Leerzeile eingefügt.
{{Infobox Schiff
| Schiffskategorie = Handelsschiff
| Name = Sietas Typ 81
| Bild = Heinrich Behrmann stranded.jpg
| Bildtext = Die gestrandete ''Heinrich Behrmann''
|{{Infobox Schiffsklasse/Basis}}
}}
wird nach drei mal starten zu
{{Infobox Schiff
| Schiffskategorie = Handelsschiff
| Name = Sietas Typ 81
| Bild = Heinrich Behrmann stranded.jpg
| Bildtext = Die gestrandete ''Heinrich Behrmann''
|{{Infobox Schiffsklasse/Basis}}
}}
Ich sehe aber nicht weshalb und nur dort. Die anderen Boxen wären davon nicht betroffen und scheinbar auch andere Artikel nicht. Ich sehe es aber nicht. --Liebe Grüße, LómelindeDiskussion19:32, 4. Jul. 2019 (CEST)
Das kann ich nicht bestätigen, so etwas passiert bei mir da nicht. Also anders gesagt von klein auf groß ja, das ist die gewünschte Form, aber zurück nicht.
Bist du sicher, dass du da nicht eventuell irgendwo mit Kopieren und Einfügen gearbeitet hast? Bewusst habe ich so etwas jedenfalls noch nicht gesehen. --Liebe Grüße, LómelindeDiskussion10:56, 11. Aug. 2019 (CEST)
Moin Moin Chiananda, Lómelinde, ich kann es bei mir auch nachvollziehen, dass es von groß auf klein geändert wird. Kann es an dem "div" liegen? mfg --Crazy188011:24, 11. Aug. 2019 (CEST)
WSTM setzt Farbcodes einheitlich auf sechsstellige Großschreibung um, sofern dies angetroffen würde.
Im fraglichen Artikel steht ein clear: zu Beginn, das speziell behandelt wird und den Rest in Mitleidenschaft zieht (kleinschreibt).
Der Code, der sich mit dem clear: befasst, ist von 2012, der wo sich mit style= allgemein beschäftigt, ist von 2015, und die beiden wussten bisher nichts voneinander; der von 2012 hatte den von 2015 geschrumpft.
Danke für den Hinweis; Änderung ist auf dem Weg. Kann sich aber etwas hinziehen, weil umfangreiche Änderungen, die erstmal längerer Testphase bedürfen. Umgekehrt fiel das vier Jahre nicht auf; kann also nicht sehr häufig vorkommen, und richtet keinen Schaden an.
so ein merkwürdiges <div></div>? Ich dachte eben schon ich sei meschugge, weil ich so etwas möglicherweise selbst eingegeben habe, obwohl ich mir sicher war, dass ich das clear geschrieben hatte. Mir war gestern schon ein merkwürdiges Verhalten aufgefallen, als aus <div /> ebenfalls ein <div></div> wurde. Da ist doch irgendwo ein Würmchen drin oder ist das schon ein ausgewachsener Käfer? --Liebe Grüße, LómelindeDiskussion09:05, 22. Aug. 2019 (CEST)
Ist einer; kam vorgestern Abend rein.
Sollte sich bis heute Abend legen.
Ist ein ziemlich fieser; und lief über zwei Wochen durch meine interne Testphase, aber fiel mir irgendwie nie auf.
Momentan weiß ich noch nicht mal, wie ich das wieder losbekomme.
Danke es scheint jetzt wieder richtig[er] zu funktionieren. Einzig das selbstschließende <div /> ohne Attribute bleibt wie es ist und meldet keinen Fehler. Aber der sollte ja zumindest als Linterror erkannt und in die Wartungskategorie mit problemetischen Tags einsortiert werden. Ganz sauber ist es noch nicht.
Beispiel
<div "/> mit ein oder mehreren " wird zu <div "></div> inklusive roter Meldung Falsches Attribut-Format im Tag <div ".
Ein geschrumpftes div ist nach XML korrekt und kratzt WSTM erstmal nicht.
Wo sowas steht, sollte vielleicht mal was hinkommen und war nicht vollständig oder steht daneben oder was auch immer; weist auf einen früheren Fehler hin. WSTM ist das jetzt erstmal egal und weiß auch keinen verständlichen Text für eine Fehlermeldung.
O.k. soweit, so gut. Das <div /> war aber eine aktive Einfügung durch einen Benutzer der eigentlich </div> meinte, ich habe ihn dann angesprochen, weil er mehr als 20 Seiten in die Liste gespült hatte. Sonst wäre mir das ja gar nicht vor die Füße gefallen. Andererseits wandelt WSTM aber andere Tags in der Form in nowikis um und sagt auch da nichts dazu → <span /><b /><i /><big /> → <nowiki /> was auch nicht immer das Gelbe vom Ei ist, weil ich zumeist davon ausgehe, dass sich da jemand vertippt hat und wer ein <b/> schrieb wollte eventuell ein <br /> oder ein </b> und kein <nowiki />, obwohl auch das mitunter vorkommt. So genug genervt, betrachte es als erledigt. --Liebe Grüße, LómelindeDiskussion16:45, 23. Aug. 2019 (CEST)
[www]→[[wiki]]
Letzter Kommentar: vor 5 Jahren6 Kommentare2 Personen sind an der Diskussion beteiligt
Du hast offenkundig manuell ein limit=50& dazwischengequetscht, was du auch darfst.
Alle von der Wiki-Software generierten URL-Pfade beginnen mit ?title= oder ?oldid=.
Das hatte ich 2012 unterstellt; ist aber natürlich nicht haltbar.
Wegen der fast sieben Jahre ohne Beanstandungen habe ich die Dringlichkeit erstmal wieder runtergefahren und werde das sorgfältig an den aktuellen Stand der Technik anpassen.
Ja sorry, kann ich ja nicht wissen, aber offenkundig war das nun nicht, denn eigentlich habe ich nur einen Datumsbereich hinzugefügt und das setzt automatisch wohl auch das Limit, denn 50 ist eigentlich der Standard, zumindest bei mir. --Liebe Grüße, LómelindeDiskussion15:20, 4. Sep. 2019 (CEST)
Aha, dann warst nicht du das, sondern dieses Datumseingabeskript hat die URL in einer bisher ungebräuchlichen Reihenfolge umgebastelt.
Egal, es ist eine legitime URL, damit muss es flutschen, und WSTM wird demnächst jede Reihenfolge der Parameter verstehen.
Würde ich so sagen, denn bewusst habe ich das nicht eingefügt. Ich wollte nur, dass es nicht morgen Beiträge von morgen zeigt. Das wandert ja mit, aber ich vermute er ist eh bald durch. Noch rund 250 Zugriffe. --Liebe Grüße, LómelindeDiskussion17:03, 4. Sep. 2019 (CEST)
config.page.include?
Letzter Kommentar: vor 4 Jahren4 Kommentare3 Personen sind an der Diskussion beteiligt
Ganz grundsätzlich fehlt hier die Definition des Anwendungsobjekts, die allem anderen vorangehen muss.
Erst danach kann die bisherige Zuweisung der Option erfolgen.
Ansonsten gibt es auch eine Fehlermeldung in der Browser-Konsole, und das ganze common.js stürzt vermutlich ab.
Es ist noch nicht definiert, was mw.libs.WikiSyntaxTextMod.config.page sein soll; und da dies nicht vorher als Objekt definiert war, kann auch keine Komponente include davon durch eine Wertzuweisung gebildet werden.
Um mit einer privaten Variablen wstm arbeiten zu können, muss erstmal das Anwendungsobjekt existieren; danach lässt sich abkürzend definieren: varwstm=mw.libs.WikiSyntaxTextMod; und hinterher kann diese Abkürzung auch verwendet werden.
Letzter Kommentar: vor 4 Jahren4 Kommentare3 Personen sind an der Diskussion beteiligt
Moin Moin PerfektesChaos, im Artikel Hofheim ist aufgefallen, dass im Parameter Format mit WSTM magic passiert. Du kannst es aktuell nachprüfen. Aus |format=PDF; 9,0 MB wurde |format=PDF; 9; 0 MB . Das zweite Semikolon gehört da doch nicht hin. Ich nutze r.WSTM und es geht um die Vorlage Internetquelle. Magst du bitte mal schauen, ob das Verhalten bei dir ähnlich ist? Danke dir --Crazy188016:10, 13. Sep. 2019 (CEST)
Bei mir (d.) passiert das nicht, vorher |format=PDF; 9,0 MB nachher, nur an anderer Position in der Vorlage, unveränderter Inhalt |format=PDF; 9,0 MB. --Liebe Grüße, LómelindeDiskussion16:26, 13. Sep. 2019 (CEST)
Öh, ümpf, klingt ungesund.
Ich hatte da kürzlich mal was gemacht, kann mich an nichts mehr erinnern, werde aber die Formeln und Ausdrücke nochmals revidieren und auch d und r vergleichen.
Kann schon sein, dass irgendein RegExp da durcheinanderkommt.
formatiert wurde. Ich habe es jetzt nochmals auf der Spielwiese getestet und ja auch dort muss ich zweimal klicken, ehe es sich sortiert. Diese Version ist nicht wirklich sinnvoll (Inhalt url=archiv-url) kann es daran liegen? Auf der Spielwiese erhalte ich beim ersten Start diese Warnmeldungen.
Klicke ich dann erneut kommen zwar auch jede Menge Warnungen aber nichts mehr was WSTM heißt. Ich weiß daher auch nicht ob das wirklich wichtig ist, denn so etwas sollte ja eher selten vorkommen, oder? --Liebe Grüße, LómelindeDiskussion17:57, 16. Sep. 2019 (CEST)
WSTM nuschelt.
Spricht einen etwas schrägen Dialekt, der bei dir beanstandet wurde. Ist nicht so ganz sauber.
Es betrifft nur border. Ich teste mal schnell, ob nur solid und ob es nur bei div oder auch bei span passiert. Es passiert immer für alle border-Arten (dashed, dotted, double, groove, ridge, inset, outset und solid) und auch innerhalb der Tabellensyntax im Kopfbereich {| und hinter |- oder ! nicht jedoch hinter |+ oder |
Hab ich etwas vergessen? Ich denke ich habe alle Eventualitäten getestet. Es bleibt übrigens dann dauerhaft klein nicht so wie neulich als es wecchselnd groß/klein war. --Liebe Grüße, LómelindeDiskussion07:40, 29. Sep. 2019 (CEST)
+1: Hatte ich gestern auch: erst paar Mal hin und her, dann bleiben die Borderfarben stabil kleingeschrieben, aber <div style="background:#FEF6E7; margin-bottom:1em; border:1px solid #ffcc33;…>. Gruß --Chiananda (Diskussion) 14:51, 29. Sep. 2019 (CEST)
Öhhf, ja, danke für den Hinweis.
Die inzwischen aktive Kleinschreibung für solid, px und Farbnamen etc. war etwas übergriffig geworden.
In den nächsten Tagen werden die Hexcodes wieder Großbuchstaben erhalten.
Letzter Kommentar: vor 4 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
War mir gestern oder neulich auch schon aufgefallen, bin aber nicht dazu gekommen es hier anzusprechen.
{{Mehrspaltige Liste |liste=
‹Inhalt›
}}
wird
{{Mehrspaltige Liste |liste=
‹Inhalt›}}
Es wird bei jedem Aufruf eine weitere Leerzeile hinzugefügt. Ich schreibe mal noch ergänzend, dass es zunächst nicht passiert wenn da der unbenannte Parameter | steht dann wird nur dieses Pipe durch |liste= ersetzt (und eventuell die untere geschweifte Klammer eins nach oben gesetzt, wenn sie nicht schon dort ist), steht |liste= aber einmal dort, so versucht WSTM immer einen anschließenden Zeilenumbruch zu ergänzen.
Magst du mal schauen, ich weiß leider nicht, wie man danach suchen könnte, um zu sehen, wie oft das schon unbemerkt passiert sein könnte, ich versuche immer die Leerzeile[n] wieder zu löschen, aber das wird ja eventuell nicht nur bei mir passieren. Such dir einfach →irgendeine zum Testen aus. --Liebe Grüße, LómelindeDiskussion11:43, 12. Okt. 2019 (CEST)
Ja, bedauerlich, in der Programmierung bereits korrigiert, baldmöglichst online.
WSTM soll das gesamte Innenleben dieses Parameters trimmen, also allen whitespace davor und dahinter wegmachen, und es anschließend zwischen Zeilenumbrüchen zurückschreiben.
Beim Trimmen blieben bislang die schon vorhandenen Zeilenumbrüche noch stehen, dadurch wurden es mehr.
Letzter Kommentar: vor 4 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Würdest du bitte erst die Verschiebung (oder was auch immer da geplant war) durchführen ehe WSTM mir da etliche Einbindungen durch Umschreibung zerlegt.
Ich habe es nur bemerkt, weil ich zufällig in der Vorschau (denn er waren mehrere Einbindungen) in den Einzelnachweisen diese roten Vorlage:Röll-1912 stehen hatte. Aufgefallen hier Wiener Stadtbahn (6 Einbindungen). Insgesamt sind zwar wohl nur etwas mehr als 100 Artikel mit Einbindungen aber, … ich möchte da keinen Ärger bekommen, wenn ich es übersehen sollte. Oder anders, ich habe mal in deiner js nachgeschaut, du hast das wohl eigentlich als perspektivische WL {{Roell-1912}} angelegt, dann sollte WSTM nicht ö schreiben oder du die Seite umbenennen, bzw noch eine WL anlagen?.
Weil ich nun etwas erstaunt war, denn Schnaks Tool sagt mir ja farblich immer was was ist, sah ich nun folgendes
{{{SORTIERUNG:Drent, Ido}} normal wäre optisch hellgelb {{SORTIERUNG:Drent, Ido}} dunkel steht für Vorlagenparameter
Erst dadurch ist mir das aufgefallen, dass WSTM da eine Klammer in die Lücke gesetzt hat. Also denke ich liegt das jetzt daran, dass es doppelt war oder an dem Leerzeichen generell. So habe ich es auf der Spielwiese nochmals ausprobiert und siehe da jedes mal wenn da ein unerwartetes Leerzeichen zwischen den vorderen Klammern und dem Inhalt steht, kommt eine Klammer hinzu. Um es noch deutlicher zu sagen, wären es zwei Leerzeichen dann würde daraus {{{{SORTIERUNG:Drent, Ido}} bei drei Leerzeichen, frag mich nicht, weshalb ich so etwas teste, {{ {{SORTIERUNG:Drent, Ido}} …. Auch wenn diese Fälle vermutlich extrem selten auftauchen, wollte ich es doch lieber ansprechen.
Ähm und da ich gerade am Testen war dachte ich liegt es an der SORTIERUNG oder passiert so etwas auch anderswo und ich hätte es lieber nicht tun sollen.
Mehr teste ich jetzt lieber nicht. Das ist sehr befremdlich. Und war vermutlich auch die Stecknadel im Heuhaufen. Aber vielleicht magst du es dir ja mal anschauen, auch wenn es ein Einzelfall war. --Liebe Grüße, LómelindeDiskussion11:21, 26. Okt. 2019 (CEST)
Seufz, ist ein schwerer und akut behandlungsbedürftiger Bug.
Das Wochenende ist gerettet. Hätte ja nicht gewusst, was ich zuerst machen soll.
Also nur weil ich zufällig noch mal geschaut habe was jemend nach meinem Edit geändert hat, oft sind es ja Schreibfehler. Hier aber war es nicht bewusst durch mich eingefügt und ich hatte es im Diff schlichtweg übersehen. --Liebe Grüße, LómelindeDiskussion09:51, 14. Nov. 2019 (CET)
Ei wei – seltsam, danke für den Hinweis.
Den Bug gibt es, und ich habe ihn bereits repariert.
Er ist spezifisch für die PD und seit Februar 2018 oder seit 2017 oder seit noch früher entstanden, wenn der Tag im Monat fehlen würde.
Erstaunlich ist, dass dies erst jetzt auffällt; die Situation ist nicht so ungewöhnlich, und dies hätte schon vor Jahren mal beanstandet werden müssen (die PDler bekommen das ja wohl mit, und müsste Vorlagen-Wartungskat schmeißen) und ich beobachte von mir geänderte Seiten auch noch einige Zeit.
Nachtrag zu Digitales Wörterbuch – In der Zielseite steht noch name= – das ist vor-1998 für id= und noch auf längere Zeit kompatibel. Kann aber eigentlich nur jemand wissen, der 1995 mit seiner eigenen Homepage unter HTML.2 online war.
Ach so, nein ich wäre nicht einmal auf die Idee gekommen mir den HTML-colde der Zielseiten anzuschauen. Du überschätzt manchmal meine Fähigkeiten. --Liebe Grüße, LómelindeDiskussion16:01, 14. Nov. 2019 (CET)
Gallerie in Tabelle
Letzter Kommentar: vor 4 Jahren5 Kommentare2 Personen sind an der Diskussion beteiligt
Kannst du mal bitte eben kurz diese Seite Hermann Lang (Bildhauer)#Werke ansehen, den Abschnitt öffnen und mir sagen was da passiert? Bei mir wird nämlich die Tabelle zerschossen. Ich werde die eh rauswerfen, weil das, meiner Meinung nach, ein Missbrauch der Galeriefunktion ist aber … gut scheint mir das nicht zu sein. --Liebe Grüße, LómelindeDiskussion15:43, 16. Nov. 2019 (CET)
Ich werde da gar nichts öffnen, weil ich mir vorstellen kann, was passiert.
Galerien haben nichts in Tabellen zu suchen, sie sollen über die Fensterbreite eine dynamische Anordnung bewirken.
Sofern die Galerie sich sauber frei von den Pipe-Symbolen der Tabelle hält, tut WSTM ihr auch nichts. WSTM sieht die Galerien jedoch als Block-Elemente auf Ebene der Gesamtseite an, und da dürfen weder davor noch danach Pipe-Symbole in derselben Zeile stehen.
Hier sind es ohnehin Einzelbilder, und eine Einzelbild-Galerie ist gleichbedeutend mit mini.
Letzter Kommentar: vor 4 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
Was habe ich jetzt wieder falsch gemacht?
{{Internetquelle |url=http://www.smb-digital.de/eMuseumPlus?service=ExternalInterface&module=collection&objectId=963470 |hrsg=SMB-digital |titel= Das Balkonzimmer |datum= |kommentar=Internetseite der Berliner Nationalgalerie mit ausführlicher Beschreibung |offline= |abruf=2019-11-20}}
wird
{{Internetquelle |url=http://www.smb-digital.de/eMuseumPlus?service=ExternalInterface&module=collection&objectId=963470 |titel=Das Balkonzimmer |hrsg=SMB-digital |datum= |abruf= |kommentar=Internetseite der Berliner Nationalgalerie mit ausführlicher Beschreibung}}
und ich werde angemeckert Vorlagenparameter fehlt {{Internetquelle|abruf=}}. Ich sehe es nicht. Es passiert scheinbar nur, wenn offline vor abruf steht, aber das hat mir Citoid so zusammengestellt. Aporops was mich schon länger etwas stört ist auch diese Pipe-Anhäufung.
Und wie man sehen kann fehlt da kein abruf. Aber als ich den Artikel eben noch mal öffnete kam dieser Murks mit dem Schwund. --Liebe Grüße, LómelindeDiskussion18:29, 21. Nov. 2019 (CET)
Letzter Kommentar: vor 4 Jahren8 Kommentare2 Personen sind an der Diskussion beteiligt
Moin Moin PerfektesChaos, ich habe in letzter Zeit vieles gemacht und habe ein paar Fragen/Wünsche/Anregungen. Ich brauche keine Adhoc-Antwort. Gerne auch wieder in Spiegelstrichen oder Aufzählungspunkten antworten ;)
Anregung nach Botläufen für die Vorlage Literatur, denn ich denke die Zeit könnte dafür gekommen sein. Die Anfrage könnte ich vorbereiten und stellen, wenn du magst. Die gröbsten Fehler und Probleme sind, meiner Meinung rausgearbeitet:
|arxiv= zu |arXiv= machen
|Zugriff= zu |Abruf= machen
|Herausgeber= zu |Hrsg= machen
|Tag= |Monat= |Jahr= zu |Datum= machen
Liegt auf Beta nicht noch eine "Verschärfung" von |Autor= xxxyyyzzz (Hg.) für die Vorlage Literatur? Ich hatte da kurz geschaut und einige Fälle durchgespielt, welche ich positiv zurückmelden kann.
Positive Rückmeldung auch noch zu Wurgl seinem Tool für die Vorlagen, da habe ich auch noch etliche Probleme mit der Vorlage Literatur finden können und bin dabei diese wegzuarbeiten.
Als Letztes bleibt wie immer zu sagen, wenn du Hilfe brauchst, lass es mich wissen. Hast du Themen, wo ich unterstützen soll?
PS.: Hast du eigentlich eine Liste, was du noch alles auf deiner Liste hast, also eine art Arbeitsliste? So, dass man mal schauen könnte, wo man unterstützen kann?
So’n Zufall, grad habe ich bei dir geschrieben, hat sich gekreuzt.
Danke erstmal für das Hilfsangebot.
Deine Tätigkeit bei Tag= bekomme ich mit, manchmal warst du einen Tag vor mir schon dran gewesen.
Bot-Läufe möchte ich grundsätzlich keine für diese Kosmetik, weil die Bots machen immer nur ein Detail was vorher funktionierte und hinterher auch. Das gibt nur Zoff mit den Hauptautoren und Beobachtern.
Das wird so nach und nach auf natürliche Weise aussterben, und wenn dann nur noch kleine Reste übrig sind dann gibt es mal gezielt den Gnadenstoß für irgendwas.
Rein zufällige Besuche auf bestimmten Seiten führen meist zum allgemeinen Durchputzen mit WSTM, machen also mehr als nur eine winzige Bot-Kleinigkeit, und vielleicht auch manuelle sichtbare Änderungen in Stil und Formalkram.
prettytable soll im ANR und den meisten Namensräumen unwirksam werden, sobald diese bereinigt sind. Werden einige Uraltler motzen.
Vorlagenparameter werden in Fehler gewandelt, sobald aus dem Bestand verschwunden, bis dahin migrieren sie still und leise, heißt geräuschlos.
Es dauert seine Jahrzehnte, bis Leutchen, die schon seit 2005 irgendwo „Zugriff“ direkt in den Artikel oder als Vorlagenparameter schreiben, sich an was Neues gewöhnt haben. Weil sie seit 2005 geistig kaum mobiler wurden, wird das in ihrer aktiven WP-Zeit oft auch nicht mehr umswitchen. Die Jungschen, die ab etwa 2010 kamen, kennen es dann nicht mehr anders als „abgerufen“ und schreiben das dann auch so in den Quelltext. Für die hatte ich vor einigen Wochen den Vorlagenparameter Abruf= großflächig lanciert, damit das olle Z-Wort allmählich nicht mehr zu sehen sein wird. Bei der Lit ist das aus gleichem Grund schon seit 2016 so. 98 % der Weblinks verwenden „abgerufen“, 1 % „Zugriff“ oder „zugegriffen“ und 1 % ein bis zwei Dutzend sonstiger Vokabeln. Wobei jemand, der das 2008 in den Quelltext schrieb noch nicht wissen konnte, denn damals hatte sich noch kein festes Vokabular herausgebildet.
ToDo-Liste habe ich, stehen Hunderte von Punkten drauf, aber das ist niemandem zu vermitteln und setzt meist Programmierungskram voraus.
Du mach einfach bienenfleißig wie bisher immer weiter, passt schon. Nie zu viel an einem Punkt, weil sonst ein „Hauptautor“ motzt, wenn er an einem Tag 50 Änderungen auf der Beo hat, sondern immer hübsch durcheinander jeder mal einen Edit und nach ein paar Tagen kommen wir wieder über dasselbe Thema. Es eilt nicht; es kommt nicht darauf an dass Programmierungen sich ändern, sondern dass in den Hirnen der Autoren oder der meisten Autoren sich allmählich was Neues durchsetzt, und das geht nicht mit der Änderung einer Programmzeile und einer Doku.
Es soll aus dem ANR verschwinden, außerdem (und das ist oder war bereits mal komplett abgeschlossen) aus zentral sichtbaren aktiven Projektseiten, Hilfeseiten (außer ggf. zu prettytable selbst) und Vorlagen.
Von uns nicht angefasst werden alle Diskussionsplattformen und Diskussionsarchive.
Von den Zuständigen in Eigenregie müssen ggf. umgestellt werden: Benutzerseiten, Portale, Wikiprojekte.
Die erste Maßnahme wäre, dass im ANR und auf Vorlagenseiten sowie Kategorien der Hintergrund knallgelb, die Linien dick rot eingefärbt werden, um vor Wiedereinbau abzuschrecken. Das würde ich nach Bereinigung des ANR den zuständigen Admins empfehlen; danach wäre auch ein Artikel im Kurier erforderlich.
Danach sollten die Zuständigen ihre Seiten aufräumen.
Dass die Definition aus unserer jedem Leser auf jeder Seite reingedrückten Software physisch eliminiert würde, könnte 2025 werden. Aber um so weniger Seiten und um so randständigere Seiten sollen noch prettytable enthalten.
Nach einer Deaktivierung bleiben die Tabellen ja Tabellen, bloß ohne Linien und browserunabhängige Dekoration. Vielleicht entscheidet man sich irgendwann, per Bot und auch in schreibgeschützten Seiten die prettytable gegen wikitable auszutauschen, wobei jedoch Kopfzeilendesign verlorenginge. Das mag dann die Linien in archivierten Diskussionen und bei verstorbenen Benutzern retten.
Liegt auf Beta nicht noch eine "Verschärfung" von |Autor= xxxyyyzzz (Hg.) für die Vorlage Literatur? Ich hatte da kurz geschaut und einige Fälle durchgespielt, welche ich positiv zurückmelden kann. (Hierzuwiki haben wir 79 solcher Fälle, die arbeite ich jetzt ab.) PS.: Wird |Autor= xxxyyyzzz (Bearb. u. Hg.) soetwas auch erkannt und wo schreibe ich den Bearbeiter am Besten hin?
Jetzt auch über Wurgls Tool gesehen, gleiche Kärbe für Autor und Herausgeber |Autor= xxxyyyzzz [Hrsg.]. Also worauf man erstmal kommen muss ;)
Du hast eingangs schon einmal auf BETA-Erprobung Bezug genommen.
Auf BETA liegen MegaByte an nicht erprobtem noch nicht produktiv-reifen Codes.
Auf meiner Festplatte liegt noch sehr viel mehr.
Der fragliche Code ist in der häufigsten Variante als Modul:Vorlage:Literatur ab Zeile 291 hier aktiv.
Ich kann zukünftig weitere Schreibweisen und Formate einbauen; aber (Bearb. u. Hg.) hat eine abweichende inhaltliche Bedeutung und wäre außerdem legitim für einen Autor= in Doppelrolle; der Dienstgrad „Bearbeiter“ als weniger wichtiger auch irgendwie „Autor“ ist im Datenmodell der Vorlage nicht abgebildet und steht auch nicht in den ZR.
Generell werde ich nicht jeder Formatierungsidee hinterherrennen können, auf die irgendein Bearbeiter dann auch noch käme.
LG --PerfektesChaos15:19, 16. Nov. 2019 (CET)
Moin Moin PerfektesChaos,
ich weis ja, dass man nicht alles abfangen kann, aber schau dir das mal an: Kammermusik von Anton Bruckner|Autor= xxxyyyzzz (Herausgeber) Sind auch nur 350, wo das so ist, bin da schon dran. ;)
Guten Wochenstart dann. Mal sehen, was in den Parametern der Vorlage Literatur noch so alles nicht stimmig ist.
Moin Moin PerfektesChaos, und ich nochmal ;) Laut Wurgl seinem Tool gibt es die Vorlage Literatur nun über 600.000 mal eingebunden. Läuft also. mfg --Crazy188019:17, 4. Dez. 2019 (CET)
Verklammert
Letzter Kommentar: vor 4 Jahren10 Kommentare3 Personen sind an der Diskussion beteiligt
Schaust du bitte mal da Karl Menser rein? Im Parameter Autor steht da so ein Murks (will sagen unmaskierte Klammern)
J[ohann] J[oseph] Brungs: Die Stadt Honnef und ihre Geschichte. Verlag des St. Sebastianus-Schützenvereins, Honnef 1925, S.264 (Neudruck 1978 durch Löwenburg-Verlag, Bad Honnef).
Was aber daraus wird ist, nun ja, eher unschön
{{Literatur |Autor=[[Johann Joseph Brungs |Titel=Die Stadt Honnef und ihre Geschichte |Verlag=Verlag des St. Sebastianus-Schützenvereins |Ort=Honnef |Datum=1925 |ISBN= |Seiten=264 |Kommentar=Neudruck 1978 durch Löwenburg-Verlag, Bad Honnef |1=J[ohann] J[oseph] Brungs]]}}
Wenn du mir sagst, wie man das in der Suche herausfilten kann, dann kann ich auch sagen, ob es das häufiger gibt. Ich teste mal kurz noch, ob das auch beim Herausgeber passieren würde. Ja, das Selbe in kracks. Scheinbar ist es egal, wo jemand solchen Schrunz einfügen würde. --Liebe Grüße, LómelindeDiskussion13:10, 11. Dez. 2019 (CET)
Das muss ich aber bis nächstes Jahr im Probebetrieb bei mir laufen lassen; so dringend wird es nach sieben Jahren nicht sein.
Die Wikilinks können einstweilen so bleiben. Die Syntax ist etwas tückisch aber legal.
WSTM hätte erkennen sollen, dass da eine Pipe innerhalb eines Wikilinks steht, wurde aber von den Klammern irritiert und hielt sie für einen Schreibfehler und da fehle eine und kam danach völlig durcheinander.
Trotzdem sollten solche irritierenden Konstrukte vermieden werden, sofern inhaltlich möglich. Bei dem ergänzten Namen war es aber okay, weil keine eckige Klammer am Ende des Namens stand, die wäre sonst konsumiert worden.
O.k. alles klar. Soweit ich weiß ist „noplayer“ wirkungslos (war bei Audio meine ich), „disablecontrols“ (da könnte Raymond mehr wissen, siehe Hilfe:Video →hier eingefügt). Ich weiß nur, dass ich mal irgendwann über ein minitime gestolpert bin.
Wenn WSTM mich anmeckert, da wäre etwas falsch und ich dann nicht weiß weshalb, oder wie ich das anstellen soll, wenn doch alles funktioniert, dann verwirrt das. --Liebe Grüße, LómelindeDiskussion14:09, 13. Dez. 2019 (CET)
„disablecontrols“ habe ich 2013 lediglich dokumentiert; an der Programmierung war ich nicht beteiligt. 2016 wurde in Task 135537 vorgeschlagen, den Parameter zu entfernen, effektiv passiert ist seither aber nichts. Also ist der Paramter immer noch gültig. — RaymondDisk.15:09, 13. Dez. 2019 (CET)
Alle genannten Parameternamen sind „gültig“ in dem Sinne, dass sie erkannt werden. Wären sie das nicht, würden sie als Bildlegende angesehen werden.
Die noplayer etc. werden, wenn sie angetroffen würden, von WSTM dezent eliminiert. Sind funktionslos aber gültig.
disablecontrols ist halt da, WSTM ignoriert Wert und Existenz. Wenn irgendwann offiziell funktionslos würde ebenfalls eliminiert werden.
Auch dann, wenn es schon auf Abstand steht, immer eins weiter nach rechts. Das ist nur eine Info (OT: das mit den Ankern macht mir etwas Kummer, ich mag die teilweise betroffenen Vorlagen nicht anfassen). --Liebe Grüße, LómelindeDiskussion17:07, 25. Dez. 2019 (CET)
Stöhn. Weiß nicht.
Wenn ich mich um irgendwelche „teilweise betroffenen Vorlagen“ kümmern soll, müsstest du auch explizit hinschreiben, welche das sind. Gut ein halbes Dutzend habe ich dementsprechend schon umgebaut, dass sie jetzt kein Markup in den Anker mehr einstreuen wie bisher; die URL mit lauter Klammern und Apostroph liest sich schrottig.
Dieses ausgebüxte Leerzeichen habe ich inzwischen auch eingefangen, und alles andere dort auch gleich. Ist mir trotzdem schleierhaft, wo das herkam und warum nur beim ersten Kommentar.
Zu den Ankern ist mir mittlerweile noch eine neue Syntax eingefallen, die in den nächsten Tagen live gehen wird: Minus 1, 2, 3 statt x1, x2, x3; gefällt mir aus verschiedenen Gründen besser und wird parallel und alternativ verstanden werden. Gibt dann leider schon einige Hundert mit x, die auch weiter unterstützt werden müssen; Pech.
Das Leerzeichen eingefangen, aber mir noch nicht übergeben? Zumindest ist es bei mir noch nicht weg. Dankeschön fürs Anpassen. Die Anfragen auf der Kategoriedisk hattest du gesehen? --Liebe Grüße, LómelindeDiskussion06:49, 27. Dez. 2019 (CET)
Kannst du ja gar nicht haben, wird ja grad erst zu Testzwecken bei mir gefunden, wird erst nächstes Jahr in den Online-Test gehen. Erstmal muss ich selber mit rumspielen und Kollateralschäden abwarten.
Kat-Disk habe ich gesehen, fühle mich aber nicht angesprochen.
ThB ist ja auch schon unter die 1000 gerutscht; wenn du was auf dem Kieker hast, bist du ja zäh.
timedmedia_thumbtime stehen weiter oben auf dieser Seite; aus deren Behandlung stammt das, aber die Aktion ging wohl irgendwie in die falsche Richtung. Es sind abstrakte Namen, die in der Programmierung, aber nicht im Wikitext auftauchen.
Letzter Kommentar: vor 4 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
{{Normdaten }} ???
wurde zerbrochen zu
{{Normdaten}}
|TYP=|GND=}} ???
Frag mich nicht, wer so etwas tun könnte. Das passiert übrigens nur wenn dort Leerzeichen stehen Normdaten , das ist jetzt nichts dringendes, war wohl eher eine vergessene Ergänzung bei der Neuanlage. --Liebe Grüße, LómelindeDiskussion12:06, 30. Dez. 2019 (CET)
In WSTM ist das ein Bug, den es schon seit 2012/14 geben müsste.
Macht sich allerdings erst bemerkbar, wenn wie in diesem Fall drei oder vier spezielle Umstände zusammentreffen.
Fix erst nächstes Jahr, Auslieferung nach Beobachtung.
Frohes Neues; Fix ist inzwischen programmiert, aber muss noch gut zwei Wochen bei mir in Quarantäne laufen, bevor ich dies online schalte. LG --PerfektesChaos12:28, 2. Jan. 2020 (CET)
Das wünsche ich dir auch. :-) es ist eh etwas, was so kaum vorkommen wird, wie immer war es Zufall, dass es gerade bei mir gelandet war. --Liebe Grüße, LómelindeDiskussion12:49, 2. Jan. 2020 (CET)
Delimiter
Letzter Kommentar: vor 4 Jahren5 Kommentare3 Personen sind an der Diskussion beteiligt
Da mich WSTM eben in dem Artikel Dora 2020 wegen des fehlenden " angemahnt hat und da auch die kleinen ' drum setzte, was völlig ok ist, wundere ich mich aber nun gerade über den nächsten Artikel den ich geöffnet habe. Die Ausgangslage ist ähnlich aber das Ergebnis ist WSTM fügt etwas ein und schweigt. Ich zeige es mal
Das Problem dabei ist, dass die unpaarigen Dingense dazu führen, dass die Klasse nicht mehr erkannt und die Tabelle ohne Ränder ausgegeben wird. Und das sollte nicht sein. Da aber bin ich drüber gefallen, es kam (da wo keine ="???" stehen) keine Meldung und mir kam das Layout dann doch merkwürdig vor, so dass ich den Diff dann doch noch mal etwas genauer angesehen habe. →World Darts Federation, ich lass den noch mal offen. Eigentlich war aber das vergessene </div> →hier (ich teste mal MU) der Grund. --Liebe Grüße, LómelindeDiskussion13:48, 4. Jan. 2020 (CET)
Du bist intelligenter als WSTM.
Für WSTM stellt sich die Welt wie folgt dar:
Fall – ein Wort: class=Komischer-Wert
Weil bisher keine paarweisen Delimiter, werden die drumrumgeschrieben; weil schon " innendrin dann halt ' um alles.
Fall – zwei Ausdrücke: class=Komischer-Wert NeuesWort
Könnte gemäß hier ein Boolesches Attribut sein, aber unwahrscheinlich weil nicht in Tabellen-HTML vorkommend.
Könnte das Gleichheitszeichen fehlen, und der Wert hintendran auch; oder es fehlt ein Gleichheitszeichen inmitten von Neues=Wort.
WSTM weiß nicht, was das alles bedeuten soll, aber durch die Einfügungen schlägt es im Diff auf und kann falls abgespeichert hinterher systematisch mit Cirrus wieder aufgearbeitet werden.
WSTM ist es egal, ob in Attributwerten sonstwas für Zeichen vorkämen. In späteren Durchgängen könnte sich vielleicht mal über Anführungszeichen im Wert von class= mokiert werden, aber bei style= wären die okay.
Bist du dir da so sicher, dass ich intelligenter bin? Na, ich werde es mal anpassen, wollte es aber lieber ansprechen. --Liebe Grüße, LómelindeDiskussion15:32, 4. Jan. 2020 (CET)
Da mir das mit class='"wikitable' u.ä. auch schon untergekommen ist: Ich brauchte einige Zeit, um das Problem herauszufinden (vergessenes ") – könnte WSTM vielleicht dazu eine Fehlermeldung ausgeben? Klar, wenn man es einmal verstanden hat, ist die ungewöhnliche Zeichenfolge eindeutig interpretierbar, aber im Quellcodesalat nicht direkt ersichtlich… Gruß --Chiananda (Diskussion) 16:53, 10. Jan. 2020 (CET)
Die Fehlermeldung besteht hier in der Diffpage, die sehr viel deutlicher das Problem aufzeigt als eine Fehlermeldung dies könnte.
Eine Fehlermeldung würde nur lauten: Mutmaßlicher Syntaxfehler in der Attributzuweisung – ja, und dann?
Für WSTM ist es im Unterschied zu sehenden Menschen nicht zu erraten, was mit dem konfusen kaputten Syntax-Gestammel eigentlich beabsichtigt wurde; wo da was fehlt oder überflküssig wäre und wie was gemeint war und wie das repariert werden könnte weiß WSTM nicht. Es können Gleichheitszeichen fehlen oder Anführungszeichen oder Leerzeichen zu viel sein oder was auch immer. Die Absichten zu raten ist WSTM nicht möglich.
Mir gefallen die Pfeilchen besser als die Vorlagen {{Gestiegen}}▲▼{{Gefallen}} (gut finde ich aber {{Unverändert}}▬), die erlauben auch keine Klicks, weil keine Grafik (▲ ▼).
(69×) Bildparameter nicht erkennbar
verweis= (Datei:Green Arrow Up.svg)
(221×) Bildparameter nicht erkennbar
verweis= (Datei:Red Arrow Down.svg)
Ich könnte die Fehlermeldung vermeiden durch den Code verweis=:, weiß aber nicht, ob das problemfrei ist. Auch könnte ich eine neue Vorlage erstellen, die die Grafiken einbaut, oder die obigen Vorlagen erweitern mit einem Grafik-Parameter. Deshalb hier meine Frage zum empfehlenswerten Vorgehen, das viele meiner (geplanten) umfangreichen Tabellen betrifft… Gruß --Chiananda (Diskussion) 16:13, 10. Jan. 2020 (CET)
Mir gefällt nicht, wenn die Formulierung auftaucht „Mir gefallen die Pfeilchen besser“ und dafür eine projektweit einheitliche Formatierung ersetzt wird durch ein privates Design in unseren Artikeln.
Die vorgesehene Syntax lautet {{Gestiegen}} und ist damit extrem viel kürzer und übersichtlicher als [[Datei:Green Arrow Up.svg|8px|verweis=|gestiegen]]. Das in 69 + 221 Fällen ist eine Belästigung aller anderer Autoren, die an diesem Artikel arbeiten. Seltsam, dann gleichzeitig Quellcodesalat ins Spiel zu bringen.
Die Vorlagen werden in Kürze barrierefrei sein, was sagen will, dass sie besonders auf die Belange nicht-sehender Nutzer der Wikipedia eingehen und sie nicht durch überflüssiges Zeugs verwirren.
Die von den Vorlagen verwendeten schlichten Symbole sind die in dieser Situation allgemein üblichen. Das von dir persönlich bevorzugte Design ist ungebräuchlich und bietet keinerlei Mehrwert, lenkt eher vom Wesentlichen ab.
WSTM duldet (seit 2012) im ANR keine Unterdrückung der Verweisziele. Dies ist heute die allererste Beschwerde dieser Art nach acht Jahren. Heißt: In unserem ANR wird sowas auch nicht gemacht, auch nicht rumgetrickst und gehackt.
Okay, habe ich im WSTM-Quelltext synchronisiert. Kann aber noch einige Wochen dauern, bis das auch für dich live wird. WSTM war noch nicht der Vorlagen-Doku hinterhergekommen, oder ich wusste beim Vereinheitlichen der Vorlagen-Doku nicht, dass WSTM diese wie 100 andere Vorlagen auch anfasst. VG --PerfektesChaos18:09, 30. Jan. 2020 (CET)
Ich habe mittlerweile eine neue Programmierung geschrieben, die doppelte Zuweisungen des gleichen Wertes still und leise schluckt; zumindest wenn bei der ersten Analyse bereits sichtbar.
Dem Code konnte ich entnehmen, dass es in diesem Fall aber zumindest eine Fehlermeldung bei wiederholtem gleichnamigen Attribut geben müsste.
Muss jetzt erstmal ein paar Wochen bei mir köcheln.
Ja das kann ich bestätigen, nur war ich mit dem Schnipsel auf der Spielwiese, weil ja WSTM bei mir nicht in allen Namensräumen laufen soll, und da habe ich nur das Bearbeitungsfenster im Blick gehabt und nicht nach oben geskrollt, es springt ja auch nicht automatisch zu der roten Kiste und meckert mich an. Da habe ich die Meldung nicht einmal registriert, es wäre ja etwas witzlos so etwas in der Vorschau betrachten zu wollen. Daher habe ich es jetzt extra noch mal getestet und ja Meldung steht dort. = CSS Property-Name wiederholt. --Liebe Grüße, LómelindeDiskussion17:19, 4. Feb. 2020 (CET)
IB-Pipes
Letzter Kommentar: vor 4 Jahren5 Kommentare2 Personen sind an der Diskussion beteiligt
Mir scheint es so, als hättest du da ein Format für IB angelegt. An sich sehr nett, aber mir ist gerade aufgefallen, dass die obere Pipe nicht mitgeht.
Inkonsequent ist dann auch, dass (hier Zeile 5) nur hinter dem = ein Leerzeichen angefügt wird, das sieht auch etwas unharmonisch aus. Ja ich weiß das hat auch etwas damit zu tun wie es vorher dort steht, aber wenn ich schon mäkele, dann richtig.
Und was ist, wenn die Doku explizit ein indent vorschreibt? →8 IBs schreiben wir da dann besser die Dokus um? Denn WSTM nimmt darauf keine Rücksicht.
Muss ich mir genauer angucken, danke für den Hinweis.
Perspektivisch ist mein Plan, zumindest ganz links die Stellung des Pipe-Symbols und die Leerzeichen davor und danach projektweit zu vereinheitlichen.
Und zwar kompakt, so kurz wie möglich, ohne irgendwas.
Es gibt keinen Grund, warum das bei einer Flugzeug-Infobox anders aussehen solle als bei einer Tennisspieler-Infobox. Mit der Position der Gleichheitszeichen können die jeweiligen Geschmacksenthusiasten sich noch genügend individuell austoben.
Nach dem Gleichheitszeichen soll einheitlich genau ein Leerzeichen stehen.
Das Leerzeichen-Gefummel am Zeilenanfang hilft nicht weiter zur Erkenntnis, kostet nur Zeilenlänge und macht nichts lesbarer. Eine Infobox steht in aller Regel praktisch zuallererst im Artikel (+BKS), und es ist völlig klar wo sie anfängt und wo sie aufhört.
Bei anderen blockweisen Vorlagen ist es anders; Zitat und unten Lit sind was anderes, die stehen mittendrin, fangen irgendwo an und hören irgendwo auf. Da müssen Anfang und Ende deutlicher sichtbar werden; deshalb Einrückung der Pipes um ein Leerzeichen.
Wenn das sowieso nur 8 IB sind, und 1000 andere einheitlich linksbündig sind, dann ist ohnehin kein Sinn in solchen wohl eher zufälligen Extratouren zu sehen. Die sind ja noch nicht mal in ihrem eigenen Themenbereich konsequent, aus jedem Dorf ein Hund.
Im ersten Anlauf will ich erstmal die Pipes ganz links haben; halbes Jahr oder so mal gucken; danach ggf. ein Leerzeichen auf der anderen Seite der Pipe weg.
Ich habe dafür im Gegenzug die „indents“ verbannt, war sowieso meist ich, als Abgleich mit der Kopiervorlage. Dann wünsche ich dir noch einen schönen Abend. --Liebe Grüße, LómelindeDiskussion18:53, 13. Feb. 2020 (CET)
mp3 ?
Letzter Kommentar: vor 4 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Schlichtweg unbekannt; war im Wiki früher nicht möglich, als die fragliche WSTM-Positivliste hinterlegt wurde, jetzt offenkundig schon; nunmehr nachgetragen, wird irgendwann bekannt. Danke für den Hinweis --PerfektesChaos12:13, 14. Feb. 2020 (CET)
Internetquelle-Doku sortiert "abruf" nicht ans Ende
Letzter Kommentar: vor 4 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
In letzter Zeit sortiert der WSTM den Parameter "abruf=" ans Ende der Parameterliste der {{Internetquelle}} – im Unterschied zur dortigen Doku. Das führt dann zu einer Re-Sortierung und evtl. weiterem Hin-und-Her (Beispiel: WSTM, Ulanwp). Ist es nicht die Absicht von WSTM, die Parameter-Sortierung an den VE anzupassen?
WSTM hat eine Glaskugel und sortiert vorsorglich den Bestand schon mal so, wie das zukünftig zu erwarten sein wird.
Ulanwp verwendet meiner Kenntnis nach zumindest zeitweise auch WSTM. WSTM ist aber auch in zwei verschiedenen Versionen unterwegs, einer Erprobungsversion und einer älteren aber gereiften ausgetesteten Version. Eine dritte ist tagesfrisch meine persönliche Entwicklerversion. Mag sein, dass die sich irgendwie unterscheiden.
Sich hinzustellen und manuell in einer vorhandenen Einbindung die Reihenfolge zweier benannter Parameter zu vertauschen ist ohnehin keine empfehlenswerte Lebensperspektive. Es ist wurscht. Wenn sich ein Parameter ganz am falschen Ende rumtreibt und Gefahr läuft, dass er völlig übersehen wird, mag man das ausnahmsweise mal grob in die richtige Reihenfolge bringen.
Letzter Kommentar: vor 4 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Moin Moin PerfektesChaos, sage mal, kann es sein, dass WSTM in der englischsprachigen Wikipedia anders läuft? Also, wenn ich einen Artikel prüfen lasse, dann baut es keine Leerzeichen in Überschriften ein, setzt teilweise Umbrüche nicht um, also all soetwas. Mache ich irgendwas falsch oder muss ich da noch irgendwas einstellen? mfg --Crazy188009:38, 24. Mär. 2020 (CET)
Moin,
WSTM muss auf geschmackliche Sitten eines Wiki spezifisch konfiguriert werden.
Standardmäßig gibt es nur harte, unstrittige, globale Syntax.
Leerzeichen um Gleichheitszeichen der Überschriften sind in dewiki absoluter Standard, in enwiki eher nicht und womöglich handelst du dir damit Ärger mit irgendwem ein, vielleicht auch nicht. Müsstest du dir privat arrangieren.
Genauso auch <br /> während enwiki eher konsequent auf <br> umbauen würde.
Es gibt zwei bis drei Dutzend derartiger projektspezifischer Anpassungen, von lokalen Vorlagen mal ganz abgesehen.
Wenn du grad hier bist: Du könntest gelegentlich und ganz langsam Stück für Stück Anker wegknabbern, mal so zwischendurch, je nach individueller Problematik.
Schaust du bitte mal ist der Artikel Challenger Plateau der auf Crazys Disk angesprochen wurde ich sollte den also lieber nicht bearbeiten, ich frage mich immer wozu man da in jeden Parameter diese Vorlage einfügen soll, wenn man doch über die Sprache anzeigen kann, dass es sich um englischsprachige Literatur handelt. ich muss das nicht verstehen, wobei für mich |Band={{lang|en|Volume 27 Issue 3}} (März/April) sowieso flasch wäre und es eigentlich |Band={{lang|en|Volume 27}} |Nummer={{lang|en|Issue 3}} (März/April) lauten müsste wenn man meint so etwas tun zu müssen, ich würde so eine Verschachtelei eh rauswerfen. Schaust du dir das bitte einmal an? --Liebe Grüße, LómelindeDiskussion11:13, 24. Mär. 2020 (CET)
Moin Moin Lómelinde, mich nervt diese Vorlage darin auch, vor allem, wenn sie überall verbaut ist. Aber das scheinen einige halt so zu machen. @PerfektesChaos: Ich wurde auch dreimal noch auf die Reihenfolge vom Parameter Sprache angesprochen, da dieser ja laut Doku an einer anderen Stelle steht. Sollte man da nochmal was machen oder so lassen? mfg --Crazy188012:08, 24. Mär. 2020 (CET)
(BK)
Keine Ahnung, aber am Schlagwort Zealandia und dem exzessiven Gebrauch sehe ich bereits, wer der verantwortliche Hauptautor wäre und empfehle, zur Schonung unserer Kräfte und Nerven hier nichts weiter zu unternehmen. Ich schaue also auch nichts weiter.
WSTM mag ein Problem haben mit Vorlagenparametern in denen ein Wikilink vorkommt in dessen Linkbeschriftung eine Vorlageneinbindung mit Parametern vorkommt. Da werden dann irgendwann die Pipes nicht mehr den richtigen Klammern zugeordnet; gab es aber in den letzten zehn Jahren nirgendwo sonst.
@Crazy1880: Deine Disk hatte ich mitgelesen, aber die Hälfte stimmt sowieso nicht (Hrsg. kommt nie vor Autor) und die andere Hälfte ist halbrichtig, denn die Vorlagendoku ist in Blöcke organisiert und die passen nicht haargenau zur momentanen ZR, während WSTM nach der Reihenfolge zu gehen versucht wie es nach ZR dargestellt wird und da kommt Sprache hinter ISBN aber die Vorlagendoku hat einen Block Details (mit Sprache=) und einen Block Schlüsselnummern (mit ISBN=) und weil die ISBN und nur diese in den ZR jedoch aus der Reihe tanzen und noch vor die Seitenzahl kommen lässt sich der Konflikt nicht auflösen und im Übrigen ist die Reihenfolge der Parameter im Quelltext letztlich wurscht und sollte nur einigermaßen einer Logik folgen, um die Parameter wiederzufinden und nicht doppelt hinzuschreiben.
Die Vorlagendoku und ZR lassen sich nicht in eine konsistente überall identische Reihenfolge bringen. Nix tun.
Letzter Kommentar: vor 4 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
Moin Moin PerfektesChaos, ich habe mal wieder etwas ausgegraben. Im Parameter Online der Vorlage Literatur wird OCLC einmal als URL, einmal mit Vorlage dargestellt. Allerdings wird beides Mal keine Wartungskategorie ausgelöst.
Ich werde die 280 Fälle davon mal wegarbeiten. Was meinst du, wäre das was für die Wartungskategorie? Gleiches habe ich auch schon für JSTOR und DOI gesehen:
Moin, Reform? Das hört sich nach viel Arbeit an. Was genau planst du denn? Also nur, damit man mal eine Idee bekommt. mfg --Crazy188021:00, 27. Mär. 2020 (CET)
Der Wert von ID würde strikte Syntaxregeln bekommen und könnte tendenziell jeden (gültigen) anderen Schlüsselnummer-Parameter ersetzen; damit würden auch mehrfache ISBN, mehrere DOI usw. möglich. Heißt: Leerzeichen-getrennte Auflistung von URI.
Letzter Kommentar: vor 4 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo, es geht um die Vorlage:Internetquelle: der Mod setzt den Parameter |offline=1 wenn eine Archiv-url gesetzt ist. Der Parameter führt zu folgender Textergänzung im dargestellten Text: "(Nicht mehr online verfügbar.)" - direkt hinter dem Link zur Archivversion. Ich halte das für unlogisch. Beispiel: Dune aufrufen und editieren, Einzelnachweis 4. --Scantasyundfiencefiction (Diskussion) 18:24, 13. Mai 2020 (CEST)
Das ist perspektivisch durchaus beabsichtigt, und wenn eine Archiv-URL definiert ist, dann darf das nach gängiger Logik dann und nur dann erfolgen, wenn die ursprüngliche Verlinkung nicht mehr erreichbar ist. Sowohl der Hinweis wie auch der explizite Schalter sind korrekt und volle Absicht. Archiv-URL „auf Vorrat“, solange die Seite des Betreibers noch erreichbar ist, sind unerlaubt und mit der Vorlage derzeit nicht möglich.
Ansonsten setzt WSTM nur den Schalter; mit der daraus resultierenden Darstellung hat WSTM ohnehin nichts zu tun und ist ebenfalls Sache der Vorlage.
Letzter Kommentar: vor 4 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
WSTM greift auch in meine Zusammenfassungszeile ein und entfernt dort (oft) das letzte Leerzeichen von /* Abschnittsname */ . Dadurch wird die Zusammenfassung als "kommentiert" angesehen und kann ohne Eintrag weggespreichert werden, also ohne Warnung. Das passiert mir ab und an und könnte mAn vermieden werden: Leider macht WSTM ja leider keine sonstigen Syntax-Prüfungen dort ;)
Bei der Gelegenheit: Warum wird (bei mir) zurzeit weder WST noch die anklickbare Sonderzeichen-Liste aktiviert? Ich fühl mich so nackt ;) Gruß --Chiananda (Diskussion) 20:05, 13. Mai 2020 (CEST)
Es gibt zwar eine zuschaltbare konfigurierbare Option, was mit der Zusammenfassungszeile zu machen, aber WSTM macht das nicht von sich aus.
Deine zweite Bemerkung ließe darauf schließen, dass du einen Bug in irgendeinem Skript hast.
Ja, danke. Dann weiß ich auch nicht, warum mir das einige Male passiert ist in letzter Zeit, nachdem ich vergessen hatte, die Z.zeile zu beschriften, aber trotzdem keine Warnung erhielt.
Letzter Kommentar: vor 4 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Ich staunte nicht schlecht als ich gerade, wegen center-Tags, eine Seite geöffnet habe. Da gibt es, meiner Meinung nach dicke fette hässliche schwarze Striche (5px). So gesehen wäre mir die Änderung optisch entgegengekommen, denn #0; ist wohl wirkungslos.
|- style="border-top:5px solid #000000;" wurde also zu
|- style="border-top:5px solid #0;" da schwarz ja Standard ist, habe ich nun auch den Rest entfernt
|- style="border-top:5px solid;"
Siehe auch diese Änderung 13. Mai (CC: Phzh nur zur Kenntnis)
Du kannst es ja mal bei den übrigen Staffeln (2, 3, 4, 6 oder 7) oder einem der anderen Vorkommen testen. Soweit ich sehe, passiert das nur bei #00 bis #000000. --Liebe Grüße, LómelindeDiskussion08:14, 15. Mai 2020 (CEST)
Danke für den Hinweis.
Ja, da ist der Mechanismus ausgetickt, der 007px in 7px wandeln soll und 00px in 0 schlicht und simpel.
Eine erste Lösung habe ich bereits programmiert, jedoch noch nicht intensiver getestet, weil ich sie mittlerweile durch eine robustere und intelligentere ablösen möchte. Die Suchvorkommen kann ich dann auch gleich zur Erprobung nutzen, danke schön.
Weil schwarz die Standardfarbe ist und es nur mit Nullen passiert und das wohl nicht sehr häufig geschah, wird es noch bis nach dem Wochenende und einigen kühleren Nächten Zeit haben.
Wobei die rowspan=22 der etwas frühen Morgenstunde geschuldet waren; und zu keinem durch Schlitzaugen wahrnehmbaren Fehler führten.
Letzter Kommentar: vor 4 Jahren4 Kommentare3 Personen sind an der Diskussion beteiligt
Ich hätte auch noch eine klitzekleine Frage, warum ändert WSTM jetzt immer meine Reihenfolge in der Syntax? Gemeint ist border: 1px solid #ABCDEF; zu border:#ABCDEF 1px solid; für mich ist es anders herum viel sinnvoller, also wie dick, welche Art und welche Farbe.
alle 3 Attributeohne Farbwert Randfarbe schwarzohne Dicke Standard medium ≈ 3pxohne Dicke und Farbwert
Mir fällt das auch als unangenehm auf und ich kann nichts Sinnvolles in dieser Neuerung erkennen, Algorithmus hin oder her. Warum sich nicht an die Konvention von SelfHTML halten?
Das führt nur zu total unnötigen Umstellungen im Quellcode, die immer wieder ablenken von den eigentlich bearbeiteten Inhalten. --Chiananda (Diskussion) 00:19, 3. Jul. 2020 (CEST)
Leerzeichen vor syte-Attributen?
Letzter Kommentar: vor 4 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Seit Neuestem fügt WSTM ein Leerzeichen ein bei "margin: -10px;" und sämtlichen anderen styles.
Das empfinde ich als unerwünscht und kann auch keinen Sinn darin erkennen. Ich möchte meine styles-Angaben nach Möglichkeit in Blöcken vor mir sehen:
"margin:-10px; text-align:center; font-size:95%;"
Aber es kommt schlimmer: Diff fügt im nächsten Durchgang ein weiteres Leerzeichen ein: "margin: -10px" (hier visualisiert mit ). Wenn ich die Passage jetzt bearbeite, ändert WSTM nix und lässt beide Leerzeichen unberührt.
Es gibt zwei Formate: komprimiert, wenn nur eine Zuweisung und insbesondere ohne Semikolon vorliegt; gegliedert, wenn es ein Semikolon und mehrere Zuweisungen gibt. Dabei fließt auch ein, welche Leerzeichen es schon bisher gegeben hatte, und wird ggf. entsprechend deren Vorhandensein stärker gegliedert, um die Lesbarkeit zu verbesseren und Programmierfehler zu vermeiden. Negative margins sind im Übrigen äußerst verdächtig, oft unerwünschte Hacks und sollten besonders deutlich erkennbar werden. VG --PerfektesChaos14:49, 6. Jul. 2020 (CEST)
Vorlage:J.League player zu Vorlage:J-League.or.jp umschreiben
Letzter Kommentar: vor 4 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Ich würde ungern gefragt werden, weshalb ich, wenn ich schon etwas umstelle, dies nur halbherzig und nicht konsequent täte. --Liebe Grüße, LómelindeDiskussion07:29, 9. Aug. 2020 (CEST)
Das ist Absicht und nicht anders möglich.
WSTM kann nur die zweifelsfreien Fälle automatisiert umstellen.
Die Tabellenzellen sind zu chaotisch formatiert, auch mit Kommentaren und veralteter Syntax, als dass hier sicher automatisiert angepasst werden kann.
Ich beobachte aber regelmäßig alle Seiten, in denen beide Vorlagen gleichzeiitig vorkommen, und greife bei passender Gelegenheit ein. Würde also nicht lange so bleiben.
Verschärft wird das noch durch die sehr häufigen Fälle, in denen diese Vorlagen zur Datumsformatierung außerhalb von Tabellensortierung missbraucht werden.
Anders als daen Großteil allmählich abzuschmelzen wird man diese Altlast nicht loswerden.
WSTM kann nicht wissen, dass das in Teilen der Tabelle so und in anderen Teilen anders auftritt.
Letzter Kommentar: vor 4 Jahren5 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo PerfektesChaos,
hatte ich das geträumt oder konnte das Tool das mal erkennen und berichtigen? Funktionierte z.B. hier nicht und musste ich zwei edits später selber machen.
Andere Frage, kann man das Tool irgendwie beim editieren abschalten ohne gleich die .js zu ändern? Manche Änderungen finde ich sehr subobtimal, zum Beispiel das Umsortieren oder Löschen von Vorlagenparametern die ich gerade ergänzen will (leere Sprache, z.B.). Vielen Dank, --Fano (Diskussion) 06:28, 11. Aug. 2020 (CEST)
Ich wüsste nicht; im Inline-Modus werden nur die <ref> und </ref> unmittelbar an deren Inhalt angeschlossen.
Das Werkzeug ist internationalisiert für beliebige Projekte geschrieben; typografische Regeln für die deutschsprachige Wikipedia gibt es aber nur wenige und das müsste dann eine sein und wäre mir nicht geläufig wo das hinterlegt sein solle.
„leere Sprache“ wurde gelöscht, gerade als du etwas eintragen wolltest
Tja, Pech gehabt.
Der Quellcode soll übersichtlich gemacht werden, und leere Sprachparameter blähen nur auf, müssen nicht inhaltlich fördernd ausgefüllt werden und würden meist ohnehin nur de enthalten – was für den Export eine gewisse Bedeutung hätte, aber dem momentanen Leser gar nicht angezeigt würde, weil Vorgabe.
Wenn dir das also jetzt gerade rausgelöscht wurde als du was Sinnvolles eintragen wolltest, kann das Werkzeug ja nicht hellsehen und müsste immer alle stehenlassen Und du kannst vermutlich auch nicht hellsehen und würdest vor der Bearbeitung auch noch nicht wissen können, dass das schon unausgefüllt im Quelltext stehen würde und du es in diesem Ausnahmefall mal gerettet haben könntest.
Vielen Dank! Ich merke gerade auch, ich war doppelt falsch. Leerzeichen vor <ref> werden gar nicht gelöscht wie ich dachte, also auch keine Inkonsistenz zu (überflüssigen) Leerzeichen zwischen Einzelnachweisen. (Wäre das was was du allgemein einbauen möchtest? Mir fällt zumindest spontan kein Fall ein wo vor dem <ref> ein Leerzeichen kommen sollte. Das selber zu programmieren reichen meine Kenntnisse zu regulären Ausdrücken wohl nicht (mehr). Mein naiver Ansatz wäre das hier, aber ich bin mir 99% sicher das kann gar nicht gehen kann, also probiere ich es erst gar nicht selber.
Der von dir in Aussicht genommene Quellcode sieht gut aus.
Es muss dabei allerdings sichergestellt werden, dass mw.libs.WikiSyntaxTextMod.config.mod zuvor existiert.
In das automatisch bei allen Benutzer ausgeführte Routineprogramm möchte ich es jedoch nicht aufnehmen, da dies auch in allen Projekten wirken würde und auf eine sichtbare Wirkung nach außen abzielt. WSTM ersetzt jedoch eher Syntaxkonstruktionen durch standardisierte gleicher bzw. mutmaßlich beabsichtigter Wirkung ohne Unterschied in der Darstellung.
Vielen Dank! Ich kopiere mir das mal auf meine Disk damit ich es wiederfinde falls Du es archivieren magst. Irgendwann werde ich das probieren, aber wann steht in den Sternen. Vielen Dank für Deine Hilfe, --Fano (Diskussion) 10:10, 15. Aug. 2020 (CEST)
Die Vorlage sagt aber, es solle genau so verwendet werden. <span style="{{MirrorH}}">abc</span> wird <span style="???:{{MirrorH}}">abc</span>
Was da steht, das verstehe ich aber nicht wirklich, ok inline-block kenne ich, aber darum geht es ja auch nicht. Die Anzahl der Einbindungen ist aber doch recht überschaubar Beispiele
Tja, WSTM erwartet keine Vorlageneinbindungen in einem style-Attribut.
Der Mist gehört integriert in Vorlage:Runen und nicht als kompliziertes Gedöns drumrum.
Alternativ Vorlage:Spiegelschrift|Text= basteln.
Magst du das eliminieren und dieses dusslige Vorlage:MirrorH dann komplett eliminieren? Wir schreiben Klartext-Attribute und nicht solche Mini-Abkürzungen von nix.
Könntest ja Vorlage:Spiegelschrift/style anlegen, die genau das produziert was in MirrorH steht, und das dann in Vorlage:Spiegelschrift sowie Vorlage:Runen inkorporieren; dann gibt es das bloß ein einziges Mal und kann mit seinen Browserversions-abhängigen Extras zentral gepflegt werden.
Ich bin auch zu müde zum denken warum fällt mir immer so etwas zu? Die Chance einen der 9 Artikel zu treffen, die diese Vorlage verwenden, ist doch fast wie 6 richtige im Lotto oder vom Blitz getroffen zu werden. Gute Nacht derweil. --Liebe Grüße, LómelindeDiskussion19:04, 13. Aug. 2020 (CEST)
Eigentlich frage ich mich gerade wozu da überhaupt ein Mirror drinsteht.
Letzter Kommentar: vor 4 Jahren7 Kommentare3 Personen sind an der Diskussion beteiligt
Moin PerfektesChaos!
Erstmal danke für das nützliche Tool. Soweit ich das sehe, wird bei den br-tags sofern nicht vorhanden ein „ /“angefügt. Ich wurde nun darauf angesprochen, dass dies den Wikipedia-Empfehlungen widerspricht. Da ich technisch nicht so bewandert bin, kannst du vielleicht etwas dazu sagen? Vielen Dank und Liebe Grüße --Ameisenigel (Diskussion) 16:30, 16. Aug. 2020 (CEST)
Das trifft nicht zu, bzw. galt wohl mal für vielleicht zwei Jahre von ca. 2011 bis 2013.
Die deutschsprachige Wikipedia formatiert seit 2004 im XML-Standard, in dem auch die MediaWiki-eigene Syntax definiert ist, und da gehört dieser Schrägstrich mit bei. Und das in ununterbrochener und unveränderter Tradition.
Nun ist unser Wiki-Quelltext eine lustige Mischung aus HTML- und MediaWiki-Syntax. Und in HTML5 wollte man aus industriepolitischen Gründen (Software-Konzerne) das XHTML, das auch XML wäre, nicht haben, und hat ein etwas seltsames eigenständiges Gemenge verzapft, das ca. 2010/2011 „offiziell“ wurde. Dort war dann der Schrägstrich nicht mehr Teil des Standards, was unsere Wiki-Seiten aber überhaupt nicht juckt, weil das nicht direkt an die Browser geliefert wird (die würden ob des Gewürges schön stöhnen), sondern von einem Werkzeug nachbereitet wird. Und das stellt dann schon Standardkonformität her, egal wie genau das im Artikel drinsteht.
Rund 98 % aller br in der deutschsprachigen Wikipedia tragen übrigens diesen Schrägstrich.
Das hat was damit zu tun, dass wir einheitlich in gleichen Situationen seit immer verwenden <references /> und <br /> – beides sind leere Elemente, während ein Tag ohne Schrägstrich <xyz> als ein öffnendes zu lesen wäre, dem zwingend noch ein schließendes </xyz> folgen muss.
Dein Edit war berechtigt, denn durch Entfernen des Pipe-Symbols wurde ein Darstellungsfehler beseitigt: | class="hintergrundfarbe7" |{{DatumZelle|
Geht noch schleckiger wie folgt: | {{DatumZelle|2012-02-14|class=hintergrundfarbe7}}
Hallo Perfektes Chaos, ich schätze deine Kompetenz und Arbeit hier sehr, aber ich muss dir in einigen Punkten widersprechen. Die Verwendung von <br> ist nicht so marginal wie du sagst, das Verhältnis in den Artikeln der de-WP ist <br> = 51.645 vs. <br/> = 31.754 vs. <br /> >300.000 (die Suche bricht hier irgendwann ab). Die letzte Diskussion, die ich gefunden habe - an der du übrigens auch beteiligt warst - war 2017 und nicht 2011 bis 2013. Und die Empfehlungen sind noch aktueller, sie wurden erst Anfang 2018 erstellt. Auch wenn die Verwendung von <br /> generell möglich ist, die Wikipedia-Empfehlungen sagen z. Z.: Eine Ersetzung von <br> zu <br /> ist ... gegen die Empfehlung, zumal sogar intern alle diese Tags (HTML5-konform) in <br> umgewandelt werden (welchen Sinn hat es also Speicherplatz zu verschwenden um zuvor <br> in <br /> umzuwandeln?) Wenn du der Meinung bist, dass die Verwendung von <br /> bevorzugt werden sollte, möchte ich dich bitten, dich für die Änderung der entsprechenden Empfehlungen einzusetzen. Denn, was mich als Autor von Artikeln extrem demotiviert, ist, wenn ich viel Zeit darauf verwende beim Erstellen von Texten perfekt die bestehende Vorgaben einzuhalten (inklusive: als Zeilenumbruch ist <br> zu verwenden) um dann zu sehen, wie durch ein Tool diese Arbeit völlig grundlos und ohne jeden Mehrwert einfach im Vorbeigehen verändert wird. Selbst wenn <br /> eine mögliche oder wie du meinst sogar die bevorzugte Version ist, gilt nach WP:KORRNicht erwünscht ist insbesondere das massenhafte Ersetzen zulässiger Wendungen durch eigene Präferenzen quer über den Artikelbestand. Und gerade daran solltest Du Dich bei der Programmierung von Tools eigentlich auch halten, oder? Zudem: Korrektoren sollten stets bedenken, dass allzu forsches Eingreifen und Beharren auf rein formalen Standpunkten einen inhaltlich produktiven Autor entmutigen und von weiterer, größerer Mitarbeit abhalten könnten. Und das ist ja nicht der Sinn der Sache. Danke. --Bert (Diskussion) 17:31, 19. Aug. 2020 (CEST)
Die Institutionen, die den ohnehin nicht rechtsverbindlichen Standard „HTML5“ festgelegt hatten, taten dies um 2010/2011 und fügten bereits 2013 schon wieder den Schrägstrich verschämt als Option wieder ein, weil sich diese Politik in der Realität nicht durchsetzen ließ.
Die deutschsprachigen Wikipedianer schreiben seit 2003/2004 einheitlich <br /> und haben das immer in allen an Autoren gerichteten Syntaxerklärungsseiten so gehandhabt und es gibt keinerlei Grund, die Autorenschaft irgendwie umzuschulen. Es gab nie einen, weil immer nach außen korrekte HTML-Syntax ausgeliefert wurde, und es gibt noch nicht einmal jetzt einen, weil <br /> eine standardkonforme HTML5-Notation ist.
Es ist völlig egal, was in unserem Wikitext stünde; es haben die gleiche Wirkung </ br /> und <BR> und <br /> und <br>.
Weil Autoren sonst Gefahr laufen, auch bei <references /> den Schrägstrich wegzulassen, weil du ihnen ja gerade aufschwatzen willst, den bräuchte man gar nicht, behandeln wir ausnahmslos alle selbstschließenden Elemente gleich; hingegen wäre es bei <small> ein öffnendes Tag, dem ein </small> folgen müsse, also wäre das bei <br> genauso zu machen. Damit die Autoren im Wikitext keine Unfälle bauen, behandeln wir ausnahmslos alle Elemente genau gleich. Nur eine Handvoll Nerds weiß irgendwas von HTML5 und was die jetzt im Moment bevorzugen, und in HTML6 kann das eines tages schon wieder ganz anders aussehen.
Tatsächlich wird die Notation von <br /> in die Millionen Seiten gehen; kein Wunder, dass deine Suche nicht zum Ende kam. Wie du aber selbst vorgerechnet hast, ist die Schreibung mit Schrägstrich die in der deutschsprachigen Wikipedia seit anderthalb Jahrzehnten gebräuchliche und es gibt nicht den allerallergeringsten Grund daran irgendetwas zu verändern.
Das Wikipedia:WikiProjekt HTML5 ist meines Wissens praktisch inaktiv, tritt zumindest schon seit Jahren nicht mit Aktivitäten und Aktivisten nach außen, und was die zwei, drei Hanseln da als Privatmeinung zur Veränderung der Projektstandards als „Empfehlung“ aufschreiben ist völlig gegenstandslos. Meiner Peilung nach ist dieses WikiProjekt schon seit 2014 quasi tot.
Umseitig kannst du in einem grünen Kasten den Hinweis lesen, dass Edits ausschließlich zur Syntaxnotation unerwünscht wären (und zumindest in serienmäßiger Praxis Konsequenzen hätte); wenn jemand eine Seite bearbeitet, dann läuft WSTM hingegen im Hintergrund automatisiert mit und bereinigt vielerlei Kleinkram im selben Edit. Der Anlass für die Bearbeitung dürfte jedoch sicher ein anderer gewesen sein als irgendein Schrägstrich an <br>; im hier anscheinend zugrunde liegenden Fall war es die Entfernung eines die Darstellung zerstörenden Pipe-Symbols gewesen.
WP:KORR behandelt im Übrigen Varianten der deutschen Sprache, etwa eine Schreibung mit „ph“ oder eine mit „f“; es gibt hingegen keinerlei Anspruch eines „Hauptautors“, seine private Wikisyntax in „seinem“ Artikel durchsetzen zu wollen – nachfolgende Bearbeiter sollen nicht durch ungebräuchliche Syntax verwirrt werden, und eine nachweislich deutlich ungebräuchlichere Syntaxnotation ist keine gleichrangige Schreibvariante wie in Fragen der Rechtschreibung.
Hallo PerfektesChaos, danke für die umfangreichen Ausführungen. Wie ich bereits angenommen hatte, bist Du mit dem Thema gut vertraut. Ich würde den letzten Absatz von dir sogar noch etwas erweitern: " ... es gibt hingegen keinerlei Anspruch eines „Hauptautors“, "Korrektors", "Botbetreibers" oder "Toolprogrammierers" seine private Wikisyntax in „seinem“ Artikel durchsetzen zu wollen ...". Wie du ja selbst schreibst, ist <br> genauso zulässig wie <br /> und damit gibt es zunächst keinen zwingenden Grund für einen Austausch. Und klarstellen möchte ich, dass ich anderen Autoren nichts aufschwatzen will, wie du oben schreibst. Denn ehrlich gesagt, ist es mir persönlich völlig egal, ob in der Wikipedia <br> oder <br /> verwendet wird. Was mir aber nicht egal ist, ist, wenn ich teilweise stundenlang an einem Artikel arbeite, mir Gedanken über Inhalt, Text und Struktur machen, den Aufbau und die Formatierung inklusive den zu verwendenden Code optimiere um dann zu sehen, wie jemand in wenigen Sekunden einen Bot über den Artikel laufen lässt um (willkürlich) korrekte/erlaubte Formulierungen durch seine bevorzugten Formulierungen (und da schließe ich den Code mit ein) zu ersetzen. Das empfinde ich als respektlos gegenüber der ganzen Arbeit und Mühe, die ich mir als Autor zuvor gemacht habe - und extrem demotivierend. Die Wikipedia lebt davon, dass man die Arbeit der Anderen respektiert, wenn sie den hier gültigen Regeln entspricht - auch wenn sie nicht mit der eigenen Meinung übereinstimmen. Du hast oben gute Gründe für die bevorzugte Verwendung von <br /> angegeben. Also, warum schreibst du das nicht einfach hier und hier rein, damit auch andere Autoren dies verstehen? Das würde zum Verständnis Aller beitragen und zukünftige Diskussionen wie diese und der damit verbundene Frust wären nicht notwendig. Die andere Möglichkeit wäre, das von dir programmierte Tool zu ändern und <br> - das in Wikipedia ebenfalls erlaubt ist - unverändert stehen zu lassen. Aber hier hast du ja eine klare Meinung. Danke für dein Verständnis. Gruß --Bert (Diskussion) 16:08, 22. Aug. 2020 (CEST)
Sowas wird nur ein einziges Mal für die gesamte Klasse oder Kategorie von Elementen erläutert und gilt dann für alle; es wird nicht bei jeder einzelnen speziellen Ausführung nochmals wiederholt. Was zu öffnenden und schließenden Elementen zu erwähnen ist, steht auch nicht jedes Mal ab Adam und Eva bei jedem dieser Elemente mit dabei; sonst würden unsere kurzen und noch relativ übersichtlichen Hilfeseiten völlig zusammenbrechen.
Wenn wir seit anderthalb Jahrzehnten eine Syntax haben, an die sich alle Bearbeiter gewöhnt haben und mit der jeder nachfolgende Bearbeiter der Artikel auch klarkommen muss, dann ist es wenig sinnvoll, sich stundenlang hinzusetzen und sich eine private Syntaxnotation auszutüfteln, die im „eigenen“ Artikel von der fast aller anderen Artikel abweicht. Da gibt es auch keinerlei Ansprüche für eine private Alternativ-Syntax und auch WP:KORR greift hier nicht, denn das regelt nur die Frage ob älter „Photo“ oder moderner „Foto“. Es hat hingegen überhaupt nichts mit Wikisyntax zu tun.
Es ist genau nicht das Ziel der Übung, dass jeder einzelne Artikel in einer anderen Syntax mit anderen Notationen und privaten Konventionen und individuellen Spezialitäten hinterlegt wird und jedem nachfolgenden Bearbeiter aufzwingt, eine wiederum andere und neue private Wikisyntax zu erlernen, die dann aber in diesem Artikel erstmal detailliert mit Anleitung beschrieben werden müsste, und zwar in jedem bearbeitbaren Abschnitt den späteren Bearbeitern von neuem erklärt würde.
Es gibt in diesem Projekt praktisch nur eine gebräuchliche Syntaxnotation, von nur sehr wenigen Varianten mal abgesehen, und die gilt für alle Artikel und Seiten und Bearbeiter. Wo das aus welchen Gründen auch immer momentan noch nicht hinkommt, wird es bei zufälliger Begegnung dann automatisiert angeglichen.
{{Zitat
|Text=Irgendein Text mit [[Klammer (Zeichen)
|Autor=Klammer im [Link]]]}}
Das sieht dann so aus.
„Irgendein Text mit [[Klammer (Zeichen)
|Autor=Klammer im [Link]]]“
Ich war zu beschäftigt, um es gleich zu melden und bei dir war da auch gerade Stress. Es passiert nur, wenn drei Klammern am Ende des Wikilinks stehen, dahinter kann weiterer Text folgen.
Ein zweites Problem hatte ich hier Spezial:PermaLink/203380062, das zeigte einen Linterfehler. Als ich den Artikel geöffnet hatte flogen mir die Zahlen (unbenannter Parameter) um die Ohren. Ich erkläre es mal kurz. In jener Version gab es einen Klammerfehler {{GBR]].
Das war aber nicht alles weiter unten steht eine weitere Tabelle für das Jahr 2019, dort nun fanden sich plötzlich besagte unbenannte Parameter, beginnend mit einer Zählung bei 308.
{| class="wikitable sortable"
|- class="hintergrundfarbe6"
! style="width:17%;" |308=Titel
! style="width:13%;" |309=Produktionsland
! style="width:8%;" |310=Regisseur
! style="width:8%;" |311=Hauptdarsteller
! style="width:10%;" class="unsortable"|312=Anmerkung
|313=-
|314= [[3 Engel für Charlie (2019)|3 Engel für Charlie]] |315=|316= {{USA}}<br/>{{DEU}} |317=|318= [[Elizaberh Banks]] |319=|320= [[Kristen Stewart]]<br/>[[Naomi Scott]]<br/>[[Ella Balinska]] |321=|322= [[Drei Engel für Charlie (Fernsehserie)|Serienverfilmung]]
|323=-
|324= [[6 Underground]] |325=|326= {{USA}} |327=|328= [[Michael Bay]] |329=|330= [[Ryan Reynolds]] |331=
|332=|333=-
…
|779=-
|780= [[Shaft (2019)|Shaft]] |781=|782= {USA}} || [[Tim Story (Regisseur)|Tim Story]] || [[Samuel L. Jackson]]<br/>[[Jessie Usher]] || [[Shaft – Noch Fragen?|Fortsetzung]]
…
|}
Vorher war es normal (oder auch nicht, es endet zumindest beim nächsten Klammerfehler {USA}})
{| class="wikitable sortable"
|- class="hintergrundfarbe6"
! style="width:17%;" |Titel
! style="width:13%;" |Produktionsland
! style="width:8%;" |Regisseur
! style="width:8%;" |Hauptdarsteller
! style="width:10%;" class="unsortable"|Anmerkung
|-
| [[3 Engel für Charlie (2019)|3 Engel für Charlie]] || {{USA}}<br/>{{DEU}} || [[Elizaberh Banks]] || [[Kristen Stewart]]<br/>[[Naomi Scott]]<br/>[[Ella Balinska]] || [[Drei Engel für Charlie (Fernsehserie)|Serienverfilmung]]
|-
| [[6 Underground]] || {{USA}} || [[Michael Bay]] || [[Ryan Reynolds]] ||
…
|-
| [[Shaft (2019)|Shaft]] || {USA}} || [[Tim Story (Regisseur)|Tim Story]] || [[Samuel L. Jackson]]<br/>[[Jessie Usher]] || [[Shaft – Noch Fragen?|Fortsetzung]]
…
|}
Nun weiß ich leider nicht, ob da der Fehler irgendwo bei mir zu suchen wäre, denn Crazy hatte den Artikel kurz zuvor bearbeitet Spezial:Diff/203377875/203380062 und scheinbar dieses Problem nicht. Was aber andererseits auch an dem Edit liegen kann der noch eine Klammer mehr hatte. Ich habe den Artikel also lieber nicht bearbeitet und den Fehler an den Verursacher weitergereicht. --Liebe Grüße, LómelindeDiskussion15:42, 14. Sep. 2020 (CEST)
Also, was Leichtes zuerst:
|323=-|324= [[6 Underground]] |325=|326=
Irgendwo gibt es eine noch nicht geschlossene Vorlage; einfach die Pipes zurückzählen von 700 über 400 über 300 und 100 bis zum Anfang. Wobei es auch irgendwo die anderen 307 gab, aber da war bislang noch nichts in der Form |x=y dazwischen gewesen; die Nummern gibt es erst, nachdem eine benannte Parameterzuweisung von einer unbenannten (hier der 308.) gefolgt wird.
Wenn der geöffneten Vorlage {{ kein schließendes }} folgt, dann sind alle Pipes Trenner in Vorlagenparametern bis sich irgendwo aus einer zweiten kaputten Einbindung die gesuchten }} anfinden.
Dann zu etwas was man auch nicht machen soll:
Irgendein Text mit [[Klammer (Zeichen)|Klammer im [Link]]]}}
Wenn das blau macht, dann steht die dritte schließende schwarz draußen, die öffnende blau drin.
Innerhalb von Linktexten sollen deshalb immer alle eckigen Klammern durch [ und ] escaped werden.
WSTM hatte nicht verstanden, was man ihm sagen wollte.
Bei drei aufeinander folgenden Klammern gibt es auch eine Warnmeldung.
Weil das Wikilink nicht als Wikilink verstanden wurde, war eine Pipe übrig, und dann folgt 1=Text und 2=Autor.
Tja, und bei Vorlagen mit unausgeglichenen Klammern verstehst du halt, wie das gemeint war und was da eigentlich hätte stehen sollen, aber keine Software.
Öffnen der Seite mit &action=submit statt &action=edit unterdrückt WSTM.
Ne ich mach das meistens anders und suche mir eine Vorherversion, wenn ich dann doch etwas ändern wollen würde. Ich war halt geschockt von dem Zahlensalat. Und nein durch den Bruch bei der Vorlage Zitat, kam da, wenn ich mich recht erinnere keine Klammerzuvielmeldung. Aber natürlich habe ich das maskiert. Und wenn ich aus der Tabelle der Linterfehler einem Link folge wie soll ich da schnell noch submit anfügen? --Liebe Grüße, LómelindeDiskussion17:02, 14. Sep. 2020 (CEST)
Moin Moin Lómelinde, da ich WSTM ja manuell verwende, also nur auf Konpfdruck, kann es auch sein, dass ich es für diesen Edit nicht aktiviert hatte. Aber bei ein paar vielen Edits kann ich das nicht mehr mit Gewissheit sagen. mfg --Crazy188019:08, 14. Sep. 2020 (CEST)
2020-06 Diverses
Letzter Kommentar: vor 3 Jahren16 Kommentare2 Personen sind an der Diskussion beteiligt
Moin Moin PerfektesChaos, ich habe mal wieder ein paar Fragen/Wünsche/Anregungen. Auch auch hier gilt, ich brauche keine Adhoc-Antwort:
Wir hatten uns mal über -moz- und -webkit- unterhalten. Ich glaube ich habe die etwa 2500 Einträge im ANR gut zusammengeschrumpft und die ein paar Knacknüsse dagelassen, wo ich nicht mehr weiterkomme.
In meiner Benutzer:Crazy1880/vector.js nutze ich eine Funktion von WSTM, womit ich ja eine Vorlage suche und eigentlich Parameter entfernen lassen möchte (Zeile 315 bis 325). Leider scheint das nicht so zu funktionieren, denn es bleiben immer leere Parameter in den Vorlagen drinnen. Kann es sein, dass sich da mit deinem Programmcode etwas in die Quere kommt?
prettytable ist ja gut geschrumpft, ich behalte den ANR im Auge
Hast du weitere Punkte, wo ich "angreifen" kann? Nur bitte keine Anker oder Zwiebelfische, die sind nicht so meins.
Hatte ich 2012 mal begonnen, aber wegen zu großer Widerstände in der Community nicht mehr viel vertieft.
Habe auch fast alles davon wieder vergessen.
Was dokumentiert ist, sollte aber nach wie vor funktionieren.
Die WSTM-eigenen Funktionen kommen immer zuerst dran; deren Wirken kannst du voraussetzen. Die sind immer schon passiert.
Was genau da jetzt nicht funktionieren würde, müsstest du mal konkreter benennen; diese in der Doku beschriebenen Objekte werden eigentlich meiner normalen WSTM-Bibliothek zum Fraß vorgeworfen, und die arbeitet ganz brav. Vielleicht fehlt mir da aber noch ein Go!
Angriffsziele wüsste ich momentan zwei:
Größere Seiten allmählich anknabbern, ohne täglich Filmfritzen oder sowas vor die Leinwand zu laufen.
Außer Philosophie sachte und thematisch gestreut wegputzen; müssten immer dieselben Autoren pro Thema gewesen sein, und falls die noch aktiv sind, sollten sie dich nicht täglich auf der Beo haben. Danach erkläre ich auch diesen ref=ja-Parameterwert für endgültig veraltet und die Angleichung von Block- und Inline-Zitat und Reduktion auf nur noch zwei Vorlagen mit kurzer und längerer Parameterliste kommt irgendwann mal.
Tag@Literatur knabberst du ja wohl täglich an; irgendwann wird die dann wohl im ANR eine Wartungskat werfen.
Spezial:Diff/200934188 sah ganz okay aus; wobei da inhaltliche Kinken drin sind, für die du vermutlich nichts kannst, weil ja nicht deine Infobox.
„Dateigröße“ als number beißt sich mit dem Beispiel 10 kB weil das ist Text; wäre „Dateigröße in kB“ und dann geht number auch wieder und die Infobox schreibt die kB selbst dahinter. number kann man gut syntaktisch überprüfen.
string ist ein Relikt aus den frühen Jahren von TemplateData; da weiß keiner so genau was damit gemeint sein soll. Wir nehmen lieber entweder:
line – einfache Codes, ohne Wikisyntax drin, die in einem Formular in ein einzeiliges Feld passen würde
content – irgendwas mit Wikisyntax, das im Formular auch mehr Platz brauchen würde.
Veröffentlichung = 2010 – in TemplateData schreibst du was von einem „Tag der ersten Entdeckung“; dann müsstest du dich auch zu ungefähren Angaben (nur Monat/Jahr, nur Jahr) äußern und Formatierung und ein Beispiel dafür angeben. Kann ja gut sein, dass das genaue Datum schon aus Sicherheitsgründen nicht bekannt wurde.
Danke für die Antwort, hier nochmal eine Rückantwort -Frage:
Wenn ich WSTM starte, dann bleiben bei mir Parameter in der Vorlage Literatur erhalten, welche aber leer sind und weg sollten. Z-B. bleibt der Parameter Hrsg leer zurück und ich muss ihn manuell noch herausnehmen. Ich weis, über das Herausnehmen von leeren Parametern kann man streiten. Auch der Parameter Ort bleibt regelmäßig stehen. Deswegen dacht ich, ich frage dich mal.
Zu FliessTextRef kann ich mal gar nichts anfangen und bräuchte nochmal kurz mehr Hintergrund.
Ja, die Vorlage Literatur habe ich auf dem Schirm und arbeite auch falsche Parameter sowie falsche Parameter-Verwendung weg.
FliessTextRef findet ref=ja und dann wird in irgendeiner kryptischen, gelegentlich falschen, oft unzureichenden Art intern ein ref gebastelt.
Das soll ersetzt werden durch offensichtliches ref=<ref></ref> und mittelfristig verschwinden.
WSTM lässt bestimmte Parameter bewusst noch stehen, von denen vermutet wird, dass dort noch was nachgetragen wird, oder regt zur Vervollständigung an, oder fügt die Namen von Quasi-Pflichtparametern neu ein. Ich weiß aber nicht mehr welche wo warum.
Moin PerfektesChaos, zwei sind es noch mit FliessTextRef (Affiche rouge und Dnepr-Becken). Könntest du ersteren bei Zeiten mal machen, da habe ich nämlich Fragezeichen aufm Kopf und wüsste gerne wie du den löst. Ansonsten schöne warme Zeit ;) PS.: "-en ist bei 162, Tag@Lit bei 1069, arxiv@Lit bei 930, Monat@Lit bei 4542 und Jahr@Lit bei 142014. (Wobei ich da immer noch für eine Art von Botlauf wäre?) mfg --Crazy188020:50, 11. Aug. 2020 (CEST)
Schönen Dank für deine Unterstützung.
Dnepr-Becken gucke ich mir selbst in einer kühlen Nacht an, Affiche versuche ich mal an einen anderen WSTM-Anwender zu delegieren.
Du kannst diese Aufgabe als beendet ansehen.
Danach würde ich die ref=ja-Geschichte für den ANR deaktivieren, eine Wartungskat wefen, und dann müssen noch die anderen Namensräume bereinigt werden, bis die Programmierung definitiv vereinfacht werden kann.
Bot-Läufe sind in diesen Angelegenheiten grundsätzlich nicht verhältnismäßig, weil kein Vorteil für die Gesamt-Community.
arxiv@Lit und Jahr@Lit tun auch nicht weh. Tag@Lit eines Tages wird fein, freue ich mich drauf.
Demnächst werde ich vermutlich die Datumsformat-Wartung ziemlich strapazieren, weil einige Vorlagen die Wartungskat erhalten werden, und es Hunderttausende von Seiten gibt, die aber ganz gut aussehen weil fast immer von Bot geschrieben.
Moin Moin PerfektesChaos, können wir in der Vorlage {{"}} via WSTM die Parameter sortieren lassen? Also quasi so, wie bei "-en, dass Sprache z.B. nach hinten geschoben wird. mfg --Crazy188014:25, 1. Sep. 2020 (CEST)
Kann langfristig geschehen, wobei sowas immer etwas mehr Staub aufwirbelt und sich Leute über Diffs bescweren. Deshalb warte ich da gern ruhigeres Fahrwasser ab.
Aber wenn du das schon am Wickel hättest: Die letzten hiervon im ANR müssten sachte und unauffällig noch aus dem ANR eliminiert werden, bevor ich diese Parameter im Zuge der Reform und Vereinfachung schlicht aus der Programmierung entferne. Teils schweizerisch, Rest weitgehend eine hessische alte Vorliebe. Damit rückt auch für die verbleibenden Parameter die Sortierung näher, wobei ich die Sprache des Textes eigentlich lieber unmittelbar hinter dem Text hätte, was bei der momentanen TemplateData-Darstellung noch nicht ginge, weil die unbenannten bislang im Vordergrund stehen.
Moin, dabei wäre das gerade jetzt das interessante, also die Parameter-Benennung durch WSTM unterstützt bei der Vorlage. Könnte man da nicht doch was machen? Augenklimpper ;) PS.: die "-en sind auf dem Artikelnamensraum weg. Wieder eine Aufgabe erledigt, bleiben noch 9999. Hast du noch was? mfg --Crazy188019:20, 1. Sep. 2020 (CEST)
Moin PerfektesChaos, was ist denn eigentlich mit der Vorlage "-de, die müsste doch auch obsolet sein, oder? mfg --Crazy188011:27, 27. Sep. 2020 (CEST)
Soll natürlich mittelfristig auch verschwinden.
Ich war mit der etwas vorsichtig gewesen, wegen Vorlage:Zitat-de.
Die hat ein Dutzend tückische Einbindungen, die erstmal vor sich hingammeln können.
Wobei die Malteser Runensteine aber schon mal weg können.
Ich werde WSTM demnächst Bescheid sagen, dass "-de kein de mehr braucht. Spricht sich irgendwann rum.
Hat 37 Einbindungen quer durch den Garten. Sehen harmlos aus.
"-en beobachte ich auf neue Einbindungen, ist anscheinend in Vergessenheit geraten, und werde ich irgendwann ANR-uneinbindbar machen wenn ich mal Langeweile habe.
"-en hat auch keine neuen Einbinden mehr hinzubekommen, ANR ist sauber
"-de-CH hat wohl irgendein Problem der Schweizer, dass die Anführungszeichen wohl nicht passen sollen. Hatte man mich in irgendeiner Diskussion hingewiesen.
PS.: Frage, wolltest du nicht noch irgendwas mit prettytable irgendwo schreiben?
Falls noch Aufgaben vorhanden sind, lass es mich wissen. Literatur knabbere ich immer noch in allen Parametern, es in die richtigen zu bringen. ;)
Momentan verlege ich mich mehr auf ANR-Beobachtung, ob irgendwer aus alter Gewohnheit was wieder einfügt. Danach kommen irgendwann die harten Dinger. Ab und zu sehe ich noch jemand von ganz früher, der hier wieder einsteigt und irgendwas oll wieder anbringt.
Kurier-Artikel zu prettytable habe ich vertagt auf ruhigere Zeiten; brodelt mir momentan zu heftig. Rennt nicht weg. Je mehr das in Vergessenheit gerät und je unsichtbarer es bis dahin im ANR war desto geringer ist dann hinterher der Aufschrei, wenn es weggenommen wird.
Schweizer kommen ganz zum Schluss dran, denen ist absolut nichts recht zu machen, kenne ich schon.
Aufgaben habe ich derzeit keine dringlichen; ruh dich mal von mir aus. Irgendwann wenn ich das Gröbste weggearbeitet habe weiß ich nicht ob Tabellensortierung mit WSTM-Unterstützung was für dich wäre.
Letzter Kommentar: vor 3 Jahren5 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo PerfektesChaos,
im Artikel Benesi-Hildebrand-Methode ist mir was interessantes vorgekommen dort gibt es TeX-Angaben in der math-Umgebung mit Attribut chem (statt chem-Umgebung).
WSTM erkennt das alleinstehende Attribut ohne Attribut-Wert als Fehler und ändert die Attribut-Angabe. Das führte zwar erst zu Fehlern in der Anzeige aber ist wohl doch okay. Wie auch immer der Text von WSTM "Falsches Attribut-Format im Tag" ist irritieren, sollte das wirklich korrigiert werden und wenn wie?
Beispiel:
Zeitweilig hieß es, das <chem> solle bei uns überhaupt nicht benutzt werden; dann kam das Gerücht auf, chem wäre kaputt und solle ganz abgeschaltet werden, und irgendwann bin ich da nicht mehr mitgekommen.
Muss ich erstmal Rächerchen anstellen, das kann etwas dauern.
Gefühlsmäßig würde ich meinen, <math chem> solle ersetzt werden durch <chem> von wegen Klarheit und intuitiv und so.
Habe in dieser Angelegenheit jedoch völlig den Durchblick verloren.
Unsere zuständige H:TeX erwähnt das mit keiner Silbe, weder als Tag noch als Parameter.
Ich habe WSTM jetzt gesagt, dass ein math-Tag einen solchen „wertlosen“ Parameter haben darf; damit ist Ruhe. Spricht sich irgendwann rum.
Wenn nichts besonders einschränkend vereinbart wurde, dann dürfen Tags beliebige Wertzuweisungen enthalten. Nur Schalter wie hier werden als eine vom Bearbeiter vergessene Wertzuweisung angesehen, was relativ häufig vorkommt. Um das zu akzeptieren, was es ohnehin wohl nur bei showfilename@gallery, responsive@references und ***@syntaxhighlight gäbe, muss es angemeldet werden.
Inhaltlich wurde das noch nie gesehen, und was genau es macht und ob es stabil wäre möge der Geier wissen.
Danke, der Artikel scheint übrigens eine Übersetzung aus dem Englischen zu sein und in en:Help:Displaying_a_formula wird zwar gesagt <math chem> ist gleich <chem>, aber dann sagen sie auch, dass es noch einige Probleme gibt die nur mit <math chem> korrekt dargestellt werden. Nungut, ich denke für uns ist das Thema erledigt, oder? Danke --Cepheiden (Diskussion) 20:46, 28. Sep. 2020 (CEST)
URS > SUN-1980 > SUN
Letzter Kommentar: vor 3 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Moin Moin PerfektesChaos, augenscheinlich hat sich bei den Vorlagen ein Update ergeben. Die Vorlage URS wurde von WSTM immer auf SUN-1980 umgebogen. Aber SUN-1980 ist jetzt auch noch nur eine Weiterleitung auf nur SUN. Könntest du in WSTM kurz anpassen, dass URS nun SUN ist? Vielen Dank im Voraus --Crazy188011:26, 27. Sep. 2020 (CEST)
Vorlage:Kicker
Letzter Kommentar: vor 3 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Sorry, dass ich dicch nochmal stören muss, aber das WSTM ist sehr konsequent und entfernt offenbar alle ID-Nummern aus der Vorlage:Kicker. Die Nummer ist allerdings nur bei Spielern (mit oder ohne Typ=Spieler) und bei den Trainern (Typ=Trainer) unbrauchbar geworden. Bei den anderen Linktypen Verein/ Partie/ Turnier/ News ist die Nummer weiterhin zwingend erforderlich. Es scheint nur Auswirkungen auf Hannover 96 gehabt zu haben, sollte noch mehr falsch geändert werden, finde ich das automatisch und werde es korrigieren. --Hadibe (Diskussion) 08:07, 1. Okt. 2020 (CEST)
Das war mein Auftrag, so wie ich ihn da aus Bröseln auf einer fremden BD entnommen hatte. Ohne dass ich dort die gesamte Geschichte durchgelesen hätte
Hier ist übrigens genau der richtige Ort, um der derartige Anfragen zu kanalisieren und systematisch abzuarbeiten. Alternativ die Disku der Vorlage, wo das dann für die Nachwelt rekonstruierbar ist.
Die WSTM-Version ist ohnehin noch nicht veröffentlicht; war erstmal nur in meiner privaten Erprobung.
Also: ID=Ziffern nur dann raus, wenn Typ=nix oder Typ=Spieler oder Typ=Trainer, und ID= wird immer 1=.
Letzter Kommentar: vor 3 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Da werde ich angemeckert https://av.tib.eu/search?f=publisher%3bhttp://av.tib.eu/resource/Deutsches_Zentrum_f%25C3%25BCr_Luft-_und_Raumfahrt_%2528DLR%2529
Unbekanntes Protokoll in URL
bhttp://av.tib.eu/resource/Deutsches_Zentrum_f%25C3%25BCr_Luft-_und_Raumfahrt_%2528DLR%2529
Ungültige Domain
av.tib.eu
Das ist zumindest kein Weg, den ich gehen möchte. Das mit dem Doppelpunktaustausch scheint aber möglich zu sein, dann ist WSTM zumindest still. --Liebe Grüße, LómelindeDiskussion16:45, 10. Okt. 2020 (CEST)
Zur Info
Letzter Kommentar: vor 3 Jahren39 Kommentare11 Personen sind an der Diskussion beteiligt
Danke für den Hinweis, aber WP:KORR behandelt gleichartige Schreibweisen oder Formulierungen der deutschen Sprache im dargestellten Text. Insbesondere gibt es um in der alten Rechtschreibung bis 1995 allein mögliche Schreibungen oder aber seitdem alternative Schreibvarianten, die sich in der jüngeren Generation oft auch immer mehr durchsetzen.
Auf Quelltextsyntax ist WP:KORR grundsätzlich nicht anwendbar.
Quelltextsyntax muss für die nachfolgenden Bearbeiter entzifferbar sein und insbesondere veraltete und nicht mehr standardgemäße Syntaxkonstrukte nach und nach modernisieren.
Es gibt keinerlei Rechtsanspruch eines „Hauptautors“, eine 2005 mal erlernte und inzwischen obsolete Quelltextsyntax müssen von allen nachfolgenden Bearbeitern respektiert werden, obwohl sie mittlerweile ausstirbt und sie niemand mehr versteht.
Der VisualEditor kümmert sich einen Teufel um die vorgefundene Syntax, und die Bearbeiter bekommen überhaupt keine Quelltextsyntax zu Gesicht und wissen überhaupt nicht was das sein soll.
Zur Rücksichtnahme auf die nachfolgenden Bearbeiter des Artikels gehört, dass in einem freistehenden Block-Element, wie es etwa eine Infobox oder ein Blockzitat wäre, bei vielen Parametern oder unübersichtlichen Werten jeder Parameter auf einer eigenen, neuen Zeile beginnt. In einem Blockzitat innerhalb derselben Quelltextzeile irgendwelche Pipe-Symbole herausangeln zu sollen, weil ein „Hauptautor“ geruht dass dies in seinen Artikeln so gemacht werden müsse, und zwar von allen, ist rücksichtslos.
Ob in einer Vorlage Text= steht oder nicht, ist völlig wumpe. Beides sind zulässige Schreibweisen, deshalb ist eine Änderung nach WP:KORR explizit unerwünscht. Erschwerend kommt hin, dass die Änderung zu keiner nach außen sichtbaren oder wirksamen Veränderung führt. Auch damit agiert das Skript regelwidrig.
Ich darf doch daran erinnern, dass Skriptdoktoren eine dienende Funktion haben. Dass sich Autoren, die den Content liefern, demütig danach zu richten oder hinzunehmen hätten, was in einem Skript programmierrt wurde, scheint mir widersinnig. Schönen Abend noch --Φ (Diskussion) 18:44, 21. Nov. 2020 (CET)
+1 eine ähnliche Diskussion hatte ich auch schon geführt (die wurde beim archivieren gelöscht). Ich habe damals schon angeführt, dass auch kein "Korrektor", "Botbetreiber" oder "Toolprogrammierer" ein Anspruch auf seinen privaten Wikisyntax hat. Schade, aus einem gutem Tool könnte ein wirklich großartiges Tool werden, wenn es nicht nur einseitig die Interessen der Korrektoren, sondern auch die der Autoren, also die, die Wikipedia mit Inhalten und Leben füllen, berücksichtigen würde. Aber dafür gibt es bei PC leider nur wenig VerständnisEmpathie. Gruß --Bert (Diskussion) 11:43, 22. Nov. 2020 (CET)
Dem kann ich ganz und gar nicht zustimmen, denn für mich sind die Hilfen, die das Tool mir bei der Bearbeitung bietet von großem Vorteil, und die leidigen Quelltextstreitigkeiten kann ich auch nicht nachvollziehen, denn ein geordneter Quelltext ist viel übersichtlicher und versändlicher als wenn es jeder so macht wie er es für richtig hält. Veraltete Syntax zu ersetzen ist zudem vorbeugende Wartung. Beteiligt sich einer von euch an der Wartung? Oder interessiert es euch einfach nicht? Ich stehe voll hinter dem was das Tool tut, da es mir sehr viel Arbeit abnimmt. Dinge, die ich sonst von Hand ersetzen müsste und oftmals übersehen würde. --Liebe Grüße, LómelindeDiskussion11:50, 22. Nov. 2020 (CET)
Ich sagte ja ein gutes Tool. Nur man sollte auch bedenken: ohne die Arbeit von Autoren gäbe es nichts zu korrigieren. Einfach nur auf dem eigenen Standpunkt zu beharren und fortwährend damit Autoren vor den Kopf zu stoßen, statt Verbesserungswünsche aufzugreifen ist nicht zielführend. Es ist auch für mich als langjähriger Autor immer noch extrem frustrierend, wenn ich viele, viele Stunden Arbeit in einen Artikel stecke, der dann im Syntax einfach durch einen Bot "grundlos" verändert wird (denn WP:KORR gilt nmM sinngemäß auch für Skript) und mir gesagt wird, erst dadurch wird der Artikel wirklich gut. Ein BOT oder Tool soll die Autoren bei der Arbeit unterstützen, er steht aber nicht über der Arbeit der Autoren, denn ohne diese ist er wert- und nutzlos. WP leidet heute schon an Autorenschwund. Deren Leistungen und Standpunkte zu ignorieren und abzuwerten hilft nicht dabei neue Autoren lange zu halten. Ich mache bei Wikifrust eine mehr oder weniger lange Pause, andere Autoren kommen einfach nicht wieder. Gruß --Bert (Diskussion) 12:32, 22. Nov. 2020 (CET)
Liebe Lómelinde, Quelltextedits ohne sichtbare Auswirkungen sind nach Hilfe:Kleine_Änderungen#Was_keine_kleinen_Änderungen_sind explizit unerwünscht: „Eine reine Syntax-Modernisierung oder Quelltext-Formatierung rechtfertigt keine neue Artikel-Version und persistente Datenbank-Belastung.“ Du siehst das anders, das sei dir unbenommen. Mein Rat: Schlag doch eine Änderung der entsprechenden Formulierung hier vor. Solange die Regel so lautet, wie sie lautet, gilt sie auch. Sonntagsgrüße --Φ (Diskussion) 12:42, 22. Nov. 2020 (CET)
Ich bin auch Autorin hier, füge durchaus auch etliche Inhalte hinzu und habe etliche hundert Artikel erstellt. Das Tool wird ja nicht nur von Leuten verwendet die Wartung betreiben, aber eben auch von solchen. Und das Argument Korrektoren zieht hier nicht, es geht eher um valide und zukunftsfähige Syntax. Korrektoren wurde mal angelegt um reine Umschreibungen von gleichbedeutenden Begriffen zu verhindern, es wird aber leider immer immer wieder von Hauptautoren dafür missbraucht ihre eigenen Vorstellungen als die einzig wahren durchzudrücken. Das finde ich dann auch sehr frustrierend. Mich unterstützt das Tool nur bei der Arbeit und ich verstehe echt nicht wo das Problem sein soll. Valide Syntax hilft nicht nur den Autren sondern auch anderen Hilfsmitteln und der Weiterverwendung. Es geht nicht darum zu sagen wie du das formatierst hast ist doof. Es übt keinerlei Kritik, es bereinigt lediglich einige formale Dinge. Aber es ist sinnlos darüber zu streiten. Ich könnte ohne diese Hilfe nicht wirklich effektiv arbeiten. --Liebe Grüße, LómelindeDiskussion12:43, 22. Nov. 2020 (CET)
Ich schreib nicht über WP:KORR, sondern über Hilfe:Kleine_Änderungen#Was_keine_kleinen_Änderungen_sind. Lies doch bitte mal, was da steht. dann kannst du es entweder beherzigen oder zu ändern versuchen. Einstweilen unterbleiben bitte reine Ordnung von Quelltexten und vorbeugende Wartung. Danke im Voraus und liebe Grüße zurück --Φ (Diskussion) 12:47, 22. Nov. 2020 (CET)
Es gibt schlicht und einfach kein Primat eines vermeintlich "geordneten Quelltextes", zumal dieser garnicht definiert ist. HTML und übrige Textauszeichnungen sind bewusst sehr frei interpretierbar, der Wikicode orientiert sich daran. Zu strenge Vorlagen werden nicht nur als bevormundend empfunden, vielmehr widerspricht sowas auch dem pluralistischen Projektgedanken, womit das Konsensgebot omnipräsent über allem stehend respektiert werden soll. --Benatrevqre…?!12:50, 22. Nov. 2020 (CET)
Hallo Lómelinde, danke für deinen Kommentar. Ich schätze deine Meinung und deine Arbeit wirklich sehr. Du schreibst von "valide und zukunftsfähige Syntax", aber wer bestimmt in WP, was das ist? So wie ich das verstehe, gibt es bewusst keine allzu engen Vorgaben oder vereinfacht gesagt, ist alles erlaubt/richtig was keinen Fehler erzeugt. Ich persönlich fände es sogar gut, wenn es beim Syntax genauere/verbindliche Vorgaben geben würde, nach denen ich mich als Autor richten kann. Denn dann könnte man sich viele der nachfolgenden Korrekturedits und unnötige Diskussionen wie diese hier sparen. Solange es solche Vorgaben aber nicht gibt, hat nmM jeder Autor - in den vorgegebenen Grenzen - ein Recht darauf Artikel nach eigenen Vorlieben zu schreiben. Beispielsweise finde ich die Vorlage:Literatur einzeilig deutlich übersichtlicher, eine Korrektur auf einen mehrzeiligen Quelltext durch einen BOT, die nmM einzig die persönliche Vorliebe des BOT-Betreibers zeigt, ist für mich unnötig und daher ein nicht gerechtfertigter Verstoss gegen WP:KORR.
Miteinander reden und versuchen, den Standpunkt anderer Autoren zu verstehen sollte das Primat der Stunde sein. Weiterhin frohes Schaffen wünscht --Bert (Diskussion) 14:12, 22. Nov. 2020 (CET)
Im fraglichen Fall, einer Einbindung der Vorlage:Zitat, war die Quelltexteinbindung in einer einzigen Quelltextzeile seit immer unerwünscht gewesen.
Es haben schon sehr oft die „Hauptautoren“ ihre eigenen Pipes nicht abgezählt bekommen und Quelle und Autor falsch zugeordnet.
Wir verwenden deshalb seit einem Jahrzehnt benannte Parameter für alle derarigen Zuweisungen, um sowohl den nachfolgenden Bearbeitern wie auch dem Ersteller selbst die korrekte Zuordnung zu ermöglichen.
Damit sind Gleichheitszeichen innerhalb von Zitat-Texten, auch wegen HTML-Elementen, kein Problem mehr.
Auch in den Kopiervorlagen ist seit 2010 in der Kurzform bzw. Langform die Anordnung auf neuen Zeilen sowie die Verwendung benannter Parameter vorgegeben.
Nicht explizit dabei steht, dass natürlich der gesamte Block nicht innerhalb desselben Absatzes steht, sondern genauso einen eigenen Quelltextbereich separiert vom vorangehenden wie auch nachfolgenden Fließtext erhält.
Die Einbindung eines Blockzitats mitten in den laufenden Fließtext, in einer einzigen durchlaufenden Zeile, war schon immer unerwünscht gewesen und von Anfang an eine Rücksichtslosigkeit gegenüber allen anderen Autoren. Dies wurde nun nebenbei anlässlich einer inhaltlichen Bearbeitung geheilt.
Finde die Pipes:
{{Zitat|Lorem ipsum dolor sit amet, consectetur adipiscing elit et lacinia purus placerat odio interdum ante maximus, a sodales sem mattis non commodo ante hendrerit ullamcorper eleifend euismod tincidunt rhoncus commodo dui eu pellentesque rhoncus vel fringil|lirum larum löffelstiel|Independency of dependencies, 3. Kapitel, 1978, McGill|lang=la}}
Es gibt keinerlei Rechtsanspruch von „Hauptautoren“, eine unerwünschte und die nachfolgenden Bearbeiter benachteiligende Quelltextsyntax in „ihrem“ Artikel beizubehalten und allen anderen Bearbeitern aufzuzwingen.
WP:KORR behandelt für die Leser sichtbare sprachliche Varianten, insbesondere Schreibvarianten nach alter und neuer Rechtschreibung ab 1995 usw. Für Quelltextsyntax ist dies unmaßgeblich.
Die Software „versteht“ unendlich viele unendlich verwirrende Syntaxkonstrukte, und stellt sie richtig dar. Für uns Menschen ist hingegen eine für alle Bearbeiter leicht verständliche und auch einheitlich gewohnte Notation entscheidend. Die Argumentation, jede Quelltextnotation wäre erlaubt und gleichberechtigt, die von der Wiki-Software in die richtige Darstellung überführt werden könne, ist gaga.
Der in Rede stehende Edit war im Übrigen durch einen Linkfix ausgelöst worden und insofern berechtigt. Der Verweis auf „Eine reine Syntax-Modernisierung oder Quelltext-Formatierung rechtfertigt keine neue Artikel-Version und persistente Datenbank-Belastung.“ ist damit eine pure Nebelkerze. Als aus begründetem Anlass der Edit vorgenommen wurde, um die Verlinkung anzupassen, wurde im selben Edit und deshalb ohne die Versionsgeschichte erneut zu belasten die Syntaxvereinheitlichung nebenbei nachrangig ausgeführt.
Der den Edit auslösende Linkfix betrifft (seltsame Rechtschreibung, aber das war dann wohl Originalzitat): [[Gerhard Schröder (Politiker, 1910)|Außnminister]]
Da würde ich dann noch ein <!--sic--> oder [[sic!]] erwarten, um Eindeutigkeit sicherzustellen.
Nebenbei wird ein ReferenceA als benannter Einzelnachweis in diesem Artikel verwendet. Das ist dümmlichstes C&P irgendeiner Kopiervorlage; gemeint ist das so, dass dieses "ReferenceA" vom „Hauptautor“ durch einen sprechenden Namen wie etwa "Rauschenbach" ersetzt werden soll.
@Diwas: Du hattest dir ja heute morgen auf FZW mehr Übersichtlichkeit gewünscht; der VisualEditor formatiert beim Antreffen der Vorlage:Zitat exakt genauso wie dokumentiert und hier praktiziert.
Dass WP:KORR „für die Quelltextsyntax unmaßgeblich“ wäre, PerfektesChaos, scheint mir eine ad hoc-Erfindung von dir zu sein. Ich kann in unseren Regularien nichts dergleichen finden.
Vorlagen haben keinen regulativ-verbindlichen Charakter. Jeder kann so eine Vorlage schreiben und verändern, kein Mensch ist aber verpflichtet, sich daran zu halten. Wie lange so eine Vorlage existiert, ist unmaßgeblich.
Auf H:KÄ gehst du gar nicht ein. Ich werte das als Zustimmung, dass reine Quelltextkosmetik unterbleiben soll.
Ich behalte mir auch weiterhin vor, Sinnlos-Edits wie die Einfügung von Leerzeichen oder von |Text= in eine Vorlage zu revertieren. Wiederholtes Einfügen ohne Konsens ist Edit War und wird von mir so behandelt werden. Ich bin aber zuversichtlich, dass das nicht nötig werden wird. In diesem Sinne ein schönes Restwochenende --Φ (Diskussion) 16:49, 22. Nov. 2020 (CET)
Es ist schlicht eine Falschbehauptung: „Auf H:KÄ gehst du gar nicht ein“.
Ein Edit soll immer mindestens zu einer nach außen sichtbaren oder wirksamen Veränderung führen;
Der Benutzer hatte mit dem Bearbeitungskommentar lf eine Verlinkung angepasst.
Ich bin darauf eingangen per [[Gerhard Schröder (Politiker, 1910)|Außnminister]] – Gerhard Schröder (CDU) isnichmehr.
In der Entstehungsgeschichte und Auslegung von WP:KORR ging es noch niemals um Quelltextsyntax, sondern um mehrfache Rechtschreibvarianten, stilistisch gleichwertige deutschsprachliche Konstruktionen usw. Es ist ein Missbrauch der Projektseite, daraus herleiten zu wollen, dass jedes Byte einer Quelltextsyntax genau so bleiben müsse wie man das 2012 mal für sich privat haben wolle.
WP:KORR ist eine Weiterleitung auf Wikipedia:Rechtschreibung #Korrektoren. Es ist hanebüchener Unsinn zu behaupten, eine Projektseite zur deutschen Rechtschreibung wäre eine Rechtfertigungsgrundlage für die Formatierung von Wikisyntax und Ermächtigungsgrundlage für „Hauptautoren“, in „ihrem“ Artikel eine private und für andere Bearbeiter missverständliche Quelltextformatierung durchzusetzen.
Die ordnungsgemäße Verwendung der Vorlage:Zitat sieht, wie oben von mir nachgewiesen, seit 2009/2010 jede Parameterzuweisung auf einer eigenen Zeile vor, ferner benannte Parameter zur Vermeidung falsch durchgezählter Pipes, wie es häufig vorkommt.
Die einheitliche Quelltextformatierung, auf die hin bereits konvergiert wird, dürfte in einigen Jahren unausweichlich sein. Der bereits seit mehreren Jahren verwendete neue Wiki-Parser hinterlegt zurzeit noch den Quelltext in der überkommenen Formatierung Byte für Byte als Text in der Datenbank, und bildet dann daraus ein neutrales strukturiertes Datenmodell zur Darstellung der HTML-Seite. Es zeichnet sich ab, dass in mittlerer Zukunft der Schalter umgelegt und der Prozess umgekehrt werden wird: In der Datenbank wird nur noch das neutrale Strukturmodell des Wikitextes gespeichert, Syntaxelement für Syntaxelement als Objekt. Sollte irgendjemand Quelltextbearbeitung wünschen, dann wird nach festen Regeln daraus ein global einheitlich formatierter Quelltext generiert und mit Abspeichern der Bearbeitung dies wieder in die neutrale Datenstruktur überführt. Was auch immer jemand an Quelltextkunststückchen gebastelt hatte wird dann neutralisiert (für technisch interesssierte Mitleser: entsprechend des DOM im HTML-Dokument).
Verzeihung, dass ich deinen Technikjargon nur unvollkommen verstehe. Von Zeilen schrieb ich doch gar nicht, sondern von Leerzeichen und obsoleten Parametern. Schön, dass wir uns einig sind, dass kein Edit ohne nach außen sichtbare oder wirksame Veränderung getätigt werden soll. Zu WP:KORR sind wir uns nicht einig. On verra. Abendgrüße --Φ (Diskussion) 18:57, 22. Nov. 2020 (CET)
Hier wird nur eines deutlich: 2 Autoren möchten ihren persönlichen Umgang mit Quelltext als Privileg verteidigen, während Dutzende von Syntaxfixern einen allgemeingültigen Standard umsetzen – auf meiner Beo täglich durchschnittlich ein Dutzend dahingehender Nachbesserungen, allen voran von Aka, Invisigoth67 und Crazy1880.
Ich finde es nicht wert, auf die "Argumente" der beiden einzugehen, denn würden sie die Syntaxstandards anerkennen, käme ihnen jede dahingehende Nachbesserung gelegen – völlig unabhängig davon, ob mit sichtbarem Ergebnis oder nicht.
Das ist völliger Unsinn. Hier geht es gerade nicht um einen „allgemeingültigen Standard“, und Du weißt ganz genau, dass die beiden mit ihrer Ansicht keineswegs alleine dastehen. Gerade Aka und Invisigoth67 beschränken sich außerdem auf echte Korrekturen und nutzen eben nicht dieses umstrittene Skript. Die von PC angeführte Behauptung, dass irgendwann sowieso auf das interne Datenmodell umgestellt werde, zeigt zudem deutlich, wie sinnlos diese Bearbeitungen sind. In diesem Fall hätten sie keinerlei Nutzen und verursachen nur Ärger. Wenn es aber wirklich irgendwann einmal dazu kommen sollte, dürfte der Aufschrei groß werden. --Rodomonte (Diskussion) 19:41, 22. Nov. 2020 (CET)
Dazu wird es nicht kommen. Die WP lebt von ihren Autoren und ihren handgeschriebenen Texten, nicht von vereinheitlichungswilligen Vorlagenschubsern. Solche Helferlein sind Unterstützung, aber keine Richtschnur; somit ist die Nutzung von Vorlagen freibleibend. Eine Verbindlichkeit gibt es nicht und war auch niemals ihr Zweck, als man sie zuließ. --Benatrevqre…?!07:51, 23. Nov. 2020 (CET)
Ich sag mal so, vieles wäre erheblich einfacher, wenn hier nicht jeder sein eigenes Süppchen kochen würde und sich alle mehr an einheitlichem Format orientieren würde. Es dient auch der Vereinfachung für neue Autoren. Ich bin beispielsweise eine echte verfechterin von sprechenden Vorlagennamen und den zugehörigen benannten (verständlichen und weit robusteren) Parametern. Sie erleichtern es anderen zu verstehen was wo in einer Vorlage eingetragen werden soll und welchem Zweck der Eintrag dient, aber wen interessiert das schon? --Liebe Grüße, LómelindeDiskussion11:02, 23. Nov. 2020 (CET)
"...dann wird nach festen Regeln daraus ein global einheitlich formatierter Quelltext generiert und mit Abspeichern der Bearbeitung dies wieder in die neutrale Datenstruktur überführt. Was auch immer jemand an Quelltextkunststückchen gebastelt hatte wird dann neutralisiert ..." Da hoffe ich mal, das PC recht hat und das bald kommt. Dann können die Autoren, die bis dahin noch nicht das Handtuch geworfen haben, sich endlich wieder voll und ganz mit der Sammlung von Wissen beschäftigen und die vielen dann arbeitslosen Korrektoren könnten sie dabei sogar noch produktiv unterstützen. In diesem Sinne allen Beteiligten noch frohes Schaffen. Gruß --Bert (Diskussion) 19:59, 23. Nov. 2020 (CET)
Hier hab ich einen Problemfall:{{Gesetzestext}}. Da würde ich mir dieselbe Formatierung erwünschen wie bei der Vorlage {{Zitat}}, d.h. den Parameternamen Text=, evtl. zusätzlich Sprache=, Autor= |Quelle=. Und Toleranz von Zeilenumbrüchen vor den Parametern (Verwendungsbeispiel für beide Vorlagen).
Angenommen, das wäre umgesetzt und VE würde das fortan nutzen – WSTM würde dann immer bei entsprechenden Bearbeitungen Ergänzungen und Zeilenumbrüche einfügen. Das könnten altehrwürdige Vielnutzer der Vorlage als nervig empfinden. Aber hier wäre eine akute Anpassung der Nutzereinstellung an den "neuen Standard" zu erwarten, statt sich persönlicher Animositäten hinzugeben. Umgekehrt würde ich das auch von mir selber erwarten, falls meine Lieblingsvorlage "im Hintergrund" umgepuzzelt wird. Ungenommen bleibt natürlich immer die Möglichkeit einer kritischen Diskussion eines solchen Standards… übrigens hasse ich Parameternamen bei der Vorlage {{"}}! ;) Gruß --Chiananda (Diskussion) 23:46, 25. Nov. 2020 (CET)
Ich plane eine mobilgerätetaugliche mehr-/viel-sprach-/schriftige Basisvorlage ganz allgemein für Textblöcke.
Diese würde sowohl das bisherige Blockzitat (Fließtext) realisieren, wie auch zitierte Aufzählungen, die zurzeit überhaupt nicht funktionieren, wie auch Gesetzestexte, wie auch Gedicht- und Liedtexte oder Bibelstellen in beliebig vielen Übersetzungen und Umschriften.
Die Parameterwelt aller Literatur-, Vertrags-, Gedicht-, Gesetzes-, Bibelzitate wäre dann ebenfalls zu harmonisieren.
Da sich das dem Ende der Ära von 2010 zuneigt, wird WSTM hier keine neuen Baustellen mehr eröffnen, sondern die Harmonisierung der Zitatvorlagen weiterführen.
Es ist mir völlig egal, wenn jemand die Einbindung nicht aus den Kopiervorlagen von 2009/2010 per C&P einfügt, sondern alles händisch eintippt und dann nur Pipes verwendet, sofern wenigstens die Pipes richtig abgezählt würden – was viele „Hauptautoren“ dann auch nicht hinbekommen. Es darf auch alles in dieselbe Quelltextzeile getippt werden. Aber niemand hat das Recht, von allen anderen Bearbeitern zu verlangen, dieser Brei müsse dann auf ewig unangetastet in „seinem“ Artikel verbleiben. Vorlagenmeister, Quelltextbearbeitung „2017“, TemplateWizard, WSTM, VisualEditor formatieren dies einheitlich gemäß der Kopiervorlage analog 2010 (heutzutage mit ein paar Leerzeichen weniger).
Niemand hat das Recht, von allen anderen Bearbeitern zu verlangen, die von einem Skript nach den persönlichen Vorlieben einer einzigen Person eingefügten Formatierungen zu akzeptieren. Solche Skripte sind purer Vandalismus. --Rodomonte (Diskussion) 08:27, 26. Nov. 2020 (CET)
+1. Die vom Skript vorgenommen Formatierung der EN ist zum Sortieren derselben vollkommen ungeeignet. Ich habe mich schon öfter über diese Art der Formatierung geärgert, speziell wenn Artikel ausgebaut und die EN öfter umgestellt danach neu sortiert werden müssen. Ich sehe in dieser Art der Formatierung nur Nachteile, keinen Vorteil. --Mister Pommeroy (Diskussion) 15:03, 22. Dez. 2020 (CET)
Ich lese eigentlich nur passiv mit, aber habe dennoch eine kurze Frage. Es geht dir also, um die Sortierung der EN-Angaben als Quelltext und dies geht nicht mehr in der mehrzeiligen Formatierung? Darf ich fragen warum und wie du dies nutzt --Cepheiden (Diskussion) 21:31, 22. Dez. 2020 (CET)
Wenn ich einen Artikel massiv umstelle (zB Methan in letzter Zeit), sind die EN im Text nicht mehr in derselben Reihenfolge wie im Abschnitt Einzelnachweise. Diese sortiere ich dann nach einiger wieder in die richtige Reihenfolge, in dem ich diese in zB Excel kopiere und dann sortiere. Geht relativ schnell, wenn die EN ohne Umbrüche sortiert sind. --Mister Pommeroy (Diskussion) 22:29, 22. Dez. 2020 (CET)
Du sortierst also etwas, was aufgrund der verwendeten Technik bewusst nicht sortiert werden braucht, um zu funktionieren. Warum machst du dir diese Mühe? Welchen Sinn bzw. Nutzen hat die Umsortierung der Einträge nach Erstauftreten für dich oder andere? (Nach Autornamen oder EN-Namen hätte ich ja noch irgendwie verstanden.)--Cepheiden (Diskussion) 00:21, 23. Dez. 2020 (CET)
Das es funktioniert, ist mir schon klar, aber da man auch mal etwas löschen muss, ist es einfacher, wenn es sortiert ist. Für andere ist es ebenfalls leichter, wenn es sortiert ist. --Mister Pommeroy (Diskussion) 07:50, 23. Dez. 2020 (CET)
Verstehe ich absolut nicht, ich habe es noch nie benötigt, dass Einzelbelege in irgendeiner Form sortiert sein müssten zumal ja jeder, der dann einen neuen Beleg einfügt verpflichtet wäre es in den Bereich einzusortieren, wo es nach deiner privaten (POV) Sortierreihenfolge hingehören würde, das finde ich schon sehr schräg. Ich käme nie darauf diese Belegangaben zu sortieren, anders ist es im Abschnitt Literatur oder Weblinks, aber selbst da herrschen sehr unterschiedliche Ansichten darüber in welcher Reihenfolge etwas sortiert sein sollte. Und einfacher ist es auch nicht wirklich den Beleg zu finden, denn man muss ja nur ref name kopieren und danach im Quelltext suchen, schon ist man beim richtigen Eintrag. Also ich sehe das als absolute Privatmeinung an und eine ständige Umsortierung nach Änderungen durch andere ist nach meiner Meinung eine unnötige Belastung der Versionsgeschichte. Wenn jemand also auf die Idee käme die Abschnitte neu anzuordnen müssten dann alle Einzelbelege, die mit verschoben wurden, neu sortiert werden, ne echt jetzt, das kann ich nicht verstehen. --Liebe Grüße, LómelindeDiskussion09:22, 23. Dez. 2020 (CET)
Volle Zustimmung, die ständige Umsortierung der Einzelnachweise gegen den Hauptautor durch dieses Skript ist eine absolut unnötige Belastung der Versionsgeschichte, daher sollte diese Funktion einfach abgeschaltet werden. --Mister Pommeroy (Diskussion) 09:43, 23. Dez. 2020 (CET)
P.S.: Abgesehen davon verstehe ich auch deine Änderungen auf Diskussionsseiten nicht (Darstellungsfehler HTML5 fixed), das interessiert nun wirklich niemanden. --Mister Pommeroy (Diskussion) 09:43, 23. Dez. 2020 (CET)
Ob meine Bearbeitungen irgendjemanden „interessieren“ hat nichts mit deiner Vorliebe der Sortierung oder diesem Skript zu tun. Es ist schlicht ein Service, weil es dazu entsprechende Fehlerlisten (Spezial:LintErrors) gibt und diese Fehler nun mal zu defekten Darstellungen auf den Seiten führen oder sie gar komplett zerlegen können. Siehe auch Hilfe:Wikisyntax/Validierung.
Das Skript „sortiert“ keinesfalls die Einträge, dazu besteht ja auch keinerlei Grund, denn die Sortierung der Reihenfolge der angezeigten Einzelnachweise richtet sich nach deren Auftreten und das macht allein die Wiki-Software. Für mich sind die einzelnen Einträge auch durchaus leichter zu unterscheiden wenn sie im Abschnitt Einzelnachweise nicht „inline“ formatiert sind. Die Angaben lassen sich leichter vergleichen und etwaig fehlendes schneller erkennen. Das ist dann aber wieder meine private Meinung. Zudem sieht ein Benutzer, der mit dem visuellen Editor arbeitet, gar nichts von all dem. Übrigens, auch Hauptautoren haben keine Sonderrechte am Inhalt der Seiten. --Liebe Grüße, LómelindeDiskussion12:14, 23. Dez. 2020 (CET)
Hallo Mister Pommeroy, es ist deine persönliche Vorliebe, um eine Art Ordnung für dich zu erhalten (wie auch diese). Also stoßen wieder zwei Vorlieben aufeinander. Das ist in der Regel nur zu lösen, wenn man die Sinn und Zweck beider Vorlieben genau anschaut und dann gemeinsam eine Lösung findet. Nachdem was ich hier gelesen hab, kommt mir der Arbeitsablauf allerdings recht ineffektiv vor. Die Suchfunktion des Browsers zu nutzen, ist da doch effektiver und spart zusätzliche Arbeitsschritte oder nicht? Ob nun manuell formatierte Einzelnachweise in der references-Umgebung mehrzeilig formatiert werden müssen, weiß ich allerdings auch nicht. Zum Aufspüren von Syntaxfehlern mag das hilfreich sein, aber ein Beispiel hab ich nicht. Mich persönlich stört das nicht, da es in Einklang mit der Einbindung von Vorlagen ist. Bei ihnen fördert der Zeilenumbruch nach jedem Parameter meiner Meinung nach die Übersichtlichkeit. Liebe Grüße --Cepheiden (Diskussion) 13:07, 23. Dez. 2020 (CET)
Hallo Cepheiden, nein, das hat meines Erachtens nichts mit Vorlieben zu tun. Ich mache mir halt die Mühe, Artikel auszubauen, und dafür opfere ich viel Zeit und benutze eben mein System und nicht irgend ein anderes. Das Skript investiert gar nichts und stört nur mein System, ohne das es zu irgendeiner Verbesserung führt, ist es (und offensichtlich nicht nur für mich) ein Verstoß gegen WP:KORR, den man unterlassen sollte. Und ich bin nicht der Einzige, der sich davon gestört fühlt. Auch andere Autoren benutzen ein ähnliches System wie ich und stören sich ebenfalls an der dauernden Umsortierung. --Mister Pommeroy (Diskussion) 13:26, 23. Dez. 2020 (CET)
Moin Moin Mister Pommeroy, du schreibst ja oben "Für andere ist es ebenfalls leichter, wenn es sortiert ist." Wenn ich mir aber mal so den Artikel über Methan anschaue, dort spezieller die Einzelnachweise Methan#Einzelnachweise (also im Quelltext), dann würde ich das nackte grausen bekommen und wäre abgeschreckt. 1.) Alles in einem Block, wo man erstmal suchen müsste, wo fängt der Einzelnachweis an, wo endet er. 2.) Eine Sortierung nach ABC sehe ich da auch nicht, die Ref-Name sind so verstreut, da sehe ich G, dann E, dann M, dann C? Logik? Keine. 3.) Vllt. magst du auch die alten Vorlagen etc. ersetzen, wie DOI, dass macht schon einiges aus. mfg --Crazy188018:25, 23. Dez. 2020 (CET)
Hallo Crazy1880, die EN sind nach dem Auftreten im Artikel sortiert, oder sollten es sein (also EN 1 als erster Artikel im Quelltext). Ich weiß ja nicht, wie andere das handhaben, aber um meine eigenen EN einigermaßen im Blick zu haben, brauche ich eine gewisse Ordnung. Bzgl. der alten Vorlagen: ich benutze nur doi: und nicht DOI|, falls Du das meinst, aber nicht alle EN sind von mir eingestellt worden. Im Laufe der Bearbeitung werde ich das einheitlich haben. --Mister Pommeroy (Diskussion) 11:39, 24. Dez. 2020 (CET)
Hallo Mister Pommeroy, doch es ist nichts anderes als eine Vorliebe, so wie wir alle Vorlieben zur Struktur, Format oder Formatierungen eines Artikels haben. Warum? Eben weil es eine von vielen Möglichkeiten ist und keine Notwendigkeit bzw. übergeordnete Vorgaben bestehen es so zu machen. Oft sind Vorlieben unterschiedlicher Autoren nicht im Einklang, so wie ich nicht verstehe, warum alle EN im References-Block sein müssen, was für einmalige EN in langen Artikel viel umständlicher ist (Jetzt muss ich den ganzen Quelltext durcharbeiten um Änderungen zu machen und nicht nur den Abschnitt). Ja, du verbringst viel Zeit damit DEIN System einzupflegen und es mag dir nicht gefallen, aber diese Zeit ist meines Erachtens vertane Zeit. Du bringst jetzt aufwendig dein System (inkl. Vorlagenumarbeitung) in einen Artikel den du gerade aufarbeitest (danke dafür), aber zum einen wer sagt denn, die andere Autoren das gut finden (nein der mehr geschrieben hat, hat keine Sonderrechte), zum anderen wie willst du in den nächsten Jahren sicherstellen, dass dieses System erhalten bleibt und noch viel entscheidender warum überhaupt? Überlege mal, ob dies wirklich die beste und effektivste Arbeitsweise für dich ist. Unabhängig sehe ich nicht, dass hier aktuell eine Einigung zu finden ist, denn zuvor müsste man ein einheitliches Verständnis von WP:KORR (gilt es nun für den Quelltext?) und WP:Hauptautor (haben die Sonderrechte?) sowie dem Nutzen der Korrekturen dieses Skripts sind (Aus meiner Sicht haben "Hauptautoren" keine Sonderrechte und das Skript bringt eine qualitative Verbesserung des Quelltexts). Daher ist die Diskussion auch nicht mehr zielführend. --Cepheiden (Diskussion) 13:48, 24. Dez. 2020 (CET)
VE-doi-Murks-Nachbesserungen
Letzter Kommentar: vor 3 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Bei diesem Edit wollte WSTM die komischen Dopplungen wie ([[doi:10.1055/s-0041-109281|doi:10.1055/s-0041-109281 <span></span>]]) bereinigen, hat allerdings vorgeschlagen: ([[doi:10.1055/s-0041-109281doi:10.1055/s-0041-109281 ]]). Ich habe zwar die Leerzeichen am Ende entfernt, aber die stehengebliebene Dopplung nicht bemerkt.
Letzter Kommentar: vor 3 Jahren4 Kommentare3 Personen sind an der Diskussion beteiligt
Gaaaanz ehrlich das Spezial:Diff/208853832/208868707 ist Murks. Also zum einen meine ich natürlich die vielen Maplinks in einem einzigen Artikel und zum anderen was WSTM dann daraus macht. Das wird Ärger geben, vermute ich. Gemeint ist das Zerbrechen des Satzbaus. Wenn ich nicht aufgepasst hätte dann wäre es so herausgekommen.
[…] der
Blauseekurve. Andernfalls wurde ein Wendetunnel gebaut, wie zum Beispiel der
Wattingertunnel bei der Doppelschleife von Wassen […]
Ob die Leute so etwas wirklich toll finden? Ich jedenfalls nicht na aber wer’s braucht. Es darf jedenfalls nicht passieren, dass das Leerzeichen mit in die neue Zeile geschoben wird. Auch ein Satzzeichen am Zeilenanfang verleitet zum Löschen des Zeichens. --Liebe Grüße, LómelindeDiskussion09:20, 16. Feb. 2021 (CET)
Ich wusste schlicht nicht, dass das inline funkioniert; ich wusste überhaupt nicht was das ist. Zu der Zeit hatten wir noch kein einziges Vorkommen gehabt, ich kannte nur das Schlüsselwort.
Deshalb war es block eingestuft gewesen, wie eine gallery und ich dachte da wird eine Landkarte angezeigt.
wenn du schon dabei gehst: Warum die Reihenfolge "longitude= latitude=" ? Das führt nur zu fehlerhaften Einträgen, da in fast allen Vorlagen, und auch bei Googlemaps sowie OSM (sowie anderen internationalen Kartendiensten, muß ich die jetzt alle referenzieren?)) das genau andersrum gehandhabt wird. Erst Breitengrad dann Längengrad ist schon fast eine Norm. Kann man das noch umdrehen, ohne das da das halbe wiki umgedreht werden muß? --Grüße aus dem Süden von Hamburg Jmv • Sprich mich an21:04, 16. Feb. 2021 (CET)
Ich gehe da nicht bei.
Ich verändere lediglich den Status von Block- auf Inline-Element.
Mit dem Inneren und den Inhalten habe ich nichts zu tun.
Es gibt ganze 8 Vorkommen im ANR; da wüsste ich andere Sorgen.
Letzter Kommentar: vor 3 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Ich weiß, das klingt jetzt merkwürdig, aber Spezial:Diff/184704629/209002041 da sind zwei ▯▯ (der Inspektor sagt Separatoren) und WSTM hat sie herausgelöscht und die Zeile umgebrochen, also so.
[…] mit inhaltlichem Schwerpunkt auf Russland. Die Themen behandeln Politik, […]
wurde so
[…] mit inhaltlichem Schwerpunkt auf Russland.
Die Themen behandeln Politik, […]
Was auch immer das für Zeichen sein mögen, sie sind jedenfalls für mich nur im verbesserten Diff (&diffmode=schnark) sichtbar. Daher schrieb ich Kästchen. --Liebe Grüße, LómelindeDiskussion17:21, 19. Feb. 2021 (CET)
merkwürdige Attributverdopplung
Letzter Kommentar: vor 3 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Aus dieser Datei mit fälschlich doppelter px-Angabe
Jaja es mahnt durch „Konflikt von Bildparameterwerten“ auch eine Doppelung an, aber wenn ich eh gerade nach doppelten Bildattributen suche, wäre das ja eine zu erwartende Meldung, was jedoch nicht erwartbar ist, ist das im Ergebnis dann drei Breiten auftauchen. Ich wollte schon in den Bearbeitungskommentar schreiben weshalb man denn die Breitenangabe dreifach setzt. Gut dass ich noch mal geschaut habe wo die dritte herkam. --Liebe Grüße, LómelindeDiskussion15:30, 1. Mär. 2021 (CET)
Stöhn.
Das vordere Dingens sollte wegfallen, und alle (=2) sollten nach hinten.
Letzter Kommentar: vor 3 Jahren2 Kommentare1 Person ist an der Diskussion beteiligt
Nur zur Info: Auch das Spezial:PermaLink/181476574 löst leider Probleme aus, dadurch das WSTM das Tag in die nächste Zeile verschiebt wird die Tabellensyntax zerbrochen. Ich habe es für diesen Fall jetzt auf Vorlage:Doppeltes Bild umgelegt, aber es sah schon sehr merkwürdig aus. Hier ein Ausschnitt.
Frag mich nicht weshalb Leute auf solche Ideen kommen. Man hätte auch jeweils zwei Einzelbilder einbinden können. Es nervt mich sowie so schon länger, dass auch einzelne Bilder zur Gestaltung (mode="packed" oder mode="nolines") in gallery-tags verfrachtet werden und das auch noch auf der Seite Hilfe:Bilder explizit so „empfohlen“ wird. Dadurch landen dann auch andere Einzelbildgalerieeinbindungen in Tabellen ([4][5]) du kannst es hier Friedhof Rohr#Gräber, Waldfriedhof Stuttgart#Gräber oder dort Ravigneaux-Satz#Funktion testen. --Liebe Grüße, LómelindeDiskussion08:02, 6. Mär. 2021 (CET)
Letzter Kommentar: vor 3 Jahren6 Kommentare3 Personen sind an der Diskussion beteiligt
Hi @PerfektesChaos: erstmal: tolles Skript :). Wäre es möglich, die Vorlagen {{Infobox Musikalbum}} und {{Infobox Song}} auch hinzuzunehmen und zu formatieren? Zudem fände ich es noch schön, wenn es möglich wäre, doppelte Leerzeichen im Fließtext (nicht in Tabellen/Vorlagen) herauszufiltern ;). Danke und Grüße, –IWL04 • 18:04, 23. Mär. 2021 (CET)
Du musst mich auf meiner eigenen Werkzeug-Disk nicht anpingen; die beobachte ich schon und antworte pronto. Rote Alarmleuchten brauche ich nicht so dringend.
Weil es immer mehr derartiger Anfragen gibt, und das den Code unübersichtlich macht und verlangsamt, gehe ich für derartige Standard-Aufgaben dazu über, funktionale Einzelprogrammierungen durch schematisierte Daten-Definitionen zu ersetzen, die sich einfacher pflegen lassen und weniger Code fressen. Deshalb kann es sich so oder so noch etwas hinziehen.
doppelte Leerzeichen im Fließtext
Mache ich in der allen aufgezwungenen Standardversion ungern, weil möglicherweise irgendwer die irgendwozu gern behalten möchte. Ggf. durch eigene Ersetzungsregeln privat ausfiltern.
Das hatte ich eh schon mal selbst fragen wollen, ja; sind doch einige Aliasse entstanden durch meine Vereinheitlichungen in jüngerer Zeit. Einiges wurde schon per Bot umgestellt, im Rahmen der notwendigen Korrekturen, aber der Bestand scheint immer noch genug Benutzer zum Verwenden der alten Parameternamen zu verleiten. Ich selbst verwende praktisch nur den neuen Quelltexteditor, WSTM wird deshalb bei mir kaum jemals wirksam, aber den Kollegen im Musikbereich kann es sicher helfen, daher sehr gerne! Gruß–XanonymusX (Diskussion) 00:21, 24. Mär. 2021 (CET)
Sorry für das tatsächlich unnötige Anpingen (hätte ich mir denken können ;)) und danke für die Antwort(en), hatte vergessen, XanonymusX anzupingen. Weil ich aktuell durch relativ viele Album-/Liedartikel durchmuss: lohnt es sich dann, noch zu warten, oder wird es noch etwas dauern (kein Stress)? Das mit den doppelten Leerzeichen verstehe ich – und noch etwas: Habe ich hier etwas falsch gemacht, sodass WSTM auf meinen Unterseiten nicht läuft? Danke und Grüße, –IWL04 • 12:31, 24. Mär. 2021 (CET)
„lohnt es sich dann, noch zu warten, oder wird es noch etwas dauern“
Es lohnt sich nicht, auf irgendwas zu warten. WSTM wird irgendwann irgendwas in der Richtung machen.
Was die Alias-Namen angeht, so ist das jetzt auf dem Dienstweg. Heißt: Es ist noch nicht online für andere außer mir, danach erproben einige Test-User sowas, und irgendwann wird es für alle wirksam.
Reihenfolge der Parameter und Layout sind zurückgestellt. Braucht zuerst eine effektive Datenstruktur für viele Vorlagen.
Benutzer:IWL04/common.js
Ja, ist was falsch.
Führt momentan zu einem knackigen Syntaxfehler. Alle folgenden Anweisungen werden nicht ausgeführt.
Wunderbar, dann werde ich merken, wenn es auch bei mir läuft und danke für die Info, jetzt funktioniert es auch auf meinen Unterseiten :) –IWL04 • 15:12, 24. Mär. 2021 (CET)
Letzter Kommentar: vor 3 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Moin Moin PerfektesChaos,
Ich habe im Hintergrund mal etwas gearbeitet und wollte noch kurz zwei Meinungen einholen:
Magst du bitte mal über die Doku drüberschauen und mir eine kurze Rückmeldung geben, ich habe diese mal mit TemplateData/JSON/Parameter gebaut. Und ja, wenn man es nutzt uns sich etwas eingelesen hat, erscheint es einfacher als Code.
Die Infobox Hohes Gebäude wurde von mir schon vor drei Wochen umgeschaufelt, sie ist komplett leer, auch nach Wurgls Tool. *Freu*. Das WSTM das ja automatisch nach Infobox Hochhaus ersetzt, wollte ich nur mal fragen, soll ich einen LA oder SLA auf die nun unnötige Weiterleitung stellen oder sollte man es so weiterlaufen lassen? Mein Bauch sagt mir, löschen. Dann könntest du denn Code-Snippet auch aus deinem Code entfernen.
Zu TemplateData: Gibt es eigentlich auch eine Möglichkeit Zwischen-Überschriften in Templatedata einzufügen? Bei der Infobox Hochhaus wäre das toll gewesen. Beispiel:
Nicht mehr eingebundene Vorlagen-WL, bei denen keine besonderen Gründe für eine permanente Unterstützung vorliegen, können und sollten per SLA entfernt werden.
Verlinkungen sind nachrangig; ggf. dort anpassen wo langfristiges Interesse an der Unterhaltung bestünde und nicht gleichzeitig ohnehin die IB Hochhaus erwähnt wird.
Überschrift: Ja, aber nur in der JSON-Syntax einzustreuen.
Datumsformat müsste benannt werden; insbesondere die Problematik taggenau – nur Jahr – nur Monat und Jahr. Ein Abriss zieht sich womöglich über Jahre hin, seltener an einem einzigen Tag.
Moin, danke nochmals fürs drüberschauen. Die Vorlage Infobox Hohes Gebäude ist nun gelöscht. Das also zur Info für dich, kannst den Code also bei dir 'ausbauen'. ;) Schönen sonnigen Tag die noch --Crazy188010:06, 30. Mär. 2021 (CEST)
Die HLS lag zwischen Dutzenden Chemie-Vorlagen aus der gleichen Ecke, vor HMDB und HSDB, und dort wurde bisher Datum= zur Kennzeichnung des Abrufdatums verwendet. Bei Vorlage:HLFL mit derselben Krankheit hatte ich das noch irgendwie mitbekommen. Es lebe der Abkürzungsfimmel.
Letzter Kommentar: vor 3 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Hi PerfektesChaos, ist es möglich, STRG_F (ist mit Unterstrich richtig) in eine Ausnahmeliste hinzuzufügen, damit die Schreibweise nicht in STRG F (ohne Unterstrich) geändert wird? Danke und Grüße, –IWL04 • 19:24, 2. Apr. 2021 (CEST)
Das werden dir diverse Werkzeuge und Menschen immer wieder einebnen.
Muttu als [[STRG_F]]<!--sic!--> notieren.
Sonst denken Menschen, du hättest das schlecht aus einer URL kopiert, und Werkzeuge denken nix aber genauso.
Letzter Kommentar: vor 3 Jahren8 Kommentare3 Personen sind an der Diskussion beteiligt
Hi PerfektesChaos, ich habe in letzter Zeit allen Chemie-Vorlagen beigebracht auch Abruf= mit Datum im ISO-Format zu verstehen. Das bisher genutzte Datum= mit Datum als Plain-Text funktioniert als Alias zwangsläufig auch noch, sollte aber zum Auslaufmodell werden. Kannst Du WSTM bei der Migration helfen lassen? Auf Wunsch kann ich eine Liste aller betroffenen Vorlagen liefern.--Mabschaaf17:18, 5. Apr. 2021 (CEST)
Hm, was mache ich falsch bzw. was fehlt in meinen Einstellungen, damit die Umstellung auch vorgenommen wird?--Mabschaaf20:52, 7. Apr. 2021 (CEST)
Moin Moin Mabschaaf, ich antworte mal flucks ;) Die Seite die PerfektesChaos verlinkt hat, ist die developer-Version "d.js", wir aber setzen eher auf die Release-Version "r.js", so wie auch in deiner monobook.js eingetragen. Alles aus d wird von Zeit zu Zeit zu r. Also etwas Geduld, oder d nehmen, dann aber mit Tests leben ;) Hoffe das reicht dir an Antwort, sonst gerne rückfragen. mfg --Crazy188020:55, 7. Apr. 2021 (CEST)
Letzter Kommentar: vor 3 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
… es tut das noch immer. Aber weil der Bot es längst abgeräumt hat. Hast du da keine Lösung gefunden, oder ist es unter deinen Schreibtisch gerutscht? --Liebe Grüße, LómelindeDiskussion15:53, 8. Apr. 2021 (CEST)
Angelegenheit ist zu komplex und bedarf mindestens eines kompletten Wikitages in Ruhe.
Ich habe aber pro Woche nur zwei, drei Stunden, wo ich ausgeschlafen und hellwach komplizierte Programmiererei betreiben kann.
Zwischendurch kommt das Tagesgeschäft mit aller möglichen Nerverei; MediaWiki ändert das Logo, ich muss innerhalb der sieben Tage noch in zwei Löschdiskussionen Stellung nehmen und bald auch zwei Löschanträge stellen, die Seiten-Koordinaten-Neugestaltung hätte schon längst viel vertiefter programmiert sein sollen, du kommst mit Magischen Wörtern und ihrem zukünftigen Verschwinden.
Außerdem Dutzende offener Baustellen, die mal abgeschlossen und aus meinem Hirn eliminiert sein sollten.
Ruf die die Seite mal auf. Da kommen jede Menge merkwürdiger Fehlermeldungen (Unbekanntes Protokoll in URL) aus WSTM. Soweit noch alles kein Problem, aber es wird, aus welchem Grunde auch immer, bei jedem neuen Aufruf ein Slash eingefügt, der vorher nicht dort war.
/iehzsgcvb://// Allianzenwappen Wolm
wird
/iehzsgcvb:///// Allianzenwappen Wolm
Leider weiß ich nicht wieviele Slashs es ursprünglich mal waren, denn es ist mir zunächst gar nicht aufgefallen, weil ich mit so etwas gar nicht gerechnet hätte. Aber es scheint schon länger zu passieren → August 2019 + Januar 2020, der Benutzer verwendet ebenfalls WSTM. Es war aber wohl mal nur ein Slash dort Spezial:PermaLink/159938829 und die Buchstaben zudem in Großschrift. Wann und durch wen das dann kein wurde, weiß ich nicht, muss ich Schnarks Tool fragen. →Spezial:Diff/164312810 war auch er (oder vielmehr es war definitiv WSTM). Das habe ich getestet indem ich die Vorherversion aufgerufen und WSTM gestartet habe. Schau es dir bitte einfach mal an. --Liebe Grüße, LómelindeDiskussion09:05, 21. Mai 2021 (CEST)
Tjaja, da haben die Virgel wohl überhandgenommen. Müsste eine mildtätige Seele wohl mal die ursprünglichen Absichten des Autors ergründen.
Für WSTM ist die Kombination Buchstaben+Doppelpunkt+Schrägstrich ein magisches Wort und wird als URL interpretiert, womöglich mit irgendwie kaputter Syntax. Deshalb wird diese Interprettion gemeldet, und wenn das irgendwer ungerührt trotz hinzugefügter Schrägstriche und roter Fehlermeldungen abspeichert, kann WSTM auch nicht dafür.
Ein Doppel-Virgel meint üblicherweise eine Leerzeile bzw. einen Absatz im Original-Text. Mehr als zwei Virgel gibt es nicht.
Zwischen Doppelpunkt und Virgel helfen <nowiki /> gegen magische Wörter. Leerzeichen ggf. auch. Eigentlich gehören um jeden Virgel herum links und rechts Leerzeichen, und dann sollte auch ein Doppelpunkt nicht mehr von WSTM missinterpretiert werden.
Ich habe den Verdacht, dass im fraglichen Artikel der Autor mit den Schrägstrichen auch noch eine private, undokumentierte und nur ihm allein bekannte Bedeutung zum Ausdruck bringen wollte. Vielleicht waren sie teilweise eher als eckige Klammern gemeint gewesen.
Was du immer so für Worte kennst. IEHZSGCVB (Johann Ernst, Herzog zu Sachsen, Gülich, Clevt und Berg) soviel habe ich schon mal herausgefunden. Wie die Inschrift aber tatsächlich aussehen mag, kann ich nicht ergründen, das Bild der Glocke hilft da auch nicht wirklich. Na ich schaue mal was ich damit mache. --Liebe Grüße, LómelindeDiskussion10:52, 21. Mai 2021 (CEST)
Frage 2021-07
Letzter Kommentar: vor 3 Jahren7 Kommentare3 Personen sind an der Diskussion beteiligt
Moin Moin PerfektesChaos,
kurze Wasserstandsmeldung und eine Frage.
Wasserstandsmeldung:
dtsx ist im ANR weg
dts bleiben 19.000 Einbindungen
nts ist nach wie vor nicht meins ;)
Frage:
Vorlage Coordinate soll doch entweder ganz an den Anfang eines Artikels oder am Ende nach den Einzelnachweisen aber vor die Navileisten und Normdaten, ist das richtig?
Moin Moin PerfektesChaos, zwei weitere Dinge sind mir aufgefallen:
Vorlage Ldif, da setzt WSTM automatisch das Abrufdaten auf klein "abruf", in der Vorlage hat es aber jemand so eingestellt, dass es groß dargestellt werden soll.
Vorlage DatumZelle, wenn ich oder ein nicht vierstelliges Jahr habe und dann ein Monat eintrage, bekomme ich !?!?!? (Beispiel: ?!?!?!) Kennst du das schon?
@Crazy, wo siehst du das denn in der Vorlage:LdiF sehe ich abruf, Abruf, zugriff und 3 als mögliche Angaben. Bevorzugt ist abruf. und alle vier funktionieren auch einwandfrei. Was DatumZelle angeht das erwartet zwingend eine Angabe JJJJ-MM also data-sort-value="15.5.0560"| Mai 560. Das kennt er sicher.
@PC, OT nur als kleine Info ehe ich das wieder vergesse. Wenn jemand die Vorlage:FNBox verwendet, weil sie so schön einen Strich zieht und Kleinschrift erzeugt, aber nicht die entsprechenden Untervorlagen FNZ dann passiert etwas dummes. WSTM rückt die erste Zeile ein, und, na ja, diese Zeile wird dann so
Kann ich nicht bestätigen bei mir ist da |abruf=2021-07-30 egal wie oft ich WSTM starte es bleibt klein. Und wenn dort |Abruf=2021-07-30, |Zugriff=2021-07-30, |zugriff=2021-07-30 oder |3=2021-07-30 steht wird es zum kleinen abruf. Mag aber sein, dass es an der d-Version liegt, die ich verwende. Oben hatte ich deine Anfrage (da setzt WSTM automatisch das Abrufdaten auf klein "abruf",) daher nicht verstanden, klein ist die gewünschte Form. Wegen der Doku kann ich mal schauen. --Liebe Grüße, LómelindeDiskussion18:42, 30. Jul. 2021 (CEST)
Ok den Text dort in der Doku verstehe ich auch nach mehrmaligen lesen nicht: „Format beliebig (deutsch/englisch), sofern eindeutig interpretierbar. Einzelner Tag, auch unspezifischer Monat oder Tag im Monat ohne Jahr usw.“ Merkwürdig, die Ausgabe funktioniert wenn man da nur eine Jahreszahl einträgt
Sortierung ist nicht so wirklich meins. Wie soll man denn diesen Satz so ändern, dass daraus hervorgeht dass ein Jahr immer vierstellig angegeben werden sollte, wenn ein Monat folgt, es sonst aber ruhig ein- bis dreistellig sein darf? Ne, das überfordert mich dann doch. Format kann sein 1. Apr. 1. April 1. 4. ohne Jahr oder mit Jahr, da ginge dann aber wieder 1. Apr. 560 = data-sort-value="1.4.0560"| 1. Apr. 560. --Liebe Grüße, LómelindeDiskussion19:19, 30. Jul. 2021 (CEST)
Letzter Kommentar: vor 3 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt
Es ist zwar sicherlich nicht die Aufgabe von WSTM der schrottigen Programmierung des VE hinterherzuputzen, dennoch würde ich mir wünschen, dass Fehler wie die hier eingefügten leeren span-Tags und die Verdoppelung des DOI vielleicht automatisiert behoben werden könnten. WSTM erkennt ja, dass da ein Problem vorliegt und versucht eine Korrektur, die ist aber leider nicht ausreichend.--Mabschaaf16:42, 8. Aug. 2021 (CEST)
Das ist weniger was für WSTM.
Der Zerlegungs- und Analyseprozess von WSTM ist auf vielfältigste Syntaxkonstrukte vorbeeitet und kann schlecht individuelle Spezialfälle erkennen und gesondert verarbeiten und dann wie gewünscht die richtige Korektur für spezielle Konstellationen erraten.
Gut geeignet hingegen für Bot-Betrieber.
Die können alle ANR-Edits belauschen und auf exakt dieses Muster reagieren.
Eine Stunde nach Beobachtung kann dann mit einem Einzeledit gezielt nur dieses Schema repariert werden.
Damit ist sofort auch eine Reparatur des unerwünschten Leerzeichens wie auch des einen Linter-Fehler auslösenden empty-span online.
Auf Bug-Behebung kann noch einige Jahre gewartet werden; WMF, WMDE und deWP haben einen dramatischen Mangel an kompetenten Entwicklerkapazitäten und können froh sein, wenn das alles irgendwie noch einigermaßen stabil bleibt.
Letzter Kommentar: vor 3 Jahren9 Kommentare3 Personen sind an der Diskussion beteiligt
Warum sieht das heute so anders aus wenn WSTM eine Fehlermeldung ausgibt? Haben die da etwas an der Farbgebung geschraubt? Will sagen gestern, meine ich, sah es noch so aus
Im Text wurde ein schwerer Fehler gefunden.
Nicht alles lässt sich automatisch beheben. Bitte kläre die folgenden Probleme von Hand:
(15×) Tag ohne notwendiges Attribut
<syntaxhighlight lang=????>
-- WikiSyntaxTextMod (PerfektesChaos)
heute ist alles schwarz, also so als hätte jemand das übermalt. Inspektor sagt da is nix mit Farbe rot nur currentcolor solid 3px was auch immer diese currentcolor sein mag oder woher sie ihren Inhalt nimmt, sie scheint pechschwarz zu sein. --Liebe Grüße, LómelindeDiskussion10:09, 13. Aug. 2021 (CEST)
Kürzliche sinnfreie Änderung seitens WMF. Funktioniert nur noch im Inhaltsbereich.
Die WMF lässt das GUI von einem langjährigen aber wenig kompetenten freiwilligen Angestellten aus der enWP bearbeiten, der monatlich einen Bock schießt und wenig Durch- und Überblick hat, maximal die enWP kennt, und noch nicht mal die. In dieser Woche wohl gleich drei oder vier Korken verzapft; siehe FZW.
Bleibt erstmal so; von meiner Seite keine Maßnahmen hier.
remindErrorMessages kann hier auch nicht helfen, weil es von der eher zufälligen Reihenfolge der Ausführung der Skripte abhängt. War WSTM zuerst da, könnte remindErrorMessages das rot einfärben; war remindErrorMessages zuerst aktiv, weiß es noch nichts von WSTM.
Dir ebenso, aber mich stört das schon, ich kann es nicht mehr so gut lesen, warum auch immer. Das Dingen hat doch eine id vielleicht kann man es individuell färben. Ich denke auch nicht, dass es helfen würde zuerst remindErrorMessages zu starten. Wenn ich es richtig verstanden habe nimmt es die Schriftfarbe an, die irgendwo zuvor mal gerade vorgegeben wurde und die ist gewöhnlich schwarz. Der Rand der Errormessage würde übrigens so _ aussehen, wenn ich das rot wegnehme. Ich muss mal suchen. Heute hast du es aber mit den Abkürzungen. Ich wollte nur fragen, ob du da etwas geändert hast, was ich mir aber nicht vorstellen konnte. --Liebe Grüße, LómelindeDiskussion18:14, 13. Aug. 2021 (CEST)
Auch die Anzeige von <ref>-Fehlern wurde in de:WP im Vorschaumodus geändert – kein Rot, keine größere Schrift; Test:<ref name="Test" />
<references />
Das ist schlecht, weil Fehlermedungen in den "Einzelnachweisen" kaum noch auffallen. Da wäre vielleicht ein Veto gegenüber WMF angebracht.
Bei der Gelegenheit kurz 3 andere Fragen zum WSTM:
Vorgestern habe ich einen ganzen Artikel erstmalig zur Bearbeitung geöffnet, und WSTM wollte auf einmal alle "abruf="-Parameter der Vorlage Internetquelle von der letzten Stelle der Platzierung vor "kommentar=" und "zitat=" ziehen – ist das jetzt ein neues Verhalten? Bisher wurde "abruf=" immer ans Ende verrückt.
Manchmal öffne ich ganze Seiten oder einen Abschnitt, ohne dass WSTM in Aktion tritt – gibt es dafür einen spez. Grund? Wenn ich gleichzeitig eine andere Seite öffne, funktioniert WSTM, auch wiederholt, aber wenn ich die erste Seite wiederholt öffne, kommt WST nie ins Spiel.
Manchmal merke ich, dass WSTM bei einer Abschnittsbearbeitung mehr/andere Änderungen vornimmt, als bei der vorhergehenden Bearbeitung der ganzen Seite (ohne dass meine ersten Änderungen nachzubessern wären).
Das mit den ref-Fehlern sehe ich zumindest noch normal (class="error" eben), hast du es mal mit remindErrorMessages versucht?
Dass WSTM manchmal scheinbar nichts tut kann daran liegen, dass nichts zu tun ist, oder eine Änderung als klein angesehen wird und nicht in einem Extrakasten oben erscheint, daher immer den Difflink vergleichen ehe du speicherst. Ich öffne eigentlich fast immer den kompletten Artikel und selten mal einen einzelnen Abschnitt. Daher ist mir ein unterschiedliches Verhalten auch noch nie aufgefallen. Es kann allerdings mal vorkommen, dass in der (komplett geöffneten) Seite irgendwo eine merkwürdige Syntaxkombination ist, die den Start von WSTM verhindert, hatte ich auch schon mal, das würde dann auch erklären warum es bei einer Abschnittsbearbeitung anders reagiert, wenn dieses Konstrukt nicht dort enthalten ist.
Das Fehlen der roten, vergrößerten Markierung von <ref>-Fehlern beim Bearbeiten des Quelltexts fällt mir jetzt auch hier beim Abschnitt wieder als ungünstig auf. Erst vor paar Tagen bemerkte ich das fehlende Rot in den Einzelnachweisen, als ich den Artikel beim Bearbeiten bis unten durchscrollte, um auf Rotes zu achten: Da war nix. Eine fehlende <ref> wurde erst nach dem Abspeichern rot angezeigt.
Wie gesagt, ich sehe das auch in der Vorschau weiterhin dick rot auf gelb in dieser Form 1. ↑Referenzwarnung: Das Tag <ref> mit dem Namen Test kann nicht in der Vorschau angezeigt werden …
Im Hintergrund hat sich wohl leider einiges geändert und das erschwert die Wartungsarbeiten. Ich weiß auch nicht weshalb man hier von den Softwaretechnikern immer wieder vor neue Hürden gestellt wird. --Liebe Grüße, LómelindeDiskussion06:31, 15. Aug. 2021 (CEST)
@Ló:
Dein CSS war schon ganz okay, aber der Selektor darf nur .error lauten, um alles zu finden, und darf nicht durch irgendwelche Zusätze enger gestellt werden.
Dass du persönlich in der Quelltext-Vorschau „rot auf gelb“ sehen kannst, liegt daran, dass hier das CSS von remindErrorMessages zugeliefert wurde; ein geeignetes CSS von MediaWiki ist nicht mehr in der Seite enthalten. Was einer von vier Bugs ist, den ein Code-aufräumender MediaWiki-Beschäftigter in der laufenden Wooche geschossen hat.
Letzter Kommentar: vor 2 Jahren11 Kommentare4 Personen sind an der Diskussion beteiligt
Moin Moin PerfektesChaos, mir ist was aufgefallen, das wollte ich mal melden. Im Artikel Johannes Riemer kommt ein Wort mit "e͏̈" vor. Wenn ich dann WSTM starte, macht er mir immer "e͏" draus. Jetzt weis ich nicht, ob es von WSTM kommt oder vllt. doch von einer persönlichen Einstellung. Vllt. mag auch ein Mitlesender mal schauen, ob das bei ihm/ihr auch passiert. Danke schonmal --Crazy188021:23, 26. Aug. 2021 (CEST)
Nachtrag: Du hattest 2014 mal diese Vorlage angelegt "Vorlage:Ref-Tag-Fehler", wird die eigentlich nicht gebraucht, weil gar nicht eingebunden etc.? mfg --Crazy188021:25, 26. Aug. 2021 (CEST)
Ja macht es aber ich vermute das liegt a dem Steuerzeichen, dass mir der Schnark-Diff so mit einem Kästchen e▯̈ anzeigt, du kannst aber solch ein e͏̈ mit Punkten durch Alt + 0235 erzeugen das sieht dann so aus ë ohne diesen Versatz. Das ist so ziemlich die einzige Tastenkombination die ich kenne, weil das im Namen Galadriël vorkommt. --Liebe Grüße, LómelindeDiskussion06:47, 27. Aug. 2021 (CEST)
Danke, Ló.
Das ist U+034F COMBINING GRAPHEME JOINER
Der Graphem Joiner ist eine unsichtbare Verbindung, um zwei Schriftzeichen übereinander zu bekommen, in erster Linie für asiatische Schriften.
Der stand da schon im Artikel, WSTM hat ihn nur sichtbar gemacht.
In unserer Sonderzeichenauswahl unter „Lateinisch“ stehen alle standardmäßig verfügbaren Kombinationen, darunter auch Micaëla aus Carmen.
Soweit möglich sollen die bekannten fertigen Kombinationen benutzt werden.
Die Vorlage ist längst vergessen; sie sollte von Bots eingefügt eine Fehlermeldung berichten, die aber inzwischen von der Wiki-Software selbst präsentiert wird.
In dem Artikel Peter Crüger, wenn ich da WSTM laufen lasse, formatiert er mir den Link von books.google durch, obwohl sauber angefangen und beendet oder habe ich einen Knick in der Optik?
Crazy meint vermutlich dass …Digitalisat]zu … (books.google.de)] wird.
Allerdings hatte zwischenzeitlich schon RonMeier den Artikel bearbeitet (19:39), so dass nun nichts mehr passiert. Ich habe mich auch erst einmal gewundert was der Satz aussagen sollte, dann aber in die VG geschaut.
„formatiert er mir den Link von books.google durch, obwohl sauber angefangen und beendet“ interpretiere ich daher so
bisher wurde ein solchen Link nicht verändert da er komplett war mit Klammern und Linktext „Digitalisat“, nun wird das wenig aussagekräftige Digitalisat eben durch „(books.google.de)“ ersetzt.
Ich denke das ist gemeint. Obwohl ich eigentlich die runden Klammern lieber außen drum herum setzen oder lassen würde, denn der Link sollte, meiner bescheidenen Meinung nach, in der Klammer stehen nicht die Klemmer im Link. vergleiche Vorlage Literatur = Beispiel. (books.google.de). ↔ Beispiel.(books.google.de). --Liebe Grüße, LómelindeDiskussion07:54, 7. Sep. 2021 (CEST)
Moin Lómelinde, Moin PerfektesChaos,
danke für die Hilfe, nein, das war es nicht oder nicht ganz, aber tatsächlich ist es seit der Bearbeitung durch RonMeier weg. Ich habe da mal ein Auge drauf. ;)
@PerfektesChaos: Hast du noch eine Cirrus-Abfrage für "OberamtWürtt", wo ich dann noch Vorlagen setzen soll?
Zur Ursprungsanfrage: Ich habe nicht vestanden, was WSTM oder ich mit dieser Angelegenheit zu tun haben sollen, noch nicht einmal welche Angelegenheit.
Moin Moin PerfektesChaos, ja sorry für die Verwirrung, als ich dir geschrieben hatte, war RonMeier noch nicht am Artikel Peter Crüger.
Ich habe den Artikel normal bearbeitet und dann WSTM laufen lassen (wie immer also), allderings entstand aus folgendem:
Johannes Hevelius: ''Machina coelestis.'' vol. 1, 1673, S. 37. {{Toter Link |date= 2021-09| url=http://books.google.com/id=xlpgaqaaiaaj&pg=pa37 | text= books.google.com}}
dann folgendes: [http://books.google.com?id=xlpgaqaaiaaj&pg=pa37/ ''Machina coelestis'', vol. 1, 1673, p.37]
Das sah mir dann etwas spanisch aus und ich hatte die Bearbeitung zurückgestellt und hier geschrieben. Danach hatte RonMeier den Artikel bearbeitet und diese Stelle ist nun nicht mehr da.
Sorry also für die Verwirrung. PS.: Wenn du noch weitere Aufgaben hast, sag Bescheid.
Habe eben den alten Artikel (also vor meiner Bearbeitung) auf meine Spielwiese kopiert und WSTM rüberlaufen lassen. Das Ergebnis entspricht meiner Erinnerung: WSTM hat in dem google-link nur die Großbuchstaben zu Kleinschreibung geändert - das wars. Gruß und schönes Wochenende --RonMeier (Diskussion) 11:11, 11. Sep. 2021 (CEST)
Letzter Kommentar: vor 2 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Da mein Hinweis hierPlötzenseer Kolk von Verursacher (Xocolatl) geflissentlich ignoriert wird, muss ich jetzt doch eine Fehlermeldung schreiben, denn das hier (Pipes einfügen) war sicherlich nicht RonMeiers Idee sondern bedingt durch die automatische Änderung von WSTM. Vergleiche in der Tabelle im Eintrag Müriz, die Bildlegende nach meiner Reparatur. Öffne ich den Artikel passiert bei all den Einbindungen folgendes.
Pipes verschwinden wenn Commonscat auf ein Pipe folgt
die schließende Klammer der Bilddatei wandert in die nächste Zeile. Diesen Umbruch gibt es bei allen fünf Bildlegenden, die diese Vorlage umschließen.
|[[Datei:Hafen Plötzensee15.JPG|mini|{{Commonscat|ENI 05602350}}]]
…
|[[Datei:Hafen Plötzensee38.JPG|mini|Rechts im Vordergrund die ''Müritz'', daneben ist der Bug der ''Sonnellino'' und ein weiterer Bug zu erkennen. In der Bildmitte die ''Alk'', daneben die kleinere ''Pluto'', die ''Uranus'' und die ''Venus''. {{Commonscat|Müritz (ship, 1986)}}]]
wird zu
|[[Datei:Hafen Plötzensee15.JPG|mini {{Commonscat|ENI 05602350}}
]]
…
|[[Datei:Hafen Plötzensee38.JPG|mini|Rechts im Vordergrund die ''Müritz'', daneben ist der Bug der ''Sonnellino'' und ein weiterer Bug zu erkennen. In der Bildmitte die ''Alk'', daneben die kleinere ''Pluto'', die ''Uranus'' und die ''Venus''. {{Commonscat|Müritz (ship, 1986)}}
]]
Das würde zu einem Riesenbild führen, da nun mini unwirksam wird.
Ich weiß ja das sollte gar nicht in Bildlegenden drin stehen aber was soll ich denn machen, mehr als den Benutzer bitten das zu entfernen, weil das eine nicht vorgesehene Verwebung der Vorlage ist kann ich auch nicht tun. --Liebe Grüße, LómelindeDiskussion15:57, 31. Okt. 2021 (CET)
Pech.
Keine der Schwesterprojektvorlagen hat irgendwo anders was am suchen als im Abschnitt „Weblinks“, und gleich gar nicht in Tabellen oder Aufzählungen. Sie signalisieren, dass der gesamte Artikel mit dieser Seite im Schwesterprojekt verknüpft wäre, und das kann irgendwann auch mal von Wikidata zentral registriert werden.
Kann sein, dass die Vorlagen-Programmierung auch irgendwannmal versuchen wird, das Erscheinungsbild dieser Tabellen zu sprengen; Mobilgeräte und so.
WSTM kann da auch nichts machen als dies durchzusetzen.
Letzter Kommentar: vor 2 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Moin Moin PerfektesChaos, die Vorlage Synchronkartei ruft den Parameter Abruf mit einem großgeschriebenen A auf. WSTM macht bei mir allerdings ein kleines a. Könntest du da mal schauen, ich habe im Source-Code auf die schnelle die Stelle leider nicht gefunden. Vielen Dank im Voraus --Crazy188019:38, 31. Okt. 2021 (CET)
Jaja, die RFF will durchgängig Kleinschreibung, ein Nicht-RFFler versucht projektweit in sämtlichen Vorlagen Großschreibung durchzudrücken.
WSTM-Programmierung angepasst, kommt irgendwann online.
Nebenbei gäbe es noch einen kleinen Restbestand an Wikisource-Oberämtern.
Letzter Kommentar: vor 2 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt
Moin Moin PerfektesChaos, hier mal ein paar Stände:
die Vorlagen VD16, VD17 und VD18 sind nicht mehr eingebunden. ;)
Oberamt scheinen Spezialfälle zu sein, ich schaue da nebenbei noch
dts und dtsx habe ich auch noch ein paar Spezialfälle, schaue immer nebenbei nochmal
Wir hatten seit langem mal wieder eine Einbindung von prettytable, ist beseitigt und Benutzer drauf hingewiesen. Auf den Disk-Seiten schaue ich nebenbei auch nebenbei.
Habe jetzt noch einige Vorlagen mit TemplateData versorgt und versuche gleich alles zu bereinigen, kostet halt ZeitPower. ;(
Frage: Es gab doch mal eine Seite, wo Wurgl durch ApperBot eine Statistik bereitgestellt hat, wie oft Datei, Bild, File etc. eingebunden ist, ich meinte auf einer deiner Seiten, aber ich weis nicht mehr wo, kannst du mir einen kurzen Tipp geben?
Unnötzes Wissen, Vorlage Literatur nun über 800.000 mal im ANR eingebunden, wir nähren uns der Million. ;)
Die unbenannten Parameter waren nicht gehärtet und getrimmt; und wenn da am Dateibezeichner noch ein Zeilenumbruch dranhängt, dann geht die ganz normale Wikisyntax einer Datei-Einbindung in die Grütze.
Na ja, aber ich kann auch nix dafür, wenn WSTM mir das zerlegt. Es geht nicht um Schuld, aber, wenn man es nicht bemerkt, dann bleibt da nur Murks übrig (keine Galerie mit Bildern). Meine Bearbeitung hatte ja direkt etwas mit genau diesem Textbereich zu tun, daher ist mir das natürlich aufgefallen.
Letzter Kommentar: vor 2 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
Dort startete WSTM nicht und es gab eine Fehlermeldung. Ist weiterhin so, ich weiß nicht ganz genau was das bedeutet, es hakt eindeutig etwas in dem kurzen Abschnitt Namensherkunft = Uncaught TypeError: that is undefined und zwar im Zusammenhang mit diesem {{lang|ar|تهيل}} es sagt etwas mit (.dL) Zeile 10260 wo ein
und Zeile 7637 rtl.lang( adjust ); es folgen weitere Einträge, die ich jetzt aber nicht alle wiedergeben mag. Davor sind noch einige Warnmeldungen jQuery.Deferred exception: that is undefined Würde ich es auf {{arS|تهيل}} ändern, gäbe es kein Problem WSTM würde laufen und das ‎ einfügen. Was mag das sein? --Liebe Grüße, LómelindeDiskussion17:11, 18. Dez. 2021 (CET)
Na, ich hätte es auch beinahe nicht bemerkt, erst als ich aus irgendeinem Grunde WSTM noch mal starten wollte und nichts passierte, wurde ich stutzig. --Liebe Grüße, LómelindeDiskussion13:52, 19. Dez. 2021 (CET)
alt Bildparameter nicht erkennbar
Letzter Kommentar: vor 2 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Tja, nach alter Logik war ein leerer Beschreibungstext nicht sinnvoll gewesen.
Weil aber etliche Autoren bei Verwendung dieser lustigen neumodischen Medieneinfügungswerkzeuge sowas generiert hatten, gab es diese Meldung.
Muss ich mal drüber schlafen; wenn kein Miniaturbild dann wäre das nunmehr okay, wenn Miniaturbild dann ist ein leerer Alternativtext trotzdem rausgeschmissener Wikitext und unsinnig eingefügt.
Bisher hätte es beim Inline-Bild auch ohne leeren Alternativtext ja wunderbar funktioniert; die haben sich da halt päpstlicher als der Großmufti.
„Marienfelde, Pfarrdorf im Teltowschen Kreise, 11⁄2M[eilen] von Berlin entfernt, und 1⁄2 M hinter vorigem Dorf [Mariendorf] an der Landstraße nach Groß-Beeren, hat 260 Einwohner.“
im Original sah das Ergebnis dann so aus:
„Marienfelde, Pfarrdorf im Teltowschen Kreise, 11⁄2 [[Meile
|Quelle=J.G.A. Ludwig Helling (1830)
|ref=[2]
|1=M[eilen]]] von Berlin entfernt, und 1⁄2 M hinter vorigem Dorf [Mariendorf] an der Landstraße nach Groß-Beeren, hat 260 Einwohner.“
↑Für Knoten struct node *K der Schwarzhöhe 0 gilt in der vorgeschlagenen Implementierung die Äquivalenz:
K != NULL
*K ist rot.
In den Diagrammen bei den Fällen erkennt man die Knoten, die eine Schwarzhöhe 0 haben können, am Fehlen einer kleinen oder großen Kreisscheibe unterhalb ihres Knotensymbols.
↑J.G.A. Ludwig Helling (Herausg.): Geschichtlich-statistisch-topographisches Taschenbuch von Berlin und seinen naechsten Umgebungen. H.A.W. Logier, Berlin 1830. Online bei google-ebooks Abgerufen 20. Mai 2012.
Danke für den Hinweis, aber daran wird sich nicht trivial was ändern lassen.
Ist offenbar das Zusammenspiel von Parameter-Benennung mit gleichzeitig kaputtem Inhalt und Pipes.
Irgendwann wird Vorlage:Zitat dann ja mal die unbenannten losgeworden sein.
Die Programmierung von Vorlage:Zitat wird aber auch irgendwann durch eine responsive, robustere und vielsprachige mit rechts-nach-links-Schriften ersetzt werden, dann sollte auch das sich erledigt haben. Wenn ich mich mal langweile.
Die drei Klammern hätten aber angemeckert werden sollen.
Sahen auch vorher schon kaputt aus, die öffnende blau im Link, die schließende schwarz außerhalb der Verlinkung.
Ich kann nix dazu, es hat nicht gemeckert, dass dort zu viele Klammern sind, es würde gemeckert haben, wenn die Klammern so [[[Meile|Meilen]]] gewesen wären, nicht einmal das [[Meile|Meilen]]] hätte WSTM angemeckert, anders hingegen diese [[[Meile|Meilen]] Form, da kommt dann wieder Zu viele linke Klammern.
Du und dein irgendwann, meinst du wirklich, dass du von dem Berg, den du da vor dir her schiebst, mal runter ins Tal kommen wirst? IQ, Zitat, und noch weitere Großbaustellen, ich wage es zu bezweifeln, du bist jetzt schon ständig überlastet. --Liebe Grüße, LómelindeDiskussion16:15, 24. Jan. 2022 (CET)
Deshalb priorisiere ich ja auch – und die hier geschilderte Kollision mehrerer Effekte ist zu selten und so hochkompliziert, dass ich eine Woche nichts anderes tun dürfte, also fange ich gar nicht erst an. Wartenummer 999. LG --PerfektesChaos16:20, 24. Jan. 2022 (CET)
Wahrscheinlich schlicht zu viele Vorlagen innerhalb eines Weblink-Titels.
Programmierung ist von 2014.
Das lateinische „F“ zwischen zwei japanischen Textfragmenten eingequetscht ist sowieso Unsinn, da gehört U+FF26 F hinein und dann langt eine einzige Vorlage drumrum.
Kursivschrift um japanische Schrift ist ohnehin unendlich dumm. Die gibt es nur lateinisch, maximal kyrillisch.
Letzter Kommentar: vor 2 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Da ich gerade einen Hinweis von einem Nutzer bekommen habe: Der WSTM trimmt Leerzeichen bei beginnenden Kommentaren. Dies ist allerdings unglücklich bei den definierten Ausnahmen
<!-- schweizbezogen --> und <!-- sic! -->, siehe Hilfe:Tags#Kommentar, jeweils mit führendem und abschließendem Leerzeichen. Eine Ausnahme hierfür wäre aus meiner Sicht sinnvoll, (ob Sinnhaft oder nicht, will ich dabei gar nicht hinterfragen). --darkking3Թ14:18, 7. Feb. 2022 (CET)
Ich habe Besseres zu tun als mich auf solche Leerzeichen-Affereien einzulassen; beide Notationen sind zulässig, eindeutig und sinnvoll.
Bots und Skripte müssen immer beide verstehen, weil die kompakte Variante über anderthalb Mal so oft verwendet wird und von den Schweizern selbst regelmäßig genutzt wird. Die CH-Projektseite sollte intelligenterweise vermerken, dass beide Formen üblich sind, statt daraus abzuleiten, dass der Minderheitengeschmack der einzig richtige wäre und die Mehrheitspraxis ja so furchtbar falsch, dass dem jetzt hinterhergestiegen werden müsse.
Letzter Kommentar: vor 2 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Moin Moin PerfektesChaos, ich hätte einen kleinen Wunsch, kannst du noch etwas in deinem SourceCode unterbringen? In diesem hier genauer gesagt. Könntest du da "[cC]oordinate":"Coordinate", aufnehmen? Mir kommt es ab und an kleingeschrieben daher, ist nur ein bisschen style. Danke schonmal im Voraus. mfg --Crazy188019:18, 18. Feb. 2022 (CET)
Ne, es war ein bisschen anders, da stand eigentlich gar kein alt= das eine hat WSTM da eingefügt und den Text einfach rausgeworfen. Als ich das gesehen hatte hab ich zunächst den Text wieder eingefügt und es nochmals laufen lassen → zack wieder Text raus. Ich es dann nochmals eingefügt und bei den anderen dann auch alt= ergänzt. --Liebe Grüße, LómelindeDiskussion16:45, 3. Apr. 2022 (CEST)
Letzter Kommentar: vor 2 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Servus, ein kleines Anliegen: wäre es möglich, in obengenannter Box bei Ersetzung von Musiker durch Interpret auch die beiden folgenden Leerzeichen (falls vorhanden) mitzuersetzen, dann stimmt das in der Quelltext-Optik wieder und muss nicht von Hand korrigiert werden (Beispiel (von Hand korrigiert))… Wenn nicht, wäre auch nicht schlimm, wäre nur ein schöner arbeitserleichternder Nebeneffekt ;) Danke und Grüße, –IWL04 • 15:57, 4. Apr. 2022 (CEST)
Bedaure, nein.
Wenn das einfach und unkompliziert möglich wäre, hätte ich das von Amts wegen so gemacht.
Es wird jedoch nur der Name des Parameters getauscht; mehr ist über diese Vorlage nicht bekannt.
Bei der benachbarten Vorlage:Infobox Musikalbum ist es noch wilder: Da wird aus Jahr dann Veröffentlichung und das ist länger als jeder bisher bekannte Parametername. Da müssten jetzt alle Gleichheitszeichen nach rechts verschoben werden.
Aus diese Grund halte ich von dem Schema „Gleichheitszeichen unter Gleichheitszeichen“ nicht viel. Es hat sich über die Jahre und Jahrzehnte nicht bewährt. Immer mal wieder werden längere Parameternamen eingeführt, und überall sollen alle Gleichheitszeichen nach rechts – dann wieder entfällt ein langer Parametername und jetzt ist eine riesige Lücke und alle Gleichheitszeichen sollen fünf nach links – dann kommt wieder ein neuer langer Parametername und alles muss vier Leerzeichen nach rechts.
Danke für die schnelle Antwort, ist dann auch in Ordnung. Bei der Album-Box ist genau das das Problem, da ersetze ich deswegen meistens gleich von Hand; hatte mich nur interessiert, ob das mit nur einem Parameter bei der Song-Box funktioniert. VG, –IWL04 • 16:27, 4. Apr. 2022 (CEST)
Tabellen in refs
Letzter Kommentar: vor 2 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Weiß nicht mehr, ob ich so etwas schon mal erwähnt hatte. Ich hatte den Fall, dass jemand meinte in ref-Tags komplette Tabellen einzuschließen, dass nun ließ diese durch WSTM zerschießen und es wäre daraus nur Schrott entstanden, so wie das hier World Games/Ewiger Medaillenspiegel passieren würde. Ich weiß, dass das totaler Murks ist aber, Benutzer machen halt, was sie wollen. Ich wusste auch nicht, wie ich das nun lösen soll (Olympische Sommerspiele). Nur ehe ich das vergesse, wollte ich das mal hier ansprechen. Wie immer wohl eine Nadel im Heuhaufen. --Liebe Grüße, LómelindeDiskussion11:49, 15. Apr. 2022 (CEST)
Das ist eine maximal instabile Konstruktion, weil sie davon abhängt, dass nicht |}</ref> sondern dies in zwei Zeilen steht.
Wusste noch nicht mal ich, dass dies ein Problem wäre, und dann WSTM erst recht nicht. Noch nie gesehen.
Müsste oben ein FN oder &sup>-Link bekommen, und die Tabellen ganz normal in Abschnitt und mit id= oder aber luxuriös noch je einen erläuternden Halbsatz davor und Anker.
Letzter Kommentar: vor 2 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Moin Moin PerfektesChaos, ich habe beim Artikel Elsbeth Wallnöfer bei der Publikation Märzveigerl und Suppenbrunzer die Merkwürdigkeit, das WSTM die ISB-Nummer nicht formatieren mag, aber sie scheint richtig zu sein. Ich habe es jetzt erstmal unformiert gelassen. mfg --Crazy188007:15, 27. Apr. 2022 (CEST)
. 400 sind das Problem.
ISBN werden von WTM auch verstanden, wenn sie statt Strichen Punkte oder Leerzeichen enthalten. Kopieren oder tippen manche Autoren halt so.
Demzufolge gehört die 400 zu den Ziffern der ISBN.
Ein Semikolon, öffnende runde Klammer oder Halbgeviertstrich würden das Problem lösen.
Letzter Kommentar: vor 2 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Wissen vor acht/Episodenliste entfernt WSTM aus der Tabelle (irgendwas mit onlyinclude ist drum herum) die Seitennamen bei der Anschnittsverlinkung. Soweit eigentlich korrekt, aber da diese Tabelle durch die includes nun leider in Wissen vor acht#Einzelthemen eingebunden wird, funktionieren dann dort natürlich die Links zu den Abschnitten der Zielseite nicht. Wie löst man das? Ich habe nämlich eine Mail bekommen, in der sich der Seitenersteller darüber beklagt hat. Ich habe diese Titel also wieder eingefügt, aber schon beim nächsten Aufruf, würde WSTM sie natürlich wieder löschen, so gesehen ist das also keine dauerhaft sinnvolle Lösung. CC:JausH --Liebe Grüße, LómelindeDiskussion08:55, 20. Mai 2022 (CEST)
Noch schlimmer, der VE setzt das auch so um, wenn keine Marker gesetzt werden, daher habe ich das mal mit WSTM getestet, weil mir das selbstschließende Dingen aufgefallen war, als ich das vorhin für die Hilfeseite probiert habe und ich dachte mir ‚das wird sicherlich meckern‘. --Liebe Grüße, LómelindeDiskussion18:57, 7. Jun. 2022 (CEST)
Bin wohl zu blöd :/
Letzter Kommentar: vor 2 Jahren9 Kommentare3 Personen sind an der Diskussion beteiligt
Hi, was mache ich ab Benutzer:IWL04/common.js#L-57 falsch, dass meine style-Definition nicht so funktioniert wie ich sie gerne hätte (die Zeilenumbrüche funktionieren glaube ich, lineup zB nicht)? Danke schonmal und VG –IWL04 • 16:45, 17. Jun. 2022 (CEST)
Für style: sind zwar keine Beispiele angegeben, aber grundsätzlich ist der jeweiligen Eigenschaft nach dem Doppelpunkt genau der Einzelwert zuzuordnen, der in der Doku als Spalte „Werte“ angegeben ist, also nur true ohne Klammern und anderes drumrum. Weil sonst.
Nebenbei hast du ein paar Kommata unmittelbar vor schließenden Klammern zu stehen, was möglicherweise durchgeht, aber eigentlich syntaktisch falsch ist und manche Ausführungen zum Absturz bringen könnte. Je nach Perfektion der Browser.
Danke soweit, jetzt abgeändert unter Benutzer:IWL04/common.js#L-39 – lineup scheint aber weiterhin nicht zu funktionieren, siehe zB Blaues Licht (Parameter Genres/Produzent)… Und noch was: Sobald ich benutzerdefinierte Ersetzungen definiere, lässt sich im Editmodus WSTM nicht noch einmal starten (durch den Button oben nach [Verschieben]). Lässt sich das ändern? Grüße, –IWL04 • 19:34, 17. Jun. 2022 (CEST)
Danke dir, so wie es jetzt ist (Benutzer:IWL04/common.js#L-59) funktionieren aber weder der Autostart noch meine selbstgewählten Ersetzungen, zieh ich den Teil vor ([7]), funktioniert der Button nicht :/ Hab wohl wirklich zu wenig Ahnung von js… VG –IWL04 • 10:17, 19. Jun. 2022 (CEST)
Moin IWL04, du hast jetzt auch zu viel drinnen. Du definierst nun einmal mw.libs.WikiSyntaxTextMod von Zeile 4–10 und einmal mit dem nachträglichen Starten von Zeile 59–94 nochmal das Gleiche mit anderen Eigenschaften. Mach mal bitte zum Test folgendes. Schmeiß bitte mal deine Zeile 2–10 raus und pack dafür meine Zeilen 44–82 rein, anschließend noch deine Zeilen ab 58 bis Ende alles raus. Nach dem Speichern einmal allen Cache vom Browser löschen, schließen und komplett neu starten, dann testen. mfg --Crazy188011:56, 19. Jun. 2022 (CEST)
Fehlermeldungen in Konsole anzeigen (sind aber ggf. sehr viele unkritische verschiedenster Herkunft sichtbar).
Klingt nach möglichem Syntaxfehler.
Es muss aufgepasst werden, dass eine zuvor definierte Komponente nicht anschließend wieder überschrieben wird.
Im Übrigen empfehle ich grundsätzlich immer und überall, mw.loader.load erst hinterher nach allen Definitionen auszuführen, weil es sonst zu einer race condition kommen kann und was dann zu spät angefordert ist wird nicht mehr beachtet.
WSTM ändert doch einige Sachen automatisch. Aber er müsste auch Folgenleiste und Folgenleiste Multi in Personenleiste ändern. --Tommes✉15:52, 8. Jul. 2022 (CEST)
Letzter Kommentar: vor 1 Jahr3 Kommentare2 Personen sind an der Diskussion beteiligt
Wenn du beizeiten mal WSTM sagen könntest, es soll das nicht immer als „CSS Zuweisung ungültig – position:sticky“ kennzeichnen, ich weiß nicht was ich dann damit tun soll. Auch wenn ich persönlich diese mitlaufenden Dinger nicht mag, so vermute ich, es gäbe da Ärger, wenn ich das einfach entfernen würde. --Liebe Grüße, LómelindeDiskussion17:04, 12. Sep. 2022 (CEST)
Letzter Kommentar: vor 1 Jahr4 Kommentare3 Personen sind an der Diskussion beteiligt
Hi zusammen, was ist bei Slender falsch? WSTM versucht das .29 aus der Versionsnummer in eine Klammer umzuwandeln. Das aka-Tool zum Checken von Abschnittslinks "erkennt" die .29 auch als Klammer, dort steht:
Das sollte es auch nicht da die Abschnittsüberschrift eindeutig → DirectX#DirectX 2.0 bis 9.29 lautet und durch die Klammer der Link zerstört wird. Und offensichtlich gab es diese Version ja, dann darf das nicht zu einer Klammer werden. Soweit ich es testen konnte hängt es direkt mit dem # zusammen, also es wird nur gewandelt, wenn das ein Abschnittslink ist, oder in dem Text des Links so ein # vorkommt, ohne würde die Ziffernfolge als das erkannt, was sie ist. Kurios ist es auch, dass eine .28 zu der anderen Klammer würde und .22" … also beliebige andere Codes aus dem Bereich der zwanziger wären da betroffen. Aber was ich mich frage ist, müsste das nicht wenn dann %29 = schließende Klammer sein? --Liebe Grüße, LómelindeDiskussion14:43, 14. Sep. 2022 (CEST)
Es gibt eine historische Syntax, die 2001–≈2017 oder so gültig war.
In den frühen Jahrzehnten konnten manche Browser (=IE) die %-Syntax des Escapen von Sonderzeichen in Sprungzielen nicht umsetzen, und damals hatten sämtliche Abschnittsverlinkungen statt % ein . verwendet, und das dann rückgewandelt.
WSTM muss davon ausgehen, dass hier ein Wikitext aus alter Zeit vorliegt, und betrachtet den . als % und führt dann URL-Decoding aus.
Muss halt mit <nowiki /> oder vielleicht per Entity für eine eindeutige Interpretation gesorgt werden.
Besser noch: Beim Linkziel einen Anker mit robustem Sprungziel reinwerfen, und dann dieses statt der gefährlichen Abschnittsüberschrift verlinken.
Sowas ähnliches hatte ich vermutet, die Syntax mit dem Punkt muss ich aber irgendwie verpasst haben, die Zeiten wo ich fürs Internet programmiert habe waren davor und damit habe ich das nicht auf dem Schirm. Gut, also verstanden, ich bau das um. Danke! --Windharp (Diskussion) 08:13, 15. Sep. 2022 (CEST)
|{{SortKey|{{nts|1592}}|ca. [[1592 in art|1592–1593]]}}:<br/><br/>''[[Eine Frucht schälender Junge]]''
wird zu
|:<br/><br/>''[[Eine Frucht schälender Junge]]''
Daher kann ich die Seite nicht bearbeiten. dieses Konstrukt löst aber leider 94 Linterfehler aus, weil div-span-irgendwie …. Ich hoffe das bearbeitet jetzt niemand der WSTM verwendet. Generell müsste das komplett überarbeitet werden denn diese Jahre 1592–1593 gibt es hier nicht und auch nicht so merkwürdige Werktitel Eine Frucht schälender Junge habe ich schon mal erwähnt, dass ich Artikelübersetzungen nicht ausstehen kann? siehe der Megamurks kommt von dort --Liebe Grüße, LómelindeDiskussion15:51, 12. Nov. 2022 (CET)
Da ist so viel Syntaxschrott drin gewesen, dass WSTM bei der Zuordnung von Klammern usw. völlig überfordert war. Eine oder viele Warnmeldungen müsste es eigentlich gegeben haben. Kann ich nichts machen. Danke für den Hinweis. --PerfektesChaos12:22, 13. Nov. 2022 (CET)
Letzter Kommentar: vor 1 Jahr8 Kommentare3 Personen sind an der Diskussion beteiligt
Ciao PC,
das Mosai͏̈ke wird beim im Betreff genannten Artikel durch Mosai͏̈ke mittels WSTM ersetzt. Sollte das so sein? Mache ich was falsch?
Danke und lieber Gruss, --Phzh (Diskussion) 23:56, 20. Nov. 2022 (CET)
Wunderbar, habs angepasst. Hoffentlich korrekt. Andere Frage: Bin händisch Deine Bot-Anfrage am Durchackern. Händisch, da ich noch das eine oder andere Inhaltliche (wie fehlende Kommata bei der Auflage) korrigieren möchte. Nun wollte ich primär die Ersetzungen an WSTM beibringen, aber scheitere kläglich. Das Rauswerfen der leeren, nicht benötigten Parametern klappt, aber die Ersetzungen nicht. Hast Du mir allenfalls einen Tipp? Danke und LG, --Phzh (Diskussion) 12:16, 26. Nov. 2022 (CET)
@ „Bin händisch Deine Bot-Anfrage am Durchackern“
Ich vermute mal, es geht um Bib-Vorlagen.
Tja, das ist lieb, wenn du dir unbedingt die Mühe machen willst.
Software-Fragen:
WSTM ist ungeeignet dafür; es wehrt sich mit Händen und Füßen, im Vorlagen-Namensraum und in Programmierungskonstrukten benutzt zu werden und ist primär für den ANR gedacht.
Du kannst jede beliebige externe Programmiersprache verwenden, die reguläre Ausdrücke kennt und dann außerhalb des Bearbeitungsfelds nach C&P Prozeduren ausführen: Visual Basic Script, Unix shell scripts, Lisp oder sonstwas. Damit müsstest du eine kleine Wegwerf-Prozedur erstellen, die immer wieder an den Anfang des Textes springt und dann die jeweilige Ersetzzung vornimmt.
Bot-Betreiber machen auch nichts anders.
In der Bot-Anfrage steht nichts anderes als in normale Sprache übersetzte reguläre Ausdrücke.
Wenn du es in JavaScript bastelst, geht es auch ohne C&P automatisch innerhalb der aktuellen Seite, sofern sie einen geeigneten Namen hätte und im Bearbeitungsmodus steht (WSTM ist auch nichts anderes).
Ich bin völlig überlastet und kann nichts Inhaltliches beisteuerm. Alles wo ich mir etwas angucken müsste ist z uviel; oich kann nur rumdiskutieren, was ich ohne Nachdenken aus dem Ärmel schütteln kann.
Letzter Kommentar: vor 1 Jahr31 Kommentare3 Personen sind an der Diskussion beteiligt
Moin Moin PerfektesChaos, mal so Schmunzler, 900.000 Mal die Einbindung der Vorlage Literatur im ANR ist die nächste Sprungmarke zur Million. Ich bin nach wie vor beschäftigt die Parameter zu warten und in die richtigen Parameter zu überführen. (Wie lange war gleich die Umstellung her, kopfkratz, ja 2016, lach.) Gleichzeitig wollte ich noch gefragt haben, hast du noch Betätigungsfelder, wo ich mal schauen kann? Ansonsten schönen Sonntag --Crazy188010:02, 11. Sep. 2022 (CEST)
@Literatur:
Veraltende Parameter im fünf- oder gar sechsstelligen Bereich lohnen keine gezielten Aktionen und sollen langsam und gemütlich aussterben und in Vergessenheit geraten.
Gibt nur Zoff, wenn lediglich deswegen Artikel bearbeitet werden.
Es müssen ohnehin alle von vor 2016 auf ewig unterstützt werden, weil im BNR und archivierten Diskussionen.
Nur im ANR werden sie dann nach und nach zurückgewiesen.
Zu Literatur: Das sind nicht nur alte Parameter, das sind auch Parameter, wo absoluter Schwachsinn enthalten ist und diese werden sauber überführt, so war es eher gemeint.
Zu AmNatBio schaue ich mal
Die Vorlagen und Module sind dann mal geschützt, ist also umgesetzt
PS.: Ich weis, dass ist ne gehasste Frage, aber weist du schon, wann du irgendwann mal Vorlage Internetquelle auf neue Beine stellen wolltest?
Und PPS aus Neugierde: Was machst das Modul: CoordParse?
„absoluter Schwachsinn“ ist was anderes als Herausgeber= oder Jahr=.
Internetquelle erfordert einen Konsens der WP:ZR, wie die Darstellung von defekten Weblinks und Archivlinks sowie Drittpublizierern wie GoogleBooks oder YouTube zukünftig robust erfolgen soll, und praktikable Lösungen für die hunderterlei Anmerkungen, dies auch für die aufgekommenen „Hybride“, also Publikationen, die wie Druckwerke organisiert sind, aber niemals auf Papier erhältlich waren, sondern nur als PDF usw. online.
Ohne runderneuerte WP:ZR ist jede Investition von Bemühungen in Internetquelle vergeudet.
Auch danach ist ein Umstellungsprozess im Aufwand von 20–33 % der Literatur von 2016 zu erwarten; also ein Jahr weitaus überwiegende Beschäftigung mit nichts als der Reformen.
Die momentanen WP:ZR stammen geistig von 2005/2006, und damals kannte man hier weder defekte Weblinks noch Archivlinks noch YouTube.
Waren den Geisteswissenschaften des letzten Jahrhunderts verhaftet, und deren etwas behäbigem Weltbild, das der modernen Vielfalt an Publikationsformen nicht standhält.
Ja, die sind mal nebenbei ein bisschen zum stumpfen Bearbeiten. Aber genauso gehören Herausoperierungen aus dem Parmater Titel oder Kommentar dazu, sowie die Überführung in passende Parameter.
Die Frage müsste dann also lauten, wie bekäme man einen guten Vorschlag auf WP:ZR und wie findet man Konsens, richtig?
Die AmNatBio sind übrigens auch weggenabbert, lekker lekker ;)
Stimme aus dem Off: Wer außer Dir, lieber PC, steckt denn so tief in der ZR-Thematik, dass er einen fundierten Vorschlag für eine Neufassung machen könnte?--Mabschaaf16:22, 12. Sep. 2022 (CEST)
Moin Moin PerfektesChaos, mir ist da nochmal was aufgefallen. Bei der Vorlage Literatur Parameter |Band= lässt WSTM ja |Band=Band 1 zu |Band=1 umbauen, richtig? Könnten wir das auch für |BandReihe= hinbekommen? Danke --Crazy188009:02, 15. Okt. 2022 (CEST)
@BandReihe: Kann ich zwar irgendwann mal machen, ist aber weniger dringlich und insgesamt seltener und ich habe zu viele offene Baustellen.
Hat insgesamt jedoch einen anderen Hintergrund:
Band=17 geht als Info in COinS ein, wird also (wie auch sprache=) im HTML-Dokument versteckt und ist an externe Literaturverwaltungssysteme exportierbar.
Damit steht dann dort volume=17. Das können Franzosen dann darstellen als tomé 17 und Engländer als vol. 17 und Russen, Ukrainer, Japaner entsprechend.
Je mehr deutschsprachige Schlüsselwörter dort mit beistehen, desto unverständlicher wird das für die Konsumenten. Die bekommen dann vol. Band 17, issue Heft 5, p. S. 234 bis 241, hätten aber lieber vol 17, issue 5, p. 234–241.
Gleiches gilt für den Austausch zwischen Wikis. Deshalb Datum und Name der Sprache in ISO, und Seitenzahlen möglichst nur als Ziffern.
Die ganze Reihe mit ihren Details wird zumindest nicht nach COinS exportiert, und ob fremde Wikis das begreifen würden ist fraglich, und wenn dann hätten sie ohnehin ganz gut zu tun.
@Wennsteschonmalhierbist: Da wäre noch etwas Oxford-Nacharbeit; die von wikipedialibrary wären relativ vorrangig:
Benutzeransprache eines sehr langjährigen erforderlich, der das wohl noch nicht mitbekommen hat: Spezial:Diff/226332135 und entsprechend Syncom 2 wobei Google Buch überhaupt nie ein Abrufdatum benötigt und Syncom 3 dito.
Mir ist beim Bearbeiten hin zur Vorlage JSTOR etwas aufgefallen. Ich wollte diese Nachweise in die Vorlage Literatur gießen, allerdings bekomme ich da die Meldung, dass die JSTOR ungültig ist. Also diese hier: JSTOR:resrep25082, gehe ich dabei richtig in der Annahme, dass die Vorlage Literatur nur Ziffern versteht?
Oxford und Benutzerinfo sind raus
Was meinst zu mit Zugriff@BibISBN, soll ich da was machen?
Danke bis hierhin, wikipedialibrary sieht schon deutlich aufgeräumter aus.
Zugriff@BibISBN ist das Gleiche wie Zugriff@Literatur – Zugriff ist alle und wir kennen nur noch Abruf= und irgendwann sollen die das nicht mehr zulassen und dafür muss das mindestens im ANR aus dem Bestand verschwunden sein.
„gehe ich dabei richtig in der Annahme, dass die Vorlage Literatur nur Ziffern versteht“
Äh, so halb.
Es ist feasible() in Modul:JSTOR und das weiß bislang nichts von resrep25082 und ich auch nix.
Muss ich mal analysieren, was da korrekt ist und ob das saubere stable sind und käme vielleicht was Sinnvolles raus wenn das nur 25082 hieße?
Sodele, wir kennen also ganze 17 URL mit stable und resrep – dann wird das Modul das als Regel für gültige ID lernen müssen und danach kennen das alle anderen auch. Kann sich aber ein paar Tage hinziehn. Wochenende und so, schönes --PerfektesChaos00:00, 21. Okt. 2022 (CEST)
www.jstor.org/stable heißen stable weil sie halbwegs stabil sein sollten; es gibt aber etliche andere Pfade und Sub-Domains. Die stable waren früher auch mal alle offen zugänglich, glaube ich. Die anderen Pfade oft nicht. Wir beschränken uns auf den Mainstream.
www.jstor.org/stable zum Austricksen der URL-Detektierung war aber auch schon bööööse; muss ich gelegentlich mal Gegenmaßnahmen ergreifen.
Wenn die fertig, hätte ich zum Ende kommender Woche noch eine längere wikipedialibrary-Serie.
@BandReihe: Das war in der WSTM-Programmierung sogar schon vorgesehen gewesen, aber ein wichtiges Zahnrädchen fehlte noch, und je nach Temperament des Browsers könnte das sogar einen Crash bewirkt haben. Glaub ich aber nicht, denn das schlummerte schon fünf Jahre unbemerkt und hätte jedes BandReihe=was zum Absturz bringen müssen. Kommt demnächst unaufgefordert.
Hatte bisher eine unzulässige falsche Linkbeschriftung bewirkt.
Weil ich im Zuge obiger Angelegenheit da rangegangen war, habe ich das jetzt auf Migration+veraltet gesetzt.
Wenn da ein Weblink auf eine fremde Ressource steht, dann muss die Verlinkung kennzeichnen auf welche Website sie geht, Google oder wer auch immer, und wir geben die ID im Klartext sichtbar an.
Vorrangig wären jetzt erstmal {{JSTOR|2=JSTOR}} weil die sehen momentan besonders dusslig aus.
Patentrezept habe ich keins; muss im Einzelfall nach ZR ggf. großflächiger umgebaut werden.
zu den fünf Jahren, da hattest du zu BandReihe folgende Aussage gemacht: "denn das schlummerte schon fünf Jahre unbemerkt", darauf hatte ich das gemünzt. Wer weis, was du noch so alles in deinem Quellcode hast ;) ;)
JSTOR schaue ich mir an. Wir haben ja auch noch die Weiterleitung von Jstor nach JSTOR, soll diese dann perspektivisch auch entfallen, oder soll die dann bestehen bleiben?
„Weiterleitung von Jstor nach JSTOR“ – von der weiß ich noch nicht mal was, aber WSTM kennt den.
Nee, sowas soll behutsam aussterben, aber ohne Tränchen.
Dieser ganze Weiterleitungsdschungel bringt niemandem etwas und macht Suchvorgänge und Ersetzungen nur unendlich kompliziert. Wurgl braucht dann wohl auch noch eine zweite Analyse dafür, oder besondere Schalter, das kommt dann davon.
Ich weis ja nicht, wie schlimm folgendes ist. ISB-Nummer formatierst du ja, das ist auch total super. Aber nun habe ich gesehen, dass auch bei BibISBN eine Formatierung vorgenommen wird. Siehe mal hier. Da sind die BibISBNs nun alle auch mit Strichen getrennt worden. Weis ja nicht, ob das so sein soll/muss, da die Vorlagen immer noch ohne Striche sind.
Naja, dir ist aber schon aufgefallen, dass trotzdem die richtigen Bücher in der Darstellung angezeigt werden? Und dass in der Liste der eingebundenen Vorlagen die ISBN-Untervorlagen aufgezählt werden, nur ohne Strichelchen? Lässt darauf schließen, dass BibISBN schon seit Jahren mit gestrichelten ISBN umgehen kann.
Bei der Bearbeitung sollen grad die 13-stelligen Bandwürmer strukturiert erscheinen, damit mehrere Bücher aus demselben Verlag nicht verwechselt werden. Diese Gliederung ist für die Menschen gemacht, und WSTM weiß das nunmehr auch.
zu BibISBN: Es war mir halt nur aufgefallen, dass da nun Strichelchen zugekommen sind. Ja, Darstellung at all ist gleich. Hatte nur im ersten verwirrt und ich dachte, ich sage Bescheid, bevor ich damit auf lange Sicht war kaputt machen könnte.
JSTOR: Kannst ja mal schauen, ob dir das so gefällt.
Jstor: Habe ich nun auch geleert/aufgeräumt und habe ich mal auf'm Plan, schaue da so in einer Woche nochmal und werde das Ding dann als unnötige WL löschen.
URN und Urn (WL) haben auch einen veralteten Parameter 2, wäre der analog zu JSTOR ebenfalls aufzulösen?
Zugriff@BibISBN => noch auf dem Schirm, bei Zeiten
Nö, lohnt keine Edits und nerven der Beobachtenden.
Macht nur aus | ein : und richtet optisch und in der Verwendung keinen Schaden an.
Wenn ich mich mal langweile, löse ich für alle NR einen Bot-Auftrag aus; aber da habe ich viel wichtigere in der Pipeline.
Ist ein Relikt aus der Vor-Lua-Ära; mangels Zeichenkettenverarbeitung mussten die das in zwei separate Parameter packen.
Den einzigen Unterschied würde man bei Quelltext-Durchsuchung nach dem Code merken, aber das macht eh kaum einer und de:Dingsbums wäre charakteristisch genug, um das sogar über Google zu finden.
JSTOR
Fein, fein, dann werde ich mal Schnüffelkat vor dem endgültigen Aufräumen einbauen.
Zugriff@BibISBN
Wieso, sind doch alle?
Schon vorgemerkt für gelegentliche Schnüffelkat.
jstor und urn könnten allerdings unauffälliges allmähliches Wegputzen und Eigen-SLA abbekommen. Vorsicht, dürften immer dieselben wenigen Autoren gewesen sein.
„sonst noch was“ – Tausende, aber muss ja immer geplant und präzise beschrieben werden.
In administrativer Eigeninitiative ausgelöster SLA auf WP:VAR →BKS; Begründung: Nicht mehr benötigter Shortcut, Freigabe der Buchstabenkombination für neue Verwendung
Gartenlaube: Habe ich mir mal angeschaut und festgestellt, sind auch in Parameter 3 noch welche, baue ich raus. Es kommt aber ein "aber", die Artikel Allerheiligen-Wasserfälle und Wilhelmine Schröder-Devrient, da bin ich lost, wie ich das umsetzen kann. Könntest du da mal schauen?
Linkfixe: Einer ausgebaut, Tommes angeschrieben (auf Beobachtung), SLA danach
Wikisource: Könntest du mir vllt. bei der Vorlage eine Schnüffelkat einbauen nach dem Parameter 3, nur damit ich mal ein Gefühl bekomme, was da noch in den restlichen Namensräumen schwirren könnte?
In Sachen Benutzerseite: Du hast es auf die BD geschrieben und das neue Linkziel hinterlassen, Zeit genug war, und dann kann jetzt zur administrativen Tat geschritten werden. Benutzer ist grad seit einer Woche nicht aktiv, warum weiß ich nicht, meist wäre der Grund im Logbuch nachzulesen. Dass das hier nicht flutscht war mir irgendwie klar. Es gibt keine Verpflichtung, erst auch noch die BNR-Verlinkung korrigiert zu bekommen, bevor gelöscht werden dürfe. Dann eben erstmal Rotlink und selbermachen.
Ich war gestern abend zu erschöpft und habe die Schnüffelkat in allen Einbindungen ausgelöst; heut mittag müsste die Kat realistisch sein.
Bei Wilhelmine Schröder-Devrient ist das im Abschnitt „Weblinks“ schon völlig okay. Es wird ja keine gedruckte Literatur verlinkt, sondern auf der Website Wikisource ein Inhaltsverzeichnis angeboten, welche digitalen Reproduktionen sie anbieten würde. Wir müssten ansonsten alle 14 Einzelausgaben bibliografisch auflisten.
Du hattest mit diesem 3@Wikisource angefangen, das hast du nun davon.
Das kann jetzt Zug um Zug wohl ausgenommen Commons*** durchgezogen werden; unbenannte 3. Parameter sind dann Geschichte. Weiß keiner mehr was die bewirken sollen.
@Lómelinde:Danke für den Tipp! Hallo, verstehe ich richtig, wenn ich die PMID in der Form „[[...:...]]“ angebe, dann sollte ich besser pmid klein schreiben nicht PMID groß? Also „[[pmid:...]]“ ?
Hintergrund: Ich hatte bis vor Kurzem die PMID immer als „PMID ...“ ohne eckige Klammern und Doppelpunkt angegeben. Das hat irgendwann einmal nicht mehr geklappt. Da hatte ich gesehen, dass es mit „[[PMID:...]]“ besser klappt. Habe est kürzlich gesehen, dass es mit „[[pmid:...]]“ auch geht. Sind alles Erfahrungswerte ;-), ich bin mit dem Recherchieren zu den Sachthemen völlig ausgelastet, bin jetzt erst wieder über einen offensichtlichen Fehler in der LPSN(!) gesolpert, hat mich viel Zeit gekostet. Umso lieber sind mir diese Tipps:-)! Fazit:
Künftig „[[pmid:...]]“
Bitte lass mich wissen, wenn es nötig sein sollte, dass ich über meine letzten Artikel (Deine Beispiele wie ich sehe) gehen, um das abzuändern. Viele Grüße--Ernsts (Diskussion) 16:53, 26. Feb. 2023 (CET)
Das muss der Toolbetreiber entscheiden, ob er seinem Tool die geklammerten Großbuchstaben beibringt. Ich möchte nur verhindern, dass durch das Tool versehentlich Links zerstört werden. Daher der Hinweis an ihn und der Ping an dich, weil ich so etwas bisher noch nicht hatte. --Liebe Grüße, LómelindeDiskussion17:02, 26. Feb. 2023 (CET)
Moin zusammen, ich hatte in meine Konfiguration ein bisschen was reingeschrieben, dass Doppelpunkte zwischen PMID und Nummer entfernt werden. mfg --Crazy188018:24, 26. Feb. 2023 (CET)
Also ich kann natürlich wieder wie früher ohne alles nur „PMID ...“ schreiben und wenn ich wieder einen Fehler bekommen sollte, der nur im Format „[[pmid:...]]“ oder „[[PMID:...]]“ zu beheben wäre, melde ich mich. Wie sollte ich mit den Artikeln aus Lómelindes Liste verfahren, Abändern (jetzt auf „ohne nix“)?--Ernsts (Diskussion) 19:59, 26. Feb. 2023 (CET)
Änderungen sind ausgeführt, die obige Suche liefert keine Treffer mehr. Hoffe, dass die PMIDs auch alle funktionieren. Kann das aber bei künftigen Artikelübersetzungen und -erstellungen im Auge behalten.--Ernsts (Diskussion) 00:13, 27. Feb. 2023 (CET)
Dankeschön, es kann aber auch mal vorkommen, dass die Seite nur kurzzeitig nicht erreichbar war. Eigentlich sollte es nicht vorkommen dass es nur mit Klammern geht. --Liebe Grüße, LómelindeDiskussion06:33, 27. Feb. 2023 (CET)
Ist sichergestellt, dass die eröffnend beanstandete Änderung auf Original-WSTM zurückzuführen ist?
Ich kann es nicht reproduzieren.
Ich finde in WSTM keinerlei Programmierung mit dieser Wirkung.
In der Zwischenzeit habe ich einen Code von 2010 aufgestöbert, der damals derartige Umstellungen vorgenommen hatte.
Die Methodik ist keine, die ich heutzutage noch anwenden würde.
Ist ein Überrest einer damals zu anderen Zwecken vorgenommenen Normalisierung.
Der von dir aufgestöberte Code von 2012 war dessen geplanter Nachfolger.
Die Methode, dass sowas mit Großbuchstaben und Doppelpunkt und doppelten eckigen Klammern drumrum von irgendjemand verwendet würde, war im letzten Dutzend Jahren niemals aufgefallen.
d online.
Reproduzieren konnte ich die eingangs geschilderte Situation zwar nie, kann aber nachvollziehen dass original.WSTM sowas gemacht haben könnte.
Letzter Kommentar: vor 1 Jahr9 Kommentare3 Personen sind an der Diskussion beteiligt
Moin Moin PerfektesChaos, ich habe mal ein paar Vorlagen gequält gehabt und es ist schon erstaunlich, was in welchen Parameter so alles zu finden ist. Daher gerne Info/Wunsch/Unterstützung:
Vorlage {{Commons}} den Parameter 3 mal mit der Schnüffelkat auszurüsten. Im ANR sollte es schon raus sein.
Vorlage Literatur bin ich noch an vielen Baustellen dran.
Vorlage Literatur/Einzelreferenz, bin ich drauf gestoßen, finde ich vom Quelltext und vom Lesen schwierig, wenn man direkt in den Bearbeitenmodus springt und auf Einmal eine Wikidata-ID in einem Parameter steht.
@Crazy1880: Wenn du durch bist mit der Wartungskat, habe ich auf BETA ein Vielfach-Update bereitgestellt (ungetestet freihändig, aber wird schon stimmen).
Außerdem kannst du mal alle üblichen in der Kat durchgehen, ob sie im Minimum edit=Sichter move=sysop haben, und ansonsten verschärfen.
Damit sind alle gepflegten in ihrer momentanen Form zukunftsfähigen einheitlich aufgerüstet; bis auf Commonscat (da gibt es genauso viele Neuzugänge 3=S wie WSTM zu audio/video konvertiert).
Kopie aus BETA war eingebaut und hatte nochmal 5 Fehlerchen geliefert, welche auch schon ausgebaut/bereinigt sind. Ansonsten bisher an dieser Front alles Commons-ruhig.
Seitenschutz: Ja, da waren welche noch fast ohne unterwegs, die habe ich mal hochgedreht, da es ja schon zentrale und häufige Vorlagen sind.
Meinst du dass bei Commonscat und Parameter 3 vllt. mal ein Bot-Lauf was bringen würde? Ich meine sonst wäre mal bestimmt ein paar Jahre bechäftigt und leider trifft man viel zu wenig auf diesen Parameter um ihn zu beheben.
Commonscat ist aussichtslos, weil es anscheinend sogar mehr Neuzugänge mit kryptischem 3=S gibt als die VE-geeigneten selbsterklärenden booleschen Parameter von WSTM (dem Host dieser Erörterung) weggeschaufelt werden können.
Ursache werden altgediente händisch-Tipper sein, und schlummernde Kopiervorlagen auf Festplatte und in irgendwelchen BNR-Seiten.
Das wird noch ein Jahrzehnt dauern, bis das so ganz allmählich in Vergessenheit gerät.
Bot-Läufe für sowas sind verboten, und irgendwann 30.000 Artikel anzufassen lohnt nicht, zumal 3=S weiterhin unterstützt werden muss, frisch in den ANR kommen wird, niemand gezwungen werden kann das nicht mehr zu tippen, und es ja auch noch andere Namensräume gibt.
Moin PerfektesChaos, dann hatte ich das falsch interpretiert und dacht, dass ich dabei auf die erste Zeile zu achten hätte. Ok, wieder was gelernt. mfg --Crazy188006:37, 22. Mär. 2023 (CET)
Moin PerfektesChaos, ich hätte da mal wieder Dinge ausgegraben ;)
Magst du dir bitte mal den Artikel Griechisch-türkische Beziehungen die Einzelnachweise 19/20 anschauen, da wird JSTOR als Link angemeckert weil im Parameter Online, aber der Short im JSTOR selbst wird als ungültig markiert, beides doof.
Dann habe ich auf meiner Diskussionsseite einen netten Hinweis zur Vorlage Wayarchiv erhalten (Benutzer_Diskussion:Crazy1880#Vorlage:Webarchiv_mit_verschwundener_PDF-Angabe). Persönlich wäre ich lost, ich könnte mir nur Vorstellen, dass der Parameter Online von der Vorlage Literatur vor der Vorlage Webarchiv etwas anderes erwartet, kann es aber nicht beweisen.
Dann bin ich an den Vorlagen "Infobox Schiff" gerade dran, da mal durchzufeudeln und die falschen Parameter zu korigieren. Ich würde dann auch gleich TemplateData hinterherschieben wollen, weis aber nicht, ob das in diesem komischen Konstrukt mit den einzelnen Untervorlagen so einfach möglich wäre. Da bräuchte ich später vllt. mal eine Expertize von dir.
Deine präzise Angabe zum Artikel und die Fehlermeldungen ermöglichten eine zügige Behebung.
In Kandidatenzüge steht ein etwas unkonventionell kurzes Schachbrett, das vor einem Dutzend Jahren bei Formatierung derartiger Einbindungen noch nicht bekannt gewesen war.
Naja, es wird halt ein Schachbrett mit 8 Zeilen und 8 Spalten erwartet. Das ist schlicht nicht vorhanden; kann sein dass das gewollt ist, kann sein dass nicht. WSTM weiß das auch nicht.
Letzter Kommentar: vor 1 Jahr1 Kommentar1 Person ist an der Diskussion beteiligt
Hallo PerfektesChaos, durch Benutzerin:Lómelinde bin ich gerade darauf aufmerksam gemacht worden, dass umseitiges Skript das Durchmesserzeichen ⌀ standardmäßig gegen den Buchstaben ø tauscht. Das scheint mir im Fließtext sinnvoll zu sein. Nun habe ich aber schon mehrfach gesehen, dass in Artikeln zu Schiffen das Durchmesserzeichen (bspw. für die Angabe von Propeller- oder Torpedorohrdurchmesser genutzt) durch den Buchstaben ersetzt wurden, in diesem Beispiel durch Lómelinde per WSTM. Das geht ja am eigentlichen Ziel dieser automatischen Ersetzung vorbei und erzeugt Zusatzaufwand. Nun meine Frage, da ich von der Skriptprogrammierung keine Ahnung habe: Ist es möglich, dem Skript beizubringen, das Durchmesserzeichen nur in Fließtexten, besser nur in Wörtern zu ersetzen, aber nicht dort, wo es eben wirklich einen Durchmesser kennzeichnen soll? Wie gesagt, von der technischen Umsetzung verstehe ich nichts, stelle mir das aber etwa so vor, dass das Skript nachsieht, ob direkt vor oder nach dem Zeichen ein anderer Buchstabe steht (das ø steht ja üblicherweise in Wörtern, das Durchmesserzeichen nicht). Sollte der Aufwand für diese Änderung am Skript zu groß oder das Ganze gar nicht möglich sein, dann muss eben weiter händisch nachgearbeitet werden. --Ambross (Disk) 15:43, 8. Apr. 2023 (CEST)
Beispiel für style-Definitionen
Letzter Kommentar: vor 1 Jahr2 Kommentare2 Personen sind an der Diskussion beteiligt
Das sind Eigenschaften von params.style – und dieses ist in der Übersicht als „(geplant)“ ausgewiesen.
Die Programmierung ist teilweise sogar realisiert, wird mindestens intern seit einem Jahrzehnt ausgiebig genutzt.
Den Ansatz einer Schnittstelle nach außen hatte ich 2012 mal begonnen, dieses jedoch wegen langjährigem Ausbleiben einer Nachfrage wieder eingestellt. Mittlerweile habe ich 50 Tools in JavaScript, die Betreuung von Hunderten an Hilfeseiten und Technik-Projketseiten, Maintenance für 50 Lua-Module und Hunderte an Vorlagen an der Backe; übernehme außerdem noch die Reinhaltung des Vorlagen-Namensraums insgesamt und komplexe Migrationsaufaben unserer Infrastruktur. Damit gibt es keinerlei Kraft und Zeit und Nerven mehr, um mich um Nischenthemen zu kümmern.
Letzter Kommentar: vor 1 Jahr3 Kommentare2 Personen sind an der Diskussion beteiligt
Moin PerfektesChaos, ich hätte da mal wieder Dinge ausgegraben ;)
Magst du dir bitte mal den Artikel Griechisch-türkische Beziehungen die Einzelnachweise 19/20 anschauen, da wird JSTOR als Link angemeckert weil im Parameter Online, aber der Short im JSTOR selbst wird als ungültig markiert, beides doof. (Hierzu hatte Lómelinde schon angemerkt, dass es sich um die Kapitel handeln würde, aber vllt. könnte man da auch irgendwas machen?)
Dann habe ich auf meiner Diskussionsseite einen netten Hinweis zur Vorlage Wayarchiv erhalten (Benutzer_Diskussion:Crazy1880#Vorlage:Webarchiv_mit_verschwundener_PDF-Angabe). Persönlich wäre ich lost, ich könnte mir nur Vorstellen, dass der Parameter Online von der Vorlage Literatur vor der Vorlage Webarchiv etwas anderes erwartet, kann es aber nicht beweisen.
Dann bin ich an den Vorlagen "Infobox Schiff" gerade dran, da mal durchzufeudeln und die falschen Parameter zu korigieren. Ich würde dann auch gleich TemplateData hinterherschieben wollen, weis aber nicht, ob das in diesem komischen Konstrukt mit den einzelnen Untervorlagen so einfach möglich wäre. Da bräuchte ich später vllt. mal eine Expertize von dir.
wird nur akzeptiert für komplette Zeitschriften; Einzelkapitel und interne Links sind nicht stable.
Kann sich also über die Zeit ändern; kein Anlass etwas an der Gültigkeitsregel zu ändern.
Mittlerweile werden gern mal JSTOR-Seiten Abo-pflichtig; um so mehr genügt es, nur auf die Startseite zu verlinken.
Immer mehr Digitalisierungsangebote gehen dazu über, erstmal auf der Startseite eine Format-Auswahl als PDF, eBook, HTML anzubieten; dann sind die internen Links auch hinüber.
Ein Kapitel hat sich dauerhaft aus den universellen bibliografischen Angaben zu ergeben; wie man dann von JSTOR zu einem Kapitel oder einer Seitenzahl navigiert, kann sich über die Zeiten ändern.
PDF Wayback
Original-WSTM macht da mit großer Sicherheit nix dran.
WSTM sieht nur, dass in Online= kein syntaxfreier offener Text steht, und ignoriert den Rest und das Innere.
Infobox Schiff
Das ist völlig verbastelt.
Da müsste schon gelangweiltes VWS-Personal ran, und das haben wir in der Ära LINT nicht.
Erstmal müssten diese dussligen unbenannten zu UnterBox1= usw.
Moin PerfektesChaos, FYI, eine Million Einbindungen der Vorlagen Literatur im ANR, hat doch mal was, oder? mfg --Crazy188010:58, 16. Mai 2023 (CEST)
doofes Fehlerchen bei den Zahlen
Letzter Kommentar: vor 1 Jahr4 Kommentare2 Personen sind an der Diskussion beteiligt
Moin! Ich schreib das Dings gerade um und dabei ist mir aufgefallen, dass bei der veralteten Syntax die Zahlen von "bgcolor" falsch sind. Ich hab die Anzahl an Artikeln gezählt und nicht die Anzahl an vorkommen dieses Tags. Also statt 55.843 Artikel sind es 1.275.404 Vorkommen (PHP-Funktion preg_match statt preg_match_all). Benutzer:PerfektesChaos/js/WikiSyntaxTextMod/usage/lang/dewiki#Anhang:_Statistik Bei "width" gibts auch eine kleine Diskrepanz, da muss ich noch suchen, 940.527 vs. 940.530 ist aber nur statistisches Rauschen. Die anderen Zahlen dieses Blocks passen aber. Asche auf mein Haupt. --Wurgl (Diskussion) 09:12, 13. Jun. 2023 (CEST)
Du könntest ja zu einem fiktiven Stichtag „1. Juli“ mit einem Halbjahresstand überschreiben; das verrät dann bereits eine erste Tendenz.
Spannend wäre das Gegenstück; also style= zum Vergleich.
Und die jeweils zugeordneten text-align: oder vertical-align: oder background: bzw. background-color:.
Ist mir klar, dass das etwas tricky ist wegen Vorlagenparametern und Pipe-Tabellensyntax.
Restlos vergleichbar ist es ohnehin nicht, weil class="toptextcells" usw. alternativ verwendet werden können und die style= sich vererben lassen, während HTML für jedes Element einzeln angegeben werden muss.
Diesen Unterschied bei "width" hab ich auch gefunden. Der Änderungskommentar in Spezial:Diff/233002159 *seufz* … wie gesagt, ich mach das jetzt ganz anders und besser. Vor der Zählung werden HTML-Kommentare rausgenommen, ebenso Weblinks, ein paar Tags wie nowiki, code, syntaxhighlight, pre, math und score. Und danach noch die Template-Parameter. --Wurgl (Diskussion) 13:00, 13. Jun. 2023 (CEST)
Was ist das denn?
Letzter Kommentar: vor 1 Jahr2 Kommentare2 Personen sind an der Diskussion beteiligt
Ehe ich in dem Artikel hier Query-String nach der falschen Sprache suche, ist html4strict soweit ist das klar, aber warum macht WSTM aus den Zeichen im {{#tag:syntaxhighlight maskierte < -Zeichen und ändert sie zu < nicht alle, die lable-Zeile bleibt wie sie ist.
Naja, <form> gehört zu den explizit ganz doll verbotenen Elementen und WSTM wendet sich mit Abscheu und deaktiviert das. <input> genauso.
Dass das nun über #tag:syntaxhighlight hinterher doch nicht wirkam wird, aber wegen {{#time:Y-m-d}} dann doch erstmal ausgewertet wird, durchschaut WSTM nicht.
Mit {{Char|60}} kannst du hier das < jedoch so verstecken dass WSTM es nicht findet und das Ergebnis trotzdem echt aussieht.
Schon schade, dass so ein Skript immer das Durchschnittszeichen gegen einen Buchstaben tauscht
Letzter Kommentar: vor 1 Jahr4 Kommentare3 Personen sind an der Diskussion beteiligt
→Spezial:Diff/235486839/235492643 tatsächlich scheint WSTM das zu tun ⌀ → ø, das kann doch eigentlich nicht richtig sein, oder? Also mir war es nicht aufgefallen, dass das hinterher ein Ö ist, kannst du das bitte ändern? Siehe auch Ø#Verwendung als Ersatzzeichen Zitat: „Das große Ø wird gelegentlich aus technischen Gründen anstatt der ähnlich aussehenden Zeichen für Durchmesser bzw. Durchschnitt (arithmetisches Mittel) und Leere Menge (∅) verwendet. Dies ist jedoch typografisch falsch und sollte grundsätzlich vermieden werden“ zumal das auch noch des kleine ø ö wäre, was meiner Meinung nach schlechter lesbar ist. CC: Ambross07.--Liebe Grüße, LómelindeDiskussion11:09, 15. Jul. 2023 (CEST)
Hallo Lómelinde, ich hatte das Thema hier vor einigen Monaten schon mal angesprochen, aber leider keine Antwort bekommen. Danke, dass du es noch einmal anschneidest. --Ambross (Disk) 11:21, 15. Jul. 2023 (CEST)
Der Grund ist, dass das Unicode-Zeichen nicht in allen Fonts vorhanden ist und es dadurch zu Darstellungsproblemen kommen kann.
Ich hatte dazu bereits auf die erste Anfrage hin umfangreiche Recherchen begonnen, aber da täglich ein Dutzend neue Angelegenheiten auf mich einprasseln, ist das dann irgendwann in der Liste offener Aufgaben ersoffen.
Die Darstellung im zitierten Artikel bezieht sich auf die Situation, dass ein Word-Dokument neu geschrieben wird und man die verwendeten eigenen Fonts vollständig unter Kontrolle hätte. Dort sollte es tatsächlich so gemacht werden. Das ist aber bei der Darstellung einer Webseite, wo wir das Erscheinungsbild beim Publikum nicht kennen, nicht der Fall.
Der Buchstabe ist jahrzehntelang, die 1980er und 1990er und 2000er hindurch als legitimes Ersatzzeichen verwendet worden. Semantisch muss damit interpretierbar sein, wie sowas vor einer Zahl gemeint ist.
Was ich ermittelt hatte, war, dass es immer noch Konfigurationen bei unserer Zielgruppe gibt, die an dieser Stelle ein Rechteck für Unbekannt darstellen. Das ANSI-Zeichen ist hingegen gesichert in der Minimalausstattung.
Ich habe auch mal Technisches Zeichnen mit Tuschefüller gelernt, und das kleine Zeichen sieht auch genau so aus wie es vor einer Maßzahl aussehen soll, während das Unicode-Zeichen für den deutschen Sprachraum meist zu groß ausfällt. Erkennen muss es eigentlich niemand, weil ein kleiner Kuller vor einer Maßzahl ist immer der Durchnmesser eines kreisrunden Bauteils; dazu gibt es noch ein gleichgro0es Quadrat, und das ist die Seitenlänge eines Bauteils mit quadratischem Querschnitt.
Ich habe keine Zeit, mich um allgemeine Aufgaben zu kümmern, für die ich länger als fünf Minuten am Stück denken müsste.
Ich bin heute geschmolzen und weggeflossen, habe kaum noch Kraft für einen Mausklick und schaffe kein Drag&Drop mehr, weil ich die Maustaste nicht gedrückt halten kann.
Nun sieht die auf den ersten Blick ja ok aus 13-stellig, wenngleich 1911 dann nicht passen kann. Sie existiert aber scheinbar nicht, ich weiß nicht, ob das wichtig wäre. Es passiert aber etwas, was nicht passieren sollte. WSTM versucht es umzuformen und macht dabei aus 978-9-92504-435-1 → 978-9925-504-435-1 und meckert danach, dass zu viele Ziffern da sind.
Es sollte aber das hier 978-9925-04435-1 werden.
{{Literatur |Autor=Albert Bielschowsky |Titel=Goethe Sein Leben und seine Werke |Band=1 |Verlag=Verone (Nachdruck) |Ort=Nikosia |Datum=1911 |ISBN=978-9925-504-435-1 |Seiten=102}}
Lösche ich jetzt die überzählige (hintere) 5 und starte WSTM erneut dann wird daraus für 1911 eine 10-stellige ISBN 9925-04435-9, weil 1911 < 2007
Albert Bielschowsky: Goethe Sein Leben und seine Werke. Band1. Verone (Nachdruck), Nikosia 1911, ISBN 9925-04435-9, S.102.
Lösche ich die vordere, dann wird sie nach dem Start erneut eingefügt und die 978- bleibt. Es scheint nur bei dieser 978-9-92504-435-1 Strich- und Ziffernfolge aufzutreten und passiert auch, wenn ich die ISBN 978-9-92504-435-1 ohne Vorlage teste. --Liebe Grüße, LómelindeDiskussion18:58, 13. Okt. 2023 (CEST)
Hm, klingt ungesund. Danke für den Hinweis.
Der Code ist seit einem Jahrzehnt unverändert.
Das Problem trat nie auf; hängt wohl mit der hohen 9-ISBN zusammen.
Ich habe alles vergessen.
Ich versuche mal, dieses Wochenende was nachzuvollziehen.
9926 – Bosnien und Herzegowina könnten wir anbieten.
WSTM (und Lua) sind nicht aktuell; es gibt neue Staaten.
WSTM kann grundsätzlich wohl nicht gut mit der Situation umgehen, dass die Gruppennummer unbekannt ist; soll dann aber eiiiiigentlich nix machen und nur meckern.
Nach aktuellem Datenstand soll es sich um Zypern handeln.
Naja, wird dann halt in Lua und WSTM einzupflegen sein.
Letzter Kommentar: vor 10 Monaten3 Kommentare2 Personen sind an der Diskussion beteiligt
WSTM formatiert
*{{Internetquelle|url=https://bieterportal.noncd.db.de/evergabe.bieter/api/supplier/subproject/f9d002a9-d433-4b66-880f-89f432141efa/projectFilesZip |titel=Projektsteuerung K<!--sic-->apazitive Optimierung Knoten Lehrte |titelerg=Anlage Nr. 1.0 zum Vertrag Nr. 21FEI56665 |werk=bieterportal.noncd.db.de |seiten=3 f. |datum=2021-12-14<!--laut Metadaten-->|archiv-url=https://web.archive.org/web/20220123151101/https://bieterportal.noncd.db.de/evergabe.bieter/api/supplier/subproject/f9d002a9-d433-4b66-880f-89f432141efa/projectFilesZip |archiv-datum=2022-01-23 |abruf=2022-01-23 |format=PDF |kommentar=Datei ''1.0 Maßnahmenbeschr. u. Vorbemerk._21FEI5665.pdf'' in ZIP-Archiv |offline=ja |archiv-bot=2022-10-07 19:42:23 InternetArchiveBot }}
zu
*{{Internetquelle|url=https://bieterportal.noncd.db.de/evergabe.bieter/api/supplier/subproject/f9d002a9-d433-4b66-880f-89f432141efa/projectFilesZip |titel=Projektsteuerung K<!--sic-->apazitive Optimierung Knoten Lehrte |titelerg=Anlage Nr. 1.0 zum Vertrag Nr. 21FEI56665 |werk=bieterportal.noncd.db.de |seiten=3 f. |datum=2021-12-14<!--laut Metadaten-->|format=PDF |offline=1 |archiv-url=https://web.archive.org/web/20220123151101/https://bieterportal.noncd.db.de/evergabe.bieter/api/supplier/subproject/f9d002a9-d433-4b66-880f-89f432141efa/projectFilesZip |archiv-datum=2022-01-23 |archiv-bot=2022-10-07 19:42:23 InternetArchiveBot |abruf=2022-01-23 |kommentar=Datei ''1.0 Maßnahmenbeschr. u. Vorbemerk. 21FEI5665.pdf}}
um Spezial:Diff/237284797/238165067. Es geht im den Bereich |kommentar= dadurch, dass dort ein Teil des Textes eliminiert wurde, entsteht zudem ein Linterfehler.
* |kommentar=Datei ''1.0 Maßnahmenbeschr. u. Vorbemerk._21FEI5665.pdf'' in ZIP-Archiv
* |kommentar=Datei ''1.0 Maßnahmenbeschr. u. Vorbemerk. 21FEI5665.pdf
Der Fehler ist nicht mir passiert, aber ich habe es getestet und auch bei mir würde das passieren. Ich vermute mal da ist schon vorher etwas schief gegangen und das hätte zur URL https://bieterportal.noncd.db.de/evergabe.bieter/api/supplier/subproject/f9d002a9-d433-4b66-880f-89f432141efa/projectFilesZip_21FEI5665.pdf gehört. Tut aber nichts zur Sache oder, na ja, im Prinzip schon, Auslöser ist nämlich der _. --Liebe Grüße, LómelindeDiskussion14:59, 15. Okt. 2023 (CEST)
Da sind zu viele HTML-Kommentare drin.
Die Gesamtsituation ist mir rätselhaft; insgesamt kein typisches Phänomen.
Ein identifiziertes URL-Stück im Kommentarparameter war dann zuviel.
Die Leut sollen schreiben, was wichtig ist, und das auch für alle sichtbar. Und was unwichtig ist, einfach weglassen. Aber dieses Überfrachten mit lauter Fitzelchen, die niemand sehen kann und die niemand interessieren, ruiniert dann die Bearbeitbarkeit im VE und treibt die (nur zusätzliche) WSTM-Korrektur in den Wahnsinn.
Wenn das jemand nach Datum in einer Excel-Tabelle auswerten möchte, dann kommt dieser ganze Mist hoch und ruiniert Bots und Skripte und Textsuchen.
Das Format der URL-Ressource ist dann übrigens Zip und nicht PDF wie fälschlich behauptet.
Und der Hinweis, es wäre eine Datei 1.0 Maßnahmenbeschr. u. Vorbemerk. 21FEI5665 in diesem Zip enthalten langt völlig. Ist sowieso eine arme Sau, die das aus dem Archiv rauspulen sollte, wenn überhaupt irgendwann, und ob das dann im Webarchiv auch noch alles ewig klappt steht dahin.
Wie gesagt, ich war da nur wegen des Linterfehlers, habe nach der Ursache gesucht, in die VG geschaut und fand es merkwürdig, dass der Benutzer da einen Teil des Kommentars gelöscht hat. Da ich sah, dass bei dem Edit auch typische WSTM Umformatierungen erfolgt sind, habe ich halt genauer nach dem Auslöser gesucht. Es passiert nur, wenn da so ein Unterstrich im Text steht. --Liebe Grüße, LómelindeDiskussion06:32, 16. Okt. 2023 (CEST)
Letzter Kommentar: vor 10 Monaten1 Kommentar1 Person ist an der Diskussion beteiligt
Was es nicht so alles gibt, wer macht bloß so etwas? Damit hat WSTM hier Überblicksliste der ISO-639-3-Codes ein Problem, es fügt Leerzeichen hinter dem öffnenden <span ein und meckert mich an (ich kann nichts dafür), dass es akut nix mit so einer Anweisung anfangen kann. <span {{ISO639-3-Style|M|L}}>'''M''' = ''macrolanguage'' ([[Makrosprache (ISO 639)|Makrosprache]])</span>
Falsches Attribut-Format im Tag
<span {{ISO639-3-Style|M|L}}
…
Letzter Kommentar: vor 9 Monaten8 Kommentare2 Personen sind an der Diskussion beteiligt
Moin PerfektesChaos, ich hätte da mal Sachen/Fragen:
Für die Vorlage Internetquelle setzt WSTM wenn die URL PDF ist ein Format=PDF, wir hatten uns ja schonmal unterhalten, ob das für die Vorlage Literatur auch machbar wäre. Da würde es mir einiges an Arbeit vorab abnehmen, wenn das möglich wäre. Hat aber keinen Stress und wenn es nicht geht, auch nicht schlimm, bekomme ich auch so hin.
Vorlage Commonscat, da habe ich leider zwei Fragen:
Ich habe da einen Fall, da bin ich mir nicht ganz sicher, wie ich den aufgelöst bekommen soll. Es geht augenscheinlich darum, dass vom Commonscat nur das Icon dargestellt werden soll, mehr nicht. Handelt sich im Sunshine live „Die 90er – Live On Stage“. Vielen Dank für einen Rat.
Wenn ich eine Schnüffelkat nur erstmal für den Wikipedia-Namensraum auf den Parameter 3 bräuchte, wie müsste man das am Besten da einbauen? Die Basis für die Eleminierung von Parameter 3 ist gelegt und die leer-Konstellationen habe ich bereits raus.
Hattest du die ganzen neuen Vorlagen von Benutzer Ssgl gesehen? Da wäre die Frage, tut das so Not oder müsste man da den Kollegen mal einfangen? Ich weis leider nicht, was da noch alles kommen soll, finde das aber schon arg kompliziert, was da gemacht wird.
Online= ist nicht nur eine URL, sondern kann auch formatierte Weblinks und für mehrere Bände oder Kapitel auch mehrere formatierte Weblinks enthalten.
Es können mehrere Kapitel als formatierte Weblinks mit nachgestelltem individuellem [PDF; 78 kB][PDF; 87 kB] auftreten. Wenn dann gleichzeitig Format=PDF gesetzt wird, gibt es Bruch.
Ist also nicht so trivial wie bei url= und mir deshalb als Feature für alle zu heikel.
Es gibt keine solchen Einbindungen; das war mal eine geistige Verirrung früher Jahre. Was in dem Quelltext mit bewusstem Austricksen per nowiki angestellt wurde ist schon bald kriminell.
Verlinkung fremder Projekte geht per Interwiki-Link.
Den Icon braucht es hier nicht. Interwiki-Link mit Linktext Commons reicht für diese Spalte.
Über eine barrierefreie Vorlage:IconCommons ließe sich reden, mit |px=20 oder was als Vorgabe. Vorlage:MediaWiki/Logo gäbe es mit sehr viel mehr Service; weil vielgestaltiger und Historie. Bei den Denkmallisten usw. wird auch gern mal dekoriert.
Commonscat|3= bleibt für unsere Veteranen aus den Nuller Jahren noch lange Zeit am Leben; gibt sonst wieder Drama. Eine komplette Eliminierung ist nicht vorgesehen, im BNR können auch noch Entwürfe schlummern.
Bei Commons und Commonscat stufe ich gleich 3= runter von „Alias“ auf „veraltet“.
Relevante Projektseiten lassen sich mit hastemplate:Commonscat und pfiffigem insource:/Commonscat *\|[^|}]*\|[^|}]*\|/ (ungetestet) usw. 3=commonscat detektieren.
Siehe VWS, eigener Abschnitt, nach administrativer Ansprache kann ja dann zum vereinbarten Zeitpunkt durch bislang unbeteiligten Admin Massen-SLA abgearbeitet werden.
Moin PerfektesChaos, ich mal wieder ;) Nervensäääge:
Vorlage Zitat-ar und Zitat-ja sind nicht mehr im ANR, wie sähe es mit einer Löschung aus?
Zu Kategorie:Wikipedia:Vorlagenfehler/Vorlage:Literatur hätte ich mal eine Frage. Wollen wir die Temp1, 2 , 3, 4 nicht mal auflösen? Und auch Parameterfehler könnte man doch direkt auf dieser Ebene anzeigen oder ist da noch was geplant?
so zwei drei andere Baustellen habe ich noch, da muss ich aber erstmal noch dran arbeiten ;)
Erst die nächste Generation in einigen Jahren wird das können. Das braucht aber knapp ein halbes Jahr, in dem ich zu nichts anderem kommen würde, und das habe ich nicht und andere Leute bekämen es nicht auf die Kette.
In der Doku zu Vorlage:Zitat steht auch ausdrücklich drin („Vereinfachte Fremdspracheneinbindung“), dass nur lateinisch verschriftete migrieren sollen. „können einstweilen belassen werden“ bedeutet im Klartext: müssen so verbleiben.
Sowas mag ja nett gemeint sein, aber der RTL-Text ist ja noch nicht einmal mit ‎ gegen Quelltext-Achterbahn geschützt. Ich glaube, WSTM macht sowas automatisch, aber natürlich nicht bei einem Text in einer LTR-Vorlage.
ja ist wenigstens LTR; und Vorlage:Zitat-ja stellt auch nix Besonderes damit an.
Nirgends eingebundene LTR-Vorlagen kannst du per Selbst-SLA auf kleinem Dienstweg eliminieren, aber die müssen dann auch aus BNR und Disk raus sein.
Die Temp-Kats bleiben auf Vorrat in Bereitstellung, bis ich irgendwann mal Zeit und Gelegenheit habe, die nächste Parameterumstellung anzugehen, und sie dann wieder benötigt werden.
Das ist dazu da, um unmittelbar hinter einen Text geschrieben zu werden, und zwar ohne ein Leerzeichen davor (ggf. aber gern danach, wenn kein Zeilenumbruch folgen sollte).
In dem von dir dargestellten Fall fehlt der Text, und dann schreibt WSTM das eben hinter das letzte auffindbare nicht-leere Zeichen.
Syntaktisch ist das, was du beanstandest, völlig einerlei; das Resultat ist immer das gleiche, egal ob zwischen Pipe und <br /> oder zwischen irgendeinem Text und <br /> irgendein oder mehrere Leerzeichen stehen würde, oder keins. Weil die Regel von HTML für den Fließtext fordert hier ohnehin, dass die begonnene Zeile „getrimmt“ werden müsse, also dass Weißraum vor und nach der dargestellten Zeile zu entfernen ist.
Verständlicher für das Publikum wäre ohnehin, wenn da nicht einfach unmotiviert eine Lücke wäre, sondern etwa ein breiter Strich wie – oder das etwas kryptische Zeichen ./. oder nicht bekannt oder schlicht ? stehen würde. Das wäre dann auch wieder ein Text, an den das <br /> direkt angeschlossen werden kann.
nowrap
Vor diesen diversen Zellen steht dauernd etwas wie: |nowrap| ''[[ELaNa]]''
Dieses |nowrap| ist ein Syntaxfehler.
Dort dürfte nur eine gültige HTML-Attribuierung stehen.
Wenn du dir erhoffst, dass dies einen Zeilenumbruch verhindern würde – nein, macht es nicht, weil ungültig und absolut wirkungslos.
Vielleicht meinst du: |style="white-space:nowrap"|
Ist aber auch nicht ratsam, gerade weil es ggf. Smartphones bei längerem Text behindert.
Ungeschickter Versuch der Synchronisation.
An der angegebenen Stelle versuchst du offenbar, mit nowrap und den <br /> zu erreichen, dass in der vierten und fünften Spalte die zehn Elemente immer auf gleicher Höhe in den Zeilen stehen.
Das ist aber gefährlich, ohne wirksames nowrap und auf einem schmalen Bildschirm nicht gesichert.
Korrekt lösen wir das anders, und in >80.000 anderen Artikeln sichtbar:
Die erste bis dritte sowie sechste Spalte bekommen ein rowspan="10" als Zellen-Attribut.
In der vierten und fünften Spalte gibt es zwei normale Zellen mit nur einer Nutzlast und Zweck als Inhalt, die dann immer auf derselben Höhe stehen, egal wie lang die Texte werden sollten.
Dann gelten die Texte in der ersten bis dritten Spalte genauso wie jetzt für alle zehn Zeilen der vierten und fünften Spalte.
Dann lassen sich alle Elemente der Spalten auch sortierbar machen.
Benutzerin:Lómelinde hilft dir sicher gern und baut dir das auf Wunsch einmal grundsanierend um.
Die Formatierung der Startlisten mit <br /> zwischen den Nutzlasten wird so bleiben, u.a. weil alles andere elend unübersichtlich wäre. Dann werde ich mal schauen, wie ich die Nutzung deines Tools dort verhindern kann, denn regelmäßige Reverts von Verschlimmbesserungen (dies ist nur eine von mehreren) sind auch nicht sinnvoll. Im konkreten Fall wird wohl ein Workaround per vor dem br funktionieren. --PM310:16, 30. Okt. 2023 (CET)
Textformatierung via Pipelink auflösen
Letzter Kommentar: vor 9 Monaten4 Kommentare4 Personen sind an der Diskussion beteiligt
Hallo PerfektesChaos, eine möglicherweise sinnvolle Ersetzung, die das Skript übernehmen könnte:
[[Text|''Text'']] zu ''[[Text]]''
Gleichermaßen dann auch für Fettung sowie gleichzeitige Fettung und Kursivierung. Der Ausgangsfall wird nervigerweise durch den visuellen Editor beim Formatieren von Wikilinks erzeugt. Ggf. übersehe ich, warum diese Ersetzung nicht immer sinnvoll ist. Danke und besten Gruß --Emberwit (Diskussion) 15:05, 28. Nov. 2023 (CET)
Ja, sowas hatte ich im Lauf der Jahre hin und wieder gesehen und auch schon dran gedacht.
Gäbe auch noch [[A|''B'']], was ebenfalls nicht im Sinne der Erfindung ist, und Suchen und VE stört.
Mein Problem damit ist:
Programmtechnisch ist der Code sehr komplex und nicht einfach nur eine Zeichenkette, die man per RegExp umschreiben könnte.
Vielmehr kommen hier fünf Text-Objekte unterschiedlicher Eigenschaften zusammen, die nur einzeln bearbeitet werden können.
Wenn deren viertes vollständig und unverschachtelt nur in '' bzw. ''' eingeschlossen wäre, könnten diese Teile vor und nach die fünf Text-Objekte geschrieben werden und der Linktext gekürzt werden, und dieser mit dem Linkziel verglichen werden (unter Schreibung des ersten Buchstabens), was ggf. eine weitere Kürzung um zwei Objekte auslösen könnte.
Das hatte ich 2012 mal programmiert; damals hätte ich das auch freihändig umsetzen können.
Jetzt ist das ein Jahrzehnt her, und ich habe alles vergessen, bräuchte mehrere Wochen um mich wieder einzuarbeiten, und dazu eine innere Ruhe.
Beides habe ich nicht, dafür Dutzende Aufgaben die dringlicher sind als das.
Soooo schrecklich oft kommt es erfreulicherweise nicht vor; mutmaßlich gibt es ein, zwei oder drei Benutzer von 2005, die sich das mal angewöhnt hatten.
Moin Moin IWL04, nein, ich habe da keinen spziellen Code. Ich lasse mir via CheckWikipedia die Fälle ausgeben und dann halt mit etwas magic via Editor, klappt für mich gut. Bei leichten Fällen unterstützt WSTM ja schon immens ;) mfg --Crazy188019:13, 29. Nov. 2023 (CET)
math display
Letzter Kommentar: vor 9 Monaten3 Kommentare2 Personen sind an der Diskussion beteiligt
Kannst du das abstellen <math display=…>? Oder was soll man da machen?
Beispiel display="block" wird zentriert in der Mitte ausgegeben:
Auch wenn das vermutlich für inline unnötig ist, aber es scheint ein gültiges Attribut zu sein und WSTM sollte das daher nicht monieren. --Liebe Grüße, LómelindeDiskussion10:03, 5. Dez. 2023 (CET)
Da habe ich eine konkrete Vorstellung davon, wo die Attribute zu den Elementen registriert sind und wie eines zu ergänzen wäre.
Letzter Kommentar: vor 5 Monaten4 Kommentare3 Personen sind an der Diskussion beteiligt
Moin PerfektesChaos. Ich habe mal eine (möglicherweise dumme, aber auch nicht dringende) Frage. Da ich ehrlich gesagt kein Interesse an dererlei Reverts habe, andererseits die Vorlage:Internetquelle aber auch tatsächlich was von "inline" in der Doku schreibt (und extra darauf hingewiesen wird, dass man sie nicht über mehrere Zeilen aufsplitten möge....), würde ich gerne das Umformatieren besagter Vorlage auf 'Zeilenweise' abschalten, WSTM aber weiter nutzen können. Geht das, und ich find's nur in der Doku nicht, oder geht das gar nicht? Oder liegt das an was anderem? --Gelegenheits-Wikipedianer (Diskussion) 12:19, 14. Mär. 2024 (CET)
Frag mal Crazy1880, soweit ich mich erinnere, hat er das bei sich abgeschaltet. Vielleicht kannst du es von ihm kopieren, wenn er dir die entsprechenden Zeilen nennt. --Liebe Grüße, LómelindeDiskussion12:44, 14. Mär. 2024 (CET)
Es geht seitens WSTM selbst nicht.
Bei Vorlage:Internetquelle und Vorlage:Literatur wird im Gegenteil vorhandene zeilenweise Anordnung innerhalb des Fließtextes in die Zeilenumbruch-lose Formatierung umgeschrieben.
Nur im Schlussbereich, also bei den Abschnitten „Literatur“ und „Weblinks“ usw., wird zeilenweise dargestellt, weil dort nicht störend und die Sinnhaftigkeit der einzelnen Parameterzuweisungen besser überprüft werden kann.
Okay, danke. Kann ich auch nachvollziehen (und sehe ich ja ähnlich), aber in der Doku steht's halt gezielt anders (selbst bei der Kopiervorlage mit den Zeilenwechseln). Dann lasse ich das mal so stehen (bzw. schlinse mal bei Crazy1880 rein, ob ich was erkenne) - denn auf die anderen Korrekturen durch WSTM mag ich auch nicht verzichten, sind zu sinnvoll. --Gelegenheits-Wikipedianer (Diskussion) 13:27, 14. Mär. 2024 (CET)
LdiF
Letzter Kommentar: vor 4 Monaten4 Kommentare2 Personen sind an der Diskussion beteiligt
Moin Moin PerfektesChaos, bei der obigen Vorlage stellt WSTM bei mir den Parameter "Abruf" immer auf "abruf" um. Magst du da bitte mal schauen? Danke dir --Crazy188022:00, 2. Mai 2024 (CEST)
Ah, danke, da gab es wohl im Lauf der Jahre öfters Hin und Her. Hatte ich irgendwann mal eine Version eingefangen.
Wird irgendwann mal online aktiv; wenn es wenigstens erstmal von zugriff= wegbewegt, ist ja auch erstmal nett.
GoogleBuch habe ich auf dem Schirm, allerdings mache ich nicht nach der Kategorie sondern nach der Vorlagenwartung, das sind noch gut 400 Fälle, kommt alles
Brockhaus is notiert und kommt auch
Frage: Wie und wann gehts weiter mit den Coordinaten? Ich habe auch etliche Artikel, wo Coordinate unter Navi steht, dass soll so ja auch nicht.
Letzter Kommentar: vor 4 Monaten2 Kommentare2 Personen sind an der Diskussion beteiligt
Moin Moin PerfektesChaos, so, die Vorlage sollte von den veralteten Parametern befreit sein, soweit gesehen. Mal ne blöde Frage dazu, könnte man diese Vorlage nicht mit den anderen Brockhaus-Vorlagen zusammenpacken und nur eine große daraus machen? mfg --Crazy188019:04, 5. Mai 2024 (CEST)
Danke bis hierhin.
Zusammenlegung aller Brockhäuser: Das funktioniert nicht.
Die Druckwerke sind unterschiedlich aufgebaut. Brockhaus-1837 hat weder BK-Nummer noch Eintragsnummer, soweit bisher bekanntgeworden.
Brockhaus-1895 hat keine zenoID sondern eine retrobID, weil halt anderes Digitalisat.
Brockhaus-1911 braucht BK-Nummer und Eintragsnummer und zenoID.
Ich arbeite jedoch generell an einer Vereinheitlichung des Parametermodells, passend zum jeweiligen Werk, für alle derartigen.
Es passiert bei mir dort folgendes (width wird bei mir nicht verändert):
<mapframelatitude="28.459033"longitude="20.039063"zoom="2"width="266"height="251"text="Aktuelle Auslandseinsätze der Bundeswehr (Stand: Dezember 2023){{Farblegende|#009edb|UN-Einsatz}}{{Farblegende|#000077|EU-Einsatz}}">
{
"type": "FeatureCollection",
…Inhalt
}
</mapframe>
wird geändert in selbstschließende Tags
<mapframelatitude="28.459033"longitude="20.039063"zoom="2"width="266"height="251"text="Aktuelle Auslandseinsätze der Bundeswehr (Stand: Dezember 2023){{Farblegende|#009edb|UN-Einsatz}}{{Farblegende|#000077|EU-Einsatz}}"/>{
"type": "FeatureCollection",
…Inhalt
}
<mapframe/>
Diese Tags sind irgendwie anders als andere, sie können ohne Inhalt vorkommen und sind dann selbstschließend, mit Inhalt müssen sie aber aus öffnendem und schließendem Element bestehen.
<mapframelatitude="28.459033"longitude="20.039063"zoom="2"width="266"height="251"text="Aktuelle Auslandseinsätze der Bundeswehr (Stand: Dezember 2023){{Farblegende|#009edb|UN-Einsatz}}{{Farblegende|#000077|EU-Einsatz}}"/>
ist identisch zu dem mapframe ohne Inhalt
<mapframelatitude="28.459033"longitude="20.039063"zoom="2"width="266"height="251"text="Aktuelle Auslandseinsätze der Bundeswehr (Stand: Dezember 2023){{Farblegende|#009edb|UN-Einsatz}}{{Farblegende|#000077|EU-Einsatz}}"></mapframe>
Klar ist aber (für mich), dass ein schließendes </mapframe> niemals zu einem <mapframe /> werden darf. Siehe auch mw:Help:Extension:Kartographer
“The <mapframe> tag embeds a map in a wiki page. The tag must be either empty or contain GeoJSON.”
Ich würde vorschlagen diese Syntax nicht auszuwerten und auch über WSTM keine Fehlermeldung auszugeben. Ich vermute mal du (PC) hast das mit deinem letzten Update eingefügt. Es ist aber leider kein reines unary-Tag sondern ein dooooofer Zwitter. --Liebe Grüße, LómelindeDiskussion15:55, 15. Mai 2024 (CEST)
Ich hatte in den letzten Tagen ein weiteres Update betreffend mapframe programmiert, war aber bislang nicht zum Einspielen oder auch nur Austesten gekommen.
Grundsätzlich ist es in der Wikisyntax (für MW-Elemente) völlig egal, ob ein Element „leer“ oder „unary“ ist (das ist anders als in HTML). Es gibt wohl auch über 100 Artikel, die problemlos ein „unary“ benutzen; auch ohne WSTM eingefügt.
Was ich bislang nicht kannte, waren leere mapframe ohne JSON-Inhalt; auf die bezog sich die von Lómelinde zitierte Änderung. Die war dann aber doch nicht so gut, was ich auch schon merkte, und inzwischen erneuert hatte.
Neben references ist das eines der wenigen Elemente, die sowohl „unary“ als auch „binary“ vorkommen können. Während references in WSTM aber eine spezielle Programmierung haben, hatte mapframe mein bisheriges Konzept gesprengt.
Ich brauche einige kühle Nachtstunden, um das weiter zu verfolgen.
Ja „auch ohne WSTM eingefügt“, es gibt dann aber immer eine Meldung, das meinte ich oben, wenn ich sagte, keine Fehlermeldung (Element muss Inhalt umfassen <mapframe />) ausgeben. Das wollte ich neulich auch schon mal ansprechen, habe es aber vergessen. --Liebe Grüße, LómelindeDiskussion16:56, 15. Mai 2024 (CEST)
Letzter Kommentar: vor 3 Monaten30 Kommentare5 Personen sind an der Diskussion beteiligt
Hissflagge
Auch wenn es in dem Fall keine wirkliche Auswirkung hatte aber eigentlich sollte das Attribut |rand nicht einfach so unterschlagen werden, oder? Siehe Spezial:Diff/245198074 konkret wurde aus
Wie gesagt ist das bei der Datei nicht ausschlaggebend. Aber es gibt andere, wo das unschön wäre.
ohne Rand unschönmit Rand
Es passiert bei folgenden Ausgangslagen
[[Datei:Flag of Kingdom of Croatia (1852-1860).svg|Bildlegende|rand|100px|links]]
[[Datei:Flag of Kingdom of Croatia (1852-1860).svg|Bildlegende|rand|links|100px]]
[[Datei:Flag of Kingdom of Croatia (1852-1860).svg|100px|Bildlegende|rand|links]]
[[Datei:Flag of Kingdom of Croatia (1852-1860).svg|100px|Bildlegende|links|rand]]
[[Datei:Flag of Kingdom of Croatia (1852-1860).svg|Bildlegende|100px|links|rand]]
[[Datei:Flag of Kingdom of Croatia (1852-1860).svg|Bildlegende|100px|rand|links]]
[[Datei:Flag of Kingdom of Croatia (1852-1860).svg|rand|100px|Bildlegende|links]]
[[Datei:Flag of Kingdom of Croatia (1852-1860).svg|links|100px|Bildlegende|rand]]
[[Datei:Flag of Kingdom of Croatia (1852-1860).svg|rand|Bildlegende|100px|links]]
Sobald hinter der eigentlichen Bildlegende noch Attribute stehen, geht es verloren, stehen alle davor [[Datei:Flag of Kingdom of Croatia (1852-1860).svg|rand|100px|links|Bildlegende]] bleibt alles unverändert stehen und es erfolgt keine Sortierung der Attribute. Generell finde ich den dünnen Rand viel zu hell. --Liebe Grüße, LómelindeDiskussion12:17, 22. Mai 2024 (CEST)
Danke erstmal für den Hinweis.
Das Grundproblem ist klar: Die Bildlegende steht nicht am Ende.
WSTM analysiert das seit anderthalb Jahrzehnten, seit einem Dutzend Jahren auf die gleiche Weise.
Jetzt wird diese Situation erstmals entdeckt.
WSTM sieht mindestens die deutschsprachigen Schlüsselwörter als die eine Bildlegende, und erkennt sie nicht als Schlüsselwort, und hat nun zwei Bildlegenden und lässt die zweite weg.
Was mir auffällt: Es geht nur um Flaggen, vermutlich alle vom selben Mensch eingefügt.
Könntest du die projektweit mit Cirrus suchen, händisch fixen, und den ggf. serienmäßigen Verursacher aufspüren und um besser menschenlesbare Syntax bitten?
Wenn es zu viele werden, ggf. Wurgl-Bot für massenhafte Standardschemata.
Da |rand| (rund 6000 + 800 [border]) und |rand]] (ca 250 + 265 [border] zumeist ohne Bildlegende) vorkommt und ich zudem nicht mit Schwund rechnete, kann mir so etwas durchaus auch schon durchgerutscht sein. Wie soll ich denn das mit Cirrus suchen, das kann an allen möglichen Stellen in den Bildattributen stehen. Könnte also |rand| sein oder |rand]], dann wären noch |border| und |border]]. Muss ich mal schauen. Meine letzte Suche waren Links mit geschützten Leerzeichen als Linktext. Die Leute hier sind manchmal wirklich merkwürdig. →Spezial:Diff/245178996 Abschnitt „Gründung des Unternehmens“ [[Sudan| ]] was auch immer es werden sollte. Aber rand/border werden sicherlich mehr Ergebnisse werden und die müsste man dann durchsuchen. Ob es nur Flaggen betrifft, weiß ich nicht. Hier ein völlig unsinniges Beispiel aus dem Wallenstein#Prager Fenstersturz.
[[Datei:Prager Fenstersturz Wahrhafftige Zeitung aus Prag.JPG|mini|Der Prager Fenstersturz auf einem zeitgenössischen Holzschnitt, 1618|alternativtext=Der Prager Fenstersturz|rand]] daraus macht WSTM dann [[Datei:Prager Fenstersturz Wahrhafftige Zeitung aus Prag.JPG|mini|alt=Der Prager Fenstersturz|Der Prager Fenstersturz auf einem zeitgenössischen Holzschnitt, 1618]] zumindest so etwas sollte doch der Wurgl eliminieren können, das müsste eigentlich auch zu einem Linterfehler werden, weil |rand und |mini nicht zugleich wirksam sein können, oder irre ich mich da? Ich pinge ihn mal an. Zumindest bräuchte ich eine sinnvolle Suchroutine, wenn ich das von Hand prüfen soll. Es trifft auch auf border zu, dass es verschwindet, also nicht nur rand. Vermutlich war es aber eh wieder die Nadel im Heuhaufen. Und vermutlich ist es auch fast alles Sport, eher aufwändig, weil oft sehr viel veraltete Syntax … --Liebe Grüße, LómelindeDiskussion16:51, 22. Mai 2024 (CEST)
Also ich hab im Dump 13.512 Bilder identifiziert, wo die Beschreibung nicht das letzte Element ist. Das geht quer durch alles, Flaggen sind eher selten. Aber so ganz hab ich das Problem nicht verstanden.
Kennzeichen für Hohlwanddosen nach VDE 0606
[[Bild:KennzeichnungHohlwanddoseVDE0606.svg|links|70px|Kennzeichen für Hohlwanddosen nach VDE 0606|border]]
Kennzeichen für Hohlwanddosen nach VDE 0606
[[Bild:KennzeichnungHohlwanddoseVDE0606.svg|links|Kennzeichen für Hohlwanddosen nach VDE 0606|70px|border]]
Kennzeichen für Hohlwanddosen nach VDE 0606
[[Bild:KennzeichnungHohlwanddoseVDE0606.svg|links|border|70px|Kennzeichen für Hohlwanddosen nach VDE 0606]]
Kennzeichen für Hohlwanddosen nach VDE 0606
[[Bild:KennzeichnungHohlwanddoseVDE0606.svg|border|links|70px|Kennzeichen für Hohlwanddosen nach VDE 0606]]
Ich sehe da keinen Unterschied in der Darstellung, wenn nur WSTM sich anders/falsch verhält, dann kann ich diese Bildattribute im Bot nebenher umsortieren, aber extra-Edit mach ich da nicht. --Wurgl (Diskussion) 11:34, 23. Mai 2024 (CEST)
Die Darstellung ist identisch, nur WSTM hat Probleme mit der Umsortierung der Parameter. Was aber nicht sein sollte ist auf jeden Fall eine gleichzeitige Zuweisung von mini und rand bzw. border, denn das geht (meiner Meinung nach) technisch nicht. Alle border sollten zugleich in rand geändert werden ebenso wie es natürlich auch noch Vorkommen von thumb geben kann, und wo eben beides vorkommt, also border/rand und zugleich das mini/thumb, da sollte border/rand entfernt werden, ehe es irgendwann Linterfehler erzeugen wird. --Liebe Grüße, LómelindeDiskussion12:02, 23. Mai 2024 (CEST)
Es haben auch menschliche Autoren Probleme damit, wenn die Legende mittendrin steht; sie übersehen sie dann und schreiben hinten noch eine weitere, die bei derzeitigem Parsing dann ignoriert würde (und eigentlich LINT auslösen sollte).
Die Legende in allen eindeutigen Fällen nach hinten zu schieben wäre in jedem Fall sehr hilfreich für alle.
Ich bin dran. Muss halt sehr vorsichtig sein, nicht dass ich da ein Attribut nicht erkenne und den Quelltext dann zerschieße, wenn ich zwei solche (dem Script) unbekannten (oder unerkannten) Attribute finde, dann mach ich nix. --Wurgl (Diskussion) 14:55, 24. Mai 2024 (CEST)
Moin zusammen, mal so als Mitlesender, gibt es Cirrus-Suchen dafür, was wir genau suchen? Lómelinde hat ja schon einen Ansatz gemacht, aber stimmen die so auch, bzw. können wir diese Suchen hier mal verlinken, damit wir alle nochmal die Köpfe zusammenstecken können? mfg --Crazy188015:41, 24. Mai 2024 (CEST)
Ich habe einfach nach |rand| ebenso oder |rand]] bzw. border gesucht, wie ich dem aber noch sagen könnte, „suche, ob in der Einbindung auch noch eine Bildlegende steht und wenn ja, wo sich diese befindet“, das weiß ich nicht. --Liebe Grüße, LómelindeDiskussion16:02, 24. Mai 2024 (CEST)
Wallenstein [[Datei:Prager Fenstersturz Wahrhafftige Zeitung aus Prag.JPG|mini|Der Prager Fenstersturz auf einem zeitgenössischen Holzschnitt, 1618|alternativtext=Der Prager Fenstersturz|rand]]
Geschichte Chiles [[Datei:Flag of Chile.svg|mini|Flagge Chiles|border]]
Bahnstrecke Amberg–Schnaittenbach [[Datei:Fahrplan 1898.jpg|alternativtext=Fahrplan 1898|links|mini|Fahrplan der Strecke Amberg – Schnaittenbach von 1898 - 1899 aus dem Kgl. Bayer. Staatseisenbahn Kursbuch mit der Beschreibung „Giltig vom Tage der Eröffnung“|rand]]
Markus Stephan Crisinus [[Datei:Sv Marko Krizevcanin Rijeka 0308.jpg|100px|mini|Darstellung von Markus Stephan Crisinus auf einem [[Glasfenster]] der Kirche ''Unsere Liebe Frau von Lourdes'', [[Rijeka]] |rand]]
Michael Flügel [[Datei:Michael Fluegel - Piano.jpg|mini|Der Jazzpianist Michel Flügel|rand|links|440x440px]]
Frischeparadies [[Datei:Fischtheke FrischeParadies.jpg|mini|306x306px|Fischtheke im Frischeparadies|rand]]
Kerstin Rudek [[Datei:Kerstin-Rudek Treck-Berlin(2009-03-28).jpg|alternativtext=Kerstin Rudek als Vorsitzende der Bürgerinitiative Umweltschutz mit weiteren Vorstandsmitgliedern (2009)|mini|Kerstin Rudek, als Vorsitzende der Bürgerinitiative Umweltschutz & Vorstandsmitglieder (2009)|rand|rechts]]
Irish National Heritage Park [[Datei:Rundturm im Irish National Heritage Park.jpg|mini|Der weithin sichtbare Rundturm, Wahrzeichen des Irish National Heritage Parks|rand]]
BMW F 700 GS [[Datei:F700chart kw nm wiki.svg|mini|Leistungsdaten der F700GS im Vergleich|alternativtext=|rand]]
Madagaskarfischer [[Datei:Madagascar Pygmy-kingfisher.jpg|mini|Pärchen Madagaskarfischer am Nisttunnel (Illustration von [[John Gerrard Keulemans|J. G. Keulemans]])|rand]]
Julia Herr [[Datei:2016 Julia Herr (27367259053).jpg|mini|Julia Herr bei einer Enquete des [[Sozialdemokratische Partei Österreichs|SPÖ-Parlamentsklubs]] zum Thema [[Cyber-Mobbing|Hass im Netz]] im Jahr 2016.|rand|300x300px]]
Lehel Kovács [[Datei:Töredék cukortartóval.jpg|mini|Fragment with Sugarbowl, 30 × 40 cm, Acryl und Öl auf Leinwand, 2019|alternativtext=|rand]]
border/rand geht nicht mit mini/miniatur/thumb/thumbnail/framed/frame/gerahmt wie beschrieben wird dann border entfernt
px geht nicht gemeinsam mit hochkant/upright, hochkant/upright wird dann entfernt (ja, das gibt es tatsächlich und px zieht, egal welche Reihenfolge)
bei allen anderen Dopplungen wie z.B. links gemeinsam mit rechts etc. wird das erste gelassen und das zweite entfernt
Zusätzlich (und das kann ich schnell abschalten wenn nicht gewünscht) tausche ich engl. gegen deutsche Begriffe aus, inkl. Image/File/Bild => Datei. Wie in Benutzer:PerfektesChaos/js/WikiSyntaxTextMod/usage/lang/dewiki#Anhang:_Statistik in den häufigsten Begriff, bis auf alt vs. alternativtext und clas vs. klasse, die beiden lass ich unverändert. Ist tabellengesteuert, also kein Problem da was zu drehen.
Die Bildbeschreibung wird immer als letztes Attribut eingesetzt
Wenn ich (aus welchem Grund auch immer) ein Bildattribut nicht erkenne, dann behandle ich das als Bildbeschreibung. Sollte ich eine zweite Bildbeschreibung entdecken, dann fass ich nix an.
Ich kann das im Bot mitlaufen lassen, sprich wenn ich aus anderem Grund ein Artkelchen anfasse, dann rattert der Code drüber, sonst nicht.
Was ich noch mache: Nochmals den Dump analysieren und mit den Erkenntnissen nicht verträgliche Dopplungen rausfischen und diese ändere ich auf jeden Fall. --Wurgl (Diskussion) 23:18, 25. Mai 2024 (CEST)
kannst du die artikel mit doppelten bildbeschreibungen, die der bot nicht anfässt irgendwo sammeln, weil das sollte eigentlich lintfehler auslösen und gar nicht mehr im ANR vorkommen, und falls doch zur manuellen bereinigung, könnten import übersetzungsreste sein. gruss, --Wetterwolke (Diskussion) 00:59, 26. Mai 2024 (CEST)
Aktuell ist das theoretisch. Momentan läuft gerade zwecks Test das Ding über 100.000 Artikel drüber und ich hab da in ca. 100 Fälle wo sowas wie 250px und hochkant gemeinsam vorkommt. Doppelte Beschreibungen hab ich bisher nicht gefunden bzw. ich hab alles richtig erkannt. Das ist sozusagen der Notausgang. Auf jeden Fall kommt das als Fehler raus und wenn das nur wenige sind, dann fixe ich das zu Fuß. --Wurgl (Diskussion) 01:09, 26. Mai 2024 (CEST)
Änderungen die der Bot machen würde, das sind nur die "unverträglichen" Kombinationen der Attribute.
Und dann hab ich alten, unfertigen (und veralzheimerten) Code entdeckt und den fertig gestellt: siehe unterabschnitte
zu den Einträgen "SORTIERUNG/DEFAULTSORT mehrfach mit gleichem Wert" und "SEITENTITEL/PAGETITLE unnötig" gibts auch zusammen so um die 300 mal ANR-Atikel, die würde ich auch gerne entfernen. --Wurgl (Diskussion) 13:34, 27. Mai 2024 (CEST)
2024-05-27 10:50:17 bot.php #2/2 (of 1787): Process Page Id:890 Rev Id:244753260 Timestamp:20240507110138 Title:Chinesische Sprachen: verstehe ich nicht ganz, warum wird
- [[Datei:4 Toene des Hochchinesischen.svg]]
+ [Datei:4 Toene des Hochchinesischen.svg|]]
(die leere pipe am ende)?
nebenbei mitgemacht werden sollte die bildgrösse immer hinter mini stehen, vereinfacht das verständnis und ist wohl eine der ursachen der doppelten parameter, dass sie manchmal davor, und manchmal dahinter stehen
2024-05-27 10:55:04 bot.php #1785/1767 (of 1787): Process Page Id:13052123 Rev Id:243829056 Timestamp:20240406204142 Title:Bilder einer Ausstellung (Ballett):
- [[Datei:Mussorgsky Pictures at an Exhibition, chords.PNG|300px|mini|hochkant=1.2|
statt
+ [[Datei:Mussorgsky Pictures at an Exhibition, chords.PNG|300px|mini|
besser
+ [[Datei:Mussorgsky Pictures at an Exhibition, chords.PNG|mini|300px|
generell parameteranordnung: nach lektüre von Hilfe:Bilder kann man die bildparameter in verschiedene gruppen einteilen:
grundsätzliche art der einbindung: mini, rahmenlos und gerahmt
parameter die diese generelle einbindung weiter modifizieren:
grösse: px, hochkannt
spezieller parameter bei rahmenlos: rand
ausrichtung: links, rechts, zentriert, ohne
bildinhalt betreffend:
alt
Legende (unbenannter (immer letzter) parameter)
sonderparameter: class, seite
ich schlage vor nebenbei die gruppen nach 1., 2. und 3. zu sortieren (reihenfolge innerhalb einer gruppe nicht ändern, und die sonderparameter nicht verschieben, da sich mir kein logischer platz aufdrängt).
erst wird die generelle art der bildeinbingung festgelegt, dann wird ein standardverhalten dieser standardeinbindung wenn gewünscht überschrieben (grösse, links bei mini, rechts bei rahmenlos, rand bei rahmenlos, etc.) zum schluss wird das bild beschrieben erst alt, dann als legende (tooltip). diese reihen folge ist logisch und verhindert auch fehler (doppelte bildgrösse, doppeltes alt oder bildbeschreibung sehe ich oft bei den lintfehlern). änderungen der reihenfolge der gruppen bitte behutsam nebenbei erledigen. gruss
Ich bin momentan zu überlastet, um hier im Detail folgen zu können oder irgendwas programmtechnisch zu lösen.
Im unmittelbar vorangehenden Beitrag ist jedoch missverständlich: #* Legende (unbenannter (letzter) parameter) # sonderparameter: class, seite
Die Legende kommt unabhängig von allem immer ganz zum Schluss.
Eine Sortierung der Parameter sowohl bei Vorlagen wie auch bei diesen Einbindungen ist immer empfehlenswert, weil eine menschliche Bearbeitung anders als Software die Dinger an bestimmten Stellen erwartet und sie übersieht, wenn sie schon woanders definiert wurden.
Ich generier mal diese Datei neu. Den Blödsinn bei Chinesische Sprachen hab ich gefixt (hab nicht gedacht, dass es eine Datei ohne irgendweche Attribute gibt), Umsortierung ist gemacht. Den Fall gerahmt/links hab ich berücksichtigt, aber der kommt da nicht vor (hab zumindest nix gesehen).
|alt= bzw. |alternativtext= bedeutet, dass diese Grafik nicht informativ für Blinde ist, und ihre Existenz komplett verleugnet und nicht mal erwähnt werden soll.
ah gute aufgepasst mit dem rahmenlos links! danke für den neuen diff, änderungen wie im bsp Bonn |mini|links|hochkant=0.5| zu |mini|hochkant=0.5|links| würde ich nicht machen. was ich meinte war, dass die parameter aus 1. vor denen aus 2. kommen. aber innerhalb der 2. gibt es keine präferenz ob erst grösse oder erst ausrichtung, ich sehe da keine klare vorgabe, logik oder dominierende verbreitung.
bzgl. |alt=| das macht sinn in den fussballtabellen wenn dort die werder raute und Werder Bremen steht, dass dem blinden das wappen verschwiegen wird und nur der Verein vorgelesen wird. wenn ich mir die diffs und einzelne seiten anschaue habe ich da so meine zweifel, die meisten bilder müssten nicht grundsätzlich für blinde verschwiegen werden, allerdings kann das kein bot leisten, muss in jedem fall manuell geprüft werden. gruss --Wetterwolke (Diskussion) 04:07, 29. Mai 2024 (CEST)
Schritt 1 |format=[[Hypertext Markup Language|]][1] ← Dadurch ([[Hypertext Markup Language|]]) ist es mir erst aufgefallen, warum das in ref-Tags so anders ausgegeben wird, weiß ich nicht
Gerade aber Schritt 1 wäre unschön, dass WSTM versucht ein |format=HTML zu eliminieren ist schon klar, nur in der Form, hatte ich das, meine ich noch nicht wirklich. Da →Kaputte Lieder über eine heile Welt wäre noch so ein Kandidat an dem du das prüfen kannst, der Benutzer macht das scheinbar exklusiv so, weitere Beispiele habe ich nicht gefunden, allerdings noch drei andere die dann leere Klammern = (Hypertext Markup Language ()) hinterlassen würden. Kannst du dir das bitte mal ansehen? --Liebe Grüße, LómelindeDiskussion12:49, 4. Jun. 2024 (CEST)
Danke für den Hinweis.
Hatten wir in dieser Konstruktion seit einem Dutzend Jahren nicht.
Vorsorglich weitere Vorkommen suchen, Benutzer ansprechen.
Ich habe es auf meine ToDo-Liste gesetzt, sehe aber kurzfristig keine Ressourcen zur Abarbeitung.