>Wouldn't it be a cleaner approach to seperate language dependent >content completely from the actual models. It's more "DRY" because you >only define the text fields on one place.
Depends. My idea is to have a situation similar with gettext: you provide default content that can be translated. If there is no translation, you already have the default content to fall back too. The nice thing about the gettext way is, you allways have a "full working system" - and translations are optional. To keep with DRY I wrote about the model-creation function - I did something like that once for my abstract tagging stuff, it's not really that complicated to generate models dynamically. So the result would be something like this: class Thing(meta.Model): title = .... description = .... content = .... make_translation_model(Thing) This would create a model dynamically, named TranslationThing, that carries only the string fields (CharField and TextField) from the original model and reference the language. That way you only write your model once and your model is "complete" in the sense that you only need to look at the translation model if you want to check for actual translations - if you don't care for translations in your current code context, you just can work with the main model. Of course that might not be what everyone likes, that's why there is no prebuilt solution in the core - how to make a model translateable highly depends on how your site is structured. For me it's rather simple - my site has content in one primary language and I won't translate _all_ elements, only some of them. Others might need different solutions - especially if you can't make sure that all content is written in one primary language, but if your content is created in different languages and then cross-translated. In those situations a model like yours is much more appropriate. bye, Georg
