Benutzer Diskussion:Dirk123456/Baustellenbaustelle 001/Baustelle-D/Baustelle-D.12

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Dient dem Test eines Antwortbeitrags

[Quelltext bearbeiten]
Letzter Kommentar: vor 4 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

Hier wird die Formatierung eines Antwortbeitrags getestet.

Feedback von Benutzer:Dirk123456:

  • Hallo und vielen Dank für das Update zu Prototyp 1, dem „Vorlagen-Finder“!
Navigation innerhalb dieses Beitrags: Prototyp-1-Update ↓ / Rückmeldungs-Optionen ↓ / Erstens ↓ / Zweitens ↓ / Drittens ↓ / Viertens ↓ / Die Punkte im Einzelnen ↓ / 1a ↓ / 1b ↓ / 1c ↓ / 1d ↓ / 1e ↓ / 1f ↓ / Versuch einer Gesamtbetrachtung ↓ / Für und Wider ↓ / Fazit ↓ / Ende ↓ /
Ein Pfeil nach links (←) zeigt einen Link zur „Vorderseite“ ( Überschrift auf der Projektseite.
Ein „Vorlagen-Finder“ geht ein wenig in die Richtung, wie ich mir mal etwas auf einem Parkplatz für Probleme unter der Überschrift „Leichter finden“ gewünscht hatte (15. August 2019, oldid=191363832#Leichter_finden).
Allerdings kannte ich damals noch nicht die technische Vielfalt, mit der Vorlagen umgesetzt werden und war der Meinung, dass man, wenn man den Namen einer Vorlage kennen würde, schon die halbe Miete drin hätte. Dieser Optimismus erwuchs unter anderem daraus, dass ich über TemplateData (Hilfe:TemplateData) wenig wusste.
Ihr freut euch „über jede Art von Rückmeldung, entweder auf der Diskussionsseite oder in der Schnellumfrage in diesem Abschnitt“. Ich hatte versehentlich auf den Absenden-Knopf der „Schnellumfrage“ gedrückt, ohne irgendeinen Haken gesetzt zu haben. Die Anzeige wechselte auf einen neuen Text, etwas wie „Danke für deine Rückmeldung ...“ der verschwand, als ich die Seite aktualisierte.
Bei den Prototypen 2 und 3 gab es zwar in der Schnellumfrage zuunterst den Punkt: „Keiner der oben genannten“ (Vorschläge ist sinnvoll); bei der Schnellumfrage des Prototyp-1-Updates weiß ich das aber nicht. Daher bin ich nicht sicher, ob mein versehentliches Absenden
  • so gewertet wird: „Der Benutzer lehnt alle Punkte ab“
  • oder so: „Die versendete Nachricht ist leer und daher ungültig“.
Ich wollte eigentlich von Anfang an die Diskussionsseite nutzen und nicht die Schnellumfrage. Mein Benutzer-Fehler hat mich so erschreckt, dass ich darüber nachgedacht habe, ob das ausschließende Oder in der Formulierung: „entweder auf der Diskussionsseite oder in der Schnellumfrage“ ernst gemeint sei und die Zahl der Entscheidungsmöglichkeiten relativieren sollte. Die beliebige Menge in der Formulierung: „jede Art von Rückmeldung“ würde dadurch auf die Anzahl 2 reduziert werden, wobei die maximale Zahl anwendbarer Elemente 1 wäre – eben entweder Diskussionsseite oder Schnellumfrage.
Immerhin stand ja in der Schnellumfrage ganz unten im Kleingedruckten ein Hinweis über Datenschutz. Den Datenschutz-Link zu einer Seite auf einem anderen Wiki außerhalb der Wikipedia hatte ich zwar noch kurz gesehen, finde ihn aber nicht mehr, weil das Dialog-Fenster der Schnellumfrage im Browser nicht mehr auftaucht.
Falls also der Verdacht aufkommt, dass ich einen billigen Trick anwenden will, um mein Feedback höher zu wichten, indem ich beides nutze, die Schnellumfrage und die Diskussionsseite – das ist nicht der Fall. Die Schnellumfrage war ein versehentlicher Klick.
Ich beantworte im Folgenden die Fragen, die als Anhaltspunkte für die Rückmeldung empfohlen werden.
  • Erstens (Anhaltspunkte/ Fragen): „Würde der Vorlagen-Finder die Suche nach der richtigen Vorlage vereinfachen? Wie?“
Das lässt sich schwer beantworten. Wenn man davon ausginge, dass eine Heerschar von Wikipedianer*innen gewonnen werden könnte, die am IST-Zustand in Hinsicht auf die Vorlagen schnell etwas ändern könnte – eher nicht. Wenn man ein robustes Analyse-Tool baut, dass auch dann sinnvolle Ausgaben liefert, wenn die Idealbedingungen nicht vorhanden sind (also beispielsweise wenn TemplateData nicht vollumfänglich angewendet wurde), dann ist es möglicherweise hilfreich. Der zweite Teil der Frage: „Wie?“ ist auch nicht leicht zu beantworten.
  • Zweitens (Anhaltspunkte/ Fragen): „Welche Funktion ist am nützlichsten? Welche bietet den geringsten Mehrwert?“
Wer „Vorlagen-Finder“ sagt, sagt auch Suchen (1a), Filtern (1b) und Sortieren (1c). Im Detail ist das schwieriger. Wer beispielsweise nach Kategorien filtern will, weil es Kategorien gibt, nicht aber nach dem „Vorlagentyp“, z. B., weil es so etwas (bisher) nicht gibt, kann die Schnellumfrage nicht nutzen. Beides ist unter ein 1b zu finden und man kann keine „halben Haken“ vergeben, um das eine aus- und das andere abzuwählen.
  • Drittens (Anhaltspunkte/ Fragen): „Wie fügt sich der Vorlagen-Finder in bestehende Arbeitsabläufe ein?“
Gegenwärtig gar nicht, da es keinen „Vorlagen-Finder“ gibt, falls ich das richtig sehe. Bitte korrigiert mich, falls ich mich da irre! Ich schreibe das nicht, um euch zu ärgern, sondern weil ich tatsächlich nicht ganz sicher bin, ob es ein solches Tool bereits gibt; immerhin kann beispielsweise der Visual Editor (WP:VE, H:VE) ja auch schon jetzt Auswahl-Listen anbieten:
  • Text-Ergänzung im Menü-Punkt: "Einfügen"→ "Vorlage"→ "Eine Vorlage hinzufügen".
Es klingt erstmal gut, wenn man im Visual Editor ein umfassenderes Tool zur Verfügung hätte:
  • Artikel aufsuchen → "Seite bearbeiten" → „Vorlagen-Finder“ öffnen → Suchen, filtern, auswählen → Vorlage einfügen.
Allerdings bin ich nicht sicher, ob es wirklich möglich ist, ein umfangreiches Tool überall gleichermaßen zu nutzen und ob das an jeder Stelle im jedem Arbeitsablauf übersichtlich bliebe.
  • Viertens (Anhaltspunkte/ Fragen): „Die Erweiterung von TemplateData würde die Menge der maschinenlesbaren Informationen über Vorlagen erhöhen und ihren Nutzen damit erheblich steigern. Allerdings würde das auch Arbeitsaufwand für die Community bedeuten. Stehen Ziel, Nutzen und Aufwand hier im richtigen Verhältnis?“
Ziel, Nutzen und Aufwand stehen hier aus meiner Sicht nicht im richtigen Verhältnis. Ich würde gern etwas anderes behaupten. Es gibt aber Themen, die erst einmal einfacher erscheinen als TemplateData (Hilfe dazu) und trotzdem problematisch sind.
Ich erinnere daran, dass der Wunschfindung im Juni 2019 (die im Themenschwerpunkt „Leichter mit Vorlagen arbeiten“ mündete), eine „Globale Konsultation zum Thema Kommunikation 2019“ voraus ging. Diese Konsultation wurde auch in die deutsche Wikipedia getragen (die Seite „Phase 1“ startete am 25. Februar 2019, oldid=186035070).
Markant finde ich folgende Aussage:
  • „Neulinge finden die Diskussionsseiten zunächst nicht und können daran schlecht teilnehmen, weil sie völlig anders funktionieren als die üblichen Foren“ (am 25. Mai 2019 erstmals auf der Seite „Phase 2“, oldid=188924565).
Die Aussage geht auf eine Untersuchung zurück, die zehn Testpersonen einbezog und (unter anderem?) in ähnlicher Form in einem englischen „Phase-1-Bericht“ auftauchte (am 15. Mai 2019 unter mediawiki.org, oldid=3230200: "All of the users struggled to find talk pages. [...] When the test directed them to the 'Discussion' tab, all of the users expected to see a typical message board or a discussion forum").
Worauf ich hinaus will, ist, dass die „Erweiterung von TemplateData“ zwar „die Menge der maschinenlesbaren Informationen über Vorlagen erhöhen“ würde, aber nicht die Menge der für die meisten Menschen gut lesbaren Information, also für „Maximila Musterfrau“ und für „Otto Normalverbraucher“. Wo sollen den die „Ganz-viel-TemplateData-in-die-Vorlagen-Integrations-Expert*innen“ herkommen?
Wer heute die maschinenlesbare Information der Form TemplateData (Hilfe) in Vorlagen bzw. in deren Dokumentationen integrieren will,
  • muss von dem Thema Ahnung haben, auf dass sich der Zweck der jeweiligen Vorlage bezieht, sie oder er
  • muss mit den TemplateData umgehen können, sie oder er
  • sollte sich verständlich und trotzdem prägnant ausdrücken können (Dokumentation der Vorlage), sie oder er
  • sollte vielleicht den zugrunde liegenden Programm-Code (H:Vorlagenprogrammierung) – zumindest in seinen Grundzügen – lesen können, sie oder er
  • sollte ein(e) „Menschenfänger*in“, sein, da man Zugriff auf verschiedene Seiten benötigt, sie oder er
  • braucht belastbare Nerven, Geduld und
  • viel, viel Zeit. (-; diese Aufzählung kann ich gesichert als unvollständig bezeichnen ;-)
Es kommt hinzu, das einige Codes ein bisschen menschlich und ein bisschen „maschinlich“ lesbar sind. Das betrifft vor allem die Auszeichnungssprache Wikitext als Basis, die es dem Menschen einfach (da halbwegs intuitiv) und der Maschine möglich machen soll, damit umzugehen. Die ursprünglich namensgebende Intension, Wikiwiki! (havaiianisch für „schnell“) gilt für die „Aufpfropfungen“, wie Vorlagen-Programmierung und TemplateData, nicht mehr.
Ich dachte mal, dass die TemplateData irgendwie in den Programm-Code integriert wären. Im Grunde genommen läuft es aber wohl meistens darauf hinaus (zumindest nehme ich das so war), dass das Codierungs-Sytem TemplateData wie eine eigene Auszeichnungssprache arbeitet. Der für die jeweilige Vorlage notwendige Text mag maschinenlesbar sein, entsteht aber durch Handarbeit. Der konkrete Text, der für die entsprechende Vorlage zum Einsatz kommt, besteht wohl ein wenig aus JSON (H:TemplateData/JSON), ein bisschen aus Englisch und auch aus Deutsch.
Ich hatte zu dem Thema TemplateData+Anwendung schon beim Prototyp 3 auf der Diskussionsseite etwas „hinterlassen“ (29. Juni 2020, oldid=201420686, dort Feedback von Dirk123456, vor allem bei den Punkten Prototypen 3.5 bis 3.8b und Zusammenfassendes und Allgemeines).
  • Die Punkte im Einzelnen
Die Prototyp-Punkte 1a bis 1d enthalten aus meiner Sicht jeweils mehrere Teilvorschläge bzw. Unterpunkte (drei unter 1a, vier unter 1b, drei unter 1c, vier unter 1d und vier unter 1e). Der fünfte Prototyp-Punkt, 1f, beinhaltet nur einen Vorschlag. Es gibt also fünf Punkte oder „Hauptvorschläge“ (1a bis 1f) mit insgesamt 19 „Teilvorschlägen“ (1a.1; 1a.2; ... 1e.4; 1f.1).
Entschuldigt bitte, dass ich die Vorschläge noch weiter untergliedert habe, als das auf der Projektseite vorgesehen wurde! Eigentlich mag ich das nicht so, wenn jeder sein eigenes Nummern-System entwickelt. Ich finde das hier beleuchtete Thema aber weder unbedeutend noch einfach. Daher versuche ich alles zu gliedern und möglichst eindeutig zu benennen, „was nicht bei drei auf dem Baum ist“; das ist meine Art, mit Komplexität umzugehen.
Im Folgenden steht unter jedem Punkt oder „Hauptvorschlag“ eine Liste mit den jeweiligen „Teilvorschlägen“. Rechts neben jedem „Teilvorschlag“ steht zur besseren Orientierung ein Textausschnitt (in Kursivschrift), wie er auf der Projektseite zu finden ist.
1a.1 — 1. Teilvorschlag; 1. von 3 in 1a (Dokus ausblenden) — Dokumentationsseiten aus den Suchergebnissen entfernen
1a.2 — 2. Teilvorschlag; 2. von 3 in 1a (Flexible Zeichenketten) — Die Reihenfolge der Wörter hat keinen Einfluss auf die Ergebnisse ...
1a.3 — 3. Teilvorschlag; 3. von 3 in 1a (Alles durchsuchen) — Ausdehnung der Suche auf die Beschreibung der Vorlage ...
Die Teilvorschläge 1a.2 (Flexible Zeichenketten, Suche im gesamten Namen) und 1a.3 (Alles durchsuchen, Beschreibung der Vorlage) sind sinnvoll.
Der Teilvorschlag 1a.1 (Dokus ausblenden) kann möglicherweise zu Verwirrungen führen, da jede Seite – so wie ich es verstehe – laut H:Vorlagenprogrammierung potentiell als Programm-Code+Dokumentations-Seite angelegt ist (Unterscheidung von Code und Doku z. B. durch verschiedenartige include-Tags).
Auch das Wort „Beschreibung“ (1a.3) ist mehrdeutig. Die meisten Menschen werden unter „Beschreibung der Vorlage“ wohl den gesamten Text verstehen, den sie zu Gesicht bekommen, wenn sie die jeweilige Vorlage anklicken, egal wo dieser Text herkommt. Entfernt man nun Dokumentationsseiten aus der Such-Anfrage, blendet sie aus oder entfernt sie aus den Suchergebnissen, sollte das resultierende Datenset – rein von der Plausibilität her gesehen – keine Dokumentationen aufweisen, also auch keine Beschreibungen.
Was passiert nun eigentlich, wenn man die Dokumentationsseiten zwar ausklammert, die Beschreibungen aber einbezieht?
1b.1 — 4. Teilvorschlag; 1. von 4 in 1b (Namensraum) — vorgesehener Namensraum: In der Wikipedia gibt es verschiedene Namensräume ...
1b.2 — 5. Teilvorschlag; 2. von 4 in 1b (Vorlagentyp) — Vorlagentyp: Wikis haben verschiedene Vorlagentypen wie Banner, Zitate ...
1b.3 — 6. Teilvorschlag; 3. von 4 in 1b (Kategorie) — Kategorie: Das Ziel bei Kategoriefiltern wäre es, bestehende Kategorien besser ...
1b.4 — 7. Teilvorschlag; 4. von 4 in 1b (TemplateData) — TemplateData vorhanden/nicht vorhanden: Die Suche könnte das Filtern nach Vorlagen ...
Das klingt erst einmal gut, dass man nach dem vorgesehener Namensraum (1b.1), dem Vorlagentyp (1b.2), der Kategorie (1b.3) und dem Vorhandensein von TemplateData (1b.4) filtern könnte.
Auf der anderen Seite ist wenig davon ohne die massive Bearbeitung der einzelnen Vorlagen und ihrer jeweils zugeordneten Ressourcen möglich. Das Team Technische Wünsche gab/ gibt unter den Hinweis „Wichtig:“ zwei Sätze als Kommentar an:
  1. „Der Vorschlag enthält einige Filter, die auf vorhandenen Daten in TemplateData (maschinenlesbare Metadaten über einzelne Vorlagen) basieren, während andere das Hinzufügen neuer Felder erfordern würden.“ und
  2. „Diese Inhalte würden nicht vom Team Technische Wünsche hinzugefügt, sondern wären flexibel und würden in jedem Wiki nach Bedarf von der entsprechenden Community hinzugefügt.“
Den ersten Satz kann man in zwei etwas verschiedenen Varianten interpretieren, da das Wort TemplateData sowohl für das allgemeine Konzept (also z. B. für die prinzipiell definierten Datentypen) als auch für die konkrete Anwendung verwendet wird (also beispielsweise für die Zuordnung eines Datentyps zu einem Parameter in einer Vorlage). Ich bin jetzt nicht wirklich sicher, ob mit dem „Hinzufügen neuer Felder“ neue Sorten von Feldern gemeint sind oder „nur“ die konsequenten Anwendung von bereits definierten „Feld-Typen“ (das heißt wahrscheinlich anders, deswegen Anführungszeichen).
Ich vermute mal, dass man für den vorgesehenen Namensraum (1b.1) und für den Vorlagentyp (1b.2) neue „Feld-Typen“ brauchen würde.
Weiterhin stelle ich fest, dass ich nicht genau weiß, was denn ein „Wiki“ ist. Bisher bin ich davon ausgegangen, dass die deutsche Wikipedia ein einzelnes Wiki wäre, dass eine Community hätte, die vom Team Technische Wünsche (TTW) unterstützt würde, dass zur Wikimedia Foundation Deutschland (WFDE) gehört. Wenn das TTW (im zweiten Satz) darüber schreibt, welche Inhalte es „in jedem Wiki“ nicht hinzufügen würde und dass diese Inhalte „nach Bedarf von der entsprechenden Community hinzugefügt“ werden könnten, stellt sich die Frage, was das soll.
Meine erste Idee dazu war, dass es tatsächlich nur um die deutsche Wikipedia gehen würde, so, wie man es ohne zusätzliche Informationen erst einmal erwartet. Unter dieser Maßgabe gäbe es „Unter-Strukturen“ und ein „Wiki“ wäre vielleicht ein mehr oder weniger abgegrenzter Bereich innerhalb eines übergeordneten „Wikis“, z. B. in der deutschen Wikipedia.
Meine erste Idee dazu ist, dass das TTW den Wunsch nach einem TemplateData-Datentyp „Vorlagentyp“ an die Wikimedia Foundation weiterreichen würde, dann käme es gegebenenfalls zur Integration eines Datentyps "TemplateType" (oder so ähnlich) und dann könnten die Gemeinschaften, z. B. die Community der deutschen Wikipedia, sich darum kümmern, wie dieses neue Feature an die Vorlagen angepasst werden soll.
Während eine spezielle Kategorie „vorgesehener Namensraum“ wenigstens eine überschaubare Zahl von definierten Elementen beherbergen würde (eben die Namensräume), besteht meines Erachtens die Gefahr, dass für eine spezielle Kategorie „Vorlagentyp“ keine Begrenzung gefunden wird, was die Unterkategorien betrifft.
1c.1 — 8. Teilvorschlag; 1. von 3 in 1c (Relevanz) — Relevanz: Vorlagen nach ihrer Relevanz ordnen, wobei der ...
1c.2 — 9. Teilvorschlag; 2. von 3 in 1c (Alphabetisch) — Alphabetische Reihenfolge: Vorlagen alphabetisch nach ihrem Namen ordnen.
1c.3 — 10. Teilvorschlag; 3. von 3 in 1c (Popularität) — Popularität Vorlagen danach ordnen, wie oft sie ...
Beim Sortieren wäre das Weglassen der alphabetischen Reihenfolge als Möglichkeit quasi ein No Go – Teilvorschlag 1c.2 ist also ein „Muss“.
Wenn man nach Punkt 1a filtern würde, sollte man eigentlich auch nach den Merkmalen des jeweiligen Teilvorschlags (also entsprechend 1a.1, 1a.2 und 1a.3) sortieren können, sofern das Relevanz ergäbe. Die Teilvorschläge unter dem Punkt 1a liefern in unterschiedlicher Art und Weise Relevanz:
  • Der Teilvorschlag 1a.1, das Weglassen der Dokumentationsseiten ergäbe für sich genommen keine Sortier-Relevanz hinsichtlich der Dokumentationsseiten. Andersherum (also wenn man Dokus einbezieht) könnte man "Dokus zuerst anzeigen" (oder Ähnliches) anbieten. Eine Gruppierung – "Vorlagen mit Dokumentationsseite" und "Vorlagen ohne Dokumentationsseite" – wäre auch interessant, wobei die "Vorlagen mit Dokumentationsseite" paarweise angezeigt werden könnten.
  • Der Teilvorschlag 1a.2 (Flexible Zeichenketten), bei der ein gefundenes Suchwort unabhängig von der gefundenen Textposition im Vorlage-Namen als Treffer gilt, liefert zwar ein Sortier-Kriterium, nämlich die Entfernung des ersten Treffers vom Anfang der durchsuchten Zeichenkette; ob diese Sortierung besser wäre, als die alphabetische, mag aber dahin gestellt sein.
  • Der Teilvorschlag 1a.3, bei dem die Beschreibungen der Vorlagen durchsucht würden, könnte die Trefferhäufigkeit als Relevanz-Kriterium liefern.
Der dritte Teilvorschlag zur Sortierung (1c.3) bezieht sich auf die Häufigkeit der Anwendung einer Vorlage. Ich würde dieses Sortier-Kriterium nicht „Popularität“ nennen. Wir unterhalten uns hier über Werkzeuge zur Gestaltung einer Enzyklopädie. Die Häufigkeit der Anwendung einer Vorlage kann etwas mit der Popularität zu tun haben, ist aber (hoffentlich!) nicht der einzige Grund; zwei Beispiele:
  • Infoboxen (Hilfe) basieren auf Vorlagen und tauchen im Allgemeinen nur einmal am Anfang einer Seite auf, weil sie weiter unten selten sinnvoll sind. Falls die Vorlage:Infobox Film sehr bekannt und beliebt ist, kann ich nicht einfach bei jeden Artikel, der einen Film als Thema hat, die Vorlage mehrfach einbinden, um mit der Häufigkeit der Popularität Ausdruck zu verleihen.
  • Wer zu vielen verschiedenen Stellen Verknüpfungs-Möglichlichkeiten benötigt, benötigt man auch entsprechend viele Anker, die man mit der Vorlage:Anker generiert muss – egal, ob die Vorlage populär ist oder nicht.
1d.1 — 11. Teilvorschlag; 1. von 4 in 1d (Vorschau) — Vorschau: Die genaue Implementierung und Umsetzbarkeit erfordert noch ...
1d.2 — 12. Teilvorschlag; 2. von 4 in 1d (Beschreibung) — Beschreibung: Die Suchergebnisse würden die in TemplateData angegebene Beschreibung ...
1d.3 — 13. Teilvorschlag; 3. von 4 in 1d (Formatierung) — Formatierung: TemplateData enthält bereits Informationen darüber, ob eine Vorlage ...
1d.4 — 14. Teilvorschlag; 4. von 4 in 1d (Parameter-Anzahl) — Anzahl der Parameter: Die Anzahl der Parameter ist ein guter Indikator für ...
Der Punkt 1d wurde mit „Zusätzliche Informationen in den Ergebnissen anzeigen, um Vorlagen vergleichen zu können“ überschrieben. Das klingt, als sollten Vorlagen miteinander verglichen werden. Ich denke, es ist gemeint, dass die angezeigten Vorlagen hinsichtlich ihrer Passgenauigkeit mit dem Grund ihrer möglichen Auswahl verglichen werden könnten.
Es gibt verschiedene Gründe, warum man aus einem Suchergebnis eine einzelne Vorlage oder mehrere auswählen möchte; beispielsweise:
  • Einfügen einer Vorlage als Einbindung in einen Artikel (z. B. im VisualEditor, siehe WP:VE und H:VE),
  • Vergleich mehrerer Vorlagen hinsichtlich bestimmter Eigenschaften in einem separaten Analyse-Tool (das ist – glaube ich – mit Punkt 1d nicht gemeint),
  • Bearbeitung der Vorlage und/ oder ihrer Dokumentation.
Der Teilvorschlag 1d.1 (Vorschau) klingt ganz nett, da aber die „genaue Implementierung und Umsetzbarkeit“ noch weitere Recherche erfordert, denke ich, dass das nicht so praktisch ist. Es ist gut, darüber nachgedacht zu haben, was passieren soll, wenn die Erwartungshaltung der potentiell künftigen Software nicht befriedigt wird („Sollte kein Beispiel zur Verfügung stehen, ...“). Auf der anderen Seite hatten die Benutzer*innen, die sich mal „Leichter mit Vorlagen arbeiten“ wünschten, was anderes im Sinn, als „noch mehr mit Vorlagen arbeiten“. Wer die Vorschau wirklich braucht, um eine Vorlage zu nutzen, wird sie kaum erstellen oder reparieren: „Falls die Vorschau ganz fehlt oder kaputt ist, würde ein Knopf angezeigt werden, der Nutzer zu TemplateData führt. Dort könnte die Vorschau aktualisiert werden.“
Im Teilvorschlag 1d.2 (Beschreibung) ist davon die Rede, dass die Suchergebnisse die „in TemplateData angegebene Beschreibung anzeigen“ würden. Bezöge sich das jeweils auf eine einzelne Vorlage, für die gerade eine Vorschau (1d.1) mit ihrer Beschreibung (1d.2) sichtbar wäre oder wären die Beschreibungen aller Vorlagen der Suchergebnis-Liste gleichzeitig im „Vorlagen-Finder“ sichtbar?
Das Erste (Anzeige der Beschreibung nur für die Vorschau) fände ich praktischer, das Zweite (Anzeige aller Beschreibungen gleichzeitig) erinnert an Prototyp 3. In Prototyp 3 wurde unter Punkt 3.4, „Beschreibungen sichtbarer machen“ vorgeschlagen, die Beschreibungen aller Parameter einer Vorlage gleichzeitig anzuzeigen und das Info-Symbol ("i") abzuschaffen (Version am 18. Juni 2020, zur Zeit des ersten Feedbacks: oldid=201083102#Prototyp_3.4_Beschreibungen_sichtbarer_machen).
Hier, also beim Teilvorschlag 1d.2, sollen fehlende Beschreibungen durch ein Info-Symbol angezeigt werden: „An betreffenden Stellen würde ein Info-Symbol eingefügt, das die Benutzer dazu ermutigt, Beschreibungen hinzuzufügen, um diese Lücken zu füllen.“ Ich halte das für keine gute Idee.
Beim Teilvorschlag 1d.3 geht es um inline- und block-Formatierung. Diese Angabe ist z. B. in der Vorlage:Infobox Film unterhalb einer Tabelle im Abschnitt „Vorlagenparameter“ zu finden: »Format: block lead align \n{{_\n| _________________ = _\n}}\n«. Wie man sieht, ist das was für Spezialisten.
Der Teilvorschlag 1d.4, bei dem es darum geht, die Anzahl der Parameter anzuzeigen, klingt erst einmal simpel, enthält aber auch einige Fallstricke, aus denen sich Fragen ergeben; z. B.:
  • Hat eine Vorlage, für die null Parameter angezeigt werden, keine Parameter oder keine TemplateData?
  • Was macht man mit Vorlagen, deren Parameter-Anzahl nicht begrenzt ist?
  • Was wird bei einer Vorlage-Einbindung gezählt – die gerade angewendeten Parameter oder die mithilfe der TemplateData für diese Vorlage beschriebenen Parameter?
1e.1 — 15. Teilvorschlag; 1. von 4 in 1e (Name kopieren) — Name der Vorlage mit einer Schaltfläche zum einfachen Kopieren ...
1e.2 — 16. Teilvorschlag; 2. von 4 in 1e (Wikitext kopieren) — Wikitext in einer Textbox, sowie ein Knopf zum einfachen Kopieren ...
1e.3 — 17. Teilvorschlag; 3. von 4 in 1e (Doku-Link) — Link zur Dokumentationsseite damit Nutzer einfach auf die dort bereitgestellten Hilfen und Erklärungen zugreifen können
1e.4 — 18. Teilvorschlag; 4. von 4 in 1e (Einbindungen) — Link zu allen Seiten, die die Vorlage verwenden so dass Nutzern Beispiele zur Verfügung stehen
Der Prototyp-Punkt 1e, „Schnellansicht der Vorlage“, scheint ein griffiger benanntes „Update“ des Prototyp-Punktes 1d zu sein (1d: „Zusätzliche Informationen in den Ergebnissen anzeigen, um Vorlagen vergleichen zu können“).
Beim Teilvorschlag 1e.1 könnte der Name der Vorlage kopiert werden, um ihn woanders anzuwenden, ohne die Vorlage öffnen zu müssen, vermutlich in dieser Form: [[Vorlage:Name der Vorlage]]. Das ist wahrscheinlich nützlich.
Der Teilvorschlag 1e.2 soll für das Kopieren von Wikitext-Code-Schnipseln gut sein. Die Frage ist, welche Schnipsel das sein sollen? Sinnvoll wäre das für einen Abschnitt, der meist – aber nicht immer – „Kopiervorlage“ heißt. Von Kopiervorlagen kann es auch mehrere geben und sie sind gern auch mal so lang, dass das Wort „Schnellansicht“ schlecht passen würde. Diese Texte sind in der Normalansicht meist wie Wiki-Code dargestellt (z. B. Maskierung der Wikisyntax durch <pre>-Tags) und können direkt kopiert werden. Insofern glaube ich, dass es einfacher ist, mit der rechten Maustaste auf den Link für die jeweilige Vorlagenseite zu klicken und die Seite separat zu öffnen, um dort das Gewünschte zu kopieren.
Beim Teilvorschlag 1e.3 geht es wieder um die Frage, ob es für die jeweilige Vorlage überhaupt eine eigene Dokumentationsseite gibt (und falls „Ja“, ob dort auch TemplateData angewendet werden). Meiner Ansicht nach muss unbedingt ein Link zur Vorlagenseite selbst da sein, weil dort eine gegebenfalls vorhandene Doku immer sichtbar wird. Es ist dafür egal
  • ob diese Doku in „klassischer Manier“ auf der Vorlagenseite selbst als Wikitext zwischen entsprechenden Quellcode-Elementen abgelegt ist oder
  • ob die Doku auf „moderne Art“ aus einer separaten /doku-Unterseite eingebettet wird.
Vielleicht kann man irgendwie das jeweils genutzte Konzept anzeigen? Vielleicht so:
oder so:
  • Vorlagenseite: [[Vorlage:FNS]]
  • Dokumentationsseite: Nein.
  • TemplateData vorhanden?: Nein. (keine Dokumentationsseite)
Das zweite Beispiel mag verwundern, da nach Maus-Klick auf [[Vorlage:FNS]] durchaus TemplateData angezeigt werden. Das liegt aber an der Vorlage selbst. Der Programmcode der Vorlage FNS ruft die Vorlage FN und deren Dokumentation auf, wodurch auch die TemplateData von FN sichtbar werden.
Beim Teilvorschlag 1d.4, „Link zu allen Seiten, die die Vorlage verwenden“, dachte ich erst, dass es „Links“ statt „Link“ heißen müsse; dann fiel mir aber ein, dass es so viele Seiten werden können, dass ein einziger Link tatsächlich besser wäre. Dieser Link würde zu einem anderen Fenster oder einer anderen Seite führen. Das wäre sozusagen ein „Link zu einer Seite mit Links zu allen Seiten, die die Vorlage verwenden“.
Ich hatte mal die Vorlage:Infobox Protein auf die „Vorlagensuche“ von Benutzer:Wurgl angewendet (https://persondata.toolforge.org/vorlagen/). Am 4. Juli 2020 waren damit 1753 Einbindungen der Vorlage "Infobox Protein" im Artikelnamensraum gefunden worden (die Einbindungen waren in 1679 Artikeln vertreten; 1623 Artikel hatten genau eine und 56 Artikel hatten mehr als eine Einbindung). Wenngleich das Tool keine offizielle Spezial-Seite in der Wikipedia ist und ich mich bei der genauen Zuordnung vertan haben könnte (-; natürlich nur rein theoretisch ;-) dürfte der Größenbereich stimmen – mehr als anderthalb tausend Artikel mit der gleichen Infobox.
1f.1 — 19. Teilvorschlag; 1. von 1 in 1f (Vorlagen im Artikel) — Es gibt eine weitere Idee, die nicht im Video enthalten ist: Wenn ...
Das schöne am Punkt 1f ist, dass er nur einen Vorschlag enthält und das man sich diesen Vorschlag relativ leicht vorstellen kann. Es ist naheliegend, die Einbindungen von Vorlagen zu einem bestimmten Artikel auflisten zu wollen, wenn man schon auf die Idee gekommen ist, die Artikel aufzulisten, die Einbindungen zu einer bestimmten Vorlage enthalten.
Für mich als Artikel-Autor ist das mit den Artikeln, die eine bestimmte Vorlage verwenden – wie das hier unter Punkt 1e vorgeschlagen wurde (Teilvorschlag 1e.4) und in der „Vorlagensuche“ von Benutzer:Wurgl schon ziemlich gut anwendbar ist (https://persondata.toolforge.org/vorlagen/) – erst mal interessanter als anders herum. Das liegt daran, dass thematisch zusammenhängende Artikel häufig die gleiche Vorlage einbinden, zumindest ist das bei vielen Infoboxen so.
Das bisherige Fehlen der Funktionalität von 1f fällt mir als Artikel-Autor erst einmal nicht so auf: wenn ich mich bei der Arbeit an einem bestimmten Artikel befinde, ist eine reine Auflistung der eingebundenen Vorlagen nicht in jeder Situation hilfreich, z. B., weil mir der umgebende Text – also im wahrsten Sinne des Wortes der Kontext – fehlen würde.
Falls man die Funktionalität 1f irgendwie im Visual Editor implementieren möchte, sollte man darauf achten, dass sie standardmäßig "Aus" ist und dass das Bedienelement für die "Ein"-Schaltung wenig Platz benötigt.
Ich dachte mal, dass eine ähnliche Funktionalität, wie hier vorgeschlagen (Punkt 1f), in der „Vorlagensuche“ von Benutzer:Wurgl eingebaut wäre; zumindest steht dort links als erste Rubrik das Wort „Artikel“.
Und was soll auf einer Seite, die „Vorlagensuche“ heißt, unter der Rubrik „Artikel“ anderes eingetragen werden, als ein Artikel, für den dann nach Vorlagen gesucht wird? – das hängt von der Intension bzw. Intuition ab:
  • ich hatte meinen Arbeitsablauf (Workflow) im Kopf und mit dieser Sichtweise wollte ich links anfangen und zwar mit dem, was ich als erstes eingeben muss, also einen Artikel, mit dem ich nach Vorlagen suche;
  • tatsächlich steht das Wort „Artikel“ links auf der Seite „Vorlagensuche“ aber in einer Navigationsleiste – und bei Navigation geht es eher darum, wo man hin will und weniger darum, wo man her kommt.
  • Versuch einer Gesamtbetrachtung
Dieser „Abschnitt“ meines Antwortbetrags ist unglaublich ausschweifend geraten. Hier habe ich versucht, eine Betrachtung darüber anzustellen, wie ich die Vorschläge einzeln und im Zusammenhang sehe. Dafür habe ich Beispiele herangezogen, die ich selbst verwende. Dieser „Versuch einer Gesamtbetrachtung“ dient dazu, dass andere ggf.meine Einschätzungen nachvollziehen können, die ich unter „Für und Wider“ (hier) und „Fazit“ (hier) zusammengefasst habe.
Das Team Technische Wünsche bietet an, ein Tool zu entwickeln, den „Vorlagen-Finder“, der an verschiedenen Stellen die Arbeit mit Vorlagen erleichtern soll, hauptsächlich, indem eine Vorlage besser gefunden werden könnte. An sehr vielen Stellen wird darauf hingewiesen, dass mehr maschinenlesbare Information dafür hilfreich wäre – und zwar „in TemplateData“. Im Prinzip läuft es auf zwei Grundfragen hinaus:
  • „Vorlagen-Finder“ bauen?
  • TemplateData erweitern?
Es bleibt beim Prototyp-1-Updates bzw. bei der Umfrage unklar, ob der Vorlagen-Finder auch ohne neue TemplateData gebaut werden könnte und ob neue TemplateData dazu kommen könnten, ohne dass ein Vorlagen-Finder fertig wird (was nicht schön wäre). Mit „neue TemplateData“ meine ich wahrscheinlich „neue TemplateData-Felder“ oder „neue TemplateData-Datentypen“ – so genau kenne ich mich bei den Begriffen nicht aus.
Ein weiterer Fragekomplex wäre, welche Funktionalität der Vorlagen-Finder an welcher Stelle anbieten würde.
Es gibt eine Reihe von Wörtern und Wortgruppen, die hier erwähnt wurden (unter ←Prototyp-1-Update auf der Projektseite) – z. B. Visual Editor, TemplateWizard, TemplateDialog und Quelltexteditor – und die potentielle Orte der segensreichen Wirkung eines „Vorlagen-Finders“ repräsentieren sollen. Ich stelle mal eine (nicht ganz ernst gemeinte) rhetorische Frage:
  • Wenn es schon einen TemplateWizard – also einen „Vorlagenzauberer“ – gibt, wozu braucht man denn dann noch andere Werkzeuge? Der kann doch zaubern!
Worauf ich hinaus will, ist, dass nicht nur die ungefähr 70000 Vorlagen kaum noch zu überblicken sind, sondern auch die ganzen Hilfsmittel und Projekte, welche die Verwaltung von und die Arbeit mit Vorlagen ermöglichen sollen.
Im Zeitraum der Vorstellung von Prototyp 3 gab es eine parallele Diskussion im Abschnitt Vorlagenauswertung. In diesem Zusammenhang hatte ich von der „Vorlagensuche“ erfahren. Die „Vorlagensuche“ vom Benutzer:Wurgl (https://persondata.toolforge.org/vorlagen/) ist zwar weder fertig noch perfekt – das sind aber Eigenschaften, die diese Softwarelösung mit den meisten anderen Softwarelösungen im uns bekannten Universum teilt – aber man kann „Vorlagensuche“ schon ausprobieren. Das ist ein riesiger Vorteil gegenüber rein fiktiven Dingen.
Ich glaube nicht, dass ich das einzige Mitglied der primären Zielgruppe „Nutzende von Vorlagen“ bin, das gern mal Sachen ausprobieren würde, ohne Gefahr zu laufen, etwas kaputt zu machen.
(Zu den Problemen hinsichtlich der beiden Gruppen, die vom Team Technische Wünsche als „Primäre Zielgruppen“ ausgemacht wurden, siehe unter „Häufigst genannte Probleme“, ab 19. Nov. 2019:
Die „Vorlagensuche“ könnte vielleicht als eine Art „funktionaler Prototyp“ dienen (wenn Benutzer:Wurgl dem zustimmen würde). Das heißt, die Entwicklung des „Vorlagen-Finders“ sollte meiner Ansicht nach die „Vorlagensuche“ selbst nicht ändern, sondern nur als Vorbild nehmen (damit man die „Vorlagensuche“ weiterhin nutzen kann).
Zurück zu den Orten der möglichen Anwendung: da wären die beiden grundsätzlichen „Schreibprogramme“ zu nennen:
Die anderen beiden erwähnten Wörter, TemplateWizard (H:Vorlagen/Wizard) und TemplateDialog, beziehen sich auf Bausteine (auf PlugIns, AddOns, Module – oder was auch immer) in den beiden „Schreibprogrammen“ (TemplateWizard ↔ Quelltext-Editor / TemplateDialog ↔ Visual Editor).
Den Visual Editor kann man als „normale(r)“ Benutzer*in nur im Artikelnamensraum oder auf eigenen Benutzer*innen-Seiten einsetzen. Der Hauptgrund dürften die Unterschiede bei Einrückungen, Aufzählungen und Signaturen zwischen Diskussions-Seiten und Artikel-Seiten sein.
Wenn es also nicht möglich ist, bestimmte Editier-Werkzeuge in allen Namensräumen einzusetzen und wenn verschiedene Editier-Werkzeuge unterschiedliche Komponenten für die Vermittlung zur Bearbeitung von Vorlagen benötigen, warum sollte dann ausgerechnet der vollumfängliche „Vorlagen-Finder“ überall gleich gut arbeiten können?
Ich vermute, dass auch das über die TemplateData gesteuert werden soll. Würde man z. B. den „vorgesehenen Namensraum“ heranziehen, um gegebenenfalls das Einfügen oder Bearbeiten einer Vorlage zu unterbinden? An dem Tag, an dem das Feld „vorgesehener Namensraum“ das erste Mal „bereits in TemplateData vorhanden“ sein würde, hätte noch keine einzige Vorlage dazu einem entsprechenden Eintrag „in TemplateData“ (d. h., es wäre noch kein entsprechender JSON-Quelltext-Abschnitt auf der entsprechenden Doku-Unterseite vorhanden). Außerdem sind die meisten Vorlagen in mehreren Namensräumen anwendbar.
Was wäre mit dem Editieren von TemplateData durch den „Vorlagen-Finder“?
Im Grunde genommen ist es eine gute Idee, dass die- oder derjenige, die oder der ein Beschreibungs-Lücke findet, von dort, wo sie oder er gerade ist (also z. B. im „Vorlagen-Finder“), dahin gelangen könnte, wo diese Lücke gefüllt werden kann. Wenn es (das Mitglied der Community) aber nach dem Klicken auf ein Symbol einfach nur ein Editier-Feld präsentiert bekäme (wie im Teilvorschlag 1d.2), in welchem es eine vermeintlich fehlende Beschreibung nachtragen könnte, könnte es sein, dass es in einem solchen Fall eine zweite Beschreibung erzeugen würde. Selbst wenn der Vorlagen-Finder ein paar Abfragen durchführen könnte:
  • „Die Vorlage XY hat noch keine Dokumentationsseite. Möchtest du jetzt eine Dokumentationsseite erstellen?“
und anschließend, falls mit [Ja] geantwortet wurde:
  • „Die Dokumentation der Vorlage XY enthält noch keine Beschreibung. Möchtest du jetzt eine Beschreibung erstellen?“
wäre es möglich, dass bereits zuvor eine Beschreibung bestand, aber auf der Vorlagenseite selbst und nicht vermittels der TemplateData auf einer Unterseite zur Dokumentation. So könnten auf der Vorlagenseite verschiedene Tags (z. B. include, onlyinclude, includeonly und noinclude) so verwendet worden sein, dass einiger Quelltext als Programmcode in Erscheinung trifft und anderer Quelltext als Dokumentation.
Ich möchte nicht den Eindruck erwecken, dass ich denke, dass ich das alles mit den Vorlagen und den TemplateData vollumfänglich durchschauen würde. Die Hälfte von dem, was ich hier erzähle, ist vermutlich unvollständig, zu stark vereinfacht oder sogar falsch, wenn es um sehr spezielle technische Details geht.
Ich möchte nur skizzieren, was vielleicht passieren könnte, wenn nicht alles haarklein bis zu Ende gedacht wird. Selbst so einfach erscheinende Sachen, wie die Auswahl geeigneter Symbole für Bedien-Elemente auf einer grafischen Oberfläche haben das Potential für Verwirrung.
Beim Prototyp 3 wurde moniert, dass das Info-Symbol auch dann erscheint, wenn keine Beschreibung vorhanden ist:
Es stimmt, dass tote Links etwas verwirrend sind. Wäre es aber weniger verwirrend, wenn die Bedeutung eines Info-Symbols in Zukunft dem Gegenteil seiner bisherigen Bedeutung entspräche? Beim Prototyp-1-Update wird vorgeschlagen, Info-Symbole bei fehlenden Beschreibungen zu zeigen:
  • „An betreffenden Stellen würde ein Info-Symbol eingefügt, das die Benutzer dazu ermutigt, Beschreibungen hinzuzufügen, um diese Lücken zu füllen.“ (Punkt 1d, Teilvorschlag 1d.2).
Mir ist schon klar, dass das eine Info-Symbol sich auf die Parameter-Beschreibungen innerhalb des Visual Editor bezieht (Prototyp 3) und dass das andere Info-Symbol sich auf die Kurzbeschreibungen der Vorlagen innerhalb des „Vorlagen-Finders“ bezieht (Prototyp-1-Update); diese Unterscheidung macht das Konzept aber nicht durchsichtiger.
Es gibt in der Beschreibung des Prototyp-1-Updates vier Hinweise, die mit „Wichtig“ eingeleitet wurden. Ein solcher Hinweis ist dieser:
  • „Wichtig: Die Umsetzung würde umfangreiche Recherchen und ausführliche Gespräche mit der Community erfordern. Der erwartete, sehr große Nutzen könnte diesen aber rechtfertigen.“
Dieser Text bezieht sich zwar nur auf einen einzelnen Vorschlag unter dem Punkt 1d (den ich hier Teilvorschlag 1d.1 genannt habe), ist aber typisch für das Prototyp-1-Update und die Umfrage.
Wenn man es der Community so leicht machen will, dass man in der Schnellumfrage nur fünf Haken zu setzen oder nicht zu setzen braucht, warum schreibt man dann bei einem einzelnen Teilvorschlag (1d.1) von insgesamt etwa 19 Teilvorschlägen hin, dass viel Arbeit („ausführliche Gespräche“) auf die Community warten wird? Das zuständige „Vorschlags-Paket“ 1d besteht aus etwa vier Teilvorschlägen. Wer bei 1d einen Haken gesetzt hat, weil sie oder er vielleicht die Anzeige der Parameter-Anzahl ganz gut findet (Teilvorschlag 1d.4), hat auch die Info-Symbole für fehlende Infos (1d.2), die kryptischen Zeichenketten für Formatierungen (1d.3) und eben auch „umfangreiche Recherchen und ausführliche Gespräche mit der Community“ für die Vorschau (1d.1) „gebucht“.
Für mich stellt sich auch die Frage, wie der „erwartete, sehr große Nutzen“ bei einer Vorschau-Möglichkeit (Teilvorschlag 1d.1) eintreten könnte. Wer eine solche Vorschau „basteln“ kann, weil sie oder er sich ausreichend mit der jeweiligen Vorlage und mit TemplateData auskennt, braucht diese Vorschau anschließend nicht unbedingt. Wer aber wirklich eine Vorschau braucht, um die zugehörige Vorlage sinnvoll nutzen zu können, sollte sich unbedingt mit der Vorlage und ihrer Dokumentation beschäftigen. Und ab da dreht sich alles im Kreis, weil die Dokumentation ... (keine Angst! ich schreibe das jetzt nicht alles nochmal hin).
Es kommt noch ein Aspekt dazu, der den Elan bei der Erstellung von Vorschau-Applikationen dämpfen könnte: die zeitliche Stabilität. Die Enzyklopädie Wikipedia behilft sich mit folgender Warnung:
  • „Dies ist eine alte Version dieser Seite, [...] Sie kann sich erheblich von der aktuellen Version unterscheiden.“
Eine alte Version kann sich aber auch bei einem Vergleich mit sich selbst erheblich unterscheiden – und zwar bezüglich der ursprünglichen, damals gewünschten Anzeige mit einer späteren Anzeige. Das Team Technische Wünsche hat dazu im November 2019 Folgendes festgestellt:
  • „Ruft man eine alte Version eines Artikels auf, so wird er nicht mit den damaligen Versionen der genutzten Vorlagen angezeigt, sondern mit den aktuellen. Dadurch ist es nicht möglich, sicher zu sein wie der Artikel damals aussah.“ (siehe unter „Häufigst genannte Probleme“, ab 19. Nov. 2019: oldid=194191254#Weitere_Probleme)
Das wird vor allem für Artikel-Versionen mit gelöschten Vorlagen besonders sichtbar oder für Artikel-Versionen mit solchen Vorlagen, die ihrerseits gelöschte Vorlagen einbinden. Aber auch dann, wenn alle Vorlagen vorhanden sind, kann es im Laufe der Zeit zu neuen Code-Interpretationen kommen, obwohl sich am Wikitext einer bestimmten Artikel-Version gar nichts ändert. Ein bestimmter Syntax-Abschnitt zur Einbindung einer Vorlage in einer bestimmten Artikelversion hat zwar Bestand und ist maschinenlesbar; die „Maschine“ aber, die diesen Syntax-Abschnitt liest – nämlich der Programmcode der Vorlage – kann sich ändern.
Man könnte einwenden, dass es ja nur um alte Versionen geht, die in der Gegenwart nicht so angezeigt werden, wie damals und dass sich innerhalb einer kurzen Zeit – sagen wir mal: in ein paar Tagen – nicht soviel ändern wird. Daher hätte man genug Zeit, Änderungen im Programmcode einer Vorlage zu berücksichtigen und die Stellen, an denen sich das auswirkt, entsprechend anzupassen. Es geht aber in der Gegenwart um eine deutsche Wikipedia, die mehr als 70.000 Vorlagen hat, welche insgesamt ungefähr 100 Millionen Parameter aufweisen. Die mehr als 70.000 Vorlagen sind an knapp 26 Millionen Stellen eingebunden (am 30. August 2020 stand dazu unter https://persondata.toolforge.org/vorlagen/: „Suche in 73.281 Vorlagen mit 25.787.700 Verwendungen und 100.119.434 Parametern“).
Die schiere Dimension der Wikipedia macht schon jetzt die Anpassung von abhängigen Komponenten zeitnah schwierig, wenn Vorlagen geändert werden, weil viele Anpassungen nicht automatisch erfolgen, sondern händisch vorgenommen werden müssen.
Käme jetzt beispielsweise eine Vorschau-Funktion dazu (Teilvorschlag 1d.1), wäre das einfach noch eine Komponente mehr, die dauerhaften „Pflegebedarf“ hätte. Um das an einem Beispiel zu verdeutlichen: für die Vorlage:Infobox Protein hatte die „Vorlagensuche“ 1753 Einbindungen gefunden (am 4. Juli 2020, https://persondata.toolforge.org/vorlagen/). Würde jemand diese Vorlage ändern und es wären beispielsweise Parameter-Namen betroffen, sollte schon nachgesehen werden, wie sich das an den verschiedenen Stellen auswirkt. Bei 1753 Stellen ohne Vorschau wären das 1754 Stellen mit Vorschau; also – oberflächlich betrachtet, nicht viel – was dazu käme. Allerdings hat das „inoffizielle“, aber vorhandene Werkzeug „Vorlagensuche“ keine Funktion für eine Vorschau und das „offizielle“, aber fiktive Werkzeug „Vorlagen-Finder“ würde die Vorschau zwar anzeigen, aber als Orientierungshilfe und nicht als Objekt der Wartung.
Ich habe die „Infobox Protein“ als Beispiel benommen, weil ich damit als „Autor“ zu tun habe. Die Vorlage:Infobox Protein hat ungefähr 40 Parameter, die nicht alle gleichzeitig angewendet werden, weil es sehr wahrscheinlich kein Protein gibt, dass alle Eigenschaften gleichzeitig aufweist. Im Ergebnis ist die Infobox im jeweiligen Artikel mal kürzer, mal länger und könnte acht Überschriften bzw. Abschnitte aufweisen, wenn das sinnvoll wäre (was es nicht ist). Was nähme man nun als Vorschau? Nähme man dafür:
  • eine Artikel-Einbindung, die besonders schick ist (welche von den etwa anderthalbtausend Einbindungen sucht man aus?),
  • ein besonders typisches Protein (wäre das dann ein Enzym oder wäre es ein Polypetidhormon für das Arzeneimittelangaben gemacht werden können?) oder
  • ein fiktives Beispiel, das sachlich keinen Sinn ergibt, aber alle Parameter verwendet?
Das Letzte kann ich ausschließen, da die Vorschau zwar auf einer Schriftrolle ausdruckbar wäre, sich aber auf keinem Bildschirm in sinnvoller Weise anzeigen ließe. Ich hatte mal eine solche Beispiel-Einbindung erstellt, um mir einen Überblick darüber zu verschaffen, welcher Parameter welchen Schriftzug an welcher Stelle erzeugt. Dabei hat sich eine neue Frage ergeben:
  • Wie geht man mit „Untervorlagen“ um, die für sich allein stehend nicht sinnvoll anwendbar sind?
Mit der „Vorlage:Infobox Protein“ kann man zwei solcher Untervorlagen einbeziehen, „Vorlage:Infobox Protein/MoreEC“ und „Vorlage:Protein Orthologe“. Die Vorschau würde also nicht ungefähr 40, sondern ungefähr 80 Parameter berücksichtigen, wenn man wirklich „alle“ Parameter anwenden wollte und Untervorlagen einbezöge.
Insgesamt ist eine Vorschau selten sonderlich informativ.
Wenn ich beispielsweise eine Stelle im Text benötige, zu welcher man per Mausklick gelangen kann, verwende ich dazu eine Überschrift oder die Vorlage:Anker. Wie sollte eine sinnvolle Vorschau für die Vorlage „Anker“ aussehen?
  • Die Darstellung eines Sprungziels kommt nicht Frage, da es in der Normalansicht gar nicht angezeigt wird,
  • eine Einbindung als Wikitext würde nur den Namen der Vorlage (Anker) zeigen und
  • das Bild eines Ankers aus der Seefahrt wäre missverständlich, weil ein Anker dort kein Navigationsmittel ist.
  • Was als sinnvolle Vorschau bleibt, ist eine verbale Kurzbeschreibung.
Gegenwärtig (30. Aug. 2020) habe ich zwei verschiedene Kurzbeschreibungen zur Vorlage „Anker“ gefunden:
  1. „Linkziel(e) zu einem Abschnitt oder einem Element innerhalb der aktuellen Wiki-Seite vereinbaren“
    • wird als Einleitung gezeigt, wenn man auf Vorlage:Anker klickt und
    • der gleiche Schriftzug wird auch als Vorschau im Visual Editor verwendet (z. B. als Tooltip), wenn man die Vorlage einfügen möchte (Menü: Einfügen→ Vorlage→ Eine Vorlage hinzufügen→ Anker);
  2. „Vorlage, um verlinkbare Sprungziele innerhalb einer Wikitext-Seite zu definieren“
    • wird im Visual Editor als Kurzinformation angeboten, wenn man den Link Vorlage:Anker bearbeiten möchte.
Der erste Text kommt „aus TemplateData“, genauer aus einen speziellen Bereich zwischen doppelten, geschweiften Klammern, der etwa so aussieht: TemplateData|JSON= ... und er steht auf einer entsprechenden Dokuseite (Vorlage:Anker/Doku). Wo der zweite Text herkommt, weiß ich nicht. Beide Texte sind offensichtlich in maschinenlesbarer Form hinterlegt worden. Eine „Maschine“, nämlich der Visual Editor, kann mir beide Texte „vorlesen“ und entscheidet scheinbar auch ohne mich, welcher Text mir an welcher Stelle in meinem Arbeitsablauf angeboten wird.
Vermutlich kann es bei der Vorlage „Anker“ auch einen Unterschied zwischen verschiedenen Informationen zur Anzahl der Parameter geben, je nachdem, wie die Anzahl ermittelt wird:
  1. „In TemplateData“, also in dem speziellen Bereich auf der Dokumentationsseite (Vorlage:Anker/Doku) ist die Information sowohl durch Menschen lesbar (in der Normalansicht) als auch maschinenlesbar abgelegt. Die Anzahl der Parameter ließe sich durch die Zählung bestimmter Tabellenzeilen bzw. Quelltext-Stellen bewerkstelligen.
  2. Auf der Dokumentationsseite (Vorlage:Anker/Doku) gibt es außerdem den Abschnitt „Anzahl der Parameter“, in welchem die Anzahl der anwendbaren Parameter verbal – in einer ausschließlich für Menschen lesbaren Form – hinterlegt ist. Dieser Abschnitt befindet sich nicht „in TemplateData“ (sondern außerhalb der Einbindungssyntax der Vorlage:TemplateData).
  3. Der eigentliche Programmcode ist in jedem Fall in irgendeiner Form maschinenlesbar und definiert letztendlich die Zahl der anwendbaren Parameter. Ob diese Zahl auslesbar ist, kann ich nicht einschätzen. Die Vorlagenseite selbst (Vorlage:Anker) enthält im eigenen Quelltext nur wenig des Programmcodes und dient vermutlich dazu, andere Seiten aufzurufen (z. B. mithilfe von: #invoke:Vorlage:Anker). Eine Schlüsselrolle scheint in diesem Zusammenhang der Seite Modul:Vorlage:Anker zu zukommen.
Die einfache Zählung der entsprechenden Zeilen in der dafür relevanten Tabelle „in TemplateData“ würde für die Vorlage „Anker“ 11 Zeilen bzw. Parameter ergeben, während im Abschnitt „Anzahl der Parameter“ steht, dass eine Begrenzung der Anzahl der Sprungziele nicht erfolgt (seit Dezember 2019), was wohl bedeutet, dass auch die Anzahl der Parameter nicht begrenzt ist.
Welche Anzahl wäre als guter Indikator für die Komplexität der Vorlage „Anker“ im Sinne des Teilvorschlags 1d.4 relevant? Wäre es
  • 6 für die sechs „Standard-Parameter“, die zwar ohne Nutzung von Parameternamen in Vorlagen-Einbindungen auftreten, aber „in TemplateData“ Benennungen haben („Anker-1“ bis „Anker-6“), um die Nutzbarkeit zu verbessern (z. B. mithilfe des VisualEditors), wäre es
  • 11 für die insgesamt elf Benennungen, die durch den Visual Editor vermittels der TemplateData-Tabelle angeboten werden, wäre es
  • Unendlich für die Zahl der Fragmentbezeichner, die innerhalb einer Vorlagen-Einbindung eingetragen werden können, wäre es
  • 4 für die vier Fragmentbezeichner, die nur als benannte Parameter angewendet werden können (Parameternamen: -1, -2, -3 und x1), wäre es
  • 3 für die drei Parameternamen (-1, -2 und -3), die nicht geprüft werden, aber irgendwie „offizieller“ wirken, als
  • 1 Parameternamen (x1), der auch nicht geprüft wird und zusätzlich irgendwie „inoffiziell“ wirkt?
Nach meinem „Bauchgefühl“ nimmt die Komplexität in Bezug auf die jeweilige Anzahl in der „Liste von Anzahlen“ von oben nach unten zu.
Die einzige, wirklich gut maschinell auslesbare Anzahl scheint mir die 11 zu sein, jene Zahl, die sich aus der Vorlagen-Einbindung der Vorlage „TemplateData“ innerhalb der Dokumentationsseite ergibt, die zur Vorlage „Anker“ gehört und die in der „Normal-Ansicht“ elf Zeilen in einer Tabelle in einem Abschnitt entspricht, der mit „Vorlagenparameter“ überschrieben ist.
Diese „Normal-Ansicht“ erhält man sowohl, wenn man Vorlage:Anker/Doku anklickt als auch, wenn man Vorlage:Anker anklickt. Die jeweilige Normalansicht enthält in beiden Fällen sowohl TemplateData, als auch „Nicht-TemplateData“.
Der TemplateData-Anteil befindet sich optisch in einem „Kasten“ mit hellblauem Rand, der wie ein Fremdkörper wirkt, was er ja auch ist. Oben links im hellblauen Rand ist immerhin eine Schriftzug zu sehen (TemplateData), der einen Link nach Hilfe:TemplateData enthält. Unten links im Kasten ist der Schriftzug „Format: inline“ zu lesen. Ich dachte anfangs, „inline“ wäre die Art, wie sich die Vorlage die Daten „reinzieht“, die im „Kasten“ zu sehen sind. Es ist aber die Art, wie Daten verarbeitet und ausgegeben werden sollen (hier wurde auch über die Formatierung nachgedacht, über die beiden Ausgabeformate inline und block; Teilvorschlag 1d.3).
Um noch einmal auf die Anzahl der Parameter und die damit verbundene Komplexität (Teilvorschlag 1d.4) zurück zu kommen, in der bereits erwähnten Vorlage:Infobox Protein gibt es ausschließlich Parameter, die einen eindeutigen Namen haben, mit dem sie angewendet werden. Es gibt dort keine zusätzlichen Benennungen für die bessere Nutzung im Visual Editor und keine unbenannten Parameter in den Vorlagen-Einbindungen. Es gibt allerdings veraltete und aktuelle Parameter. Früher (bis Ende 2019) gab es den Parameter "CID", der durch den Parameter "PubChem" ersetzt wurde. Der veraltete Parameter steht weiterhin als solcher in der TemplateData-Tabelle, was gut so ist, da man dadurch erfährt, dass man in den Artikeln, die die „Infobox Protein“ anwenden, den Parameter "CID" durch "PubChem" austauschen sollte. Wenn man die Anzahl der Parameter vermittels der TemplateData ermitteln würde, würden nicht nur die benutzbaren, sondern auch historische Parameternamen mitgezählt werden.
Ich denke, dass der „Vorlagen-Finder“ weniger Interpretationen, sondern eher Basis-Fakten liefern sollte. Das heißt, ich würde die Rubrik für den Teilvorschlag 1d.4 zwar auch „Anzahl der Parameter“ nennen, aber mit einer allgemeinen Zusatz-Information versehen, etwa so:
  • Anzahl der Parameter (?)
Bei einem Klick auf (?) oder (i) sollte dann ein Text als Erläuterung erscheinen, der recht genau beschreibt wie „Anzahl der Parameter“ zustande kommt und weniger, wie man diesen Wert interpretieren könnte (z. B. als Komplexitätsmaß). Die Erläuterung sollte jemand Schreiben, die oder der Ahnung hat, nicht ich. Ich skizziere hier nur mal den „Text-Prototypen“ meiner ungefähren Vorstellung:
  • Anzahl der Parameter — Die angegebene Zahl ergibt sich aus den sogenannten TemplateData, einer Gruppe von Meta-Informationen ... kann sich erheblich von der tatsächlichen Anzahl der Parameter in einer Vorlage-Einbindung unterscheiden ... wenn keine ... haben den Wert 0:
    • 0 (keine Dokumentationsseite) ...
    • 0 (keine TemplateData) ...
    • 0 (keine Parameter) ...
Irgendwie müsste kenntlich gemacht werden, dass es verschiedene „Nullen“ gibt. Die Zahl 0 dürfte nur selten die richtige Anzahl repräsentieren; häufiger ist meiner Einschätzung nach ein Wert, der verbal „nicht verfügbar“, „nicht angewendet“ oder ähnlich lauten würde (das dürfte mit nil bzw. null in einigen Computer-Sprachen vergleichbar sein).
Die Frage, ob ein einzelnes Feature der TemplateData für die unterschiedlichen Arbeitsabläufe verschiedener Nutzer*innen sinnvoll ist oder nicht, würde ich gar nicht mehr so dringlich stellen; interessanter ist die Frage, ob es diese Features gibt. Ein Beispiel ist die Formatierung beim Teilvorschlag 1d.3.
Vielleicht brauchen diese Information nicht viele, ob eine Vorlage eine inline-formatierte Ausgabe erzeugt (d. h., dass die Ausgabe in einer einzelnen Zeile erfolgt) oder ob sie eine block-formatierte Ausgabe erzeugt (d. h., dass die Ausgabe als Block erfolgt, der mehrere Zeilen aufweisen kann); sie ist aber – allgemein betrachtet – „bereits in TemplateData“ vorhanden. Deshalb sollte der „Vorlagen-Finder“ das konkretisieren können: filtern, sortieren, gruppieren, auswählen.
Mir ist aufgefallen, dass man mit dem Visual Editor (WP:VE, H:VE) zwar die Einbindungen von Vorlagen im Artikelnamensraum bearbeiten kann, dass man aber nichts Vergleichbares für die zugeordneten Ressourcen hat – für die Vorlagenprogrammierung und für die Dokumentation. Durch Prototyp 2, „Verbesserte Syntaxhervorhebung“, wird zwar gegebenenfalls künftig eine übersichtlichere Bearbeitung des Programmcodes gewährleistet, für die Dokumentation hat man weiterhin nichts Eigenes zum Editieren. Der „Nicht-TemplateData-Wikitext“ innerhalb einer Dokumentationsseite (falls es die gibt), lässt sich noch recht gut mit einem Quelltexteditor bearbeiten, aber der TemplateData-Anteil (falls es den gibt) muss ohne ein darauf abgestimmtes Werkzeug bearbeitet werden.
Das führt zu der paradoxen Situation, dass die
  • Erleichterung auf der einen Seite, nämlich, dass die Anwendung einer Vorlage in einem Artikel durch eine graphische Benutzeroberfläche bewerkstelligt werden kann, zu einer
  • Erschwerung auf der anderen Seite geführt hat, nämlich, dass die recht komplizierten TemplateData ohne die Nutzung eines einfach bedienbaren Werkzeugs geschrieben werden müssen.
Salopp formuliert: der Visual Editor macht es also leicht, wenn TemplateData da sind – das ist aber selten, weil TemplateData schwer sind.
Es war daher nahe liegend, die fehlenden Schreibfunktionen für die TemplateData irgendwo „ranzuhängen“, z. B. an den Visual Editor (Vorschläge beim Prototyp 3) oder an den „Vorlagen-Finder“ (Vorschläge beim Prototyp-1-Update). Wenn z. B. der Visual Editor von einem Artikel im Artikelnamensraum, in dem die Vorlage eingebunden oder bearbeitet werden soll, „kurz mal rübergreifen“ würde, um im Vorlagennamensraum auf einer Dokumentationsseite eine einzelne Information „abzusetzen“, wäre das für die/ den Benutzer*in bequem aber undurchsichtig. Ähnliches gilt für den
Ich hätte nichts dagegen, wenn es für das Editieren von Dokumentationsseiten eine eigene graphische Benutzeroberfläche gäbe, mit der man sowohl die TemplateData, als auch die „Nicht-TemplateData“ einer Dokumentationsseite „aus einem Guss“ bearbeiten könnte.
Es gibt übrigens einen „Vorlagendokumentations-Editor“, der als grafische Benutzeroberfläche funktionieren soll und mit dem man TemplateData zwar importieren oder initial erstellen können soll; die anschließende Wartung müsste aber ohne dieses Tool erfolgen: „Dieses von MediaWiki bereitgestellte Werkzeug ist nur bei der Ersterstellung einer TemplateData-Dokumentation verwendbar.“ (4. Sept. 2020; Hilfe:TemplateData#Formulargestützte Erstellung und Bearbeitung).
Die TemplateData sind spezielle Metadaten, womit die Schwierigkeit verbunden ist, dass diese Daten wohl zumeist kein „richtiger Code“ in dem Sinne sind, dass sie den Programmablauf der jeweiligen Vorlage beeinflussen. Wenn in den TemplateData einer Vorlage Informationen eingetragen werden, die nicht gut zum Programmablauf der Vorlage passen, gibt es dazu keine automatischen Warnungen oder Fehlermeldungen. Im Gegensatz zu Programmiersprachen mit starker Typisierung, bei denen die unpassende Anwendung eines Datentyps spätestens bei der Ausführung des Programmcodes verhindert wird, sind die Datentypen in den TemplateData der Dokumentation zumeist eher ein Angebot als eine Vorgabe.
Die Vorlagenprogrammierung (H:VP) war eher da, als die später „übergestülpten“ TemplateData. Dadurch existiert raffinierter Code, der die Möglichkeiten übersteigt, der durch die TemplateData einfach dargestellt werden können.
In der „Vorlage:Infobox Protein“ gibt es beispielsweise einen Parameter, der HGNCid heißt und als Datentyp „Nummer“ in den TemplateData ausgewiesen ist. Eine Beschreibung des Parameters sucht man in der TemplateData-Tabelle vergebens, da fast alle Parameterbeschreibungen aus praktischen Gründen nicht dort, sondern in einer anderen Tabelle außerhalb der TemplateData eingetragen wurden. In dieser anderen Tabelle (im Abschnitt Parameter-Details) gibt es die Spalten „Parameter“, „Beschreibung“ und „Möglicher Wert“. Dem Parameter HGNCid kann diesen Angaben zufolge die Zahl 399 als „Möglicher Wert“ zugeordnet werden. Im Zusammenhang mit der Beschreibung: „Verlinkung auf den Eintrag bei HGNC (HUGO Gene Nomenclature Committee)“ wird klar, dass man wohl irgendwie eine Verknüpfung zu einer Datenbank erzeugt, wenn man HGNCid=399 in einer Vorlageneinbindung einträgt. Tut man das, erkennt man, dass der Parameter für sich allein genommen die Überschrift „Eigenschaften des menschlichen Proteins“ in der Infobox hervorruft und erst im Zusammenhang mit dem Parameter Symbol Verknüpfungen bewirkt. Ein dritter Parameter, AltSymbols, modifiziert in diesem Zusammenhang erzeugte Schriftzüge (z. B. Einzahl/ Mehrzahl).
Die Vorlage „Infobox Protein“ hat um die 40 Parameter zwischen denen oft komplexe Abhängigkeiten bestehen. Würde man diese Abhängigkeiten alle vollständig beschreiben, dann würde der Text in den jetzigen Beschreibungen der Parameter außerhalb der TemplateData um einiges länger werden. Würde man versuchen, die Beschreibungen innerhalb der TemplateData zu liefern, wäre es gut, wenn jedem Parameter ein einzelner, gut definierter Datentyp zugeordnet werden könnte. Gegenwärtig beschreibt der Datentyp „Nummer“ gut, welche Sorte von Werten man unter HGNCid eintragen sollte. HGNCid hat aber mehrere Funktionen und eine davon würde eher dem Datentyp „Boolesch“ entsprechen, nämlich die Frage, ob die Überschrift „Eigenschaften des menschlichen Proteins“ eingetragen wird oder nicht und eine weitere Funktion ist eine Veknüpfung, wofür der Datentyp „URL“ stehen würde. Wenn besonders knapper Text in der Vorlageneinbindung als günstig für die Benutzung angesehen wird, ist die Textmenge so, wie es jetzt ist, nicht mehr zu unterbieten; wenn man darauf Wert legen würde, dass nicht eingeweihte Benutzer*innen die Dokumentation verstehen, wären mindestens zwei separate Parameter an dieser Stelle vermutlich besser.
Es wäre nicht zu schaffen, sämtliche Vorlagen auf die TemplateData zuzuschneiden indem man die Vorlagenprogrammierung ändert.
  • Für und Wider
Das Thema „Vorlagen-Finder“ berührt mehrere Bereiche: die Anwendung von Vorlagen, die Analyse von Vorlagen, die Dokumentation von Vorlagen und – zumindest indirekt – auch die Programmierung von Vorlagen.
Der Ausgangspunkt ist die Anwendung von Vorlagen. Der/ die Benutzer*in soll in die Lage versetzt werden, innerhalb seines/ ihres Arbeitsablaufes den „Vorlagen-Finder“ einzusetzen, um die dafür passende Vorlage zu finden. Dafür braucht der „Vorlagen-Finder“ Voraussetzungen. Einen großen Teil dieser Voraussetzungen sollen die Benutzer*innen liefern, indem sie alte und neue TemplateData mit Leben erfüllen.
Das müsste – stark vereinfacht – etwa so aussehen:
  1. Die Community beschäftigt sich ohne „Vorlagen-Finder“ und ohne ein anderes, geeignetes Tool mit den Voraussetzungen, die den „Vorlagen-Finder“ mehr Möglichkeiten zur Nutzung geben, den TemplateData.
  2. Die Community bekommt den „Vorlagen-Finder“, nachdem sie bewiesen hat, dass sie ohne „Vorlagen-Finder“ und ohne ein anderes, geeignetes Tool zur Bearbeitung der TemplateData zurecht kommt.
Das wird so nicht klappen, auch wenn der „Vorlagen-Finder“ ein wenig Editier-Funktionalität bekäme und man das Ganze andersherum betrachten würde:
  1. Die Community macht erst einmal so weiter, wie bisher.
  2. Die Community bekommt den „Vorlagen-Finder“ und neue TemplateData-Funktionen. Anfangs kann der „Vorlagen-Finder“ noch nicht viel finden.
  3. Nach und nach bekommen viele Vorlagen Kurzbeschreibungen, die über eine einzelne Editierfunktion des „Vorlagen-Finders“ in die TemplateData eingetragen werden. Andere TemplateData-Felder bleiben ungenutzt, da es dafür kein einfach benutzbares Tool gibt.
Bei den Editierfunktionen sehe ich es ähnlich, wie PerfektesChaos: „dazu hat gefälligst die Vorlagendoku im Zusammenhang bearbeitet zu werden“.
Ich denke, dass der „Vorlagen-Finder“ sich auf Vorlagenauswertung konzentrieren sollte. Wichtig wäre, dass angegeben wird, welche Vorlagen überhaupt TemplateData haben, um die anderen Angaben, die der Vorlagen-Finder“ zur jeweiligen Vorlage liefern würde, dahin gehend bewerten zu können.
Ich fände es schön, wenn der „Vorlagen-Finder“ zur Parameter-Auswertung befähigt wäre, ähnlich wie das in der „Vorlagensuche“ (https://persondata.toolforge.org/vorlagen/) von Benutzer:Wurgl geht (und wahrscheinlich auch so ähnlich, wie es beim Templatetiger-Projekt gedacht ist).
Es bleiben so allerdings auch einige Sachen auf der Strecke:
  • übersichtliche Editierfunktionen für die Vorlagen-Dokumentation im Allgemeinen und für die TemplateData im Besonderen werden weiterhin fehlen; daraus folgend werden
  • einfache und gleichzeitig ausreichende Dokumentationen, die Autor*innen gut unterstützen, weiterhin eher selten sein, vor allem hinsichtlich der TemplateData (die für die Nutzung im Visual Editor wichtig sind) und
  • das Filtern von Suchergebnissen nach den „neuen TemplateData“ würde entfallen.
Es gibt im Grunde zwei Gruppen von Benutzer*innen im Zusammenhang mit dem Thema:
  1. Vorlagenprogrammierer*innen, die am besten wissen, was sie programmiert haben und deshalb die Dokumentation beliefern sollten und
  2. Autor*innen, die am besten wissen sollten, was sie brauchen und danach versuchen, die Vorlagen auszuwählen, wobei gute Dokumentationen helfen.
In beiden Gruppen ist die Dokumentation von Vorlagen nicht das primäre Ziel. Genau deshalb wäre es eigentlich gar nicht schlecht, wenn es eine Art „Visual Editor für die Vorlagendokumentation“ gäbe, der auch TemplateData kann. Einen solchen Editor gibt es allerdings nicht. Gäbe es ihn, könnte er auch nichts daran ändern, dass die zugrunde liegende Vorlagenprogrammierung mächtiger sein kann, als es durch die Datentypen der Parameter in den TemplateData angedeutet wird.
Aus all dem hier Geschriebenen ziehe ich den Schluss, dass der Ausbau der TemplateData wahrscheinlich erst einmal nicht auf der Agenda stehen sollte.
  • Fazit
Ich denke, dass die Wirkung der TemplateData im Sinne von „Leichter mit Vorlagen arbeiten“ überschätzt wird. Sie sind schwer umzusetzen, was dazu führt, dass das Schreiben der TemplateData für die einzelnen Vorlagen ein Job für Spezialisten ist. Wollte man daran etwas ändern, müsste man eine Art „Visual Editor für die Vorlagendokumentation“ bauen, der auch TemplateData kann. Vorher ist meiner Meinung nach etwas anderes dran:
Wir alle, die Helfenden (das Team Technische Wünsche), die Programmierenden von Vorlagen und die Nutzenden von Vorlagen, benötigen ein Werkzeug, dass den IST-Zustand hinsichtlich der Beschaffenheit der Vorlagen insgesamt und im Einzelnen analysieren kann. Dieses Werkzeug muss auch dann gut funktionieren, wenn Vorlagen suboptimal verwirklicht wurden.
Die Hälfte der „Legislaturperiode“ von „Leichter mit Vorlagen arbeiten“ ist rum und es bleibt noch ein Jahr.
Meiner Ansicht nach sollte man mit dem „Vorlagen-Finder“
  • alles suchen, filteren, auswählen und sowohl im Zusammenhang als auch Einzeln darstellen können, was bisher geht
  • und nichts suchen, filteren, auswählen und sowohl im Zusammenhang als auch Einzeln darstellen können, was bisher nicht geht.
Unter den gegenwärtigen Gegebenheiten sollte man nicht versuchen, dem „Vorlagen-Finder“ direkte Schreib-Funktionen für die Vorlagen-Dokumentation mitzugeben, da sie Einfachheit dort vortäuschen würden, wo Komplexität vorliegt.
Zum Schluss gebe ich noch ein paar Antworten auf selbst gestellte Fragen:
  • „Vorlagen-Finder“ bauen? Ja. Ich bin ziemlich sicher, dass wir ein Werkzeug zur Vorlagenauswertung benötigen.
  • TemplateData erweitern? Nein. Das ist eventuell Zukunftsmusik.
  • „Vorlagen-Finder“ überall integrieren? Nicht überall. Ich vermute, dass da Vorsicht geboten ist und dass man die Möglichkeit haben sollte, den Vorlagen-Finder gegebenenfalls nicht zu benutzen, wenn er im Arbeitsablauf stört.
  • Ende dieses Beitrags
Zum Anfang dieses Beitrags: ↑ 
Ich hoffe, dass ich euch (dem Team Technische Wünsche) etwas dabei helfen konnte, uns (der Community der deutschen Wikipedia) zu helfen.
Bei den Bestrebungen, die Wikipedia als vitale Plattform der freien Wissensvermittlung zu erhalten, wünsche ich uns allen viel Glück!

Mfg --Dirk123456 (Diskussion) 11:57, 8. Sep. 2020 (CEST)Beantworten

Abgerufen von „https://de.wikipedia.org/w/index.php?title=Benutzer_Diskussion:Dirk123456/Baustellenbaustelle_001/Baustelle-D/Baustelle-D.12&oldid=233136135“