Wikipédia:Bulletin du filtrage/2022

Bienvenue à Tractopelle-jaune

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)

Brigittenouasse : créations en chaîne

 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)

Ok, merci de l'info @Supertoff ! — Jules* ^Discuter 20 janvier 2022 à 18:13 (CET)

Et encore un nid de 3 'toff ^[discut.] 20 janvier 2022 à 18:20 (CET)

Ah, en effet… — Jules* ^Discuter 20 janvier 2022 à 18:20 (CET)

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)

Miaourci @Supertoff que de fourbasseries ! Quel pénible chronophage, faut passer son temps à bloquer les avatars au lieu de bosser sur autre chose. Bédévore ^[plaît-il?] 20 janvier 2022 à 18:30 (CET)

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 LD (d) 20 janvier 2022 à 18:34 (CET)

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)

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)

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 :

• Karama1234 (d · c · b), création du jour par Souhana1234 (d · c · b) qui a fait déclencher le filtre - bloqué ce jour
• Affouzay (d · c · b) créé le 15/01 par Souhana1234 (d · c · b) - bloqué ce jour
• ChounchSowski (d · c · b) créé le 16/01 par Affouzay (d · c · b) - bloqué le 16/01 par Bédévore
• Tyroblato (d · c · b) créé le 16/01 par ChounchSowski (d · c · b) - bloqué ce jour
• SoloYouncky (d · c · b) créé le 16/01 par ChounchSowski (d · c · b) - bloqué ce jour
• BlotkayMyra (d · c · b) créé le 16/01 par SoloYouncky (d · c · b) - bloqué ce jour

'toff ^[discut.] 21 janvier 2022 à 11:48 (CET)

Demande de fonctionnalités dans la liste de souhaits communautaire 2022

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

• AbuseFilter: Indicate that an edit was a revert ;
• Create CheckUser-level and Oversight-level abuse filters ;
• Add variables in AbuseFilter to detect/block thanks.

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)

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)

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)

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)

Collec de fausses truffes

Bonjour Miaou

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 ^[plaît-il?] 24 janvier 2022 à 12:45 (CET)

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

Kiev/Kyiv

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)

 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)

Sauf que le message du filtre est lui aussi dédié à Mahomet. 'toff ^[discut.] 5 mars 2022 à 12:02 (CET)

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)

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)

 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)

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

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)

C'est ce que j'avais en tête, hop c'est fait. — Thibaut (discuter) 5 mars 2022 à 16:49 (CET)

Flux structurés

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

+1 ! Déjà que je n'ai jamais bien compris comment le faire… ni pourquoi. Hyméros ^{--}-≽ ♥} 30 mars 2022 à 23:36 (CEST)

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)

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 3^e option, qui est de « Supprimer le sujet » (équivalent d'un masquage léger). Et les OS disposent sûrement encore d'une 4^e 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)

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

 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)

BN -> Subst

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)

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)

Filtre 209, NS/PF/BN

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 :

• BN, avec la stratégie du brouillon évoquée dans la section ci-dessus ;
• Noah Sokolowski (cf. Wikipédia:Faux-nez/Noah Sokolowski#IP mobiles Bouygues) et Papa Franck (cf. spécial:diff/193189383), ou bien l'un des deux imitant l'autre ; d'autant qu'il y a eu des mentions d'Apokrif (qui a aussi été repéré par Thibaut contournant son blocage via cette plage).

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)

Salut, , BàT LD (d) 29 avril 2022 à 18:30 (CEST)

Nouveaux filtres

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)

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)

 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)

@Tractopelle-jaune : Merci pour le suivi, que j'avais remarqué (notamment via les demandes de masquage) .

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)

 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)

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

Spécial:Filtre_antiabus/history/374/diff/prev/6094 (et suivant) . — Jules* ^discuter 1 mai 2022 à 22:37 (CEST)

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)

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)

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)

2^e 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 . 'toff ^[discut.] 2 mai 2022 à 10:20 (CEST)

Conflit d’édition —  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)

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)

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)

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)

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)

Perso (encore une fois), je pense que dans les commentaires de diff, c'est dispensable, non ? 'toff ^[discut.] 2 mai 2022 à 21:32 (CEST)

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)

Filtre anti-emojis (suite)

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)

Dernier ajout sur 209

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)

 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)

Merci pour cette correction qui dissipe distinctement tous les doutes. Bonne soirée, LD (d) 17 mai 2022 à 19:14 (CEST)

page_age == 0

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)

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)

Filtre 309

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)

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 . LD (d) 7 juin 2022 à 01:11 (CEST)

J'ai une question technico-pratique, mais j'ai « peur » de la mentionner car elle pourrait donner des idées aux plus mâlins. LD (d) 7 juin 2022 à 01:16 (CEST)

Il te reste le mail 'toff ^[discut.] 7 juin 2022 à 09:43 (CEST)

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

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)

Filtres 361 et 363

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)

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 'toff ^[discut.] 22 juin 2022 à 06:14 (CEST)

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)

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)

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)

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)

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)

366

 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)

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)

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)

Filtre 123

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 .

Dites-moi si ça vous va. — Jules* ^discuter 1 août 2022 à 23:46 (CEST)

Honnêtement, ça ne changera pas grand chose pour moi : je ne vais pas sur Wikipédia:AbuseFilter/Modifications bloquées . C'est peut-être un tort d'ailleurs ? Pas de soucis. 'toff ^[discut.] 2 août 2022 à 07:17 (CEST)

 Jules* : --Tractopelle-jaune (discuter) 3 août 2022 à 11:18 (CEST)

Messages AbuseFilter

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)

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)

Oui , c'est corrigé merci ! LD (d) 3 août 2022 à 16:14 (CEST)

I have a dream

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 'toff ^[discut.] 2 août 2022 à 16:25 (CEST)

Hey @Supertoff. Je suis beaucoup moins actif sur les filtres depuis plusieurs mois. Je compte m'y réinvestir, mais compliqué de tout concilier . — Jules* ^discuter 2 août 2022 à 16:57 (CEST)

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)

┌─────────────────────────────────────────────────┘
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 :

• Wikipédia:AbuseFilter/Faux positifs#Spécial:AbuseFilter/321 2022-02-04 03:28 —  Tractopelle-jaune et LD : je ne suis plus ce filtre et ses détections mais la requête étant ancienne, il faudrait peut-être classer sans suite ? Je vous laisse voir. 'toff ^[discut.] 3 août 2022 à 07:24 (CEST)
• Wikipédia:AbuseFilter/Faux positifs#Spécial:AbuseFilter/312 2022-07-04 03:46 —  Thibaut120094, Jules*, JohnNewton8, Bédévore, NB80, Bertrand Labévue et Fugitron : je ne connais Papa Franck que de nom donc je ne me prononcerai pas. J'ai notifié les contributeurs qui ont modifié la page de faux-nez associée et qui sont aussi AF.

'toff ^[discut.] 3 août 2022 à 07:24 (CEST)

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)

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ââââââ je kiffe ! 'toff ^[discut.] 6 août 2022 à 07:19 (CEST)

Merci encore pour le ménage. — Jules* ^discuter 6 août 2022 à 12:11 (CEST)

Amélioration du filtre 363 grâce au 209 ?

 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)

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)

@Jules* je te rassure, je ne connaissais pas non plus avant 'toff ^[discut.] 9 août 2022 à 13:32 (CEST)

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 (et vous me corrigez aussi quand le format n'est pas très naturel pour un filtre ). 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 ). LD (d) 9 août 2022 à 14:12 (CEST)

 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)

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)

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)

Je m'en souviens bien (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)

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)

Filtre 123 (2)

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 . LD (d) 10 août 2022 à 01:52 (CEST)

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)

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)

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)

Parfait, Coincoinci Supertoff LD (d) 10 août 2022 à 23:04 (CEST)

filtre 378 ?

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)

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)

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)

Effectivement, je vais le fusionner dans le 309. JackPotte ($♠) 9 août 2022 à 09:41 (CEST)

┌─────────────────────────────────────────────────┘
 JackPotte : j'ai transféré dans le filtre 309 et j'ai désactive le filtre 378.
 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)

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)

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

Merci @Jules* : j'ai activé avec le message & une nouvelle balise. LD (d) 21 août 2022 à 14:52 (CEST)

 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.

 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)

@Supertoff : car j'ai oublié ce point, tout simplement  ; c'est corrigé. Et non, mais je peux le faire. — Jules* ^discuter 23 août 2022 à 12:29 (CEST)

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)

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)

Parfait. — Jules* ^discuter 23 août 2022 à 12:44 (CEST)

┌─────────────────────────────────────────────────┘
 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)

Candidature AF : Abusefilter

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

Pourquoi ce statut ? :

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 ?

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 ?

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

• voir aussi : Discussion utilisateur:Jules*#Candidature AF

 S̲e̲t̲h̲  ^{ᴍɪᴀᴜʟᴇ ᴄʜᴇᴢ ᴍᴏɪ}  9 août 2022 à 20:43 (CEST)

Salut @Felix felines ;

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)

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

Moi je ne soumets pas de test, mais je regarderai les réponses aux deux autres . — Jules* ^discuter 9 août 2022 à 23:40 (CEST)

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̲  ^{ᴍɪᴀᴜʟᴇ ᴄʜᴇᴢ ᴍᴏɪ}  10 août 2022 à 09:53 (CEST)

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̲  ^{ᴍɪᴀᴜʟᴇ ᴄʜᴇᴢ ᴍᴏɪ}  10 août 2022 à 12:45 (CEST)

 Felix felines : 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 . 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)

@Supertoff Je ne l'avais pas dis/écris. Car cela me semblait évident, merci de la remarque  S̲e̲t̲h̲  ^{ᴍɪᴀᴜʟᴇ ᴄʜᴇᴢ ᴍᴏɪ}  10 août 2022 à 18:08 (CEST)

@LD Re, Pour le Genre, mettre Utilisatrice:LD|UtilisateurLD, Comme cela ça filtrera les deux ?  S̲e̲t̲h̲  ^{ᴍɪᴀᴜʟᴇ ᴄʜᴇᴢ ᴍᴏɪ}  10 août 2022 à 17:12 (CEST)

Merci Felix felines 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 ? ) 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)

Ton code d'origine détecterait aussi "Jule" 'toff ^[discut.] 10 août 2022 à 19:30 (CEST)

Oui, même plus large . LD (d) 10 août 2022 à 23:04 (CEST)

@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 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̲  ^{ᴍɪᴀᴜʟᴇ ᴄʜᴇᴢ ᴍᴏɪ}  10 août 2022 à 19:42 (CEST)

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.

• je n'ai pas d'objection à ta candidature. LD (d) 10 août 2022 à 23:30 (CEST)

@LD, à mon tour de poser une question :

::::::match:="^Supertoff|Jules[*]$";
::::::action == 'edit'
::::::contains_any = Felix felines|SiriυsSeth
::::::& article_namespace == 3
::::::& page_title == "Discussion utilisateur:LD"
::::::& user_name irlike match
::::::

Est ce que cela bloquera l'ajout de Felix felines et SiriυsSeth sur là dit page ? (j'ai fait exprès d'ajouter le υ grec)  S̲e̲t̲h̲  ^{ᴍɪᴀᴜʟᴇ ᴄʜᴇᴢ ᴍᴏɪ}  11 août 2022 à 10:19 (CEST)

Salut. Je laisse LD répondre parce que ce n'est pas élément usuel pour moi mais la syntaxe serait plutôt :

contains_any ("Felix felines" , "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)

@Felix felines 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, "Felix felines", "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 « Felix felinesExemple » ou « ExempleFelix felines » 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)

Je n'avais pas rafraîchi la page ; en effet, j'ai la critique facile sur les constructions avec irlike (user_name irlike ...), mais j'évite de m’en plaindre trop souvent (pas taper ). LD (d) 11 août 2022 à 19:39 (CEST)

 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 'toff ^[discut.] 11 août 2022 à 21:42 (CEST)

@Supertoff Je cherche aussi !  S̲e̲t̲h̲  ^{ᴍɪᴀᴜʟᴇ ᴄʜᴇᴢ ᴍᴏɪ}  11 août 2022 à 21:47 (CEST)

Je vous donne un indice : il y a le même problème avec vν 'toff ^[discut.] 11 août 2022 à 22:06 (CEST)

Je donnerais une réponse après toi. LD (d) 11 août 2022 à 22:30 (CEST)

AH AH ! ccnorm ne fait pas la différence entre le V grec et le V français !  S̲e̲t̲h̲  ^{ᴍɪᴀᴜʟᴇ ᴄʜᴇᴢ ᴍᴏɪ}  11 août 2022 à 22:31 (CEST)

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

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

@LD @Supertoff, je reviens, j'ai besoin d'un doliprane , en tout cas c'est intéressant !  S̲e̲t̲h̲  ^{ᴍɪᴀᴜʟᴇ ᴄʜᴇᴢ ᴍᴏɪ}  12 août 2022 à 11:51 (CEST)

Vous m'avez perdu. — Jules* ^discuter 12 août 2022 à 16:07 (CEST)

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)

 Jules* : je te rassure, quand LD parle de pairs, c'est pas de moi dont il s'agit 'toff ^[discut.] 12 août 2022 à 17:05 (CEST)

@Jules* tu n'es pas vraiment le seul  S̲e̲t̲h̲  ^{ᴍɪᴀᴜʟᴇ ᴄʜᴇᴢ ᴍᴏɪ}  12 août 2022 à 17:27 (CEST)

Miaou 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 Felix felines est un patrouilleur régulier et à cet égard, je lui fais confiance. Surtout qu'il est inféodé aux minets. — Bédévore ^[plaît-il?] 15 août 2022 à 11:29 (CEST)

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̲  ^{ᴍɪᴀᴜʟᴇ ᴄʜᴇᴢ ᴍᴏɪ}  19 août 2022 à 10:09 (CEST)

Retour (chariot|à la ligne)

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

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*".

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

'toff ^[discut.] 19 août 2022 à 09:33 (CEST)

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 . 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 : les concaténations comme :

match:="Supertoff"
+ "|Jules\*"
+ "|LD";

user_name irlike match

Bien à toi, LD (d) 19 août 2022 à 11:09 (CEST)

n.b. * : je ne parle que du « chariot » mais c'est un peu bête … … 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)

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)

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 et je ne voudrais pas mettre en note avant qu'il soit compréhensible [pour moi en premier déjà , 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)

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)

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

@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 'toff ^[discut.] 19 août 2022 à 13:40 (CEST)

┌─────────────────────────────────────────────────┘
 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)

Merci @Supertoff  ! — Jules* ^discuter 19 août 2022 à 17:31 (CEST)

Merci, (moi, c'est bouquet ). LD (d) 19 août 2022 à 19:34 (CEST)

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)

Merci @Jules* et @LD pour... les remerciements . 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)

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

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)

 Jules* : j'ai bien compris le message subliminal qui m'était adressé : filtre 336 modifié . @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)

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)

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)

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

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)

365 et 148 ; 133

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)

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)

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)

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)

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

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

Je me demande si ce n'est pas trop "light", j'ai failli ne pas le voir  : 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)

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

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

Spécial:Abusefilter/41 est désormais le filtre complémentaire à Mediawiki:Spam-blacklist. — Jules* ^discuter 23 août 2022 à 16:29 (CEST)

 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)

@Jules*, no worries

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

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)

 LD : Ça ne fonctionne pas parce que NewAbuseFilter-help est un id dans MediaWiki:Abusefilter-edit-subtitle-new et une class dans Modèle:AbuseFilter.css. od†n ↗^blah 18 mars 2023 à 00:26 (CET)

Merci @Od1n :) LD (d) 18 mars 2023 à 00:32 (CET)

Ça ne fonctionne pas non plus en corrigeant la confusion id/class, parce que le message ne se trouve pas à l'intérieur d'un .mw-parser-output, et est donc en dehors du domaine d'application permis par les TemplateStyles. La seule solution serait donc de revenir à du CSS inline. (ça fonctionnerait peut-être en plaçant le CSS dans le fichier MediaWiki:Group-abusefilter.css, mais on va tout de suite éliminer cette solution, car cela rendrait le code CSS difficile à retrouver). od†n ↗^blah 18 mars 2023 à 15:45 (CET)

Je me perds facilement dans cela, c'est peut-être un signe que c'est mal foutu (si tant est que l'intention reste que chacun puisse aisément personnaliser...). Avoir le css de l'extension dans Mediawiki:AbuseFilter.css serait appréciable. Le plus simple reste de forcer la couleur dans MediaWiki:Abusefilter-edit-subtitle-new, à l'instar de ce qui existait avant. Pour la navigation, ce n'est pas MediaWiki:Abusefilter-topnav qui aidera donc le plus simple reste d'avoir dans son propre common.css :

.mw-abusefilter-navigation {
  color: #000000;
}

LD (d) 18 mars 2023 à 22:31 (CET)

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)

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)

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)

Filtre 366

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)

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)

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)

 LD : quasi sûr que c'était 164 mais j'ai probablement enlevé une ligne entre-temps pour aérer

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)

@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 @Felix felines LD (d) 1 septembre 2022 à 11:01 (CEST)

 LD : répondu à tes questions dans le filtre. 'toff ^[discut.] 1 septembre 2022 à 18:40 (CEST)

@LD répondu  S̲e̲t̲h̲  ^{ᴍɪᴀᴜʟᴇ ᴄʜᴇᴢ ᴍᴏɪ}  1 septembre 2022 à 19:09 (CEST)

Vandalismes qui pourraient être filtrés

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

Bonsoir,

Probablement, mais le mot « nude » n'est pas un mot qui implique nécessairement des vandalismes, cf. Nude  ou cette recherche sommaire. LD (d) 31 août 2022 à 21:51 (CEST)

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̲  ^{ᴍɪᴀᴜʟᴇ ᴄʜᴇᴢ ᴍᴏɪ}  31 août 2022 à 22:21 (CEST)

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)

Salut. En accord avec LD : on a trop de chances de faux-positifs sans autres variables. 'toff ^[discut.] 1 septembre 2022 à 07:09 (CEST)

Suite échange

Bonjour/Soir, Suite à la Discussion sur Le filtre 96, Si vous êtes d'accord, je commence les test ce soir ou demain sur mon compte de test, Cordialement  S̲e̲t̲h̲  ^{ᴍɪᴀᴜʟᴇ ᴄʜᴇᴢ ᴍᴏɪ}  3 septembre 2022 à 17:00 (CEST)

pour info, je pense que ce filtre est un bon candidat  S̲e̲t̲h̲  ^{ᴍɪᴀᴜʟᴇ ᴄʜᴇᴢ ᴍᴏɪ}  3 septembre 2022 à 17:06 (CEST)

Filtre nuisible ?

Salut. Je viens de voir sur la page du filtre 336, cet avertissement : « Attention : ce filtre a été automatiquement marqué comme nuisible. Aucune action n’a été automatiquement désactivée, mais veuillez vérifier si le taux élevé de correspondances est attendu. Si c’est le cas, vous pouvez ignorer cet avertissement. » C'est lié à quoi ? A un nombre de détections élevé récemment ? J'ai pourtant l'impression qu'il y a pire, le filtre 30 par exemple (sauf qu'il n'est pas bloquant) ? @LD et @Jules* si vous avez une idée ? 'toff ^[discut.] 5 septembre 2022 à 07:06 (CEST)

Salut, c'est le ratio actions filtrées et actions récentes totales qui entrent en jeu. En pleine nuit européenne, ce n'est pas étonnant que cela s'active lors d'un spam, ce qui est le cas ici.

Lorsqu'une condition active le filtre beaucoup de fois en peu de temps, il y a l'avertissement de vérification, avant celui de désactivation du filtre. Notre configuration compte à partir de 2(%?) modifications filtrées suite à un changement du filtre pour envoyer cet avertissement : c'est parfois bas, cela s'active assez souvent lorsque l'activité diminue en métropole française.

Sauf si on s'approche des 5% d'actions totales récentes filtrées, il n'y a vraiment de quoi s'inquiéter. Le compteur se remet à jour chaque 24 heures pour un arrêt d'urgence, j'imagine que c'est pareil pour cet avertissement, voire moins. Un arrêt d'urgence ne serait pas très grave non plus ceci dit. LD (d) 5 septembre 2022 à 09:30 (CEST)

OK merci : c'est le lien un changement récent du filtre que je n'avais pas. 'toff ^[discut.] 5 septembre 2022 à 09:55 (CEST)

Pages utilisateurs et renommages "maladroits" : extensions des filtres n°7 ou n°228 ?

Bonjour,

Au détour de ce renommage, je pense que les filtres n^os 7 et 228, dits « renommage de page utilisateur par un nouvel utilisateur » et « Déplacement de PU vers l'espace principal », peuvent (devraient) être étendus. Inspirés du filtre n^o 5 anglophone, ce dernier me semble plus large dans sa finalité (quoi que pas assez large àmha).

Les pages utilisateurs (PU et PDDu) n'ont pas pour vocation à être déplacées dans n'importe quel autre espace et n'importe comment :

1. Les pages PU peuvent être renommées à la suite d'un renommage de compte (ou archivées dans le même espace, sous le même nom de compte)
   • les sous-pages servent de brouillon (on peut les exclure)
2. Les pages PDDu sont vouées à être archivées, parfois par déplacement a priori dans le même espace, bien que l'on peut accepter le jonglage entre espace utilisateur et espace dicussion utilisateur, tant qu'il s'agit toujours du même utilisateur...

En-dehors de ce 1^er cas, existe-t-il des cas où la page principale (pas les sous-pages) peut être déplacée vers un autre espace que ces deux là (espace utilisateur et espace dicussion utilisateur) ?

• Filtre n°7 ? :
  • Les PDDs d'utilisateur ne devraient quasiment jamais être déplacées ailleurs (hors ns:2 et ns:3) : elles ne peuvent pas servir de brouillon, à moins de jouer avec l'intégrité des historiques (scissions régulières). En admettant que pour une raison spéciale ce soit nécessaire, alors être autopatrolled devrait être un pré-requis (si ce n'est admin, steward, bot, etc.).
  • Quant aux sous-pages PPDu, elles ne devraient pas être déplacées hors ns 2 et ns 3 pour au moins les non autopatrolled. WP:DR en cas de raison valable me semble bienvenue.
• Filtre 228 ? :
  • Alternativement, les sous-pages PDDu peuvent être journalisées au déplacement (sauf si déplacées par bot, admin, etc.).
  • En admettant que la PU serve de brouillon (pourquoi pas), il faudrait alors a minima journaliser et baliser ces déplacements.

Heureusement, l'un est bloquant et l'autre balisant, ils peuvent être étendus et nous ne sommes pas contraints de créer un nouveau.

Je pense que les cas sont relativement rares, mais lorsque cela se produit, aucune garantie que quelqu'un s'en rend(e)* compte non plus : que dîtes-vous de tout cela ? * subjonctif et indicatif valables LD (d) 7 septembre 2022 à 04:28 (CEST)

Salut. Vite fait en passant, pour le cas 1 (hors brouillon) : ce n'est pas le contributeur qui renomme son compte cf Aide:Changer de nom d'utilisateur#Conséquences. Donc ce n'est pas à prendre en compte pour les filtres puisque limité à certains groupes de contributeurs. 'toff ^[discut.] 7 septembre 2022 à 12:24 (CEST)

Si le renommage de compte n'est possible que par un renommeur global, le déplacement reste possible et ce dès 4 jours (autoconfirmed) : on s'approche de ceci, mais j'aurais pu déplacer ma PU n'importe où LD (d) 9 septembre 2022 à 04:03 (CEST)

J'ai bien compris (et je vais clarifier mon propos) : dès lors que le renommage de PU fait suite à un renommage de compte, il n'est pas fait par le contributeur lui-même, quel que soit son statut (toi ou moi y compris) : c'est une action faite suite à une action d'un renommeur global. Il n'y a donc pas lieu pour un contributeur de renommer son compte. En résumé, dans le cadre du filtre : renommage de PU = interdit pour tous (éventuellement hors admin car je ne sais pas si ça ne bloquera pas le renommage global). Donc non, il ne faut pas dire "Les pages PU peuvent être renommées à la suite d'un renommage de compte". 'toff ^[discut.] 9 septembre 2022 à 07:11 (CEST)

Filtre 378 : émoticônes

Bonjour à vous,

Je suis (enfin ) parvenu à faire une refonte qui me convient et j'espère qu'elle vous conviendra aussi. J'ai testé des milliers de révisions, il ne semble pas avoir de faux-positif mais tout n'est pas filtré non plus (les notes expliquent pourquoi).

Il reste une interrogation aux lignes 5-6 et un autre point qui me semble pouvoir être étudié (en notes "A étudier [...]"), mais pas nécessairement sur ce filtre. Pour aller au plus simple, je propose d'exclure la ligne 5 et mon objet d'étude qui n'est pas encore inclu, et de les mettre dans un des filtres de test disponible pour suivre les révisions (en journalisation simple sur deux semaines - 1 mois), nous aviserons ensuite.

Le reste du filtre me semble pouvoir être activé mais rien ne presse : nous pouvons encore échanger dans les jours ou semaines à venir, surtout si vous voyez des points sur lesquels vous voyez une révision ou un ajout nécessaire (ou simplement si vous voulez en discuter) ; j'ai inclu les liens internes vers les blocs utilisés, cela facilitera grandement à la compréhension de ce jargon (que nul ne devrait apprendre par coeur ).

Je peux aussi rédiger une note complémentaire qui compare le fonctionnement avec le filtre global : il y a des blocs supplémentaires, et ils autorisent certains caractères de blocs particuliers, et je n'ai pas vu de raisons de suivre le même découpage pour deux grandes tables. Sans être opposé ou réticent, suivre les mêmes exclusions, lignes 11 à 14, ne me semble pas très utile aujourd'hui mais pourquoi pas les adapter.

Voilà, j'ai fait le tour de ce que je souhaitais partager, si ce n'est ce bonus : j'ai annulé ce diff (et le précédent) sur la base d'un dernier test, nous nous approchons donc du but

Bonne journée, LD (d) 29 août 2022 à 05:38 (CEST)

 LD : salut. cette création est passée au travers ? 'toff ^[discut.] 23 septembre 2022 à 16:10 (CEST)

Salut @Supertoff, ma proposition n'est pas encore activée (j'attendais d'éventuels retours), elle filtre ce diff. LD (d) 23 septembre 2022 à 19:55 (CEST)

Pas compris de quoi tu parles mais je suis assez déconnecté des filtres en ce moment et je te fais confiance. 'toff ^[discut.] 23 septembre 2022 à 21:37 (CEST)

Restructuration filtre 319

Salut. Pour info, j'ai restructuré le filtre 319 comme on l'avait déjà fait pour d'autres. De mémoire,  LD c'était pas un de tes projets ? En tout cas ,c'est fait. Comme d'hab, ça a permis d'éliminer des doublons 'toff ^[discut.] 1 novembre 2022 à 13:22 (CET)

Salut et merci cet avancement qui fait du bien ; ce filtre fait en effet partie mes projets, mais pas d'inquiétude cela ne perturbe en rien celui-ci : il vise d'autres règles décrites par WP:NUI qui devraient s'ajouter aux règles déjà comprises.

J'ai ajouté quelques idées de réflexion. BàT, LD (d) 1 novembre 2022 à 22:49 (CET)

Demande de statut AF

Bonsoir

Je viens de solliciter le statut....

Bien cordialement. --O-R (discuter) 1 novembre 2022 à 22:28 (CET)

Bonsoir, de droit, bienvenue à @Culex et à toi. LD (d) 1 novembre 2022 à 22:55 (CET)

Merci @LD !

Merci également @LD ! Culex (discuter) 1 novembre 2022 à 23:33 (CET)

Préchargement des demandes

Salut à tous.  LD et Jules* notamment mais tous les avis sont évidemment bienvenus. Actuellement, quand un contributeur clique sur le bouton "Signaler un faux positif", ça charge par défaut :

• Titre :

<code>[[Spécial:AbuseFilter/ ]] {{#timel:Y-m-d H:i}}</code>

• Texte :

<!-- Écrivez dans la boîte ''Sujet/titre'' ci-dessus : [[Spécial:AbuseFilter/numéro du filtre]], puis remplissez les rubriques ci-dessous -->

<small>Demandé le <includeonly>~~</includeonly><includeonly>~</includeonly><includeonly>~~</includeonly> par <includeonly>~</includeonly><includeonly>~~</includeonly></small> <!-- ne modifiez pas cette ligne -->

'''Utilisateur''' : <includeonly>{{u|{{subst:REVISIONUSER}}}} {{subst:AJournal}}</includeonly> <!-- ne modifiez pas cette ligne si vous êtes celui qui a déclenché le filtre -->

'''Numéro du filtre déclenché''' : 

'''Commentaire''' :<noinclude>

Je trouve que le préchargement du titre n'est pas très efficient :

• Souvent, des contributeurs déclenchent plusieurs filtres à la fois ;
• Le lien par défaut ne permet pas de renvoyer vers les filtres globaux ;
• Les contributeurs ne lisent pas le texte donc ne remplissent pas le titre (90 % des cas àmha) ;
• Les contributeurs ne lisent pas le texte donc ne remplissent pas le numéro de filtre dans le texte.

Je vous propose donc quelques modifications pour faciliter notre maintenance :

• Titre : précharger un modèle qui permet plusieurs numéros de filtre et un lien vers meta. J'ai fait quelques test sur Utilisateur:Supertoff/modèle :
  • {{#timel:Y-m-d H:i}} - {{Utilisateur:Supertoff/modèle}} donne :
    • 2024-04-08 01:00 -
  • {{#timel:Y-m-d H:i}} - {{Utilisateur:Supertoff/modèle|309}} donne :
    • 2024-04-08 01:00 -
  • {{#timel:Y-m-d H:i}} - {{Utilisateur:Supertoff/modèle|301|302|303|304|305}} donne :
    • 2024-04-08 01:00 - (5 filtres max : je pense que c'est suffisant)
  • {{#timel:Y-m-d H:i}} - {{Utilisateur:Supertoff/modèle|301|302|303|304|305|m=oui}} donne :
    • 2024-04-08 01:00 - (le lien vers meta ne fonctionne que sur le premier filtre mais on pourrait l'envisager sur tous : m1, m2, m3, m4 et m5)

• Texte : en parallèle, supprimer <!-- Écrivez dans la boîte ''Sujet/titre'' ci-dessus : [[Spécial:AbuseFilter/numéro du filtre]], puis remplissez les rubriques ci-dessous --> et '''Numéro du filtre déclenché''' :

J'aimerais aussi précharger dans le titre <!-- {{fait}} {{pas fait}} --> mais  Orlodrim il faudrait savoir comment OrlodrimBot (d · c · b) gère l'archivage et si ça ne va pas créer un bug.

Nota : il existe le modèle {{Modèle:Faux_positifs_filtre 2}} qui n'est pas utilisé et que je propose de supprimer. 'toff ^[discut.] 29 octobre 2022 à 14:01 (CEST)

Bonjour,

Il y a deux méthodes pour signaler un faux positif :

• Le bouton "signaler un faux positif" sur Wikipédia:AbuseFilter/Faux positifs. C'est plutôt réservé aux contributeurs expérimentés qui connaissent déjà la page. Dans ce cas, on n'a aucun moyen de préremplir le numéro du filtre. Cette méthode utilise {{Modèle:Faux positifs filtre}} en préchargement.
• Le lien "signaler un faux positif" en bas du cadre lors du déclenchement d'un filtre (généra via {{Avertissement filtre}}). C'est le plus courant. Si le filtre affiché possède un message personnalisé, ce message appelle en général le modèle {{Avertissement filtre}} avec un paramètre qui permet de préremplir le numéro du filtre lors du signalement. Cette méthode utilise {{Modèle:Faux positifs filtre 2}} en préchargement (la différence avec l'autre est qu'on ne demande pas le numéro du filtre, puisque celui-ci est prérempli).

Historiquement, il n'était possible d'afficher un message personnalisé que lorsque le filtre affichait un avertissement, pas lorsqu'il était bloquant. Cette limitation n'existe plus, mais pour que le lien "signaler un faux positif" préremplisse correctement le numéro du filtre, il reste encore à créer un message par filtre bloquant qui n'en a pas encore.

À ma connaissance, il n'est pas possible de générer un message "combiné" en cas de déclenchement simultané de plusieurs filtres, ce qui rend difficile de préremplir plusieurs numéros lorsque plusieurs filtres se déclenchent à la fois. Avoir un modèle en gérant plusieurs pourrait éventuellement permettre une correction a posteriori par ceux qui traitent les demandes, mais c'est tout. Je ne sais pas non plus si on peut afficher un message personnalisé pour les filtres globaux. Sans ça, difficile de préremplir le numéro de filtre. Demander aux contributeurs de remplir manuellement le numéro du filtre me semble peu réaliste (il faudrait qu'ils fouillent dans leur journal des filtrage, et encore, s'ils ne sont pas autoconfirmés, ils ne pourront sans doute même pas le voir le numéro).

Pour l'archivage, je viens d'ajuster le bot pour qu'il ignore les commentaires dans les titres.

Orlodrim (discuter) 29 octobre 2022 à 15:31 (CEST)

 Orlodrim : merci pour ton analyse. En effet, ma proposition porte sur la correction à posteriori par les AF. Je n'avais pas perçu l'utilité de {{Modèle:Faux_positifs_filtre 2}} car il est catégorisé dans Wikipédia:Rapports/Modèles inutilisés. On peut concevoir de le modifier légèrement pour qu'il utilise la même forme, même s'il ne gère qu'un seul filtre : ajout dans le titre des modèles {{fait}} {{pas fait}} en commentaire et d'un modèle autorisant plusieurs numéros. Dans tous les cas, les AF doivent apposer un modèle {{fait}} ou {{pas fait}} pour permettre l'archivage : l'ajout d'autres filtres dans la liste n'est qu'un plus pour le suivi dans les archives. 'toff ^[discut.] 29 octobre 2022 à 15:47 (CEST)

Les modifications sont ok pour moi. Si tu veux que le lien direct vers la section ajoutée dans le commentaire de diff reste fonctionnel malgré la présence du modèle, tu peux utiliser une astuce similaire à celle de {{a-dpp}} avec le span. Orlodrim (discuter) 30 octobre 2022 à 22:29 (CET)

Salut, toute ma confiance @Supertoff, go LD (d) 1 novembre 2022 à 22:13 (CET)

┌─────────────────────────────────────────────────┘
Bon alors en fait il y a trois méthodes pour rapporter les FP (ce que je n'avais pas perçu au départ) :

1. Filtre avec message personnalisé : utilise {{Avertissement filtre}}
2. Filtre avec message par défaut : utilise MediaWiki:Abusefilter-disallowed
3. Wikipédia:AbuseFilter/Faux positifs, bouton "Signaler un faux positif" : utilise Wikipédia:AbuseFilter/Faux positifs/En-tête

Les deux premiers utilisent {{Faux positifs filtre 2}} et le troisième {{Faux positifs filtre}}. J'ai déjà ajouté <!-- {{fait}} {{pas fait}} --> dans les 3 cas (si vous voulez vérifier que je n'ai pas fait de bêtises, mais à priori ça fonctionne bien) :

1. Message personnalisé
2. Défaut
3. Bouton

(Au passage, étant donné que je ne suis pas informaticien, pourquoi un coup en décimal, un autre en hexa ? pfff )

Pour ce qui est du reste de ma proposition, il faudra que je remette le nez dedans, d'autres choses son passées dans ma tête en une semaine et j'ai un peu perdu le fil. 'toff ^[discut.] 6 novembre 2022 à 10:36 (CET)

Filtre 93

Bonjour,

Je viens de faire une proposition dans le filtre 93. C'est surtout la partie Notes que je vous invite à lire et à commenter soit ici ("ok", "c'est nul", "surtout pas") ou là-bas si c'est plus confidentiel.

Merci. -- Habertix (discuter) 7 novembre 2022 à 23:50 (CET).

Répondu , bonne soirée/Journée Felix felines - ^{(ᴅɪsᴄᴜssɪᴏɴ)} 8 novembre 2022 à 20:56 (CET)

On m'a (gentiment) répondu "non". . -- Habertix (discuter) 10 novembre 2022 à 00:35 (CET).

Pour info

Je viens de voir passer ça. Je ne sais pas s'il y a plus à faire (signalement hors WP ?) 'toff ^[discut.] 8 novembre 2022 à 12:30 (CET)

Salut, àmha cela relève des OS (@Jules*), eux peuvent toujours relayer c.à.d être un liant avec du légal (WMF ou externe).

Il est possible de signaler l'IP à Pharos, tout comme il est possible de signaler l'IP à son opérateur (Free => abuseproxad.net). LD (d) 8 novembre 2022 à 13:47 (CET)

C'est masqué. — Jules* ^discuter 8 novembre 2022 à 13:50 (CET)

Vandalisme sur pddu

Bonjour,

Personnellement, les vandalismes de ce genre m’indiffèrent complètement. Mais peut-être qu'un éditeur de filtre en tirera quelque chose pour une amélioration quelque part.

Cordialement. -- Habertix (discuter) 15 novembre 2022 à 21:49 (CET).

Hello. Très à la marge, j'ai enrichi le filtre 139. — Jules* ^discuter 23 novembre 2022 à 13:52 (CET)

Tickets phabricator

Hello à tous, notamment @LD, @Supertoff et @Habertix.

AF est un outil puissant, mais qui manque de fonctionnalités et dont l'interface est franchement peu ergonomique (et quand on y passe du temps c'est vraiment pénible). J'ai l'impression que la WMF ne fait pas grand chose pour améliorer tout ça.

J'aimerais bien que l'on se coordonne, si possible avec d'autres wikis, pour demander à la WMF de mettre des développeurs pour améliorer l'outil. Qu'en pensez-vous ? De ce que j'ai compris, Daimona Eaytoy (hi!) a pas mal bossé pour améliorer le code de l'extension (ce qui est un préalable à de futures améliorations), mais il est tout seul, travaille en partie bénévolement, et les tickets Phabricator sont nombreux. Un seul dev, ça ne semble vraiment pas à la hauteur de l'importance de l'outil.

Je viens de soumettre plusieurs tickets, pour info :

• phab:T323698 pour demander une fonctionnalité d'auto-complétion (à mon sens il faudrait aussi un truc plus pratique que la liste déroulante, mais je ne sais pas quoi : si vous avez une idée, vous pouvez ouvrir un ticket) ;
• phab:T323695 qui est une suggestion pour améliorer la manière dont sont commentés les filtres.

Par ailleurs, j'attire votre attention sur phab:T294856, qui contient des améliorations à mon sens indispensables (fenêtre d'édition du code plus grande et redimensionnable, notamment) que j'avais demandées il y a un an, et sur phab:T269769, une demande de variable pour obtenir la durée depuis la dernière modification opérée sur une page.

N'hésitez pas à vous abonner aux tickets qui vous semblent intéressants (qu'ils soient mentionnés dans mon message ou non), ça aide à montrer qu'il y a une attente. — Jules* ^discuter 23 novembre 2022 à 13:23 (CET)

Bonjour, bonnes idées et initiatives.

Juste une remarque : il y a constamment des postes à pouvoir en technologie et les personnes déjà employées contribuent à Phabricator (pas nécessairement aux réponses aux souhaits, cela dit). J'ai l'impression qu'ils peinent parfois à recruter ; l'ouverture d'un poste dédié au développement de certaines extensions (dont AF) me semble pertinente mais, « stratégiquement », je dirais même qu'il faudrait souffler à leurs oreilles que le développement de partenariats avec entreprises (sur le modèle Dev Bootcamp ?) ou des universités aiderait également. LD (d) 23 novembre 2022 à 17:55 (CET)

Bonjour @LD, @Supertoff, @Od1n, @Habertix et @Thibaut120094, j'ai soumis une proposition très basique (pour maximiser les chances qu'elle soit acceptée) à la liste de souhaits de la communauté : meta:Community Wishlist Survey 2023/Anti-harassment/Make the AbuseFilter edit window resizable and larger by default. En bon français : agrandir la fenêtre d'édition des filtres, et la rendre redimensionnable.

Pour info, il y a aussi une demande d'avoir des filtres visibles seulement des OS : meta:Community Wishlist Survey 2023/Anti-harassment/Allow abuse filters to be hidden to only oversighters. Ping @Bédévore, @Kropotkine 113, @Lomita, @Arcyon37 et @JohnNewton8.

Est-ce que vous voyez d'autres demandes à faire concernant les filtres anti-abus ? — Jules* ^discuter 29 janvier 2023 à 17:20 (CET)

Miaourci Jules* pour les filtres "réservés OS", effectivement, ce serait pas dommage vu ce qu'on y croise de temps en temps. Ronron, Bédévore ^[plaît-il?] 29 janvier 2023 à 17:22 (CET)

Vu de chez moi, ce lien n'amène à rien ? Et du coup, j'ai pas compris le but : les OS ne sont pas automatiquement AF sauf sur demande (puisqu'ils sont Admins). Je suppose donc que le but de cette demande est que certains filtres ne soient visibles que des OS ? Vu le peu d'OS sur WP.fr qui sont aussi actifs comme AF (à part Jules*, qui est OS et modifie des filtres régulièrement ?) je m'interroge de l'intérêt d'un tel truc ? J'ajoute que si c'est bien ça, je m'interroge aussi sur le fait que ça ne soit pas soumis à la communauté vu que l'admission au sein du corps des AF (automatique des Admins sur demande et après un consultation pour les autres) est une décision de la communauté justement (sauf erreur évidemment) : pour l'instant, la communauté a décidé que tous les filtres sont visibles par les AF, quels qu'ils soient, admins ou non. De plus, je ne vois aucunement l'intérêt d'une telle limitation (mais je suis prêt à écouter et à en comprendre l'intérêt si c'est démontré) et je suis contre sa mise en place sans concertation de la communauté : ça fait très "petits arrangement entre amis" (déjà que l'annonce ici est confidentielle)... Mais je fais peut-être fausse route n'ayant pas eu connaissance de la question. 'toff ^[discut.] 29 janvier 2023 à 18:13 (CET)

C'est ici. Kropotkine 113 (discuter) 29 janvier 2023 à 18:18 (CET)

Conflit d’édition — J'ai corrigé le lien. Il y a aussi Bédévore qui sait modifier les filtres. Cinq OS sur les six ont accès aux filtres à l'heure actuelle et pourraient donc contrôler le contenu d'un filtre réservé aux OS.

La demande sur la liste de souhaits de la communauté est une demande de fonctionnalité technique ; ensuite, chaque wiki peut voir s'il utilise la fonctionnalité. Chez nous, elle serait utile pour une petite partie du contenu actuel des filtres 365 et 148, à savoir les identités réelles de contributeurs, qui seraient le cas échéant déplacées dans un filtre limité aux OS. L'utilité est avérée ; la phrase « petits arrangements entre amis » est désagréable. — Jules* ^discuter 29 janvier 2023 à 18:27 (CET)

On (OS) a reçu plusieurs fois des emails d'AF nous demandant de masquer certaines entrées du journal des filtrages en raison de leur caractère illégal (menaces de mort et autres joyeusetés) et plusieurs fois, j'y ai procédé. On a déjà des filtres meta et locaux relatifs au doxing, question qui de toute façon relève des OS. Il n'y a pas d'arrangement entre amis, il n'y a que la protection de la vie privée des wikipédiens. Bédévore ^[plaît-il?] 29 janvier 2023 à 18:36 (CET)

Désolé si vous n'aimez pas la phrase mais toutes ces fonctionnalités techniques, ou pas, n'ont pas à être mises en place sans l'avis de la communauté. C'est peut-être utile, mais ça n'a pas à être mis en place "discrètement" (ça encore, c'est un mot qui ne va pas vous plaire) sur un coin de table. Perso, ce sont des filtres que je n'aurai pas à suivre (parmi tant d'autres) donc ça ne fait pas de différence, mais je n'aime absolument pas ce sentiment de mise en place d'outils sans que ce soit concerté et visible par la communauté. Après, ma vision communautaire de l'encyclopédie est peut-être trop "bisounours"...

Autre chose : le masquage d'entrées de journal des filtrages par les OS (et là je dis peut-être une bêtise) est déjà non visible par les "non-OS" et ça doit représenter moins de 0,01 % des filtrages alors l'intérêt me semble limité et je ne vois toujours pas ce qui pourrait être efficacement filtré? Un truc genre "Jules*" & "Jules Dupont" je présume ? 'toff ^[discut.] 29 janvier 2023 à 19:10 (CET)

En résumé : je ne suis pas contre la mise en place, mais contre la mise en place sans concertation. Je rappelle nous sommes au service de WP, pas l'inverse. 'toff ^[discut.] 29 janvier 2023 à 19:10 (CET)

PS : vu la rapidité d'action de Phabricator sur les filtres, c'est peut-être une discussion inutile de toutes façons. 'toff ^[discut.] 29 janvier 2023 à 19:10 (CET)

Ce n'est pas mis en place sans l'avis de la communauté, sans concertation, ni sur un coin de table, @Supertoff, c'est même l'inverse : la liste des souhaits de la communauté, comme chaque année depuis huit ans, fait l'objet d'un vote de la communauté, avec une bannière sur tous les wikis pour inviter chacun à y participer, des rappels au Bistro, etc. Là, c'est la phase des propositions ; la phase du vote vient après.

Cdlt, — Jules* ^discuter 29 janvier 2023 à 19:21 (CET)

On verra. Et sans vouloir personnaliser le débat : ce qui est marrant c'est que tu es tellement impliqué dans WP et que tu connais tellement d'arcanes (ce n'est pas un reproche au contraire, il faut des gens impliqués comme toi) que j'ai l'impression (ce n'est peut-être qu'une impression, je ne veux pas encore te froisser) que tu ne vois pas que pour 99,9 % des contributeurs c'est du chinois et que c'est inconnu. Je n'avais jamais vu meta:Community Wishlist Survey 2023 avant ton lien. Et je suis sûr que pour l'essentiel des contributeurs réguliers, y compris les admins, Meta est un lieu inconnu ou quasiment (et en plus il faut généralement comprendre l'anglais il me semble). C'est peut-être un tort ou c'est peut-être un manque de communication interne, je ne sais pas. Il y a matière à débat sur le sujet, mais ça n'a rien à voir avec les filtres certes. Sur ce, A+. 'toff ^[discut.] 29 janvier 2023 à 19:37 (CET)

[4]. Cette année, 17 janvier + 24 janvier, pour la seule phase de proposition. Et il y a en ce moment-même une bannière qui s'affiche sur notre wiki. Effectivement meta est globalement un lieu très peu connu de nos pairs, mais cette consultation annuelle est tout de même largement annoncée. Une bonne partie des textes, pour la phase de vote, sont traduits en français. Bonne soirée, — Jules* ^discuter 29 janvier 2023 à 19:57 (CET)

Pour info, j'ai réussi à produire un code rendant l'éditeur redimensionnable :

Éditeur de filtre redimensionnable

if ( mw.config.get( 'wgCanonicalSpecialPageName' ) === 'AbuseFilter' ) {
    $( function ( $ ) {
        var elm = document.getElementById( 'wpAceFilterEditor' );
        if ( !elm ) {
            return;
        }

        if ( typeof ace === 'undefined' ) {
            return; // simple sécurité
        }
        if ( typeof ResizeObserver === 'undefined' ) {
            return; // ResizeObserver n'est pas implémenté dans IE 11
        }

        elm.style.resize = 'both';

        var editor = ace.edit( elm );

        // pour que la mise à jour de la taille de l'éditeur (notamment les scrollbars) se fasse aussi
        // quand on le redimensionne, et pas seulement quand la fenêtre du navigateur est redimensionnée
        new ResizeObserver( function () {
            editor.resize();
        } ).observe( elm );
    } );
}

 

od†n ↗^blah 31 janvier 2023 à 16:22 (CET)

Super, @Od1n, merci ! C'est utilisable dans notre common.js ? — Jules* ^discuter 31 janvier 2023 à 21:12 (CET)

C'est bien entendu utilisable, néanmoins j'ai hésité à publier ce code car je n'ai pas envie qu'il se retrouve un peu partout, car s'il y a lieu de le modifier, ou le supprimer car plus nécessaire, il faudra aller le chercher et le modifier partout sur le wiki. J'avais aussi pensé à le mettre dans une sous-page de mon espace Utilisateur, importable avec importScript(), mais là encore, je préfère ne pas me retrouver avec une sous-page de plus sur les bras.

L'idéal serait que cela soit nativement implémenté dans l'extension AbuseFilter, ce qui me paraît tout à fait concevable car le code n'est guère compliqué.

od†n ↗^blah 1 février 2023 à 10:49 (CET)

Je comprends, @Od1n. Est-ce que je peux mentionner ton code sur le ticket phabricator, ou souhaites-tu le faire toi-même ? — Jules* ^discuter 1 février 2023 à 10:52 (CET)

Pas de problème, je te laisse faire. od†n ↗^blah 1 février 2023 à 11:30 (CET)

J'ajoute une autre proposition, qui ne fait que reprendre des tickets phabricator existants : meta:Community Wishlist Survey 2023/Anti-harassment/Allow checkusers to use user-agent variables in Abusefilters. L'idée est d'avoir des filtres réservés aux CU, avec possibilité de filtrer des user agents particuliers. Ping @Hyméros et @LD. — Jules* ^discuter 2 février 2023 à 21:08 (CET)

@Jules*, dans la même idée : meta:Community Wishlist Survey 2023/Anti-harassment#Allow checkusers to use XFF variable in Abusefilters. LD (d) 2 février 2023 à 22:24 (CET)

Masquage lourd ?

Bonjour,

Il me semble que les masqueurs peuvent techniquement masquer les contributions filtrées.

• Est-ce qu'il faudrait pas masquer celles de 2a01:cb14:11b6:4800:ec43:a5b4:15ce:b962 ?
• Est-ce qu'un masqueur peut me confirmer que le masquage léger admin n'est pas techniquement possible ?

Merci. -- Habertix (discuter) 25 novembre 2022 à 22:48 (CET)

@Habertix :

• Si, fait ;
• Je te le confirme (et c'est dommage, àmha).

— Jules* ^discuter 26 novembre 2022 à 00:26 (CET)

Merci. -- Habertix (discuter) 26 novembre 2022 à 00:27 (CET)

Et bonjour ! (J'en perds ma politesse ; ça doit être l'appel de l'oreiller.) — Jules* ^discuter 26 novembre 2022 à 00:46 (CET)

Transfert d'éléments du 312 vers le 133

Hello,

Le filtre 312, dédié à Papa Franck (PF), contenait diverses grossièretés qui ne lui étaient pas spécifiques, conduisant à des déclenchements pour des vandalismes génériques sans aucun rapport avec PF. J'ai déplacé un certain nombre d'entre eux vers le filtre 133, que j'ai par ailleurs renommé de « Ajouts intempestifs récurrents » (titre un peu vague) en « Grossièretés et autres ajouts intempestifs », puisque la quasi-totalité des éléments filtrés sont des grossièretés, injures vulgaires, etc.

Il reste quelques vieux filtrages spécifiques dans le 133 (j'en ai encore retiré trois, obsolètes), que j'aimerais bien virer.

Bon dimanche, — Jules* ^discuter 27 novembre 2022 à 13:54 (CET)

Le filtre 133 fait un tabac. Les regex déplacées depuis le 312 n'ont pas été modifiées : le nombre croissant de déclenchements est une conséquence du fait que le 133 s'applique très largement, à l'inverse du 312, dont le périmètre d'application était plus restreint (ligne 9). — Jules* ^discuter 29 novembre 2022 à 15:29 (CET)

Salut @Jules* ;

Merci pour tout. Je suis plus réservé et mitigé sur cette modification (pas les précédentes) : les lignes 41-43 du 133 sont différentes de celles du 312.

Par exemple, les lignes 17-23 du filtre 312 pourraient être impactées par ce changement, celles-ci restent difficilement comparables avec l'effet entonnoir mentionné dans ton second message : c'est un autre entonnoir. Cela dit, je me pose la question de la juste place de ces lignes, tout comme celles l. 26-33 qui pourraient faire l'objet d'un filtre dédié. Dans le doute, j'aurais plutôt conservé certaines expressions, mais certaines autres me semblent bienvenues (et d'autres pourraient àmha encore être retirées).

Tu penses à quels éléments obsolètes du filtre 133 ?

Hors-propos : je rêverais que l'on puisse « importer » un filtre dans un autre (idée de phabricator !), la cascade permettrait de créer un filtre-dictionnaire et ainsi diminuer ces doublons.

Bien à toi, LD (d) 30 novembre 2022 à 00:17 (CET)

Merci pour ton retour @LD. Oui pour les lignes 41-43, que j'ai d'ailleurs retouchées pour éviter tout FP, puisque j'avais conscience d'élargir la détection.

Bien vu pour les lignes 17-23 du 312 ; mais sauf la ligne 22 qui est spécifique (et sans doute obsolète), le reste participait vraisemblablement, avec l'ancien match, à détecter des trucs sans aucun rapport avec PF. Àmha on pourrait virer ces lignes 17-23.

Pour les lignes 26-33, un filtre dédié mais générique en les remaniant pourrait être pertinent, bonne idée ; à proposer sur le BA avant.

Dans le filtre 133, il reste des éléments hors grossièretés (lignes 30-35), et je viens d'ailleurs d'en ajouter un (qui n'est pas obsolète, donc). En fait, il manque un filtre à mon sens : le filtre 29 est dédié aux vandalismes spécifiques sur des pages spécifiques ou par des IP spécifiques, donc théoriquement, l'élément que j'ai ajouté aujourd'hui au 133 n'y a pas sa place ; et je n'ai pas trouvé de filtre plus approprié que le 133.

Hors-propos : plus qu'un import de filtre, ce serait un import de regex, une bibliothèque de regex, non ? Ça peut être une bonne idée, mais les cas de doublon de regex ne sont pas si courants, et j'ai peur qu'une telle fonctionnalité fasse perdre en clarté du code ce que l'on gagnerait en économie de caractères . — Jules* ^discuter 30 novembre 2022 à 00:32 (CET)

Non merci à toi . Je regarderais à tête reposée mais avec ta réponse je me fais ces remarques :

• l.17-23 du 312 seraient obsolètes si on transferait vers le 148 qui se veut propice et large : je pense que ça irait dans la bonne voie ;
• H.S : la plupart des fonctions agissent souvent comme des bibliothèques de regex (ip_in_range, rmspecials, etc.). En dehors de AF "brut", des extensions viennent fournir des bibliothèques ; une extension BadWords, configurable en json ou autre, verra peut-être le jour. J'ai tendance à croire qu'on tend vers ce type de fonctionnement (Extensions AntiSpoof, StopForumSpam, CentralAuth, etc. viennent enrichir AbuseFilter). Alternativement à la « cascade » de biblothèque, donc sans se passer de la répétition des doublons, on pourrait « encadrer » les doublons récurrents. Par exemple, en créant un filtre dédié (non activé) qui listerait des variables (mots-clés récurrents) ou formats réutilisables (par ex. pour les pseudos). Cela permettrait probablement de « lisser » l'utilisation des variables, voire de tendre vers des variables concaténées et modifier les filtres en série comme si on venait appliquer un « patch » en copiant-collant la dernière bibliothèque. Par exemple toujours c/c (si ce n'est en mode commentaire) ou se référer à la dernière version de match_blabla du « filtre bibliothèque », en particulier si on passe de match_blabla = "a|b"; à match_blabla = "a|b|c|d"; ou qu'un nouveau FP est découvert ; plutôt que d'avoir une seule variable englobante dans laquelle on se perd au bout d'un an.

LD (d) 30 novembre 2022 à 01:08 (CET)