Discussion Projet:Correction syntaxique/2021

Problème de balises

Bonjour, j'ai voulu réorganiser les références sur l'article Famille de Grandson en créant deux références group et une section classique. Toutefois, il y a eu un hic, et je n'arrive pas à voir lequel. Est-ce que quelqu'un pourrait m'apporter son aide. --AlpYnement vôtre, B-noa (d) 12 mars 2021 à 10:53 (CET)

Bonjour B-noa. Je crois que c'est bon maintenant. Le modèle {{Références nombreuses}} accepte le paramètre groupe mais pas l'alias group (valide pour {{Références}}). Ne pas hésiter à aller voir la documentation voire le code des modèles sollicités . On a eu un conflit d'édition sur l'article. Merci de vérifier si je n'ai pas écrasé une de tes modifications. — Ideawipik (discuter) 12 mars 2021 à 11:42 (CET)

 Ideawipik :, merci pour la correction. En effet, cette subtilité du « e » pour group il fallait la trouver... . --AlpYnement vôtre, B-noa (d) 12 mars 2021 à 11:49 (CET)

Lien magique RFC obsolète ?

Bonjour. Juste pour signaler une "correction" qui n'en est pas une : ici, en bas de la page.  Hyméros. Voir après et avant. Un {{lien|RFC 2828}} menait à une page inexistante sur enwiki mais {{lien|{{RFC|2828}}}} donne quelque chose de vraiment farfelu. Prendre le temps de vérifier les propositions. Merci aux correcteurs pour leur activité. Cordialement. — Ideawipik (discuter) 6 avril 2021 à 22:13 (CEST)

Erreur n^o 67

Bonjour,

J'ai forcé la suppression de la table de l’erreur 67 puisque, depuis plusieurs jours, je me dédie à la résolution de celle-ci via AWB et que la liste n'a pas été correctement mise à jour depuis le dump (20 juillet). Certaines erreurs étaient déjà corrigées et auraient dû être actualisées par la mise à jour journalière. J'ai aussi travaillé sur l'erreur 81, qui en passant a énormément diminué , mais elle a été mise à jour, je n'ai pas eu besoin de forcer la mise à jour.

Bref, la table 67 sera raffraîchie le 24 juillet à 00:05 ; d'ici là, si vous souhaitez avoir la liste, je peux la fournir. — LD ^{• m'écrire •} 23 juillet 2021 à 18:04 (CEST)

Des abuse filter?

Bonjour,

Idée du jour : ne pourrait-on pas utiliser des abuses filter pour signaler aux contributeurs que la modif qu'ils s'apprêtent à publier contient une erreur syntaxique?

Aucune idée si c'est applicable et comment faire par contre .

— RG067 (discuter) 23 août 2021 à 20:32 (CEST)

Bonjour RG067

Techniquement possible de créer un filtre pour baliser. Toutefois, cette idée me semble à évaluer au sein de la communauté :

• Veut-on vraiment un avertissement ?
• Qui devra avoir cet avertissement ? (tous les utilisateurs ? certains statuts ? IPs ?)
• Est-ce que, vu que les messages sytèmes sont peu personnalisables, l'effet escompté (minimiser les erreurs syntaxiques) n'engendra-t-il pas une incompréhension et également une diminution des tentatives d'ajouts par les néophytes qui trouveraient la tâche "trop difficile" ? (WP a la vocation d'être utilisable par tous)

Mais la question est intéressante. D'ailleurs, j'ai candidaté cette année en tant qu'AF pour trouver de telles fonctionnalités ou en tout cas, essayer d'y réfléchir avec la communauté. Une idée similaire sur le phénomène de surcatégorisation ou de "suportalisation" m'était venue en juin : cf. cette discussion qui pointe néanmoins des contraintes techniques qui ne rendent pas possible cette détection d'erreur "facilement" pour le moment.

A quelles erreurs penses-tu ?

