Vorlage Diskussion:Str sub/Archiv/1

aus Wikipedia, der freien Enzyklopädie

Indexfehler?

Hallo, habe festegstellt, dass die in der Vorlagen-Doku aufgeführten Beispiele nicht mit dem tatsächlichen Verhalten von {{str sub|Text|Index|Anzahl}} übereinstimmen:

Testfall Ausgabe gemäß Doku tatsächl. Ausgabe
{{str sub|Autobahn|0|4}} Auto Auto
{{str sub|Autobahn|2|4}} toba utob
{{str sub|Autobahn|1|4}} — Auto
{{str sub|Autobahn|-1|4}} — Auto
{{str sub|Autobahn|-99|4}} — Auto
{{str sub|Autobahn|7|4}} — hn
{{str sub|Autobahn|8|4}} — n
{{str sub|Autobahn|9|4}} — Leerstring
{{str sub|Autobahn|99|4}} — Leerstring
Vorlagen-Version: 14. Feb. 2015, 15:36; Modul-Version: 23. Okt. 2015, 21:36

Habe weitere Testfälle angefügt, um das Verhalten von str sub zu klären. Demnach ist das Kernproblem die Implementierung/Bedeutung des Indexwertes: Die Doku beschreibt ein typisch unixoides Verhalten, d. h. das erste Zeichen im Text wird angeblich mit Indexwert 0 adressiert, das zweite mit Indexwert 1, usw. Dem ist aber nicht so! Tatsächlich steht das erste Textzeichen an der Position mit Indexwert 1, das zweite an 2, usw. (So ist z. B. auch die Vorlage:str index implementiert.)

Stellt sich die Frage: Bug oder Feature? Da str sub eine vielfach eingebundene Vorlage ist, gehe ich davon aus, dass ein Fehler in der Kernfunktionalität längst aufgefallen wäre. Daher ist die Implementierung wohl so gewollt und „lediglich“ die Doku fehlerhaft – richtig ?!

Nebenbei kommt mir noch das unterschiedliche str-sub-Verhalten an den beiden Textenden merkwürdig vor. Während am Textende die resultierende Zeichenkette immer kleiner wird (was intuitiv einleuchtet), liefert str sub am Textanfang immer die ersten Anzahl Zeichen, egal wie klein wie der Index ist ?!? Konsequent (und logisch) wäre doch eher folgendes:

  • {{str sub|Autobahn|1|4}} ⇒ Auto
  • {{str sub|Autobahn|0|4}} ⇒ Aut
  • {{str sub|Autobahn|-1|4}} ⇒ Au
  • {{str sub|Autobahn|-2|4}} ⇒ A
  • und ab Indexwert -3 immer der Leerstring.

PS: Auch die Beschreibung in der Navi-Leiste war falsch. Habe ich bereits korrigiert... --rolf_acker (Diskussion • Beiträge • Logbücher) 12:05, 21. Aug. 2018 (CEST)

Tja, die Problematik ist altbekannt, war auch bereits vor rund fünf Jahren kritisiert worden, blieb aber ergebnislos.
Ein Hintergrund ist, dass alle mit den genau gleichnamigen der enWP unbedingt exakt kompatibel sein müssen, was dann mal gelang, mal abwich.
Dort ist es en:Template:Str sub – diese erwähnt aber nur auf der Doku-Seite die Nummerierung beginnend bei Null, während die TemplateData-Darstellung hinsichtlich der Zählweise vage bleibt.
Die hiesige Programmierung ist allgemein ein konfuses Durcheinander aus Vorlagenprogrammierung, Untervorlagen {{Str sub/Call}} und Lua-Programmierung.
Auf WP:BETA gibt es seit fünf Jahren eine konsequente und einheitliche Lua-Implementierung nebst Testseite – hier diese.
VG --PerfektesChaos 12:52, 21. Aug. 2018 (CEST)
Hallo PerfektesChaos, Danke für die Infos, sind interessante Hintergründe, aber das hilft einem (potentiellen) Anwender der Vorlage:str sub leider nicht wirklich weiter. Möchte dazu zwei Dinge anmerken:
1. Die seit Jahren hier produktive Vorlage:str sub ist im Kern eine andere Funktion als ihre gleichnamigen Pendants in enWP bzw. ß-dewiki, da das erste Zeichen mit Indexwert 1 adressiert wird, während die beiden anderen bei Indexwert 0 starten.
2. Für Autoren/Vorlagenprogrammierer der deWP, die str sub verwenden wollen, ist es wichtig, dass eine stimmige Doku vorliegt. Das ist heute leider nicht der Fall!
Falls wir hier – insbesondere bei Punkt 2 – übereinstimmen, würde ich die Doku an die tatsächliche Implementierung der Vorlage anpassen. Wäre das aus Deiner Sicht ok? --rolf_acker (Diskussion • Beiträge • Logbücher) 14:16, 25. Aug. 2018 (CEST)
Nein, das ist absolut nicht ok.
  • Die enWP zählt ab Null, die saubere Lua-Lösung auf BETA zählt ab Null, unsere Vorlagendoku zählt seit 2009 (Beispiel 2013 unmittelbar vor Desaster) ab Null, weltweit alle Vorlagen einschließlich ggf. unserer eigenen seit 2009 verlassen sich darauf, dass ab Null gezählt wird.
  • Irgendwann wird es einen globalen Kanon weltweit unterstützter Vorlagen und Module für Basisfunktionen geben, der automatisch in allen Wikis nutzbar sein wird, und diese Zeichenkettenfunktionen sind prädestiniert dafür. Sie werden selbstverständlich ab Null zählen, weil das international einheitlich seit 2006 so gemacht wird, wenn eine Vorlage diesen Namen trägt.
  • Wenn du jetzt den Programmierfehler von 2013 nachträglich dadurch heiligst, dass du es zur korrekten Funktion erklärst, dann wird hinterher bei keiner Vorlagenprogrammierung mehr irgendjemand wissen, ob der deutsche Sonderweg von 2013 oder die international einheitliche Funktionalität gelten solle.
