[I18n-sig] Python Translation

[Guido van Rossum]

> [dindin2k@yahoo.com]
> 
> > Is there any working/ target towards translating Python to other
> > languages. i.e.  Some sort of structure like the *.po files in KDE such
> > that native languages can be substituted for the standards keywords.
> > Are there any plans to port Python to other (human) languages.

[pinard@iro.umontreal.ca]
> I would not think there is.  Some while ago, I wrote to Guido about i18n
> issues, and to my surprise, he replied quite strongly against the above
> suggestion, which I did not even make in my letter.  So, I presumed the
> issue was rather hot for him, for him to read it where not written :-).
> The main point of Guido is that it goes against source portability.
> 
> Yet, and even I do not remember having discussed this with Guido, I think
> it would be a good idea.  Some shops develop in-house code never meant
> to be exported, and it would locally help a lot, and not hurt everybody
> outside, being able to use diacritics within identifiers, and even
> translated keywords.  For one of my contracts, I'm working in such a shop.
> 
> I had a very comfortable experience in such things when I was younger,
> which lasted for many years, using a French adaptation of a Pascal compiler.
> See `http://www.iro.umontreal.ca/~pinard/accents/bonjour.tar.gz' to see some
> archived code from this period (better to like French and CDC machines! :-).
> 
> My point is that source portability might be a concern for some, but not for
> everybody, and I wish Python is open enough to not impose source portability
> where it has no meaning.  If Python may be nationally comfortable, just
> let it be, and let users choose where their priorities are.

Let me restate my position.  It's not a priority for me, and I believe
that most in the Python community probably don't see it as a priority
for themselves either.  There is so much else to do that I don't see
myself putting effort in it.

But if it is a priority for you, I won't stop you!  It would probably
best be implemented as a custom translator.  We're thinking about
making the Python chain of command (input loop -> parser -> compiler
-> optimizer -> bytecode interpreter -> runtime) more pluggable in
future (post-2.0) versions, and an internationalization pass would
easily plug in there.

--Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)