Global templates/Transition

The implementation of Global templates and modules has two sides:


 * 1) The creation of the repository and the infrastructure that makes it possible
 * 2) The work by editors of multiple wiki projects to move the existing templates to this repository.

The “” document primarily addresses the infrastructure. (Also, as of June 2020, it mostly speaks about it on the level of product requirements and not on the level of internal technical architecture.)

This document here tries to address the other side: How will editors of wiki projects use this infrastructure once it’s available. It may seem that writing such a document so early in the process is too far-fetched because doing any of these things will be possible only when the infrastructure is actually deployed. However, it is useful to try to think about it as early as possible because it can inform the development of the technical infrastructure and the planning of its implementation. It may also help the developers understand which parts of this process can be at least partly automated. Once the infrastructure exists, this page will be converted from a theoretical plan to a practical transition guide.

As with all the other documents about Global templates, this is not the work of one person or a small group. The comments of all editors, developers, and other stakeholders are welcome—otherwise it just won’t work.

What happens today
So, let’s say that you want to write an article in the Wikipedia in your language about the Battle of Waterloo, and you want to have in it an infobox like the one in the English Wikipedia article about it. You try to type, but when you publish, you see a red link: Template:Infobox military conflict. So you figure out that you probably have to copy the whole template to your wiki.

If you don’t know much about programming and wikitext (also known as wiki syntax), then you have these options:


 * 1) Make a simpler template with fewer features.
 * 2) Make a table that looks kind of like the infobox. (And then make such a table in every article about every city.)
 * 3) Just give up and have an article about the Battle of Waterloo without an infobox.

If you do have some time and some knowledge about programming and wikitext, then here’s a simplified list of what you’ll have to do:


 * 1) Copy the code of this template to your wiki. You realize that it actually uses a module, which has 270 lines of code, and uses several other modules.
 * 2) You realize that this template alo uses a lot of other templates. You learn how to use Export feature. Export the template, with the  option enabled. As of this writing, this will import 112 templates and modules, and the XML dump will have more than 14,000 lines.
 * 3) Go through all the wiki syntax code you copied, find all the human-readable user interface strings that have to be translated, and translate them. Be careful not to touch parameters and parser functions.
 * 4) Go through all the wiki syntax and Lua code that you copied in 112 templates and modules, find all the parameter names and where they are used, and change them to your language. (This step is optional, but useful for editors who don’t know English.)
 * 5) Copy the documentation pages, delete all the English text from them, and write the same text in your language. Be careful to change the parameter names.
 * 6) Change the parameter names in TemplateData, but keep the English names as aliases.
 * 7) Make sure that the TemplateStyle pages were correctly imported. Fix the CSS if needed.
 * 8) Check that the template actually works and does what you need. If it does not, you may have to search for CSS or JS pages on which it depends.

You have to do all of this for every template that doesn’t exist in your wiki. And it has to be done in every wiki. And now you have a forked version of the template, so importing new features from the English Wikipedia will be far from trivial. These are basically the problem that the Global templates proposal is trying to solve.

Working together
A cross-wiki community of template and module maintainers will have to arise as early as possible. It must be truly global, serving all projects equally: Wikipedia, Wikidata, Commons, and even the less famous projects, such as Wikinews and Wikispecies. All wikis need global templates and there must be no preferential treatment.

TODO: Add some more details about cross-wiki community building...

What to migrate
It was discussed several times what templates and modules should be migrated, for example on the pages meta:Which templates should be global? and Multilingual Templates and Modules. All the proposals there make sense.

One approach may be to define which are the most used modules and templates across versions and projects, and then start the migration from there. Attention: the keyword here is used, not needed, since this will help us on two different levels:
 * 1) Focusing on what is already a core functionality across projects; and
 * 2) Demonstrating that the whole project works and has positive feedback for involved communities.

