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
_______________________________________________
IDLE-dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/idle-dev
