Database localization (multilingual) design for Python/Django

2
votes

I am currently in the process of creating an app, on which the information will be accessed by people who speak different languages. The information will be highly unique, so using translation tools will not be good enough. All the information will need to be in different languages, and when the user logs in, the information is displayed according to his settings. Now, the application is based off Django and MySQL. I see that Django has a localization feature, but I don't quite understand it. Is it calling a translation mechanism or something? I don't get it.

Putting that aside, I was wondering what was the best approach to solve this issue. The number of different languages is unknown for now. So I don't think storing the exact translation of each column within one table is a good idea, even though it would save time when querying. (no inner joins etc).

1) Should I look into the Django localization feature? What is it exactly? [I don't really want to store the translations into files.]

2) What Database design is best for multilingual applications? I found those ones:

How people usually solve this issue? Thanks a lot!

EDIT: I am not looking especially for something that is THAT easy to use. Mostly for something that is performant and won't create a giant mess in my DB... is that possible?

1
pythondatabasedjangolocalizationtranslation
Have you seen django-hvad? – ilvar
I am not looking especially for something that is THAT easy to use. Mostly for something that is performant and won't create a giant mess in my DB... is that possible? – abisson

1 Answers

2
votes

1) Django i18n mechanism is used to allow localization of static text- labels in templates, field names, error messages- basically every text you don't store in database. It won't help much for translation of database contents.

2) Every major effort at multilingual django models I have seen uses one of the following approaches:

  • Adding modlename_lang columns to the same table.
  • Storing shared fields in one table and translations in another.

I would advise you to decide which of these approaches you like more, and just use the best documented model translation app for the chosen approach.

If you're going to have a few languages, then I'd advise to go for the first approach. On the other hand, if the number of languages gets larger, the second approach may be more viable.