Global templates/Proposed specification/nl



Dit is een voorstel voor de functionele vereisten voor globale sjablonen en modules.

U kunt ook een lezen.

'''Dit is geen project dat wordt uitgevoerd of gepland om door iemand op een bepaald moment in de tijd te worden uitgevoerd, althans nog niet. Dit is slechts een idee, zij het een zeer gedetailleerd idee.'''

Het uiteindelijke doel is om een team- en projectoverschrijdend betrokkenheid te vormen bij het implementeren van deze dingen, met de juiste architectuur, product- en projectmanagement, betrokkenheid van de gemeenschap, enz.

Dit document probeert niet in te gaan op de details van technische implementatie in termen van opslag, caching, levering, PHP-codeontwerp, enz. Het probeert alleen de vereisten te definiëren van hoe deze functie zal werken vanuit het oogpunt van de gebruikers:


 * 1) Mensen die sjablonen en modules maken en onderhouden.
 * 2) Mensen die pagina's maken en bewerken die sjablonen en modules bevatten. Dit omvat alle editors en alle soorten pagina's:
 * 3) * Alle ervaringsniveaus: van degenen die volledig nieuw zijn tot degenen die duizenden bewerkingen hebben uitgevoerd
 * 4) * Allerlei bewerkingshulpmiddelen: wiki-syntaxisbewerking, Visual Editor, Content Translation en andere (zelfs botoperators)
 * 5) * Alle wiki's: Wikipedia, Wikiwoordenboek, Wikivoyage, Wikidata, Incubator, etc., en eventuele nieuwe toekomstige projecten
 * 6) * Alle talen: Engels, Frans, Russisch, Spaans, Armeens, Perzisch, Zulu, Manipuri, enz.
 * 7) * Alle soorten pagina's: Wikipedia-artikelen, overlegpagina's met artikelen, overlegpagina's voor gebruikers, discussiepagina's voor de gemeenschap, WikiProject-pagina's, categorieën, sjabloondocumentatiepagina's, enz.



Moeilijk beginpunt
Een groot deel van de functionaliteit van Wikimedia-sites is geïmplementeerd in sjablonen en Lua-modules. In hun huidige vorm kunnen ze niet worden gedeeld tussen verschillende wiki's en talen. Hierdoor zijn ze moeilijk te integreren met moderne manieren om artikelen te maken en te bewerken, zoals Visual Editor, Wikidata en Content Translation. Ze zijn ook moeilijk aan te passen aan mobiele apparaten. Dit veroorzaakt verspilling van de inspanningen van bijdragers en problemen voor nieuwe redacteuren en kleinere projecten. Het moet mogelijk worden om ze te delen op wikisites, net als Commons-afbeeldingen. Dit zal softwareontwikkeling sneller en robuuster maken, en het zal redacteuren ook in staat stellen zich meer te concentreren op het schrijven.



Het probleem
Algemene opmerking: Tenzij anders vermeld, zijn alle verwijzingen naar "sjablonen" ook van toepassing op Lua modules.

Sjablonen implementeren functies van Wikimedia-sites. Sommige van deze functies zijn zeer prominent, vooral de infoboxen, de referenties, "citatie nodig" en vele anderen. Zie. Alle lezers zien ze en alle redacteuren komen ze tegen in bijna elke bewerkingsactie. Bovendien implementeren ze veel van de interne communitybeheerfuncties van de sites: verzoeken om verwijdering, verzoeken om deblokkering, het uiten van steun in discussies, het sorteren van artikelen voor WikiProjects, enz.

Sjablonen bieden een efficiënt mechanisme om snel repetitieve stukken tekst en markeringen op veel pagina's te ontwerpen, te implementeren en te gebruiken. Sjablonen hebben echter ook verschillende acute bruikbaarheidsproblemen voor allerlei soorten editors.



Moeilijkheden voor veel redacteuren in alle wiki's


Wiki syntaxis editors
Sjablonen zijn vaak moeilijk te begrijpen door de wiki-syntaxis. Mensen die ervaring hebben met het gebruik van een bepaald sjabloon, zullen een pagina kunnen bewerken die deze bevat. Redacteuren die niet bekend zijn met dit sjabloon, moeten echter de documentatie opzoeken wanneer ze het tegenkomen, zelfs als ze over het algemeen ervaring hebben met bewerken en van andere sjablonen. Redacteuren met weinig ervaring zullen staren naar de cryptische tekst met o.a. accolades, verticale streepjes en is-tekens

