Global templates/Proposed specification/fr

  Татары, узбеки и ненцы И весь украинский народ, И даже приволжские немцы К себе переводчиков ждут. И может быть в эту минуту Меня на турецкий язык Японец какой переводит И в самую душу проник. — Осип Мандельштам

Ceci est une proposition des besoins fonctionnels pour les modules et les modèles globaux.

Vous pouvez aussi lire la.

'''Ceci n'est pas un projet en cours ou prévu par qui que ce soit ni quand que ce soit, pas pour le moment tout du moins. Il s'agit juste d'une idée, bien que ce soit une idée très détaillée.'''

L'objectif final est de créer un engagement multi-équipes et multi-projets sur la mise en œuvre de ces éléments, avec une architecture appropriée, une gestion de produits et de projets, un engagement de la communauté, etc.

Ce document n'essaie pas d'entrer dans les détails de la mise en œuvre technique en termes de stockage, de mise en cache, de livraison, de code PHP, etc. Il tente uniquement de définir les spécifications de cette fonctionnalité du point de vue des utilisateurs :


 * 1) personnes qui créent et gèrent des modèles et des modules.
 * 2) personnes qui créent et modifient des pages qui incluent des modèles et des modules. Cela comprend tous les éditeurs et toutes sortes de pages :
 * 3) * Tous les niveaux d'expérience : depuis ceux complètement nouveaux à ceux qui ont effectué des milliers de modifications
 * 4) * Toutes sortes d'outils d'édition : édition en syntaxe de wiki, Éditeur visuel, traduction de contenu, et autres (même les opérateurs robot)
 * 5) * Tout les wikis: Wikipédia, Wiktionaire, Wikivoyage, Wikidata, Incubator, etc. et tous les futurs projets
 * 6) * Toutes les langues : anglais, français, russe, espagnol, arménien, persan, zoulou, manipuri, etc.
 * 7) * Toutes sortes de pages : articles Wikipédia, page de discussion des articles, page de discussion des utilisateurs, pages de discussions communautaires, pages projets, catégories, pages de documentation des modèles, etc.

Résumé
Une grande partie des fonctionnalités des sites de Wikimedia sont mises en oeuvre à l'aide de modèles et de modules LUA. Sous leur forme actuelle, ceux-ci ne peuvent être partagés entre différents wikis et différentes langues. De ce fait, il est difficile de les intégrer dans les outils modernes de création d'articles et de contribution aux articles tels que l'Éditeur Visuel, Wikidata et la traduction de contenu. Ils sont également difficiles à adapter aux périphériques mobiles. Cela entraîne une perte des efforts des contributeurs et des difficultés pour les nouveaux contributeurs et les petits projets. Il doit être possible de les partager entre les sites de wikis, comme les images de Commons. Ceci rendra le développement logiciel plus rapide et plus robuste et permettra aux contributeurs de se concentrer sur l'écriture.

Le problème
Remarque générale : sauf indication contraire, le terme « modèle » s'applique aussi aux modules Lua 

Les modèles mettent en oeuvre des fonctionnalités sur les sites de Wikimedia. Certaines sont très importantes comme les infobox, les références, "Référence nécessaire" et beaucoup d'autres. Tous les lecteurs les voient et tous les auteurs les utilisent dans pratiquement chaque edition. De plus, ils sont utilisés dans la plupart des fonctionnalités de gestion interne de la communauté : pages à supprimer, demande de déblocage, expression de leur support dans les pages de discussion, classement des articles dans les WikiProjets, etc.

Les modèles sont un mécanismes efficaces pour la conception, le déploiement et l'utilisation répétitive du texte ainsi que pour le balisage dans de nombreuses pages. Cependant, les modèles posent des problèmes dans tous les éditeurs.

Éditeurs de syntaxe Wiki
Pour les contributeurs, les modèles sont souvent difficiles à comprendre dans la syntaxe wiki. Les personnes habituées à utiliser un modèle particulier vont probablement le reconnaître et pourront modifier une page qui l'utilise. Néanmoins, les contributeurs qui sont face à un modèle qui ne leur est pas familier, devront lire sa documentation, même s'ils ont une expérience générale sur la manière de modifier ainsi que des autres modèles. Et les contributeurs qui n'ont qu'une expérience élémentaire seront rebutés à la vue d'un texte crypté d'accolades, de barres verticales, de signes égal, etc.

