+1 for this type of solution.
Just there is no need for the intermediate table between the table
with untranslatable fields and the table with translatable ones,
because the relationship between these two tables is one to many. So
the table with translatable fields could just have a FK to the table
with untranslatable fields. So the solution is more or less the same
as I proposed some time ago.
Actually this could be integrated into the core.
When you create a model, you could add translatable=True to fields
that have to be in the language-specific table.
When you make selections, you would need to set the language name in
the following or a similar way:
MyModel.objects.by_language("EN").all()
MyModel.objects.by_language("EN").order_by('title')
which would form queries like:
SELECT * FROM myapp_mymodel INNER JOIN myapp_mymodel_translatable ON
myapp_mymodel.id = myapp_mymodel_translatable.id ORDER BY title
Regards,
Aidas Bendoraitis [aka Archatas]
On 11/9/06, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote:
>
>
> On 08-Nov-06, at 5:22 PM, fdb wrote:
>
> > Note again that it's perfectly fine to add objects in another language
> > than the default that don't have translations in the default language.
> > One restriction: you cannot translate a page that doesn't have a
> > default language version.
>
> i took a look at this - it seems to imply that there is only one
> translateable field in the model (I may be wrong). But for me a
> typical page model would have several Char fields and more than one
> text field. How does one handle that? I was thinking having
>
> 1. languages table - longname and shortname
> 2. for each table a translate table with fk to languages table and fk
> to the translated table. This table will contain only translateable
> fields (char and text). The two fks are unique_together. Whenever the
> app sees a text or char field, it searches for a translation to insert.
> 3. Translation would be page independant and table independant. For
> any given language, the app searches for all untranslated text and
> char fields and displays them, one can select to translate.
> 4. Provision should be made for automatically translating strings,
> review of this and review of translations themselves.
>
> --
>
> regards
> kg
> http://lawgon.livejournal.com
> http://nrcfosshelpline.in/web/
>
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
