Vorlage Diskussion:Str crop

Diese Diskussionsseite dient dazu, Verbesserungen an der Vorlage „Str crop“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen.

• Diskussionsregeln
• Hilfe zu Diskussionsseiten
• Sei sachlich und freundlich!
• Greife niemanden persönlich an!
• Geh von guten Absichten aus.

Funktion der Vorlage wurde grundlegend geändert

@Antonsusi: Das widerspricht ja allem, was man mir auf meiner Seite über Funktionsänderungen an vielfach benutzten Vorlagen erklärt hat:

„Wie setzt man Änderungen, die viele Benutzer betreffen dann um? Man setzt sie auf einen breiten Konsens. Diskussionsseiten, Umfragen und Meinungsbilder sind der Ort dafür. Eine Persiode von Wochen oder Monaten der angemessene zeitliche Rahmen, um nicht-power-usern Gelegenheit zur Beteiligung zu geben. Man unterliegt mit solchen Vorhaben also dem Zwang zur umfangreichen Kommunikation, es ist zeitraubend und man begibt sich in ein Dickicht aus diplomatischen Fettnäpfchen. Die Grundprinzipien sind der obligatorische Rahmen für all das“ (Benutzer:Grim).

Bisher arbeitete diese Vorlage mit ersten Stellungsparameter ohne "trim". Damit ändert sich in den Einbindungen das Ergebnis! Du hast vorher die 70.592 Einbindungen nicht überprüft.

M. E. war die Lösung bei dieser Vorlage sowieso besser, da durch die Art der Parameter bei den Einbindungen selbst entschieden werden konnte, ob die Zeichenfolge vorher getrimmt wird. Zudem war dies mit Systemmitteln schon immer unterstützt. (Trimmen durch Benutzung des benannten Parameters 1= statt entsp. Stellungsparameter.) --Former111 (Diskussion) 12:58, 8. Nov. 2021 (CET)

Also, Geschichten mit Trimmen sind extrem fehleranfällig und das Verhalten für Anwender extrem undurchsichtig.

• Sollte tatsächlich mal führend oder schließend ein Leerzeichen, ggf. Zeilenumbruch benötigt sein, dann fordern wir explizit   davor oder dahinter anzugeben.
• Spontan wüsste ich nicht allzu viele Fälle, insbesondere keine im ANR, wo das als Vorlagenparameter auftreten würde. Es kommt gelegentlich vor, wenn innerhalb von {{#if:}} ein aus mehreren Wörtern oder Satzteilen bestehendes Ergebnis zusammengebastelt werden soll.
• Ansonsten fordern wir, dass alle Parameter gleichartig verarbeitet werden sollen, egal ob von den Anwendern getrimmt oder mit Leerzeichen angegeben wurden.
• Insbesondere die Wirkung von schließendem Whitespace ist für Anwender nicht erkennbar, das Vorhandenein unsichtbar. Wir arbeiten schließlich nicht in Whitespace sondern Wikitext.
• Gerade alte Programmierungen im Bestand sind aber nicht „gehärtet“, also auf wahlweise getrimmte und ungetrimmte Parameterwerte vorbereitet. Wird etwa eine URL zusammengebaut aus ID, dann muss der ID-Parameterwert zwingend getrimmt werden. Alte Programmierungen erwarteten aber {{DBL|ID|Titel}} und wenn das heutzutage angegeben wird als {{DBL | ID | Titel}} dann enthält die URL Leerzeichen und bricht an deren erstem Auftreten ab.

Die jetzt notwendige Folge dieser nicht sehr durchdachten Aktion ist, dass sämtliche Verwendungen der Vorlage:str crop überprüft werden müssen, ob sie robust gegen Trimmung sind.

• Das wäre so oder so im Lauf der Jahre erforderlich gewesen.
• Alle 70.592 Vorkommen irgendwo sind nicht das Problem, da diese durch begrenzt wenige Programmierungen verursacht werden.
• Es ist aber das alte Bild, dass ungetestet im produktiven Artikelbestand herumgebastelt wird. Das haben wir jedoch 2013 mit WP:BETA abgeschafft.
• Normalerweise arbeiten wir kompatibel zum Bestand und führen ggf. etwas wie einen Migrationsparameter legacy=1 ein, und erst wenn sämtliche Vorkommen überprüft und keine mehr ohne diesen Migrationsparameter vorkommen, dann werden die Bremsklötze entfernt und die Kompatibilitätsprogrammierung wird abgeschaltet und alles läuft nur noch im neuen Modus.

@S.K.: zur weiteren Beobachtung

VG --PerfektesChaos 13:23, 8. Nov. 2021 (CET)

„... sämtliche Verwendungen der Vorlage:str crop überprüft werden müssen, ob sie robust gegen Trimmung sind. ...“ (PerfektesChaos)
Das ist aber wohl die Aufgabe von Antonsusi! Eine enorme manuelle Arbeit, da er gegen nicht notwendige Änderungen (so auch Einbau von Testkats in Vorlagen) ist, müssen 70.592 Einbindungen manuell auf den Bildschirm aufgerufen und optisch überprüft werden. --Former111 (Diskussion) 14:38, 8. Nov. 2021 (CET)

Och, da gibt es schon effizientere Methoden, um das zurückzuverfolgen. VG --PerfektesChaos 14:39, 8. Nov. 2021 (CET)

@PerfektesChaos: Wäre für mich auch interessant, wie man das hier in Wikipedia macht. Dann würde ich auch ohne Einbau von Testkats bestimme Einbindungen vorher überprüfen können. Kannst du du mir das Vorgehen kurz auf meiner Disk beschreiben. --Former111 (Diskussion) 14:53, 8. Nov. 2021 (CET)

Also ich habe den neuen Quelltext vorher mit einem Duplikat vom Modul mittels "Vorlagen expandieren" getestet und dabei die Beispiele aus der Doku genommen. Mir ist da keine Abweichung zur vorherigen Funktion von Str crop aufgefallen. Diese Vorlage hier ist auch fast ausschließlich Teil von anderen Vorlagen. Sofern diese sauber programmiert sind, dürfte kein Fehler auftauchen. Es ist jedenfalls nicht gut, wenn die Stringvorlagen Trimmung verschieden handhaben. Hier würde ich nur bei der Suche nach Leerzeichen eine Ausnahme machen wollen. ÅñŧóñŜûŝî (Ð) 18:25, 8. Nov. 2021 (CET)

@PerfektesChaos: Danke für den Hinweis.

Ein "Problem" mit der Härtung, das ich momentan habe, ist, dass TemplatePar#match oder TemplatePar#valid Whitespace zumindest bei numerischen Parametern nicht erlauben. Sprich, ich kann entweder die Parametervalidierung mit den beiden Methoden nutzen (was ich gerne/verstärkt mache), dann müssen die entsprechenden Werte aber eh ohne Leerzeichen sein (ich habe öfter numerische Parameter), oder ich kann die Eingabe und Programmierung tolerant/robust machen, dann aber check/valid nicht einsetzen (oder ich muss eigene Lua-Pattern verwenden). :-(

Aber ja, ich schaue, dass ich die Vorlagen, die ich betreue/anpasse bei nächster Gelegenheit entsprechend robuster mache.

--S.K. (Diskussion) 18:54, 8. Nov. 2021 (CET)