Das ist ungetestet und völlig überstürzt und in einem heillosen Durcheinander und ohne irgendwelche Absprachen Anfang Mai 2013 urplötzlich in den produktiven Artikelbestand geschossen worden, nachdem Lua seit Mitte April 2013 bei uns verfügbar wurde. Es sollte ein Experiment sein, wie sich wohl das Programmieren mit der neuen völlig unbekannten Programmiersprache anfühlen würde.
  • Es hatte niemals eine Gegenüberstellung der erwarteten Funktionalität und der momentan generierten Funktionalität gegeben, sonst wäre der Fehler noch in der Erprobungsphase aufgefallen. Es gab nie eine Erprobungsphase, sondern die Programmierung wurde unmittelbar am echten Artikelbestand ausprobiert.
  • Sowas oder sowas oder sowas oder die Tabelle ganz oben in diesem Abschnitt hatte es für diese Vorlage noch niemals gegeben. In der Dokuseite steht nur konstant, was herauskommen sollte, aber man war zu faul, daneben den Selbsttest zu schreiben, was die momentane Programmierung denn tatsächlich liefert; notfalls auf eine gesonderte Vorlagen- oder Modultest-Seite.
  • Bereits die Stümperei mit einer überflüssig dazwischengeschalteten Untervorlage {{Str sub/Call}} kostet nur Performance und verkompliziert die Angelegenheit sinnlos. So würde eine korrekte effiziente Lua-gestützte Programmierung dieser Vorlage aussehen.
VG --PerfektesChaos 16:24, 25. Aug. 2018 (CEST)
Jetzt mach mal halblang. Hinterher schlauer sein und den Mund weit aufreißen kann jeder. Zum o. g. Zeitpunkt hat niemand hier von einer Vereinheitlichung gesprochen. Das war überhaupt kein Thema hier. Diese Vorlage hier baut auf Lua auf und diese Sprache indiziert - im Unterschied zu vielen Hochsprachen - Zeichenketten ab 1. Ergo war es völlig logisch, das auch so zu übernehmen, zumal es ja auch anschaulicher ist. Die Vorlage ist, was es fragliche Werte angeht, schlichtweg tolerant (Für andere Mitleser):
  1. Ein Index kleiner 1 wird wie 1 (also "von Anfang an") gewertet, ein Index größer als die Stringlänge wird wie #variable, also den letzten Index behandelt.
  2. Sind nicht genug Zeichen vorhanden, um von der Startposition aus die angegebene Anzahl Zeichen zu kopieren, dann geht es bis zum Ende und das Ergebnis ist kürzer.
Selbstverständlich kann man das auf den Startindex Null ändern, indem man schlicht 1 dazuaddiert, aber das erfordert eine Kontrolle aller Vorlagen, welche die Vorlage hier einbinden. Das ist ein Riesenaufwand und hat eine chaotische Übergangsphase zur Folge. Was wohl nicht stimmt, ist die Doku. Behaupte nicht einfach willkürlich bei allem, was nicht von dir stammt, dass es schlecht umgesetzt sei. ÅñŧóñŜûŝî (Ð) 20:54, 25. Aug. 2018 (CEST)

Zunächst eine Bitte: Es wäre hilfreich, wenn WP:WQ beachtet werden würde!
Außerdem erscheint es mir jetzt hilfreich, wenn die aktuelle Doku-Problematik unabhängig von der „Vergangenheitsbewältigung“ behandelt wird. Fakt ist, dass die derzeit vorliegende Version von str sub (mit Indexierung ab 1) seit vielen Jahren produktiv in der deWP verwendet wird, aber fehlerhaft dokumentiert ist. (Wie gesagt, auf die Umstände wie es dazu kam, möchte ich hier nicht eingehen oder sie bewerten.) Und eine fehlerhafte Doku darf/muss korrigiert werden – das steht für mich außer Frage! Das ist im Übrigen auch keine nachträgliche Billigung der Aktionen von 2013; insbesondere dann nicht, wenn die Doku zwar jetzt an die dt. Sonderlösung angepasst wird, gleichzeitig aber z. B. darauf hingewiesen wird, wie die Funktion eigentlich hätte implementiert werden sollen und dass es eben eine Sonderlösung ist. Und dass zukünftig eine andere, sauber spezifizierte und Lua-gestützte Vorlage (mit abweichender Indexierung) zur Verfügung stehen wird. BTW: dann aber vermutlich unter einer anderen Bezeichnung, da der Name „str sub“ inzwischen verbrannt ist. Arg viel mehr kann man wohl zu dieser verkorksten str sub nicht tun – abgesehen vllt. vom Entfernen der Zwischenschicht str sub/call. Insgesamt betrachtet sollte man eigentlich str sub schnellstmöglich abkündigen...
Könnt Ihr Euch mit diesem Vorschlag bzgl. der Doku anfreunden? --rolf_acker (Diskussion • Beiträge • Logbücher) 00:55, 26. Aug. 2018 (CEST)

