As per our current understanding this would be a varnish layer redirection based on the Via http header. Its value need to be matched for example, with the translation proxy servers. A known value at this point is translate.googleusercontent.com

Paraphrasing a dialogue with @BBlack immediate edge side HTTP redirects based on header/regex might be feasible without fragmenting caches/backends.

@BBlack do you think something similar to https_recv_redirect might work?

@santhosh in addition to restricting this to specific transcoding proxies (and not negatively influencing for example search automata), I think you'd want to also be cognizant of special redirection logic about mobile subdomains (cf. mobile_redirect).

CC: @atgo

Hi @BBlack , any suggestion here?

We determined on a separate thread that I'll be the one writing the patch.

CC @Arrbee @ggellerman

I don't have any suggestions, no. Develop a straw-patch which at least serves in code terms to document the intent (e.g. the explicit header and URI values matched/transformed, etc) and we'll poke at it!

Change 485171 had a related patch set uploaded (by Dr0ptp4kt; owner: Dr0ptp4kt):
[operations/puppet@production] Add a Google Translate specific redirect-to-mobile

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

@BBlack patch posted for your review ^. Would you please review and let me know on patch for any additions?

@BBlack hold that thought, one more condition to add.

Okay, @BBlack, now it's ready for review.

Heads up @phuedx . @BBlack and I spoke yesterday and we'll go with a simpler patch instead of the fuller refactor, given the plan to have the Varnish stuff in maintenance mode and switch to ATS (i.e., don't fix it if it ain't broken).

Change 485171 merged by BBlack:
[operations/puppet@production] Add a Google Translate-specific redirect-to-mobile

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

Change 489244 had a related patch set uploaded (by BBlack; owner: BBlack):
[operations/puppet@production] Bugfix for prev commit rOPUP6c0cea96cbca

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

Change 489244 merged by BBlack:
[operations/puppet@production] Add file resource for translation-engine.inc.vcl

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

Hi team.

Okay, this is activated for Simple English as the source wiki.

Thank you so much @BBlack!

I'll prepare two patches next week, ahead of ExterrnalGuidance deployment to English Wikipedia as the source wiki.

@Arrbee would you please confirm the expected ship date for ExternalGuidance being activated for English Wikipedia (for Bahasa Indonesia readers).

The patches I'll create next week:

• A Varnish patch for enwiki, so that Google Translate users get redirected to the mobile web treatment if enwiki is the source wiki for the Google Translate user. Working from the assumption that we want desktop users to get the guided flow just like mobile users, I suggest that the Varnish patch for enwiki is deployed the day before the deployment of the configuration patch to activate ExternalGuidance for enwiki (for Bahasa Indonesia readers).
• I identified a regression that surfaces only in a very specific case at present. If a user uses Google Translate and has Simple English as the source wiki, the user gets the mobile web treatment (that was the point of this patch - specifically to ensure that desktop users are sent to the simpler experience). But if the Google Translate user using Simple English as the source wiki taps/clicks the "Desktop" link in the footer of the mobile web treatment the user doesn't in fact get a desktop treatment. That's frustrating of course (even if there are many other limitations in this transcoding proxy scenario). This is a rather rare behavior when we're only talking about Simple English as the source wiki, via Google Translate. But we can be fairly confident that once we add the enhancement to redirect traffic from desktop to mobile for Google Translate in the case of enwiki as the source wiki, the behavior will probably be modestly more commonplace because of the scale and shape of translated traffic involving enwiki sourcing - so a fix should be made.

I should note that, concerning the edge case regression, it has historically been the case that, even after the mobile Google Translate user taps/clicks "Desktop" link and is landed in a desktop presentation, subsequent taps/clicks in article links would wind them back into a mobile presentation. This has to do with the way cookies are not capable of being enforced in this translation context like when users access the site directly. So addressing the regression for the mobile user is only a modest improvement. But for the genuine desktop user, it may not be perceived as so modest because the desktop user may have been accustomed to the desktop treatment (even if we think the mobile treatment is more reader friendly). I'll need to check with @Pginer-WMF about the mental model and nearer term (next six to twelve months) user journey here and determine how to handle this, in a sustainable way, if at all. Given that users can use inbuilt translation in user agents, we may just want to notify the user on tap to do that upon the "Desktop" click/tap by way of ExternalGuidance JavaScript, for example.

In T212197#4939326, @dr0ptp4kt wrote:

@Arrbee would you please confirm the expected ship date for ExternalGuidance being activated for English Wikipedia (for Bahasa Indonesia readers).

Not before the last week of February, may even be the 1st week of March. We will have a clearer date later this week.

In T212197#4941262, @dr0ptp4kt wrote:

I'll need to check with @Pginer-WMF about the mental model and nearer term (next six to twelve months) user journey here and determine how to handle this, in a sustainable way, if at all.

The way I see this is the following: for automatic translation we are providing content with a custom "automatic translation" skin that responds to the limitations of externally-served content. That "automatic translation" skin is based on the mobile skin for convenience, but is the intended representation for users accessing translated content from all platforms. The classical desktop or mobile skins are not very useful in this context since they expose actions that do not work (plus we cannot access user preferences to check if the user selected a different skin than the defaults).

From that perspective, I'd propose not exposing the mobile/desktop switch options for automatic translations. In this way, translated content is always delivered with the "automatic translation" skin, without a path to other representations full of links and actions that do not work in this context.

Thanks @Arrbee. Thanks @Pginer-WMF.

@santhosh and @Gilles the footer list containing the "Desktop" link and other list items places the dot character between elements using an li::after pseudo-element. Do you think we should just use JS to remove the "Desktop" <li> instead of using a CSS rule? Setting the opacity to 0 like the other hidden elements would leave the dot character for any preceding bullets in place, which looks unusual because it leaves a dot at the end of the list. If we use JS is there a preferred segment of the JS code to do so to avoid any performance issues?

Heads up @chelsyx: for simplewiki access via the Google Translate proxy the traffic pattern is now mobile web based even for desktop UAs. The same will happen with enwiki when we make that change later. I thought I should make this clear for any intervention analysis.

@dr0ptp4kt Any of the extension's modules is fine to do this in JS, they're low priority. It does mean that the link will appear until the JS module is loaded and executed. But there's no good way around that.

Change 490089 had a related patch set uploaded (by Dr0ptp4kt; owner: Dr0ptp4kt):
[mediawiki/extensions/ExternalGuidance@master] Hide the Desktop footer in external guidance mode

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

@santhosh ^ would you please review and verify it has the intended effect? I need to reset my Vagrant stuff, but figured this was simple looking enough to post a patch (we'll see if I'm right!).

Thanks @Gilles for the note.

Change 490120 had a related patch set uploaded (by Dr0ptp4kt; owner: Dr0ptp4kt):
[operations/puppet@production] WIP DO NOT MERGE enwiki source Google Translate

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

@BBlack ^ would you please review the enwiki VCL patch? We'll only want to merge it after ExternalGuidance has been tested with simplewiki and @Pginer-WMF has given the greenlight, but I figured it best if we go through review ahead of that.

Change 490089 merged by jenkins-bot:
[mediawiki/extensions/ExternalGuidance@master] Hide the Desktop footer in external guidance mode

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

Thanks, @santhosh !

For those following along, I ran a query to get a sense of global usage of Google Translate and using the "Desktop" link. On 11 February 2019 there were only 89 such requests globally, about 2/3 where enwiki was the source wiki. This figure is not a perfect predictor of desktop user behavior, as for desktop users using enwiki as the source wiki receiving the mobile treatment it will be a new thing. But it probably suggests that, in addition to the rationale @Pginer-WMF provides about the basis of stopping showing broken stuff, the mobile read view is okay for consumptive purposes in general.

select count(1) from webrequest
where
year = 2019
and month = 2
and day = 11
and uri_query like '%mobileaction=toggle_view_desktop%'
and x_analytics_map['translationengine'] = 'GT';

OK
_c0
89

So that it's available later for additional comparison, here's some data about pageviews, use of the "Desktop" link, and tagging for use of a translation engine. The TL;DR is at present GT constitutes a relatively modest portion of global traffic and clicks/taps to the "Desktop" link in that mode are small (n.b., SERP-based treatment for Bahasa Indonesian users is nontrivial with respect to Google search engine-based traffic, presently mobile based, now using the enwiki source for articles).

select count(1), x_analytics_map['translationengine'], uri_query like '%mobileaction=toggle_view_desktop%', access_method, is_pageview from webrequest
where
year = 2019
and month = 2
and day = 11
and agent_type = 'user'
group by x_analytics_map['translationengine'], uri_query like '%mobileaction=toggle_view_desktop%', access_method, is_pageview;



_c0     _c1     _c2     access_method   is_pageview
280884  NULL    true    desktop false
194741  NULL    true    desktop true
28442   NULL    true    mobile web      false
11082   NULL    true    mobile web      true
6520290033      NULL    false   desktop false
261199128       NULL    false   desktop true
2226023657      NULL    false   mobile web      false
317005595       NULL    false   mobile web      true
77      GT      true    desktop false
12      GT      true    desktop true
62796   GT      false   desktop false
295839  GT      false   desktop true
2713    GT      false   mobile web      false
165500  GT      false   mobile web      true
253572508       NULL    false   mobile app      false
8404315 NULL    false   mobile app      true

