Page MenuHomePhabricator

Deliver mobile-based version for automatic translations
Open, HighPublic


When a page is delivered through an external translation service some functionality may be missing. 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 propose to the use of the mobile version of the content, even on desktop.

When an external translation service requests a page to translate, contents will be delivered using the default mobile skin (Minerva).

Other tickets will capture further adjustments on top of the mobile skin for this context in order to label the content as an automatic translation (T212202), and guide the user on how to contribute back.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptDec 18 2018, 12:23 PM
Pginer-WMF triaged this task as Medium priority.Dec 19 2018, 10:19 AM

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

Pginer-WMF raised the priority of this task from Medium to High.Dec 21 2018, 8:07 AM
dr0ptp4kt added subscribers: BBlack, atgo.

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

Restricted Application added a project: SRE. · View Herald TranscriptJan 7 2019, 7:51 PM
ema moved this task from Triage to Caching on the Traffic board.Jan 9 2019, 10:52 AM

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

@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).

santhosh moved this task from Backlog to In Review on the ExternalGuidance board.Feb 7 2019, 5:46 AM
debt added a subscriber: debt.Feb 7 2019, 10:04 PM

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

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

Change 489244 merged by BBlack:
[operations/puppet@production] Add file resource for

dr0ptp4kt added a comment.EditedFeb 8 2019, 8:09 PM

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.
dr0ptp4kt added a comment.EditedFeb 10 2019, 12:23 PM

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.

@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.

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

@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

@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

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
year = 2019
and month = 2
and day = 11
and uri_query like '%mobileaction=toggle_view_desktop%'
and x_analytics_map['translationengine'] = 'GT';


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
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 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?

dr0ptp4kt added a comment.EditedFeb 26 2019, 11:07 AM

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

The "Desktop" link in the footer is removed by way of 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 .

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.

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

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


Krenair added a subscriber: Krenair.Mar 7 2019, 9:02 AM

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.

santhosh moved this task from In Review to Done on the ExternalGuidance board.Apr 18 2019, 5:37 AM

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

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 to deploy.

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