Als u een functie gebruikt die als sjabloon is geïmplementeerd, moet u de naam van de sjabloon kennen en deze tussen accolades ( – ) typen of van een andere pagina kopiëren. Dit is niet duidelijk voor nieuwe gebruikers en ervaren gebruikers moeten elke nieuwe sjabloon ook afzonderlijk leren.

Sommige wiki's hebben gadgets waarmee knoppen worden toegevoegd waarmee sjablonen die in dat project gebruikelijk zijn, worden ingevoegd in de werkbalk. Deze zijn verschillend in elke wiki, hoewel veel van de sjablonen vergelijkbare functionaliteit hebben voor projecten en talen.



Visual Editor gebruikers
VisualEditor-gebruikers hebben enkele voordelen met het gebruik van sjablonen, maar er zijn ook veel problemen voor hen. In het bijzonder is er een vergelijkbaar vindbaarheidsprobleem: in Visual Editor is alle functionaliteit van de sjablonen verborgen achter het menu-item " " en moet de gebruiker de sjabloonnaam kennen voordat hij deze kan gebruiken.

Het menu "" van Visual Editor bevat items voor wiskundige formules, Egyptische hiërogliefen, muziekpartituren en enkele andere functies die als extensies zijn geïmplementeerd, maar het heeft geen items zoals "Infobox", "Bronvermelding nodig", "Eenheid conversie", "Citeren", enz. Alle sjablonen zijn hetzelfde soort generieke item.

Er is één belangrijke uitzondering: sommige wiki's hebben de knop "", die voetnoten met referentiesjablonen invoegt. Het is echter de uitzondering die de regel bewijst. Het vereist handmatige configuratie zelfs voor basisfunctionaliteit, deze configuratie is afzonderlijk in elke wiki en als gevolg daarvan hebben veel wiki's deze knop helemaal niet. Een vergelijkbare uitzondering, die eind 2019 werd toegevoegd, is speciale ondersteuning voor sjablonen voor het melden dat bronvermelding nodig is, maar dit vereist ook een aangepaste configuratie op elke wiki om daadwerkelijk te werken.



Moeilijkheden voor redacteuren die in meer dan één project schrijven
Er bestaan veel sjablonen in het ene project, maar niet in een andere, en vaak is er een sjabloon beschikbaar, maar in een andere vorm. Hierdoor is het moeilijk of onmogelijk om vaardigheden die in één project zijn opgedaan opnieuw te gebruiken: de functionaliteit die het sjabloon biedt, is soms niet beschikbaar en soms werkt het anders. Dit geldt niet alleen voor wiki's in verschillende talen, maar ook voor verschillende wiki's in dezelfde taal, bijvoorbeeld de Engelse Wikipedia en de Engelse Wikisource.

Voor mensen die in verschillende talen bewerken, maken sjablonen het vertalen moeilijker. Bij het vertalen van een pagina zijn sjablonen veel moeilijker te hanteren dan de artikeltekst ("proza"), of de vertaling nu handmatig of met inhoudsvertaling wordt gedaan. Gebruikers moeten het sjabloon vaak overslaan of corrigeren nadat het artikel is gepubliceerd. Dit zorgt er ook voor dat lopende vertalingen worden verlaten, omdat sjabloonvertaling er intimiderend uitziet.

De meest gemelde problemen in Content Translation hebben betrekking op sjablonen.

'Content Translation' heeft een sjabloonaanpassingsfunctie, die sommige delen van dit proces automatiseert, maar het werkt alleen als er een overeenkomstige sjabloon in beide talen bestaat en als alle parameters zorgvuldig zijn toegewezen door de sjabloonbeheerders. Dit moet voor elke sjabloon in elke taal afzonderlijk en handmatig worden gedaan en continu worden onderhouden wanneer het bron-sjabloon wordt gewijzigd. Dit gebeurt ook al is de functie van de sjablonen in de talen meestal hetzelfde.