Nein, denn die hiesigen Programmierungen von 2009 bis 2013 gingen von der Zählung ab Null aus, und jede von draußen übernommene Vorlage erwartet ebenfalls die weltweit einheitliche Zählung ab Null, und die zukünftig zu erwartende unter dem Namen str sub global unterstützte Funktion wird ebenfalls ab Null zählen.
Es gibt nur die Möglichkeit, den bereits seit fünf Jahren beanstandeten Fehler jetzt endlich mal zu korrigieren und erstmalig die hiesige Lua-Untervorlagen-Mischmasch-Programmierung systematisch durchzutesten und das auch jederzeit reproduzierbar zu machen.
In der Doku kann gerne und nun erstmals darauf hingewiesen werden, dass es von 2013 bis heute diesen Programmierfehler gegeben hatte, und wer sich zwischenzeitlich entgegen dem in der Doku kontinuierlich seit 2006/2009 bis heute beschriebenen Verhalten darauf eingestellt hatte, dass die Zählung bei Null beginnt, muss das entsprechend nachführen.
Es ist nicht mein Versäumnis, dass der Umprogrammierer von 2013 sich konsequent weigert, seinen Fehler einzugestehen und die Diskrepanz zu den Resultaten bis 2013 und der enWP und der Beschreibung in der Doku auf fehlende systematische Erprobung zurückzuführen ist.
Wahrscheinlich gibt es aber nur wenige oder überhaupt keine bislang betroffenen Fälle, wo existierende Programmierungen nachgebessert werden müssten.
Dass der Name der Funktion „verbrannt“ sein mag, ist zwar misslich, aber ein deutscher Sonderweg wird das weder durch eine Umdefinition noch durch Inkompatibilität mit den früheren verwendenden Vorlagenprogrammierungen bis 2013 lösen. Das Durcheinander würde durch Heiligung des Programmierfehlers nur noch größer.
d:Q5622224 zählt 87 weitere Implementierungen auf, und die zählen mit großer Sicherheit alle ab Null.
Wie sowas zustande kommt, und das aus den seit vielen Jahren bemängelten methodischen Fehlern nichts gelernt wurde, lässt sich am gestrigen Nachmittag usw. an der Versionsgeschichte dieses Moduls nachvollziehen: Es wird alle Stunde am produktiv eingesetzten Modul herumexperimentiert, ob und wann es denn endlich wie erwartet funktionieren würde. Das sind hier nur 140 Einbindungen; genauso läuft es aber leider ab, wenn in 10.000 oder über 100.000 Artikel eingebunden wird. Die werden auch gnadenlos experimentell zerschossen; wenn zwei oder drei Artikel dann herausgepickt werden und es in deren Konstellation schließlich richtig aussieht, dann muss die Programmierung ja goldrichtig sein. Wochen später melden sich schließlich genervte Autoren in der Werkstatt, weil ihr ursprünglich korrekter Artikel jetzt seltsam beschädigt sei.
Wir haben seit 2013 die Möglichkeit, per WP:BETA in einer Simulation ohne Kollateralschäden alle Neuerungen durchzutesten, bevor wir ganz zum Schluss mit einer robusten Lösung hier in den produktiven Artikelbestand zurückkommen. Bis auf einen machen das auch alle so, die eine komplexere Änderung an Programmierungen vornehmen.
Für diese Vorlage hier hatte es weder 2013 noch 2015 noch sonstwann hierzuwiki ein systematisches und reproduzierbares Durchspielen der Resultate gegeben, sehr wohl aber 2013 auf BETA – mehrere Vorlagenleutchen hatten 2013 dazu aufgefordert, diesen Fehler zu beseitigen und die Programmierung dem bisherigen Zustand und der Doku und der enWP anzupassen, aber das wurde dreist ignoriert.
VG --PerfektesChaos 01:58, 26. Aug. 2018 (CEST)
Ok, die fehlende Abwärtskompatiblität war ein Fehler. Der ist aber gut fünf Jahre her und inzwischen dürften hier alle Vorlagen, welche auf die aktuellen Stringvorlagen zugreifen, an diese Abweichung angepasst sein. Wenn das also jetzt einfach so zurückgesetzt wird, dann werden die angepassten Vorlagen nicht mehr funktionieren. Eine Umstellung auf den Startindex Null kann m. E. also nur mit einem neuen Vorlagenset (für die Vorlagen mit Indexangabe) realisiert werden, welches dann parallel zu dem jetzigen in Betrieb wäre. Die aufrufenden Vorlagen müssten dann sukzessive umgestellt werden. Gibt es dann irgendwann keine Einbindungen der jetzigen Versionen mehr, dann wären sie dann hinfällig. ÅñŧóñŜûŝî (Ð) 19:51, 30. Aug. 2018 (CEST)
P.S.: Das Thema betrifft mehrere Vorlagen. Ich schlage vor, wir fangen es - diesmal ohne gegenseitige anspielungen und Sticheleien - in der Vorlagenwerkstatt neu an. ÅñŧóñŜûŝî (Ð) 20:01, 30. Aug. 2018 (CEST)

