Re: Need for an internationalization/translation system not request-based

[Malcolm Tredinnick]

On Thu, 2009-08-13 at 10:11 +0200, Jarek Zgoda wrote:
> Wiadomość napisana w dniu 2009-08-13, o godz. 09:38, przez Enrico  
> Sartorello:
> 
> > Nice information, so we can go ahead working with activate() :-)
> >
> > Let me ask you one more question: in your code, i see you're using  
> > django.util.translation.get_language(), it's not a documented  
> > function and according to django policies it can be changed or  
> > removed in any new release.
> > Perhaps it's better using request.LANGUAGE_CODE?
> 
> 
> This function looks like part of public interface and the page 
> http://docs.djangoproject.com/en/dev/misc/api-stability/ 
>   lists the whole internationalization subsystem as stable API so I'd  
> not worry.

Well, it says that anything documented in the internationalization
subsystem is stable API. So the original poster still has a point.

But let's not worry about semantics too much here. I am quite willing to
say that get_language() is stable API (I'm kind of the de-factor i18n
sub-system maintainer, so I doubt I'll get any real arguments there). It
hasn't changed in years and it does what is advertised. It's also
needed, for exactly the reasons Jarek points out. Let's just document it
and help people out.

Generally, we haven't documented a lot of the internals of the i18n
stuff for low-level customisation. Ramiro Morales has been doing some
good work over the past few months helping sort out the documentation
there -- splitting up some confusing single file i18n stuff into i18n
and l10n and template versus backend. We're now in a position to start
filling in some of the gaps.

In short: feel free to use get_language() and unless some amazingly
hidden bug or security hole is found in it, the API will not change. I'm
happy to take a documentation patch that documents what it does (Jarek's
code example is a good place to start -- that's the sort of thing I
would include in the docs).

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 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Need for an internationalization/translation system not request-based

[Jarek Zgoda]

Wiadomość napisana w dniu 2009-08-13, o godz. 09:38, przez Enrico  
Sartorello:

> Nice information, so we can go ahead working with activate() :-)
>
> Let me ask you one more question: in your code, i see you're using  
> django.util.translation.get_language(), it's not a documented  
> function and according to django policies it can be changed or  
> removed in any new release.
> Perhaps it's better using request.LANGUAGE_CODE?


This function looks like part of public interface and the page 
http://docs.djangoproject.com/en/dev/misc/api-stability/ 
  lists the whole internationalization subsystem as stable API so I'd  
not worry.

get_language() gives you current language for the thread, which may be  
already different than request.LANGUAGE_CODE.

-- 
Artificial intelligence stands no chance against natural stupidity

Jarek Zgoda, R, Redefine
jarek.zg...@redefine.pl


--~--~-~--~~~---~--~~
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 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Need for an internationalization/translation system not request-based

[Enrico Sartorello]

Nice information, so we can go ahead working with activate() :-)

Let me ask you one more question: in your code, i see you're using
django.util.translation.get_language(), it's not a documented function and
according to django policies it can be changed or removed in any new
release.
Perhaps it's better using request.LANGUAGE_CODE?

2009/8/13 Jarek Zgoda 

>
> Wiadomość napisana w dniu 2009-08-12, o godz. 17:11, przez Andrea Zilio:
>
> > I'm sorry, can you explain a little bit this problem? Or where I can
> > get info about it?
> >
> > On Aug 12, 3:48 pm, Jarek Zgoda  wrote:
> >> Wiadomość napisana w dniu 2009-08-12, o godz. 13:00, przez Enrico
> >> Sartorello:
> >>
> >>> i'm facing a problem developing with Django a Web Application: in
> >>> response to some events (for example, after an admin action) i
> >>> need to
> >>> sendemailsto some users of my site.
> >>
> >>> The problem arises when i want theseemailsto be translated in any
> >>> user-specific language: the Request object i have just contains the
> >>> language infos of the user that trigger the event, so it's not
> >>> what i
> >>> need.
> >>> Generally, LocaleMiddleware behaviour can't do that job, because is
> >>> based on sessions and cookies of a particular user.
> >>> Roughly speaking i need (at least) a way to manually decide which is
> >>> the language to apply for translations.
> >>
> >> OnceIneededtosendemailsinHungarianfromEnglishapplication and
> >> this worked.
> >>
> >> Before translating any string you need to know which language to use.
> >> If you have this information handy somewhere you can just switch the
> >> translation catalog safely in separated process environments
> >> (FastCGI,
> >> WSGI). As translation.activate() is process-wide, this approach is
> >> not
> >> safe in multithreaded environment if using static translation (not
> >> request-based).
>
>
> The problem: translate some text to language other than specified in
> request or statically in settings (but of course already known).
> The solution:
>
> def to_german():
> cur_lang = translation.get_language()
> try:
> translation.activate('de')
> german_text = translation.ugettext(u'This is some text')
> finally:
> translation.activate(cur_lang)
> return german_text
>
> I stand corrected that translation activation **is** thread safe and
> does not affect code running in another threads (mod_python might be
> the cause of my problems).
>
> --
> Artificial intelligence stands no chance against natural stupidity
>
> Jarek Zgoda, R, Redefine
> jarek.zg...@redefine.pl
>
>
> >
>


