<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Thank you very much for your detailed response. There is much in it for me to digest.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">(more below)</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 23, 2019 at 10:30 PM Terry Reedy <<a href="mailto:tjreedy@udel.edu">tjreedy@udel.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 5/23/2019 7:19 AM, Andre Roberge wrote:<br>
<br>
> I'm currently working on an experimental fork of Idle. One of the many <br>
> things I plan to do is to see if I can have translatable menus to make <br>
> it more user-friendly for international users.  If there is interest, <br>
> this could presumably be back-ported to Idle. [Most other features I <br>
> have planned would not be relevant for Idle.] My plan is to use the <br>
> standard gettext approach, and have an additional language selector <br>
> menu, so that the language used for the UI can be changed while Idle is <br>
> running.<br>
<br>
I have been at least somewhat in favor of having IDLE menu translations <br>
since before <a href="https://bugs.python.org/issue17776" rel="noreferrer" target="_blank">https://bugs.python.org/issue17776</a> was opened.</blockquote><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">(Interesting read...)</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">  Even though <br>
I rejected the specific patch (see 2. below), I left the issue open to <br>
keep the idea open.  Given a new start, I would close it and open a new <br>
issue with a more specific title, such as 'Allow translations of IDLE <br>
menus".  I have been thinking about contacting you since I read, <br>
recently, something somewhere about you planning to work on menu <br>
translations.<br>
<br></blockquote><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">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 (<a href="https://aroberge.blogspot.com/2019/05/avant-idle-experiment.html">https://aroberge.blogspot.com/2019/05/avant-idle-experiment.html</a>) dealing with translations. </div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Blocking issues:<br>
<br>
1. Who writes patch? Many favor the idea and are willing to discuss it. <br>
Up to now, no one has been willing to the harder work, even with my <br>
help, of producing a patch I will accept.<br>
<br>
2. Where translate?  The submitted patch decorated the submenu entries <br>
in idlelib.mainmenu.menudefs.  My objections, in brief, are that a) this <br>
makes the code uglier and harder to read and edit; b) this makes a <br>
permanent one-way change to an internal data structure; and c) this is <br>
unnecessary, as the sub-menu translations can and should be done <br>
somewhere in idlelib.editor.EdiorWindow.fill_menus, just before adding <br>
the label to a menu item.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">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.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
At least one translation guideline I have read agrees with me on b) and <br>
c).  I believe your idea of dynamically switching languages would also <br>
be easier if the internal structure were left alone.<br></blockquote><div> </div><div><span class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Agreed.</span> </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Currently the display labels for the menu bar are not contained in <br>
menudefs, but are translated to their display forms with caps and <br>
underscores elsewhere.  Most are translated twice.  In order to remove <br>
duplication and to be able to write them in their proper place along <br>
with the sub-menu labels, the display forms should be moved to menudefs. <br>
    (With dicts insertion ordered, menudefs can be a dict keyed on <br>
'file', etc.)  I may do this as a separate patch.  This would make it <br>
possible to write a file of labels to be translated in their proper <br>
order, as they appear in the doc.<br></blockquote><div><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">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 translated.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
3. Initial translation?  I was and am not willing to add code that has <br>
no immediate use and cannot be tested.</blockquote><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Sounds perfectly reasonable.</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">  The patch on #17776 lacked a <br>
translation.  Someone subsequently did a different patch, not on the <br>
tracker, that had a translation, but the method struck me as too <br>
invasive of IDLE code and not scalable to multiple languages.<br>
<br>
4. What translations? As I said on the issue, I cannot vet translators <br>
and translations, but I will not display unvetted translations.  (I <br>
could perhaps check a Spanish translation.)  This is the same issue that <br>
blocked PSF and coredev endorsement of doc translations.<br>
<br>
A couple of years ago, a translation system was set up with Julien <br>
Palard responsible for vetting teams of translators. I am willing to <br>
include translations from those teams, and think that other coredevs <br>
might concur.  I would check on pydev before we got very far.  There <br>
might be some teams not part of the official project that would be accepted.<br>
<br>
The current Japanese translation of the IDLE doc has a nearly complete <br>
translation of the menu section.  Lines like the following<br>
<br>
"File メニュー (Shell ウィンドウ、Editor ウィンドウ)<br>
New File [新規ファイル] "<br>
<br>
can easily be reformatted to be usable by IDLE.  This solves the initial <br>
translation problem.  We would have to check if it is restricted to the BMP.<br>
<br>
The Simplified Chinese translation only translates the File and Edit <br>
menus.  Assuming correct order, the English originals can be filled in. <br>
French and Korean do not yet translate the IDLE doc.  Once the feature <br>
was merged with at least one working language, and I was ready to merge <br>
more, I would post to the translation list and request more menu <br>
translations.<br>
<br>
5. Machinery and translation file format.  I had and probably still have <br>
some unanswered questions about gettext.  See my first response on the <br>
issue.  I don't know what .mo and .po files look like.  </blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">.po files are very verbose but easy to deal with using the specialized editor Poedit.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">.mo files are compiled binary files, unreadable by humans.</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I do not believe <br>
the translation group is using gettext, since they are not selecting <br>
strings from code.  If "_(...)" is not used for collecting labels from <br>
literals, is it needed for the dict lookup?<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">They are using .po files though...</div><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">[ significant chunk of informative text deleted ]</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
---<br>
<br>
A couple of related items.  Someone posted to (I believe) python-ideas <br>
about translating exception messages.  </blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">I seem to have missed that. (I did suggest this 9 years ago <a href="https://mail.python.org/pipermail/python-ideas/2010-May/007211.html" style="font-family:Arial,Helvetica,sans-serif">https://mail.python.org/pipermail/python-ideas/2010-May/007211.html</a>).</div></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><span style="font-family:Arial,Helvetica,sans-serif"> </span><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Guido is in favor of the idea. <br>
If done in Python, as it should be, IDLE gets it for free.<br></blockquote><div><span class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"></span></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">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.</div><br></div><div><span class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"></span> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
As part of the Squeezer work, Tal and I improved the tooltip code, which <br>
is now used for both calltips and a time-delayed Squeezer tip.  I have <br>
thought about using the same to add time-delayed menu tips, which would <br>
consist of the doc entry for that menu item.  The main issue is <br>
extracting the right text from the html.  If IDLE had both menu tips and <br>
translated menus, translated menu tips would be a logical next step.<br></blockquote><div><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">I'll have to take a look at that.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">= = =</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">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 found.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">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. </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">I'll try a few things on my own and, if I find something that seems reasonable, I will indicate it on this list.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Once again, thank you for the detailed response.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">André Roberge</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
---<br>
Terry Jan Reedy<br>
<br>
</blockquote></div></div>