Comments on Marc Garcia & The Python: django-multilingual syntax poll

just wondering if anyone has checked the issues on...

2009-03-16T13:05:00.000+01:00

just wondering if anyone has checked the issues on :
http://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.

You may also want to read my entry about translati...

2009-03-10T06:52:00.000+01:00

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/

Malcolm: you are right, there is a huge difference...

2009-03-10T01:48:00.000+01:00

Malcolm: you are right, there is a huge difference between these models.

I'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.

Just a suggestion: maybe sending the poll link to ...

2009-03-10T01:33:00.000+01:00

Just a suggestion: maybe sending the poll link to the django-i18n mailing-list?

I'm reluctant to subscribe to yet another mailing ...

2009-03-10T01:08:00.000+01:00

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...

Please 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".