CODEWITHSUNDEEP
djangoherokuinternationalization
user1802310
user1802310

Reputation: 126

i18n doesn't work at production environment on heroku

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 develop machine. But when I bring to heroku nothing happens. The files are not translated at all. It seems that the locale folder in my project is not being found.

Locale folder is at my project level and this is my settings:

BASE_PATH = os.path.dirname(os.path.abspath(__file__))

LANGUAGE_CODE = 'pt-br'

USE_I18N = True

USE_L10N = True

ugettext = lambda s: s
LANGUAGES = (
    ('en-us', ugettext('English')),
    ('pt-br', ugettext('Portuguese')),
)

LOCALE_PATHS = (
       os.path.join(BASE_PATH, "locale"),
)

Locale folder follows this structure:

locale
    pt_BR
        LC_MESAGES
            django.mo
            django.po

Upvotes: 8

Views: 3440

Answers (7)

mirek
mirek

Reputation: 1350

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),

Upvotes: 0

Dos
Dos

Reputation: 2507

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

Upvotes: 0

goose
goose

Reputation: 2652

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.

Upvotes: 0

Onur Ferhat
Onur Ferhat

Reputation: 59

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.

Upvotes: 4

Relaed
Relaed

Reputation: 56

First of all, your language settings are wrong.

It should be like:

LANGUAGES = (
    ('zh', 'China'),
    ('en', 'English'),
    ('ja', 'Japanese'),
)

Next, check if the domain in your cookie settings are correct.

I had the same problem and thought Heroku's virtual environment would never support i18n, but finally found out that my 'django-language' value in the session cookie belongs to my local testing server '0.0.0.0:5000'.

After changing the settings, my translations done on the local server worked out of the box.

Upvotes: 0

mkoistinen
mkoistinen

Reputation: 7773

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.

Upvotes: 6

tutuDajuju
tutuDajuju

Reputation: 10860

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

Upvotes: 3

Related Questions