Wiktionnaire:Prise de décision/Mise en place du modèle C pour les précisions de sens

Discussion en cours Cette décision est actuellement en cours de discussion. Avez-vous des remarques, des suggestions, des évolutions à demander pour ce modèle avant le vote ? D’autres remarques à partager au sujet de ce modèle ? À vous la parole : rendez-vous sur la page de discussion de la présente proposition. N’éditez pas la proposition elle-même tant que la discussion n’est pas terminée.

Présentation

Ce qu’on fait actuellement

Actuellement, pour ajouter des précisions de sens à une définition, on utilise un modèle par précision de sens :

Code Wiki	Rendu
# {{France|fr}} {{histoire de France|fr}} {{familier|fr}} {{jeu de paume|fr}}	(France) Modèle:histoire de France (Familier) Modèle:jeu de paume

Cette gestion des précisions de sens est suboptimale pour plusieurs raisons :

• on a un modèle par précision de sens, ce qui rend pratiquement impossible toute gestion globale cohérente des précisions de sens ;
• pour créer un synonyme de la précisions de sens, on doit créer un autre modèle appelant le modèle maître, concourant ainsi à leur multiplication anarchique ;
• cela surcharge le code Wiki, et également l’affichage : on appelle plusieurs modèles, qui sont rendus autant de mentions entre parenthèses ; cela provoque l’affichage de nombreuses parenthèses en début de ligne, diminuant la lisibilité du résultat ;
• appeler une précision de sens pas encore référencée provoque l’affichage d’un lien rouge type Modèle:inexistant.

Ce qui se fait ailleurs

À côté, le Wiktionnaire anglais a le modèle {{lb}}, dont l’utilisation est plus simple :

Code Wiki	Rendu
# {{lb|en|France|history of France|colloquial|jeu de paume}}	(France, history of France, colloquial, jeu de paume)

Comme vous pouvez le voir, ce modèle unique permet l’appel à virtuellement toutes les précisions de sens ; de plus, la configuration des précisions de sens se fait dans une poignée de modèles Lua tels que celui-ci, au lieu d’être éparpillée sur une multitude de pages. L’un dans l’autre, cela résout ou réduit grandement les remarques faites ci-dessus au sujet de la gestion actuelle des précisions de sens sur le Wiktionnaire francophone :

• la gestion des précisions de sens est centralisée ;
• les synonymes sont gérés dans le même modèle que le modèle maître, et non par un autre modèle ;
• cela simplifie à la fois le code Wiki et l’affichage, tout en maintenant l’essentiel ;
• si une précision de sens inconnue est donnée, elle est rendue telle quelle, comme history of France dans l’exemple ci-dessus, au lieu d’un lien rouge du plus mauvais effet.

Ce qu’on pourrait faire

Pour améliorer cela, Darkdadaah (d · c · b) avait créé le modèle {{C}}, dont le fonctionnement actuel est similaire à celui de {{lb}} :

Code Wiki	Rendu
# {{C|familier|France|blablabla|lang=fr}}	(Familier, France, blablabla)

Il est à noter que ce fonctionnement pourrait évoluer en fonction du résultat des discussions et du vote sur la présente page.

Darkdadaah a commencé ce travail en 2013, mais son modèle n’a jamais été adopté, devenant un serpent de mer. La présente page a pour objet de tenter d’enfin mettre en production ce modèle, éventuellement après modification selon le résultat de la discussion sur les deux points ci-dessous.

Possibilités à discuter

Contenu amené à évoluer en fonction des discussions À partir de ce bandeau, le contenu n’est pas encore fixé, car il pourrais évoluer selon les discussions à venir ; veuillez donc ne le considérer comme présent uniquement pour informer des possibilités déjà discutées par ailleurs.

