Python And Internationalization maybe a pre-pep?

[Brian Kelley]

Martin v. Löwis wrote:

> I'm uncertain how this relates to the internationalization tables
> you are proposing, but please recognize that a single application
> may have *multiple* such tables, called "textual domains". To
> find a translation, you not only need the message id, but you
> also need the textual domain.

I understand this.  I was just curious whether this should be internal 
or external to python.  Various comments have indicated that it really 
doesn't matter.  This might be a red-herring to the current discussion, 
let's forget that I mentioned parsing at all :)

>>This should tranparent to Gui Widgets and the like so you can place
>>i"Message" in a list box, it will automatically get internationalized
>>but when you get the result of the user selected, it still can be used
>>to dictionary look ups exactly the same as the original i"Message".
> 
> 
> Using what textual domain?

As I understand it, it doesn't matter.  I have been wrong before though. 
  The textual domains are set by setting the locale and what I 
considered the "neat" part was that the dictionary look ups are 
independent of textual domain.  That is, you could switch textual 
domains on the fly and not affect dictionary look-ups.  I don't think 
that with the original gettext system that this would work.  That is as 
I understand it, if you changed the locale you need to call the _() 
function again which means that any previous dictionaries would need to 
be re-created with the new string values.

> xgettext.py already performs very simple parsing of source files,
> to extract messages. Why reinvent the wheel?

I agree with this.  I just initially didn't like the idea of using an 
independent source code analyzer.  Let's assume that I will start with 
xgettext and modify that instead.

>>In either case, I far prefer using internation("This is good") over
>>the _("This is good") function call.
> 
> 
> So do call it internation(), or internationalization() or something
> else. It is just a function:

Ahh, but mine isn't a function, it is a subclass of string.

So my version of gettext, calling
_("Hello")

doesn't return the current localized string, it returns a string object 
that looks up on the fly the current localization for the purposes of 
printing, essentially str operations.

Your comments about looking at the thread state are quite useful, I 
might play with that.

Again, if I am reinventing the wheel on this, I apologize.  And again, 
thanks for bearing with me.

Brian