Re: [Idle-dev] Forking Idle - translating menus, etc.
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 ___ IDLE-dev mailing list IDLE-dev@python.org https://mail.python.org/mailman/listinfo/idle-dev
Re: [Idle-dev] Forking Idle - translating menus, etc.
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.updat
Re: [Idle-dev] Forking Idle - translating menus, etc.
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(
Re: [Idle-dev] Forking Idle - translating menus, etc.
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
___
IDLE-dev mailing list
IDLE-dev@python.org
https://mail.python.org/mailman/listinfo/idle-dev
Re: [Idle-dev] Forking Idle - translating menus, etc.
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 ___ IDLE-dev mailing list IDLE-dev@python.org https://mail.python.org/mailman/listinfo/idle-dev
Re: [Idle-dev] Forking Idle - translating menus, etc.
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 ___ IDLE-dev mailing list IDLE-dev@python.org https://mail.python.org/mailman/listinfo/idle-dev
Re: [Idle-dev] Forking Idle - translating menus, etc.
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. ___ IDLE-dev mailing list IDLE-dev@python.org https://mail.python.org/mailman/listinfo/idle-dev
Re: [Idle-dev] Forking Idle - translating menus, etc.
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@python.org > https://mail.python.org/mailman/listinfo/idle-dev > ___ IDLE-dev mailing list IDLE-dev@python.org https://mail.python.org/mailman/listinfo/idle-dev
Re: [Idle-dev] Forking Idle - translating menus, etc.
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 ___ IDLE-dev mailing list IDLE-dev@python.org https://mail.python.org/mailman/listinfo/idle-dev
Re: [Idle-dev] Forking Idle - translating menus, etc.
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 > ___ IDLE-dev mailing list IDLE-dev@python.org https://mail.python.org/mailman/listinfo/idle-dev
Re: [Idle-dev] Forking Idle - translating menus, etc.
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 ___ IDLE-dev mailing list IDLE-dev@python.org https://mail.python.org/mailman/listinfo/idle-dev
Re: [Idle-dev] Forking Idle - translating menus, etc.
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. Assum
Re: [Idle-dev] Forking Idle - translating menus, etc.
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
