> "serious" developers? sorry but I think that is a unfortunate phrase
> that goes against the Python Diversity Statement

With "serious" I just mean anyone that wants to continue programming, as opposed as someone doing e.g. a one-off course at university (hence the quotes).  The whole ecosystem around Python and most of the other programming languages is mostly in English, and anyone that doesn't know English will have to face many other problems later on (e.g. no localized documentation and blog posts).

There are two solutions to this problem:
1) adapt the language to the users;
2) teach the users English;

While the first (i.e. what you are proposing) works as a short term solution, I believe the second is a much better long term solution, because IMHO users will anyway have to learn English sooner or later.


> In some places (like my country, public schools), English is not
> teach formally until the University.

This is very unfortunate -- I was under the impression that teaching English in middle/high schools was already common in most of the countries.

> And I don't think non-English speakers are just a subset of users.

Do you mean people that aren't native English speakers or people who don't even grasp enough English to understand the error messages?

> BTW, as the draft says, Python is the offender here, as other error
> messages are already translated (including the OS ones, even inside
> Python!):

This is another thing that I dislike, for the aforementioned reasons.  I've seen buildbots reporting unintelligible error messages in German, and just a few days ago I even came across a mercurial version in Russian.
It makes somewhat sense to translate OS error messages, because they are read by regular users that have a localized OS and expect localized messages.  The same could be said for bash, even if the distinction between "regular users" and "developers" starts to fade a bit here.


> I don't see why this could cause confusion, instead that, I think
> python would become more consistent with other tools and thus more 
> easy to use.

For example the other day I saw a student confused by this error message:
>>> a, b = 1, 2, 3
ValueError: too many values to unpack (expected 2)

The offender here is most likely the word "unpack".  "Unpack" is closely related to the concept of tuple unpacking, so if the student is aware of what tuple unpacking is, he might fail to associate the problem with it if the error uses another word.  In addition, I can not think of any word that might be a suitable translation for "unpack" in my native language.  In Spanish "desempaquetar" could maybe be used, but I'm not sure how well it works.



> The mechanism to restore the language is the common one (used by 
> almost every other application that support i18n):
> >>> locale.setlocale(locale.LC_MESSAGES, "C")
> It should be not difficult for "serious" programmers to handle that :-)
> If that is a concern, it could be implemented a command line 
> parameter, a environment variable or a shortcut in locale module.

It's not difficult to change, but you would have to remember how to do it and what LC_* variable you should change.  Assuming this gets implemented it would most likely require a command line parameter and an envvar too.

> Anyway, people will not necessarily be faced by default with the 
> localized version, an if for example, a teacher has to jump to an 
> student machine, surely it could use it as messages will be probably 
> in the spoken language of the country (BTW, probably most of the 
> operating system components will be localized, not only Python)

FWIW I've been in the situation where neither my students nor I could understand the local language -- luckily all the machines were using English.

> If PostgreSQL and other tools could do that, why Python could not?

Does any other popular programming language do it?  And if so, how?