Traceback Internationalization Proposal

[reingart]

BPO	16344
Nosy	@birkenfeld, @rhettinger, @terryjreedy, @pitrou, @ezio-melotti, @stevendaprano, @bitdancer
Files	traceback_internationalization_proposal.patch: initial patch to add Py_GETTEXT i18n (EXPERIMENTAL) pep_i18n_traceback.txt: PEP draft for traceback internationalization proposal

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2012-11-01.05:12:50.938>
created_at = <Date 2012-10-28.06:57:37.640>
labels = ['interpreter-core', 'type-feature', 'expert-unicode']
title = 'Traceback Internationalization Proposal'
updated_at = <Date 2015-05-04.04:36:21.571>
user = 'https://bugs.python.org/reingart'

bugs.python.org fields:

activity = <Date 2015-05-04.04:36:21.571>
actor = 'reingart'
assignee = 'none'
closed = True
closed_date = <Date 2012-11-01.05:12:50.938>
closer = 'rhettinger'
components = ['Interpreter Core', 'Unicode']
creation = <Date 2012-10-28.06:57:37.640>
creator = 'reingart'
dependencies = []
files = ['27756', '27757']
hgrepos = []
issue_num = 16344
keywords = ['patch']
message_count = 30.0
messages = ['173998', '174005', '174007', '174008', '174013', '174081', '174084', '174092', '174116', '174209', '174212', '174215', '174232', '174243', '174257', '174298', '174343', '174345', '174350', '174351', '174353', '174354', '174355', '174361', '174364', '174389', '174390', '174391', '242541', '242543']
nosy_count = 10.0
nosy_names = ['georg.brandl', 'rhettinger', 'terry.reedy', 'pitrou', 'ezio.melotti', 'steven.daprano', 'r.david.murray', 'neologix', 'Ramchandra Apte', 'reingart']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = None
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue16344'
versions = ['Python 3.4']

[reingart]

I'm opening this ticket to organize patches for a proposal of a GETTEXT-based message translation for exception/tracebacks as described in:

<http://python.org.ar/pyar/TracebackInternationalizationProposal\>

This requires the patch in issue bpo-16343

Attached is a patch for a proof of concept, it includes:

• pyi18n.h: header for Py_GETTEXT macro definition
• Locale/es.po: sample Spanish language messages translation file
• test_i18n.py: basic tests
• errors.c: patched PyErr_SetString(), PyErr_Format()
• traceback.c: patched tb_displayline(), PyTraceBack_Print()
• pythonrun.c: patched _Py_InitializeEx_Private()
• site.py: patched main() and added seti18n()

[birkenfeld]

Has this been discussed on python-dev before? I see that your proposal is in PEP form; it would be a good idea to post it to python-dev since this is not a change that can be done without a PEP.

[reingart]