Idealiter zouden de sjablonen en hun parameters bijna volledig automatisch naar de vertaalde pagina moeten worden overgebracht, zodat de vertalers zich kunnen concentreren op het schrijven van het proza, omdat het schrijven van het proza het gebied is waar menselijk werk het meest nodig is.

Een sjabloon kan van de ene wiki naar de andere worden geëxporteerd, maar zodra dit is gebeurd, wordt het sjabloon een gevorkte kopie. Het blijft ofwel in de staat waarin het werd geëxporteerd, of blijft afzonderlijk worden ontwikkeld, waardoor incompatibiliteit ontstaat. Soms blijven mensen de verschillende kopieën onderhouden, maar dit is niet robuust en kan niet worden geschaald voor de honderden wiki's die we hebben.

Sjabloonparameters kunnen dezelfde functionaliteit hebben, maar verschillende namen in verschillende wiki's. Ze kunnen worden aangepast met behulp van TemplateData-aliassen, maar dit is een suboptimale hack: het is niet waar TemplateData oorspronkelijk voor is gemaakt en het moet handmatig worden gedaan voor elk talenpaar.

Sjablonen combineren algoritmische logica, door mensen leesbare tekstreeksen en opmaak. Hierdoor is er geen robuuste manier om de gebruikersinterfacestrings van de sjablonen te vertalen, zoals het wordt gedaan met MediaWiki-kern en extensies.



Moeilijkheden voor redacteuren in kleinere wiki's
Een nieuw wikiproject wordt gemaakt door de kern van MediaWiki te installeren en een standaardset extensies in te schakelen. In de praktijk creëert dit geen gelijk speelveld omdat veel belangrijke functies van grotere wiki's zijn geïmplementeerd in sjablonen: infoboxen, citaten, onderhoudshatnotes (zoals ), enz.



Moeilijkheden voor softwareontwikkelaars
Het is moeilijk voor ontwikkelaars van MediaWiki-kern, extensies, bots en andere hulpmiddelen die wikipagina-inhoud analyseren, genereren of wijzigen om functies te bouwen die afhankelijk zijn van de aanwezigheid van bepaalde sjablonen in een wiki. Ontwikkelaars van extensies zoals GrowthExperiments, PageTriage, ContentTranslation, sommige componenten van Wikibase en vele anderen, moeten ze ofwel in productie testen, wat een slecht idee is, of de sjablonen importeren in hun lokale wiki's of een online testwiki.

Onderzoekers die gegevens over wiki-inhoud krijgen op basis van sjablonen, moeten hun analysecode voor elke wiki afzonderlijk schrijven, en soms doen ze dat voor slechts één wiki. Een opmerkelijk voorbeeld is het gebruik van de WikiProject-sjablonen van de Engelse Wikipedia om paginaonderwerpen te analyseren en de kwaliteit van het artikel te beoordelen.

Aannames


Extensies versus sjablonen: overeenkomsten en verschillen
Een van de belangrijkste aannames van dit projectvoorstel is dat sjablonen en modules erg lijken op de kern en extensies van MediaWiki: ze zijn software en ze implementeren functies die de editorsgemeenschap nodig heeft. Met name omdat sjablonen meestal door de redactie zelf worden ontwikkeld, is het duidelijk dat de gemeenschap ze echt nodig heeft. De grote verschillen tussen hen liggen in de manier waarop ze worden ontwikkeld, gelokaliseerd en ingezet.

Sjablonen en modules moeten vergelijkbaar worden met extensies in sommige belangrijke eigenschappen die ze momenteel missen, en een aantal goede eigenschappen behouden die extensies missen. (Voor het gemak van het begrip voor lezers, in de tabel, worden voorbeelden van sjablonen gegeven van de Engelse Wikipedia. Ze kunnen ook afkomstig zijn van elke andere wiki en elke andere taal.)



