On 21 January 2013 07:56, Andre Klapper aklap...@wikimedia.org wrote:
at all implies that some spambots are blocked at least?
Yes, but to count as successful it would have to block approximately
all, I'd think.
I mean, you could redefine something that doesn't block all spambots
but does
Not sure about enwiki, but from my experience with hosting smaller wiki's
CAPTCHA's are pretty useless (reCAPTCHA, FancyCAPTCHA, some custom ones).
The spambots keep on flooding through.
I've found its much more effective to just use the AbuseFilter.
-- Chris
On 2013-01-21 3:56 AM, Andre Klapper aklap...@wikimedia.org wrote:
On Mon, 2013-01-21 at 07:48 +, David Gerard wrote:
On 21 January 2013 05:13, Victor Vasiliev vasi...@gmail.com wrote:
On 01/20/2013 04:22 PM, David Gerard wrote:
The MediaWiki captcha is literally worse than
On 21 January 2013 08:43, Bawolff Bawolff bawo...@gmail.com wrote:
Does
http://elie.im/publication/text-based-captcha-strengths-and-weaknessescount
as evidence? (Copied and pasted from the mailing list archives)
404 :-) Correct link:
Hi Krinkle!
Thanks for the clarification!
mediawiki.searchSuggest does NOT use jquery.ui.autocomplete.
Yes, I know. I never said anything like this. Maybe this was a
misunderstanding. I said I wanted to replace mediawiki.searchSuggest with my
own implementation _based on_
Hey,
I have a custom action in which I construct HTML to display by rendering
some user provided wikitext and some grammatically build chunks of HTML. It
looks like this:
$html = 'some html';
$html .= $this-getOutput()-parse( 'wiki text' );
$html .= 'more html';
$html .= 'even more html';
Hi,
thanks for your suggestions, at the end I found it :-)
It was a closed data base connection, that prevented
Title::newFrom...-methods to get articleId etc.
--- the eval part ---
$dbReadOnly2 = wfGetDB(DB_SLAVE);
# do some stuff
$dbReadOnly2-close();
# use another method that needs data base
On Mon, Jan 21, 2013 at 12:28 AM, Sébastien Santoro
dereck...@espace-win.org wrote:
I concur and offer to document that. Something like this text could be
used in this purpose.
== Tips ==
=== Push to Gerrit to show your code. In code review we trust. ===
MediaWiki uses a continuous
And to be more explicit, quoting the paper in case someone really has
doubts: «we deem a captcha scheme broken when the attacker is able to
reach a precision of at least 1%». With our FancyCaptcha we are/were at
25 % precision for attackers, so yes, it's officially broken, and it's
been so
Hi guys!
I'm searching the good sidebar extension for MediaWiki project, can
anyone recommend something nice? I've tried SidebarEx, NavBlocks,
CustomSidebar
Requirements:
1) Full MediaWiki markup support;
2) show different content for different groups of users;
3) show different content for
Heya :)
On the 4th of February Quim will be at the Wikimedia Germany office to
introduce MediaWiki groups. See https://www.mediawiki.org/wiki/Groups
for more info about the groups.
We'll meet at 18:30 in the office in Obentrautstr. 72, Berlin. Quim
will talk and answer questions for about 1 hour
On Mon, Jan 21, 2013 at 6:07 AM, Yury Katkov katkov.ju...@gmail.com wrote:
Hi guys!
I'm searching the good sidebar extension for MediaWiki project, can
anyone recommend something nice? I've tried SidebarEx, NavBlocks,
CustomSidebar
https://www.mediawiki.org/wiki/Extension:DynamicSidebar
Is that stuff supposed to go after one chooses no, ask me more questions?
Cause I was not asked *any* more questions.
On a related story: if I give the installer a table prefix for which the
tables already exist, what will it do? I have 3 wikis in the same DB, and
I therefore cannot simply drop
There's a useful blog post on code review at Mozilla by Mozilla developer David
Humphrey on his blog: http://vocamus.net/dave/?p=1569.
I like his breakdown of different types of code reviews. It seems like at
Mozilla there is a lot of room for the patch submitter to indicate to reviewers
what
On Mon, Jan 21, 2013 at 3:00 AM, David Gerard dger...@gmail.com wrote:
I mean, you could redefine something that doesn't block all spambots
but does hamper a significant proportion of humans as successful,
but it would be a redefinition.
It's not a definition, it's a judgment.
And whether or
Given that there are algorithms that can solve our captcha presumably they
are mostly preventing the lazy and those that don't have enough knowledge
to use those algorithims. I would guess that text on an image without any
blurring or manipulation would be just as hard for those sorts of people to
On 01/21/2013 03:00 AM, David Gerard wrote:
On 21 January 2013 07:56, Andre Klapper aklap...@wikimedia.org wrote:
at all implies that some spambots are blocked at least?
Yes, but to count as successful it would have to block approximately
all, I'd think.
That's dubious. Blocking all
This call is equally valid to MediaWiki / Wikimedia tech contributors:
Original Message
Subject: [Wikimedia-l] Wikimania 2013 scholarship now accepting application
Date: Tue, 22 Jan 2013 13:03:47 +0800
From: Simon Shek simon.s...@wikimedia.hk
Reply-To: Wikimedia Mailing List
Am 21.01.2013 09:48, schrieb Robert Vogel:
Hi Krinkle!
Thanks for the clarification!
mediawiki.searchSuggest does NOT use jquery.ui.autocomplete.
Yes, I know. I never said anything like this. Maybe this was a
misunderstanding. I said I wanted to replace mediawiki.searchSuggest with
my
I tried to build a template which wraps template parameters into data-
attributes. First results have been incouraging, then I find something
logical but unexpected, crushing the whole idea.
I wrote into the code of an infobox-like template something like this:
span data-author={{{author}}}
On 22 January 2013 04:28, Matthew Flaschen mflasc...@wikimedia.org wrote:
On 01/21/2013 03:00 AM, David Gerard wrote:
Yes, but to count as successful it would have to block approximately
all, I'd think.
That's dubious. Blocking all spambots is not the goal of any CAPTCHA.
The goal is to
Hi Thomas,
thanks for sharing your experiences. The issues you mention can truly be
problematic. I will keep them in mind. But for my use case
jquery.ui.autocomplete does work quite well.
[...] and my advice for MediaWiki is, _not_ to go this way.
I don't think there were considerations
22 matches
Mail list logo
