Global templates/Alternative solutions/nl

en in Wikimedia projecten zijn lokaal per project, dat is een probleem voor de bruikbaarheid, vindbaarheid, kennis, inhoud vermeerdering en gestructureerde gegevensverwerking.

Het probleem is met meer details beschreven in de, er is ook een.

Deze genoemde pagina's beschrijven ook de voorgestelde oplossing: Toestaan dat enkele sjablonen en modules globaal worden, dit is vergelijkbaar met afbeeldingen op Commons,, , enz.

Als u instemt dat dit een echt probleem is en dat het opgelost moet worden, maar denkt dat het voorstel om bepaalde sjablonen en modules globaal te maken niet optimaal is, en een ander idee heeft, dan kunt u deze pagina gebruiken. Het beschrijft meerdere manieren om dit probleem op te lossen, voorstellen uit recente jaren met verklaringen waarom deze oplossingen minder zijn dan ons voorstel.

Enkele van deze voorstellen geven niet uitgebreid het probleem aan, andere gaan over een ander probleem. Elk van deze voorstellen is besproken in een discussie in een sectie op deze pagina. Als u het er niet mee eens bent, voel u vrij om deze pagina te bewerken en op de overlegpagina dit mee te bespreken.



Converteren van enkele sjablonen en modules naar extensies
Conclusie: het is voor sommige sjablonen en modules te doen, maar het is niet uitvoerbaar om het voor alle te doen.

Enkele sjablonen en modules kunnen omgezet worden naar een extensie. Dat zou de volgende voordelen hebben:
 * Een extensie is eenvoudig te installeren.
 * Een extensie is eenvoudig te vertalen op translatewiki.
 * Bij extensies is er een echt proces voor het beoordelen van de code, integratie en in productie name. Dit is natuurlijk voor het bereiken van stabiliteit, testen en beveiliging.

Deze aanpak heeft ook nadelen:
 * De programmeertalen zijn verschillend: Sjablonen zijn in wiki-syntax en modules zijn in Lua, extensie zijn in PHP en JavaScript. Voor het converteren van een sjabloon zou daardoor het herschrijven nodig zijn en dat zal een aanzienlijke inspanning en tijd kosten.
 * Het eindproduct kan dan wel robuuster worden, het is onvermijdelijk dat er fouten worden gemaakt bij de conversie, dat gevaar is er bij elke wijziging.
 * Veel mensen die sjablonen onderhouden hebben geeb of beperkte kennis van PHP, JavaScript of Git. Zij hebben een voorkeur voor wiki-syntax, Lua en het bewerken van wiki-pagina's. Er zijn honderden van die mensen en wij kunnen en willen hun kennis en inzet niet missen. Als er door het proces een scheiding komt tussen de sjabloononderhouders en wiki-bewerkers, dan zullen zij de extensies negeren en de sjablonen blijven gebruiken.
 * Het huidige proces in Gerrit voor het beoordelen van code en het in gebruik nemen van nieuwe software duurt erg lang, vooral als men het vergelijkt met het invoeren van sjablonen.

Ondanks de problemen is het herschrijven van enkele sjablonen en modules als extensies een goed idee, vooral voor die sjablonen die complex, stabiel en veel gebruikt worden op veel wiki's. Deze stellen hoge eisen aan de security, stabiliteit en performance. Dit kan in het bijzonder voor modules gemakkelijk zijn, deze kunnen in een package in een extensie relatief gemakkelijk worden gedaan. De mogelijkheid voor het inpakken van Lua bestanden in extensies bestaat al, al wordt dat zelden gedaan. Het herschrijven van alle sjablonen als extensies is echter niet haalbaar en ook niet de wens om dat te doen.



Koppel de parameters van bestaande sjablonen aan elkaar
Conclusie: Dit wordt al wel gedaan en het helpt wat, maar het is niet schaalbaar.

Enkele voorstellen voor het aanpakken van de incompatibiliteit van sjablonen tussen projecten stellen het koppelen van parameters van sjablonen met elkaar voor.

Die oplossing kan tot een bepaalde hoogte het probleem oplossen, het is al gedaan bij de extensie Content Translation door het gebruiken van TemplateData aliassen voor het koppelen van de parameters. Hierdoor is het vertalen van Wikipedia artikelen wat robuuster. Dat is zelfs wat verhoogd door wat machine-lerende technieken om te voorspellen welke parameters moeten worden gekoppeld. .

Ook met deze verbeteringen wordt het echter nooit een volledige oplossing. Het pakt niet het hele probleem aan. De incompatibiliteit tussen bestaande sjablonen is maar een aspect van het probleem. Een groter probleem is dat op veel projecten deze sjablonen niet eens bestaan, ook al zijn ze nodig.

