Global templates/Proposed specification/uk



Це пропозиція функціональних вимог до глобальних шаблонів та модулів.

Ви також можете прочитати.

'''Цей проект наразі не здійснюється і не має жодних планів здійснення з чітко зазначеними виконавцями та строками, принаймні поки що. Це просто ідея, хоч і вельми деталізована.'''

Кінцевою метою є організація зусиль багатьох команд та проектів у втіленні цієї пропозиції, з належною архітектурою, управлінням продуктом і проектом, залученням спільноти тощо.

Цей документ не робить спроб вдаватися в деталі технічної імплементації як-от пам'ять, кешування, надання результату, дизайн PHP-коду тощо. Він спрямований тільки на визначення вимог до роботи пропонованого функціоналу з точки зору користувачів:


 * 1) Людей, які створюють і обслуговують шаблони та модулі.
 * 2) Людей, які створюють і редагують сторінки зі включенням шаблонів і модулів. Сюди входять всі дописувачі та всі види сторінок:
 * 3) * Всі рівні досвіду: від цілковитих новачків до людей з тисячами редагувань
 * 4) * Всі види інструментів редагування: редагування вікікоду, Візуальний редактор, Переклад вмісту та інші (навіть оператори ботів)
 * 5) * Всі вікі: Вікіпедія, Вікісловник, Вікімандри, Вікідані, Інкубатор і т.д., і будь-які нові проекти в майбутньому
 * 6) * Всі мови: англійська, французька, російська, іспанська, вірменська, перська, зулу, маніпурі тощо.
 * 7) * Всі види сторінок: статті Вікіпедії, їх сторінки обговорення, сторінки обговорення користувачів, сторінки дискусій спільноти, сторінки вікіпроектів, категорії, документації шаблонів тощо.

Презентація для ліфту
Значна частина функціоналу проектів Вікімедіа імплементується в шаблонах і модулях Lua. В їх нинішньому вигляді вони не можуть спільно використовуватися багатьма вікіпроектами. Через це їх важко інтегрувати з сучасними способами створення та редагування статей, як-от Візуальним редактором, Вікіданими та Перекладом вмісту. Їх також важко адаптувати до мобільних пристроїв. Це призводить до змарнування зусиль дописувачів і труднощів для новачків і малих проектів. Необхідно надати можливість спільного доступу до них з усіх вікі, подібно до зображень Вікісховища. Це зробить розробку ПЗ швидшою і дієвішою та дозволить дописувачам зосередитися на написанні статей. In their current form they cannot be shared across different wikis and languages. Because of this they are hard to integrate with modern ways of creating and editing articles, such as Visual Editor, Wikidata, and Content Translation. They are also hard to adapt to mobile devices. This causes waste of contributors’ effort, and difficulties for new editors and smaller projects. It must become possible to share them across wiki sites, similarly to Commons images. This will make software development faster and more robust and will let editors focus more on writing.

Проблема
Загальний коментар: якщо не зазначено протилежного, усі згадки "шаблонів" також стосуються Lua-модулів 

Шаблони реалізують функції сайтів Вікімедіа. Деякі з цих функцій дуже помітні, особливо картки, виноски, «джерело?» і багато інших. Всі читачі бачать їх, і всі дописувачі стикаються з ними майже в кожному редагуванні. Крім того, вони реалізують багато функцій внутрішнього управління спільнотами сайтів: запити на видалення, запити на розблокування, вираження підтримки в обговореннях, сортування статей для вікіпроектів, і т.д.

Шаблони надають ефективний механізм швидкого дизайну, розміщення та повторення фрагментів тексту і розмітки на багатьох сторінках. Втім, шаблони також мають кілька гострих проблем зі зручністю використання для всіх видів дописувачів.

Редагування вікірозмітки
Шаблони часто важкі для розуміння дописувачів, що редагують вікірозмітку. Досвідчені користувачі певного шаблона, ймовірно, впізнають його і зможуть відредагувати сторінку, яка його містить. Втім, не знайомі з цим шаблоном дописувачі при зіткненні з ним змушені будуть відшукати його документацію, навіть якщо вони загалом набули досвіду в редагуванні та з іншими шаблонами. А менш досвідчених користувачів може спантеличити загадковий текст з фігурними дужками, вертикальними рисками, знаками "дорівнює" і т.д

Для використання функції, імплементованої як шаблон, необхідно знати назву шаблону і вписати її у фігурні дужки ( – ) або скопіювати її з іншої сторінки. Це не очевидно для новачків, та й ветеранам доводиться запам'ятовувати кожен новий шаблон окремо.

Деякі вікі мають гаджети, які додають на панель редагування кнопки для вставлення поширених шаблонів проекту. Вони різні в кожній вікі, хоч багато шаблонів різних проектів на різних мовах виконують схожі функції.

Візуальний редактор
Користувачі Візуального редактора мають певні переваги у використанні шаблонів, але й у них з цим є негаразди. Зокрема, існує аналогічна проблема зі знаходженням шаблонів: у Візуальному редакторі весь функціонал шаблонів прихований за елементом меню “ ”, і користувачу необхідно знати назву шаблону для його використання.