Vaardigheden voor het ontwikkelen van sjablonen en modules
Andere belangrijke aannames waarop dit voorstel is gebaseerd, zijn de volgende:
 * De vaardigheden voor het ontwikkelen van sjablonen en modules zijn niet-triviaal. Zowel sjablonen als modules hebben tal van obscure functies.
 * Hoewel veel van de meest opvallende functies van de sites worden geïmplementeerd als sjablonen en modules, worden deze vaardigheden vaak onopgemerkt, ondergewaardeerd en als vanzelfsprekend beschouwd.
 * Er zijn tientallen mensen die deze vaardigheden hebben, en ze bewerken veel wiki's. Ze richten zich meestal op hun thuiswiki en communiceren relatief zelden met bijdragers van andere wiki's of andere talen. Hoewel de onderliggende technologie overal hetzelfde is, is er geen echte wereldwijde gemeenschap van sjabloonontwikkelaars die vergelijkbaar zou zijn met de wereldwijde gemeenschap van MediaWiki-kern- en extensieontwikkelaars. Er zijn gevallen van cross-wiki-samenwerking op bepaalde sjablonen, maar ze zijn inconsistent.
 * Er zijn ook veel wiki's waarin er geen redacteuren zijn die deze vaardigheden hebben. Ze kopiëren sjablonen en modules van andere wiki's zonder volledig te begrijpen hoe ze werken en zonder de mogelijkheid om ze effectief te lokaliseren en te onderhouden, of ze gebruiken helemaal geen sjablonen.

Deze situatie is verre van optimaal. De vaardigheden van de sjabloon- en moduleontwikkelaars hebben meer waardering nodig. Ze ontwikkelen echt benodigde functies en ze zijn ingebed in hun editorscommunity's. In wiki's in vele talen komen de sjabloonontwikkelaars met innovatieve functies voor gestructureerde inhoud, gegevenspresentatie en modularisering. Deze innovaties zouden nuttig kunnen zijn in veel wiki's, maar momenteel is er geen handig mechanisme om dit te bereiken.

En natuurlijk moet elke oplossing voor deze problemen niet komen met nieuwe technologieën die de vele jaren praktijkervaring die de sjabloonbeheerders hebben opgedaan, zullen weggooien. Daarom moeten er zo min mogelijk wijzigingen zijn in de syntaxis voor het ontwikkelen van sjablonen en modules. De dingen die moeten veranderen, zijn de manier waarop ze worden geïmplementeerd en verspreid over wiki's, en de manier waarop de door mensen leesbare tekenreeksen erin worden gelokaliseerd (vertaald). 

De voorgestelde oplossing: Samenvatting
Er zijn al veel functies van MediaWiki die wereldwijd zijn op wiki's:


 * afbeeldingen (via Commons)
 * gebruikersaccounts
 * Globale volglijst is vanaf eind 2020 actief in ontwikkeling
 * en enkele andere.
 * Globale volglijst is vanaf eind 2020 actief in ontwikkeling
 * en enkele andere.
 * Globale volglijst is vanaf eind 2020 actief in ontwikkeling
 * en enkele andere.

Het moet ook mogelijk zijn om sjablonen en modules op te slaan in een wereldwijde repository en ze net zo robuust te lokaliseren als met extensies.

Sjabloonbeheerders in alle wiki's zullen door globale sjablonen en modules gemakkelijker kunnen samenwerken bij het ontwikkelen van de code van de sjablonen.

De vertalers kunnen zich concentreren op het vertalen van alleen de tekenreeksen van de gebruikersinterface ("berichten"), zonder te hoeven zoeken naar tekenreeksen in de code, en door hen in staat te stellen dezelfde vaardigheden en hulpmiddelen te gebruiken voor het vertalen van sjablonen en MediaWiki-extensies.

Inhoudseditors in alle wiki's zullen in staat om inhoud te schrijven en te vertalen die deze sjablonen gebruikt zonder in de verschillen te hoeven duiken en om verschillende regels en vaardigheden in elke wiki opnieuw te leren.

De syntaxis voor het ontwikkelen van sjablonen en modules en de algemene sjabloononderhouds- en implementatiecyclus zullen niet veranderen, dus alle vaardigheden die de sjabloononderhouders in de loop der jaren hebben verworven, blijven relevant.

Alle wiki's kunnen de algemene sjablonen gebruiken, maar worden niet gedwongen om dit te doen. Gemeenschappen behouden hun mogelijkheid om alle wereldwijde functionaliteit, ontwerp, workflows en gegevens te negeren.

Het lokaliseren van sjablonen wordt net zo handig als het lokaliseren van MediaWiki-extensies. 