Utiliser une fonctionnalité implémentée dans un modèle implique que vous connaissez le nom du modèle et que vous l'appeliez avec des accollades ( – ) ou que vous le copiez d'une autre page. Ceci n'est pas évident pour les nouveaux utilisateurs, et les utilisateurs confirmés doivent aussi réapprendre séparément chaque nouveau modèle.

Certains wikis ont des gadgets qui ajoutent des boutons pour insérer des modèles communs au projet et à la barre d'édition. Cela dépend des wikis, même si beaucoup de modèles ont des fonctionnalités similaires parmi les projets et les langues.

Utilisateurs de l’éditeur visuel
Les utilisateurs de l'Editeur Visuel ont certains avantages en utilisant des modèles, néanmoins ces derniers présentent également quelques problèmes : dans l'Editeur Visuel toutes les fonctionnalités des modèles sont cachées derrière l'élément de menu «   » et l'utilisateur doit connaître le nom du modèle avant de les utiliser.

Le menu « » de l'Editeur Visuel possède des entrées pour les formules mathématiques, les hyéroglyphes égyptiens, les partitions de musique, et quelques autres fonctions qui sont implémentées par les extensions, mais il n'y a rien concernant les boîtes d'information, les références nécessaires, la conversion d'unités, la mise entre apostrophes, etc. Tous les modèles sont du même type d'éléments génériques.

Sauf une exception : certains wikis possèdent le bouton « », qui insère des notes de bas de page avec les modèles référencés. Néanmoins, c'est une exception qui prouve la règle. Cela nécessite de configurer manuellement même les fonctionnalités de base, et cette configuration est fait séparément pour chaque wiki; en conséquence de quoi, beaucoup de wikis n'ont pas du tout ce bouton. Une autre exception comparable, qui a été ajoutée dernièrement en 2019 est la prise en charge spéciale des modèles Références nécessaires, mais ceci nécessite en plus pour chacun certaines configurations adaptées ainsi que pour chaque wiki, afin que cela puisse fonctionner.

Difficultés pour les éditeurs qui écrivent dans plus d'un projet
 Keep what ya got by giving it all away. Keep what ya got by giving it all away. Keep what ya got, Hold it, don’t stop, Keep what ya got by giving it all away. — Ian Brown Dans un projet donné, il y a beaucoup de modèles, mais pas dans d'autres, et souvent le modèle existe mais sous une forme différente. A cause de cela, il est difficile ou impossible de réutiliser la connaissance acquise dans un projet : les fonctionnalités fournies par le modèle ne sont quelquefois pas disponibles ou fonctionnent différemment. Ceci ne s'applique pas seulement aux wikis de langues différentes, mais aussi à différents wikis d'une même langue, par exemple les Wikipedia et Wikisource anglophones.