Potential candidates for this “phase 1 migration” might be:


 * Module:Arguments, used on ~340 projects
 * Module:String, used on ~285 projects
 * Module:No globals, used on ~275 projects
 * Module:Wikidata, used on ~140 projects
 * Template:Ambox, used on ~350 projects
 * Template:Speedy delete, used on 820 projects
 * Template:Bot, used on 654 projects
 * All the modules managed by the bot, because they are already global in practice.
 * The various Cite templates and modules

And so on. A more precise list of potential candidates can be this one. (It should be noted how many “universally needed” modules and templates are not present in all projects, one more time underlining the necessity of such a project)

What should be avoided, though, it’s a potential feeling of imposing something to the community. This can arise when locally a module or a template has been modified to the point that it’s not similar to the one of other communities. For this reason, phase 1 should probably limit to “non-controversial modules and templates”, i.e. modules and templates with the most basic functionalities as possible—speedy deletions, boxes, and such.

Migrating local to global
''TODO: This is only an outline. The section will be rewritten in more detail''

Many of the actions are the same for templates and the modules, so they are given together. It’s split where relevant.

Migrating the first version of a template or a module from a local wiki to the global repo
Every template or module can be a candidate for moving to the global repository. If, for any reason, a template or a module is supposed to remain local, it should be tagged accordingly.


 * Check that it is not already available in the global repo. If it is already there, proceed to the next section.


 * Recursive: If this module or template uses other modules or templates, migrate them first.
 * Export the template or the module page and its documentation page from the local wiki and import it to the global repo. Add sitelinks to the imported pages in the corresponding Wikidata item pages.
 * Find which CSS styles does the template or the module use.
 * Some of the template’s CSS will be in TemplateStyles. In templates, they appear in tags, and in modules they are in code that looks like . TemplateStyles are supposed to be exported and imported automatically in the XML file by the export tool.
 * Some others CSS rules that are used by the template will be in Common.css or other wiki pages. Find them and copy them to a TemplateStyles page in the global repository. (Don’t put them in Common.css. They should not have been there in the first place, because Common.css is for the whole site, and putting styles for particular templates there has always been an unfortunate hack.)

Making it translatable
If this template or module is intended for use in several wikis in the same language, then translatability is not required and this whole section is optional.


 * Find all the human-readable strings that are displayed to users:
 * Modules: Find all the instances of literal strings in quotation marks in Lua code. Skip those that are used internally, and process only those that are actually displayed to users.
 * Templates: Find all the strings that are not pure wiki syntax (tables, links, other tempalte invocations,, etc.). Note that template parameters are treated separately!
 * Move all the strings to a separate storage and replace them with message keys.
 * Modules: Remove the literal strings in quotation marks in Lua code and change them to in message keys. (How will this actually work is to be determined, see .) Pay attention to string concatenation (e.g. ), which may require translation placeholders.
 * Templates: Remove the literal strings from the template and replace them with message keys in the wikitext. (How will this actually work is to be determined, see .)
 * TBD: Another option is to do something like what is done in the TNT system: add tags and translate them like a.
 * Make the strings translatable using Translate:
 * Make sure that this template or module is conveniently discoverable in the project selector.
 * Add message documentation (known as “qqq” in core and extensions) so that translators would understand the context.
 * Apply the usual best practices from the page.
 * Make the template or the module usage documentation translatable as a . (TODO Consider creating association between the UI strings translation and the documentation translation.)
 * Templates: Make the template’s title and parameter names translatable. (How will this actually work is to be determined, see .)

Discarding the local wiki page when creating the first version in the global repo

 * Delete the template or the module from the local wiki.
 * Delete the template or the module documentation page from the local wiki.
 * Templates: Delete the CSS styles used by the template from TemplateStyles, Common.css, or other CSS wiki pages, unless:
 * These styles are also used by other templates that were not yet migrated to the global repo.
 * These styles need to remain customized in the local wiki, and the customizations cannot be moved to the global repo conveniently.
 * Test that the template or the module still works as expected in the local wiki. Fix it if it can be fixed quickly, or restore the local template or module if it’s not trivial. Fix what’s needed, and then delete again, test, etc.

