I think if it'd be possible to have only this syntax: from django.contrib.translations import translation
translation.register(SomeObj, ['foo']) Veena On Aug 4, 9:45 pm, veena <[email protected]> wrote: > 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 <[email protected]> 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
