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
-~----------~----~----~----~------~----~------~--~---

Reply via email to