Es gibt genau sechs Vorlagen, die in ihrer Programmierung überhaupt die umseitige Vorlage einbinden.

  • Von denen sind mindestens zwei von dir selbst.
  • Wie viele von vor 2013 stammen, mag ich grad nicht ermitteln.
  • Es ist eine Selbstverständlichkeit, dass du diese Handvoll Vorlagen durchsiehst, ob sie überhaupt von der Angelegenheit betroffen wären (was nicht zwingend ist) und ggf. berichtigst.
  • Und es ist genauso selbstverständlich, dass der Programmierfehler von 2013 berichtigt und obendrein eine effiziente Umsetzung ohne Gehampel mit Untervorlagen erfolgt, etwa durch das schon seit 2013 auf BETA bereitstehende richtige und systematisch getestete Lua-Modul.

Ein Aufrechterhalten eines deutschen Sonderwegs und Inkompatibilität zum internationalen Schema kommt nicht in Frage.

  • Eine separate deutsche Vorlage mit anderem Namen und für deine Zählung ab Eins und eine noch andere Vorlage mit noch anderem Namen für die internationale Zählung ab Null ist nicht diskutabel; und für ganze sechs Verwendungen schon gar nicht.

VG --PerfektesChaos 20:19, 30. Aug. 2018 (CEST)

    • Es gibt auch Direktaufrufe des Moduls. die muss man auch durchsichten. ÅñŧóñŜûŝî (Ð) 23:18, 31. Aug. 2018 (CEST)
  • Die Dokumentationsseite zum Modul erwähnt eine Funktion sub interessanterweise überhaupt nicht; zumindest mit jetzigem Stand.
    • Damit ist die öffentliche Nutzung der Modul-Funktion direkt noch überhaupt nicht freigegeben worden.
    • Naturgemäß ist dann in der Modul-Dokumentation auch noch gar nicht beschrieben, mit welchen Parametern die Implementierung der Modul-Schnittstelle arbeitet.
    • Schon gar nicht wurde jemals sauber dargestellt, ob das Modul die Zählung bei Null (wie zu erwarten) oder aus unerklärlichen Gründen bei Eins beginnen würde.
  • Es gibt genau zwei Direktaufrufe der Modulfunktion durch anwendende Vorlagen.
  • Insgesamt gibt es
  • Es ist also nur eine Handvoll Vorlagen, ohnehin nur fünf von Außenstehenden, die sorgfältig geprüft werden müssen.
    • Es muss gar nicht in jeder Konstellation der Programmierfehler wirksam werden; siehe die den Abschnitt einleitende Tabelle.
    • Es muss jetzt auf jeden Fall für jede Fremdverwendung akkurat nachgeprüft werden, ob die Anwender
      • sich auf das Verhalten gemäß Dokumentation (also die Zählung ab Null) verlassen hatten?
      • sich am tatsächlichen Verhalten orientiert hatten, also die Zählung ab Eins nutzen?
      • nicht betroffen sind, weil der Fehler in dieser Kombination ausgeschlossen werden kann.
  • So oder so müssen alle fünf Vorlagen Dritter jetzt durchgearbeitet werden, und ggf. zusammen mit der ausstehenden Fehlerkorrektur im Modul angepasst werden.
  • Diese Debatte zieht sich jetzt bereits über fünf Jahre hin und kostet allein in diesem Abschnitt 20 kB und jede Menge Aufwand. Wäre der bereits im Sommer 2013 bekannte Fehler sofort behoben worden, bräuchten auch nicht die ab 2014 erfolgten Verwendungen überprüft werden. Bereits damals war die Fehlerkorrektur abgelehnt worden; bis in die heutige Zeit war die niemals irgendwo dokumentierte private Vorliebe für eine Zählung ab Eins und der wissentliche Bruch mit der vorherigen hiesigen Dokumentation und die absichtliche Inkompatibilität zur enWP nebst aller internationalen Klone über alle anderen Notwendigkeiten gestellt worden.
VG --PerfektesChaos 10:58, 1. Sep. 2018 (CEST)
@PerfektesChaos: Meinem Test nach sind im Modul m. E. die Funktionen index, find und sub betroffen. Bei den anderen kommt der Index nicht zur Wirkung. Es gibt aber noch Vorlage:Str right, bei der ich mir nicht sicher bin, welche Funktion sie genau erfüllen sollte. ÅñŧóñŜûŝî (Ð) 13:50, 1. Sep. 2018 (CEST)

