Global templates/Alternative solutions

Templates and modules on Wikimedia projects are local to each project and this is a problem.

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.

These pages describe the problem and 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 is not optimal, this page is for you. It discusses several other possible ways to resolve the problem, and explains why they are not as good as making some templates and modules global. 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 because, and this requires considerable resources.
 * 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 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 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, although it's rarely used). But rewriting all templates as extensions 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 somewhat. 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 a problem. A much wider problem is that on many projects the templates in question don't exist at all.

Besides, the mapping of the parameter has to 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, which guarantees that all parameters can be used in all wikis without any effort on the editors' behalf even if they are not explicitly localized, and that if they are localized, this is done safely, easily, and robustly.

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.

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, it admits that it's not the best approach.

This 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, but is a very opt-in system.

So yes, it's probably still the best approach given the current technology, and it can serve as a transition phase towards true support for global templates and modules in the software platform. But it's not perfect.