Pour les contributeurs qui modifient en différentes langues, les modèles rendent la traduction plus difficile. Lorsque vous traduisez une page, les modèles sont beaucoup plus difficiles à manier que le texte des articles (c'est à dire la prose), que la traduction soit faite de manière manuelle ou par la traduction de contenu. Les utilisateurs doivent souvent sauter le modèle ou le corriger après que l'article ait été publié. Ceci a pour conséquence que certaines traductions restent inachevées parce que la traduction du modèle apparaît intimidante.

Les problèmes rapportés le plus souvent dans la traduction de contenu concernent les modèles.

Content Translation has a template adaptation feature, which automates some parts of this process, but it works only if a corresponding template exists in both languages, and if all the parameters were meticulously mapped by the template maintainers. This must be done for each template in each language separately and manually, and continuously maintained when the source template changes. This happens even though the templates’ function across the languages is the same most of the time.

Dans l'idéal, les modèles et leurs paramètres doivent être transférés dans la page traduite de manière presque complètement automatique, de sorte que les traducteurs puissent se focaliser sur l'écriture du texte, car la prose dans le domaine où l'humain travaille est la chose la plus nécessaire.

A template can be exported from one wiki to another, but once this is done, the template becomes a forked copy. It either stays in the state in which it was exported, or continues to be developed separately, causing incompatibility. Sometimes people keep maintaining the different copies, but this is not robust and cannot scale for the hundreds of wikis that we have.

Template parameters can have the same functionality, but different names in different wikis. They can be adapted using TemplateData aliases, but this is a suboptimal hack: it is not what TemplateData was originally made for, and it has to be done manually for each language pair.

Les modèles mélangent la logique algorithmique, les chaînes de caractères lisibles par les humains, ainsi que le formatage. A cause de tout cela il n'existe pas de manières robustes pour traduire le texte des interfaces utilisateur des modèles comme cela est fait dans le noyau MediaWiki et les extensions.

Difficultés pour les éditeurs dans les petits wikis
A new wiki project is created by installing core MediaWiki and enabling a default set of extensions. In practice this doesn’t create a level playing field because a lot of the key features of larger wikis is implemented in templates: infoboxes, citations, maintenance hatnotes (such as ), etc.

Difficultés pour les développeurs logiciels
For developers of MediaWiki core, extensions, bots, and other tools that analyze, generate, or modify wiki page content it is difficult to develop features that depend on the presence of certain templates in a wiki. Developers of extensions such as GrowthExperiments, PageTriage, ContentTranslation, some components of Wikibase, and many others, have to either test them in production, which is a bad idea, or to import the templates to their local wikis or an online test wiki.

Researchers who get data about wiki content based on templates have to write their analysis code for each wiki separately, and sometimes they end up doing for only one wiki. A notable example is using English Wikipedia’s WikiProject templates to analyze page topics and assess article quality.

Extensions et Modèles : similitudes et différences
One of the main assumptions of this project proposal is that templates and modules are very similar to MediaWiki core and extensions: They are software, and they implement features that the editors community needs. In particular, since templates are usually developed by the editors themselves, it’s obvious that the community really needs them. The big differences between lie in how they are developed, localized, and deployed.

Templates and modules should become similar to extensions in some key properties that they currently lack, and preserve some good properties that extensions lack. (For ease of understanding by English readers, in the table, examples of templates are given from the English Wikipedia. They could also come from any other wiki and any other language.)

Compétences pour le développement des modèles et des modules
Un autre ensemble important d'hypothèses sur lesquelles cette proposition est basée est le suivant :
 * Les compétences requises pour le développement des modèles et des modules ne sont pas évidentes. A la fois les modèles et les modules comportent des fonctionnalités obscures.
 * Bien que les fonctionnalités notables sur la plupart des sites soient implémentées sous forme de modèles et de modules, ces connaissances ne sont souvent pas remarquées, non appréciées, ou prises pour argent comptant.
 * Il existe des dizaines de contributeurs qui ont ces compétences et qui modifient plusieurs wikis. Ils se concentre d'ordinaire sur leur wiki d'accueil et communiquent très rarement avec les contributeurs d'autres wikis ou d'autres langues. Néanmoins, la technologie sous-jascente est la même partout, il n'existe pas vraiement de communauté globale réelle de développeurs de modèles qui pourrait être comparée à la communauté globale des développeurs du noyau MediaWiki et des extensions. Il existe des cas de collaboration inter-wiki pour certains modèles, mais ils ne sont pas cohérents.
 * Il existe aussi beaucoup de wikis pour lesquels il n'y a pas de contributeurs ayant ces compétences. Soit ils recopient les modèles et les modules à partir des autres wikis sans comprendre complètement la manière dont ils fonctionnent et sans avoir la possibilité de les traduire et de les maintenir effectivement, soit ils n'utilisent pas du tout ces modèles.

This situation is far from optimal. The template and module developers’ skills need more appreciation. They develop truly needed features, and they are embedded in their editors communities. In wikis in many languages, the template developers come up with innovative features for structured content, data presentation, and modularization. These innovations could be useful in many wikis, but currently there is no convenient mechanism to achieve this.

And of course, any solution for these problems must not come up with completely new technologies that will discard the many years of hands-on experience that the template maintainers have acquired. Hence, there must be as few changes as possible in the syntax for developing templates and modules. The things that need to change are the way in which they are deployed and propagated across wikis, and the way in which the human-readable strings in them are localized (translated).

La solution proposée : sommaire
Beaucoup de fonctionnalités de MediaWiki sont déjà globales à tous les wikis :


 * images (en utilisant Commons)
 * comptes utilisateur
 * et quelques autres.
 * et quelques autres.
 * et quelques autres.
 * et quelques autres.
 * et quelques autres.

Il faut pouvoir sauvegarder les modèles et les modules sur un dépôt global, et aussi pour les internationaliser avec la même robustesse que cela est fait avec les extensions.

Les modèles et les modules globaux permettront aux responsables de modèles dans tous les wikis, de collaborer plus facilement au développement du code de ces modèles.

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.

Les modèles globaux et les modules vont renforcer les éditeurs de contenu dans tous les wikis pour l'écriture et la traduction de contenu qui utilise ces modèles, sans rentrer dans les différences, ni réapprendre les différentes règles et les connaissances liées à chaque wiki.

La syntaxe pour développer les modèles et les modules ainsi que la maintenance générale et le cycle de déploiement ne changent pas, donc toutes les connaissances accumulées pendant les années par les personnes qui ont travaillé à la maintenance des modèles, restent valables.

Tous les wikis pourront utiliser les modèles globaux, mais n'y seront pas obligés. Les communautés garderont leur capacité à réécraser les fonctionnalités globales, l'architecture, les flux de travail et les données.

L'internationalisation des modèles sera aussi aisée que l'internationalisation des extensions MediaWiki.

Les modèles doivent être sémantiques et globaux
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 indique que le code du modèle est maintenu à un seul endroit et qu'il est utilisable par tous les wikis.

Rendre les modèles sémantiques
Les modèles n'ont jamais été sémantiquement robustes, dans le sens d'être facilement utilisables par le logiciel qui traite les pages.

Voici seulement quelques exemples de modèles qui ont été rendus sémantiques :


 * Différents modèles de référence, utilisables à partir du bouton « » de la barre d'outils de l'Editeur Visuel. Ils nécessitent d'écrire beaucoup de code séparé pour configurer Citoid sur chaque wiki qui veut les utiliser.
 * “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.
 * Modèles pour mentionner des utilisateurs dans l'extension Flow, nécessitant aussi une configuration locale.
 * Certains processus de vidage (dump) et outils de recherche peuvent analyser syntaxiquement les modèles d'acces aux pages des projets wiki de la Wikipedia anglophone, qui sont habituellement ajoutés aux pages de discusssion.
 * 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.
 * L'extension PageTriage est configurée pour fonctionner avec les modèles des notes chapeau de la Wikipedia anglophone (également connues comme « balises » ).

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.

Ces éléments doivent être globaux par défaut afin d'être immédiatement utilisables par les extensions, les robots, les analyseurs de dump ..., dans au moins une configuration par défaut sur tous les wikis et en même temps.

Stockage et diffusion
Les modèles globaux et les modules peuvent être stockés sur un wiki central (tel que Meta, Commons, ou un wiki complètement nouveau), ou même être Gerrit ou un autre dépôt.

La meilleure solution est probablement de créer un nouveau wiki qui va les héberger, sans les mélanger avec les images, les discussions générales de la communauté, 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.

Les modèles doivent rester faciles à modifier
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.

Il doit être possible de rendre les modèles non globaux
Tous les modèles ne seront pas forcés à devenir globaux.

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.

On doit pouvoir réécraser certaines fonctionnalités ou l'apparence d'un modèle global
 ਸਹੀ ਰਸਤਾ ਵਖਰੇ ਲੋਕਾਂ ਲਈ ਵਖਰਾ ਹੈ। ਆਪਾਂ ਏਕਤਾ ਵਿਚ ਰਹਿਏ, ਜੈ ਜੈ। — ਤਜਿੰਦਰ ਸਿੰਘ 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.)

