8

I have a Django app (on Google App Engine) that I wish to internationalize.

settings.py:

USE_I18N = True
LANGUAGE_CODE = 'en'

# Restrict supported languages (and JS media generation)
LANGUAGES = (
  ('en', 'English'),
  ('fr', 'French'),
)

MIDDLEWARE_CLASSES = (
  'ragendja.middleware.ErrorMiddleware',
  'django.contrib.sessions.middleware.SessionMiddleware',
  # i18n
  'django.middleware.locale.LocaleMiddleware',
  ...

I have generated .po and .mo files for my app in locale/fr/LC_MESSAGES (though not at the global level).

I set my browser Accept-Language heading to "fr" and Django ignores it. When I look at request.LANGUAGE_CODE it is always "en".

I can tell the browser is proper because I visit some other i18n-aware site and it returns French.

How do I find what Django thinks is missing about my setup?

I saw this question and it didn't help me.

I am running Django 1.0 using app engine patch 1.0.2.2 on Google App Engine.

Community
  • 1
  • 1
dfrankow
  • 20,191
  • 41
  • 152
  • 214

2 Answers2

7

There's a certain order that Django does things in terms of i18n.

First it checks LANGUAGE_CODE. It's the site-wide language and if nothing else is set, this is the language the user gets.

Second, since you've added the LocaleMiddleware, it checks if django_language is set in the user session. I would suggest clearing the session information in the DB or creating a completely new user to try with.

Third, it checks if there's a django_language cookie set (or, actually, the name of the cookie is defined by the LANGUAGE_COOKIE_NAME). I would suggest deleting this cookie.

Fourth, it looks for the Accept-Language HTTP header. Which is where your browser setting comes in.

Good luck!

lemonad
  • 4,148
  • 26
  • 27
  • I appreciate that explanation, but is there a way to tell which of those things is actually the one matching? I can do all the song and dance you've described and still not be sure what's causing the issue. – dfrankow Nov 03 '09 at 16:56
  • I assume you've cleared both sessions and cookies and it still doesn't work? I've never actually had to investigate it further since Django i18n has always worked nicely for me, at least with 1.0 and up. – lemonad Nov 03 '09 at 21:14
  • 8
    This is inaccurate: the `settings.LANGUAGE_CODE` is the last thing being checked: https://github.com/django/django/blob/stable/1.4.x/django/utils/translation/trans_real.py#L366 – Denilson Sá Maia Jun 04 '12 at 19:33
  • Thanks for the correction, Denilson. I definitely should have explained it based on the order of the code instead. If one just ignores the execution order, I think the explanation still holds though. – lemonad Sep 25 '12 at 17:22
3

Taken from this page, you can remove the HTTP_ACCEPT_LANGUAGE from the request and fall back on the LocaleMiddleware:

class ForceDefaultLanguageMiddleware(object):
    """
    Ignore Accept-Language HTTP headers

    This will force the I18N machinery to always choose settings.LANGUAGE_CODE
    as the default initial language, unless another one is set via sessions or cookies

    Should be installed *before* any middleware that checks request.META['HTTP_ACCEPT_LANGUAGE'],
    namely django.middleware.locale.LocaleMiddleware
    """

    def process_request(self, request):
        if request.META.has_key('HTTP_ACCEPT_LANGUAGE'):
            del request.META['HTTP_ACCEPT_LANGUAGE']
Nasir
  • 1,982
  • 4
  • 19
  • 35
  • 1
    I get this error: `'dict' object has no attribute 'has_key'` – Flimm Jan 23 '20 at 12:12
  • 1
    @Flimm Because it was not a dictionary back in that Django version. Replace with `if "HTTP_ACCEPT_LANGUAGE" in request.META:` – rolory Jun 22 '20 at 12:39