@KCVelaga_WMF Would it be possible to exclude bot crawlers from the analytics data?

I don't think it is possible with any of the available contextual attributes. I have to check with Exp Platform on this one.

Change #1186437 had a related patch set uploaded (by Huei Tan; author: Huei Tan):

[mediawiki/extensions/ContentTranslation@master] MinT: Redirect user to confirm page to prevent crawler access

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

In T403389#11161449, @gerritbot wrote:

Change #1186437 had a related patch set uploaded (by Huei Tan; author: Huei Tan):

[mediawiki/extensions/ContentTranslation@master] MinT: Redirect user to confirm page to prevent crawler access

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

Accessing Special:AutomaticTranslation?page=Hello+(Adele+song)&from=en&to=fr&step=translation directly will now redirect the user to the confirm step instead.

Change #1186437 merged by jenkins-bot:

[mediawiki/extensions/ContentTranslation@master] MinT: Redirect user to confirm page to prevent crawler access

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

The proposal makes sense. It would be great to check that:

• Info on the parameters is respected (i.e., source/target languages are pre-filled accordingly).
• The preview card gets the input focus automatically. Allowing users to (a) identify it as the next step, and (b) be able to just hit enter to continue.
• Make sure that we are still allowing users to access links from machine translated content directly. That is, when reading a machine translation of article X, a user can still click on a link to article Y and get a machine translation of it directly without having to access the Confirm step (in the future we can consider a more subtle link preview: T359824).
• For instrumentation, it would be great to be able to identify how much crawler access these links get. Ideally, helping to distinguish crawlers trying to access translations from real users that access the Confirm step and drop-off.

A couple of additional considerations:

• Wondering if it makes sense to still allow direct access to logged-in users. Can we assume logged-in users are not crawlers? In the context of the experiment, I'm not sure if this would allow for any useful comparison or would just make things more complex. If the latter, feel free to ignore.
• As a side note, I wonder how crawlers could figure out a url such as the one in the example, but the button in the confirmation step can keep them out. Adding a note about this in the ticket description may be useful to understand the approach for future reference.

In T403389#11179964, @Pginer-WMF wrote:

• Make sure that we are still allowing users to access links from machine translated content directly. That is, when reading a machine translation of article X, a user can still click on a link to article Y and get a machine translation of it directly without having to access the Confirm step (in the future we can consider a more subtle link preview: T359824).

• Currently the is no AX article link within the machine translation of article X
• user can change the target/source language directly on the page to see new machines translation page

• For instrumentation, it would be great to be able to identify how much crawler access these links get. Ideally, helping to distinguish crawlers trying to access translations from real users that access the Confirm step and drop-off.

• unfortunately, currently there is no way to distinguish crawlers from the analytics; we can have a event log if someone use the translation page link directly but we can't really tell they are crawlers or real user

• Wondering if it makes sense to still allow direct access to logged-in users. Can we assume logged-in users are not crawlers? In the context of the experiment, I'm not sure if this would allow for any useful comparison or would just make things more complex. If the latter, feel free to ignore.

This make sense to me, and T405097 was created for this, @Pginer-WMF feel free to take a look and share your opinion

Moving to Done, feel free to reopen ticket or use the new ticket as the follow up.