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
off.
I'd like to add my observations on some existing translation projects
to this discussion, I hope the designers of Django will find them
helpful:
----
'''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
thing).
----
'''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
different).
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
uncluttered.
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.