This has been discussed in python-ideas two years ago (I've resurrected the thread there)

Sadly I didn't have time for this before, but as in 15 days we have a sprint on cpython at PyCon Argetina 2012, maybe it would be a good idea discuss this again.

Sorry if I've made any mistake, this is my second patch here, and my C skills are rusty as I've mentioned in the other issue.

[reingart]

BTW, I'd write a draft PEP for this (attached), the online version is at <http://python.org.ar/pyar/TracebackInternationalizationProposal\>

Just let me know if it has to be uploaded/discussed elsewere

[ezio-melotti]

I'm -1 on the idea for the following reasons:

• any "serious" developer is expected to know English, and novice developers should be encouraged to learn it, rather than being confined to a localized environment;
• even if the error messages are translated, all the keywords and names would still be in English, and the result will be even more confusing;
• even if the feature might be useful for a small subset of people, I think it's not big enough and the feature shouldn't be included in Python by default (OTOH I'm not sure how easy it is to provide it as an external module);
• translating and maintaining translations of all the error messages requires lot of work and we will be forced to either commit patches without translations or to hold them until all the translations are available;
• I personally prefer to use English for "technical" stuff, because either the translations keep many English word or they end up translating them with something improbable and result in something that is even more cryptic;
• a set of available languages should be defined and maintained;
• googling and/or reporting localized errors doesn't work too well, and the mechanism proposed in the PEP to restore the language is somewhat cumbersome IMHO;
• people might come across a localized version of Python and have to know how to restore the language before being able to use it;
• this will also make debugging more difficult if it happens in places where the user can't easily change the language (e.g. server logs);

[reingart]

"serious" developers? sorry but I think that is a unfortunate phrase that goes against the Python Diversity Statement
What about young pupil?
What about non-programmers (i.e. accountants)?
In some places (like my country, public schools), English is not teach formally until the University.

And I don't think non-English speakers are just a subset of users.
Come on, English is not even the top native tongue (that is Chinese Mandarin). English can be one of the most spoken languages, but even that metric only reach 1/7th of the total world population. Other languages like Spanish or Portuguese are also rising.

http://en.wikipedia.org/wiki/Language#Linguistic_diversity

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

C:\Python32>python
Python 3.2.2 (default, Sep  4 2011, 09:51:08) [MSC v.1500 32 bit (Intel)] on win 32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.listdir("J:\\")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
WindowsError: [Error 3] El sistema no puede encontrar la ruta especificada: 'J:\\*.*'

PostgreSQL already translates error messages too:

C:\Program Files\PostgreSQL\9.0\bin>psql
psql (9.0.3)
Digite «help» para obtener ayuda.

Mariano=> SELECT * FROM nowhere;
ERROR: no existe la relación «nowhere»
LÍNEA 1: SELECT * FROM nowhere;
^

And Bash too:

reingart@desktop:~/cpython$ ls /nowhere
ls: no se puede acceder a /nowhere: No existe el archivo o el directorio

Of course, there is no need to translate keywords or libraries (as SQL sentences and bash command are not translated, just messages are), 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.

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.

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)
For advanced users or logging, it could be disabled at all!

Finally, you're correct about that translation is not easy job, and this proposal (traceback internationalization) is just the tip of the iceberg (even more work will be needed in other aspects to get a full localization).
If PostgreSQL and other tools could do that, why Python could not?

[pitrou]

I think the PEP should be proposed on python-dev or python-ideas.
Also, it's probably better if the PEP is encoded in utf-8, not latin-1.

[terryjreedy]

I am sympathetic with non-English speakers wanting a native-language translation. But I think the interpreter should *always* emit the standard message and that any translation should be an addition, not a replacement. This would maintain discoverablity and help people learn the English version, not hinder it.

The real question to me is how deep in the interpreter such support should go. Third party shells can (and sometimes do) intercept tracebacks and reformat (and translate) as they wish. But there would be advantages and disadvanteges is adding the translation sooner.

[ezio-melotti]

"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?

[RamchandraApte]

Unless Python's grammar is translated into other languages I'm -1 on this.
I don't see any use of this. You anyway have to know English to understand the docs and Python's grammar is English.
@ezio melotti

> 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.

English is actually oppressing other languages. Schools put a priority on English but not on native languages. Languages must be preserved because they contain culture (in one language, the future is behind because you can't see it and the past is in front of you.)

[neologix]

Schools put a priority on English but not on native languages. Languages must be preserved because they contain culture

Of course, but the main goal of a language is to communicate.

As it stand, English is the language which is the most likely to be understood by Python users and developers (I don't count Esperanto ;-).

It'll get tricky if in a couple months, we start getting bug reports with traceback in Finnish or French...

[terryjreedy]

It'll get tricky if in a couple months, we start getting bug reports with traceback in Finnish or French...

That is another reason to *always* output the standard English message first. I think this was discussed a couple of years ago on PyDev, or maybe another issue. I think the proposal to *replace* English messages should be rejected.