nesh napisaĆ(a): > > The "separate columns for each language" backend does not require any > > changed to Django, as far as I can see. Even table updates in syncdb > > are doable without touching Django source. > > If you go this way you can drop class Translation altogether, it's little > awkward to require to define translatable > fields below class definition. IMHO better approach is to use (revamped ;)) > I18N(Char|Text)Field.
I like the Translation class because it is generic: it allows me to make any field translatable. I can easily imagine models with language-dependent: * URLFields: "Producer's web page describing the product in this language", * EmailField: "The right contact address for queries in this language", * SlugField: slug to use when accessing this version of an object; I want /en/category-name-1/ and /pl/nazwa-kategorii-1/ point to the same Category object, but in different languages, * ImageField: an image of something containing localized text, * XMLField: XML documents with localized content, This is off the top of my head after a quick look at the model documentation page, there are probably more use cases I can not think of right now. It will also work with fields that are not in Django core. > 2. Models which contain data that depends on the language > --------------------------------------------------------- > > Using language field paired with some custom manager is the simplest method. > IMHO this is trivial to achieve. Simply add one field and some manager > methods. OTOH if one have lot's of models like > this some level of the automation is nice to have. It is only that simple if you do not need to track the connection between different language versions of the same content. In that case I agree, it is trivial, but this means we are not talking about translations anymore, only separate pieces of data in different languages. The connection is the added value I need here. > 3. Mixed models, translatable and not translatable data together > ---------------------------------------------------------------- > > Your's 'separate table' or 'separate columns' approach. > > This is a ideal solution if it can be implemented in the general way without > constraints to other model properties > (unique, unique_together, db_index, validators, ...) These two cases are the same to me. Case 2 simply contains the minimum non-translatable information: a "master" ID shared between all the translations, allowing me to find all the translations of the same content. Good point about unique and unique_together, I haven't thought about it yet. > Ideally translatable model will behave like any ordinary model hiding the > fact that some his fields are stored somewhere > else (in separate table or separate columns) and it will support all of the > common model operations. My thoughts exactly :) -mk --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---