Daarnaast is het koppelen van de parameters iets handmatig dat blijvend en per sjabloon ondersteund moet worden voor elk taalpaar. Ook al doen we dat voor enkele gebruikelijke sjablonen, er blijven lokaal sjablonen aangemaakt worden, wat dan nog meer koppeling nodig maakt. Er komt geen eind aan.

Het voorstel met Globale sjablonen beveelt een centraal en robuust systeem voor vertaling parameternamen aan (in de sectie over het vertalen van parameters). Er is dan de garantie dat alle parameters gebruikt kunnen worden, zonder inspanning van de bewerkers, ook al zijn ze niet expliciet vertaald.



Verbeteren van de sjabloontechnologie
Meerdere voorstellen stellen in het algemeen voor de sjabloontechnologie te verbeteren of een andere programmeertaal te gebruiken voor een vergelijkbare taak. Deze voorstellen worden hier besproken, ze hebben allemaal een ding gemeen: er wordt geprobeerd andere problemen op te lossen, niet het probleem om de sjablooncode te delen tussen de de wiki's. Het voorstel "Global templates" beveelt alleen het wijzigen van de opslaan van de sjablonen aan, met gebruik van dezelfde wikitext (en dezelfde Lua code bij modules). De bestaande code wordt dus behouden en daarmee de kennis en kunde van de gemeenschap in die talen. Er kunnen verbeteringen in de technologie van sjablonen en modules worden aangebracht, dit zijn gescheiden problemen die een eigen oplossing vereisen. Die vallen voor ons buiten het project "Global templates".



Het verbeteren van de wiki syntaxis voor het maken van sjablonen
Conclusie: het lost diverse problemen op, maar niet het gevraagde.

De wiki-syntaxis voor sjablonen is moeilijk en  complex. De broncode van veel sjablonen bevatten veel accolades, verticale streepjes, gelijktekens, hash-tekens, enz. Het Parsing team heeft hier wat voorstellen voor gedaan; bekijk deze presentatie over wikitext uit Wikimania 2019.

Dit is echt een probleem dat opgelost moet worden, maar het is niet een probleem wat in ons voorstel wordt meegenomen. Het project “Evolving wikitext” gaat over het verbeteren van de taalsjablonen zelf, waar eht het project “Global templates” gaat over het opslaan en leveren van sjablonen en hoe de bewerkers ze kunnen vinden. Het beter maken van wikitext is het proberen het ontwikkelen van het sjabloon gemakkelijker te maken, bij Globale sjablonen is het een poging het aantal stappen om gebruik te maken een sjabloon in een wiki terug te dringen tot nul.

Deze twee projecten bijten elkaar niet, zij kunnen elkaar zelfs helpen om de ander te laten slagen. Dit is een vergelijkbare opvatting in een andere Wikimania 2019 presentatie, ''Laten we de werking van sjablonen compleet veranderen, daar worden de beide problemen ook apart bekeken. Als het mogelijk wordt om sjablonen lokaal op te slaan, dan hoeft een wijziging in de broncode van dat sjabloon die ten gevolge van het initiatief 'Evolving wikitext' maar eenmalig gedaan te worden. Zolang de sjablonen niet globaal zijn moet het meerdere keren voor elk sjabloon gedaan te worden.

Daarbij zullen enkele wijzigingen in de syntaxis de performance van het verwerken van sjablonen verbeteren, dat zal bijdragen aan het succes van globale sjablonen.

Het verbeteren van de wikitext zelf zal enkel direct van invloed zijn voor de ontwikkelaars van sjablonen en modules. Dat werk kan dan efficiënter worden gedaan, het zal ook een beter en een beter bruikbaar product opleveren. Het globaal maken van sjablonen zal positieve en zichtbare gevolgen hebben voor alle bewerkers en lezers in alle wiki's, dus niet alleen voor de ontwikkelaars.



Toestaan dat modules in JavaScript mogen worden geschreven
Conclusie: het lost diverse problemen op, maar niet het gevraagde.

Er zijn meerdere voorstellen gedaan om toe te staan dat Scribunto modules in andere talen dan Lua mogen schrijven, meestal in JavaScript. Voorbeeld: en de presentatie dia 18 in het eerder genoemde Let's Completely Change How Templates Work!.

Dit is een geldig voorstel. Er zijn meer mensen met kennis van JavaScript dan van Lua, het ontwikkelen zou dus door meer mensen gedaan kunnen worden, een groei van het aantal module ontwikkelaars ligt dan voor de hand.

Maar opnieuw, dat is alleen van belang bij gemeenschappen waar onder de leden ook ontwikkelaars zitten. De Wiki gemeenschappen in andere talen hebben meestal geen ontwikkelaars, dus dan is er minder kans op groei van het aantal ontwikkelaars.



