Introduce a language preference/cookie to prevent site redirections

RESOLVED FIXED

Status

developer.mozilla.org
Localization
--
enhancement
RESOLVED FIXED
a year ago
a month ago

People

(Reporter: el8, Unassigned)

Tracking

({in-triage})

Details

(Reporter)

Description

a year ago
User Agent: Mozilla/5.0 (Windows NT 6.0; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20161208153507

Steps to reproduce:

I'm using Firefox and have the "intl.accept_languages" preference set to "ru-ru, ru, en-us, en", so the browser sends the "Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3" header (I speak Russian and visit a lot Russian sites).

The problem is because of the header developer.mozilla.org redirects me to its Russian versions, but it's better to read web-related documentation in English, besides, many articles in Russian are outdated.

So it would be useful to have a preference for registered users (or a cookie for all) that would prevent such redirections.
(Reporter)

Updated

a year ago
Severity: normal → enhancement
(Reporter)

Comment 1

a year ago
An example of such redirection: on opening the CSS pane of Page Inspector, switching to Computed View and clicking a CSS property (let it be "background-color", for example), Firefox opens the "https://developer.mozilla.org/ru/CSS/background-color" page (which yields a 404 error, but that's another issue). If I had "intl.accept_languages" set to "en-US, en", https://developer.mozilla.org/en-US/docs/Web/CSS/background-color would have been opened.
(Reporter)

Comment 2

a year ago
> clicking a CSS property
..and pressing F1, sorry.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: in-triage
After some discussion, staff thinks this UI would work:

1) If the URL contains a locale, the URL wins
1) If the URL is a generic URL, use the browser's Accept-Languages header as the first guess at the user's locale preference.
2) If the user uses the language switcher, save that language in a cookie or in the session as the user's new locale preference.
So, if it's a generic URL, and the user has used the language switcher to select a different locale than what's specified in the accept-languages header, the selected language wins?
Sorry, if that was unclear. The algorithm is:

1) If the URL contains a locale, the URL wins
2) If the URL is a generic URL:
   - If the visitor has ever used the language switcher, use the last language they selected.
   - If the visitor has never used the language switcher, use the browser's Accept-Languages header to pick the language

The experience of many users will continue to be their browser's Accept-Languages header, because search engines will use it to present the language-specific links on MDN, and, because the URL locale wins, that it the one they will see.  An exception will be these links from the page inspector, which are usually the generic URLs.

Updated

11 months ago
Duplicate of this bug: 1368612
Depends on: 1385315
bug 1385315 is added as a blocker, to make page redirects 302 Found vs 301 Moved Permanently.  I believe we should exclude the homepage from this new algorithm, because it would risky to reduce the signal that https://developer.mozilla.org/en-US/ is the canonical homepage, and it's 1% of the traffic that we don't want to make slower or involve the Django backend in each request.

I think there should be an explicit POST to create this cookie.  We'd notice that the user just used the language picker, and ask them if they'd prefer that language.  Clicking "yes" would add the cookie. I am concerned that a search crawler will follow the language switcher with a GET and index non-English pages.

To be clear, this will not make the target audience happy. They want to browse the web in their native language, and MDN in English. Why? Maybe they are more comfortable in English for technical docs. Maybe the translation is out of date and the English is always up-to-date. Maybe the translation is mix of out-of-date translations and English anyway. This change will not change any of this.  It will only change the behaviour when they visit a link without a locale embedded in it, which is not the one from a search engine.

A better solution would be an Extension [1] that redirects the client to the English version of a page. This would cover the use case of following a link from a search engine as well.

[1] https://wiki.mozilla.org/Add-ons/Terminology

Comment 8

9 months ago
I don't see an issue with excluding the home page.

Would that dialog be shown more than once?

The solution here would solve the problem of the OP, on the other hand: that specific problem doesn't exist anymore, that feature was apparently removed from Firefox in the last few month.

All in all, this doesn't look like a small fix to me, and the original problem is moot. I think we should stop here.
The CSS reference links to MDN were hard to discover and have been removed. However, the developer tools still links to MDN for error messages, using the generic URLs, so there is still an issue.

:safwanrahman has proposed a solution from kitsune in mozilla/kuma#4321. It looks for a language in the request and stores that in a cookie as the user's preferred language.  I'm concerned about scrapers picking up a language cookie during scraping, but I can research the history of this code and the SEO on Kitsune.
Duplicate of this bug: 1400172
Duplicate of this bug: 1402395
See Also: → bug 1403135
Duplicate of this bug: 1411902
Duplicate of this bug: 1430481

Comment 14

3 months ago
Commit pushed to master at https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/7fc6e17fde515b1c73802068bd843c3455537de5
[Bug 1331729] Language preference cookie to stop site redirection (#4321)

* [Bug 1331729] Language preference cookie to stop site redirection

* Fixup the frontend things

* fixup according to comments

* adding never button
See Also: → bug 1432826
This cookie has been implemented for several months. Some people want a stronger preference, to be automatically redirected to the English page. I'm using bug 1432826 for a proposal for an extension, and bug 1440602 for the feature request without a technical solution.
Status: NEW → RESOLVED
Last Resolved: a month ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.