-- 
Enrico Sartorello

--~--~-~--~~~---~--~~
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 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Need for an internationalization/translation system not request-based

[Jarek Zgoda]

Wiadomość napisana w dniu 2009-08-12, o godz. 17:11, przez Andrea Zilio:

> I'm sorry, can you explain a little bit this problem? Or where I can
> get info about it?
>
> On Aug 12, 3:48 pm, Jarek Zgoda  wrote:
>> Wiadomość napisana w dniu 2009-08-12, o godz. 13:00, przez Enrico
>> Sartorello:
>>
>>> i'm facing a problem developing with Django a Web Application: in
>>> response to some events (for example, after an admin action) i  
>>> need to
>>> sendemailsto some users of my site.
>>
>>> The problem arises when i want theseemailsto be translated in any
>>> user-specific language: the Request object i have just contains the
>>> language infos of the user that trigger the event, so it's not  
>>> what i
>>> need.
>>> Generally, LocaleMiddleware behaviour can't do that job, because is
>>> based on sessions and cookies of a particular user.
>>> Roughly speaking i need (at least) a way to manually decide which is
>>> the language to apply for translations.
>>
>> OnceIneededtosendemailsinHungarianfromEnglishapplication and
>> this worked.
>>
>> Before translating any string you need to know which language to use.
>> If you have this information handy somewhere you can just switch the
>> translation catalog safely in separated process environments  
>> (FastCGI,
>> WSGI). As translation.activate() is process-wide, this approach is  
>> not
>> safe in multithreaded environment if using static translation (not
>> request-based).


The problem: translate some text to language other than specified in  
request or statically in settings (but of course already known).
The solution:

def to_german():
 cur_lang = translation.get_language()
 try:
 translation.activate('de')
 german_text = translation.ugettext(u'This is some text')
 finally:
 translation.activate(cur_lang)
 return german_text

I stand corrected that translation activation **is** thread safe and  
does not affect code running in another threads (mod_python might be  
the cause of my problems).

-- 
Artificial intelligence stands no chance against natural stupidity

Jarek Zgoda, R, Redefine
jarek.zg...@redefine.pl


--~--~-~--~~~---~--~~
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 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Need for an internationalization/translation system not request-based

[Jarek Zgoda]

Wiadomość napisana w dniu 2009-08-13, o godz. 04:31, przez Malcolm  
Tredinnick:

>> As translation.activate() is process-wide, this approach is not
>> safe in multithreaded environment if using static translation (not
>> request-based).
>
> This is not correct. The translation.activate() call is thread- 
> specific
> and definitely thread-safe. Otherwise Django's entire translation
> infrastructure wouldn't work.


Hmmm. Must be some kind of race condition in mod_python... Anyway, I  
was wrong, activate() is thread safe.

-- 
Artificial intelligence stands no chance against natural stupidity

Jarek Zgoda, R, Redefine
jarek.zg...@redefine.pl


--~--~-~--~~~---~--~~
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 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Need for an internationalization/translation system not request-based

[Malcolm Tredinnick]

On Wed, 2009-08-12 at 15:48 +0200, Jarek Zgoda wrote:
[...]
> As translation.activate() is process-wide, this approach is not  
> safe in multithreaded environment if using static translation (not  
> request-based).