Amitiés, LD ^{• m'écrire •} 23 août 2021 à 21:28 (CEST)

@LD Je pense aux erreurs qui causent des grands problèmes d'affichages, c'est à dire celles classés comme d'importance élevés.

Effectivement, je suis conscient que ma demande ne prendra pas 5 minutes et devra être évalué dans sa faisabilité puis soumise à la communauté. Pour moi, il s'agirait surtout de prévenir des éventuelles erreurs qui peuvent être facilement corrigés par celui qui rédige (voir même plus facilement que par celui qui repasse après et qui doit comprendre quelle était l'intention d'origine).

Concernant le dernier point, je vois deux pistes :

• Je vois le message comme un message du type "dans votre ajout, l'erreur numéro ... (description de l'erreur et lien vers le Projet:Correction syntaxique) apparait.", en ajoutant quelques mots pour faire comprendre que la correction n'est en rien obligatoire.
• ou alors, seuls certains contributeurs expérimentés pourrait voir le message : par exemple, un contributeur autopatrolled comprendra normalement le problème et pourra aviser et le corriger.

Je pense aussi que les abusefilter peuvent avoir des utilisations supplémentaires par rapport à ce qui est fait actuellement, et j'espère que nous arriverons à trouver des idées intéressantes.

Merci pour la réponse et une très bonne soirée, — RG067 (discuter) 23 août 2021 à 21:43 (CEST)

Je notifie également de cette discussion sur Wikipédia:Bulletin du filtrage (suivie par des AF mais pas que) pour d'éventuelles réflexions qui permettront d'enrichir la discussion. Merci d'avoir pris le temps de soulever la question. N'hésite pas à la mentionner sur le Bistro si elle reste sans réponse complémentaire. LD ^{• m'écrire •} 23 août 2021 à 21:57 (CEST)

Salut. Dans le doute, je me permets d'intervenir sur la différence entre « balisage » et « message au contributeur » au cas où vous ne connaissiez pas différence entre les deux notions car au vu de la discussion il me semble qu'il y a amalgame (et désolé si vous saviez déjà) :

• Le message au contributeur (appelé officiellement « avertissement à l'utilisateur ») oblige le contributeur à cliquer une deuxième fois avant publication en lui affichant un message d'avertissement
• Le balisage ajoute un "tag" dans le commentaire de diff (exemple) pour relecture ultérieure sans obligation de re-cliquer.

Une fois cette explication posée, si le filtre est créé, je suis opposé l'avertissement qui va imposer une étape supplémentaire aux contributeurs et favorable à la balise. Charge aux contributeurs de ce projet de vérifier les articles balisés : les balises existantes sont listées sur Spécial:Balises. Il suffit alors de cliquer sur la liste des modifications balisées du filtre considéré pour jeter un œil aux dernières détections. J'ajoute que le balisage n'a pas besoin d'être soumis à la communauté : il s'agit uniquement d'une indication sans contrainte.

Enfin, avant de savoir si c'est techniquement faisable, il faut définir précisément ce que vous voulez détecter. Comme dit par LD (d · c · b), tout n'est pas faisable même si pour les « non-AF » ça paraît simple d'un premier abord. 'toff ^[discut.] 24 août 2021 à 09:45 (CEST)

Bonjour @Supertoff,

Merci pour cette réponse et cette précision qui est effectivement importante.

J'ai par contre pas le même avis que vous : pour moi, le balisage ne servirait à rien (les erreurs syntaxiques sont mises à jour toutes les nuits). Le but des abuses filter serait de permettre au contributeur qui fait la modification de se rendre compte de l'erreur.

Donc je m'imaginais peut-être plus un message qui s'affiche et donc une étape supplémentaire. De plus, si on applique les filtres seulement à certains erreurs de haute priorité (type LI/Modèle mal ouverts/fermés), le nombre de détection et donc le dérangement de chaque contributeur serait très faible (actuellement, je tablerais sur centaine d'erreurs par jour si l'on prend en compte toutes les erreurs de priorité haute, et je ne pense pas qu'il faille toutes les prendre en compte).

Je suis bien conscient que tout n'est pas techniquement faisable, il s'agissait simplement de lancer une idée et d'avoir des retours et un débat sur les possibilités qui s'offrent à nous pour réduire le nombre d'erreurs à corriger. — RG067 (discuter) 24 août 2021 à 09:54 (CEST)

Correction sur le nombre d'erreurs : il s'agit du nombre d'erreur qui sont détectées chaque matin, et qui comprend donc les erreurs non corrigées du jour avant. Le chiffre sera donc bien moindre. — RG067 (discuter) 24 août 2021 à 09:56 (CEST)

Au vu du lien, je ne serai probablement personnellement pas capable techniquement de créer un filtre simple sur ces erreurs (aucune) et il risque d'y avoir bien trop de faux positifs : les détections semblent bien trop complexes. De plus, étant donné que ce lien donne déjà les erreurs comme le ferait un balisage de filtre, je ne suis pas favorable à sa création. 'toff ^[discut.] 24 août 2021 à 10:03 (CEST)

Si c'est techniquement impossible, rien ne sert de débattre sur une potentielle mise en place. Merci en tout cas pour les précisions, j'ai appris des choses qui pourront me resservir. — RG067 (discuter) 24 août 2021 à 10:10 (CEST)

Attention, j'ai dit que personnellement je n'en suis pas capable et que ça me semble compliqué 'toff ^[discut.] 24 août 2021 à 18:10 (CEST)

┌─────────────────────────────────────────────────┘
Il existe quelques filtres, listés dans Spécial:Filtre antiabus, qui visent à détecter des erreurs syntaxiques provenant directement du contributeur : #37 et #45, ou carrément à les empêcher : #212 (filtre destiné à bloquer les bugs d'un bot).

D'autres filtres existent, mais sont destinés à identifier, et parfois à baliser, des erreurs indépendantes du contributeur. Ils sont destinés à identifier des bugs provenant de l'éditeur visuel (gros pourvoyeur historique d'aberrations syntaxiques), d'extensions MediaWiki, de bugs au sein de différents navigateurs (ou encore de certaines de leurs extensions).

Certains filtres balisent les modifs, et parfois avertissent l'utilisateur avec un message, mais la plupart ne font rien (il faut donc consulter le journal du filtre pour identifier les détections). Certains de ces filtres sont visiblement toujours activés alors que les bugs ont depuis été a priori corrigés.

Voici une petite liste (pas forcément exhaustive) des filtres destinés à des bugs/erreurs syntaxiques/erreurs de manipulation :

• Spécial:Filtre_antiabus/37, cassages de tables et modèles par de nouveaux utilisateurs (pas toutes les situations sont détectés, et il y a parfois quelques faux-positifs).
• Spécial:Filtre_antiabus/45, redirections redirigeant vers elles-mêmes.
• Spécial:Filtre_antiabus/171, insertions de balises <nowiki> ou <nowiki /> (dans les articles uniquement). 99 % des cas sont involontaires (au sein des articles) ; il s'agit soit de bugs de l'éditeur visuel (devenus moins fréquents), soit issus de manipulations hasardeuses du contenu ou de liens dans l'éditeur visuel (considérés alors en gros par les devs comme étant des problèmes d'interface chaise-clavier).
• Spécial:Filtre_antiabus/184, insertions de pions et de bonhommes de neige par l'EV (chercher « pions » ou « bonhommes de neige » dans Wikipédia:ÉditeurVisuel/Avis/Archive 2, Wikipédia:ÉditeurVisuel/Avis/Archive 3, Wikipédia:ÉditeurVisuel/Avis/Archive 4 et suivants, pour le contexte). Problème normalement réglé depuis longtemps.
• Spécial:Filtre_antiabus/194, remplacements de paramètres âge=oui par genre âge=46 dans les modèles {{Date de naissance}}. Ces modifications sont quasiment toujours effectuées par des IP de passages (ou des comptes créés pour la circonstance), qui consultaient une version de la page mise en cache (qui n'avait pas été recalculée depuis plusieurs heures). Et l'âge indiqué n'était donc plus le bon.. Un développeur ou informaticien qualifierait cela d'un problème d'interface chaise-clavier. Ces modifications ne sont pas graves, s'agissant d'un paramètre booléen (toute valeur non-nulle passée équivaut à 1). Mais les laisser trainer induit des confusions futures certaines, car le modèle n'afficherait plus l'âge indiqué en paramètre un an plus tard. D'où l'objectif d'annuler cette modification précise (mais sans forcément perdre le reste des modifs).
• Spécial:Filtre_antiabus/195, bug d'encodage de l'éditeur visuel.
• Spécial:Filtre_antiabus/212, pour détecter (et bloquer) les bugs d'un bot cross-wiki (CommonsDelinker), qui casse parfois des liens ou laisse traîner des bouts de code quand il veut retirer une image supprimée sur Commons. Dans ces cas, le filtre interdit la modif du bot (car le bot cause plus de dégâts que de bénéfices). Ces problèmes auraient dû êtres réglés en amont dans le code du bot depuis longtemps, mais ce n'est qu'imparfaitement le cas. Donc le filtre a été créé pour y remédier (un blocage du bot n'est pas justifié au vu de ses apports indispensables à la bonne marche de l'encyclopédie).
• Spécial:Filtre_antiabus/216, bug de l'éditeur visuel, insertion de lignes vides au début d'une page, après un seul caractère.
• Spécial:Filtre_antiabus/263, bug d'un navigateur identifiant certaines suites de chiffres dans les articles comme un numéro de téléphone, et ajoutant le protocole tel:// devant ces suites de chiffres.
• Spécial:Filtre_antiabus/275, bugs de l'outil de traduction laissant du balisage inutile, comme des <span class="cx-segment" data-segmentid="61"></span>. Aucun impact en soi (il s'agit d'une balise générique sans contenu). Mais ça n'a strictement rien à faire dans les articles. Dans des cas extrêmes, certains paragraphes peuvent comporter plus de balisage inutile que de contenu.

Il y a peut-être d'autres filtres que je n'ai pas vu dans la liste, mais je crois avoir fait le tour. De nombreux autres filtres visant des bugs depuis corrigés (issus de l'EV, d'un navigateur ou d'une de ses extensions) ont été supprimés depuis.

Pour le reste, si on avertit l'utilisateur d'un problème, il faut qu'il soit en capacité de comprendre la nature du problème. Or, vu les questions relativement fréquentes sur WP:QT ou sur le bistro, venant de contributeurs expérimentés (certes, ce ne sont pas des informaticiens ou des développeurs, mais ils ont plusieurs années d'expérience avec le wikicode), relatives à des modèles dysfonctionnels ou des tableaux cassés, un rendu bizarre, etc. Hé bien je me dis que c'est pas si facile...

Il faut aussi garder à l'esprit que nous sommes aussi responsables (indirectement) de bon nombre de ces erreurs et autres problèmes d'interface chaise-clavier venant de contributeurs inexpérimentés. Nous avons créé un nombre incalculable de modèles, dont certains horriblement complexes, des noms de paramètres qui ne veulent rien dire, des syntaxes qui nécessitent de consulter la doc à chaque fois que l'on s'en sert, ou encore des pratiques liées à l'accessibilité (indispensables, mais compliquant parfois le code), etc.

Certes, tout ne vient pas de nous, certains utilisateurs sont vraiment d'une imagination débordante pour arriver à pondre des trucs complètement invraisemblables. Mais pour le reste, cela n'a aucune gravité de casser un lien interne ou un modèle, quelqu'un passera derrière le réparer...

Il ne faut pas mettre de barrières techniques à la contribution. Souvent, des raisons techniques sont derrières certaines pratiques ou choix. On fait du mieux que l'on peut avec les contraintes techniques.

Si certaines erreurs syntaxiques particulièrement problématiques (ou qui devraient être corrigées rapidement avant qu'une prochaine édition avec l'EV ne casse tout), peuvent être détectées par un filtre, très bien. Ce sera ainsi journalisé. Mais pas besoin (sauf dans des cas qui nécessiteraient une action rapide de réparation) de baliser ces modifs. Une balise est visible dans les historiques et sur les listes de contributions, elle peut être mal acceptée ou incompréhensible (même si on peut la supprimer manuellement).

--Tractopelle-jaune (discuter) 25 août 2021 à 16:07 (CEST)

Création page exceptions erreur 60

Bonjour,

Serait-il possible de créer la liste blanche pour l'erreur 60 et d'y ajouter V830 Tauri et Aldébaran? Il ne faut visiblement par remplacer le paramètre V* par autre chose.

Merci d'avance, — RG067 (discuter) 25 août 2021 à 11:52 (CEST)

Bonjour RG067. Il est écrit, en commentaire dans le code des articles mentionnés, pour ces paramètres V* : « merci de ne PAS re-changer en Vstar, cela casse le lien ». Mais dans le module:Liens VisieR, le paramètre s'appelle « VStar » (la variante typographique est importante).

Dans le code du module, le paramètre V* semble faire doublon exact avec VStar. Pourquoi ne pas conserver uniquement ce dernier, comme dans BL Lacertae ? Pour information,  Romuald 2. — Ideawipik (discuter) 25 août 2021 à 13:47 (CEST)

Il s'agit d'une bonne question. Je n'ai fait que suivre les consignes dans les commentaires des articles, ne voulant rien casser. — RG067 (discuter) 25 août 2021 à 13:51 (CEST)

@RG067. En fait, j'ai vérifié. VStar ne fonctionne pas dans ce cas, car il est utilisé directement dans le lien (url), d'où un lien effectivement erroné. Mais on peut voir s'il est possible de modifier le module/modèle, afin qu'il traite différemment ce cas particulier. — Ideawipik (discuter) 25 août 2021 à 13:56 (CEST)

Je laisse les spécialistes s'en charger, je serais bien incapable de modifier le modèle. Merci en tout cas pour la vérification. — RG067 (discuter) 25 août 2021 à 13:58 (CEST)

@RG067. Je m'en suis chargé. Les appels au modèle avec le nom de paramètre « VStar » généraient des adresses invalides. C'est corrigé et l'url contient désormais bien le V* attendu. Seul le paramètre « VStar » a été conservé dans le modèle. Cf. Discussion modèle:Palette VizieR#Paramètre V*. Les deux articles ont été corrigés. — Ideawipik (discuter) 25 août 2021 à 18:20 (CEST)

Bonsoir,

J'avais en effet inséré cette remarque parce que le modèle générait un lien avec "Vstar" qui cassait le lien. Merci beaucoup d'avoir corrigé ce problème (je ne sais pas pourquoi je ne l'avais pas signalé qque part à ce moment-là). Romuald 2 (d) le 25 août 2021 à 18:42 (CEST)

Présence de formatnum incomplets

Bonjour. En contrôlant la présence de « {{formatnum:…}} [mot] » pouvant être convertis en « {{nombre|…|[mot]}} », pour des nombres supérieurs à mille (NB pour les entiers inférieurs, le modèle plus léger {{nobr}} convient), je suis tombé sur des occurrences étranges de insource:/\{\{formatnum:[0-9]*\}\} [0-9]+/. L'historique de deux articles pris au hasard révèle une introduction ancienne provenant d'un outil (semi-)automatique mal configuré : « {{formatnum:1057}} 289 spectateurs » ou « {{formatnum:13255231}} 970||  ».

1. Est-ce que l'expression régulière d'AWB a été modifiée depuis, pour ne pas continuer à faire les mêmes erreurs ?
2. Je ne crois pas qu'il soit très facile de corriger cela de manière automatique car on trouve par exemple des « {{formatnum:6000}} 78 tours », qui gagneraient à être écrits « {{nombre|6000|disques}} {{nobr|78 tours}} », ou autres « {{formatnum:1118}} 737-200 » pour désigner des avions Boeing.

Variantes :

• avec des double espaces multiples \{\{formatnum:[0-9]*\}\} {2,}[0-9]+ : très peu de cas ;
• sans espaces \{\{formatnum:[0-9]*\}\}[0-9]+
• nombre avant le formatnum [0-9]+ *\{\{formatnum:[0-9]*\}\} : dont certains pour lesquels une virgule serait à ajouter après une année écrite en chiffres et avant le nombre considéré.

Bonjour  Jules*, LD, FDo64 et NicoV, si vous avez des idées… — Ideawipik (discuter) 11 septembre 2021 à 20:09 (CEST)

Salut, un avis bref (je n'ai pas regardé toutes les implications) :

Pour AWB, formatnum est cité à la fin de Syntaxe Wiki. Wikiblame ne m’a pas remonté bien au-delà de 2009, mais les expressions étaient différentes : Spécial:Diff/43614661.

Je réaliserais un test prochainement, il est probable qu'avec une regex qui retire le formatnum si suivi d'une espace puis d'un chiffre, la regex actuelle recorrige convenablement. Sinon, il est toujours possible de rajouter une regex pour corriger ces cas vers nombr.

Pour le cas particulier de x tours, c'est plus compliqué sous AWB que WPCleaner àmha, vu qu'a priori, il faudrait des suggestions multiples. Le mot "tours" pourrait être confondu, par exemple, avec "tour de pistes" en athlétisme, etc. — LD (d) 11 septembre 2021 à 20:24 (CEST)

 Ideawipik : Bonsoir. Dans les deux exemples que tu as fournis, je ne suis pas sûr que cela vienne de Wikipédia:AutoWikiBrowser/Typos puisqu'on peut choisir de ne pas les utiliser. C'est mon cas. Et alors le problème vient uniquement des regex écrites par celui qui utilise AWB. Comme Hercule n'intervient plus, on ne saura pas d'où vient le problème. --FDo64 (discuter) 11 septembre 2021 à 22:42 (CEST)

Bonsoir Ideawipik . Pour information, j'ai recherché et corrigé tous les cas de formatnum précédés ou suivis de chiffres (hors cas particulier des années et des codes). --FDo64 (discuter) 30 septembre 2021 à 23:19 (CEST)

Rassemblement pour la République

Bonjour, je ne sais pas comment et où poster cette demande, mais est-ce que quelqu'un pourrait revérifier la forme de cet article Rassemblement pour la République. Merci à vous, Rassemblement pour la République--2A01:E0A:A04:E270:7421:A617:D984:36D1 (discuter) 9 novembre 2021 à 14:19 (CET)

Détection faux liens bleus

Bonjour, une méthode assez "vicieuse" pour contourner la création de liens rouges en particulier vers des articles supprimés en WP:PàS a fait son apparition, consistant à forcer la couleur bleue sur le lien en insérant une balise "span color", par exemple ici ou encore ici. Est-il possible d'activer la détection de l'erreur 526 pour détecter ce genre de contournement de décision communautaire ou de mauvaise syntaxe, ou plus généralement un détection de l'utilisation de balises span inutiles ou incorrectes ? -- Speculos ^✉ 28 novembre 2021 à 15:10 (CET)

Salut @Speculos, c'est évidemment proscrit. Cette IP en question n'est rien d'autre qu'un banni : Wikipédia:Faux-nez/Brigittenouasse.

A mon avis, ce genre de cas est vraiment isolé, en dehors de lui, je n'ai jamais vu de telles pratiques. LD (d) 28 novembre 2021 à 15:22 (CET)

 LD : Oui je sais bien qu'il s'agit du faux-nez de Brigittenouasse, et je l'ai d'ailleurs bloqué pour cette raison. Mais connaissant l'obstination de ce pénible, il est fort probable qu'il réapparaisse sous d'autres IP, il serait souhaitable de pouvoir le détecter si possible. -- Speculos ^✉ 28 novembre 2021 à 15:25 (CET)

@Speculos, j'ai corrigé le filtre qui lui est dédié pour interdire ce genre de tour de passe-passe. Lorsque tu le croises, n'hésite pas à intervenir sur WP:BF (section du filtre 361 ou 363), on mettra à jour. (et merci pour le blocage, je n'avais pas vu). LD (d) 28 novembre 2021 à 15:35 (CET)

Ceci dit, il serait intéressant de corriger certains span comme mentionné, par ex. par une légende quand c'est possible.

+13.000 cas à vérifier. LD (d) 28 novembre 2021 à 15:59 (CET)

Merci pour le tuyau, si on limite à span style="color on réduit la recherche à 4100 cas, et on peut filtrer sur la couleur recherchée si nécessaire. -- Speculos ^✉ 29 novembre 2021 à 16:36 (CET)