Discussion Wikipédia:AutoWikiBrowser/Typos/Archives 2013

Typographie du %

Bonjour,

AWB applique une règle anglaise de typographie en supprimant l'espace devant les "%". Comment faire en sorte qu'AWB applique la règle française, en maintenant cet espace et en le rajoutant si nécessaire ?

Merci pour votre aide ! --M0tty ^{[Plaidoyers et jérémiades]} 4 janvier 2013 à 12:42 (CET)

Peut-être en utilisant {{unité}}. JackPotte ($♠) 4 janvier 2013 à 13:05 (CET)

Apparemment, pas trop conseillé pour le modèle : Unité…

M0tty, la case est « Apply general fixes » de l'onglet « Options » est forcément cochée vu le cas que tu décris. T'est-elle nécessaire ? — Hawk-Eye (d) 4 janvier 2013 à 13:24 (CET)

Bah, c'est parce que j'utilise AWB pour justement faire ce genre de choses, du nettoyage et de la correction typographique sur des articles généralement peu suivis. Du coup, si je désactive le bouton, ça n'a plus beaucoup d'intérêt... --M0tty ^{[Plaidoyers et jérémiades]} 5 janvier 2013 à 19:03 (CET)

Bonjour. Je me permets d'intervenir car j'ai essayé d'élucider à plusieurs reprises cette anomalie. Il faut savoir en effet qu'AWB supprime cette espace de façon aléatoire, ce n'est pas systématique. la dernière fois que j'ai alerté la communauté AWB, c'était il y a quelques semaine ici, mais visiblement, le sujet n'intéresse personne et j'ignore même si le sujet a été remonté à qui de droit pour que qqn travaille à la correction à apporter. C'est bien dommage en effet. Cordialement. AntonyB (d) 5 janvier 2013 à 21:13 (CET)

A mon avis, pour demander une correction sur AWB, il vaut mieux poster un message sur en:Wikipedia_talk:AutoWikiBrowser/Bugs, plus de chances d'être lu par un développeur. --NicoV (d) 5 janvier 2013 à 22:13 (CET)

Attention' : je suis tombé plusieurs fois sur des pages où des URL ont été brisées par des remplacements automatiques de typographie du % (par exemple ajout d'un espace entre un chiffre et le signe %, ce qui n'est valide QUE dans le texte visible mais pas dans des URL comme celles contenant des query-strings). Exemple : les URLs avec query-strings archivées vers wikiwix qui réencode l'URL complète, peut nécessiter des signes % pour leur réencodage. Exemple de liens rompus: les archives de pages IGN sur les communes ; il y a d'autres cas et c'est difficile à repérer ensuite, surtout si l'URL modifiée affiche un résultat (mais pas forcément celui attendu).

Bref AWB ne doit pas toucher aux URL des liens externes, et les tentatives de remplacement automatique de typographie autour du signe % sont plutôt à éviter si vous ne savez pas repérer les URLs danns le wikicode, et aussi à éviter dans les paramètres passés aux modèles, sauf si vous savez que le modèle utilise le paramètre uniquement pour du texte visible et pas pour générer un lien). Même remarque au sujet de la typographie française d'autres ponctuations mais qui sont utilisées de façon spécifique dans les URL comme ?, : ou &. AWB devrait aprendre à reconnaitre les URL pour ne jamais y toucher, sauf avec des règles spécifiques de réécriture des URLs. Merci. Verdy p (discuter) 3 décembre 2013 à 22:06 (CET)

Règles formatnum

Bonjour, pourrait-on modifier les 3 règles formatnum pour qu'elles fonctionnent aussi quand le caractère après le nombre est un retour à la ligne et pas seulement une espace ou une parenthèse fermante ? Ce serait en particulier utile pour les nombres dans des tableaux. --NicoV (d) 5 janvier 2013 à 15:08 (CET)

Fait : a priori, je ne vois pas de faux-positifs que ça pourrait engendrer. Hawk-Eye (d) 5 janvier 2013 à 15:15 (CET)

Merci ! --NicoV (d) 5 janvier 2013 à 16:46 (CET)

Règlementaire et réglementairement.

Réglementaire est transformé en règlementaire, mais règlementairement est transformé en réglementairement. Cette différence de traitement me surprend. Selon Wiktionnaire les deux mots s'écrivaient avec un é avant la réforme de 1990, et avec un è depuis. Je serais plutôt partisan du è, mais l’absence de modification me va aussi.

— Zebulon84 (d) 5 février 2013 à 15:22 (CET)

Mieux vaut ne pas prendre position pour une orthographe plutôt qu'une autre quand les deux sont justes. JackPotte ($♠) 27 avril 2013 à 16:40 (CEST)

J'ai supprimé ces règles. — Zebulon84 (d) 27 avril 2013 à 23:31 (CEST)

,<br />

Faut-il mettre une espace entre une virgule et un retour-ligne ? Si ce n'est pas nécessaire, est-il possible d'adapter la règle ?

— Zebulon84 (d) 5 février 2013 à 15:30 (CET)