Avant toute chose, un point essentiel : dans les listes de possibilités ci-dessous, la complexité du code Lua se rapporte au nombre de lignes de code, pas nécessairement à la complexité de ces lignes pour un programmeur. Ces mentions se rapportent au principe informatique KISS (Keep It Simple, Stupid) : un programme plus long ou plus complexe est en moyenne plus long à concevoir, plus prompt aux erreurs et bogues, et plus difficile à maintenir. En pratique, la différence n’est pas toujours tangible, mais elle doit être gardée à l’esprit. Ainsi, du seul point de vue de la programmation du modèle et de sa propension à provoquer des erreurs, la meilleure solution pour les deux paramètre proposés est la première, l’absence de support, sinon un support basique et simple au possible.

Langue

Actuellement, lors de l’appel d’une précision de sens, on précise la langue, par exemple {{euphémisme|fr}}. {{C}} pourrait récupérer la langue de la définition actuelle pour ce faire, ce qui éviterait d’avoir à préciser la langue de catégorisation à chaque appel de {{C}} : ainsi, si on est dans la section française de l’article, {{C|France}} ajouterait automatiquement l’article à la catégorie français de France. En cas de besoin, on pourrait garder la possibilité d’ajouter un paramètre de langue pour outrepasser cet auto-paramétrage.

On pourrait aussi ne pas passer par un paramètre nommé mais un paramètre placé à un endroit précis, par exemple en premier, comme le font les anglophones : utiliser {{C|fr|France}} au lieu de {{C|France|lang=fr}}. C’est moins verbeux mais ça casse la convention actuelle.

Les deux possibilités ci-dessus ne sont pas mutuellement exclusives : on peut avoir un paramétrage automatique par défaut et utiliser le premier paramètre au lieu de lang pour outrepasser ce paramétrage par défaut.

Précision secondaire

Une possibilité évoquée au cours des précédents débats concernant ce modèle concernait la possibilité d’affiner les précisions de sens données à l’aide d’un paramètre dédié — dont le nom n’est pas fixé mais pourrait être spéc, et qu’on appellera précision secondaire ci-après — : au lieu d’utiliser une précision de sens jeux de cartes, on donnerait une précision de sens jeu, puis un paramètre affinant cette précision de sens pour indiquer qu’en matière de jeux, on parle uniquement de ceux de carte.

Voici les possibilités de support de cette fonctionnalité, les raisons de choisir telle ou telle possibilité et ses avantages et inconvénients :

Possibilité	Exemple de code	Raisons possibles de faire ce choix	Avantages	Inconvénients
1) Ne pas supporter les précisions secondaires	{{C|histoire|mode romaine|architecture|lang=fr}}	Les cas où une précision secondaire serait réellement utile sont trop limités pour un support généralisé ; elle sera donc gérée par une précision de sens comme les autres.	Rien ne change : pas de nouvelle fonctionnalité à connaître pour les contributeurs ; pas de programmation nécessaire dans le modèle {{C}}, ce qui évite de le complexifier.	Pas de possibilité de hiérarchiser entre elles les précisions de sens par des précisions secondaires.
2) Support d’un seul paramètre de précision secondaire, applicable à une seule précision de sens parmi celles précisées	{{C|histoire|mode|architecture|spéc=romaine|lang=fr}}	Les cas où cette fonctionnalité serait réellement utile sont suffisamment présents pour qu’on la prenne en compte, mais suffisamment limités pour qu’on puisse raisonnablement estimer qu’elle ne sera utilisée qu’une fois par appel au modèle {{C}}	On supporte cette fonctionnalité sans que l’usage en soit trop complexe, et le code Lua nécessaire reste assez limité	À la lecture du code Wiki de l’appel à {{C}}, on ne sait pas à quelle précision de sens se rattache spéc : est-ce l’histoire, la mode ou l’architecture qui est romaine ? Si on ne connaît pas la réponse, on doit examiner le code Lua pour le savoir, ce qui n’est pas trivial ; si la précision secondaire est applicable à plusieurs précisions de sens, comme dans l’exemple en deuxième colonne, le code Lua ne pourra pas savoir à quelle précision de sens appliquer la précision secondaire, introduisant des erreurs dans le rendu ; on ne peut spécifier qu’une précision secondaire, même si plusieurs seraient utiles.
3) Support d’une précision secondaire multivaleurs	{{C|histoire|mode|architecture|spéc=romaine,,moderne|lang=fr}}	On peut avoir besoin de préciser plusieurs précisions secondaires, sans en donner une pour chaque précision de sens : ici, l’histoire est romaine et l’architecture est moderne.	Si besoin, on peut spécifier plusieurs précisions secondaires.	Complexification du code Lua ; complexification du code Wiki en cas d’utilisation des précisions secondaires.
4) Support d’un paramètre par précision secondaire, dont le nom est celui de la précision de sens à laquelle se rattache la précision secondaire	{{C|histoire|histoire=romaine|mode|mode=romaine |architecture|architecture=moderne|lang=fr}}	On peut avoir besoin de préciser plusieurs précisions secondaires.	Le code wiki reste assez lisible, et on voit bien à quelle précision de sens se rattachent les précisions secondaires.	Impossibilité de documenter tous les paramètres nommés supportés par le modèle, car ils seront générés à la volée par le code Lua ; complexification du code Lua ; risque de collision : le modèle aura un comportement chaotique sur tout le Wiktionnaire si on lui donne deux fois la possibilité d’un paramètre secondaire nommé, par exemple, mode.