Wijzig het frontend van de ontwikkel bibliotheek
Conclusie: het lost diverse problemen op, maar niet het gevraagde. De volgende alinea's zijn bewust niet vertaald.

In 2019 (of was het al eerder) waren er discussies over het upgraden van het frontend van MediaWiki met een combinatie van jQuery, ResourceLoader en OOJS UI naar iets nieuws (zie: ). Dit is ook gepresenteerd als een mogelijke oplossing voor het delen van gestructureerde frontend software tussen projecten. Hoewel technisch mogelijk is dit in de praktijk waarschijnlijk meer geschikt voor gadgets dan voor sjablonen. Het compleet verplaatsen van sjablonen naar JavaScript zou het opgeven van wikitext betekenen, dat is voor de gemeenschap iets wat in de te overziene tijd onhaalbaar is.

Het gaan naar een nieuwe frontend ontwikkel bibliotheek kan een mogelijkheid geven om de interface tussen JavaScript en sjablonen te verbeteren, maar ook een meer moderne JavaScript, kan wikitext niet geheel vervangen. Een globale sjablonen repository is een voorstel voor een nieuwe opslag van wikitext (en Lua).



Wikifunctions en Abstract Wikipedia
Conclusie: Dit project heeft hogere doelen. Het bevat een globale code repository, wat eigenlijk hetzelfde is als globale sjablonen. Men zou globale sjablonen als deel van de implementatie hiervan kunnen zien. De volgende alinea's zijn bewust niet vertaald.

The Wikifunctions project, also known as “Abstract Wikipedia” (and previously, as “Multilingual Wikipedia” and “Wikilambda”) is an idea to make a global repository of functions that automatically generate prose for Wikipedia articles in multiple languages from a central set of data and abstract descriptions of topics. Of all the different alternative proposals on this page, this one is perhaps the closest to the Global templates proposals, but it is not a replacement for it.

The main functionality that the Wikifunctions project suggests is considerably more advanced in its capabilities to generate text (prose) in natural language than the current technology for modules and templates. However, its central functions repository is essentially the same thing that is needed for Global templates and modules. The Abstract Wikipedia task list as of May 2020 even explicitly includes “A cross-wiki repository to share templates and modules between the WMF projects” as one of the first deliverables, although it is much less detailed in how it will actually work than the.

The most important difference is that as of early 2023, there are practically no usable Wikifunctions, while there is an enormous existing codebase written as wikitext templates and Lua modules. This codebase is stable and tested, it has worked in production for years, and it has skilled maintainers. It provides important features, which are used on millions of wiki pages, and which users in many more wikis want to use. In theory, these features could be rewritten as Wikifunctions, but given that it took about twenty years to write them in the first place, it may take many years more to rewrite them.

So, both Wikifunctions and Global templates will need a new wiki that will serve as a repository of code: templates, modules, and text generation functions. Both will also need a modernized mechanism for managing dependencies and change propagation across wikis, also known as “Dependency engine”. But the eventual goals of Wikifunctions and Global templates are distinct, and they will complement each other. Because of their familiarity to the editors and because of the huge and working codebase of modules and templates, they should be made global and available to wiki editors. Wikifunctions are not a replacement, but a complement, and may be deployed separately.



Integreer gestructureerde gegevens in de wiki syntaxis
Conclusie: dit is op de lange termijn een mooi doel, maar nu niet praktisch op deze termijn. Ook zal een repository voor globale sjablonen dan toch hierbij ook een noodzakelijk stap zijn. De volgende alinea's zijn bewust niet vertaald.

Another proposal that is somewhat similar to “Evolving wikitext” is making wiki syntax more structured for data, as a middle ground between the current, mostly structureless wikitext and a completely structured storage such as Wikidata. It is described on the page User:Tgr (WMF)/structured article data.

This is a valid proposal, and it addresses the need to balance between some communities’ desire to control the information locally in the pages and the need to process structured information semantically by software. However, like the “Evolving wikitext” proposal and some other proposals described on this page, it does not address the needs of the wikis that do not have people who have the necessary skills to maintain highly technical templates.

This proposal does not contradict the Global templates proposal, and both can be implemented. However, if this proposal is implemented without also making templates global, then at least in the foreseeable future it will most likely be used only in the largest wikis.



Maak een beheersysteem voor packages voor het eenvoudiger kopiëren van sjablonen naar een ander project
Conclusie: dit lijkt voor gebruikers gemakkelijk, maar het is niet schaalbaar en het lijkt ver af te wijken van wat we willen en het zal de zaken gecompliceerder maken. De volgende alinea's zijn bewust niet vertaald.

At the moment, to copy a template from one wiki to another, the editor needs to export it as a wiki page from the source wiki, including some cascading pages, import it into the target wiki, search the wiki syntax for human-readable strings and translate them, and then fix any remaining errors. The result may work as needed, but it will be a fork of the source template. This is an extremely manual and difficult process, and the results are far from perfect.

