Page MenuHomePhabricator

Enable captcha for anonymous page creation on Spanish Wikipedia
Closed, InvalidPublic

Description

Author: pdsanchez

Description:
Well, I?m only the carrier as they don't know who to talk about it.

There has been discussion and voting on es: regarding captchas for anon editing.
http://es.wikipedia.org/wiki/Wikipedia:Votaciones/2006/Introducci%C3%B3n_de_un_captcha_para_la_creaci%C3%B3n_de_art%C3%ADculos_por_parte_de_usuarios_an%C3%B3nimos

They've contacted me to forward the request to enable them on es:

  • drini

Version: unspecified
Severity: enhancement
URL: http://es.wikipedia.org/wiki/Wikipedia:Votaciones/2006/Introducci%C3%B3n_de_un_captcha_para_la_creaci%C3%B3n_de_art%C3%ADculos_por_parte_de_usuarios_an%C3%B3nimos

Details

Reference
bz8668

Related Objects

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:31 PM
bzimport set Reference to bz8668.
bzimport added a subscriber: Unknown Object (MLST).

pdsanchez wrote:

(In reply to comment #1)

Editing? Or _page creation_?

My mistake. For creation.
(captcha para la creación de artículos)

pdsanchez wrote:

ping? people asked me if this will be actually enabled

Apply bug 9099 to make this happen.

Configuration on LocalSettings would be as follows:

$wgCaptchaTriggers['create'] = true; Show captcha on page creation
$wgGroupPermissions['user' ]['skipcaptcha'] = true;
For unregistered
users only

The suggested configuration would break the anti-spam and anti-password-cracking use of the captcha, by allowing addurl, createaccount and badlogin from any logged-in user.

It would break addurl, but that was a known drawback. The users have already passed a captcha to create the account.
Only breaks createaccount from registered users (create2), and it would be logged, so not a big problem.
badlogin captcha show always, even with skipcaptcha permission.

mike.lifeguard+bugs wrote:

Is this still relevant several years later?