De voorgestelde oplossing: Gedetailleerde vereisten


Sjablonen moeten semantisch en globaal kunnen zijn
Semantisch betekent dat andere softwarecomponenten, met name Visual Editor en Content Translation, een algemene manier moeten hebben om te begrijpen dat een sjabloon bestaat en dat het bepaalde functionaliteit biedt, zodat het mogelijk is om het in een pagina in te voegen als een infobox, een citaat, een onderhoudstag, enz., En niet alleen als een generieke sjabloon. Nu komt TemplateData het dichtst in de buurt van het semantisch maken van sjablonen, maar het beschrijft alleen de parameters van het sjabloon. Het helpt Visual Editor bijvoorbeeld niet om een knop "Infobox invoegen" aan de werkbalk toe te voegen.

Globaal betekent dat de code van een sjabloon op één plaats moet worden onderhouden en bruikbaar moet zijn in alle wiki's.



Sjablonen semantisch maken
Sjablonen zijn nooit robuust semantisch geweest, in de zin dat ze gemakkelijk te hanteren zijn door software die pagina's verwerkt.

Er zijn slechts enkele voorbeelden van sjablonen die semantisch zijn gemaakt:


 * Verschillende referentiesjablonen, die bruikbaar zijn via de knop op de Visual Editor-werkbalk "". Ze vereisen het schrijven van veel afzonderlijke code om Citoid te configureren op elke wiki die ze wil gebruiken.
 * "Citation needed", dat eind 2019 werd aangepast naar Visual Editor. Het vereist ook configuratie op elke wiki. Bijvoorbeeld: Engels, Hebreeuws, Sloveens. Op het moment van schrijven zijn Frans, Spaans en de meeste andere talen hier niet voor geconfigureerd, ook al hebben ze dit soort sjablonen.
 * Sjablonen voor het vermelden van gebruikers in de extensie Flow, die ook lokale configuratie vereisen.
 * Sommige dumpverwerkings- en onderzoekshulpmiddelen kunnen de WikiProject-beoordelingssjablonen van de Engelse Wikipedia parseren, die meestal worden toegevoegd aan overlegpagina's.
 * De extensie GrowthExperiments stelt editors voor om bepaalde taken in artikelen uit te voeren op basis van de sjablonen die erin zijn opgenomen. De sjabloonnamen moeten handmatig worden geconfigureerd door JSON-bestanden afzonderlijk in elke wiki te schrijven. Bijvoorbeeld: Tsjechisch, Vietnamees, Koreaans, Arabisch.
 * De extensie PageTriage is geconfigureerd om te werken met de hatnote-sjablonen van de Engelse Wikipedia (ook bekend als "tags").

In het geval van PageTriage codeert de extensie in wezen de sjablonen van een enkele wiki, waardoor deze onbruikbaar wordt in andere wiki's zonder een significante herschrijving. Zelfs als de on-wiki configuratiestap klein is, zoals bij Flow, moet het nog steeds worden gedaan. Dit schaalt niet goed voor de 900 wiki's die Wikimedia heeft, en de duizenden die het in de toekomst zal hebben.

Deze dingen moeten standaard globaal zijn, zodat ze onmiddellijk bruikbaar zijn in ten minste een eenvoudige standaardconfiguratie op alle wiki's tegelijk door extensies, bots, dumpanalyzers, enz.



Opslag en levering
De globale templates en modules kunnen worden opgeslagen in een centrale wiki (Meta, Commons of een geheel nieuwe wiki), en het kan zelfs Gerrit of een andere repository zijn.

De beste oplossing is waarschijnlijk het maken van een nieuwe wiki die ze opslaat, zonder verward te raken met afbeeldingen, algemene gemeenschapsdiscussie, enz.

Het gebruik van Gerrit als opslag voor templates en modules code is technisch mogelijk, maar het zou een belangrijk element van toegankelijkheid voor sjabloononderhouders verliezen: het bewerken van een sjabloon in een wiki-pagina is veel makkelijker en vertrouwd voor de overgrote meerderheid van de sjabloononderhouders  dan het maken van Git commits en het wachten op code review. Daarom moet Gerrit waarschijnlijk niet gekozen om de sjabloon en modulecode op te slaan, althans niet de primaire.

