This task has been referenced in a thread at the wikisource-l mailing list: http://thread.gmane.org/gmane.org.wikimedia.wikisource/2635

The detailed analysis on the feasibility, mainly from the Ops perspective, is at T43451: ULS causes pages to be cached with random user language. That was in 2012. If the infrastruture changes if any after that is favorable now, we should re-assess.

Since 2012, we have migrated from Squid to Varnish, so the situation might need to be reevaluated.

By design, testwiki responses are never cached in varnish, so it's not a great wiki to target if you're hoping to learn anything about how enabling $wgULSAnonCanChangeLanguage would interact with the caching layer. You could change your patch to target test2wiki instead, but even then I don't expect we would learn much that we don't already know.

@Nikerabbit succinctly explained the crux of the problem in T58464#994780. I'll try to expand on that comment a little.

The WMF's Varnish layer handles the Cookie header in the following way: unless the cookie header sent by the client includes a session token, the cookie header is not treated as significant for the purposes of a cache lookup.

Thus the following request is a cache miss:

$ curl --silent --head --cookie "session=$(date +%s)" "https://de.wikipedia.org/wiki/Wikipedia:Hauptseite" | grep X-Cache
X-Cache: cp1065 miss (0), cp2016 miss (0), cp2016 frontend miss (0)

Whereas this request is not:

$ curl --silent --head --cookie "xyz=$(date +%s)" "https://de.wikipedia.org/wiki/Wikipedia:Hauptseite" | grep X-Cache
X-Cache: cp1065 hit (2), cp2016 hit (2), cp2016 frontend hit (54)

Even though in both cases, the cookie value is novel.

Unless Varnish is configured to treat the language cookie set by ULS as cache-relevant, on every request, one of the following two scenarios will happen: either the page will be served from the cache, in which case its content will be oblivious to the visitor's language preference, or (if the page is not in the cache) it will be cached with HTML specific to the visitor's language preference and then served to subsequent visitors, regardless of whether or not they have the same language preference set. This is what would happen if you simply set $wgULSAnonCanChangeLanguage to true (for any wiki other than testwiki) and took no further action. (Edit: it is what happened; see T43451.)

So, for this feature to work, we would need to configure Varnish to vary the cache based on the language preference. Increasing the number of variants that are cached for each page would increase the demand for memory on the Varnish hosts, causing Varnish to be more aggressive in evicting older cache entries, leading to a decrease in the cache hit-rate and a consequent increase in load on the application servers and in latency. It would represent a significant change to the WMF's site architecture, and it would require rigorous capacity planning, informed by metrics data from production and from experiments which simulate substantial load. Testing this by enabling it on test2wiki would be a bit like testing the capacity factor of the local power station by keeping your night-lamp on all night.

The description doesn't define whether the ultimate goal is to have this feature enabled in all Wikimedia wikis or only in the multilingual ones.

If the priority are the multilingual ones, we could start there. Somewhere we have data about how many anonymous users we have visiting mediawiki.org, Meta, Commons... The impact on server use caused by changing this configuration on i.e. mediawiki.org probably is a lot smaller than the big wikis. In fact, why not starting to test this change in mediawiki.org, being ready to revert if the change is problematic?

I started writing my response before Quim added a link to the thread on wikisource-l, so I did not know the context. It may be feasible to turn this on if it were scoped to wikisource.

Change 255953 abandoned by TTO:
Enable $wgULSAnonCanChangeLanguage on testwiki

Reason:

testwiki responses are not cached in varnish

Is that documented anywhere?

In any case, I don't think this is going to be very useful.

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

So suddenly this is again an operations request? ;)

Increasing the number of variants that are cached for each page would increase the demand for memory on the Varnish hosts

If it were just a matter of RAM, who can decide to buy more? :)

Storing page content and user chrome separately and combining them either on the client (as recently proposed in T106099: RFC: Page composition using service workers and server-side JS fall-back) on edge caching servers would be ideal, but it is at least two years away from full deployment on all platforms (in my estimation; others may disagree).

It may be feasible to turn this on if it were scoped to wikisource.

What is the difference in Wikisource? What does it take to start enabling language choice in Wikisource?

FWIW, excepting commons (for obvious reasons), most wikis where this feature would be desirable/necessary seem to me to be the smaller wikis and it's not immediately clear that the performance impact would be all that catastrophic if the caches did vary on a language selection cookie for them.

Use case for me is the Wikimania2017 wiki, where it is very important that visitors be able to switch to (at least) French for the interface and contents without having to register an account (and - in an ideal world - according to browser language prefs if only to originally set the cookie).

As a user spending some time translating help content on Wikidata, I would much prefer that new users could actually find the translated content.

It’s also kinda hard to promote Wikidata as a multilingual site, when it’s not so until you register.

This task not blocked by T58292: Make ULS more lightweight. ULS is already deployed to all users, just that some features are not enabled for anonymous.

Commons has its own custom language selector enabled for anonymous users. It also comes with a banner at the top advising the user to change their language, depending on their browser language:

After you choose a language other than English, ?uselang=foo is automatically added to the URL of any links you click.

(source code: https://commons.wikimedia.org/wiki/MediaWiki:AnonymousI18N.js)

And all page views with ?uselang= are uncached. So, at least for Commons, I think just enabling this (and making pages with the ULS cookie set not cached) would be just fine. This is already the case, I don't think we can do any worse. :)

In T58464#3131083, @matmarex wrote:

So, at least for Commons, I think just enabling this (and making pages with the ULS cookie set not cached) would be just fine.

Sounds reasonable, then we can remove the ja hack from commons.

The situation at Commons has been mostly discussed on the parent task T5665.