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
Dès qu'un module est capable d'être copié sans modification sur d'autres wikis, l'outil peut être utilisé pour le copier et le maintenir synchronisé sur tous les wikis Wikimedia.



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
De nombreux modules doivent produire des chaînes lisibles par l'utilisateur, telles que les messages d'erreur et les éléments d'interface (comme les boutons). Le codage en dur du texte de ces chaînes oblige les autres wikis à modifier le code afin de les localiser, empêchant la globalisation. To avoid this, developers should provide ways to localize user-readable strings without having to modify the code itself. Cette section explique plusieurs manières de faire cela.



Paramètres des modèles
User-readable strings can be localized through template parameters when calling the module. Cette approche est pratique quand :


 * Le texte est susceptible de varier à chaque appel du modèle
 * Le texte est susceptible d'être modifié par les utilisateurs lors de l'appel du modèle
 * Le texte est susceptible de contenir un mot magique, un appel de modèle, une fonction d'analyse syntaxique ou un autre élément wiki

Exemple de module utilisant cette approche :

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. Ceci n'est pas nécessaire. Modules may require template callers to set the  parameter by throwing an error if they don't. Cependant, il est souvent plus sympathique d'avoir une solution de repli.



Fichier de configuration
Une autre façon de localiser les chaînes lisibles par l'utilisateur est de le faire via une sous-page séparée de /config. Cette approche est pratique lorsque :


 * Le module est destiné à être appelé par de nombreux modèles par wiki, permettant ainsi la localisation de se faire une seule fois et d'être ensuite réutilisée
 * Il y a beaucoup de messages à localiser, donc il est plus facile de les avoir tous ensemble à un même endroit
 * Nous avons déjà besoin d'un fichier  pour d'autres raisons, alors nous pourrions aussi bien l'utiliser aussi pour la localisation

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
En fonction des cas, toutes les méthodes ci-dessus peuvent être combinées. 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
Les paramètres du modèle sont généralement stockés sous forme de bloc JSON de templatedata dans la sous-page de  du modèle. Cela rend la traduction pratique, mais lorsqu'un nouveau paramètre est ajouté à un modèle global, toutes les pages  doivent être mises à jour dans chaque langue. Module:TNT aide à faire cela en générant automatiquement le bloc des templatedata à partir d'une table stockée sur Commons. En plaçant la ligne suivante dans chaque sous-page de  on utilise la table Data:Templatedata/Graph:Lines.tab pour générer toutes les informations Templatedata nécessaires pour chaque langue. 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

 * Proposition de la liste des souhaits 2019 (40 votes)
 * T122086 - RFC à propos du partage des modèles et des modules entre les wikis - manuel simple (idée originale pour ce robot)
 * 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