2

Porting a Django site from 1.2 to 1.5 on Python 2.6 i ran into problems with internationalization.

The wierd thing is that only one string gets translated in the entire site (Well, almost, the date filter could translate long month names when I tested). Other strings located in the same template doesn't get translated, and all translations are located in a single po/mo file. All translations are there, verified with Poedit and compiled with manage.py compilemessages.

Edit: The reason for the single translated string was that it matched a string in the admin site.

While trying things to get it to work I cleared the LOCALE_PATH, restarted the dev server (manage.py runserver), cleared any browser cache (even though meta-data for the site disables cashing), lo and behold the element is still translated. I verified this by adding the same text again after, and it still gets translated, so no client side caching is involved.

Language switching works as expected and the only translated element is changed to the default language, {{ LANGUAGE_CODE }} confirms this. I've tried clearing the session data and django cache (which doesn't seem to be used by the dev server).

Can someone guess what's going on here? Isn't there any debug flags to get more extensive logging or something?

A minimal view:

def locale_test(request):
    locale = request.GET.get('l', None)
    if locale:
        translation.activate(locale)
    di = {"foobar": _("foobar")}
    return render_to_response('locale_test.html',di, context_instance=RequestContext(request))

And corresponding template (locale_test.html):

{% load i18n %}
<p>Language: {{ LANGUAGE_CODE }}</p>
<p>Matching string from admin site that gets translated correctly: {% trans "Log out" %}</p>
<p>Translated in template: {% trans "Foobar" %}</p>
<p>Translated in view: {{ foobar }}</p>

Relevant settings:

USE_I18N = True

USE_L10N = True

LANGUAGES = (
    ('en', 'English'),
    ('foo', 'Fooo'),
)

LANGUAGE_CODE = 'en'

MIDDLEWARE_CLASSES = (
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.locale.LocaleMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',

 )

 TEMPLATE_CONTEXT_PROCESSORS = (
      'django.contrib.auth.context_processors.auth',
      'django.core.context_processors.i18n',
      'django.core.context_processors.request',
     )
LOCALE_PATHS = ('/path/to/my/locale',)

For reference, these questions didn't help me:

Community
  • 1
  • 1
mandrake
  • 1,213
  • 1
  • 14
  • 28
  • could you perhaps share the template as well? – yuvi Aug 15 '13 at 10:24
  • The mystery of the single translated text was solved: It matched a string from the admin site. – mandrake Aug 15 '13 at 12:26
  • Had a look at [this page](https://docs.djangoproject.com/en/1.5/topics/i18n/translation/#how-django-discovers-translations)? – Adrián Aug 15 '13 at 12:28
  • "Deprecated since version 1.3: Lookup in the locale subdirectory of the directory containing your settings file (item 3 above) is deprecated since the 1.3 release and will be removed in Django 1.5. You can use the `LOCALE_PATHS` setting instead, by listing the absolute filesystem path of such locale directory in the setting value." Did you change that? – Adrián Aug 15 '13 at 12:30
  • I did, but not correctly (see answer). – mandrake Aug 15 '13 at 12:38

2 Answers2

3

Gah! I got bit by the same issue as this guy : https://code.djangoproject.com/ticket/18492

Namely that a trailing comma was missing in the LOCALE_PATHS tuple. Too bad Django doesn't raise an error for that.

mandrake
  • 1,213
  • 1
  • 14
  • 28
  • This just saved me from pulling out all my hair. Thank you! – Melissa Avery-Weir Jan 31 '14 at 22:03
  • This was helpful for me because I didn't even realise I had to manually set LOCALE_PATHS because I am using a single locale file for two or three core apps. +1 that django should raise an error if the value of LOCALE_PATHS is not a list or tuple. – fabspro Mar 03 '14 at 04:50
0

I had a similar issue that I resolved in making sure that whenever I update the django.po file, I compile it:

./manage.py compilemessages

The translation get done from the compiled file (django.mo) and not the .po file

  1. Generate the translation file: ./manage.py makemessages -a
  2. Translate: manually or using a tool like autotranslate
  3. compile the file: ./manage.py compilemessages
  4. Test to see the changes: not that the default language might be picked first, make sure that you change the language. For example change localhost:8000/en/ to localhost:8000/fr/ or localhost:8000/foo/ depending on the language you want to see

I hope this helps

Patrick
  • 1,091
  • 1
  • 14
  • 14