[Idle-dev] I18n of IDLE's interface ?

[Terry Jan Reedy]

On 4/17/2013 6:47 AM, Olivier Berger wrote:
> I've filed a wishlist at : http://bugs.python.org/issue17760 about the
> potential need for translated UI elements in IDLE. In our case, french
> would be an example language.
>
> It was suggested to me to forward the request to this list.

That was my suggestiion. Thank you for paying attention ;-).

> I hope this is not a FAQ (although I'd be surprised to be the first to
> raise this need), as I haven't checked the list archives.

Internationalization has been an issue, and a controversial one, for at 
least a decade. Let's categorize things that could be translated to 
reach more people.

For Python itself, there are the keywords (about 25), the builtin names 
(< 100), the stdlib module names (a few hundred), the names within 
stdlib modules (a few tens of thousands), docstrings, the tutorial, the 
other manuals, and let us not forget, the tracebacks, exception names, 
and exception messages.

For the community, there are mailing lists, web pages, and books 
(already done as people have taken the initiative to do so).\

For Idle, there is the UI and the belp page. The help page is currently 
a text file separate from the manual. There is an issue to synchronize 
the help file with the maunal chapter and then just use the manual 
chapter. Even when that is done, we could have a mechanism to grab 
translations of the manual chapter. I would be fine with that if there 
was a commitment from someone to do at least one translation.

> I'm sure some may object in the line of
> http://bugs.python.org/issue17760#msg187088 but I find it a bit odd to
> force this on users... which are free to set their system's locale to
> english if they *do* want to force Python beginners to learn english.

There are various reasons people oppose Il8n. Some apply to some 
categories more than others. I am sure you will appreciate some more 
than others.

1. Inertia: if it doesn't seem broke to me, why fix it?
2a. Self-interest 1: why should I help people write code that I cannot 
read or use?
2b. Self-interest 2: Why should we make the code base harder to maintain?
3. Visceral: I survived English, others can too.
4. Concern: programming, especially Python programming is international; 
a complete translation of everything will box people in national 
ghettos; this is ultimately a disservice to learners.
5a. Practicality 1: all the categories above are changing targets, 
nothing is fixed; all translations become obsolete sooner or later.
5b. Practicality 2: there is too much to translate everything; even if, 
for instance, keyword and builtin names were translated to native words 
and characters, people would still have to learn Latin characters to use 
the stdlib and read tracebacks and error messages.
6. Freedom: Python is given out freely; people are free to modify it 
with few restrictions; the core devs need not be involved.
7. A lack of volunteers to do the extra work required.

Point 2 lead some to object to allowing general unicode identifies even 
in Python 3.

'Moving targets' are a real concern. For instance, the 2.7 Tutorial is 
available in Spanish, but the last I knew, no 3.x Tutorial was, thus 
tending to tie Spanish-only Python users to Python 2.

> FYI, we for example have the oportunity to teach Python to all students
> in some classes in France (CPGE), and although they may have also some
> honest english curriculum too, I'd expect their computers to have some
> french locales, and the discrepency may look a bit surprising to some
> (whether or not these english strings only makes Python look more or
> less "sexy" is to be determined ;-).

Many of the objections above do not apply very much to Idle. I would 
expect that even some of the core devs use apps with non-English 
native-word menus. I think learning the keywords and a subset of builtin 
names (perhaps 50 total) is enough for a first Python course.

> I haven't investigated how IDLE handles UI elements, but could volunteer
> for helping on translations to french of any messages in .po or likes,

You have not specified which items you would translate. The File...Help 
menus? Right-context menus? Dialog boxes? Error-message boxes? Various 
help items? All of the above? Would only translating some elements be 
worthwhile?

There are people who think string literals should be collected together, 
separate from the code that uses them, where they can be easily found 
and modified, and not scattered about and hard-coded into expressions. 
But the latter can be easier in some cases.

Suppose, hypothetically, that Idle has a line like
     ErrBox("ConfigError: bad value")
Then someone posts an issue requesting that the error message be made 
more informative. With the hard-coded string, it is a simple fix:
     ErrBox("FileError: bad value {} for {} in {}".
         format(value, item, config_file))
It is easy to see that the format string and the format call match.

But if the string literal is elsewhere, the fixer has to go find it and 
fix whereever it is, complicating the patch.. It is no longer easy to 
see that the format string and format() call match.

If there are translations, the translations no longer work; instead they 
raise format string errors. So each translation has to be patched by the 
translator and tested before each release. Are you volunteering to do 
that for at least 5 years?

Of course, proper testing would mean having automated tests that causing 
each possible error to be raised. We should have that, but do not now. 
We would need to have that before separating format strings and format 
calls, even without translations.

Bottom line: a multilingual app is not trivial. Corporations pay people 
to attend to all the picky details.

> Looking forward to your opinions,

I would rather have people learn Python using Il*n'ized Idle than not at 
all. I would rather beginners struggle with Python itself than with the 
Idle interface.

--
Terry Jan Reedy