Python And Internationalization maybe a pre-pep?

["Martin v. Löwis"]

Brian Kelley wrote:
> I don't see too much difference between using
> _("STRING")
> 
> to indicate a string to be internationalized and
> i"STRING"
> 
> Except that the later will be automatically noticed at compile time, not 
> run-time.

I'm not really sure what "compile time" is in Python. If it is the time
when the .pyc files are generated: What happens if the user using the
pyc files has a language different from the language of the
administrator creating the files?

Or, what precisely does it mean that it is "noticed"?


>> Using what textual domain?
>>
> I am using the same mechanism as gettext but tying it into the "import 
> locale" mechanism.

That does not answer my question? How precisely do you define the
textual domain?

In gettext, I typically put a function at the beginning of each module

def _(msg):
   return gettext.dgettext("grep", msg)

thus defining the textual domain as "grep". In your syntax, I see no
place to define the textual domain.

> I think this happens fine in both cases.  The mechanism for 
> internationalizing with wxPython just didn't feel, well, pythonic.  It 
> felt kind of tacked into place.  Of course I feel the same way about 
> most C macros :)

Can you be more specific? Do you dislike function calls?

> Perhaps I am optimizing the wrong end of the stick.  

Why is this an optimization in the first place? Do you make anything run
faster? If so, what and how?

> Compile-time generation just feels safer to me.  The code-analyzer might 
> miss special cases and what not, but if it is generated at compile time 
> it will work all the time.

Please again elaborate: What is compile-time, and what is generation,
in this context?

> Since you brought it up, how does gettext handle multiple users?  Does 
> each user get a different gettext library (dll) instance?

Gettext, in Python, is a pure Python module - so no DLL.

The gettext module provides the GNUTranslation object. You can have
multiple such objects, and need to explicitly use the language's
object on gettext() invocation, e.g.

   print current_language.gettext("This is good")

If you can be certain that users will be subsequent, you can do

def _(msg):
    return current_language.gettext(msg)

print _("This is good")

There might be other ways to determine the current context, e.g.
by looking at thread state. In that case, you still can use
the _ function, but implement it in looking at the thread state.

Regards,
Martin