On 12/05/2012 05:54 PM, Chris Steipp wrote:
> On Wed, Dec 5, 2012 at 1:11 PM, Matthew Flaschen
> <[email protected]> wrote:
>> It makes sense for AbuseFilter and Wikidata to work in conjunction. But
>> it seems Wikidata should provide a hook that AbuseFilter calls.
>
> I think we agree on this point, although I'll clarify and say I think
> AbuseFilter should be calling wfRunHooks, and Wikibase should provide
> the functions.
No, we disagree on this.
Wikibase should call wfRunHooks. This is analogous to the way it is now
for regular wikitext.
For example, AbuseFilter has:
$wgHooks['EditFilterMerged'][] = 'AbuseFilterHooks::onEditFilterMerged';
Then, core MediaWiki calls:
if ( !wfRunHooks( 'EditFilterMerged', array( $this, $this->textbox1,
&$this->hookError, $this->summary ) ) ) {
The same general idea should apply for Wikibase. The only difference is
that the core functionality of data editing is in Wikibase.
Thus, Wikibase should call wfRunHooks for this.
>> What if someone wants to make spam filter that works differently than
>> AbuseFilter? For example, it uses its own programmatic rules rather
>> than ones that can be expressed in the Special:AbuseFilter language.
>
> You are correct, AbuseFilter doesn't currently have hooks to let an
> extension run its own logic, but that wouldn't be too difficult to
> implement.
I don't think it necessarily needs one. A spam filter with a different
approach (which may not have a rule UI at all) can register its own
hooks, just as AbuseFilter does.
> Although I would be interested to know what kind of rules you have in
> mind, since it's certainly possible that we would want to implement it
> as a AbuseFilter operation.
I don't have an immediate practical suggestion. But I do know that
modern spam filters use a variety of approaches, including Bayesian
filtering.
Matt Flaschen
_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
