i18n doesn't work at production environment on heroku

Question

I have seen more than one hundred posts about i18n issues and no solution seems to solve my problem.

I have an app running with Django 1.3.1 and it works Fine at my

Answer 1

In the sample above you wrote LC_MESAGES instead of LC_MESSAGES (notice the double S), I believe this very well could be your issue.

If not then read on!

I had this issue (again!) recently, and the answer was found in this part of the django documentation

I suspect you have the same issue since your "admin" app was translated but not your own (project) app.

It seems that Django is looking for your translations like so:

1. The directories listed in LOCALE_PATHS have the highest precedence, with the ones appearing first having higher precedence than the ones appearing later.
2. Then, it looks for and uses if it exists a locale directory in each of the installed apps listed in INSTALLED_APPS. The ones appearing first have higher precedence than the ones appearing later.
3. Finally, the Django-provided base translation in django/conf/locale is used as a fallback.

With the settings you described above, you must make sure your tree looks something like this (with the most important being settings.py is in the dir above the 'locale' dir):

+-project_top/
  |
  +-project_app/
  | |
  | +-locale/
  | | |
  | | +-pt_BR/
  | |   |
  | |   +-LC_MESSAGES/
  | |     |
  | |     +-django.po
  | |  
  | +-settings.py
  |
  +-manage.py

Answer 2

I want to highlight a comment by @msaad above. If you're developing on Mac OS X and your translation directory is all lower case then change it from es_es -> es_ES and redeploy. This solved the problem for me. On OS X the system is case insensitive, but on linux systems it is not.

Answer 3

In some cases, directories with a "-" or "_" within the name are not correctly addressed. I solved the issue customizing the url to be be a 2-chars code. This can be done creating an alias:

from django.conf import global_settings, locale
EXTRA_LANG_INFO = {
    'pt': {
        'fallback': ['pt-br'],
    },
}
LANG_INFO = dict(locale.LANG_INFO, **EXTRA_LANG_INFO)
locale.LANG_INFO = LANG_INFO

Answer 4

I've found different platforms prefer different language folder names. I was pulling my hair out on my development system (Mac OS X) because '/pt-br/LC_MESSAGES/' wouldn't work, even though makemessages created the folders that way and compile messages worked fine too. It finally sprang to life once I renamed the languages as '/pt_br/LC_MESSAGES/' (notice the underscore).

Migrating the same project to production (Ubuntu), it stopped working again, I tried everything under the Sun thinking the folder names must already be correct since they work on my dev. machine. I finally, out of desperation tried uppercasing the country component like '/pt_BR/LC_MESSAGES/', and, boom, it started working again.

Even thought my Python and Django and all of my various Python/Django libraries and apps were (by design) identical versions, I suspect that each system has different versions/builds of gettext beneath them, which is likely responsible for the differences.

Answer 5

By default, compiled translation files (*.mo) are ignored by git. Verify that you have this exception removed from your .gitignore file.

If that is the case, remove this exception, add these files to git, commit and push to Heroku to have them available to the app in Heroku.

Answer 6

I don't answer related to Heroku, but just to have most possibilities collected:

I have Debian 10 development and Debian 10 virtual server in production. Everything was ok in development, i18n failed in production.

Reason: I needed apt install gettext.

And in addition, be sure that .mo files are in git and not disabled by .gitignore (this answer is here already),