Discussion Projet:Correction syntaxique

Une page de Wikipédia, l'encyclopédie libre.
Sauter à la navigation Sauter à la recherche

2008 • 2009 ( 1er2e3e4e)
20102011201220132014
20152016201720182019
2020

(en) WikiProject Check Wikipedia

Avis sur des erreurs détectées sur Projet:Liens rouges/Lien avec un titre mal formé[modifier le code]

Est-ce que certaines erreurs listées par titre avec parenthèse mal formé peuvent être pris en charge par le Projet:Correction syntaxique

  • par exemple : espaces après une parenthèse d'ouverture et ceux avant une parenthèse de fermeture : Titre ( suffixe… ; …suffixe ) ? Avec quelques exception : ( - et - ) ; ( . et . ) ; ( , et , ) + parenthèse vide ( ) ; de ) et ( de.
  • parenthèse mal ouverte ou mal fermée, ou parenthèse de fermeture mis dans un lien alors qu'elle devrait être à l'extérieur ou à l’intérieur.
  • voir d'autres cas dans la liste "divers". --ParaBenT (discuter) 14 février 2019 à 13:29 (CET)

Retours d'expérience sur WPCleaner et plus généralement la correction syntaxique.[modifier le code]

Bonsoir, Notification NicoV, Antimuonium, Ange Gabriel, Arcyon37, Cascade65, Clumsy and stupid, Dartyytrad bot, Denvis1, Devil.town, Dpegz, Friday83260, Giorgio69, Jarfe, Jean 5 5 et Keckel :, Notification Leag, LeFit, LilKil, Litlok, Lomita, Ltrlg, Msbbb, Mattho69, Myloufa, Rehtse, Romanc19s, Speculos, Tearow, Tomo8 5, ‎Vlaam et YanikB : Je notifie des contributeurs réguliers au projet CS, en particulier, utilisateurs de WPCleaner, mais la discussion est bien sûr ouverte à toutes les bonnes volontés concernées.
Voici un brouillon de page concernant des retours sur expériences relatifs au projet, dans le but de le rendre plus efficace et moins abscons. Désolé, ce n'est pas bien concis. Cela vous semble-t-il utile? Si oui, merci pour vos contributions et commentaires sur la page en question. A bientôt Aidewikip (discuter) 5 mai 2019 à 23:52 (CEST)

Bonjour, J'aime bien la page que vous avez écrite, elle permet de bien comprendre WPC. C'est d'ailleurs un outil que j'aime bien utiliser pour certaines tâches comme faire une liste d'article selon une erreur commune que je désire corriger, souvent un lien vers un article qui se trouve dans plusieurs articles. L'enchaînement se fait plus rapidement que si je le faisais directement dans Wikipédia. J'apprends que je suis dans les utilisateurs les plus réguliers de l'outil, intéressant! --Myloufa Discuter ou faire Appel? 6 mai 2019 à 00:03 (CEST)
Bonjour Aidewikip. Merci pour cette page, ça pourrait être pratique pour des utilisateurs de WPC Sourire. En tout cas, je suis toujours content de trouver de la documentation écrite par des utilisateurs plutôt que par moi, ça permet justement d'apporter une vision utilisateur. Je m’abstiendrais donc de faire des modifications sur la page, mais juste quelques suggestions :
  • Sur les corrections orthographiques proposées qui sont des non-sens : peut-être indiquer (en note ?) que toutes les corrections sont définies par des contributeurs dans les pages Wikipédia:Liste de fautes d'orthographe courantes et Wikipédia:AutoWikiBrowser/Typos. Si certaines donnent trop d'erreurs, il est possible de les modifier ou de les désactiver.
  • Niveaux de titre : il y a un éditeur de table des matières dans WPCleaner qui permet de voir et de modifier la hiérarchie des titres en comparant l'état actuel et l'état initial. Ca peut aider pour éviter les mauvaises modifications du plan.
  • Références identiques mais non détectées : si tu as des exemples (même si j’ai des idées), je peux toujours regarder.