nocat

De la même manière, a été évoquée le support du paramètre nocat, dont la présence avec une valeur positive permet actuellement, pour virtuellement tous les modèles de précision de sens, d’empêcher la catégorisation de la page appelant le modèle dans la catégorie gérée par ledit modèle.

Par exemple, et pour mémoire, {{euphémisme|fr|nocat=1}} permet de ne pas faire apparaître l’article contenant ce code dans la catégorie Euphémismes en français. nocat est par exemple utilisé dans les sections de synonymes ou de traduction, car, lorsqu’on précise qu’un synonyme ou une traduction est utilisé dans un registre familier, on ne souhaite généralement pas pour autant que la page signalant le synonyme ou la traduction soit elle-même traitée comme d’un registre familier, puisque cette précision de sens concerne uniquement le synonyme ou la traduction.

Là encore, il y a plusieurs façon de gérer cette possibilité, avec chacune ses raisons, avantages et inconvénients :

Possibilité	Exemple de code	Catégories de rangement par cet exemple	Raisons possibles de faire ce choix	Avantages	Inconvénients
1) Pas de support de cette fonctionnalité	{{C|France|familier|nocat=1|lang=fr}}	français de France Termes familiers en français	Ne pas complexifier le code Lua	Code Lua plus simple	Régression par rapport aux précisions de sens actuelles
2) Support d’une seule valeur nocat, appliquée à l’ensemble des précisions de sens	{{C|France|familier|nocat=1}}	Aucune	Quand plusieurs précisions de sens sont utilisées au même emplacement, généralement, soit elles utilisent toutes nocat, soit aucune ne l’utilise ; le support d’une seule valeur de nocat appliquée à l’ensemble des précisions de sens permettrait de suivre cet usage.	Conservation de la fonctionnalité ; usage simple ; code Lua assez simple néanmoins.	Impossibilité d’appliquer nocat à seulement certaines précisions de sens.
3) Support de plusieurs valeurs pour nocat	{{C|France|familier|nocat=,1|lang=fr}}	Termes familiers en français	Garder la souplesse d’utilisation actuelle de nocat par précision de sens	Garder la souplesse d’utilisation actuelle de nocat par précision de sens	Code Wiki moins lisible ; code Lua plus complexe ; le support de ce mode de fonctionnement n’est pas forcément nécessaire, vu l’usage soit généralisé, soit totalement absent, de nocat quand les précisions de sens sont groupées au même endroit.
4) Support automatique selon la section : si on est dans la section Traductions ou Synonymes, ou toute autre section dans laquelle on n’est pas censé catégoriser le mot vedette, ne pas utiliser les précisions de sens pour catégoriser la page	=== {{S|synonymes|fr}} === * {{C|France|familier}} Bla	Aucune	Ne plus se soucier de catégoriser ou non le mot vedette lors de chaque appel de {{C}}, le modèle gérant cela tout seul.	Gestion automatique de nocat	Si on a un cas particulier où on a besoin d’utiliser nocat, ou au contraire où on doit forcer la catégorisation, dans une section arbitraire, on ne peut plus ; code Lua plus complexe.

