Defining models with django-hvad is done by inheriting
TranslatableModel. Model definition works like in
regular Django, with the following additional features:
- Translatable fields can be defined on the model, by wrapping them in a
TranslatedFieldsinstance, and assigning it to an attribute on the model. That attribute will be used to access the translations of your model directly. Behind the scenes, it will be a reversed ForeignKey from the Translations Model to your Shared Model.
- Translatable fields can be used in the model options. For options that take
groupings of fields (
index_together), each grouping may have either translatable or non-translatable fields, but not both.
- Special field
language_codeis automatically created by hvad, and may be used for defining
unique_togetherconstraints that are only unique per language.
A full example of a model with translations:
from django.db import models from hvad.models import TranslatableModel, TranslatedFields class TVSeries(TranslatableModel): distributor = models.CharField(max_length=255) translations = TranslatedFields( title = models.CharField(max_length=100), subtitle = models.CharField(max_length=255), released = models.DateTimeField(), ) class Meta: unique_together = [('title', 'subtitle')]
TranslatedFields cannot contain a field named
master, as this name
is reserved by hvad to refer to the Shared Model. Also, special
language_code can be overriden in order to set it to be a
different type of field, or change its options.
Prepares a new translation for this instance for the language specified.
This method does not perform any database queries. It assumes the translation does not exist. If it does exist, trying to save the instance will raise an
Returns the value of the field specified by
nameif it’s available on this instance in the currently cached language. It does not try to get the value from the database. Returns the value specified in
defaultif no translation was cached on this instance or the translation does not have a value for this field.
This method is useful to safely get a value in methods such as
This method never performs any database queries.
class MyModel(TranslatableModel): translations = TranslatedFields( name = models.CharField(max_length=255) ) def __unicode__(self): return self.safe_translation_getter('name', str(self.pk))
Changed in version 0.4.
Tries to get the value of the field specified by
safe_translation_getter(). If this fails, tries to load a translation from the database. If none exists, returns the value specified in
This method is useful to get a value in methods such as
Returns a list of available language codes for this instance.
This method runs a database query to fetch the available languages, unless they were prefetched before (if the instance was retrieved with a call to
save(force_insert=False, force_update=False, using=None, update_fields=None)
This method runs an extra query to save the translation cached on this instance, if any translation was cached.
It accepts both translated and untranslated fields in
- If only untranslated fields are specified, the extra query will be skipped.
- If only translated fields are specified, the shared model update will be skipped. Note that this means signals will not be triggered.
Please note that
select_related() used on
a foreign key pointing from a normal model to a
translatable model does not span to its
translations and therefore accessing a translated
field over the relation will cause an extra query. Foreign keys from a
translatable model do not have this restriction.
If you wish to filter over a translated field over the relation from a
Normal Model you have to use
get_translation_aware_manager() to get a manager that allows
you to do so. That function takes your model class as argument and returns a
manager that works with translated fields on related models.
New in version 0.5.
Abstract models can be used normally with hvad.
Untranslatable fields of the base models will remain untranslatable, while
translatable fields will be translatable on the concrete model as well:
class Place(TranslatableModel): coordinates = models.CharField(max_length=64) translations = TranslatedFields( name = models.CharField(max_length=255), ) class Meta: abstract = True class Restaurant(Place): score = models.PositiveIntegerField() translations = TranslatedFields() # see note below
The concrete models must have a
instance as one of their attributes. This is required because this
attribute will be used to access the translations. It can be empty.
New in version 0.4.
Proxy models can be used normally with hvad, with the
__init__method of the proxy model will not be called when it is loaded from the database.
- As a result, the
post_initsignals will not be sent for the proxy model either.
__init__ method and signals for the concrete model will still be called.
managers, using vanilla
querysets can be used with translatable
models. However, they will not have access to translations or translatable fields.
Also, such a vanilla manager cannot server as a
default manager for the model. The default manager
must be translation aware.
To have full access to translations and translatable fields, custom managers
TranslationManager and custom querysets
must inherit either
TranslationQueryset (enabling the
FallbackQueryset (enabling the use of
use_fallbacks()). Both are described in the
Once you have a custom queryset, you can use it to override the default ones
in your manager. This is where it is more complex than a regular manager:
TranslationManager uses three types of queryset, that
can be overriden independently:
TranslationQueryset, and will be used for all queries that call the
FallbackQueryset, and will be used for all queries that call the
default_classmay be any kind of queryset (a
FallbackQuerysetor a plain
QuerySet). It will be used for all queries that call neither
untranslated. It defaults to being a regular, translation-unaware
QuerySetfor compatibility, see next section about overriding it.
As a convenience, it is possible to override the queryset at manager instanciation, avoiding the need to subclass the manager:
class TVSeriesTranslationQueryset(TranslationQueryset): def is_public_domain(self): threshold = datetime.now() - timedelta(days=365*70) return self.filter(released__gt=threshold) class TVSeries(TranslatableModel): # ... (see full definition in previous example) objects = TranslationManager(queryset_class=TVSeriesTranslationQueryset)
Overriding Default Queryset¶
New in version 0.6.
By default, the
TranslationManager returns a vanilla,
QuerySet when a query is
done without either
untranslated(). This conservative
behavior makes it compatible with third party modules. It is, however, possible
to set it to be translation-aware by overriding it:
class MyModel(TranslatableModel): objects = TranslationManager(default_class=TranslationQueryset)
This deeply changes key behaviors of the manager, with many benefits:
- The call to
language()can be omitted, filtering on translations is implied in all queries. It is still possible to use it to set another language on the queryset.
- As a consequence, all third-party modules will only see objects in current language, unless they are hvad-aware.
- They will also gain access to translated fields.
- Queries that use
prefetch_related()will prefetch the translation as well (in current language).
- Acessing a translatable model from a
GenericForeignKeywill also load and cache the translation in current language.
In other terms, all queries become translation-aware by default.
Some third-party modules may break if they rely on the ability to see all objects. MPTT, for instance, will corrupt its tree if some objects have no translation in current language. Use caution when combining this feature with other manager-altering modules.
Custom Translation Models¶
New in version 1.5.
It is possible to have translations use a custom base
class, by specifying a
base_class argument to
This may be useful for advanced manipulation of translations, such as customizing some
model methods, for instance
class BookTranslation(models.Model): @classmethod def from_db(cls, db, fields, values): obj = super(BookTranslation, self).from_db(cls, db, field, values) obj.loaded_at = timezone.now() return obj class Meta: abstract = True class Book(TranslatableModel): translations = TranslatedFields( base_class = BookTranslation, name = models.CharField(max_length=255), )
In this example, the
Book‘s translation model will have
BookTranslation as its
first base class, so every translation will have a
loaded_at attribute when loaded
from the database. Keep in mind this attribute will not be available on the book itself,
but can be accessed through
Such classes are inserted into the translations inheritance tree, so if some other model
Book, its translations will also inherit
Next, we will detail the translation-aware querysets provided by hvad.