--NicoV (discuter) 6 mai 2019 à 19:35 (CEST)
Bonjour Aidewikip. Merci pour cette page, elle nous permettra de nous harmoniser et de profiter d'autres expériences et points de vue (je me suis reconnu dans l'utilisation maladroite du modèle Lien :)
J'essaierai de l'enrichir au fil de l'eau, notamment pour certains Liens internes avec deux barres verticales et Éléments de programmation de modèles qui m'en ont fait suer… --Tom (discuter) 7 mai 2019 à 20:51 (CEST)
Bonjour,
Notification Myloufa : J'ai "notifié" une liste non-exhaustive d'utilisateurs récents ou réguliers (pas forcément les plus réguliers).
Notification NicoV : Merci pour ton retour. Comme tu as pu le comprendre, les quelques non-sens qui sont introduits dans les articles proviennent d'une précipitation de l'utilisateur et non des propositions judicieuses issues des listes. Je vais rajouter le liens vers les listes, cela permettant de mieux comprendre ce qui se cache derrière les suggestions de correction et de magnifier le caractère vivant et humain du projet Correction Syntaxique. (J'en profite pour rappeler une petite correction à faire dans les propositions pour les siècles, WPC propose bien {{s|XX}} dans le cas où un lien interne est souhaité mais sans lien, il propose {{s-|XX|e}} (ancienne utilisation du modèle) au lieu de {{s-|XX}}.)
Quant à la question des titres de section , elle permet de souligner le risque général pour l'utilisateur de se contenter de regarder et de corriger seulement ce qui apparait en rouge, comportement particulièrement scabreux dans ce cas précis où seule la ligne de titre concernée sera modifiée. Proposition: ajouter une mise en garde dans le résumé de l'erreur en haut invitant à regarder l'intégralité du plan de l'article. Et éventuellement, si possible, que l'éditeur de table des matières dans WPCleaner s'ouvre automatiquement quand on arrive sur une erreur de ce type.
En ce qui concerne les références identiques, ce qui est entre les balises <ref> n'est pas exactement la même chose mais très proche (exemple: réf 1 et 11 de cette page où seule diffère la mise en italique). On n'est plus dans du regex très simple et la comparaison devrait s'orienter vers une IA plus avancée, d'où la nécessité de besoins en compétences et en temps. L'utilisation généralisée des modèles du type {{Lien web}}, {{Ouvrage}} et consors, pourrait permettre une détection plus aisée, avec des paramètres identifiés.

- La prévisualisation est aussi bien utile (J'ai découvert assez récemment l'aperçu Cobra car avec mon affichage, "Développer les modèles et aperçu" donnent de prime abord le même rendu que "Développer les modèles", avec le code HTML. Mais si je déplace la fenètre et qu'elle se redimensionne à mon écran, les 3 zones apparaissent bien).
- Une incompréhension des éditions de la Correction syntaxique par la communauté peut aussi venir du déclenchement de filtres anti-erreur lors d'une édition avec WPCleaner. Et l'édition peut sembler apporter une nouvelle erreur. Par exemple un copier-coller peut de façon invisible pour l'utilisateur et complètement transparente pour l'interprétation du code et le rendu final de l'article, modifier le type d'espace (normal, insécable, fine insécable. (lire par exemple cette discussion suivie de cette explication sur les espaces insécables et les guillemets). Y aurait-il utilité et moyen, dans le cas des corrections validées manuellement par l'utilisateur, de faire passer ses filtres lors de la validation (ou de l'envoi).
- Une autre option, pourrait être de pouvoir obtenir les messages d'avertissement qui s'affichent en rouge en cas de problème, lors d'une prévisualisation avec l'éditeur visuel.
- Une fonctionnalité "Rechercher (suivant) et remplacer" dans WPC serait pratique et permettrait à certains utilisateurs d'éviter le copier-coller dans un autre éditeur (supprimant le signalement anti-erreur 227).
- En ce qui concerne l'accès à la page rédigée, faut-il la laisser dans l'espace utilisateur ou la déplacer dans une sous-page du projet ? Pour tous, je ne peux qu'inviter les contributeurs du projet à compléter les pages d'aide concernant les erreurs (inutile d'avoir à réinventer la roue). Souvent, en faisant acte de pédagogie et en essayant de faire preuve de clarté, on apprend beaucoup pour sa propre pratique.
Notification Tomo8 5 : merci d'avance pour tes contributions à l'aide. Dans l'exemple que tu as ajouté et relatif à la deuxième division du championnat de foot espagnol, j'aurais tendance à simplifier en Liga 2 tout simplement car la notation La Liga 1|2|3 relève plutôt du logo que de la dénomination réelle, est moins claire pour le quidam et est moins conforme aux conventions des projets de sport. (et encore moins quand tout est écrit à la même taille comme sur ces exemples). Question d'accessibilité. (et techniquement, vérifier que cela ne déclenche pas l'erreur 11 « HTML pour des caractères particuliers » ou l'erreur 27 « HTML numérique pour des caractères »)
Notification LeFit : Bonjour, j'imagine que le partage de ton/votre expérience pourrait être profitable, si c'est possible bien sûr.
(Aidewikip (discuter) 8 mai 2019 à 17:01 (CEST)).
Bonjour Aidewikip Bonjour, je n'ai pas assez d'expérience pour participer à la conversation, mais je la suis. Formule cordiale, --Msbbb (discuter) 29 mai 2019 à 07:41 (CEST)

Nouvelle liste de maintenance : maintenance des paramètres contenant un signe égal dans le modèle Lien[modifier le code]

Il me semble que ce suejt est en lien avec le projet ?
La liste de maintenance du modèle {{lien}} : Projet:Liens rouges/Paramètre contenant un signe égal dans le modèle Lien détecte les appels au modèle présentant un paramètre contenant un signe égal.
Un paramètre contenant le signe égal peut être le signe d'une erreur de syntaxe qui peut conduire à un lien erroné ou empêcher la conversion (par bot) du modèle Lien en lien interne classique si l'article en français a été crée.
Pour ceux qui savent manipuler des outils de maintenance de traitement en série, ici, une piste d'action autour de l’ajout de « | » ou la suppression de paramètre en double. --ParaBenT (discuter) 13 octobre 2019 à 12:30 (CEST)

De façon générale le modèle {{lien}} peut contenir plusieurs types d'erreur syntaxique. Il nécessite un travail de maintenance à partir de plusieurs listes (Projet:Liens rouges).
Voir discussion en cours Discussion modèle:Lien/Conversion automatique. --ParaBenT (discuter) 2 novembre 2019 à 07:54 (CET)

Requête traitée Erreur div-span-flip, et autres questions[modifier le code]

Bonjour, je me promène dans les erreurs de Lint depuis plusieurs mois ; je m’y pose plusieurs questions.

  • Que veut dire div-span-flip, erreur listé dans les Problèmes divers classés priorité haute ?

D’après mon expérience (et la traduction de flip en Français), elle est causée par des balises de types div ou span (au sens large) incluse l’une dans l’autre, au lieu de l’autre dans l’une. Mais je n’ai touvé nul part mention d’un ordre particulier, sauf des conseils sur l’inclusion ou non dans un lien interne.
Ce qui m’amène à d’autres questions :

  • [[ | ]], '', ''', <small>, <poem>, <ref>, etc. sont-elles span ou div ? Quelle est la différence ?
  • Pourquoi Aide:Signature#Balises demande l’inclusion de <span style> dans les crochets, alors qu’une autre page (que je retrouve pas) et mon expérience conseillent de sortir les balises span des crochets ?
  • Quels sont les inclusions obligatoires, conseillées ?
  • Y a-t-il des problèmes causés par l’inclusion de <br> dans certaines balises ?
  • Y a-t-il une page répertoriant – ou même expliquant – les différents types de balises, les différentes utilisations possibles de span, les différentes options de span style, etc. ?

La seule chose que je sais vraiment est qu’il faut sortir <poem> de {{nobr}}. Mais il y a d’autres modèles conflictuels.

Sernin SC (discussion) 16 mai 2020 à 20:06 (CEST)

Bonjour Sernin SC. Premier élément de réponse : ce que j’ai compris est qu'une balise div est un élement de bloc, une balise span un élement inline (cf. en:Span and div), et qu'il est déconseillé d'avoir un élément de bloc dans un élément inline, ce qui semble logique. --NicoV (discuter) 17 mai 2020 à 11:53 (CEST)
La page https://developer.mozilla.org/fr/docs/Web/HTML/%C3%89l%C3%A9ments_en_bloc donne une liste d'éléments en bloc. C'est un concept HTML, donc pour ce qui est spécifique à la syntaxe MediaWiki, il faut voir quel éléments HTML sont présents dans le rendu de la page. Parmi ceux mentionnés :
  • Éléments en ligne : [[ | ]] (donne <a> dans le rendu), '' (donne <i>), ''' (donne <b>), <small> (reste <small>), <ref> (donne <sup>), <br> (reste <br>)
  • Élément en bloc : <poem> (donne <div class="poem">)
  • Ce que suggère Aide:Signature#Balises n'est pas lié à cette contrainte. Mettre la balise span à l'extérieur d'un lien est correct et souhaitable dans la plupart des cas, car l'inverse oblige à séparer la cible du texte (<span ...>[[Exemple]]</span> ou [[Exemple|<span ...>Exemple</span>]] marchent, mais pas [[<span ...>Exemple</span>]]). Par contre, le changement de couleur doit être à l'intérieur du lien parce que les liens ont déjà une couleur spécifique (le bleu) et que seule une indication de couleur présente à l'intérieur du lien peut la changer. Comme ce comportement était différent par le passé dans MediaWiki, une détection spécifique a été créée.
Orlodrim (discuter) 17 mai 2020 à 14:45 (CEST)
Merci pour vos deux réponses : j’en suis rassasié pour l’instant, et j’ai des pistes si j’ai à nouveau faim. — Sernin SC (discussion) 19 mai 2020 à 10:28 (CEST)
Salut Sernin SC. Pour info, j’ai corrigé quelques-uns des modèles qui posaient problème, il en reste encore une dizaine on dirait. --NicoV (discuter) 25 mai 2020 à 13:46 (CEST)
Merci NicoV.
Pour le modèle:Évolution du vivant, que je suivais depuis plusieurs semaines, ta modification n’a pas suffit. Alors j’ai brutement recherché et remplacé tout div par span, et ce n’est maintenant plus listé dans la liste des erreurs.
Je note quand même que le rendu graphique est légèrement différent. — Sernin SC (discussion) 28 mai 2020 à 09:06 (CEST)
Comme les retours à la ligne des span en valaient deux, j’ai annulé ma modification, et ai plutôt remplacé des spans par des divs dans Modèle:Scalemarkers et Modèle:Timeline Note, qui sont inclus dans Modèle:Graphical timeline , lui-même inclus dans plusieurs frises causant div-span-flip. Je pense que le problème est résolu de ce côté. — Sernin SC (discussion) 28 mai 2020 à 12:06 (CEST)

┌─────────────────────────────────────────────────┘
Cool Sernin SC, ça va faire un peu de ménage. Je vois qu’il reste beaucoup de cas liés à l'utilisation de {{Langue}} ou {{Nobr}} encadrant des div (comme poem) : je me demande si il ne faudrait pas faire des modèles équivalents (ou un paramètre supplémentaire aux modèles existants) pour que le rendu soit dans un div et pas dans un span (un peu comme {{Citation}} et {{Citation bloc}}). Orlodrim, une idée ? --NicoV (discuter) 28 mai 2020 à 12:56 (CEST)

Pour poem, on pourrait faire passer un robot : j’ai fait plusieures corrections comme icelle à l’aide d’un petit programme personnel. — Sernin SC (discussion) 28 mai 2020 à 13:37 (CEST)
Sernin SC, le problème avec ce type de modification, c'est qu'il ne corrige pas le problème en entier, et que la page est détectée en erreur dans Spécial:LintErrors/html5-misnesting, justement pour le {{nobr}} dans poem. Une balise span ne devrait pas englober un texte sur plusieurs lignes. --NicoV (discuter) 28 mai 2020 à 14:09 (CEST)
Rectification, c'était à cause des balises center dans le nobr, j'ai fait une modification complémentaire. --NicoV (discuter) 28 mai 2020 à 14:12 (CEST)
Bonsoir NicoV Bonsoir. J'ai pas tout suivi dans cette conversation, je me contente donc de constater qu'il y a 57 pages qui ont une balise <poem> dans un {{nobr}} (simple recherche de insource:/nobr *\| *\<poem/). Est-il utile de les corriger ? --FDo64 (discuter) 3 juin 2020 à 21:53 (CEST)
Bonjour FDo64. Oui, a priori, c'est utile. Le cas que j'indiquais est quand il y a en plus des balises de type div (center par exemple) dans poem, qui demande un peu plus d'attention pour corriger complètement. --NicoV (discuter) 4 juin 2020 à 08:35 (CEST)

Requête traitée Lien interne circulaire directement ou via une redirection, beaucoup de cas.[modifier le code]

Bonjour. Une analyse du dernier dump (20 mai, discussions et les pages utilisateur exclues) trouve :

  1. des liens internes directs vers le titre de la page sur 6 600 pages hors espace de nom Wikipédia (13 500 ce dernier inclus). La liste peut-être mise à disposition sur demande. Il s'agit :
    • soit d'un lien [[T(t)itre de page|texte]] qui affiche le texte en gras. Cette erreur est normalement déjà détectée via la correction syntaxique no 48 et corrigée par WPCleaner.
    • soit d'un lien ancré [[T(t)itre de page#ancre|texte]] qui pourrait être simplifié en [[#ancre|texte]]. Éditer des articles uniquement pour faire ces modifications cosmétiques n'est pas utile mais ces corrections ou des suggestions pourraient être ajoutées à nos outils, comme WPCleaner. Attention toutefois, certains de ces liens ne doivent pas être corrigés, notamment pour les pages ayant vocation à être incluses dans d'autres, à l'image de modèles.
  2. des liens internes bleus vers une redirection qui pointe vers l'article concerné (lien circulaire). Ces liens ne servent aucunement au lecteur. La page Projet:Correction syntaxique/Lien vers une redirection ramenant sur l'article initial a été actualisée avec un tableau, la mise à jour antérieure datant de dix ans. Est-ce que cela peut-être utile ? Faut-il en faire quelque chose?

--Ideawipik (discuter) 30 mai 2020 à 14:05 (CEST)

Bonjour Ideawipik. Mon avis :
  • Premier cas : déjà détecté, il suffit de s'atteler à la correction
  • Deuxième cas : si ce n’est pas déjà le cas, possibilité d'ajouter cette détection des WPC (+ correction automatique)
  • Troisième cas : pour moi, ces liens peuvent être utiles dans 2 cas, soit quand la redirection comporte une ancre, soit quand la redirection pourrait être remplacée par un article (et qu'en l’absence de cet article, elle renvoie vers quelque chose de proche).
--NicoV (discuter) 30 mai 2020 à 14:56 (CEST)
Merci NicoV pour la réponse.
  • Premier cas : il y a très peu de tels cas dans les articles (une trentaine sur Check Wikipedia) et ton bot WikiCleanerBot est efficace pour les corriger régulièrement. Hors articles, la majorité des occurrences se trouve sur les pages Wikipédia:Bistro/jour, créées à partir de Wikipédia:Le Bistro/préchargement (dans le calendrier inséré à droite. Mais comme il me semble que ces pages ont vocation à être insérées dans d'autres pages, j'aurais tendance à dire qu'il faut les laisser ainsi. Et puis cela n'est pas essentiel dans un espace pas vraiment encyclopédique
  • Deuxième cas : En ce qui concerne les articles, c'est ce cas qui alimente la liste comptabilisée plus haut. Super si WPCleaner peut intégrer cette correction dorénavant, à l'image de la précédente Bravo !. La syntaxe courte est plus intéressante que la syntaxe longue (avec le nom de la page), cette dernière générant des « troisième cas » lors de renommage de la page.
  • Troisième cas : Tes deux objections rejoignent mes remarques en début de liste, peut-être mal formulées (cf colonne « Lien ancré ? »). Sur le principe général, je trouve dommage de décevoir un lecteur qui pense tomber sur un article en cliquant sur un lien. Et souvent les liens sont complètement inutiles quand il s'agit de synonymes ou bien de variantes orthographiques, de pluriels, de gentilés... Exemples : Éco‐quartier dans Écoquartier ; Danser dans Danse ; Carolingienne dans Carolingiens, etc.
En résumé, une modification n'est pas évidente ou pertinente, voire est problématique :
  • si la redirection a vocation à devenir un article propre ;
  • si la page en question est insérée dans d'autres pages (surtout si elle l'est soit partiellement, avec des <noinclude>, <includeonly> ou <onlyinclude>, soit dans une page qui aurait plusieurs ancres identiques) ;
  • si la redirection est ancrée.
En revanche le cas suivant devrait pouvoir être corrigé de façon automatisée, si les conditions sont réunies :
  • dans l'article AAA : [[BBB#AncreA|Texte]],
  • la page BBB est une redirection non ancrée vers AAA,
  • l'ancre ou la section AncreA existe dans AAA.
⇒ Correction dans AAA [[#AncreA|Texte]] comme pour le deuxième cas.
Cdlt. --Ideawipik (discuter) 30 mai 2020 à 16:42 (CEST)
Pour le deuxième, est-ce que tu aurais quelques exemples Ideawipik ? Histoire que je vérifie le comportement de WPC, et que je complète si besoin. --NicoV (discuter) 30 mai 2020 à 21:45 (CEST)
Notification NicoV : Exemples du deuxième cas:
  • [[Arsène Lupin#La dalle des rois de Bohême|énigme de la dalle des rois de Bohême]] : énigme de la dalle des rois de Bohême
  • [[France Télécom#Plan NExT|Plan NExT]]
  • dans l'infobox [[Fidji#Gentilé|Fidjien]]
  • dans un article récent [[Mariage de la princesse Eugenie et de Jack Brooksbank#Liste des invités|Liste des invités]].
Cela ne changerait pas le comportement final mais je me demande s'il ne faudrait pas tester l'existence de l'ancre dans la page avant de faire cette modification, car remplacer par bot un lien ancré brisé par un autre n'est pas très pertinent. Je n'ai pas d'exemple sous la main. Pour cette détection, je n'ai stocké que les titres des articles concernés. En voici une vingtaine.
Remarques générales mais tu en as l'habitude : exclure le texte en nowiki (exemple). Ne traiter que l'espace des articles, pas les modèles, ni les espaces projet/portails, pour des raisons d'inclusions. --Ideawipik (discuter) 30 mai 2020 à 23:23 (CEST)
Bonjour Ideawipik. J'ai complété les détections dans #48 pour les liens avec ancre. Pour l'instant, il y a détection et suggestion de remplacement, mais pas encore de remplacement automatique (je verrais pour le faire quand la liste aura été mise à jour avec le nouveau dump, ce qui incluera ces liens). Quelques exemples de modifications : Arsène Lupin, Algèbre de Boole (logique), Akira Kurosawa, Amon, Astéroïde, Blender, Bruxelles. --NicoV (discuter) 3 juin 2020 à 17:21 (CEST)
Bonjour NicoV. Nickel, comme d'habitude. Au vu des premiers cas rencontrés, je craignais de voir dans la future liste de détection de nombreux liens [[Titre#cite note-n|texte]] avec n un numéro correspondant au numéro d'une ancienne référence devenue obsolète. Mais en fait, il n'y en aura pas tant que cela puisque insource:/\#cite note-/ ne retourne qu'un gros demi-millier de résultats. Quand le lien renvoie sur la propre page, ces cas devraient souvent être remplacés par de simples balises <ref> nommées. Mais difficile parfois de faire le lien avec la bonne ref/source externe, source initiale qui a pu être retirée de l'article.
Merci aussi pour la question des balises vides. --Ideawipik (discuter) 4 juin 2020 à 12:29 (CEST)
Bonjour Ideawipik. Projet:Correction syntaxique/Analyse 048 a été mis à jour. A voir si il y a des faux positifs, et ce qui peut être fait en termes de correction automatique. --NicoV (discuter) 7 juin 2020 à 09:18 (CEST)
Bonjour NicoV. Rapide coup d’œil. pas de faux positifs. Vu passer le bot. Pas nécessaire de traiter les « id="cite_ref-… » car souvent la correction devrait être autre. --Ideawipik (discuter) 7 juin 2020 à 21:43 (CEST)
Bonjour Ideawipik. La liste a été mise à jour après avoir fait passé les corrections automatiques, Projet:Correction syntaxique/Analyse 048. Il reste environ 300 pages, à corriger manuellement… --NicoV (discuter) 12 juin 2020 à 16:45 (CEST)

Balise sans contenu[modifier le code]

Bonjour. Faudrait-il ajouter les espaces en HTML dans la détection de l'« erreur 85 : Balise sans contenu » ? Par exemple &#x20; n'est pas signalé par WPCleaner. Exemple corrigé. Il existe une liste blanche pour cette erreur. --Ideawipik (discuter) 1 juin 2020 à 16:57 (CEST)

Bonjour Ideawipik, j'ai ajouté ce cas dans les détections de WPCleaner pour #85. J'ai aussi prévu de remplir la page Projet:Correction syntaxique/Analyse 085 pour le prochain dump. --NicoV (discuter) 3 juin 2020 à 17:36 (CEST)
Bonjour Ideawipik, la liste est générée. Reste à voir si il y a des faux positifs dedans, et ce que WPCleaner arrive déjà à corriger automatiquement ou ce qui pourrait être amélioré. --NicoV (discuter) 7 juin 2020 à 09:17 (CEST)
Bonjour NicoV et merci pour la liste. Les [NBSP] correspondent bien à des &nbsp;. Il y a plusieurs faux positifs dont des balises qui contiennent une autre balise de type code ou pre ou nowiki ou score. Exemples:
  • <center><code>M. FOLV[IO(S) Q. F. COS]OL D(EDET) VOLS[INIO] CAP[TO]</code></center> dans Aire de Sant'Omobono
  • Bataille de Jersey: <sup><nowiki>[5] : 124 [8]</nowiki></sup>
  • CP System: <sup><nowiki>[Dash]</nowiki></sup>, <sup><nowiki>[Dash]</nowiki></sup>
  • Carré magique (lettres): <center>↵<pre>↵L E S L O I S C U L T E P A C T I S E N T P R E C A I R E S↵E T E O V N I U N I E S A C H E M I N E R R E D O N N E N T↵S E C I N C A L I O N S C H A R M E R A I E D E N T A S S E↵ S I A L T E N T A T E R R I G E N E C O N C I L I E R↵ E S S A I I M M I N E N T S A N T I S I G M A↵ S I E G E R A I T I N A L I E N E S↵ E N R E N A S S E R E S I G N O N S↵ N E A N T I S E R E N S E M E N C E↵ T R I E S T E R S S T E R A S S E S↵</pre>↵</center>, <center>↵<pre>↵B I T C A R D H E A R T G A R T E R B R A V A D O L A T E R A L S↵I C E A R E A E M B E R A V E R S E R E N A M E D A X O N E M A L↵T E N R E A R A B U S E R E C I T E A N A L O G Y T O E P L A T E↵ D A R T R E S I N T R I B A L V A L U E R S E N P L A N E D↵ T R E N D E S T A T E A M O E B A S R E L A N D E D↵ R E E L E D D E G R A D E A M A N D I N E↵ O D Y S S E Y L A T E E N E R↵ S L E D D E R S↵</pre>↵</center>
  • Chlorure de manganèse(II): <sup><nowiki>&minus;</nowiki></sup>, <sup><nowiki>&minus;</nowiki></sup>, <sup><nowiki>&minus;</nowiki></sup>
  • Clef (musique): <center><score raw="1">↵\header {↵ piece = "Tessiture de la guitare classique"↵ tagline = ##f↵}↵↵\score {↵ \relative c, {↵ \clef "treble_8"↵ \time 2/1↵↵ e1\glissando b''''↵ \bar "||"↵ }↵ \layout {↵ \context {↵ \Staff↵ \remove "Time_signature_engraver"↵ }↵ }↵ \midi {}↵}↵</score></center>
  • Collégiale Notre-Dame de Lamballe: <center><nowiki>Charles de Blois</nowiki></center>, <center><nowiki>Inscription mentionnant la date de 1514 sur le contrefort nord-ouest</nowiki></center>, <center><nowiki>Transept nord et clocher-tour</nowiki></center>, <center><nowiki>Sacristie</nowiki></center>
  • Vérification de modèles: <sup><nowiki>|φ|</nowiki></sup>, <sup><nowiki>|φ|</nowiki></sup>

Possibilité d'un traitement automatisé ? Des éléments ne devraient pas être supprimés mais remplacés par des {{Ancre}} quand la balise (souvent un span) contient un paramètre id=… non vide, mais cela n'est pas systématique.
  • Parfois les id servent à la navigation interne par exemple initiales des mots.
  • Parfois à la navigation dans l'encyclopédie (lien placé dans un autre article).
  • Parfois, ils sont des résidus d'éléments copiés ailleurs et pourraient être supprimés, avec la balise.
Les « id="cite_ref- » sont délicats à traiter et devraient souvent intégrer des balises ref
A suivre. --Ideawipik (discuter) 7 juin 2020 à 21:35 (CEST)
Bonsoir Notification Orlodrim et FDo64. Pour le cas des balises vides servant à la navigation dans la page à partir de sommaires alphabétiques, quelle est la meilleure pratique ?
  • quand il n'y a pas de texte, remplacer par une {{ancre}} nommée comme l'id de la balise,
  • quand il y a un texte, par exemple <span id="B"></span>B dans Liste de gares du canton d'Appenzell Rhodes-Extérieures. Une correction <span id="B">B</span> est-elle préférable à {{Ancre|B}}B ? il me semble que oui. Un avis ? Merci.
--Ideawipik (discuter) 10 juin 2020 à 00:15 (CEST)
Notification Ideawipik : {{Ancre}} affiche un marqueur visible dans l'éditeur visuel, tandis que <span> n'affiche rien du tout. Du coup, {{ancre}} me semble un peu mieux pour avoir plus de chances que la balise reste là où elle devrait sur le long terme. Mais ça pourrait aussi être l'inverse : des contributeurs ne comprennent pas pourquoi ils voient {{ancre}} en mode édition et l'enlèvent malencontreusement. Orlodrim (discuter) 13 juin 2020 à 19:53 (CEST)
Bonjour Ideawipik. Je ne suis pas fan de <span id="B">B</span> : pour moi, la balise span id est utilisée pour faire une ancre, c'est-à-dire un endroit dans l’article où pouvoir rediriger, pas pour englober une zone de texte. --NicoV (discuter) 15 juin 2020 à 10:51 (CEST)
OK merci NicoV. C'est précisement dans le but de faire des ancres, en association avec un {{sommaire alphabétique}}, que sont présentes les balises span initialement sans contenu mentionnées ci-dessus. Je n'ai corrigé que les environ vingt-cinq tableaux de la liste de gares en Suisse avec cette syntaxe. Pour les futures modifications et à la lecture de vos deux avis, une utilisation du modèle {{ancre}} me convient tout à fait. Et cela serait même plus simple à automatiser.
En ce qui concerne les faux positifs (voir plus haut), y a-t-il moyen de modifier la détection ? Souvent dans les articles, les balises <nowiki> sont superflues ; les balises <center> peuvent être remplacées par des class ou style CSS ou le modèle {{Centrer}}. Néanmoins, les balises <pre>, <score> et <code> non vides devraient être prise en compte en tant que contenu. --Ideawipik (discuter) 15 juin 2020 à 13:21 (CEST)
Bonjour Ideawipik. Les faux positifs étaient volontaires : avant, ils étaient détectés par CheckWiki, et donc j'étais obligé de les détecter dans WPC (mais ils apparaissent à la fin de la liste en "Warning" et pas en "Error"). Il semblerait que CheckWiki ne fasse plus cette erreur, je peux donc retirer le code spécifique que j’avais fait pour les détecter en Warning. --NicoV (discuter) 15 juin 2020 à 14:37 (CEST)
Bonjour Ideawipik. J'ai automatisé l'utilisation de {{ancre}} et j'ai fait passé mon bot pour corriger ce qu'il pouvait. Il faudra voir ce qu'il reste dans la liste après la prochaine analyse de dump. --NicoV (discuter) 17 juin 2020 à 13:35 (CEST)
Bonjour NicoV et merci pour le travail effectué. Coïncidence, j'ai corrigé aujourd’hui-même cet article contenant, sur la même ligne dans la biblio, un <span> avec id et le modèle {{ancre}} équivalent. Cela m'inspire une autre détection : plusieurs « Ancres identiques dans la page ». --Ideawipik (discuter) 17 juin 2020 à 14:00 (CEST)

┌─────────────────────────────────────────────────┘

Bonjour Ideawipik. La liste a été mise à jour cette nuit. De mon côté, il me reste à exclure les articles qui sont en warning (ceux à la fin de la liste, à partir de Aire de Sant'Omobono), mais les autres sont à corriger manuellement si tu veux t'en charger :
  • les <span id="mw…"> </span> ou les <span title="ctx_ver=Z39.88-2004…" class="Z3988"> </span> sont des bugs de l'outil de traduction de contenu, normalement à supprimer
  • les <span id="cite…"></span> sont à retravailler pour mettre des références
  • les <sup class="noprint Inline-Template " style="white-space:nowrap;"></sup> et quelques autres cas : à voir
--NicoV (discuter) 18 juin 2020 à 12:54 (CEST)

Requête traitée Modèle fermé par }}}[modifier le code]

Bonjour,

En jouant avec le parser de mon bot, j'ai repéré plus de 1000 pages avec des accolades en trop à la fin des modèles, du genre {{en}}}. Est-ce qu'il y a une détection pour ça ? Je suis en train d'en corriger en semi-automatique [1]. J'ai vu quelques exceptions notamment avec les pages utilisant {{math}} et parlant d'ensembles, mais la grande majorité des cas sont des erreurs.

Orlodrim (discuter) 3 juin 2020 à 23:45 (CEST)

Salut Orlodrim. Il n'y a pas de détection pour ça à ma connaissance, mais je dois pouvoir ajouter ça facilement à WPCleaner. --NicoV (discuter) 4 juin 2020 à 12:46 (CEST)
Bonjour Orlodrim et NicoV. Une recherche connexe pourrait être les tableaux suivis de } ie |}} en début de ligne dans un tableau. Remarque : cette dernière ligne seule est une syntaxe potentiellement valide par exemple le else vide d'une « fonction de test » utilisée dans les modèles ou la dernière ligne d'un modèle avec un paramètre vide, de même que }}} peut-être la fermeture d'un paramètre ou une exception comme cela est signalé dans le premier message. Après vérification, dans le cas du tableau seulement, WPCleaner déclenche une erreur #47 « Modèle mal ouvert » ; donc un petit message du type « cette erreur est aussi déclenchée par un tableau fermé avec une accolade en trop » dans le tableau des erreurs pourrait suffire. --Ideawipik (discuter) 4 juin 2020 à 13:39 (CEST)
Bonjour Ideawipik. Je pensais que ça déclenchait aussi une erreur tableau mal fermé (si il y a bien un début de tableau). --NicoV (discuter) 4 juin 2020 à 13:47 (CEST)
Salut NicoV. C'est possible. Peut-être à l'ouverture d'un article concerné ? À vérifier ! En revanche, si on ouvre au hasard un article contenant un tableau bien fermé pour seulement lui ajouter une accolade fermante et si on refait une analyse (bouton Valider), WPCleaner n'annonce en rouge que « Modèle mal ouvert ». --Ideawipik (discuter) 4 juin 2020 à 14:06 (CEST)
Salut Orlodrim. J'ai ajouté la détection #552 dans WPCleaner, la prochaine analyse de dump devrait remplir la page Projet:Correction syntaxique/Analyse 552 (d'ici quelques jours normalement). Je verrais à ce moment là pour ajouter des corrections automatiques. --NicoV (discuter) 4 juin 2020 à 20:19 (CEST)
Génial, c'est rapide :) Orlodrim (discuter) 4 juin 2020 à 21:36 (CEST)
Bonsoir, dans le même genre d'idée, il y a les séries de 4 « [ ». La recherche insource:/\[\[\[\[/ en trouve 115 dans l'espace principal et 985 sur tous les espaces. Par contre la recherche de 4 « ] » donne trop de faux positifs à cause des liens internes dans le fichiers.
--FDo64 (discuter) 5 juin 2020 à 00:09 (CEST)
Bonjour FDo64. En pratique, WPCleaner signale dans les cas que tu proposes des erreurs de « lien interne mal fermé » et « lien interne mal ouvert ». Avec l'analyse mise en place, il ne crée pas de faux positifs, la recherche ne se limitant pas à une simple recherche brute d'un motif dans le wikicode. Sinon, on imagine le nombre de faux positifs qui seraient crées lors des recherches de }}} qui peuvent correspondre à la fermeture au même endroit de deux modèles imbriqués. Bonne journée. --Ideawipik (discuter) 5 juin 2020 à 08:46 (CEST)
Bonjour FDo64. Normalement, comme le dit Ideawipik, c'est détecté par #10 et #46. Par contre, pour ces erreurs, je ne génère pas de listes pour l’analyse de dumps (#10 et #46) car il y a probablement pas mal de faux positifs. Si besoin, je peux ajouter ces listes dans le résultat de l’analyse de dumps, et voir après si il y a besoin de faire du tri dans les faux positifs. --NicoV (discuter) 5 juin 2020 à 10:55 (CEST)
Notification NicoV : Bonsoir, sauf mauvaise compréhension de ma part, ces deux listes ne détectent que les déséquilibres, pas les cas du style [[[[Steidl Verlag|Steidl]]|Steidl]] dans Hermès International (pour info, causé par Codexbot Notification Irønie). Idem pour [[[[Pont du détroit de Tacoma (1940)|Pont du détroit de Tacoma]]]] dans Liste de ponts aux États-Unis depuis 2015.
--FDo64 (discuter) 5 juin 2020 à 21:43 (CEST)
Ok, bug de CodexBot sur 14 articles. Merci du signalement. -- Irønie (discuter) 6 juin 2020 à 08:24 (CEST)
Bonsoir FDo64. Peut-être pour les listes gérées sur wmflabs, mais WPCleaner détecte tous ces cas : il détecte les crochets doubles qui n'ont pas été associés à un lien, une image, une catégorie… par le parseur intégré. Par contre, il peut y avoir des faux positifs. Si tu es intéressé, je peux toujours essayer de générer les listes. --NicoV (discuter) 5 juin 2020 à 22:34 (CEST)
Bonjour FDo64. Projet:Correction syntaxique/Analyse 010 et Projet:Correction syntaxique/Analyse 046 ont été générées. A voir si il y a des faux positifs, et ce qui peut être fait en termes de correction automatique, sachant que WPC traite déjà certains cas du #46. --NicoV (discuter) 7 juin 2020 à 09:22 (CEST)
Merci NicoV Clin d'œil. Pour éviter tout faux espoir, je précise que je n'utilise pas WPCleaner et que ma priorité est la maintenance de l'espace modèle. Donc j'espère que d'autres vont se charger de ces corrections. Sinon je regarderai ça quand j'aurai plus de temps, donc pas de si tôt… --FDo64 (discuter) 7 juin 2020 à 10:21 (CEST)
Bonjour FDo64. Dommage, j’aime bien quand ceux qui proposent des détections s'attellent aussi à la correction Clin d'œil. J'ai ajouté une correction automatique pour certains cas de #10, mais bien souvent, il faudra aussi qu'un humain repasse car il y a d'autres erreurs (#46 en particulier). J'y verrais un peu plus clair quand j'aurai relancé une analyse du dump maintenant que les corrections automatiques sont passées. --NicoV (discuter) 7 juin 2020 à 10:45 (CEST)
Bonsoir NicoV Bonsoir. Comme un gentil utilisateur de WPCleaner a traité presque tous les cas Clin d'œil, j'ai corrigé hier les 15 cas qu'il restait, la plupart des [[[[Catégorie. --FDo64 (discuter) 9 juin 2020 à 22:00 (CEST)
Bonjour FDo64. En fait, il en reste pas mal… Il faut encore que je modifie WPCleaner pour ignorer quelques cas (en particulier l'utilisation de {{CURRENTYEAR}} dans les liens internes). --NicoV (discuter) 18 juin 2020 à 12:58 (CEST)
Bonsoir NicoV Bonsoir. En ce qui concerne le cas que je signalais, à savoir insource:/\[\[\ *[\[/, il n'y a plus de cas.
Tu sembles parler du cas insource:/\[\[ *\{\{/ qui est nouveau pour moi. Il y a actuellement 123 cas, dont de belles horreurs du style [[{{langue| ou [[{{#property: (totalement interdit dans les articles).
Il y avait aussi 12 cas de insource:/\{\{ *\[\[/ que j'ai corrigé.
--FDo64 (discuter) 18 juin 2020 à 22:41 (CEST)
Bonjour Orlodrim. Projet:Correction syntaxique/Analyse 552 a été généré. A voir si il y a des faux positifs, et ce qui peut être fait en termes de correction automatique. --NicoV (discuter) 7 juin 2020 à 09:22 (CEST)
Dans ta liste, il y a de nombreux {{formatnum:{{modèle}}}} qui ne devraient pas être signalés (tous ceux avec la population) et quelques uns avec {{#expr:{{modèle}}}} comme AAA World Trios Championship. Je ne sais pas comment l'analyseur syntaxique de WPCleaner marche, mais ce serait bien s'il pouvait considérer les fonctions parser de la même manière que les modèles ici. Orlodrim (discuter) 7 juin 2020 à 11:10 (CEST)
Les cas particuliers que j'avais déjà détectés de mon côté sont :
  • Dans Géographie de l'Asie, {{!}}} est une fermeture de tableau légitime
  • Parfois, comme dans Écart type, le "}" est volontaire. C'est fréquent dans les articles liés aux mathématiques, surtout avec {{math}} et {{formule}}, mais aussi parfois avec des modèles génériques comme {{nobr}}.
  • Parfois, comme dans Yoon Je-moon, le "}" devrait remplacé par un autre caractère (typiquement une parenthèse fermante).
Des moyens d'éviter la plupart des corrections dangereuses sont :
  • éviter {{!}}, {{math}} et {{formule}}
  • éviter le modèle s'il contient une accolade ouvrante isolée
  • éviter l'article si (nombre d'accolades fermantes - nombre d'accolades ouvrantes) != nombre d'occurrences de l'erreur
  • éviter l'article si (nombre de parenthèses fermantes - nombre de parenthèses ouvrantes) != 0 (risque qu'il faille remplacer '}' par ')')
Par contre, rechercher le "}" dans le rendu pour voir s'il y a vraiment une erreur n'est pas totalement fiable. Par exemple, dans Futsal aux Jeux de la Lusophonie 2006 (déjà corrigé), l'accolade en trop n'apparaissait pas directement mais se retrouvait dans un attribut HTML, ce qui bizarrement changeait la couleur de la cellule du tableau dans Firefox.
Orlodrim (discuter) 7 juin 2020 à 10:32 (CEST)
D'un autre côté, lorsqu'il n'y a qu'une fonction parser sans modèle, l'erreur pourrait être détectée aussi. Par exemple : {{formatnum:66000}}} dans Henri XI de Legnica. Cela dit, c'est assez rare, pas la peine de le faire si c'est compliqué. Orlodrim (discuter) 7 juin 2020 à 11:10 (CEST)
Merci Orlodrim pour les remarques. L'analyseur syntaxique de WPCleaner détecte tous les éléments du wikitexte (liens, modèles, fontions…), et après chaque algorithme de détection se base sur ces éléments pour détecter la présence d'erreurs particulières. Donc, c'est assez facile de rajouter des contrôles aux algorithmes. J'ai pris en compte plusieurs points, et je ne vois plus de faux positifs dans la première partie de la liste (B inclus) :
  • Cas où le modèle est inclus dans une fonction comme formatnum : OK
  • Cas de modèles particuliers : OK, j’ai ajouté une liste paramétrable de modèles à ignorer
  • Cas des fonctions se terminant par 3 } : OK
Je verrais après la prochaine analyse de dump ce qu'il reste réellement, et si il y a moyen de faire un peu de correction automatique. --NicoV (discuter) 7 juin 2020 à 13:35 (CEST)
Salut Orlodrim. J'ai refait une analyse de dumps, ça a fait du ménage, mais je pense qu'il faut aussi que j'ignore les cas où il y a une accolade ouvrante isolée comme tu avais suggéré. --NicoV (discuter) 8 juin 2020 à 12:44 (CEST)
Depêche-toi, j'en suis à la lettre L, et après il n'y aura plus que les cas tordus Espiègle.
En fait, si on regarde à la loupe, même les {{math|{x}}} mériteraient d'être corrigés car la police de l'accolade fermante est différente de celle de l'accolade ouvrante (rendu : « {x} » ). On pourrait écrire {{math|{x}|}} à la place, par exemple. Par contre, avec {{nobr}}, ça ne change rien.
Orlodrim (discuter) 8 juin 2020 à 18:09 (CEST)
Salut Orlodrim. Je ne vais pas pouvoir relancer une analyse avant quelques jours, tu auras sans doute fini de les corriger avant. Mais comme l'analyse sera lancée régulièrement, j'aimerais bien avoir une détection correcte : peu ou pas de faux positifs, peu ou pas de ratés. Donc, continuons à discuter sur ce qu’il faut détecter et ignore. Est-ce que tu penses qu'il faudrait remettre les modèles {{math}} ? --NicoV (discuter) 9 juin 2020 à 08:35 (CEST)
Notification NicoV :
Idéalement, il faudrait les inclure mais proposer une correction différente selon qu'ils contiennent ou non un déséquilibre d'accolades.
  • Si le "}}}" ferme une accolade ouverte dans le modèle, proposer de le remplacer par "}|}}" (exemple : Spécial:Diff/171846345).
  • Si le "}}}" ne ferme pas une accolade ouverte dans le modèle, proposer de retirer le "}" en trop (exemples : Spécial:Diff/171810805, Spécial:Diff/171811319). Pour être plus sûr, tu pourrais vérifier que cela n'introduit pas un déséquilibre global des accolades dans l'article, afin de ne pas modifier un cas comme {{nobr|E∩{1,{{math|x}}}∩F}} (j'invente, il ne semble pas y en avoir pour le moment, mais on trouve tout de même des situations tordues où seule une partie de la formule est dans un modèle {{math}}, comme {{nobr|1=]{{math|–∞}}, 0[∩]0, {{math|+∞}}[}} dans Adhérence (mathématiques)).
Orlodrim (discuter) 9 juin 2020 à 19:52 (CEST)
Notification Orlodrim : Voici ce que j’ai fait pour l'instant :
  • Si il y a plus d'accolades ouvrantes que d'accolades fermantes dans le modèle, proposition de remplacer par {{…}<nowiki/>}} : ça permet de gérer les cas comme {{math|{x}}} (2e et 3e modifications dans Univers constructible)
  • Si les accolades ouvrantes et fermants sont équilibrées, proposition de remplacer par {{…}}<nowiki/>} : ça permet de gérer les cas comme {{nobr|E∩{1,{{math|x}}}∩F}} (1re modification dans Univers constructible)
  • Proposition de supprimer l’accolade en trop : ça permet de gérer le cas général.
Pour l'instant, aucune de ces propositions n’est appliquée automatiquement, à voir si on peut en appliquer certaines sans risque… Je vais retirer les modèles {{math}}… de la liste des modèles ignorés et on verra le résultat sur la prochaine analyse. --NicoV (discuter) 10 juin 2020 à 10:15 (CEST)

┌─────────────────────────────────────────────────┘

Bonjour. La liste a été mise à jour, Projet:Correction syntaxique/Analyse 552. Il reste environ 150 pages à traiter manuellement je pense. --NicoV (discuter) 12 juin 2020 à 16:49 (CEST)
Bonjour Orlodrim. Normalement, j'ai corrigé toutes les pages. --NicoV (discuter) 15 juin 2020 à 10:49 (CEST)

Erreurs lien interne mal ouvert ou mal fermé[modifier le code]

Bonjour NicoV et compagnie. Rebond sur la digression à propos des erreurs #10 et #46. Il y a quelques faux positifs dans la détection. Les liens suivants sont fonctionnels :

  1. Détection liée à la présence d'une fonction dans le lien. Exemples:
    • dans les pages du type Août 2007 en sport, [[{{CURRENTDAY}} {{CURRENTMONTHNAME}} en sport|L'éphéméride sportive du jour]]. Le passage par un modèle dédié pour créer ce lien reproduit sur plusieurs pages permettrait de supprimer les deux erreurs concernées et le signalement #34 « Élément de programmation des modèles ». Un passage de bot pourrait facilement traiter ce cas.
    • dans Festival international du film de Toronto, [[Festival international du film de Toronto {{CURRENTYEAR}}]]
  2. Des liens corrects dont la cible correspond au titre de la section (ancre), titre contenant une fonction MediaWiki. Exemple dans la page Championnats d'Europe de natation en petit bassin 2011 : [[#{{formatnum:1500}} m nage libre|{{formatnum:1500}} m]]. Dans ce cas, un lien [[#1 500 m nage libre|{{formatnum:1500}} m]] est aussi fonctionnel.

Quelle est l'attitude à tenir ? Modifier les pages ou restreindre la détection ? Merci.--Ideawipik (discuter) 9 juin 2020 à 00:07 (CEST)

Les formatnum sont sans doute là pour des raisons historiques. Avant, les espaces insécables dans les titres de section donnaient des id avec « .C2.A0 », donc c'était soit #{{formatnum:1500}}, soit #1.C2.A0500. Maintenant que ça donne simplement une espace, autant enlever le formatnum à mon avis. Orlodrim (discuter) 9 juin 2020 à 00:32 (CEST)

Taxobox[modifier le code]

Bonjour FDo64. En parlant de maintenance de l’espace modèle, est-ce que tu saurais comment corriger les missing-end-tag (les premiers dans la liste) liés aux modèles du groupe {{Taxobox}} ? --NicoV (discuter) 8 juin 2020 à 10:04 (CEST)

Notification NicoV : C'est un sujet que je connais bien, on parle quand même de 116 000 erreurs !
J'ai même développé la solution : l'{{Infobox Taxon}} qui en plus de corriger les problèmes de LINT est compatible avec l'éditeur visuel. Je l'ai proposée à diverses reprises au Projet:Biologie :
  1. Projet:Biologie/Le café des biologistes/Archives/Septembre-octobre 2018#Erreurs de Lint dans les taxobox (du 13 septembre 2018 au 21 décembre 2018)
  2. Projet:Biologie/Le café des biologistes/Archives/Mars-avril 2019#Refonte des Taxobox (du 26 mars 2019 au 6 mai 2019)
  3. Projet:Biologie/Le café des biologistes/Archives/Mars-avril 2019#Nouvelle Infobox Taxon (du 25 avril 2019 au 3 mai 2019)
  4. Projet:Biologie/Le café des biologistes/Archives/Juillet-août 2019#Mise en place de l’Infobox Taxon (du 10 juillet au 12 juillet 2019)
Il m'avait été demandé d'attendre, du coup je suis parti sur d'autres projets. De plus, je comptais sur Notification Hexasoft pour développer le bot, puisqu'il connait particulièrement bien le sujet, mais ses soucis perso (auxquels je compatis pleinement) m'ont freiné au moment où je voulais relancer cette migration. À moins qu'un autre dresseur ne se sente apte et suffisamment disponible pour s'y attaquer, je vais devoir patienter.
--FDo64 (discuter) 8 juin 2020 à 13:11 (CEST)