Zum Inhalt springen

Benutzer Diskussion:PerfektesChaos/js/WikiSyntaxTextMod/Archiv4

Seiteninhalte werden in anderen Sprachen nicht unterstützt.
aus Wikipedia, der freien Enzyklopädie
Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 1. März 2014 um 04:17 Uhr durch ArchivBot (Diskussion | Beiträge) (1 Abschnitt aus Benutzer Diskussion:PerfektesChaos/js/WikiSyntaxTextMod archiviert). Sie kann sich erheblich von der aktuellen Version unterscheiden.

Letzter Kommentar: vor 11 Jahren von Griot in Abschnitt Whitespace am Zeilenende
Dies ist das Archiv abgeschlossener Diskussionen zum Skript WikiSyntaxTextMod und auch zu allen Unterseiten dazu.

Diese Archivseite beginnt mit Version WSTM.6 ab Anfang 2014.

Andere Archivseiten siehe Archiv.

Et cetera - Bildklammer

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

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

Ja; alte Mühsal – danke erstmal.
Es kommt, wenn sowohl der Dateiname transformiert wird als auch kein Bildtitel und möglicherweise auch nur, wenn nicht in eigener Zeile. Lausig komplizierte Geschichte, weil es im Bildtitel auch Vorlagen und Tabellen und Kommentare und Links und hinter dem Bildtitel nochmals Bildparameter geben kann, und ich in jeder Situation mitzählen muss, welche Pipes und welche schließenden Klammern es gibt und welche zu welchem Syntaxelement gehören.
So habe ich einen neuen Testfall. Selten simpel, war offenbar in dieser Kombination noch nicht auf dem Radar. Code ist seit einem Dreivierteljahr unverändert; scheint also zumindest nicht sehr häufig vorzukommen.
Es wird Frühling --PerfektesChaos 10:01, 7. Jan. 2014 (CET)Beantworten

Whitespace am Zeilenende

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

  • Das hat so seine Richtigkeit.
  • Zuerst prüft WSTM, ob es wirklich etwas zu ersetzen gibt. Dazu würden auch Leerzeilen mit nur Leerzeichen und aller nicht-ASCII-32-Whitespace gehören.
  • Erst wenn es tatsächlich etwas zu tun gibt, werden auch hinter nicht-leeren Zeilen ASCII-Leerzeichen entfernt.
  • Grund: Es soll nicht dazu verleitet werden, nur wegen solcher Quasi-Null-Edits neue Versionen abzuspeichern. Für Normalbenutzer sind die Whitespace-Änderungen und unsichtbaren Zeichen nicht unterscheidbar.
  • Dass du nach dem automatischen WSTM-Lauf noch eine Klammer ersetzen würdest, konnte WSTM nicht vorhersehen. Hätte es eine Diffpage gezeigt, wären sich die Benutzer verschaukelt vorgekommen. Wäre ohne Diffpage was verändert worden, ist das Geschrei auch groß.
