Locale-less URLs cause redirection to URL for ja/Japanese-localized article

[sideshowbarker]

In my Chrome or Firefox, when I open https://developer.mozilla.org/docs/Web/MathML/Element/mover or other locale-less URL, I get re-directed to https://developer.mozilla.org/ja/docs/Web/MathML/Element/mover (the ja-localized version of the doc).

And that’s in spite of the request not having an request headers that indicate a preference for Japanese:

Accept-Language: en-US,en;q=0.5 (in Firefox)
Accept-Language: en-US,en;q=0.9 (in Chrome)

So is the development server maybe doing some kind of content negotiation based on a reverse lookup of my IP address?

It’s interesting that I don’t see this behavior in Safari. In Safari I get redirected to https://developer.mozilla.org/en-US/docs/Web/MathML/Element/mover (en-US) as expected. Maybe that’s due to Safari having a simpler Accept-Language header?

Accept-Language: en-us (in Safari)

[Ryuno-Ki]

Could it be related to https://github.com/mdn/yari/issues/128 - as in: do you have a cookie set to indicate Japanese preference?

[sideshowbarker]

Could it be related to #128 - as in: do you have a cookie set to indicate Japanese preference?

Indeed yes, thanks — I find now that there was a preferredlocale cookie set to ja in both Chrome and Firefox. After deleting that cookie, I get redirected to the en-US article as expected

[peterbe]

That's interesting. Interesting that someone as organized and mindful could forget about having set a cookie. Perhaps you're an odd case because you test a lot of stuff as part of your work. But the reason you have the cookie is because, at some point, you used the little language switching dropdown and opted over to Japanese. It's not very obvious that that'll set a cookie on you.

The other interesting use case is when someone who generally prefers, say, French is reading a French article and thinks to herself, "Right now, I'm going to switch to read THIS article in English" but does not realize the cookie getting set and now any time she stumbles into a URL (e.g. VSCode tool tips) that doesn't have the locale hardcoded, she's "stuck" in English.

I guess every UX functionality has some pros and some cons. We can't cover every single possible case if we try to introduce the slightest bit of convenience.

[ghost]

I have the feeling that that cookie must be removed. You should really not use cookies in the world, perhaps this way you would avoid those annoying banner where you have to accept them. It is not that remembering user preferences is then a great value, especially if no one has asked for it

[sideshowbarker]

But the reason you have the cookie is because, at some point, you used the little language switching dropdown and opted over to Japanese. It's not very obvious that that'll set a cookie on you.

Yeah that must have been what happened — because I do in fact read the Japanese versions, and have reviewed some in the past. So I guess I just used that menu as some time in the past. And I never ran noticed a problem with it til now, because we always use the localized en-US URLs.

But the reason I did notice it yesterday is that for BCD, we use the locale-less URLs in our mdn_url values. And I never really have need to open those URLs in a browser manually, and we don’t link to them anywhere else, so I never have occasion to click on them. But yesterday I had a failure in one of the scripts I use for some BCD stuff, and then script emitted an error message which cited an mdn_url value. So I clicked on that URL, and then that’s why I noticed the behavior I mentioned.