Un modèle global doit être immédiatement utilisable dans chaque wiki
Tout comme une page utilisateur globale est immédiatement disponible sur chaque wiki où il n'y a pas de page utilisateur globale, chaque modèle ou module créé dans l'infrastructure globale doit être immédiatement utilisable dans chaque wiki.

Cela ne doit pas induire d'étapes supplémentaires, telles que copier des pages wiki, créer des modèles de type conteneur avec un nom local, faire intervenir un administrateur, attendre pendant des heures que les caches se remettent à jour, etc.

Après que la version centralisée a été mise à jour, la nouvelle version apparaît partout. Pour combattre le vandalisme, la communauté des éditeurs développera des règles sur les droits ainsi que des niveaux de protection.

Si le texte de l'interface utilisateur (connu également comme composé d'un ensemble de messages) n'est pas traduit, le modèle reste utilisable néanmoins mais le texte est affiché dans la langue de repli. Voir les sections sur l'internationalisation pour plus de détails.

Le texte présenté à l'utilisateur doit être traductible
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.

Au mieux, il doit être possible de traduire les modèles tout comme on le fait pour le noyau ou les extensions, en utilisant un wiki avec l'extension.

La chaîne traduite doit être immédiatement utilisable après que la traduction ait été fournie par l'interface Translate.