Меню "" Візуального редактора містить елементи для математичних формул, єгипетських ієрогліфів, музичних нот і деяких інших функцій, імплементованих через розширення, але не містить таких елементів, як "Картка", "Джерело?", "Перетворення одиниць", "Цитата" тощо. Усі шаблони – однакові трафаретні елементи.

Існує один істотний виняток: деякі вікі мають кнопку "", яка додає примітки з шаблонами виносок. Втім, це виняток, який підтверджує правило. Навіть для базового функціоналу потрібне ручне налаштування, окреме для кожної вікі, і як наслідок на багатьох вікі цієї кнопки взагалі немає. Аналогічний виняток, доданий наприкінці 2019 року – спеціальна підтримка шаблонів "Джерело?", але й вона потребує особливих налаштувань на кожній вікі, щоб взагалі працювати.

Редагування кількох проектів
Багато шаблонів існують в одному проекті, але не в інших, і часто шаблон наявний в іншому вигляді. Через це важко або неможливо повторно застосувати навички, отримані в одному проекті: наданий шаблоном функціонал деколи недоступний, а іноді працює інакше. Це стосується не лише вікі різними мовами, а й різних вікі однією мовою, наприклад, англійських Вікіпедії та Вікіджерел.

Для дописувачів, які редагують різними мовами, шаблони ускладнють переклад. Перекладаючи сторінку, набагато важче впоратися з шаблоном, ніж текстом статті ("прозою"), робиться переклад вручну чи через Переклад вмісту. Користувачам часто доводиться пропускати шаблон або виправляти його після опублікування статті. Це також призводить до того, що недороблені переклади покидаються через страшний неперекладений шаблон.

Проблеми Перекладу вмісту, про які повідомляється найчастіше, пов'язані з шаблонами.

Переклад вмісту має функцію адаптації шаблонів, яка автоматизує частину процесу, але вона працює тільки якщо відповідний шаблон існує в обох мовних версіях і для всіх параметрів ретельно проставлено відповідник людьми, які обслуговують шаблон. Це необхідно робити для кожного шаблону кожною мовою окремо і вручну, і постійно підтримувати, коли змінюється вихідний шаблон. І це незважаючи на те, що функції шаблонів у всіх мовних версіях зазвичай однакові.

В ідеалі шаблони та їх параметри мали б переноситися на перекладену сторінку майже цілком автоматично, щоби перекладачі могли зосередитися на прозі, бо саме там найбільш потрібна робота людей.

Шаблон можна експортувати з однієї вікі в іншу, але створена копія не має прямого зв'язку з оригіналом. Вона або залишається такою, якою її створили, або розвивається окремо, призводячи до несумісності. Деколи люди підтримують різні копії, але це ненадійно і не може поширюватися на наявні у нас сотні вікі.

Параметри шаблонів можуть мате однакове призначення, але різні імена в різних вікі. Їх можна адаптувати, використовуючи псевдоніми (aliases) TemplateData, але це неоптимальний "хак": TemplateData було створено не для цього, і це потрібно робити вручну для кожної пари мов.

Шаблони змішують логіку алгоритмів, читабельні текстові рядки та форматування. Через це не існує надійного способу перекладати рядки користувацького інтерфейсу в шаблонах так, як це робиться у ядрі MediaWiki та розширеннях.

Редагування малих вікі
Новий вікі-проект створюють, встановлюючи ядро MediaWiki і вмикаючи стандартний набір розширень. На практиці це не надає всім однакові початкові умови, оскільки чимало ключових фукнцій великих вікі імплементовано в шаблонах: картки, "джерело?", службові плашки (як-от ) і т.д.

Розробка програмного забезпечення
Розробникам ядра MediaWiki, розширень, ботів, інших інструментів для аналізу, генерування і модифікації контенту вікісторінок складно розробляти функції, які залежать від наявності у вікі певниз шаблонів. Розробникам таких розширень, як GrowthExperiments, PageTriage, ContentTranslation, деяких компонентів Wikibase та багатьох інших доводиться або тестувати їх в ході роботи коду – а це погана ідея – або імпортувати шаблони до своїх локальних вікі чи онлайнової тестової вікі.

Дослідники, які отримують дані про вікі-контент через шаблони, мусять писати аналіичний код окремо для кожної вікі, й іноді врешті-решт обмежуються однією вікі. Примітний приклад – використання в англійській Вікіпедії шаблонів вікіпроектів для аналізу тем сторінок і оцінки якості статей.

Розширення і Шаблони: подібності й відмінності
Одним із головних припущень проекту є те, що шаблони і модулі дуже подібні до ядра MediaWiki та розширень. Вони є програмним забезпеченням, яке імплементує потрібні спільноті дописувачів функції. Зокрема, оскільки шаблони зазвичай розробляються самими дописувачами, очевидно, що спільнота дійсно їх потребує. Серйозні відмінності між ними полягають у тому, як вони розробляються, локалізуються і розгортаються.

Шаблони і модулі повинні стати подібними до розширень у деяких своїх ключових властивостях, яких їм нині бракує, і зберегти деякі хороші властивості, яких бракує розширенням.

