Last modified: 2014-10-24 08:44:19 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T36182, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 34182 - Special:Translate unable to save where CAPTCHA is required
Special:Translate unable to save where CAPTCHA is required
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
Translate (Other open bugs)
unspecified
All All
: Normal normal with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 34197 42161 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-02-03 08:34 UTC by aokomoriuta
Modified: 2014-10-24 08:44 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description aokomoriuta 2012-02-03 08:34:59 UTC
When I don't have skipcaptcha right, page translation with external link got error.
Can we pass CAPTCHA test in translation function?
Comment 1 Siebrand Mazeland 2012-02-03 09:30:59 UTC
Nice find. Will look into this. To avoid actual spamming, I think we should only allow this if there are no warnings on the translation, ie changed links that would cause fuzzy markings.
Comment 2 aokomoriuta 2012-02-03 12:31:44 UTC
To avoid this error, I can edit the message directly (Translating:XXX) instead of editing through Special:Translate.
So as First Aid, it seems good to modify the error message in Special:Translate "Saving failed. Please report this error." to "You need edit this message directly to pass CAPTCHA.".
Comment 3 Niklas Laxström 2012-02-04 04:18:59 UTC
It is not easy to fix since all edits go through the API through normal saving mechanism.
Comment 4 qbphcqdw 2012-02-04 14:21:31 UTC
*** Bug 34197 has been marked as a duplicate of this bug. ***
Comment 5 Nemo 2012-02-05 14:08:03 UTC
ConfirmEdit can be configured per namespace, you can just disable it on translations: namespace with $wgCaptchaTriggersOnNamespace as a (partial) workaround?
Comment 6 Niklas Laxström 2012-11-15 20:41:26 UTC
*** Bug 42161 has been marked as a duplicate of this bug. ***
Comment 7 Kelson [Emmanuel Engelhart] 2013-09-05 07:20:00 UTC
I'm also impacted by this issue and I agree, if the API does not provide the necessary tools then it seems to me complicated to deal with this. How does the VisualEditor? He is impacted?
Comment 8 Nemo 2013-09-05 07:38:13 UTC
(In reply to comment #7)
> I'm also impacted by this issue and I agree, if the API does not provide the
> necessary tools then it seems to me complicated to deal with this. How does
> the
> VisualEditor? He is impacted?

It was: bug 50356 / https://gerrit.wikimedia.org/r/#/c/71160/ .
Comment 9 Kelson [Emmanuel Engelhart] 2013-09-05 08:06:46 UTC
So, it seems it's possible to deal with with the extension:ConfirmEdit through the API:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50356#c3

Would that be possible for extension:Translate to deal with it?
Comment 10 Nemo 2013-09-05 08:20:48 UTC
(In reply to comment #9)
> So, it seems it's possible to deal with with the extension:ConfirmEdit
> through
> the API:
> https://bugzilla.wikimedia.org/show_bug.cgi?id=50356#c3

Note, that comment mentions only FancyCaptcha [which is the least used component of ConfirmEdit: few wikis other than WMF use it].
Comment 11 Kelson [Emmanuel Engelhart] 2013-09-30 22:54:00 UTC
If this works only with FancyCaptcha, this is already a good start.
Comment 12 Nemo 2014-07-16 07:02:33 UTC
ContentTranslation implemented a (after the fact) solution: https://gerrit.wikimedia.org/r/#/c/146426/

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links