Ian's Blog

Avatar

A RESTful Blog/Homepage.

i18n tip for django

"Django's":http://www.djangoproject.com "Internationalization":http://www.djangoproject.com/documentation/i18n/ support is freaking awesome. and it is so easy to use it isn't funny. Django's i18n support is based on the brower sending a accept-language, or having the server set a cookie to handle the user preference. I was in the middle of porting a legacy app for a client which didn't work the way the designers of i18n had thought of.. they set the language in the URL itself for the request. (ie /challenge/spanish/signup.html was the spanish version of the page and /challenge/english/signup.html was the english version) . now..this presented 2 problems. first 'english/spanish' are not language codes, and more importantly I wanted the server to render the page it was asked for in the language specified.. (it couldn't trust the cookie in this instance). so.. an easy solution at the top of each view I added a call to 'setlang'

def setlang(request, language ):
    if language == 'english':
        translation.activate('en')
        request.LANGUAGE_CODE = translation.get_language()
        request.session['django_language'] = 'en'
    elif language == 'spanish':
        translation.activate('es')
        request.LANGUAGE_CODE = translation.get_language()
        request.session['django_language'] = 'es'
this also had the effect of not requiring *every* page to have the language code in the URL (we forgot some), as we can assume the user will be entering into the site via a language-encoded landing page first. now this code isn't 'beautiful' and is a bit hackish. but it met the needs of my client, and like most projects i18n was left to the end when we were had zero time.. It also has the benefit of keeping the english and spanish separate in the URL space, so google and other bots will find (and index) both languages. other tips for i18n work (coming from a first-timer after reading the docs): * fix up the content-type in the .po file when you initially generate it. by default it puts in 'CHARSET'. I just copied what the default django locale had and it seems ok. * remember to restart your server after you recompile the languages (thanks FunkyBob from IRC) * MS word is evil. it puts in funny UTF characters instead of a regular "'". gettext doesn't like them, and you will need to find all of them and replace them with ascii characters. (this took the longest time for me) * DOS-format files don't work with gettext.. gettext expects lines to be ended with a simple '\n' not '\r\n' * Don't put ALL the text in the blocktrans section in the template. just a keyword will suffice, instead of the 5-block english copy. I wish I knew this *before* hand. as the templates have large english blurbs in them which have to be taken out and put into the .po file. eg.

{% blocktrans %}welcometext{% endblocktrans %} 
instead of

{% blocktrans %}Welcome to the new and improved version of FOO BAR.... {% endblocktrans %}
and the stuff inside the blocktrans is the actual key inside the .po file. and this will confusing as HTML editors fix up typos in the HTML and forget to update the .po files and so on. FWIW.. if you have got all your 'trans' and 'blocktrans' stuff done in the templates, it takes about 30 minutes for a complete i18n newbie to create a multi-lingual site. FANTASTIC.

Category: i18n django