On Fri, Sep 26, 2014 at 4:58 AM, Wayne Ye <[email protected]> wrote: > I noticed on small defect here while I was testing my django website's > I18N/L10n, basically below are example Accept-Language headers sent by > Chrome and Firefox (all latest version): > > Chrome: Accept-Language: zh-TW,zh;q=0.8,en-US;q=0.6,en;q=0.4 > Firefox: Accept-Language: zh-tw,zh;q=0.8,en-us;q=0.5,en;q=0.3 > > You noticed that "zh-TW" and "zh-tw", according to the standard: w3c and > ietf rfc2616, the language tag(s) are lower-cased. > > But I've verified that Django will only correctly recognize Chrome's request > (i.e. treat end user prefers zh-tw), for Firefox example above, Django will > actually fallback to en-us/en. > > Could some fellow developers in this forum kindly triage this issue? Once > confirmed I will create a ticket in Trac and submit a pull request > accordingly, expecting any feedback on this.
I'd be very interested in learning about the scenario necessary to reproduce this. My reading of the code and tests make me think it's correclty handling these language names in a case insensitive manner when it comes to interpret users' user agent language preferences. Also, I've expanded test a bit to try to demonstrate this. See https://github.com/ramiro/django/compare/lang-tag-ordering?expand=1 On Fri, Sep 26, 2014 at 12:32 PM, Carl Meyer <[email protected]> wrote: > Here's the section of RFC 2616 that makes it explicit that language tags > should be treated as case insensitive: > http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.10 > > I haven't tested, but based on code inspection of > translation.get_language_from_request() and the functions it calls, it > appears to me that you are correct; Django is incorrectly handling > language tags as case-sensitive. See above. > > Ideally (ISTM) the pull request would be comprehensive in testing and > implementing case-insensitive locale-name handling throughout: i.e. not > just in handling the HTTP header, but also checking against > settings.LANGUAGES, etc. > > I wonder if this also has implications for checking whether a given > locale is present on the system. It looks to me like we also do this > case-sensitively right now, but we should do it case-insensitively. This > might be a bit of work, since it would mean that rather than just > checking for the existence of a particular locale directory as we do > now, we would need to read in all the available locale names into memory > (presuming we can't/don't want to enforce that all locales on disk are > lower-cased or whatever). The names of directories with translations on disk are actually GNU gettext locale names[1] as opposed to language names[1] (the ones in the Accept-Language HTTP header and discussed above.) It does specify that the part after the underscore separator must be a ISO 3166 country code. See [2] and [3]. So, for me, this indicates Django current behavior with these file system dir names is correct. But perhaps I'm missing something? Regards, 1. https://docs.djangoproject.com/en/dev/topics/i18n/#definitions 2. https://www.gnu.org/software/gettext/manual/html_node/Locale-Names.html 3. https://www.gnu.org/software/gettext/manual/html_node/Country-Codes.html#Country-Codes -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAO7PdF_Bm%2Btg-mkv38fGGjTCSuEAU6bNvQuo-UXxDwaVMpu87g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