Il doit être possible de modifier le texte de l'interface utilisateur sur des pages wiki brutes, mais l'idéal est qu'il soit modifié d'abord en passant par un interface de traduction dédié.

Les traducteurs doivent pourvoir se concentrer sur la traduction uniquement du texte. En faisant apparaître du code à côté, les personnes avec moins d'expérience en programmation et avec les fichiers JSON auront plus de difficultés à contribuer. En plus, la modification des traductions où l'écriture de fait de droite à gauche dans les fichiers de texte brut n'est pas du tout pratique. L'extension Translate résoud déjà tous ces problèmes.

Les pages de documentation des modèles doivent également être traductibles. Il suffit presque de le faire en utilisant la fonctionnalité de traduction de page de l'extension Translate, mais cela peut nécessiter quelques adaptations.

Langue dans laquelle le texte est présenté à l'utilisateur
Les modèles sont utilisés initialement pour être intégrés à du contenu, donc par défaut les messages traduits doivent être affichés dans la langue du contenu du wiki.

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.

Clés des messages
Les messages doivent être représentés par des clés, de la même manière que cela est fait dans le noyau de MediaWiki, les extensions et les outils.

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.

Pour rendre facilement les clés globalement uniques, il est probablement possible d'inclure automatiquement le nom du modèle global dans la clé du message.

Outils de transition
Un outil est à écrire pour aider au transfert des modèles et des modules vers le dépôt central. Il pourrait réaliser les étapes suivantes :
 * 1) Exportez un modèle d'un wiki local et importez le dans le wiki global.
 * 2) Exportez tous les modèles utilisés par ce modèle (en cascade).
 * 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) Importe la page de documentation du modèle avec les TemplateData.
 * 5) Importe les pages CSS nécessaires.

Dans la plupart des cas, ce processus automatique ne peut probablement pas créer un modèle ou un module robuste et complètement utilisable, mais il peut aider à commencer le processus de transition.

Organiser les 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”.

Parce qu'il existe beaucoup plus de modèles que d'extensions, certaines modifications peuvent être nécessaires pour faciliter la traduction des modèles dû à la manière dont l'extension Translate gère les groupes de messages.

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:
 * Nous aurons des milliers de modèles, et il serait bien que l'architecture de la table corresponde quelque part à cela.
 * 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.

Trouver la manière de traduire un modèle
Chaque page de description de modèle doit avoir un lien direct vers sa traduction dans la langue de l'utilisateur.

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

Paramètres des messages et mots magiques
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.

Quelquechose de similaire est nécessaire également dans les modèles, bien que la forme ne soit pas forcément $1, $2, mais avec des paramètres comme ceux des modèles, c'est à dire avec des accolades triples ( { – } ). Il faudra décider de cela en prenant en compte les besoins de l'analyse syntaxique et ceux de la traduction.

Les mots magiques,  , et   doivent être pris en charge dans les messages des modèles ainsi que dans les messages MediaWiki.

Documentation des messages
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.

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

Technique du 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.)

Un mécanisme similaire sera nécessaire pour internationaliser des modèles. Néanmoins puisqu'il serait bon que les sources soient forcés en anglais, il y aura plus de possibilités d'avoir des messages marqués fuzzy.

Considérations pour internationaliser les 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.

Certains modules techniques très internes, utilisés en commun, rarement modifiés et qui n'ont pas besoin d'être traduits, peuvent probablement être déplacés sans douleur vers l'extension Scribunto elle même. Comme exemples, nous avons No globals et Arguments.

