Model translation

Skip to first unread message


Dec 21, 2009, 8:37:22 AM12/21/09
to Django developers
I know this has been discussed and in most threads I've found it has
been disregarded with comments like: "Just use a 3rd party app" or
"just use the sites-framework" but I think there are definetly
advantages to having this an included feature. So here goes again:

I was very surprised to find that the "batteries included" Django did
not come with an app to translate content. This is an essential
feature, at least for us non-english speaking developers. I hope we
can develop a solid implementation to include with Django. The 3rd
party solutions are very varying in quality and implementation and
have cost me a lot of time, and most do not follow a django-ish path.

I sincerely hope a model translation mechanism can be seriously
considered for inclusion in the framework. (If there is already a
branch for this I appologise) (I also appologise if there is an active
thread discussing this that I didn't find)
I also offer my help in testing and submitting patches if this takes

I'd like to add my observations on some existing translation projects
to this discussion, I hope the designers of Django will find them


'''django-multilingual''': (I haven't used this myself, only checked
it out)
It feels to complex and non-intuitive. It obfuscates the model code
by moving fields into a subclass and makes the code to hard to
understand at a glance. It also adds joins to queries by having the
translations in a different table (This might or might not be a good


'''django-transmeta''': (I have used this)
It is the simplest of the approaches I've checked out, just specify
a different __metaclass__ and specify the fields you want translated
in the meta class. BIG PROBLEM with this approach: It obviously
doesn't work with other solutions that want to replace your metaclass,
for example when I wanted to both translate a model and have it tree
structured by using EasyTree, EasyTree complained. This _might_ not be
a problem though if the functionality of Transmeta's metaclass was
moved into Django's own standard metaclass, then EasyTrees metaclass
would subclass that functionality anyway.
This approach does not add joins as the translations are kept in the
same table (Again, this might or might not be a good thing).
In the end I think the simplicity of transmeta has the same
disadvantages as having the admin specifications in the metaclass.


'''django-modeltranslation''': (I have used this as well)
I think this general approach is the way to go. It uses the familiar
registration based approach that we use when specifying the admin and
is also used by the Haystack search engine app, so it feels very
Django-ish. This also has the side-benefit of allowing you to register
3rd party apps for translation. This does not clash with other apps I
use such as EasyTree, since it doesn't replace the metaclass.
This approach does not add joins as the translations are kept in the
same table (Again, this might or might not be a good thing).


'''Up for discussion''':
'''The pros and cons of how to store the translations''': In a
different table, as extra fields in the original table or as a
different row in the same table with an extra lang-field (Would
require duplicating non-translated data), (Or something completely
My gut-feeling tells me that storing them as extra fields in the same
table will be simple to code, faster in practise and keep the database
On the other side, storing in another table will keep the original
table uncluttered..

'''The admin interface support''': My dream scenario here would be if
it would work like django-page-cms. In the list-display it shows icons
for each supported language that are colored for languages that have
been entered, but grayed-out if a language is missing. In the Edit/Add
page it only shows input fields for the language that is currently
being edited, but it has a translation-helping-pane where it can
display text from another language if it has been entered.
But honestly, to get this off the ground, to begin with it is enough
to just display the fields for all languages in the edit/add page,
like django-modeltranslation does. It's enough for 90% of use-cases
(i.e. when there are only a couple of languages).

'''How ORM queries should work''': Should DB queries in the ORM
replace, say, title with title_en automatically? optionally? Should
indexes be created automatically for translated fields if the base
field is indexed?

Thank you for reading.

Russell Keith-Magee

Dec 21, 2009, 8:59:28 AM12/21/09
On Mon, Dec 21, 2009 at 9:37 PM, hejsan <> wrote:
> I know this has been discussed and in most threads I've found it has
> been disregarded with comments like: "Just use a 3rd party app" or
> "just use the sites-framework" but I think there are definetly
> advantages to having this an included feature. So here goes again:

I don't want to dampen your enthusiasm, but you've chosen a
inopportune time to try and start this discussion. We're just days
away from an alpha release, which will mark the point at which no more
big features will be accepted for the v1.2 release. The attention of
the Django core developers is currently on trying to finish the
features that we have all agreed are important for v1.2, as documented
in the wiki [1].

The right time to start a discussion like this is during the feature
selection phase of development. The next feature selection window will
open just after the release of Django 1.2, in about 3-4 months time.

Again - I don't want to dampen your enthusiasm. I just want to let you
know why you may not get a very enthusiastic response to your
suggestions at this time.


Russ Magee %-)


Dec 21, 2009, 9:11:03 AM12/21/09
to Django developers
Ok, thanks for letting me know. I will bump or repost after the
release if this discussion doesn't catch on, and if my enthusiasm
hasn't worn out by then ;)

On Dec 21, 1:59 pm, Russell Keith-Magee <>

JK Laiho

Dec 22, 2009, 7:01:57 AM12/22/09
to Django developers
As Russell said, this is probably a bad time, but I thought I'd throw
in some quick notes nonetheless.

> '''django-modeltranslation''': I think this general approach is the way to go

I agree that it's probably the best alternative available currently,
but still not without significant drawbacks (like breaking when fields/
fieldsets are used in the ModelAdmin, and not being able to
transparently query on translated fields - an issue you later
mentioned). We're running a severely hacked private version/fork of
django-modeltranslation in production, having added fields/fieldsets
and some custom jQuery/CSS admin widgetry, but in no form that would
be ready for public consumption, let alone as a basis for inclusion in
Django core.

Also, I was about to say that the development of django-
modeltranslation seems essentially stalled, but then checked to see
that the first update since March (support for admin inlines) was made
three days ago, so scratch that ;-)

However. I'm in the conceptual planning stages of a fresh solution to
the model translation problem, one that I hesitate to say anything
more about at this time since the ideas involved are not yet fully
formed in my head. When Django 1.2 hits bugfix-only mode, I'll
probably start tracking trunk and doing some initial prototyping
against it. If it amounts to anything, you'll hear more about it next
spring, hopefully around the timeframe that Russ talked about (3-4
months or so). Absolutely, positively no promises, though.
Procrastinating endlessly and losing motivation altogether are a
distinct possibility :-). But still, if and when the discussion pops
up again later on, I might have some ideas and/or code to share.

Until then.

- JK Laiho

Reply all
Reply to author
0 new messages