Some strings not translated in django i18n module

Question

I have some strange troubles with django's internationalization module. Most of strings are translated as they must be and some other aren't. Let me show you and example:

<li>{% trans "Upload Score" %}</li>
<li>{% trans "Profile" %}</li>
<li>{% trans "Invite friends" %}</li>
<li>{% trans "Settings" %}</li>

I have a list of 4 items for a menu. I run the django command makemessages to translate the site in french and I get everything as expected:

#: templates/main.html:190 templates/main.html.py:195
#, fuzzy
msgid "Upload Score"
msgstr "Publier"

#: templates/main.html:191 templates/main.html.py:196
msgid "Profile"
msgstr "Profil"

#: templates/main.html:192 templates/main.html.py:197
#, fuzzy
msgid "Invite Friends"
msgstr "inviter vos amis"

#: templates/main.html:193 templates/main.html.py:198
msgid "Settings"
msgstr "Préférences"

But when I compile it, will django-admin compilemessages, only "Profile" and "Settings" are translated. Do you know where it could come from? Could it be linked to the use of white spaces? Is there a debug mode in the i18n module?

Thanks for you help! :)

EDIT: We are on django 1.4.

Answer 1

You need to remove fuzzy lines.

Fuzzy probably means that the original string have been changed. Gettext don't want to lose your translations so it will change it but mark it fuzzy.

I recomend you rosetta. It will create you admin like interface where you can translate strings and manage fuzzy.

Cheers

Answer 2

I had the exact same symptom, I simply forgot to add the LOCALE_PATHS settings and Django was using some default translation strings for some of my strings, and not reaching my custom developed messages files.

Adding this setting solved the problem:

LOCALE_PATHS = (
    PROJECT_DIR.child('locale'),  # assuming PROJECT_DIR is set to project root (using unipath)
)

Answer 3

In my case it was that the directory holding my LC_MESSAGES directory was named after the language code I wanted (e.g. en-us) rather than the locale (en_US). Renaming it to locale format fixed things.