Wikipedia Diskussion:Technische Wünsche/Topwünsche/Leichter mit Vorlagen arbeiten

Platz für Anmerkungen zu diesem Thema

Einbeziehung der Community-Techies

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:VWS – informativ
• 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).

VG --PerfektesChaos 14:49, 2. Jul. 2019 (CEST) Ergänzt 22:14, 3. Jul. 2019 (CEST)

 Info: @Vorlagenauswertung

• 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.

Enjoy. --PerfektesChaos 12:30, 8. Jul. 2019 (CEST)

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)
+--------------------------+-------------+--------------+

Was mir noch fehlt ist eine Webseite auf toolforge, Webseiten und vor allem Layout ist nicht so mein Ding. --Wurgl (Diskussion) 13:38, 8. Jul. 2019 (CEST)

Beispiel für einen Anwendungsfall (jeweils Permalink): Wikipedia:Fragen_zur_Wikipedia und die Antwort: Benutzer_Diskussion:Schraubenbürschchen

Die Query hat keine 20 Sekunden gedauert. --Wurgl (Diskussion) 11:04, 9. Jul. 2019 (CEST)

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.

@PerfektesChaos: Wäre mir sehr recht, wenn du mal vorab deinen Senf dazu abgibst. --Wurgl (Diskussion) 16:10, 16. Jul. 2019 (CEST)

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.

FlagIcons rennen nicht weg.

LG --PerfektesChaos 16:16, 16. Jul. 2019 (CEST)

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)

Zwischenüberschrift wegen Abweichung vom Ursprungsthread

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)

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)

@Justus Nussbaum: Das findet schon seit 2013 genau so durch das Internet Archive statt. Der InternetArchiveBot fügt mittlerwelie Wayback- und andere Archivlinks nach und nach in die Artikel ein.--Cirdan ± 20:59, 3. Jul. 2019 (CEST)

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)

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)

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)

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.

VG --PerfektesChaos 16:36, 4. Jul. 2019 (CEST)

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)

@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)

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)

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.

Daß Metadaten zu Belegen auf Wikidata hinterlegt werden, ist übrigens nix neues, das passiert schon seit ein paar Jahren, und es dürften inzwischen tausende von Journal- oder Zeitungsartikeln sein, deren Metadaten dort verfügbar sind. Und man ist schon ziemlich weit, diese auch nutzbar zu machen, cf. meta:Wikidata:WikiProject Source MetaData/Bibliographic metadata for scholarly articles in Wikidata. --Matthiasb – ^{(CallMyCenter)} 01:00, 4. Jul. 2019 (CEST)

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)

WikiCon, Workshop & so

Schönen Dank erstmal für die Info.

• 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 --PerfektesChaos 17:27, 26. Sep. 2019 (CEST)

@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)

@Johanna Strodt (WMDE):

Ich antworte mal in mehreren Abschnitten, und heute noch nicht alle:

1. 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.
2. Präzisierung der Thematik „mit Vorlagen arbeiten“ – da gibt es rund fünf Rollen und Schwierigkeitsgrade, was aber aus der Projektseite nicht klar hervorgeht
   1. Mit einer vorhandenen Vorlage arbeiten; sie also ausfüllen, einfügen, Werte ändern
      • Einziger für Außenstehende relevanter Aspekt, insbesondere unter „Leichter arbeiten“.
   2. 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.
   3. 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.
   4. 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.
   5. 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.
3. 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.

VG --PerfektesChaos 17:32, 27. Sep. 2019 (CEST)

Schnellschusskommentar zu „Primäre Zielgruppen“ usw.

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:
    1. Lernen, was in anderen Artikeln zu ähnlichen Themen so vorkommt
    2. 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.
    3. 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.

VG --PerfektesChaos 19:16, 19. Nov. 2019 (CET)

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)

„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.

VG --PerfektesChaos 20:12, 26. Mär. 2020 (CET)

1. Prototyp: Suchfilter für ausgezeichnete Vorlagen

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.

• Feedback bitte hier einfügen (nicht signierter Beitrag von Michael Schönitzer (WMDE) (Diskussion | Beiträge) 16:49, 26. Mär. 2020 (CET))

• 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.
    1. Keine Weiterleitungen vorschlagen; bzw. erst nach allen anderen. Sind oft veraltete unerwünschte Namen; bei FlagIcons hingegen beabsichtigt.
    2. TemplateData vorhanden?
    3. Häufigkeit der projektweiten Einbindungen
    4. Absteigende Folge nach Nicht-TemplateData seltener benutzt
    5. 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.
  • Beispiel: Wir suchen Vorlage:Navigationsleiste Befehle der GNU core utilities.
    • 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.

VG --PerfektesChaos 18:04, 26. Mär. 2020 (CET)

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)

(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)

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ß, -- hgzh 18:47, 26. Mär. 2020 (CET)

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 Featured-Suche ist ja parallel trotzdem sinnvoll. -- DerFussi 19:02, 26. Mär. 2020 (CET)

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.

VG --PerfektesChaos 19:06, 26. Mär. 2020 (CET)

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)

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. -- DerFussi 19:25, 26. Mär. 2020 (CET)

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. -- DerFussi 19:36, 26. Mär. 2020 (CET)

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)

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)

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)

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)

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.

Fehlen mir hier noch zwei im Kontext verwendete Links: TemplateWizard und TemplateData -- Gelli1742 (Diskussion) 00:41, 27. Mär. 2020 (CET)

Anleitung für das Vorlagen erstellen

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)

Template:Interlanguage link