Algemene sjablonen en modules moeten worden opgeslagen in een gemeenschappelijke opslagplaats die door de meeste wiki-editors kan worden bewerkt. Regels over blokkeren en speciale machtigingen moeten in eerste instantie vergelijkbaar zijn met de regels in andere wiki's: alles moet standaard open zijn en het moet mogelijk zijn om zeer gebruikelijke, gevoelige of vaak vernielde sjablonen te beschermen. Meer gedetailleerde regels over beschermingsniveaus kunnen later door de redactiegemeenschap worden ontwikkeld.

De code van de sjablonen in de centrale repository gebruikt de generieke Engelse namen van tags zoals, parserfuncties zoals   of   en magische woorden zoals.

Hoe de sjablonen aan de doelwiki's worden geleverd, is een kwestie van interne engineering en architectuur, zolang de andere vereisten worden aangepakt. Deze vragen werden in het verleden door sommige platformontwikkelaars besproken, bijvoorbeeld rond het project Shadow namespaces. Dit document probeert gerelateerde vragen te beantwoorden over hoe het werkt voor de gebruiker die een pagina bewerkt die een sjabloon gebruikt, of die het sjabloon zelf onderhoudt, hoe deze op een lokaliseerbare manier te schrijven; hoe wordt het vertaald; hoe wordt het lokaal aangepast; enz. Deze vragen kwamen onvoldoende aan bod in de eerdere architectuurdiscussies over het onderwerp.

<span id="Templates_must_remain_easy_to_modify">

Sjablonen moeten eenvoudig te wijzigen blijven
Een belangrijk kenmerk van hoe sjablonen momenteel werken, is dat ze net als wikipagina's worden bewerkt en onmiddellijk functioneel worden na publicatie zonder beoordeling of implementatie. Dit is enigszins gevaarlijk omdat een slechte bewerking veel pagina's kan verpesten, maar het feit is dat het meestal goed werkt.

Dit gemak moet behouden blijven. Communityleden die sjablonen onderhouden, zullen hoogstwaarschijnlijk de overstap naar een nieuw systeem weigeren waarvoor ze nieuwe vaardigheden moeten leren en elke wijziging door een uitputtende beoordelings- en implementatiefase slepen. Dit betekent waarschijnlijk dat het opslaan van de sjablonen in Gerrit niet gaat werken, tenzij het proces voor beoordeling en implementatie misschien veel eenvoudiger zal zijn dan voor extensies.

<span id="It_must_be_possible_to_make_some_templates_non-global">

Het moet mogelijk zijn om sommige sjablonen niet-globaal te maken
Niet alle sjablonen moeten worden gedwongen om globaal te zijn.

Sommige sjablonen moeten zelfs lokaal zijn omdat ze een functionaliteit implementeren die uniek is voor een bepaalde taal. Door hun aard hoeven dergelijke sjablonen niet te worden vertaald en moet er een manier zijn om zowel menselijke editors als vertaalhulpmiddelen (zoals Content Translation) een hint te geven dat ze niet hoeven te worden aangepast en kunnen worden overgeslagen of vervangen. Dit is een onderdeel van de inspanning om sjablonen semantischer te maken.

<span id="It_must_be_possible_to_override_some_functionality_or_appearance_of_a_global_template">

Het moet mogelijk zijn om bepaalde functionaliteit of het uiterlijk van een globale sjabloon te overschrijven
Geen enkele gemeenschap zou het gevoel moeten hebben dat een functionaliteit wordt opgelegd door een krachtige externe speler, zoals de Engelse Wikipedia-gemeenschap, de Wikidata-gemeenschap, de WMF of iemand anders. Globale sjablonen moeten worden ontwikkeld en gezamenlijk worden gebruikt voor het algemeen belang. Meestal zou het voor iedereen moeten werken.

Soms hebben sommige gemeenschappen een sterke mening over het willen hebben van bepaalde functionaliteit of ontwerp dat anders zal zijn in hun taal of project, of om een infobox te tonen met informatie die anders is dan wat in andere projecten wordt getoond, of om het helemaal niet te laten zien. De mogelijkheid om dingen lokaal te overrulen, moet vanaf het begin worden toegestaan. (Of beter gezegd, het mag niet worden weggenomen.)

