Discussion Projet:Modèle/Maintenance de l'insertion des modèles

Utilité de cette page de maintenance

 Ideawipik : Puisque tu me demandes mon avis], le voici :

• Sur le principe : je ne peux qu'être favorable à cette initiative. J'ai travaillé sur tant de projets de maintenance que j'ai développé dans AWB des centaines de règles qui s'appliquent sur toutes les pages sur lesquelles j'interviens. J'effectue ainsi en un seul edit des modifications à la fois importantes, souhaitables ou cosmétiques. J'ai dans ma to-do-list le souhait de partager ces modifications qui pourraient en inspirer d'autres. Pourquoi pas sur cette page d'ailleurs ?
• Dans la pratique : le cumul de toutes ces règles AWB fait que parfois il y a des effets de bord qui m'obligent à vérifier visuellement toutes les modifications. Je pense que même avec une vraie programmation ce serait impossible d'automatiser cela. Donc pas de bot, uniquement du semi-automatique. C'est d'ailleurs pour cela que les dresseurs ne font généralement que ce qui leur est demandé dans la requête.

Pour ce qui est de lister des modèles à inclure dans cette page, la tâche est monstrueuse vu le nombre d'erreurs signalées dans les Statistiques sur les modèles. Pour les utiliser quotidiennement, je confirme qu'il y a une vraie analyse à faire à chaque fois. Se contenter de supprimer les paramètres en rouges n'est généralement pas la bonne méthode.

Voilà, je ne cherche pas à te décourager, surtout qu'à mes débuts j'étais persuadé que tous les dresseurs agissaient comme tu le souhaites. C'est juste que dans la pratique, il est difficile de cumuler plusieurs maintenances.

--FDo64 (discuter) 11 septembre 2019 à 19:05 (CEST)

Merci.  FDo64 « Se contenter de supprimer les paramètres en rouge n'est généralement pas la bonne méthode.»

C'est bien ce que je pense aussi et c'est pourquoi, les algorithmes de corrections doivent être les plus complets possibles. Je sais aussi qu'un bot ne peux pas tout corriger. Tu peux le voir sur le premier algorithme sur les dates. Certains cas prévus mais en dehors du cadre des corrections envisagés, sont signalés comme des erreurs et listés dans un fichier, pour y réaliser une correction manuelle ultérieure (cas signalées en rouge). Se servir de Statistiques sur les modèles ou d'un scan (en lecture seule) d'un bot sur un dépôt/dump pour identifier les principaux cas. Puis corriger manuellement les cas vraiment farfelus, avant de valider les corrections possibles et l'algorithme.

Tu parles de risques d'effet de bord. Dans certains cas, dans lesquels travaille uniquement sur les paramètres de modèles, il n'y a aucun risque si l'algorithme est bien réfléchi en mode automatique

Après il faut distinguer :

• les cas où un paramètre est renommé et le nom initial ne reviendra pas (à partir du moment où la doc est à jour). Là un passage unique de bot est possible
• le cas des modèles très utilisés où une erreur de coquille est possible. La maintenance proposée ici a davantage d'intérêt.

Avantages et inconvénients :

• Avantage de cette liste : utilisation plus raisonnable des robots, en limitant les interventions qui allongent les historiques des articles.
• Limites : il faut maintenir la liste, algorithmes et code des bots, en cas de modification des modèles.

Dans le programme, on peut créer un "module"/fonction/filtre (mot module pas au sens de wikipédia) par modèle avec possibilité de choisir son état (actif ou inactif).

Pour l'instant, les scripts que j'utilise et basés sur Pywikibot incluent l'essentiel de cette liste de redirections de modèles, le renommage de certains paramètres de modèles bibliographiques traduits depuis l'anglais.

Je ne ferai pas passer mon bot uniquement pour cela mais seulement en complément de modifs plus conséquentes : requêtes aux bots ou erreurs manifestes, avec des conséquences visibles.

Je peux aussi, selon les cas et pour des cas plus complexes, faire des actions semi-automatiques avec validation du diff et possibilité de refuser la modification ou d'éditer le wikicode au moyen d'un éditeur local avant enregistrement.

J'aimerais bien avoir des avis de membres du  Projet:Modèle sur l'utilité d'une telle page de maintenance. Merci d'avance.

Cordialement. --Ideawipik (discuter) 11 septembre 2019 à 20:16 (CEST)

 Ideawipik : J'ai oublié de te dire que je trouve ton algorithme pour le modèle {{date}} excellent !

Je me permets d'illustrer les effets de bords dont je parle et que je vis au quotidien : lorsque tu as un modèle inclus dans un autre modèle, également inclus dans un autre modèle (par exemple, le modèle date inclus dans une Infobox sur laquelle tu interviens également), tu n'as pas toujours le résultat que tu souhaiterais.

--FDo64 (discuter) 11 septembre 2019 à 22:27 (CEST)

 FDo64 : Merci pour la précision qui me permet de mieux comprendre ce dont tu parles. On peut résoudre ces cas avec de bons regex. J'ai commencé comme cela en travaillant sur un modèle particulier en supposant qu'il n'y avait pas plus de trois niveaux d'imbrications, ni d'accolades dans commentaires. Cela marche dans la majorité des cas mais il faut quand même un contrôle visuel. Par exemple:r"({{Feff début(({{(({{[^}{]*}})|[^}{])*}})|[^}{])*}})([\s]*)((())*-->)|[^}{<]|(<(?!\!--)))*)([\s]*)({{Feff joueur(({{[^}{]*}})|[^}{])*}})" . Mais depuis, j'utilise le parser "mwparserfromhell" développé en python. C'est du bonheur. En l'occurrence pour ta question de modèle date inclus dans un autre modèle, il faut juste ajouter ce cas de figure aux valeurs possibles (ou valides) avec ou non correction nécessaire. Au pire, si on n'a pas pensé à un cas, il apparaîtra dans la liste d'articles (ou tableau de résultats d'analyse) à traiter manuellement.

En ce qui concerne le modèle date, il est assez particulier car paramètres non nommés et surtout deux syntaxes possibles pour un même rendu. Mais c'est encore jouable et codé. Si tu veux faire la même chose avec {{Date de décès}}, je prendrai ton algorithme et je le coderai. Promis! Mais attention, c'est beaucoup plus complexe. --Ideawipik (discuter) 11 septembre 2019 à 23:24 (CEST)