Wiktionnaire:Prise de décision/Gestion des codes de langues

Proposition close

Résultat :
La proposition est acceptée.

Au vue des réserves mentionnées, il serait sage de mettre en place un système d'ajout groupé et concerté des langues, ce qui permettra de mieux contrôler ce qui s'y met et de ne pas modifier la page trop souvent. — Dakdada 31 mai 2013 à 12:50 (UTC)

Les langues dans le Wiktionnaire

Dans le Wiktionnaire, on utilise le code d'une langue pour l'identifier (fr pour français par exemple). Pour retrouver le nom d'une langue, on a créé pour chaque langue définie un modèle portant le nom du code, et contenant le nom de la langue : le modèle {{fr}} contient donc français. Il suffit donc d'écrire {{fr}} dans une page pour afficher le nom d'une langue.

Ces modèles codés sont actuellement utilisés dans un grand nombre de modèles qui ont besoin du nom de la langue correspondante :

• Modèle de titre de langue ({{langue|fr}}) et de sections ({{-nom-|fr}})
• Modèles de traduction ({{T|en}}, {{trad|en|foo}}, {{trad+|en|foo}}...)
• Divers modèles catégorisants (comme {{familier|fr}}, {{étyl}}...)

L'usage direct est plus rare et généralement déconseillé puisqu'il est plus lisible d'avoir le nom en entier dans le source des pages.

On a actuellement 4433 modèles de langue catégorisés. Les langues et leurs codes sont également listés (à la main) dans la liste des langues. Une page d'explication est disponible dans WT:Langues.

Gestion des langues avec Scribunto

Scribunto est une extension du logiciel Mediawiki qui permet de programmer certaines parties du site en remplacement du code wiki. Des modèles écrits avec Scribunto sont bien plus performants que ceux écrits en texte wiki normal (d'autant plus qu'ils sont compliqués). Mais ils sont aussi plus souples et permettent de faciliter certains aspects du site.

Gestion proposée

Plutôt que de créer une multitude de modèles pour toutes les langues, je propose que les langues ne soient définies que dans une seule page générale, qui listerait les codes langues et le nom de la langue correspondant. La liste actuelle proposée est Module:langues/data.

Ce qui va changer

• Pas grand chose du point de vue des utilisateurs. Les modèles de langue existants déjà seront gardés et toujours utilisables (avec le code changé pour refléter la liste Module:langues/data).
• Plutôt que d'écrire {{fr}} au milieu d'un texte, on pourra préférer {{nom langue|fr}} qui aura les données de langue à jour.
• De même, dans les modèles, on remplacera l'utilisation de {{ {{{lang}}} }} par {{nom langue | {{{lang}}} }}.
• Pour ajouter une langue, il suffira d'ajouter une ligne à Module:langues/data (ou de demander l'ajout, si on n'est pas sûr).

À quoi ça sert ?

Si peu de choses semblent changer, la gestion des langues et les performances des modèles utilisant des langues seront grandement améliorés.

1. Toutes les langues dans une seule page
   • Avoir une multitude de modèles pour autant de langue est très compliqué à gérer.
   • Si toutes les langues sont définies dans une seule page, on peut ajouter une langue très facilement.
   • On peut même en ajouter une liste entière de langues sans que ça ne pose de problème.
   • La liste étant une page de module Scribunto, elle peut être utilisée directement dans tous les modules.
2. Automatisation
   • La liste des langues reflétera en temps réel l'état de la liste des langues (à l'heure actuelle elle doit être modifiée à la main).
   • Plus besoin de catégoriser les modèles de langue supplémentaires.
3. Contrôle
   • Plutôt que de charger n'importe quel modèle à partir du code (on peut très bien écrire {{langue|m}} sans code d'erreur), on peut contrôler l'usage correct des codes langues.
   • En surveillant les modifications de la page Module:langues/data, tout un chacun peut être au courant de l'ajout de nouvelles langues, ou de tout autre changement.
   • Possibilité de se concerter pour l’ajout de nouveaux codes langue, de nouvelles langues (nom plus ou moins francisé, ambigu).
4. Performances
   • La liste est chargée une seule fois par page (plutôt que de charger plusieurs fois les modèles de langue, qui peuvent être des centaines voire des milliers par pages avec les traductions).
   • Avoir une liste de toutes les langues au même endroit dans un module Scribunto permet de récupérer les informations bien plus efficacement que si les informations sont disséminées dans les modèles. Et ce même sans convertir les modèles en Scribunto.
   • Si on convertit les modèles en Scribunto, ils bénéficieront grandement de la liste des langues dans un module Scribunto.