<span id="A_global_template_must_be_immediately_usable_in_every_wiki">

Een globaal sjabloon moet onmiddellijk bruikbaar zijn in elke wiki
Net zoals een globale gebruikerspagina direct beschikbaar is in elke wiki waarin geen lokale gebruikerspagina is, moet elk sjabloon of module die op de globale infrastructuur wordt aangemaakt direct bruikbaar zijn in elke wiki.

Dit mag geen geen extra stappen vereisen, zoals het kopiëren van wikipagina's, het maken van wrappersjablonen met een lokale naam, tussenkomst van de beheerder, urenlang wachten tot caches zijn vernieuwd, enz.

Nadat de centrale versie is bijgewerkt, wordt de bijgewerkte versie onmiddellijk overal weergegeven. Om vandalisme te voorkomen, zal de redactiegemeenschap beleid ontwikkelen over machtigingen en beschermingsniveaus.

Als de tekenreeksen van de gebruikersinterface (ook bekend als "berichten") niet zijn vertaald, is het sjabloon niettemin bruikbaar en worden de tekenreeksen weergegeven in de terugvaltaal. Zie de secties over lokalisatie voor meer informatie.

<span id="Localization_of_user-facing_strings">

Lokalisatie van tekenreeksen die de gebruiker ziet
<span id="It_must_be_possible_to_translate_all_user-facing_strings">

Het moet mogelijk zijn om alle deze tekenreeksen te vertalen
The user interface strings (messages) of core MediaWiki, extensions, and some external tools such as Pageviews are translated conveniently and robustly on translatewiki.net. This localization process is familiar to at least some editors in all languages.

It’s currently not possible to do the same with templates. Multilingual sites such as Commons and mediawiki.org have the “TNT” system for translating some templates, but it’s very complicated and cannot be reused for Wikipedia, Wikisource, etc. In 2021, this became more robust thanks to the "language-aware transclusion" feature, but it still needs some improvements.

Ideally, it should be possible to translate templates just like core and extensions, using a wiki with the Translate extension.

The translated string must become usable immediately after the translation is submitted using the Translate interface.

It can be possible to edit the user interface strings in raw wiki pages, but ideally they should be edited primarily through a dedicated translation interface.

Translators should be able to focus on translating nothing but text. Seeing any code around it makes it difficult for people who are not experienced with programming and JSON files to contribute easily. In addition, editing translations into languages that are written from right to left in raw text files is extremely inconvenient. The Translate extension already addresses all of these issues.

The template documentation pages must be translatable as well. It’s mostly enough to do it using the page translation feature of the Translate extension, but it may require some adaptations.

The language in which the strings are shown to the user
Templates are primarily used when they are integrated into content, so by default the translated messages must be shown in the wiki’s content language.

Some templates, however, are used as UI elements. Therefore, perhaps it makes sense to also allow showing the translated strings in the user language, when it’s different from the wiki content language. This may be particularly relevant for multilingual sites such as Commons, Wikidata, Meta, and mediawiki.org.

MediaWiki’s usual fallback language chains must be used when a translation is not available. For example, if a message is not translated into Quechua or Guarani, it will be shown in Spanish, if it’s not translated into Bashkir or Chuvash, it will be shown in Russian, and so on. The ultimate fallback language is English, so if this message is not translated into Spanish or Russian, it will be shown in English.

Message keys
Messages should be represented as keys, similarly to how it is done in MediaWiki core, extensions, and tools.

Writing translatable strings will probably be the largest change in the template development process that template maintainers will have to get used to. Hard-coded strings will have to be separated and moved to messages organized by key. It must be made as easy as possible not only for the translators, but also for the template maintainers. Otherwise, they won’t actually do it, and the feature will be effectively rejected.

To easily make keys globally unique, it’s probably OK to automatically include the global template name in the message key.

Transitioning tools
A tool should be developed that will help the transitioning of a template or a module to central storage. It can do the following steps:


 * 1) Export a template from a local wiki and import it into the global wiki.
 * 2) Export all the templates that are used by this template (cascading).
 * 3) Identify the human-readable strings, convert them to a list with keys, and replace them with keys in the template’s source code.
 * 4) Import the template’s documentation page and TemplateData.
 * 5) Import the necessary CSS pages.

