The django ORM and multilingual database contents - Jonas Obrist (djangocon.eu)¶

Tags: djangocon, django

What he wants is multilingual content in the database with an easy API. He doesn’t want to use something like gettext as that has other uses.

Some approaches:

• Single-table: one extra field per translatable field per language. Plusses: somewhat easy to implement. Few queries. Fallbacks are simple. Minusses: ordering/filtering is hard. Migrations are no fun: for every new field, you need a schema migration. Query results can get big.

• Hash-table: one extra table with key/value translations. Pro: easy to implement. Only translate once. Con: slow, no ordering.

• Dual-tables: one for translated fields, one for untranslated fields. Pro: can be very fast. Few queries. Works great with south. Con: harder to implement. Django doesn’t like you to implement it this way in a generic way. Only in your own app is ok, but a generic solution is hard.

• Other things like JSONField, build-in google translate, things he doesn’t like.

django-multilingual-ng is something he wrote build upon django-multilingual. Don’t use it. It is slow. Dual-table approach.

django-nani: dual-table approach again. His current effort. It tries to be as fast as possible. QuerySet API should stay the same where possible. Documented. (After twittering him, Jonas added the README to the pypi page within five minutes, so it looks fine there, too. Thanks! Quick!)

django-nani is optimized for single-language read queries. Write is fairly optimized. Fallbacks are possible, but they’re more expensive and have to be used explicitly. Ordering and filtering just works as expected.

Problems: when querying over relations, the starting model has full power over the query, so multilinguality is a big problem there. A workaround is to call some utility method to re-gain the translation-aware manager.

Django drawback: you cannot easily store additional information in a class’s Meta. It seems an unnecessary restriction in django. The workaround is that he adds things anyway over django’s complaints.

He had to tie deep into django’s queryset code, so he hopes it doesn’t change too many internal details. Otherwise he’s screwed.