Python And Internationalization maybe a pre-pep?

[Brian Kelley]

Martin v. Loewis wrote:
> Brian Kelley wrote:
> 
>> Essentially, everything looks like this
>> _("STRING")
>>
>> I got to thinking that this is python, I shouldn't have to do this.  
>> Why not have a mechanism to capture this data at compile time?
> 
> 
> Precisely because it is Python you should have to do this. The language
> that looks like line noise is a different one...
> 
> Explicit is better than implicit.
> Simple is better than complex.

I suppose we see a little differently here.  What I am suggesting I 
think is still explicit, the major difference is that when the code is 
compiled the internationalization tables are generated.

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 have also played with

international("STRING")

>> if a value exists in the international table for 
>> the given string, the string is converted to the current locale.
> 
> Using what textual domain?
> 
I am using the same mechanism as gettext but tying it into the "import 
locale" mechanism.

>> Now, I don't know if this is a good idea or not, and I may be 
>> reinventing some wheels, but it has some appealing characteristics and 
>> ties in with the gettext system really well.  Of course, I'm a bit 
>> leary with changing the python parser but I was uncomfortable with the 
>> two step process of writing the code, then passing it through a source 
>> analyzer so that it could be internationalized.
> 
> What is your problem with that technique? You have to extract the
> strings *anyway*, because the translators should get a list of the
> strings to translate, and not need to worry with your source code.

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 :)

>> So, am I being silly, redundant or just plain different?
> 
> I do wonder what kind of application are you looking at. How
> many strings? How many different translators? How often do
> the strings change? Are the strings presented to the immediate
> user of the application sitting in front of the terminal where
> the application is running, or are there multiple simultaneous
> accesses to the same application, e.g. through a Web server?

The number of strings doesn't really matter I think as long as you can 
automatically generate the ones that need to be translated.  Both 
mechanisms do this.

I hadn't previously thought about multiple simultaneous users but this 
could fit in nicely.  After some experimentation with the string 
classes, it turns out that as long as the __repr__ of the string stays 
unchanged, i.e. in this case the original english version, then the 
__str__ of a string (the locale specific changes) can change willy-nilly 
and not affect things like dictionaries and class name lookups.

Perhaps I am optimizing the wrong end of the stick.  I could change the 
gettext _("STRING") functionality to (mostly) do what I want without the 
need for parser changes.  However, I was entranced by the thought of 
writing (in normal python)

raise Exception(i"You shouldn't reach this exception at line %s"%line)

and automatically generating the translation files at compile time.  Of 
course this is different than

raise Exception(_("You shouldn't reach this exception at line %s"%line))

which generates them at run-time or by using the source code-analyzer. 
I personally think the first one is slightly more explicit.  Perhaps

raise Exception(
   internationalize("You shouldn't reach this exception at line %s"%line)
)

would be better.

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.

I suppose that there really isn't much difference in the long run as 
long as tools exist that make these translations relatively easy but I 
can't quite shake the thought of trying to teach my brother, a 
biologist, how to enable localization in his code in an easy manner.

Anyway, you have made good points and maybe all I need are some better 
integrated tools for localizing my applications.

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

Brian