From andre.roberge at gmail.com Thu May 23 07:19:27 2019 From: andre.roberge at gmail.com (Andre Roberge) Date: Thu, 23 May 2019 08:19:27 -0300 Subject: [Idle-dev] Forking Idle - translating menus, etc. Message-ID: Hi, 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 at least one and possibly three questions related to this: 1. If I were to implement this in my fork, would there be some interest in back-porting this to Idle? If the answer is no, there is no need to read further. - - - As I understand, the role of the underscore preceding a letter, such as ("Save _As...", "<>"), 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 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). 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? - - - 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. 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? Thanks, Andr? Roberge -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjreedy at udel.edu Thu May 23 21:30:38 2019 From: tjreedy at udel.edu (Terry Reedy) Date: Thu, 23 May 2019 21:30:38 -0400 Subject: [Idle-dev] Forking Idle - translating menus, etc. In-Reply-To: References: Message-ID: <680c1842-f2cc-e14d-fece-2bde29d7c87a@udel.edu> 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...", "<>"),??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 From andre.roberge at gmail.com Fri May 24 12:46:54 2019 From: andre.roberge at gmail.com (Andre Roberge) Date: Fri, 24 May 2019 13:46:54 -0300 Subject: [Idle-dev] Forking Idle - translating menus, etc. In-Reply-To: <680c1842-f2cc-e14d-fece-2bde29d7c87a@udel.edu> References: <680c1842-f2cc-e14d-fece-2bde29d7c87a@udel.edu> Message-ID: 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 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. > Agreed. > 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 translated. > > 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 https://mail.python.org/pipermail/python-ideas/2010-May/007211.html). > 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 found. 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: From taleinat at gmail.com Fri May 24 15:16:04 2019 From: taleinat at gmail.com (Tal Einat) Date: Fri, 24 May 2019 22:16:04 +0300 Subject: [Idle-dev] Forking Idle - translating menus, etc. In-Reply-To: References: <680c1842-f2cc-e14d-fece-2bde29d7c87a@udel.edu> Message-ID: On Fri, May 24, 2019 at 7:47 PM Andre Roberge wrote: > > I'll try a few things on my own and, if I find something that seems reasonable, I will indicate it on this list. > Some things to consider when working on this: 1. There are a few places in the code that alter the menus, removing and/or adding items. One example is in Lib/idlelib/macosx.py, which makes macOS-specific adjustments. I think the other examples have been refactored by now, but some 3rd party extensions also add items to menus. Therefore, when translating, try to translate the OS-specific menu items which aren't defined in Lib/idlelib/mainmenu.py, but more importantly, make sure to fall back to the English texts when no translation is available 2. Besides underscores (_) for the keyboard shortcuts, the menu labels can also contain an exclamation mark (!) to mark an item as a boolean flag. There's a function named prepstr() in Lib/idlelib/editor.py that returns menu labels without the underscores, but it doesn't remove the boolean flag marks! Here's a little helper function to get the actual displayed text, which would then need to be translated: def get_menuitem_display_text(menuitem): label, _event = menuitem label_noflag = label[1:] if label[0] == '!' else label _underscore, display_text = prepstr(label_noflag) return display_text The code that currently does this is somewhere deep inside editor.py; make sure not to miss it! Please feel free to contact me directly if you have any technical questions; I know this code rather well and I'm happy to help. - Tal Einat From andre.roberge at gmail.com Fri May 24 16:21:05 2019 From: andre.roberge at gmail.com (Andre Roberge) Date: Fri, 24 May 2019 17:21:05 -0300 Subject: [Idle-dev] Forking Idle - translating menus, etc. In-Reply-To: References: <680c1842-f2cc-e14d-fece-2bde29d7c87a@udel.edu> Message-ID: On Fri, May 24, 2019 at 4:16 PM Tal Einat wrote: > On Fri, May 24, 2019 at 7:47 PM Andre Roberge > wrote: > > > > I'll try a few things on my own and, if I find something that seems > reasonable, I will indicate it on this list. > > > > Some things to consider when working on this: > > 1. There are a few places in the code that alter the menus, removing > and/or adding items. One example is in Lib/idlelib/macosx.py, which > makes macOS-specific adjustments. I think the other examples have been > refactored by now, but some 3rd party extensions also add items to > menus. Therefore, when translating, try to translate the OS-specific > menu items which aren't defined in Lib/idlelib/mainmenu.py, but more > importantly, make sure to fall back to the English texts when no > translation is available > > 2. Besides underscores (_) for the keyboard shortcuts, the menu labels > can also contain an exclamation mark (!) to mark an item as a boolean > flag. There's a function named prepstr() in Lib/idlelib/editor.py that > returns menu labels without the underscores, but it doesn't remove the > boolean flag marks! Here's a little helper function to get the actual > displayed text, which would then need to be translated: > > def get_menuitem_display_text(menuitem): > label, _event = menuitem > label_noflag = label[1:] if label[0] == '!' else label > _underscore, display_text = prepstr(label_noflag) > return display_text > > The code that currently does this is somewhere deep inside editor.py; > make sure not to miss it! > I had noticed it - but I didn't see any item that ended with a !. (And I completely overlooked the MacOS stuff). I've had to take a bit of a crash course in Idle's code to get my hack to work. > > Please feel free to contact me directly if you have any technical > questions; I know this code rather well and I'm happy to help. > Thank you. Andr? Roberge > > - Tal Einat > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjreedy at udel.edu Fri May 24 17:04:52 2019 From: tjreedy at udel.edu (Terry Reedy) Date: Fri, 24 May 2019 17:04:52 -0400 Subject: [Idle-dev] Forking Idle - translating menus, etc. In-Reply-To: References: <680c1842-f2cc-e14d-fece-2bde29d7c87a@udel.edu> Message-ID: On 5/24/2019 4:21 PM, Andre Roberge wrote: > I had noticed it - but I didn't see any item that ended with a !. Zoom Height used to be checked or not, but Cheryl Sabella and I changed it to switch between 'Zoom' and 'Restore'. (Oh dear, what will that do to translations. Another reason for a custom menu label list generator.) -- Terry Jan Reedy From andre.roberge at gmail.com Fri May 24 17:11:51 2019 From: andre.roberge at gmail.com (Andre Roberge) Date: Fri, 24 May 2019 18:11:51 -0300 Subject: [Idle-dev] Forking Idle - translating menus, etc. In-Reply-To: References: <680c1842-f2cc-e14d-fece-2bde29d7c87a@udel.edu> Message-ID: On Fri, May 24, 2019 at 6:05 PM Terry Reedy wrote: > On 5/24/2019 4:21 PM, Andre Roberge wrote: > > > I had noticed it - but I didn't see any item that ended with a !. > > Zoom Height used to be checked or not, but Cheryl Sabella and I changed > it to switch between 'Zoom' and 'Restore'. > > Restore Height does not work here (Python 3.7.3, 32 bit, on Windows 10). Andr? Roberge > (Oh dear, what will that do to translations. Another reason for a > custom menu label list generator.) > > -- > Terry Jan Reedy > > _______________________________________________ > IDLE-dev mailing list > IDLE-dev at python.org > https://mail.python.org/mailman/listinfo/idle-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjreedy at udel.edu Fri May 24 22:06:15 2019 From: tjreedy at udel.edu (Terry Reedy) Date: Fri, 24 May 2019 22:06:15 -0400 Subject: [Idle-dev] Forking Idle - translating menus, etc. In-Reply-To: References: <680c1842-f2cc-e14d-fece-2bde29d7c87a@udel.edu> Message-ID: <663f4f26-ffc8-ac83-5785-78b0e0aef881@udel.edu> On 5/24/2019 5:11 PM, Andre Roberge wrote: > Zoom Height used to be checked or not, but Cheryl Sabella and I changed > it to switch between 'Zoom' and 'Restore'. > > Restore Height does not work here (Python 3.7.3, 32 bit, on Windows 10). I just checked and for me it works (as documented) by restoring to the default (rather than to the previous size). Did you not get some reduction from max? I admit that this can be initially surprising. I believe the behavior is original. A menu hint would be helpful here. I opened https://bugs.python.org/issue37039 to polish the doc. From andre.roberge at gmail.com Sat May 25 05:48:15 2019 From: andre.roberge at gmail.com (Andre Roberge) Date: Sat, 25 May 2019 06:48:15 -0300 Subject: [Idle-dev] Forking Idle - translating menus, etc. In-Reply-To: <663f4f26-ffc8-ac83-5785-78b0e0aef881@udel.edu> References: <680c1842-f2cc-e14d-fece-2bde29d7c87a@udel.edu> <663f4f26-ffc8-ac83-5785-78b0e0aef881@udel.edu> Message-ID: On Fri, May 24, 2019 at 11:06 PM Terry Reedy wrote: > On 5/24/2019 5:11 PM, Andre Roberge wrote: > > > Zoom Height used to be checked or not, but Cheryl Sabella and I > changed > > it to switch between 'Zoom' and 'Restore'. > > > > Restore Height does not work here (Python 3.7.3, 32 bit, on Windows 10). > > I just checked and for me it works (as documented) by restoring to the > default (rather than to the previous size). Did you not get some > reduction from max? I admit that this can be initially surprising. I > believe the behavior is original. A menu hint would be helpful here. > > I opened https://bugs.python.org/issue37039 to polish the doc. > I've uploaded a short video (no sound; wmv file - I could embed an mp4 in an html file if it would be preferable) showing the behaviour. http://reeborg.ca/idle-restore-problem.wmv When I click on Zoom Height, the status bar is hidden. Clicking on Restore Height (which I attempted to do twice in that video) does absolutely nothing. I expected it to toggle i.e. switch back to the height it had when I started Idle (so that I could easily see the status bar). At the beginning of the video, I show my screen resolution and related parameters as perhaps this might be relevant. Andr? Roberge -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjreedy at udel.edu Sat May 25 12:35:00 2019 From: tjreedy at udel.edu (Terry Reedy) Date: Sat, 25 May 2019 12:35:00 -0400 Subject: [Idle-dev] Forking Idle - translating menus, etc. In-Reply-To: References: <680c1842-f2cc-e14d-fece-2bde29d7c87a@udel.edu> <663f4f26-ffc8-ac83-5785-78b0e0aef881@udel.edu> Message-ID: <293ff4eb-1de1-d01c-de59-81729c9875d6@udel.edu> On 5/25/2019 5:48 AM, Andre Roberge wrote: > I've uploaded a short video (no sound; wmv file - I could embed an mp4 > in an html file if it would be preferable) showing the behaviour. > http://reeborg.ca/idle-restore-problem.wmv You or your site provider need to fix something. Both Firefox and Edge refuse to open that URL. Edge says something about a bogus security certificate. Perhaps not coicidentally, my system crashed with a blue screen, for the first time in months, about a minute after. > When I click on Zoom Height, the status bar is hidden. I know about that bug. >? Clicking on > Restore Height (which I attempted to do twice in that video) does > absolutely nothing. I expected it to toggle i.e. switch back to the > height it had when I started Idle (so that I could easily see the status > bar). I will believe this without the video. I would be equally puzzled either way. This discussion should go to https://bugs.python.org/issue37039 I added you as nosy to the issue and made a suggestion. > At the beginning of the video, I show my screen resolution and related > parameters as perhaps this might be relevant. Hard to guess. -- Terry Jan Reedy From tjreedy at udel.edu Sat May 25 12:35:00 2019 From: tjreedy at udel.edu (Terry Reedy) Date: Sat, 25 May 2019 12:35:00 -0400 Subject: [Idle-dev] Forking Idle - translating menus, etc. In-Reply-To: References: <680c1842-f2cc-e14d-fece-2bde29d7c87a@udel.edu> <663f4f26-ffc8-ac83-5785-78b0e0aef881@udel.edu> Message-ID: <293ff4eb-1de1-d01c-de59-81729c9875d6@udel.edu> On 5/25/2019 5:48 AM, Andre Roberge wrote: > I've uploaded a short video (no sound; wmv file - I could embed an mp4 > in an html file if it would be preferable) showing the behaviour. > http://reeborg.ca/idle-restore-problem.wmv You or your site provider need to fix something. Both Firefox and Edge refuse to open that URL. Edge says something about a bogus security certificate. Perhaps not coicidentally, my system crashed with a blue screen, for the first time in months, about a minute after. > When I click on Zoom Height, the status bar is hidden. I know about that bug. >? Clicking on > Restore Height (which I attempted to do twice in that video) does > absolutely nothing. I expected it to toggle i.e. switch back to the > height it had when I started Idle (so that I could easily see the status > bar). I will believe this without the video. I would be equally puzzled either way. This discussion should go to https://bugs.python.org/issue37039 I added you as nosy to the issue and made a suggestion. > At the beginning of the video, I show my screen resolution and related > parameters as perhaps this might be relevant. Hard to guess. -- Terry Jan Reedy From Richard at Damon-Family.org Sun May 26 07:22:39 2019 From: Richard at Damon-Family.org (Richard Damon) Date: Sun, 26 May 2019 07:22:39 -0400 Subject: [Idle-dev] Setting Command Line Arguments in IDLE In-Reply-To: <7065cefe-682d-722a-30eb-506a7f5a3d92@Damon-Family.org> References: <7065cefe-682d-722a-30eb-506a7f5a3d92@Damon-Family.org> Message-ID: I am working on a python script that will be provided arguments when run from the system command line. Is there any place in IDLE to provide equivalent arguments for testing while developing in IDLE? Is there any way to define the working directory for the program when run under IDLE, or will it always be the directory the script is in (it will be typically run using the PATH, so not the same directory as the script)? If not, is there an easy way to detect that I am running in IDLE so I can fake the command line arguments when testing? -- Richard Damon idle From tjreedy at udel.edu Sun May 26 12:40:20 2019 From: tjreedy at udel.edu (Terry Reedy) Date: Sun, 26 May 2019 12:40:20 -0400 Subject: [Idle-dev] Setting Command Line Arguments in IDLE In-Reply-To: References: <7065cefe-682d-722a-30eb-506a7f5a3d92@Damon-Family.org> Message-ID: <861a65db-cfdd-059b-f70a-9c1e7ccc3405@udel.edu> On 5/26/2019 7:22 AM, Richard Damon wrote: > I am working on a python script that will be provided arguments when run > from the system command line. Is there any place in IDLE to provide > equivalent arguments for testing while developing in IDLE? This is the subject of https://bugs.python.org/issue5680. There is a PR that needs to be reviewed. > Is there any way to define the working directory for the program when > run under IDLE, > or will it always be the directory the script is in (it will be typically > run using the PATH, so not the same directory as the script)? os.chdir(path) > If not, is there an easy way to detect that I am running in IDLE so I > can fake the command line arguments when testing? import sys if __name__ == '__main__': if 'idlelib.run' in sys.modules: sys.argv.extend(('a', '-2')) # add your argments here. print(sys.argv) # in use, parse sys.argv after extending it ['', 'a', '-2'] # in my test in Shell -- Terry Jan Reedy From andre.roberge at gmail.com Sun May 26 21:00:30 2019 From: andre.roberge at gmail.com (Andre Roberge) Date: Sun, 26 May 2019 22:00:30 -0300 Subject: [Idle-dev] Forking Idle - translating menus, etc. In-Reply-To: <293ff4eb-1de1-d01c-de59-81729c9875d6@udel.edu> References: <680c1842-f2cc-e14d-fece-2bde29d7c87a@udel.edu> <663f4f26-ffc8-ac83-5785-78b0e0aef881@udel.edu> <293ff4eb-1de1-d01c-de59-81729c9875d6@udel.edu> Message-ID: I have started working on a possible implementation for providing translations for IDLE's menu. Right now, it generates a traceback which stumps me. Regardless, before I spend more time trying to figure out what goes on, I thought it would be a good idea to see if the approach I have in mind would be acceptable. Copying the docstring of the main module I wrote: """This module is intended to provide translations of menu items. Instead of trying to approve translations for inclusion in Python's standard library, translations would be obtained separately by the end users and be located in a place from where they could be imported. This could be done by having a user put a translation file in their home directory or install them from Pypi. A translation file could have any name. However, its content would have to include a dict named "idle_translation" whose content would include at least one language, with the possibility of having more, and would have the following structure idle_translation = { "fr": { "File" : "Fichier", ...}, "es": {"File": "Archivo", ...} # not sure of the Spanish term } The addition of a directory would be done through the configuration menu and the name of the translation file would be saved in the user's configuration file. In case it is needed, we compile a reverse dictionary; but we have not gotten far enough to use it yet. """ The essence of the implementation can be described as follows: Existing code (one example copy-pasted from editor.py) menu.add_command(label=label, underline=underline, command=command, accelerator=accelerator) New code label = translator.get(label) # single line added menu.add_command(label=label, underline=underline, command=command, accelerator=accelerator) Where translator.get(label) can be thought of as a function like the following: def get_translation(label): if translation_exists(user_language, label): return translation_of(user_language, label) else: return label The actual code is a bit more complicated. = = = I admit to not really knowing how best to proceed with using git on a project like this. What I did is the following: 1. I cloned the cpython repository; 2. I created a local branch which I called "idle-translation-dev". 3. Trying to run "python -m idlelib", I got a traceback as "_pickle" could not be found when pickle was processed. So, I changed the name of "pickle.py" so that it would import the version from Python installed from my computer. That allowed me to proceed and explain the strange file renaming you might see if you look at the commit. What I did can be viewed in this single commit: https://github.com/aroberge/cpython/commit/8e329288cf1e97d35ecc2b9b65fafb9e2190d361 The traceback I got (preceded by two print statement I included in an attempt to figure out what went wrong) is the following: menu = options index = *Code Context state = disabled menuitem = .!menu.options Traceback (most recent call last): File "C:\Users\andre\github\cpython\Lib\runpy.py", line 193, in _run_module_as_main "__main__", mod_spec) File "C:\Users\andre\github\cpython\Lib\runpy.py", line 85, in _run_code exec(code, run_globals) File "C:\Users\andre\github\cpython\Lib\idlelib\__main__.py", line 7, in idlelib.pyshell.main() File "C:\Users\andre\github\cpython\Lib\idlelib\pyshell.py", line 1521, in main shell = flist.open_shell() File "C:\Users\andre\github\cpython\Lib\idlelib\pyshell.py", line 328, in open_shell self.pyshell = PyShell(self) File "C:\Users\andre\github\cpython\Lib\idlelib\pyshell.py", line 879, in __init__ OutputWindow.__init__(self, flist, None, None) File "C:\Users\andre\github\cpython\Lib\idlelib\outwin.py", line 81, in __init__ self.update_menu_state('options', '*Code Context', 'disabled') File "C:\Users\andre\github\cpython\Lib\idlelib\editor.py", line 462, in update_menu_state menuitem.entryconfig(index, state=state) File "C:\Users\andre\github\cpython\Lib\tkinter\__init__.py", line 3354, in entryconfigure return self._configure(('entryconfigure', index), cnf, kw) File "C:\Users\andre\github\cpython\Lib\tkinter\__init__.py", line 1627, in _configure self.tk.call(_flatten((self._w, cmd)) + self._options(cnf)) _tkinter.TclError: bad menu entry index "*Code Context" I *suspect* that it is because other places required translations to my fictitious uppercase language before reaching that point, resulting in some inconsistencies ... but it seemed like a good place to stop to get some feedback as to whether or not this approach would be acceptable. Andr? Roberge -------------- next part -------------- An HTML attachment was scrubbed... URL: From andre.roberge at gmail.com Mon May 27 12:37:59 2019 From: andre.roberge at gmail.com (Andre Roberge) Date: Mon, 27 May 2019 13:37:59 -0300 Subject: [Idle-dev] Forking Idle - translating menus, etc. In-Reply-To: References: <680c1842-f2cc-e14d-fece-2bde29d7c87a@udel.edu> <663f4f26-ffc8-ac83-5785-78b0e0aef881@udel.edu> <293ff4eb-1de1-d01c-de59-81729c9875d6@udel.edu> Message-ID: Hello everyone, Please ignore the traceback mentioned in the previous email. I made a few changes and got rid of the traceback. The good news: IDLE starts and appear to work correctly. The bad news: the menu items are not changed to the test "uppercase" language. I will try to figure out how to fix this. Andr? Roberge On Sun, May 26, 2019 at 10:00 PM Andre Roberge wrote: > I have started working on a possible implementation for providing > translations for IDLE's menu. Right now, it generates a traceback which > stumps me. Regardless, before I spend more time trying to figure out what > goes on, I thought it would be a good idea to see if the approach I have in > mind would be acceptable. > > Copying the docstring of the main module I wrote: > > """This module is intended to provide translations of menu items. > > Instead of trying to approve translations for inclusion in Python's > standard > library, translations would be obtained separately by the end users and > be located in a place from where they could be imported. > This could be done by having a user put a translation file in their home > directory or install them from Pypi. > > A translation file could have any name. However, its content would have > to include a dict named "idle_translation" whose content would include > at least one language, with the possibility of having more, and > would have the following structure > > idle_translation = { > "fr": { "File" : "Fichier", ...}, > "es": {"File": "Archivo", ...} # not sure of the Spanish term > } > > The addition of a directory would be done through the configuration > menu and the name of the translation file would be saved in the user's > configuration file. > > In case it is needed, we compile a reverse dictionary; but we have not > gotten far enough to use it yet. > > """ > > The essence of the implementation can be described as follows: > > Existing code (one example copy-pasted from editor.py) > > menu.add_command(label=label, underline=underline, > command=command, > accelerator=accelerator) > > New code > > label = translator.get(label) # single line added > > menu.add_command(label=label, underline=underline, > command=command, > accelerator=accelerator) > > Where translator.get(label) can be thought of as a function like the > following: > > def get_translation(label): > if translation_exists(user_language, label): > return translation_of(user_language, label) > else: > return label > > The actual code is a bit more complicated. > > = = = > I admit to not really knowing how best to proceed with using git on a > project like this. > What I did is the following: > 1. I cloned the cpython repository; > 2. I created a local branch which I called "idle-translation-dev". > 3. Trying to run "python -m idlelib", I got a traceback as "_pickle" could > not be found when pickle was processed. So, I changed the name of > "pickle.py" so that it would import the version from Python installed from > my computer. That allowed me to proceed and explain the strange file > renaming you might see if you look at the commit. > > What I did can be viewed in this single commit: > > > https://github.com/aroberge/cpython/commit/8e329288cf1e97d35ecc2b9b65fafb9e2190d361 > > > The traceback I got (preceded by two print statement I included in an > attempt to figure out what went wrong) is the following: > > menu = options index = *Code Context state = disabled > menuitem = .!menu.options > Traceback (most recent call last): > File "C:\Users\andre\github\cpython\Lib\runpy.py", line 193, in > _run_module_as_main > "__main__", mod_spec) > File "C:\Users\andre\github\cpython\Lib\runpy.py", line 85, in _run_code > exec(code, run_globals) > File "C:\Users\andre\github\cpython\Lib\idlelib\__main__.py", line 7, in > > idlelib.pyshell.main() > File "C:\Users\andre\github\cpython\Lib\idlelib\pyshell.py", line 1521, > in main > shell = flist.open_shell() > File "C:\Users\andre\github\cpython\Lib\idlelib\pyshell.py", line 328, > in open_shell > self.pyshell = PyShell(self) > File "C:\Users\andre\github\cpython\Lib\idlelib\pyshell.py", line 879, > in __init__ > OutputWindow.__init__(self, flist, None, None) > File "C:\Users\andre\github\cpython\Lib\idlelib\outwin.py", line 81, in > __init__ > self.update_menu_state('options', '*Code Context', 'disabled') > File "C:\Users\andre\github\cpython\Lib\idlelib\editor.py", line 462, in > update_menu_state > menuitem.entryconfig(index, state=state) > File "C:\Users\andre\github\cpython\Lib\tkinter\__init__.py", line 3354, > in entryconfigure > return self._configure(('entryconfigure', index), cnf, kw) > File "C:\Users\andre\github\cpython\Lib\tkinter\__init__.py", line 1627, > in _configure > self.tk.call(_flatten((self._w, cmd)) + self._options(cnf)) > _tkinter.TclError: bad menu entry index "*Code Context" > > > I *suspect* that it is because other places required translations to my > fictitious uppercase language > before reaching that point, resulting in some inconsistencies ... > but it seemed like a good place to stop to get some feedback > as to whether or not this approach would be acceptable. > > > Andr? Roberge > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andre.roberge at gmail.com Mon May 27 12:42:52 2019 From: andre.roberge at gmail.com (Andre Roberge) Date: Mon, 27 May 2019 13:42:52 -0300 Subject: [Idle-dev] Forking Idle - translating menus, etc. In-Reply-To: References: <680c1842-f2cc-e14d-fece-2bde29d7c87a@udel.edu> <663f4f26-ffc8-ac83-5785-78b0e0aef881@udel.edu> <293ff4eb-1de1-d01c-de59-81729c9875d6@udel.edu> Message-ID: Sigh ... I "spoke" too soon. Last night, as a final sanity check, I had put a hard-return in the function that provided the translations so that it would return the original, untranslated label. This is the code that I just ran. The traceback is unfortunately still there. Andr? Roberge On Mon, May 27, 2019 at 1:37 PM Andre Roberge wrote: > Hello everyone, > > Please ignore the traceback mentioned in the previous email. I made a few > changes and got rid of the traceback. > > The good news: IDLE starts and appear to work correctly. > The bad news: the menu items are not changed to the test "uppercase" > language. > > I will try to figure out how to fix this. > > Andr? Roberge > > On Sun, May 26, 2019 at 10:00 PM Andre Roberge > wrote: > >> I have started working on a possible implementation for providing >> translations for IDLE's menu. Right now, it generates a traceback which >> stumps me. Regardless, before I spend more time trying to figure out what >> goes on, I thought it would be a good idea to see if the approach I have in >> mind would be acceptable. >> >> Copying the docstring of the main module I wrote: >> >> """This module is intended to provide translations of menu items. >> >> Instead of trying to approve translations for inclusion in Python's >> standard >> library, translations would be obtained separately by the end users and >> be located in a place from where they could be imported. >> This could be done by having a user put a translation file in their home >> directory or install them from Pypi. >> >> A translation file could have any name. However, its content would have >> to include a dict named "idle_translation" whose content would include >> at least one language, with the possibility of having more, and >> would have the following structure >> >> idle_translation = { >> "fr": { "File" : "Fichier", ...}, >> "es": {"File": "Archivo", ...} # not sure of the Spanish term >> } >> >> The addition of a directory would be done through the configuration >> menu and the name of the translation file would be saved in the user's >> configuration file. >> >> In case it is needed, we compile a reverse dictionary; but we have not >> gotten far enough to use it yet. >> >> """ >> >> The essence of the implementation can be described as follows: >> >> Existing code (one example copy-pasted from editor.py) >> >> menu.add_command(label=label, underline=underline, >> command=command, >> accelerator=accelerator) >> >> New code >> >> label = translator.get(label) # single line added >> >> menu.add_command(label=label, underline=underline, >> command=command, >> accelerator=accelerator) >> >> Where translator.get(label) can be thought of as a function like the >> following: >> >> def get_translation(label): >> if translation_exists(user_language, label): >> return translation_of(user_language, label) >> else: >> return label >> >> The actual code is a bit more complicated. >> >> = = = >> I admit to not really knowing how best to proceed with using git on a >> project like this. >> What I did is the following: >> 1. I cloned the cpython repository; >> 2. I created a local branch which I called "idle-translation-dev". >> 3. Trying to run "python -m idlelib", I got a traceback as "_pickle" >> could not be found when pickle was processed. So, I changed the name of >> "pickle.py" so that it would import the version from Python installed from >> my computer. That allowed me to proceed and explain the strange file >> renaming you might see if you look at the commit. >> >> What I did can be viewed in this single commit: >> >> >> https://github.com/aroberge/cpython/commit/8e329288cf1e97d35ecc2b9b65fafb9e2190d361 >> >> >> The traceback I got (preceded by two print statement I included in an >> attempt to figure out what went wrong) is the following: >> >> menu = options index = *Code Context state = disabled >> menuitem = .!menu.options >> Traceback (most recent call last): >> File "C:\Users\andre\github\cpython\Lib\runpy.py", line 193, in >> _run_module_as_main >> "__main__", mod_spec) >> File "C:\Users\andre\github\cpython\Lib\runpy.py", line 85, in _run_code >> exec(code, run_globals) >> File "C:\Users\andre\github\cpython\Lib\idlelib\__main__.py", line 7, >> in >> idlelib.pyshell.main() >> File "C:\Users\andre\github\cpython\Lib\idlelib\pyshell.py", line 1521, >> in main >> shell = flist.open_shell() >> File "C:\Users\andre\github\cpython\Lib\idlelib\pyshell.py", line 328, >> in open_shell >> self.pyshell = PyShell(self) >> File "C:\Users\andre\github\cpython\Lib\idlelib\pyshell.py", line 879, >> in __init__ >> OutputWindow.__init__(self, flist, None, None) >> File "C:\Users\andre\github\cpython\Lib\idlelib\outwin.py", line 81, in >> __init__ >> self.update_menu_state('options', '*Code Context', 'disabled') >> File "C:\Users\andre\github\cpython\Lib\idlelib\editor.py", line 462, >> in update_menu_state >> menuitem.entryconfig(index, state=state) >> File "C:\Users\andre\github\cpython\Lib\tkinter\__init__.py", line >> 3354, in entryconfigure >> return self._configure(('entryconfigure', index), cnf, kw) >> File "C:\Users\andre\github\cpython\Lib\tkinter\__init__.py", line >> 1627, in _configure >> self.tk.call(_flatten((self._w, cmd)) + self._options(cnf)) >> _tkinter.TclError: bad menu entry index "*Code Context" >> >> >> I *suspect* that it is because other places required translations to my >> fictitious uppercase language >> before reaching that point, resulting in some inconsistencies ... >> but it seemed like a good place to stop to get some feedback >> as to whether or not this approach would be acceptable. >> >> >> Andr? Roberge >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andre.roberge at gmail.com Tue May 28 19:37:35 2019 From: andre.roberge at gmail.com (Andre Roberge) Date: Tue, 28 May 2019 20:37:35 -0300 Subject: [Idle-dev] Forking Idle - translating menus, etc. In-Reply-To: References: <680c1842-f2cc-e14d-fece-2bde29d7c87a@udel.edu> <663f4f26-ffc8-ac83-5785-78b0e0aef881@udel.edu> <293ff4eb-1de1-d01c-de59-81729c9875d6@udel.edu> Message-ID: Translation is *almost* working perfectly. There are two exceptions that are raised which I do not understand. Currently, I just ignore them and, as far as I can tell, everything still works. I've tried to figure out what is going on and I did not manage to do it. The code is in the following branch https://github.com/aroberge/cpython/tree/idle-translation-dev which has a total of 3 commits. The error I got are the following: bad menu entry index "*Code Context" menu = options ;index = *Code Context ;state = disabled menuitem = .!menu.options bad menu entry index "* Height" inside zoom_height_event menu="options", index="* Height", label = RESTORE HEIGHT bad menu entry index "* Height" inside zoom_height_event menu="options", index="* Height", label = ZOOM Height They all include an asterisk in the index. I'm guessing it has a special meaning but I couldn't figure it out. # The first one occurs in update_menu_state in editor.py -- sorry, I forgot to log the information. The others occur in zoomheight.py Andr? Roberge -------------- next part -------------- An HTML attachment was scrubbed... URL: