Wikipédia:Bulletin du filtrage/2010/avril

Filtre n°36

Bonsoir,

Est ce qu'un admin pourrait créé Mediawiki:abusefilter-warning-36 avec :

{{Avertissement filtre |niveau = modéré |texte = {{:MediaWiki:Abusefilter-warning-R3R}} |filtre = 36 }}

et Mediawiki:abusefilter-warning-R3R avec :

---

Cet article a subi récemment une [[Wikipédia:Guerre d'édition|guerre d’édition]] au cours de laquelle plusieurs contributeurs ont mutuellement annulé leurs modifications respectives. Ce comportement non collaboratif est proscrit par la '''[[Wikipédia:Règle des trois révocations|règle dite des trois révocations]]'''. En cas de désaccord, un consensus sur la [[{{TALKPAGENAME}}|page de discussion]] doit être obtenu avant toute modification.

Si c'est le cas et que '''vous êtes sûr{{GENDER:||e|(e)}} de ce que vous faîtes''', enlevez le bandeau et cliquez à nouveau sur publier.

Votre modification sera toutefois balisée pour permettre son suivi.

---

ainsi que : Mediawiki:Tag-R3R avec :

[[Spécial:Balises|Balise]] : <abbr title="Règle des trois révocations">R3R</abbr>

et Mediawiki:Tag-R3R-description avec :

Cette modification intervient après l'apposition d'un bandeau {{M|R3R}}.<br />
Détectée par le [[Spécial:Filtre antiabus/36|filtre n° 36]]

Cordialement Micthev ^{(discuter • contrib')} 2 avril 2010 à 21:29 (CEST)

⇨ Dr Brains ^{∞ Doléances ∞} 2 avril 2010 à 23:16 (CEST)

Merci Micthev ^{(discuter • contrib')} 3 avril 2010 à 00:23 (CEST)

Filtres spécial Bot ?

A-t-on déjà envisagé de baliser les modifications faites par des bots, et plus spécifiquement le plus méchant d'entre-eux : Salebot (d · c · b) ?

Exemple de modif balisables :

• blanchiment :
  • Pour Salebot : recréation d'article récemment supprimé;
  • Pour un autre bot : bot fonctionnent mal (a priori)
• révocations successives sur une même page dans un laps de temps court : guerre d'édition newbie/salebot ou attaque vandale coordonnée;
• ajout de modèle avec une erreur (à déterminer) : bot fonctionnant mal
• et peut-être d'autres...

Il ne serait pas question de prévenir (ça pourrait perturber le fonctionnement du bot), mais de baliser la modif (ou pas).

Votre avis ?

⇨ Dr Brains ^{∞ Doléances ∞} 3 avril 2010 à 17:25 (CEST)

Un truc qui s'ajouterait au botflag déjà visible dans les RC ? Pas convaincu de l'utilité, ça fait quand-même double emploi.

J'ajoute que les "bots fonctionnant mal" couvrent un ensemble très varié d'erreurs possibles, et il me paraît difficile de les lister toutes...

Les guerres d'édition newb/Salebot sont difficiles à repérer, l'abusefilter ne piochant pas dans l'historique. Un throttle basé sur l'annonce de révocation serait possible, mais là encore ça se remarque dans les RC.

Alphos ^{[me pourrir la vie]} 3 avril 2010 à 23:50 (CEST)

Oui, il ne s'agirait pas de baliser/filtrer toutes les actions des bots (repérables par le b dans les RC), mais seulement certaines d'entre-elles.

Par exemple les blanchiments de salebot sont visibles dans les RC (comme toutes ses révocations), mais sont noyées dans les contributions des autres utilisateurs ou des autres bots. Coller un filtre à cette action permettrait de les isoler pour mieux les suivre, et voir le cas échéant si certaines pages sont plus touchées que d'autres et nécessitent une (semi-)protection à la création.

Pour l'aspect guerre d'édition, je croyais qu'Abusefilter autorisait des seuils ( « Le seuil peut être défini par exemple par type de contributeurs, par page ou pour le site en entier. On peut ainsi demander à AbuseFilter une action A si le filtre F est déclenché X fois pendant la durée T par le compte utilisateur C sur la page P. ».

L'idée, ce serait par exemple salebot qui révoque plusieurs (3, 4...) fois la même page dans un court laps de temps (5-10 min) déclencherait une balise, indiquant ainsi que cette page a visiblement besoin d'être (semi-)protégée.

⇨ Dr Brains ^{∞ Doléances ∞} 4 avril 2010 à 01:07 (CEST)

Cassage de modèles

Un filtre pour détecter les cassages ou les réparations d'inclusions de modèles pourrait s'avérer utile.

La méthode la plus simple, c'est de comparer la différence entre les nombres de {{ et de }} avant à la même différence après.

Il me semble cependant qu'éluder les "annulations/révocations/rv/revert" etc serait une bonne chose, pour éviter de repérer 15 fois la même destruction sous edit war, et pour éviter aussi de repérer la réparation via annulation des modifications du maladroit : inutile de tagger 15 fois la même chose, et inutile d'avoir 50% de faux-positifs (strictement, si ça détectait les corrections autant que les annulations, on tomberait sur du moitié-moitié Il n'y aura a priori aucun autre faux-positif, sauf les rares réparations de cassages qui ne comporteraient pas de sommaire d'annulation).

Proposition de règle :

!(lcase(summary) rlike "\b(annul|révoc|revert|rv|revoke|liverc)") & (count("{{", removed_lines) - count("}}",removed_lines) != count("{{", added_lines) - count("}}",added_lines))

J'ai aussi pensé aux modifications de modèles avec paramètres, qui ne devraient pas être reconnues par le filtre si elles sont légitimes : "{{{" contient deux fois "{{" selon AbuseFilter, et de même avec "}}}" pour "}}".... Il devrait donc être parfaitement possible d'étendre ce filtre à tous les espaces de noms.

C'est très vaguement basé sur la théorie des groupes, à un niveau assez bas mais que je trouve quand-même assez retors et assez efficace pour l'utiliser

Alphos ^{[me pourrir la vie]} 7 avril 2010 à 02:32 (CEST)

Dans le dernier cas pourquoi ne pas simplement compter le nombre de { et non de {{ ? Micthev ^{(discuter • contrib')} 8 avril 2010 à 01:44 (CEST)

Parce que {<espace>{ et {{ seraient comptées de la même façon, mais que {<espace>{ casse le modèle qui le suit.

On peut en revanche l'étendre aux tables en employant des regex contenant (\{\{|\{\|) et (\}\}|\|\}).

Cependant il vaudrait mieux faire deux groupes "count" simples (sans regexp) séparés, vu qu'il serait possible contre cette regex de "transformer une table en modèle et vice-versa" (quelqu'un remplaçant {{ par {| casserait la syntaxe, mais ne serait pas pour autant décelé).

Alphos ^{[me pourrir la vie]} 9 avril 2010 à 08:22 (CEST)

Fait : Spécial:Filtre antiabus/37. Alphos ^{[me pourrir la vie]} 27 avril 2010 à 11:35 (CEST)

Cassage de titres de section

Ouais, je sais, deux messages d'un coup...

Il arrive que des petits étourdis ajoutent quelque chose à la fin de la ligne contenant le titre d'une section :

• ceci :

  "=== Test ==="

• devenant ceci :

  "=== Test === truc"

Ceci brise le titre d'une section, qui n'est plus considéré que comme du texte normal, jugez-en par vous-mêmes :

Test

===Test=== truc

Cela peut se produire lorsque le premier paragraphe d'une section est supprimé, ou lorsqu'un petit malin veut faire des tests, etc...

J'ai testouillé une règle qui semble donner de bons résultats :

(?m-s:^=+\h*[^=]+\h*=+(?!=)\h*\S.*$)

Gribeco n'a pas fait de remarque dessus quand je lui en ai parlé sur IRC, mais je vous laisse décider

Alphos ^{[me pourrir la vie]} 7 avril 2010 à 02:49 (CEST)

(?m:^=+\h*[^=]+\h*=+(?!=)\h*\S) ?

Pourrait-on en profiter pour vérifier que les « = » sont équilibrés ? Quelque chose du genre :

(?m:^(?P<level>=+)\h*[^=]+\h*(?P=level)\h*\S) (ça ne passe pas dans checkpcre, j'ai peut-être fait une erreur de syntaxe) ? — Arkanosis ^✉ 7 avril 2010 à 11:14 (CEST)

Si tu veux simultanément vérifier qu'ils sont équilibrés, inutile d'employer un sous-masque nommé (on a qu'une seule référence, je pense qu'on ne s'y perdra pas) : (?m-s:^(=+)\h*[^=]+\h*\1(?!=)\h*\S.*$).

Mais un déséquilibre peut être souhaité, justement.

Pour ce qui est des sous-masques nommés, vu que les utilisations sont exceptionnellement rares (et que AbuseFilter nous fera la gueule si un jour on fait une regex assez suffisamment pour avoir à s'en servir), vu aussi que j'ai souhaité que <span> soit affiché tel quel plutôt qu'en tant que balise HTML, je n'en ai tout simplement pas tenu compte : dans la regex, les < qui ne sont pas précédés par "(?" ou suivis par "!" (sauf si suivi par --, pour les commentaires html) ou "=" sont transformés directement en "<", et la cible elle-même est transformée en remplaçant tous les < et > (par exemple ceux des balises) par leurs équivalents html, pour permettre la coloration des morceaux reconnus par la regex dans la cible sans interférence avec les balises html préexistantes de la cible

Faire une exception similaire à celle des assertions pour les noms de sous-masques serait franchement superflu, étant donné qu'il faudrait faire une assertion contenant plusieurs longueurs de noms de masques, et que l'avantage en est franchement limité.

Alphos ^{[me pourrir la vie]} 7 avril 2010 à 17:05 (CEST)

D'ac, merci pour l'éclaircissement . Par contre pour les cas où on souhaiterait un déséquilibre, je ne vois pas... tu as un exemple en tête ? — Arkanosis ^✉ 7 avril 2010 à 17:50 (CEST)

Section "1+x" ; sous-section "=5" ; contenu de la sous-section "x=4". C'est trivial, mais c'est possible Je pense aussi aux bacs à sable, à l'aide, aux contenus de tags pre où on a placé un signe "=" en début de ligne, etc...

Alphos ^{[me pourrir la vie]} 7 avril 2010 à 18:03 (CEST)

Ben oui, mais dans ces cas là, le [^=]+ en milieu de regexp est au moins aussi problématique (section « f(x) = ax + b »), non ?

Je vais tout de même répondre à la question du départ : en ce qui me concerne, ta règle me va, le reste est du détail (juste virer le -s et le .*$ vu qu'on n'utilise pas ce qui est reconnu) — Arkanosis ^✉ 7 avril 2010 à 18:14 (CEST)

Faut surtout pas virer le -s (suppression de l'option s, par défaut insérée dans toutes les regex AbuseFilter de même que l'option u), on ne veut absolument pas de reconnaissance sur plusieurs lignes. C'est justement le principe.

J'ai retapé la regex pour prendre en compte les ==f(x) = ax+b == :

(?m-s:^=+(?!=)[^=]+(?<!=)=+(?!=)\h*(\S.*)(?<!=)$)

Pour une raison que j'ignore cependant, elle marche parfaitement dans un shell sur php 5.2.4 et php 5.2.10 mais déconne parfaitement dans checkpcre... Pas trouvé d'où le bug pouvait bien venir, bizarre

Elle reconnaît les lignes commençant par des =, contenant à distance d'eux des = même si en nombre différent des = initiaux et même si en plusieurs groupes, mais ne finissant pas par des = :

• ==test ne fait pas tilter
• ==test == ne fait pas tilter
• ==test = truc == ne fait pas tilter
• ==test = truc fait tilter
• ==f(x) = ax + b == ne fait pas tilter
• ==f(x) = ax + b == truc fait tilter

Bref, tout ça sans se servir des sous-masques nommés

Alphos ^{[me pourrir la vie]} 8 avril 2010 à 00:45 (CEST)

Semi protection ?

Face aux nombres de faux négatifs abusifs signalés par les IP je suggère une semi protection de la page de signalement et pour le coup un changement pour le bandeau d'avertissement (je ne vois pas trop quoi par ailleurs), si seulement cette extension était installée… Micthev ^(discuter) 25 avril 2010 à 03:02 (CEST)

Comme la plupart des filtres s'adresse aux IP et aux nouveaux, autant supprimer la page des faux-positifs. Les demandes sont loin d'être ingérables (voir WP:DRP pour des exemples de demandes plus ou moins abusives en grand nombre), et s'il y a un gros foutage de gueule de la part d'un vandale, rien ne nous empêche de lui coller 2h de blocage. Moyg hop 25 avril 2010 à 11:50 (CEST)

Certes Micthev ^(discuter) 25 avril 2010 à 11:52 (CEST)

Contre : on a un outil dangereux entre les mains, risquant potentiellement de nous faire perdre de nouveaux contributeurs agacés par les messages d'avertissement, il faut se montrer au maximum à l'écoute des problèmes (quitte à ce que ça nous fatigue un peu).

Ce ne sont pas les habitués que l'on risque de perdre à cause d'AbuseFilter (au pire on se fera taper dessus — c'est un moindre mal ). — Arkanosis ^✉ 25 avril 2010 à 15:53 (CEST)

Absolument Contre. Plusieurs signalements corrects sont effectués par des IP, on ne va pas s'en passer. Alphos ^{[me pourrir la vie]} 25 avril 2010 à 17:54 (CEST)

Ah, au passage, on peut faire la même chose via AbuseFilter, d'un point de vue technique. Pas besoin de 50 extensions... Alphos ^{[me pourrir la vie]} 26 avril 2010 à 01:18 (CEST)

MediaWiki:Abusefilter-warning-36 (d · h · j · ↵)

Correction orthographique: s/faîtes/faites , voir discussion. Apokrif (d) 28 avril 2010 à 00:02 (CEST)

MediaWiki:Abusefilter-warning-R3R en fait — déplacé sur le BF Micthev ^(discuter) 28 avril 2010 à 00:06 (CEST)

Mise en production du Filtre n°5

Salut.

Le filtre Filtre n°5 est un des filtres les plus déclenchés et à mon avis un des plus utiles. Malheureusement il souffre encore d'un grand nombre de faux positifs (environ 10 sur les 50 que j'ai testés aujourd'hui, cf la page de report de faux positifs). Je pense qu'il faut essayer de faire un effort sur ce filtre, quitte à en limiter la portée, par exemple en excluant les gros ajouts, qui contiennent trop probablement un faux positif et qui ont toutes es chances d'être détectés par un autre filtre et/ou Salebot s'il s'agit d'un vandalisme.

Il faudrait ensuite passer en avertissement, sans balisage ni interdiction, afin d'avoir plus de retour de faux positifs.

Kropotkine_113 21 avril 2010 à 12:52 (CEST)

Pour mais il faudrais voir à corriger les faux-positifs en attente dont le pd dans l'url que je vois pas personnellement comment traiter Micthev ^(discuter) 21 avril 2010 à 13:48 (CEST)