Play this article
A while back I wrote a post about Django translation and getting your websites to be translated. Since then it has been pretty successful in our development version of the site and I have continued to learn the quirks of Django translation. A couple of things to note:
- In your .po files you will occasionally see that some of your strings have a
#, fuzzytag above them. This means that there is already a translation found elsewhere and it's not sure if it should use your translation file in this app or the other one it knows about. I had a lot of issues with this so I have been removing the fuzzy tag entirely when I find it and this forces Django to use the translation file as is.
- Ordering matters in INSTALLED_APPS. Django will load translation files in order of your INSTALLED_APPS list. Django has a set of built in translated strings that it will use first before using your translations. I found this was causing an issue when I didn't like the translation used for the Chinese version of Email. Django's version was four characters long and the one I was using would only be two. I had to rearrange my INSTALLED_APPS to load my translation files first before the Django ones. Although, now that I think about it, this may be caused by fuzzy tags...I'll look into this.
sudo apt-get install gettext- This is what Django uses to figure out translation and must be installed.
USE_I18N = Truein settings.py. Ours was but it's good to check.
django.middleware.locale.LocaleMiddlewaremust be listed in your
MIDDLEWARE_CLASSES- This is the kicker that took me a while to figure out. Since it took me a long time to get this working on my dev server I didn't write down all of the steps, hence this post. This will not throw errors to your log files either so double-check.
- Update your project
url(r'^i18n/', include('django.conf.urls.i18n'))- This is what Django uses to set the language of the user and is necessary for URL calls to change it.