Dealing with Model Content

Strategies

As we discussed in the design decisions one key challenge for our model design is the question of how language interacts with our concept of an object: do we have abstract entities with associated translations, text which only exists in one language or some combination of the two? Do I support only a small number of pre-defined languages or anything which someone on the internet felt like contributing?

This has implications for our database design:

Each object has a language code and no direct links across languages
Each object has separate fields for each language
Each object which defines language-neutral properties (e.g. a City has a country and and a GeoDjango shape) and uses related objects for translation

Any of these could be correct depending on the project. We'll look at two Django apps which help manage the second and third possibilities

django-modeltranslation

Simple installation and usage: simply register the models and fields which you want to translate.
All translations are stored in the same table: the title field will become title_en, title_de, etc.
Model access is based on the active translation: obj.title becomes a property which returns title_LANGUAGE_CODE.
Full integration in the Django admin

This is avoids adding any extra tables or performing extra queries but it will retrieve considerable extra data if you have more than a few languages or very much text. You can compensate partially using Django's defer(), only values or values_list queryset methods to retrieve only the fields you care about at the cost of having to code some language-specific queries.

django-hvad

Provides a TranslatableModel class which your models should subclass. Untranslated fields are declared normally; translated fields are declared using a TranslatedFields helper
Translated fields are stored in a separate table; the TranslationQueryset provides a language() method which will automatically populate the fields of a retrieved object with the desired language, optionally falling back to other languages when a particular translation doesn't exist
Full integration in the Django admin

hvad retrieves only the translations you care about and allows you to avoid duplicating the untranslated portion of your model data. On the downside, every query now involves at least an extra JOIN which may be a performance concern, particularly for MySQL users.