| Yamaha5 | |
| Aug 29 2014, 5:32 AM |
| F14427: abuseFilter.png | |
| Nov 22 2014, 3:35 AM |
At Abuse log we can not recognize which text or word case abuse filter active.It should highlight the match cases at Abuse Log
This was also proposed on Portuguese Wikipedia:
https://pt.wikipedia.org/wiki/Wikipedia:Esplanada/propostas/Proponho_melhorar_a_extens%C3%A3o_AbuseFilter
As I was saying in the duplicate, this task won't be easy at all. First, we need to determine what "the content that matched a filter" is. For a simple filter consisting of e.g. only an "rlike" condition, we may highlight the regex match. But in any other case it's not so clear. Also, where should we highlight it? And no, not on the variable content: what if there are multiple regex using it? We would end up with tons of cryptic highlighting. Even after understanding what to do and where to do it, this would require quite a big change to the parser.
Perhaps this could be broken out to a separate function/screen? I'm usually able to determine the string hits using testers like the one at https://regex101.com/
Indeed, I usually test regexps there to determine what triggered the filter. However, many filters don't even use regexps. I'm also reluctant in adding another page: we currently have under review T120740 which would add a new page, and T193064 which will add two. We're also discussing about T198005, and an option is to add another page. I don't think we want too many new pages added (at least, not without a major restyling), do we?
Some kind of mechanism for allowing variables in filter messages and/or allowing messages to be tied to wikitext offsets (where the filter author would have to specify what those parameters/offsets are) would probably be ideal, but it seems like a lot of effort to implement that,
Some kind of mechanism for allowing variables in filter messages
Something like T174554?
Was shown this task when I presented the same problem. It would be very nice if the matched case could be highlighted in Edit Filters. In SqWiki we have many cases when new users activate the bad words filter accidently because they create a full article on Content Translation Tool and one of the names mentioned there could be listed as a bad word in our language. After having written the full article they try to publish their changes only to find out they can't because of this filter and they ask for help. It takes quite some effort to find out what specific word caused the filter to activate and to solve the problem. Having this feature would tremendously speed up the process of finding false positives.
