Wikipedia Diskussion:Technische Wünsche/Topwünsche/Leichter mit Vorlagen arbeiten
Bitte achtet auf einen freundlichen Umgangston.
Das Projekt Technische Wünsche lebt vom Austausch. Alle Beiträge sind willkommen, solange sie konstruktiv sind. Das Projektteam bittet von persönlichen Angriffen oder beleidigenden Kommentaren abzusehen.
Letzter Kommentar: vor 5 Jahren7 Kommentare2 Personen sind an der Diskussion beteiligt
Nachdem nun also dieser Bereich den Rahmen absteckt, möchte ich gern, dass nach Erstellung einer shortlist der beabsichtigten konkreten Einzelaufgaben diese auf den nachfolgenden Seiten zwecks Kommentierung und Insider-Tipps veröffentlicht wird, bevor die Umsetzung begonnen wird:
WP:TWS – weil es vermutlich um relevante Software, Skripte usw. gehen wird.
Das weite Feld „Leichter mit Vorlagen arbeiten“ lässt sich ein wenig in Zielgruppen und Aspekte gliedern:
Aus Anwendersicht, namentlich per VisualEditor, Verbesserungen beim Eingabeformular
Sonderfall: Belege eingeben, und diese dann fachgerecht in Vorlagensyntax umtopfen, wobei es extrem viele Probleme gibt
Aus Sicht von Erstellern einer Vorlagensyntax
Der CodeMirror kann das im Prinzip; aber die Zugehörigkeit von Klammerpaarungen sollte besser sein, wie wohl bei Schnark?
Aus Sicht der Betreuer einer Vorlage und ihrer tatsächlichen Verwendung
Nachfolger für templatetiger in Quasi-Echtzeit (bissel lag ist immer).
vorlagenparser als Anregung. Problem: liefert immer sämtliche Einbindungen, ermöglicht keine Einschränkung. Damit untauglich bei mehr als 1000 Artikeln oder so; außerdem immer alle Parameter. Müsste filterbar sein nach bestimmten Ergebnisparametern, beliebige Bedingungen für Parameterwerte, alle Namensräume. Andernfalls herzlich unbrauchbar etwa für Vorlage:Internetquelle, aber CSV wäre schon mal ein wünschenswertes Ausgabeformat; MediaWiki-sortierbare HTML-Tabelle das alternative erste Ergebnis. XML, JSON, Lua wären weitere Exportformate und CSV deutlich überlegen. Ist egal; wenn erstmal der Ergebnissatz vorliegt, ist der Output einerlei in HTML/CSV/JSON/XML/Lua recht trivial formatierbar. Natürlich beliebige WMF-Wikis.
Zum VisualEditor würden mir zwei konkrete Themenbereiche aufscheinen:
Eingabeformular Vorlagen allgemein
Verbesserung des datepicker, und Einbau in den VE; jedoch mit individueller kalendarischer Präzision (nur Jahr, Jahr und Monat, Jahr-Monat-Tag; siehe phab:T226309) und außerdem für Jahre vor der Zeitenwende und gern auch mit julianisch-Option. Ggf. Zielvorgabe steuerbar als Typ date-year ./. date-year-month ./. date-year-month-day für TD.
ENUM-Typ, also eine in TD zu vereinbarende Liste diskreter Werte (Array: Text/Zahl), die dann als dropdown aus (ggf. scrollbarer) Vorschlagsliste ausgewählt werden können, oder keiner von denen (=Combo-Box). Gibt es sicherlich schon als Phab-Ticket irgendwo.
ENUM-Typ: „Sprachauswahl“. Ziel: Eine navigierbare Auswahl, die komfortabel aus Hunderten von Sprachen auswählen lässt, und als Ergebnis einen Code gemäß ISO 639 → RFC 5646 liefert. Um die 1000 Sprachen kämen in Frage; ein simples drop-down wäre überfordert. Eher nach Kontinenten vorsortiert. Immer Präferenz für (Projektsprache=) Seitensprache, Benutzersprache, Englisch, IME-Einstellungen. Neuer string-Typ erforderlich; vielleicht auch eine neue Familie code-language für TD. Kürzestmöglicher Code gemäß IANA.
ENUM-Typ: „Staatsauswahl“. Ziel: Eine navigierbare Auswahl, die komfortabel aus rund 200 Staaten auswählen lässt, und als Ergebnis einen Code gemäß ISO 3166 liefert. Ein simples drop-down wäre überfordert. Eher nach Kontinenten vorsortiert. Neuer string-Typ erforderlich; vielleicht auch eine Familie code-country für TD; code-country-a2 ./. code-country-a3.
Anwenderspezifizierbare <ref>-Namen, also statt der automatisch vergebenen name=":0" usw. ein Schulze-345 – das Kopieren von Quelltextsequenzen von einem Artikel in einen anderen ist höchst gefährlich, wenn es in Quelle und Ziel ein <ref name=":0" /> geben darf, bloß mit einer völlig anderen Bedeutung; und die Auswahl unter bereits vorhandenen ref wäre glücklicher, wenn die sprechende Namen trügen statt 0 1 2 3 4 5 6 7 8 9 (zugegebenermaßen nur Randgebiet zu „Vorlagen“, aber die ref umschließen die Zitationsvorlage).
Benutzer:Wurgl bereitet zurzeit auch so ein Echtzeit-Werkzeug zur Vorlagenauswertung vor (nutshell).
Funktionalität bei WMDE, falls dort realisiert, sollte in etwa wie folgt sein:
Es gibt eine Datenbank für jedes Wiki.
Jeder Datensatz ist eine Transklusion (keiner der Parserfunktions-Aliasse, kein 3{-Parameter):
page_id
ns
template_name (normalisiert; muss nicht exisitieren)
parameter
Dabei ist parameter ein Objekt key1=val1, key2=val2, key3=val3.
Bei jeder Veränderung einer Wiki-Seite (edit, delete page, move page[ns→ns], OS/hide, idealerweise auch purge) wird für die betroffene page_id jeder Datensatz gelöscht und anhand der neuesten Seitenversion erneut eine Folge von Datensätzen eingefügt (beim NS-move würde ein Update der nsn langen, bei gleicher nsn zu ignorieren).
Eine Abfrage soll aussehen:
Für
template_name (zu normalisieren, ergibt Array aus einem Element)
mit optional boolean Aliasse=true (ergänze template_name zu einem Array aus jedem redirect-Ziel bzw. WhatLinksHere-redirect hierauf)
in optional ns= (Vorgabe: 0)
für Ergebnis-Parameter=Array (Vorgabe: alle jemals auftretende) [Super-Formular: Multiselect-Auswahl aus Vorschlagsliste]
für RE-Bedingung1 UND/ODER RE-Bedingung2 UND/ODER RE-Bedingung3 UND/ODER (Vorgabe: alle) Parametername=RegExp
liefere Ergebnis im Format HTML (sortierbare Tabelle) oder (zusätzlich mit page_id): XML oder JSON oder Lua oder CSV.
Weil ich genannt wurde: Die Auswertung der Vorlagen hatte APPER schon implementiert, daraus wurden die Daten für das persondata-Tool generiert, diese Auswertung war auch die Grundlage für die Liste der Biografien mit ihren momentan über 4000 Subseiten und auch für diverse Normdaten-Auswertungen, allerdings hat er damals nicht alle Vorlagen ausgewertet. Der Crash der User-Datenbank (im Februar oder so) in Kombination mit Upgrade PHP 5 auf PHP 7 war für mich Anlass diese Datenbank mit besserer Struktur (Platzbedarf grob halbiert, und jetzt sind alle Vorlagen aus dem ANR drinnen) neu zu schreiben.
In der Datenbank stehen die Rohdaten der Vorlage drinnen, also wenn in einer Vorlage sowas wie param={{#expr:40969443/2381741 round 1}} steht, dann steht in meiner Datenbank eben auch {{#expr:40969443/2381741 round 1}} als Wert der Parameters "param", selbiges gilt für HTML-Kommentare2021 termin=2012<!--Fertigstellung für 2020 geplant--> ist in meiner Datenbank zum Parameter termin der Wert 2012<!--Fertigstellung für 2020 geplant--> hinterlegt. Ist der Parameter leer, dann ist NULL als Wert in der Datenbank. Ist der Parameter nicht in der Vorlage (im Artikel!, nicht im Template selbst) dann gibts eben keinen Eintrag. Zusätzlich parse ich die Vorlagen und weiß so auch, welche Parameter die Vorlage überhaupt hat (Einschränkung: wenn #invoke im Template vorkommt, dann mach ich das nicht, da muss ich noch forschen wie ich die bekannten Parameter eines Moduls rauspfriemle). Wie im Link geschrieben: alle 90 Sekunden (nachts 300 Sekunden) such ich aus der Tabelle dewiki_p.recentchanges alle Neuerungen raus (Verschiebung in und aus dem ANR, Löschung, (ich glaub auch Aufhebung einer Löschung), Edit ((purge bekomm ich nicht mit, wüsste nicht warum ich das bräuchte))) und lese diese Seiten neu.
Das Script macht aber auch einiges, das speziell für das Tool persondata ist, wie Gedaddel mit Normdaten, Das Artikel-Bilder bei Personen, ein wenig mit Kategorien, etc. Das müsste ich für andere Wikis rausnehmen.
Platzbedarf für dewiki:
MariaDB [s51412__data]> SELECT TABLE_NAME, DATA_LENGTH, INDEX_LENGTH FROM information_schema.tables WHERE table_schema = 's51412__data' and TABLE_NAME like "dewiki_td%";
+--------------------------+-------------+--------------+
| TABLE_NAME | DATA_LENGTH | INDEX_LENGTH |
+--------------------------+-------------+--------------+
| dewiki_td_data | 2436874240 | 2821652480 | (die Werte der Parameter)
| dewiki_td_data_pages | 347865088 | 245334016 | (die Seiten)
| dewiki_td_param | 2637824 | 2605056 | (die Namen der Parameter)
| dewiki_td_template | 5783552 | 6324224 | (die Namen der Vorlagen)
| dewiki_td_use | 531578880 | 1021214720 | (die Zuordnung zwischen Artikel, Template und den im Artikel verwendeten Parametern)
| dewiki_td_template_param | 4734976 | 2637824 | (welche Parameter kennt die Vorlage, eben mit der Einschränkung von #invoke)
+--------------------------+-------------+--------------+
Ein erster Wurf ist mal gemacht. Es fehlt noch einiges. Beispiel 1: Suche nach Vorlage:Infobox Fußballklub wo im Parameter "homepage" ein https-Link zu finden ist (mir ist nix besseres eingefallen und Fußball geht immer).
Beispiel 2: Vorlagen in denen der (wahrscheinlich unbenannte) Parameter "2" den Wert "mini" hat. Das sind wahrscheinlich fehlerhafte Copy-Paste-Fehler, das "mini" kommt von einem Logo, das vorher mal mit [[Datei:blubb.png|…|mini|…]] gestanden hat.
Werde ich beim nächsten konkreten Wartungsfall machen; passiert sicher innerhalb der nächsten paar Tage.
Einen habe ich gerade auf anderem Weg realisiert und arbeite ihn momentan etwas ab. Zu spät.
Dein Werkzeug ist sicher eine hilfreiche Zwischenlösung; mit mehr Möglichkeiten (Filterung statt alle Felder und Datensätze) als bei Gifti, und verschafft Erkenntnisse für die Erstellung eines möglichen globalen All-Wiki-Werkzeugs.
Also wertvolles proof-of-concept nach dem halbjährlich aktualisierten Templatetiger.
Nee, die rennen nicht weg, mein Kopf ist nicht (wie mein Rechner) mit mehreren Kernen bestückt und die beiden Interfaces mit den jeweils 5 Pins sind auch nicht die schnellsten. --Wurgl (Diskussion) 16:24, 16. Jul. 2019 (CEST)Beantworten
Zwischenüberschrift wegen Abweichung vom Ursprungsthread
Letzter Kommentar: vor 5 Jahren12 Kommentare4 Personen sind an der Diskussion beteiligt
Das müßte mMn sowieso ganz anders gelöst werden, nämlich mit unique identifiers für die Einzelnachweise, idealerweise die Q-Nummer, unter der der Einzelnachweis auf Wikidata oder, mglw. besser, einem eigenständigen Referenzdatenbankwiki abgelegt wird, siehe meta:Wikicite. Im Artikelquelltext haben Referenzen an sich, ob Vorlageoder nicht, mMn gar nix zu suchen. --Matthiasb – (CallMyCenter)21:32, 2. Jul. 2019 (CEST)Beantworten
Hey, das sehe ich aus langjähriger Praxis aber völlig anders. Referenzen haben ganz klar ihren natürlichen Ort im Artikelquelltext. Nur dort sind sie leicht zu prüfen und leicht zu bearbeiten. Ausgelagerte Referenzen sind IMO eine arbeitsuntaugliche, unsinnige Schnapsidee. Ich erinnere mich mit Grausen an wissenschaftliche Schwarten, die ihre Fußnoten in einen Extrateil am Buchende ausgelagert anbieten. Welch eine zeitraubende Hin- und Her-Blätterei! -- Was man hingegen anstreben sollte, ist eine engere Zusammenarbeit mit dem Internet Archive -> Jede Ref-URL sollte wann immer möglich sofort eine Wayback-Kopie abbekommen (mit einer vogeschalteten Prüfroutine, ob die gleiche Adresse nicht schon in den letzten 14 Tagen angelegt wurde, was ein Doppel unnötig machte). Macht Wp-fr das nicht schon? -- Justus Nussbaum (Diskussion) 11:27, 3. Jul. 2019 (CEST)Beantworten
Danke für den Hinweis, Cirdan. Hört sich ja gut an, aber entspricht nicht ganz meinen aktuellen Erfahrungen. Ich habe des öfteren Refs eingefügt und later on eine Wayback-Kopie-Anlage geprüft, dabei auch am nächsten Tag keine solche vorgefunden. Es könnte nun allerdings sein, dass eine größere, mehrtägige Zeitverzögerung dieses Bot-Mechanismus diesen Widerspruch erklären könnte. Vor Monaten hatte ich tatsächlich den Eindruck, dass eine Automatisierung der Ref-Sicherungen in der Wp-de flächendeckend eingerichtet sei, zuletzt seit einigen Monaten indes fielen mir eher die Lücken darin auf. Mangels zu mir durchgedrungener Informationen (ich habe drei wp-Newsletter auf meiner Userpage abonniert, lese wg dieser Menge diese manchmal aber nur quer) vermutete ich, dass der eingerichtete Automatismus ausgesetzt, nicht mehr erlaubt oder defekt sei. Bitte, @Cirdan:, sprich dich aus, ist es nur eine ggf. mehrtägige Zeitverzögerung der Bot-Durchläufe oder könnten da auch noch andere Ursachen mit hereinspielen? -- Justus Nussbaum (Diskussion) 14:21, 4. Jul. 2019 (CEST)Beantworten
Hallo Justus, das Internet Archive macht die Archivierung nicht per Bot, sondern liest Spezial:Letzte Änderungen mit. Der Bot ist nur dafür zuständig, die Archivlinks dort nachzutragen, wo der Link mittlerweile tot ist. Der Bot achtet darauf, eine Archivversion zu nehmen, die möglichst nah an dem Zeitpunkt liegt, zu dem der Link eingefügt wurde. An der großen Anzahl von Links, bei denen die Archivversion genau von dem Zeitpunkt stammt, zu dem der Link eingefügt wurde, kann man sehen, dass der Automatismus sehr gut funktioniert.
Dass du für von dir eingefügte Links keine Archivversion findest, liegt wahrscheinlich daran, dass das Internet Archive Archivversionen häufig nicht sofort freischaltet, sondern erst nach ca. einem halben Jahr online stellt. Das kann man gut daran erkennen, dass der IntenrnetArchiveBot z.B. im März eines Jahres einen Link als tot deklariert und dann im August eine Archivversion nachträgt, obwohl die Archivversion schon im März auf den Servern gelegen haben muss. Wie genau das gesteuert wird, weiß ich nicht. Es ist auch so, dass manche Websites die Archivierung untersagen/unterbinden, daran hält sich das Internet Archive in der Regel.--Cirdan±15:28, 4. Jul. 2019 (CEST)Beantworten
Vielen Dank für deine Auskünfte, Cirdan. Diese Hintergründe waren mir nicht bekannt. Halbes Jahr Zeitverzug finde ich äußerst ungut, heftig. Abgesehen davon, dass Schimpfen nichts nützt, findest Du das okay und auf Dauer tragbar so? Gäbe es eventuell Chancen, auf Wikimedia-Eben eine eigene, tauglichere Referenzen-Sicherungs-Datenbank einzurichten? Wäre das sinnvoll? Ob Wikidata dafür geeignet ist, halte ich für mindestens fragwürdig. Klar war mir bekannt, dass bestimmte Medienhäuser, z.Bsp. die FAZ, das Sicherungsreferenz-Anlegen per Wayback bislang schon blocken. -- Justus Nussbaum (Diskussion) 16:16, 4. Jul. 2019 (CEST)Beantworten
Ich klinke mich hier mal ungefragt ein.
Die ganzen Webarchive sind allesamt Urheberrechtsverletzungen. Sie präsentieren Inhalte eines fremden Publizierers, ohne dass dieser Verfügungsgewalt darüber hätte, geschweige denn zugestimmt hätte oder gefragt wurde. Das ist eine extrem fragile Gratwanderung.
Es kann sein, dass eine Webseite wegen kleinerer technischer Schwierigkeiten vorübergehend nicht abrufbar ist, aber nach ein paar Wochen wieder im Original verfügbar wird.
Die Archivierungsdienste warten deshalb zumindest ein halbes Jahr, ob zwischenzeitlich ein mögliches Serverproblem behoben wurde, oder aber scheinbar „dauerhaft“ dieser Inhalt nicht mehr angeboten würde.
Wenn es gleichzeitig das Original und die inhaltsgleiche Archivkopie gibt, dann fehlen dem Anbieter Klicks, Nachfrage, Werbeeinnahmen, weiteres Stöbern auf seiner Original-Website, und dann kann er sein Angebot nicht mehr finanzieren und der Aufwand lohnt nicht mehr und er stellt sein komplettes Angebot ein und generiert überhaupt keine Inhalte mehr.
Da die Rechtslage ungeklärt und eine riesige Grauzone ist, wäre es nicht allzu weise, wenn Wikimedia in Konkurrenz zum Internet-Archiv auch noch fragwürdige Urheberrechtsverletzungen auf Wiki-Servern anbietet und dafür Millionen investiert.
Eine Grauzone sagst Du, PerfektesChaos, zurecht. Damit hast Du sicher nicht unrecht! Die Tatsache, dass es das Internet Archive etc. nach Jahren noch immer gibt, ist sicher vordergründig dem US-Grundsatz des Fair Use zu danken. OTOH ist da auch der gesellschaftliche Nutzen zu sehen, den öffentlich zugängliche, nicht-kommerzielle Referenzdatenbanken erbringen. Ökonomie ist nicht alles und BWL schon gar nicht, sonst gäbe es keine Open Source, Open Access, Kunstfreiheit, Zitierfreiheit und Panoramafreiheit.
Wenn wir mit der Wikipedia da auf unsicherem Eis tanzen, dann müssten wir nicht Angst und Panik schüren, sondern erfindungsreicher werden. Vielleicht brauchen wir zukünftig z.Bsp. mal eine große Kampagne zur gesetzlichen Einführung von Fair Use in Deutschland? Unmöglich? Wer für die lebbare Zukunft nicht notfalls kämpft, der hat seine Freiheit alsbald verloren. -- Justus Nussbaum (Diskussion) 19:04, 4. Jul. 2019 (CEST)Beantworten
@Justus Nussbaum: Den Ausführungen von PerfektesChaos kann ich nichts weiter hinzufügen. Was mit Sicherheit vorstellbar und aus meiner Sicht überlegenswert ist, wäre eine nicht-öffentliche Archivierung aller als Beleg genutzten Websites und zwar möglichst (auch) als Screenshot. Gleichzeitig sollte diese Wikimedia-Institution auch alle gedruckten und sonstigen Werke sammeln, die als Beleg verwendet werden. Das wäre in etwa das Pendant zu einer Nationalbibliothek, wo man auf (ggf. begründete) Anfrage diese Websites, Bücher oder Videos einsehen kann. Diese Idee einer Wikimedia-Bibliothek ist nicht neu und könnte in den nächsten Jahren neues Interesse erhalten, denn auch die Nationalbibliotheken selbst beschäftigen sich (u.a. in Zusammenhang mit ausschließlich als E-Book oder Online-Publikation erscheinenden Veröffentlichungen) mit der Frage der Konservierung flüchtiger digitaler Inhalte.--Cirdan±19:27, 6. Jul. 2019 (CEST)Beantworten
Klar doch, ich bin immer für realistisches, pragmatisches Herangehen. Deine Überlegungen hinsichtlich nicht-öffentlicher Ref-Archivierung durch Wikimedia sind gangbar. Webbasierte Zugangsberechtigung könnte ggf. an Sichterstatus gebunden erteilt werden. Nunja, noch Zukunftsmusik, ein weites Arbeitsfeld. -- Justus Nussbaum (Diskussion) 12:54, 7. Jul. 2019 (CEST)Beantworten
Nein, Justus Nussbaum. Referenzen sind strukturierte Daten, und die speichert man am besten in einer Datenbank. Wo die dann angezeigt werden, ist eine ganz andere Sache. (Es wäre z.B. für große Bildschirme ein dreispaltiger Skin denkbar, der außer der Navigationsspalte links eine Anmerkungsspalte rechts anbietet, in der die Fußnotentexte auf derselben Zeile stehen (oder beginnen), auf der ihr Anker im Text steht.) Es reicht aus, wenn im Artikelquelltext ein Anker steht, der beim Klicken das Öffnen eines Bearbeitungsfensters auslöst. So schwer dürfte das softwaretechnisch auch nicht sein; Word 5.0 für MS-DOS konnte das schon um 1991. Und sinnvoll ist das schon deswegen, daß nicht jede Sprachversion die Metadaten einer Referenz erneut erfaßt. Wenn schon einmal die Metadaten erfaßt sind, reichen ISBN oder URL oder doi. oder vergleichbare Identifier, um einen Belegs eindeutig wiederzuerkennen. Eine solche zentrale Ablage hätte den Vorteil, daß die Linkfixer aller Herren Länder ihre Arbeit nicht in mehreren Sprachversionen erledigen müssen bzw. beim Überseten aus anderen Sprachversionen deutlich weniger bis mglw. gar keine toten Links mehr kopiert werden.
Allerdings sehe ich eine Problematik, nämlich sicherzustellen, daß eine reine URL-Angabe nicht zwingend eindeutig ist, wenn nämlich bspw. eine Homepage zu unterschiedlichen Zeiten unterschiedliche Inhalte hatte und manche Verlage nicht bei jedem Nachdruck mit nur marginal veränderten Inhalt eine neue ISBN vergeben, kostet ja Geld, da kann man sparen. Und bei Werken, die keine ISBN oder zumindest OCLC haben, fehlt es an einem eindeutig identifizierbaren (sic!) eindeutigen Merkmal. Egal, wer als eine solche Referenz bearbeiten will, etwa durch Dppelklick auf den Anker im Quelltext bzw. in ähnlicher Weise im VE, der bekommt meiner Vorstellung nach ein Fenster, in dem er die Referenz bearbeiten kann. Die bereits erfaßten Metadaten zieht die Software aus Wikidata, eine Veränderung bewirkt die Änderung der Abspeicherung dort (ähnlich zur Eintragung anderer Sprachversionen bei einem neuen Artikel). Ob und wie deutlich man dem Benutzer anzeigt, daß diese Abspeicherung in Wikidata erfolgt, ist eine andere Frage, die auch damit zusammenhängt, daß Wikidatabearbeitungen CC0 sind.
Sorry, Matthiasb, mich hat deine Argumentation nicht überzeugt. Ich konstatiere, dass wir unterschiedliche Auffassungen vertreten und das möglicherweise auch auf Dauer so bleibt. Gleich dein Eingangsstatement "Referenzen sind strukturierte Daten" möchte ich als sachlich falsch zurückweisen. Richtig ist vielmehr: Referenzen lassen sich als strukturierte Daten abspeichern, aber eben auch anders. Dass eine Datenbank-Auslagerung nötig sei, ist deine Bewertung; meiner Auffassung nach ist das Gegenteil richtig. Wenn es dennoch so gemacht werden sollte, muss ein Überwiegen der Nützlichkeit (inklus. für wen? nützlich?) nicht nur behauptet sondern nachvollziehbar bewiesen werden. Das dürfte IMHO schwer bis unmöglich sein, denn die Nachteile für Leser und Wikipedianer überwiegen m.E. deutlich.
Gerade weil ich seit langem in Wikidata aktiv bin, stoße ich ständig darauf, wie baustellenmäßig und dürftig der Sachstand dort weiterhin ist. Gerade Neuerungen sind dort häufig sehr unausgereift umgesetzt und machen den aktiven Beiträgern dort das Arbeiten unnötig sauer. Ich freue mich auf künftige Gelegenheiten, etwa auf der Wikicon in Wuppertal mit deutschsprachigen Wikidata-Admins und Softwaretechnikern in fruchtbare Diskussion zu Fehlerbereinigungen zu kommen. Deine Verlinkung, Danke dafür, bezieht sich nur auf Scholar-Metadaten wie beim DOI-Nachweis, das Feld ist ja viel weiter. Aber auch da taucht ein Unterschied zwischen uns auf, ich setze zumeist auf 'Klasse statt Masse', mich euphorisieren daher Aussagen wie "inzwischen tausende von ..." keineswegs. Lieber mehr handwerklich gute Arbeit als tausendfach eingesetzte unausgereifte Skripte und Konditionierungen. Abschließend eine Bitte an Dich, mir gefällt der manchmal sehr dogmatische, rechthaberische Tonfall deiner Äußerungen oben nicht, gib Dir bitte mehr Mühe bei deinen Formulierungen. Last not least, fortgesetzte Endlosdiskussionen brauche ich/brauchen wir hier eher nicht! -- Justus Nussbaum (Diskussion) 15:51, 4. Jul. 2019 (CEST)Beantworten
WikiCon, Workshop & so
Letzter Kommentar: vor 5 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Wenn ich das richtig überblicke, wird niemand von der Vorlagenwerkstatt auf der WikiCon anwesend sein.
Ergo wird die VWS nicht bei der geplanten Vorlagen-Werkstatt mitwirken.
Das sind prächtige Voraussetzungen, um wunderbar aneinander vorbei und gegeneinander zu arbeiten.
Das Vorlagensystem ist seit fünf Jahren in einem allmählichen strukturellen Umbau, was Praktiken der ersten Jahre angeht, als es mal einige 100 Vorlagen gab, alle Benutzer alle Vorlagen und ihre wenigen Parameter kannten, und diese mit direkter Tipparbeit im Quelltext eingebunden wurden.
Inzwischen gibt es über 70.000 Vorlagen.
Das hat Auswirkungen auf eine konfliktfreie und selbsterklärende Namensgebung.
Sie haben wesentlich mehr Parameter und Optionen.
Sie werden nicht mehr durch einzelne Tastendrücke erarbeitet, sondern per C&P aus Kopiervorlagen oder komfortabel durch Formulare im VisualEditor bzw. Quelltext-Editor „2017“.
Inzwischen gibt es zu allen häufig im ANR verwendeten Vorlagen Einzel-Dokumentationen (die erst ab 2008/2009 eingeführt wurden); zu häufig im ANR benutzten meist auch bereits für VisualEditor, sofern diese Vorlagen gepflegt werden und sich die Betreuer der Vorlagen nicht sogar ausdrücklich gegen eine Modernisierung und Eignung für den VisualEditor zur Wehr setzen.
Niemand mehr, der ein wenig über den Tellerrand hinaus arbeitet, weiß heute noch von allen über einen extrem engen Themenbereich hinausgehenden Vorlagen alle Parameter auswendig mit vorgeschriebener Reihenfolge und Details zur Bedeutung.
Die langjährigen Restrukturierungsmaßnahmen der VWS zielen darauf ab, die Vorlagen leichter bedienbar zu machen; insbesondere durch Vereinheitlichungen und selbsterklärende Praktiken. Das stößt aber immer wieder auf Widerstand der damaligen Ersteller, die verlangen, dass die Welt gefälligst so zu bleiben habe wie sie das 2005 mal programmiert hatten, und der Rest der Welt habe gefälligst zu verstehen, wie sie persönlich sich das 2005 mal ausgedacht hatten.
Die Erfahrung lehrt, dass solche Workshops, wenn unkontrolliert driftend, schnell von einer nicht repräsentativen Minderheit umfunktioniert werden können mit Forderungen, zurück zur guten alten Zeit zurückzukehren, wie das 2005 mal war, mit 200 Vorlagen die alle auswendig kannten, und dann alles ganz ganz einfach zu machen, und das wäre ja genau das Ziel eines Workshops „Leichter mit Vorlagen arbeiten“.
Das wird nicht funktionieren, und wäre Zeitvergeudung.
Auch Beschwerden über einzelne Vorlagen, die X habe zu viele Parameter oder Zeilenumbrüche im Quelltext würden diese in deren Artikeln nicht haben wollen, während jene eine zeilenweise Gliederung bei Vorlagen mit vielen Parametern dringend benötigen, um überhaupt noch den Überblick zu behalten – solche Angelegenheiten liegen weder bei WMDE noch wären sie zielführend zu erörtern.
Ein Grundproblem ist es, dass es praktisch keinerlei Richtlinien zu Vorlagen gibt – was zur Folge hat, dass jeder Depp unter jedem Namen neue Vorlagen erstellen darf, mit konfuser Programmierung und unbedienbarer Parametrisierung, und die nachfolgenden Generationen und die WP:VWS dann irgendwie die Altbestände zukunftsfähig umbauen müssen.
Es gibt auch niemanden, der befugt wäre, Richtlinien und Spielregeln zu Vorlagen zu erlassen und verbindlich durchzusetzen; und jeder Versuch auf Einschränkung des Wildwuchses hatte wütende Proteste vereinzelter aber sehr lautstarker Benutzer zur Folge. Dann halt nicht. Ergo gibt es keine vertiefende Anleitung zur Neuerstellung von Vorlagen, und wird es auch auf absehbare Zeit mangels Konsens nicht geben. Wobei das Hauptproblem auf der inhaltlichen, organisatorischen Ebene liegt – wann ist wozu überhaupt eine Vorlage sinnvoll, und welche Parameterstruktur ist zu wählen? Die technische Umsetzung bereitet seltener Schwierigkeiten; dazu wird bei ähnlichen mehr oder weniger gelungenen Programmierungen abgeguckt und eiskalt abkopiert.
Ich rege deshalb an, dass es eine Art Live-Schaltung in den Minuten der Workshop-Zeit gibt, also eine spezielle Wikitext-Diskussionsseite, bei der konkret auftauchende Fragen durch regelmäßig in der WP:VWS Mitarbeitende beantwortet und kommentiert werden können, so dass Missverständnisse in den Ergebnissen des Workshops vermieden werden können. Besonders live für die Dauer eines physischen Workshops, und etwas offliniger für die Gesamtdauer der WikiCon.
VG --PerfektesChaos17:27, 26. Sep. 2019 (CEST)Beantworten
@PerfektesChaos: Hallo und danke für die Hinweise. Mein Text auf der Vorderseite ist nicht ganz klar formuliert gewesen, vor allem der Begriff Werkstatt war irreführend. Ist jetzt geändert und so hoffentlich besser.
Im Workshop zum Thema Vorlagen auf der WikiCon geht es darum, verschiedene Perspektiven auf das Thema zu bekommen, also zum Beispiel von Leuten, die sich gut mit Vorlagen auskennen, und auch von solchen, die sich weniger gut auskennen. Wichtig: Es wird noch nicht um Lösungsideen gehen und auch nicht um Fragen zu dem Thema, sondern um das Beschreiben von Erfahrungen und Problemen, die Leute im Umgang mit Vorlagen haben. Zu diesem Beschreiben eine textbasierte Live-Schalte anzubieten, wird nicht machbar sein, weil mit die verwendete Methode Stift und Papier erfordert. Wie immer werden die Ergebnisse nach der WikiCon aber im Wiki vorgestellt, und sollen dann gerne auch kommentiert werden.
Dieser Workshop ist nur eine von mehreren Quellen für die Recherche, die das Team Technische Wünsche zzt. vornimmt.
Es wird Interviews geben, sowohl auf der WikiCon als auch als Ferninterviews.
Es werden existierende Phabricator-Tasks ausgewertet.
Es werden Hinweise und Diskussionen aus den Wikis ausgewertet. Dazu zählen Hinweise aus der Umfrage und der Diskussionsseite des Gewinnerthemas, Hinweise auf dieser Seite hier, und es werden auch weitere Diskussionen aus den Wikis betrachtet. Wenn du oder andere Mitlesende Tipps für Seiten haben, die dabei unbedingt Betrachtung finden sollten, dann bitte gerne Bescheid geben.
Die Vorlagen-Praxis (vorher: Vorlagen-Werkstatt), die für die WikiCon geplant ist, ist eine weitere Möglichkeit, anhand von echten Beispielen zu beobachten, wo es bei Leuten in ihrer Arbeit mit Vorlagen hakt. In der Tat lädt die Bezeichnung „Werkstatt“ zu Verwechslungen mit der VWS ein, daher nun die Umbenennung.
Die Expertise des VWS-Teams wäre für die Recherche dieses Themenschwerpunkts sehr wertvoll. Daher wäre es toll, wenn auch Leute aus der VWS für (Fern-)Interviews bereit stünden. Gibt es vielleicht eine Übersicht der VWS-Mitglieder? Ich würde sie dann diesbezüglich direkt anpingen und fragen, ob Interesse besteht. Für wen Interviews nichts sind, der kann natürlich alles, was ihm wichtig ist, auch auf dieser Diskussionsseite hier beschreiben. Auch darauf würde ich beim Pingen hinweisen. Dir schon mal vielen Dank für deine vielen Beispiele, wo es hakt und was zu berücksichtigen ist.
Sobald nach der Recherche konkrete Ideen für Einzelprojekte feststehen, werden diese dann auch auf den von dir weiter oben vorgeschlagenen Seiten vorgestellt, um auch dann noch mal Tipps und Hinweise zu bekommen. -- Viele Grüße und ein schönes Wochenende, Johanna Strodt (WMDE) (Diskussion) 14:59, 27. Sep. 2019 (CEST)Beantworten
Ich antworte mal in mehreren Abschnitten, und heute noch nicht alle:
Mitgliederliste VWS
Gibt es, ist wohl von 2011, taugt nix. Stehen diverse Leute drauf, die nicht oder nicht mehr im Vorlagenbereich aktiv sind, und ich sowie andere sehr aktive aktuelle Leutchen stünden nicht drauf.
Einfach mal über die WP:VWS oder die jüngste archivierte Version gucken und selbst herausfinden, welche Nicks da häufiger in beantwortender Rolle aktiv sind.
Präzisierung der Thematik „mit Vorlagen arbeiten“ – da gibt es rund fünf Rollen und Schwierigkeitsgrade, was aber aus der Projektseite nicht klar hervorgeht
Mit einer vorhandenen Vorlage arbeiten; sie also ausfüllen, einfügen, Werte ändern
Einziger für Außenstehende relevanter Aspekt, insbesondere unter „Leichter arbeiten“.
Eine neue Version einer Standardvorlage neu anlegen.
Etwa eine neue Navigationsleiste für einen frisch aufgestiegenen Fußballverein, genauso wie 30 bereits existierende Navigationsleisten der Fußballvereine in der Region.
Keine geistige Herausforderung; C&P, Name des Vereins überschreiben, anderes Logo einfügen, Namen der Spieler anpassen.
Wer es kann, macht es; wen das überfordert, der bittet andere Fußballer darum; wird es auch nicht erlernen. Sowas liegt nun mal nicht allen.
Programmierung substanziell verändern
Braucht gefestigte Kenntnisse der Quelltextsyntax und zusätzlicher Sprachmöglichkeiten und interner Vorlagen/Modulaufrufe; auch der Dokumentation, des Testens, weitere Strategien zur Anpassung von Altbeständen.
Lässt sich im Lauf der Jahre erlernen. Liegt nicht allen. Kleine Textanpassungen werden sich machen lassen; geändertes Verhalten nach außen und Handhabung bisheriger Werte können sehr schnell die Managementfähigkeiten überfordern.
Eine komplett neue Vorlage anlegen; ohne unmittelbare Vorbilder.
Ist das überhaupt sinnvoll? Wäre das überhaupt erwünscht?
Wie sind die Daten zu strukturieren? Was wäre zwecks Zukunftsfähigkeit zu bedenken?
Wie soll die Vorlage heißen, wie die Parameter?
Viele Fragestellungen, für deren Beantwortung es sehr viel Hintergrundwissens und einige Jahre Erfahrung bedarf. Nix für schnelles HowTo und Guide und Tutorial und Crashkurs.
Management ganzer Vorlagenpakete, aller Vorlagen, einheitliche Dokumentation, Vereinheitlichung, strategische Ziele
Außen vor.
Die VWS strebt generell eine Vereinfachung an durch Vereinheitlichung von Parameternamen, Parameterwerten und -formaten, Namensgebung, Dokumentation usw. Bewährte zukunftsfähige Praktiken sollen ausgebaut werden, exotische Einzelkonstrukte durch einfache Standardlösungen ersetzt werden. Damit soll neben der Anwendung auch die Pflege der Programmierung erleichtert werden. Führt zu Konflikten mit noch aktiven Erstellern von ≈2006, die sich mühsam etwas gebastelt hatten und grundsätzlich keinerlei Veränderung daran wünschen.
Generationenkonflikt
Heute nicht mehr; Wochenende, Anfang Oktober.
Generell haben die in der VWS Mitwirkenden jahrelange Erfahrung mit den typischen Problemen der Anwenderschaft. Das lässt sich nicht mal eben an einem WikiCon-Wochenende erlernen, und es haben unterschiedliche Autorengruppen fundamental unterschiedliche Probleme, und die Lösungsstrategien und Wünsche können in direktem Konflikt stehen.
Schnellschusskommentar zu „Primäre Zielgruppen“ usw.
Letzter Kommentar: vor 4 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Einige Anmerkungen:
„Code kann nur über HTML-Kommentare kommentiert werden – diese werden mit eingebunden und erscheinen somit im HTML-Quelltext der Artikel.“
Das ist schlicht falsch.
Aus Wertzuweisungen an Parameter werden die HTML-Kommentare bereits ausgefiltert und sind aus einer eingebundenen Vorlage heraus nicht mehr sichtbar.
Aus dem gesamten Artikel werden seit etwa zehn Jahren alle HTML-Kommentare ausgefiltert und erscheinen nie im HTML-Dokument der Leser (war ganz ganz früher noch nicht so).
„Die Syntax verwendet zahlreiche geschweifte Klammern. Dadurch ist es schwer zu sehen, was zusammen gehört und ob etwas fehlt.“
Ja, Riesenproblem.
Unsere CodeMirror-Werkzeuge unterstützen sowas für andere Programmiersprachen, auch Schnark hat .js für sowas und es gibt eine trickreiche Benutzerkonfiguration für CodeMirror, mit dem das auch geht.
Ist aber mühsam.
Persönlich weiche ich bei komplexen Ausdrücken immer in externe Editoren aus, bei denen ich Klammern anklicken kann und die Paarung hervorgehoben sehe.
„Da es keine Variablen oder Funktionen gibt, muss Vorlagencode oft dupliziert werden.“
Äh, wäre genauer zu spezifizieren.
Es würde auch in einem unentwirrbaren Dschungel landen, wenn jedes Fitzelchen von zwei Zeilen wieder in einer anderen Vorlage untergebracht wird; das Zusammenwirken wäre nicht mehr überschaubar, die Fitzelchen wegen unübersehbarer Auswirkungen nicht mehr wartbar.
Duplikation und damit robusten self-contained Code unabhängig vom Rest der Welt ist da überschaubarer.
Ich habe Dutzende von Hilfsfunktionen in mehreren Lua-Bibliotheken bereitgestellt.
Vermutlich eher nicht bekannt.
„Weißräume werden bei benannten und unbenannten Parametern unterschiedlich behandelt.“
Ist seit immer so, und kann aus Kompatibilitätsgründen nach anderthalb Jahrzehnten und unbekannt vielen von einer Änderung betroffenen Wikis mit ungezählt vielen betroffener Vorlagen auch nicht mehr verändert werden.
Trick: Die VWS geht konsequent dazu über, selbst bei zwei Parametern beiden Namen zu geben, und trimmt so automatisch.
Parameternamen können beliebige Zeichen enthalten. Dies kann bei unbenannten Parametern dazu führen, dass ein Teil des Wertes als Parametername identifiziert wird.
Trick: Die VWS geht konsequent dazu über, selbst bei zwei Parametern beiden Namen zu geben, und vermeidet so automatisch dieses Problem.
Unbenannte Parameter waren eine Masche der frühen Jahre gewesen, als es 200 oder 300 Vorlagen gab, mit immer nur zwei oder vier Parametern, die jeder auswendig kannte und ohne Doku freihändig dahintippte. Bei 70.000 Vorlagen und teilweise zig optionalen Parametern raten wir jedem Quelltext-Tipper die Nutzung von Kopiervorlagen aus den Einzeldokus an. Dann stören beim C&P auch längere Namen der Vorlage und der Parameter beim C&P nicht.
„Historisch gewachsene … Uneinheitliche Namen sind somit kaum auflösbar.“
In der Tat ein Problem, aber reine Namensgeschichte ist über WL leicht funktional zu ändern.
Schwierig ist, dass dann während einer Migrationsphase alter und neuer Name nebeneinander stehen, die zu merkende Informationsmenge duplizieren, und außerdem auf ewig in den Schädeln steckt, was man sich 2007 mal gemerkt hatte und nun auf ewig neu eintippt.
WSTM stellt dezent den Altbestand allmählich um. Es ist zu hoffen, dass veraltete Formen vergessen werden.
„Viele alte Templates müssen überarbeitet oder auf Lua migriert werden.“
Viele alte Vorlagen werden systematisch von der VWS aufgearbeitet, bekommen neue (selbsterklärende) Namen, neue systematische Parameter mit neuen Werteformaten und aktualisierter vereinheitlichter Namensgebung. Außerdem modernisierte Funktionalität mit Kompatibilität und responsiver Darstellung auf Mobilgeräten.
Ist aber Riesen-Akt.
„oder auf Lua migriert werden“ – das wäre sehr dumm.
Mit einer Umstellung auf Lua sinkt der Personenkreis, der die Programmierung pflegen könnte, von mehreren Hundert auf ein Dutzend, von denen das nur ein oder zwei für fremde Lua-Codes machen würden, und eine Umstellung auf Lua führt dazu, dass aus Kapazitätsgründen nichts mehr gepflegt oder repariert oder weiterentwickelt werden kann.
Komplett-Umstellung auf Lua machen wir nur dort, wo zentrale Rückgrat-Funktionalität mit klassischer Vorlagenprogrammierung nicht mehr effizient lösbar ist.
Ohne Lua können die Fachautoren an ihren eigenen Vorlagen noch selbst basteln und experimentieren und aktualisieren.
„Es ist schwer Vorlagen zu verstehen, wenn sich ihre Funktionalität über viele Untervorlagen verteilt.“
Jau, und das ist gerade die Gegenposition zu weiter oben: „Da es keine Variablen oder Funktionen gibt, muss Vorlagencode oft dupliziert werden.“
„Es fehlen Tools, um zu analysieren, wie bestehende Vorlagen verwendet werden.“
Stimmt, und hier wäre WMDE-Unterstützung auf den Labs sehr, sehr erwünscht. Stichwort: Wurgl-Zauber.
Es kann nicht ausreichend überprüft werden, welche Auswirkungen Änderungen an Vorlagen haben.
Naja; gute Testseiten, Unit-Tests halten einem das Gröbste vom Leib.
Setzt aber von vornherein gutes Aufgabendesign, gutes Lösungskonzept voraus.
Ohne systematische Testseiten ist das nur am Aufschrei auf der Vorlagendisk, in FZW oder VWS zu bemerken.
Bugs können immer passieren. Aber ungetestete Änderungen ins Blaue am produktiven Bestand sind tödlich und vermeidbar.
„Nutzende wissen oft nicht, welche Vorlagen es gibt oder wie diese heißen.“
Die Altvorderen hatten die Idee gehabt, alle Vorlagen immer zusammen auf Projektseiten für einen Themenbereich zu dokumentieren, mit Dokumentation aller Parameter und Ansichtsbeispielen. Etwa WP:TBS.
Das ging für ein paar Dutzend, bei einer Gesamtzahl unter 500.
Bei 70.000 Vorlagen ist das schlicht utopisch. Auch wenn man Navileisten rausrechnet; es gibt um 1000 produktive Infoboxen.
Es gibt drei Wege für Verwendung in Artikeln:
Lernen, was in anderen Artikeln zu ähnlichen Themen so vorkommt
Systematische Erschließung im Kategoriesystem der Vorlagen, was versucht wird auszubauen, aber längst nicht perfekt ist.
Setzt nebenbei sprechende, selbsterklärende Namensgebung voraus; aus irgendeinem kryptischen QXJ in irgendeiner Ecke wird niemand darauf gestoßen, dass dies jetzt genau jenes Problem lösen würde.
Simpel die Schlagwortsuche im Vorlagen-Namensraum; wie bei der Suche nach anderen Seiten.
„Oft gibt es dabei Inkonsistenzen zwischen Vorlagen und zwischen Wikis“
Das Thema „globale Vorlagen“ mit identischen (also englischen) Vorlagennamen und Parameternamen und identischer Funktion auf allen Wikis darf ohnehin getrost vergessen werden.
Das kann aus vielerlei Gründen so nicht funktionieren, wie es sich manche erträumen. Würde es von irgendeiner globalen Vorlagen-Regierung in irgendeiner Weise durchgesetzt, geht sofort das gleiche Gejammer los, dass die allermeisten Autoren die Namen der Vorlagen und ihrer Parameter nicht verstehen können und benötigte Veränderungen nur mit Zustimmung von 500 anderen Wikis möglich wären und dass vom Antrag auf eine Veränderung, etwa einen neuen Parameter, bis zur Realisierung drei Jahre vergehen würden, und auch nur auf Englisch mittels Phabricator-Ticket abgewickelt werden können. Jede Veränderung beeinflusst nicht nur das eigene Wiki, sondern 500 andere mit.
„Regeln zur Vereinheitlichung von Vorlagen finden keine Mehrheit.“
Müsste genauer spezifiziert werden
Es gibt für Vorlagen eigentlich keine Regeln außer der Löschdiskussion.
Jeder Volldepp darf jederzeit jede Vorlage unter jedem Namen anlegen und sonstwo einbauen. Es gibt keine Qualitätssicherung, keine Handhabe, keine Ermächtigung für irgendwen dagegen etwas zu tun. Der einzige Weg nach Bitten und Aufforderung ist die Löschdiskussion.
Ansonsten wüsste ich nicht, wo was „keine Mehrheit“ gefunden haben solle. Es gibt weder MB noch projektweite noch globale Entscheidungen, die „Mehrheiten“ finden könnten.
„Vorlagen machen den Quelltext unübersichtlicher.“
Schlechte ja; gute im Gegenteil, und die gleiche Funktionalität und Wartbarkeit ohne Vorlagen schier nicht erreichbar.
„Manche Vorlagen verlangsamen das Rendern von Seiten.“
Ziemliches Gerücht. Nachweis fehlt.
Bei manchen bekannten schlechten Lösungen würde das passieren; aber die sind selten und private Spielereien.
Die gleiche Funktionalität ohne Vorlagen wäre noch riesiger und würde genauso lang dauern.
„#ifexist … fälschlich als Links auftauchen.“
Die Software verwendet die Abfragen mit ifexist als Hinweis darauf, dass die Seitengestaltung sich verändern würde, wenn die bislang nicht existierende Seite neu angelegt würde, oder eine bislang existierende gelöscht würde. Diese Link-Eintragung ist wichtig, um sofort aus Blaulinks Rotlinks oder aus Rotlinks Blaulinks darzustellen. Die Ausnutzung durch Menschen ist nur Abfallprodukt davon.
Das geht eigentlich nur die Leute an, die mit den Spezialseiten arbeiten würden; und die sind ohnehin nur mit sehr viel Hintergrundwissen anzuwenden.
„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.“
Ja, und viele URL liefern nicht mehr die Webseiten und den Wetterbericht von vor zehn Jahren.
Viele Vorlagen existieren heute schon gar nicht mehr, sie würden den Vorlagennamensraum verschmutzen und Unmengen Suchtreffer auf unerwünschte gelöschte Vorlagen liefern, oder es würden veraltete unerwünschte Vorlagen irrtümlich wieder neu eingebaut, wenn die Altlasten nicht gelöscht würden.
Wir sind kein Software-Projekt, das wie GitHub usw. in eingefrorene Altzustände zurückgedreht werden könnte. Wie eine Seite vor zehn Jahren mal aussah, wird sich am Quelltext einigermaßen erahnen lassen; aber wir sind nicht dafür zuständig, jeden ein Jahrzehnt alten Text originalgetreu zu reproduzieren. Viele Verlinkungen sind auch heute Blaulinks und waren früher Rotlinks oder sind heute Rotlinks und waren früher Blaulinks. Dann dürften auch keinerlei Seiten mehr gelöscht werden, lediglich um die Optik von vor zehn Jahren auf ewig wiederherzustellen.
Auch externe MediaWiki-Ressourcen beeinflussen das Erscheinungsbild. Auch da wird gelöscht, was nicht mehr benötigt wird.
Unser Ziel ist es, die Seiten von heute einfach und robust darzustellen. Was die vor Jahren mal inhaltlich enthielten, welche Zahlenwerte und Namen und Datumsangaben, das kann dem alten Quelltext problemlos entnommen werden. Aber wie die optisch mal ausgesehen hatten und dies originalgetreu zu präsentieren ist keine unserer Aufgaben.
„Für jedes Wiki müssen die „Standard“-Vorlagen entweder selbst neu geschrieben werden oder aus einem anderen Wiki importiert werden. Beides führt mit der Zeit zu Inkonsistenzen zwischen den verschiedenen Wikis.“
Ja, und wenn man nur noch Vorlagen verwenden würde, die die englischsprachige Vorlagen-Weltregierung geschrieben hat und die nur von dieser verändert werden dürfen, nach mehrjähriger Phabricator-Beantragung und Abstimmungsprozess zwischen allen Wikis, dann wäre es diesen Herrschaften auch wieder nicht recht. Aber dann gäbe es auch die beanstandeten Inkonsistenzen nicht, und nur dann.
Die „‚Standard‘-Vorlagen“ haben wir nach anderthalb Jahrzehnten eigentlich alle, und zwar in der Form wie wir sie benötigen. Was wir an „Standard“ nicht haben, brauchen wir in aller Regel nicht und wollen wir auch ganz bewusst nicht haben. Irgendeine neue Navileiste, wenn ein Verein aus der 3. Liga irgendwohin aufsteigt, kann jederzeit spontan ergänzt werden.
Schlussbemerkung zu „Inkonsistenzen“ und „verschiedenen Wikis“ – Das ließe sich ausschließlich dadurch ändern, dass hierfür nur noch die von der Vorlagen-Weltregierung festgelegten Codes verwendet werden, jeder Veränderung zuvor 500 weitere Wikis zugestimmt haben, und zur Vereinheitlichung unsere Autoren ihre seit einem Dutzend Jahren eingeübten Gewohnheiten auf den welteinheitlichen Standard umstellen müssen und unsere inkonsistenten Abweichler-Vorlagen konsequent gelöscht werden.
Zitat: Jeder Volldepp darf jederzeit jede Vorlage unter jedem Namen anlegen und sonstwo einbauen. Es gibt keine Qualitätssicherung, keine Handhabe, keine Ermächtigung für irgendwen dagegen etwas zu tun. Der einzige Weg nach Bitten und Aufforderung ist die Löschdiskussion.
Das Problem sehe ich nicht. Entweder werden die Vorlagen in den jeweiligen Portalen besprochen, oder sie kommen nicht zur Anwendung. Alles was größer ist würde sowieso nicht funktionieren.
Anders ist das mit Vorlagen in commons, da sind die "Volldeppen" die eine Vorlage anlegen meist aber auch die "Volldeppen" die halb Commons nach ihrem Gusto sortieren, weil es überall zu wenige Mitarbeiter gibt und jeder der halbwegs sinnvolle Arbeit leistet einfach tut was er für richtig hält und gewähren lassen wird. --Kersti (Diskussion) 19:18, 26. Mär. 2020 (CET)Beantworten
„Entweder werden die Vorlagen in den jeweiligen Portalen besprochen, oder sie kommen nicht zur Anwendung“
Das ist schlicht falsch.
Es gibt keinerlei Notwendigkeit, dass irgendwas in irgendeinem Portal besprochen würde.
Jeder Autor kann jederzeit jede Vorlage anlegen und hundertfach in Artikel einbauen, ohne dies vorher mit irgendwem zu besprechen oder irgendwie daran gehindert werden zu können. Für einen Großteil der Artikel gibt es auch keine Portale oder Redaktionen, die dafür zuständig wären, geschweige denn personell besetzt und in der Lage wären, irgendwelche internen Entscheidungen durchzusetzen.
Viele und gerade strittige Vorlagen sind überhaupt keinem bestimmten thematischen Gebiet zuzuordnen, sondern projektweit beliebig verwendbar. Hier gibt es keine Instanz, auch die Vorlagenwerkstatt nicht; diese ist völlig machtlos und hätte lediglich das Instrument der Löschdiskussion.
1. Prototyp: Suchfilter für ausgezeichnete Vorlagen
Letzter Kommentar: vor 4 Jahren16 Kommentare13 Personen sind an der Diskussion beteiligt
Hältst du diese beiden Vorschläge für geeignet um zu vereinfachen die passende Vorlage zu finden und würde dies dir deine Arbeit erleichtern? Sollten wir diese Vorschläge weiter verfolgen? Wir freuen uns auf jederlei Feedback. Wenn möglich gebt bitte mit an, ob ihr euch eher als Vorlagennutzer oder Vorlagenerstellen und eher als Neuling oder als erfahrene(n) Wikipedianer*in seht.
Die Teil-Idee „ausgezeichnete Vorlagen“ halte ich für ausgemachten Schwachsinn.
Die Leutchen, die sich sowas irgendwie als ganz nett gewünscht hatten, hatten keine Ahnung von der Komplexität des Vorlagen-Namensraums und der bei jedem Bearbeiter unterschiedlichen Erfordernisse.
Ein „Featured Article“ bezieht sich auf eine besondere inhaltliche Qualität. Was soll eine „Featured Template“ sein? Eine ordnungsgemäß programmierte? Das erwarte ich von allen produktiv eingesetzten, und ist weitgehend für den ANR der Fall (90 % aller Vorlagen).
Wer soll diese Qualität jetzt beurteilen? Wer welcher Vorlage mit welcher Begründung ein Qualitätssiegel erteilen oder verweigern?
Selbst wenn man solch ein Featured-Zeugs einführen würde, käme nicht das heraus, was sich die Wünschenden vorgestellt hatten.
Es gibt keine homogene Autorenschaft, die jeder genau dieselben und damit featured markierbaren Bedürfnisse hätten. Und die featured sind auch nicht diejenigen, die die Benutzer brauchen würden.
Es muss außerdem projektunabhängig global skalierbar sein; also auf 70.000 Vorlagen bei uns und Richtung einer halben Million in der enWP.
Was ich unabhängig von der Wunschliste mal hier aufgeschrieben habe (glaube ich mich zu erinnern), ist aber in der Tat eine verbesserte Suche nach einzufügenden Vorlagen.
Das beträfe alle Formulare im VE und ähnlichen Werkzeugen; womöglich auch per URL-Parameter/REST-API auch in normalen Seiten oder Eingabefeldern nutzbar?
Dabei sollen die Suchvorschläge nach objektivierbaren automatischen Kriterien geordnet werden.
Keine Weiterleitungen vorschlagen; bzw. erst nach allen anderen. Sind oft veraltete unerwünschte Namen; bei FlagIcons hingegen beabsichtigt.
TemplateData vorhanden?
Häufigkeit der projektweiten Einbindungen
Absteigende Folge nach Nicht-TemplateData seltener benutzt
Im Webstorage des Browsers hinterlegte Liste derjenigen Vorlagen, die dieser Browserprofil-Nutzer bereits einmal zum Einfügen ausgewählt hatte, und Priorisierung vor allen anderen Vorschlägen.
Dadurch würden die Bedürfnisse der Suchenden nach Wahrscheinlichkeit besser erfüllt werden, weil das was sehr viele Autoren im Lauf der Jahrzehnte mal eingebaut hatten wahrscheinlich auch von den späteren Autoren häufiger mal benötigt würde. Im Ergebnis käme das heraus, worauf die verschwommene Featured-Idee mal abzielte: Die häufig benötigten würden bevorzugt in der Liste angeboten werden; bloß dass dies ohne ManPower automatisch ermittelt würde.
@TemplateData + Statistik:
Wir haben wohl knapp 60.000 Vorlagen, die im ANR eingesetzt würden und keine Weiterleitungen sind.
Von denen sind wohl mehr als 45.000 parameterlose Bausteine mit aussagekräftigem Namen, vor allem knapp 40.000 Navileisten und irgendwelche Positionskarten und Imagemap und Zeitleisten und sowas. Die würden von TemplateData nicht profitieren, weil der Klartext-Name bereits selbsterklärend ist und es keine Parameter zu erklären gibt und mehr könnte TemplateData auch nicht machen.
Von den verbleibenden mutmaßlich um 13.000 direkt im ANR eingebundenen Vorlagen, die ich Anfang des Jahres mal genauer ermittelt hatte, sind zurzeit etwas über 6.000 bereits mit TemplateData ausgestattet. Stand heute sind das insgesamt über 6.500, aber einige davon sind nicht für den ANR vorgesehen.
Insbesondere sind die häufigsten fast durchgängig schon mit TemplateData ausgestattet, sofern sie nicht obsolet wären oder einen ungeeigneten Namen hätten, oder einer Komplettsanierung bedürften, oder von Fachportalen und Redaktionen betreut würden.
Heißt: Das featured gibt es schon längst, heißt bloß anders: TemplateData.
Ein allgemeines Feature, das dann aber auf Ebene von OOjs-UI allgemein zu realisieren wäre, würde das einfachere Eingeben in Formularfelder betreffen.
Es geht um das Unix-Feature des Autovervollständigen mittels Tab.
Prinzip: Gibt es in einer angebotenen Auswahl zu bisher eingetippten Buchstaben nur solche, die alle bis zu einem bestimmten Punkt übereinstimmen, dann werden durch Tab alle derartigen Zeichen der Auswahl in das Eingabefeld übernommen, und mit dem nächsten eingetippten Zeichen, wodurch sich die Auswahl unterscheidet, hat man vielleicht auch schon den einzigen und gewünschten Treffer.
Wir tippen ein: n und erhalten allerlei Treffer, auch Nicht archivieren und NowCommons
Wir tippen ein: a und erhalten Treffer mit Na, vielleicht auch was mit „Name“ und „National“.
Wir tippen ein: v und erhalten nur noch Treffer mit „Navigationsleiste“.
Jetzt drücken wir Tab und im Eingabefeld steht Navigationsleiste (mit einem Leerzeichen endend, weil das war auch allen Treffern gemein gewesen).
Jetzt tippen wir den ersten Buchstaben des Namen unserer gesuchten Navileiste, also b, und das Tab-Spiel kann dann später wiederholt werden.
Zu meinem obigen Vorschlag „Webstorage“:
Das ist natürlich genau das personalisierte Gedächtnis, das nicht eine einheitliche Prioritätenliste für alle Autoren aller Fachgebiete festlegt, sondern genau die Bedürfnisse dieses Bearbeiters abdeckt.
Wenn es im persönlichen Webstorage Vorlagen gibt, die die momentan eingetippten Buchstaben treffen, dann werden diese Vorlagen zuoberst in der Trefferliste dargestellt. Sollte sich das in der sonstigen Trefferliste wiederholen, sollen sie natürlich nicht doppelt auftreten. Es kann sein dass die Gesamtlänge der Vorschlagsliste (wohl 10 oder 20) bereits nur aus dem Webstorage abgedeckt ist; dann ist natürlich entsprechend zu kürzen.
Featured Template wär vielleicht ein Weg, wenn die offene Frage ist, was die Community eigentlich als best practice ansieht und in welche Richtung man weiter vorgehen soll, macht aber die Arbeit mit Vorlagen tatsächlich um nichts besser, und in meinen Augen ist die genannte Frage an dieser Stelle nicht die richtige. Und, bitte nicht bös sein, aber um Wikipedia:Kandidaten für exzellente Vorlagen einzuführen brauchen wir kein WMDE-Entwicklerteam sondern eine daran interessierte Community. … «« Man77 »»Alle Angaben ohne Gewehr.18:26, 26. Mär. 2020 (CET)Beantworten
(BK) Ich vermute, hier wurden zwei Dinge vermischt. Das was im Namensraum Vorlage zur Verfügung steht und sowas wie Formatvorlagen, die ein Grundgerüst für Artikel darstellen. Siehe z.B.: Wikipedia:Formatvorlage Biografie#Kopiervorlage. Aber bei beiden ergibt sich die das zu verwendende Ziel automatisch aus der Problemstellung. Wenn ich was über eine Person schreiben will, dann kann ich schwer mit Wikipedia:Formatvorlage_Film/Kopiervorlage anfangen. Genauso wenn ich einen Link auf die Internet Movie Database setzen will, dann ist die Vorlage:IMDb das Mittel der Wahl und eben nicht Vorlage:Internetquelle. Trotzdem könnten Kopiervorlagen für Artikel ausgezeichnet werden, um einen Anreiz zur Erstellung solcher zu schaffen. Für irgendeine Priorisierung der Vorschlage bei der Auswahl erscheint mir allerdings recht sinnfrei. --Wurgl (Diskussion) 18:33, 26. Mär. 2020 (CET)Beantworten
Ich halte die „ausgezeichneten Vorlagen“ in der hier vorgeschlagenen Form ebenfalls für nicht sinnvoll. Redundante Vorlagen sind so oder so nicht erwünscht und werden meist beizeiten zusammengeführt. Und dass dieses System zu signifikant besserer Auffindbarkeit führt, denke ich auch nicht, zudem müsste dazu ein begleitender Prozess der Auswahl etc. stattfinden, für den sich nach meiner Einschätzung allerhöchstens die zehn vorlagenaffinen Benutzer interessieren würden. Suchfilter hingegen finde ich in Ordnung, wenn sie gut gemacht sind, gerne auch als Spezialseite, denn ich beispielsweise nutze keine der Vorlagentools in den Editoren, suche mich aber dennoch häufiger mal im Vorlagennamensraum kaputt, gerade bei eher für die interne Nutzung bestimmten Vorlagen. Gruß, -- hgzh18:47, 26. Mär. 2020 (CET)Beantworten
Ich komme primär von Wikivoyage. Ich glaube, ich habe meine Idee woanders schon mal aufgeschrieben. Ich sehe das "Featured" eher als wichtig und häufig benutzt - Favoriten halt. Meine Idee wäre folgende.
Unabhängig von diesem Tool könnte der VE einen weiteren Menüpunkt "Einfügen" (mit irgendeinem einmaligen Namen)
Jedes Wiki kann sich dorthin eine Liste von Vorlagen mit einem Aliasnamen (wichtig) für die Vorlage reinparametrieren (z.B. über eine Mediawiki-Seite). Halt die Vorlagen die man immer braucht. Legt dann die Community fest. Ebenso die Standard-/optionalen Paremeter.
Vorteil: Ein Neuling/Nichtwiki-Nerd muss nicht mal wissen, dass es Vorlagen gibt, und wie man die benutzt, geschweige, denn wie sie heißt. Bei uns ist es z.B. die Vorlage VCard und die ist schon recht komplex. Wenn dort aber im VE-Menü ein Punkt "Hinzufügen" > "Museum" zufinden ist, sollte jeder damit jeder (auch Neuling) klarkommen. Dann muss man auch keine Vorlage suchen/kennen. Momentan weiß man ja nicht mal, welchen Suchbegriff man nehmen muss um eine zu finden, wenn sie keinen super passenden Namen hat, manche sind im schlimmsten Fall noch Anglizismen.
Das wäre sinnvoll für die Vorlagen, die Autoren auch immer (zwingend) benutzen sollten, nicht nur teilweise oft benötigen.
Die Fragestellung zielte auf: „Übersicht und Auffindbarkeit von Vorlagen“ (im Vorlagen-Namensraum) zu verbessern.
Dabei war die Vorstellung der Antwortenden gewesen, dass jeder andere Autor dieselben Vorlagen am meisten verwenden würde wie man selbst, und wenn jetzt die Vorlagen, die mich persönlich besonders interessieren würde ich als Suchvorschläge diejenigen bevorzugt bekommen, die mich persönlich interessieren. Nur wird jeder andere seine eigenen Interessengebiete als ganz doll wichtig markieren, und nachdem dieser personell nicht unterlegte Exzellenz-Wettbewerb (den einige häufig eingebundene Vorlagen nicht bestehen würden) nach Jahren mit 10.000 exzellent empfohlenen Vorlagen unter riesigem Ressourcenverbrauch und endlosen Diskussionen abgeschlossen wäre, hätte man genau die gleichen Treffer wie zuvor, und bekäme wieder lauter andere Vorlagen fremder Arbeitsgebiete vorgeschlagen wie heute auch. Über 90 % der im ANR eingebundenen Vorlagen sind themenspezifisch; heißt, auch nach dem irre aufwändigen Prozess wären neun von zehn exzellent featured mir angebotenen Vorlagen immer ncoh solche, die mich nicht die Bohne interessieren, genau wie heute. Das kann man auch simpler haben.
Es muss bei uns mit 70.000 Vorlagen funktionieren und in der enWP mit bald einer halben Million Seiten. Wie das in einem Wiki mit 1000 Vorlagen featured wäre würde nicht den Entwicklungsaufwand rechtfertigen.
Welche Vorlage braucht "man" immer - das ist doch für das Biologie-Portal anders als wenn es um autobahnen geht und kann eigentlich nur themenspezifisch festgelegt werden. --Kersti (Diskussion) 19:12, 26. Mär. 2020 (CET)Beantworten
Es gibt in Schwesterprojekten schon Vorlagen die man immer braucht. Dazu zähle ich z.B. auch Commons. Es ist ja auch als Ergänzung zum Besser-Auffindbarkeits-Tool gedacht. Wegen mir die Idee gerne auch in einem extra Abschnitt. -- DerFussi19:25, 26. Mär. 2020 (CET)Beantworten
PS: Ich sehe bei der ganzen Thematik auch die Unerfahrenen und Neulinge als Zielgruppe. Ich bin Nerd, ich benutze weder den VE noch ein künftiges Auffindbarkeits-Tool. Ich schmiere die Vorlage im normalen Editor einfach so hin. Ich würde es aber gerne Autoren, die gerne würden, aber nicht so leicht klarkommen, leichter machen. und nicht zuletzt muss man auch an die mobile Webseite denken und nicht nur an Nerds, die daheim an ihren großen Bildschirmen hocken. Da ist so eineinfach zu bedienendes Werkzeug schon praktisch. Die Seite heißt ja auch "Leichter mit Vorlagen arbeiten". Und wir sollten nicht nur was für "uns" sondern auch mal was für "die" (die noch nict da sind) basteln. -- DerFussi19:36, 26. Mär. 2020 (CET)Beantworten
Ich teile die geäußerten Zweifel an der Sinnhaftigkeit „exzellenter“ Vorlagen. Am wichtigsten scheint mir die Häufigkeit der projektweiten (namensraumspezifischen) Einbindungen als Filterkriterium zu sein. Eine Untergliederung nach reinen Textbausteinen (parameterlos) und komplexeren Vorlagen oder nach einer kleinen Anzahl von Grundkategorien (zB Infoboxen, Navigationsleisten, Tabellenvorlagen, Zitiervorlagen, Linkvorlagen, sonstige Textvorlagen …) wäre sicher auch praktisch bei der Suche und Auswahl (Vorlagen sind ja auch heute schon kategorisiert, daraus sollte sich eigentlich auch etwas machen lassen). TemplateData schön und gut, aber solange die Entwickler keine Anstalten machen, die vielen schon jahrelang bekannten Unzulänglichkeiten des Instruments anzupacken, ist es schlicht nicht möglich, alle Vorlagen, die davon profitieren würden, auch damit auszurüsten. Gruß–XanonymusX (Diskussion) 20:27, 26. Mär. 2020 (CET)Beantworten
Ich wünschte mir die Möglichkeit, aus der Vielzahl an Vorlagen eine personalisierte "Trefferliste" solcher erstellen zu können, die ich meistens benötige und die mir anschliessend per Filter zur Verfügung stehen könnten. --Huberbe (Diskussion) 22:26, 26. Mär. 2020 (CET)Beantworten
Ich schließe mich Huberbe an: Einen Suchfilter für Vorlagen könnte ich gut gebrauchen. Am wichtigsten wäre mir hier aber, die Vorlagen, die ich oft nutze, schnell zur Hand zu haben. Könnte mir vorstellen, dass das auch für Neulinge praktisch ist, um sich nicht im Vorlagen-Dschungel zu verlieren. Nach „exzellenten Vorlagen“ würde ich persönlich eher nicht suchen. Eher nach üblichen oder beliebten oder den meistbenutzten Vorlagen.--Kaethe17 (Diskussion) 22:53, 26. Mär. 2020 (CET)Beantworten
Ich halte beide Grundideen für sinnvoll: Sowohl eine kategorische/ausgebaute Filterung/Suche, als auch "featured templates". Nur usability-technisch sollte das ganze ausgebaut werden: es muss einen Schnellzugriff auf die meist-verwendeten Artikel geben (evt. in dem Kontext des Artikels). Allgemein ist dazu wohl eine "Personalisierung" der "zuletzt/meist verwendeten Vorlagen" sinnvoll. Wobei dies, z.B. bei wenigen vorhandenen Daten, durchaus damit gemischt werden sollte, welche Vorlagern allgemein "beliebt" bzw. evt. "in dem Artikel bereits verwendet" oder "in dem Kontext passend" sind. Welche genau das sind und wie die Mischung/Zusamenstellung dieser doch sehr unterschiedlichen "Featured template"-Datenquellen dann genau funktioniert, das ist sicherlich dann der schwierige Teil des Projektes.
Das Ziel sollte sein, ganz oben die "relevanteste" Vorlage anzuzeigen, die man als selbst direkt auswählen wollte. Die Software muss so gut wie möglich voraus denken – natürlich ohne die Möglichkeit zu nehmen, manuell möglichst gut eine neue Vorlage zu finden, die man noch nie gefunden hat. Und zwar mit möglichst wenig Klicks, d.h. am Besten gleich als Dropdown im Visual Editor (für kleine Vorlagen wie Vorlage:Datum zB. (Alleine der extra Klick um "alle Vorlagen" zu durchsuchen ist umständlich, das ganze muss ein Fenster sein.) Ich denke bei dem Prototyp liegt auf diesem Usability-Aspekt des "Liefere mir das beste Ergebnis möglichst schnell" noch zu wenig der Fokus. --rugk (Diskussion) 22:53, 26. Mär. 2020 (CET)Beantworten
Angefragtes Intro: ich nutze sehr häufig Infoboxen, editiere sie gelegentlich und selten erstelle ich auch mal selber eine.
Die Suche sollte sich sich selbst anbieten, solange man dies Feature nicht deaktiviert hat (es kann sein, dass das beim Visual Editor schon funktioniert, doch den nutze ich nicht, da mir dessen Bedienung zu mühsam ist). Dabei bedeutet sich selbst anbieten eine dezent erscheinende Vorschlagsliste von Infoboxen, die eine Nähe zum editierten oder direkt verlinkten Lemmata aufweisen. Als Beispiel erscheinen bei 'Ministerpräsident' z.B. die Infoboxen Person, Politik, Partei, Staat, Geschichte o.ä., die man direkt in den Fließtext einbauen oder zumindest für die verlinkten Seiten zur Kenntnis nehmen kann. Es mag oft vorkommen, dass man gar nicht nach einem Template sucht, was dennoch gerade nützlich wäre.
Bei der Autovervollständigung hoffe ich auf den Wiki-Suchstandard, bei dem auch alle Einträge erscheinen, die erst in späteren Wörtern treffen.
Die Wertung als 'ausgezeichnete Templates' erscheint mir ziemlich aufwändig, um letztlich ohne wirkliche Sichtbarkeit zu bleiben. Damit meine ich weniger die Bereitstellung der Bewertbarkeit, als die Bewertung selber.
Mir scheint eine Bewertung für nicht sehr sinnvoll, da häufig Vorlagen für eine gewisse Funktion geschrieben wurden, für die sie in der Regel eine starke Vereinfachung darstellen sollte. Ob nun eine Vorlage eine starke oder nur "halbstarke" Vereinfachung darstellt, ist da glaub ich irrelevant. Eine Wertung zu welchem Themengebiet die Vorlage gehört scheint dagegen passender. Habitator terrae16:49, 15. Jul. 2020 (CEST)Beantworten
Anleitung für das Vorlagen erstellen
Letzter Kommentar: vor 4 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Was ich mir unter mit vorlagen arbeiten vorgestellt habe, war daß ich irgendwo mal erfahre, was ich eigentlich machen muß, um die Namen einer Tierart aus aus Wikidata in eine Vorlage zu bekommen die wie Vorlage VN aussieht, ohne gleich die Interwikis mit audzurufen. Wo findet man diese Information, wie man so eine Vorlage erstellt? --Kersti (Diskussion) 19:08, 26. Mär. 2020 (CET)Beantworten
Letzter Kommentar: vor 4 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
In Wikisource gibt es eine Reihe von Vorlagen für die Verlinkung von Literatur. In Wikipedia gibt es die teilweise auch (z.B. Vorlage IA), aber bei der Seitenverlinkung funktioniert die Vorlage anders. Es wäre sehr hilfreich, wenn die Vorlagen aus Wikisource 1:1 auch in Wikipedia funktionieren würden. --Zieglhar (Diskussion) 12:11, 27. Mär. 2020 (CET)Beantworten
Vorlage BibISSN
Letzter Kommentar: vor 4 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Bei Referenzen auf Zeitschriftenartikel wäre es hilfreich, wenn analog BibISBN ein BibISSN hätte. Damit könnte man ohne großen Schreibaufwand die korrekten (teilweise umfangreichen) Zeitschriftentitel einmal eingeben und den Baustein dann einfach und schnell einsetzen. --Zieglhar (Diskussion) 12:44, 27. Mär. 2020 (CET)Beantworten
javascript-Schnipsel
Letzter Kommentar: vor 4 Jahren4 Kommentare4 Personen sind an der Diskussion beteiligt
Javascript-Snipplet bei fzW Sowas könnte man für etliche Vorlagen machen, die irgendwie eine ID und einfach zu identifizierenden/extrahierenden Text aus einer Webseite enthalten. So ziemlich alle Links auf Sportlerseiten, IMDB, etc. etc.
Die Luxusvariante wäre ja: Man wirft einen Link in ein Fensterchen ein, eine schlaue Software guckt sich die Domain/den Host an und gibt dann ganz wenige Vorlagen zur Auswahl. Ich wähle eine Vorlage aus, die immer noch schlaue Software pickt sich aus der URL oder aus dem Metadaten der Seite ein paar Infos raus und füllt die in die Felder. Als User brauch dann kaum was von Vorlagen wissen, ich brauch nur wissen, dass es da ein Fensterchen gibt, wo ich einen externen Link einwerfe. --17:17, 27. Mär. 2020 (CET) (unvollständig signierter Beitrag vonWurgl (Diskussion | Beiträge) )
Die gesamte javascript-Schnipsel-Technologie wird aus Sicherheitsgründen von vielen Browsern unterbunden, weil sie leicht zum Transport von Schadsoftware verwendet werden kann.
Und die Vorstellung, solche Bastelarbeiten für etliche Vorlagen einzurichten und pflegen zu wollen ist schaurig.
Das Projekt bietet eigentlich aus Sicherheitsgründen keinen von irgendwem irgendwohin geschriebenen JavaScript-Code an. Auf die Bookmarklet-Seite habe ich ein Auge, die paar die dort stehen sind harmlos. Alles andere läuft nur über Benutzerskripte und muss von demjenigen Benutzer verantwortet und gepflegt werden, dessen Nick zwischen Doppelpunkt und Schrägstrich steht. Kapazitäten, um sowas für irgendwelche Webseiten zu programmieren und sicherheitstechnisch zu überwachen und obendrein zu pflegen gibt es nicht.
Im Übrigen macht Citoid genau sowas für jede beliebige URL.
Das Problem ist doch: Es gibt 60.000 Vorlagen (oder sind es gar 70.000?) und der Benutzer soll eine auswählen. Wald und Bäume sag ich da. Der Benutzer hat eine Url wo irgendwas schlaues steht. Und so manche URL kann man recht eindeutig einer Vorlage zuordnen: https://www.weltfussball.de/ → Vorlage:Weltfussball, https://www.imdb.com/ → Vorlage:IMDb, https://de.findagrave.com → Vorlage:Findagrave usw. Wenn die Community zu den einzelnen Vorlagen die typischen URLs dazupackt (in welcher Form auch immer, templatedata erweitern oder sowas zum Beispiel), dann kann schlaue Software aus einer URL einen Vorschlag für eine Vorlage machen. Und als zweiten Schritt mit so einem Javascript-Schnippsel die Vorlage auch ausfüllen. Das sollte wohl sowohl beim Quelltexteditor als auch beim VE gehen.
Zum Einwand von PC: Man kann ja auch Regular Expressions von der Community zu den Webseiten erstellen, oder irgendeine andere Art der Beschreibung welche Daten-Schnippsel in welches Feld gehören und den Code der das abarbeitet in die WP-Software packen. --Wurgl (Diskussion) 17:44, 27. Mär. 2020 (CET)Beantworten
Und als Ergänzung: Egal, was man in dieses ich nenne es mal "Suchfeld" einwirft, sollte eine intelligente Suche zu einer passenden Vorlage führen und die maximal mögliche Anzahl an Parametern mit Vorschlagswerten befüllen. Das sollte für eine URL möglich sein wie von Wurgl gerade beschrieben, aber auch beispielsweise für einen DOI oder eine PMID (das macht PMID2reference schon lange). Genauso vorstellbar ist das für eine ISBN, eine OCLC, arXiv usw. usw. --Mabschaaf19:55, 27. Mär. 2020 (CET)Beantworten
Karten
Letzter Kommentar: vor 4 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Mein Vorschlag für die Integration von Vorlagen in den VisualEditor
Letzter Kommentar: vor 4 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Hier ist ein Vorschlag von mir, wie das Vorlagenmenü im VisualEditor in Zukunft vielleicht funktionieren könnte. Dieser stellt nur meine Meinung dar. Ob etwas davon umgesetzt wird, darf das Team Technische Wünsche selbst entscheiden.
Zunächst könnte man noch einmal über die Platzierung dieser so wichtigen Funktion nachdenken. Im VE für Mobiltelefone ist sie nur durch die Eingabe von {{ auf der Tastatur zu erreichen, auf dem Computer sind zwei Klicks erforderlich, obwohl die Funktion bestimmt nicht weniger wichtig als „Link“ oder „Belegen“ ist. Sie könnte also aus dem Einfügen-Menü herausgenommen und in die Toolbar integriert werden. Darum soll es in meinem Beitrag aber nicht weiter gehen.
Es wurde ein Prototyp mit dem Namen „Suchfilter für ausgezeichnete Vorlagen“ vorgestellt, der IMHO jedoch einen falschen Ansatz hat. Die Auszeichnung von besonders gut gemachten Vorlagen hilft Neuautoren nicht gerade dabei weiter die richtige Vorlage zu finden. Es gibt für jeden Zweck nur eine Vorlage. Diese zu verbessern wird nie Neuerstellungen von Vorlagen unnötig machen, weil jede Vorlage nur einen Zweck hat. Das Menü sollte vielmehr hierarchisch geordnert werden. So könnte das neue Fenster aussehen:
Beim ersten Starten wird durch ein Tutorial mit „Sprechblasen“ erklärt, was Vorlagen sind und welche Kategorien es gibt. Eventuell ist aber auch die Aufteilung in andere Kategorien als oben angegeben sinvoll. Mit der Schaltfläche kann das Tutorial erneut angezeigt werden.
Die Sortierung hierbei kann wie bei den Kategorien erfolgen, darf jedoch nicht automatisch aus dem Kategoriennamensraum übertagen werden, weil ansonsten durch Vandalismus irgendwelche Seiten in diese Liste gelangen könnten.
Die Wartungsbausteine könnten wiederum in einer Liste stehen, die so wie das Menü zum Hinzufügen von Parametern aussieht: Es werden jeweils Name und eine Kurzbeschreibung angezeigt.
Nun sehen wir uns mal genauer an, was angezeigt wird, wenn wir die Vorlage „Infobox Fußballspieler“ einfügen. Hierzu bitte die Spielwiese mit dem VE öffnen, unter „Einfügen“ „Vorlage“ wählen und die Vorlage „Infobox Fußballspiler“ auswählen.
Hier fällt uns auf, dass bei einigen Feldern die wohl funktionslosen Klammern [[]] erscheinen. Der Tooltip dazu lautet „Zurück zu einfachem Wikitext“ und die einzige nutzlose Funktion ist die Lesbarkeit durch eine fast-graue Hintergrundfarbe zu veringern und den Text in einer Monospace-Schriftart darzustellen. Ich rate die Entfernung dieser Funktion an, da sie für Nicht-Wikitech-Leute keinen Nutzen zeigt.
Das zweite und das dritte Feld haben die Bezeichnungnen „Bildname“ und „Bildunterschrift“. Diese Parameter und „Bildbreite“ sollten zu einem einigen Element zusammengefasst werden. Wie das aussieht, ist weiter unten zu sehen. Beim Klick auf einen der Buttons öfnnet sich das bekannte Fenster zum Einfügen und Bearbeiten von Bildern. Alle von der Vorlage nicht unterstützten Parameter sind ausgeraut. Beim Klick auf den Mülleimer werden alle Bildparameter wieder geleert.
Später kommt der Parameter „Jugendvereinsstationen“. Der Parameter kann so aktuell nicht wirklick visuell befüllt werden. Für die Verwendung durch Personen, die sich nicht mit dem Quelltext auskennen, ist das Ausfüllen davon nicht möglich.
Mein Vorschlag wäre für solche Parameter eine Darstellung in Tabellenform zu wählen. Mit dem Icon in der Spalte links können die Elemente nach oben und unten verschoben werden (Drag&Drop), der Mülleimer löscht einen Eintrag und mit dem Button darunnter kann eine neue Zeile hinzugefügt werden. Die „Überschrift“ der letzten Spalte öffnet eine Sprechblase mit dem bereits bekannten Parameter-hinzufügen-Menü. Der Inhalt aller Zellen, bei denen es sinvoll ist, ist bearbeitbar. Über jeder solchen Tabelle sollte auch eine Toolbar für Formatierungen gesetzt werden (Im Beispiel nicht zu sehen). Wenn ein Feld ohne Formatierungsmöglichkeit ausgewählt ist, wird die Toolbar nicht ausgegraut.
Zudem schlage ich einen neuen Feldtyp mit einer Checkbox für Wahrheitswerte vor (Siehe Beispiel „Zurzeit aktiv“)
Abschließend empfehle ich noch eine Dropdown-Liste, in der aus mehreren Werten ausgewählt werden kann.
Die Werte für die verschiedenen Einstellungen sollten zudem frei festlegbar sein. Somit soll es möglich sein, für eine nicht ausgewählte Checkbox wahlweise „Nein“, „0“, „“ oder einen ganz anderen Text als Wert einzusetzen, für eine ausgewählte ginge dann zum Beispiel „Ja“ oder „1“. Bei Drop-Down-Listen kann es zudem notwendig sein, die Abkürzung für die Auswahl an den Parameter zu übergeben. Beispielsweise lautet bei männlichen Personen der einzutragende Wert „m“, bei weiblichen „w“ und bei solchen mit einem Geschlecht aus dem Sammelsurium der „diversen“ Geschlechter „d“.
Nun zum Aussehen der vorgeschlagenen Parametertypen:
Zusätzlich soll aber noch vor jedem Parameter, der Formatierungen zulässt, eine Werkzeugleiste eingefügt werden und die Parameter sollen auch wie in einem WYSIWYG-Editor anezeigt werden.
Bei den neuen Parametertypen, die im Beispielkasten vorgestellt werden, kann die Funktion „Zurück zu einfachem Wikitext“ anders als anfangs erwähnt in speziellen Fällen auch nützlich sein. Sollte die Funktion zurückgestellt werden, obwohl der Wert nicht zu den Standardwerten gehört, muss davor gewarnt werden, dass der Wert dadurch verlorengeht.
Zudem sollte eine Funktion für die Vorlagenersetzung hinzugefügt werden, zum Beispiel mit der im obigen Beispiel gezeigten Checkbox
Für die neuen Parameter ist auch eine neue TemplateData-Version erforderlich, die die folgenden Eingabefelder besitzen könnte:
String: Parametername (im Wikitext)
String: Parametername (für die Anzeige)
String: Parameterbeschreibung
String: Standardwert
Boolean: Autowert (Fügt den eingegebenen Wert automaisch ein, wenn das dazugehörige Feld leergelassen wird)
Boolean: Prefill (Der Wert wird beim Einfügen in den Vorlagendialog eingesetzt, jedoch im Gegensatz zu Autowert nicht beim späteren Bearbeiten der Vorlage, sondern nur beim erstmaligen Einfügen und beim Öffnen, nicht beim Schließen des Dialogs. Das Feld kann also leer gespeichert werden)
Auswahl aus Liste: Typ
Bild (Siehe oben)
String: Parameter für die Bildbeschreibung
String: Parameter für die Bildgröße
String: Parameter für den Alternativtext
Unformatierter Text (Verwendet den alten Editor, Text soll nicht formatiert werden)
Formatierter Text (Ermöglich Formatierungen mit einem WYSIWYG-Editor)
Seitentitel (Seiten können wie beim Einfügen eines Links aus einem Drop-Down-Menü gewählt werden)
Boolean: Nur vorhandene Seiten (Gibt eine Fehlermeldung aus, wenn die Seite nicht existiert)
String: Präfix (Textteil, der von der Vorlage jeder Eingabe vorrangestellt wird. Kann ein Namensraumpräfix sein. Im Falle der Babelvorlage wäre das „User “, in den Quelltext wird beispielsweise „de“ (Deutsch als Muttersprache, Vorlage:User de) oder „:Miiich/Babel/Vorlage:Kommaregeln“ (Vorlage User :Miiich/Babel/Vorlage:Kommaregeln) geschrieben.)
String: Suffix (Wie Präfix, wird aber hinten angehängt)
Vorlage (Funktioniert wie „Bild“, dient aber zur Verwendung von Vorlagen und nicht zur Verwendung von Bildern, die Vorlage wird immer mit geschweiften Klammern eingefügt, ohne Klammern funktioniert es nicht richig!)
Mehrere aufeinanderfolgende Vorlagen (In Tabellenformat, wie oben dargestellt)
String: Vorlage, die über eine TemplateData-Dokumentation im neuen Format verfügt, aber selbst keinen Parameter vom Typ „Mehrere aufeinanderfolgende Vorlagen“ besitzt (Die Vorlage, die mehrmals aufeinanderfolgen soll)
Boolean (Kästchen, siehe oben)
String: Wert bei „falsch“ (wird in den Quelltext geschrieben)
String: Wert bei „wahr“ (wird in den Quelltext geschrieben)
Dropdown
Array: Werte
Sting: Bezeichner (Wird in der Drop-Down-Liste zur Auswahl angeboten)
Sting: Quelltext (Wird in den Artikel eingefügt)
Ganzzahl: Notwendigkeit
0 (Normal, wird nicht standardmäßig angezeigt)
1 (Empfohlen, wird standardmäßig angezeigt)
2 (Dringend empfohlen, steht ganz oben, kann nicht gelöscht werden)
3 (Erforderlich, beim Weglassen sieht die Seite dennoch richtig aus)
4 (Dringend erforderlich, die Vorlage kann nur mit dem Parameter richtig dargestellt werden oder produziert eine Fehlermeldung)
7 (Parameter im VE nicht anzeigen)
8 (Legacy, für veraltete Parameter)
String: Hinweis für Legacy
Ganzzahl: Parameter in den Quelltext einfügen…
0 (Unset, immer wenn der Parameter im VE angezeigt wird, kommt er auch in den Quelltext - selber Müll wie früher)
1 (Nur mit Wert einfügen, vor Allem für Parameter mit Standardwert, die wenn sie vorhanden sind einen leeren Wert haben, sodass Textteile aus Vorlagen verschwinden oder diese unbrachbar werden. Beispielsweise fehlte früher in der Vorlage {{Belege fehlen}} der Text „Dieser Artikel oder Abschnitt“, wenn sie mit dem VE eingefügt wurde)
2 (Parameter immer einfügen, beispielsweise bei Infoboxen)
Liste: Group (Andere Parameter der Dringlichkeit 7, die als Unterparameter dieses Parameters dienen sollen, wenn dieser Parameter keine Entsprechung im Quelltext hat, hat er kein Eingabefeld, so können zusammengehörige Parameter immer zusammen angezeigt werden)
Sting: Beschränkung (Ein Regex oder ein Text aus den folgenden, wenn der Wert unten nicht definiert ist, wird er als Regex behandelt)
e-mail (E-Mail-Adressen)
number (Zahlen)
web (Webadresse)
uri/url
Sring: Beschreibung der Beschränkung (Für die Fehlermeldung, die erscheint, wenn die Beschränkung nicht eingehalten wurde, da eine Standardmeldung nur den Regex enthält, der für viele nichtssagend ist)
Des Weiteren sollte für die gesamte Vorlage zwingend festgelegt werden, ob sie gesubstet werden muss.
Genug schwer verständliche, schwer umsetzbare, sehr lange und sehr ausführliche Ideen
Letzter Kommentar: vor 4 Jahren7 Kommentare3 Personen sind an der Diskussion beteiligt
Ich habe kein Problem, passende Vorlagen zu finden. Wenn ich ein brauche, schaue ich in einen passenden Artikel und schaue, wie die verwendeten Vorlagen dort heissen. Dann lese ich mir die Dokumentation zur Vorlage durch. Das Ausfüllen von Infoboxen im Visual Editor ist auch einfach. Mein Hauptproblem damit: Wenn man mit dem Visual Editor eine Vorlage bearbeitet, erzeugt dies automatisch beim Speichern eine Leerzeile über der Infobox, der Artikel ist danach verschoben. Zweites Problem: Ich präferiere Direktlinks in Vorlagen anstelle von verwendeten Weiterleitungen. Es gibt aber BenutzerInnen, welche keine Änderungen an Vorlagen zulassen. --Gereon K. (Diskussion) 18:38, 23. Apr. 2020 (CEST)Beantworten
@Cirdan: Das passiert bei allen Infobox Asteroid. Sobald man die im Visual Editor bearbeitet, hat man nach dem Speichern eine Leerzeile über der Infobox, die den Artikel nicht oben am Bildschirm anfangen lässt. --Gereon K. (Diskussion) 14:07, 9. Mai 2020 (CEST)Beantworten
Die Leerzeile am Artikelanfang vor der Infobox ist nicht schön, sie hat aber keine Auswirkung. Wenn allerdings ein HTML-Kommentar oder so etwas davor steht, dann wirkt diese Leerzeile. --Wurgl (Diskussion) 17:54, 9. Mai 2020 (CEST)Beantworten
Habe es gerade noch einmal ausprobiert. Die Leerzeile im Artikelstart wird weiterhin erzeugt, es ist aber nach Speichern in der Artikelansicht nicht mehr sichtbar, das wurde also tatsächlich gefixt. --Gereon K. (Diskussion) 20:15, 9. Mai 2020 (CEST)Beantworten
Vorlagen-Unterseiten und Seiteneinbindungen
Letzter Kommentar: vor 4 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Zwei Hinweise zu Vorlagenproblemen im VisualEditor:
Die meisten Vorlagen haben irgendwelche (standardisierten) Unterseiten. Im Auswahlfenster des VE-Vorlageneditors bekommt man diese regelmäßig zur Auswahl, obwohl es sich überwiegend nicht um Vorlagen, sondern um Dokumentations-, Wartungs- oder Testseiten handelt, die für Autoren im ANR uninteressant sind und schon gar nicht eingebunden werden dürfen. Offenbar werden, wie neulich festgestellt, Unterseiten mit „/Doku“ automatisch aus der Auswahl ausgeschlossen; dann müsste es auch möglich sein, eine Reihe weiterer typischer Unterseiten auszublenden.
Dazu noch ein Hinweis auf phab:T241933: Seiteneinbindungen werden wie Vorlageneinbindungen behandelt, was sehr irreführend sein kann. Das Identifizieren einer tatsächlichen Vorlage müsste einfach besser funktionieren.
Feedback: ich nutze die Syntaxhervorhebung im normalen Editor sehr gern und gerade bei der Bearbeitung komplexer Vorlagen finde ich sie hilfreich. Schön, dass ihr da weiter verbessern wollt.
2a: bitte die Standard-Hintergrundhervorhebung nicht deaktivieren, ich finde damit (inkl. der dunkleren Farbe bei mehreren Verschachtelungsebenen) relativ einfach nicht geschlossene Verschachtelungen, also wo noch schließende Klammern fehlen etc.
2b: wäre in Ordnung. Ließe sich vielleicht als Alternative zu 2a ausbauen, indem die Klammern, die die aktuelle Verschachtelung begrenzen, immer markiert werden (also anstatt Hintergrundhervorhebung Klammerhervorhebung, dann könnten auch die normalen Hintergründe bestehen bleiben.
2c: brauche ich persönlich nicht, weil das nicht in meinen jahrelang konditionierten Arbeitsmodus in Quelltexten passt. Gern optional zuschaltbar für diejenigen, die es nutzen wollen, dann aber bitte so wie im CodeMirror, der mit anschließend manuell eingetippten schließenden Klammern klar kommt.
2d: sehr gern, das sorgt immer wieder für Verwirrung und kann, wenn es gut gemacht ist, sicher helfen.
2e: bin zwar nicht betroffen, aber ein starker Befürworter barrierefreier Oberflächen, also nur zu (solang der Hochkontrastmodus kein Standard wird ;)).
Wenn ich mich entscheiden müsste, dann entweder 2b oder 2d, schön wäre außerdem die beschriebene „Erweiterung“ von 2b um 2a. Gruß, -- hgzh19:02, 28. Apr. 2020 (CEST)Beantworten
Insgesamt wünsche ich mir mehr, dass die Vorlagen besser mit dem VisualEditor (WP:VE, H:VE) zusammenarbeiten könnten. Auf der anderen Site habe ich mir den (-; mit dem Klammerbeutel gepuderten ;-) Code auch schon angesehen und mir dabei gewünscht, dass es da doch mehr visuelle Unterscheidung gäbe.
Wie würden sich die Änderungen auf meine Arbeit mit Vorlagen auswirken?
Vielleicht positiv. Ich halte die „Sprache H:VP“ (hat sie eigentlich einen Namen?) gerade aufgrund ihrer Einfachheit für schwierig, z. B. durch das Fehlen von echten Variablen und Funktionen (siehe auch #Probleme mit der Syntax, #Unzureichende Entwicklerwerkzeuge). Nichtsdestotrotz wird sie bis auf Weiteres eine bedeutende Rolle spielen.
Insofern wäre es gut, wenn Vorlagen-Programm-Syntax besser handhabbar wäre.
Ich habe ein wenig Bedenken, dass die verbesserte Syntax-Hervorhebung die eine oder den anderen dazu einlädt, noch komplexere Vorlagen – nicht mehr vierzig, sondern lieber fünfzig Parameter – anzufertigen.
Von welchem Vorschlag bin ich am meisten begeistert?
Sortierung - bester Vorschlag zuerst:
2b: Hervorhebung zusammengehöriger Klammern
2d: Hervorhebung von Leerraum der die Formatierung beeinflusst
2a: Hervorhebung des aktuellen Bereichs und Reduzierung der Hintergrundfarben
2e: Überarbeitung des Farbthemas
2c: Automatisches Schließen von Klammern
Was meiner Meinung nach sonst noch wichtig ist.
Ich denke, dass die meisten, die den Schwerpunkt „Leichter mit Vorlagen arbeiten“ gewählt haben, eher „Leichter“ als „mit Vorlagen arbeiten“ im Sinn hatten (weiß ich allerdings nicht).
Auch wenn leichteres Arbeiten mit einem Quelltext-Editor definitiv dazu gehört, sollten auch die Möglichkeiten, die Einbindungs-Wikitexte für Vorlagen durch den VisualEditor (WP:VE, H:VE) gut nutzbar anzubieten, nicht aus den Augen verloren werden.
Zumindest für die Wikipedia, die eine Enzyklopädie ist, befürchte ich auf lange Sicht ein schleichendes Absterben, wenn man Artikel (bzw. in den Artikeln) nicht überwiegend im WYSIWYG-Style, also im VE, schreiben kann. (Das sieht bei WikiData vermutlich anders aus.)
Der Einstieg in die Wikipedia war früher einfacher, weil man dem Wikitext anfangs keine größere Aufgabe zugedacht hatte, als leichter und übersichtlicher zu sein, als HTML. Der Preis dieser Übersichlichkeit war, keine allzu komplexen Sachen zu machen und Seiten nicht allzu lang werden zu lassen.
Nach und nach ist die Komplexität, z. B. durch neue Vorlagen, Erweiterungen u. ä. gestiegen, wobei sich die Wikipedianerinnen und Wikipedianer langsam und parallel dazu anpassen konnten.
Wer heute neu dazu kommen will, hat diese Möglichkeit nicht, sich parallel zu entwickeln. Der Gedanke, die Auffindbarkeit von Vorlagen durch den VE zu verbessern, ist richtig. Man sollte aber zunehmend die Möglichkeit bekommen, eine Vorlage-Einbindung effektiv dort zu bearbeiten, wo man in diesem Fall gerade ist – nämlich beim Schreiben mit dem VE.
Deshalb empfehle ich, den Syntax-Hervorhebungen nicht die gesamte verbleibende „Legislatur-Periode“ des technischen Wunsches „Leichter mit Vorlagen arbeiten“ zu widmen. Sonst wär's natürlich gut, wenn 2a bis 2e gehen würden.
zusätzliche Klammerhervorhebung nur bei Schnark, wenn der Cursor hinter einer Klammer steht (nicht rot markiert wenn die zugehörige Klammer fehlt)
{{FNZ|F|[https://www.duden.de/suchen/dudenonline/lies lies – etwas lesen] ↔ [https://www.duden.de/suchen/dudenonline/lie%C3%9F ließ – etwas lassen]}}
{{FNZ|F|[https://www.duden.de/suchen/dudenonline/lies lies – etwas lesen] ↔ [https://www.duden.de/suchen/dudenonline/lie%C3%9F ließ – etwas lassen]}}
Und ich sage ausdrücklich, diese Syntaxhervorhebung, sowohl in der Farbgestaltung als auch in der Klammerhervorhebung (nur bei Schnark) sind bisher ungeschlagen, da sie auch die Inhalte farblich hinterlegen. Das erleichtert das Auffinden von Fehlern in Quelltext enorm. Ohne diese Hilfe könnte ich hier nicht effektiv arbeiten. Die dezente Farbgebung stört den Lesefluss weit weniger als der CodeMirror mit seiner aufdringlichen Fettschrift. --Liebe Grüße, LómelindeDiskussion09:50, 18. Okt. 2020 (CEST)Beantworten
Prototyp 3: Leichteres Arbeiten mit Vorlagen im Visual Editor
Letzter Kommentar: vor 4 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Erstmal: Gefällt mir sehr gut! Ich finde sämtliche Vorschläge sinnvoll, würde aber gern noch ein paar Dinge ergänzen, die vielleicht im gleichen Schritt ebenfalls verbessert werden könnten.
zu 3.2: Es wäre sinnvoll, dabei auch Parameter zu unterschieden, die nicht leer sein sollten/dürfen (und dann beim Speichern entweder automatisch entfernt oder notfalls von Hand gelöscht werden, wenn darauf hingewiesen). Leider ist es in der aktuellen Konfiguration nur möglich, einen Parameter als „vorgeschlagen“ zu definieren, wenn er den Benutzern angeboten werden soll; dieser wird dann aber auch wenn nicht ausgefüllt immer in den Quelltext geschrieben, was erfahrungsgemäß nur selten erwünscht ist.
zu 3.5: Ist dies rein optisch gedacht? Es ist ja schon lange ein Wunsch (siehe etwa phab:T192385, phab:T197634, phab:T95695 oder phab:T119423), Abhängigkeiten zwischen Parametern besser darzustellen. Wenn also hier im Beispiel Bild und Bildbeschreibung optisch „gekoppelt“ sind, müsste das auch beim Auswählen der Parameter aus der Liste (wenn optional) oder beim Einfügen in den Quelltext immer mit berücksichtigt werden. Wäre jedenfalls ein wichtiger Schritt. Verwandt ist auch das Problem mit unendlich nummerierten Parametern …
zu 3.7 und 3.8a: Was hier noch dazupassen würde, ist der sehr wichtige (da extrem häufige) Fall von verschachtelten Vorlagen. Der Vorlagen-Editor mag ja noch so schön und benutzerfreundlich sein; solange er nicht auf alle Vorlagen im Quelltext zugreifen kann, steht er auf verlorenem Posten (im VE Elvis Presley/Diskografie oder Liste der Nummer-eins-Hits in den USA (1975) zu bearbeiten ist deutlich mühsamer als im Quelltext). So, wie neue Fenster für den Medienselektor aufgerufen werden sollten, müsste es die gleiche Option eben auch für Vorlagen geben (und ja, das kann dann schon mehrfach der Fall sein; die maximale Verschachtelungstiefe, mit der ich im Normalfall zu tun habe, ist 5 [im Beispiel die Vorlage:Webarchiv]). Verschachtelte Vorlagen zu unterstützen wäre in meinen Augen wohl die größte und wichtigste Weiterentwicklung in diesem Bereich!
und vielen Dank an das Team Technische Wünsche für die Ausarbeitung mit Vorschlägen zur besseren Nutzbarkeit des VE!
Ich (Dirk123456/Disk) glaube, dass die Zusammenarbeit vom VisualEditor (WP:VE, H:VE) und Vorlagen schon ganz gut klappt, nämlich in den Fällen, wo die Programmierung einer Vorlage (H:VP), die Dokumentation (H:Vorlagendokumentation) und die TemplateData („Vorlage-Daten“, H:TemplateData) – z. B. die Verwendung von sogenannten Datentypen (Hilfe:TemplateData/Anwendung) – gut aufeinander abgestimmt sind.
Auch in den Fällen, wo zwar weder TemplateData noch eine separate Dokumentationsseite vorhanden sind, aber ein Klick auf die Vorlage-Seite reicht, um sich einen Überblick zu verschaffen – z. B. weil nur wenige Parameter zum Einsatz kommen – ist die Anwendung des VE passabel.
Ich vermute, dass in vielen Fällen die Weiterentwicklung des VE für sich genommen wenig hilft, da die Software wohl auf diese Abgestimmtheit der oben genannten Ressourcen angewiesen ist. Im Folgenden gehe ich auf die einzelnen Punkte zum Prototyp 3 ein. Darunter folgt Zusammenfassendes und Allgemeines.
Die Pfeile nach links (←) verweisen zum jeweiligen Abschnitt auf der Projektseite („Vorderseite“).
← Zu Prototyp 3 (Leichteres Arbeiten mit Vorlagen im Visual Editor) — Es wurden vier Abbildungen zum Prototyp 3 mit insgesamt neun Punkten bereit gestellt.
Prototyp Benutzeroberfläche - Leichteres Arbeiten mit Vorlagen im Visual Editor
Punkte 1 bis 6 im Bild, Prototypen 3.1 bis 3.6 als Abschnitte auf der Projektseite
Prototyp 3.7 - Automatische Vervollständigung verbessern
Punkte 7a und 7b im Bild, Prototypen 3.7a und 3.7b als Abschnitte auf der Projektseite
Prototyp 3.8a - Knöpfe zur Verwendung des vorhandenen Medien-Selektor im Visual Editor hinzufügen
Punkt 8a im Bild, Prototyp 3.8a als Abschnitt auf der Projektseite
Prototyp 3.8b - Bildvorschau
Punkt 8b im Bild, Prototyp 3.8b als Abschnitt auf der Projektseite
← Zu Prototyp 3.1 (Besserer Hilfetext) — Es werden hier zwei Aspekte beleuchtet: Doppelter Titel und Doku-Link.
Doppelter Titel: Dass einige Informationen doppelt angezeigt werden, mag im Einzelfall überflüssig anmuten, ich selbst finde es aber nicht schlimm. Ich fände es schlimmer, wenn irgendwo Info fehlt. Deshalb sollte man diese Redundanz nur verringern, falls sich beide Zeilen aus ein und derselben Ressource speisen.
Doku-Link: Die Aussage: „Es wird dazu ermuntert die Dokumentation auf der Vorlagenseite zu Hilfe zu ziehen“, wird durch ein fiktives Beispiel – eine „Vorlage:Infobox Person“ gibt es gegenwärtig nicht – unterfüttert:
„lnfobox für einen Artikel über eine Person. Zusätzliche Hilfe beim Ausfüllen der Vorlage erhalten Sie auf der Dokumentationsseite.“ („Dokumentationsseite“ ist blau, als Link gedacht).
Ein solcher Text würde den gegenwärtigen, z. B. für die Infobox Protein, ersetzen:
„Infobox für einen Artikel über ein Protein“ (Kurzbeschreibung der konkreten Vorlage) und
„Es könnten einige zusätzliche Informationen über die Vorlage „Infobox Protein“ auf ihrer Seite vorhanden sein“ (allgemeine Angaben und konkreter Link).
Die Verknüpfung vom Text „ihrer Seite“ entspricht in diesem Beispiel Vorlage:Infobox Protein.
zum einen ist es nicht nötig, da die Vorlage-Seite des Beispiels (Vorlage:Infobox Protein) die Doku-Unterseite einbettet (Vorlage:Infobox Protein/Doku) und
zum anderen hat nicht jede Vorlage eine Doku-Unterseite.
Im zweiten Fall steht die Dokumentation zusammen mit dem Vorlage-Programm-Code auf derselben Seite, so dass in der Normal-Ansicht nur die Dokumentation zu sehen ist, was im Quell-Code (Editier-Ansicht) vor allem durch die Anwendung von include-, onlyinclude- und includeonly-Tags gewährleistet wird (soweit ich das überschaue).
Die Formulierung: "... „Infobox Protein“ auf ihrer Seite ..." ist vielleicht nicht die günstigste, weil man erst mal denken könnte, dass man plötzlich bei moderner Anwendung der Groß- und Kleinschreibung gesietzt wird; man kann aber auf "ihrer Seite" klicken und erkennt, dass das wohl die Seite von „Infobox Protein“ sein wird, nämlich Vorlage:Infobox Protein.
(-; Ich dachte nach dem ersten Mal Lesen eines solchen Textes tatsächlich, mein Benutzer-Namensraum hätte irgendeine Spezial-Seite ;-)
Im Englischen habe ich dafür diesen Text gefunden:
“The "Template:Literature" template doesn't yet have a description, but there might be some information on the template's page.” (Google-Übersetzung: „Die Vorlage "Vorlage: Literatur" enthält noch keine Beschreibung, möglicherweise befinden sich jedoch einige Informationen auf der Seite der Vorlage.“)
Ich bin dafür, dass der sichtbare Text der Verknüpfung und das Ziel der Verknüpfung identisch sind;
etwa so: „Zur Anwendung der Vorlage auf der Seite "Vorlage:Literatur"“
oder so: Es können zusätzliche Informationen auf dieser Seite vorhanden sein: Vorlage:Literatur.
Das Wort „Dokumentationsseite“ halte ich für nicht so günstig, gerade wenn dazu „ermutigt“ wird, diese Seite zu „ziehen“. Das kann zu Frust führen, da – wie oben beschrieben – nicht jede Vorlage eine eigene Dokumentationsseite hat.
Denkbar wäre auch ein Extra-Dialog, ähnlich diesem:
Menüpunkt: Hilfe zur Anwendung der Vorlage →
Dialog-Fenster mit dem Titel: Hilfe zur Anwendung der Vorlage "FN"
Hinweis: Nicht alle Vorlagen sind nach den gleichen Prinzipien gestaltet. Daher kann der VisualEditor manchmal nicht alle Informationen zu jeder Vorlage in gleicher Weise darstellen. Möglicherweise findest du einige zusätzliche Angaben auf der jeweiligen Seite der Vorlage.
Da könnten alle möglichen Hinweise über Vorlagen im Allgemeinen und über die konkrete, jeweils bearbeitete Vorlage rein. Aber vielleicht schösse man so mit Kanonen auf Spatzen.
Fakt ist, dass es sehr viele Varianten gibt, wobei ich nicht behaupte, das in Gänze zu durchschauen: klassische Vorlagen-Programmierung (H:VP) ohne sichtbare Kommentare, VP mit der Dokumentation auf derselben Seite, VP mit der Dokumentation auf einer Unterseite; es ist theoretisch wohl auch möglich, dass ein bisschen Doku auf der Vorlage-Seite und ein bisschen auf einer Unterseite stattfindet. Dann gibt es noch die Vorlage-Seiten, die mit "invoke" ein durch Lua erzeugtes Programm einbinden (z. B. in Vorlage:Literatur). Man findet auch Misch-Formen, z. B. wenn der letztlich wirksame Programm-Code auf der „klassischen Vorlagen-Programmierungs-Sprache“ (H:VP) beruht, aber Lua einen Beitrag leistet (z. B. in Vorlage:Infobox Protein so angegeben).
Nur Eins ist sicher: wenn, irgendwelche Informationen vorhanden sind, ob nun einige, zusätzliche oder die gleichen, wie die, die man auch im VisualEditor sieht, dann sollte man sie auf der Seite der Vorlage finden.
Zusammenfassung für 3.1 – Doku-Link: Ich denke, man sollte weder ermutigen noch verunsichern, sondern einfach auf die Seite der Vorlage mit dem qualifizierten Namen verweisen. Der Verknüpfungstext und das Link-Ziel sollten identisch sein (allgemeine Form: Vorlage:Name der Vorlage).
Die trennende Linie zwischen der Kurzbeschreibung und dem Hinweis mit Link sollte erhalten bleiben.
← Zu Prototyp 3.2 (Erforderliche Parameter) — „Tests haben gezeigt, dass Sternchen für Benutzer nicht allgemein "erforderlich" bedeuten.“
Es gibt kaum einzelne Zeichen, die für sich genommen eindeutig sind. Nun ist das Sternchen (*) besonders beliebig, weil es häufig für „beliebig“ steht (z. B. als Joker-Zeichen). Woanders kann es auch ein Multiplikations-Zeichen oder ein Fußnoten-Zeichen sein. Letzteres erklärt wohl auch seine Herkunft. In den Dokumentations-Angaben stand/ steht häufig so etwas, wie: „Mit * bezeichnete Felder müssen angegeben werden“. Solche Hinweise finden sich zwar meist oberhalb eine Parameter-Tabelle, haben aber letztlich eine ähnliche Funktion, wie Tabellen-Fußnoten.
Der Text „(Erforderlich)“ nimmt mehr Platz ein, als das Symbol * und es gibt ein Tooltip mit dem Text „Erforderliches Feld“. Der Stern fällt mehr auf als Text, steht unmittelbar neben dem Namen und zeigt mit dem Tooltip „Erforderliches Feld“ an, was erforderlich ist.
Ich halte es für gut so, wie es ist. Wenn jedoch künftig ein Text angewendet wird, sollte das Tooltip erhalten bleiben.
← Zu Prototyp 3.3 ([[ ]] Knopf entfernen) — Wenn der „doppelte, kantige Klammer-Knopf“ zwischen Normalansicht und Wikitext umschalten könnte, dann hätte er durchaus Berechtigung.
Das könnte etwa so aussehen:
Normalansicht: ⟨ DNA-Methylierung, Übertragung einer Methylgruppe auf den Pyrimidin-Ring des Cytosins in Position 5 durch eine "DNA (cytosine-5-)-methyltransferase" (EC 2.1.1.37). ⟩ und
Wikitext: ⟨ [[DNA-Methylierung]], Übertragung einer Methylgruppe auf den [[Pyrimidin]]-Ring des [[Cytosin|Cytosins]] in Position 5 durch eine "DNA (cytosine-5-)-methyltransferase" (EC 2.1.1.37). ⟩,
Ich denke, so war das auch mal gedacht; zumindest deutet das zugehörige Tooltip („Zurück zu einfachem Wikitext“) das an.
Gegenwärtig gibt es in den Parameter-Feldern des VE nur Wikitext. Man würde für das Editieren der Parameter-Werte im WYSIWYG-Stil ein Basis-Menü benötigen, ähnlich wie das beim Belegen der Fall ist:
⟨ Belegen ⟩→ ⟨ Einen Beleg einfügen ⟩ →⟨ Basisform ⟩→ ⟨ Einzelnachweis ⟩→ dort Basismenü:
Das würde erst einmal nur mit dem sogenannten Datentyp "content" bzw. "Inhalt" klappen, vorausgesetzt, der in das Feld eingegebene Wikitext wird ohne Extras verwendet (Datentyp Inhalt: H:TemplateData/Anwendung#wikitext).
← Zu Prototyp 3.4 (Beschreibungen sichtbarer machen) — „Gegenwärtig sind die Beschreibungen ausgeblendet und werden nur angezeigt, wenn das Info "i"-Symbol angeklickt wird.“
Das reicht doch aus, oder? Gerade wenn Folgendes zutrifft:
„Häufig enthalten die Beschreibungen wichtige Informationen, die dabei helfen, Parameter korrekt auszufüllen und zu formatieren.“
könnte die eine oder andere Liste ziemlich lang werden. Es sollte ja eigentlich immer so sein, dass die Beschreibungen alle Informationen enthalten, die dabei helfen, die Parameter anzuwenden; denn Infos, die bei irgendwas helfen, sind automatisch wichtig und Beschreibungen ohne alle wichtigen Infos wären unvollständig.
Gegenwärtig hat jedes Feld zwei Zeilen, eine Zeile mit dem Namen des Feldes und Schaltknöpfen, unter anderem mit dem (i)-Symbol, und die andere Zeile mit dem Eingabe-Feld. Das (i)-Symbol wird vom Tooltip „Beschreibung des Feldes“ begleitet und bietet mit Mausklick eben diese Beschreibung eines einzelnen Feldes.
Wenn man diese (i)-Symbole sozusagen „ausklappt“, hätte das zwar den Vorteil, dass man nicht auf jede Beschreibung einzeln klicken müsste, man würde aber die Eingabe-Felder zwischen den Beschreibungen schlechter finden. Ich fände das unpraktisch, da ich ja irgendwann weiß, welche Felder ich editieren möchte und das sind meist wenige. Für alle Beschreibungen könnte man ja noch den Doku-Link nehmen, also die Verknüpfung zur Seite der Vorlage (siehe Prototyp 3.1).
Zu den Prototypen 3.5 bis 3.8b — Vorgeschlagene Neuerungen
Die vorgeschlagenen Neuerungen:
← Prototyp 3.5 (Einführung gruppierter Parameter),
basieren alle auf einer soliden Anwendung der TemplateData (H:TemplateData). Die Vorschläge schauen sich sehr gut an. Allerdings macht der VE das alles wohl nicht allein, sondern benötigt Ressourcen, die – so wie ich es verstanden habe – noch komplexer werden sollen. Es ist schon jetzt so, dass das Schreiben der Dokumentation durch Einbeziehung der TemplateData nicht besonders einfach ist, unter anderem deshalb, weil dazu eine weitere „Codierungsform“ notwendig ist (H:TemplateData/JSON).
Hinzu kommt, dass die durch TemplateData unterstützten Datentypen – falls ich das richtig sehe – eher Empfehlungen sind als strikte Festlegungen.
So erzeugt beispielsweise die Vorlagenprogrammierung (H:VP) von "Infobox Protein" beim Parameter "Kategorie" automatisch doppelte, eckige Klammern, die man nicht mit eingeben muss (und auch nicht eingeben darf), so dass aus dem eingegebenen Wikitext immer ein Link wird. Beim Parameter "Reaktionstyp" derselben Vorlage ist das nicht der Fall. Für beide Parameter ("Kategorie" und "Reaktionsart") wird in der Doku derselbe Datentyp "Inhalt" angegeben (gegenwärtige Versionen, Vorlage-Seite: oldid=201276907 und Doku: oldid=200160972).
Der Vorschlag unter Prototyp 3.7:
„Darüber hinaus würde die Zielseite, nachdem sie ausgewählt wurde, automatisch so formatiert werden, dass sie als Wiki-Link erscheint (siehe 7b).“,
hätte hier keinen positiven Effekt, da der Link in einem Fall bereits durch den zu Grunde liegenden Programmcode gesetzt wird (für Parameter "Kategorie") und im anderen Fall nicht immer gebraucht wird (bei Parameter "Reaktionsart"). Selbst wenn es den Datentyp "Wikipedia-Link" gäbe, wäre vermutlich eher der Programmablauf der Vorlage dafür zuständig, als der VE.
Zusammenfassendes und Allgemeines
Bei einzelnen Punkten kann man vermutlich anfangen, den VE äußerlich zu verbessern; das betrifft zum Beispiel die Titel-Redundanz (Prototyp 3.1). Bei anderen Sachen wird es vielleicht schwieriger. Meine Erfahrung sagt mir, dass Veränderungen auch gern mal „Verschlimmbesserungen“ sein können. Das geht an keine konkrete Adresse, sondern ist eine allgemeine Erfahrung.
(-; Sobald ich bei irgendeinem Thema versuche, einen zweiten Blick auf die hintergründigen Details zu werfen, nimmt sich meine Begeisterung des öfteren vornehm zurück ;-)
Ich denke, dass bis auf Weiteres nicht jede Vorlage gleich gut mit dem VE zurecht kommen wird oder anders herum. Das hat verschiedene Gründe, unter anderem den, dass der Zweck der Vorlage einen anderen Fokus hat oder hatte, als von einer graphischen Benutzeroberfläche (GUI) eingebunden zu werden. Die Vorlage:Klade wurde z. B. dazu entwickelt, um Stammbäume zu „konstruieren“. Einige Vorlagen wirken nur im Zusammenhang (z. B. die Fußnoten-Vorlagen FN, FNZ und FNBox) und können die Abstimmung zueinander nicht selbst kontrollieren.
In beiden Fällen – Stammbaum und Fußnoten – gibt es Alternativen. Den Stammbaum könnte ich mir z. B. mit der Vorlage:Klade auf einer Baustelle „zurecht basteln“ (Vorlage:Baustelle), davon einen Screenshot machen, diesen als PNG-Bild speichern, auf Wikimedia Commons hochladen und dann als Abbildung in einem Wikipedia-Artikel einbinden. Statt der Fußnoten-Vorlagen kann ich zumeist die Belegen-Funktion des VE nutzen.
Viele Vorlagen sind nützlich und auf Grund ihrer Einfachheit nicht geeignet, um da herum viel Aufwand zu betreiben (Anlegen einer Doku-Unterseite mit Einbeziehung der Template-Data usw.).
Der arme VE, der sozusagen „auch nur das essen kann, was auf den Tisch kommt,“ sollte das Recht haben, zu erwähnen, dass es mit der jeweiligen Vorlage „Verdauungsprobleme“ geben könnte. Bisher gibt es zur Abgestimmtheit zwischen VE und Vorlage einen einzelnen Satz (Es könnten einige zusätzliche Informationen über die Vorlage „<jeweiliger Name>“ auf ihrer Seite vorhanden sein), der so wirkt, als wolle der VE sich für irgendetwas entschuldigen, ohne genau angegeben zu wollen, wofür.
Ich fände es gut, wenn der VE eine Vorlage und ihre Ressourcen prüfen könnte, um formale Anforderungen an die Kompatibilität zwischen sich und der Vorlage zu erfassen.
Wenn keine besonders große Kompatibilität vorliegt, dann könnte der VE – wie bisher – die Werte für die Felder bzw. Parameter entgegen nehmen und daraus einfach die entsprechende Vorlage-Einbindung erzeugen. Das wäre dann sozusagen der „robuste Modus“.
Wenn formal eine große Kompatibilität erreicht wird, dann könnte der VE – das ist bloß ein Gedanke – erweiterte Funktionen anbieten. Das wäre dann sozusagen der „smarte Modus“.
Ich habe diese beiden Vorgehensweisen des VE bei der Vorlage-Bearbeitung hier mal den „robusten“ und den „smarten Modus“ genannt – das ist nur, um Arbeitsbegriffe zu haben. Auf alle Fälle sollten die bisherigen Grundfunktionen nicht verloren gehen:
Anklicken der Seite der jeweiligen Vorlage und
Ausfüllen der Parameter mit den erwarteten Werten als Text.
Es wäre fatal, wenn man nur deshalb zum Quelltext-Editor (WP:wikEd) wechseln würde, weil eine Seite nicht in jedem Fall erreichbar ist oder ein automatisch erzeugter Link an der falschen Stelle stört. Ich denke, man sollte gegebenenfalls vom „smarten Modus“ in den „robusten Modus“ zurück schalten können.
Ich weiß nicht, wie die formalen Anforderungen an hohe Kompatibilität zwischen VE und Vorlage im Detail aussehen müssten. Auf der Seite WP:... Häufigst genannte Probleme hatte das Team Technische Wünsche schon einiges zusammen getragen, was die Arbeit mit Vorlagen insgesamt erschwert. Darunter ist vermutlich auch einiges, das definieren könnte, was einer solchen Kompatibilität im Wege steht.
Ich glaube, dass es halbwegs objektiv sein kann, wenn Software die Kompatibilität von Software-Komponenten prüft, wenngleich mir klar ist, dass es Diskussionen darum geben könnte, was der VE und was die Vorlage können muss.
Der bessere Komfort beim Ausfüllen von Vorlage-Einbindungen für Artikel-Schreibende darf auch nicht zu sehr zu Lasten des Komforts für die Programmierenden und Dokumentierenden gehen.
Als man die Dokumentation noch einfach als Wikitext unter den Vorlage-Code schrieb, hatte dass ja auch Vorteile; beides – die Programmierung und die Dokumentation für die Anwendenden – wurden meist synchron erledigt. Jetzt gibt es die Dokumentations-Unterseiten mit JSON für die TemplateData und Wikitext für weitere Informationen. Selbst bei der einen oder anderen Infobox, die eine Vorlage-Dokumentations-Unterseite mit JSON-Code für die TemplateData besitzt, sind dort die Paramerter-Beschreibungen freigelassen worden (etwa in der Form: ... "params": { ... "description": "", ...), um sie in einer „normalen“ Wikitext-Tabelle abzulegen
Je komplexer das gesamte System wird, desto mehr besteht die Gefahr, dass die unterschiedlichen Gruppen von Beitragenden und Leidtragenden aneinander vorbei reden oder – um noch eine Spezialität aus „Wiki-World“ zu nennen – mithilfe unendlicher Diskussionswürste aneinander vorbei schreiben.
Bildliche Darstellungen sind bei der Kommunikation in „Wiki-World“ selten, weil sie eben auch eher umständlich zu erzeugen sind. Sie helfen aber; gerade, wenn es um eine Idee geht, die noch vorgestellt werden muss. Ich freue mich über das Engagement des Teams Technische Wünsche. Lasst Euch bitte nicht entmutigen!
Letzter Kommentar: vor 4 Jahren12 Kommentare4 Personen sind an der Diskussion beteiligt
Was der Software wirklich fehlt, ist eine Vorlagenauswertung, d.h. eine Analyse der Parameterwerte je Vorlage. Es gab dazu einmal den TemplateTiger, der das auf Tool-Basis konnte, und das inzwischen inaktive WikiProjekt Vorlagenauswertung. Ein solcher Ansatz würde uns erhebliche Wartungsmöglichkeiten bieten, die derzeit völlig undenkbar sind, und zwar für jeden Benutzer intuitiv und einfach zu nutzen. Yellowcard (D.) 10:47, 23. Jun. 2020 (CEST)Beantworten
Ein paar Tests weiter kann ich nur sagen: Dieses Tool ist hervorragend und füllt eine große Lücke. Wie lang wird es denn voraussichtlich dauern, bis es aus Persondata entnommen ist? Wenn das ein größerer Akt ist, fände ich es nicht sinnvoll, dieses Tool nicht genau so, wie es ist, zu dokumentieren und auch bekannter zu machen. Yellowcard (D.) 11:43, 23. Jun. 2020 (CEST)Beantworten
Yep, will er so.
Voraussetzung für ein stabiles Werkzeug sind:
Offene Maintainer-Gruppe zur längerfristigen Pflege.
Damit langfristige Verfügbarkeit.
Damit ausbaufähig zur globalen Einsatzfähigkeit:
Alle Wikis.
GUI I18N
Einer meiner Vorschläge im Zusammenhang dieser TW-Disk geht dahin, dass WMDE in die neue Maintainer-Gruppe eintreten möge.
Damit wäre eine langfristige Robustheit besser zu sichern.
WMDE müsste nicht unbedingt jedes Detail der Umsetzung betreuen, könnte aber Maintainer sein für Datenbank-Pfade, Umgebung in der Cloud, Anschubsen, Aktualisierung irgendwelcher interner Links und Zugriffe auf mitbenutzte Software.
Außerdem das Framework in der Cloud zu konfigurieren; für die neue Maintainer-Gruppe template…….
Solange das keine robuste URL hat, gibt es keine Doku.
Auch keine Reklame für ein nicht dauerhaftes Werkzeug.
Jedes Provisorium ist von unendlicher Dauer.
Jede Bastelei mit nicht dauerhaft unterstützten Vorab-Versionen gibt hinterher unendliches Geschrei und Geplärre, Gejammer und Zwergenaufstand in der Community, wenn die Benutzer anschließend wieder umlernen müssen, und alle Leute ihre Seiten und Verlinkungen wieder umändern müssen.
Das habe ich jetzt schon ein dutzend Mal erlebt, und ich lasse mich grundsätzlich nicht mehr darauf ein, halbfertige oder unausgegorene oder instabile Angelegenheiten zu propagieren oder in andere Umgebungen zu integrieren.
Da ist die Community selbst schuld, wenn es jedesmal ein Riesendrama gibt, weil irgendwas nicht mehr exakt so unterstützt wird wie es 2004 mal irgendwer bei prä-MediaWiki oder in unseren Vorlagen programmiert hatte.
Gerade bei Vorlagen sind die 2004, 2006 oder 2008 so gebastelt worden, wie man das damals wusste und konnte, und ausgelegt für 100 oder 200 verschiedene, von denen man es sich seinerzeit so vorstellte, dass die vollständige Dokumentation für alle Vorlagen zusammen auf Seiten wie H:DBL geleistet werden könne.
Inzwischen haben wir viel dazugelernt, was zu tun ist, damit es dauerhaft und möglichst robust funktioniert.
Ich bin seit Jahren mit der Aufarbeitung von Fehlern ausgelastet, bei denen man schon 1998 bekannt gewesene Erkenntnisse über korrektes HTML oder sinnvolle Programmierung von Wiki-Vorlagen in der enWP gehabt hatte und diese aus Dummheit oder Faulheit oder schlichter Unfähigkeit teils bewusst ignoriert hatte.
Es ist so unendlich mühsam und kostet so immensen Pflegeaufwand, nachträglich die von vornherein erkennbar falschen Wege wieder umzubauen und noch viel schwieriger die in den Köpfen einmal falsch gespeicherten zu blitzdingsen und die Benutzer zum Umlernen zu bringen, dass ich grundsätzlich keinerlei Provisorien mehr für produktive und potenziell millionenfach eingesetzte Bastelarbeiten mehr unterstütze, und gehe dagegen notfalls mittels Warnhinweisen vor.
Wir hatten mal für 18 Monate die wohl aus der enWP abkopierte prettytable, die danach durch die später auch global standardisierte wikitable abgelöst wurde. Wir sind gerade in diesen Wochen die letzte Verwendung im ANR losgeworden; nach zwölf Jahren. Selbst in jüngerer Zeit sind mir Admins aufgefallen, die bis heute nicht begriffen haben, dass prettytable obsolet ist und in mittlerer Zukunft nicht mehr unterstützt werden wird, um die Performance und Effizienz aller anderen Seiten zu steigern.
90 % meiner Arbeitskraft, zuzüglich einer Herde von Wartungsameisen, Bot-Einsätze und WSTM sind damit beschäftigt, teils seinerzeit unvermeidliche und teils in Unfähigkeit zusammengepfuschte Geschichten aus Vorlagen und Artikeln wieder herauszuoperieren, damit die Programmierungen vereinfacht und robust gemacht werden können.
Lieber PerfektesChaos, nichts von alledem, was Du schreibst, ist eine irgendwie falsche oder nicht nachvollziehbare Anforderung. Ich möchte hier aber einmal mehr an Dich appellieren zu berücksichtigen, dass wir hier kein vollprofessionelles Entwicklerteam sind, sondern ein Haufen von Freiwilligen mit sehr unterschiedlichen Kenntnissen und Fähigkeiten – zumal unbezahlt. Ich schätze Deine Arbeit sehr, aber solche Anforderungskataloge wie der obige sind in einem Projekt wie diesem, anders als in einem kommerziellen und professionellen Entwicklerprojekt und -umfeld, nicht immer sonderlich förderlich. Wenn Wurgl das Tool im jetzigen Zustand für einen Status Quo hält, den er zunächst nicht weiter entwickeln möchte (aus welchem Grund auch immer, und sei es einfach, dass er keine Lust hat), dann ist das so, und ist ganz bestimmt kein Argument, dass dieses Tool nicht im WP-Namensraum dokumentiert werden darf oder die Nutzer zur Nutzung des Tools ermutigt werden können. Liebe Grüße, Yellowcard (D.) 14:23, 23. Jun. 2020 (CEST)Beantworten
Um das nochmal deutlicher zu formulieren, weil es mich wirklich wurmt: „Solange das keine robuste URL hat, gibt es keine Doku.“ – Das ist Deine persönliche Meinung, die aber in dieser Schärfe viele Benutzer mit guten Ideen und Ansätzen abschreckt. Ich wehre mich dagegen. Wenn Wurgl dieses Tool as-it-is dokumentiert und zur Nutzung einlädt, werde ich sein Vorhaben unterstützen, soweit das notwendig ist. Gleichzeitig, ebenfalls nochmal betont, sind Deine Forderungen alle inhaltlich richtig, aber eindeutig als Nice-to-have und bestimmt nicht als absolute Anforderungen, über die Du allein bestimmst. Yellowcard (D.) 14:25, 23. Jun. 2020 (CEST)Beantworten
Es ist nicht so, dass ich es so lassen will, wie es ist. Das Ding hat in recht einfacher Form und ohne GUI schon APPER im Jahre anno dazumal geschrieben. Er hat es verwendet um die Daten für die Biographielisten und für die persondata-Seite rauszupfriemeln. Dann kam ein Totalverlust seiner Daten durch Plattencrash (seine Datenbank war irgendwann mal zu groß für ein Backup, also gabs da keines) und der Umbau von PHP5 auf PHP7. Also hab ich das alte Zeugs mal vergessen und neu geschrieben, alles nur für Persondata und die Biographielisten. Die Oberfläche kam im August dazu, nachdem doch einige Anfragen waren, die ich per vogelteufelwildem. SQL-Statement auf der Kommandozeile beantworten konnte. Entsprechend verwoben ist das mit persondata. Das rausnehmen ist einfach, dann macht der Server halt alles doppelt und wenn noch ein Fehlerchen auftaucht, dann ist das Fehlerchen in beiden Tools zu fixen. Find ich alles nicht toll. Zwei Tools, eine gemeinsame Datenbank verschiebt das Problem der Trennung nur auf einen Zeitpunkt wo andere Wikis auch ranwollen. Also muss das sauber getrennt werden. Das eine Ding saugt sich die Vorlagen+Parameter, bietet diese per Weboberfläche feil und das gute, alte persondata greift über eine Schnittstelle zu und holt sich dort die Daten. Und da bin ich am Überlegen, hab schon ein paar Ideen zur Machbarkeit, aber so richtig gefällt mir das noch nicht. Die Schnittstelle soll nicht nur für persondata sein, die soll dann auch Dritte zufrieden stellen.
Ob persondata in der URL vorne steht, ist mir erstmal egal. Die Urls würden zum Zeitpunkt der Trennung bleiben. Redirect machts möglich.
Im Zuges des Umbaus muss ich noch ein alternatives Datenmodell wegen Performance ausprobieren. Eine weitere Tabelle, dafür ist eine kleiner (weniger Datenfelder, ein Index weniger), auch eine zweite kleiner (26 Mio Records weniger) aber eben eine zusätzliche Tabelle mit ca. 70 Mio Records. keine Ahnung, ob das dann schneller, langsamer oder gleich bleibt. Wird sich aber nur bei Vorlagen wie Literatur, Internetquelle, Personendaten oder Commons auswirken, solche mit mehreren 100.000 Einbindungen.
Im Zuge des Umbaus muss ich Namensbereiche einführen, momentan geht nur ANR. Die enWP hat ja z.B. Draft als weiteren endusertauglichen Namensbereich und es gab anfragen, ob ich auch in weiteren Nmensbereichen suchen kann (wie gesagt: Entstanden aus Anforderungen persondata & Biolisten zu füttern, da haben mich Portale etc. nicht interessiert).
Im prealpha-Zustand ist dann die Möglichkeit eine Artikelchen nach diversen Vorlagenproblemchen abzuklopfen, das ist aber unfertig …
Angedacht ist eine Kombinationssuche über mehrere Parameter/Vorlagen …
Intern unterscheide ich zwischen benannte Parametern und unbenannten, auf der Weboberfläche noch nicht (ist nur bei numerischen Parametern wie 1=, 2= relevant)
Eventuell noch so Infos, wie Lomelinde momentan sucht: Ist die Vorlage auf einer eigenen Zeile oder steht da noch anderes Zeugs davor/danach …
Die Webseite ist ein Mix aus 0er-Jahre Tabellenkram (der obere Teil mit den Eingabefeldern) und <div>-Elementen (der Rest). Da wollte ich auch mal mit Autovervollständigung und so Kram ran. Mit dem Tabellenkram schaff ich das leider nicht, da fehlt es mir an Erfahrung.
Mein aktuelles Problem ist, dass mir zwei Auftraggeber (ich bin selbstständig) weggebrochen sind (nicht wegen Corona, sondern wegen Diesel). Ich komm zwar mit dem Dritten über die Runden, nur das ist keine Dauerlösung. Ich investiere momentan recht viel Zeit in die Suche. Wenn es also einen Sponsor dafür gibt, … --Wurgl (Diskussion) 15:23, 23. Jun. 2020 (CEST)Beantworten
@Wurgl: Bewirb dich doch mal als Entwickler bei WMDE mit Schwerpunkt Vorlagenauswertung, und arbeite gleich mal Nachfolger ein. Geht per Home office.
@Yellowcard: Von dem, was durch halbfertige und unreife Programmierung insbesondere im ANR sichtbar wird, womöglich in Millionen von Artikeln eingebunden, wird trotzdem erwartet, dass es hinterher zu 100 % funktioniert, und zwar mindestens anderthalb Jahrzehnte hindurch am Stück; desgleichen bei allen breit genutzten Tools.
Sobald irgendwann irgendwo mal was nicht mehr funktioniert, gibt es Riesen-Zoff, und Volksaufstände, von denen habe ich schon diverse durchlebt.
Ich bin zu 90 % meiner Zeit damit beschäftigt, alles das wieder geradezubiegen, was irgendwer vermeidbar versemmelt hatte, oder was durch bessere Planung und Koordination hätte vermieden werden können.
Sobald dann irgendwas inkompatibel wird, muss ich alles stehen und liegen lassen, und hinspringen und es wieder irgendwie flicken und zum Laufen bringen.
Das Hinterherreparieren unvollkommener Programmierung und vor allem die nachträgliche Umerziehung von Autoren, die vor 10 oder 15 Jahren mal was gelernt hatten, was mittlerweile völlig veraltet und nicht mehr unterstützbar ist, kostet mich und andere zehn- bis hundertmal so viel Zeit wie es gleich richtig zu machen. Wir haben eh schon eine ganz massive Unterdeckung an Manpower und einen Bearbeitungsrückstau von eigentlich einem Jahrzehnt; je mehr unausgereifte Geschichten immer weiter neu reingedroschen werden, desto schlimmer wird das.
Es gibt praktisch keinerlei Projektregeln für das Anlegen neuer Vorlagen und Module; zumindest keine, die sich auf Qualitätsstandards und Robustheit beziehen würden. Jeder Depp darf alles an Vorlagen und Modulen und Tools erschaffen und auch überall einbinden; wenn es dann hinterher wie zu erwarten war nicht mehr funktioniert, weil Grundsätze missachtet wurden, dann bin ich wieder der Depp, der es zum Laufen bringen muss. Wir haben keinerlei Qualitätssicherung für die Infrastruktur.
Ich werde aber ab sofort alle Fälle von mangelhafter Qualität der Programmierung an dich persönlich weiterverweisen, da du ja so vehement für die massenhafte produktive Verwendung von Basteleien eintrittst. Drei Kandidaten(-gruppen) für den Start habe ich schon mal für dich zur Lösung auf Wiedervorlage gelegt:
In der Mobildarstellung sind keinerlei Artikelkoordinaten zu sehen, nur später im Hotelzimmer am Desktop. Ich kann also in meinem Sommerurlaub nicht zu den Sehenswürdigkeiten navigieren, sondern muss mir das vorher im Hotelzimmer auf einen Zettel schreiben und in das Smartphone übertragen. Ursache ist ein unsäglich kurzsichtiger, unzulässiger Pfusch von 2005. Bitte repariere das jetzt endlich.
Die Wikidata-Lua-Bibliothek erfordert, dass vor Zugriff auf einen Item geprüft wird, ob der Item existiert. Greift man trotzdem auf einen Item zu, obwohl keiner mit der aktuellen Seite verbunden ist, stürzt Lua-invoke unauffangbar ab. Das füllt dann dauerhaft Kategorie:Wikipedia:Seite mit Skriptfehlern und macht sie unbrauchbar, obwohl sie eigentlich immer leer sein sollte, damit sich frische Programmierfehler erkennen lassen.
Das ist wohl die Ursache für die Lua-Fehler bei den HW-Modulen im Wikipedia:WikiProjekt Österreich.
Das ist mit Sicherheit die Ursache für die Lua-Fehler im Zusammenhang mit Schwimmmeisterschaften; bitte repariere das jetzt.
Ein anderer Programmierfehler liegt in fehlendem Parametercheck bei der Auflage von Zeitungen, wenn kein Metadaten-Eintrag unter dieser ID vorhanden ist. Bitte repariere das jetzt.
@Wurgl: Danke für den Einblick. Das klingt nach einem spannenden wie auch arbeitsreichen Projekt. Ich finde das extrem begrüßenswert, und gleichzeitig sehe ich nichts, was gegen eine Dokumentation des Status Quo dieses Tools spricht. Es scheint in der jetzigen Form produktiv nutzbar. RL inklusive monetärem Einkommen hat ganz ohne Zweifel vorrang, wie alle anderen Dinge hier auch, und genau das dürfte bei vielen freiwilligengetriebenen Entwicklerprojekten der Grund sein, weshalb diese in dreiviertelfertigem Zustand liegen bleiben: Freizeit ist rar und kostbar.
@PerfektesChaos: Ich sehe eigentlich zwei etwas voneinander abzugrenzende Themen:
Externe Tools, sei es auf Toolforge oder gänzlich extern: Ich sehe weiterhin überhaupt kein sinnvolles Argument, produktive und hilfreiche Tools hier quasi zu verstecken, weil sie ggf. nicht hunderprozentig nachhaltig für die Ewigkeit sind. Volksaufstände, Riesen-Zoff Geschrei, Gemecker – ich weiß, was Du im Kern meinst, aber externe Tools sind immer verzichtbar. Der Verlust tut zwar weh, aber so sei es. Bei den Folgen übertreibst Du mittelschwer, ich habe hier noch keinen Volksaufstand wegen eines nicht mehr funktionierenden externen Tools gesehen.
Module und Vorlagen, sprich Werkzeuge mit unmittelbarer Auswirkung auf den Artikelbestand: Hier gebe ich Dir ein Stück weit Recht, wobei auch hier die Ansprüche und die Wirklichkeit in Einklang gebracht werden müssen, solange wir über freiwillige Programmierer sprechen. Lua-Module müssen robust geschrieben sein, um Folgeprobleme zu vermeiden, und sie sollten nach Möglichkeit im Konsens geschaffen werden. Gegenseitige Konzeptbesprechungen und Code-Reviews wären wünschenswert, und vielleicht sollte man hier etwas restriktiver vorgehen. Zugleich ist es unglücklich, wenn dadurch potenzielle Neu-Entwickler rechtzeitig abgeschreckt werden und Projekte gar nicht erst zur Umsetzung kommen (ich denke hierbei unter anderem an Modul:Wikidata/ValueComparison). Basta-Ansagen, die ich von Dir inzwischen leider recht häufig lese, sind da ebenso unangebracht wie bei den externen Tools – so sehr ich Deine Arbeit schätze und so richtig ich Deine Anforderungen im Grundsatz halte, das habe ich ja allein vorstehend schon mehrfach betont.
Es mag tatsächlich ein Ansatz sein, hier auch WMDE mehr ins Boot zu holen. Ich persönlich hielte die Spendengelder für kaum sinnvoller einsetzbar (sowohl was Unterstützung im Vorlagen-/Modul-Namensraum angeht, als auch in Bezug auf externe Tools). Vielleicht ließe sich ja sogar ein Projektantrag für ein konkretes Vorhaben schreiben, ich würde da durchaus unterstützen, wenn wir auf einem konstruktiven Level arbeiten können.
Der Rest wird mir zu zynisch, weshalb ich ihn ignoriere, mit Ausnahme des angesprochenen Wikidata-Punkts, da melde ich mich gleich bei Dir auf der Benutzerdisk. Viele Grüße, Yellowcard (D.) 18:07, 23. Jun. 2020 (CEST)Beantworten
Hab den Thread gerade zufällig entdeckt. Ich will jetzt nicht nachforschen, seit wie vielen Jahren ich mich darum bemühe, dass der TemplateTiger oder ein Nachfolgetool wieder brauchbar wird, jedenfalls sind es viele. Es freut mich, dass ich diesen Bedarf nicht als einziger sehe, auch wenn ich längst vergessen habe, wo ich ihn ursprünglich entdeckt habe. 2019 auf der WikiCon hab ich mich mit dem WMDE-Team zum Punkt Vorlagenwartung intensiv unterhalten. Ob zwischen diesem Gespräch und dieser Entwicklung irgendeine Form von Kausalität vorliegt, weiß ich nicht, aber ich begrüße ausdrücklich, dass es einen Fortschritt gibt. LG, danke, … «« Man77 »»Alle Angaben ohne Gewehr.22:29, 18. Aug. 2020 (CEST)Beantworten
Zu: Prototyp 1 Update: Vorlagen-Finder
Letzter Kommentar: vor 4 Jahren6 Kommentare4 Personen sind an der Diskussion beteiligt
Kurzer™ Senf von meiner Seite (dann sollte ihr mal eine Langfassung lesen):
Klingt vielversprechend und diverses ist praktikabel und zielführend.
Ich habe keine Videofassung gesehen, noch die Zeit, Experimente an BETA-Implementierungen zu machen; ich beschränke mich auf die textliche Darstellung.
Zu den Punkten im Einzelnen:
1f. Alle in einem Artikel verwendeten Vorlagen anzeigen
Sehr gute Idee; die hatte wohl noch keiner.
Wenn ich an einem Artikel über einen Ort in Lampukistan sitze, dann kann ich bei einem ausgereiften vorbildlichen anderen Artikel über einen Nachbarort spicken.
Der liefert mir Infobox, Navileiste, sprachenspezifische Vorlagen, Vorlagen zu Standardliteratur und relevanten Datenbanken.
Ohne Konfigurationsaufwand auf jede beliebige Seite spontan anwendbares Konzept, um mir eine Standardauswahl in dieser Situation anzubieten.
Ich muss mir also nur noch merken oder aufschreiben, welches Musterseiten zu welchem Thema wären.
Dokumentationsseiten aus den Suchergebnissen entfernen
Standardmäßig alles mit einem Schrägstrich, weil diese mit relativ wenigen Ausnahmen nicht zur Direktverwendung durch Autoren vorgesehen sind.
Vorlage:NavFrame/Ende wäre ein Ausnahmefall. Generell gibt es bei festen Gruppierungen für Tabellen eine Unterseiten-Methodik zusammengehörender Vorlagen für Kopf, Zeile, Legende.
In diesem Projekt gibt es jedoch eine Standard-Nomenklatur, welche Unterseiten regelmäßig nicht zur Einbindung vorgesehen sind: /Doku/Editnotice/Preload/Test/Wartung/XML/styles/styles.css und Seiten, die diesem Muster entsprächen, sollten nie zur Einbindung angeboten werden.
Kategorie
Navigieren durch den Kategoriebaum Kategorie:Vorlage: ist ein sinnvolles Angebot.
„… welche die meisten Vorlagen enthalten“ – das wird nichts bringen. Relevante, oft benötigte Vorlagen stehen nicht in einer Kategorie, die ganz viele einzelne Vorlagen auflisten, sondern eher umgekehrt. Kategorien mit sehr wichtigen und sehr häufigen Vorlagen sind sehr eng geschnitten, haben viel Beschreibung und enthalten nur wenige Vorlagen. Reinschmeiss-Kategorien für allerlei Kroppzeug enthalten einen abgekippten Haufen nicht näher auseinandergefummelter teils überhaupt nirgendwo noch verwendeter Vorlagen mit teilweise Tausenden von Einträgen. Eine Kategorie mit sehr wenigen Vorlagen kann sehr wenige sehr oft benötigte Vorlagen enthalten, oder sehr wenige völlig obskure Gebilde, die irgendwie aus dem Weg sollten. Kategorien mit sehr vielen Vorlagen enthalten ein wirres Durcheinander aus völlig unbrauchbaren und einigen wichtigen Vorlagen. Aus der Anzahl der Einträge lässt sich keinerlei Schluss ziehen.
TemplateData vorhanden / nicht vorhanden
Sehr sinnvolles Auswahlkriterium.
Alle gepflegten, aktuellen, gut einsetzbaren Vorlagen mit Parametern haben in der Regel auch TemplateData.
In unserem ANR sind für die etwa 1000 oder 2000 häufigsten (bis zu rund 100 ANR-Einbindungen) Vorlagen praktisch alle mit TemplateData ausgestattet; zumindest wo Parameter vorhanden und gepflegt und empfehlenswert.
Navileisten haben in der Regel keine Parameter; von denen gibt es über 40.000 und die zu finden ist ein eigenes Spiel.
Formatierung (block/inline)
Ja, mag gern als Filterkriterium unserer demnächst mal 7.000 TemplateData-Vorlagen angeboten werden.
Wir haben jedoch auch 40.000 Navileisten, die alle vom block-Typ sind, jedoch zurzeit noch kein TemplateData erhalten, und weitere 10.000 block-Vorlagen ohne TemplateData oder Parameter und 10.000 inline-Vorlagen ohne TemplateData oder Parameter.
Schnellansicht
Was genau anderes als die Kurzbeschreibung soll ich mir darunter vorstellen?
Eine aus TemplateData generierte Kurzparameterliste, wie wir sie regelmäßig im Abschnitt „Kopiervorlage“ anbieten, erschiene mir grad noch sinnvoll.
Dabei müssen aber alle nicht-Pflicht nicht-empfohlenen Parameter weggelassen werden; ähnlich wie bei einer VE-Einfügung. Ansonsten würde der Quelltext mit lauter ungebräuchlichen Ausnahmefall-Parametern oder gar veralteten Einfügungen geflutet werden.
Die Versorgung des Quelltexteditors bei vielen Parametern passiert besser über die Dokuseite. Mit simplen C&P ist das oft nicht zu leisten; es ist wichtig zu jedem Parameter auch die in der Doku niedergeschriebenen inhaltlichen Hinweise zur Kenntnis zu nehmen (auch zur Formatierung und Bedeutung zulässiger Werte). Im Übrigen sind etliche Parameter unverständlich oder überhaupt nicht benannt.
vorgesehener Namensraum
Das wird wenig bringen und den Aufwand der Sucheingabe mehr erhöhen als die momentanen Ergebnisse zielführend filtern.
Die Strukturen in Kategorie:Vorlage:nach Namensraum müssten pro Wikiprojekt für alle Autoren in der Werkzeug-Konfiguration abgebildet werden und automatisch funktionieren und die zulässigen bzw. unzulässigen Vorlagen ausfiltern.
Weit über 70.000 Vorlagen sind aber für alle Namensräume geeignet.
Man darf in jeder Diskussion (ohnehin zurzeit nicht mit VE, aber andere Werkzeuge) praktisch jede Vorlage einbinden.
Link zur Dokumentationsseite
Das ist identisch mit dem Link zur Vorlagenseite selbst.
Eine Direktverlinkung mit der Dokumentationsseite wäre absolut unerwünscht.
Das würde Normalbenutzer unbemerkt auf die falsche Unterseite und falsche zugeordnete Diskussionsseite beamen, die Kategorisierung nicht darstellen, und würde insgesamt nur verwirren.
Link zu allen Seiten, die die Vorlage verwenden
aka Linkliste.
Negativ; das brächte auch jede Menge schlechter und veralteter und unerwünschter Vorbilder.
Die vorbildlichen aktuellen Beispiele sind auf der Dokumentationsseite dargestellt; alle anderen Beispiele sind allenfalls schlechter als dort.
Wenn es bisher noch keine Dokumentationsseite gibt, wäre eine anzulegen; wenn es noch kein Vorbild gibt dann wäre eine Musterlösung durch die zuständigen Maintainer zu erstellen.
Irgendein Link auf einen Artikel, in dessen eigenem Quelltext die Einbindung überhaupt nicht vorkommen muss, sondern mittelbar über andere Vorlagen erfolgt, bringt niemandem was.
Anzahl der Parameter
Das halte ich, mit Verlaub, für ein sehr realitätsfremdes und unbrauchbares Kriterium, und die getroffene Aussage zur Komplexität ist schlicht falsch.
Vorlage:lang versteht wohl über 1000 Parameter, Vorlage:min akzeptiert auch 10.000 Parameter, und selbst Vorlage:Medaillen ist eher simpel im Selbstverständnis, jedoch für 211 Parameter programmiert.
Vorschau
Das halte ich nicht für zielführend, und über den Namen der Vorlage und ihre Beschreibung hinaus gäbe es dort meist nichts zu sehen. Eine „leere Einbindung“ zeigt auch nichts anders als den Namen der Vorlage.
Auf Tausende von Vorlagen ist ein solches Konzept nicht erweiterbar, sondern mag grad mal für ein paar Dutzend taugen.
Was sagt mir ein generiertes: [{{{1}}} {{{2}}}] als VisualEditor-Newbie ohne Wikisyntax-Kenntnisse?
Es müssten alle Dokus mit zusätzlichen Informationen für ein „Vorschaubild“ ausgestattet werden; dazu hat niemand Zeit und wir fokussieren die Ressourcen der wenigen Betreuer in diesem Projekt lieber auf TemplateData sowie robustere und zeitgemäße Programmierungen und Parametrisierungen.
TemplateData-Kurzbeschreibungen und sprechende Namen von Vorlagen bringen wesentlich mehr für alle denn die Etablierung eines neuen Vorschaubild-Wesens für Zigtausende von Vorlagen.
Beschreibung
„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.“
Glasklares Veto.
Artikel-Autoren haben da nicht irgendwie spontan was reinzueditieren.
Das Verfassen prägnanter Beschreibungstexte nach einheitlichem Muster ist eine Sache für Routiniers, und dazu hat gefälligst die Vorlagendoku im Zusammenhang bearbeitet zu werden.
Schon mal den Wikitext praktisch aller unserer Doku-Seiten mit TemplateData genauer angeguckt?
Vorlagentyp
„Vorlagentypen wie Banner, Zitate oder Stubs“ – lässt mich rätselnd zurück.
Kann mir kein Klassifizierungssystem vorstellen, das vom Management jeder einzelnen Vorlage zugeordnet werden könnte und das hinterher Autoren intuitiv sinnvoll verwenden würden.
Jeder „Vorlagentyp“ hat dann zwei oder fünf oder 10.000 oder 40.000 Mitglieder; es müsste parallel zum existierenden Kategoriesystem (das neben anderem bereits genau solchen „Vorlagentyp“ abbildet) eine komplett neue Struktur geschaffen werden. Die ihrerseits Hunderte von Typen zuordnet; bloß nicht diejenigen, die man beim Suchen grade brauchen würde, und wenn es den Typ gibt, dann hat nicht jeder Maintainer der rund 80.000 einbindbaren Vorlagen in der deWP und der über 400.000 in enWP ihr einen solchen Typ einprogrammiert.
Heißt jedoch: Ich muss eigentlich nur wissen, wie zu welchem „Vorlagentyp“ die dafür zuständige Kategorie heißt.
Wenn die Programmierer bei WMDE eine solche Konfiguration in der Software zum Werkzeug hinterlegen möchten, dann mal munter zu. Falls das dann noch ein Suchender verstünde.
Nachtrag – Weiterer Ausschluss von Suchvorschlägen:
Alle Weiterleitungen (sofern sich das nicht bisher schon ohnehin aus der Suchtechnik ergibt)
bzw. wenn der Suchbegriff grade eine Weiterleitung gut trifft, dann mit der Zielseite weiterarbeiten und die WL vergessen.
Grund: Weiterleitungen bezeichnen oft veraltete, unverständliche, obsolete, aussterbende Namen und Kandidaten für zukünftige Löschungen.
Es soll möglichst einheitlich mit dem echten Namen gearbeitet werden, der dann länger sein mag, aber dafür selbsterklärend, und der einheitlich im Quelltextgesucht und erkannt werden kann.
Eine oder mehrere Kategorien pro Wiki, die vorhandene Vorlagen enthalten, die nicht mehr neu eingebunden werden sollen.
Vorlage:Veraltete Vorlage kategorisiert entsprechend, und das sollte konfigurierbar aus der Suche ausgenommen werden; das bedarf aber der Hinterlegung einer per-Wiki-Infrastruktur.
Vielleicht besser ein neuer globaler Marker für TemplateData; nicht ein einzelner Parameter, sondern die gesamte Vorlage ist obsolet wenn deprecated auch hier auf gleicher Ebene mit description auftritt.
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.
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 wurden), 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:
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 AuszeichnungsspracheWikitext 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.
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:
„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
„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:
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:
„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);
„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:
„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.
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).
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:
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.
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:
Die Community macht erst einmal so weiter, wie bisher.
Die Community bekommt den „Vorlagen-Finder“ und neue TemplateData-Funktionen. Anfangs kann der „Vorlagen-Finder“ noch nicht viel finden.
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:
Vorlagenprogrammierer*innen, die am besten wissen, was sie programmiert haben und deshalb die Dokumentation beliefern sollten und
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.
Hallo Dirk123456, danke für dein ausführliches Feedback, dass wir berücksichtigen werden, wenn wir an der Idee Template-Finder weiterarbeiten. Für den Augenblick fokussieren wir uns auf die anderen Projektvorschläge, da diese klarer abgegrenzt und einfacher umzusetzen sind. -- Michael Schönitzer (WMDE) (Diskussion) 12:05, 7. Okt. 2020 (CEST)Beantworten
Hallo und vielen Dank für die Antwort! Es ist sicherlich vernünftig, mit den Projektvorschlägen von Prototyp 2 anzufangen (Verbesserte Syntaxhervorhebung). Dass diese klarer abgegrenzt und einfacher umzusetzen sind, bezweifle ich nicht. --Dirk123456 (Diskussion) 14:07, 7. Okt. 2020 (CEST)Beantworten
Wir suchen Freiwillige
Letzter Kommentar: vor 4 Jahren5 Kommentare3 Personen sind an der Diskussion beteiligt
Ich stoße schon jetzt an technische Grenzen und auch der Text im Formular weist Fehler auf. Allein die Formulierung „willst“ finde ich immer wieder unschön.
Simulation
Danke, dass du uns durch deine Teilnahme an den Nutzungstest unterstützen willst. Bitte ließ F dir die Beschreibung des Testablaufes und die Datenschutzerklärung sorgfältig durch. […] Des Weiteren werden wir dein Erfahrungslevel bei der Arbeit mit Vorlagen, sowie deine E-Mail-Adresse, erfragen. Dies tun wir, um einen Termin mit dir für den Nutzungstest zu vereinbaren. Anm.
Was du über den Nutzungstest wissen musst:
Der Test wird 45-60 Minuten dauern.
Wir wollen mit dir per Videoanruf (z. B. google meet, Jitsi, etc.) sprechen. 1
Damit wir sehen können, wie du mit der verbesserten Oberfläche interagierst, musst du deinen Bildschirm mit uns teilen. 2
Es wäre für uns von Vorteil, wenn du deine Kamera während des Testes einschalten würdest, damit wir dein Gesicht sehen können. Deine Mimik hilft uns deine Gefühle hinter deinen Reaktionen auf die verbesserte Oberfläche und zu deinem Feedback besser zu verstehen. 1
Es würde uns helfen Audio und Video während des Gespräches aufzuzeichnen, um das Gespräch transkribieren zu können und deine Arbeitsweise nachvollziehen zu können. Die Aufnahme wird spätestens nach 3 Monaten von uns gelöscht. 3
Du erhältst Aufgaben, die du mit Hilfe der verbesserten Oberfläche lösen sollst.
Nach den Aufgaben kannst du uns nochmals abschließendes Feedback zu den vorgeschlagenen Verbesserungen geben.
Meine persönliche E-Mail-Adresse gebe ich ungern weiter (auch nicht mit Datenschutzerklärung)
1
Geht gar nicht ich bin keine Teilnehmerin dieser Dienste und habe auch keine Kamera am PC
2
Kann ich nicht, dazu müsste ich mich für irgendwelche Dienste anmelden oder etwas herunterladen, das tue ich aber nicht
3
Ich habe auch kein Mikrofon am PC
Soviel zu Feedback erwünscht und Freiwillige vor. Damit bin ich schon mal von dieser Testphase ausgeschlossen. Zumal ich auch nicht bereit wäre das „aufzeichnen“ zu lassen. --Liebe Grüße, LómelindeDiskussion09:26, 18. Okt. 2020 (CEST)Beantworten
Hi @Lómelinde:, danke für deine Rückmeldung. Eigentlich werden solche Nutzungstests in der analogen Welt meistens persönlich durchgeführt. Dies ist mit dem momentanen Infektionsgeschehen leider nicht möglich. Trotzdem wollten wir natürlich nicht auf Nutzungstests verzichten, weshalb wir uns entschieden haben diese vermehrt online über ein Videotelefonat durchzuführen.
Zu “Anm.”: Um dafür einen Termin mit den Leuten auszumachen und den Link zum entsprechenden Anruf zu teilen, ist es für uns am Einfachsten dies über E-Mail zu klären.
Zu 1: Bei google meet und jitsi muss man nicht angemeldet sein, um an einem Videoanruf teilzunehmen. Desweiteren ist es für uns vorteilhaft, wenn wir das Gesicht der anderen Person sehen. Sollte dies jedoch nicht möglich (z.B. wegen nicht vorhandener Kamera) oder erwünscht sein, so kann das Gespräch auch ohne Video und Aufzeichnung stattfinden.
Zu 2: Wie oben schon erwähnt kann man diese Dienste (google meet und jitsi) unangemeldet, und ohne etwas herunterladen zu müssen, nutzen und darüber den Bildschirm teilen.
Zu 3: Das ist in diesem Falle natürlich problematisch. Wir verstehen, dass wir dich mit dem momentanen Nutzungstestkonzept nicht abholen. In welchem Rahmen wäre es für dich möglich an einem Nutzungstest teilzunehmen, so dass wir deine Rückmeldung auch bekommen können? -- Für das Team Technische Wünsche: Max Klemm (WMDE) (Diskussion) 13:28, 20. Okt. 2020 (CEST)Beantworten
Ich würde die übliche Vorgehensweise bevorzugen:
Eine Testumgebung wird beispielsweise im Beta-Wiki bereitgestellt.
Aufgabenstellungen können auf einer zugehörigen Portalseite angegeben werden. Ebenso wie eine Seite für die Rückmeldungen.
Die neue Umgebung kann von jedem, der es möchte, ausprobiert werden, auch unabhängig von den Aufgabenstellungen.
Eine, die Anonymitätsprinzipien der Wikipedia verletzende Aufzeichnung von Personen (Aussehen, Geschlecht, Alter, Verhalten) lehne ich grundweg ab. Eine Auswertung dieser Informationen durch unbekannte Dritte, erst recht.
Bildschirm teilen, liefert, wenn ich das so laienhaft überlege, durchaus auch weitere heimliche Informationen über mich, offene Tabs, …, weiß nicht, damit kenne ich mich nicht aus
Die Ergebnisse der Test sollten allen frei zugänglich sein, damit sie durch andere nachvollziehbar sind oder ergänzt werden können. Die Community hier reagiert sehr … „eigen“ auf Dinge die quasi im Hinterzimmer entwickelt und dann als „supertolle Features“ eingestellt werden. (Allein der VE wird noch immer von vielen als „unbrauchbar“ eingestuft) auch ich verwende ihn nicht.
Man kann durchaus aus den Beiträgen anderer etwas lernen.
Resultate, die ausschließlich durch Dritte eingesehen und ausgewertet werden, die hier sonst niemandem zugänglich sind, halte ich für keine gute Idee. Wer auf die Zustimmung der Community baut, sollte möglichst transparent arbeiten.
Auch ein „persönlich durchgeführter Nutzungstest“, ist für mich nicht mit Wikipedia:Anonymität vereinbar. Diese Hürde schließt, meiner Meinung nach, etliche Benutzer von der Erprobung samt Rückmeldungen aus, darunter auch einige, die sich hier mit Vorlagenwartung und Erstellung beschäftigen und selbst versuchen sie für alle nutzbar zu gestalten. --Liebe Grüße, LómelindeDiskussion14:12, 20. Okt. 2020 (CEST)Beantworten
Hi @Lómelinde, danke für dein Feedback. Um eine Funktion zum testen, wie du es beschreibst, auf einem Beta-Wiki bereit zu stellen, muss diese schon ziemlich weit umgesetzt sein, was einen hohen Entwicklungsaufwand benötigt und dadurch auch viele Kosten verursacht. Im Rahmen derartiger Nutzungstestes ist es uns möglich kostengünstiger erste Ideen zu testen, um zu verstehen, ob es sich lohnt diese überhaupt weiterzuentwickeln. Desweiteren ist es für uns sehr wertvoll nicht nur geschriebenes Feedback zu erhalten, sondern zu sehen wie Freiwillige mit der Oberfläche interagieren.
In einem späteren Entwicklungsstadium wird die Funktion auf dem Beta-Wiki oder als Beta-Funktion auf der Wikipedia zu erproben sein. In diesem Stadium gibt es dann erneut Test- und Feedbackrunden, auf deren Basis die Funktion weiterentwickelt wird, bis sie irgendwann für alle aktiviert werden kann.
Die Ergebnisse des Nutzungstest werden hier auf der Seite dokumentiert, so dass diese für alle zugänglich sind und diskutiert werden können. Es ist nicht die Absicht etwas “im Hinterzimmer” zu entwickeln; es wird probiert so transparent, aber auch effektiv, wie möglich zu arbeiten.
Wir sind immer bemüht allen zu ermöglichen uns in allen Entwicklungsstadien Rückmeldung zu geben – auch denen die auf ihre Anonymität wert legen – und nutzen deshalb möglichst viele Kanäle und Formate. Wir sind jedoch auch auf Erkenntnisse, die über die Möglichkeiten von Onwiki-Feedback hinausgehen angewiesen.
Die Freiwilligen in Nutzungstestes können frei entscheiden mit welchem Namen und E-Mail Adresse sie sich für den Test anmelden und müssen ihre Kamera nicht einschalten. Die Teilnahme an dem Nutzungstest ist also möglich ohne seine Identität preiszugeben. Wir sind immer offen für Vorschläge für weitere Möglichkeiten um die Communities einzubeziehen. -- Michael Schönitzer (WMDE) (Diskussion) 17:49, 10. Nov. 2020 (CET)Beantworten
Wie schon geschrieben ist für mich diese Tür verschlossen. Ihr schließt damit, meiner bescheidenen Meinung nach, wirklich effizient jene Mitarbeiter aus, die sich hier der Vorlagenerstellung und -wartung widmen, aber das sind eh nicht sehr viele.
IP-User werden ebenso von der Möglichkeit der Teilnahme ausgeschlossen, man müsste sich da wohl anmelden.
Um eine breite Auswahl an Benutzern für diesen Test zu gewinnen, sollte dieser frei zugänglich sein. Effektiv stelle ich mir das jetzt nicht vor. Wer den VE nicht mag, wird vermutlich nicht teilnehmen, wer weiß, wie man Vorlagen findet und damit arbeitet, benötigt das auch nicht wirklich. Laien (oder Neueinsteiger) werden nicht Teilnehmen, weil sie diese Seite gar nicht finden. … Meine Erfahrungen mit all den Neuerungen seit meinem Einstieg hier waren eher so, dass vieles komplizierter wurde, dass man viel, viel mehr erklären muss, (Deskrop, Mobil, Quelltext, VE …) …ich bin hier raus. --Liebe Grüße, LómelindeDiskussion18:10, 10. Nov. 2020 (CET)Beantworten
,_ceiling_fresco_in_the_Camera_dei_Papiri,_Vatican_Library,_1772_-_M0tty.jpg){kind=small}
.jpg){kind=small}
