From Django Documentation:
If you define a custom
LANGUAGES
setting, it's OK to mark the languages as translation strings (as in the default value displayed above) -- but use a "dummy"gettext()
function, not the one indjango.utils.translation
. You should never importdjango.utils.translation
from within your settings file, because that module in itself depends on the settings, and that would cause a circular import. The solution is to use a "dummy"gettext()
function. Here's a sample settings file:
gettext = lambda s: s LANGUAGES = (
('de', gettext('German')),
('en', gettext('English')),
)
With this arrangement,
django-admin.py makemessages
will still find and mark these strings for translation, but the translation won't happen at runtime -- so you'll have to remember to wrap the languages in the realgettext()
in any code that usesLANGUAGES
at runtime.
What does it exactly mean to wrap languages in real gettext()
? How it should be called in the code?
Exactly what it says: call gettext() on the language names when you actually use them or show them to the user:
(You should generally use ugettext rather than gettext, since all text in Django is unicode.)
To do the equivalent in a template, just use the {% blocktrans %} tag, which just calls ugettext behind the scenes:
This is really a comment and further explanation on the above Q&A. I could not get my translations to work, read and re-read the docs, searched for hours online, and after reading this post I realized it came down to this:
I originally had:
Which would not work, then after reading this tried
Which made everything work... and I just searched for this and it is in the doc's at https://docs.djangoproject.com/en/1.4/topics/i18n/translation/#how-django-discovers-language-preference, toward the bottom of this section...
in Template you could just do the following:
According to the latest docs you can use
ugettext_lazy
in settings without causing circular imports: