Wikipédia:Bulletin du filtrage/2022

Une page de Wikipédia, l'encyclopédie libre.

Bienvenue à Tractopelle-jaune[modifier le code]

Hello nous accueillons Tractopelle-jaune,

Bienvenue ! Tu trouveras la plupart des pages utiles dans le {{Navigation filtres}} et certaines réponses dans le guide suprême. Au besoin, nous essayerons de répondre à tes interrogations ici ou en privé.

Bien à toi, LD (d) 20 janvier 2022 à 20:40 (CET)Répondre[répondre]

Brigittenouasse : créations en chaîne[modifier le code]

Notification Jules*, LD et Bédévore : Petite alerte : si vous tombez sur un nouveau compte de BN, elle a trouvé une nouvelle technique : elle crée des comptes à la chaîne grâce à la fonction créateur de compte. Ca fait deux fois que je le vois déjà : il faut donc bloquer tous les comptes liés. Je viens de bloquer Zukolsa (d · c · b) qui a été créé par MartySako (d · c · b) qui a été créé par Sawen123456 (d · c · b). Ce même Sawen123456 (d · c · b) a créé 5 autres comptes donc j'en suis à 8 blocages. Il faut remonter les logs des journaux de création de comptes... 'toff [discut.] 20 janvier 2022 à 18:11 (CET)Répondre[répondre]

Ok, merci de l'info @Supertoff ! — Jules* Discuter 20 janvier 2022 à 18:13 (CET)Répondre[répondre]
Et encore un nid de 3 'toff [discut.] 20 janvier 2022 à 18:20 (CET)Répondre[répondre]
Ah, en effet… — Jules* Discuter 20 janvier 2022 à 18:20 (CET)Répondre[répondre]
Hello @Jules* & @Supertoff : Spécial:Filtre antiabus/370 me semble approprié. Par contre, en dehors de la journalisation, j'ignore ce qui ferait consensus en termes d'application. LD (d) 20 janvier 2022 à 18:24 (CET)Répondre[répondre]
Miaourci @Supertoff que de fourbasseries ! OpenMoji-color 1F63E.svg Quel pénible chronophage, faut passer son temps à bloquer les avatars au lieu de bosser sur autre chose. soupir Bédévore Cat Cabal logo.svg [plaît-il?] 20 janvier 2022 à 18:30 (CET)Répondre[répondre]
Je me suis emballé, ça ne semble pas fonctionner comme attendu (en tout cas dans la fonction test). Il faudrait poser la question aux administrateurs d'interface : est-il possible de restreindre Spécial:Créer un compte aux IPs ou autopatrolled ou créateurs de compte (Smiley: triste) LD (d) 20 janvier 2022 à 18:34 (CET)Répondre[répondre]
Quoi que, j'en sais trop rien, cf. Spécial:Journal du filtre antiabus/3257446 qui est un cas positif àmha <=> Spécial:Journal/Ludovic sontia LD (d) 20 janvier 2022 à 18:36 (CET)Répondre[répondre]
Si, ça l'air de fonctionner, avec ta modif de 18 h 26, @LD. J'ai un peu restreint le filtre à notre cas actuel, mais à voir si pertinent. — Jules* Discuter 20 janvier 2022 à 19:28 (CET)Répondre[répondre]
Effectivement, ça a l'air de fonctionner : Souhana1234 (d · c · b) pris dans le mailles du filet ce qui m'a permis de trouver un nid :
'toff [discut.] 21 janvier 2022 à 11:48 (CET)Répondre[répondre]

Demande de fonctionnalités dans la liste de souhaits communautaire 2022[modifier le code]

Hello,

J'ai soumis trois demandes relatives aux filtres anti-abus, toutes liées à la lutte contre le harcèlement (mais la première, typiquement, sera utile plus largement) :

De manière générale, je trouve que la WMF n'investit pas assez dans l'amélioration de cet outil (Daimona Eaytoy travaille plus ou moins seul dessus, alors qu'il y a beaucoup à faire), pourtant essentiel à la fois dans la lutte contre le vandalisme et dans la lutte contre le harcèlement.

— Jules* Discuter 23 janvier 2022 à 11:20 (CET)Répondre[répondre]

Cet outil est pourtant très efficace (et pourrait l'être encore plus)
@Jules* On n'avait pas demandé aussi (pas moi) de pouvoir filtrer en fonction des catégories ? 'toff [discut.] 23 janvier 2022 à 11:56 (CET)Répondre[répondre]
Hello et merci, si : T285915 en juillet 2021. J'ai l'impression que, sauf si la demande provient d'une prise de décision, les moyens ne sont pas mis en oeuvre pour répondre aux demandes (mais je peux me tromper).
Pour lutter contre le harcèlement, je vois aussi une autre amélioration souhaitable : ajouter l'IP utilisée dans le log de "createaccount", visible que pour les CU/AFs. LD (d) 23 janvier 2022 à 12:37 (CET)Répondre[répondre]
N'hésitez pas à ajouter la demande sur la possibilité d'utiliser les catégories, @LD et @Supertoff !
Pour ton idée sur l'IP utilisée pour créer un compte, seuls les CU devraient y avoir accès.
— Jules* Discuter 23 janvier 2022 à 12:50 (CET)Répondre[répondre]

Collec de fausses truffes[modifier le code]

Bonjour Miaou Émoticône

Après avoir vu le chambard que nous sème ce type : Wikipédia:Vérificateur d'adresses IP/Requêtes/janvier 2022#Asf Diine, Asf Dine Ubé - 21 janvier, je viens de tripoter le filtre 309. N'hésitez pas à vérifier si j'ai fait comme il faut (ou bien si j'ai tout cassé). Cordialement, — Bédévore Cat Cabal logo.svg [plaît-il?] 24 janvier 2022 à 12:45 (CET)Répondre[répondre]

Salut. J'ai regroupé les détections. 'toff [discut.] 24 janvier 2022 à 16:39 (CET)Répondre[répondre]

Kiev/Kyiv[modifier le code]

Salut ! En faisant de la patrouille, je me rends compte que plusieurs personnes probablement bien intentionnées remplacent "Kiev" par "Kyiv", ce qui en l'état est contraire au principe de moindre surprise (voir aussi cette discussion sur la page de discussion de Kiev). Ne serait-il pas pertinent de créer un filtre pour prévenir les utilisateurs cherchant à effectuer ce remplacement ? Ils pourraient ainsi comprendre pourquoi il n'est pas adapté dans l'immédiat de procéder à un tel remplacement. Je peux en créer un, mais comme j'étais en long wikibreak je ne sais pas s'il est préférable d'en modifier un existant, ou d'en créer un ex nihilo. Toto Azéro suivez le guide ! 5 mars 2022 à 11:48 (CET)Répondre[répondre]

Notification Toto Azéro : salut. Je pense que tu pourrais l'inclure dans le filtre 123 actuellement dédié uniquement à Mahomet mais dont le titre correspond à ça. 'toff [discut.] 5 mars 2022 à 11:59 (CET)Répondre[répondre]
Sauf que le message du filtre est lui aussi dédié à Mahomet. 'toff [discut.] 5 mars 2022 à 12:02 (CET)Répondre[répondre]
J'ai hésité puis finalement créé le filtre 371 dédié, en ayant pris en compte :
  • qu'il y a des risques de faux positifs assez difficiles à détecter (eg. Kyiv Post)
  • que le filtre 123 interdit les modifications
  • qu'il faudrait alors rendre le message du filtre 123 générique, alors qu'il est déclenché fréquemment et que conserver un message spécifique me parait donc pertinent
Toto Azéro suivez le guide ! 5 mars 2022 à 16:19 (CET)Répondre[répondre]
Il vaut mieux effectivement ne pas interdire les modifications à cause des faux positifs et afficher un message (et peut-être baliser les modifications avec remplacement contraire au principe de moindre surprise ?).
Vu que le filtre 123 n'est pas générique, je l’ai renommé. — Thibaut (discuter) 5 mars 2022 à 16:31 (CET)Répondre[répondre]
Notification Supertoff et Thibaut120094 : L'un de vous peut-il créer une page pour afficher un message aux utilisateurs déclenchant le filtre ? Une proposition toute prête ici sur une page de mon espace PU. N'étant plus admin, je n'ai plus les droits. Toto Azéro suivez le guide ! 5 mars 2022 à 16:41 (CET)Répondre[répondre]
@Toto Azéro : Fait : MediaWiki:Abusefilter-warning-371, tout le monde est d'accord pour le balisage ? — Thibaut (discuter) 5 mars 2022 à 16:45 (CET)Répondre[répondre]
OK pour moi (NB : j'ai testé sur plusieurs pages dont Kiev, Crise diplomatique russo-ukrainienne de 2021-2022, Invasion de l'Ukraine par la Russie en 2022 pour vérifier). On peut ré-utiliser la balise du filtre 123 pour le coup je pense. Toto Azéro suivez le guide ! 5 mars 2022 à 16:47 (CET)Répondre[répondre]
C'est ce que j'avais en tête, hop c'est fait. — Thibaut (discuter) 5 mars 2022 à 16:49 (CET)Répondre[répondre]

Flux structurés[modifier le code]

Bonjour,

Régulièrement, j'observe des masquages de flux structurés de la part d'utilisateurs divers et variés. Traditionnellement, le masquage est réservé aux admins et aux OS.

Or, tout utilisateur possède le droit flow-hide (droits de groupe). Je propose d'empêcher systématiquement ces masquages via un nouveau filtre.

Sont concernés :

  1. Le forum des nouveaux, forum de relecture et autres forums actuels ou à venir similaire sur l'espace de nom Wikipédia ;
  2. Pages de discussions en flow sur l'espace de nom "Discussion utilisateur" ;

Pour les plus profanes, cela n'empechera pas de "clore" une discussion (flow-lock) : l'archivage sera encore possible, et par extension, cela n'empêchera pas non plus une suppression administrative ou OS (flow-delete, flow-suppress) des sujets qui posent des contraintes légales.

Voici un exemple de masquage contraire à nos usages : Sujet:Wskim5dg6lcezcw7.

Alternativement, il est aussi possible de lancer une décision communautaire pour demander le retrait de ce droit attribué par défaut à tout le monde dans Flow.php (cf. Extension:StructuredDiscussions/Moderation).

Par extension, pour lutter contre le vandalisme, je propose d'étudier la mise en place d'un second filtre avec ces mesures :

  1. empêcher de changer le titre d'une discussion structurée initié par quelqu'un d'autre. Voir cet exemple sur la pdd de Trizek ;
  2. empêcher le droit de modifier les messages des autres (droit « Modifier des messages de Discussions structurées publiés par d’autres utilisateurs (flow-edit-post) », accessible aux confirmés) ;
  3. empêcher la modification du "board" (description), cf. cet exemple sur la pdd de Trizek.
    • N.b. il existe déjà le filtre no 364, « blocage de l'édition des descriptions de pages Flow dédiées à l'aide », réservé au forum des nouveaux, de relecture et assimilés. On peut envisager de l'étendre aux discussions d'utilisateur, ou en créer un autre pour plus de lisibilité en suivant le même principe.

Par défaut, le fait de n'autoriser que les contributeurs patrolled de pouvoir réaliser ces actions devrait diminuer drastiquement les vandalismes.

Avez-vous des remarques ou des objections à formuler ?

Bien à vous, LD (d) 30 mars 2022 à 23:17 (CEST)Répondre[répondre]

+1 ! Déjà que je n'ai jamais bien compris comment le faire… ni pourquoi. Hyméros --}-≽ 30 mars 2022 à 23:36 (CEST)Répondre[répondre]
Ce serait très cool, en attendant que les nouveaux outils de discussion arrivent à prendre le relais convenablement. Merci LD ! Trizek bla 31 mars 2022 à 22:14 (CEST)Répondre[répondre]
Désolé de paraître un peu rabat-joie, mais je ne vois aucun problème à ce qu'un contributeur lambda puisse masquer un sujet.
Il ne faut pas oublier que Flow a été conçu par les devs dans l'idée de se rapprocher du fonctionnement des forums internet (le résultat est un désastre, mais passons...).
Masquer un sujet, c'est un peu comme quand un patrouilleur révoque un vandalisme sur une PdD. Simplement, comme Flow fonctionne avec des « sujets » (qui sont l’équivalent d'une section de PdD), on masque simplement le sujet.
Clore un sujet, c'est le marqué comme traité, résolu ou hors-sujet. L'équivalent avec un forum serait de « verrouiller » le sujet. Dans WP, par exemple sur WP:QT, on va indiquer que la question est hors-sujet (mais il n'y a pas besoin de la supprimer).
Par contre, un vandalisme, sur WP, on l'efface. Et comme n'importe qui a le droit de le faire sur une PdD normale. N'importe qui (ou alors maximum un autoconfirmed) doit avoir le pouvoir de masquer un tel sujet. Et n'importe qui peut le restaurer au besoin.
Les admins disposent quant à eux d'une 3e option, qui est de « Supprimer le sujet » (équivalent d'un masquage léger). Et les OS disposent sûrement encore d'une 4e option, pour faire un masquage lourd.
Je suis contre le fait de restreindre par des filtres des fonctionnalités du logiciel MediaWiki. Si un masquage (niveau péon) est problématique, on l'annule simplement, comme n'importe quelle autre modif.
Même opposition pour interdire la modification des messages d'autrui. C'est comme ça que fonctionnent les PdD sur WP. Pas de raison que Flow y déroge.
La seule chose sur laquelle je suis néanmoins d'accord, c'est la protection par filtrage des modifs des descriptions de PdD Flow critiques (tel que le FdN, fait actuellement par filtre). Car là on a des maladresses régulières. Et a priori peu de raisons qu'un contributeur nouveau ait à y modifier. Et on a aucune possibilité de semi-protéger ça. On pourrait envisager un filtre général interdisant par exemple aux comptes avec moins de 50 contribs (limite pour voter aux PàS) de modifier ça sur une PdDU d'autrui.
Mais de manière générale, ce n'est pas à nous de corriger par des filtres des fonctionnalités MediaWiki. Au passage, rappelons que c'est Flow qui aurait de toute façon déjà dû être mis à la poubelle depuis des années au vu de l'arrêt définitif de son développement (et vu l'inaboutissement du truc). Les devs ne vont de toute façon pas garder ça éternellement en l'état, espérons-le...).
--Tractopelle-jaune (discuter) 31 mars 2022 à 23:27 (CEST)Répondre[répondre]
@Tractopelle-jaune : merci pour ton avis, j'aimerais néanmoins souligner la possibilité de masquer chaque réponse, et pas seulement un sujet, sans avoir de moyen efficace d'annuler massivement. Le masquage n'est pas un archivage, il rend illisible la réponse jusqu'à l'annulation de chaque masquage manuellement en renseignant un motif.
Ceci dit, restreindre aux comptes confirmés (âgés de 4 jours) empêcherait déjà la majorité des vandalismes, si ce n'est des maladresses.
Cela peut peut-être nous inviter au moins à réfléchir sur des filtres non bloquants. Par exemple :
  • en demandant une confirmation au bout de x masquages sauf pour les autopatrolled ;
  • en créant un suivi par journalisation ou balisage.
