Discussion Projet:Correction syntaxique/2020

Description du projet

Liste des erreurs

Discussions

Page de discussion archivée du Projet:Correction syntaxique pour l'année 2020.

Archives

2008 • 2009 (1^er • 2^e • 3^e • 4^e)
2010 • 2011 • 2012 • 2013 • 2014
2015 • 2016 • 2017 • 2018 • 2019
2020 • 2021 • 2022

(en) WikiProject Check Wikipedia

Erreur div-span-flip, et autres questions

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 . 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)

Lien interne circulaire directement ou via une redirection, beaucoup de cas.

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 n^o 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 . 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)

 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.

articles concernés (extrait)

Arsène Lupin
Algèbre de Boole (logique)
Akira Kurosawa
Amon
Astéroïde
Blender
Bruxelles
Cuisine japonaise
Champagne-Ardenne
Côte-d'Or
Cinéma
Cowboy Bebop
Cyberpunk
Debian
Dictionnaire
Euro
Escalade
Fidji
Festival de Cannes
France Télécom
GNU
Game Boy
Genre (sciences sociales)
Haut-Rhin
Haute-Vienne
Homo habilis

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

Bonjour. Faudrait-il ajouter les espaces en HTML dans la détection de l'« erreur 85 : Balise sans contenu » ? Par exemple   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: ^{<nowiki>[5] : 124 [8]</nowiki>}
• CP System: ^{<nowiki>[Dash]</nowiki>}, ^{<nowiki>[Dash]</nowiki>}
• 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): ^{<nowiki>&minus;</nowiki>}, ^{<nowiki>&minus;</nowiki>}, ^{<nowiki>&minus;</nowiki>}
• 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: ^{<nowiki>|φ|</nowiki>}, ^{<nowiki>|φ|</nowiki>}

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  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)

 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)

Modèle fermé par }}}

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)

 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  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 . 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 . 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 . Comme un gentil utilisateur de WPCleaner a traité presque tous les cas , 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 . 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 .

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)

 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)

 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}}} (2^e et 3^e 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}} (1^re 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é

Enregistré sur Phabricator
Tâche 258313

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)

Bonjour. Normalement dans la prochaine analyse de dumps, une bonne partie des faux positifs devraient disparaître, en particulier ceux avec des CURRENTYEAR ou similaire. --NicoV (discuter) 19 juillet 2020 à 17:05 (CEST)

Balises HTML center ou modèle.

Bonjour. Les erreurs de lint recensent des cas de balises HTML obsolètes notamment les <center>. Y a-t-il lieu de remplacer les <center>…</center> par {{Centrer|…}} ou {{Centrer|1=…}} si la présence d'un signe = dans le texte perturberait la modèle ? La page Wikipédia:Code HTML, rédigée il y a pas mal de temps, ne le recommande pas.  STyx auteur de la page.
Si ces corrections sont utiles elles pourraient être ajoutées aux corrections cosmétiques des bots. En réalité, certaines balises :

• sont superflues et peuvent sans problème être retirées, comme autour des balises <gallery> ou autour de certains modèles tels {{Tableau rang commune de France}} ou autour des {{Feff début}} et associés.
• qui englobent un modèle, peuvent être remplacées par la spécification d'un paramètre du modèle.
• peuvent être retirées pour des raisons éditoriales.

Apparemment, la majorité de ces balises concerne des alignements de légendes d'images, dans le texte ou dans des galeries.
Note : Exceptions et précautions à prendre. Selon le contenu des balises, le modèle de substitution peut ne pas convenir techniquement et ne pas donner l'alignement assuré par les balises. Qu'en pensez-vous ? Merci. Cdlt. — Ideawipik (discuter) 5 juillet 2020 à 18:28 (CEST)

 Ideawipik : La balise <center> est obsolète et doit effectivement progressivement être supprimée. Mais ce n'est pas non plus une urgence prioritaire, compte tenu des conséquences d'une correction mal maîtrisée.