Danke für die Kontrollanfrage --PerfektesChaos 20:48, 23. Jan. 2014 (CET)Beantworten
ach, ich mag mal keinen neuen Abschnitt aufmachen. Seit Ewigkeiten scheint es mir so, dass, falls Einzelnachweise im References-Tag definiert werden, dort vor den schließenden Ref-Tags ein Zeileneinbruch eingefügt wird (sogar manchmal auch nach dem öffnenden; Beispiel). Ich finde das nicht sehr gelungen, da so fast nie mehr Übersichtlichkeit reinkommt, aber dafür z.B. bei nur kurzen Einzelnachweisen dies auf die doppelte Zeilenanzahl vergrößert wird und durch den wechselnenden Zeileninhalt (EN/"</ref>) schlechter zu überblicken ist. Falls da ne lange Vorlage drin ist oder auch stark wechselnde EN-Namenslängen sind, kann man drüber reden, was da besser gefällt. Für den Rest meiner Meinung nach verschlechtere Lesbarkeit. Steckt da ein mir nicht zu erschließende Intention hinter? Ansonsten würd ich doch dafür stimmen, das auszuschalten. Grüße --se4598 / ? 18:46, 24. Jan. 2014 (CET)Beantworten
Ach herrje, was soll ich denn bloß mit euch machen.
  • Du bist nicht der erste, der danach fragt.
  • Schon richtig herausbekommen hast du, dass das Feature deshalb eingeführt wurde, um lange Textsequenzen (gerade auch bei Vorlagen ohne Zeilenumbruch nach jedem Parameter) besser abzugrenzen; und bei Vorlagen mit Zeilenumbruch nach jedem Parameter und Einrückung die einzelnen refs voneinander klarer abzugrenzen.
  • Nun würde sich die Frage stellen: Was ist lang? Wie lang ist eine Zeile im Bearbeitungsfeld? Bei mir oft um die 70 Zeichen. Also müsste ein „kurzer“ Beleg auf einen Inhalt von <ref name=""></ref> 19 Zeichen Minimum plus Länge des name-Parameters (oft 20 Zeichen); also bis zu 30 Zeichen Länge eines kurzen Belegtextes. Für Kursivschreibung des Titels gehen 4 Apostrophe weg, ein Komma und ein Leerzeichen für S. und dahinter noch ein Leerzeichen; Doppelpunkt mit einem Leerzeichen ja auch noch mal 2; bleiben für Autor, Titel, Seitenzahl zusammen 20 Zeichen. Das ist nur selten der Fall. Andernfalls entstehen dann doch wieder mehrere Zeilen; dann kommt es auf eine mehr oder weniger nicht an.
  • Nun müssen aber auch die Einträge gleich aussehen. Sonst wird es zum völligen Voodoo, wenn das bei dem einen Eintrag hü und beim nächsten hott ist. Das kapiert nun wirklich keiner. Okay; der Artikel hat ja nur ganz kurze Einträge. Also alle einzeilig. Nun ist ein Wiki aber dynamisch und nicht statisch. Jetzt fügt jemand einen zweifelsfrei langen Eintrag ein; also schalten sich nun sämtliche Einträge auf mehrzeilig. Das kann aber auch umgekehrt passieren: Aus dem Artikel wird eine Textpassage und der sie stützende Beleg entfernt. Das war ein langer gewesen; Juhu! jetzt schalten sich die anderen 20 alle auf einzeilig.
  • Kannst du einen Algorithmus angeben, der für alle Breiten von Bearbeitungsfeldern der Autoren, alle persönlichen Geschmäcker, alle Kombinationen von teils langen, teils kurzen Einträgen für den momentanen und auch alle zukünftigen Gestalten des Artikels eine konstante Formatierung liefert, die niemanden durch konfuses und rätselhaftes Verhalten verwirrt?
  • Im Übrigen sind diese Kurzhinweise ohnehin unerwünscht; es muss nur jemand aus dem Abschnitt „Literatur“ das Buch als überflüssig herauskürzen und ihn mal wieder auf fünf Einträge stutzen; schon steht irgendein Handbuch von irgendeinem Meier ohne bibliografische Angaben da. Und wenn schon unbedingt kurz, dann kann man sie auch gleich im laufenden Text einstreuen; der Block am Ende eignet sich insbesondere für die großen Vorlagen.
Schönes Wochenende --PerfektesChaos 23:18, 24. Jan. 2014 (CET)Beantworten
Ich stell mir gerade so als Idee vor, nur innerhalb der Vorlage umzubrechen, aber halt nicht am Tag, sodass halt dann so etwas wie das hier:
<references>
<ref name="Buch1">John Doe: Wikipedia. Wesen, Wert und Gefahr. Wikipedia-Press, Musterstadt 2001, ISBN 3-12-123453-2, S. 53–98.</ref>
<ref name="Buch2">{{Literatur
|Autor=Max Mustermann
|Titel=Semantischer Kollaps bei Löschdiskussionen
|Sammelwerk=Journal of Wikipedianism 
|Band=Bd. 2
|Nummer=3
|Jahr=2006
|Seiten=17–67
}}</ref>
<ref name="Buch3">{{Literatur
|Autor=Max Mustermann
|Titel=Semantischer Kollaps bei Löschdiskussionen
|Sammelwerk=Journal of Wikipedianism 
|Band=Bd. 2
|Nummer=3
|Jahr=2006
|Seiten=17–67
}}</ref>
<ref name="Buch4">John Doe: Wikipedia. Wesen, Wert und Gefahr. Wikipedia-Press, Musterstadt 2001, ISBN 3-12-123453-2, S. 53–98.</ref>
<ref name="Buch_abc">John Doe: Wikipedia. Wesen, Wert und Gefahr. Wikipedia-Press, Musterstadt 2001, ISBN 3-12-123453-2, S. 53–98.</ref>
</references>
als Kompromiss-Beispielformatierung gegenüber dem wohl derzeitigen Stand
<references>
<ref name="Buch1">
John Doe: Wikipedia. Wesen, Wert und Gefahr. Wikipedia-Press, Musterstadt 2001, ISBN 3-12-123453-2, S. 53–98.
</ref>
<ref name="Buch4">
John Doe: Wikipedia. Wesen, Wert und Gefahr. Wikipedia-Press, Musterstadt 2001, ISBN 3-12-123453-2, S. 53–98.
</ref>
<ref name="Buch_abc">
John Doe: Wikipedia. Wesen, Wert und Gefahr. Wikipedia-Press, Musterstadt 2001, ISBN 3-12-123453-2, S. 53–98.
</ref>
</references>
verglichen mit für mich besser lesbar, platzsparend (gegenüber dem 3mal so langen obigen) und so oft verwendet:
<references>
<ref name="Buch1">John Doe: Wikipedia. Wesen, Wert und Gefahr. Wikipedia-Press, Musterstadt 2001, ISBN 3-12-123453-2, S. 53–98.</ref>
<ref name="Buch4">John Doe: Wikipedia. Wesen, Wert und Gefahr. Wikipedia-Press, Musterstadt 2001, ISBN 3-12-123453-2, S. 53–98.</ref>
<ref name="Buch_abc">John Doe: Wikipedia. Wesen, Wert und Gefahr. Wikipedia-Press, Musterstadt 2001, ISBN 3-12-123453-2, S. 53–98.</ref>
</references>
Ich finde, so wird jede Zeile eindeutig zuordbar zu einer Ref. und die Lesbarkeit wird gewährleistet (Refs ohne Vorlagen kann man ja meist wie Fließtext durchlesen, Vorlage mit Parameter eher nicht, dort wird es halt aufgespalten). Am Ende sieht es bedingt durch das Editerfenster sowieso wieder anders aus, wobei ja höhere Auflösungen immer verbreiteter werden. Dann da so ein Zeilen fressendes Monster zu haben, verbessert nicht gerade die Navigierbarkeit/Überblick über den gesamten Wikitext --se4598 / ? 00:32, 25. Jan. 2014 (CET) PS: Ja, ich habs auch mit schmalem Editierfenster verglichen, wobei bei mir standardmäßig bei sage und schreibe etwas mehr als 200 Zeichen pro Zeile reinpassen (Zum Editieren gut, zum konzentrierten Lesen ja eher weniger, siehe Typographie-Breitenbegrenzungs-Spielereien von der WMF).Beantworten
„Du bist nicht der erste, der danach fragt.“ Ich z.B. fragte schon. Ich glaube nicht mehr, dass eine einheitliche automatische Formatierung des references-Blocks für alle geeignet ist. Eine Lösung wäre, die Einfügung von Umbrüchen nach <ref ...> und vor </ref> von einem Parameter abhängig zu machen, etwa wie mit diffPage. Eine andere – das wäre aber wohl Neuland – wäre, in den Artikeltext einen steuernden Kommentar wie etwa <!--kein automatischer Umbruch--> aufzunehmen. (Die letztgenannte Möglichkeit schützt 'momentane' Hauptautoren vor unerwünschten Änderungen durch (bezogen auf den jeweiligen Artikel) 'einmalige' Mitarbeiter, die vielleicht nur einen Schreibfehler korrigieren wollen.) --Griot (Diskussion) 16:21, 25. Jan. 2014 (CET)Beantworten


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

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

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

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