Vorlage Diskussion:Str find

Diese Diskussionsseite dient dazu, Verbesserungen an der Vorlage „Str find“ 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.

Groß- und Kleinschreibung

Die Vorlage arbeitet offensichtlich unter Berücksichtigung der Groß- und Kleinschreibung (ist also case-sensitive). Ich habe diesen Hinweis in die Doku mit aufgenommen (diff). Wäre es darüber hinaus nicht sinnvoll, den nicht-case-sensitiven Vergleich per Parameter zu ermöglichen? Yellowcard (D.) 11:55, 5. Aug. 2020 (CEST)

• Die umseitige Programmierung soll kompatibel mit en:Template:Str find sein, die ihrerseits durch perspektivisch 100 andere Wikis übernommen wurde und hervorragender und ausnahmsweise mal sinnvoller Kandidat für die sagenumwobenen „globalen Vorlagen“ ist.
• Durch einen äußerst dummen Programmierfehler, als hier überhastet, mit mangelnder Lua-Erfahrung und ohne die erforderlichen Testprozeduren eine eigene Lua-Programmierung des Str-Pakets eingeführt wurde, leisten wir uns bereits bei einer anderen Str-Vorlage eine vom enWP-Vorbild abweichende Zählung in der Zeichenposition und Inkompatibilität mit der globalen Praxis. Das muss nicht noch weiter verschlimmert werden.
• Zwischen Wikis austauschbare Vorlagen verlassen sich auf eine identische Parametrisierung ohne lokale Forks.
• Nebenbei bemerkt ist die umseitige Programmierung ohnehin nicht sonderlich schlau, denn anstatt das Trimmen gleich dem ohnehin aufgerufenen Modul komplett zu überlassen und dort effizient und übersichtlich auszuführen, wurde 2013 eine krude Mischung aus halber Vorlagenprogrammierung und halber Lua-Programmierung gebastelt.

VG --PerfektesChaos 12:46, 5. Aug. 2020 (CEST)

Hallo PerfektesChaos, danke für die schnelle Antwort. Ich kann das Argument verstehen, aber nur als Zwischenlösung akzeptieren. Wenn nicht irgendwann(tm) globale Vorlagen eingeführt werden, sollten wir Vorlagen dort entkoppeln, wo es sinnvoll ist, auch wenn dadurch die Rückwärtskompatibilität verloren geht (sprich Übertrag von de.wp in en.wp funktioniert nicht, umgekehrt aber weiterhin – so wäre es ja in diesem Fall). Dies beziehe ich sowohl auf einen optionalen Parameter zur Deaktivierung der Case Sensitivity als auch auf die von Dir erwähnte Optimierung hinsichtlich des Trimmens der Zeichenkette, wobei ich nicht einschätzen kann, ob durch die beiden if-Funktionen Ressourcen in relevanter Größe verloren gehen. Grüße, Yellowcard (D.) 13:32, 5. Aug. 2020 (CEST)

Nein, die umseitige Vorlage ist nur ein Hilfsmittel innerhalb der Vorlagenprogrammierung.

Dort ist es (bei allen Str-Vorlagen) ein global übliches Mittel, die beiden Parameter wahlweise per uc oder lc zu entkäsen, sofern Bedarf.

In allen anderen Fällen, sprich in der Lua-Programmierung, ist umseitig Nonsens.

Autoren von Artikeln haben mit dieser Vorlage absolut nix am tun; sie wären aber die einzigen, die eine solche Erleichterung beanspruchen dürften.

Es gibt ein minimales Spektrum an Vorlagen, die sich überhaupt als globale Vorlagen eignen würden; es scheiden alle aus, die eine unmittelbar sichtbare Präsentation von irgendwas vornehmen, weil das immer kulturell, sprachlich, projektbezogen, typografisch auf lokale Besonderheiten Rücksicht nehmen muss; außerdem alle Vorlagen, die von den Autoren der Seiten direkt verwendet werden könnten, weil hier immer Fehlermeldung und die projektspezifische Organisation von Wartungskategorien erforderlich wäre.

Nur elementare mathematische, logische, oder auf bedeutungsfrei neutrale Zeichenketten bezogene Funktionen wie umseitig kommen überhaupt für den globalen Standard in Frage. Es wäre Eselei hoch drei, ohne einen nennenswerten Vorteil die globale Kompatibilität an die Wand zu fahren. Sowas machen gute Programmierer niemals ever und gilt als Todsünde.

Wenn du etwas verändern willst, müsstest du das zuerst bei der virtuellen globalen Mutter durchsetzen; also die enWP überzeugen.

VG --PerfektesChaos 13:52, 5. Aug. 2020 (CEST)