In most cases, this automatic process probably cannot create a fully usable and robust template or module, but it can help begin the transitioning process.

Organizing messages
The Translate extension organizes messages by groups, also known as “projects”, which can be further organized by aggregate groups. For example, Article Placeholder, Score, and Poem are all groups that represent the corresponding MediaWiki extensions, and they are all included in the “Extensions used by Wikimedia - Advanced” aggregate group, along with many other extensions.

Projects that represent MediaWiki extensions are configured in YAML files in the translatewiki repository and shown in the Translate user interface in a project selector, also known as “message group selector”.

Since there are many more templates than extensions, some modifications may be needed in the way the Translate extension handles message groups to accommodate templates translation.

Each template should be a message group. Closely related templates should be grouped in an aggregate message group. They can be similar to the categories in which they are stored, and in fact, the categories may even be reused. Editing files in a Git repository to organize these message groups is probably not desirable, because it’s too complex and slow.

It would be nice to show group and template names as localized in the selector, but it’s also OK if they are shown in English. If it’s good enough for extension localizers, it’s good enough for template localizers, too.

Templates must be shown as message groups on the Translate extension’s Language statistics special page (Special:LanguageStats). This will help localizers find what templates need translation. This should be generally similar to all message groups, but there are some special considerations for templates:
 * There will be thousands of templates, so it will be nice if the table’s design corresponds to this somehow.
 * The table should show on how many pages is each template transcluded and make it possible to order the rows by this number, to help localizers prioritize what is more important to translate.

Finding how to translate a template
Every template description page needs to have a direct link to translating it to the user’s language.

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.

Message documentation
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  statements.

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:

Invoer:

Uitvoerː

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.

Nameless parameters
Nameless numbered parameters must continue working, of course.

A decision is needed about how will their names be localized.

Translating parameter values
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 direction
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.

Other features related to templates
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 “” 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 “” parameter 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 “” 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

 * Special:TemplateSandbox must keep working.
 * 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

 * VisualEditor obviously needs to be able to insert both global and local templates.
 * 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:


 * 1)  (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.
 * 2) Global modules: Modules become shareable across wikis. This should happen before making templates shareable because the modules’ infrastructure is less coupled to core MediaWiki.
 * 3) 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.
 * 4) 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:

(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. Several other similar ideas were raised later, for example Phabricator. 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 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.

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. <span id="Useful_links">

Bruikbare links
Enkele relevante pagina's die vergelijkbare onderwerpen bespreken:


 * Platform evolutie doelen
 * Platform evolutie aanbevelingen
 * Meertalige sjablonen en modules - Een poging om een vergelijkbare functie te implementeren met behulp van bots
 * Wensenlijst 2015 - Centrale globale Repository voor sjablonen, Lua modules en Gadgets kwam binnen als #3 in de Community Wishlist stemming. Vermeld als "In ontwikkeling - Parsing team", maar niet echt gedaan.
 * Welke sjablonen moeten globaal zijn - een informele lijst gemaakt door meerdere berwerkers
 * Verzoeken om commentaar/Shadow namespace - een slapende RFC over één voorstel voor een technische implementatie van een dergelijke infrastructuur
 * - een bestaand rudimentair mechanisme voor het transclueren van inhoud tussen projecten. Beschouwd als inefficiënt en onveilig, en uitgeschakeld op Wikimedia-projecten.
 * m:Global-Wiki - een soortgelijk voorstel, met een bredere reikwijdte. Het stond enkele jaren open voor discussie en sloot als "consensus". Sommige dingen daarin zijn geïmplementeerd, zoals algemene gebruikerspagina's en voorkeuren, maar het bevat ook algemene sjablonen, die nog niet zijn gedaan.
 * m:Abstract Wikipedia - Een groter voorstel, dat een globale module en template repository bevat (ook bekend als Wikifunctions, en voorheen bekend als "Wikilambda").
 * m:Community Wishlist Survey 2021/Translation/Templates translation - Een gemeenschapswens die overeenkomt met sommige delen van dit voorstel, met name Automatische parametervertaling.