Навички розробки шаблонів і модулів
Додатковий перелік важливих припущень, на яких основана ця пропозиція, є наступним:
 * Навички розробки шаблонів і модулів нетривіальні. І шаблони, і модулі мають чимало незрозумілих функцій.
 * Хоча багато найважливіших функцій сайтів реалізовано як шаблони і модулі, ці навички часто не помічаються, недооцінюються і вважаються за належне.
 * Є десятки людей з цими навичками, і вони редагують багато вікі. Зазвичай вони зосереджуються на своїх домашніх вікі й порівняно рідко спілкуються з дописувачами в інших проектах чи на інших мовах. Хоча технологія, що лежить в основі, скрізь однакова, не існує справжньої глобальної спільноти розробників шаблонів, яку можна було б порівняти з глобальною спільнотою розробників ядра MediaWiki чи розширень. Є випадки співпраці вікі-проектів над певними шаблонами, але вони нерегулярні.
 * Є також багато вікі, які не мають дописувачів з такими навичками. Вони або копіюють шаблони і модулі з інших вікі без повного розуміння принципу їх роботи і можливості ефективно їх перекладати і підтримувати, або зовсім не користуються шаблонами.

Така ситуація геть не оптимальна. Навички розробників шаблонів і модулів потребують більшого визнання. Вони розробляють дійсно необхідні функції, і є невід'ємною частиною спільноти дописувачів. На вікі багатьма мовами розробники шаблонів вигадують інноваційні функції для структуризації вмісту, представлення даних і модульності. Ці нововведення могли б бути корисними для багатьох вікі, але зараз не існує зручного механізму, щоб цього досягти.

І звісно ж, будь-яке вирішення цих проблем не повинне вводити абсолютно нові технології, які б звели нанівець багато років безпосереднього досвіду, набутого підтримувачами шаблонів. Отже, в синтаксисі розробки шаблонів і модулів необхідно зробити якомога менше змін. Що потрібно змінити, то це спосіб, у який вони розгортаються і поширюються вікі-проектами, і спосіб перекладу читабельного тексту в них.

Пропоноване рішення: Огляд
Вже багато функцій MediaWiki є глобальними у вікі:


 * зображення (завдяки Вікісховищу)
 * облікові записи користувачів
 * глобальний список спостереження станом на кінець 2020 року активно розробляється
 * та деякі інші.
 * глобальний список спостереження станом на кінець 2020 року активно розробляється
 * та деякі інші.
 * глобальний список спостереження станом на кінець 2020 року активно розробляється
 * та деякі інші.

It must be possible to store templates and modules in a global repository, too, and to localize them as robustly as it is done with extensions.

Global templates and modules will empower template maintainers in all wikis by letting them collaborate more easily on developing the templates’ code.

Global templates and modules will empower translators and localizers by allowing them to focus on translating just the user interface strings (“messages”), without having to look for strings in the code, and by allowing them to use the same skills and tools for translating templates and MediaWiki extensions.

Global templates and modules will empower content editors in all wikis to write and translate content that uses these templates without having to dive into the differences and to relearn different rules and skills in each wiki.

The syntax for developing templates and modules, and the general template maintenance and deployment cycle will not change, so all the skills that the template maintainers have acquired over the years will remain relevant.

All wikis will be able to use the global templates, but not forced to do this. Communities will keep their capability to override any global functionality, design, workflows, and data.

Localizing templates will be as convenient as localizing MediaWiki extensions.

Templates must be able to be semantic and global
Semantic means that other software components, especially Visual Editor and Content Translation, must have a general way to understand that a template exists and that it provides certain functionality, so that it will be possible to insert it into a page as an infobox, a citation, a maintenance tag, etc., and not only as a generic template. Currently, the closest thing there is to making templates semantic is TemplateData, but it only describes the template’s parameters. It doesn’t, for example, help Visual Editor add an “Insert infobox” button to the toolbar.

Global means that a template’s code must be maintained in one place and usable in all wikis.

Making templates semantic
Templates have never been robustly semantic, in the sense of being easy to handle by software that processes pages.

There are only a few examples of templates that were made semantic:


 * Various reference templates, which are usable from the Visual Editor toolbar “” button. They require writing a lot of separate code to configure Citoid on each wiki that wants to use them.
 * “Citation needed”, which was adapted to Visual Editor in late 2019. It also requires configuration on each wiki. For example: English, Hebrew, Slovene. As of this writing, French, Spanish, and most other languages are not configured for this, even though they have templates of this kind.
 * Templates for mentioning users in the Flow extension, which require local configuration, too.
 * Some dump processing and research tools can parse English Wikipedia’s WikiProject page assessment templates, which are usually added to talk pages.
 * The GrowthExperiments extension suggests editors to perform certain tasks in articles based on the templates that are transcluded in them. The template names have to be configured manually by writing JSON files separately in each wiki. For example: Czech, Vietnamese, Korean, Arabic.
 * The PageTriage extension is configured to work with English Wikipedia’s hatnote templates (also known as “tags”).

