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
_______________________________________________
IDLE-dev mailing list
IDLE-dev@python.org
https://mail.python.org/mailman/listinfo/idle-dev
