Almanac.httparchive.org: Consider users' Accept-Language preference when selecting the default language

[MSakamaki]

When users first visit, I think that it will be a good experience for the user to be not conscious of language selection.

To do this, need to check the Accept-Language header sent by the client and route it to the appropriate language.
(Must be careful not to work with redirects after being selected by the switcher)

This needs to be addressed after #50.

[rviscomi]

Yes! Looking at the Accept-Language docs:

The Accept-Language request HTTP header advertises which languages the client is able to understand, and which locale variant is preferred. (By languages, we mean natural languages, such as English, and not programming languages.) Using content negotiation, the server then selects one of the proposals, uses it and informs the client of its choice with the Content-Language response header. Browsers set adequate values for this header according to their user interface language and even if a user can change it, this happens rarely (and is frowned upon as it leads to fingerprinting).

This header is a hint to be used when the server has no way of determining the language via another way, like a specific URL, that is controlled by an explicit user decision. It is recommended that the server never overrides an explicit decision. The content of the Accept-Language is often out of the control of the user (like when traveling and using an Internet Cafe in a different country); the user may also want to visit a page in another language than the locale of their user interface.

So we should only consider the Accept-Language request header for non *_i18n router methods, like the index router method for the root page, /. If we recognize and support the language, we will return the contents in that language using the corresponding *_i18n method. If for example, someone has Accept-Language: ja-JP, we will recognize that the user prefers Japanese and route their / request to the index_i18n handler for lang=ja.

Alternatively, we might want to force a redirect to the /ja/ URL. Otherwise I'm not sure what the caching behavior would be with a single URL that can appear in multiple languages depending on the user's request headers. Open to other ideas and curious to hear if anyone has experienced this before.

Not quite sure what the docs are getting at regarding fingerprinting, but it sounds like we also want to return the Content-Language response header for every *_i18n router method.

[MSakamaki]

So we should only consider the Accept-Language request header for non *_i18n router methods, like the index router method for the root page, /.

I agree with this solution!
I think that implicit routing to language is sufficient only if the URL does not include language code.

Content-Language

my experience it was common case to set it to only language-aware document/image

[mikegeyser]

I believe that PR #49 addressed this, would you mind having a look @MSakamaki and let me know if it's sufficient?

[MSakamaki]

@mikegeyser Great!
I got the latest and confirmed the operation, which can be viewed in Japanese on all my browsers.
Thank you!

[rviscomi]

We still haven't implemented Content-Language but not sure if that's still needed. @MSakamaki could we close this issue or would you still like to see that added?

[MSakamaki]

@rviscomi
I'm sorry for the late reply
Yes, there is no problem closing this issues.

I examined Content-Language in deep.
This content I did not feel necessary because it was not highly interactive between the client and the server.

References

https://www.w3.org/TR/UNDERSTANDING-WCAG20/meaning-doc-lang-id.html

SVR5: Specifying the default language in the HTTP header (SERVER)