In the case of PageTriage, the extension essentially hard-codes a single wiki’s templates, making it unusable in other wikis without a significant rewrite. Even if the on-wiki configuration step is small, as it is with the Flow example, it still needs to be done. This doesn’t scale well for the 900 wikis that Wikimedia has, and the thousands that it will have in the future.

These things should be global by default, so that they will be immediately usable in at least a basic default configuration on all wikis at once by extensions, bots, dump analyzers, etc.

Storage and delivery
The global templates and modules can be stored in a central wiki (Meta, Commons, or a whole new wiki), and it can even be Gerrit or another repository.

The best solution is probably creating a new wiki that will store them, without getting mixed up with images, general community discussion, etc.

Using Gerrit as storage for templates and modules code is technically possible, but it would lose an important element of accessibility for template maintainers: editing a template in a wiki page is much easier and familiar to the vast majority of template maintainers than making Git commits and waiting for code review. Therefore, Gerrit probably shouldn’t become a way for storing the template and module code, at least not the primary one.

Global templates and modules must be stored in a common repository that can be edited by most wiki editors. Rules about blocking and special permissions should initially be similar to the rules in other wikis: everything should be open by default, and it must be possible to protect very common, sensitive, or frequently-vandalized templates. More detailed rules about protection levels can be developed by the editors community later.

How the templates are delivered to the target wikis is a question of internal engineering and architecture, as long as the other requirements are addressed. These questions were discussed in the past by some platform developers, for example around the Shadow namespaces project. This document tries to address related questions of how it works for the user who edits a page that uses a template, or who maintains the template itself—how to write it in a localizable way; how is it translated; how is it locally customized; etc. These questions weren’t addressed sufficiently in the previous architectural discussions on the topic.

Templates must remain easy to modify
An important feature of how templates currently work is that they are edited just like wiki pages and immediately become functional after publishing without review or deployment. This is somewhat dangerous because a bad edit can ruin many pages, but the fact is that it works mostly well.

This ease must be preserved. Community members who maintain templates will most likely reject moving to a new system that will require them to learn completely new skills and drag every change through an exhausting review and deployment phase. This probably means that storing the templates in Gerrit is not going to work, unless, perhaps, the process for review and deployment will be much easier than it is for extensions.

It must be possible to make some templates non-global
Not all templates should be forced to be global.

In fact, some templates should be local because they implement a functionality that is unique to a certain language. By their nature, such templates don’t need to be translated, and there should be a way to give a hint to both human editors and translation tools (such as Content Translation) that they don’t need to be adapted, and can be skipped or substituted. This is a part of the effort to make templates more semantic.

It must be possible to override some functionality or appearance of a global template
No community should feel that a functionality is imposed on it by some powerful external player, like the English Wikipedia community, the Wikidata community, the WMF, or anybody else. Global templates should be developed and used collaboratively for the common benefit. Most of the time it should work for everybody.

Sometimes some communities will have strong opinions about wanting to have particular functionality or design that will be different in their language or project, or to show an infobox with information that is different from what is shown in other projects, or not to show it at all. The capability to override things locally must be allowed from the start. (Or rather, it must not be taken away.)

A global template must be immediately usable in every wiki
Just like a global user page is immediately available in every wiki in which there is no local user page, every template or module that is created on the global infrastructure must be immediately usable in every wiki.

This must not require any extra steps, such as copying wiki pages, creating wrapper templates with a local name, administrator intervention, waiting for hours for caches to refresh, etc.

After the central version is updated, the updated version will be immediately shown everywhere. To prevent vandalism, the editors community will develop policies on permissions and protection levels.

If the user interface strings (also known as “messages”) were not translated, the template will nevertheless be usable and the strings will be shown in the fallback language. See the sections on localization for more details.

It must be possible to translate all user-facing strings
The user interface strings (messages) of core MediaWiki, extensions, and some external tools such as Pageviews are translated conveniently and robustly on translatewiki.net. This localization process is familiar to at least some editors in all languages.

It’s currently not possible to do the same with templates. Multilingual sites such as Commons and mediawiki.org have the “TNT” system for translating some templates, but it’s very complicated and cannot be reused for Wikipedia, Wikisource, etc.

Ideally, it should be possible to translate templates just like core and extensions, using a wiki with the Translate extension.

The translated string must become usable immediately after the translation is submitted using the Translate interface.

It can be possible to edit the user interface strings in raw wiki pages, but ideally they should be edited primarily through a dedicated translation interface.

Translators should be able to focus on translating nothing but text. Seeing any code around it makes it difficult for people who are not experienced with programming and JSON files to contribute easily. In addition, editing translations into languages that are written from right to left in raw text files is extremely inconvenient. The Translate extension already addresses all of these issues.

The template documentation pages must be translatable as well. It’s mostly enough to do it using the page translation feature of the Translate extension, but it may require some adaptations.

The language in which the strings are shown to the user
Templates are primarily used when they are integrated into content, so by default the translated messages must be shown in the wiki’s content language.

Some templates, however, are used as UI elements. Therefore, perhaps it makes sense to also allow showing the translated strings in the user language, when it’s different from the wiki content language. This may be particularly relevant for multilingual sites such as Commons, Wikidata, Meta, and mediawiki.org.