Ich fände es lediglich einen netten Service für Gelegenheits-Vorlagenprogrammierer wie mich. Ich musste vorhin nämlich zunächst auf der Spielwiese testen, ob die Vorlage case-sensitive ist oder nicht; und anschließend habe ich eine Vorlage gesucht, die die Zeichen in Kleinbuchstaben umwandelt, bis mir nach einiger Sucherei erst eingefallen ist, dass hierfür ja Parserfunktionen zur Verfügung stehen. Wie dem auch sei, durch die Ergänzung in der Vorlagendoku wird das zukünftig erspart bleiben und dann wäre der Vorteil eines zusätzlichen Parameters sicherlich kein großer Gewinn – passt also so. Grüße, Yellowcard (D.) 14:25, 5. Aug. 2020 (CEST)

Alle Funktionen zu Zeichenketten sind immer zunächst case-sensitive, sofern es nicht im Einzelfall besonders dabeisteht.

Das trifft genauso zu für:

• MediaWiki-Lua-Standardbibliothek,
• Lua-Sprache-Standardbibliothek selbst,
• Hunderte und Tausende von Programmiersprachen; zumindest jedoch alle die ich näher kenne.

Auch bei den eben aufgezählten gibt es meist keine Hilfs-Flags, mindestens nicht im Lua-Kontext, und es ist überall Sache des Anwenders, sich Nadel und Heuhaufen selbst wahlweise downzucasen oder zu uppern, falls das nicht aus einer inneren Logik schon garantiert ist. Weil wenn das sowieso aus den Umständen heraus gesichert ist, dann macht es die Bibliotheksfunktionen träger, wenn das nochmals untersucht werden muss, oder ein garantiert immer in Kleinbuchstaben vorliegender Wert nochmals und vielleicht auch in beliebigen Nicht-ASCII-Schriftsystemen umständlich erneut Zeichen für Zeichen analysiert werden muss.

Hier war das Problem statt Eingriffs in die Programmierung mit einem kleinen Hinweis in der Doku-Seite zu lösen, mit der ich nebenbei bemerkt nichts zu tun habe.

Gehört aber, wie auch das Wissen um getrimmte Parameterwerte und vieles mehr zu den Grundkenntnissen erfahrener Vorlagenprogrammierer.

VG --PerfektesChaos 15:18, 5. Aug. 2020 (CEST)

Geänderte Funktion der Vorlage

@Antonsusi: Auch hier wurde die Funktion der Vorlage grundsätzlich geändert. Es betrifft hier den 2. Stellungsparameter 3 (Suchtext), welcher bisher getrimmt wurde aber durch deine heutige Änderung nicht mehr. Hier betrifft es mehr als halbe Million Einbindungen (551.685).

Grundsätzlich gilt das hier in Diskussion:Str_crop aufgeführte entsprechend auch für diese Vorlage. Dort betraf es allerdings bedeutend weniger Einbindungen (70.592). --Former111 (Diskussion) 17:21, 8. Nov. 2021 (CET)

Ich halte es grundsätzlich für sinnvoll, auch ein Leerzeichen suchen zu können. Daher habe ich auf die Trimmung des Pattern im Modul verzichtet. Sollte es hier Seiten geben, auf denen jetzt etwas nicht mehr richtig funzt, dann muss man in der betroffenen aufrufenden Vorlage nach führenden Leerzeichen suchen und dort trimmen. ÅñŧóñŜûŝî (Ð) 18:32, 8. Nov. 2021 (CET)

@Antonsusi: Ich halte es auch für sinnvoll dass Leerzeichen gesucht werden können. Zu bedenken ist aber auch, dass dein Aufwand zur Prüfung der derzeit vorhandenen Einbindungen bei der jetzigen Funktionsänderung nicht gerade gering ist.
Weshalb nutzt du nicht im 2. Parameter den Code   um Leerzeichen (im Innern von Zeichenketten) zu suchen? (siehe Hinweis „Sollte tatsächlich mal führend oder schließend ein Leerzeichen, ggf. Zeilenumbruch benötigt sein, dann fordern wir explizit   davor oder dahinter anzugeben.“ (PerfektesChaos: Disk Str crop))
--Former111 (Diskussion) 16:13, 9. Nov. 2021 (CET)

„Nach Leerzeichen suchen“ (meint ASCII, einfach, nicht als Entity) kann man ja gern machen, aber nur im Inneren von Zeichenketten.

Ansonsten betrachten wir Zeichenketten getrimmt und ggf. ungetrimmt aber als gleichbedeutend.

Außer durch unbenannte Vorlagenparameter haben Anwender auch keine Möglichkeit, ungetrimmte Werte anzugeben, und das auch nur im Quelltext. Mit den vier formulargestützten Werkzeugen lassen sich ggf. keine ungetrimmte Zeichenketten angeben, und falls doch, wäre hier ein schließendes Leerzeichen nicht wahrnehmbar. Obendrein trimmen diese ggf. automatisch angefasste Einbindungen, oder fügen gemäß format-Spezifikation Leerzeichen zum Wikitext-Layout hinzu, ohne dass Autoren etwas davon bemerken. Aus diesem Grund sind Unterscheidungen zwischen getrimmten und ungetrimmten Angaben unzulässig.

Es gibt keine bekannten Anwendungsfälle, wo ein inhaltlicher Unterschied zwischen einem ungetrimmten und einem getrimmten Wert gemacht werden würde; und falls es diesen geben würde, so wäre er unerwünscht und verwirrend und zu eliminieren. Dokumentiert ist sowieso kein einziges derartiges Verhalten.

Diese ganze Diskussion ist sowas von Nullerjahre. Schon seit Ewigkeiten ist völlig klar, dass eine saubere Programmierung keine Unterschiede zwischen ungetrimmten und getrimmten Werten machen darf, auch wenn vieles aus den Anfangsjahren bei {{DBL | ID | Linktext}} jämmerlich versagt, weil der Wert der ID einfach mitten in eine URL reingeschrieben wurde und man sich damals drauf verlassen hatte, dass alle Menschen nur {{DBL|ID|Linktext}} schreiben.

VG --PerfektesChaos 17:01, 9. Nov. 2021 (CET)

Klar sollte das möglichst nur für Leerzeichen im Inneren gemacht werden. Es steht uns ja auch frei, die Vorlage um ein explizites Feature zu erweitern. Es wäre ja möglich, für die Suche auch (dezimale) Entities als Pattern zu erlauben. Dann findet man mit   auch Leerzeichen. ÅñŧóñŜûŝî (Ð) 18:39, 9. Nov. 2021 (CET)

Wer tatsächlich mal nach einem Leerzeichen suchen wollte (bis heute ist kein Anwendungsfall bekannt geworden), der möge Vorlage:Str match dafür verwenden.

Da gäbe es ^(%S+)%s als Suchmuster und die Länge der Gruppe ist die Zahl der Zeichen davor; bzw. einschließlich des Zeichens halt entsprechend einbezogen. Je nachdem wie man die Null-Eins-Zählung denn gern hätte.

Klärt auch genauso die Frage, ob im Inneren ein Leerzeichen enthalten ist.

Der Heuhaufen bleibt jedoch getrimmt, und die Nadel auch.

@Former111: Das Entity ist problematisch, weil dann wüsste ich nicht ob ich nach der Zeichenkette   suchen soll.

• Das Escapen als   ist mehr dafür gedacht, dass eine Zeichenkettte zurückgegeben würde, und dann kann ein solches Resultat auch wieder getrimmt und ungetrimmt an andere Vorlagen und Parserfunktionen weitergereicht werden, weil das erste betrachtete Zeichen & ist.

VG --PerfektesChaos 20:55, 9. Nov. 2021 (CET)

Dann wäre m. M. die günstigste Lösung, hier als 3. zusätzlichen wahlfreien Stellungsparameter Regex mit gleicher Wirkung einzuführen und auf jeden Fall den 2. Par. hier wieder trimmen. --Former111 (Diskussion) 14:05, 10. Nov. 2021 (CET)

@PerfektesChaos: Danke für den Tipp. ÅñŧóñŜûŝî (Ð) 14:18, 10. Nov. 2021 (CET)

„die günstigste Lösung, hier als 3. zusätzlichen wahlfreien Stellungsparameter“

• Nein, auf keinen Fall.
• Unser Vorlagenpaket verwendet seit 2009 die von der enWP definierte und längst zum globalen Standard gewordene einheitliche Funktionalität. Jede Abweichung irgendeiner dieser Vorlagen von der globalen Funktionalität führt zu unendlichem Durcheinander, wenn wir eine Vorlage aus einem anderen Wiki beziehen oder eine unserer Vorlagen in ein anderes Wiki kopiert wird.
• Ohnehin gehört das str-Paket neben einigen anderen Basisfunktionen aus Mathematik oder zu URL zu den einzigen, die sich als „globale Vorlagen“ eignen würden, weil sie unabhängig von sprachlichen, kulturellen und projektspezifischen Sitten sind.
• Umseitig wird nur nach einfachen Zeichenketten gesucht, und der Umgang mit den Lua-pattern ist ausschließlich eine Angelegenheit von Vorlage:Str match.
• Es ist kein einziger Anwendungsfall bekannt, wo zurzeit jemand nach einem Leerzeichen suchen würde. Insofern ist das eine akademische Debatte.
• Übrigens hat diese Vorlage automatisch die inline-Eigenschaft; sollte es also tatsächlich irgendjemand fertigbringen, mittels VE oder einem anderen Werkzeug eine Einbindung anzufassen, dann wird führender und schließender Whitespace automatisch entfernt. Weil, für die inhaltliche Bedeutung von Parameterwerten ist es unerheblich, ob sie getrimmt oder ungetrimmt, bzw. angegeben oder leer sind.

VG --PerfektesChaos 16:49, 11. Nov. 2021 (CET)