5. Extensibilité
   • Au-delà des noms de langue, la liste pourra également contenir diverses propriétés utiles (utilisables par les modèles) comme : le script utilisé, la famille de la langue, s'il s'agit d'un code normalisé ou pas, etc.

Inconvénients

Les inconvénients de ce changement sont :

1. Besoin de réapprendre comment on ajoute une langue. En particulier, on est amené à modifier une page de module en Lua.
   • Commentaire : tout changement nécessite un apprentissage. En l'occurrence, l'apprentissage est ici minime puisqu'il faut juste apprendre à ajouter une langue dans une liste simple : tout ce qu'il faut savoir faire, c'est copier-coller. À comparer à la procédure actuelle, qui nécessite de créer un modèle et de le catégoriser correctement.
2. S'assurer que tous les modèles existants ont une ligne correspondant dans la nouvelle liste.
3. Mise à jour des pages de documentation à faire.
4. Mettre à jour les modèles qui utilisent les codes langues bruts dans leur source ({{ {{{lang}}} }} -> {{nom langue| {{{lang}}} }}).

Je pense que ces inconvénients sont mineurs par rapport aux améliorations apportées par les changements proposés (la plupart des points ci-dessus sont plus des travaux de transition que des inconvénients). Plus précisément, une fois les changements apportés, tout sera même plus simple qu'actuellement.

Autres inconvénients proposés :

1. Ne plus pouvoir modifier la liste des langues depuis le bas débit car elle atteint actuellement 151 668 octets. Sachant que même en ADSL il y a eu de nombreux problèmes pour des pages de l’ordre de 92 016 octets. — message non signé de JackPotte (d · c)

   Je ne suis pas convaincu qu'avoir un débit faible ne permette pas de modifier la page, ni même que ce soit un argument qui justifierait qu'on ne fasse pas le changement suggéré. 152 Ko, ça reste raisonnable, même avec un bas débit. Je rappelle qu'il est toujours possible de demander à quelqu'un d'ajouter une langue si on n'y arrive pas ou si on ne sait pas comment faire.

   En outre, ça n'a rien à voir avec le temps d'affichage d'une page qui contient un nombre trop important de modèles (cf lien donné).

   Au final, utiliser Lua permettra justement d'éviter que l'utilisation intensive de modèles ne fasse planter les pages, et ça permettra aussi de recevoir les pages plus rapidement, même avec un bas débit. — Dakdada 17 mai 2013 à 11:37 (UTC)

   Évidemment que le temps d’affichage est hors sujet, je te parle de la requête SQL update sur la table text ou de la variable superglobale PHP qui sature (peut-être un quota de temps du php.ini, il faudrait checker les logs avec un admin système au Hackathon pour le déterminer ). JackPotte ($♠) 17 mai 2013 à 13:17 (UTC)

   Sachant qu'il existe déjà plein de page beaucoup plus lourdes (cf w:Spécial:Pages_longues), ça ne posera certainement pas de problème. — Dakdada 17 mai 2013 à 17:13 (UTC)

