Need for an internationalization/translation system not request-based

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

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 [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

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
<http://bazaar.launchpad.net/~bronger/bobcat/main/annotate/head%3A/src/bobcatlib/i18n.py>.
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: [hidden email]
                                  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 [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

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

Jarek Zgoda-7
In reply to this post by Enrico Sartorello

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&D, Redefine
[hidden email]


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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&D, Redefine
> [hidden email]

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

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

Malcolm Tredinnick
In reply to this post by Jarek Zgoda-7

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 [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

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

Jarek Zgoda-7

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&D, Redefine
[hidden email]


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

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

Jarek Zgoda-7
In reply to this post by Andrea Zilio

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 <[hidden email]> 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&D, Redefine
[hidden email]


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>

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 <[hidden email]> 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&D, Redefine
[hidden email]






--
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 [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

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

Jarek Zgoda-7

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&D, Redefine
[hidden email]


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

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 [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---