MediaWiki’s usual fallback language chains must be used when a translation is not available. For example, if a message is not translated into Quechua or Guarani, it will be shown in Spanish, if it’s not translated into Bashkir or Chuvash, it will be shown in Russian, and so on. The ultimate fallback language is English, so if this message is not translated into Spanish or Russian, it will be shown in English.

Message keys
Messages should be represented as keys, similarly to how it is done in MediaWiki core, extensions, and tools.

Writing translatable strings will probably be the largest change in the template development process that template maintainers will have to get used to. Hard-coded strings will have to be separated and moved to messages organized by key. It must be made as easy as possible not only for the translators, but also for the template maintainers. Otherwise, they won’t actually do it, and the feature will be effectively rejected.

To easily make keys globally unique, it’s probably OK to automatically include the global template name in the message key.

Transitioning tools
A tool should be developed that will help the transitioning of a template or a module to central storage. It can do the following steps:


 * 1) Export a template from a local wiki and import it into the global wiki.
 * 2) Export all the templates that are used by this template (cascading).
 * 3) Identify the human-readable strings, convert them to a list with keys, and replace them with keys in the template’s source code.
 * 4) Import the template’s documentation page and TemplateData.
 * 5) Import the necessary CSS pages.

In most cases, this automatic process probably cannot create a fully usable and robust template or module, but it can help begin the transitioning process.

Organizing messages
The Translate extension organizes messages by groups, also known as “projects”, which can be further organized by aggregate groups. For example, Article Placeholder, Score, and Poem are all groups that represent the corresponding MediaWiki extensions, and they are all included in the “Extensions used by Wikimedia - Advanced” aggregate group, along with many other extensions.

Projects that represent MediaWiki extensions are configured in YAML files in the translatewiki repository and shown in the Translate user interface in a project selector, also known as “message group selector”.

Since there are many more templates than extensions, some modifications may be needed in the way the Translate extension handles message groups to accommodate templates translation.

Each template should be a message group. Closely related templates should be grouped in an aggregate message group. They can be similar to the categories in which they are stored, and in fact, the categories may even be reused. Editing files in a Git repository to organize these message groups is probably not desirable, because it’s too complex and slow.

It would be nice to show group and template names as localized in the selector, but it’s also OK if they are shown in English. If it’s good enough for extension localizers, it’s good enough for template localizers, too.

Templates must be shown as message groups on the Translate extension’s Language statistics special page (Special:LanguageStats). This will help localizers find what templates need translation. This should be generally similar to all message groups, but there are some special considerations for templates:
 * There will be thousands of templates, so it will be nice if the table’s design corresponds to this somehow.
 * The table should show on how many pages is each template transcluded and make it possible to order the rows by this number, to help localizers prioritize what is more important to translate.

Finding how to translate a template
Every template description page needs to have a direct link to translating it to the user’s language.

Some templates use Wikidata labels as part of their UI instead of hard-coding strings. This is done at the moment in Wikidata Infobox on Commons, Infotaula persona (Infobox person) in the Catalan Wikipedia, and in several other templates. These labels and values can be localized in Wikidata itself. Such usage cannot cover all the needs of template localization, but it is legitimate and useful for particular purposes. As long as this is properly described in the template documentation, this can continue to be used, and probably doesn’t need special infrastructure adaptations. (Perhaps the translation of the relevant labels and values can be somehow integrated into the Translate interface for localizing the template, but this is optional.)

Message parameters and magic words
In core MediaWiki and extensions, many messages have parameters, sometimes also known as “placeholders”. They are named $1, $2, etc., and they are filled in run time. Parameters are particularly important for making messages robustly translatable because different languages have different word order.

Something like this is needed in templates, too, although it is possible that the form does not have to be $1, $2, but template-like parameters with triple curly braces ( { – } ). This is to be decided according to considerations of parsing and localization convenience.

The magic words PLURAL, GENDER, and GRAMMAR must be supported in template messages as in MediaWiki messages.

Message documentation
In core MediaWiki and extensions, every translatable message is documented for the convenience of developers and translators. The documentation may include information about where the message appears, what the $1, $2, etc. parameters are, whether the word is a verb or an adjective, etc. This documentation is stored as pseudo-language with the code qqq.

Such documentation will be useful for template translation, too. How it is stored is a question of technical architecture. Perhaps it can be combined with TemplateData, perhaps it can be stored as a qqq language, and perhaps it can be something else.

Source language
Templates will be imported to the global storage not only from English-language projects, but from wikis in many languages. More than ever, the localization tools must support translation from any language and not only from English.

Fuzzying
In core MediaWiki and extensions and in translatable pages, if the source message in English changes, the message is automatically marked as outdated or “fuzzy”. The existing translations continue to work, but are shown to translators as needing an update. (The translation manager can also mark a message as not needing fuzzying.)

A similar mechanism will be needed for template localization. However, since it would be nice not to force English as the source language, there should be more ways to mark messages as fuzzy.