@BBlack in https://gerrit.wikimedia.org/r/490120 I checked in with @Pginer-WMF today. Pau said deploying this the day or two prior to ExternalGuidance being activated for the source wiki of enwiki (for Indonesian) would be ideal.

I put the big "WIP DO NOT MERGE" on this because I wasn't clear on the desired ship date dependent on testing. Should I remove that verbiage from the commit message now? Presently the ship date for ExternalGuidance activated for the source wiki of enwiki (for Indonesian) looks like March 28 or February 7 - meaning the VCL should be in on March 26-27 or February 5-6. I was wondering if I should schedule some time with you for deployment of the VCL (and if you think we need any deployment window) on those two possible times. Would that be okay?

The VCL looks good, please give us some notice (~24h would be ideal?) on when you need it actually deployed once you've decided on a date. Any news on the Desktop-denial regression?

Thanks, @BBlack, will give the heads up once the date is set.

The "Desktop" link in the footer is removed by way of https://gerrit.wikimedia.org/r/490089. When wmgUseExternalGuidance is set to true for enwiki, that will suppress the "Desktop" link in the footer as per T212197#4942773. You can see it in action on https://translate.google.com/translate?sl=auto&tl=en&u=https%3A%2F%2Fid.m.wikipedia.org%2Fwiki%2FPenanganan_pengecualian .

This code block runs unconditionally when the ExternalGuidance JS init is called (n.b., GT is only running in a JS context) - although that made me think: @santhosh is there any scenario in a future architecture of the extension where it might not run unconditionally for the extension? This doesn't seem to matter today, but I just want to ensure we get ahead of it should that be a risk in the future.

@santhosh is there any scenario in a future architecture of the extension e where it might not run unconditionally for the extension?

No. If it happens there will be lot of more important problems. The context detection code is the only code that goes unconditionally.

Thanks, @santhosh. When you say "context detection code", I take that to mean inclusive of this init code we're referring to for the "Desktop" footer link removal.

What's our latest read on the release date for enwiki as the source? I was thinking to set a reminder on the calendar corresponding to the VCL change.

In T212197#4991170, @dr0ptp4kt wrote:

What's our latest read on the release date for enwiki as the source? I was thinking to set a reminder on the calendar corresponding to the VCL change.

The candidate date for deployment is March 7. There are still some blockers that could affect the date (more details in T216129). I expect next Monday (March 4) to have more clarity on the status of these blockers.

Thanks @Pginer-WMF. I've put a HOLD on the calendar for March 6 to get the Varnish patch up a little bit ahead of this, although will adjust as needed for any change in the activation for the extension (or the schedule of @BBlack and myself the day prior to the activation of the extension).

Change 490120 merged by BBlack:
[operations/puppet@production] Redirect Google Translate enwiki source to mobile

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

Confirmed that enwiki redirects to mobile version when accessed from Google translate from desktop browser

Example: https://translate.google.com/translate?hl=id&sl=en&tl=id&u=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FProxima_Centauri&sandbox=1

Update: We are deploying ExternalGuidance to all Wikis (but mainly visible for English translations) tomorrow during EU Mid-day SWAT. See T216129 for all deployment details.

Change 506043 had a related patch set uploaded (by Santhosh; owner: Santhosh):
[operations/puppet@production] Redirect Google Translate any wiki source to mobile

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

@BBlack Can you please review https://gerrit.wikimedia.org/r/506043 ?

Done. Are we ready to deploy it already or blocked on other MW-level deploys still?

We don't have any other blockers for this puppet patch. Once this puppet patch is deployed, we have a configuration change https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/504261 to deploy.

Change 506043 merged by Ema:
[operations/puppet@production] Redirect Google Translate any wiki source to mobile

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

The swap of Traffic for Traffic-Icebox in this ticket's set of tags was based on a bulk action for all such tickets that haven't been updated in 6 months or more. This does not imply any human judgement about the validity or importance of the task, and is simply the first step in a larger task cleanup effort. Further manual triage and/or requests for updates will happen this month for all such tickets. For more detail, have a look at the extended explanation on the main page of Traffic-Icebox . Thank you!

In order to focus on content and reduce the number of tools exposed in the UI chrome that may not work on an external context, we

Could this be elaborated on? I understand that some actions may not work in an external proxy context, but this 1) does not follow the principle of "least surprise", while users may be aware those could be broken, as it is not unique to this site. In particular, if I hit, "switch to desktop" while on mobile translation it sticks to mobile. 2) it breaks functionality that the users want, like access to talk pages. See https://app.slack.com/client/T024KLHS4/C0153LQ5G82/thread/C0153LQ5G82-1660916209.007379 for context.

What exactly is left to do in this open task?