Detect user's preferred language from Accept-Language header and switch to that language if available

[strophy]

Read The Docs should check the Accept-Language header in the user's http request and attempt to display a localized version of the documentation, if a matching language is available. This would ideally be paired with an implementation of a language switcher as described in readthedocs/addons#250 so an override cookie could be set if the user manually selects a language.

As mentioned in readthedocs/addons#250 I am prepared to pay a bounty for this work, or alternatively have already sourced a willing developer who can fork the appropriate repository. Also, it seems that readthedocs.org itself already implements language detection and a language switcher, could this be recycled? Thanks guys!

[agjohnson]

This is more closely represents an operations issue, so paying a third party won't really help us get this implemented. It's not quite on our roadmap, though I have been pushing to focus on more i18n support, so I'm generally 👍 on an improvement like this in the short term.

We have a few issues open already regarding similar changes (some in our private operations provisioning), but to summarize what redirects we are looking at:

• User requested /, redirect to /<default language>/<version> if no accept language header, or /<accept language header code>/<version> if there is a header. This change is relatively easy and we have an issue already tracking this internally.
• User request /en/latest/something. Can we redirect? What if a user wants /en/latest/something, we can't cover this use case and reliably redirect to the language code from accept languages -- these are at odds. This one requires storing something in session perhaps, yes.

[agjohnson]

Also, note that none of these changes happen in this code base, so I'll likely close this issue. We're tracking work internally though.

[strophy]

Just came across this reference from Google relating to best practices for multilingual versions of pages in order to ensure proper indexing. In short, Accept-Language should trigger a popup allowing the user to redirect to a localized version, but this should not necessary happen automatically. I believe adobe.com follows this practice, for example.

https://support.google.com/webmasters/answer/182192

[AustinShalit]

@agjohnson Hi! I just wanted to see if anything ever happened with the first change you suggested (looking at the accept language header).

[agjohnson]

I'm going to reopen this one, as we were tracking changing this at our infrastructure level, but since 2018, we moved much of this handling away from Nginx and back into our application.

I'd still like to see this done, but haven't quite lined up figures for how beneficial this is to readers overall.

I can say that ~50% of our traffic is en-us or en-gb, zh-cn is about 10% of traffic, and then drops off after that. ru-ru, fr-fr, ja, es-es, de-de locales are all >2% of our traffic. The big question is how much this overlaps with major projects with multiple translations though.

This will be somewhere on our backlog for now, we aren't focusing heavily on i18n efforts currently. But if someone wants to try this out, the code is relatively isolated and moderately easy to test as well:

https://github.com/readthedocs/readthedocs.org/blob/main/readthedocs/proxito/views/serve.py

[agjohnson]

Also, thinking about this more, this is maybe a good case for a redirect rule type perhaps? I could see how this would maybe be easiest as a Proxito resolver addition though.

A redirect rule would avoid the trouble we'd have implementing this at a broad level, across all projects. Projects could opt in to the redirect rule if they need/want.

A couple of constraints/issues I sense with this approach:

• The rule needs to support a fallback mechanism when the accept language locale doesn't exist. This might be easier as an explicit redirect for each language?
• Redirect rules wouldn't be shared across translations