OK, after digging around the django source, it seems that the database cursors, where the SITE_ID is read runs at a different thread. I also looked into the translation framework, it uses "currentThread" to fetch the current active translation. So what should I do ? This is tricky stuff...
On May 14, 3:52 am, orestis <[EMAIL PROTECTED]> wrote: > Hello, > > I'm having a weird python error, and I can't seem to find out what's > wrong. > > I wanted to extend the site framework, so I can use it for > multilingual content. The way to do this is to override the SITE_ID > with a function: > > import threadlocals > def SITE_ID(): > lang = threadlocals.get_current_lang() > if lang=='en': return 1 > else: return 2 > > I've also added the ThreadLocals middleware discussed in the CookBook > [0]. The problem is, I think, the funky code path of django settings. > I see the ThreadLocals middleware imported 4 times, and, all in all, > there are different threadlocal objects that of course return > different results. > > Is there any way to troubleshoot this ? Am I missing something big > here ? I know the sites framework wasn't designed to do this, but it > seemed a natural extension for me. > > To rephrase: Is there a way I can guarantee that the threadlocal > object I create in the middleware will be the same that the SITE_ID > function in the settings file will get ? > > [0]http://code.djangoproject.com/wiki/CookBookThreadlocalsAndUser --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
