Internalization: Two DB tables for one Model?

[Aidas Bendoraitis]

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

[Archatas]

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

[tekNico]

Aidas Bendoraitis wrote:
> Hello Django Professionals!
>
> I am making a Django-based website that has to be multilingual.

Me too. :-)

> 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)

I don't like this.

> 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)

I'm leaning toward this. Yes, it's not flexible, but it's YAGNI for me,
and the simplifying gains are huge.

> 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))

Complex, ugly.

There's also another approach: use translation tables for content, same
as it is done for the app interface. I don't like that either.

--
Nicola Larosa - http://www.tekNico.net/

Continuation-based web frameworks (like Seaside) seem lame to me. I'm
so much more impressed by event-based programming, and continuations
(used in that way) seem like a way to avoid explicit events. Events are
the web. Continuations are people who want to make the web into an MVC
GUI. -- Ian Bicking, February 2006