Since the previous bugs I was thinking would address this issue were closed (T35677#382858 and T44186#474966) I'm opening one specifically about the request to allow interface language section by unregistered users (fix T5665) via UniversalLanguageSelector.
== Context ==
On our biggest multilingual wikis, Commons and Wikidata, the (monolingual) cache gets bypassed by using a gadget which makes everyone use the `uselang` URL parameter. Hence, as discussed in T114662, there are no significant performance problems with making the cache more permissive.
Using Commons' AnonymousI18N.js globally is not feasible until we can have central gadgets to deploy it ({T31272}).
Such a feature would help e.g. on this discussion [[https://pt.wikipedia.org/wiki/Wikip%C3%A9dia:Esplanada/propostas/Uso_do_portugu%C3%AAs_de_Portugal,_pt-PT_%284mar2012%29|w:pt:Wikipédia:Esplanada/propostas/Uso do português de Portugal, pt-PT (4mar2012)]]
== The problem ==
Interface language selection is only available to registered, logged-in users on Wikimedia projects. This is especially problem for multilingual projects including Wikisource, Wikidata and Commons.
Some wikis use workarounds to simulate this feature, but those do not scale and increase our technical debt.
Language selection (both manual and automatic) has been implemented in #mediawiki-extensions-universallanguageselector and is already in use (both registered and unregistered) by many third party wikis, given it is enabled by default.
This issue has been discussed before, but due to unclear status of ownership (language? editing? reading?) and unclear status of blockers has stalled it. The main issue seems to be making some trade-offs to work within the current caching infrastructure.
There are two directions that allow gradually going towards the ideal end state.
By functionality:
* Enable manual language selection
* Enable automatic language selection
By scope:
* Enable for multilingual wikis
* Enable for all wikis
== Draft proposal ==
# Add support for varying caches by value of `language` cookie.
# Enable manual language selection for multilingual wikis
# Evaluate feasibility of extending based on increase in resource usage and discuss again
The way forward from here could be
# Stop expanding
# Expand to non-multilingual wikis
# Try out automatic language selection on a small multilingual wiki [1]
[1] Possibly using using a different approach than reading the `Accept-Languages` request header in PHP side. For example using JavaScript to suggest a language change if we are confident, that would then set the language cookie and work like manual language selection.
----
**See Also**:
{T44186}
{T3135}