Page MenuHomePhabricator

CX2: Show the captcha confirmation dialog when the target wiki requests it
Closed, ResolvedPublic

Description

Some wikis require a captcha to be filled when publishing.

When users click on "publish", if the target wiki requests a captcha, users should be able to fill it. Ideally, the captcha dialog should be the same as used in VisualEditor.

As the first step of this task, we may want to check how it is provided in VE and CX1 currently (feel free to add screenshots to the ticket).


Related ticket (that may get fixed as a result of this one): T161333

Details

Related Gerrit Patches:
mediawiki/extensions/ContentTranslation : masterCX2: Add captcha support

Event Timeline

Pginer-WMF triaged this task as Medium priority.Mar 15 2018, 10:17 AM
Pginer-WMF created this task.
In T189766, @Pginer-WMF wrote:

As the first step of this task, we may want to check how it is provided in VE and CX1 currently (feel free to add screenshots to the ticket).

Here is how CX1 handles QuestyCaptcha:


As you can see, problem from T161333 exists in LTR wikis as well.

Here is how VE CAPTCHA looks on enwiki:


Entering wrong CAPTCHA text just gives you another puzzle to solve in both cases.

@Pginer-WMF How should the dialog look on CX2 and is the described retry process (when wrong CAPTCHA text is entered) good for us? Here is how CAPTCHA looks inside OOUI dialog. It's not reusing VE dialog like you requested in the description, but it's modeled after it.


Another important question. How should CAPTCHA dialog behave in relation to "Publish anyway" dialog? Should we modify the dialog from last screenshot and include info that page will be overwritten and change "Publish" button to "Publish anyway" or some other solution to avoid two dialogs appearing in succession?

@Pginer-WMF How should the dialog look on CX2 and is the described retry process (when wrong CAPTCHA text is entered) good for us? Here is how CAPTCHA looks inside OOUI dialog. It's not reusing VE dialog like you requested in the description, but it's modeled after it.

Thanks for the screenshots of current behaviour. Your approach looks good to me. I'd only customise the text a bit:

