Hi David,
I read your first post now. Then I think it could be great solution if
it's possible to be implemented.
Perhaps I appreciate less lines in every translation model. If you
look at:
class SomeObjTranslation(models.Model):
language = models.CharField(max_length=5, \
choices=settings.LANGUAGES, \
default=settings.LANGUAGE_CODE)
object = models.ForeignKey(SomeObj,
related_name='translations')
foo = models.CharField(...)
class Meta:
# only one translation per language and object
unique_together = (('language', 'object'),)
Generaly the only required things you need to set up in each
translation model are translatable fields and name of model your
translation is for. The rest is always the same. But even if this
would be only one disadvantage it's worth to have this implementation
because of other advantages.
I must say great thinking out of the box and good work anyway!
Veena
On 2 srp, 18:49, David Danier <goliath.mailingl...@gmx.de> wrote:
> > I don't research your idea deeply but for first look it seems very
> > similar or same to django-multilingual.
> >http://code.google.com/p/django-multilingual/
>
> From the database perspective it is similar, meaning it uses the same
> database structure. What I tried to write down was mostly some usage and
> API ideas to solve some things which pop up when using
> django-multilingualand others:
> * Make it possible to use third party apps in i18n environments even if
> the app was not designed to do this (This idea was stolen from
> pluggable-model-i18n.)
> * Don't add to much overhead for db performance and others (One JOIN,
> nothing more, this JOIN should be transparent to the user. This idea was
> stolen from model inheritance.)
> * Support getting results if no translation is available (sometimes you
> don't need to have a translation, for example if all fields are
> optional. This is possible in most model translation projects, even if
> it involves hammering the database with extra queries for each
> translation there. Conditional JOIN solves this in my proposal.)
>
> In conclusion I try to use the database structure django-multilingual
> proposes (which should be the best for the job anyway), keep usage as
> simple as using model inheritance (keep working with translations as
> simple as possible) while using a register approach to keep this
> application independent (thats some kind of killer feature).
>
> Hope this helps to see the differences here. Perhaps the file I attached
> helps to see some usage examples.
>
> One big advantage of my proposal over any existing solution is the
> possibility to use third party apps without changing their code. I still
> think this is very important as developers should not need to worry
> about internationalization when writing third party apps, because you
> should not need to use some complex database layout if you don't need
> translations.
>
> pluggable-model-i18n solves this, too, but it has some
> limitations/flaws. Using the pluggable-model-i18n you cannot optimize
> the SQL query when using translations and you run into many choices
> where to find a value, which are most significant if you want to query
> your database by some translated field (slug is translated:
> Book.objects.get(slug=...) vs. Book.objects.get(translation__slug=...,
> translation__language=...)). This are the two most significant
> disadvantages, others might appear when using pluggable-model-i18n in a
> productive environment.
>
> Greetings, David Danier
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@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
-~----------~----~----~----~------~----~------~--~---