Ich denke es wäre jetzt auch eine Chance im Projekt Vorteile anderer wikis zu übernehmen. Aus meiner Sicht überfällig ist die Realisierung des Template:Interlanguage link der in vielen Sprachversionen vorteilhaft Verwendung findet. --Zieglhar (Diskussion) 12:04, 27. Mär. 2020 (CET)

Vorlagen aus wikisource

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)

Vorlage BibISSN

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)

javascript-Schnipsel

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 von Wurgl (Diskussion | Beiträge) )

Es sei auf Wikipedia:Technik/Browser/Bookmarklet verwiesen. Habe ich lange verwendet (für die Internetquelle), aber hatte für mich nur so lange einen Wert, wie ich mit dem alten Quelltext-Editor gearbeitet habe, ist also mE nicht unbedingt zukunftsträchtig.–XanonymusX (Diskussion) 17:31, 27. Mär. 2020 (CET)

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.

VG --PerfektesChaos 17:38, 27. Mär. 2020 (CET)

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:Wfb, 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)

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. --Mabschaaf 19:55, 27. Mär. 2020 (CET)

Karten

Leichtere Einbeziehung von OpenStreetMap.--Albin Schmitt (Diskussion) 14:55, 12. Apr. 2020 (CEST)

Mein Vorschlag für die Integration von Vorlagen in den VisualEditor

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:

X Vorlage einfügen Einfügen
Kategorien Infoboxen Wartungsbausteine Weitere Bausteine Sonstiges	Nach einer Vorlage suchen Vorlage hinzufügen

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.

Bei „Infobox“ könnte das Menü so aussehen:

X Vorlage einfügen Einfügen

Kategorien Sport und Spiel American Football Fußballspieler Infoboxen Bauwerk Fußball Fußballklub Wartungsbausteine Geographie und Geologie Handball Fußballiga Weitere Bausteine Geschichte Motorsport Fußballnationalmannschaft Sonstiges Naturwissenschaften Wintersport Fußballsaison

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:

X Infobox Fußballspieler Einfügen

0 Die Vorlage beim Speichern durch ihren Quelltext ersetzen Bild Suchen Hochladen Bild Beckswimbledon.jpg Beckham bei den Wimbledon Championships 2014 Ändern Jugendvereinsstationen Zeitraum Teamname der Station Leistungsdaten Eintrag hinzufügen Vereinsstationen Zeitraum Teamname der Station Leistungsdaten Vertragsstatus: Leihe? 1992–2003 Manchester United 265 (62) 0 1995 Preston North End 5 (2) 2003–2007 Real Madrid 116 (13) 0 2007-2012 La Galaxy 98 (18) 0 2009 AC Mailand 18 (2) 2010 AC Mailand 11 (0) 2013 Paris Saint-Germain 10 (0) 0 Eintrag hinzufügen Nationalmannschafts-Stationen Hinzufügen Zurzeit aktiv 0 Geschlecht Männlich

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
  1. Bild (Siehe oben)
     • String: Parameter für die Bildbeschreibung
     • String: Parameter für die Bildgröße
     • String: Parameter für den Alternativtext
  2. Unformatierter Text (Verwendet den alten Editor, Text soll nicht formatiert werden)
  3. Formatierter Text (Ermöglich Formatierungen mit einem WYSIWYG-Editor)
  4. 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)
  5. 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!)
  6. 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)
  7. Boolean (Kästchen, siehe oben)
     • String: Wert bei „falsch“ (wird in den Quelltext geschrieben)
     • String: Wert bei „wahr“ (wird in den Quelltext geschrieben)
  8. Dropdown
     • Array: Werte
       1. Sting: Bezeichner (Wird in der Drop-Down-Liste zur Auswahl angeboten)
       2. Sting: Quelltext (Wird in den Artikel eingefügt)
• Ganzzahl: Notwendigkeit
  1. 0 (Normal, wird nicht standardmäßig angezeigt)
  2. 1 (Empfohlen, wird standardmäßig angezeigt)
  3. 2 (Dringend empfohlen, steht ganz oben, kann nicht gelöscht werden)
  4. 3 (Erforderlich, beim Weglassen sieht die Seite dennoch richtig aus)
  5. 4 (Dringend erforderlich, die Vorlage kann nur mit dem Parameter richtig dargestellt werden oder produziert eine Fehlermeldung)
  6. 7 (Parameter im VE nicht anzeigen)
  7. 8 (Legacy, für veraltete Parameter)
• String: Hinweis für Legacy
• Ganzzahl: Parameter in den Quelltext einfügen…
  1. 0 (Unset, immer wenn der Parameter im VE angezeigt wird, kommt er auch in den Quelltext - selber Müll wie früher)
  2. 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)
  3. 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)
  1. e-mail (E-Mail-Adressen)
  2. number (Zahlen)
  3. web (Webadresse)
  4. 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

FF-11 (Diskussion | Bewertung | Beiträge) • Mitglied der Jungwikipedianer 22:31, 15. Apr. 2020 (CEST)

Arbeiten mit Vorlagen

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)

Vorlagen-Unterseiten und Seiteneinbindungen

Zwei Hinweise zu Vorlagenproblemen im VisualEditor:

1. 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.
2. 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.

Gruß--XanonymusX (Diskussion) 23:44, 26. Apr. 2020 (CEST)

Prototyp 2: Verbesserte Syntaxhervorhebung

Wir freuen uns auf euer Feedback. Dabei interessiert uns insbesondere:

• Würdest du diese Änderungen hilfreich finden?
• Wie würden sie sich auf deine Arbeit mit Vorlagen auswirken?
• Von welchem Vorschlag bist du am meisten begeistert?