Modèles globaux/Proposition de spécification
Ceci est une proposition des besoins fonctionnels pour les modules et les modèles globaux.
Vous pouvez aussi lire la version de cette proposition sur une page.
Ceci n'est pas un projet en cours ou prévu par qui que ce soit ni quand que ce soit, pas pour le moment tout du moins. Il s'agit juste d'une idée, bien que ce soit une idée très détaillée.
L'objectif final est de créer un engagement multi-équipes et multi-projets sur la mise en œuvre de ces éléments, avec une architecture appropriée, une gestion de produits et de projets, un engagement de la communauté, etc.
Ce document n'essaie pas d'entrer dans les détails de la mise en œuvre technique en termes de stockage, de mise en cache, de livraison, de code PHP, etc. Il tente uniquement de définir les spécifications de cette fonctionnalité du point de vue des utilisateurs :
- personnes qui créent et maintiennent les modèles et les modules.
- personnes qui créent et modifient des pages qui incluent des modèles et des modules. Cela comprend tous les éditeurs et toutes sortes de pages :
- tous les niveaux d'expérience : depuis ceux complètement nouveaux à ceux qui ont effectué des milliers de modifications
- toutes sortes d'outils d'édition : édition en syntaxe de wiki, Éditeur visuel, traduction de contenu, et autres (même les opérateurs robot)
- tous les wikis : Wikipédia, Wiktionaire, Wikivoyage, Wikidata, Incubator, etc. et tous les futurs projets
- toutes les langues : anglais, français, russe, espagnol, arménien, persan, zoulou, manipuri, etc.
- toutes sortes de pages : articles Wikipédia, page de discussion des articles, page de discussion des utilisateurs, pages de discussions communautaires, pages projets, catégories, pages de documentation des modèles, etc. {{🌎🌍🌏}}
Résumé
Une grande partie des fonctionnalités des sites de Wikimedia sont mises en oeuvre à l'aide de modèles et de modules LUA. Sous leur forme actuelle, ceux-ci ne peuvent être partagés entre différents wikis et différentes langues. De ce fait, il est difficile de les intégrer dans les outils modernes de création d'articles et de contribution aux articles tels que l'Éditeur Visuel, Wikidata et la Traduction de contenu. Ils sont également difficiles à adapter aux périphériques mobiles. Cela entraîne une perte des efforts des contributeurs et des difficultés pour les nouveaux contributeurs et les petits projets. Il devrait être possible de les partager entre les sites wikis, comme on le fait pour les images de Commons. Ceci rendra le développement logiciel plus rapide et plus robuste et permettra aux contributeurs de se concentrer sur l'écriture. {{🌎🌍🌏}}
Le problème
Remarque générale : sauf indication contraire, le terme « modèle » s'applique aussi aux modules Lua Scribunto
Les modèles réalisent les fonctionnalités sur les sites de Wikimedia. Certaines sont très importantes comme les infobox, les références, "Référence nécessaire" et beaucoup d'autres. Pour une liste plus complète des fonctions implémentées par les modèles, voir Taxonomie. Tous les lecteurs les voient et tous les auteurs les utilisent pour pratiquement toutes les actions de modification. De plus, ils implémentent la plupart des fonctionnalités de gestion interne des communautés des sites : demandes de page à supprimer, demande de déblocage, demande de support sur les pages de discussion, classement des articles dans les WikiProjets, etc.
Les modèles sont un mécanismes efficaces pour la conception, le déploiement et l'utilisation répétitive du texte ainsi que pour le balisage dans de nombreuses pages. Cependant, les modèles posent des problèmes dans tous les éditeurs.
Difficultés dans tous les éditeurs dans toutes les langues
Éditeurs de syntaxe Wiki
Pour les contributeurs, les modèles sont souvent difficiles à comprendre dans la syntaxe wiki. Les personnes habituées à utiliser un modèle particulier vont probablement le reconnaître et pourront modifier une page qui l'utilise. Néanmoins, les contributeurs qui sont face à un modèle qui ne leur est pas familier, devront lire sa documentation, même s'ils ont une expérience générale sur la manière de modifier ainsi que celle d'autres modèles. Et les contributeurs qui n'ont qu'une expérience élémentaire seront rebutés à la vue d'un texte crypté avec des accolades, des barres verticales, de signes égal, etc.
Utiliser une fonctionnalité implémentée dans un modèle implique que vous connaissez le nom du modèle et que vous l'appeliez avec des accollades ({{}}) ou que vous le copiez d'une autre page. Ceci n'est pas évident pour les nouveaux utilisateurs, et les utilisateurs confirmés doivent aussi réapprendre séparément chaque nouveau modèle.
Certains wikis ont des gadgets qui ajoutent des boutons pour insérer des modèles communs au projet et à la barre d'édition. Cela dépend des wikis, même si beaucoup de modèles ont des fonctionnalités similaires parmi les projets et les langues.
Utilisateurs de l’Editeur visuel
Les utilisateurs de l'Editeur Visuel ont certains avantages en utilisant des modèles, néanmoins ces derniers présentent également quelques problèmes : dans l'Editeur Visuel toutes les fonctionnalités des modèles sont cachées derrière l'élément de menu « Insérer → Modèle » et l'utilisateur doit connaître le nom du modèle avant de les utiliser.
Le menu « Insérer » de l'Editeur Visuel possède des entrées pour les formules mathématiques, les hyéroglyphes égyptiens, les partitions de musique, et quelques autres fonctions qui sont implémentées par les extensions, mais il n'y a rien concernant les boîtes d'information, les références nécessaires, la conversion d'unités, la mise entre apostrophes, etc. Tous les modèles sont du même type d'éléments génériques.
Sauf une exception : certains wikis possèdent le bouton « Sourcer » , qui insère des notes de bas de page avec les modèles référencés. Néanmoins, c'est une exception qui prouve la règle. Cela nécessite de configurer manuellement même les fonctionnalités de base, et cette configuration est fait séparément pour chaque wiki; en conséquence de quoi, beaucoup de wikis n'ont pas du tout ce bouton. Une autre exception comparable, qui a été ajoutée dernièrement en 2019 est la prise en charge spéciale des modèles Références nécessaires, mais ceci nécessite en plus pour chacun certaines configurations adaptées ainsi que pour chaque wiki, afin que cela puisse fonctionner.
Difficultés pour les éditeurs qui écrivent dans plus d'un projet
Dans un projet donné, il y a beaucoup de modèles, mais pas dans d'autres, et souvent le modèle existe mais sous une forme différente. A cause de cela, il est difficile ou impossible de réutiliser la connaissance acquise dans un projet : les fonctionnalités fournies par le modèle ne sont quelquefois pas disponibles ou fonctionnent différemment. Ceci ne s'applique pas seulement aux wikis de langues différentes, mais aussi à différents wikis d'une même langue, par exemple les Wikipedia et Wikisource anglophones.
Pour les contributeurs qui modifient en différentes langues, les modèles rendent la traduction plus difficile. Lorsque vous traduisez une page, les modèles sont beaucoup plus difficiles à manier que le texte des articles (c'est à dire la prose), que la traduction soit faite de manière manuelle ou par la traduction de contenu. Les utilisateurs doivent souvent sauter le modèle ou le corriger après que l'article ait été publié. Ceci a pour conséquence que certaines traductions restent inachevées parce que la traduction du modèle apparaît intimidante.
Les problèmes rapportés le plus souvent dans la traduction de contenu concernent les modèles.
La traduction de contenu possède une fonctionnalité d'adaptation du modèle, qui automatise cetaines parties de ce processus, mais cela ne fonctionne que si le modèle existe dans les deux langues et que les mainteneurs de modèles ont défini méticuleusement la correspondance de chacun des paramètres. Ceci doit être fait pour chaque modèle dans chaque langue séparément et d'une manière manuelle et soigneusement maintenu lorsque le source du modèle évolue. Cela se produit même si la fonction des modèles dans les différentes langues reste la même la plupart du temps.
Dans l'idéal, les modèles et leurs paramètres doivent être transférés dans la page traduite de manière presque complètement automatique, de sorte que les traducteurs puissent se focaliser sur l'écriture du texte, car la prose dans le domaine où l'humain travaille est la chose la plus nécessaire.
Un modèle peut être exporté d'un wiki vers un autre, mais une fois que cela est fait, le modèle devient une copie dérivée (forked). Soit il reste dans l'état où il était au moment de son exportation, soit il continue à évoluer séparément provoquant alors une rupture de compatibilité. Quelques fois, les contributeurs maintiennent les différentes copies, mais cela n'est pas fiable et ne peut pas s'appliquer à l'échelle des centaines de wikis que nous avons.
Les paramètres des modèles peuvent garder la même fonctionnalité, mais avoir des noms différents dans chaque wiki. Ils peuvent être adaptés en utilisant des alias TemplateData, mais ce n'est qu'un palliatif car TemplateData n'a pas été prévu pour cela à l'origine, et il faut faire cela manuellement pour chaque paire de langues.
Les modèles mélangent la logique algorithmique, les chaînes de caractères lisibles par les humains, ainsi que le formatage. A cause de tout cela il n'existe pas de manières robustes pour traduire le texte des interfaces utilisateur des modèles comme cela est fait dans le noyau MediaWiki et les extensions.
Difficultés pour les éditeurs dans les petits wikis
Un nouveau projet wiki est créé dès que l'on installe le noyau de Mediawiki et que l'on active un ensemble par défaut d'extensions. En pratique, cela ne crée pas encore une aire de jeu car beaucoup des fonctionnalités clé que l'on trouve dans les wikis plus importants viennent des modèles : boîtes d'information, citations, notes-chapeau de maintenance (telles que {{non référencé}}), etc.
Difficultés pour les développeurs logiciels
Pour les développeurs du noyau MediaWiki, des extensions, des robots, ainsi que des autres outils qui analysent, génèrent ou modifient le contenu des pages du wiki, il est difficile de développer des fonctionnalités qui dépendent de la présence de certains modèles sur un wiki. Les développeurs d'extensions telles que : GrowthExperiments, PageTriage, ContentTranslation, certains composants de Wikibase, et beaucoup d'autres, doivent soit les tester en production - ce qui est une mauvaise idée - soit importer les modèles sur leurs wikis locaux ou un wiki de test en ligne.
Le chercheurs qui reçoivent les données de contenu du wiki en se basant sur les modèles doivent écrire le code qui les analyse, séparément pour chaque wiki et quelque fois ils ne le font uniquement que pour un seul wiki. Un exemple significatif est l'utilisation des modèles de projet wiki de la Wikipedia anglophone pour analyser les sujets des pages et accéder à la qualité des articles. {{🌎🌍🌏}}
Hypothèses
Extensions et modèles : similitudes et différences
Le point de départ de cette proposition de projet repose sur la constatation que les modèles et les modules sont très similaires au noyau MediaWiki et aux extensions : ils contiennent du logiciel et ils implémentent des fonctionnalités utiles pour la communauté des contributeurs. En particulier, depuis que les modèles sont habituellement développés par les contributeurs eux-mêmes, il devient évident que la communauté a réellement besoin d'eux. Les grandes différences résident dans la manière dont ils sont développés, internationalisés et déployés.
Les modèles et les modules devraient devenir similaires aux extensions en ce qui concerne certaines propriétés clé qu'ils n'ont pas actuellement, et préserver certaines bonnes propriétés que les extensions n'ont pas (pour que ce soit facile à comprendre par les lecteurs anglais, les exemples de modèles du tableau sont issus de la Wikipedia anglophone. Ils auraient pu aussi bien venir de n'importe quel autre wiki et d'une autre langue).
| Propriété | Noyau et extensions | Modèles | Action sur les modèles |
|---|---|---|---|
| Implémente un type spécial de contenu | Oui.
image, symbole mathématique, hieroglyphes, score, référence de base |
Oui. | |
| └ Un type spécial de contenu est facile à insérer dans les pages | Oui (en utilisant la barre d'outils). | Non (sauf si vous avez appris comment le faire). | Doit être modifié. |
| └ Un type spécial de contenu est facile à adapter pour les appareils mobiles | Oui le plus souvent. | Parfois. | Doit être modifié. |
| └ Un type spécial de contenu est facile à traduire en tant que partie d'article | Oui le plus souvent. | Non. | Doit être modifié. |
| Implémente les fonctionnalités de formatage de page | Oui.
gallery, poem |
Oui. | |
| Implémente les processus de flux de travail communautaire | Oui.
filtre anti-abus, vérification d'utilisateur, renommage |
Oui. | Doit être facile à réutiliser, mais non forcé. |
| Version initiale facilement déployable | Non. | Oui. | Doit être protégé. |
| Modifications facilement déployables | Non. | Oui. | Doit être protégé. |
| Facile à internationaliser | Oui. | Non. | Doit être modifié. |
| Utile sur des wikis multiples | Souvent. | Souvent. | |
| Utilisé uniquement sur un nombre limité de wikis | Parfois. | Parfois. | |
| Facile à installer et à utiliser sur des wikis multiples | Oui. | Non. | Doit être modifié. |
| Facile à utiliser sur un wiki qui est nouveau ou créé récemment | Oui. | Non. | Doit être modifié. |
Compétences pour le développement des modèles et des modules
Un autre ensemble important d'hypothèses sur lesquelles cette proposition est basée est le suivant :
- Les compétences requises pour le développement des modèles et des modules ne sont pas évidentes. A la fois les modèles et les modules comportent des fonctionnalités obscures.
- Bien que les fonctionnalités notables sur la plupart des sites soient implémentées sous forme de modèles et de modules, ces connaissances ne sont souvent pas remarquées, non appréciées, ou prises pour argent comptant.
- Il existe des dizaines de contributeurs qui ont ces compétences et qui modifient plusieurs wikis. Ils se concentre d'ordinaire sur leur wiki d'accueil et communiquent très rarement avec les contributeurs d'autres wikis ou d'autres langues. Néanmoins, la technologie sous-jascente est la même partout, il n'existe pas vraiement de communauté globale réelle de développeurs de modèles qui pourrait être comparée à la communauté globale des développeurs du noyau MediaWiki et des extensions. Il existe des cas de collaboration inter-wiki pour certains modèles, mais ils ne sont pas cohérents.
- Il existe aussi beaucoup de wikis pour lesquels il n'y a pas de contributeurs ayant ces compétences. Soit ils recopient les modèles et les modules à partir des autres wikis sans comprendre complètement la manière dont ils fonctionnent et sans avoir la possibilité de les traduire et de les maintenir effectivement, soit ils n'utilisent pas du tout ces modèles.
Cette situation est loin d'être optimale. Les connaissances des développeurs de modèles et de modules doivent être détaillées davantage. Ils développent des fonctionnalités réellement nécessaires, et ils appartiennent à leur communauté d'éditeurs. Dans les wikis de beaucoup de langues, les développeurs de modèles arrivent avec de nouvelles fonctionnalités innovantes pour le contenu structuré, la présentation des données et la modularisation. Ces innovations pourraient être utiles dans beaucoup de wikis, mais actuellement il n'existe pas de mécanisme pratique pour faire cela.
Et bien sûr, toute solution à ces problèmes ne doit pas aboutir à des technologies complètement nouvelles qui annuleront les nombreuses années d'expérience pratique acquises par les mainteneurs des modèles. Par conséquent, il doit y avoir aussi peu de changements que possible dans la syntaxe pour développer les modèles et les modules. Les choses à changer sont la manière dont ils sont déployés et propagés entre les wikis, et la manière dont les chaînes lisibles par l'homme qu'ils contiennent, sont localisées (traduites). {{🌎🌍🌏}}
La solution proposée : sommaire
Beaucoup de fonctionnalités de MediaWiki sont déjà globales à tous les wikis :
- images (en utilisant Commons)
- blocage
- comptes utilisateur (CentralAuth)
- préférences
- pages utilisateur
- pages utilisateur JS et CSS
- la liste globale de suivi est en phase de développement actif depuis la fin 2020 (GlobalWatchlist)
- et quelques autres.
Il faut pouvoir sauvegarder les modèles et les modules sur un dépôt global, et aussi pour les internationaliser avec la même robustesse que cela est fait avec les extensions.
Les modèles et les modules globaux permettront aux responsables de modèles dans tous les wikis, de collaborer plus facilement au développement du code de ces modèles.
Les modèles et les modules globaux permettront aux traducteurs et aux personnes locales de se concentrer uniquement sur la traduction du texte de l'interface utilisateur (les messages), sans avoir à rechercher les chaînes de caractères dans le code, et en leur permettant ainsi d'utiliser les mêmes conaissances et les mêmes outils pour la traduction des modèles que pour celle des extensions MediaWiki.
Les modèles globaux et les modules vont renforcer les éditeurs de contenu dans tous les wikis pour l'écriture et la traduction de contenu qui utilise ces modèles, sans rentrer dans les différences, ni réapprendre les différentes règles et les connaissances liées à chaque wiki.
La syntaxe pour développer les modèles et les modules ainsi que la maintenance générale et le cycle de déploiement ne changent pas, donc toutes les connaissances accumulées pendant les années par les personnes qui ont travaillé à la maintenance des modèles, restent valables.
Tous les wikis pourront utiliser les modèles globaux, mais n'y seront pas obligés. Les communautés garderont leur capacité à réécraser les fonctionnalités globales, l'architecture, les flux de travail et les données.
L'internationalisation des modèles sera aussi aisée que l'internationalisation des extensions MediaWiki. {{🌎🌍🌏}}
La solution proposée: détail des besoins
Les modèles doivent être sémantiques et globaux
Etre sémantique signifie que les autres composants logiciels, particulièrement l'Editeur visuel et le Contenu de traduction, doivent avoir une manière générale pour comprendre qu'un modèle existe et qu'il fournit certaines fonctionnalités, si bien qu'il sera possible de l'insérer dans une page en tant que boîte d'information, citation, balise de maintenance, etc., et non plus comme un modèle générique. Actuellement ce qui est immédiat pour rendre sémantiques les modèles, ce sont les TemplateData, mais ces dernières ne décrivent que les paramètres du modèle. Par exemple elles n'aident pas l'Editeur visuel à ajouter un bouton Insérer une boîte d'information dans la barre d'outils.
Global indique que le code du modèle est maintenu à un seul endroit et qu'il est utilisable par tous les wikis.
Rendre les modèles sémantiques
Les modèles n'ont jamais été sémantiquement robustes, dans le sens d'être facilement utilisables par le logiciel qui traite les pages.
Voici seulement quelques exemples de modèles qui ont été rendus sémantiques :
- Différents modèles de référence, utilisables à partir du bouton « Sourcer » de la barre d'outils de l'Editeur Visuel. Ils nécessitent d'écrire beaucoup de code séparé pour configurer Citoid sur chaque wiki qui veut les utiliser.
- « Citation nécessaire », qui a été adapté à Visual Editor fin 2019. Il nécessite également une configuration sur chaque wiki. Par exemple : anglais, hébreux, slovène. À ce jour, le français, l'espagnol et la plupart des autres langues ne sont pas configurés pour cela, même s'ils ont des modèles de ce type. (tâche T211243)
- Modèles pour mentionner des utilisateurs dans l'extension Flow, nécessitant aussi une configuration locale.
- Certains processus de vidage (dump) et outils de recherche peuvent analyser syntaxiquement les modèles d'acces aux pages des projets wiki de la Wikipedia anglophone, qui sont habituellement ajoutés aux pages de discusssion.
- L'extension GrowthExperiments suggère aux éditeurs d'effectuer certaines tâches dans les articles en fonction des modèles qui y sont inclus. Les noms des modèles doivent être configurés manuellement en écrivant les fichiers JSON séparément dans chaque wiki. Par exemple: tchèque,vietnamien, koréen, arabe.
- L'extension PageTriage est configurée pour fonctionner avec les modèles des notes chapeau de la Wikipedia anglophone (également connues comme « balises » ).
Dans le cas de PageTriage, l'extension code en dur essentiellement les modèles d'un wiki unique, ce qui la rend inutilisable dans d'autres wikis sans réécriture importante. Même si l'étape de configuration sur les wikis est petite, comme c'est le cas avec l'exemple Flow, elle doit encore être effectuée. Cela ne convient pas bien aux 900 wikis de Wikimedia et aux milliers qu’elle aura à l’avenir.
Ces éléments doivent être globaux par défaut afin d'être immédiatement utilisables par les extensions, les robots, les analyseurs de dump ... , dans au moins une configuration par défaut sur tous les wikis et en même temps.
Stockage et diffusion
Les modèles globaux et les modules peuvent être stockés sur un wiki central (tel que Meta, Commons, ou un wiki complètement nouveau), ou même être Gerrit ou un autre dépôt.
La meilleure solution est probablement de créer un nouveau wiki qui va les héberger, sans les mélanger avec les images, les discussions générales de la communauté, etc.
L'utilisation de Gerrit comme stockage pour les modèles et le code des modules est techniquement possible, mais cela perdrait un élément important d'accessibilité pour les mainteneurs de modèles : la modification d'un modèle dans une page wiki est beaucoup plus facile et familière à la grande majorité des mainteneurs de modèles que de faire des validations dans Git et des relectures de code. Par conséquent, Gerrit ne devrait probablement pas devenir un moyen de stocker les modèles et le code des modules, du moins pas être le principal.
Les modèles et les modules globaux doivent être stockés sur un dépôt commun qui peut être modifié par la plupart des contributeurs du wiki. Les règles concernant le blocage et les autorisations spéciales doivent être similaires initialement, aux règles des les autres wikis : tout doit être ouvert par défaut, et il doit être possible de protéger les modèles les plus communs, ceux qui sont sensibles ou fréquemment vandalisés. Des règles plus détaillées sur les niveaux de protection peuvent être développées ultérieurement par la communauté des éditeurs.
Le code des modèles dans le dépôt central utilisera les noms génériques anglais des balises tels que <section>, les fonctions d'analyse syntaxique telles que {{#ifexist}} ou {{#invoke}}, et les mots magiques tels que {{DISPLAYTITLE}}.
La façon dont les modèles sont diffusés sur les wikis cibles est une question d'ingénierie interne et d'architecture, tant que les autres exigences sont satisfaites. Ces questions ont été discutées dans le passé par certains développeurs de plates-formes, par exemple autour du projet Espaces de noms fantômes. Ce document tente de répondre aux questions connexes sur la façon dont cela fonctionne pour l'utilisateur qui modifie une page utilisant un modèle, ou qui maintient le modèle lui-même - comment l'écrire de manière localisable; comment est-il traduit; comment est-il personnalisé localement; etc. Ces questions n’ont pas été suffisamment abordées dans les discussions architecturales précédentes sur le sujet.
Les modèles doivent rester faciles à modifier
Une fonctionnalité importante concernant la manière dont les modèles fonctionnent actuellement, est qu'on les modifie exactement comme des pages wiki et ils deviennent immédiatement fonctionnels après leur publication sans relecture ni déploiement. C'est un peu dangereux car une mauvaise correction peut casser nombre de pages, mais la réalité est que cela fonctionne plutôt bien.
Cette facilité doit être préservée. Les membres de la communauté qui maintiennent des modèles rejetteront très probablement le passage à un nouveau système qui les obligera à acquérir de nouvelles compétences et à faire passer chaque changement par une phase de relecture et de déploiement épuisante. Cela signifie probablement que le stockage des modèles dans Gerrit ne fonctionnera pas, sauf si, peut-être, le processus de relecture et de déploiement est beaucoup plus facile qu'il n'est pour les extensions.
Il doit être possible de rendre les modèles non globaux
Tous les modèles ne seront pas forcés à devenir globaux.
En réalité, certain modèles doivent rester locaux parce qu'ils implémentent une fonctionnalité dédiée à une langue donnée. De par leur nature, de tels modèles ne doivent pas être traduits, et il faut définir une manière de le signaler aux contributeurs humains ainsi qu'aux outils de traduction (tel que la traduction de contenu) afin de ne pas les adapter, et qu'ils peuvent être sautés ou substitués. Ceci est une partie de l'effort à réaliser pour avoir des modèles plus sémantiques.
On doit pouvoir réécraser certaines fonctionnalités ou l'apparence d'un modèle global
Aucune communauté ne doit sentir se voir imposer une fonctionnalité par un acteur extérieur puissant tel que la communauté de la Wikipedia anglophone, celle de Wikidata, la WMF, ou qui que ce soit d'autre. Les modèles globaux doivent être développés et utilisés collaborativement pour le bénéfice commun. La plupart du temps, cela s'applique à chacun de nous.
Parfois, certaines communautés auront des opinions bien arrêtées sur le fait de vouloir avoir une fonctionnalité ou une conception particulière qui sera différente dans leur langue ou leur projet, ou d'afficher une boîte d'information avec des données différentes de celles qui sont affichées dans d'autres projets, ou de ne pas les montrer du tout. La possibilité de remplacer les éléments localement doit être autorisée dès le départ (ou plutôt, elle ne doit pas être supprimée).
Un modèle global doit être immédiatement utilisable dans chaque wiki
Tout comme une page utilisateur globale est immédiatement disponible sur chaque wiki où il n'y a pas de page utilisateur globale, chaque modèle ou module créé dans l'infrastructure globale doit être immédiatement utilisable dans chaque wiki.
Cela ne doit pas induire d'étapes supplémentaires, telles que copier des pages wiki, créer des modèles de type conteneur avec un nom local, faire intervenir un administrateur, attendre pendant des heures que les caches se remettent à jour, etc.
Après que la version centralisée a été mise à jour, la nouvelle version apparaît partout. Pour combattre le vandalisme, la communauté des éditeurs développera des règles sur les droits ainsi que des niveaux de protection.
Si le texte de l'interface utilisateur (connu également comme composé d'un ensemble de messages) n'est pas traduit, le modèle reste utilisable néanmoins mais le texte est affiché dans la langue de repli. Voir les sections sur l'internationalisation pour plus de détails.
Traduction du texte présenté à l'utilisateur
Le texte présenté à l'utilisateur doit être traductible
Les textes de l'interface utilisateur (messages) du noyau MediaWiki, des extensions, et de quelques outils externes tels que Pageviews sont traduits facilement et de manière fiable sur translatewiki.net. Ce processus de traduction est familier au moins à quelques contributeurs dans toutes les langues.
Il n'est pas possible actuellement de faire la même chose avec les modèles. Les sites multilingues tels que Commons et mediawiki.org disposent du système TNT pour traduire certains modèles, mais ceci est très compliqué et ne peut être réutilisé pour Wikipedia, Wikisource, etc. En 2021, ceci est devenu plus solide avec la fonctionnalité de "transclusion consciente des langues", mais il a toujours besoin de quelques améliorations.
Au mieux, il doit être possible de traduire les modèles tout comme on le fait pour le noyau ou les extensions, en utilisant un wiki avec l'extension Translate.
La chaîne traduite doit être immédiatement utilisable après que la traduction ait été fournie par l'interface Translate.
Il doit être possible de modifier le texte de l'interface utilisateur sur des pages wiki brutes, mais l'idéal est qu'il soit modifié d'abord en passant par un interface de traduction dédié.
Les traducteurs doivent pourvoir se concentrer sur la traduction uniquement du texte. En faisant apparaître du code à côté, les personnes avec moins d'expérience en programmation et avec les fichiers JSON auront plus de difficultés à contribuer. En plus, la modification des traductions où l'écriture de fait de droite à gauche dans les fichiers de texte brut n'est pas du tout pratique. L'extension Translate résoud déjà tous ces problèmes.
Les pages de documentation des modèles doivent également être traductibles. Il suffit presque de le faire en utilisant la fonctionnalité de traduction de page de l'extension Translate, mais cela peut nécessiter quelques adaptations.
Langue dans laquelle le texte est présenté à l'utilisateur
Les modèles sont utilisés initialement pour être intégrés à du contenu, donc par défaut les messages traduits doivent être affichés dans la langue du contenu du wiki.
Certains modèles sont néanmoins utilisés comme éléments de l'interface utilisateur. C'est pourquoi il est acceptable de permettre également l'affichage des chaînes traduites dans la langue de l'utilisateur, lorsque celle-ci est différente de la langue du contenu du wiki. Ceci peut être particulièrement adapté aux sites multilingues tels que Commons, Wikidata, Meta, et mediawiki.org.
Les chaînes habituelles des langues de repli de MediaWiki doivent être utilisées lorsqu'une traduction n'est pas disponible. Par exemple, si un message n'est pas traduit en quechua ou guarani, il sera affiché en espagnol, s'il n'est pas traduit en bachkir ou en tchouvache, il sera affiché en russe, etc. La langue de repli ultime est l'anglais, donc si ce message n'est pas traduit en espagnol ni en russe, il sera affiché en anglais.
Clés des messages
Les messages doivent être représentés par des clés, de la même manière que cela est fait dans le noyau de MediaWiki, les extensions et les outils.
L'écriture de chaînes traductibles sera probablement le plus grand changement dans le processus de développement du modèle auquel les mainteneurs de modèles devront s'habituer. Les chaînes codées en dur devront être séparées et renommées en messages organisés par clé. Cela doit être le plus facile possible et pas seulement pour les traducteurs mais aussi pour les mainteneurs de modèles. Sinon, ils ne le feront pas maintenant et la fonctionnalité sera effectivement rejetée.
Pour rendre facilement les clés globalement uniques, il est probablement possible d'inclure automatiquement le nom du modèle global dans la clé du message.
Outils de transition
Un outil est à écrire pour aider au transfert des modèles et des modules vers le dépôt central. Il pourrait réaliser les étapes suivantes :
- Exportez un modèle d'un wiki local et importez le dans le wiki global.
- Exportez tous les modèles utilisés par ce modèle (en cascade).
- Identifiez les chaînes de caractères lisibles par un humain, convertissez-les en une liste avec les clés associées, et remplacez-les par les clés dans le code source du modèle.
- Importez la page de documentation du modèle avec les TemplateData.
- Importez les pages CSS nécessaires.
Dans la plupart des cas, ce processus automatique ne peut probablement pas créer un modèle ou un module robuste et complètement utilisable, mais il peut aider à commencer le processus de transition.
Organiser les messages
L'extension Translate organise les messages par groupes, également appelés « projets », qui peuvent être organisés par groupes agrégés. Par exemple, Article Placeholder, Score et Poem sont tous des groupes qui représentent les extensions MediaWiki correspondantes, et ils sont tous inclus dans le groupe agrégé « Extensions utilisées par Wikimedia - Advancé », avec de nombreuses autres extensions en parallèle.
Les projets représentant les extensions MediaWiki sont configurés dans des fichiers YAML dans le dépôt translatewiki et affichés dans l'interface utilisateur de Translate dans un sélecteur de projets également connu comme le sélecteur de groupe de messages.
Parce qu'il existe beaucoup plus de modèles que d'extensions, certaines modifications peuvent être nécessaires pour faciliter la traduction des modèles dû à la manière dont l'extension Translate gère les groupes de messages.
Chaque modèle doit représenter un groupe de messages. Les modèles liés de manière proche doivent figurer dans un groupe de messages aggrégés. Il peuvent être similaires aux catégories dans lesquelles ils sont rangés et en fait, on peut même réutiliser les catégories. Modifier les fichiers dans un dépôt Git pour organiser ces groupes de messages n'est probablement pas ce que l'on souhaite car cela est trop complexe et lent.
Il serait bon d'afficher les noms des groupes et des modèles tels que traduits dans le sélecteur, mais c'est aussi bien qu'ils soient affichés en anglais. Si cela convient aux traducteurs d'extensions, cela convient également aux traducteurs de modèles.
Les modèles doivent être affichés sous forme de groupes de messages sur la page spéciale des statistiques de langue de l'extension Translate (Special:LanguageStats). Cela aide les localisateurs à trouver les modèles qu'il faut traduire. Cela doit être généralement similaire à tous les groupes de messages, mais il existe des considérations spéciales pour les modèles :
- Nous aurons des milliers de modèles, et il serait bien que l'architecture de la table corresponde quelque part à cela.
- La table doit afficher le nombre de pages sur lesquelles chaque modèle est transclus en fournissant une manière de trier les rangées en fonction de ce nombre pour aider les traducteurs à attribuer une priorité à ce qui est le plus important à traduire.
Trouver la manière de traduire un modèle
Chaque page de description de modèle doit avoir un lien direct vers sa traduction dans la langue de l'utilisateur.
Certains modèles utilisent des étiquettes Wikidata dans le cadre de leur interface utilisateur au lieu de chaînes codées en dur. Cela se fait actuellement dans les les boîtes d'information Wikidata sur Commons, dans Infotaula persona (boîtes d'information de personnes) dans la Wikipedia catalane, et dans plusieurs autres modèles. Ces étiquettes et valeurs peuvent être localisées dans Wikidata lui-même. Une telle utilisation ne peut pas couvrir tous les besoins de localisation de modèles, mais elle est légitime et utile à des fins particulières. Tant que cela est correctement décrit dans la documentation du modèle, il peut continuer à être utilisé et n'a probablement pas besoin d'adaptations spéciales d'infrastructure. (Il est possible que la traduction des étiquettes et des valeurs pertinentes puisse être en quelque sorte intégrée à l'interface de traduction pour localiser le modèle, mais cela est facultatif.)
Paramètres des messages et mots magiques
Dans le noyau MediaWiki et les extensions, beaucoup de messages possèdent des paramètres, connus quelques fois sous le nom de placeholders (éléments à remplacer). Ils sont appellés $1, $2, etc., et sont initialisés au moment de l'exécution. Les paramètres sont particulièrement importants pour consolider la traduction des messages car l'ordre des mots dépend de la langue.
Quelquechose de similaire est nécessaire également dans les modèles, bien que la forme ne soit pas forcément $1, $2, mais avec des paramètres comme ceux des modèles, c'est à dire avec des accolades triples ({{{}}}). Il faudra décider de cela en prenant en compte les besoins de l'analyse syntaxique et ceux de la traduction.
Les mots magiques PLURAL, GENDER, et GRAMMAR doivent être pris en charge dans les messages des modèles ainsi que dans les messages MediaWiki.
Documentation des messages
Dans le noyau MediaWiki et dans les extensions, chaque message traduisible est documenté pour la commodité des développeurs et des traducteurs. La documentation peut inclure des informations sur l'endroit où le message apparaît, ce que sont les paramètres $1, $2, etc. , si le mot est un verbe ou un adjectif, etc. Cette documentation est stockée dans la pseudo-langue qqq.
Une telle documentation sera également utile pour la traduction des modèles. La façon dont elle sera stockée est une question d'architecture technique. Peut-être on peut la combiner avec les TemplateData, peut-être on peut la classer en tant que langue qqq, et peut-etre même elle peut devenir quelque chose d'autre.
Langue source
Les modèles seront importés dans le dépôt global pas seulement à partir des projets en langue anglaise, mais également à partir de beaucoup de wikis dans d'autres langues. Plus que jamais, les outils de traduction doivent prendre en charge les traductions à partir de n'importe quelle langue et pas seulement depuis l'anglais.
Technique du fuzzying
Dans le noyau MediaWiki, les extensions et les pages traductibles, si le message source en anglais est modifé, le message est automatiquement marqué comme obsolète ou fuzzy. Les traductions existantes restent opérationnelles, mais sont signalées aux traducteurs comme ayant besoin d'être mises à jour (le gestionnaire de traduction peut également marquer un message comme n'ayant pas besoin d'être fuzzy).
Un mécanisme similaire sera nécessaire pour internationaliser les modèles. Néanmoins puisqu'il serait bon que les sources soient forcés en anglais, il y aura davantage de possibilités d'avoir des messages fuzzy.
Considérations pour internationaliser les modules
Les modules Lua peuvent charger et faire l'analyse syntaxique des chaînes traductibles de MediaWiki, mais il n'existe pas de manière définie pour stocker ces chaînes, pour les modules Lua qui sont maintenus de la même manière que les pages wiki. Il est possible d'embarquer les modules Lua en tant que parties d'extensions, afin qu'ils puissent ensuite charger les messages à partir des fichiers i18/*.json des extensions, mais ceci n'est possible actuellement qu'avec un petit nombre d'extensions. Réécrire les modèles en Lua peut être une solution plus robuste d'un point de vue technique mais Lua ne sera pas nécessairement adopté par tous les mainteneurs de modules existants, et leur collaboration sera cruciale au succès du projet, donc cela ne pourra pas se faire avec tous les modèles.
Certains modules techniques très internes, utilisés en commun, rarement modifiés et qui n'ont pas besoin d'être traduits, peuvent probablement être déplacés sans douleur vers l'extension Scribunto elle même. Comme exemples, nous avons No globals et Arguments.
Internationaliser le nom du modèle
Le modèle peut avoir un nom différent dans chaque langue, mais il doit être directement connecté au dépôt central.
Les modèles et les modules globaux sont supposés être directement utilisables sur tous les wikis sans étapes supplémentaires, donc il doit être possible de transclure un modèle global dans une page du wiki local en utilisant son nom global. La communauté des éditeurs inter-wiki décidera des règles concernant les noms globaux.
Comme pour les noms des paramètres, les modèles peuvent avoir des noms différents dans les différentes langues, et ceci doit être respecté. Il faut une méthode structurée pour traduire le nom des modèles. Peut-être les liens de site Wikidata peuvent apporter une solution, mais pas nécessairement.
Si cela n'est pas fait, les contributeurs vont soit éviter les modèles globaux, ou bien ils vont inclure le modèle global dans un modèle local avec un nom traduit, ce qui fera perdre probablement au modèle tout lien avec l'entité globale. Cela n'est pas souhaité et ne correspond pas au but de ce projet.
Les noms des modèles doivent uniquement être traduits dans les langues qui peuvent être des langues du contenu des wikis. La traduction en allemand formel ou en anglais britannique n'est probablement pas nécessaire. Il peut y avoir un moyen d'avoir des alias ou des redirections. Les variantes de langue, par exemple pour le serbe et le chinois, doivent être prises en charge en fonction des besoins de ces langues.
Si un modèle local existe dans un wiki et qu'il a le même nom qu'un nom localisé d'un modèle global, le modèle local sera utilisé. Ceci est similaire à la façon dont les fichiers locaux avec des noms identiques remplacent les fichiers globaux sur Commons, ainsi que la manière dont les messages locaux dans l'espace MediaWiki remplacent la localisation provenant du code.
Les noms des modules Lua sont également souvent localisés. Ces noms peuvent être traduits pour un appel direct à partir des pages wiki, mais comme le code utilise généralement des identifiants de style anglais, les noms internes globaux doivent probablement être préférés pour une utilisation dans le code lui-même, par exemple dans les instructions require .
Internationalisation des paramètres
Internationalisation le nom des paramètres
Le nom des paramètres est différent dans chaque langue. il est généralement basé sur plusieurs mots dans chaque langue, donc il est important pour une modification facile de la transclusion dans la syntaxe wiki.
Idéalement, le modèle global devrait avoir des noms de paramètres internes génériques qui possèdent des traductions dans les différentes langues. C'est quelque peu similaire aux étiquettes de nom des propriétés dans Wikidata, mais cela peut être plus simple : comme l'anglais est une lingua franca pour les développeurs logiciels et que les modèles sont une sorte de logiciel, il est probablement évident que l'anglais soit la langue source par défaut plutôt que d'utiliser des numéros génériques comme c'est le cas dans Wikidata.
Ces noms génériques de paramètre seront les noms communs par défaut. Ils fonctionneront sur les wikis dans toutes les langues. Les noms traduits seront utilisés sur les wikis si la langue du contenu leur correspond.
Ces traductions de noms de paramètres doivent être validées :
- ils ne doivent pas contenir de caractères non valides
- ils ne doivent pas être répétés dans un même modèle d'une même langue
- Autre chose ?
Le processus actuel de traduction des noms des paramètres peut être différent de la traduction des chaînes d'interface utilisateur. Ces noms ont des contraintes techniques, et ils doivent rester stables car la modification d'un nom de paramètre cassera les transclusions existantes, donc il faut prendre des garanties contre cela.
Traduction automatique des paramètres
Si tous les modèles et les paramètres traduits sont stockés de manière centrale, il sera possible d'avoir un service simple réalisant un appel de modèle valide avec ses paramètres, un nom de langue source, et un autre pour la cible, et renvoyant l'appel au modèle traduit. Par exemple :
Entrée :
{
sourcewiki: "enwiki",
targetwiki: "frwiki",
template: "{{Infobox writer|name=Ľudovít Štúr|birth_date=1815-10-28}}"
}
Sortie :
{
template: "{{Infobox Écrivain|nom=Ľudovít Štúr|date de naissance=1815-10-28}}"
}
Dans la traduction de contenu, ce sera la première façon d'adapter les modèles. Contrairement à ce qui est fait actuellement dans la traduction de contenu pour l'adaptation des modèles, ceci est plus précis et plus complet plutôt que de se baser sur des suppositions.
Dans l'édition visuelle et l'édition de la syntaxe wiki de style 2017, il suffit de copier et coller un modèle à partir du wiki d'une autre langue pour effectuer la traduction des paramètres automatiquement.
Pour une édition de la syntaxe wiki simple, il doit y avoir un moyen simple d'utiliser ce service, par exemple une page spéciale ou une boîte de dialogue où un contributeur peut coller le modèle et la langue source et obtenir le modèle traduit avec ses paramètres.
Dans les deux cas, seuls les noms des modèles et les paramètres seront traduits. La traduction des valeurs du paramètre est discutée à part.
Paramètres anonymes
Les paramètres sans nom et portant un numéro doivent bien sûr rester utilisables.
Il faudra statuer sur la manière dont leur nom sera traduit.
Traduire la valeur des paramètres
En plus de partager la fonctionnalité du modèle et sa conception, il faut aussi penser à faire partager les valeurs des paramètres (ou à ne pas les partager).
Certaines valeurs de paramètres de par leur nature même, restent identiques dans toutes les langues. Comme exemple la prononciation IPA pour un lieu dans sa langue native (par exemple [dɛn ˈɦaːx] pour La Hague), l'année de fondation d'une ville, la formule chimique d'un composant, etc. Au moins certaines de ces valeurs pourraient être stockées dans Wikidata et facilement chargées dans un modèle.
Certaines valeurs de paramètre doivent être traduites ou translitérées, par exemple le nom des personnes, les devises des pays, etc.
Les modèles généraux doivent pouvoir rendre cela possible, mais en pratique, ces éléments sont encore souvent recopiés de wiki à wiki, et ceci doit être également pris en compte.
Certaines valeurs de paramètres peuvent être converties de manière fiable et prévisible automatiquement, et l'infrastructure des modèles globaux doit prendre cela en charge. Par exemple, les formats numériques et les caractères numériques sont souvent différents en birman, dans les langues de l'Inde et dans certaines autres langues, mais ils peuvent être convertis de manière fiable à l'aide d'un logiciel simple.
Les valeurs valides et fonctionnelles des paramètres doivent être utilisables dans plusieurs langues et ne doivent pas être spécifiques à une langue. Par exemple, utiliser « yes » et « no » comme valeurs booléennes est trop centré sur l'anglais. Cela ne nécessite probablement pas de changements dans l'infrastructure, mais surtout un accord dans la communauté de développement des modèles inter wiki sur les bonnes pratiques pour l'adaptation à toutes les langues.
Direction du texte
Les modèles doivent s'adapter automatiquement au sens de lecture (ltr de gauche à droite, ou rtl de droite à gauche) du wiki dans lequel ils sont affichés.
Il serait pratique de pouvoir écrire un modèle d'une manière indépendante du sens de lecture, avec le moins d'indications explicites possibles sur l'alignement à droite ou à gauche.
Robots
Beaucoup de modèles sur plusieurs wikis sont modifiés régulièrement par les robots. Cette possibilité doit être préservée.
Cela suppose de ne pas modifier la structure du logiciel, et on évoque le sujet ici pour compléter car c'est un cas d'utilisation important.
Migrer les modèles à partir des grands wikis vers un dépôt central
La langue source la plus populaire pour la traduction de contenu est de loin l'anglais. Après cela viennent l'espagnol, le russe, le français, l'allemand, le catalan, l'ukrainien, l'italien, le chinois et le portugais. Pour cette raison, il est logique que les modèles courants dans les éditions de Wikipedia dans ces langues les plus courantes, en particulier ceux en anglais, soient ceux qui sont les plus importants à rendre globaux au profit de toutes les autres langues.
Paradoxalement, cependant, les éditeurs dans ces langues les plus importantes, sont également les moins intéressés à les rendre globaux :
- Les modèles fonctionnent déjà bien pour eux et la plupart des personnes ne s'inquiète pas directement de la possibilité de traduire dans d'autres langues.
- Réécrire les modèles de sorte que les chaînes soient traductibles peut s'avérer couteux en temps et peut les obliger à apprendre de nouvelles connaissances sur la maintenance des modèles.
- En rendant le modèle immédiatement utilisable par un nombre plus grand de projets on arrive plus difficilement à un consensus pour les modifications à venir, sur la manière de faire fonctionner le modèle.
- Les contributeurs de différents wikis majeurs devront travailler pour aboutir à un consensus sur la manière de fusionner les modèles qui ont des fonctionnalités similaires et qui sont déja sur leurs sites.
Il s'agit davantage d'une considération de l'aspect pratique et des relations avec la communauté que d'une considération d'ingénierie, mais elle doit être prise en compte lors de la prise de décisions architecturales techniques. Sans une préparation adéquate dans ce domaine, l'ensemble du projet va échouer.
Tant qu'il existe des modèles communs importants qui ne sont pas globaux, la traduction de contenu et d'autres logiciels qui gèrent les modèles de différents wikis de quelque manière que ce soit, devront continuer à les prendre en charge. Si l'infrastructure pour les modèles globaux est créée et que la migration des modèles existants se déroule à un bon rythme, les développeurs peuvent envisager d'arrêter de développer et de délaisser un jour le code pour l'adaptation des modèles non globaux.
Le rythme de migration des modèles pour de grands wikis vers le dépôt central peut être l'une des métriques de réussite du projet.
Les modèles doivent être complètement utilisables, à la fois dans leur syntaxe wiki ainsi que dans l'éditeur visuel
C'est évident mais il faut le dire quand même : la modification de la syntaxe Wiki ne va pas disparaître de si tôt et il doit être possible de conserver la transclusion des modèles d'édition dans les pages en l'état. Cela ne doit pas devenir plus difficile.
Cependant, Visual Editor est de plus en plus adopté par les éditeurs expérimentés et les nouveaux contributeurs, de sorte que chaque fonctionnalité du fonctionnement des modèles doit s'exécuter correctement lors de l'édition visuelle du wiki ainsi que dans l'édition de la syntaxe.
Autres fonctionnalités relatives aux modèles
Certaines fonctionnalités existantes ont rapport avec les modèles dans le noyau Mediawiki et ses extensions. Tout ceci doit continuer à fonctionner, et peut nécessiter une mise à jour au moment où les modèles globaux seront adoptés.
Noyau MediaWiki
Il devrait y avoir des outils sur les wikis pour montrer au moins une analyse de base de l'utilisation des modèles et des modules sur les pages : le nombre de transclusions et d'invocations regroupées par wiki, et les listes de pages qui utilisent les modèles et les modules. La fonctionnalité qui affiche les modèles qu'une page transclut pendant qu'elle est en cours de modification, doit continuer à fonctionner avec les modèles globaux.
La page « Pages liées » doit rester fonctionnelle, et reste utile pour les transclusions globales.
TemplateData
- Il est possible de traduire les descriptions des modèles et des paramètres dans TemplateData, et les traductions sont affichées dans la langue de l'interface utilisateur dans la boîte de dialogue d'insertion de modèle de Visual Editor. C'est bien et doit être préservé. L'interface de traduction pourrait éventuellement être améliorée, mais le début est bon. L'ajout de la prise en charge des données du modèle dans l'extension Translate peut être une solution à cela, mais il peut également exister d'autres possibilités.
- Le paramètre « Mise en forme suggérée du wikicode » (Sur une seule ligne, Multiligne, Personnalisé) doit continuer à fonctionner. Il doit également être possible de les personnaliser par wiki - certains wikis peuvent préférer voir un certain modèle écrit dans la syntaxe wiki comme sur une seule ligne, et certains peuvent préférer utiliser plusieurs lignes.
Citoid
- Citoid doit être configuré sur chaque wiki séparément à l'aide des fichiers JSON, tels que Citoid-template-type-map.json. À l'ère des modèles globaux, il doit devenir possible de partager ces fichiers, afin que le bouton « Sourcer » soit disponible dans tous les wikis et fonctionne de manière identique partout « par défaut ». Comme pour les modèles, il doit exister un moyen de remplacer cette valeur par défaut dans chaque wiki où la communauté souhaite un comportement différent.
Modèles de style
- Il doit être possible d'écrire les pages de style des modèles dans le même dépôt central que celui des modèles. Le style central doit être chargé par défaut et réécrasable localement.
Bac à sable des modèles
- Special:TemplateSandbox doit continuer à fonctionner.
- Il doit être possible de modifier un modèle sur le dépôt central et de l'afficher sur une page d'un wiki cible.
Assistant de modèle
- Le système actuel utilise la recherche standard du wiki pour trouver les modèles. Les résultats sont présentés sur une liste modifiable pour afficher l'état global ou global du modèle.
- TemplateWizard obtient ses informations pour les modèles à partir de l'API TemplateData, donc tant qu'elle continue à renvoyer la même structure, il ne doit pas y avoir de problème, et i18n fonctionne déjà.
Wikibase
- Wikidata peut être utilisé pour inclure certaines valeurs de paramètres à partir d'un dépôt central vers le wiki. Ceci est utilisé de manière productive dans Wikipedia pour plusieurs langues, parmi lesquelles le français, l'hébreu, le basque, le russe, le catalan, l'estonien et quelques autres, ainsi que dans Commons, bien que la mise en œuvre actuelle puisse être différente. Cela doit continuer à fonctionner, bien sûr. L'unification de la manière de faire sur les différents wikis peut devenir l'un des domaines d'impact les plus importants de ce projet.
- Cela peut également faciliter l'implémentation de Wikidata Bridge, le projet permettant de modifier les valeurs dans le modèles à partir des wikis. Les modifications des modèles eux-mêmes ne devront être effectuées qu'une seule fois dans les modèles globaux et non pour chaque wiki.
Editeur Visuel
- Il va sans dire que l'Editeur Visuel doit pouvoir insérer à la fois les modèles locaux et les modèles globaux.
- VisualEditor affiche un lien vers la page de description du modèle dans la boîte de dialogue d'édition du modèle. Ce lien doit pointer directement vers le modèle global lorsqu'il est utilisé.
Développement et déploiement
Le développement de l'infrastructure des modèles et modules globaux est un projet vaste et complexe. Il doit être divisé en parties gérables pour être réalisé. En gros, les différentes parties de ce projet doivent être développées dans l'ordre suivant :
- Modules traduisibles : avant de rendre les modules partageables sur les wikis, l'environnement de leur internationalisation et localisation doit être développé eux. Cela sera immédiatement utile aux modules sur les wikis qui sont déjà multilingues, notamment Commons et Wikidata. Certains d'entre eux sont actuellement traduits à l'aide de tableaux Lua ou d'astuces avec des pages traduisibles, mais ceci n'est pas un système de localisation complet.
- Modules globaux: les modules deviennent partageables entre les wikis. Ceci doit arriver avant de rendre les modèles partageables car l'infrastructure des modèles est moins liée au noyau MédiaWiki.
- Modèles traductibles : ceci est semblable aux modules traductibles ci-dessus, et peut réutiliser beaucoup d'éléments de la même architecture, mais cela nécessitera aussi de disposer de la capacité à traduire les noms de modèle leux-mêmes ainsi que les paramètres et quelques autres fonctions. Voir les sections sur l'internationalisation dans les spécifications.
- Modèles globaux: compléter le projet en rendant les modèles globaux.
Le développement de fonctionnalités plus avancées, telles que la création de modèles sémantiques, peut et doit venir plus tard, après qu'ils soient partageables. S'ils deviennent sémantiques avant d'être partageables, le code qui les décrit sémantiquement sera dérivé sur les différents wikis, comme les modèles eux-mêmes, ce qui rendra la réutilisation du code encore plus difficile qu'aujourd'hui.
L'accès aux modèles et modules globaux sera disponible à partir de tous les wikis Wikimedia. Cela comprend les éditions de Wikipedia, Wiktionary, Wikivoyage, etc. dans toutes les langues, ainsi que Commons, Wikidata, Meta, mediawiki.org, Wikitech, etc., ainsi que les wikis de test (test.wikipedia.org, etc.). Cela est similaire à la façon dont les images sur Commons sont disponibles pour tous les wikis. Même si les modèles et les modules globaux seront disponibles pour les wikis, les wikis ne seront pas obligés de les utiliser.
Rendre les modèles facilement réutilisables sur les projets non-Wikimedia peut également être souhaitable. Même si cela ne profite pas directement aux projets Wikimedia, il peut être judicieux d'envisager de rendre les modèles facilement réutilisables non seulement dans les projets Wikimedia, mais également sur d'autres sites MediaWiki. Faire cela nécessitera probablement un peu plus de travail, mais cela peut contribuer à une meilleure modularisation, et cela pourrait éventuellement profiter également aux projets Wikimedia. Ceci est comparable à la capacité d'intégration directe des images provenant de Commons sur des sites web non-Wikimedia. {{🌎🌍🌏}}
Imaginer un monde
Imaginez un monde où tout être humain pourrait partager librement l'ensemble des connaissances, c'est une chose très facile à réaliser actuellement car les modèles sont globaux :
| Action | Avec le système de modèles actuel | Avec les modèles globaux |
|---|---|---|
| Insérer une boîte d'information en utilisant l'Editeur Visuel |
Notez bien que vous devrez trouver le nom du modèle dans chaque wiki séparément, et que dans certains de ces wiki cela ne fonctionnera pas du tout. |
Notez-bien que ceci fonctionne de la même manière pour tous les wikis et dans toutes les langues, sauf si cela est explicitement réécrasé. |
| Insérer une boîte d'information en utilisant l'éditeur de syntaxe wiki |
|
Si vous voulez, vous pouvez encore faire les mêmes actions qu'avec le système de modèles actuel.
Mais vous disposerez en plus de ces fonctionnalités optionnelles :
|
| Utiliser dans le wiki de votre langue, un super modèle que vous avez vu sur un wiki en anglais, français, russe ou espagnol |
|
Si le modèle se trouve dans le dépôt global, alors :
Voilà, le modèle est complètement utilisable dans votre langue. (Et oui, cela aussi doit être répété pour chaque langue, et la même chose est vraie pour les extensions MediaWiki). |
| Utiliser dans le wiki de votre langue, les nouvelles fonctionnalités d'un super modèle que vous avez déjà exporté à partir d'un wiki en anglais, français, russe ou d'une autre langue | Trois options :
|
Traduisez simplement le nouveau texte. Toutes les nouvellles fonctionnalités sont déja disponibles pour tous les wikis. |
| Implémenter Wikidata Bridge (pour la modification des données Wikidata directement à partir des boîtes d'information) | Ceci est un projet qui n'est qu'à l'aube de sa définition. Néanmoins, on peut déjà affirmer qu'avec la technologie actuelle, l'implémentation va demander probablement la modification de chaque modèle de boîte d'information et ceci dans chaque wiki en fonction des instructions publiées par les développeurs Wikidata. | Le code des modèles des boîtes d'information ne sera modifié qu'une seule fois et fonctionnera pour tous les wikis. |
| Traduire un article dans votre langue à partir de l'anglais, du français, ou du russe en utilisant le traduction de contenu. |
Dans ce scénario, les étapes 4 et 7 peuvent prendre plus de temps que l'étape 3. |
Dans ce scenario, l'étape 3 prend le plus de temps, les étapes 4 et 7 sont très courtes, et le temps total est plus court. |
| Copier un extrait intéressant d'un article académique de la Wikipédia danoise vers la Wikipedia allemande (ou avec des autres langues) |
|
Dans l'Editeur Visuel: copiez/collez sans vous préoccuper si cela fonctionne ou pas
Dans l'éditeur de syntaxe wiki :
(Dans l'Editeur de syntaxe wiki 2017, l'outil de conversion des modèles peut éventuellement être intégré à l'action Coller). |
| Avoir un tableau des derniers résultats du Tour de France actuel dans la Wikipedia de votre langue
Ce scénario est basé sur le module actuel Course cycliste. Il n'est pas utilisé dans la Wikipedia anglophone suite aux désaccords concernant la conception des tables, mais la communauté semble ouverte pour son adoption dans le futur si les modifications nécessaires sont réalisées. |
|
Pratiquement toutes les langues obtiennent la table entière gratuitement, sans rien faire. Tout le travail est fait par les personnes qui créent les modèles et les modules, une fois pour tout le monde, et par les personnes qui suivent les événements et mettent à jour les résultats. Une plate-forme inter-wiki pour développer et localiser le module et le modèle peuvent faciliter le développement d'une conception acceptable dans toutes les langues. |
| Commencer à écrire un nouveau wiki après la création du domaine. | Après avoir importé le contenu de Incubator, il n'existe pas de modèles pour les boîtes d'information, les références, les boîtes utilisateur, la gestion des discussions, la possibilité de marquer les pages en vue de la fusion ou de la suppression, etc.
Commencez par copier ces modèles un par un, ou créez le votre. Vous trouverez des gens sympas sur d'autres wikis pour vous aider, mais ils ne connaîtront probablement pas votre langue; vous devrez donc traduire manuellement toutes les chaînes de caractères (comme dans le scénario appelé « Utilisez dans le wiki de votre langue, un super modèle que vous avez vu sur un wiki en anglais, français, russe ou espagnol »). Vous pouvez également laisser tel quel et n'écrire que le texte, mais vous aurez alors moins de fonctionnalités : pas de boîtes d'information, pas de citations formatées, pas de flux de travail pour supprimer ou pour fusionner, etc. |
Tous ces modèles sont déjà disponibles. Traduisez simplement les chaînes de caractères dans un interface du type translatewiki. |
| Utiliser une boîte de navigation pendant la lecture d'un article sur un appareil mobile | Pas possible.
Les boîtes de navigation sont si difficiles à adapter aux écrans des mobiles, et si différentes les unes des autres au fil des wikis, qu'elles sont générées par le logiciel (il existe une demande Phabricator pour cela). |
Possible.
Parce que l'infrastructure des modèles est partagée entre les langues, les différentes communautés linguistiques peuvent travailler ensemble ainsi qu'avec les développeurs des interfaces de lecture et de modification pour les mobiles afin de les rendre dynamiques. |
| Avoir une page d'accueil qui soit bien conçue et adaptée aux mobiles avec des actualités mises à jour régulièrement, des articles et des images me concernant, etc. | Option 1 : trouver des volontaires qui connaissent votre langue, mais aussi très bien le HTML et la syntaxe wiki (particulièrement les tables et les modèles) et qui ont le temps de modifier la page d'accueil quotidiennement. Ceci est traité à part et utilise des méthodes différentes dans chaque wiki. C'est le cas d'environ 70 des wikis principaux : anglais, russes, français, espagnols, etc.
Option 2 : si personne ne connaît votre langue et ne peut également maintenir le code HTML de la page principale quotidiennement, copiez le code de la page principale à partir de l'anglais ou du français et demandez à des volontaires d'autres wikis, qui ne connaissent pas votre langue, mais qui connaissent la syntaxe wiki, pour remplacer l'image du jour de temps en temps. Puisqu'ils ne connaissent pas la langue, ils ne peuvent pas maintenir le texte régulièrement, et vous ne pouvez pas le faire parce que vous avez peur de casser le code HTML, donc vous êtes coincé avec le même article présenté sur la page principale pendant des mois, voire des années. Cela se produit avec certaines langues les plus rares. Option 3 : terminez et obtenez une page d'accueil statique, qui - c'est presque certain - ne fonctionnera pas sur les appareils mobiles, même si la page d'accueil figure habituellement parmi les pages les plus vues du wiki. Ceci se produit sur beaucoup de wikis, même si on y trouve des activités de modification. |
Option 1 : si vous disposez de personnes ayant les connaissances requises ainsi que le temps nécessaire pour maintenir une page d'accueil personnalisée et gérée de manière artisanale dans votre langue, et que vous voulez qu'il en soit ainsi, alors faites le.
Option 2 : si vous n'avez personne pour effectuer ce travail manuel ou si votre communauté est d'accord avec une page principale qui ressemble à celle des autres langues, mettez un modèle simple géré de manière centralisée sur votre page principale. Remplacez uniquement le texte des éléments qui changent, sous une forme simple, sans avoir vous préoccuper de la syntaxe wiki, des tableaux ou du HTML. Le processus est le même pour la plupart des wikis, donc les mêmes modèles et les robots peuvent être utilisés par chacun. |
| Analyser comment les articles sont triés en fonction des projets du Wiki pour une recherche concernant Wikipedia |
|
|
{{🌎🌍🌏}}
État
Cette section concerne l'état général du project. Pour les détails relatifs aux derniers développements, ainsi qu'a l'historique brève des efforts passés, voir la page Modèles globaux/Etat.
Comme indiqué ci-dessus, en décembre 2020, cette page n'est qu'une grande idée et non un engagement à mettre en œuvre un projet.
Des idées similaires ont été suggérées dans le passé. La plus ancienne suggestion connue pour rendre les modèles réutilisables sur les wikis a été émise en décembre 2004 dans Bugzilla:Interwiki templates (tâche T3126). Plusieurs autres idées similaires ont été soulevées plus tard, par exemple Phabricator tâche T6547. En février 2017, une proposition similaire appelée Global-Wiki a été classée comme consensus. Certains de ses composants ont été implémentés, tels que les préférences globales, mais pas les modèles.
Le souhait « Dépôt global central pour les modèles, gadgets et modules Lua » est arrivé en 3e position à l'issue de l'enquête 2015 sur les souhaits de la communauté et les « Gadgets globaux » sont arrivés en position 1 dans l'enquête 2016 sur les souhaits de la communauté. Malgré le soutien de la communauté, aucun des deux n'a été mis en œuvre, car ils n'étaient pas appropriés pour l'équipe Community Tech, et ils n'ont pas non plus, été transférés à une autre équipe.
Le projet Platform Evolution (2018) a signifié son intention de prendre en charge les modèles globaux à l'avenir. La page Platform Evolution/Recommendations développe des idées pour la mise à jour de la modularité du contenu, et indique :
- ... les « boîtes » sont un domaine privilégié pour la créer la modularité. Elles représentent des fonctionnalités autonomes et permettent également de partager équitablement les fonctionnalités utilisateur entre les projets et les langues en établissant un service inter-projets pour partager les modèles. Ce projet nous obligera également à considérer comment gérer la mise en page et la structure du contenu séparément du contenu des pièces composables.
La page Evolution de la plateforme/Objectifs qui est directement liée, liste ceci parmi ses objectifs :
- Augmenter l'équité et le pouvoir des outils de contribution. Nous voulons soutenir la contribution de plus de types de contenu, y compris les médias, de manière plus interactive et dans tous les projets. Cela signifie rendre certains outils existants - comme les modèles - disponibles pour une réutilisation cohérente dans tous les projets et toutes les langues. Cela signifie aussi améliorer les outils de traduction pour supprimer les silos de contenu. Enfin, nous voulons également permettre aux contributeurs de créer facilement de nouveaux outils de contenu communs aux projets et qui soint internationalisables.
Abstract Wikipedia, qui a été approuvé par la WMF en juillet 2020 en tant que nouveau projet à développer dans un futur proche, comprend un « dépot inter wiki pour partager les modèles et les modules entre projets de la WMF » à l'intérieur de son composant Wikifunctions comme l'un de ses objectifs principaux (Wikifunctions était auparavant connue sous le nom « Wikilambda »).
L'initiative des modules traductibles a été lancée en septembre 2020. IElle concerne une partie de cette proposition.
Dans le sondage 2021 des souhaits de la communauté, le souhait intitulé « Traduction des modèles » a reçu le plus grand nombre de voix. A la date de décembre 2020, c'est également le souhait avec le plus grand nombre de voix de toute l'histoire. Ce souhait correspond de très près à certaines parties de cette proposition, particulièrement la traduction automatique des paramètres.
Pour d'autres exemples de relations entre cette proposition de modèles globaux et les différents plans stratégiques de la grande communauté Wikimedia, voir la page Modèles globaux/Relation avec la stratégie.
Il n'y a pas de plan technique complet pour la mise en œuvre du partage cross-wiki complet des modules et des modèles. Cette page est une tentative pour proposer un tel plan et attend en retour les avis des contributeurs. {{🌎🌍🌏}}
Liens utiles
Quelques pages relatives discutant de sujets similaires :
- Evolution de la plateforme/Objectifs
- Evolution de la plateforme/Recommendations
- Modèles et modules multilingues - une tentative pour implémenter une fonctionnalité similaire en utilisant des robots
- Résultats du sondage 2015 sur les souhaits de la communauté - Dépôt global et central pour les modèles, les modules Lua et les gadgets est arrivé en position 3 dans le vote des souhaits de la communauté.
Marqué « En développement - Equipe d'analyse » , mais pas réalisé actuellement.
- Quels modèles doivent être globaux ? - une liste informelle faite par différents éditeurs (sur meta)
- RFC sur les espaces de noms fantômes - une RFC dormante concernant une proposition pour l'implémentation technique d'une telle infrastructure
- Manuel:$wgEnableScaryTranscluding - un mécanisme rudimentaire existant pour transclure du contenu au travers des projets. Ceci considéré comme non efficace et dangereux, est désactivé dans les projets Wikimedia.
- Global-Wiki (meta) - est une proposition similaire, avec un champs d'action plus large. Elle a été ouverte pour discuter durant plusieurs années, puis fermée en temps que consensus. Certains éléments qu'elle contient furent implémentés, tels que les pages utilisateur globales et les préférences, mais cela concerne aussi les modèles globaux, qui ne sont pas encore implémentés.
- Wikipédia abstraite - une proposition plus large, qui inclut un module global et un dépôt de modèles (également connu sous le nom de Wikifunctions, et précédemment connu sous le nom de «Wikilambda»).
- Traduction des modèles - Un souhait de la communauté qui correspond à certaines parties de cette proposition, particulièrement pour la traduction automatique des paramètres. {{🌎🌍🌏}}