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

Andre Roberge 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
to digest.

(more below)

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.

(Interesting read...)

>   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.
> 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 (
https://aroberge.blogspot.com/2019/05/avant-idle-experiment.html) dealing
with 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.

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

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

.po files are very verbose but easy to deal with using the specialized
editor Poedit.
.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
existing code.

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.

André Roberge

> ---
> Terry Jan Reedy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20190524/c312dfd9/attachment.html>

More information about the IDLE-dev mailing list