While there are some intentional differences among some projects (for example django-modeltranslation is the only one that can translate models without editing them), it would be great to merge all (or most) existing projects, and join the efforts to get our best application (and hopefully it'll worth to be included in Django itself).
So, with the merge of those applications in mind, we're planning to create a branch on django-multilingual that will have the very best of each existing application, and any other cool idea.
So if you have good Python/Django skills, and want to add some open source work in your CV... ;) join us now!
Or if you are a potential user of this application, or you just think that your opinion is worth to be shared, please fill the MODEL SYNTAX POLL, or mail us with your ideas.
Here there are simple sample for each option on the poll:
class Translation
class MyModel(model.Model):
my_field = CharField()
class Translation(multilingual.Translation):
my_i18n_field = CharField()
custom fields
class MyModel(model.Model):
my_field = CharField()
my_i18n_field = TransCharField()
separate model
class MyModel(model.Model):
my_field = CharField()
my_i18n_field = CharField()
Class MyModelTranslation(TranslationOptions):
fields = ('my_i18n_field',)
translate attrs in Meta
class MyModel(model.Model):
my_field = CharField()
my_i18n_field = CharField()
class Meta:
translate = ('my_i18n_field',)
translate=True in field options
class MyModel(model.Model):
my_field = CharField()
my_i18n_field = CharField(translate=True)
Do you have a better idea?
Just leave a comment here,
or write a mail on this thread
I'm reluctant to subscribe to yet another mailing list (although I suspect I might at some point), so I'm going to add my two cents here and you can use it as you wish...
ReplyDeletePlease keep in mind that there are at least two broad groups of use-cases here that don't have a lot of overlap and which require different designs. If you're going for one-size-fits-all, you will have one size that fits few.
The first case is common in internal applications, where the number of languages is a known quantity and/or can be controlled. For example, even if it's not known at build time that Spanish will be supported, it can be scheduled that "we'll roll out Spanish support in June" and database changes can be made to support that. If every piece of content is to be translated (e.g. a website with all content available simultanesouly in multiple languages), then including the localised copy in the same model as the original, or in one separate "translation" model makes some sense.
The other model is the open source one. You don't know in advance which languages you will be supporting. You don't know when support for a new language will arrive and you don't have any real control over how much of the content will be translated. In that case, having a separate entity for each language (e.g. a separate model) makes more sense, since you don't want to have to add extra database columns to everything just because somebody translated 14 strings of the existing 978 into Spanish. There's also a pretty strong argument that the Open Source / bazaar style of development leads to translations into more languages than almost all internal and proprietary products.
I think you'll need to be prepared to support both in-table and extra-table cases for holding translated copies. One might even consider also storing on-disk (file-based) copy for translated content, but that's a whole other storage model and I wouldn't do it in the initial project.
I suspect you, Marc, already realise all this, but I've had to explain the differing models to a few people over the past 12 months or so when they've been wondering about some Grand Unifed Solution in this space, so it's probably important to be able to address both situations, at least to the point of saying "we've decided this situation is out-of-scope" and leaving that up to some other project.
Having two or three projects for differing storage models isn't the end of the world, either, by the way. One tool to do a particular job well is a good philosophy, not just in Unix-like systems. The job might be "storing translations in related tables to support the bazaar style of addition" or "supporting fixed / small numbers of translations inline".
Just a suggestion: maybe sending the poll link to the django-i18n mailing-list?
ReplyDeleteMalcolm: you are right, there is a huge difference between these models.
ReplyDeleteI'm not really convinced we should try and implement both of them in a single library; joining these implementations means increased complexity and more work for maintainers.
But if we could make our libraries use the same API and minimize differences in behaviour, we would allow creating apps that are independent on the multilingual "backend". You could just take, say, the multilingual flatpages app and use it without any changes both in internals and large, open source projects.
There are still some technical problems, as in some places the abstractions crack and leak (ie. the save method), but I think we can find solutions to those.
You may also want to read my entry about translation in Django, even if it is a completely different way, but used twice in practice: http://www.rafaljonca.org/blog/2009/03/08/third-style-django-multilingual-data-handling/
ReplyDeletejust wondering if anyone has checked the issues on :
ReplyDeletehttp://code.google.com/p/django-transmeta/issues/list
i personaly think that "column storing" is better when there are lots of languages. I found that extra table approach is very slow with lots of data also.