Localization considerations for modules
Lua modules can load and parse translatable MediaWiki strings, but there is no defined way for storing these strings for Lua modules that are maintained as wiki pages. It is possible to package Lua modules as parts of extensions, and then they are able to load messages from the extensions’ i18/*.json files, but this is done in very few extensions at the moment. Rewriting templates in Lua may be a more robust solution from the engineering point of view, but Lua will not necessarily be embraced by all existing template maintainers, and their cooperation will be crucial to the project’s success, so this cannot be done to all templates.

Some very internal, technical modules that are commonly used, rarely changed, and don’t require internationalization can probably be painlessly moved into the Scribunto extension itself. Some examples are No globals and Arguments.

Localizing the template name
The template may have a different name in every language, but it must be directly connected to the central storage.

Global templates and modules are supposed to be immediately usable in all wikis without any extra steps, so it must be possible to transclude a global template in a local wiki page using its global name. The cross-wiki editors community shall decide what will be the policy for these global names.

Similarly to parameter names, templates may have different names in different languages, and this must be preserved. There must be a structured way to translate template names. Perhaps Wikidata sitelinks can play a role, but not necessarily.

If this is not done, editors will either avoid global templates, or wrap the global template in a local template with a translated name, and this will probably cause the template to lose the connection to the global entity. This is not desirable and misses the whole point of the project.

Template names must only be translated to languages that can be content languages of wikis. Translation to Formal German or British English are probably unnecessary. There may be a way to have aliases or redirects. Language variants, for example for Serbian and Chinese, must be supported according to these languages’ needs.

If a local template exists in a wiki and it has the same name as a localized name of a global template, the local template will be used. This is similar to how local files with identical names override global files on Commons, and how local messages in the MediaWiki space override the localization coming from the code.

Lua module names are often localized, too. Their names can be localized for direct invoking from wiki pages, but since code usually uses English-like identifiers, the internal global names should probably be preferred for use in the code itself, for example in  statements.

Localizing parameter names
Parameter names are different in every language. They are usually based on words in each language, so it’s important for editing the transclusion in wiki syntax conveniently.

Ideally, the global template should have generic internal parameter names that have translations to different languages. This is somewhat similar to Wikidata property name labels, but it can be simpler: since English is a lingua franca for software developers and templates are a kind of software, it’s probably OK to have English as the default source language rather than generic numbers as it is in Wikidata.

These generic parameter names will be the common default names. They will work in wikis in all languages. The localized names will work in the wikis that has that language as its content language.

These translations of parameter names must be validated:


 * they must not include invalid characters
 * they must not be repeated within one template in one language
 * Anything else?

The actual process of translating the parameter names may be different from translating user interface strings. These names have technical constraints, and they must remain stable because changing a name of parameter will break existing transclusions, so there should be some safeguards against this.

Automatic parameter translation
If all the localized template and parameter names are stored centrally, it will be possible to have a simple service that gets a valid template call with parameters, a source language name, and a target language name, and outputs a localized template call. For example:

Input:

Output:

In Content Translation this will be the primary way to adapt templates. Unlike the current template adaptation in Content Translation, this will be precise and complete, rather than based on guesses.

In visual editing and in 2017-style wiki syntax editing, simply copying and pasting a template from wiki in another language will do the parameter translation automatically.

For plain wiki syntax editing, there should be a simple way to operate this service, for example a special page or a dialog box where an editor can paste the template and the source language, and get the template with translated parameters.

In both cases only the names of the template and the parameters will be translated. Translating the parameter values is discussed separately.

Nameless parameters
Nameless numbered parameters must continue working, of course.

A decision is needed about how will their names be localized.

Translating parameter values
In addition to making the templates’ functionality and design shared, some thought must be given to making the template parameter values shared, as well as not shared.

Some parameter values are the same in all languages by their nature. Some examples include an IPA pronunciation of a place’s native name (e.g. [dɛn ˈɦaːx] for The Hague), the year of foundation of a city, the chemical formula of a compound, etc. At least some of these should probably be stored in Wikidata and easily loadable in a template.

Some parameter values have to be translated or transliterated, for example people’s names, translations of country mottos, etc.

Global templates must make this possible, but in practice, these things are still often copied across wikis, and this must be taken into account as well.

Some parameter values can be reliably and predictably converted automatically, and the global templates infrastructure must support this. For example, number formats and digit characters are often different in Burmese, in languages of India, and in some other languages, but they can be reliably converted using simple software.

Valid and functional parameter values must be usable in multiple languages and must not be language-specific. For example, using “yes” and “no” as boolean values is too English-centric. This probably doesn’t require changes in the infrastructure, but mostly an agreement in the cross-wiki template development community on good practices for adaptation to all languages.

Text direction
Templates must adapt themselves to the text direction (ltr / rtl) of the wiki in which they are displayed.

It must be convenient to write a template in a direction-neutral way, with as little explicit right and left alignment as possible.

Bots
Many templates in many wikis are regularly edited by bots. This capability must be preserved.

This is not supposed to require any changes in the software infrastructure, but it is mentioned here for completeness because it’s an important use case.

Transitioning the templates from the large wikis to central storage
The most popular source language for translation in Content Translation is English, by far. After it come Spanish, Russian, French, German, Catalan, Ukrainian, Italian, Chinese, and Portuguese. Because of this, it makes sense that the common templates in the editions of Wikipedia in these most common languages, especially those in English, are the ones that are the most important to make global for the benefit of all other languages.

Somewhat paradoxically, however, the editors in these largest languages are also the least interested in making them global:


 * The templates already work well for them and most people there don’t directly care about the convenience of translation to other languages.
 * Rewriting the templates so that the strings will be translatable may be time-consuming and may force them to learn some new template maintenance skills.
 * Making the templates suddenly used by many more projects may make it harder to achieve consensus about making future changes in how the templates work.
 * Editors from different major wikis will have to work on reaching consensus about merging some templates with similar functionality that already exist on their sites.

This is more of a consideration of practicality and community relations than a consideration of engineering, but it must be taken into account when making technical architectural decisions. Without doing proper preparation in this area, the whole project will fail.

As long as there are important common templates that are not global, Content Translation and other software that handles templates from different wikis in any way, will have to keep supporting them. If the infrastructure for global templates is created, and migration of existing templates proceeds in a good pace, developers may consider stopping developing and some day deprecating the code for non-global template adaptation.

The pace of migrating templates from large wikis to the central repository can be one of the success metrics for the project.

It must be possible to use templates completely in both wiki syntax and in visual editing
It’s obvious, but should be mentioned anyway: Wiki syntax editing is not going away soon, and it must be possible to keep editing template transclusions in pages as it is done now. This must not become more complicated.

However, Visual Editor is increasingly embraced by both experienced and new editors, so every feature of how templates work must work well in both visual and wiki syntax editing.

Other features related to templates
There are some features that deal with templates in core MediaWiki and its extensions. All of them must continue working, and may need updating for the global templates age.

Core MediaWiki
There should be on-wiki tools for showing at least basic analysis of templates’ and modules’ usage on pages: the number of transclusions and invocations grouped by wiki, and lists of pages that use the templates and the modules. The feature that shows which templates does a page transclude while it’s being edited must continue working with global templates.

The “” page must keep working, and remain useful for global transclusions.

TemplateData

 * It is possible to translate template and parameter descriptions in TemplateData, and the translations are displayed in the user interface language in Visual Editor’s template insertion dialog. This is good and must be preserved. The translation interface could possibly be improved, but the beginning is good. Adding support for TemplateData in the Translate extension can be a solution for this, but there can also be other solutions.
 * The “” parameter must keep working. It must also be possible to customize them per wiki—some wikis may prefer to see a certain template written in wiki syntax as one line, and some may prefer multiple lines.

Citoid

 * Citoid has to be configured on every wiki separately using JSON files, such as Citoid-template-type-map.json. In the global templates age, it must become possible to share these files, so that the “” button would be available in all wikis and work identically everywhere by default. As with templates, there must be a way to override this default in each wiki where the community wants different behavior.

TemplateStyles

 * There must be a possibility to write Template Styles pages in the same central repository as templates. The central style must be loaded by default, and it must be possible to override it locally.

TemplateSandbox

 * Special:TemplateSandbox must keep working.
 * It must be possible to edit a template in the central repository and preview it in a page in the target wiki.

TemplateWizard

 * The current system uses a wiki’s standard search to find templates. The results are presented in a list that might need to be changed to make the global or local status visible.
 * TemplateWizard gets its information for templates from the TemplateData API, so as long as that keeps returning the same structure there shouldn’t be any issues, and i18n is already working.

Wikibase

 * Wikidata can be used to bring in some parameter values from a central repository to the wiki. This is used productively in Wikipedia in several languages, among them French, Hebrew, Basque, Russian, Catalan, Estonian, and some others, as well as in Commons, although the actual implementation may differ. This must continue working, of course. Unifying the way in which it is done across different wikis may become one of this project’s most significant impact areas.
 * It may also make it much easier to implement Wikidata Bridge, the project to allow editing template values from within wikis. The modifications to the templates themselves will have to be done only once in the global templates, and not in each wiki.

VisualEditor

 * VisualEditor obviously needs to be able to insert both global and local templates.
 * VisualEditor shows a link to the template description page in the template editing dialog. This link should point directly to the global template when it is used.

Development and deployment
Developing the infrastructure for global templates and modules is a large and complex project. It must be divided into manageable parts to get done. Roughly, the multiple parts of this project should be developed in the following sequence:


 * 1) : Before making the modules shareable across wikis, the internationalization and localization framework for them should be developed. This will be immediately useful to modules on wikis that are already multilingual, most notably Commons and Wikidata. Some of them are currently translated using the “TNT” system, but this could be better.
 * 2) Global modules: Modules become shareable across wikis. This should happen before making templates shareable, because the modules’ infrastructure is less coupled to core MediaWiki, and they will be easier to migrate.
 * 3) Translatable templates: This is similar to Translatable modules above, and can reuse much of the same framework, but it will also need the capability to translate the names of the template itself and its parameters and some other features. See the sections on localization in the specification.
 * 4) Global templates: Complete the project with making the templates global.

The development of more advanced features, such as making templates semantic can and should come later, after they are shareable. If they become semantic before they are shareable, the code that describes them semantically will be forked on different wikis, like the templates themselves, which will make code reuse even harder than it is today.

Access to global templates and modules will be available from all the Wikimedia wikis. This includes editions of Wikipedia, Wiktionary, Wikivoyage, etc. in all the languages, as well as Commons, Wikidata, Meta, mediawiki.org, Wikitech, etc., as well as test wikis (test.wikipedia.org, etc.) This is similar to how images on Commons are available on all the wikis. Even though the global templates and modules will be available to the wikis, the wikis won’t be obliged to use them.

Making templates easily reusable on non-Wikimedia projects may be desirable, too. Even though it doesn’t directly benefit Wikimedia projects, it may make sense to consider making templates easily reusable not only across Wikimedia projects, but also on other MediaWiki sites. Doing this will probably require some more work, but it may contribute to better modularization, and this may eventually benefit Wikimedia projects, too. This is comparable to the capability of direct embedding of images from Commons on non-Wikimedia websites.

Imagine a world
Imagine a world in which every single human being can freely share in the sum of all knowledge and it’s actually a really easy thing to do because templates are global:

(Note: The “With global templates” column assumes that the infrastructure is deployed in all Wikimedia wikis, and that the most often used templates are moved to the central infrastructure.)

Status
''This section is about the general status of the project. For details about the latest developments, as well as a brief history of past efforts, see the page Global templates/Status.''

As noted above, as of December 2020, this page is only a big idea, and not a commitment to implement a project.

Similar ideas were suggested in the past. The oldest known suggestion to make templates reusable across wikis was raised in December 2004 in Bugzilla: Interwiki templates. Several other similar ideas were raised later, for example Phabricator. In February 2017 a similar proposal called Global-Wiki was closed as "consensus". Some of its components were implemented, such as global preferences, but not the templates.

The wish "Central global repository for templates, gadgets and Lua modules" was voted #3 at the Community Wishlist Survey 2015 and "Global gadgets" was voted #1 in Community Wishlist Survey 2016. Despite the community support, neither was implemented, because they weren’t appropriate for the Community Tech team, and they weren’t transferred to another team either.

The Platform Evolution project (2018) indicated some intentions to have support for global templates in the future. The page Platform Evolution/Recommendations discusses ideas for updating content modularity, and says:


 * ... “boxes” are an ideal focus area for creating modularity. They represent self contained features and also an opportunity to enable equitable sharing of user features across projects and languages be establishing a cross-project service to share templates. This project will also force us to consider how to handle content layout and structure separately from composable pieces content.

The closely related page Platform Evolution/Goals lists this as one of the goals:


 * Increase equity and power of contribution tools. We want to support the contribution of more content types of content, including media, in more interactive ways and across all projects. This means making some existing tools - like templates - available for consistent reuse across all projects and languages. It also means improving translation tools to remove silos of content. Finally, we also want to make it easy for contributors to create new cross-project, localizable content tools.

Abstract Wikipedia, which was approved by the WMF in July 2020 as a new project to be developed in the near future, includes “a cross-wiki repository to share templates and modules between the WMF projects” inside its Wikifunctions component as one of its major goals (Wikifunctions was previously known as “Wikilambda”).

The initiative was launched in September 2020. It addresses a part of this proposal.

In Community Wishlist Survey 2021, the wish titled “Templates translation” received the highest number of votes. It was also the wish with the highest number of votes in the history of the survey to date (December 2020). This wish closely corresponds with some parts of this proposal, especially Automatic parameter translation.

For other examples of relationship between this Global templates proposal and various strategic plans in the wider Wikimedia community, see the page.

There is no complete technical plan for implementing full-featured cross-wiki sharing of modules and templates. This page is an attempt to propose such a plan and listen to feedback from editors.

Useful links
Some relevant pages that discuss similar topics:


 * Platform Evolution/Goals
 * Platform Evolution/Recommendations
 * Multilingual Templates and Modules - An attempt to implement a similar feature using bots
 * m:Community Wishlist Survey 2015/Results - Central Global Repository for Templates, Lua modules, and Gadgets came in as #3 in the Community Wishlist vote. Listed as “In development - Parsing team”, but not actually done.
 * m:Which templates should be global? - an informal list made by various editors
 * Requests for comment/Shadow namespaces - a dormant RFC about one proposal for a technical implementation of such an infrastructure
 * - an existing rudimentary mechanism for transcluding content across projects. Considered inefficient and insecure, and disabled on Wikimedia projects.
 * m:Global-Wiki - a similar proposal, with a wider scope. Was open for discussion for several years, and closed as "consensus". Some things in it were implemented, such as global user pages and preferences, but it also includes global templates, which are not yet done.
 * m:Abstract Wikipedia - A bigger proposal, which includes a global module and template repository (also known as Wikifunctions, and previously known as “Wikilambda”).
 * m:Community Wishlist Survey 2021/Translation/Templates translation - A community wish that corresponds to some parts of this proposal, especially Automatic parameter translation.