Cela revient au même, il serait dommage de complexifier pour un résultat similaire. JackPotte ($♠) 27 avril 2013 à 16:41 (CEST)

Si les deux sont acceptables, le but est d'éviter de faire des modifications inutiles sur les pages en s'abstenant de suggérer une correction, même si ça complexifie légèrement l'expression régulière ici. Je vais voir si je peux trouver une solution « simple ». — Zebulon84 (d) 27 avril 2013 à 22:50 (CEST)

La balise &lt:br /> génère un saut de ligne en HTML, mais le texte seul extrait du DOM (sans HTML) ne contient aucun saut de ligne. C'est gênant pour traiter des données en copier-coller ou pour exploiter une table de données venant d'une page Wiki dans un tableur car il faut reconstituer les espaces manquantes là où on n'a non plus aucun saut de ligne.

C'est gênant aussi pour l'indexation par pas mal de moteurs (même si le bot Google reconnait les balises br en les assimilant à une espace pour éviter de fusionner deux mots, tous les moteurs de recherche ne le font pas forcément car c'est compliqué d'analyser le balisage HTML et son style associé).

C'est gênant aussi pour un certain nombre de lecteurs d'écran (pour aveugles ou malvoyants) qui souvent ignorent le balisage HTML dans leur rendu Braille ou vocal : la balise br n'est pas en elle-même un espace blanc (comme peut l'être un véritable saut de ligne ou un paragraphe ou un bloc HTML, elle ne sépare pas deux mots, c'est juste un saut de ligne forcé pour la seule présentation visuelle (affiché sur écran ou projecteur, ou imprimé) et qu'on pourrait même insérer au milieu d'un même mot trop long pour tenir entier sur une ligne compacte. La balise en elle-même n'a aucune valeur sémantique.

Pour ces raisons il vaut mieux ajouter une espace (préférablement après la balise <br />), sans aucun saut de ligne avant ou après dans le wikicode (sauf s'il n'y a pas d'autres caractères non blancs après). Cette espace ajoutée après la balise est conservée dans le code HTML généré par MediaWiki, et restera conservée aussi dans le DOM (la propriété .innerText d'un élément), alors qu'un rendu HTML l'ignorera après la balise br (sauf en cas de style CSS "white-space: preserve", un style rarement voire jamais utilisé sur Wikipédia, car pour styler du code source, on n'utilise pas non plus la balise <br /> pour sauter une ligne au milieu du texte dans une balise <pre>...</pre> destinée à mettre en forme du code source préformaté), tel que le retournera le DOM (la propriété .innerHTML d'un élément). Verdy p (discuter) 3 décembre 2013 à 22:31 (CET)

Virgule et espace insécable

Bonjour,

Serait-il possible de modifier la première règle dans Wikipédia:AutoWikiBrowser/Typos#R.C3.A8gles_orthographiques_g.C3.A9n.C3.A9rales pour qu'une virgule suivie d'une espace insécable ne soit pas détectée comme une erreur, et surtout que le remplacement proposé ne soit pas virgule suivie d'une espace suivie d'une espace insécable ? A priori, l'espace insécable pourrait être utile devant « etc. » par exemple. Demande initiale Discussion_Wikipédia:WPCleaner#Fautes_:_espacement. --NicoV (d) 27 avril 2013 à 14:25 (CEST)

Pourquoi ne pas remplacer plus globalement toute chaine " &nbsp;" par " " ? JackPotte ($♠) 27 avril 2013 à 16:49 (CEST)

Les espaces ne seraient plus insécables dans ce cas, ce qui n'est pas le but recherché. Ou alors je n’ai pas compris… --NicoV (d) 27 avril 2013 à 16:54 (CEST)

Cela n'engage que moi mais je crains que l'utilisation de &nbsp; rebute plus les nouveaux éditeurs que ce qu'il enchante de lecteurs puristes. JackPotte ($♠) 27 avril 2013 à 17:54 (CEST)

Ca risque de faire débat, et je pense que les remplacements qui peuvent présenter une polémique ne doivent pas être listés… Par contre, est-ce que l'on peut quand même modifier la règle pour qu'elle ne propose pas de modifier la virgule suivie d'une espace insécable ? Et ensuite créer une règle pour remplacer espace + espace insécable par espace (et dans l’autre sens) ? Proposition d'écriture des règles:

<Typo word=", " find="(?<=[^0-9 {]) *,(?!\s)" replace=", " /> <!-- Virgule sans espace après -->

<Typo word=", " find="(?<=[^0-9 {]) *,( |&nbsp;) +(?!\s)" replace=", " /> <!-- Virgule avec plusieurs espaces -->

<Typo word="espace + espace insécable" find=" &nbsp;" replace=" " />

<Typo word="espace insécable + espace" find="&nbsp; " replace=" " />

--NicoV (d) 28 avril 2013 à 13:09 (CEST)

Cela me semble correct, mais je ne trouve pas la signification de ton "!". JackPotte ($♠) 28 avril 2013 à 14:32 (CEST)

