On 12/05/2012 05:54 PM, Chris Steipp wrote:
On Wed, Dec 5, 2012 at 1:11 PM, Matthew Flaschen mflaschen@wikimedia.org 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