On 06.12.2012 01:55, Chris Steipp wrote:
The same general idea should apply for Wikibase. The only difference is
that the core functionality of data editing is in Wikibase.
Correct, and I would say that Wikibase should be calling the same
hooks that core does, so that AbuseFilter can be
On 05.12.2012 22:06, Matthew Flaschen wrote:
More specifically, what if Wikidata exposed a JSON object representing
an external version of each change (essentially a data API).
This already exists, that's more or less how changes get pushed to client wikis.
It could allow hooks to register
On 12/06/2012 05:22 AM, Daniel Kinzler wrote:
On 05.12.2012 22:06, Matthew Flaschen wrote:
More specifically, what if Wikidata exposed a JSON object representing
an external version of each change (essentially a data API).
This already exists, that's more or less how changes get pushed to
On 04.12.2012 18:20, Matthew Flaschen wrote:
On 12/04/2012 04:52 AM, Daniel Kinzler wrote:
4) just add another hook, similar to EditFilterMergedContent, but more
generic,
and call it in EditEntity (and perhaps also in EditPage!). If we want a spam
filter extension to work with non-text
On Wed, Dec 5, 2012 at 3:34 AM, Daniel Kinzler dan...@brightbyte.de wrote:
You really want the spam filter extensions to have internal knowledge of
Wikibase? That seems like a nasty cross-dependency, and goes directly against
the idea of modularization and separation of concerns...
We are
On 12/05/2012 06:34 AM, Daniel Kinzler wrote:
I think that makes sense. The spam filters will work best if they are
aware of how wikidata works, and have access to the full JSON
information of the change.
You really want the spam filter extensions to have internal knowledge of
Wikibase?
On 12/05/2012 12:28 PM, Chris Steipp wrote:
On Wed, Dec 5, 2012 at 3:34 AM, Daniel Kinzler dan...@brightbyte.de wrote:
You really want the spam filter extensions to have internal knowledge of
Wikibase? That seems like a nasty cross-dependency, and goes directly against
the idea of
On Wed, Dec 5, 2012 at 1:11 PM, Matthew Flaschen
mflasc...@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
On 12/05/2012 05:54 PM, Chris Steipp wrote:
On Wed, Dec 5, 2012 at 1:11 PM, Matthew Flaschen
mflasc...@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
On Wed, Dec 5, 2012 at 3:53 PM, Matthew Flaschen
mflasc...@wikimedia.org wrote:
No, we disagree on this.
I was afraid that might be the case, so I'm glad we clarified.
The same general idea should apply for Wikibase. The only difference is
that the core functionality of data editing is in
On 12/05/2012 07:55 PM, Chris Steipp wrote:
If Wikibase wants to define another hook, and can
present the data in a generic way (like Daniel did for content
handler) we can probably add it into AbuseFilter.
It should be presented in a suitable way (not obscure Wikibase internal
structures),
Hi!
Once wikidata.org allows for entry of arbitrary properties, we will need some
protection against spam. However, there is a nasty little problem with making
SpamBlacklist, AntiBot, AbuseFilter etc work with Wikidata content:
Wikibase implements editing directly via the API, but using
On Tue, Dec 4, 2012 at 4:52 AM, Daniel Kinzler dan...@brightbyte.de wrote:
There's another closely related problem, btw: showing captchas. How can that
be
implemented at all for API based, atomic edits? Would the API return a special
error, which includes a link to the captcha image as a
On 12/04/2012 04:52 AM, Daniel Kinzler wrote:
4) just add another hook, similar to EditFilterMergedContent, but more
generic,
and call it in EditEntity (and perhaps also in EditPage!). If we want a spam
filter extension to work with non-text content, it will have to implement that
new hook.
14 matches
Mail list logo
