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. Chaque traducteur doit bien comprendre le balisage MediaWiki, ce qui fait de la copie un processus très fastidieux et sujet à erreurs, en partie parce que les auteurs des modèles supposent souvent que leurs modèles ne sont utilisés que dans une seule langue. Une fois copiés, les modèles originaux sont souvent améliorés, et chaque copie doit être mise à jour tout en conservant toutes les traductions existantes. Les frais purement humains pour copier les modèles et les modules sont si élevés que la plupart d'entre eux ne sont jamais copiés ni mis à jour, en particulier pour les petits 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. Des modèles multi-sites ont été demandés dès le début en 2001, mais peu a été fait simplement parce que c'est un problème difficile à résoudre. Avec cette approche, il est possible de créer maintenant du contenu multilingue, et une fois que MediaWiki le supportera, nous pourrons facilement migrer le contenu multi-lingue vers le nouveau système sans beaucoup de travail.



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.
 * Pour devenir global, un module doit fournir les moyens aux wikis de traduire tout ce qu'ils ont besoin de localiser, sans avoir à toucher le code du module lui-même. 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.

Les modules globaux destinés à être utilisés par d'autres modules doivent être nommés de la même manière sur tous les wikis afin d'éviter les ruptures de dépendance avec les autres modules globaux. Par exemple, si un module nommé A nécessite un module nommé B, mais que dans certains wikis le module B est nommé C, alors le module A ne fonctionnera pas dans ce wiki, à moins que le code source du module A ne soit modifié localement pour utiliser C au lieu de B, ce qui serait contraire à la mondialisation du module A.

Si une communauté locale n'accepte pas le nom global, ou si le renommage est trop problématique, alors une solution est de créer un module de redirection portant le nom global, qui renvoie simplement le nom du module local.

Heureusement, le fait que l'espace de noms du module soit nommé différemment dans chaque langue ne casse pas les dépendances, car Module est un alias pour l'espace de noms du module dans toutes les langues.



Module maître
Les modules globaux doivent choisir un wiki où les développements seront faits. Généralement, ce sera le wiki d'accueil du module, mais il peut bouger pour diverses raisons, par exemple si on veut augmenter les chances de recruter de nouveaux développeurs en centralisant le développement dans un wiki plus grand ou plus approprié.

Les modules globaux doivent commencer par un commentaire comportant un lien vers le module maître afin de réduire les chances d'avoir des fork et pour aider au recrutement de nouveaux développeurs (exemple).

Bac à sable
Les modules globaux doivent avoir une sous-page /sandbox où tester les modifications avant de les déployer sur le module maître et sur les autres wikis (exemple).

Cas d'utilisation
Les modules globaux doivent avoir une sous-page /testcases avec des tests unitaires réussis pour vérifier la haute qualité et la stabilité du module (exemple). Les cas d'utilisation doivent :


 * Utiliser Module:ScribuntoUnit
 * S'exécuter à la fois avec le module principal et les versions du bac à sable, afin que nous puissions comparer les résultats (exemple)
 * Utiliser pour éviter d'utiliser accidentellement des variables non déclarées
 * Output results both in  and the main   page of the module, to catch errors as early as possible

Documentation
Les modules globaux doivent avoir une sous-page  avec la documentation de toutes les fonctions publiques du module (exemple) et une section avec les cas de test à la fois pour les versions primaires et le bac à sable du module (exemple).

Configuration
Les modules globaux qui nécessitent une configuration doivent avoir un sous-module séparé  pour empêcher les wikis locaux de modifier le code source pour configurer le module (exemple).

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
Les modules globaux doivent généralement maintenir le développement rétrocompatible, car les changements qui ne sont pas rétrocompatibles nécessitent souvent des mises à jour manuelles dans chaque wiki, modèle ou module utilisant le module.



Internationalisation des paramètres des modèles
Les modules globaux peuvent avoir leurs paramètres localisés par les appelants du modèle. Par exemple, considérez le module suivant qui génère simplement le texte donné (ou « Example » si aucun n'est donné) :

Puis un modèle espagnol localiserait le module ainsi :

Notez que le modèle ne localise pas seulement le nom du paramètre « texte » (texto en espagnol) mais aussi le texte par défaut « Exemple » (Ejemplo en espagnol).

Voir Plantilla:Extracto pour un cas réel de modèle qui localise un module global avec cette technique. Voir aussi Template:Excerpt pour un cas où un module global est localisé pour la Wikipédia anglophone, démontrant que l'internationalisation n'est pas toujours la même chose qu'une traduction.



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
Une autre façon de traduire les chaînes lisibles par l'utilisateur est de passer par une centrale sur Commons. Cette approche est pratique quand :


 * Les chaînes doivent changer en fonction de la langue préférée de l'utilisateur, plutôt que de la langue du wiki ou celle de la 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
Dans certains cas, MediaWiki lui-même (ou une extension) peut avoir les messages dont nous avons besoin, déjà traduits. Par exemple, si nous avons besoin de la chaîne « Nouvelle page » nous pouvons utiliser MediaWiki:Newpage, comme ceci :

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



Le tout ensemble
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  subpage. This makes it convenient to translate, but when a new parameter is added to a global template, all  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  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