2. Auparavant on ne risquait pas de flinguer tous les articles du site en ajoutant ou modifiant une langue. — message non signé de JackPotte (d · c)

   Les changements à la liste ne sont pas récupercutés directement dans les articles, mais seulement progressivement (voir w:en:Wikipedia:Job_queue). Sachant que la liste est surveillée, si quelqu'un faisait une erreur (les erreurs de syntaxe ne peuvent pas être sauvegardées, au passage) ou un changement mal intentionné (limité aux contributeurs enregistrés), ce serait facilement corrigé. On peut aussi envisager de bloquer complètement la page et d'ajouter les nouvelles langues périodiquement par quelqu'un qui sait ce qu'il fait (ce que je recommanderais d'ailleurs).

   Ce sera toujours mieux que d'utiliser des modèles que personne ne voit créer et qui ne sont ni surveillés ni protégés.

   Et enfin : risquer de flinguer tous les articles du site, c'est ce qui est fait depuis longtemps puisqu'on utilise de nombreux modèles ubiquitaires. Ces modèles ont d'ailleurs été souvent modifiés (parfois sans discussion), parfois même ces modifications étaient délétères. Mais au final même dans ces cas-là les articles du site n'ont jamais été flingués, et je ne vois pas pourquoi ce serait différent ici. — Dakdada 17 mai 2013 à 11:51 (UTC)

   Spécial:Pages_non_suivies devrait te donner raison sur ce point, il n’empêche que cette liste impacte tous les articles contrairement aux modèles régulièrement modifiés. JackPotte ($♠) 17 mai 2013 à 13:17 (UTC)

   Dans la mesure où seules les pages contenant les langues nouvellement définies verront une différence quand on modifiera la page, ça ne changera pas grand chose en pratique. Si tu penses que modifier trop régulièrement cette page pourrait être dommageable, on peut proposer de préparer une liste de langues et de n'ajouter cette liste qu'une fois par semaine, par exemple. De cette manière l'impact sera minimisé (même si, encore une fois, j'estime qu'on n'a pas trop à s'en faire de ce côté) et il y aura en plus un bon contrôle de ce qui est ajouté. Je suppose ici que la page est protégée complètement, et qu'un admin s'occupera d'ajouter les langues proprement à intervalle régulier. Contrôle, sécurité, impact minime. — Dakdada 17 mai 2013 à 16:53 (UTC)

Changements

Si cette proposition est acceptée, voici ce qu'il faudra faire :

1. Vérifier que tous les codes langues actuels disposant d'un modèle ont une ligne dans la nouvelle liste des langues.
2. Modifier les modèles utilisant les codes langues bruts pour qu'ils récupèrent leur nom avec {{nom langue}}.
3. Modifier leur documentation.
4. Changer les modèles de code langue actuels pour qu'ils reflètent les noms de la liste.
5. Modifier les aides relatives à l’ajout d’une langue sur le Wiktionnaire : Wiktionnaire:Liste des langues#Guide de création et Aide:Modèle#Modèles nom de langue.

Vote

Le vote est ouvert pour deux semaines du 16 mai 2013 au 30 mai 2013. — Dakdada 16 mai 2013 à 16:04 (UTC)

Pour

1. Si j’ai bien tout compris, ça ne va rien changer à ce qui sera sur les pages de contenu mais ça changera un peu l’affichage des pages de modèles, en expliquant plus clairement qu’il s’agit de l’inclusion d’un code de langue. Et ça accélérera le chargement des pages, ça, j’ai bien compris. Donc c’est bon pour moi Eölen 16 mai 2013 à 16:25 (UTC)
2.  Pour Tout à fait d'accord. L’ajout d'une nouvelle langue me semble même plus simple maintenant (si l’on connait l’existence de Module:langues/data). Pamputt ^[Discuter] 16 mai 2013 à 16:33 (UTC)
3.  Pour — Unsui Discuter 16 mai 2013 à 18:33 (UTC)
4.  Pour le regroupement de l’information et l’accélération du chargement des pages. Automatik (discussion) 16 mai 2013 à 22:24 (UTC)
5.  Pour la liste devra inclure les modèles en redirection, pour permettre à {{trad}} de pointer vers le bon site (complément). Sans tenir compte de cette dizaine d’exceptions, l’ancien système de modèles devra continuer à alimenter les traductions avec les codes langues actuels. Une manière astucieuse d’ajouter ces lignes à Module:langues/data serait de les faire pointer vers leur codes langues alias, plutôt que de dupliquer les noms de leurs langues, ou de modifier leurs invocations depuis les modèles (qui ne permettrait pas de les lister). JackPotte ($♠) 17 mai 2013 à 12:17 (UTC)

   Oui, on devra ajouter un paramètre "lien" pour faire correspondre le code du wiki correspondant s'il est différent du code langue qu'on utilise. Pour les alias, il y a plusieurs manières de le faire, mais l'important est qu'au final ils se comportent comme actuellement, de manière transparente. — Dakdada 17 mai 2013 à 16:59 (UTC)

6.  Pour Le problème que soulève Shinji n’est pas anodin mais en comparaison des avantages que cela permet il le devient presque. Comme expliqué par Dak on pourra ajouter les langues de façon groupé à intervalles réguliers et durant les heures creuses et le rafraîchissement ne devrait pas gêner grand monde. V!v£ l@ Rosière ^{/Murmurer…/} 18 mai 2013 à 09:44 (UTC)

   Pendant les heures creuses ça coûtera moins cher, et ça c’est un avantage. -- Béotien lambda ☏ 19 mai 2013 à 12:46 (UTC)

   Au vu du coût initial déjà bien dérisoire, je me demande même si il y aura une réelle différence sur la note. V!v£ l@ Rosière ^{/Murmurer…/} 29 mai 2013 à 14:21 (UTC)

7.  Pour Partant pour la simplicité d’ajout de langue. --Lyokoï (discussion) 19 mai 2013 à 10:33 (UTC)
8.  Pour Cette centralisation a des avantages (simplification, meilleur suivi, etc.), mais elle doit être, en effet, encadrée : La page Module:langues/data/Documentation devrait indiquer la procédure de modification de Module:langues/data : par exemple : « Ajouts à proposer sur Wikidémie ». Module:langues/data doit bien sûr être protégée. Stephane8888 ✍ 29 mai 2013 à 11:38 (UTC) P.S. : je pense qu’il est toujours souhaitable de se concerter pour l’ajout de langues, de codes langue.

Contre

1.  Contre. Cette proposition aura un mauvais effet sur la performance. Maintenant, si on modifie {{amm}} pour une raison mineure comme Wiktionnaire:Wikidémie/août 2012#Désambigüisation de noms de langues, les pages qui le comprennent seront toutes rafraichies, mais ce n’est pas un gros problème parce que le nombre des pages est de moins de dix. Si on accepte cette proposition, on modifiera Module:langues/data, qui sera utilisé dans toutes les pages de l’espace de noms principal. Quelque modification que ce soit sur quelque code de langue que ce soit fera rafraichir plus d’un million de pages. Les modification récentes comprennent plusieurs nouveaux modèles de code de langue, ça signifie que toutes les pages seront rafraichies fréquemment. — TAKASUGI Shinji (d) 18 mai 2013 à 05:39 (UTC)

   Je suggère de migrer d’abord le français, puis de tester les performances pendant une semaine. Cela permettra de revenir en arrière facilement. JackPotte ($♠) 18 mai 2013 à 11:14 (UTC)

   Notez que les pages ne sont pas rafraîchies directement mais sont placées dans une queue qui s'exécute au fur et à mesure de manière, justement, à ne pas impacter les performances (voir w:en:Help:Job queue). On peut envisager de regrouper les ajouts pour éviter d'avoir à rafraîchir le tout trop fréquemment, comme je l'ai dit plus haut. — Dakdada 18 mai 2013 à 11:51 (UTC)

   Pour compléter, comme je l'ai dit plus bas : les anglais ont déjà procédé à une migration similaire (depuis 2 semaines) sans problème particulier. — Dakdada 29 mai 2013 à 11:47 (UTC)

Neutre

1.  Neutre pour le moment : je ne connais pas suffisamment bien MediaWiki pour me faire une idée de l’impact sur les performances (les pages sont pré-rendues dans un cache ?), mais il faut tenir compte du problème mentionné par Shinji. Pour ce qui est de la facilité d’ajouter ou de supprimer des langues, je suis d’accord avec le proposant : copier coller une ligne de Lua, même sans rien y connaître, me paraît plus facile que de créer un modèle MediaWiki complexe. --Eiku (d) 19 mai 2013 à 10:37 (UTC)

   Pour être précis, les pages sont réécrites dès qu'un de leurs éléments est mis à jour (texte, modèles ou modules). Cependant, si on modifie un modèle ou un module très répandu, toute les pages ne sont pas réécrites directement : elles sont ajoutées à une queue, si nécessaire, qui exécute l'opération de mise à jour progressivement, sans impacter les performances du site. On peut voir l'état de cette queue dans la page suivante : [1]. En pratique, ce nombre est généralement proche de 0. — Dakdada 28 mai 2013 à 13:05 (UTC)

2.  Neutre J’aimerais bien que Shinji, qui touche sa bille, confirme son vote Contre ou pas. C’est une opposition de poids qui empêche à mon avis de conclure à un consensus favorable en raison du nombre de vote Pour. Qu’en disent aussi Lmaltier, Stéphane8888, Verdy_p ? Eiku, supra, a-t-il été convaincu ?-- Béotien lambda ☏ 29 mai 2013 à 09:43 (UTC)

   Je peux donner une réponse en pratique : les anglais ont déjà modifié leurs modèles pour qu'ils utilisent une liste similaire, donc on peut les utiliser comme cobaye pour voir si ça marche bien, car l'immense majorité de leurs articles est impactée. Au final, il ne semble pas y avoir de problème quelconque : ils modifient la liste régulièrement ([2]) sans pour autant qu'on ne perçoive d'impact sur les performances (le nombre de jobs est constamment proche de 0 [3]). — Dakdada 29 mai 2013 à 11:46 (UTC)

3.  Neutre Quand je n’ai rien à dire, je préfère généralement ne rien dire, mais là je vois qu’on insiste. --Psychoslave (discussion) 30 mai 2013 à 13:33 (UTC)

Commentaires

Si vous avez quelque chose à commenter, écrivez ici.

Décision

Décompte :

• 8 avis pour
• 1 avis contre
• 3 avis neutre

Majorité pour le changement du mode de gestion. — Dakdada 31 mai 2013 à 12:50 (UTC)