Habe mir kürzlich mal die entsprechenden Vorlagen in der deWP und enWP angesehen, die mit absoluten Positionsangaben (Indizes) arbeiten:

Vorlagen zur Zeichenkettenverarbeitung mit absoluten Positionsangaben
deWP   enWP
Vorlage / Spezifikation Basis Beispiel Template / Specification Base Example
{{str index|Text|Index}} 1 {{str index|ABCDEF|2}} ⇒ B {{str index|text|number}} 1 {{str index|ABCDEF|2}} ⇒ B
{{str sub|Text|Index|Anzahl}} 1 {{str sub|ABCDEF|2|3}} ⇒ BCD {{str sub (old)|text|start|length}} 0 {{str sub|ABCDEF|2|3}} ⇒ CDE
nicht verfügbar {{str sub new|text|start|end}} 1 {{str sub new|ABCDEF|2|4}} ⇒ BCD
{{str right|String|Offset}} 1 {{str right|ABCDEF|2}} ⇒ CDEF {{str right|string|offset}} 1 {{str right|ABCDEF|2}} ⇒ CDEF
nicht verfügbar {{str mid|text|first|length|last}} 1 {{str mid|ABCDEF|2||4}} ⇒ BCD
{{str find|String|Teilstring}} 1 {{str find|ABCDEF|B}} ⇒ 2 {{str find|string|sub_string}} 1 {{str find|ABCDEF|BCD}} ⇒ 2
nicht verfügbar {{str find0|string|sub_string}} 0 {{str find0|ABCDEF|BCD}} ⇒ 1
nicht verfügbar {{str sub find|string|sub_string|offset}} 0 {{str sub find|ABCDEF|BCD|2}} ⇒ Leerstring
{{str sub find|ABCDEF|BCD|1}} ⇒ 1
nicht verfügbar {{strloc insert|string1|strloc=n|string2}} 1 {{strloc insert|ABCDEF|strloc=2|xyz}} ⇒ AxyzBCDEF
Stand: 27. August 2018

Demnach:
1. Alle (!) derzeit verfügbaren Vorlagen in der deWP arbeiten 1-basiert.
2. In der enWP gibt es kein einheitliches Bild bzgl. der Indizes; die meisten Vorlagen arbeiten da 1-basiert.
3. Das englische Pendant zur Vorlage str sub, um die es hier eingangs ging, wird als str sub old bezeichnet (hört sich eher nach Auslaufmodell an...)
Da hier mehrfach behauptet wurde, in Zukunft wäre eine international einheitliche Implementierung mit Zählung ab Null vorgesehen, würde mich interessieren, wo die Grundlage für so eine Behauptung ist. Wenn ich mir den Status quo so anschaue, sehe ich ein deutlich anderes Bild... --rolf_acker (Diskussion • Beiträge • Logbücher) 00:16, 2. Sep. 2018 (CEST)

Sehr interessant. Würde mich auch gerne wissen... ÅñŧóñŜûŝî (Ð) 01:22, 2. Sep. 2018 (CEST)

