Global templates/Alternative solutions

Templates and modules on Wikimedia projects are local to each project, and this is a problem for usability, discoverability, knowledge equity, content propagation, and structured data processing.

The problem is described in detail on the page Global templates/Draft spec/TLDR and in even more detail on the page Global templates/Draft spec.

The pages mentioned above also propose the solution: Allow making some templates and modules global, similarly to images on Commons, global personal JS and CSS pages, global user pages, etc.

If you agree that the problem is real and should be resolved, but the proposed solution of making templates and modules global is not optimal, and something else should be done instead, this page is for you. It discusses several other ways to resolve the problem that were proposed over the recent years, and explains why they are not as good as making templates and modules global. Some of these proposals don't address the problem comprehensively and some of them sound related, but address different problems. If you still disagree with something, feel free to edit this page or to discuss it at the talk page.

Convert some templates and modules into extensions
Some templates and modules could be converted into extensions. This would have the following advantages:
 * Extensions are easy to install on all wikis.
 * Extensions are easy to localize on translatewiki.
 * Extensions have a robust process for code review, integration, and deployment, and this is good for stability, testing, and security.

However, there are also several problems with this approach:
 * The programming languages are different: Templates are in wiki syntax and modules are in Lua, and extensions are in PHP and JavaScript. Thus, converting a template requires a complete rewrite, which, in turn, requires considerable resources and time.
 * While the final product can be more robust, bugs can be introduced along the way, as it happens with any rewrite.
 * Many template maintainers are not familiar with PHP, JavaScript, and Git. They prefer wiki syntax, Lua, and editing wiki pages. There are hundreds of template maintainers and discarding their experience and skill is not right, not just emotionally, but practically. If the process will alienate template maintainers, they will discard the extensions and keep using the templates.
 * The current Gerrit code review and deployment process is extremely slow, especially in comparison to the immediate deployment of templates.

Despite the problems, rewriting some templates and modules as extensions is a valid idea, especially for those templates and modules that are stable, complex, change rarely, are clearly useful on many wikis, and require high security, stability, and performance. In particular, this may be quite easy for modules, which can be packaged in extensions relatively easily (the capability to put Lua files in extensions already exists, but it's rarely used). Rewriting all templates as extensions, however, is probably not feasible.

Map the parameters of existing templates to each other
Some proposals to address the problem of incompatibility of templates between projects suggest mapping the parameters of templates to each other.

This solution can indeed alleviate the problem of incompatibility to a certain extent. It has already been done in the Content Translation extension as a hack that uses TemplateData aliases to map the parameters. This made Wikipedia article translation somewhat more robust. This is being improved even further in Content Translation by using some machine learning techniques to predict what parameters need to be mapped (see ).

However, even with these advancements, this is never going to be a complete solution. First of all, it doesn't address the complete problem. The incompatibility between existing templates is just one aspect of the problem. A much wider problem is that on many projects the templates in question don't exist at all, even though they are necessary.

In addition, the parameter mapping has to be manually and continuously maintained for each template in each language pair, and this just doesn't scale. Even if it is done for some common templates, new templates will keep being created locally and will require yet more manual mapping. There is no end to this.

The Global templates proposal recommends a central and robust system for localizing parameter names. This will guarantee that all parameters can be used in all wikis without any effort on the editors' behalf even if they are not explicitly localized.

Improve the wiki syntax for building templates
The wiki syntax for templates is difficult, complex, intricate, and intimidating. The source code of many templates is overloaded with curly braces, pipe characters, equal signs, hash marks, etc. The Parsing team has made several good proposals in this area; for an example, see the presentation Evolving wikitext: embracing incrementalism from Wikimania 2019.

This is a valid problem, and it should be solved, but it is distinct from the problem that the Global templates proposal is trying to address. The "Evolving wikitext" project is about improving the templates language itself, whereas the "Global templates" project is about how the templates are stored and delivered, and how they become discoverable to editors. Evolving wikitext is trying to make developing the template itself easier, and Global templates is trying to reduce to zero the number of steps that are required to start using a template in any wiki.

The two projects do not contradict each other, and can help each other succeed. This is confirmed by another Wikimania 2019 presentation, Let's completely change how templates work, which shows both problems distinctly. If it becomes possible to store templates globally, any change in a template's source that has to be done as part of Evolving wikitext initiative will have to be done just once. As long as templates are not global, it will have to be done multiple times for each template.

It should also be noted that evolving wikitext, by itself, will have direct impact only on the developers of templates and modules. This will enable them to work more efficiently, and may help them develop templates that are better and more usable. This is desirable, but less visible. Making templates global, on the other hand, will have direct, positive, and visible impact on all editors and readers in all wikis, and not only on developers.

Integrate structured data into wiki syntax
Another proposal that is somewhat similar to "Evolving wikitext" is making wiki syntax more structured for data, as middle ground between the current, mostly structureless wikitext and a completely structured storage such as Wikidata. It's described at 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 doesn't address the needs of the wikis that don't have people who have the necessary skills to maintain highly technical templates.

This proposal doesn't 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.

Allow writing modules in JavaScript
There have been several proposals to allow writing Scribunto modules in languages other than Lua, most notably in JavaScript. For an example see and slide 18 in the aforementioned Let's Completely Change How Templates Work! presentation.

This is a valid proposal. More people know JavaScript than Lua, so it should make module development more accessible, and the number of module developers may grow.

Yet again, however, this will only affect communities that have developers as members. Wiki communities in many languages don't have any developers at all, so they won't enjoy the fruits of this feature.

Make a package management system for easier copying of templates from one project to another
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's done well, it will require running this copying process for each template, whereas a global repository will make all template immediately available with zero extra steps.

Developing such a package will require something similar to a tool that is described in the section "Transitioning tools" in the detailed Global templates spec. If it's done, why not just go all the way and make templates global.

Make gadgets global
Gadgets are pieces of JavaScript that are developed onwiki.

Like templates, they belong to the "Local customizations" side of Wikimedia software as described on the page Global templates/Draft spec/TLDR. 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 don't 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 wasn't 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 affect the page content, they mostly alter the user interface. The gadgets' functionality is barely affected 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.

Make a bot that copies templates from a central repository
This is what the Multilingual Templates and Modules proposal is about. It's a reasonable approach given the current MediaWiki platform, however it has some disadvantages. In fact, that project's own description page admits that it's not the best approach.

The bot approach requires several manual steps for each template in each language. It doesn't have full-fledged translation tools for localizing the messages, and requires editing JSON files instead.

Finally, it doesn't truly make templates available in all languages. This system still requires 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 several steps for each template.

So yes, it's probably still the best approach given the state of MediaWiki technology in late 2019. It can serve as a testing ground and a transition phase towards true support for global templates and modules in the software platform. But it's not perfect.