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.
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
and then use getModel instead. Hacking the internals of an ORM is
asking for trouble.
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.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
