Translatable modules/Proposed solutions/fr

 Le projet Modules traduisibles essaie de construire un nouveau cadre pour la localisation des modules.

Plusieurs solutions de stockage sont proposées ici pour discussion.

L'un des principaux objectifs de cette consultation est de décider laquelle de ces solutions mettre en œuvre et recommander à tous les développeurs de modules.

Description
Utilisez quelque chose de similaire à Module:ModuleMsg sur Meta, mais normalisé :


 * Mettre tous les messages sur une page classique en wikicode marquée comme « à traduire ».
 * Avoir des fonctions Lua standard pour les charger (plutôt qu'un module comme Module:ModuleMsg sur chaque wiki).

Avantages

 * Le marquage des pages à traduire est familier aux administrateurs de traduction.
 * Cela put également fonctionner pour les modèles.
 * Chaque traduction est une page wiki, ce qui est meilleur pour le crédit d'auteur, l'historique, le traitement séparé, etc.

Inconvénients

 * Par défaut, les marqueurs d'unité de traduction sont des nombres. L'utilisation de nombres comme touches de message rend le code illisible. Il est possible de remplacer les chiffres par des chaînes de caractères, mais, comme indiqué ci-dessus, la façon de le faire dans l'extension Translate n'est pas bien documentée actuellement. Ce problème peut probablement être résolu par une documentation et une normalisation appropriées de cette fonction d'extension Translate.
 * Le fonctionnement des paramètres ($1, etc.) et des autres caractéristiques de la syntaxe wiki dans les caractéristiques (GENDER, PLURAL, etc.) n'est pas clair. Ils ne sont pas nécessairement compatibles avec les pages de contenu en wikicode.
 * Cela peut fonctionner pour la localisation de modules au sein d'un wiki, mais ne fonctionnera pas nécessairement lorsque les modules deviendront globaux.
 * Une solution sera nécessaire pour rechercher les pages à traduire. Actuellement, le sélecteur de groupe de messages affiche seulement toutes les pages traductibles.
 * À l'ère des modules et des modèles globaux, la manière dont ils seront personnalisés localement sur les wikis n’apparaît pas clairement.
 * Des problèmes de performances sont possibles si chaque traduction de message est chargée individuellement, et dans la gestion des solutions de secours. Il y a l'API d'action  mais peut-être pas d'API ergonomique en Lua ou en Wikicode pour charger les traductions.

Description
Use something similar to what Module:TNT is doing, but formalized:


 * Stocker tous les messages sources dans un fichier JSON dans l'espace de noms Data sur Commons au format « banane », comme dans les extensions MediaWiki, y compris qqq pour la documentation.
 * La même syntaxe peut être utilisée pour les messages de base et d'extension.
 * Améliorer l'extension Translate pour charger les messages sources et écrire les traductions dans des fichiers JSON par langue.
 * Ajouter des fonctions Lua à la bibliothèque standard de Scribunto pour charger les messages.
 * Utiliser un autre fichier JSON pour organiser le fichier traduisible pour un affichage optimal dans le sélecteur de groupe de messages de Translate.

Avantages

 * Le format du fichier est le même que celui des extensions.
 * Ces pages sont déjà globalement accessibles depuis les modules.
 * Les pages brutes sont facilement disponibles pour les gadgets JavaScript, qui convertiront JSON en objet natif, contenant toutes les traductions si cela est souhaité. Une API pourrait être nécessaire pour récupérer une seule langue ou une solution de secours, améliorant ainsi l'accès au réseau. Les gadgets JavaScript préfèrent que soit présentée une seule requête, stockée dans le cache du client, pour tous les messages.

Inconvénients

 * Un nouveau format de fichier de support (FFS) devra être développé et maintenu dans l'extension Translate. Nous aurons besoin d'un nouveau type de MessageGroup, ainsi que de MessageLoading.
 * À l'ère des modules et des modèles globaux, la manière dont ils seront personnalisés localement sur les wikis n’apparaît pas clairement.

Description
Similaire à « fichier JSON .tab dans l'espace de noms Data », mais :


 * Stocker tous les messages sources dans un fichier JSON dans l'espace de noms Data sur Commons au format « banane », comme dans les extensions MediaWiki, y compris qqq pour la documentation.
 * (Il faut décider s'il faut stocker toutes les langues dans une seule structure JSON, ou un emplacement par langue).
 * Le fichier JSON est stocké comme un emplacement MCR avec la page wiki qui stocke le code du module.
 * La même syntaxe peut être utilisée pour les messages de base et d'extension.
 * Améliorer l'extension Translate pour charger les messages sources et écrire les traductions dans des fichiers JSON par langue.
 * Ajouter des fonctions Lua à la bibliothèque standard de Scribunto pour charger les messages.
 * Utiliser un autre fichier JSON pour organiser le fichier traduisible pour un affichage optimal dans le sélecteur de groupe de messages de Translate.

Avantages

 * Rangement élégant avec le module.
 * Si le module devient global, les données suivent.
 * La création de créneaux MCR peut nécessiter quelques restrictions d'accès, mais cela ne pose probablement pas de problème, car la création de nouveaux fichiers de messages n'est de toute façon pas destinée aux débutants, tandis que l'édition reste accessible à la plupart des rédacteurs.

Inconvénients

 * Il faudra un certain développement pour créer un support pour les créneaux.
 * Un nouveau FFS devra être développé et maintenu dans Translate. Nous aurons besoin d'un nouveau type de MessageGroup, ainsi que de MessageLoading.
 * À l'ère des modules et des modèles globaux, la manière dont ils seront personnalisés localement sur les wikis n’apparaît pas clairement.
 * Inconvénient commun de l'approche des créneaux MCR : les permissions et l'historique seront mélangés. La programmation du code a le même niveau de protection que les traductions, chaque traducteur est autorisé à modifier le code effectif. Il n'y a pas d'historique des changements effectifs dans la programmation globale, mais ce dernier est noyé parmi les révisions de traduction. Si la protection et l'histoire sont séparées, il s'agit de pages individuelles mais pas de MCR.

Description
Similaire aux propositions JSON ci-dessus, mais avec le JSON stocké dans TemplateData :


 * Stocker tous les messages sources sous forme de valeur JSON dans TemplateData associée à un modèle qui utilise le module. Outre le fait qu'il fait partie d'une structure JSON plus large, le format est par ailleurs le même que le format « banane », comme dans les extensions MediaWiki, y compris qqq pour la documentation.
 * La même syntaxe peut être utilisée pour les messages de base et d'extension.
 * Améliorer l'extension Translate pour charger les messages sources et écrire les traductions dans des fichiers JSON par langue.
 * Ajouter des fonctions Lua à la bibliothèque standard de Scribunto pour charger les messages.
 * Utiliser un autre fichier JSON pour organiser le fichier traduisible pour un affichage optimal dans le sélecteur de groupe de messages de Translate.

Avantages

 * Continuité avec la technologie existante de TemplateData
 * En particulier, TemplateData prend déjà en charge l'internationalisation ; par exemple, la description du modèle peut être en plusieurs langues.
 * Les clefs peuvent être gérées par l'éditeur de TemplateData (cela nécessitera toutefois des mises à jour de l'interface utilisateur de l'éditeur).
 * Cette technologie peut être partagée ultérieurement avec des modèles.
 * Si TemplateData passe un jour à MCR, il y passera aussi.

Inconvénients

 * There is a hard-coded limit of 64 KiB (gzipped) in the TemplateData extension’s code. While this is enough room for something like 700 messages, we have about 400 languages to manage. When using the rate at which MediaWiki core messages are localized, there is room for only 20 messages.
 * Il faut ajouter la prise en charge de TemplateData à Scribunto.
 * Un nouveau support de format de fichier (FFS) devra être développé et maintenu dans Translate.
 * À l'ère des modules et des modèles globaux, la manière dont ils seront personnalisés localement sur les wikis n’apparaît pas clairement.

Description

 * Store the translatable messages in the MediaWiki namespace, like core and extension messages.
 * Create message groups for Translate using a JSON or YAML file stored as a wiki page. This is already supported (WikiMessageGroup) as whitespace separated lists, however, there is no mechanism exposed to define groups inside the wiki itself.

Advantages

 * Mostly natural for Translate to process (but support for the message group organizer will probably have to be developed).
 * Mostly natural for Scribunto to process—message loading parsing functions already exist.
 * Can be customized on local wikis when modules become global the same way that messages from core and extensions are customized.

Disadvantages

 * Double duty of listing messages as well as creating them separately.
 * Creating the messages will require sysop or edit-interface permissions, making comprehensive module development and bug fixing accessible to much fewer people.
 * Lack of packaging. Many distributed development teams will create and maintain packages of module, global template, accompanied by TemplateData, or JavaScript gadget, but should not conflict in naming between packages of similar targets. Should be bundled per package.

Description
Do it similarly to existing solutions in Module:I18n on Commons and Module:Wikidades/i18n on the Catalan Wikipedia, but:


 * Standardize the Lua table format: Decide whether it is one message key pointing to many translations indexed by language, or language codes pointing to many message keys, etc.
 * Add functions to the Scribunto standard library to load these messages.
 * Add support for reading and writing this file format to Translate.

Advantages

 * Natural for Lua.
 * Continuity with at least some existing solutions.

Disadvantages

 * This is actual code, which is error-prone and less safe. (We already used to have messages in PHP arrays, and moved away from it.)
 * It’s natural for Lua, but what if Scribunto acquires support for other programming languages? There are recurring requests to support JavaScript, Python, Rexx, etc.
 * Language codes that have hyphens have to be written with square brackets, which is non-obvious and error-prone.

= Proposed solutions comparison table =

More information

 * Discuss at Talk:Translatable modules.