Global templates/Alternative solutions/ru
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 more detail in the short version of the Global templates specification and in even more detail in its full version.
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 feel that 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, which were proposed over the recent years, and explains why they are not as good as making templates and modules global.
Some of these proposals do not address the problem comprehensively, and some others are good by themselves, but address different problems. Each of these other proposed solutions is discussed in a section on this page. 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
TL;DR: It is good to do it for some templates and modules, but it is far from feasible to do it for all of them.
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, both socially and practically. If the process alienates template maintainers and wiki editors, 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 complex, stable, rarely changed, clearly useful on many wikis, and have high security, stability, and performance requirements. In particular, this may be quite easy for modules, which can be packaged in extensions relatively easily—the capability to package Lua files in extensions already exists, but it is rarely used. Rewriting all templates as extensions, however, is neither feasible nor desirable.
Map the parameters of existing templates to each other
TL;DR: It is already being done, and it is somewhat helpful, but not scalable.
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 T224721).
However, even with these advancements, this is never going to be a complete solution. First, it does not 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 do not 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 does not 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 (in the “Localizing parameters” section). 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 templates technology
Several alternative proposals suggest improving the template technology in general or creating a new programming language to achieve a similar task. They are grouped under this section because they all have a common property: they are trying to resolve different problems, and not the problem of the difficulty to share the templates’ code across wikis. The Global templates proposal recommends only changing the templates’ storage, while using the same wikitext (and the same Lua code for modules), thus keeping the existing code and the existing community skills as much as possible. There are improvements to be made with the templates and modules technology, but these are separate problems that require separate solutions, and they are out of scope of Global templates.
Improve the wiki syntax for building templates
TL;DR: It resolves different problems, but not the one in question.
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 code 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.
In addition, some changes in the syntax may improve the performance of templates parsing, which will also contribute to the success of Global templates.
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.
Allow writing modules in JavaScript
TL;DR: It resolves different problems, but not the one in question.
There have been several proposals to allow writing Scribunto modules in languages other than Lua, most notably in JavaScript. For an example, see T61101 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 accessible to more people, 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 other languages do not have any developers at all, so they will not enjoy the fruits of this feature.
Update the frontend development library
TL;DR: It resolves different problems, but not the one in question.
In 2019 (or even earlier), serious discussions began about upgrading MediaWiki’s frontend development library from a mix of jQuery, ResourceLoader, and OOJS UI to something new (see T241180). This has also been presented as a possible solution for sharing structured frontend software between projects. While theoretically possible, in practice it is probably more applicable to gadgets than to templates. Completely moving templates to JavaScript will mean giving up on wikitext, which is not really feasible for the community in the foreseeable future.
Switching to a new frontend development library can be an opportunity to improve the interface between JavaScript code and templates, but JavaScript, even in a modernized form, cannot replace wikitext completely. A global templates repository is a proposal for new storage of wikitext (and Lua).
Wikifunctions and Abstract Wikipedia
TL;DR: This project has bigger goals. It includes a global code repository, which is essentially the same as Global templates. The Global templates proposal can be implemented as part of it.
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 Global templates proposal.
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.
Integrate structured data into wiki syntax
TL;DR: It is a good long-term strategic goal, but too far-fetched for now, and a global templates repository will be a necessary step towards implementing it anyway.
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.
Make a package management system for easier copying of templates from one project to another
TL;DR: It sounds like a convenient thing for users, but actually, it is not scalable and going too far down this path will only complicate things.
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 the Transition to global templates, 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.
Make gadgets global
TL;DR: It resolves different problems, but not the one in question.
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 short version of the proposal. 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.
Make a bot that copies templates from a central repository
TL;DR: It was made, and it tried to resolve the same problem, but it was imperfect and hard to maintain, and even the bot’s maintainer admitted it.
This is what the Multilingual Templates and Modules 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.)
Conclusion
There are many ways in which the technology around templates and modules could be improved. Some of them will clearly be beneficial to Wikimedia projects in various ways, and they should be carried out. However, none of them fully or even partially resolves the problem described in the proposal: the need to have features that are useful to multiple wikis and implemented as templates easily and immediately available to everyone who needs them, while preserving the ease and the agility of template development and deployment. Only the implementation of Global templates will resolve this problem comprehensively. {{🌎🌍🌏}}