Does not work with traditonal vs simplified Chinese

[ragesoss]

The way that this gem throws out everything after a dash means that it is broken for Chinese locales. Typically, the languages codes are zh-hant, zh-hans, zh-CN, zh-TW, etc.

With the default methods, this gem always serves the first zh available zh variant. But almost any internationalized site that supports Chinese will have two or more variants, and getting simplified Chinese when you read traditional Chinese is not a usable situation.

Here's how I worked around it in my app: https://github.com/WikiEducationFoundation/WikiEduDashboard/commit/cea14bce1d0818d93d5a9e0a10f52becbef3c98b

I suggest that this gem would be a much more robust solution if it followed the RFC spec, rather than the current behavior described in the readme.

[bsiegel]

I have a fork here that has implemented fallback for Chinese languages: https://github.com/mobiledefense/http_accept_language

Information about the algorithm used to select the appropriate locale is in the README.md

[recipedude]

This is also an issue with English.

config.i18n.available_locales = %w(en en-CA en-AU en-GB zh-CN fr es)

The gem seems to return en no matter what variety of English the end-user browser is requesting (in this case US English) for Canadians, Aussies, Brits as well.

[gommo]

Yeah pretty weird that it was implemented the way it is

[KelseyDH]

I can no longer recommend this gem for any project unless this behaviour gets fixed. Either with a new method that preserves regional variance or by updating the existing method to return the correct region. To not break current (buggy) behaviour, I suspect adding a new method that preserves regional variance might be better, given it could cause problems if the currently buggy behaviour of apps receiving browser headers asking for en-gb being pointed to en... suddenly starting having those locales pointed to missing or incomplete en-gb files.

[arianf]

What gem is everyone else using if not this one?