For better understanding of the second and the third ways of creating
multilingual models I mentioned, you can read the sub-article
"Database" in the "Internationalization Primer" at
http://digital-web.com/articles/internationalization_primer/
In my opinion, internalization is very important feature of websites.
Therefore, it has to be fully supported in any web CMS or development
framework.
Aidas
Aidas Bendoraitis wrote:
> Hello Django Professionals!
>
> I am making a Django-based website that has to be multilingual.
> Everything is clear about making the admin section and the templates
> translatable. The problem is multilingual objects.
>
> I could think of several approaches to implement internationalization
> for Django objects:
>
> 1. Use special tagging inside the translatable fields, i.e.
> <%en%>Title<%/en%><%de%>Titel<%/de%><%lt%>Pavadinimas<%/lt%>
> (this is not usable for common people, administrating the site and
> tricky for implementing searches and other functionalities)
>
> 2. Create class attributes for every single translatable field, i.e.
> title_en = models.TextField(verbose_name=_("English Title"));
> title_de = models.TextField(verbose_name=_("German Title"));
> title_lt = models.TextField(verbose_name=_("Lithuanian Title"));
> (it's not flexible, because you can't add languages dynamically)
>
> 3. Create a separate DB table for every model that has translatable fields
> The table would contain
> - model_id
> - translatable fields (title, description)
> - language_id (or code)
> (I find this way the most proper for implementing multilingual
> objects, but.. (read further))
>
> One way to have a separate table for a model is to have a separate
> model for translatable fields and One to Many relationship between the
> models.
> i.e.
> class ItemLng(models.Model):
> product = models.ForeignKey(Item);
> language = models.CharField(maxlength=5, choices=LANGUAGES,
> verbose_name=_("language"))
> title = models.CharField(maxlength=200, core=True,
> verbose_name=_("title"))
> description = models.TextField(verbose_name=_("description"))
> Then you can use tabular views in the administration to edit those
> translatable fields. (is it possible to restrict administrator from
> inserting two different versions of translations for the same
> language?)
>
> This may be OK until you start using tabular views for the primary
> objects. Let's take the example with Polls. Poll has children PollLng
> and Option, whereas Option has children OptionLng. As it is impossible
> to use two levels of tabular views, either Poll has to be edited
> separately from its Options, or Options has to be edited separately
> from their translated fields. And that makes no sense.
>
> So, I think, there should be a way to bound two database tables for
> one model. If you have an example or suggestions how to do that, or
> you have some suggestions how to implement translatable objects in
> another way, please respond to this email.
>
> Mr. Aidas Bendoraitis
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" 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-users
-~----------~----~----~----~------~----~------~--~---
