Page MenuHomePhabricator

VisualEditor should explicitly set Accept-Language
Closed, ResolvedPublic

Description

Requests made by VisualEditor will implicitly contain Accept-Language header provided by the browser. The browser sets the Accept-Language to the preferred system language of the user, and for wikis that support language variants, we split the Varnish cache by variant. So, for example, if a person who has English as a default system language goes to edit Serbian wiki - he will most definitely get a cache miss.

More importantly, for some languages OS allows to select a variant, for example, zh-tw for Taiwan Chinese variant, so REST API will serve the content in a variant that after saving in VE will potentially create a dirty diff since the original wikitext was stored in a natural, mixed variant.

Until we start supporting visual editing in variants in Parsoid, VE needs to explicitly set the Accept-Language header to the page_language of the page being edited.

Event Timeline

Pchelolo triaged this task as High priority.Jun 26 2018, 10:15 AM
Pchelolo created this task.
Restricted Application added subscribers: Petar.petkovic, Aklapper. · View Herald TranscriptJun 26 2018, 10:15 AM

Just verified in Vagrant that explicitly specifying Accept-Language in VE works and visual editing works as well if we provide the page_language as Accept-Language. When we start supporting editing in variants we will want to specify something else, but now it seems pagelang is the best option.

Change 442148 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/VisualEditor@master] Pass content language in Accept-Language header to RESTBase

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

cscott added a subscriber: cscott.Jun 26 2018, 5:15 PM

Even after editing in variants works, we'll want to set accept-language to the user's mediawiki-preferred variant, not necessarily whatever the browser happens to emit. So overriding the browser header is definitely necessary.

In order to unblock the current stage of RESTBase work, VE could also just hardcode Accept-Language: en for every request. Then it could land the "correct" patch w/o schedule pressure from RESTBase.

Change 442159 had a related patch set uploaded (by C. Scott Ananian; owner: C. Scott Ananian):
[mediawiki/extensions/VisualEditor@master] Override browser/PHP's default Accept-Language header sent to RESTBase

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

Change 442148 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] Pass content language in Accept-Language header to RESTBase

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

Deskana added subscribers: Esanders, Deskana.

I believe that @Esanders's patch fully resolves this issue, and that @cscott's patch is therefore unnecessary now and can be abandoned. Is that right?

Change 442159 abandoned by Jforrester:
Override browser/PHP's default Accept-Language header sent to RESTBase

Reason:
Overtaken by I2176f68f76, which is now merged.

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

Any chance we could SWAT this?

Change 443754 had a related patch set uploaded (by Jforrester; owner: Esanders):
[mediawiki/extensions/VisualEditor@wmf/1.32.0-wmf.10] Pass content language in Accept-Language header to RESTBase

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

Change 443754 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@wmf/1.32.0-wmf.10] Pass content language in Accept-Language header to RESTBase

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

Mentioned in SAL (#wikimedia-operations) [2018-07-05T15:03:37Z] <mobrovac@deploy1001> Started scap: Set the Accept-Language header explicitly when making requests to the REST API - T198186

Mentioned in SAL (#wikimedia-operations) [2018-07-05T15:34:28Z] <mobrovac@deploy1001> Finished scap: Set the Accept-Language header explicitly when making requests to the REST API - T198186 (duration: 30m 50s)

Pchelolo closed this task as Resolved.Jul 5 2018, 3:36 PM
Pchelolo claimed this task.

The patch was SWATed, checked it works, resolving.