thank you very much. the important piece here was the "translation.get_language()" i oversaw that ...
thanks wolfram On 5/15/07, Aidas Bendoraitis <[EMAIL PROTECTED]> wrote: > > This should help you to solve almost all your multilingual problems: > http://www.djangosnippets.org/snippets/51/ > > Regards, > Aidas Bendoraitis aka Archatas > > > > On 5/15/07, Wolfram Kriesing <[EMAIL PROTECTED]> wrote: > > > > I have a bi-language (english and german) site. I try to hide the > > multi language part as best as I can from the programmer, by > > encapsulating it as best as I can in the model. > > An example: > > > > class Tag(models.Model): > > name_en = models.SlugField() > > name_de = models.SlugField() > > > > @property > > def name(self): > > "Return the name depending on the users language" > > if user_language=="en": # how can i get user_language? > > return self.name_en > > else: > > return self.name_de > > > > This would allow me to use the Tag-model anywhere without knowing the > > user's language, by accessing the property "name" and it handles the > > language stuff. > > This is a very much simplified example of what I actually need. > > It shows that inside a template I could simply write: > > {{ tag.name }} > > and get the proper translation. > > > > The problem: > > Here is the problem I don't get "user_language" without having access > > to the request! :-( > > > > > > The simple example above would solve small translation tasks, but I > > have another model, that has some more complex translation logic. I > > constructed this by using DB-views, and creating models that map > > directly to appropriate view. > > To demonstrate this: > > class DataEnglish(models.Model): > > id = .... > > title = .... > > abstract = ..... > > class Meta: > > db_table = "core_dataenglishview" > > > > class DataGerman(models.Model): > > id = .... > > title = .... > > abstract = ..... > > class Meta: > > db_table = "core_datagermanview" > > > > To abstract the language stuff, I would like to only access a model > > called "Data" which in turn maps to "DataGerman" for a german user and > > to "DataEnglish" to an english user. Unfortunately I only have access > > to the language via django.utils.translation.get_language_from_request > > when I have the request available. > > But I would like to use: > > Data.objects.all() > > Data.objects.filter() > > inside my code, without worrying about the language setting in the > > place where I read from the objects (of course for updating the > > objects I have to use DataGerman or DataEnglish explicitly, and I do). > > > > How can I achieve this in a clean way, without passsing the request > > around every time? > > > > > > My hacky solution: > > Write a middleware, that sets some "global" variable i.e. in > > settings.current_language and use this as language. That would work > > since every request has its thread/process that is running in apache, > > but that seems quite dirty. > > > > Any ideas? Or have my thoughts been going a completely wrong way? > > > > -- > > cu > > > > Wolfram > > > > > > > > > > > > -- cu Wolfram --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---