>so 'thing' and 'language' will be unique_together. and to actually >do the translation, a form which will give side by side areas, one >displaying the values in 'Thing' and the other giving space to fill >in the values for 'TranslatedThing'. >TranslatedThing would only have those fields in Thing that are text. >Thing, when displayed, would have to check if there is a >translation available and if so, lift those fields from >TranslatedThing.
Exactly. It's very much like what gettext already does, only extended to the database. This stuff even could be nicely made into some abstract stuff - just write a model-constructor that takes an available model, pulls out all string fields and adds the language and the foreign key field and produces a new TranslatedSomething model class. Additionally you would need some user interface to make translations easier and maybe add two timestamps to see when the main object changed and so the translations are outdated. Throw in some custom permissions where translators only get edit rights on the translation table, and only view rights for the main table, and add a view to the admin and it should be useable as a start. I actually planned on doing that, but did put that on the back burner because of magic removal - that branch will change a lot in the model stuff, so it doesn't make sense to start now with something that goes that deep into the innards if those innards are about to change in a few weeks. bye, Georg