Celui dans (?!\s) ? Ca vient de l’expression actuelle, c'est un groupe non capturant qui indique qu'il ne doit pas y avoir de caractère blanc après l’expression. --NicoV (d) 28 avril 2013 à 14:38 (CEST)

Merci, cette syntaxe doit être propre au C++, je vais tenter de l'ajouter dans mon libre b:Catégorie:Expression rationnelle. JackPotte ($♠) 28 avril 2013 à 16:03 (CEST)

Pas que le C++, aussi le Java (cf. Wikipédia:Liste_de_fautes_d'orthographe_courantes#Explications_d.C3.A9taill.C3.A9es qui explique la syntaxe pour le modèle {{Suggestion}} qui est utilisée par WPCleaner en Java). Les expressions régulières C++ et Java sont quasiment identiques, j’ai l'impression qu'il y a juste quelques possibilités supplémentaires en Java (possibilité de faire quantification réticente au lieu de gloutonne).

Je mets en service les expressions régulières proposées et je les teste. --NicoV (d) 28 avril 2013 à 16:28 (CEST)

Classes de caractères d'alphabets non latins

Bonjour,

Dans la mesure où [a-z] ne capte que les 26 lettres de l'alphabet latin, y a-t-il un moyen de capturer également des lettres d'autres alphabets — sinon les écrire une à une dans une classe de caractères ou les repérer avec '.' ?

Merci d'avance, Automatik (d) 1 mai 2013 à 19:10 (CEST)

Avec .*, ou bien par exclusion d'un autre caractère (ex : [^}]*). JackPotte ($♠) 1 mai 2013 à 19:48 (CEST)

Merci. Ça confirme ce que je pensais ; repérer tous les caractères des alphabets grec, cyrillique, arabe et hébreu uniquement impliquerait donc de les écrire un à un dans une classe de caractères. Automatik (d) 1 mai 2013 à 19:53 (CEST)

\w devrait représenter n'importe quel lettre ou chiffre, cela inclue probablement les caractères non latin : à tester. — Zebulon84 (d) 2 mai 2013 à 08:34 (CEST)

Ca dépend des moteurs de regexp je crois. Pour Java, c'est non à priori. Pour .Net, peut-être. --NicoV (d) 14 mai 2013 à 11:18 (CEST)

Avec AWB, \w matche bien tout caractère, même d'alphabets non latins. Automatik (d) 14 mai 2013 à 17:48 (CEST)

Questions sur un regex

Bonjour,

J'aimerais vous demander, dans la ligne suivante :

<Typo word="espace avant ref" find="([^|]) <ref" replace="$1<ref" />

est-ce normal que le pipe « | » n'ait pas besoin d'être échappé pour être exclu de la classe de caractères ?

En vous remerciant par avance,

Cordialement, Automatik (d) 10 mai 2013 à 20:28 (CEST)

Bonjour, pour répondre à ta question, j'aurai aussi utilisé l'échappement personnellement, mais force est de constater qu'en testant, cela fonctionne aussi sans… — Hawk-Eye (d) 10 mai 2013 à 21:22 (CEST)

Merci, c'est probablement parce que l'alternative avec « | » n'est pas possible dans une classe de caractères. Apparemment pour ton lien, tu as volontairement enlevé le protocole http: qu'il y avait devant, du coup il n'est pas fonctionnel pour tout le monde, puisqu'il n'est pas fonctionnel en https: par exemple. Enlever le protocole n'est valable à priori que pour l'ensemble des projets Wikimedia, qui permettent la navigation en http: tout comme en https:.

À part ça, j'aurais une question sur ce regex tester, comment effectuer les tests une fois qu'on a correctement rempli les champs ?

Cordialement, Automatik (d) 11 mai 2013 à 23:37 (CEST)

1. Pour qui ces liens ne fonctionnent pas ? Je n'ai jamais entendu un tel bug.
2. Le résultat apparait en jaune en temps réel. JackPotte ($♠) 12 mai 2013 à 00:26 (CEST)

Pour le 1. : le serveur www.regexpal.com ne supporte pas l’https, d’où problème pour ceux qui consultent WP en https. — Ltrl G^☎, le 12 mai 2013 à 00:59 (CEST)

Oui, c'est le cas par exemple quand on utilise HTTPS Everywhere, un module complémentaire de Firefox. D'où l'utilité de spécifier le protocole pour des serveurs qui ne supportent pas le https:, ça force à ce que le lien soit bon. Automatik (d) 12 mai 2013 à 01:32 (CEST)

Merci pour l'explication du fonctionnement, je confondais à tort avec un Find and replace. Automatik (d) 12 mai 2013 à 01:35 (CEST)

Classes de caractère vides

Bonjour,

J'aurais à nouveau une question, car apparemment ce que j'ai pu lire sur les classes de caractère ne recouvre pas certains cas. Par exemple, pour le regex suivant :

\[\[(Image:[^][|]+)\|([^][]*(\[\[[^][]+\]\][^][]*)*)\]\]

Je me demandais :

• Écrire [^][xyz] (quels que soient x, y et z) est-il équivalent à écrire [^xyz] ?
• Que signifient [^][] ?
  • Quand on écrit utilise ce regex avec comme Replace « B » pour remplacer le texte « a », ça renvoie B, tandis que [^][]* renvoie BB et [^][] renvoie B. C'est déroutant.

Quelqu'un saurait-il expliquer ce comportement de ce type de regex ?

En vous remerciant par avance, Automatik (d) 12 mai 2013 à 16:07 (CEST)

Bonjour

[^][xyz] et [^xyz] sont différents. La 2e veut dire 1 caractère différent de x, y et z. La 1e veut dire un caractère différent de ], [, x, y et z.

[^][] veut dire un caractère différent de ] et [. Appliqué à a, ça donne bien B.

[^][]* veut dire de zéro à n caractères différents de ] et [. Je pense que le résultat est doublé car l'expression matche sur a et sur après a (explication à confirmer). --NicoV (d) 12 mai 2013 à 16:21 (CEST)

Merci, ça devient tout de suite plus clair Cordialement, Automatik (d) 12 mai 2013 à 16:35 (CEST)

Règle n°

Bonjour,

Telle qu'est écrite actuellement la règle "n°", elle détecte des textes tels que "loi n°83-581" et le remplacement associé est "loi {{numéro|83}}-581". Est-ce correct ? Ne vaudrait-il mieux pas proposer "loi {{numéro|83-581}}" ou alors ne pas le détecter ? --NicoV (d) 13 mai 2013 à 20:15 (CEST)

Bonjour,

Vu le code du modèle, remplacer par "loi {{n°}}83-581" me paraît tout aussi correct, mais ta solution me va aussi. Rien d'incorrect apparemment pour le code actuel, si ce n'est qu'il est insensé àmha. À moins qu'il y ait des faux positifs, sa détection me paraît utile par contre (respect des conventions typographiques).

Cordialement, Automatik (d) 13 mai 2013 à 21:08 (CEST)

Détail sur les regex

Bonjour,

Vaut-il mieux, pour les performances, écrire ([jJ]) ou (j|J) ? Je me posais la question aussi pour ([a-z]?) ou ([a-z])?

Merci par avance pour votre assistance, Automatik (d) 13 mai 2013 à 21:11 (CEST)

Bonjour

Pour les 2 premières, je ne suis pas sur qu'il y ait de différence de performance entre les deux expressions. Dans WP:FAUTE, la deuxième forme est utilisée, surtout car elle est plus lisible à mon avis.

Pour les 2 dernières, je crois qu'elles ne sont pas tout à fait équivalentes en ce qui concerne le remplacement (existence ou non de $1). Je préfère la première forme (? dans le groupe).

--NicoV (d) 14 mai 2013 à 11:15 (CEST)

Proposition concernant « innatendu »

<Typo word="Inatendu" find="\b(I|i)nn?att?endu(e|es|)\b" replace="$1nattendu$2" />

Wikipédia:Le_Bistro/21_mai_2013#Cacographie

--Orikrin1998 (+) ^{→blablatoir←} 21 mai 2013 à 18:55 (CEST)

Voilà le diff de correction.

Les erreurs corrigées, dans l'ordre :

1. \ en \b (qui indique le début d'un mot) → je pense que c'était une erreur d'étourderie ;
2. (Ii) en (I|i) : attention, il faut soit (I|i) soit [Ii] mais pas (Ii) qui indique que je mot commence par « Ii », ce qui est totalement faux ^^ ;
3. t? en tt? → le choix doit se faire entre « innatendu » et « innattendu » (et pas entre « innaendu » et « innatendu ») ;
4. (e|es) en (e|es|) → le but est d'inclure également « innattendu » (et pas seulement « innattendue » et « innattendues »).

Voilà, maintenant, je pense que tu peux l'insérer .

— Hawk-Eye (d) 21 mai 2013 à 20:18 (CEST)

PS : je sais écrire « inattendu » correctement, hein, c'est juste pour les exemples que je l'écris mal orthographié…

1. J'ai copié une ligne qui existait dans la page ; elle devait venir de là je pense...
2. Je ne savais pas.
3. J'ai changé au dernier moment ! [1]
4. Bon, ben j'ai pas osé mettre ça. ^^

Merci de tes corrections ! --Orikrin1998 (+) ^{→blablatoir←} 21 mai 2013 à 20:40 (CEST)

@Hawk-Eye : Tu avais oublié un t dans le replace apparemment [2], mais pas de problème pour la version mise en ligne. Automatik (d) 21 mai 2013 à 20:45 (CEST)

Je m'étais trop focalisé sur la regexp (find) en tant que telle… C'est donc l'histoire du correcteur corrigé . Merci — Hawk-Eye (d) 21 mai 2013 à 21:58 (CEST)

J'étais tellement obnubilé par le double N que je n'ai même pas fait gaffe aux T ! --Orikrin1998 (+) ^{→blablatoir←} 22 mai 2013 à 11:12 (CEST)

Sens de ?+

Bonjour,

Quelqu'un saurait-il m'expliquer le sens de ?+ ? On en trouve un ici. Cordialement, Automatik (d) 3 juin 2013 à 23:22 (CEST)

Erreur de ma part, j’avais oublié que .Net ne gérait pas le "+" possessif. --NicoV (d) 3 juin 2013 à 23:30 (CEST)

Merci pour cette réponse rapide. Automatik (d) 3 juin 2013 à 23:43 (CEST)

Propositions

Siècle

Bonjour.

Je propose une nouvelle règle pour les siècles : corriger les erreurs de rédaction du type « XX° » ou « XX° siècle » comme j'en ai corrigées ici.

Je ne maîtrise pas assez le langage de nos logiciels pour proposer la ligne nécessaire, ni pour savoir si c'est réalisable (même si je le pense).

Cordialement, --Orikrin1998 (+) ^{→blablatoir←} 10 juin 2013 à 14:29 (CEST)

De ce que je vois sur Wikipédia:AutoWikiBrowser/Typos#Si.C3.A8cles, le cas avec ce caractère semble déjà géré non ? -- Chico (blabla) 10 juin 2013 à 20:32 (CEST)

J'ai passé l'article en question sur WPC, mais le logiciel ne m'a pas proposé le remplacement de la chaîne de caractères avec ce symbole. J'en déduis donc qu'il ne le gère pas. --Orikrin1998 (+) ^{→blablatoir←} 10 juin 2013 à 20:36 (CEST)

J'avoue pour ma part ne pas avoir compris pourquoi ces règles ne marchent pas. Où dans quel cas elles marchent. J'en propose des nouvelles dans quelques instants, qui elles semblent marcher (du moins elles marchent dans le Normal settings). Automatik (d) 10 juin 2013 à 22:05 (CEST)

C'est peut être l'utilisation des « " » dans l'expression régulière qui pose problème pour la lecture des règles existantes par AWB ou WPCleaner. Je ne suis pas sur qu'elles respectent la syntaxe XML actuellement. --NicoV (d) 10 juin 2013 à 22:53 (CEST)

J'ai essayé d'enlever les balises et par la même occasion les guillemets (échappés, pourtant), mais ça n'avait rien changé avec AWB ; j'ai pu mal réaliser mon test cela dit…

Cela dit, il paraît possible que ce soient la syntaxe qui rend ces règles obsolètes, vu la couleur noire une fois les balises <sup> refermées.

Toutefois est-il que le cas qu'expose Orikrin n'est pas prévu par cette liste, car les règles prévues actuellement ne gèrent pas systématiquement un chiffre romain suivi d'un o en exposant par le modèle siècle : il y aurait trop de faux positifs. Elle demande qu'il y ait au moins un "s." sinon "siècle" après le "??°". Automatik (d) 10 juin 2013 à 23:03 (CEST)

Les regex déjà présents ne semblant pas faire effet, j'ai essayé d'en écrire de nouveaux (mais moins complets que ce qu'essayait de faire ceux qui ne marchent pas — ce sera toujours possible de compléter au besoin cela dit, c'est un premier jet).

Voilà comment je procèderais pour ma part :

Première étape : chercher des faux positifs

• « volume III, V° Péculat, » — (Nicolas Fouquet#cite note-63)
• « n°II° » — (Jean Racine#cite ref-8)
• « XIII° s. - XIV° s. » — (Jean de Morigny, intro) (faux positif puisqu'on aurait deux fois le mot siècle affiché avec deux {{s-}}, alors qu'il n'en faudrait qu'un placé à la fin)
• [[Fichier:Avignon (palais des papes) gravure anonyme du début du XIX° s.jpg|…]] (ça existe, et complique donc les regex à utiliser qui doivent écarter toute présence de fichier: et apparentés (Fichier, image, etc.) avant le texte à remplacer, du moment que ces deux syntaxes ne sont pas séparées par un pipe « | »)

Deuxième étape : Déterminer les cas à gérer en considération des faux positifs

Vu les faux positifs ci-dessus, gérer un siècle seul (??°) ne semble pas évident, par contre il est possible de gérer les cas où le mot siècle (ou une de ses abréviations) est explicité après le nombre en chiffres romains (1). De même il est possible de gérer les cas où deux siècles se suivent séparés par un tiret ou par une des conjonctions et et ou, sachant que avec ou, siècle ne doit pas prendre de s, alors qu'avec et et le tiret, si (2).

Troisième étape : écrire les regex

Les règles suivantes pourraient peut-être convenir :

Gestion du cas (1), en deux étapes :

Le siècle est "I" :

<Typo word="I° siècle" find="I°(?: *siècle| *s\.?)(?!\.? *(?:-|et|ou))(?<![XIV]I°(?: *siècle| *s\.?))" replace="{{s-|I|er}}" />

ou non :

<Typo word="??° siècle" find="([XVI]{2,5}|V|X)°(?: *siècle| *s\.)(?!\.? *(?:-|et|ou)|\S)(?<!(?:-|et|ou)\s*([XVI]{2,5}|V|X)°(?: *siècle| *s\.))" replace="{{s-|$1}}" />

Gestion du cas (2), en quatre étapes (deux pour le cas -/et, et deux pour le cas ou, selon à chaque fois que le premier siècle est "I" ou non) :

Les deux siècles sont séparés par un tiret ou par et.

Le premier siècle est "I" :

<Typo word="I° - ??° siècles" find="I°(?: *siècle| *s\.?)? *(-|et) *([XVI]{1,5})°(?: *siècles?| *s\.?)(?<![XIV]I°(?: *siècle| *s\.?)? *(?:-|et) *[XVI]{1,5}°(?: *siècles?| *s\.?))" replace="{{sp-|I|er|-|$2|e|s}}(?<![XVI])" />

Pour des siècles quelconques :

<Typo word="??° - ??° siècles" find="([XVI]{2,5}|V|X)°(?: *siècle| *s\.?)? *(-|et) *([XVI]{2,5}|V|X)°(?: *siècles?| *s\.?)" replace="{{sp-|$1|e|-|$2|e|s}}" />

Les deux siècles sont séparés par ou.

Le premier siècle est "I" :

<Typo word="I° ou ??° siècle" find="I°(?: *siècle\b| *s\.?| *s\b)? *ou *([XVI]{1,5})°(?: *siècles?\b| *s\.?| *s\b)(?<![XIV]I°(?: *siècle\b| *s\.?| *s\b)? *ou *[XVI]{1,5}°(?: *siècles?\b| *s\.?| *s\b))" replace="{{sp-|I|er|ou|$1|e}}" />

Pour des siècles quelconques :

<Typo word="??° ou ??° siècles" find="([XVI]{2,5}|V|X)°(?: *siècle\b| *s\.?)? *ou *([XVI]{2,5}|V|X)°(?: *siècles?\b| *s\.?)" replace="{{sp-|$1|e|ou|$2|e}}" />

J'ai pu faire des erreurs, alors il ne faut pas hésiter à tester ces regex, et à les corriger au besoin. Note : voici une liste de cas qui marchent. J'ai essayé de faire en sorte que les regex ne rentrent pas en conflit. Les remplacements dans les fichiers sont également bien évités, sauf quand il ne s'agit pas du nom du fichier, mais de la légende (ou du alt= par exemple), d'où le remplacement final. Il va sans dire que, le regex étant lourd, les tests que j'ai réalisés peuvent s'avérer être lacunaires à l'avenir, d'où l'intérêt de systématiquement vérifier les corrections typographiques réalisées avec la liste de typos d'AWB. Automatik (d) 10 juin 2013 à 23:40 (CEST)

Tu peux simplifier ces regexp: AWB ou WPCleaner ne font pas de vérification d'orthographe dans les noms de fichiers car rien n'oblige à ce que les noms de fichiers soient en français. AWB ne fera pas non plus de vérification dans les légendes, tandis que WPCleaner le fera. --NicoV (d) 11 juin 2013 à 00:01 (CEST)

Merci, effectivement je me demandais s'il fallait vraiment faire attention à ça, alors merci pour la précision. J'ai simplifié en conséquence. Automatik (d) 11 juin 2013 à 00:39 (CEST)

Nombres

Nouvelle proposition : remplacer les nombres non formatés de plus de trois chiffres, espacés d'un point, comme 250.000. --Orikrin1998 (+) ^{→blablatoir←} 10 juin 2013 à 15:07 (CEST)

Pourquoi pas, mais attention au remplacement proposé : il est fort probable que 250.000 doive être remplacé par {{formatnum:250000}}, mais selon les cas 123.456 pourrait être remplacé par {{formatnum:123456}} ou par {{formatnum:123.456}}. --NicoV (d) 9 juillet 2013 à 19:08 (CEST)

Tu sous-entends que cette modification est préférable pour un logiciel semi-automatique plutôt qu'automatique, comme WPC ? Ce dernier a l'avantage de faire des propositions... --Orikrin1998 (+) ^{→blablatoir←} 10 juillet 2013 à 12:19 (CEST)

C'est sur qu’en automatique, ce n'est pas possible sans gros risque. Je ne sais pas comment AWB réagit si on lui donne deux règles avec la même expression régulière mais avec des remplacements différents. Côté WPCleaner, c'est prévu, le format pour définir des règles permet justement de définir plusieurs remplacements possibles. --NicoV (d) 10 juillet 2013 à 12:42 (CEST)

Il est bien évident que ce cas ne peut pas être traité au automatique. Pour moi, la bonne correction dans ce cas, c'est du 50-50 entre {{formatnum:123456}} et {{formatnum:123.456}}. AWB propose l'une des 2 (c'est très bien ainsi, parce que ça met en évidence le cas), mais à l'utilisateur de vérifier unitairement, pour valider ou rectifier. Zetud (d) 10 juillet 2013 à 22:31 (CEST)

Tester ses regex en ligne

Bonjour,

Autant tester les regex avec le testeur d'AWB est simple, autant le site vers lequel pointe un lien de l'intro de Wikipédia:AutoWikiBrowser/Typos (http://lumadis.be/regex/index.php) ne semble pas avoir la même syntaxe de regex que celle d'AWB. Ce lien est-il remplaçable par mieux ? Automatik (d) 10 juin 2013 à 23:10 (CEST)

D'après le site, il s'agit d'expressions régulières pour du PHP. Je ne sais pas à quel point c'est différent. Sur WP:FAUTE, il y a un lien vers un testeur, mais pour du Java: les syntaxes sont assez proches de celle d'AWB (WPCleaner s'en sort plutôt bien avec les regexp d'AWB) mais il y a quand même quelques différences sur les cas compliqués. --NicoV (d) 11 juin 2013 à 00:06 (CEST)

En fait, le site proposé permet de choisir le langage de développement. Je pense que c'est .Net pour AWB. --NicoV (d) 11 juin 2013 à 00:07 (CEST)

Merci pour la réponse. Toutefois n'ai-je pas réussi à faire fonctionner ma regex (dispo ici) en sélectionnant .NET. Automatik (d) 11 juin 2013 à 00:47 (CEST)

Mois et année

Résolu.

Bonjour,

La 2^e règle sur les dates fait actuellement que « {{date||mois|année}} » est proposé en remplacement de « [[mois année]] » (en tout cas dans WPCleaner, car je ne suis pas certain qu'AWB fasse cette proposition vu qu'il s'agit de liens internes). Est-ce que ce remplacement est réellement voulu ?

En ce qu'il me concerne, je ne fais jamais ce remplacement car je ne vois pas l'intérêt de remplacer un lien interne simple par un appel à un modèle. Qu'en pensez-vous? --NicoV (d) 23 juin 2013 à 03:06 (CEST)

Ce serait utile pour convertir les 1 et 01 en janvier afin d'uniformiser les dates. JackPotte ($♠) 23 juin 2013 à 14:14 (CEST)

Pas cette règle, elle ne s'occupe que des mois et des années, pas des jours. Il y a d'autres règles qui gèrent les jours, et pour elles je trouve vraiment normal de proposer {{date}}. Pour la 2e règle, on parle des liens du genre juin 2013 pour lesquels une proposition de remplacement par juin 2013 est faite: je trouve cette proposition inutile, le lien interne me semblant tout à fait correct.

Edit: en relisant, je pense avoir mal compris ta remarque, mais cette règle ne s'applique pas non plus, elle ne s'applique qu'aux mois en toutes lettres. --NicoV (d) 23 juin 2013 à 15:32 (CEST)

J'ai modifié la 2^e règle pour ne plus détecter des constructions comme juin 2013. Les autres formes sont toujours détectées. Si quelqu'un pense que ça avait une réelle utilité, n'hésitez pas à la remettre comme avant. --NicoV (d) 24 juin 2013 à 04:57 (CEST)

Précédent

Résolu.

Bonjour,

Je pense que la règle "précédent" est fausse. En effet, "précédent" (article) et "précèdent" (verbe conjugué) existent tous les deux. Hors, la règle détecte le deuxième comme une faute. --NicoV (d) 8 juillet 2013 à 21:03 (CEST)

Exact. Dans les 20 % de faux-positifs à mon avis. Zetud (d) 8 juillet 2013 à 22:06 (CEST)

Je proposerais la modification suivante :

<Typo word="précédent" find="\b(p|P)r[eéè][cs]{1,2}[eéè]d(a|e)nt(e?s?)\b(?<![pP]récèdent)" ... />

Automatik (d) 8 juillet 2013 à 22:23 (CEST)

Ca me semble bien. --NicoV (d) 9 juillet 2013 à 00:03 (CEST)

Mis en place. --NicoV (d) 9 juillet 2013 à 19:02 (CEST)

<br> ou <br />

Depuis un an wikipédia utilise le doctype HTML5.

HTML5 recommande l'utilisation simple de <br>, contrairement au xhtml qui recommande <br /> (Cf. w3schools et la dernière candidate recommandation du HTML5). Et comme de toute façon Media wiki transforme tout en <br />, je propose de supprimer la ligne :

<Typo word="<br />" find="</?[Bb][Rr] ?/?>" replace="<br />" />

Zebulon84 (discuter) 20 octobre 2013 à 13:37 (CEST)

Effectivement le XHTML définissait ce slash pour toutes les balises autofermantes : <area /> , <br /> , <hr /> , <img /> , <input /> , <link /> , <meta /> , <param />. Dont seul le break figure dans nos corrections.

HTML5 y a ajouté <wbr>, mais autant utiliser XHTML5 en ajoutant le slash dans tous ces exemples. JackPotte ($♠) 26 octobre 2013 à 16:04 (CEST)

Pourquoi devrait-on utiliser le XHTML ? C'est encore moins utile que les apostrophes courbes qui au moins se voient.

Par ailleurs la regexp actuelle transforme même les <br/> en <br /> alors que l'espace est optionnelle. Les spécification du xml 1.0 utilise même <br/> comme exemple d'élément vide [3].

Le HTML5 dit explicitement que les / sont optionnels pour les balises « void » [4].

Si on veut corriger le seul code effectivement erroné (</br>) et un peu éviter les récriminations contre les bot qui font des modification inutiles je propose :

<Typo word="
" find="</[Bb][Rr] ?>" replace="
" />

Zebulon84 (discuter) 10 novembre 2013 à 15:39 (CET)

Les "Fraçais" et les "Anglis", et sûrement d'autres...

Bonsoir,
Voici quelques corrections (dont j'ai, involontairement pour la première puis volontairement pour les suivantes, testé via le moteur de recherche la présence dans des articles) qu'il serait intéressant d'automatiser (ainsi que toutes les formes liées : masc./fém., sing./plur., conjug., ...) sur l'ensemble des systèmes de correction (WPCleaner, AWB, bots, etc.) :

• *fraçais > français
• *anglis > anglais (attention j'ai vu que certains "Anglis" sont par contre corrects par exemple, un nom de plante manifestement, donc il faudra voir comment s'arranger pour ne corriger que ce qui doit l'être).
• *ameriain > américain
• *novuelle, *nuovelle > nouvelle
• *autmobile, *autombile > automobile
• *a/Agleterre, *a/Anleterre, *a/Anlgeterre, *a/Angletere > Angleterre
• *a/Allmagne, *a/Allemange > Allemagne
• *e/Espange, *e/Espangol(e/s) > Espagne, e/Espagne (suivant les cas)
• *f/Frnace, *f/Farnce, *f/Fracne > France
• *talbeau, *tablaeu, *tableua > tableau
• *caractérisitque, *caractérsitique > caractéristique
• *uassi > aussi
• *m/Mardid > Madrid
• *l/Lisbone > Lisbonne

Il y en a encore des dizaines, centaines, voire milliers d'autres, mais comme je ne vais pas non plus passer la nuit à tester ça, je vous laisse cette liste pour le moment.
Cordialement. SenseiAC (discuter) 26 octobre 2013 à 02:08 (CEST)

Il n'y a que quelques occurrences (moins de 5 dans les cas testés) de ces erreurs, voire une seule qui plus est « normale » pour autmobile ou fraçais.... Zetud (discuter) 26 octobre 2013 à 09:55 (CEST)

Et ? J'en ai déjà corrigé qq unes, dont certaines listées ici (devrais-je m'en excuser ?), et puis ça évitera de devoir repasser derrière aux prochaines mêmes fautes de frappe, parce que quand je vois le nombre de fois qu'apparaissent ces fautes dans les discussions (PdD, Bistro, etc.) ce n'est pas qu'une ou deux… SenseiAC (discuter) 26 octobre 2013 à 17:56 (CEST)

Passez-vous de faire des corrections automatiques avec AWB dans les pages de discussions, tant qu'elles sont lisibles et qu'il n'y a pas d'ambiguïté (une discussion technique demandant de la précision peut justifier cette correction, mais pas automatiquement par un Bot ou un outil comme AWB qui n'est pas destiné à ces espaces de discussion). Tant pis si ceux qui discutent font des fautes de frappe, ce n'est souvent pas utile de corriger à la place de celui qui a écrit.

Si ces corrections sont réellement nécessaires (dans un bout de discussion contenant un exemple de code wiki, par exemple, ou mettre à jour la cible d'un lien vers une autre page sur le wiki ou vers un site externe ou dans une utilisation dans une discussion d'un modèle qui nécessite cette modification pour garder la discussion lisible quand le modèle a été modifié, ou nettoyer d'anciennes références à une page supprimée et remplacée par autre chose non équivalent), faites-les à la main (ou alors n'utilisez AWB que pour corriger vos propres discussions, à vos risques et périls, donc à vous de relire le résultat avant de valider). Verdy p (discuter) 3 décembre 2013 à 22:58 (CET)

Bonjour. Pour info, lorsque j'ai commencé à utiliser AWB (il y a longtemps, il est vrai), la première chose qu'on m'a apprise, c'est qu'on ne devait pas corriger les PDD. Cela aurait-il changé ? Cordialement. AntonyB (discuter) 3 décembre 2013 à 23:10 (CET)

Mr -> M.

Bonjour, aujourd'hui Mr ou Mr. est replacé par {{M.}}, mais il existe un modèle {{Mr.}} qui est plus approprié quand il faut garder l'abréviation anglaise. Êtes-vous d'accord pour revoir cette ligne ? -- Sisyph 24 décembre 2013 à 13:29 (CET)

<Typo word="M." find="\b(M|m)r\.?\b" replace="{{M.}}" />

Dac. Leag ⠇⠑⠁⠛ 24 décembre 2013 à 13:50 (CET)