[lazerlapin]

He's missing the why they're doing this.

Tons of websites are server-rendered, which means the decision of which language to show has to be made upfront: at the time of the first HTTP request, so before sending the page to the user. And we don't know the user's language preferences until we reach the browser and can execute some JavaScript. If we do as he suggest, it would paradoxically lead to the very behavior he is criticizing in the post: page loads default (e.g english), (then reads user preferences with JS, e.g german), then reloads to show german instead.

So why pre-populating the page with the langage the users in that particular country are most likely to wanna use a bad 'default'? Would it be worth it to rather worsen their experience by forcing all german users to load english first, and then repaint the page with german?

I think only SPAs could afford to implement the whole thing based on user local preferences without major UX drawbacks.

[marticode]

> we don't know the user's language preferences until we reach the browser and can execute some JavaScript

This is untrue: the HTTP "Accept-Language" header tells the server what language the browser wants to get, right before any request get served. There is no need for Javascript.

[lazerlapin]

Alright, fair enough

[robjan]

Your browser sends an accept-language request header so JavaScript isn't needed to determine the wanted language.

My browser sends "en-GB" in this header but Google always defaults to Chinese because I am using a Hong Kong IP.