API Reference

Public API

modeltrans.admin

class modeltrans.admin.ActiveLanguageMixin

Add this mixin to your admin class to exclude all virtual fields, except:

• The original field (for the default language, settings.LANGUAGE_CODE)
• The field for the currently active language, without fallback.

modeltrans.apps

class modeltrans.apps.RegistrationConfig(app_name, app_module)

modeltrans.fields

class modeltrans.fields.TranslatedVirtualField(original_field, language=None, *args, **kwargs)

A field representing a single field translated to a specific language.

Parameters:

• original_field – The original field to be translated
• language – The language to translate to, or None to track the current active Django language.

get_field_name()

Returns the field name for the current virtual field.

The field name is <original_field_name>_<language> in case of a specific translation or <original_field_name>_i18n for the currently active language.

get_language()

Returns the language for this field.

In case of an explicit language (title_en), it returns “en”, in case of title_i18n, it returns the currently active Django language.

class modeltrans.fields.TranslationField(fields=None, required_languages=None, virtual_fields=True, fallback_language_field=None, *args, **kwargs)

This model field is used to store the translations in the translated model.

Parameters:

• fields (iterable) – List of model field names to make translatable.
• required_languages (iterable or dict) – List of languages required for the model. If a dict is supplied, the keys must be translated field names with the value containing a list of required languages for that specific field.
• virtual_fields (bool) – If False, do not add virtual fields to access translated values with. Set to True during migration from django-modeltranslation to prevent collisions with it’s database fields while having the i18n field available.
• fallback_language_field – If not None, this should be the name of the field containing a language code to use as the first language in any fallback chain. For example: if you have a model instance with ‘nl’ as language_code, and set fallback_language_field=’language_code’, ‘nl’ will always be tried after the current language before any other language.

modeltrans.manager

class modeltrans.manager.MultilingualManager

When adding the modeltrans.fields.TranslationField to a model, MultilingualManager is automatically mixed in to the manager class of that model.

If you want to use translated fields when building the query from a related model, you need to add objects = MultilingualManager() to the model you want to build the query from.

For example, Category needs objects = MultilingualManager() in order to allow Category.objects.filter(blog__title_i18n__icontains="django"):

class Category(models.Model):
    title = models.CharField(max_length=255)

    objects = MultilingualManager()  # required to use translated fields of Blog.

class Blog(models.Model):
    title = models.CharField(max_length=255)
    body = models.TextField(null=True)
    category = models.ForeignKey(Category, null=True, blank=True, on_delete=models.CASCADE)

    i18n = TranslationField(fields=("title", "body"))

class modeltrans.manager.MultilingualQuerySet(model=None, query=None, using=None, hints=None)

Extends ~django.db.models.query.QuerySet and makes the translated versions of fields accessible through the normal QuerySet methods, analogous to the virtual fields added to a translated model:

• <field> allow getting/setting the default language
• <field>_<lang> (for example, <field>_de) allows getting/setting a specific language. Note that if LANGUAGE_CODE == "en", <field>_en is mapped to <field>.
• <field>_i18n follows the currently active translation in Django, and falls back to the default language.

When adding the modeltrans.fields.TranslationField to a model, MultilingualManager is automatically mixed in to the manager class of that model.