En effet, tout contenu englobé avec le modèle {{centrer}} ne peut plus être édité directement par l'éditeur visuel. Car il s'agit alors du contenu d'un paramètre. Donc cela implique d'être en mesure de pouvoir modifier le wikicode (donc de connaître le wikicode) du contenu centré depuis l'éditeur visuel. Ce sont les limites de l'éditeur visuel, qui n'offre pas d'édition WYSIWYG pour le contenu des paramètres d'un modèle, ni pour les modèles imbriqués. Pour un titre centré, du simple texte, etc. ce n'est pas trop gênant.

Par contre, englober un tableau dans ce modèle, en plus de compliquer le wikicode, casse deux choses:

1. Il devient en pratique totalement impossible d'éditer ce tableau depuis l'éditeur visuel. C'est impossible pour un être humain normalement constitué de modifier le wikicode d'un tableau dans la minuscule fenêtre de l'éditeur de modèle de l'EV.
2. Cela casse la coloration syntaxique du tableau offerte par CodeMirror dans l'éditeur de code.

Le problème se pose aussi dans d'autres cas, où cette balise sert par exemple à centrer un modèle ou le contenu d'une autre balise. Actuellement, la balise étant "transparente" à l'édition pour l'éditeur visuel, ça n'a pas de conséquence. Mais il en est tout autrement si ce contenu est mis dans le modèle Centrer. C'est la raison pour laquelle il m'arrive occasionnellement d'en laisser volontairement. Car parfois, le rapport coût/bénéfice d'un tel remplacement peut s'avérer totalement disproportionné. Remplacer une balise, certes obsolète — mais supportées par tous les navigateurs — par le modèle apporte un bénéfice ridicule, pour un coût monstrueux, tant pour l'éditeur visuel que pour la lisibilité du wikicode avec Aide:CodeMirror.

En pratique, lorsque je fait de la maintenance de pages, plus de 80 % des cas utilisations de cette balise ne sont pas remplacés par {{centrer}}, mais sont supprimées, remaniées, gérées via un attribut style="" ou toute autre technique pertinente au cas présent.

Donc attention avant chaque remplacement. Le bénéfice est — à l'heure actuelle — très faible, pour un coût parfois très élevé. La plupart des autres balises et attributs (qui ne sont eux pas indiqués par linter) obsolètes n'ont pas un tel "coût" associé à leur correction.

Et d'expérience, comme tu le souligne, pas mal d'utilisations de cette balise sont, soit inutiles, soit problématiques, soit largement dispensables. On trouve par mal de trucs centrés avec un <center> qui devraient être gérés par des méthodes ad hoc, voire parfois pour lesquelles le centrage est largement dispensable...

Exemple courant : les tableaux. On trouve pas mal de tableaux centrés avec cette balise. Il ne faut en aucun cas la remplacer par {{centrer}}, mais par la classe centre. Dans d'autres cas, un simple style="text-align:center;" sur une balise permet de régler le problème.

On trouve aussi parfois cette balise dans d'autres configurations, notamment à l'intérieur de tableaux de mise en page. Dans ce cas, il est souvent préférable de traiter l'ensemble, et de remplacer le tableau de mise en page par une solution plus accessible.

Bref, il n'y a pas une solution prête à l'emploi, encore moins d'automatisation possible. Sans compter que selon ce qu'elle enveloppe, la remplacer par le modèle {{centrer}} empêchera d'éditer ce contenu correctement depuis l'éditeur visuel. Donc, toujours bien se poser la question à chaque fois, est-ce qu'un simple remplacement est approprié, où vaut t'il pas mieux reprendre la mise en page du contenu l'utilisant ?

Quand à la page Wikipédia:Code HTML, elle est obsolète, comme bien d'autres. Plus de détails sur les balises obsolètes sur mw:Help:Lint errors/obsolete-tag.

