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

[Olivier Berger]

Hi.

Thanks of the detailed argumentation. But I feel it is going a bit too
far, wrt to IDLE and my initial query. Just responding quickly below to
a few elements. I'm not an i18n expert no an IDLE developer, so, this is
just MHO.

Terry Jan Reedy <tjreedy at udel.edu> writes:

> On 4/17/2013 6:47 AM, Olivier Berger wrote:

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

My main concern for the moment is the Menus and other "higher" elements
of UI, and not internationalization of Python as a whole.

Let's Keep It Simple Stupid for a start ;)

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

SNIP

>
> 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'll not (feed the troll ;-) respond on all aspects (interesting
discussion in general, but not specific to IDLE, I guess, and... maybe
that looks to me like beating a dead horse somehow).

My main goal, again, is just to avoid the kind of discrepency one could
notice when running IDLE next to other GUI tools (editors, text
processors, etc.) on most desktop envs where menus and dialogs are
internationalized.

I want to diminish the cognitive overhead of looking for a way to save a
program to the computer for beginners.

If others aren't interested by this issue, fine with me, but I just
expect them to not refuse patches that would address such an issue.

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

Yes, as many of these, with an order of priority that looks fine to me at
first sight.

SNIP

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

Exactly my idea... but maybe i18n isn't a problem after all... I'm just
starting the teaching process, so maybe not a big deal... still, I think
it can't harm caring for IDLE's i18n.

Best regards,
-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)