On Thu, 2008-07-17 at 08:26 -0700, Valery wrote:
> Hi Malcolm,
>
> > It's not documented in thei18n.txt file (which needs a bit of a rewrite
> > and splitting up once the docs reorganisation lands in trunk), but have
> > a look at the activate() function in
> > django/utils/translation/trans_real.py.
>
> according to what is stated here:
> http://code.djangoproject.com/browser/django/trunk/django/utils/translation/trans_real.py?rev=6582#L189
>
> The setting is applied to a current thread. Well, could I be sure that
> other HTTP-requests handled by the same thread wouldn't be affected by
> this setting? I mean, my language setting should be applied to the
> current single HTTP-request (for a given URL) only.
Since the language is set each time (by the middleware and by your
code), each request will be operating under the same assumptions. If you
change nothing then, yes, subsequent requests will use the same
settings. But that's why you will be setting it the same way each time.
Either by a common entry point for your views, or using middleware or
however is most convenient for your code.
You could even do something like this if you wanted it to be guaranteed
to be restricted to the view:
original_locale = translation.get_language()
translation.activate(new_locale)
try:
...
output = render_to_string(....)
...
return HttpResponse(output)
finally:
translation.activate(original_locale)
Yes, the "active language" is per-thread, but it's really per-request
since it's set anew for each request (unless you have wildly different
code paths and very inconsistent code). As I think I mentioned in my
original resopnse, this is exactly how Django sets the active language
with the i18n middleware and in other places. How you choose to set the
language each time is going to be dependent on your circumstances and I
cannot possibly lay out all the possibilities, since they are literally
boundless. At some point it's a matter of just writing the code.
> I start to believe that it is impossible to control translation
> language of a view from inside of view functions. Although I wouldn't
> find this as a very odd use case.
If that was true, it would not be possible to use translations at all in
Django, since this is how the whole i18n support works (it is really
just something that is called right before your view).
Regards,
Malcolm
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
