This kind of translation support is something django really needs in my
opinion. If this gets implemented together with the unicode conversion
by the time 1.0 gets rolled out, i'd be very, very happy.
I've read your blog post and i do have some remarks. I think it's
better not to put the languages in a separate table and then
referencing them with a foreign key. I have implemented something very
similar in another language some time ago, and i distinctly remember
regretting using a separate table. This is because in other parts of
the code you'll need to
lookup which language an id stands for, and that just means unnecessary
lookups.
There were other downsides to using a foreign key, but i can't recall
right now.
So i would use:
CategoryTranslation: category_id | language_code | name | description
and lookups like c.get_name('pl')
In your blog post you have on your todo list:
"another "backend", one that uses name_en, name_pl, name_de fields in
the Category model instead of creating a separate model"
I would really advise against this. The need to add a language to an
existing project is not so uncommon. This would be a major pain using
this system. Instead, as you mention yourself, some kind of caching
mechanism would alleviate enough of the database load.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