Indexfehler 2

  1. Vergleich mit der enWP
    1. Dass die enWP unter einem anderen Bezeichner auch die Zählung ab 1 vornimmt, ändert absulut nichts daran, dass unter dem Namen von 2006 die Funktionalität von 2006 auf immer und ewig in der enWP und allen anderen Wikis exakt unterstützt werden wird.
    2. Wobei ich persönlich das nicht old und new genannt hätte, was dem Anwender herzlich überhaupt nix sagt, sondern sie sprechend sub0 und sub1 getauft hätte, damit sich die unterschiedliche Funktionalität zweifelsfrei aus dem Namen ergibt.
    3. 2006, als diese Vorlagerei noch sehr neu und gerade erst die if-Abfrage eingeführt worden war, hatte irgendein Programmierer wohl mit C-Orientierung die ihm vertraute Null-Zählung definiert. Normalen Autoren mag sicher die Zählung ab Eins näher liegen. Das ist aber absolut megascheißegal, weil die einmal getroffene und über Jahre beibehaltene Entscheidung nie nie nie nie in inkompatibler Weise geändert wird.
    4. Da der hiesige Modul-Ersteller Dokumentationen nur selten sorgfältig liest oder schreibt oder berücksichtigt, ist die Geschichte von der 2013 getroffenen Entscheidung zur Umstellung der deutschsprachigen Wikipedia auf Einser-Zählung eine blanke Schutzbehauptung, ein Märchen, eine Ausrede, die schon im Sommer 2013 ergebnislos verreckte. Mal davon abgesehen, dass eine derartige eigenmächtige Entscheidung, einsam und allein, weder abgesprochen noch kommuniziert, unzulässig ist. Sie wurde auch nie in irgendeiner Zeile dokumentiert, nicht in der umseitigen Vorlagendoku, nicht in der Modul-Doku (die sub nicht mal erwähnt), nicht im Modul-Quuellcode. Es wurde schlicht und ergreifend überhaupt nicht drauf geachtet und der erste Parameter, das ist der Beginn der Zeichen, aha, das tun wir jetzt als Beginn-Parameter in Lua, zack, fertig ist die Laube. Ausgetestet und die umseitigen Beispiele als Soll-Ist-Vergleich, nö, wird schon klappen, wenn nicht, dann sollen die anderen Autoren kommen und sich beschweren und ihre Artikel anpassen.
  2. Globale Vorlagen
    1. Das steht unter mw:Requests for comment/Shadow namespaces (Ergebnis zahlreicher Forderungen).
    2. Die Arbeiten daran kommen langsam, aber kontinuierlich voran und werden unter den Entwicklern beachtet und angestrebt. Der Weg dorthin ist aber lang, mühsam und steinig.
    3. Das Prinzip ist von den Dateien bekannt, die im Commons shadow namespace liegen. Wenn in unserem Wikitext [[Datei:Question mark.svg]] vorkommt, dann gibt es in diesem Wikitext absolut keinerlei Möglichkeit, um herauszufinden, ob diese Datei lokal oder global=Commons vorliegt.
    4. Das solle genauso für User, Template, Module, Help umgesetzt werden.
    5. Weil die Umsetzung nicht schnell genug vorankam, wurde vorab dasselbe Konzept bereits für Globale Benutzerseite und globales .css/.js umgesetzt. Damit ist die wesentliche Notwendigkeit für User: bereits weitgehend erschöpft; ob es noch weitere globale Benutzerseiten in einem Shadow geben wird, wäre abzuwarten.
    6. Help: wird kaum realisiert werden, weil es bereits (inzwischen) eine von Projekten unabhängige (also auch für karlsruhe: oder Wikia gültige) Hilfeseiten-Sammlung in vielen Sprachen übersetzt gibt als mw:Help:Templates usw. Dazu ein Konkurrenzprodukt aufzuziehen und zu pflegen wird keiner machen. Schon der Sprachdschungel, damit ein normaler Spanier oder Russe als Autor eine scheinbar lokale Hilfeseite zu seinem Problem auswählen kann, und im Suchfeld aus 100 Seiten mal 200 Weiterleitungen des Titels in anderen Sprachen zu filtern, und letztlich einen englischen Text zu lesen, ist gaga.
    7. Vorlagen und Module:
      1. Dies wird vielfach sehnsüchtig gefordert.
      2. Die Wirkung wäre, dass in allen fast 1000 WMF-Wikis automatisch bestimmte Vorlagen und Module immer vorhanden und durch andere Vorlagen nutzbar sind. Es sei denn, es gäbe unter demselben Namen eine lokale Seite; dann hat diese Vorrang wie ein lokales Bild.
      3. Geeignet dafür sind aber nur relativ wenige Aufgaben, die eine Reihe von Kriterien erfüllen müssen:
        1. Das Ergebnis muss weitgehend sprach-, schrift- und kulturunabhängig sein.
        2. Die Aufgabenstellung muss global in gleicher Art sinnvoll sein.
        3. Nebenbei muss die Namensgebung sprechend und selbsterklärend sein. Die enWP verwendet traditionell einen Wust von kryptischen Abkürzungen für Vorlagen, die niemand außer Experten begreifen und nachvollziehen und einsetzen kann.
        4. Vorlagen der enWP sind seit jeher nur für die enWP und nur für englischsprachigen Kontext vorgesehen; Anpassung an andere Projekte wird in Modulen oder Vorlagen oder auch vielen Skripten grundsätzlich nicht eingeplant. Insofern wäre es eine Träumerei zu glauben, dass da mal eben 500 Vorlagen der enWP zum Weltmaßstab würden.
      4. Was sich grundsätzlich gut als globale Vorlagen und Module eignet, sind Basisfunktionen für Numerik, Zeichenketten oder Wikidata-Zugriffe; auch ISO-Datum, Kalender und Maßeinheiten-Umrechnung.
        1. Ich sehe nur um die 50 Vorlagen aus diesem Bereich; darunter auch die in Rede stehende Str-Familie mit allen Spielarten.
        2. Numerisch geht etwa {{Max}} intergalaktisch (beachte den Soll-Ist-Vergleich unter „Beispiele“).
      5. Ansonsten können gelegentlich ohnehin schon vorhandene Systemnachrichten mitgenutzt werden, oder es wird mal speziell dafür eine Systemnachricht angelegt und in 300 Sprachen übersetzt.
      6. Ach ja, und selbstverständlich wird str sub oder str left in der 2006 festgeschriebenen Funktionalität und Zählweise und optionalen wie Pflichtparametern mit dabei sein, denn deren Programmierung wird auf sehr vielen Wikis für vorhandene Anwendungen vorausgesetzt.
    8. Noch nicht geklärt wurde, wer oder was ein Host sein solle.
      1. Denn jedes Wiki braucht seinen Vorlagen- und Modulnamensraum auch für sich selbst, aber nicht alles, was da zufällig drinsteht, darf automatisch internationale Anwendung werden.
      2. Außerdem müssen dann alle Seiten im Namensraum geschützt werden; lohnendes Angriffsziel für globalen Vandalismus oder Opfer stümpernder Rumprogrammierer dieses Planeten. Vor jeder Änderung an einer global eingebundenen Seite muss ein Review-Prozess und eine Erprobung erfolgen. Einpflegen nur durch Global-Administratoren.
      3. In Frage kämen gesonderte Namensräume etwa auf dem Meta-Wiki oder ein eigenes Wiki nur für globale Seiten ohne Eigenbedarf.
      4. Es war schon eine verunglückte Konstruktion, dass die normale Benutzerseite auf dem Meta-Wiki entweder immer auf allen Wikis gilt und man auf dem Meta-Wiki keine spezielle Benutzerseite haben kann, oder gar nicht global.
    9. Ebenfalls ungeklärt ist die automatische lokalsprachlich generierte Vorlagendokumentation sowohl ausführlich als Dokumentationsseite mit Verlinkungen wie auch ohne Verlinkungen im VisualEditor per TemplateData.
  3. Die obige Tabelle sagt im Übrigen herzlich wenig über irgendwas aus.
    1. Da werden vier vergleichbare Vorlagen gegenübergestellt, und bei der einen hatte der Programmierer von 2006 bei Null angefangen und bei anderen hatte man das nicht gemacht.
    2. Ist aber auch völlig wurscht, weil für die 2006 gesetzten Profile diese nunmehr Ewigkeitscharakter haben.
    3. Ewigkeitscharakter heißt auch: Über die Entscheidung von 2006 mag ewig rumphilosophieren, wer das toll findet, ändert aber nix, weil das 2006 gesetzte Profil niemals mehr geändert werden kann, und deshalb aus dem ganzen Rumdiskutieren niemals was rauskommen wird.
  4. Dieser Driss hier hat mich in dieser Woche für beschissene acht Verwendungen über ein Dutzend Arbeitsstunden gekostet, und das gleiche Drama hatten wir Sommer 2013 schon mal.
    1. Leider taucht das periodisch alle paar Monate aus immer den gleichen Gründen mit immer den gleichen Auswirkungen seit über einem Jahrzehnt wie das Murmeltier auf, mal hier, mal da.
    2. Den gestrigen Samstagnachmittag wurde mal wieder aus heiterem Himmel ein Dutzend Wikipedianer mit der Fehlersuche in ihren zerschossenen Artikeln beschäftigt (VWS, A/A, BD), weil spontan entschieden wurde, einen optionalen Parameter zum Pflichtparameter zu erklären.
    3. Das war wieder ein Dutzend Arbeitsstunden und Nerven, die völlig sinnlos verbraten werden und die Autoren von Artikelarbeit und anderen wichtigen Aufgaben abhalten.
    4. Ich bin mega-angekotzt von der Rücksichtslosigkeit, mit der immer und immer wieder allen anderen eine Agenda aufgezwungen wird, um den angerichteten Schaden baldmöglichst wieder zurückzubauen, und erstmal die Ursache zu finden.

