How about this:
The django main code implements a KISS version of model translation
that works for most cases.
It will still be possible for others that need more sophisticated ways
to use one of the plethora of third party apps.
This is in line with many of the contrib apps, for example most people
can make flatpages work for them, but many prefer to use django-cms or
django-page-cms or whatever to get every possible bell and whistle.
Do not forget, to quote the djangoproject.com contrib app site:
Django aims to follow Python’s “batteries included” philosophy. It
ships with a variety of extra, optional tools that solve common Web-
development problems.
And to further rub that point in, on the frontpage of
djangoproject.com Internationalization is boasted as a main feature:
"Django has full support for multi-language applications, letting you
specify translation strings and providing hooks for language-specific
functionality."
Currently this is, as I see it, false and I felt rather let down after
I started learning django and found out that in reality only static
text could be translated.
For most countries other than the English speaking ones this is one of
the most important features.
My proposal:
I say we go with the "Multilingual model with one object per language"
way, as stefanw proposed above, mainly because it seems to be the
simplest one to adapt to the ORM's query language, and I don't see why
it wouldn't comply with cases 1, 2, 3, 4 and 6 of JK Laiho's
considerations. As for number 5, working well with South, I have no
idea if it does, but since South's only purpose in life is to migrate
Django apps, then I guess South would simply have to adapt to changes
in the django core.
I propose a setting be added, in line with USE_I18N and USE_L10N:
USE_MODEL_I18N # false by default
And another tuple setting specifying which models should be
translated:
I18N_MODELS = (
"myblog.entry",
"django.contrib.flatpages",
...
)
If USE_MODEL_I18N is true then django.db.models.Model adds two fields:
language and group_id. I don't think I care if it adds these fields to
all models in the project or just the ones specified by I18N_MODELS.
Admin support and widgetry can be added gradually because off the
shelf you just create a new object instance to create a new
translation. (Keep It Simple Stupid) and filtering in the admin is
trivial.
The only blazingly obvious caveat I can see is that
modelname.objects.all() returns every possible language. This means
for example that the generic views in their current form list all
languages.
To solve this, either change the functionality of
modelname.objects.all() to return only objects from current locale if
USE_MODEL_I18N is True or add a localized() function as David Danier
mentions above:
If a modelname.objects.localized() filtering function is added then
backwards compatibility becomes trivial, by just replacing for example
{% for entry in articles %}
with
{% for entry in articles.localized %}
in your templates. The localized function should probably do nothing
if USE_MODEL_I18N is False.
I haven't seen django-datatrans before. Does it play well with the
Django ORM querying style? The other registration based apps don't.
- hejsan
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
