Python And Internationalization maybe a pre-pep?

[Martin v. Loewis]

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.

> Which is just a subtype of string.  When python parses this it adds it 
> in an entry in the internationalization table.  (essentially a 
> dictionary)  It also addes it as an entry to the standard gettext 
> mechanism to indicate strings that need to be localized.  When the 
> string is created, if a value exists in the international table for the 
> given string, the string is converted to the current locale.

Using what textual domain?

> 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.

> 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?

Regards,
Martin