Hello Wayne, On 09/26/2014 01:58 AM, Wayne Ye 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 > <http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.4>and ietf > rfc2616 <http://tools.ietf.org/html/rfc2616#page-104>, 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.
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. If you'd be willing to file a bug and submit a pull request, that would be great. 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). (I'm not the most i18n-experienced member of the core team by far, so hopefully if I'm totally off-track here someone will weigh in to correct me.) Carl -- 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/54258718.1090304%40oddbird.net. For more options, visit https://groups.google.com/d/optout.
