Modeltranslation¶

Requirements¶

Using Pip¶

$ pip install django-modeltranslation

Using the Source¶

Get a source tarball from github or pypi, unpack, then install with:

$ python setup.py install

Configure the Project’s settings.py¶

INSTALLED_APPS = (
    ...
    'modeltranslation',
    ....
)

gettext = lambda s: s
LANGUAGES = (
    ('de', gettext('German')),
    ('en', gettext('English')),
)

MODELTRANSLATION_DEFAULT_LANGUAGE = 'en'

MODELTRANSLATION_TRANSLATION_FILES = (
    '<APP1_MODULE>.translation',
    '<APP2_MODULE>.translation',
)

MODELTRANSLATION_TRANSLATION_FILES = (
    'news.translation',
    'projects.translation',
)

MODELTRANSLATION_CUSTOM_FIELDS = ('MyField', 'MyOtherField',)

Changes Automatically Applied to the Model Class¶

After registering the News model for translation an SQL dump of the news app will look like this:

$ ./manage.py sqlall news
BEGIN;
CREATE TABLE `news_news` (
    `id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY,
    `title` varchar(255) NOT NULL,
    `title_de` varchar(255) NULL,
    `title_en` varchar(255) NULL,
    `text` longtext NULL,
    `text_de` longtext NULL,
    `text_en` longtext NULL,
)
;
ALTER TABLE `news_news` ADD CONSTRAINT page_id_refs_id_3edd1f0d FOREIGN KEY (`page_id`) REFERENCES `page_page` (`id`);
CREATE INDEX `news_news_page_id` ON `news_news` (`page_id`);
COMMIT;

Note the title_de, title_en, text_de and text_en fields which are not declared in the original News model class but rather have been added by the modeltranslation app. These are called translation fields. There will be one for every language in your project’s settings.py.

The name of these additional fields is build using the original name of the translated field and appending one of the language identifiers found in the settings.LANGUAGES.

As these fields are added to the registered model class as fully valid Django model fields, they will appear in the db schema for the model although it has not been specified on the model explicitly.

If you are starting a fresh project and have considered your translation needs in the beginning then simply sync your database and you are ready to use the translated models.

In case you are translating an existing project and your models have already been synced to the database you will need to alter the tables in your database and add these additional translation fields. Note that all added fields are declared null=True not matter if the original field is required. In other words - all translations are optional. To populate the default translation fields added by the modeltranslation application you can use the update_translation_fields command below. See The update_translation_fields Command section for more infos on this.

Rules for Translated Field Access¶

So now when it comes to setting and getting the value of the original and the translation fields the following rules apply:

Rule 1

Reading the value from the original field returns the value translated to the current language.

Rule 2

Assigning a value to the original field also updates the value in the associated default translation field.

Rule 3

Assigning a value to the default translation field also updates the original field - note that the value of the original field will not be updated until the model instance is saved.

Rule 4

If both fields - the original and the default translation field - are updated at the same time, the default translation field wins.

Examples for Translated Field Access¶

Because the whole point of using the modeltranslation app is translating dynamic content, the fields marked for translation are somehow special when it comes to accessing them. The value returned by a translated field is depending on the current language setting. “Language setting” is referring to the Django set_language view and the corresponding get_lang function.

Assuming the current language is de in the News example from above, the translated title field will return the value from the title_de field:

# Assuming the current language is "de"
n = News.objects.all()[0]
t = n.title # returns german translation

# Assuming the current language is "en"
t = n.title # returns english translation

This feature is implemented using Python descriptors making it happen without the need to touch the original model classes in any way. The descriptor uses the django.utils.i18n.get_language function to determine the current language.

Tweaks Applied to the Admin¶

class NewsAdmin(TranslationAdmin):
    fieldsets = [
        (u'News', {'fields': ('title', 'news',)})
    ]

>>> a = NewsAdmin(NewsModel, site)
>>> a.get_fieldsets(request)
[(u'News', {'fields': ('title_de', 'title_en', 'news',)})]

TranslationAdmin in Combination with Other Admin Classes¶

If there already exists a custom admin class for a translated model and you don’t want or can’t edit that class directly there is another solution.

Taken a (fictional) reusable blog app which defines a model Entry and a corresponding admin class called EntryAdmin. This app is not yours and you don’t want to touch it at all.

In the most common case you simply make use of Python’s support for multiple inheritance like this:

class MyTranslatedEntryAdmin(EntryAdmin, TranslationAdmin):
    pass

The class is then registered for the admin.site (not to be confused with modeltranslation’s translator). If EntryAdmin is already registered through the blog app, it has to be unregistered first:

admin.site.unregister(Entry)
admin.site.register(Entry, MyTranslatedEntryAdmin)

class EntryAdmin(model.Admin):
    def formfield_for_dbfield(self, db_field, **kwargs):
        # does some funky stuff with the formfield here

class MyTranslatedEntryAdmin(EntryAdmin, TranslationAdmin):
    def formfield_for_dbfield(self, db_field, **kwargs):
        field = super(MyTranslatedEntryAdmin, self).formfield_for_dbfield(db_field, **kwargs)
        self.patch_translation_field(db_field, field, **kwargs)
        return field

Admin Inlines¶

Support for tabular and stacked inlines, common and generic ones.

A translated inline must derive from one of the following classes:

• modeltranslation.admin.TranslationTabularInline
• modeltranslation.admin.TranslationStackedInline
• modeltranslation.admin.TranslationGenericTabularInline
• modeltranslation.admin.TranslationGenericStackedInline

Just like TranslationAdmin these classes implement a special method formfield_for_dbfield which does all the patching.

For our example we assume that there is new model called Image. Its definition is left out for simplicity. Our News model inlines the new model:

from django.contrib import admin
from news.models import Image, News
from modeltranslation.admin import TranslationTabularInline

class ImageInline(TranslationTabularInline):
    model = Image

class NewsAdmin(admin.ModelAdmin):
    list_display = ('title',)
    inlines = [ImageInline,]

admin.site.register(News, NewsAdmin)

from django.contrib import admin
from news.admin import ImageInline
from news.models import Image, News
from modeltranslation.admin import TranslationAdmin, TranslationGenericStackedInline

class TranslatedImageInline(ImageInline, TranslationGenericStackedInline):
    model = Image

class TranslatedNewsAdmin(NewsAdmin, TranslationAdmin):
    inlines = [TranslatedImageInline,]

    def formfield_for_dbfield(self, db_field, **kwargs):
        field = super(TranslatedNewsAdmin, self).formfield_for_dbfield(db_field, **kwargs)
        self.patch_translation_field(db_field, field, **kwargs)
        return field

admin.site.unregister(News)
admin.site.register(News, NewsAdmin)

Using Tabbed Translation Fields¶

Modeltranslation supports separation of translation fields via jquery-ui tabs. The proposed way to include it is through the inner Media class of a TranslationAdmin class like this:

class NewsAdmin(TranslationAdmin):
    class Media:
        js = (
            'modeltranslation/js/force_jquery.js',
            'http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.24/jquery-ui.min.js',
            'modeltranslation/js/tabbed_translation_fields.js',
        )
        css = {
            'screen': ('modeltranslation/css/tabbed_translation_fields.css',),
        }

The force_jquery.js script is necessary when using Django’s built-in django.jQuery object. Otherwise the normal jQuery object won’t be available to the included (non-namespaced) jquery-ui library.

Standard jquery-ui theming can be used to customize the look of tabs, the provided css file is supposed to work well with a default Django admin.

Using a Custom jQuery Library¶

If you don’t want to use the jquery library shipped with Django, you can also include a standard one. While this adds some redundancy it could be useful in situations where you need certain features from a newer version of jquery that is not yet included in Django or you rely on a non-namespaced version of jquery somewhere in your custom admin frontend code or included plugins.

In this case you don’t need the force_jquery.js static provided by modeltranslation but include the standard jquery library before jquery-ui like this:

class NewsAdmin(TranslationAdmin):
    class Media:
        js = (
            'http://code.jquery.com/jquery-1.8.2.min.js',
            'http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.24/jquery-ui.min.js',
            'modeltranslation/js/tabbed_translation_fields.js',
        )
        css = {
            'screen': ('modeltranslation/css/tabbed_translation_fields.css',),
        }

The update_translation_fields Command¶

In case the modeltranslation app was installed on an existing project and you have specified to translate fields of models which are already synced to the database, you have to update your database schema manually.

Unfortunately the newly added translation fields on the model will be empty then, and your templates will show the translated value of the fields (see Rule 1 below) which will be empty in this case. To correctly initialize the default translation field you can use the update_translation_fields command:

$ ./manage.py update_translation_fields

Taken the News example from above this command will copy the value from the news object’s title field to the default translation field title_de. It only does so if the default translation field is empty otherwise nothing is copied.

All translated models (as specified in the project’s translation.py will be populated with initial data.

The sync_translation_fields Command¶

$ ./manage.py sync_translation_fields

Accessing Translated Fields Outside Views¶

Since the modeltranslation mechanism relies on the current language as it is returned by the get_language function care must be taken when accessing translated fields outside a view function.

Within a view function the language is set by Django based on a flexible model described at How Django discovers language preference which is normally used only by Django’s static translation system.

When a translated field is accessed in a view function or in a template, it uses the django.utils.translation.get_language function to determine the current language and return the appropriate value.

Outside a view (or a template), i.e. in normal Python code, a call to the get_language function still returns a value, but it might not what you expect. Since no request is involved, Django’s machinery for discovering the user’s preferred language is not activated.

The unittests in tests.py use the django.utils.translation.trans_real functions to activate and deactive a specific language outside a view function.

django-multilingual¶

A library providing support for multilingual content in Django models.

It is not possible to reuse existing models without modifying them.

django-multilingual-model¶

A much simpler version of the above django-multilingual.

It works very similiar to the django-multilingual approach.

transdb¶

Django’s field that stores labels in more than one language in database.

This approach uses a specialized Field class, which means one has to change existing models.

i18ndynamic¶

This approach is not developed any more.

django-pluggable-model-i18n¶

This app utilizes a new approach to multilingual models based on the same concept the new admin interface uses. A translation for an existing model can be added by registering a translation class for that model.

This is more or less what modeltranslation does, unfortunately it is far from being finished.