When I needed multi-language flatpages and flatblocks for telvee I searched for available Django apps that do dynamic translation. By dynamic translation, I mean translations are entered and stored in the database. As I said I needed to be able to translate both full pages and chunks of text that I can include into another page. I ended up rolling my own, which is without a doubt lesser to some apps below. I will try to imrove it with the good ideas from existing projects and then open source. Meanwhile I would like to share my review of 6 dynamic translation apps with you. I hope someone out there finds it useful.
Django-multilingual
One of the few active projects I have reviewed is django-multilingual. To enable a model for translations you need to create a Translation inner-class and move translatable fields inside. Then a seperate model for those fields is created behind the scenes. Django-multilingual has admin integration and a multi-language flatpages app. Another nice thing about this app is that it’s using signals internally. The API is based on getter and setter methods. For instance you call get_<fieldname>(language_id=None) on your model to get the field value for the active translation. This app has no releases and less than satisfactory API documentation and has tests only on the example project.
Django-pluggable-model-i18n
Django-pluggable-model-i18n uses registration pattern of admin app. It creates an extra model for translated fields and stores translations of non-default languages in it. This app has no releases, no tests, no API documentation and it is clearly stated to be experimental. I would also like to note the last commit date is May 25, 2009.
Django-modeltranslation
Another app that implements registration pattern is django-modeltranslation. The advantage of registration pattern is you don’t have to modify the code of the 3rd party apps you want to translate dynamically. But the database schema still needs to be modified if you are using django-modeltranslation. Also there is one translations.py for the project. I think one translation definition file per app would be better (just like admin does). Django-modeltranslation has intuitive underscore-language_code API but it is somewhat inconsistent; when you read the unsuffixed field you read the currently active language, when you write you write the default language specified in settings.py. Also the modified model stores some redundant data. For instance if your DEFAULT_LANGUAGE is "ES" both <fieldname> and <fieldname>_es columns will store the same value. Django-modeltranslation has admin integration and a management command to update database schema. Most importantly this app is the only one which has both tests and a release. (Unfortunately tests require specific settings to run)
Transdb
Transdb takes a completely different approach to dynamic translation problem. It provides two new field types; TransCharField and TransTextField. Then it serializes all your translations within a single column for each field of those. This means no JOINs and no extra queries. Unfortunately transdb doesn’t implement underscore-language_code API, you need to use get_in_language() and set_in_language() methods. Transdb has default widgets that render one form field for each language. Last commit date is Nov 07, 2008 and there is a release.
Django-multilingual-model
This one is not actually an app but just one module with 33 42 lines of code. You need to define the model that holds translations manually. This introduces some code redundancy, since you also define which fields get translated in the original model. Django-multilingual-model doesn’t implement any translation API, so it’s rather verbose to do anything with it. There are no tests and no releases. I simply don’t recommend django-multilingual-model for anything serious.
Django-transmeta
Django-transmeta stores translations in extra columns it creates in the original field’s table similar to django-modeltranslation. But you enable translation assigning a metaclass for your model and then add a Meta attribute; this means you can’t make models in existing apps translatable without modifying their code. Django-transmeta implements underscore-language_code API, has admin integration and a management command to sync database when you add new languages or translatable fields. There are documentation and code examples but no tests or releases. Last commit date it Nov 24, 2009.
Comparison of Dynamic Translation Apps
Software development is making choices. Would you rather have a clean and stable schema with an extra translations model or avoid extra JOINs and denormalize translations onto your original model’s table? Both have advantages and disadvantages. But some choices are not based on trade-offs. Documentation, examples, tests and releases for instance. Also in my opinion underscore-language_code API is way better than any of the alternatives.
Django platform is a very powerful and intuitive one. Many people have moved in last year. This popularity affected app ecosystem as well. But unfortunately a significant number of those apps are half baked fire-and-forget type. I wish 2010 to be the year of a significant increase in software quality of Django apps. I’ll try to do my part.
Related posts:
- Developing Reusable Django Apps
- Developing Reusable Django Apps: Signals
- Developing Reusable Django Apps: App Settings
- django-formfieldset
- django-renderformplain
Tags: django, i18n, open source, python, review, translation
I have created a translation system using a different approach… it’s called django-datatrans. Maybe you want to check this out too…
http://github.com/citylive/django-datatrans
there’s also my http://tabed.org/software/django-multilang/ but it very similar to transmeta
@Jef, @pawnhearts: I have just took a quick look at your apps. They both look interesting, they both differ from the 6 above in unique ways. I would love to take a closer look and perhaps write a review later.
Thanks for sharing.
An alternative approach — http://bitbucket.org/drmeers/django-dbgettext/wiki — “Extracts translatable strings from Django models for handling via Django’s standard i18n mechanisms.”
Interesting, I’ve only used django’s native i18n but these are worth checking out
This comment was originally posted on Reddit
addons.mozilla.org has a pretty janky way of doing this: all translations are stored in one table, and you look up an (id, locale) pair to get a string. I want to change it eventually, but right now we’re stuck maintaining compatibility with the legacy site.
My take on this is in http://github.com/jbalogh/zamboni/tree/master/apps/translations/ (fields.py and models.py are interesting), with docs at http://github.com/jbalogh/zamboni/tree/master/apps/translations/. But the docs are directed more to the people who already know how the system works.
I’ve used django-transmeta for a project and it worked pretty well. It’s very simple to use, and the only non-model changes you need are for queries since "fieldname" goes in the database as "fieldname_en", "fieldname_es", etc
This comment was originally posted on Reddit
Nice writeup! Multilingual sites are getting more and more popular nowadays. Looking forward to see your implementation.
if i’ve seen transmeta before writing multilang, i would’t write it. idea is basically the same, and they do the same thing in a very similar way. (main difference – i used class decorator, transmeta’s author used metaclass) i think our approach is the only real solution, because it does’t need heavy queries with joins, etc. we’ve used it to add another language support for models in existing big and serious application…
one little thing – i only add columns, default language column is not modified and not renamed, only additional language columns have underscore postfix(e.g. _es, _de)
I would like to apologize for the delay in approval of comments. I couldn’t connect to Internet for the last two days. And I will have limited connectivity for the next few.
I love the way your blog looks!! (Although django apps are not my thing).
Nice post muhuk.
Just wanted to share with you that django-pluggable-model-i18n has become very active this month (after a 7 month hiatus) and, although we’re still in a pre-alpha experimental stage, alpha is getting closer so we’re pretty excited about it and we hope to have a 0.1 release soon.