I have some questions about the introductory text ("To edit this page, please answer the question that appears below (more info):":

  • Does this come from the Captcha itself or is something that we can customise. I'm concerned about the "to edit this page", and would like to have a more specific message (using "publish" instead).
  • Is the "more info" link opening in a new tab/window?

Regarding the workflow, retrying makes sense, but I'd like if possible to show a message to indicate what happened. Something along the lines of "Your answer does not seem correct,. Let's try again.". Based on the flexibility we have to tweak the messages in the dialog, we can present it in different ways.

Another important question. How should CAPTCHA dialog behave in relation to "Publish anyway" dialog? Should we modify the dialog from last screenshot and include info that page will be overwritten and change "Publish" button to "Publish anyway" or some other solution to avoid two dialogs appearing in succession?

The "publish anyway" dialog already combines two steps: confirming the contents will be overwritten (T190038) and confirm publishing with existing warnings is ok (T189671). So I'd keep the captcha as a separate final step after this since it is more of a technical check rather than a decision making point about the content.

I have some questions about the introductory text ("To edit this page, please answer the question that appears below (more info):":

  • Does this come from the Captcha itself or is something that we can customise. I'm concerned about the "to edit this page", and would like to have a more specific message (using "publish" instead).

CAPTCHA system is implemented in ConfirmEdit extension and everything in my demo dialog from last comment is coming from that extension, including the messages ("CAPTCHA" message in dialog header and introductory text "To edit this page...") and the content of CAPTCHA (question, image, math equation...). So, the messages are defined in ConfirmEdit extension, but we're controlling what is used in dialog and we can introduce new messages for this use case.
That will also remove the dependency on UI messages which are coming from non-CX extension. You can specify entirely different introductory sentence if you want, but keep in mind that different types of CAPTCHA may require different introductory sentences. You have the list of CAPTCHA types on extension mediawiki page (on the end of this comment, there are messages for these different types). Or, we can try to come up with universal intro sentence.

ConfirmEdit extension recognizes different types of triggers for CAPTCHA. Among others, two possible types are "create" and "edit" actions. Our CX publish API uses 'action' => 'edit' when wikitext from target article is being published. That's why "edit" messages were used. Using "create" messages from ConfirmEdit extension is another option and you can check the difference in the UI messages listing at the end of this comment.

  • Is the "more info" link opening in a new tab/window?

Yes, and it leads to /index.php/Special:Captcha/help. (example)

Regarding the workflow, retrying makes sense, but I'd like if possible to show a message to indicate what happened. Something along the lines of "Your answer does not seem correct,. Let's try again.". Based on the flexibility we have to tweak the messages in the dialog, we can present it in different ways.

One way to communicate that entered CAPTCHA text was wrong is to tweak introductory sentence when that happens. That would just double the number of potentially many messages (which might need to cover all types of CAPTCHAs).
Also, OOUI dialog provides option to show errors, but it's not usable in this case, because it overlays the entire panel:


Since I'm implementing our own dialog, which inherits from OOUI dialog, we can tweak the dialog to present indicator about failed CAPTCHA entry, so that similar dialog to error one (on above screenshot) is displayed inline (possibly on top) with non-red color.

I have already provided demo of QuestyCaptcha in previous comments and here is how FancyCaptcha (which WMF uses) looks with the dialog.

If you decide to come up with new UI messages here is what's already defined in ConfirmEdit extension:

FancyCaptcha used by WMF

"fancycaptcha-create": "To create the page, please enter the words that appear below in the box ([[Special:Captcha/help|more info]]):"
"fancycaptcha-edit": "To edit this page, please enter the words that appear below in the box ([[Special:Captcha/help|more info]]):"

QuestyCaptcha

"questycaptcha-create": "To create the page, please answer the question that appears below ([[Special:Captcha/help|more info]]):"
"questycaptcha-edit": "To edit this page, please answer the question that appears below ([[Special:Captcha/help|more info]]):"

ReCaptcha

"recaptcha-edit": "To protect the wiki against automated edit spam, we kindly ask you to type the words you see in the box."
"recaptcha-create": "To protect the wiki against automated page creation, we kindly ask you to type the words you see in the box."

ReCaptchaNoCaptcha

"renocaptcha-edit": "To protect the wiki against automated edit spam, we kindly ask you to solve the following CAPTCHA:"
"renocaptcha-create": "To protect the wiki against automated page creation, we kindly ask you to solve the following CAPTCHA:"

SimpleCaptcha

"captcha-edit": "To edit this page, please solve the following task below and enter the answer in the box ([[Special:Captcha/help|more info]]):"
"captcha-create": "To create the page, please solve the following task below and enter the answer in the box ([[Special:Captcha/help|more info]]):"

Change 427196 had a related patch set uploaded (by Petar.petkovic; owner: Petar.petkovic):
[mediawiki/extensions/ContentTranslation@master] CX2: Add captcha support

https://gerrit.wikimedia.org/r/427196

Thanks for all the details @Petar.petkovic

I think we can do the following:

  • Use the default messages, but use the "create" action instead. That allows to keep the messages aligned with the user goal (create a new article), consistent with other places users may have seen them before and updated if anything changes in the captcha extensions.
  • Override the dialog title message. As an exception to the above point, I think we want to replace the "CAPTCHA" title since it is a technical term that does not describe why we are showing it to the user. I propose to use "Checking you are not a robot" instead.
  • Show an error box. When the captcha fails, we could add an error message box inline ("Your answer does not seem correct. Please, try again."). From your comments, it is not clear whether this is a valid and technically simple option. Another option could be to show the messages based on time. I illustrated both approaches below:

Error message (using whichever is the default styling for the error box):

Time-based message (showing the error message for 3 seconds):

I think we can do the following:

  • Show an error box. When the captcha fails, we could add an error message box inline ("Your answer does not seem correct. Please, try again."). From your comments, it is not clear whether this is a valid and technically simple option. Another option could be to show the messages based on time.

Reusing existing error mechanism that OOUI dialogs have is possible with little tweaks here and there. Here is how it looks for FancyCaptcha and QuestyCaptcha:

FancyCaptchaQuestyCaptcha

Reusing existing error mechanism that OOUI dialogs have is possible with little tweaks here and there. Here is how it looks for FancyCaptcha and QuestyCaptcha:

FancyCaptchaQuestyCaptcha

That seems a good enough approach. This will be exposed to very few users (many won't be shown the captcha and only a few are expected to fail) and it seems already an improvement over the current status.

Change 427196 merged by jenkins-bot:
[mediawiki/extensions/ContentTranslation@master] CX2: Add captcha support

https://gerrit.wikimedia.org/r/427196

Petar.petkovic moved this task from In Review to QA on the Language-2018-Apr-June board.
Petar.petkovic added a subscriber: KartikMistry.

@KartikMistry, CAPTCHA patch is now merged, you can configure cx2-testing for ConfirmEdit (CAPTCHA extension).

@KartikMistry, CAPTCHA patch is now merged, you can configure cx2-testing for ConfirmEdit (CAPTCHA extension).

Thanks. I have enabled strict captcha config on cx2-testing.

Checked it in cx2-testing - FancyCaptcha seems to be in place and works (Chrome 64, Mac) :


@Petar.petkovic - looks a little bit blurrier than in your previous screenshots?


@Petar.petkovic - looks a little bit blurrier than in your previous screenshots?

There is a script that is supposed to create CAPTCHA images. It was not working for me, so I created my own CAPTCHA. For @KartikMistry, everything went smoothly with the given script when he was setting up test environment. Probably that's where the difference is coming from.

Please test functionality and try to keep the image quality aside.

Etonkovidova closed this task as Resolved.May 1 2018, 4:11 PM

Thanks, @Petar.petkovic. I agree that the image quality is out of scope of this ticket. The functionality's been tested.