Here's one prototype: https://people.wikimedia.org/~jgirault/

The idea is to read user's preferred languages,

• try to find these languages in the top10 and move the nodes to the first positions.
• if language is not in top10 but we know an existing wiki for this language, we remove the 10th top wiki and build a new node (with stats and defs) that goes to the first position.

User's preferred languages is read from navigator.languages
Because it's not supported by all browsers, I also read as many fallbacks as I can:

navigator.language
navigator.userLanguage
navigator.browserLanguage
navigator.systemLanguage

(Right now it's not optimized, but anyway manipulating the dom takes some time. It's the issue of doing it client-side. We can do the same little trick as the a/b test but it still slows down by a few ms the full page load.)

Play with it. What do you think?

As long as the DOM manipulations happen onReady or DOMContentLoaded, they at least won't block loading the page in the first place, right?

We can also hardcode a hidden placeholder div for the detected language, so that it just needs to be populated but not built from scratch. The CSS for the top 10 can be refactored to automatically position based on nth-of selectors.

(I'm reading this on my phone, so apologies for the spam if this is already implemented in the prototype.)

Is navigator.languages etc the JS read of accept_languages?

to @mxn:
Yes, the trick is to temporarily hide/set a placeholder while JS is loading. I haven't done it in the prototype.

to @Ironholds: Yes
https://developer.mozilla.org/en-US/docs/Web/API/NavigatorLanguage/languages

The Accept-Language HTTP header in every HTTP request from the user's browser uses the same value for the navigator.languages property except for the extra qvalues (quality values) field (e.g. en-US;q=0.8).

Gotcha! And we can only access that sometimes? I thought it was sent with every request.

The spike realized T120866 showed interesting results.
Finding the smaller wikis amongst the hundreds of links of the bottom of the page is too painful. Giving more visibility to the wikis that match user's (navigator) preferred languages seem to make sense as a user standpoint.

I created T121843 as a follow-up to discuss one of the decisions we need to make around this.

Closing this ticket as done - further discussion will be done on [[ URL | T121843 ]]