Internationaliser le nom du modèle
Le modèle peut avoir un nom différent dans chaque langue, mais il doit être directement connecté au dépôt central.

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.

Comme pour les noms des paramètres, les modèles peuvent avoir des noms différents dans les différentes langues, et ceci doit être respecté. Il faut une méthode structurée pour traduire le nom des modèles. Peut-être les liens de site Wikidata peuvent apporter une solution, mais pas nécessairement.

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.

Internationalisation le nom des paramètres
Le nom des paramètres est différent dans chaque langue. il est généralement basé sur plusieurs mots dans chaque langue, donc il est important pour une modification facile de la transclusion dans la syntaxe wiki.

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.

Ces noms génériques de paramètre seront les noms communs par défaut. Ils fonctionneront sur les wikis dans toutes les langues. Les noms traduits seront utilisés sur les wikis si la langue du contenu leur correspond.

Ces traductions de noms de paramètres doivent être validées :


 * ils ne doivent pas contenir de caractères non valides
 * ils ne doivent pas être répétés dans un même modèle d'une même langue
 * Autre chose ?

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.

Traduction automatique des paramètres
Si tous les modèles et les paramètres traduits sont stockés de manière centrale, il sera possible d'avoir un service simple réalisant un appel de modèle valide avec ses paramètres, un nom de langue source, et un autre pour la cible, et renvoyant l'appel au modèle traduit. Par exemple :

Entrée :

Sortie :

Dans la traduction de contenu, ce sera la première façon d'adapter les modèles. Contrairement à ce qui est fait actuellement dans la traduction de contenu pour l'adaptation des modèles, ceci est plus précis et plus complet plutôt que de se baser sur des suppositions.

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.

Dans les deux cas, seuls les noms des modèles et les paramètres seront traduits. La traduction des valeurs du paramètre est discutée à part.

Paramètres anonymes
Les paramètres sans nom et portant un numéro doivent bien sûr rester utilisables.

Il faudra statuer sur la manière dont leur nom sera traduit.

Traduire la valeur des paramètres
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.

Certaines valeurs de paramètre doivent être traduites ou translitérées, par exemple le nom des personnes, les devises des pays, etc.

Les modèles généraux doivent pouvoir rendre cela possible, mais en pratique, ces éléments sont encore souvent recopiés de wiki à wiki, et ceci doit être également pris en compte.

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.

Direction du texte
Les modèles doivent s'adapter automatiquement au sens de lecture (ltr de gauche à droite, ou rtl de droite à gauche) du wiki dans lequel ils sont affichés.

Il serait pratique de pouvoir écrire un modèle d'une manière indépendante du sens de lecture, avec le moins d'indications explicites possibles sur l'alignement à droite ou à gauche.

Robots
Beaucoup de modèles sur plusieurs wikis sont modifiés régulièrement par les robots. Cette possibilité doit être préservée.

Cela suppose de ne pas modifier la structure du logiciel, et on évoque le sujet ici pour compléter car c'est un cas d'utilisation important.

Migrer les modèles à partir des grands wikis vers un dépôt central
 וּמֵעֵבֶר לְשׁוּרַת הַבְּרוֹשִׁים עָבְרָה הָרַכֶּבֶת אֲבָל אֲנַחְנוּ רַק שָׁמַעְנוּ אוֹתָהּ, וְלֹא רָאִינוּ. וְכָל הַדְּבָרִים שֶׁדִּבָּרְנוּ בֵּינֵינוּ הִתְחִילוּ בַּמִּלִּים, „אֲבָל אֲנַחְנוּ”. — יהודה עמיחי 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.
 * Réécrire les modèles de sorte que les chaînes soient traductibles peut s'avérer couteux en temps et peut les obliger à apprendre de nouvelles connaissances sur la maintenance des modèles.
 * 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.
 * Les contributeurs de différents wikis majeurs devront travailler pour aboutir à un consensus sur la manière de fusionner les modèles qui ont des fonctionnalités similaires et qui sont déja sur leurs 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.

