Python And Internationalization maybe a pre-pep?
bkelley at wi.mit.edu
Sun Jan 11 22:51:12 CET 2004
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
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.
More information about the Python-list