Entwurf einer Spezifikation für globale Vorlagen
Dies ist ein Vorschlag für die funktionalen Anforderungen an globale Vorlagen und Module.
Du kannst auch eine kurze Beschreibung dieses Vorschlags lesen.
Dieses Projekt wird weder durchgeführt noch ist eine Durchführung durch irgendjemand zu irgendeinem Zeitpunkt in Planung, zumindest noch nicht. Es handelt sich nur um eine Idee, wenn auch um eine sehr detaillierte.
Das letztendliche Ziel ist ein team- und projektübergreifenden Bekenntis zur Implementierung dieser Dinge, mit ordentlicher Architektur, Produkt- und Projektmanagement, Community-Einbindung, usw.
Dieses Dokument befasst sich nicht mit Details der technischen Implementierung in Hinsicht auf Speicherung, Caching, Ausbringung, Design von PHP-Code, usw. Es versucht nur, die Anforderungen zu definieren, wie diese Funktionalität aus Sicht der Benutzer*innen aussehen wird:
- Personen, welche Vorlagen und Module erstellen und warten.
- Personen, welche Seiten erstellen und bearbeiten, die Vorlagen und Module einbinden. Das schließt alle Bearbeiter ein und alle Arten von Seiten:
- Alle Erfahrungsniveaus: von kompletten Neulingen bis zu solchen, die tausende Bearbeitungen hinter sich haben
- Alle Arten von Bearbeitungswerkzeugen: Bearbeitung von Wiki-Syntax, VisualEditor, Inhaltsübersetzung, und andere (selbst Betrieb von Bots)
- Alle Wikis: Wikipedia, Wiktionary, WikiVoyage, Wikidata, Incubator, usw., und zukünftige neue Projekte
- Alle Sprachen: Englisch, Französisch, Russisch, Spanisch, Armenisch, Persisch, Zulu, Manipuri, usw.
- Alle Arten von Seiten: Wikipedia-Artikel, Artikeldiskussionsseiten, Benutzerdiskussionsseiten, Projektdiskussionsseiten, Seiten von WikiProjekten, Kategorien, Dokumentationsseiten von Vorlagen, usw. {{🌎🌍🌏}}
Elevator Pitch
Ein großer Teil der Funktionalität von Wikimedia-Seiten ist in Vorlagen und Lua-Modulen implementiert. In ihrer gegenwärtigen Form können diese nicht zwischen verschiedenen Wikis und Sprachen geteilt werden. Aus diesem Grund ist es schwierig, sie mit modernen Arten der Artikelerstellung und -bearbeitung zu integrieren, etwa VisualEditor, Wikidata, und Inhaltsübersetzung. Auch ist es schwierig, sie auf Mobilgeräte anzupassen. Dadurch wird Zeit von Beitragenden vergeudet und es bestehen Schwierigkeiten für neue Beitragende und kleinere Projekte. Es muss möglich werden, sie zwischen Wiki-Seiten zu teilen, ähnlich wie Bilder auf Commons. Dadurch wird Software-Entwicklung schneller und robuster und Beitragende können sich mehr darauf konzentrieren, Text zu schreiben. {{🌎🌍🌏}}
Das Problem
Allgemeine Anmerkung: Wo nicht anders angegeben, beziehen sich Verweise auf „Vorlagen“ auch auf Scribunto-Lua-Module.
Vorlagen implementieren Funktionalität von Wikimedia-Seiten. Einige dieser Funktionen sind hochgradig sichtbar, besonders Infoboxen, Einzelnachweise, „citation needed“ (nicht in der deutschsprachigen Wikipedia), und viele weitere mehr. Alle Leser*innen sehen sie, und alle Beitragenden treffen bei fast jeder Bearbeitung auf sie. Zusätzlich implementieren sie viele der internen Kommunikationsmittel der Projekte: Löschanträge, Sperrprüfungen, Ausdruck von Zustimmung in Diskussionen, Sortierung von Artikeln in WikiProjekten, usw.
Vorlagen bieten einen effizienten Weg, um sich wiederholende Text- und Formatierungsabschnitte schnell zu entwerfen und einzusetzen. Allerdings haben Vorlagen auch mehrere empfindliche Nutzbarkeitsprobleme für alle Arten von Beitragenden.
Schwierigkeiten für alle Beitragenden in allen Wikis
Beiträge via Wikitext
Vorlagen sind für Beitragende in Wiki-Syntax oft schwer zu verstehen. Personen, die Erfahrung mit einer bestimmten Vorlage haben, werden sie vermutlich erkennen und in der Lage sein, eine Seite zu bearbeiten, welche sie verwendet. Allerdings müssen Beitragende, die sich mit einer Vorlage nicht auskennen, ihre Dokumentation nachschlagen, wenn sie auf sie treffen, selbst wenn sie generell erfahren im Umgang mit anderen Vorlagen sind. Und Beitragende mit wenig Erfahrung werden vom mysteriösen Text mit geschweiften Klammern, senkrechten Strichen, Gleichheitszeichen usw. verwirrt sein.
Um eine Funktionalität zu verwenden, die als Vorlage implementiert is, muss man den Namen der Vorlage kennen und ihn in geschweiften Klammern eingeben (<nowikii>{{}}</nowiki>) oder die Vorlage aus einer anderen Seite kopieren. Das ist für Neulinge nicht offensichtlich, und erfahrene Beitragende müssen jede neue Vorlage ebenfalls separat erlernen.
Einige Wikis haben Helferlein, welche Buttons zur Editor-Symbolleiste hinzufügen, die in diesem Projekt häufig verwendete Vorlagen einfügen. Diese sind in jedem Wiki unterschiedlich, obwohl viele der Vorlagen zwischen den Projekten und Sprachen sich in der Funktionalität ähneln.
Beiträge via VisualEditor
VisualEditor-Benutzer*innen haben einige Vorteile dabei, Vorlagen zu verwenden, allerdings gibt es auch hier viele Probleme damit. Insbesondere gibt es ein ähnliches Problem mit der Auffindbarkeit: Im VisualEditor ist die gesamte Vorlagen-Funktionalität hinter dem „Einfügen → Vorlage“-Menüeintrag verborgen, und Beitragende müssen den Namen der Vorlage kennen, um sie zu verwenden.
Das „Einfügen“-Menü des VisualEditor hat Einträge für mathematische Formeln, ägyptische Hieroglyphen, Musiknoten, und einige andere Funktionen, die als Erweiterungen umgesetzt sind, aber hat keine Einträge wie „Infobox“, „citation needed“ (nicht in der deutschsprachigen Wikipedia), „Einheitenumwandlung“, „Zitat“, usw. Alle Vorlagen sind der gleiche generische Menüeintrag.
Es gibt eine namhafte Ausnahme: Einige Wikis haben einen „Belegen“-Button, welcher Fußnoten mit Einzelnachweis-Vorlagen einfügt. Diese Ausnahme bestätigt allerdings nur die Regel. Sie erfordert manuelle Konfiguration selbst für grundlegende Funktionalität, diese Konfiguration ist in jedem Wiki separat, und infolgedessen gibt es in vielen Wikis diesen Button überhaupt nicht. Eine vergleichbare Ausnahme, die Ende 2019 hinzugefügt wurde, ist spezielle Unterstützung für „citation needed“-Vorlagen (nicht in der deutschsprachigen Wikipedia), aber auch das benötigt etwas maßgeschneiderte Konfiguration in jedem einzelnen Wiki, um zu funktionieren.
Schwierigkeiten für Beitragende in mehr als einem Projekt
Viele Vorlagen existieren nur in einem Projekt, aber nicht in anderen, und oft ist eine Vorlage verfügbar, aber in einer anderen Form. Aus diesem Grund ist es schwierig oder unmöglich, in einem Projekt gelernte Kompetenzen wieder anzuwenden: die Funktionalität, welche eine Vorlage anbietet, ist manchmal nicht verfügbar und manchmal funktioniert sie anders. Das betrifft nicht nur Wikis in verschiedenen Sprachen, sondern auch verschiedene Wikis in der gleichen Sprache, zum Beispiel die englischsprachige Wikipedia und englischsprachige Wikisource.
Für Personen, die in verschiedenen Sprachen arbeiten, erschweren Vorlagen die Übersetzung. Wenn eine Seite übersetzt wird, sind Vorlagen viel schwerer zu behandeln als der Artikeltext („Prosa“), gleich ob die Übersetzung von Hand oder durch Inhaltsübersetzung geschieht. Beitragende müssen oft die Vorlage überspringen oder nach Veröffentlichung des Artikels korrigieren. Dies führt auch dazu, dass bereits begonnene Übersetzungen abgebrochen werden, da Übersetzung von Vorlagen einschüchternd wirkt.
Die am häufigsten gemeldeten Probleme mit der Inhaltsübersetzung betreffen Vorlagen.
Inhaltsübersetzung hat eine Funktion zur Anpassung von Vorlagen, welche einige Teile dieses Prozesses automatisiert, aber sie funktioniert nur, wenn entsprechende Vorlagen in beiden Sprachen zur Verfügung stehen, und wenn alle Parameter fein säuberlich durch die Vorlagen-Autor*innen abgebildet werden. Diese Arbeit muss für jede Vorlage in jeder Sprache separat und manuell vollbracht werden, und muss ständig instand gehalten werden, wenn sich die ursprüngliche Vorlage ändert. Und das, obwohl die Funktionalität der Vorlage sich zwischen verschiedenen Sprachen meist nicht groß ändert.
Idealerweise sollten die Vorlagen und ihre Parameter fast vollständig automatisch auf die übersetzte Seite übertragen werden können, so dass Übersetzer*innen sich auf das Prosaschreiben konzentrieren können, weil das der Bereich ist, wo menschliche Arbeit am meisten vonnöten ist.
Eine Vorlage kann von einem Wiki zu einem anderen exportiert werden, aber nachdem dies geschehen ist, wird die Vorlage zu einer abgespaltenen Kopie. Sie bleibt entweder in dem Zustand, in welchem sie exportiert wurde, oder wird weiterhin separat entwickelt, was zu Inkompatibilät führt. Manchmal warten Leute die verschiedenen Kopien, aber das ist nicht robust und lässt sich nicht auf die hunderten von Wikis, die wir haben, übertragen.
Vorlagenparameter können in verschiedenen Wikis die gleiche Funktion, aber unterschiedliche Namen haben. Sie können durch TemplateData-Aliasse angepasst werden, aber das ist ein suboptimaler Notbehelf: TemplateData ist nicht dafür ausgelegt, und es muss für jedes Sprachpaar von Hand eingestellt werden.
Vorlagen vermischen algorithmische Logik, menschenlesbare Zeichenketten, und Formatierung. Aus diesem Grund gibt es keinen zuverlässigen Weg, die Texte der Benutzeroberfläche einer Vorlage zu übersetzen, wie es mit MediaWiki und seinen Erweiterungen geschieht.
Schwierigkeiten für Beitragende in kleineren Wikis
Ein neues Wiki-Projekt wird angelegt, indem MediaWiki installiert wird und eine Standardauswahl von Erweiterungen aktiviert wird. In der Praxis schafft dies keine fairen Bedingungen, weil viele Schlüsselfunktionen größerer Wikis in Vorlagen implementiert sind: Infoboxen, Einzelnachweise, Wartungsbausteine (wie etwa {{Belege fehlen}}), usw.
Schwierigkeiten für Software-Entwickler*innen
Für Entwickler*innen von MediaWiki, seinen Erweiterungen, Bots, und anderen Werkzeugen, welche den Inhalt von Wiki-Seiten analysieren, generieren, oder modifizieren, ist es schwierig, Funktionen zu entwickeln, die sich auf die Verfügbarkeit bestimmter Vorlagen in einem Wiki stützen. Entwickler*innen solcher Erweiterungen wie GrowthExperiments, PageTriage, ContentTranslation, einiger Teile von Wikibase, und vieler anderer, müssen sie entweder in den realen Wikis testen, was eine schlechte Idee ist, oder die Vorlagen in ihre lokalen Wikis oder ein online verfügbares Testwiki importieren.
Forscher*innen, welche Daten über Wiki-Inhalte basierend auf Vorlagen gewinnen, müssen ihren Code zur Analyse für jedes Wiki separat schreiben, und manchmal belassen sie es bei nur einem Wiki. Ein wichtiges Beispiel ist die Verwendung der WikiProjekt-Vorlagen der englischsprachigen Wikipedia, um Seitenthemen zu analysieren und die Qualität von Artikeln zu beurteilen. {{🌎🌍🌏}}
Annahmen
Erweiterungen und Vorlagen: Ähnlichkeiten und Unterschiede
Eine der Hauptannahmen dieses Projektvorschlags ist, dass Vorlagen und Module der MediaWiki-Kernsoftware und Erweiterungen sehr ähnlich sind: es handelt sich um Software, die Funktionen implementiert, welche die Beitragenden brauchen. Insbesondere ist es, da die Vorlagen üblicherweise von den Beitragenden selbst entwickelt werden, offensichtlich, dass die Gemeinschaft sie wirklich braucht. Die großen Unterschiede liegen darin, wie sie entwickelt, übersetzt, und ausgebracht werden.
Vorlagen und Module sollten in einigen Kerneigenschaften, welche ihnen aktuell fehlen, Erweiterungen ähneln, und sollten einige vorteilhafte Eigenschaften beibehalten, die bei Erweiterungen fehlen. (Die folgende Tabelle verwendet Beispiele aus der englischsprachigen Wikipedia, aber sie könnten auch aus jedem anderen Wiki und jeder anderen Sprache stammen.)
| Eigenschaft | Kernsoftware und Erweiterungen | Vorlagen | Was sollte hier mit Vorlagen geschehen? |
|---|---|---|---|
| Implementieren spezielle Inhalte | Ja.
Bilder, mathematische Formeln, Hieroglyphen, Musiknoten, Einzelnachweise |
Ja. | |
| └ spezielle Inhalte können einfach zu Seiten hinzugefügt werden | Ja (über das Menü). | Nein (außer man hat gelernt, wie es geht). | Sollte geändert werden. |
| └ spezielle Inhalte können leicht an Mobilgeräte angepasst werden | Größtenteils ja. | Manchmal. | Sollte geändert werden. |
| └ spezielle Inhalte können innerhalb von Artikeln einfach übersetzt werden | Größtenteils ja. | Nein. | Sollte geändert werden. |
| Implementieren Formatierungsoptionen für Seiten | Ja.
gallery, poem |
Ja. | |
| Implementieren Arbeitsprozesse der Gemeinschaft | Ja.
Bearbeitungsfilter, Checkuser, Verschieben |
Ja. | Wiederverwendung sollte einfach möglich, aber nicht zwingend erforderlich sein. |
| Initiale Version kann leicht ausgebracht werden | Nein. | Ja. | Sollte beibehalten werden. |
| Änderungen können leicht ausgebracht werden | Nein. | Ja. | Sollte beibehalten werden. |
| Kann leicht übersetzt werden | Ja. | Nein. | Sollte geändert werden. |
| Nützlich auf mehreren Wikis | Oft. | Oft. | |
| Nur auf einer begrenzten Menge an Wikis verwendet | Manchmal. | Manchmal. | |
| Kann einfach auf mehreren Wikis installiert und verwendet werden | Ja. | Nein. | Sollte geändert werden. |
| Kann einfach auf einem neuen, kürzlich erstellten Wiki verwendet werden | Ja. | Nein. | Sollte geändert werden. |
Entwicklungsfähigkeiten für Vorlagen und Module
Einige weitere wichtige Annahmen, auf denen dieser Vorschlag basiert, sind die folgenden:
- Die Fähigkeiten, Vorlagen und Module zu entwickeln, sind nicht trivial. Sowohl Vorlagen als auch Module haben viele obskure Funktionen.
- Obwohl viele der bemerkenswertesten Funktionen der Seiten als Vorlagen und Module implementiert sind, werden diese Fähigkeiten oft nicht erkannt, zu wenig gewürdigt, und als gegeben angenommen.
- Es gibt dutzende Personen, die über diese Fähigkeiten verfügen, und sie bearbeiten auf vielen Wikis. Sie konzentrieren sich meist auf ihr Heimatwiki und kommunizieren eher selten mit Beitragenden anderer Wikis oder Sprachen. Obwohl die grundlegende Technologie überall die gleiche ist, gibt es keine wirklich globale Gemeinschaft von Vorlagenentwickler*innen, welche zur globalen Gemeinschaft an MediaWiki- und Erweiterungsentwickler*innen vergleichbar wäre. Es gibt Fälle von Zusammenarbeit an bestimmten Vorlagen zwischen Wikis, aber sie sind inkonsistent.
- Es gibt auch viele Wikis, wo keine Beitragenden über diese Fähigkeiten verfügen. Sie kopieren entweder Vorlagen und Module von anderen Wikis, ohne ihre Funktionsweise vollständig zu verstehen und ohne zu wissen, wie sie effektiv übersetzt und gewartet werden können, oder sie verwenden überhaupt keine Vorlagen.
Diese Situation ist alles andere als optimal. Die Fähigkeiten von Vorlagen- und Modulentwickler*innen müssen mehr gewürdigt werden. Sie entwickeln stark benötigte Funktionen, und sie sind Teil ihrer jeweiligen Gemeinschaft an Beitragenden. In mehrsprachigen Wikis finden sie innovative Lösungen für strukturierte Inhalte, Datenaufmachung, und Modularisierung. Diese Innovationen könnten für viele Wikis nützlich sein, aber es gibt aktuell keinen geeigneten Mechanismus, um dies zu erreichen.
Und natürlich darf keine Lösung für diese Probleme völlig neue Technologien erfinden, welche die über viele Jahre erworbene praktische Erfahrung der Vorlagen-Entwickler*innen verwirft. Deshalb muss es so wenig Änderungen wie möglich an der Syntax zur Entwicklung von Vorlagen und Modulen geben. Was sich ändern muss, ist die Art und Weise, auf die sie ausgebracht und zwischen Wikis verteilt werden, und auf die ihre menschenlesbaren Texte übersetzt werden.
{{🌎🌍🌏}}
Die vorgeschlagene Lösung: Zusammenfassung
Viele MediaWiki-Funktionen sind bereits global und Wiki-übergreifend:
- * Bilder (über Commons)
- Sperren
- Benutzerkonten (CentralAuth)
- Einstellungen
- Benutzerseiten
- persönliche JS- und CSS-Seiten
- global watchlist is in active development as of late 2020 (GlobalWatchlist)
- und einige andere.
Es muss möglich sein, auch Vorlagen und Module in einem globalen Aufbewahrungsort zu speichern, und sie so robust wie Erweiterungen zu übersetzen.
Globale Vorlagen und Module ermächtigen Vorlagen-Entwickler*innen in allen Wikis und erlauben es ihnen, einfacher am Code der Vorlagen zusammenzuarbeiten.
Globale Vorlagen und Module ermächtigen Übersetzer*innen und ermöglichen es ihnen, sich auf die Übersetzung der Oberflächen-Texte („Nachrichten“) zu konzentrieren, ohne im Code nach Zeichenketten suchen zu müssen, und erlauben ihnen, die gleichen Fähigkeiten und Werkzeuge zur Übersetzung von Vorlagen und von MediaWiki-Erweiterungen einzusetzen.
Globale Vorlagen und Module ermächtigen inhaltlich Beitragende in allen Wikis und lassen sie Inhalte schreiben und übersetzen, welche diese Vorlagen verwenden, ohne Zeit auf die Unterschiede vergeuden oder in jedem Wiki verschiedene Regeln und Fähigkeiten lernen zu müssen.
Die Syntax, um Vorlagen und Module zu bearbeiten, und der allgemeine Arbeitsablauf zur Wartung und Ausbringung von Vorlagen werden sich nicht ändern, so dass alle Fähigkeiten, welche die Vorlagen-Bearbeiter*innen sich über Jahre angeeignet haben, ihre Relevanz behalten.
Alle Wikis werden in der Lage sein, die globalen Vorlagen zu verwenden, aber nicht dazu gezwungen sein. Gemeinschaften werden die Fähigkeit, jegliche globale Funktionalitäten, Designs, Arbeitsprozesse, oder Daten lokal zu ersetzen, beibehalten.
Vorlagen zu übersetzen wird so einfach sein, wie Mediawiki-Erweiterungen zu übersetzen. {{🌎🌍🌏}}
Die vorgeschlagene Lösung: Detaillierte Anforderungen
Vorlagen müssen semantisch und global sein können
Semantisch heißt, dass es für andere Software, besonders VisualEditor und Inhaltsübersetzung, eine allgemeine Möglichkeit geben muss, zu verstehen, dass eine Vorlage existiert und dass sie bestimmte Funktionen anbietet, damit es möglich ist, sie in eine Seite als Infobox, Einzelnachweis, Wartungshinweis, usw. einzufügen, und nicht nur als generische Vorlage. Aktuell kommt TemplateData dieser Anforderung am nächsten, dort werden aber nur die Parameter einer Vorlage beschrieben. Das hilft zum Beispiel nicht dabei, einen „Infobox einfügen“-Button zum VisualEditor hinzuzufügen. It doesn’t, for example, help Visual Editor add an “Insert infobox” button to the toolbar.
Global heißt, dass der Code einer Vorlage an einer Stelle gewartet wird und in allen Wikis zur Verfügung steht.
Vorlagen semantisch machen
Vorlagen sind nie robust semantisch gewesen, also so, dass sie einfach von Software, die mit Seiten arbeitet, verarbeitet werden könnten.
Es gibt nur wenige Beispiele von Vorlagen, die semantisch gemacht wurden:
- Verschiedene Vorlagen für Einzelnachweise, die im VisualEditor-Menü unter dem „Belegen“-Button verfügbar sind. Sie benötigen viel separaten Code, um Citoid auf jedem Wiki, das sie verwenden will, zu konfigurieren.
- „Citation needed”, was Ende 2019 für den VisualEditor angepasst wurde. Benötigt ebenfalls Konfiguration auf jedem Wiki. Zum Beispiel: Englisch, Hebräisch, Slowenisch. Stand der Verfassung dieses Textes wurden Französisch, Spanisch und die meisten anderen Sprachen noch nicht entsprechend konfiguriert, obwohl sie ähnliche Vorlagen haben. (task T211243)
- Vorlagen, um Benutzer*innen in der Flow-Erweiterung zu erwähnen, welche ebenfalls lokale Konfiguration benötigen.
- Einige Forschungswerkzeuge und Helfer zur Verarbeitung von Daten-Dumps können die Seitenbeurteilungs-Vorlagen von WikiProjekten der englischsprachigen Wikipedia erkennen, welche dort üblicherweise zu Diskussionsseiten hinzugefügt werden.
- Die GrowthExperiments-Erweiterung schlägt Bearbeitenden Aufgaben vor, die in einem Artikel erledigt werden können, basierend auf den Vorlagen, welche darin eingebunden werden. Die Namen der Vorlagen müssen manuell konfiguriert werden, in dem JSON-Dateien separat in jedem Wiki geschrieben werden. Zum Beispiel: Tschechisch, Vietnamesisch, Koreanisch, Arabisch.
- Die PageTriage-Erweiterung ist so konfiguriert, dass sie mit den „hatnote“-Vorlagen der englischsprachigen Wikipedia funktioniert (auch als „Tags“ bekannt).
Im Fall von PageTriage werden im Grunde die Vorlagen eines einzelnen Wikis fest im Quelltext eingebaut, sodass die Erweiterung ohne signifikante Quelltextänderungen auf anderen Wikis nicht nutzbar ist. Selbst wenn die erforderliche Konfiguration auf jedem Wiki klein ist, so wie im Flow-Beispiel, ist sie immer noch nötig. Das skaliert nicht gut für die 900 Wikis, welche Wikimedia hat, und die tausende, welche es in Zukunft haben wird.
Diese Dinge sollten standardmäßig global sein, so dass sie zumindest in einer grundsätzlichen Standardkonfiguration auf jedem Wiki sofort durch Erweiterungen, Bots, Dump-Werkzeuge etc. verwendbar sind.
Speicherung und Auslieferung
Die globalen Vorlagen und Module können in einem zentralen Wiki gespeichert werden (Meta, Commons, oder ein ganz neues Wiki), und es könnte sogar Gerrit oder ein anderes Repository sein.
Die beste Lösung ist vermutlich, ein neues Wiki zu erstellen, worin sie gespeichert werden, ohne sie mit Bildern, genereller Diskussion usw. zu vermischen.
Gerrit zum Speichern von Vorlagen und Modulen zu verwenden, ist technisch möglich, verliert aber ein wichtiges Element der Zugänglichkeit für Vorlagenbetreuende: eine Vorlage auf einer Wiki-Seite zu bearbeiten, ist viel einfacher und vertrauter für die große Mehrheit an Vorlagenbetreunden, als Git-Commits zu erstellen und auf Code-Review zu warten. Deshalb sollte Gerrit vermutlich nicht zu einer Option zur Speicherung von Vorlagen- und Modulquelltext werden, zumindest nicht zur primären.
Globale Vorlagen und Module müssen in einem gemeinsamen Aufbewahrungsort gespeichert werden, wo sie von den meisten Bearbeitenden anderer Wikis bearbeitet werden können. Regeln bezüglich Blockierung und spezieller Erlaubnisse sollten zunächst ähnlich zu den Regeln anderer Wikis sein: alles sollte standardmäßig offen sein, und es muss möglich sein, sehr häufige, sensible, oder oft von Vandalismus betroffene Vorlagen zu schützen. Detailliertere Regeln über Seitenschutz können später durch die Gemeinschaft erarbeitet werden.
The code of the templates in the central repository will use the generic English names of tags such as <section>, parser functions such as {{#ifexist}} or {{#invoke}}, and magic words such as {{DISPLAYTITLE}}.
Wie die Vorlagen zu den Zielwikis ausgeliefert werden, ist eine Frage interner Entwicklung und Architektur, solange die anderen Anforderungen erfüllt werden. Diese Fragen wurden in der Vergangenheit durch einige Plattform-Entwickler*innen diskutiert, etwa im Kontext des Schatten-Namensraum-Projekts. Dieses Dokument versucht, die verwandten Fragen zu behandeln, wie es für Beitragende funktioniert, die eine Seite bearbeiten, welche eine Vorlage verwendet, oder die selbst eine Vorlage warten – wie man sie so schreibt, dass sie übersetzt werden kann; wie sie übersetzt wird; wie sie lokal angepasst wird; usw. Diese Fragen wurden in früheren technischen Diskussionen zu diesem Thema nicht hinreichend angesprochen.
Vorlagen müssen weiterhin einfach zu bearbeiten sein
Eine wichtige Eigenschaft davon, wie Vorlagen aktuell funktionieren, ist, dass sie genau wie Wiki-Seiten bearbeitet werden und nach der Veröffentlichung sofort in Effekt treten, ohne Überprüfung oder separate Ausbringung. Das ist zu einem gewissen Grad gefährlich, weil eine schlechte Bearbeitung viele Seiten ruinieren kann, aber tatsächlich funktioniert es meistens gut.
Diese Einfachheit muss erhalten bleiben. Die Mitglieder der Gemeinschaft, welche Vorlagen warten, werden höchstwahrscheinlich den Umzug auf ein System, das von ihnen erfordert, neue Fähigkeiten zu erlernen und jede Änderung einer erschöpfenden Überprüfungs- und Ausbringungsphase zu unterziehen, verweigern. Das heißt vermutlich, dass es nicht funktionieren wird, Vorlagen auf Gerrit zu speichern, es sei denn, der Prozess zur Überprüfung und Ausbringung wird viel leichter als für Erweiterungen.
Es muss möglich sein, einige Vorlagen nicht global zu machen
Nicht alle Vorlagen sollten zwangsweise global sein.
Tatsächlich sollten einige Vorlagen global sein, weil sie eine Funktion umsetzen, die auf eine bestimmte Sprache beschränkt ist. Solche Vorlagen müssen schon aufgrund ihres Wesens nicht übersetzt werden, und es sollte möglich sein, sowohl menschlichen Beitragenden als auch Übersetzungswerkzeugen (so wie Inhaltsübersetzung) darauf hinzuweisen, dass sie nicht angepasst werden müssen, und übersprungen oder ersetzt werden können. Das ist Teil des Ziels, Vorlagen semantischer zu machen.
Es muss möglich sein, einen Teil der Funktion oder des Erscheinungsbilds einer globalen Vorlage anzupassen
Keine Gemeinschaft sollte das Gefühl bekommen, dass bestimmt Funktionalität ihr durch eine mächtige externe Partei aufgezwungen wird, etwa die Gemeinschaft der englischsprachigen Wikipedia, die von Wikidata, die WMF, oder sonst irgendjemand. Globale Vorlagen sollten zum gemeinsamen Nutzen entwickelt und verwendet werden. Die meiste Zeit sollten sie für alle funktionieren.
Manchmal werden einige Gemeinschaften feste Meinungen dazu haben, dass eine bestimmte Funktion oder ein bestimmtes Design sich in ihrer Sprache oder ihrem Projekt unterscheidet, oder eine Infobox mit anderem Inhalt als in anderen Projekten zu zeigen, oder sie überhaupt nicht zu seigen. Die Fähigkeit, Dinge lokal zu überschreiben, muss von Beginn an gegeben sein. (Oder vielmehr darf sie nicht weggenommen werden.)
Eine globale Vorlage muss sofort in jedem Wiki nutzbar sein
Genauso wie eine globale Benutzerseite sofort in jedem Wiki zur Verfügung steht, in welchem keine lokale Benutzerseite existiert, so muss auch jede Vorlage und jedes Modul, die in der globalen Infrastruktur erstellt werden, sofort in jedem Wiki bereitstehen.
Dafür dürfen keine zusätzlichen Schritte erforderlich sein, etwa das Kopieren von Wiki-Seiten, die Erstellung von Hüllen-Vorlagen mit lokalem Namen, Mitwirkung von Administrator*innen, stundenlanges Warten bis Caches aktualisiert werden, usw.
Nachdem die zentrale Version aktualisiert wurde, wird die aktualisierte Version sofort überall gezeigt. Um Vandalismus vorzubeugen, wird die Gemeinschaft der Beitragenden Richtlinien zu Erlaubnissen und Schutzstufen entwickeln.
Wenn Texte der Benutzeroberfläche (auch als „Nachrichten“ bekannt) nicht übersetzt wurden, kann die Vorlage dennoch verwendet werden und die Texte werden in der Fallback-Sprache angezeigt. Siehe die Abschnitte zur Übersetzung für weitere Details.
Übersetzung von Texten für Endnutzer*innen
Es muss möglich sein, alle Texte für Endnutzer*innen zu übersetzen
Für die MediaWiki-Kernsoftware, Erweiterungen, sowie einige externe Werkzeuge wie Seitenaufrufe werden die Texte (Nachrichten), welche Endnutzer*innen angezeigt werden, bequem und robust auf translatewiki.net übersetzt. Dieses Übersetzungsverfahren ist zumindest einigen Beitragenden in allen Sprachen bekannt.
Für Vorlagen ist dies im Moment nicht möglich. Mehrsprachige Seiten wie Commons und mediawiki.org haben das “TNT”-System, um einige Vorlagen zu übersetzen, aber es ist sehr kompliziert und kann nicht für Wikipedia, Wikisource usw. wiederverwendet werden.
Idealerweise sollte es möglich sein, Vorlagen genau so wie MediaWiki und seine Erweiterungen zu übersetzen, auf einem Wiki mit der Translate-Erweiterung.
Der übersetzte Text muss sofort, nachdem die Übersetzung in der Translate-Oberfläche gespeichert wird, verfügbar werden.
Es mag möglich sein, die Text auf Wiki-Seiten direkt zu bearbeiten, aber am besten sollten sie hauptsächlich durch eine maßgeschneiderte Übersetzungsfunktion bearbeitet werden.
Übersetzer*innen sollten sich darauf konzentrieren können, nichts als Text zu übersetzen. Irgendwelchen Code drumherum zu sehen, macht für Leute, die keine Erfahrung mit Programmierung oder JSON-Dateien haben, schwieriger beizutragen. Zusätzlich ist es extrem lästig, Sprachen, die von rechts nach links geschrieben werden, in Textdateien direkt zu bearbeiten. Die Translate-Erweiterung löst bereits all diese Probleme.
Die Dokumentationsseiten für Vorlagen müssen auch übersetzbar sein. Es sollte meistens genügen, die Seiten-Übersetzungsfunktion der Translate-Erweiterung zu verwenden, aber möglicherweise werden einige Anpassungen nötig sein.
Die Sprache, in der die Texte dem Benutzer angezeigt werden
Vorlagen werden in erster Linie dann verwendet, wenn sie in den Inhalt integriert werden, so dass die übersetzten Nachrichten standardmäßig in der Inhaltssprache des Wikis angezeigt werden müssen.
Einige Vorlagen werden jedoch als UI-Elemente verwendet. Daher ist es vielleicht sinnvoll, die Anzeige der übersetzten Texte auch in der Benutzersprache zu erlauben, wenn diese sich von der Sprache des Wiki-Inhalts unterscheidet. Dies kann besonders für mehrsprachige Sites wie Commons, Wikidata, Meta und mediawiki.org von Bedeutung sein.
Wenn eine Übersetzung nicht verfügbar ist, müssen die üblichen Ausweich-Sprachketten von MediaWiki verwendet werden. Wenn zum Beispiel eine Nachricht nicht ins Quechua oder Guarani übersetzt existiert, wird sie auf Spanisch angezeigt, wenn sie nicht ins Baschkirische oder Tschuwaschische übersetzt existiert, wird sie auf Russisch angezeigt, und so weiter. Die letztendliche Ausweichsprache ist Englisch, wenn also diese Nachricht nicht ins Spanische oder Russische übersetzt wird, wird sie auf Englisch angezeigt.
Nachrichten-Schlüssel
Nachrichten sollten als Schlüssel dargestellt werden, ähnlich wie dies im MediaWiki-Kern, den Erweiterungen und Werkzeugen geschieht.
Das Schreiben von übersetzbaren Texte wird wahrscheinlich die größte Änderung im Prozess der Vorlagenentwicklung sein, an die sich die Vorlagenverwalter gewöhnen müssen. Hartkodierte Texte werden getrennt und in nach Schlüsseln geordnete Nachrichten verschoben werden müssen. Dies muss nicht nur für die Übersetzer, sondern auch für die Vorlagenverwalter so einfach wie möglich gemacht werden. Andernfalls werden sie es nicht wirklich tun, und die Funktion wird effektiv abgelehnt.
Um Schlüssel leicht global eindeutig zu machen, ist es wahrscheinlich OK, den globalen Vorlagennamen automatisch in den Nachrichtenschlüssel aufzunehmen.
Übergangswerkzeuge
Es sollte ein Werkzeug entwickelt werden, das die Überführung einer Vorlage oder eines Moduls in einen zentralen Speicher unterstützt. Es kann die folgenden Schritte durchführen:
- Eine Vorlage aus einem lokalen Wiki exportieren und sie in das globale Wiki importieren.
- Alle Vorlagen, die von dieser Vorlage verwendet werden, exportieren (Kaskadierung).
- Die menschenlesbaren Zeichenfolgen identifizieren, sie in eine Liste mit Schlüsseln konvertieren, und sie durch Schlüssel im Quellcode der Vorlage ersetzen.
- Die Dokumentationsseite und TemplateData der Vorlage importieren.
- Die erforderlichen CSS-Seiten importieren.
In den meisten Fällen kann dieser automatische Prozess wahrscheinlich keine voll verwendbare und robuste Vorlage oder ein Modul erstellen, aber er kann helfen, den Übergangsprozess zu beginnen.
Organisieren von Nachrichten
Die Translate-Erweiterung organisiert Botschaften nach Gruppen, die auch als "Projekte" bezeichnet werden und weiter nach Aggregatgruppen organisiert werden können. Zum Beispiel sind Article Placeholder, Score, und Poem alles Gruppen, die die entsprechenden MediaWiki-Erweiterungen repräsentieren, und sie sind alle in der Aggregatgruppe "Von Wikimedia verwendete Erweiterungen - Erweitert" enthalten, zusammen mit vielen anderen Erweiterungen.
Projekte, die MediaWiki-Erweiterungen repräsentieren, werden im Translatewiki-Repository in YAML-Dateien konfiguriert und in der Translate-Benutzeroberfläche in einem Projekt-Selektor, auch "Nachrichtengruppen-Selektor" genannt, angezeigt.
Da es viel mehr Vorlagen als Erweiterungen gibt, sind möglicherweise einige Änderungen in der Art und Weise erforderlich, wie die Erweiterung Translate Nachrichtengruppen behandelt, um die Übersetzung der Vorlagen zu ermöglichen.
Jede Vorlage sollte eine Nachrichtengruppe sein. Eng verwandte Vorlagen sollten in einer aggregierten Nachrichtengruppe gruppiert werden. Sie können den Kategorien, in denen sie gespeichert sind, ähnlich sein, und tatsächlich können die Kategorien sogar wiederverwendet werden. Dateien in einem Git-Repository zu bearbeiten, um diese Nachrichtengruppen zu organisieren, ist wahrscheinlich nicht wünschenswert, da es zu komplex und langsam ist.
Es wäre schön, die Gruppen- und Vorlagennamen so anzuzeigen, wie sie im Selektor lokalisiert sind, aber es ist auch OK, wenn sie in Englisch angezeigt werden. Wenn es gut genug für Erweiterungs-Lokalisierer ist, ist es auch gut genug für Vorlagen-Lokalisierer.
Vorlagen müssen als Nachrichtengruppen auf der Spezialseite Sprachstatistik der Erweiterung Translate (Special:LanguageStats) angezeigt werden. Dies wird Lokalisierern helfen, die zu übersetzenden Vorlagen zu finden. Dies sollte im Allgemeinen allen Meldungsgruppen ähnlich sein, aber es gibt einige besondere Überlegungen zu Vorlagen:
- Es wird Tausende von Vorlagen geben, es wird also schön sein, wenn das Design der Tabelle dem irgendwie entspricht.
- Die Tabelle sollte zeigen, auf wie vielen Seiten jede Vorlage übertragen wird, und es ermöglichen, die Zeilen nach dieser Zahl zu ordnen, um den Lokalisierern zu helfen, die Prioritäten zu setzen, was wichtiger zu übersetzen ist.
Finden, wie man eine Vorlage übersetzt
Jede Vorlagenbeschreibungsseite muss einen direkten Link zur Übersetzung in die Sprache des Benutzers haben.
Some templates use Wikidata labels as part of their UI instead of hard-coding strings. This is done at the moment in Wikidata Infobox on Commons, Infotaula persona (Infobox person) in the Catalan Wikipedia, and in several other templates. These labels and values can be localized in Wikidata itself. Such usage cannot cover all the needs of template localization, but it is legitimate and useful for particular purposes. As long as this is properly described in the template documentation, this can continue to be used, and probably doesn’t need special infrastructure adaptations. (Perhaps the translation of the relevant labels and values can be somehow integrated into the Translate interface for localizing the template, but this is optional.)
Message parameters and magic words
In core MediaWiki and extensions, many messages have parameters, sometimes also known as “placeholders”. They are named $1, $2, etc., and they are filled in run time. Parameters are particularly important for making messages robustly translatable because different languages have different word order.
Something like this is needed in templates, too, although it is possible that the form does not have to be $1, $2, but template-like parameters with triple curly braces ({{{}}}). This is to be decided according to considerations of parsing and localization convenience.
The magic words PLURAL, GENDER, and GRAMMAR must be supported in template messages as in MediaWiki messages.
Nachrichtendokumentation
In core MediaWiki and extensions, every translatable message is documented for the convenience of developers and translators. The documentation may include information about where the message appears, what the $1, $2, etc. parameters are, whether the word is a verb or an adjective, etc. This documentation is stored as pseudo-language with the code qqq.
Such documentation will be useful for template translation, too. How it is stored is a question of technical architecture. Perhaps it can be combined with TemplateData, perhaps it can be stored as a qqq language, and perhaps it can be something else.
Source language
Templates will be imported to the global storage not only from English-language projects, but from wikis in many languages. More than ever, the localization tools must support translation from any language and not only from English.
Fuzzying
In core MediaWiki and extensions and in translatable pages, if the source message in English changes, the message is automatically marked as outdated or “fuzzy”. The existing translations continue to work, but are shown to translators as needing an update. (The translation manager can also mark a message as not needing fuzzying.)
A similar mechanism will be needed for template localization. However, since it would be nice not to force English as the source language, there should be more ways to mark messages as fuzzy.
Localization considerations for modules
Lua modules can load and parse translatable MediaWiki strings, but there is no defined way for storing these strings for Lua modules that are maintained as wiki pages. It is possible to package Lua modules as parts of extensions, and then they are able to load messages from the extensions’ i18/*.json files, but this is done in very few extensions at the moment. Rewriting templates in Lua may be a more robust solution from the engineering point of view, but Lua will not necessarily be embraced by all existing template maintainers, and their cooperation will be crucial to the project’s success, so this cannot be done to all templates.
Some very internal, technical modules that are commonly used, rarely changed, and don’t require internationalization can probably be painlessly moved into the Scribunto extension itself. Some examples are No globals and Arguments.
Localizing the template name
The template may have a different name in every language, but it must be directly connected to the central storage.
Global templates and modules are supposed to be immediately usable in all wikis without any extra steps, so it must be possible to transclude a global template in a local wiki page using its global name. The cross-wiki editors community shall decide what will be the policy for these global names.
Similarly to parameter names, templates may have different names in different languages, and this must be preserved. There must be a structured way to translate template names. Perhaps Wikidata sitelinks can play a role, but not necessarily.
If this is not done, editors will either avoid global templates, or wrap the global template in a local template with a translated name, and this will probably cause the template to lose the connection to the global entity. This is not desirable and misses the whole point of the project.
Template names must only be translated to languages that can be content languages of wikis. Translation to Formal German or British English are probably unnecessary. There may be a way to have aliases or redirects. Language variants, for example for Serbian and Chinese, must be supported according to these languages’ needs.
If a local template exists in a wiki and has the same name as a localized name of a global template, the local template will be used. This is similar to how local files with identical names override global files on Commons, and how local messages in the MediaWiki space override the localization coming from the code.
Lua module names are often localized, too. Their names can be localized for direct invoking from wiki pages, but since code usually uses English-like identifiers, the internal global names should probably be preferred for use in the code itself, for example in require statements.
Localizing parameters
Localizing parameter names
Parameter names are different in every language. They are usually based on words in each language, so it’s important for editing the transclusion in wiki syntax conveniently.
Ideally, the global template should have generic internal parameter names that have translations to different languages. This is somewhat similar to Wikidata property name labels, but it can be simpler: since English is a lingua franca for software developers and templates are a kind of software, it’s probably OK to have English as the default source language rather than generic numbers as it is in Wikidata.
These generic parameter names will be the common default names. They will work in wikis in all languages. The localized names will work in the wikis that has that language as its content language.
These translations of parameter names must be validated:
- they must not include invalid characters
- they must not be repeated within one template in one language
- Anything else?
The actual process of translating the parameter names may be different from translating user interface strings. These names have technical constraints that must be enforced. They must also remain stable because changing a parameter name will break existing transclusions, so there should be some safeguards against changing them too often.
Automatic parameter translation
If all the localized template and parameter names are stored centrally, it will be possible to have a simple service that gets a valid template call with parameters, a source language name, and a target language name, and outputs a localized template call. For example:
Eingabe:
{
sourcewiki: "enwiki",
targetwiki: "frwiki",
template: "{{Infobox writer|name=Ľudovít Štúr|birth_date=1815-10-28}}"
}
Ausgabe:
{
template: "{{Infobox Écrivain|nom=Ľudovít Štúr|date de naissance=1815-10-28}}"
}
In Content Translation, this will be the primary way to adapt templates. Unlike the current template adaptation in Content Translation, this will be precise and complete, rather than based on guesses.
In visual editing and in 2017-style wiki syntax editing, simply copying and pasting a template from wiki in another language will do the parameter translation automatically.
For plain wiki syntax editing, there should be a simple way to operate this service, for example a special page or a dialog box where an editor can paste the template and the source language, and get the template with translated parameters.
In both cases, only the names of the template and the parameters will be translated. Translating the parameter values is discussed separately.
Namenlose Parameter
Nameless numbered parameters must continue working, of course.
A decision is needed about how will their names be localized.
Parameterwerte übersetzen
In addition to making the templates’ functionality and design shared, some thought must be given to making the template parameter values shared, as well as not shared.
Some parameter values are the same in all languages by their nature. Some examples include an IPA pronunciation of a place’s native name (e.g. [dɛn ˈɦaːx] for The Hague), the year of foundation of a city, the chemical formula of a compound, etc. At least some of these should probably be stored in Wikidata and easily loadable in a template.
Some parameter values have to be translated or transliterated, for example people’s names, translations of country mottos, etc.
Global templates must make this possible, but in practice, these things are still often copied across wikis, and this must be taken into account as well.
Some parameter values can be reliably and predictably converted automatically, and the global templates infrastructure must support this. For example, number formats and digit characters are often different in Burmese, in languages of India, and in some other languages, but they can be reliably converted using simple software.
Valid and functional parameter values must be usable in multiple languages and must not be language-specific. For example, using “yes” and “no” as boolean values is too English-centric. This probably doesn’t require changes in the infrastructure, but mostly an agreement in the cross-wiki template development community on good practices for adaptation to all languages.
Text-Richtung
Templates must adapt themselves to the text direction (ltr / rtl) of the wiki in which they are displayed.
It must be convenient to write a template in a direction-neutral way, with as little explicit right and left alignment as possible.
Bots
Many templates in many wikis are regularly edited by bots. This capability must be preserved.
This is not supposed to require any changes in the software infrastructure, but it is mentioned here for completeness because it’s an important use case.
Transitioning the templates from the large wikis to central storage
The most popular source language for translation in Content Translation is English, by far. After it, come Spanish, Russian, French, German, Catalan, Ukrainian, Italian, Chinese, and Portuguese. Because of this, it makes sense that the common templates in the editions of Wikipedia in these most common languages, especially those in English, are the ones that are the most important to make global for the benefit of all other languages.
Somewhat paradoxically, however, the editors in these largest languages are also the least interested in making them global:
- The templates already work well for them, and most people there don’t directly care about the convenience of translation to other languages.
- Rewriting the templates so that the strings will be translatable may be time-consuming and may force them to learn some new template maintenance skills.
- Making the templates suddenly used by many more projects may make it harder to achieve consensus about making future changes in how the templates work.
- Editors from different major wikis will have to work on reaching consensus about merging some templates with similar functionality that already exist on their sites.
This is more of a consideration of practicality and community relations than a consideration of engineering, but it must be taken into account when making technical architectural decisions. Without doing proper preparation in this area, the whole project will fail.
As long as there are important common templates that are not global, Content Translation and other software that handles templates from different wikis in any way, will have to keep supporting them. If the infrastructure for global templates is created, and migration of existing templates proceeds in a good pace, developers may consider stopping developing and some day deprecating the code for non-global template adaptation.
The pace of migrating templates from large wikis to the central repository can be one of the success metrics for the project.
It must be possible to use templates completely in both wiki syntax and in visual editing
It’s obvious, but should be mentioned anyway: Wiki syntax editing is not going away soon, and it must be possible to keep editing template transclusions in pages as it is done now. This must not become more complicated.
However, Visual Editor is increasingly embraced by both experienced and new editors, so every feature of how templates work must work well in both visual and wiki syntax editing.
There are some features that deal with templates in core MediaWiki and its extensions. All of them must continue working, and may need updating for the global templates age.
Core MediaWiki
There should be on-wiki tools for showing at least basic analysis of templates’ and modules’ usage on pages: the number of transclusions and invocations grouped by wiki, and lists of pages that use the templates and the modules. The feature that shows which templates does a page transclude while it’s being edited must continue working with global templates.
The “Links auf diese Seite” page must keep working, and remain useful for global transclusions.
TemplateData
- It is possible to translate template and parameter descriptions in TemplateData, and the translations are displayed in the user interface language in Visual Editor’s template insertion dialog. This is good and must be preserved. The translation interface could possibly be improved, but the beginning is good. Adding support for TemplateData in the Translate extension can be a solution for this, but there can also be other solutions.
- The “Vorgeschlagene Wikitext-Formatierung” parameter (Inline, Block, Benutzerdefiniert) must keep working. It must also be possible to customize them per wiki—some wikis may prefer to see a certain template written in wiki syntax as one line, and some may prefer multiple lines.
Citoid
- Citoid has to be configured on every wiki separately using JSON files, such as Citoid-template-type-map.json. In the global templates age, it must become possible to share these files, so that the “Belegen” button would be available in all wikis and work identically everywhere by default. As with templates, there must be a way to override this default in each wiki where the community wants different behavior.
TemplateStyles
- There must be a possibility to write Template Styles pages in the same central repository as templates. The central style must be loaded by default, and it must be possible to override it locally.
TemplateSandbox
- Spezial:TemplateSandbox muss weiter funktionieren.
- It must be possible to edit a template in the central repository and preview it in a page in the target wiki.
TemplateWizard
- The current system uses a wiki’s standard search to find templates. The results are presented in a list that might need to be changed to make the global or local status visible.
- TemplateWizard gets its information for templates from the TemplateData API, so as long as that keeps returning the same structure there shouldn’t be any issues, and i18n is already working.
Wikibase
- Wikidata can be used to bring in some parameter values from a central repository to the wiki. This is used productively in Wikipedia in several languages, among them French, Hebrew, Basque, Russian, Catalan, Estonian, and some others, as well as in Commons, although the actual implementation may differ. This must continue working, of course. Unifying the way in which it is done across different wikis may become one of this project’s most significant impact areas.
- It may also make it much easier to implement Wikidata Bridge, the project to allow editing template values from within wikis. The modifications to the templates themselves will have to be done only once in the global templates, and not in each wiki.
VisualEditor
- Der VisualEditor muss natürlich in der Lage sein, sowohl globale als auch lokale Vorlagen einzufügen.
- VisualEditor shows a link to the template description page in the template editing dialog. This link should point directly to the global template when it is used.
Development and deployment
Developing the infrastructure for global templates and modules is a large and complex project. It must be divided into manageable parts to get done. Roughly, the multiple parts of this project should be developed in the following sequence:
- Translatable modules (in development): Before making the modules shareable across wikis, the framework for their internationalization and localization should be developed. This will be immediately useful to modules on wikis that are already multilingual, most notably Commons and Wikidata. Some of them are translated using Lua arrays or tricks with translatable pages, but this is not a full-fledged localization system.
- Global modules: Modules become shareable across wikis. This should happen before making templates shareable because the modules’ infrastructure is less coupled to core MediaWiki.
- Translatable templates: This is similar to Translatable modules above, and can reuse much of the same framework, but it will also need the capability to translate the names of the template itself and its parameters and some other features. See the sections on localization in the specification.
- Global templates: Complete the project with making the templates global.
The development of more advanced features, such as making templates semantic, can and should come later, after they are shareable. If they become semantic before they are shareable, the code that describes them semantically will be forked on different wikis, like the templates themselves, which will make code reuse even harder than it is today.
Access to global templates and modules will be available from all the Wikimedia wikis. This includes editions of Wikipedia, Wiktionary, Wikivoyage, etc. in all the languages, as well as Commons, Wikidata, Meta, mediawiki.org, Wikitech, etc., as well as test wikis (test.wikipedia.org, etc.) This is similar to how images on Commons are available on all the wikis. Even though the global templates and modules will be available to the wikis, the wikis won’t be obliged to use them.
Making templates easily reusable on non-Wikimedia projects may also be desirable. Even though it doesn’t directly benefit Wikimedia projects, it may make sense to consider making templates easily reusable not only across Wikimedia projects, but also on other MediaWiki sites. Doing this will probably require some more work, but it may contribute to better modularization, and this may eventually benefit Wikimedia projects, too. This is comparable to the capability of direct embedding of images from Commons on non-Wikimedia websites. {{🌎🌍🌏}}
Imagine a world
Imagine a world in which every single human being can freely share in the sum of all knowledge and it’s actually a really easy thing to do because templates are global:
| Aufgabe | Mit den aktuellen Vorlagensystem | Mit globalen Vorlagen |
|---|---|---|
| Insert an infobox using the Visual Editor |
Note that you will have to find the template name for each wiki separately, and in some wikis it will not work at all. |
Note that the above will work the same way in every wiki and in every language, unless specifically overridden. |
| Insert an infobox using the wiki syntax editor |
|
If you want, you can still do all the same things as with the current template system.
But you will also have these additional optional features:
|
| Use a nice template that you saw in a wiki in English, French, Russian, or Spanish in the wiki in your language |
|
If the template is in the global repository, then:
That’s it, the template is fully usable in your language. (And yes, this also has to be repeated for every language, but the same is true for MediaWiki extensions.) |
| Use the new features of a nice template that you once exported into your language from a wiki in English, French, Russian, or another language | Three options:
|
Just translate the new strings. All the new features are already available in all wikis. |
| Implement Wikidata Bridge (editing Wikidata’s data directly from infoboxes) | This is a project in a very early stage of design. However, it can probably be said already that with the current technology, implementing it will probably require changing every infobox template in every wiki according to instructions that will be published by Wikidata developers. | The infoboxes’ template code will only have to be changed once, and it will work for all the wikis. |
| Translate an article from English, French, or Russian into your language using Content Translation |
In this scenario, steps 4 and 7 may take more time than step 3. |
In this scenario, step 3 takes most of the time, steps 4 and 7 are very short, and the total time is shorter. |
| Copy a useful citation of an academic article from the Danish Wikipedia to the German Wikipedia (or between any other two languages) |
|
In Visual Editor: Copy and paste without having to wonder whether it will work
In the wiki syntax editor:
(In the 2017 wiki syntax editor, the template conversion tool can probably be integrated into the pasting action.) |
| Have a table of the latest results of the ongoing Tour de France in the Wikipedia your language
This scenario is based on an actual module, Cycling race. It is not used in the English Wikipedia because of disagreements about the design of the tables, but the community appears to be open about adopting it in the future if necessary changes are made. |
|
Practically all the languages get the whole table for free, without doing anything. All the work is done by the people who create the templates and the modules, once for everybody, and by the people who follow the events and update the results. A cross-wiki platform for developing and localizing the module and the template may facilitate the development of a design that is acceptable in all languages. |
| Start writing in a new wiki after the domain is created | After the content is imported from Incubator, there are no templates for infoboxes, references, userboxes, discussion management, marking pages for merging or deletion, etc.
Start copying these templates one by one, or create your own. Nice people from other wikis may help you, but they probably do not know your language, so you will have to manually translate all the strings (as in the scenario called “Use a nice template that you saw in a wiki in English, French, Russian, or Spanish in the wiki in your language”). You can also just give up and only write text, but then you will get fewer features: no infoboxes, no formatted citations, no deletion and merging workflows, etc. |
All those templates are already available. Just translate the strings in a translatewiki-like interface. |
| Use a navigation box while reading an article on a mobile phone | Unmöglich.
Navigation boxes are so difficult to adapt to mobile screens, and so different from each other across wikis, that the software just hides them. (And yes, there is demand for it.) |
Möglich.
Since the templates’ infrastructure is shared across languages, the different language communities can work with each other and with the developers of the mobile reading and editing interface and make them responsive. |
| Have a beautifully designed and mobile-friendly main page with regularly updating news, featured articles and images, etc. | Option 1: Find volunteers who know your language, as well as HTML and wiki syntax (especially tables and templates) very well and who have time to edit the main page every day. This is done separately and using different methods in every wiki. This happens in the top 70 wikis or so: English, Russian, French, Spanish, etc.
Option 2: If you can’t find anyone who knows your language and can also maintain the HTML code of the main page every day, copy the code from the main page from English or French and ask volunteers from other wikis, who don’t know your language, but know wiki syntax, to replace the picture of the day occasionally. Since they don’t know the language, they cannot maintain the text regularly, and you cannot do it because you are afraid of breaking the HTML code, so you get stuck with the same featured article on the main page for months or years. This happens in some of the smaller languages. Option 3: Give up and have a static main page, which most likely doesn’t work well on mobile devices, even though the main page is usually the top viewed page in a wiki. This happens in a lot of wikis, even if there’s other editing activity. |
Option 1: If you have people with the needed skills and time to maintain a manually crafted custom main page in your language, and you want to keep things that way, you can do it.
Option 2: If you don’t have the people who can do this manual work or if your community is fine with having a main page that looks similar to the one in other languages, put a simple centrally maintained template on your main page. Replace only the text of the changing items in an easy form, without having to deal with wiki syntax, tables, or HTML. The process is the same for most wikis, so the same templates and bots can be used by everyone who is interested. |
| Analyze how articles are sorted by WikiProjects for a research about Wikipedia |
|
|
(Note: The “With global templates” column assumes that the infrastructure is deployed in all Wikimedia wikis, and that the most often used templates are moved to the central infrastructure.)
{{🌎🌍🌏}}
Status
This section is about the general status of the project. For details about the latest developments, as well as a brief history of past efforts, see the page Global templates/Status.
As noted above, as of December 2020, this page is only a big idea, and not a commitment to implement a project.
Similar ideas were suggested in the past. The oldest known suggestion to make templates reusable across wikis was raised in December 2004 in Bugzilla: Interwiki templates (task T3126). Several other similar ideas were raised later, for example Phabricator task T6547. In February 2017 a similar proposal called Global-Wiki was closed as "consensus". Some of its components were implemented, such as global preferences, but not the templates.
The wish "Central global repository for templates, gadgets and Lua modules" was voted #3 at the Community Wishlist Survey 2015 and "Global gadgets" was voted #1 in Community Wishlist Survey 2016. Despite the community support, neither was implemented, because they weren’t appropriate for the Community Tech team, and they weren’t transferred to another team either.
The Platform Evolution project (2018) indicated some intentions to have support for global templates in the future. The page Platform Evolution/Recommendations discusses ideas for updating content modularity, and says:
- ... “boxes” are an ideal focus area for creating modularity. They represent self contained features and also an opportunity to enable equitable sharing of user features across projects and languages be establishing a cross-project service to share templates. This project will also force us to consider how to handle content layout and structure separately from composable pieces content.
The closely related page Platform Evolution/Goals lists this as one of the goals:
- Increase equity and power of contribution tools. We want to support the contribution of more content types of content, including media, in more interactive ways and across all projects. This means making some existing tools - like templates - available for consistent reuse across all projects and languages. It also means improving translation tools to remove silos of content. Finally, we also want to make it easy for contributors to create new cross-project, localizable content tools.
Abstract Wikipedia, which was approved by the WMF in July 2020 as a new project to be developed in the near future, includes “a cross-wiki repository to share templates and modules between the WMF projects” inside its Wikifunctions component as one of its major goals (Wikifunctions was previously known as “Wikilambda”).
The Translatable modules initiative was launched in September 2020. It addresses a part of this proposal.
In Community Wishlist Survey 2021, the wish titled “Templates translation” received the highest number of votes. It was also the wish with the highest number of votes in the history of the survey to date (December 2020). This wish closely corresponds with some parts of this proposal, especially Automatic parameter translation.
For other examples of the relationship between this Global templates proposal and various strategic plans in the wider Wikimedia community, see the page Global templates/Relationship to strategy.
There is no complete technical plan for implementing full-featured cross-wiki sharing of modules and templates. This page is an attempt to propose such a plan on a product level and listen to feedback from editors.
{{🌎🌍🌏}}
Nützliche Links
Some relevant pages that discuss similar topics:
- Platform Evolution/Goals
- Platform Evolution/Recommendations
- Multilingual Templates and Modules - An attempt to implement a similar feature using bots
- m:Community Wishlist Survey 2015/Results - Central Global Repository for Templates, Lua modules, and Gadgets came in as #3 in the Community Wishlist vote. Listed as “In development - Parsing team”, but not actually done.
- m:Which templates should be global? - an informal list made by various editors
- Requests for comment/Shadow namespaces - a dormant RFC about one proposal for a technical implementation of such an infrastructure
- Handbuch:$wgEnableScaryTranscluding - an existing rudimentary mechanism for transcluding content across projects. Considered inefficient and insecure, and disabled on Wikimedia projects.
- m:Global-Wiki - a similar proposal, with a wider scope. It was open for discussion for several years, and closed as "consensus". Some things in it were implemented, such as global user pages and preferences, but it also includes global templates, which are not yet done.
- m:Abstract Wikipedia - A bigger proposal, which includes a global module and template repository (also known as Wikifunctions, and previously known as “Wikilambda”).
- m:Community Wishlist Survey 2021/Translation/Templates translation - A community wish that corresponds to some parts of this proposal, especially Automatic parameter translation. {{🌎🌍🌏}}