--Tractopelle-jaune (discuter) 5 juillet 2020 à 22:59 (CEST)

Merci Tractopelle-jaune, pour cette réponse. La correction dans le cas du tableau me paraissait tellement évidente que j'ai oublié de lister cette éventualité . Et ce n'est pas une question récente.

Donc je laisse tomber l'automatisation de cette correction sauf quelques cas évidents dans lesquels les balises sont inutiles.

Y a-t-il une possibilité CSS (dans <gallery> de centrer les légendes de toutes les images d'une galerie ? Il y a bien le mode="nolines" mais il n'est pas toujours très esthétique en cas d'images aux dimensions disparates. Je n'ai pas fais de statistiques mais je ne serais pas étonné que cette utilisation des <center> représente près de 50% de l'ensemble de leur présence dans l'espace des articles. Les « pseudo-barres de navigation » des chronologies sont aussi un gros pourvoyeur.

— Ideawipik (discuter) 5 juillet 2020 à 23:47 (CEST)

 STyx : Non ! La balise <center> est obsolète en HTML ; mais ici c'est du code Wiki ! Ce n'est pas obsolète. C'est aux développeurs de Mediawiki qu'il appartient de décider quoi faire de <center> (style="text-align:center;" ou pas? en l'occurrence : pas)   <STyx @ (en vadrouille) 5 juillet 2020 à 23:52 (CEST)

 STyx : La balise <center> est considérée comme obsolète en HTML5 ET en wikicode. Contrairement à la balise <big>, obsolète en HTML5, mais qui n'est pas considérée comme obsolète en wikicode par les devs (phab:T154067).

Et un remplacement interne par MediaWiki des <center></center> par <div style="text-align:center;"></div> ne produit pas un rendu équivalent dans tous les cas. Par exemple ça ne marche pas comme attendu pour les tableaux, voir ce test sur mon brouillon.

• <center> autour d'un tableau alignera ce dernier au centre, mais conserve l'alignement à gauche du texte des cellules.
• <div style="text-align:center;"> ne centre pas le tableau, mais aligne le contenu des cellules au centre.

--Tractopelle-jaune (discuter) 6 juillet 2020 à 01:44 (CEST)

 Ideawipik : Si ça peut t'aider, j'avais déjà recensé quelques remplacements :

• utilisation de class="center" pour les balises <gallery> et <poem>.
• utilisation de |style="text-align: center;" | dans les cellules de tableaux.
• utilisation du tag center dans les images.

--FDo64 (discuter) 6 juillet 2020 à 00:33 (CEST)

Pour info WPCleaner gère le cas des cellules de tableaux, il faudrait juste activer l’erreur #541 dans la configuration : error_541_prio_frwiki=3 END et error_541_bot_frwiki=true END, comme sur Utilisateur:WikiCleanerBot/WikiCleanerConfiguration. Mais bien sûr, ça entraîne la détection de toutes les erreurs de balises obsolètes comme pour Special:LintErrors/obsolete-tag --NicoV (discuter) 6 juillet 2020 à 08:16 (CEST)

Important : mise à jour manuelle de WPCleaner

Enregistré sur Phabricator
Tâche 257495

Bonjour, à cause de la migration du domaine Toolforge, WPCleaner ne peut plus se mettre à jour de la version 2.02 vers la version 2.03. Je suis en discussion avec la fondation pour voir si ils peuvent faire quelque chose de leur côté, mais si vous voulez mettre à jour en 2.03 (améliorations mineures pour l'instant), vous pouvez le faire de plusieurs manières :

• Réinstaller WPCleaner avec l'installeur mis à jour
• Dans le répertoire où WPCleaner est installé, remplacer getdown.txt par ce fichier
• Dans le répertoire où WPCleaner est installé, modifier getdown.txt et remplacer la ligne avec appbase par appbase = https://wpcleaner.toolforge.org/wpcleaner/

Dites-moi si il y a un problème. --NicoV (discuter) 13 juillet 2020 à 10:39 (CEST)

Remplacement de harvsp par sfn

Bonjour, serait-il possible svp de cesser les remplacements par sfn ? Cordialement, — Racconish ^💬 6 août 2020 à 16:08 (CEST)

Bonjour Racconish. J'imagine que tu fais référence à ce diff de LeFit, action qui vise à regrouper les appels multiples de références identiques. Pour ce faire, il y a deux options naturelles :

• transformer, par exemple, <ref>{{harvsp|Maroille|2005|p=12}}.</ref> en <ref name="Maroille2005_p12">{{harvsp|Maroille|2005|p=12}}.</ref> lors du premier appel et en <ref name="Maroille2005_p12"/> lors des rappels ;
• transformer tous les appels <ref>{{harvsp|Maroille|2005|p=12}}.</ref> en {{sfn|Maroille|2005|p=12}}

Il m'est déjà arrivé quelquefois d'opter indifféremment l'une ou l'autre. La seconde présente l'avantage de ne pas avoir à définir de nom (subjectif) pour la référence et de pouvoir supprimer ultérieurement un passage référencé, sans se soucier d'éventuels autres appels à la même référence ni risquer des messages « Erreur de référence : Balise <ref> incorrecte : aucun texte n’a été fourni pour les références nommées […] ». Après cela peut être lié à un choix personnel ou selon les circonstances. Que conseilles-tu, pour éviter les doublons dans la section des références ? Merci. — Ideawipik (discuter) 6 août 2020 à 17:08 (CEST)

Je trouve le premier constructif et le second intrusif, puisqu'au motif d'un regroupement de références, utile, il impose un passage en sfn, optionnel et pour ce qui me concerne agaçant. Le choix "subjectif" d'un nom, genre foo1, foo2, n'est pas un problème. Cordialement, — Racconish ^💬 6 août 2020 à 17:13 (CEST)

 Racconish. J'avoue être d'accord avec toi mais surtout pour des raisons de cohérence et d'uniformité au sein d'un même article. Si tu le souhaites, tu peux toujours préciser ces recommandations dans l'aide du projet Correction syntaxique en créant Projet:Correction syntaxique/Erreur syntaxique 081. Cordialement. — Ideawipik (discuter) 6 août 2020 à 17:35 (CEST)

Ideawipik : Cordialement, — Racconish ^💬 6 août 2020 à 17:51 (CEST)

Privilégier le caractère de contrôle ou son équivalent html ?

Bonjour, après recherches sur les corrections syntaxiques des caractères unicodes ou leurs équivalents html [2], je me tourne vers vous et vous prie de me ré-aiguiller si le sujet a déjà été traité (en 2016, [3] ne traitait pas vraiment du sujet). Je me suis récemment intéressé aux problématiques d'erreurs de caractères unicodes illisibles dans la plupart des navigateurs, mais me suis arrêté sur ce cas (voir mon diff). WPCleaner me propose de corriger ce caractère unicode, selon la liste des erreurs syntaxiques. La fonction de check avant application des modifications m'a permis de constater que ces règles ne semblent pas toujours compatibles : Dans mon diff,

• 11 [4] propose de remplacer&.#59415; par  ;

pendant que

• 16 [5] demande de remplacer  par &.#59415; (NB: je retrouve les codes html équivalents avec unicodelookup).

J'ai pu lire avec attention les recommandations officielles, recommandations informelles fort utiles, de même que les bonnes pratiques en matière d'accessibilité pour les caractères unicodes. Y-a-t'il une règle qui prime sur l'autre : 11 est priorisé bas, 16 priorisé moyen, mais 11 < 16, 11 l'emporte peut-être sur 16 ? Faut-il privilégier le format unicode et mettre en liste blanche les pages qui sont détectées avec un caractère ce contrôle ? -- Ga3lig(📧) 23 septembre 2020 à 19:15 (CEST)