Les modèles doivent être complètement utilisables, à la fois dans leur syntaxe wiki ainsi que dans l'éditeur visuel
C'est évident mais il faut le dire quand même : la modification de la syntaxe Wiki ne va pas disparaître de si tôt et il doit être possible de conserver la transclusion des modèles d'édition dans les pages en l'état. Cela ne doit pas devenir plus difficile.

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.

Autres fonctionnalités relatives aux modèles
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.

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

La page « » doit rester fonctionnelle, et reste utile pour les transclusions globales.

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.

Modèles de style

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

Bac à sable des modèles

 * Special:TemplateSandbox doit continuer à fonctionner.
 * Il doit être possible de modifier un modèle sur le dépôt central et de l'afficher sur une page d'un wiki cible.

Assistant de modèle

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

Editeur Visuel

 * Il va sans dire que l'Editeur Visuel doit pouvoir insérer à la fois les modèles locaux et les modèles globaux.
 * 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.

Développement et déploiement
 Quam multa fieri non posse prius quam sunt facta iudicantur — C. Plinius Secundus 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) Translatable modules: 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) Modèles traductibles : ceci est semblable aux modules traductibles ci-dessus, et peut réutiliser beaucoup d'éléments de la même architecture, mais cela nécessitera aussi de disposer de la capacité à traduire les noms de modèle leux-mêmes ainsi que les paramètres et quelques autres fonctions. Voir les sections sur l'internationalisation dans les spécifications.
 * 4) Modèles globaux: compléter le projet en rendant les modèles globaux.

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.

Imaginer un monde
Imaginez un monde où tout être humain pourrait partager librement l'ensemble des connaissances, c'est une chose très facile à réaliser actuellement car les modèles sont globaux :

État
 А мы всё молчим, Мы всё считаем и ждём; Мы всё поём о себе, О чём же нам петь ещё? — Борис Гребенщиков

Comme indiqué ci-dessus, depuis octobre 2019, cette page n'est simplement qu'une idée, et non pas une spécification pour implémenter un 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.

La page Evolution de la plateforme/Objectifs qui est directement liée, liste ceci parmi ses objectifs :


 * Augmenter l'équité et le pouvoir des outils de contribution. Nous voulons soutenir la contribution de plus de types de contenu, y compris les médias, de manière plus interactive et dans tous les projets. Cela signifie rendre certains outils existants - comme les modèles - disponibles pour une réutilisation cohérente dans tous les projets et toutes les langues. Cela signifie aussi améliorer les outils de traduction pour supprimer les silos de contenu. Enfin, nous voulons également permettre aux contributeurs de créer facilement de nouveaux outils de contenu communs aux projets et qui soint internationalisables.

A part ces objectifs, il n'existe pas en outre, de plan détaillé sur la manière dont une telle fonctionnalité va opérer. Cette page est là dans le but de proposer un tel plan et attend en retour les avis des contributeurs.

Liens utiles
Quelques pages relatives discutant de sujets similaires :

Marqué « En développement - Equipe d'analyse », mais pas réalisé actuellement.
 * Evolution de la plateforme/Objectifs
 * Evolution de la plateforme/Recommendations
 * Modèles et modules multilingues - une tentative pour implémenter une fonctionnalité similaire en utilisant des robots
 * Résultats du sondage 2015 sur les souhaits de la communauté - Dépôt global et central pour les modèles, les modules Lua et les gadgets est arrivé en position 3 dans le vote des souhaits de la communauté.
 * Quels modèles doivent être globaux ? - une liste informelle faite par différents éditeurs (sur meta)
 * RFC sur les espaces de noms fantômes - une RFC dormante concernant une proposition pour l'implémentation technique d'une telle infrastructure
 * - un mécanisme rudimentaire existant pour transclure du contenu au travers des projets. Ceci considéré comme non efficace et dangereux, est désactivé dans les projets Wikimedia.
 * Global-Wiki (meta) - est une proposition similaire, avec un champs d'action plus large. Elle a été ouverte pour discuter durant plusieurs années, puis fermée en temps que consensus. Certains éléments qu'elle contient furent implémentés, tels que les pages utilisateur globales et les préférences, mais cela concerne aussi les modèles globaux, qui ne sont pas encore implémentés.
 * Wikilambda (sur méta) - Une proposition plus large, qui inclut un module global et un dépôt de modèles.