[Idle-dev] Forking Idle - translating menus, etc.

Terry Reedy tjreedy at udel.edu
Thu May 23 21:30:38 EDT 2019


On 5/23/2019 7:19 AM, Andre Roberge wrote:

> I'm currently working on an experimental fork of Idle. One of the many 
> things I plan to do is to see if I can have translatable menus to make 
> it more user-friendly for international users.  If there is interest, 
> this could presumably be back-ported to Idle. [Most other features I 
> have planned would not be relevant for Idle.] My plan is to use the 
> standard gettext approach, and have an additional language selector 
> menu, so that the language used for the UI can be changed while Idle is 
> running.

I have been at least somewhat in favor of having IDLE menu translations 
since before https://bugs.python.org/issue17776 was opened.  Even though 
I rejected the specific patch (see 2. below), I left the issue open to 
keep the idea open.  Given a new start, I would close it and open a new 
issue with a more specific title, such as 'Allow translations of IDLE 
menus".  I have been thinking about contacting you since I read, 
recently, something somewhere about you planning to work on menu 
translations.

Blocking issues:

1. Who writes patch? Many favor the idea and are willing to discuss it. 
Up to now, no one has been willing to the harder work, even with my 
help, of producing a patch I will accept.

2. Where translate?  The submitted patch decorated the submenu entries 
in idlelib.mainmenu.menudefs.  My objections, in brief, are that a) this 
makes the code uglier and harder to read and edit; b) this makes a 
permanent one-way change to an internal data structure; and c) this is 
unnecessary, as the sub-menu translations can and should be done 
somewhere in idlelib.editor.EdiorWindow.fill_menus, just before adding 
the label to a menu item.

At least one translation guideline I have read agrees with me on b) and 
c).  I believe your idea of dynamically switching languages would also 
be easier if the internal structure were left alone.

Currently the display labels for the menu bar are not contained in 
menudefs, but are translated to their display forms with caps and 
underscores elsewhere.  Most are translated twice.  In order to remove 
duplication and to be able to write them in their proper place along 
with the sub-menu labels, the display forms should be moved to menudefs. 
    (With dicts insertion ordered, menudefs can be a dict keyed on 
'file', etc.)  I may do this as a separate patch.  This would make it 
possible to write a file of labels to be translated in their proper 
order, as they appear in the doc.

3. Initial translation?  I was and am not willing to add code that has 
no immediate use and cannot be tested.  The patch on #17776 lacked a 
translation.  Someone subsequently did a different patch, not on the 
tracker, that had a translation, but the method struck me as too 
invasive of IDLE code and not scalable to multiple languages.

4. What translations? As I said on the issue, I cannot vet translators 
and translations, but I will not display unvetted translations.  (I 
could perhaps check a Spanish translation.)  This is the same issue that 
blocked PSF and coredev endorsement of doc translations.

A couple of years ago, a translation system was set up with Julien 
Palard responsible for vetting teams of translators. I am willing to 
include translations from those teams, and think that other coredevs 
might concur.  I would check on pydev before we got very far.  There 
might be some teams not part of the official project that would be accepted.

The current Japanese translation of the IDLE doc has a nearly complete 
translation of the menu section.  Lines like the following

"File メニュー (Shell ウィンドウ、Editor ウィンドウ)
New File [新規ファイル] "

can easily be reformatted to be usable by IDLE.  This solves the initial 
translation problem.  We would have to check if it is restricted to the BMP.

The Simplified Chinese translation only translates the File and Edit 
menus.  Assuming correct order, the English originals can be filled in. 
French and Korean do not yet translate the IDLE doc.  Once the feature 
was merged with at least one working language, and I was ready to merge 
more, I would post to the translation list and request more menu 
translations.

5. Machinery and translation file format.  I had and probably still have 
some unanswered questions about gettext.  See my first response on the 
issue.  I don't know what .mo and .po files look like.  I do not believe 
the translation group is using gettext, since they are not selecting 
strings from code.  If "_(...)" is not used for collecting labels from 
literals, is it needed for the dict lookup?

Once we have a system in place, I would like it to be easy for a core 
developer to take enough interest in IDLE to contribute a menu translation.

> 1. If I were to implement this in my fork, would there be some interest 
> in back-porting this to Idle?

Answered above.

> - - -
> 
> As I understand, the role of the underscore preceding a letter, such 
> as  ("Save _As...", "<<save-window-as-file>>"),  is to provide a quick 
> menu navigation using only the keyboard correct, and is only available 
> in Windows (and Linux?) but not on MacOS.   For example, typing in 

I presume this is usable on Linux.  Does macOS have no equivalent, or is 
it just not working with tk/tkinter/IDLE?

> succession "Alt", "o", "o", "enter" opens the Options menu.  I noticed 
> that a few items, such as Edit -> Find in files..., do not appear to be 
> reachable in this way (at least, not without using the arrow keys).

An oversight that should be fixed.

> 2. Assuming that the answer to question 1 is "yes", and that my 
> understanding of the role of the underscores is correct, is the quick 
> navigation considered an essential feature, and would have to be 
> retained in an "international" version of Idle?

No, with caveats.  It is an OS feature implemented by tk, not an IDLE 
feature.  If it exists in the Windows and Linux versions of a language, 
I would prefer that the translator add them.  The Japanese and Chinese 
doc translations do not, of course, have them.  I have no idea whether 
their native Windows' have such a feature.  I won't bother asking until 
a PR is merged or nearly ready, and I would do so without _s, even if it 
were appropriate to add later.

> Most menu items, but not all, have associated to them some keyboard 
> shortcuts. As I have only experience working in French and English, 
> these keyboard shortcuts do not need to be changed. However, they would 
> need to be changed for languages which do not include a subset of the 
> ASCII characters ... and I have no idea at the moment how to deal with 
> this and may end up not trying to support it in my fork.

Keyboard shortcuts are either built into tk and tkinter or defined in 
the Keys tab of the Settings dialog.  IDLE appends them to menu entries 
as a convenience to users, but they are otherwise independent of the 
menu.  Menu selections and shortcuts are separately bound to the 
pseudoevents that are bound to event handlers.  To keep the two 
independent, we must make sure to translate labels before appending 
shortcut text.

Anyone programming Python must have a keyboard capable of producing 
ascii characters.  My daughter sometimes uses Japanese character 
identifiers in private code and has never mentioned a problem with 
shortcuts.  Serhiy Storchaka once mentioned an issue with control chars 
working in Cyrillic versus Ascii mode, but that had nothing to do with 
the menus.

> 3. Assuming that the answer to question 1 is "yes", would supporting 
> localized keyboard shortcuts be required for back-porting the work I do 
> in my fork into Idle?

Irrelevant to this issue.  Keyboard shortcuts have to be 'localized' to 
Apple's non-standard keyboards and Windows versus *nix standards, not to 
standard international keyboards.  You likely should not touch them.

---

A couple of related items.  Someone posted to (I believe) python-ideas 
about translating exception messages.  Guido is in favor of the idea. 
If done in Python, as it should be, IDLE gets it for free.

As part of the Squeezer work, Tal and I improved the tooltip code, which 
is now used for both calltips and a time-delayed Squeezer tip.  I have 
thought about using the same to add time-delayed menu tips, which would 
consist of the doc entry for that menu item.  The main issue is 
extracting the right text from the html.  If IDLE had both menu tips and 
translated menus, translated menu tips would be a logical next step.

---
Terry Jan Reedy



More information about the IDLE-dev mailing list