Hi Wayne, On Mon, Sep 29, 2014 at 5:27 AM, Wayne Ye <[email protected]> wrote: > > Per official I18n wiki: > https://docs.djangoproject.com/en/1.4/topics/i18n/translation/#using-translations-outside-views-and-templates > > I was using *translation.get_language()* method to retrieve the client > preferred language: > > class IndexView(generic.TemplateView): > def get(self, request): > cur_language = translation.get_language() > print('='*50) > print('Current locale: ' + cur_language) > print('='*50) > return render(request, 'myapp/index.html', {}, > context_instance=RequestContext(request)) > > By hitting view above I noticed that django actually does not correctly > recognise all lower-cased language tag (such as zh-cn), I did change your > testing code a little bit to below and it will fail: > > r.META = {'HTTP_ACCEPT_LANGUAGE': > 'zh-TW,zh;q=0.8,en-US;q=0.6,en;q=0.4'} > self.assertEqual('zh-tw', g(r)) > self.assertEqual('zh-tw', get_language()) > r.META = {'HTTP_ACCEPT_LANGUAGE': > 'zh-tw,zh;q=0.8,en-us;q=0.5,en;q=0.3'} > self.assertEqual('zh-tw', g(r)) > self.assertEqual('zh-tw', get_language()) > > So I am thinking will it be better to use get_language_from_request() > instead of get_language(), i.e.: > cur_language = translation.get_language_from_request(request) > >
As Ramiro said, Django uses a different naming scheme for "language names" (GNU way) than what the Accept-Language header uses (BCP-47). The function get_language() can only be used to get the *already activated* language (based on Django's names) and not read it from the Accept-Language header. The steps to do this manually would be something like: lang = guess_language() // call get_language_from_request activate_language(lang) // sets the active language for Django print get_language() // prints that language. In the tests above, g(r) has not activated any "language" in django for get_language() to work. Can you double-check you have followed all steps at [1]? I hope this helps, Apostolis [1]: https://docs.djangoproject.com/en/dev/topics/i18n/translation/#how-django-discovers-language-preference > By doing this I don't see any issues. BTW, I was using both Django 1.4.15 > LTS and edge 1.7. > > Sincerely yours, > Wayne > > On Saturday, September 27, 2014 8:14:18 PM UTC+8, Ramiro Morales wrote: >> >> 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/32345674-3256-4204-91ac-66bfc5869213%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/32345674-3256-4204-91ac-66bfc5869213%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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/CAEa3b%2BqDOOMCz8-f%2B-bzOkx_aNpEaE-ru1Fnf5Jjg1VsvWtuMg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
