Marc Garcia created a new translatable fields project: django-transmeta
[1] [2]. It works by add new <field>_<lang> fields to a model
automatically, instead of adding a new table.
[1] http://vaig.be/2009/03/easier-field-translation-with-django.html
[2] http://code.google.com/p/django-transmeta/
Because the model syntax is so similar to DM, I feel we should work
together to come up with a shared 'API', so that the implementation of
translated fields becomes, well, an implementation detail.
This stuff should be in Django proper, and that will happen sooner if
there is consensus.
Regards,
Joost
--
Joost Cassee
http://joost.cassee.net
The "stuff" that should be in Django is the API, you mean? Not
django-transmeta? Because I dislike django-transmeta. In my opinion, it
violates the 1st normal form of the database; it may look simpler at
first but it will create a huge number of problems later when compared
to a design such as DM (this is why I chose DM; it's the only one that
is correctly designed from a theoretical point of view). This, however,
concerns the implementation. The DM interface, I agree, sucks.
Transmeta is nicer. I agree that a shared API would be great. Maybe it
would be easy for DM to follow the Transmeta interface? I mean that
class MyModel(models.Model):
name = models.CharField(max_length=100)
description = models.TextField()
class Meta:
translate = ('name', 'description')
just looks very much more elegant than
class MyModel(models.Model):
class Translate:
name = models.CharField(max_length=100)
description = models.TextField()
Yes, I mean the API.
> Not
> django-transmeta? Because I dislike django-transmeta. In my opinion, it
> violates the 1st normal form of the database; it may look simpler at
> first but it will create a huge number of problems later when compared
> to a design such as DM (this is why I chose DM; it's the only one that
> is correctly designed from a theoretical point of view).
I agree, I also think the DM implementation is better. On the other
hand, denormalizing the database can be trade-off for performance.
> This, however,
> concerns the implementation. The DM interface, I agree, sucks.
> Transmeta is nicer. I agree that a shared API would be great.
It's not (necessarily) that the DM sucks, it's the fact that although
various projects are developing different implementations, they all
share the same goal. Having a shared API would make it easier for
developers to 'try out' some of these projects without having to rewrite
their applications.
There has been talk of different APIs (for example in [1]), but the
current one is just good enough.
I'll try to direct Marc Garcia's attention to this thread.
> Yeah, the UI could definitely use a facelift. Philippe Lafaye shared
> a patch for great-looking tabbed interface:
>
> http://groups.google.pl/group/django-multilingual/browse_thread/thread/2e19de5d78ca4fb5
>
> But it would mean adding a dependency on jquery and several of its
> components, which is something I hesitate to do -- just like Django, I
> don't want to tie DM to any particular JS framework. Even tie in the
> sense that "using this framework is not mandatory, but you lose
> important/nice parts of the interface".
In case you are interested and if jQuery would be tolerated, I could
create a patch for django-multilingual of a custom inline admin class
I use in one of my projects. It would require a bit of cleanup and
update to the current dm version, but should be reusable.
Here is a simple screenshot: http://flickr.com/photos/jannis/3221935791/
Best,
Jannis
> So to put it in a nutshell I thing that all these reusable apps are
> the killer feature of django based project so I would prefer to have
> yet another reusable app to add the multilingual capability to my
> project.
Agreed, that's a good point given most available Django apps don't
support multilingual content out of the box. Not having a complete
overview of the technical difficulties, I think it would be great for
developers to be able to retrofit external apps with translatability
depending on their use case, just like we are able to do it with the
admin app, for example. App authors could of course also provide
sensible defaults.
At some point in the future, Pinax needs to be able to handle
translated content. Although I've used django-multilingual in a Pinax-
based project recently, I wondered about the inner class declaration.
Mostly because it reminded me of the inner Admin class drama and its
limitated reusability. Having said that I'd be happy to contribute.
Best,
Jannis
Thanks for setting up the poll!
Your reply to Malcolms comment on your blog, and Yann's reply to this
e-mail, highlight the (in my opinion) most important goal of a shared
API: to allow a model to indicate which fields can be translated, like
strings in static Python text or templates.
There is a division of labour here between application developers and
project developers. I think we can safely leave the decision of which
fields are translatable to the app developers. They make this decision
already for static strings. Decisions such as which languages to
provide, fallback to default language, where to store translations, etc.
should be left to project developers.
I believe this separation of labour evades the problem Malcolm sees with
a one-size-fits-few solution.
Wouldn't that be easy if you override the __metaclass__ property on
models (like transmeta does)? Probably I didn't understand the problem.
Anyway, what would happen if Django would accept and store the
'i18n=True' argument to Field constructors. Apps like DM could just
listen to the 'class_prepared' signal and do their magic there.
Nothing serious here, just wanna say "Yay!" for a unified API :D
> Reading your reply let me think tha tI was not clear enough on the
> point I was trying to make. I think it is not reasonable to believe
> that reusable app developer **will do any effort** to enable
> multilingual support for the information stored in db. And this for
> the foreseeable future.
Aha! :-) Well, my experience is that all application projects already
accept patches to internationalize static strings in Python or
templates, so I'm very optimistic on this point.
This depends, of course, on the availability of a way to specify
translatable fields without depending on some external i18n project.
for my store app, define a `store/conf/settings.py`::
from django.conf import settings
IS_MULTILINGUAL = getattr(settings, 'STORE_IS_MULTILINGUAL', False)
so, if we don't override this in our project's `settings.py` file it's
false by default.
In the `models.py` this is defined like so::
if settings.IS_MULTILINGUAL:
import multilingual
...
class Category(models.Model):
if settings.IS_MULTILINGUAL:
class Translation(multilingual.Translation):
name = models.CharField(_('name'), max_length=50)
desc = models.TextField(_('description'), blank=True)
else:
name = models.CharField(_('name'), max_length=50)
desc = models.TextField(_('description'), blank=True)
slug = models.SlugField(max_length=50, unique=True)
...
This way an app can be multilingual by demand. Pretty easy without
sacrificing much.
Of course this can be applied if we use the META syntax, with the same logic.
We can ask projects to include this patch to their apps, since it will
not break usage for their non multilingual users.
--
Panos Laganakos
The difference here is that the admin app lives in contrib, whereas if
model-level support for i18n enters Django, it's going to live in the
core code. The admin gets added to a project via INSTALLED_APPS, but
once model-level i18n gets added it's going to just be baked in. I
don't think it makes sense to think about these solutions as something
optional that may or may not be there. Ultimately, some sort of
solution /will/ be there. That's what we're all working towards, right?
Sam
> After looking at the poll results, and reading all comments on this
> subject, what I think is...
You do realize the poll has been up (or at least advertised) for only 17
hours? :-)
> May be we could try to make django be patched to not break if a
> translate attribute is found in Meta.
I like it. It's unobtrusive and backwards compatible.
> But anyway, I don't see any reason for not providing an additional way
> to register translations with no change on the original application.
> So what do you think about implementing both syntax and let the
> developer to choose which one is better for each case?
Nice for when this functionality remains a third-party option (and it is
not yet 'the Django way'. In the long term my vote is for letting the
application developer mark translatable model fields. (I have never felt
the need to mark translatable static strings 'in an additional way'.)
By the way, my current thoughts are based on the premiss that an
application developer is in a position to know which fields should be
translatable. Anyone disagree?
So this would be a limitation of using inline editing for the
translations. (Good decision, though, as it is.) I do not necessarily
propose to lose the Translation class, just having it automatically
generated.
>> Anyway, what would happen if Django would accept and store the
>> 'i18n=True' argument to Field constructors.
>
> This would require monkey patching the constructors of all fields you
> might want to use in models or creating special fields. This is bad,
> as we want to be able to handle translations of _any_ fields, no
> matter if we know about them or not.
Would that still be the case if the Django Field class accepted the
argument? I mean: would it be interesting to propose a change in Django,
for the support of translatable fields applications (TFAs)? I think the
important part would be contribute_to_class? If there were some sort of
registration for a TFA, that function could check for 'self.i18n' and
call into the TFA if it is translatable. Maybe a few other functions,
such as save, would have to change similarly.
Changes to Django could 1) make our life easier en 2) be negotiable if
they were supported by more than one TFA.
> Which is why I don't treat options 2 and 5 in the poll as serious
> alternatives to other methods. They are simply too limiting to what
> you can accomplish.
Would that still be true with Django support?
Apoligies for the lack of knowledge on this matter but I'm trying to understand the true function of Django Transmeta. Here is the situation:
Our website has been launched in a variety of different countries but would like all of the territories to be routed into one .com domain where we can pigeon hole each users activities.In order to localise our website we need full control of the 'Meta Description'.