Simple Django model translations without nasty hacks.

Features:

• Nice admin integration.
• Access translated attributes like regular attributes.
• Automatic fallback to the default language.
• Separate table for translated fields, compatible with django-hvad.
• Plays nice with others, compatible with django-polymorphic, django-mptt and such:
  • No ORM query hacks.
  • Easy to combine with custom Manager or QuerySet classes.
  • Easy to construct the translations model manually when needed.

See the documentation for more details.

The package can be installed using:

pip install django-parler

Add the following settings:

INSTALLED_APPS += (
    'parler',
)

Optionally, the admin tabs can be configured too:

PARLER_LANGUAGES = {
    None: (
        {'code': 'en',},
        {'code': 'en-us',},
        {'code': 'it',},
        {'code': 'nl',},
    ),
    'default': {
        'fallback': 'en',             # defaults to PARLER_DEFAULT_LANGUAGE_CODE
        'hide_untranslated': False,   # the default; let .active_translations() return fallbacks too.
    }
}

Replace None with the SITE_ID when you run a multi-site project with the sites framework. Each SITE_ID can be added as additional entry in the dictionary.

Make sure your project is configured for multiple languages. It might be useful to limit the LANGUAGES setting. For example:

from django.utils.translation import gettext_lazy as _

LANGUAGE_CODE = 'en'

LANGUAGES = (
    ('en', _("English")),
    ('en-us', _("US English")),
    ('it', _('Italian')),
    ('nl', _('Dutch')),
    ('fr', _('French')),
    ('es', _('Spanish')),
)

By default, the fallback language is the same as LANGUAGE_CODE. The fallback language can be changed in the settings:

PARLER_DEFAULT_LANGUAGE_CODE = 'en'

Using the TranslatedFields wrapper, model fields can be marked as translatable:

from django.db import models
from parler.models import TranslatableModel, TranslatedFields

class MyModel(TranslatableModel):
    translations = TranslatedFields(
        title = models.CharField(_("Title"), max_length=200)
    )

    def __unicode__(self):
        return self.title

Translatable fields can be used like regular fields:

>>> object = MyModel.objects.all()[0]
>>> object.get_current_language()
'en'
>>> object.title
u'cheese omelet'

>>> object.set_current_language('fr')       # Only switches
>>> object.title = "omelette du fromage"    # Translation is created on demand.
>>> object.save()

Internally, django-parler stores the translated fields in a separate model, with one row per language.

To query translated fields, use the .translated() method:

MyObject.objects.translated(title='cheese omelet')

To access objects in both the current and possibly the fallback language, use:

MyObject.objects.active_translations(title='cheese omelet')

This returns objects in the languages which are considered "active", which are:

• The current language
• The fallback language when hide_untranslated=False in the PARLER_LANGUAGES setting.

The queryset can be instructed to return objects in a specific language:

>>> objects = MyModel.objects.language('fr').all()
>>> objects[0].title
u'omelette du fromage'

This only sets the language of the object. By default, the current Django language is used.

Use object.get_current_language() and object.set_current_language() to change the language on individual objects. There is a context manager to do this temporary:

from parler.utils.context import switch_language

with switch_language(model, 'fr'):
    print model.title

And a function to query just a specific field:

model.safe_translation_getter('title', language_code='fr')

This package also includes:

• Creating the TranslatedFieldsModel manually!
• Form classes for inline support.
• View classes for switching languages, creating/updating translatable objects.
• Template tags for language switching-buttons.
• ORM methods to handle the translated fields.
• Admin inlines support.

See the documentation for more details.

• Using ModelAdmin.prepopulated_fields doesn't work, but you can use get_prepopulated_fields() as workaround.
• Due to ORM restrictions queries for translated fields should be performed in a single .translated(..) or .active_translations(..) call.
• The .active_translations(..) method typically needs to .distinct() call to avoid duplicate results of the same object.

• The list code currently performs one query per object. This needs to be reduced.
• Preferably, the TranslatedField proxy on the model should behave like a RelatedField, if that would nicely with the ORM too.

Please contribute your improvements or work on these area's!

This module is designed to be generic. In case there is anything you didn't like about it, or think it's not flexible enough, please let us know. We'd love to improve it!

If you have any other valuable contribution, suggestion or idea, please let us know as well because we will look into it. Pull requests are welcome too. :-)