VG --PerfektesChaos 14:29, 2. Sep. 2018 (CEST)

Ich hoffe ja nicht, dass das der Versuch ist, mit möglichst viel Text die Diskussion abzuwürgen ;-) Es wäre aber schon hilfreich, bei der Problematik zu bleiben und alles andere wegzulassen.
Bisher wurde schon mit Vorgängen aus 2013/14 argumentiert, aber nachdem jetzt 2006 (!) ins Spiel kommt, halte ich einfach mal fest: Das ist alles viiiele, viiiele Jahre her! Und der heutige Status Quo ist bereits mehrere Jahre produktiv im Einsatz. Da kann man doch nicht ernsthaft erwarten, dass auf irgendwelche Fehlentwicklungen vor x Jahren noch Rücksicht genommen werden soll; erst recht, wenn es um etwas geht, dass „megascheißegal“ ist. Für mich ist die (heutige!) Situation (in der deWP) bzgl. der abs. Positionsangaben ziemlich eindeutig; und die ist schon seit einigen Jahren so. Auch wenn die Umstände, wie es dazu kam, extrem ärgerlich sein mögen (und ich Deinen Frust darüber verstehen kann): hart ausgedrückt, das interessiert heute nach so langer Zeit nicht mehr. Im Übrigen – um zum Ausgangsproblem zurückzukommen – wollte ich lediglich eine Doku-Korrektur anstoßen! Ich werde es jedenfalls nicht akzeptieren, dass die Korrektur einer mangelhaften Doku mit Hinweis auf Vorgänge von 2014 oder gar 2006 blockiert wird. Ich gehe davon aus, dass dieser Standpunkt verständlich ist (ansonsten einfach mal das Thema aus Anwendersicht betrachten). Grüße --rolf_acker (Diskussion • Beiträge • Logbücher) 20:01, 2. Sep. 2018 (CEST)
Es geht um lächerliche fünf Verwendungen durch Unbeteiligte, von denen unklar ist, ob sie überhaupt von der Zählung betroffen wären, und ob deren Bearbeiter sich nach der umseitigen Doku gerichtet hätten oder nach tatsächlichem Verhalten, und ob das jemals wahrgenommene Auswirkungen in den Einbindungen hatte.
Es ist die Verantwortung des Rumbastlers von Mai 2013, seinen bereits seit Sommer 2013 bekannten Programmierfehler zu eliminieren und dadurch ggf. erforderlich werdende Korrekturen in diesen fünf Verwendungen entsprechend zu führen, falls überhaupt nötig. Seine eigenen drei wird er ja wohl kennen.
Dazu ist innerhalb einer Minute in den parallel geöffneten Browser-Fenstern auf „Speichern“ zu klicken, so dass es zu keinen merklichen Fehlern in den Darstellungen kommt.
Wenn das schon im Sommer 2013 beseitigt worden wäre, dann hätte es die offenbar erst seitdem entstandenen 8 problematischen Verwendungen nie gegeben. Aber da wurde rumgeeiert, man fände das ja angeblich viel hübscher wenn sowas ab 1 gezählt würde – dabei wurde das nie beabsichtigt, sondern einfach nur der Wert „Beginn“ von der Vorlage an die Lua-Funktion durchgereicht, ohne den Unterschied in der Zählung wahrzunehmen, geschweige denn jemals die umseitig dokumentierten Verwendungsfälle durchzutesten, ohnehin die umseitige Doku überhaupt zu lesen.
Es wird definitiv unter dem Namen str sub niemals eine legalisierte Zählung ab Eins geben, die uns dann mit Einführung der globalen Vorlagen noch viel größere Probleme bereiten wird, weil dann überhaupt keiner mehr durchblickt, welche jetzt grad den deutschen Sonderweg meint und welche die aus der globalen und in Hunderten von Wikis wirkende Fassung ist. Mit Einführung der globalen Vorlagen werden alle lokalen Versionen hier nämlich getonnt werden.
Es ist Sache des Verursachers 2013, seinen Fehler und die Folgen jetzt endlich unverzüglich zu beseitigen und die von ihm verursachte Konfusion zu beenden. Dann ist auch keine Konfusion in der Dokumentation erforderlich.
VG --PerfektesChaos 20:58, 2. Sep. 2018 (CEST)