Switching from a local template or module to a version already available in the global repo
This should be done in every wiki in which a version of a template or a module that is already available in the global repo exists.

Start from comparing the code of the template or the module to the code in the global repo.

If the code is the same as the one in the global repo

 * Translate the template or the module’s strings into the wiki’s language. (This is optional, but highly desirable.)
 * Go to the “Discarding” section.

If the code is different
Was the template or the module imported some time ago, left unchanged, but updated in the other wiki? If the updates there are useful for your wiki, and the parameters are compatible with the current usage in the local wiki, do the same as in the “If the code is the same” section.

Was the template or the module imported some time ago, and changed only to adapt it to the local language? Copy the translated strings from the local wiki to the localizable module in the central repo. If there are no other differences, do the same as in the “If the code is the same” section.

Was the template or the module imported some time ago, and had some non-trivial functional changes? Or is it a module that has similar functionality, but was developed separately? Decide in the local wiki on a case by case basis. The main imaginable decisions are (in no particular order):


 * Stop here and keep the local module. Tag it as “don’t move to the global repository”, and explain why.


 * Decide that the local changes are not that important, and do the same as in the “If the code is the same” section.
 * Copy the local changes to the global template or module, making them usable for all wikis. This must be done only after making sure that they don’t break the functionality for other wikis and don’t make the global code harder to maintain.
 * Split the local template or module: Move the local changes to another template or module, and discard the local one.

Discarding the local wiki page in favor of a version in the global repo

 * Templates: If needed, localize the template title and parameters. (How will this actually work is to be determined, see .)
 * Check the parameters:
 * Modules: Check that the local and the global module have the same parameters. If they are not compatible, replace the current invocations of the module to use parameters that are compatible with the global module. This can often be done with a bot, but sometimes may have to be done manually.
 * Templates: Check that the local and the global template have the same parameters. They may be localized for your language, but the names must be mapped in the global repository. (How will this actually work is to be determined, see .) If they are not compatibe, replace the current transclusions of the template to use parameters that are compatible with the global template. This can often be done with a bot, but sometimes may have to be done manually.
 * Test that the global template or module works as expected in the local wiki. Fix if needed.
 * Delete the local wiki page with the template or the module.

Concluding

 * If you found anything problematic during the migration process, or if you migrate several templates or modules and you find yourself repeatedly doing something that isn’t documented here, update this guide for the benefit of other template developers.

Migrating global to local
Global templates and modules are usually supposed to be more useful for collaboration and localization, but sometimes a wiki community will want local control over how a template or a module works. Even then, it is better to override only a part of the functionality, but it must be possible to copy a global template or module fully to the local wiki, with all or some of the dependencies, and with translated strings.

Cross-wiki diff
A tool that shows a diff between revisions of wiki pages on two separate wikis. This would be useful for checking whether the module or the template is the same as on another wiki or the global repo. Comparing old revisions will be particularly useful, because it often happens with templates and modules that they are imported and forked.

Dependency look up
A tool that gets a list of the templates and the modules that a given template or module uses, and checks which ones are already global.

Module string migrator

 * Finds all the strings in Lua code.
 * Let the user select those that will be shown to users.
 * Copy them to the message storage.
 * Replace the strings in the code with message keys.

(This is just the first step, and the strings will probably have to be tweaked more later.)

Template string migrator

 * Find all the strings in wikitext: Everything that is not in, not ParserFunctions (including localized ParserFunctions), not template or module calls.
 * Copy them to the message storage.
 * Replace the strings in the code with message keys or put them in tags.

(This is just the first step, and the strings will probably have to be tweaked more later.)

When the dust settles
''TODO: This is only an outline. The section will be rewritten in more detail''


 * Some issues to address:
 * Where are the new modules and templates created?
 * How are changes coordinated between different wikis?

Looking even further into the future
''TODO: This is only an outline. The section will be rewritten in more detail''


 * Making templates semantic: making them accessible from VE toolbar, more machine readable, etc.
 * Wikilambda