Multilingual Templates and Modules/fr



Cette page explique comment créer des modules et des modèles globaux, interwiki et multilingues''' et comment les garder synchronisés sur les wikis Wikimedia.

Pourquoi est-ce nécessaire ? Parce que nous n'avons pas qu'une seule Wikipedia, nous en avons plus de 300 différentes ainsi que d'autres projets de wiki, et chaque fois que quelqu'un crée un nouveau modèle ou un module Lua valable, il est copié et traduit plus de 300 fois. Every translator has to thoroughly understand MediaWiki markup, making copying a very tedious and error-prone process, partially because template authors often assume their templates will be used in just one language. Once copied, the original templates are often improved, and each copy has to be updated while maintaining all existing translations. The pure human expense of copying templates and modules is so high that most of them are either never copied or never updated, especially for the smaller wikis.

Est-ce que c'est la meilleure approche ? Non, mais c'est la meilleure approche avec la technologie actuelle. Une réécriture importante de MediaWiki est nécessaire pour que cela soit possible au niveau du système. Multi-site templates has been requested from the start in 2001, but not much was done simply because this is a hard problem to solve. With this approach it is possible to create multilingual content now, and once MediaWiki supports it, we can easily migrate multilingual content to the new system without much work.



Méthode générale

 * Un module global est un module Lua conçu pour être utilisé avec exactement le même code sur chaque wiki.
 * To become global, a module must provide ways for wikis to localize everything they need to localize, without having to touch the code of the module itself. Cette page décrit plusieurs techniques pour réaliser cela.
 * Une fois le module devenu global, l'outil peut être utilisé pour le garder à jour sur tous les wikis Wikimedia.
 * Pour obtenir un modèle global, il faut le transformer en module global.



Pratiques recommandées
Cette section décrit certaines des meilleures pratiques pour développer des modules globaux.

Nommage
Cette section peut être ignorée si les modules sont conçus pour être appelés uniquement à partir des modèles.

Global modules that are meant to be used by other modules should be named the same in all wikis to avoid dependency breaks with other global modules. For example, if a module named A requires a module named B, but in some wiki, module B is named C, then module A will not work in that wiki, unless the source code of module A is changed locally to require C instead of B, which would defeat globalization (of module A).

If a local community does not accept the global name, or renaming is too much trouble, then a workaround is to create a "redirect module" with the global name, that simply requires and returns the module with the local name.

Fortunately, the fact that the Module namespace is named differently in each language doesn't break dependencies, because "Module" is an alias for the Module namespace in all languages.



Module maître
Les modules globaux doivent choisir un wiki où les développements seront faits. Generally this will be the home wiki of the module, but it may migrate for various reasons, for example to increase the chances of recruiting new developers by centralizing the development in a larger or more appropriate wiki.

Global modules should start with a comment that includes a link to the master module, to reduce the chances of forking and help recruit new developers (example).

Bac à sable
Global modules should have a /sandbox subpage where to test out changes before deploying them to the master module and the other wikis (example).

Cas d'utilisation
Global modules should have a /testcases subpage with good unit tests to ensure high quality and stability of the module (example). Test cases should:


 * Use Module:ScribuntoUnit
 * Run with both the main module and the sandbox versions, so that we can compare the results (example)
 * Use to avoid accidentally using non-declared variables
 * Output results both in /testcases/doc and the main /doc page of the module, to catch errors as early as possible

Documentation
Global modules should have a /doc subpage with documentation of all public functions of the module (example) and a section with the testcase runs for both the primary and the sandbox versions of the module (example).

Configuration
Global modules that require configuration should have a separate /config submodule to prevent local wikis from modifying the source code to configure the module (example).

Synchronisation
Once a module is able to be copied unchanged to other wikis, the tool can be used to copy it and keep it synced across all Wikimedia wikis.



Compatibilité arrière
Global modules should generally keep development backwards-compatible, because changes that are not backwards-compatible will often require manual updates to each and every wiki, template and module that uses the module.



Internationalisation des paramètres des modèles
Global modules can have their parameters localized by the template callers. For example, consider the following module that simply outputs the given text (or "Example" if none is given):

Puis un modèle espagnol localiserait le module ainsi :

Notice that the template not only localizes the name of the "text" parameter ("texto" means "text" in Spanish), but also the default text ("Ejemplo" means "Example" in Spanish).

See Plantilla:Extracto for a real case of a template that localizes a global module with this technique. Also, see Template:Excerpt for a case where a global module is localized to the English Wikipedia, demonstrating that localization is not always the same as translation.



Traduction des chaînes lisibles par l'utilisateur
Many modules need to output user-readable strings, such as error messages and interface elements (like buttons). Hard-coding the text of these strings forces other wikis to modify the code in order to localize them, preventing globalization. To avoid this, developers should provide ways to localize user-readable strings without having to modify the code itself. This section explains several ways to accomplish this.



Paramètres des modèles
User-readable strings can be localized through template parameters when calling the module. This approach is convenient when:


 * The text is likely to vary with each template call
 * The text is likely to be changed by users when calling the template
 * The text is likely to contain a magic word, a template call, a parser function or some other wiki element

An example of a module using this approach would be:

De cette manière, chaque modèle peut modifier le texte lors de l'appel du module, ainsi :

Notice that in this example, if a template calls the module without specifying the  parameter, then the hard-coded English text 'Example' would be used. This is not necessary. Modules may require template callers to set the  parameter by throwing an error if they don't. However, it's often friendlier to have a fallback.



Fichier de configuration
Another way to localize user-readable strings is through a separate /config subpage. This approach is convenient when:


 * The module is meant to be called by many templates per wiki, thus allowing localization to be done only once and then reused
 * There're many messages to localize, so it's easier to have them all together in their own place
 * There's already a need for a /config file for other reasons, so we might as well use it for localization too

Exemple de module utilisant cette approche :

Les wikis pourraient alors créer des fichiers /config ainsi :



Tables de traduction
Another way to localize user-readable strings is through a central at Commons. Cette approche est pratique quand :


 * The strings should vary with the preferred language of the user, rather than the language of the wiki or page.
 * Nous voulons centraliser les efforts de traduction sur une page unique.

Module:TNT a été créé spécifiquement pour obtenir les chaînes des tables de traduction. Exemple de module utilisant TNT :

See Data:I18n/Template:Graphs.tab for a simple but real example of a translation table with two messages, each having a single parameter. It's important to store parameters as parts of the strings because in many languages the parameter would have to be placed at a different position in the string according to the norms of the language.

Translation tables should start with the "Data:I18n/..." prefix to separate them from other types of tabular data. If a message has not yet been localized, TNT will fall back to English (or other fallback language as defined by the language's ). TNT also supports all standard localization conventions such as NaN undefineds and.

One downside of this approach is that it requires installing and setting up, which may not have been done on non-Wikimedia wikis, limiting the ability to reuse these modules on third-party wikis.



Messages MediaWiki
In some cases, MediaWiki itself (or some extension) may have the messages we need already localized. For example, if we need the string "New page" we may use MediaWiki:Newpage, like so:

Voir Special:AllMessages pour la liste de tous les messages disponibles.



Tout ci-dessus
Depending on the case, all of the above methods may be combined. For example, MediaWiki messages may be used when available, and when not, a translation table or config file is queried, and if no localization is found there, then a hard-coded English text is used, unless a template parameter overrides it.

Combining several methods can be effective, but the benefits should be weighted against the downsides of the increased complexity, which may cause performance loss and bugs, as well as more difficulty in maintaining the code and recruiting new developers.

Template data
Template parameters are usually stored as a JSON templatedata block inside the template's /doc subpage. This makes it convenient to translate, but when a new parameter is added to a global template, all /doc pages need to be updated in every language. Module:TNT helps with this by automatically generating the templatedata block from a table stored on Commons. Placing the following line into every /doc subpage will use Data:Templatedata/Graph:Lines.tab table to generate all the needed templatedata information in every language. Even if the local community has not translated the full template documentation, they will be able to see all template parameters, centrally updated.



Voir aussi

 * Wishlist proposal 2019 (40 votes)
 * T122086 - RFC: Sharing templates and modules between wikis - poor man's version (original idea for this bot)
 * T121470 - Central Global Repository for Templates, Lua modules, and Gadgets ticket (main ticket for everything cross-site shareable)
 * Global templates/Proposed specification, short version - Proposal to implement a similar idea comprehensively, without the need for the special tools, and with full support in MediaWiki core and extensions