This is not correct. The translation.activate() call is thread-specific
and definitely thread-safe. Otherwise Django's entire translation
infrastructure wouldn't work.

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 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Need for an internationalization/translation system not request-based

[Andrea Zilio]

I'm sorry, can you explain a little bit this problem? Or where I can
get info about it?

On Aug 12, 3:48 pm, Jarek Zgoda  wrote:
> Wiadomość napisana w dniu 2009-08-12, o godz. 13:00, przez Enrico  
> Sartorello:
>
> > i'm facing a problem developing with Django a Web Application: in
> > response to some events (for example, after an admin action) i need to
> >sendemailsto some users of my site.
>
> > The problem arises when i want theseemailsto be translated in any
> > user-specific language: the Request object i have just contains the
> > language infos of the user that trigger the event, so it's not what i
> > need.
> > Generally, LocaleMiddleware behaviour can't do that job, because is
> > based on sessions and cookies of a particular user.
> > Roughly speaking i need (at least) a way to manually decide which is
> > the language to apply for translations.
>
> OnceIneededtosendemailsinHungarianfromEnglishapplication and  
> this worked.
>
> Before translating any string you need to know which language to use.  
> If you have this information handy somewhere you can just switch the  
> translation catalog safely in separated process environments (FastCGI,  
> WSGI). As translation.activate() is process-wide, this approach is not  
> safe in multithreaded environment if using static translation (not  
> request-based).
>
> --
> Artificial intelligence stands no chance against natural stupidity
>
> Jarek Zgoda, R, Redefine
> jarek.zg...@redefine.pl

--~--~-~--~~~---~--~~
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 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Need for an internationalization/translation system not request-based

[Jarek Zgoda]

Wiadomość napisana w dniu 2009-08-12, o godz. 13:00, przez Enrico  
Sartorello:

> i'm facing a problem developing with Django a Web Application: in
> response to some events (for example, after an admin action) i need to
> send emails to some users of my site.
>
> The problem arises when i want these emails to be translated in any
> user-specific language: the Request object i have just contains the
> language infos of the user that trigger the event, so it's not what i
> need.
> Generally, LocaleMiddleware behaviour can't do that job, because is
> based on sessions and cookies of a particular user.
> Roughly speaking i need (at least) a way to manually decide which is
> the language to apply for translations.

Once I needed to send emails in Hungarian from English application and  
this worked.

Before translating any string you need to know which language to use.  
If you have this information handy somewhere you can just switch the  
translation catalog safely in separated process environments (FastCGI,  
WSGI). As translation.activate() is process-wide, this approach is not  
safe in multithreaded environment if using static translation (not  
request-based).

-- 
Artificial intelligence stands no chance against natural stupidity

Jarek Zgoda, R, Redefine
jarek.zg...@redefine.pl


--~--~-~--~~~---~--~~
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 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Need for an internationalization/translation system not request-based

[Torsten Bronger]

Hallöchen!

Enrico Sartorello writes:

> [...]
>
> Roughly speaking i need (at least) a way to manually decide which
> is the language to apply for translations.

I had the same problem.  My solution (not in Django) can be seen at
.
You can use this module.  This only dependency of "common" can be
removed easily.

However, I'm very interested in a simpler approach.  :-)

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
   Jabber ID: torsten.bron...@jabber.rwth-aachen.de
  or http://bronger-jmp.appspot.com


--~--~-~--~~~---~--~~
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 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Need for an internationalization/translation system not request-based

[Enrico Sartorello]

Hi all,
i'm facing a problem developing with Django a Web Application: in
response to some events (for example, after an admin action) i need to
send emails to some users of my site.

The problem arises when i want these emails to be translated in any
user-specific language: the Request object i have just contains the
language infos of the user that trigger the event, so it's not what i
need.
Generally, LocaleMiddleware behaviour can't do that job, because is
based on sessions and cookies of a particular user.
Roughly speaking i need (at least) a way to manually decide which is
the language to apply for translations.

I've tried to search the web in order to look for a solution but i
wasn't able to find it.
For example, django-multilingual package doesn't affect the way the
translations are made.

Can somebody help me?

Thanks for the attention,

Enrico

--~--~-~--~~~---~--~~
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 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---