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.
 * (Need to decide whether to store all the languages in one JSON structure, or a slot per language.)
 * The JSON file is stored as an MCR slot with the wiki page that stores the module’s code.
 * The same syntax can be used as for core and extension messages.
 * Enhance the Translate extension to load the source messages and write the translations to JSON files by language.
 * Add Lua functions to the standard Scribunto library to load the messages.
 * Use another JSON file to organize the translatable file for convenient display in Translate’s message group selector.

Advantages

 * Stored elegantly with the module.
 * If the module becomes global, the data becomes global with it.
 * Creating MCR slots may require some privileges, but that’s probably OK because creating new messages files is not for total newbies anyway, while editing is still accessible to most editors.

Disadvantages

 * Will require some development to create slot support.
 * A new FFS will have to be developed and maintained in Translate. We will need a new type of MessageGroup, as well as MessageLoading.
 * In the global modules and templates age, it’s unclear how it will be locally customized on wikis.
 * Common disadvantage of MCR slot approach: Permissions and history mixed altogether. Code programming has the same protection level as translations, every translator is permitted to modify the effective code. There is no history of the effective changes in global programming, but drowning among translation edits. If protection and history would be separated, these are individual pages but not MCR.

Description
Similar to the JSON proposals above, but with the JSON stored inside TemplateData:


 * Store all the source messages as a JSON value in TemplateData associated with a template that uses the module. Other than being part of a larger JSON structure, the format is otherwise the same as “banana” format, like in MediaWiki extensions, including qqq for documentation.
 * The same syntax can be used as for core and extension messages.
 * Enhance the Translate extension to load the source messages and write the translations to JSON files by language.
 * Add Lua functions to the standard Scribunto library to load TemplateData and the messages.
 * Use another JSON file to organize the translatable file for convenient display in Translate’s message group selector.

Advantages

 * Continuity with existing TemplateData technology.
 * In particular, TemplateData already has some support for internationalization, e.g. template description can be in several languages.
 * Keys can be managed through the TemplateData editor (this will require updates to the editor UI, however).
 * The technology can be later shared with templates.
 * If TemplateData ever moves to MCR, it will move there, too.

Disadvantages

 * 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.
 * Requires adding TemplateData support to Scribunto.
 * A new file format support (FFS) will have to be developed and maintained in Translate.
 * In the global modules and templates age, it’s unclear how it will be locally customized on wikis.

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.