On 3/26/07, Jeremy Bowers <[EMAIL PROTECTED]> wrote: > > Wolfram Kriesing wrote: > > The main reason I need this is that I want to have a transparent model > > that switches the underlying language (the according DB table it > > should work on) on the fly, so i can keep hacking away without > > language switching before every access via my model. > > > Why do you have a separate table for each translation? Absent > extraordinary circumstances, the correct solution is to add an > indication of which language a given string is in to the one central table.
How do you mean? We have been discussing the various solutions a while and came to the conclusion that we go by the following model. We only have 2 languages! 1) We have three models: XXXCommon - contains all the data that are common for XXX XXXEnglish - contains only the english data and has a foreign key to XXXCommon, for easy reference XXXGerman - contains only the german plus ref to XXXCommon 2) We have a view XXX Using the view/model XXX you dont need to worry about the language, always the user's prefered language is used to retreive the data, you can even update the view, it updates the right localized table. Now I only need to switch betweentwo views, one is for the prefered language english, the other one for german. Since mysql doesnt provide parameterized views we have to provide two views. And now I would like to switch between those two seemlessly. Therefore I need to dynamically modify db_table. > Failing that, remember that classes in Python are first-class objects > and can be freely assigned to variables. Rather than trying to hack the > internals of Django, consider: > > class French(Model): ... > class English(Model): ... > class Elvish(Model): ... > > def getModel(params, you, decide, with): > if whatever: > return Elvish i gave my reasoning why i dont want this: The main reason I need this is that I want to have a transparent model that switches the underlying language (the according DB table it should work on) on the fly, so i can keep hacking away without language switching before every access via my model. > > and then use getModel instead. Hacking the internals of an ORM is > asking for trouble. i completely agree :-) thats why i try to discuss it here thx for opinions, I am rethinking things and might need to drastically simplify ... Thank you Wolfram > However, unless those Models actually vary in structure on a > per-language basis, you really need one table. A composite uniqueness > constraint in most DBs will prevent duplicate definitions. > > > > -- cu Wolfram --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
