[I18n-sig] Python Translation
Guido van Rossum
guido@beopen.com
Sat, 02 Sep 2000 10:46:35 -0500
> [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/)