[Idle-dev] Forking Idle - translating menus, etc.
andre.roberge at gmail.com
Fri May 24 12:46:54 EDT 2019
Thank you very much for your detailed response. There is much in it for me
On Thu, May 23, 2019 at 10:30 PM Terry Reedy <tjreedy at udel.edu> wrote:
> 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
> Hmmm ...I do not remember mentioning that I was planning to work on menu
translations; it is possible that I have as I do seem to think a lot about
the topic of translations. I have been busy with two projects, which I
mentioned in a blog post today (
> 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.
I certainly agree with this idea; in my experience, if at all possible,
translations should be the last thing done prior to showing/printing the
> 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.
dicts insertion for translations are indeed easy to do (I have used this
approach in a couple of projects) and most likely would work well for menu
items, but they don't necessarily scale well when longer strings need to be
> 3. Initial translation? I was and am not willing to add code that has
> no immediate use and cannot be tested.
Sounds perfectly reasonable.
> 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
> 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
> 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
> 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.
.po files are very verbose but easy to deal with using the specialized
.mo files are compiled binary files, unreadable by humans.
> 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?
They are using .po files though...
[ significant chunk of informative text deleted ]
> A couple of related items. Someone posted to (I believe) python-ideas
> about translating exception messages.
I seem to have missed that. (I did suggest this 9 years ago
> Guido is in favor of the idea.
> If done in Python, as it should be, IDLE gets it for free.
While I used to think it would be a good idea, I am no longer enthusiastic
about that: the message accompanying exceptions is often so cryptic that a
translation would likely not be that useful. This is why I started on
Friendly-traceback, which expands on the cryptic text and does it in such a
way that translation is supported.
> 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.
I'll have to take a look at that.
= = =
After having read your reply a few times, I think that it makes sense to me
to try various approaches on my own project and see if I can find a way
that would reduce to a minimum the number of changes required to the
While it is a recognized standard which can, in principle, deal with very
complicated grammatical issues specific to individual languages (like
pluralisation which can be utterly complicated in some languages), as far
as I know it imposes a directory structure where all the translations are
Using a dict-based approach, it might be easy design some interface
(perhaps a configuration in IDLE) where one can give a path as to where a
python file resides for a given translation. This would bypass the need to
have someone to vet official translations: people could share (and
customize) existing translations.
I'll try a few things on my own and, if I find something that seems
reasonable, I will indicate it on this list.
Once again, thank you for the detailed response.
> Terry Jan Reedy
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the IDLE-dev