Jannis Leidel tells us about django internationalisation (or should that be internationaliZation? Well, Jannis confessed to changing it to an S on purpose :-) ) Jannis used to maintain django’s translations a few years ago. Now he works on the mozilla developer network website, which has translations into more than 30 languages.
He showed a picture of the Rosetta stone. That stone turned into a tool to transmit the previously-unknown egypt hyroglyphs to our times. It was the vessel that brought lots of Egypt culture to the present time.
Isn’t what we do with our Django websites something that similarly can transfer knowledge and culture? But there is a problem…
56% of the web is English. 5% is a native speaker. Only 20% of the world population has a basic knowledge of English!
Another example? 0.8% of the web is Arabic. 4% is a native speaker. 0.1% is Hindi, with 5% native speakers.
Multilingual and multicultural… There are huge differences. The future is a global web, with lots of fresh new internet users coming online in the coming years. Users that don’t speak English and largely aren’t “western”. How do we get to a global web? There are three long words that are relevant:
Internationalization, “i18n”. The preparation phase of making your software
at least translatable. Django has tools for this, for instance
blocktrans %} in your templates. And
gettext() in your python code.
Translation, “t9n”. Actually translating the marked-as-translatable strings from the i18n phase. Additionally you can translate your content. A different problem altogether is translating your project’s documentation.
The files used for translation are normally the GNU gettext
.po files. A technical format.
Localization (l10n). Different representations for numbers or dates and so. “5 mei 2014” versus “May 5th, 2014”.
In django, everything is done automatically if you have
True in your settings file.
In django, look at
django.utils.translation. It is an old part of the
code. There wasn’t much web tech experience at that time. It contains a
“thread local” that accesses the request, for instance. Various parts really
should be replaced.
How does django detect the current language?
We have tons of information here, but it also means that it isn’t quite clear which language the user is actually going to see.
Most of the tools the open source generally uses come from the GNU Gettext project. It isn’t particularly bad as such, but we’re pretty much bound to gettext and cannot really use any improvements made in other toolsets.
The normal gettext string extraction workflow means running
sending the untranslated
.po files over to the translators. Get them back,
compilemessages to generate the resulting
.mo compiled translation
file. This is very technical. A very technical solution to a non-technical
Timezones are aonother area. We use
pytz for that, which works well.
The missing pieces in django. This are the bits he wants us all to add to django to support all those upcoming 4 billion/milliard (depends on your locale, I mean 4*10^9) new users.
Call to action
USE_I18Nsetting. It should be on by default.
His slides are on http://www.slideshare.net/jezdez/django-internationalisation
My name is Reinout van Rees and I work a lot with Python (programming language) and Django (website framework). I live in The Netherlands and I'm happily married to Annie van Rees-Kooiman.
Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):