(Ich habe deine Auflistung mal auf Nummern umgestellt,um ggf. besser Bezug nehmen zu können)

  1. Zu 1.1.: Wo sind die Versionen von 2006? Hier und in enWP sind die ersten Versionen von 2009...
  2. Du schreibst mehrmals (2.7.6, 3.2 und noch ein paar), dass die 2006 getroffene Festlegung angeblich nicht mehr geändert werden kann(!) Eine Erklärung dafür, warum das angeblich nicht mehr zu ändern ist, und warum die globale Funktion deshalb bei Null anfangen muss(!) hast du hier noch nicht aufgezeigt. Aus meiner Sicht sieht es sehr danach aus, als ob es deine persönliche Vorliebe ist, die globale Version nullbasiert umzusetzen. Man bekommt sogar den Eindruck, dass du befürchtest, eine verbreitete einsbasierte Realisierung in den Wiki-Vorlagen könnte zu einer einsbasierten Realisierung der globalen Funktion führen, was nicht deinen Interessen entspräche. Ich würde eine derartige, anwenderfreundliche Methode bevorzugen. Es ist der explizite Wunsch der Betreiber der WP, dass auch Nicht-Programmierprofis Vorlagen erstellen können und denen wird man schwer die Notwendigkeit belegen können, warum ein Teilstring str_sub(irgendeintext,5,3) nicht beim 5. sondern beim 6. Zeichen beginnen soll. Es spricht also einiges dafür, der einsbasierte Version den Vorzug zu geben und lokalen Vorlagen daran auszurichten. Belege bitte diesen "Ewigkeitscharakter".
  3. Nachdem die Vorlagen mehrere Jahre einsbasiert aktiv sind, ist die Gefahr groß, bei einer Umstellung auf nullbasiert mehr zu zerstören als zu reparieren. Das gilt besonders im Zusammenhang mit en:WP, wo es die Tendenz zur einbasierten Zählung gibt. Für diese Umstellung möchte ich von dir zumindest mal Beweise dafür sehen, dass spätere globale Umsetzungen garantiert (!) nullbasiert sind.
  4. Zum Thema Vorgabewert (4.2.): Es ist eine absolut idiotische Idee, einer derartigen Stringfunktion einen Defaultwert zuzuordnen, schon gar nicht eine Eins. Derartige Funktionen müssen - wie du selbst schreibst - sorgfältig gehandhabt werden und dazu gehört, Parameter immer explizit anzugeben. Du weist selbst ganz genau, dass es sauberer Programmierstil wäre, wenn der Aufruf von Str_len ohne 2. Parameter eine Fehlermeldung generieren würde. Es ist garantiert sinnvoll, den 2. Parameter zur Pflicht zu machen, unabhängig davon, ob ich das gestern auf ausreichend sorgfältige Weise angegangen bin oder nicht.
Thema Korrektur durch mich: Nur wenn die einsbasierten Versionen wirklich später Probleme machen (bitte belegen, siehe oben), werde ich das Risiko, Das Modul:Str im jetzigen Status nochmal anzufassen, eingehen. Auch bei Nutzung des Beta-Wikis bleibt ein Restrisiko. ÅñŧóñŜûŝî (Ð) 22:55, 2. Sep. 2018 (CEST)
Abgerufen von „https://de.wikiup.org/index.php?title=Vorlage_Diskussion:Str_sub/Archiv/1&oldid=217240016“