Closed
Bug 1440602
Opened 7 years ago
Closed 4 years ago
Always view documentation pages in user selected language
Categories
(developer.mozilla.org Graveyard :: Localization, defect, P3)
developer.mozilla.org Graveyard
Localization
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: daniel, Unassigned)
References
Details
(Keywords: in-triage, Whiteboard: [specification][type:bug][points=6+])
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.167 Safari/537.36
Steps to reproduce:
1. open a web documentation page in a specific locale
https://developer.mozilla.org/es/docs/Web/JavaScript/Referencia/Objetos_globales/Array/fill
2. change language to "english"
3. select YES when asked "You are now viewing this site in English (US) (en-US). Do you always want to view this site in English (US) (en-US)?"
Actual results:
On opening the page again it reads in locale "es" again, although the cookie of "django_language" is set to "en-US"
Expected results:
I would expect the "developer.mozilla.org" server to detect the "django_language" cookie and do a (maybe 303) redirect to the url with the preferred locale set by the user in case it is present.
Comment 2•7 years ago
|
||
daniel, I'm sorry, this can be very frustrating.
The language preference is used when a URL without a locale is visited, such as:
https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Array/fill
The "no-locale" URL is the English URL, without '/en-US' in the middle.
The language preference only addresses some of the cases when a user's Accept-Language setting doesn't match their preferred language for viewing MDN. Some other cases are:
- Google search results show translated URLs for the user. The user can tell Google what language they prefer.
- Users follow links from a web page, such as Stack Overflow or a Bugzilla report. The locale baked into the URL is used, and the visitor has to use the language selector to switch.
I don't believe all of these cases can be handled by the website. An alternate idea of a user-configured extension is on bug 1432826.
Status: UNCONFIRMED → NEW
Ever confirmed: true
John, thanks for the reply.
Found some other reports related to this redirect logic and saw the dices already been rolled - in this case against the mentioned UX.
Indeed, one is Yours from last year https://bugzilla.mozilla.org/show_bug.cgi?id=926963#c10
I couldn't find the other one explaining the final default locale handling logic though, but if i'm remembering it right it was "URL overriding everything else" in the first place.
The use-case of mine is exactly the one You described 'Google search results...' - and yes, "very frustrating" is an understatement.
So it seems that this report is just another opinion late to the game (user set preference over anything else, a.k.a. UX for the win).
Feel free to close this bug.
Comment 4•7 years ago
|
||
You are not the only person who wishes locales worked differently (and everyone seems to prefer English). I'm going to leave the bug open for now, so that I can point people at this issue, and duplicate bugs to it.
Summary: view documentation pages in user selected language → Always view documentation pages in user selected language
Updated•6 years ago
|
Comment 9•4 years ago
|
||
MDN Web Docs' bug reporting has now moved to GitHub. From now on, please file content bugs at https://github.com/mdn/sprints/issues/ and platform bugs at https://github.com/mdn/kuma/issues/.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
Updated•4 years ago
|
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•