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

[Terry Jan Reedy]

On 4/17/2013 4:40 PM, Terry Jan Reedy wrote:
> 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.

Looking at the patch at http://bugs.python.org/issue17776
I see that the gettext mechanism leaves the string where it is, just 
enclosing it in _(...), so the above is not an issue.

> 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