Modules traduisibles/Solutions proposées
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.
Page traductible
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
messagecollectionmais peut-être pas d'API ergonomique en Lua ou en Wikicode pour charger les traductions.
JSON .tab file in the Data namespace on Commons
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.
Fichier JSON dans un emplacement MCR
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.
TemplateData
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 (tâche T56140), 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 (tâche T107119).
- 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.
Messages en tant que pages dans l'espace MediaWiki
Description
- Stocke les messages traduisibles dans l'espace de noms MediaWiki, comme les messages de base et d'extension.
- Créer des groupes de messages pour Translate en utilisant un fichier JSON ou YAML stocké comme une page wiki. Cette fonction est déjà prise en charge (WikiMessageGroup) sous forme de listes séparées par des espaces, mais il n'existe aucun mécanisme permettant de définir des groupes dans le wiki lui-même.
Avantages
- Le traitement par Translate est en grande partie naturel (mais le support de l'organisateur de groupes de messages devra probablement être développé).
- Il est tout à fait naturel pour Scribunto de traiter des fonctions d'analyse syntaxique de chargement de messages qui existent déjà.
- Peut être personnalisé sur les wikis locaux lorsque les modules deviennent globaux de la même manière que les messages du noyau et des extensions sont personnalisés.
Inconvénients
- Double fonction : lister les messages et les créer séparément.
- La création des messages nécessitera des autorisations des administrateurs ou de modification de l'interface, ce qui rendra le développement complet du module et la correction des bogues accessibles à beaucoup moins de personnes.
- Manque d'emballage. De nombreuses équipes de développement distribuées créeront et maintiendront des paquets de module, de modèle global, accompagné de TemplateData, ou de gadget JavaScript, mais il ne devrait pas y avoir de conflit dans la dénomination entre les paquets de cibles similaires. Devraient être regroupés par paquet.
Lua table
Description
Do it similarly to existing solutions in Module:I18n on Commons and Module:Wikidades/i18n on the Catalan Wikipedia, but:
- Standardiser le format de la table Lua : Décidez s'il s'agit d'une clef de message pointant vers plusieurs traductions indexées par langue, ou de codes de langue pointant vers plusieurs clefs de message, etc.
- Ajouter des fonctions Lua à la bibliothèque standard de Scribunto pour charger les messages.
- Ajouter le support pour la lecture et l'écriture de ce format de fichier dans Translate.
Avantages
- Naturel pour Lua.
- Continuité avec au moins certaines des solutions existantes.
Inconvénients
- Il s'agit du code réel, qui est sujet aux erreurs et moins sûr. (Nous avions déjà l'habitude d'avoir des messages dans des tableaux PHP, et nous nous en sommes éloignés).
- C'est naturel pour Lua, mais que se passera-t-il si Scribunto acquiert le support d'autres langages de programmation ? Il y a des demandes récurrentes pour supporter JavaScript, Python, Rexx, etc.
- Les codes linguistiques qui comportent des traits d'union doivent être écrits avec des crochets, ce qui n'est pas évident et est source d'erreurs.
Tableau comparatif des solutions proposées
| Fonctionnalité | Pages traductible | Fichier JSON .tab dans l'espace de noms Data sur Commons | == Fichier JSON dans un créneau MCR == | TemplateData | Messages dans l'espace MediaWiki | Tableau en Lua |
|---|---|---|---|---|---|---|
| Changements de traduction (voir les détails dans « Considérations techniques ») | Mineurs | Majeurs | Majeurs | Majeurs | Mineurs | Majeurs |
| Doit obtenir la permission de modifier les messages sources | À marquer pour la traduction | Non | Pour créer des créneaux | Non | Oui - Administrateur de l'interface d'édition | Non |
| Traduction de FFS | Aucune | Majeure | Majeure | Majeure | Aucune | Majeure |
| Personnalisation du wiki | Incertaine | Incertaine | Incertaine | Incertaine | Probablement facile, mais peut connaître des problèmes de performance | Incertaine |
| Similarité au noyau et aux extensions | Non | Très proche | Très proche | En grande partie similaire | Oui, mais seulement pour les éditeurs en mode wiki. | Non |
| Clefs de messages lisibles | Fragile, doit être réparé dans Translate | Oui | Oui | Oui | Oui | Oui |
| Imports et exports | Peu aisé | Peu aisé | Facile | Facile | Peu aisé | Probablement facile |
| Peut également être utilisé dans des modèles sur le même wiki. | Directement | En passant par un module | En passant par un module | En passant par un module | Directement | En passant par un module |
| Traitement du flou | Probablement déjà fait | Nécessite un travail non trivial | Nécessite un travail non trivial | Nécessite un travail non trivial | Probablement déjà fait | Nécessite un travail non trivial |