- Author:
- foxbunny
- Posted:
- July 4, 2008
- Language:
- Python
- Version:
- .96
- models i18n metaclass translated-content
- Score:
- 2 (after 2 ratings)
Together with my mentor, Dusty Phillips, I have developed a simple class that dynamically adds two fields to its subclasses.
This is useful in cases when a single piece of content is divided into translatable and non-translatable fields, connected by a 1-to-many relationship.
Update 2009/03/30
Since its inception, this snippet has grown into a significantly more powerful solution for translatable content (I use it myself with great joy :). The project is now hosted on github:
Update 2008/07/09
It is now possible to define
i18n_common_model attribute in
class Meta section. Here's an example:
class Meta: i18n_common_model = "MyCommonModel"
As you can see, it has to be a string, not the real class, and it is case-sensitive.
Example
class Article(models.Model): author = models.CharField(max_length = 40) class Admin: pass class ArticleI18N(I18NModel): title = models.CharField(max_length = 120) body = models.TextField() class Admin: pass # optionally, you can specify the base class # if it doesn't follow the naming convention: # # class Meta: # i18m_common_model = "Article"
When the ArticleI18N class is created, it automatically gains two new fields.
lang field is a CharField with choices limited to either
settings.LANGUAGES or
django.conf.global_settings.LANGUAGES. The other field is
i18n_common field which is a ForeignKey to Article model.
The conventions
call the translation model
SomeBaseModelI18N, and the non-translation model SomeBaseModel (i.e., the translation model is called basename+"I18N")
the first convention can be overriden by specifying the base model name using the
i18n_common_modelattribute in
Metasection of the
I18Nmodel
I18N model is a subclass of
I18NModelclass
Original blog post
More like this
- Extended i18n base model by alcinnz 1 year, 10 months ago
- PositionField by jpwatts 6 years, 7 months ago
- Multiple inheritance of newforms and modelforms by simon 6 years, 10 months ago
- Modifying the fields of a third/existing model class by marinho 4 years, 2 months ago
- render_markup filter, specify the markup filter as a string by exogen 7 years, 10 months ago
I would import the settings like this:
from django.conf import settings
#
Heh, and there also a typo there. Thanks. I'll fix that.
#
Why not use model inheritance to do the same thing?
If you really wanted, you could create a mixin to keep things cleaner, and automatically add the language field eg:
But I like to keep things explicit :-)
#
Good call, that's exactly the case. Your approach is now my favourite.
#
It is now possible to define i18n_common_model attribute in class Meta section. Here's an example:
#
The above makes it a bit more explicit if you want that. I might make it a requirement in future.
#
I've added
to the
I18NModel. It seems it has to be there or this thing fails when deleting models.
#
Can you please write about usage / querying for values in views/templates ?
Thanks!
#
I've seen the project you mentioned, but it's a totally different philosophy.
The querying of I18N models is the same as any other model. You just keep in mind that you have a many-to-1 link from the I18N model to the non-I18N models. The I18N model has a field called
i18n_common, which you use to find the non-translated (non-translatable) fields (see line 23). The language of the I18N model is defined by the
langfield (line 24).
What this code does is basically just add the above two fields into the I18N model based on the name of the model. Nothing more, and nothing less. The rest is up to you. You do with them what you'd do with related models.
#
Oh, and btw, this has nothing to do with the Admin app. The admin app will treat the two models just like any two models. If someone's interested in writing the admin part so that admin will use the two models as one, that's cool, but I don't have the skills yet.
#
Please login first before commenting.