Serais-tu également opposé à ces autres modes de filtrage ? LD (d) 31 mars 2022 à 23:52 (CEST)Répondre[répondre]
Notification LD : Ce que je peux imaginer, qui irait globalement dans ton sens :
  • Cacher un sujet :
    • autopatrolled : aucune restriction
    • autoconfirmed (ou alors user > 50 contribs) : 1-2 masquage/heure, au-delà averto de confirmation OU blocage de la modif (permet ainsi par exemple de masquer sa question sur la PdD Flow d'autrui si on a entre-temps résolu son problème).
    • nouveaux : averto (indiquant de maquer comme résolu si problème réglé) + blocage modif si confirmation (nécessité de l'avertissement pour éviter d'encombrer la liste des modifs bloquées, déjà assez chargée comme ça).
  • Journalisation avec/sans balisage : aucun soucis pour moi, et peu importe le level de l'utilisateur.
--Tractopelle-jaune (discuter) 1 avril 2022 à 00:19 (CEST)Répondre[répondre]

BN -> Subst[modifier le code]

Salut à tous. Juste pour informer, notamment @Jules* et @LD, de la dernière manière de BN de modifier les articles (subst). Vu sous IP et sous FN. 'toff [discut.] 23 avril 2022 à 16:27 (CEST)Répondre[répondre]

Hello @Supertoff et tous, merci de l'info. J'ai mis à jour les filtres 361 et 363 ; à suivre. — Jules* discuter 23 avril 2022 à 19:20 (CEST)Répondre[répondre]

Filtre 209, NS/PF/BN[modifier le code]

Hello, notamment @Thibaut120094 et @Tractopelle-jaune.

La plage 2A04:CEC0:0:0:0:0:0:0/32 (u · d · b) (IP mobiles Bouygues) accueille plusieurs bannis, notamment :

En plus du blocage partiel de la plage sur l'espace Utilisateur, je viens de mettre en place un filtrage dans le filtre 209. N'hésitez pas à le compléter selon les besoins.

À ce sujet, dans le même filtre, @LD, peut-on supprimer la partie « Spam d'IPs et proxies ouverts » (ligne 2) ? Il me semble qu'elle n'est plus nécessaire/d'actualité.

Cdlt, — Jules* discuter 29 avril 2022 à 11:52 (CEST)Répondre[répondre]

Salut, ✔️, BàT LD (d) 29 avril 2022 à 18:30 (CEST)Répondre[répondre]

Nouveaux filtres[modifier le code]

Hello,

Pour info, création des filtres 373 (contournements de blocage par Apokrif) et 374 (WP:Faux-nez/Antivax, qui était jusqu'alors inclus dans un autre filtre).

Par ailleurs, étant donné que le filtre 133 est très fourni et très actif (à tel point qu'il est détecté comme potentiellement mal configuré, heureusement sans préjudice pour la détection), je propose d'en extraire la détection d'émoticônes et d'en faire un filtre dédié. Ça me semble d'autant mieux que l'ajout d'émoticônes procède parfois de la maladresse (émoticône présente dans le titre d'une ref par exemple ; j'ai eu un cas il y a peu) : le titre du filtre étant explicite, ça évitera certains questionnements.

Par ailleurs, il y aurait sans doute du ménage à faire dans la regex principale du 133 (pour en faciliter la lecture/maintenance) : il y a probablement pas mal d'éléments obsolètes.

Cdlt, — Jules* discuter 1 mai 2022 à 21:57 (CEST)Répondre[répondre]

P.-S. : incidemment, la lecture de ce message de @Tractopelle-jaune (merci) me fait penser qu'on pourrait introduire plus souvent un avertissement avant blocage des modifs, pour tout ce qui n'est pas pur vandalisme (par exemple, les ajouts d'émoticônes), histoire de peut-être désengorger un peu Wikipédia:AbuseFilter/Modifications bloquées. Ça me semblerait être une bonne pratique. — Jules* discuter 1 mai 2022 à 22:01 (CEST)Répondre[répondre]
Notification Jules* : Merci pour ces deux nouveaux filtres.
Je suis assez actif dans le suivi de Wikipédia:AbuseFilter/Modifications bloquées, et c'est vrai que le traitement de cette page est parfois assez lourd depuis 6-8 mois.
Pour la sortie des smileys dans un filtre spécifique, avec avertissement préalable, SAUF pour ceux clairement assimilables à un vandalisme (💩 et 🖕).
--Tractopelle-jaune (discuter) 1 mai 2022 à 22:13 (CEST)Répondre[répondre]
@Tractopelle-jaune : Merci pour le suivi, que j'avais remarqué (notamment via les demandes de masquage) Émoticône.
Hmmm, àmha il vaudrait mieux laisser ensemble tous les smileys, pour faciliter la maintenance. Donc soit décider de se passer de l'avertissement, soit accepter qu'il y ait avertissement au préalable même pour des vandalismes évidents (à mon sens il n'y a pas trop d'inconvénient à cela, à moins que je ne loupe qqch). (Je trouve vraiment que les filtres fourre-tout sont une plaie.) — Jules* discuter 1 mai 2022 à 22:17 (CEST)Répondre[répondre]
Notification Jules* : Pas de soucis, je préfère qu'ils soient tous sortis ailleurs plutôt qu'ils restent où ils sont actuellement.
Et peut-être qu'un usage accru des diverses fonctions norm, ccnorm, rmspecials, rmdoubles et rmwhitespace dans nos filtres pourrait aider. Les regex seraient plus robustes face aux diverses variantes, tout en gagnant en robustesse et lisibilité.
-Tractopelle-jaune (discuter) 1 mai 2022 à 22:23 (CEST)Répondre[répondre]
Je pense que tu as raison, même si j'ai un peu de mal perso ^^. Je trouve que l'usage de ccnorm n'est pas évident, même en s'aidant de [1] ; il me faut toujours dix minutes pour retrouver dans quel sens s'opèrent les transformations. Sans doute car je n'utilise pas la fonction assez souvent (seulement dans les filtres où tu l'as introduite !). Il me semble aussi, de mémoire, que j'avais relevé des incohérences dans la doc concernant les tables de caractères/transformations. — Jules* discuter 1 mai 2022 à 22:27 (CEST) P.-S. : et clairement rmdoubles est sous-exploité.Répondre[répondre]
Spécial:Filtre_antiabus/history/374/diff/prev/6094 (et suivant) Émoticône. — Jules* discuter 1 mai 2022 à 22:37 (CEST)Répondre[répondre]
Hello, merci @Jules* et @Tractopelle-jaune.
Le filtre anti-emoji fai(sai)t partie de mes tâches, conseillé par @Le chat perché en privé, deux documents me semblent pertinents : celui-ci et celui-là pour le créer.
Avoir deux filtres distincts ne me semble pas problématique en soi. Le premier qui se veut exhaustif et avec un avertissement, et l'autre plus versatile pour interdire les utilisations problématiques (appel à brûler des voitures, vandalisme-popo, etc.). LD (d) 1 mai 2022 à 23:17 (CEST)Répondre[répondre]
Salut. Petit rappel au passage : il y a aussi le filtre global 110 (public) pour les emoji mais qui n'est pas bloquant. Si on ne veut pas interdire certains smiley, autant les déplacer dedans ? (Perso, à part quelques articles comme Émoticône, je ne vois pas comment une émoticône est justifiable dans le main ?) 'toff [discut.] 2 mai 2022 à 09:48 (CEST)Répondre[répondre]
Au passage, pour ccnorm, il faut aussi penser qu'il n'agit pas de la même manière pour les majuscules et les minuscules (testez le avec "éeèÉEÈ") @Tractopelle-jaune norm étant une combinaison de rmwhitespace, rmspecials, rmdoubles et ccnorm il faut vraiment savoir ce qu'on recherche comme résultat. Pas si évident. 'toff [discut.] 2 mai 2022 à 10:12 (CEST)Répondre[répondre]
2e passage Et il faut aussi faire attention aux combinaisons : par exemple rmdoubles(rmwhitespace(arg)) ne retourne pas le même résultat que rmwhitespace(rmdoubles(arg)). C'est logique, mais il faut y penser Émoticône. 'toff [discut.] 2 mai 2022 à 10:20 (CEST)Répondre[répondre]
Conflit d’édition Notification Supertoff : En fait, le problème c'est que l'on peut trouver des émoticône dans de très nombreux domaines : citations de tweets/blogs, titres de réfs, articles de plages de code Unicode et caractères, articles des pays (drapeaux Unicode). Tout dépend du domaine du sujet de l'article.
Et ce n'est donc pas un vandalisme (tout en étant pas forcément approprié).
On a aussi des soucis récurrents avec les en:Regional indicator symbol (drapeaux Unicode des pays), qui sont fréquemment utilisé depuis mobiles pour insérer le drapeau d'un pays dans un champ d'infobox au lieu d'utiliser nos modèles habituels {{Drapeau}}, {{Pays}}, {{CIO-d}} ou des modèles « pays et drapeaux » genre {{Canada}}.
On ne peut là non plus les interdire globalement (vu qu'ils sont fréquemment présents dans des citations de tweets ou blogs et titres de pages). Mais les drapeaux Unicode n'ont rien à faire dans les infobox et tableaux de résultats sportifs.
Pour les diverses fonctions que j'ai cité, bien entendu que norm est inadapté dans bien des cas, ccnorm l'est parfois même aussi. Mon propos visait surtout à dire qu'au lieu de multiplier les ?, +, * et autres [AÀÂ], ou pouvait parfois déjà traiter la chaîne d'entrée pour faciliter les tests. Mais il faut bien entendu utiliser les bonnes fonctions aux bons endroits. Parfois on peut aussi souhaiter supprimer les espaces pour identifier certains mots (dont la longueur ou la spécificité le permet, sans risque de matcher d'autres mots). Dans d'autres cas, on souhaite éviter les contournements à l'aide des diacritiques ou de caractères Unicode. C'est vraiment du cas par cas, vu qu'il faut aussi éviter les faux-positifs.
Mais on a encore une bonne marge de progression au vu de certaines regex (qui restent très basique, sachant que l'on dispose du plus puissant moteur de regex (AbuseFilter utilise les PCRE). La donc PHP est aussi parfois bien utile pour ceux qui n'utilisent pas tous les jours les regex Perl et/ou PCRE : https://www.php.net/manual/fr/reference.pcre.pattern.syntax.php
--Tractopelle-jaune (discuter) 2 mai 2022 à 10:31 (CEST)Répondre[répondre]
Hmmmm, j'avais tendance à penser comme Supertoff, mais du coup je peux imaginer quelques cas rares dans lesquels l'insertion d'émoticônes serait entendable : pour les citations, on peut mettre une alternative textuelle à l'émoticône, et quant aux titres de ref, l'expérience montre que les refs utilisant de telles émoticônes sont généralement des sources de mauvaise qualité, mais pour les pages Unicode, je comprends. Une exception pour ces pages-là devrait faire l'affaire. Quoi qu'il en soit, peut-être qu'une approche plus pragmatique serait de n'ajouter au filtre que les émoticônes dont nous avons constaté l'usage problématique ? (C'est d'ailleurs ce que nous avions fait jusqu'alors.)
Quant aux drapeaux, pour le coup je pense que ça mériterait un filtre distinct, qui vise spécifiquement l'ajout dans des infobox mais pas les autres usages, et qui avertisse avant de bloquer la modif ? — Jules* discuter 2 mai 2022 à 16:40 (CEST)Répondre[répondre]
A contrario, le pragmatisme ne me semble pas pertinent car en théorie chaque illustration visuelle doit avoir un intérêt encyclopédique (Wikipédia:Conventions d'utilisation des images ?). Un avertissement pour tous les emojis/toutes les émoticônes suit cette logique. S'amuser à les ajouter un à un, à la suite d'une mauvaise utilisation qui aurait pu être évitée, plutôt que de baliser une range comme le fait le filtre global me semble chronophage et inutile.
A l'inverse, si tu soutiens désormais plusieurs filtres (3 ? un général, un bloquant et un pour les drapeaux ?), @Jules*, l'approche pragmatique me semble convenir pour les non généraux. LD (d) 2 mai 2022 à 18:59 (CEST)Répondre[répondre]
La question est aussi celle de savoir si les insertions d'émoticônes et de drapeaux posent un problème tel que des filtres soient nécessaires. J'ai du mal à l'évaluer ; Tractopelle-jaune semble dire que oui pour les drapeaux. — Jules* discuter 2 mai 2022 à 19:12 (CEST)Répondre[répondre]
C'est aussi là qu'intervient ma limite : qu'est-ce qui est pertinent ? C'est la base pour construire un/des filtres 'toff [discut.] 2 mai 2022 à 21:16 (CEST)Répondre[répondre]
Perso (encore une fois), je pense que dans les commentaires de diff, c'est dispensable, non ? 'toff [discut.] 2 mai 2022 à 21:32 (CEST)Répondre[répondre]
Pour les émotionnes drapeaux (qui se retrouvent surtout dans les infobox et tableaux sportifs), je pense que l'on peut regarder ça dans un second temps.
Ils sont généralement insérés (hormis quand ils accompagnent des vandalismes) avec des modifs de bonne foi. Donc si on veut s'en occuper, il faut de toute façon faire filtre dédié aux drapeaux Unicode à cause de la nécessité de pouvoir disposer d'un message système dédié, aidant à se diriger vers nos différents modèles courants insérant des drapeaux, selon la situation (je peux m'occuper d'écrire le message système d'avertissement qui redirigera aux mieux le novice parmi nos différents systèmes de drapeaux).
Et ce filtre n'a pas besoin d'être bloquant (en tout cas en l'état), s'agissant avant tout de maladresses. Et cela permet aussi au passage de ne pas trop se casser la tête avec les exceptions à gérer. La combinaison message d'avertissement dédié + ajout d'une balise genre « drapeau Unicode » si confirmation me semble la plus pertinente.
--Tractopelle-jaune (discuter) 2 mai 2022 à 23:56 (CEST)Répondre[répondre]

Filtre anti-emojis (suite)[modifier le code]

Bonjour @LD,

Pour prolonger cette section et notre échange sur ta PDD. J'ai aujourd'hui un autre exemple d'insertions répétées d'emojis pour vandaliser, dans l'infobox cette foi, c'est ici. Je comprend aisément que d'une part il ne soit pas approrprié de mettre un filtre systématique et qu'un tel filtre soit difficile à paramétrer. Cela dit comme je le faisais remarquer les vandales n'utilisent pas l'insertion via les modèles mais l'insertion directe. Cela pourrait être une piste.

Bàt

--Le chat perché (discuter) 5 mai 2022 à 20:46 (CEST)Répondre[répondre]

Dernier ajout sur 209[modifier le code]

Bonjour,

Mon dernier ajout n'est pas très efficace, semble-t-il cf. mailles du filet ; il y a donc une subtilité qui m'a échappée. Des remèdes ?

Pour info : @Tractopelle-jaune.

Bien à vous, LD (d) 17 mai 2022 à 18:21 (CEST)Répondre[répondre]

Notification LD : J'ai appliqué un petit correctif au filtre.
Ça fonctionne dorénavant comme attendu.
Bonne soirée.
--Tractopelle-jaune (discuter) 17 mai 2022 à 18:51 (CEST)Répondre[répondre]
Merci pour cette correction qui dissipe distinctement tous les doutes. Bonne soirée, LD (d) 17 mai 2022 à 19:14 (CEST)Répondre[répondre]

page_age == 0[modifier le code]

Salut. Sur Mediawiki il est inscrit que pour "page_age", page_age == 0 détecte les créations de pages. En testant sur mes contributions, il apparaît qu'il ne détecte pas les créations mais les suppressions. C'est moi ? Et si ça ne fonctionne pas, par quoi remplacer ? (c'est pour le filtre 336 entre autres). 'toff [discut.] 3 juin 2022 à 06:23 (CEST)Répondre[répondre]

Hello @Supertoff,
Il me semble que cela fonctionnait avant.
Je contournerais le problème avec old_size == 0 voire avec page_first_contributor si tu veux match un utilisateur en particulier (dans l'idée : page_first_contributor = <une variable>). LD (d) 4 juin 2022 à 15:02 (CEST)Répondre[répondre]

Filtre 309[modifier le code]

Salut à tous. Le filtre 309 étant relativement gros et mélangeant ccnorm et regex, il devenait un peu compliqué de cerner certains termes filtrés. Pour une visualisation plus facile, j'ai reclassé par groupe de termes et ensuite par ordre alphabétique et j'ai mis en remarque la liste complète, "en clair", des termes filtrés. Ca évitera de créer des doublons. 'toff [discut.] 6 juin 2022 à 23:56 (CEST)Répondre[répondre]

Salut @Supertoff,
Ah...! Lors de mon dernier ajout, je n'avais pas compris qu'il s'agissait d'un classement ccnorm-alphabétique, c'est contre-intuitif lorsqu'on n'en a pas l'habitude.
C'est une très bonne idée et la note est très utile, merci Émoticône. LD (d) 7 juin 2022 à 01:11 (CEST)Répondre[répondre]
J'ai une question technico-pratique, mais j'ai « peur » de la mentionner car elle pourrait donner des idées aux plus mâlins. Smiley Colère LD (d) 7 juin 2022 à 01:16 (CEST)Répondre[répondre]
Il te reste le mail Émoticône 'toff [discut.] 7 juin 2022 à 09:43 (CEST)Répondre[répondre]
Ou utiliser la section Notes d'un filtre privé bidon pour partager entre initiés ? Habertix (sous son faux-nez Hab'rtix) (discuter) 21 juin 2022 à 23:30 (CEST).Répondre[répondre]
Très bonne idée, @Habertix, j'ai recyclé le 96 qui n'a pas servi depuis 5 ans. LD (d) 22 juin 2022 à 15:52 (CEST)Répondre[répondre]

Filtres 361 et 363[modifier le code]

Bonjour,

Les filtres Spécial:AbuseFilter/361 et Spécial:AbuseFilter/363 s'activent régulièrement, avec très souvent une requête en faux-positif.

Avez une estimation (au doigt mouillé) du taux réel de faux-positif ? Pensez-vous qu'une RCU serait utile pour clarifier les choses ?

-- -- Habertix (discuter) 21 juin 2022 à 23:23 (CEST)Répondre[répondre]

Salut. @Jules* aura peut-être une idée plus précise mais àmha on est de l'ordre de 90 à 95 % de requêtes faites par BN. Par contre si tu demandes le pourcentage de FP, le taux devrait descendre un peu (mais je n'ai pas d'idée précise). En ce qui concerne les RCU, il me semble qu'on avait évoqué des RCU régulières au début du cas BN ? En tout cas, c'est sur ce principe que j'ai faite une requête le 19 juin pour faire du ménage Émoticône 'toff [discut.] 22 juin 2022 à 06:14 (CEST)Répondre[répondre]
Salut. Question complexe et réponse complexe.
Pour le 363, si on en tennait à sa version en novembre/décembre, on aurait pu estimer jusqu'à 30 % de FP car les comptes ont été vérifiés via RCU 1 et RCU 2. Mais, si on compte en termes d'IP différentes, nous n'arrivons pas à 30 %, nous serions probablement à 10 - 20 % maximum : il n'y a pas que BN qui est prise la main dans le sac. Cette RCU 3 vaut aussi le détour, elle met en évidence qu'on peut trouver plusieurs FNs (a priori différents) sur une même plage.
Une RCU me semble toujours utile ponctuellement pour trouver les proxies ouverts voire les plages utilisées par plusieurs FNs... Je peux m'y coller en récoltant toutes les informations qui ont moins de 3 mois.
Pour le 361, aucune idée. LD (d) 22 juin 2022 à 15:40 (CEST)Répondre[répondre]
Hello. Globalement, je dirais qu'il y a environ 20-25 % de FP pour le 363. Et en parcourant les détections, plusieurs d'entre eux viennent d'un point que je viens de corriger (c'était pertinent au départ, ça ne l'est plus aujourd'hui).
Pour le 361, j'ai du mal à évaluer, notamment car un certain nombre de diffs filtrés peuvent correspondre à BN, mais sans certitude. Mais je suggère en tout état de cause que nous supprimions (pour la même raison que pour le 363) la ligne 6, qui détecte désormais trop largement ; typiquement, ce faux-positif en est la conséquence. D'ailleurs je joins l'acte à la parole (annulez si vous estimez que je fais une erreur d'analyse, évidemment).
Amicalement, — Jules* discuter 22 juin 2022 à 17:29 (CEST)Répondre[répondre]
P.-S. : oui, des RCU de temps en temps, c'est toujours utile pour faire le point. Je ne le fais pas systématiquement, mais de ce que je vois passer nous en faisons tous les trois de manière régulière. — Jules* discuter 22 juin 2022 à 17:30 (CEST)Répondre[répondre]
J'ajoute que parfois, les filtres BN permettent de filtrer d'autres vandalismes même s'ils ne sont pas dédiés à ça. 'toff [discut.] 22 juin 2022 à 18:24 (CEST)Répondre[répondre]
Oui : témoin 1 et témoin 2.
Ceci dit, il y a probablement de petites améliorations, cf. ce cas qui n'a pas été exclu par la ligne 12 du 363 à date. Va-t-on savoir pourquoi (=moi pas comprendre). LD (d) 22 juin 2022 à 18:47 (CEST)Répondre[répondre]

366[modifier le code]

Notification Jules*, LD et Bédévore : salut. Dans l'urgence (pas pris le temps de creuser le problème), j'ai supprimé une partie des détections du filtre 366 à cause d'au moins deux comptes récents non détectés (je mets des diffs, pas envie de mettre un lien vers ces noms de contributeurs) : [2] et [3]. Si vous arrivez à corriger le problème moins radicalement. En attendant, il me semblait urgent de faire cette action. 'toff [discut.] 8 juillet 2022 à 06:20 (CEST)Répondre[répondre]

Salut @Supertoff, je ne comprends pas comment la suppression d'une condition connexe pourrait être bénéfique, mais c'est lié à l'urgence j'imagine et peu importe : j'ai soumis une idée dans Spécial:Filtre antiabus/96. LD (d) 8 juillet 2022 à 19:00 (CEST)Répondre[répondre]
Salut. J'ai pas le temps de me pencher sur le problème en ce moment mais en test la suppression de la condition a permis de détecter une création que le filtre ne détectait pas avant. Toute correction qui permet au filtre de mieux fonctionner est bienvenue. Je retourne IRL, A+ 'toff [discut.] 9 juillet 2022 à 07:06 (CEST)Répondre[répondre]

Filtre 123[modifier le code]

Hello,

Pour alléger un peu le nombre de signalements sur Wikipédia:AbuseFilter/Modifications bloquées, j'ai ajouté un avertissement préalable au blocage des modifications dans spécial:Abusefilter/123. J'ai créé pour ça MediaWiki:Abusefilter-warning-123 qui est une copie de MediaWiki:Abusefilter-disallowed-123.

Ça ne change pas grand chose pour les utilisateurs, ça évite juste d'engorger la liste des modifications bloquées avec ces modifications-là, faites de bonne foi et qui ne demandent pas d'intervention des admins pour bloquer les comptes. Oui, je pense à vous @Tractopelle-jaune et @Supertoff Émoticône.

Dites-moi si ça vous va. — Jules* discuter 1 août 2022 à 23:46 (CEST)Répondre[répondre]

Honnêtement, ça ne changera pas grand chose pour moi : je ne vais pas sur Wikipédia:AbuseFilter/Modifications bloquées Émoticône. C'est peut-être un tort d'ailleurs ? Pas de soucis. 'toff [discut.] 2 août 2022 à 07:17 (CEST)Répondre[répondre]
Notification Jules* : Buvons, c'est bon ! --Tractopelle-jaune (discuter) 3 août 2022 à 11:18 (CEST)Répondre[répondre]

Messages AbuseFilter[modifier le code]

Hello et merci pour le travail réalisé ci-haut ;

Dans cette lignée, je me suis lancé dans la mise à jour des Wikipédia:AbuseFilter/Messages d'avertissement en révisant d'abord {{Avertissement filtre}} pour mieux personnaliser et ensuite uniformiser les messages.

Concrètement aussi, je pense déplacer les "warning" qui sont utilisés par des filtres bloquants vers "disallowed", comme pour MediaWiki:Abusefilter-disallowed-320. Ensuite, les passer en revue et les mettre à jour en même temps que les filtres (sélection de l’avertissement), au moins pour que le message coïncide avec l'objectif et rajouter les balises utilisées si pertinentes pour le message d'avertissement. A terme, les "warning" qui ne sont pas utilisés seront simplement supprimés (ex. Spécial:Filtre_antiabus/29 <=> MediaWiki:Abusefilter-warning-29 (redirect) ; MediaWiki:Abusefilter-warning-320 sera remplacé par MediaWiki:Abusefilter-warning, puis ce premier supprimé car MediaWiki:Abusefilter-disallowed-320 existe désormais, etc.)

@Jules*, j'ai bricolé les historiques de MediaWiki:Abusefilter-warning / MediaWiki:Abusefilter-warning-377 pour restaurer le message qui avait été modifié puis transféré en juin (ce qui a finalement supprimé localement Abusefilter-warning).

Bien à vous, LD (d) 3 août 2022 à 15:30 (CEST)Répondre[répondre]

Excellente initiative @LD, merci ! Par contre il y a un problème dans le titre de MediaWiki:MediaWiki:Abusefilter-warning-377, je pense. Amicalement, — Jules* discuter 3 août 2022 à 16:03 (CEST)Répondre[répondre]
Oui (Smiley: triste), c'est corrigé merci ! LD (d) 3 août 2022 à 16:14 (CEST)Répondre[répondre]

I have a dream[modifier le code]

Je sais qu'on n'est pas nombreux à surveiller WP:FP mais j'aimerais bien qu'il ne traîne pas autant de requêtes non répondues, quel qu'en soit le sens : je pense qu'une dizaine en instance serait un grand max en fonction des circonstances et qu'avec un peu d'effort, on serait capable de tout solder au fur et à mesure. Je viens de faire un premier tri : ajout des numéros de filtres, réponses en {{fait}} ou {{pas fait}} quand c'est traité, renvoi vers mes collègues concernés (suivez mon regard) quand il y a besoin d'un avis. Je continuerai prochainement. Nota pour les collègues : si vous corrigez un filtre au vu d'une requête, n'oubliez pas de classer Émoticône 'toff [discut.] 2 août 2022 à 16:25 (CEST)Répondre[répondre]

Hey @Supertoff. Je suis beaucoup moins actif sur les filtres depuis plusieurs mois. Je compte m'y réinvestir, mais compliqué de tout concilier Émoticône. — Jules* discuter 2 août 2022 à 16:57 (CEST)Répondre[répondre]
Pas de soucis, c'est un vœu pieux et moi aussi faut que je m'y mette. Je vais essayer de continuer le ménage et "pinguer" au besoin. 'toff [discut.] 2 août 2022 à 21:44 (CEST)Répondre[répondre]

┌─────────────────────────────────────────────────┘
Bon, voilà, j'ai fait le tour de ce que je pouvais (et merci @Jules* d'avoir clôturé les requêtes où je l'avais notifié) : OrlodrimBot (d · c · b) devrait nous épurer tout ça d'ici 2-3 jours. Il reste 2 requêtes à traiter :

'toff [discut.] 3 août 2022 à 07:24 (CEST)Répondre[répondre]

Bonjour. Je ne suis pas vraiment une pointure à ce jeu. Il m'arrive de traiter des évidences mais ma mémoire de poisson rouge me handicape sérieusement dans la chasse aux faux-nez récurrents. Bertrand Labévue (discuter) 3 août 2022 à 09:28 (CEST)Répondre[répondre]
Hello, merci et bravo à tous pour le nettoyage de printemps et les corrections liées. cf. ci-bas, je me lance progressivement dans une vérification de chaque filtre ; je ferais probablement un bilan dans un tableau. LD (d) 3 août 2022 à 18:01 (CEST)Répondre[répondre]

┌─────────────────────────────────────────────────┘
Rââââââ je kiffe ! 'toff [discut.] 6 août 2022 à 07:19 (CEST)Répondre[répondre]

Émoticône Merci encore pour le ménage. — Jules* discuter 6 août 2022 à 12:11 (CEST)Répondre[répondre]

Amélioration du filtre 363 grâce au 209 ?[modifier le code]

Notification LD et Jules* : salut. En regardant cette « retouche » de LD sur le filtre 209 je me suis demandé si ça ne pourrait pas être appliqué sur le 363 pour éviter certains FP ? Quand on regarde les comptes détectés par le 363 et bloqués depuis (sans oublier l'observation que j'avais partagé par mail il y a quelques mois), ça me semble être une piste non ? 'toff [discut.] 9 août 2022 à 08:05 (CEST)Répondre[répondre]

Hello @LD et @Supertoff. Je ne connaissais pas ces regex, mais je pense avoir compris leur usage. Et du coup oui, ça me semble une excellente idée pour éviter les FP sur le 363. — Jules* discuter 9 août 2022 à 13:18 (CEST)Répondre[répondre]
@Jules* je te rassure, je ne connaissais pas non plus avant Émoticône 'toff [discut.] 9 août 2022 à 13:32 (CEST)Répondre[répondre]
Hello, ne vous flagelez pas car à l'inverse j'ai été obligé d'apprendre certains formats pour que Wikipédia comprenne ce que je dise Smiley Colère (et vous me corrigez aussi quand le format n'est pas très naturel pour un filtre Tire la langue). Les Unicode brackets sont également compatibles avec PCRE donc il y a plein de choses qu'on puisse mettre en place pour abolir ce "irlike" insensible à la casse ou qui fait n'importe quoi sur certains caractères (bon je vais pas trop me plaindre, on va me sucrer l'outil après (Smiley: triste)). LD (d) 9 août 2022 à 14:12 (CEST)Répondre[répondre]
Notification LD : du coup tu peux nous mettre ça en place dans le 363 ? Ca évitera que je fasse des bêtises. C'est vrai que parfois irlike que j'aime bien et que je trouve pratique dans la plupart des cas peut être un handicap. D'ailleurs : une question va suivre par mail. 'toff [discut.] 9 août 2022 à 18:13 (CEST)Répondre[répondre]
Re @Jules* & @Supertoff, héhé : je viens de mettre à jour. La ligne 15 ne me semble plus nécessaire car peu active mais je ne l'ai pas supprimée (ai-je raté un truc ?). LD (d) 9 août 2022 à 18:15 (CEST)Répondre[répondre]
Ajout qui date de novembre 2021 : j'avais "bétonné" les détections sur cette page parce que ça devenait très pénible à cette époque. Je pense que ça s'est calmé et que ça n'est peut-être plus utile, tout comme la ligne 14 d'ailleurs. Ton avis @Jules* ? 'toff [discut.] 9 août 2022 à 22:01 (CEST)Répondre[répondre]
Je m'en souviens bien Smiley Colère (j'étais pas sûr qu'il y ait eu d'autres cas très récents : vous avez fait le gros du ménage) : àmha, plutôt que de supprimer on peut mettre en commentaire, comme ça on réactive au besoin. LD (d) 9 août 2022 à 22:33 (CEST)Répondre[répondre]
Coucou tous les deux. Oui, ça fait quelque temps que je songe à les virer (la ligne 16 aussi). Je mets ça en commentaire, donc, puisque consensuel. — Jules* discuter 9 août 2022 à 23:42 (CEST)Répondre[répondre]

Filtre 123 (2)[modifier le code]

Re,

Ce cas (admin-only) auraît pu être filtré par le filtre 123 mais sauf réécriture partielle, impossible. J'avais dit en novembre 2021 que je ne pourrais pas me pencher sur l'étude d'un autre cas avant quelques jours, et lorsque j'avais regardé à nouveau, j'avais compris qu'il fallait l'ajuster quasi-entièrement (changer son paradigme). Avez-vous des suggestions ?

  • D'ailleurs je retire mon propos sur les flags, il y en a au moins un Pop !. LD (d) 10 août 2022 à 01:52 (CEST)Répondre[répondre]
Salut. À priori, c'est surtout une faute de frappe de l'IP (inversion a et o) qui a permis de contourner le filtre. Je ne suis pas persuadé que ce soit courant vu que mal orthographier son nom est très mal vu. Mais si on veut que ce soit filtré sous cette forme, un "[aou]" à la place du "[ou]" et un "[ao]" à la place du "a" feront l'affaire (lignes 5, 8 et 9). 'toff [discut.] 10 août 2022 à 07:26 (CEST)Répondre[répondre]
Salut @Supertoff, je ne pense pas que cette correction change la donne, le contournement me semble dû aux caractères qui ne sont pas détectés dans l'expression ; la ressemblance entre [a] et [o] me semble déjà être détectée et je crois que la 'faille' a été trouvée par erreur, ou à force de tester. On n'a pas eu de requête qui en relèverait d'autres, je les ai vu un peu par hasard, mais il est possible que le filtre ne soit plus aussi efficace qu'avant. LD (d) 10 août 2022 à 19:13 (CEST)Répondre[répondre]
J'ai testé la correction que j'ai proposée ci-dessus et elle fonctionne. Et je reste (pour l'instant — mais l'avenir pourra me donner tort) persuadé qu'il s'agit d'un hasard, surtout connaissant ce que représente ce nom pour les croyants. Pour moi, le filtre est toujours aussi efficace (et la modification que j'ai proposée ne s'impose pas). 'toff [discut.] 10 août 2022 à 19:27 (CEST)Répondre[répondre]
Parfait, Coincoinci Supertoff Émoticône LD (d) 10 août 2022 à 23:04 (CEST)Répondre[répondre]

filtre 378 ?[modifier le code]

Salut à tous. Il y a une raison pour ce filtre spécifique ? Je notifie en particulier @JackPotte qui l'a créé mais si d'autres savent ? On a le 309 ou le 336 qui feraient très bien l'affaire àmha (et éventuellement le fourre-tout 29). 'toff [discut.] 8 août 2022 à 15:30 (CEST)Répondre[répondre]

Salut, vu les IPs filtrées, il me semble que la personne visée est WP:Faux-nez/Alisabriofficiel mais que cela n'a pas été remarqué : cette occassion peut permettre de migrer tout ce qui le concerne dans un même filtre. LD (d) 8 août 2022 à 15:44 (CEST)Répondre[répondre]
Hey. À voir la réponse de JackPotte, mais oui le 309 et/le 366 semblent tout à fait adaptés. On pourra recycler le 378 en autre choses (par exemple le filtre émoticônes non bloquant auquel il faut que je m'attelle). — Jules* discuter 8 août 2022 à 15:45 (CEST)Répondre[répondre]
Effectivement, je vais le fusionner dans le 309. JackPotte ($) 9 août 2022 à 09:41 (CEST)Répondre[répondre]

┌─────────────────────────────────────────────────┘
Notification JackPotte : j'ai transféré dans le filtre 309 et j'ai désactive le filtre 378.
Notification Jules* et LD : j'ai commencé le recyclage du filtre 378 en filtre pour les émoticônes : rapatriement des émoticônes non problématiques du filtre 133 et celles du filtre global 110. Pour l'instant :

  1. il n'est pas activé => attente d'être en accord sur son principe de fonctionnement
  2. il est privé => je pense qu'il peut être public
  3. le message n'est pas créé => @LD ? (oui je suis fainéant)
  4. je suis parti du principe qu'il ne concernait que le main (article et commentaire de diff)
  5. quand il sera activé il faudra :
    1. supprimer les émoticônes en double dans le filtre 133
    2. demander aux AF globaux de mettre une exception à fr.WP pour le filtre global 110.

'toff [discut.] 11 août 2022 à 10:48 (CEST)Répondre[répondre]

Merci @Supertoff. Oui pour le main. Je n'arrive pas à me rendre compte de la pertinence de filtrer les commentaires de diff également, mais on verra à l'usage. J'ai ébauché MediaWiki:Abusefilter-warning-378, en essayant de faire simple. — Jules* discuter 12 août 2022 à 16:49 (CEST)Répondre[répondre]
@LD : est-ce qu'on peut activer le spécial:abusefilter/378 avec filtrage de la première ligne, le temps que tu bosses le reste ? Comme ça je vire d'ores et déjà les quelques emotes du 133. Amicalement, — Jules* discuter 21 août 2022 à 01:49 (CEST)Répondre[répondre]
Merci @Jules* : j'ai activé ✔️ avec le message & une nouvelle balise. LD (d) 21 août 2022 à 14:52 (CEST)Répondre[répondre]
Notification Jules* : pourquoi tu as supprimé toutes les émoticônes du 133 ? De nos derniers échanges à ce sujet, il me semblait qu'on devait en conserver 2 qui devaient, elles, rester interdites ? Pour moi, ça reste d'actualité : j'ai tujours vu ces 2 émoticônes incluses par vandalisme.
Notification Jules* et LD : quelqu'un a fait action sur meta pour exclure wp.fr du filtre global 110 qui n'a plus lieu d'être ? 'toff [discut.] 23 août 2022 à 08:20 (CEST)Répondre[répondre]
@Supertoff : car j'ai oublié ce point, tout simplement Émoticône ; c'est corrigé. Et non, mais je peux le faire. — Jules* discuter 23 août 2022 à 12:29 (CEST)Répondre[répondre]
✔️ Demande déposée. Mais je ne suis pas sûr qu'on puisse se désinscrire d'un seul filtre global ; je me demande si ce n'est pas tout ou rien. — Jules* discuter 23 août 2022 à 12:35 (CEST)Répondre[répondre]
Si, ils l'ont déjà fait pour d'autres filtres : ils excluent wp.fr cf le filtre 214 : & wiki_name != "frwiki". 'toff [discut.] 23 août 2022 à 12:41 (CEST)Répondre[répondre]
Parfait. — Jules* discuter 23 août 2022 à 12:44 (CEST)Répondre[répondre]

┌─────────────────────────────────────────────────┘
Notification Jules* et LD : du coup, on a peut-être lancé l'idée de création de possibilité de désactivation locale des filtres globaux. 'toff [discut.] 23 août 2022 à 20:22 (CEST)Répondre[répondre]

Candidature AF : Abusefilter[modifier le code]

Bonjour, après à peu près deux semaines de réflexions je me décide de demander le statut de AF.

Pourquoi ce statut ? :[modifier le code]

en tant que patrouilleur régulier des modifications récentes et des journaux des modifications bloquées, j’ai souvent à consulter les filtres. Mais le problème, c’est que la plupart d’entre eux sont privés, je ne peux donc pas comparer les diffs avec tout les filtres

Quelles Utilisations j’en ferais-Je ?[modifier le code]

Dans un premier temps je les consulterai pour la raison citée plus haut. Puis dans un second temps, les modifier quand il sera nécessaire.

Ai-Je les capacités pour ?[modifier le code]

Oui, les expressions régulières me sont pas inconnues, j’ai déjà eu a les utiliser.

 S̲e̲t̲h̲  ᴍɪᴀᴜʟᴇ ᴄʜᴇᴢ ᴍᴏɪ Logo Patrouille.svg 9 août 2022 à 20:43 (CEST)Répondre[répondre]

Salut @SiriusSeth ;
Nous avons échangé, et tu as échangé avec Jules*. C'est une bonne chose d'avoir tâté le terrain, à mon avis.
Les candidatures récentes se concentraient uniquement sur la consultation, et dans celles-ci, j'y ai donné un avis favorable sans interroger sur l'édition en elle-même ; ici, vu que tu parles d'édition, j'aurais plutôt tendance à te questionner ; non pas pour te discréditer selon tes réponses (je suis favorable à ta candidature) mais pour comprendre ton raisonnement et ta manière de résoudre un « problème ».
En effet, tes récentes contributions à WP:FP montrent suffisament que tu comprends les mécanismes principaux. Quant à la pratique, c'est autre chose ; mon expérience : avant d'éditer des filtres, j'ai utilisé mon temps à regarder les FPs et prendre mes marques.
Imaginons que je veuille interdire Jules* et Supertoff d'éditer Discussion utilisateur:LD :
  1. Penses-tu que je puisse le faire car je suis AF, si oui pourquoi, si non pourquoi pas ?
  2. Penses-tu que le code suivant serait efficace et sans risque de faux-positif ?
    match:="Supertoff|Jules*";
    article_namespace == 4
    & page_prefixedtitle == "Discussion utilisateur:LD"
    &username rlike match
    
  3. Penses-tu que le code pourrait être modifié pour ne pas prendre en considération le genre du compte (« utilisateur ») : par exemple car je pourrais en changer via les paramètres ? Si oui, comment ? Si non comment résoudrais-tu ce problème ? En théorie, en pratique ou les deux : comme tu veux.
  • As-tu, toi, des questions que tu souhaiterais poser (auxquelles nous pourrions répondre) ?
Je réitère, ce n'est pas une interrogation surprise ; cela permet néanmoins de comprendre le raisonnement (Jules*, Supertoff et moi n'avons pas les mêmes, par exemple, mais cela nous disqualifie pas ; et heureusement car c'est même très bénéfique.). LD (d) 9 août 2022 à 23:11 (CEST)Répondre[répondre]
Salut. Je suis un peu réticent en raison de ta présence relativement récente sur WP (compte créé en novembre 2021). Mais ce n'est ni un pour, ni un contre : plutôt un neutre.
Après, moi je te soumets un petit test (que j'ai subi, je n'invente rien Émoticône) : peux-tu me dire ce que ce filtre est sensé faire ?
action = "edit" &
!("bot" in user_groups
| "sysop" in user_groups
| user_name in page_title) &
page_namespace = 2
'toff [discut.] 9 août 2022 à 23:28 (CEST)Répondre[répondre]
Moi je ne soumets pas de test, mais je regarderai les réponses aux deux autres Émoticône. — Jules* discuter 9 août 2022 à 23:40 (CEST)Répondre[répondre]
Hello, @LD pour
match:="Supertoff|Jules*";
article_namespace == 4
& page_prefixedtitle == "Discussion utilisateur:LD"
&username rlike match
la cible est l'escape en [[wikipédia:]]
Tu as mis ton espace de discussion, hors ce n'est pas le même namespace.
Je te dis la suite après, je suis assez occupé ce matin  S̲e̲t̲h̲  ᴍɪᴀᴜʟᴇ ᴄʜᴇᴢ ᴍᴏɪ Logo Patrouille.svg 10 août 2022 à 09:53 (CEST)Répondre[répondre]
Donc le bon Namespace est le 3 (discussion utilisateur)
Maintenant @Supertoff, je m'attelle à ton Test :
action = "edit" &
!("bot" in user_groups
| "sysop" in user_groups
| user_name in page_title) &
page_namespace = 2
Déjà, cela concerne les pages utilisateurs, Selon moi, ce filtre est censé empêcher l'édition d'une PU, par les non admins et les non Bots (mais Pourquoi le bot ? un admin n'est pas censé vandaliser une PU)
Voilà !  S̲e̲t̲h̲  ᴍɪᴀᴜʟᴇ ᴄʜᴇᴢ ᴍᴏɪ Logo Patrouille.svg 10 août 2022 à 12:45 (CEST)Répondre[répondre]
Notification SiriusSeth : ce n'est qu'un exemple et un admin n'est pas censé vandaliser une PU c'est pour ça qu'ils sont autorisés Émoticône. Sinon tu as oublié de dire que le "titualire" de la PU, même s'il n'est ni admin ni bot, peut modifier sa PU. 'toff [discut.] 10 août 2022 à 17:57 (CEST)Répondre[répondre]
@Supertoff Je ne l'avais pas dis/écris. Car cela me semblait évident, merci de la remarque  S̲e̲t̲h̲  ᴍɪᴀᴜʟᴇ ᴄʜᴇᴢ ᴍᴏɪ Logo Patrouille.svg 10 août 2022 à 18:08 (CEST)Répondre[répondre]
@LD Re, Pour le Genre, mettre Utilisatrice:LD|UtilisateurLD, Comme cela ça filtrera les deux ?  S̲e̲t̲h̲  ᴍɪᴀᴜʟᴇ ᴄʜᴇᴢ ᴍᴏɪ Logo Patrouille.svg 10 août 2022 à 17:12 (CEST)Répondre[répondre]
Merci SiriusSeth d'avoir pris le temps de répondre.
J'y réponds de manière (très) détaillée.
Il n'y avait pas de bonne(s) réponse(s) dans la globablité (mes collègues pourraient aussi avoir des choses à dire sur ma proposition, et c'est normal). Il y a néanmoins des subtilités et des "pièges" (de mon dû ou non) :
  • Pour match:="Supertoff|Jules*";, la petite étoile de Jules* (si élégante soit-elle ; je taquine son auteur), est un token (jeton), plus précisément un opérateur quantifieur, qui peut poser problème : il faut l'échapper (\* voire le transformer en caractère : [*]) la plupart du temps. Par exemple, le filtre détecterait Jules*, mais aussi Juless, Julesss, Julessss, ... Couplé avec rlike, il détecterait aussi Jules** (deux fois plus élégant ? Sourire diabolique) et potentiellement d'autres "Jules". Ce type de "problème" peut être constaté, soit par les faux-positifs, soit par une réflexion en amont : des tests sur un testeur comme regex101, ou Spécial:Filtre antiabus/test.
  • Pour l'espace, tu as effectivement bien vu le piège (de mon dû) et Aide:Espace de nom est toujours utile car on peut oublier cet index. Il y a au moins une subtilité avec cet index qui est utile à connaître si tu veux te pencher sur les disctructurées (flow) : 2600 pour les sujets flow ne fonctionnera pas si le "modèle" du filtre est défini sur « par défaut », d'où des filtres « flow ».
    • L'autre (petite) piège était article_namespace qui existe encore mais qui pourrait ne pas fonctionner car il a été remplacé par page_namespace.
  • page_prefixedtitle existe bien, la subtilité résidera avec page_title qui est expliquée sur mw:Extension:AbuseFilter/Rules format : recourir au second (tout en conservant la notion d'espace de nom) permet notamment de ne plus se servir de l’espace, donc du genre, mais d'autres solutions existent.
    • Utilisatrice:LD|UtilisateurLD ne fonctionnerait pas puisqu'il manque un : mais Utilisatrice:LD|Utilisateur:LD ou Utilisat(rice|eur):LD ou d'autres formes similaires macheraient.
  • username n'existe pas mais user_name existe : là, l'éditeur de filtre met en évidence ce qui ne va pas, tout comme la vérification de la syntaxe (sinon le manuel susmentionné).
  • Une subtilité sur le code proposé ci-haut : mes deux compères ne seraient pas seulement interdits à l'édition (action == 'edit') : toutes leurs actions sur cette page seraient interdites (renommage/suppression par exemple).
match:="^Supertoff|Jules[*]$";
action == 'edit'
& article_namespace == 3
& page_title == "LD"
& user_name irlike match
Ce code marcherait (je ne dis pas que c'est le plus efficace et sûr, exemple : (user_name == "Jules[*]" | user_name == "Supertoff") serait bien pour éviter la notion de ressemblance), mais penses-tu que je puisse l'utiliser car je suis AF, si oui pourquoi, si non pourquoi pas ? (je pense que c'est la question la plus importante de ma série). Bien à toi, LD (d) 10 août 2022 à 19:07 (CEST)Répondre[répondre]
Ton code d'origine détecterait aussi "Jule" Émoticône 'toff [discut.] 10 août 2022 à 19:30 (CEST)Répondre[répondre]
Oui, même plus large émoticône Gros yeux !. LD (d) 10 août 2022 à 23:04 (CEST)Répondre[répondre]
@LD pour
::::match:="^Supertoff|Jules[*]$";
::::action == 'edit'
::::& article_namespace == 3
::::& page_title == "LD"
::::& user_name irlike match
::::
Si il y en a le besoin oui (par exemple @Jules* te spamme des photos de minous Émoticône ou que @Supertoff spamme son site préféré) cela leur empêchera toutes actions sur ta PDD, le namespace 3 étant pour la PDD Donc discussion utilisateur:LD donc le mieux ça serait selon moi, pour éviter un potentiel FP :
match:="^Supertoff|Jules[*]$";
action == 'edit'
& article_namespace == 3
& page_title == "Discussion utilisateur:LD"
& user_name irlike match
Voîla, Merci de ta réponse détaillé, j'ai encore appris !  S̲e̲t̲h̲  ᴍɪᴀᴜʟᴇ ᴄʜᴇᴢ ᴍᴏɪ Logo Patrouille.svg 10 août 2022 à 19:42 (CEST)Répondre[répondre]
Merci pour cette réponse.
En effet, selon le besoin et la gravité à jauger avec prudence et discernement, un AF peut se servir de ce genre d'outils néanmoins il est d'usage que les blocages ou les restrictions thématiques sur des comptes restent réservés aux admins, et doivent être utilisés que dans l'intérêt de Wikipédia, après un consensus ou en dernier recours (urgence manifeste).
  • Scénario catastrophe : si un AF venait à agir de manière suspecte, la première réaction à avoir serait de contacter les bureaucrates, voire les stewards et T&S pour un retrait immédiat des droits et bloquer le compte. Mais le scénario catastrophe a une probabilité quasi-nulle d'arriver avec l'activation de la double authentification (je recommande donc son activation).

J'imagine que les bureaucrates liront ce bulletin pour traiter ta demande.
@LD, à mon tour de poser une question :
::::::match:="^Supertoff|Jules[*]$";
::::::action == 'edit'
::::::contains_any = SiriusSeth|SiriυsSeth
::::::& article_namespace == 3
::::::& page_title == "Discussion utilisateur:LD"
::::::& user_name irlike match
::::::
Est ce que cela bloquera l'ajout de SiriusSeth et SiriυsSeth sur là dit page ? (j'ai fait exprès d'ajouter le υ grec)  S̲e̲t̲h̲  ᴍɪᴀᴜʟᴇ ᴄʜᴇᴢ ᴍᴏɪ Logo Patrouille.svg 11 août 2022 à 10:19 (CEST)Répondre[répondre]
Salut. Je laisse LD répondre parce que ce n'est pas élément usuel pour moi Émoticône mais la syntaxe serait plutôt :
contains_any ("SiriusSeth" , "SiriυsSeth")
Perso j'utiliserais juste parce que LD n'aime pas irlike :
added_lines irlike "Siri(u|υ)sseth"
'toff [discut.] 11 août 2022 à 18:36 (CEST)Répondre[répondre]
@SiriusSeth ce code ne pourrait pas être publié, la syntaxe est incorrecte.
contains_any est une fonction, et non une variable : pour fonctionner, il lui faut une variable et au moins un argument ; par exemple, contains_any(user_name, "SiriusSeth", "SiriυsSeth") (pour upsilon, on peut recourir à ccnorm ou variantes, ou [uυ].) Il faut surtout un connecteur logique (graphique) dans une instruction conditionnelle, des boléens : | (OR), & (AND), ^ (XOR) ou encore !<condition> (NOT). Idem sur le type de données : il faut encadrer une chaîne de caractères par " ou '. Écrire & contains_any(<variable (chaîne)>, "chaîne1") serait ici obligatoire, bien que tu puisses théoriquement utiliser cette fonction pour d'autres types de données (entier, boléen, ...).
  • Néanmoins, je déconseillerais d'utiliser contains_any et variantes pour les noms d'utilisateur, sauf dans certains cas très précis, car si le compte « SiriusSethExemple » ou « ExempleSiriusSeth » sont créés, il seront également soumis à la condition.

L'avantage c'est que la personnalisation de l'interface que j'ai proposée met en évidence les variables dépréciées, les fonctions ou la mauvaise syntaxe (pas au niveau de la logique mais plutôt du côté de l'« aberrant », notion volontairement vague que je ne peux pas définir ici : cela reviendrait à donner des pistes de contournements de certains filtres, y compris publics).

L'essentiel du savoir technique que nous avons se trouve dans mw:Extension:AbuseFilter/Rules format/fr, le restant se trouve dans l'expérience des AFs ou les notes de filtre. LD (d) 11 août 2022 à 19:28 (CEST)Répondre[répondre]
Je n'avais pas rafraîchi la page ; en effet, j'ai la critique facile sur les constructions avec irlike (user_name irlike ...Sourire diabolique), mais j'évite de m’en plaindre trop souvent (pas taper émoticône Gros yeux !). LD (d) 11 août 2022 à 19:39 (CEST)Répondre[répondre]
Notification LD : j'ai failli aussi parler de ccnorm qui est assez puissant mais je me suis abstenu parce que dans le cas présent, à priori, ça ne fonctionne pas. Je te laisse trouver pourquoi Émoticône 'toff [discut.] 11 août 2022 à 21:42 (CEST)Répondre[répondre]
@Supertoff Je cherche aussi !  S̲e̲t̲h̲  ᴍɪᴀᴜʟᴇ ᴄʜᴇᴢ ᴍᴏɪ Logo Patrouille.svg 11 août 2022 à 21:47 (CEST)Répondre[répondre]
Je vous donne un indice : il y a le même problème avec vν Émoticône 'toff [discut.] 11 août 2022 à 22:06 (CEST)Répondre[répondre]
Je donnerais une réponse après toi. LD (d) 11 août 2022 à 22:30 (CEST)Répondre[répondre]
AH AH ! ccnorm ne fait pas la différence entre le V grec et le V français !  S̲e̲t̲h̲  ᴍɪᴀᴜʟᴇ ᴄʜᴇᴢ ᴍᴏɪ Logo Patrouille.svg 11 août 2022 à 22:31 (CEST)Répondre[répondre]

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

Là c'est le moment où je critique le fameux irlike (voire l'extension) :
  • Une liste de caractères similaires (homoglyphes ou pas) a été créée pour AntiSpoof (infos techniques sur Equivset) puis importée dans l'extension AbuseFilter ;
  • ccnorm utilise la liste (c'est génial) mais, même avec irlike (/iu), quand il cherche upsilon (υ) il n'a pas l'air de pouvoir trouver V et/ou U, donc il est incapable de vérifier la condition ; bêtement, je ne m'y attendais pas puisque upsilon figure bien dans la liste, par deux fois ;
  • pour nu (lettre grecque) : il renvoie N, mais pas V (un choix des développeurs qui s'explique, a priori, car la capitale de la lettre est Ν)
J'ai essayé de contourner le problème pour donner tort à Supertoff Sourire diabolique ma curiosité. Par exemple la syntaxe suivante fonctionne :
match:= str_replace("Supertōff", "ō", "o");
user_name irlike ccnorm(match)
Mais tous les caractères testés (non latins, non latins étendus) ne fonctionnent visiblement pas sur cette fonction (même en cherchant la propriété de l'unicode comme \p{Greek})
Je m'avoue vaincu Supertoff (Smiley: triste), du moins pour l'instant car les dévs n'ont pas fini leur tâche sur ccnorm. LD (d) 12 août 2022 à 03:18 (CEST)Répondre[répondre]
@LD @Supertoff, je reviens, j'ai besoin d'un doliprane Émoticône, en tout cas c'est intéressant !  S̲e̲t̲h̲  ᴍɪᴀᴜʟᴇ ᴄʜᴇᴢ ᴍᴏɪ Logo Patrouille.svg 12 août 2022 à 11:51 (CEST)Répondre[répondre]
Vous m'avez perdu. — Jules* discuter 12 août 2022 à 16:07 (CEST)Répondre[répondre]
La conclusion : il est difficile de tout maîtriser, il faut tester, consulter ses pairs et chercher à comprendre. LD (d) 12 août 2022 à 16:44 (CEST)Répondre[répondre]
Notification Jules* : je te rassure, quand LD parle de pairs, c'est pas de moi dont il s'agit Émoticône 'toff [discut.] 12 août 2022 à 17:05 (CEST)Répondre[répondre]
@Jules* tu n'es pas vraiment le seul Émoticône  S̲e̲t̲h̲  ᴍɪᴀᴜʟᴇ ᴄʜᴇᴢ ᴍᴏɪ Logo Patrouille.svg 12 août 2022 à 17:27 (CEST)Répondre[répondre]
Miaou Émoticône je n'ai bien sûr rien à dire sur la technique, puisque je n'interviens dans les filtres que pour des modifs très basiques et surtout pour vérifier certaines actions néfastes (dans l'objectif de bloquer les vandales, pénibles & harceleurs qui déclenchent le filtrage). Toujours est-il que SiriusSeth est un patrouilleur régulier et à cet égard, je lui fais confiance. Surtout qu'il est inféodé aux minets. Sourire diaboliqueBédévore Cat Cabal logo.svg [plaît-il?] 15 août 2022 à 11:29 (CEST)Répondre[répondre]
Hello @Jules*, @LD, @Supertoff, la date est passée sans que je m’en rende compte, Merci pour vitres confiance !
@Bédévore Pas que.. il y a le chocolat aussi :)  S̲e̲t̲h̲  ᴍɪᴀᴜʟᴇ ᴄʜᴇᴢ ᴍᴏɪ Logo Patrouille.svg 19 août 2022 à 10:09 (CEST)Répondre[répondre]

Retour (chariot|à la ligne)[modifier le code]

Salut les experts. Z'avez vu ? J'ai mis de la Regex dans le titre ! Émoticône

Trêve de plaisanterie, voilà ma question :
Si on utilise la syntaxe suivante :

match:="Supertoff|Jules\*|LD";
added_lines irlike match

tout ajout d'un des trois noms est détecté.
Si on utilise la syntaxe suivante :

match:="Supertoff|Jules\*
|LD";
added_lines irlike match

alors les ajouts de "Jules*" (s'ils sont seuls sans "Supertoff" ou "LD") ne sont plus détectés. Vous pouvez par exemple tester sur ce diff.
De même, si on utilise :

match:="Supertoff
|Jules\*|LD";
added_lines irlike match

alors c'est la détection "Supertoff" qui ne fonctionne plus. Test par exemple sur ce diff

En résumé, pour moi il n'y a pas de différence entre les deux pourtant pour les filtres (qui n'indiquent aucune erreur) il y en a une : le terme précédent le retour à la ligne "accolé" au retour à la ligne n'est plus détecté. C'est un fonctionnement normal ou un bug ? Perso, sur certains gros filtres (309 par exemple), le retour à la ligne permettrait une visualisation plus facile. 'toff [discut.] 19 août 2022 à 09:29 (CEST) Edit : dans le cas ou on laisse le "ou" sur la ligne précédente, c'est le terme suivant le retour à la ligne qui n'est plus détecté. Dans l'exemple ci-dessous, c'est "Jules*".Répondre[répondre]

match:="Supertoff|
Jules\*|LD";
added_lines irlike match

'toff [discut.] 19 août 2022 à 09:33 (CEST)Répondre[répondre]

Salut @Supertoff ;
Ce n'est pas un bug, ni une erreur, dès lors que tu utilises un caractère dans une expression régulière, celui-ci est littéralement interprêté d'où le problème avec les * ? . par exemple. Cela rejoint une discussion que nous avons eu en privé sur les caractères de contrôle : le retour chariot est un caractère de contrôle Émoticône. Pour le filtre*, que tu recherches \r, un retour chariot en littéral ou U+000D en dur (\x{D}), c'est pareil.
Si tu n'utilises pas une variable à expression régulière mais outre chose, par exemple des uplets, tels que suivent, tu n’as pas ce problème sauf si tu coupes le mot en deux, regarde avec :
match:=["Supertoff", "Jules*", "LD"];
user_name in match
puis avec
match:=["Supertoff


", "Jules*", "LD"];
ou
match:=["


Supertoff", "Jules*", "LD"];
J'ai néanmoins une solution qui devrait te plaire Émoticône sourire: les concaténations comme :
match:="Supertoff"
+ "|Jules\*"
+ "|LD";

user_name irlike match
Bien à toi, LD (d) 19 août 2022 à 11:09 (CEST)Répondre[répondre]
n.b. * : je ne parle que du « chariot » mais c'est un peu bête … soupir… car le filtre ne fonctionne pas comme un terminal/une console, je ne crois pas que tu puisses rechercher \r tout seul. Selon le système utilisé, il y a bien des subtilités mais je doute qu'il y en ait une ici. Je crois plutôt que le filtre fonctionne sur le modèle Windows en recherchant \r\n, donc le chariot (\r) + le retour à la ligne (\n ou \x{A} ou U+000A), mais si c'était une console \r suffirait (pour l’anecdote, Unix n'aime pas trop \r et préfère \n). Cela ne change pas la conclusion : les deux sont des caractères de contrôle qui sont interprêtés littéralement en regex. LD (d) 19 août 2022 à 11:52 (CEST)Répondre[répondre]
La concaténation, c'est bien, je l'avais déjà utilisée dans certains filtres, mais il faut faire gaffe à ne pas s'embrouiller avec les pipes | (qu'ils ne soient pas surnuméraires ou qu'il n'en manque pas). Sinon, je partage ton objectif de rendre les longues regex plus lisibles, @Supertoff. — Jules* discuter 19 août 2022 à 12:04 (CEST)Répondre[répondre]
On peut passer en revue et concaténer ;
J'en profite pour dire qu'en secret j'ai commencé à réécrire le 319 (c'est un brouillon, je teste de nouvelles variables Oh ! et je ne voudrais pas mettre en note avant qu'il soit compréhensible [pour moi en premier déjà Sourire diabolique, ce qui est loin d'être gagné en l'état]).
Personnellement, j'aime assez l'idée de faire plusieurs variables distinctes grâce à un classement thématique, ou numéraire, puis les concaténer ensemble ; plutôt que de garder une variable fourre-tout concaténée. On évite mieux les problèmes de pipes àmha puisqu'on ne retouche pas la concaténation de variables mais les expressions, tout en optimisant les regroupements, la vérification lors des FPs, les retraits pour inactivité voire l'écriture puisqu'on s'épargne l'obligation de faire "matcher" systématiquement l'ensemble. C'est notamment ce que je voulais faire pour la version en travaux du 378 et le 319 donc.
Il y a plein de choses que je voudrais faire, mais j'ai aussi moins de temps : si vous voyez des priorités de chantier... LD (d) 19 août 2022 à 12:53 (CEST)Répondre[répondre]
Typiquement, les filtres comme le 309 ou le 133 contiennent de longues regex. L'avantage d'avoir une regex par ligne, c'est la possibilité de pouvoir insérer un commentaire pour chaque élément, si besoin. Bon, après, il y a aussi que l'interface de l'outil Abusefilter est perfectible. — Jules* discuter 19 août 2022 à 13:24 (CEST)Répondre[répondre]
Merci de vos retours
@LD j'avais subodoré le fait que les caractères de contrôle soient pris en compte (surtout après ma vérification des détections en fonction de l'emplacement du retour à la ligne)
mais je n'avais pas pensé à la concaténation (surtout que dans mon esprit, hors regex, "+" = "ou" Émoticône)
@Jules* la possibilité de pouvoir insérer un commentaire pour chaque élément est totalement dans l'esprit de ce que j'escomptais, essentiellement pour le filtre 309 pour lequel je pourrai supprimer le long commentaire actuel qui suit -> insertion derrière chaque élément qui le nécessite (ceux qui ne sont pas visuels directement ou qui ont des variantes).
A vous deux : je vais m'atteler à rendre le filtre 309 "plus lisible" avec la concaténation Émoticône sourire 'toff [discut.] 19 août 2022 à 13:40 (CEST)Répondre[répondre]

┌─────────────────────────────────────────────────┘
Notification Jules* et LD : voilà. C'est beaucoup plus lisible et normalement, il n'y a pas d'erreur : l'avantage quand tu "gères" assez souvent un même filtre, c'est qu'il est plus facile de repérer les points de retour à la ligne sans te mélanger les pinceaux entre les pipes. 'toff [discut.] 19 août 2022 à 17:23 (CEST)Répondre[répondre]

Merci @Supertoff WikiThanks ! — Jules* discuter 19 août 2022 à 17:31 (CEST)Répondre[répondre]
Merci, 🌺🌹🌸 (moi, c'est bouquet Émoticône). LD (d) 19 août 2022 à 19:34 (CEST)Répondre[répondre]
N.b. j'allais te parler de la l. 84 car cela changeait (de beaucoup) son utilisation mais tu as rétabli. Il y a peut-être un entre deux mais il faudrait 2 variables. LD (d) 19 août 2022 à 19:39 (CEST)Répondre[répondre]
Merci @Jules* et @LD pour... les remerciements Émoticône. Pour la l. 84, c'est une erreur de ma part recupérée depuis mes tests : mea culpa ! (actuellement, je pense que la valeur de cette variable est OK). 'toff [discut.] 19 août 2022 à 22:51 (CEST)Répondre[répondre]

┌─────────────────────────────────────────────────┘
Nota : en plus, comme c'est beaucoup plus lisible, c'est beaucoup plus pratique pour détecter les faux-positifs Émoticône sourire. 'toff [discut.] 20 août 2022 à 11:26 (CEST)Répondre[répondre]

Le 336 est également un bon candidat à la concaténation, pour une présentation et une traçabilité plus claires. — Jules* discuter 21 août 2022 à 01:53 (CEST)Répondre[répondre]
Notification Jules* : j'ai bien compris le message subliminal qui m'était adressé : filtre 336 modifié Émoticône. @LD et @Jules* en dehors de ça, même si ce n'est pas le même but au départ, je pense que les lignes #1, #3 et #7 du 336 font doublon respectivement avec les lignes #54, #5 et #25 (c'est simple la recherche maintenant !) du 309 : il y a très peu de chance que le filtre 336 se déclenche sans le 309. Vos avis ? 'toff [discut.] 21 août 2022 à 08:17 (CEST)Répondre[répondre]
Émoticône Supertoff. Oui effectivement, on pourrait ne garder que la mention dans le filtre 309 si le forcing passe aussi par autre chose que des créations d'article (ajout de liens rouges, mentions dans le corps des articles) ; si à l'inverse seules des créations d'article ont été constatées, alors le 336 devrait suffire. — Jules* discuter 21 août 2022 à 12:23 (CEST)Répondre[répondre]
Notez que pour les liens rouges d'articles supprimés en PàS débat d'admissibilité, j'avais créé le filtre 355 spécifique qui est en partie du à BN. L'avantage de ce filtre est qu'il est facilement modifiable par un AF non initié aux regex (sans avoir peur d'oubli de pipe par exemple) : un copié/collé simple est efficace.
Comme quoi, le 361, le 363, le 309, le 355, le 336 sont étroitement liés et peuvent créer des doublons.
Dans le 336, j'ai supprimé les 3 doublons 309/336 et j'ai mis une note. 'toff [discut.] 21 août 2022 à 13:46 (CEST)Répondre[répondre]
Àmha, l'articulation entre le 355, le 336 et le 309 devrait être clarifiée dans Wikipédia:AbuseFilter/Tableau de bord (et dans l'intro de la zone commentaires des filtres ?). — Jules* discuter 21 août 2022 à 14:02 (CEST)Répondre[répondre]
Bonne idée. Au passage, je viens de modifier le message du filtre 336 pour qu'il soit plus explicite. 'toff [discut.] 23 août 2022 à 12:19 (CEST)Répondre[répondre]

365 et 148 ; 133[modifier le code]

Hello,

Je vais essayer de m'occuper dans les jours à venir de déplacer certains éléments du 365 vers le 148 (et supprimer des doublons aussi), car le 365 détecte d'autres pénibles. Le but étant que le 365 ne détecte plus que ce qui est propre au pénible visé, tandis que le 148, plus large, pourra offrir une protection pérenne aux contributeurs en question.

Je vais aussi essayer de faire du ménage dans le 133, avec prudence évidemment. — Jules* discuter 21 août 2022 à 01:09 (CEST)Répondre[répondre]

Alors, le ménage dans le 133 est fastidieux, mais avance bien : beaucoup de trucs ajoutés en 2016 et totalement obsolètes aujourd'hui. Un certain nombre d'ajouts n'ont pas fait l'objet de commentaire, donc sauf si je parviens à retrouver l'origine, je dégage. D'autres ajouts sont commentés mais passez, genre : l'identifiant d'une vidéo YT avec pour commentaire « vidéo youtube spammée par le pénible italien selfie » : sans nom de compte ni titre d'article, dur de retrouver le spam (et de vérifier s'il se poursuit ou non).
Par ailleurs, plusieurs regex dans le filtre 133 visaient des sites web spammés, avec contournement de Mediawiki:Spam-blacklist (qui ne détecte que les url fonctionnelles, pas la simple mention du nom de domaine). La majorité de ces regex était obsolète donc j'ai fait le ménage, mais le nombre d'occurrences de ces ajouts me fait proposer la création d'un filtre dédié en appui de Mediawiki:Spam-blacklist. Ce sera plus simple à maintenir que dans le filtre 133 qui est fourre-tout. — Jules* discuter 21 août 2022 à 12:55 (CEST)Répondre[répondre]
Bonjour et merci @Jules*, favorable également à ce filtre complémentaire à Mw:S-b. J'ai recensé les filtres supprimés (dans le tableau de bord) dont vertains pourraient être recyclés (car 0 détection par exemple). LD (d) 22 août 2022 à 22:19 (CEST)Répondre[répondre]
Quand on regarde les filtres supprimés et/ou désactivés, on s'aperçoit quand même qu'il y en a un bon nombre qui sont soit des doublons, soit auraient pu être inclus dans d'autres. Il n'y a pas moyen de faire en sorte que la création d'un nouveau filtre soit assortie d'une forme d'avertissement ? Genre très gros bandeau genre « vérifiez que ce filtre ne peut pas être inclus dans un filtre déjà existant ou posez la question sur WP:BF ». On s'est aperçu récemment que le filtre 378 n'était pas nécessaire... 'toff [discut.] 22 août 2022 à 22:41 (CEST)Répondre[répondre]
@LD : on avait dit (je ne sais plus où) qu'il était généralement préférable de ne pas recycler d'anciens filtres, pour que ça reste lisible (notamment car les anciennes détections se retrouvent avec un titre de filtre incohérent). J'ai suggéré l'inverse pour le 378 car il était vraiment récent et avec très peu de détections, mais c'est une exception Émoticône.
@Supertoff : oui, tout à fait. Je viens de créer MediaWiki:Abusefilter-edit-subtitle-new avec un message d'avertissement qui s'affiche dans Spécial:Filtre antiabus/new. N'hésitez pas à retoucher. — Jules* discuter 23 août 2022 à 12:43 (CEST)Répondre[répondre]
Je me demande si ce n'est pas trop "light", j'ai failli ne pas le voir Émoticône : j'ai forcé la couleur en "noir" pour que ce soit plus visuel. mais je ne sais pas s'il ne faudrait pas mettre un cadre autour (voire un cadre "rouge"). 'toff [discut.] 23 août 2022 à 13:15 (CEST)Répondre[répondre]
@Jules* : àmha le recyclage n'est pas systématiquement problématique ; ex. que j'ai donné : ceux qui sont restés sans détection, voire ceux qui ont toujours été des filtres publics. Pour le reste, l'historique peut être aisément commenté en notes ou ailleurs. LD (d) 23 août 2022 à 16:04 (CEST)Répondre[répondre]
@LD : autant pour moi, je n'avais pas suivi ton lien et pas vu que tu avais justement fait le tri ! Désolé. Ceux sans détection peuvent en effet être recyclés sans problème. — Jules* discuter 23 août 2022 à 16:11 (CEST)Répondre[répondre]
✔️ Spécial:Abusefilter/41 est désormais le filtre complémentaire à Mediawiki:Spam-blacklist. — Jules* discuter 23 août 2022 à 16:29 (CEST)Répondre[répondre]
Notification LD : tu as fait exprès d'enlever la couleur noire du message ? Je trouve que c'est moins visible, même avec le cadre. 'toff [discut.] 23 août 2022 à 16:43 (CEST)Répondre[répondre]
@Jules*, no worries Émoticône sourire
@Supertoff, pas taper je voulais déplacer le css mais ça n'a pas eu l'effet escompté.

Salut @Orlodrim, j'ai tenté d'utiliser un css dans MediaWiki:Abusefilter-edit-subtitle-new via Modèle:AbuseFilter.css (qui pourrait être renommé, j'en conviens), mais j'ignore si TemplateStyles se charge dans AF (ou si je m'y suis bien pris) puisque cela ne s'affiche pas correctement dans Spécial:Filtre_antiabus/new, éventuellement on peut fusionner dans Common.css après la ligne 1918. Des suggestions ou des corrections à apporter pour que cela fonctionne bien ? BàT, LD (d) 23 août 2022 à 16:47 (CEST)Répondre[répondre]
Quand on peut, les css c'est bien ! (même si je n'y connais pas grand chose). 'toff [discut.] 23 août 2022 à 17:01 (CEST)Répondre[répondre]

✔️ Après plusieurs heures de labeur sur deux jours, j'ai fini le grand ménage dans le filtre 133, dont plus de 80 % était obsolète, et 5 % pas dans le bon filtre (au doigt mouillé). J'en ai profité pour utiliser une mise en page avec concaténation pour mieux s'y retrouver ; utiliser rcount, qui est la méthode la plus sûre pour éviter les FP et maximiser les détections pertinentes. @LD, je pense que le symbole en question peut rester dans ce filtre bloquant : aucune chance que ce ne soit pas un vandalisme. — Jules* discuter 23 août 2022 à 23:03 (CEST)Répondre[répondre]

Grand merci @Jules* ; en effet, le déplacement complet n'est pas approprié, mais je crois que le doublon sera exceptionnement utile pour étendre sa détection ; je l'ajouterais ultérieurement.
C'est de l'ordre du détail mais il peut toutefois y avoir des ajouts "non vandales", sa (première) signification n'est pas la même sur tout le globe. Par exemple, j'avais lu un article scientifique sur l'architecture de Yunnan qui l'utilise à plusieurs reprises de manière appropriée. La redirection utilisée pour ce symbole résume bien cette pluralité de sens. Mais oui, il est préférable d'avoir des FPs potentiels que de le laisser passer à tout va : coût bénéfice/risque, usage/marginalité sur notre wiki. LD (d) 24 août 2022 à 00:18 (CEST)Répondre[répondre]
Oui, surtout que le 133 ne s'applique pas à tous les contributeurs, donc le risque de FP est vraiment faible. Mais on avisera si besoin. — Jules* discuter 24 août 2022 à 00:57 (CEST)Répondre[répondre]

Filtre 366[modifier le code]

Salut. Je viens de voir que le filtre 366 est aussi un bon candidat à la concaténation. Je m'en occupe. 'toff [discut.] 31 août 2022 à 19:20 (CEST)Répondre[répondre]

Bon, j'ai réorganisé. J'ai supprimé quelques doublons, j'ai corrigé quelques trucs (\. au lieu de .), et du coup, je pense que certaines détections ne sont pas fonctionnelles car incompatibles avec la ligne 164 : lignes 24, 49 ou 68 par exemple. Vos avis ? 'toff [discut.] 31 août 2022 à 20:32 (CEST)Répondre[répondre]
Salut et merci @Supertoff, tu veux dire ligne 163, non ?
Le plus simple serait de retirer ce qu'ils ont en commun, tout en privilégiant la notion de ^blabla$. Ainsi, la fonction utilisée est  OK.
Sinon, il y a au moins une alternative testable : créer une fonction if then else end.
if [condition discriminante du format] [opérateur] [règle] (COR)
then
[fonction alternative : COR]
else
[COR : fonction principale sans discrimination = lignes 162 - 164]
end
Sans dire que cela marcherait, je l'ai testée pour une màj du 319 : je n'ai pas encore été déçu. LD (d) 31 août 2022 à 21:48 (CEST)Répondre[répondre]
Notification LD : quasi sûr que c'était 164 mais j'ai probablement enlevé une ligne entre-temps pour aérer Émoticône
C'était pour être sûr que mon impression était bonne : je suis plus pour l'option "simplification" que "complexification". Je vais étudier les cas qui posent problème et re-vérifier s'il n'y a pas d'autres cas avec des syntaxes erronées : par exemple, je pense qu'à la ligne 46, il vaudrait mieux remplacer \s par \b (en plus c'est moi qui ai mis \s) ? 'toff [discut.] 1 septembre 2022 à 07:05 (CEST)Répondre[répondre]
@Supertoff, j'ai préféré répondre dans le filtre 96 pour que cela ne donne pas trop d'idées et de détails sur le fonctionnement.
Je t'ai aussi répondu @SiriusSeth LD (d) 1 septembre 2022 à 11:01 (CEST)Répondre[répondre]
Notification LD : répondu à tes questions dans le filtre. 'toff [discut.] 1 septembre 2022 à 18:40 (CEST)Répondre[répondre]
@LD répondu  S̲e̲t̲h̲  ᴍɪᴀᴜʟᴇ ᴄʜᴇᴢ ᴍᴏɪ Logo Patrouille.svg 1 septembre 2022 à 19:09 (CEST)Répondre[répondre]

Vandalismes qui pourraient être filtrés[modifier le code]

Bonsoir, ce genre de Vandalisme, pourrait être filtré ? Surtout pour le mot Nudes.. Cordialement  S̲e̲t̲h̲  ᴍɪᴀᴜʟᴇ ᴄʜᴇᴢ ᴍᴏɪ Logo Patrouille.svg 31 août 2022 à 19:59 (CEST)Répondre[répondre]

Bonsoir,
Probablement, mais le mot « nude » n'est pas un mot qui implique nécessairement des vandalismes, cf. Nude Ce lien renvoie vers une page d'homonymie ou cette recherche sommaire. LD (d) 31 août 2022 à 21:51 (CEST)Répondre[répondre]
Merci @LD de cette précision, si par exemple on utilise Added lines : Mots choisi ou, si il y a, une variable permettant de savoir si l’utilisateur/IP a déjà été révoqué, de comparer avec le diff révoqué précédemment avec la modification en cours, en espérant avoir été clair  S̲e̲t̲h̲  ᴍɪᴀᴜʟᴇ ᴄʜᴇᴢ ᴍᴏɪ Logo Patrouille.svg 31 août 2022 à 22:21 (CEST)Répondre[répondre]
Cela s'apparente au throttling mais cela est inefficace contre le vandalisme à usage unique. Il n'y a pas de variable qui analyse si un utilisateur a été révoqué, ni de comparaison possible avec un ancien diff et la modification actuelle. Tu peux comparer la page dans sa verion actuelle et le diff proposé, ou vérifier que l'utilisateur a déjà contribué ou non (page_recent_contributors).
En comparant qu'avec added_lines, il y aura des faux-positifs ; il faudrait trouver des variables discriminantes. LD (d) 31 août 2022 à 22:51 (CEST)Répondre[répondre]
Salut. En accord avec LD : on a trop de chances de faux-positifs sans autres variables. 'toff [discut.] 1 septembre 2022 à 07:09 (CEST)Répondre[répondre]