Occasionally, there are proposals to make something like a package management for templates and modules, so that copying will become easier. However, this will also be a very partial solution. Even if it is done well, it will require running this copying process for each template, whereas a global repository will make all templates immediately available with zero extra steps. In fact, the system described on the page Multilingual Templates and Modules, along with the volunteer-developed DiBabel tool, already implemented something like this, and while it made it somewhat easier to copy templates between wikis and perform other steps described on the page about, it would always require repeated manual steps for every template. (As of early 2023, DiBabel is inactive.) This cannot scale for the thousands of templates that have to be shared. 

Maak gadgets globaal
Conclusie: het lost diverse problemen op, maar niet het gevraagde. De volgende alinea's zijn bewust niet vertaald.

Gadgets are pieces of JavaScript that are developed onwiki and packaged in a way that allows conveniently enabling and disabling them through user preferences.

Like templates, they belong to the “Local customizations” side of Wikimedia software, as described in the. The problems with gadgets are similar to the problem with templates: they cannot be easily ported from one wiki to another, and even the existing hacks for making them work across wikis, such as those that are used by the famous HotCat gadget, are imperfect. In addition, they do not have a convenient and uniform framework for localization, as there is for extensions.

It should be possible, therefore, to make gadgets global as well. In fact, “Global gadgets” came in at #1 at the 2016 Community Wishlist Survey, but was not implemented because it was deemed too big for the Community Tech team.

However, the technology for global gadgets will be quite different from the technology for global templates. Gadgets are purely frontend components, and even though they sometimes modify the page content, they mostly alter the user interface. The gadgets’ functionality is barely impacted by the parser and the MediaWiki backend (except maybe ResourceLoader).

Templates are different: they are strongly built into the content and rendered server-side, so they are strongly coupled with the core platform and especially the parser. In addition, gadgets are primarily used by power-users of the wikis, whereas the templates’ code is seen by all editors and the templates’ output is seen by all readers, so the templates’ impact is much larger.

The most relevant thing that may be common to global templates and gadgets is storing and managing their localization, but even this is not certain. The localization of their user interface strings (messages) may be similar, but templates have additional needs, such as the localization of the template name and the parameters.

So yes—while gadgets, templates, and modules should all be global, it probably makes sense to handle gadgets mostly separately from modules and templates.



Maak een bot die sjablonen uit een centrale repository kopieert
Conclusie: Dat bestaat al, het lost hetzelfde probleem op, maar niet perfect en moeilijk te onderhouden, dat geeft ook de onderhouder van de bot toe. De volgende alinea's zijn bewust niet vertaald.

This is what the proposal is about. It is a reasonable approach given the current MediaWiki platform, but it has some disadvantages. In fact, that project’s own description page admits that it is not the best approach. It was developed as a bot called DiBabel, with a web-based frontend to synchronize the templates and modules across languages. As of early 2023, however, the DiBabel bot is abandoned and doesn’t work.

This bot approach required multiple manual steps for each template in each language. It did not have full-fledged translation tools for localizing the messages, and required manually editing wiki pages with JSON files instead.

Finally, it did not truly make templates available in all languages. This system still required the editors to opt in for each template in each wiki. This opt-in process is somewhat easier than the fully manual template importing process, but it still requires multiple steps for each template, so it's hardly scalable.

So yes, it may have been the most practical approach given the state of MediaWiki technology in 2021. Something of this kind can be attempted again and serve as a testing ground and a transition phase towards true support for global templates and modules in the software platform. But it cannot be a perfect and fully scalable solution.

(Another attempt to do something similar: Synchronizer.)

Conclusie
Hierboven is per alternatief ook een conclusie gegeven. Eigenlijk is het meer een beoordeling van TL en DR van de niet vertaalde tekst per alternatief. Het is niet vertaald omdat het wel erg gedetailleerd is en het zaken zijn die alleen als alternatieven besproken zijn. Als conclusie over het geheel kunnen we het zeggen dat er zijn veel manieren waarop de technologie rond sjablonen en modules verbeterd kan worden. Enkele kunnen zeker op meerdere punten voordelig zijn voor Wikimedia projecten, die punten zouden opgepakt kunnen worden. Er is er echter geen die ook maar deels het probleem oplost wat in is beschreven: de noodzaak om functies te hebben die op meerdere wiki's bruikbaar zijn en als sjablonen eenvoudig kunnen worden gemaakt en die dan direct beschikbaar voor iedereen die ze nodig heeft. Dit terwijl het gemak en de flexibiliteit bewaard blijft van het ontwikkelen en toepassen van sjablonen. Alleen de implementatie van Globale sjablonen zal dit probleem afdoende oplossen.

