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: WikiEducationFoundation/WikiEduDashboard@cea14bc

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?

[dgpokl]

Sorry to resurrect an old thread but I'm just wondering, is the buggy behavior you're describing @KelseyDH @recipedude seen only with preferred_language_from? The docs say that there's this far more useful-sounding method:

language_region_compatible_from(languages): Returns the first of the user preferred languages that is also found in available languages. Finds best fit by matching on primary language first and secondarily on region. If no matching region is found, return the first language in the group matching that primary language.

When it comes to preferred_language_from... I don't even see the point in using a library to do the job of "pick the first one in [LIST] that happens to have the same first two letters as a value in [OTHER LIST]", as that method is advertised to do.

[KelseyDH]

@dgpokl Sorry I'm no longer working on that project, and I think this gem got removed from the project any way. I suspect it was the default method though.

If you are going to use this gem and regional variances matter (they will if you support Chinese), I would recommend verifying carefully that something like en-us resolves correctly to en-us if you have it, rather than en-gb if you have it over en. It's a bit tricky to test as it depends on what regional variances your app will have available to pull from.