En attendant de trancher cette question, le modèle {{C}} ne gère pas encore les catégories ajoutées automatiquement par les précisions de sens ; ce support sera ajouté, le cas échéant, entre la prise de décision et la mise en place effective.

Processus de migration

JackPotte (d · c · b) a proposé son bot pour faire la migration des domaines.

JackPotte, cette section est plus de votre ressort, je pense. A priori et naïvement — vu que je ne connais pas assez l’arborescence des modèles de précision de sens —, je verrai la migration faite comme suit :

1. implémentation des décisions prises pour les paramètres spéc et nocat, et implémentation de la prise en charge des catégories ; si DarkDadaah ne peut s’en charger, je pense en être capable ;
2. préparation de la liste des modèles que le robot doit considérer comme à remplacer. Pour simplifier l’établissement de cette liste, le mieux serait de n’y placer que les modèles racine, c’est-à-dire les modèles comme {{région}} et {{term}}, qui ne sont utilisés ou hérités que pour des précisions de sens. L’avantage de procéder par héritage plutôt qu’avec une liste exhaustive est que le travail sera moindre pour l’établissement d’une liste de modèle hérités que d’une liste exhaustive, car il n’y aura pas de parcours de tous les modèles existants pour déterminer ceux qui sont éligibles à un remplacement par {{C}}. Je pars ici du principe que le bot est capable de vérifier l’héritage d’un modèle pour savoir si ce modèle se contente d’en appeler un autre ; s’il ne le peut pas simplement, on reviendrait à une liste exhaustive ;
3. création d’une liste Lua vide, ici nommée {{contexte/autodata}}, appelée en plus de {{contexte/data}} par le module {{contexte}} pour ses précisions de sens prises en charge. {{contexte/autodata}} se verrait ajouter par le robot, lors de la migration, les précisions de sens qu’il rencontre et qui ne sont pas encore gérées dans {{contexte/data}} : si le robot rencontre un modèle présent dans la liste du point 2., mais qui n’est pas dans {{contexte/data}}, il ajoute automatiquement à {{contexte/autodata}} un élément qu’il génère, puis continue la migration en utilisant cet élément comme s’il appartenait à {{contexte/data}}. À la fin de la migration, il faudra examiner {{contexte/autodata}} pour la fusionner, le cas échéant après correction, avec {{contexte/data}}, puis supprimer {{contexte/autodata}} et en retirer l’appel dans {{contexte}} ; je peux prendre part à cette fusion ;
4. programmer le robot pour faire la migration ; il devra fusionner et remplacer les précisions de sens qui se suivent, éventuellement séparées par un espace, une ponctuation, le mot et… par un unique appel à {{C}}, éventuellement avec spéc ou nocat selon la situation et le résultat des discussions et du vote ;
5. faire le remplacement en masse ; ne serait-t-il pas pertinent de geler les modifications du Wiktionnaire pendant la migration pour éviter toute interférence de contributions anarchiques avec le fonctionnement du robot ?
6. remercier votre bot et vous-même pour ce travail .

Discussions

Utilisez la page de discussion Cette section a été conservée par erreur. Pour discuter de la proposition, rendez-vous sur sa page de discussion. N’éditez pas la présente page tant que la discussion n’est pas terminée. Les commentaires ajoutés précédemment dans cette section ont été déplacés sur la page de discussion.