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 globules global is not optimal, 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 some 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 addressing the problem of incompatibility of templates between project 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 more 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.

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 the number of steps that are required to start using a template in any wiki to zero.

The two projects do not contradict each other, and can help each other succeed. 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. This is also confirmed by another Wikimania 2019 presentation, Let's completely change how templates work, which shows both problems distinctly.

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 even a single extra step.

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