The IDLE is a starting point for many new programmers (it was for myself) and I think that if the menu buttons / configuration options were localized to the learner’s language, it would allow them to focus on just learning to actually code.
I don’t have a lot of experience with gettext and tkinter, but I have a tonne of spare time and would be very willing to learn and help set it up if everyone is on board with this. Also, I noticed that the IDLE might need some major changes to incorporate this, for example I can’t simply change some phrases which have an underlined character. Example:
One thing I concluded from that experiment: it would be impossible to have this as part of Python’s standard distribution since vetting translations would likely be impossible. Instead, it should be done as an add-on that users can import.
For beginners, I would strongly recomment using either Thonny or Mu instead of IDLE. Both support localization and there user interface is much more modern and user friendly than IDLE’s.
I have been the main IDLE developer since sometime in 2013 and have been in favor of having translations of at least the menus since then. But I will not do it all myself. I have written about what I would accept first on the April 2013 bpo issue Issue 17776: IDLE Internationalization - Python tracker and more completely in my first reply to André’s May 2019 idledev post [Idle-dev] Forking Idle - translating menus, etc.. @jiaminglimjm If you still want to pursue this, please read both the bpo issue and idledev thread, and then let me know what you think.
In the idledev thread, I suggested that the vetting issue would be solved by using the then somewhat new doc translations and there teams. There are more teams and translations now. There are also many core devs whose native language is something other than English.
In my idledev reply, I suggested that some changes were needed to IDLE’s menu structure and machinery before adding translations (and that some would be good aside from enabling translations). Still true. Part of this is taking advantage of dict keys being insertion-ordered in all current bug-fix versions. I believe some unittests are needed before making changes. This includes the result of macosx alterations.
Hi Terry @tjreedy I have spent a few days exploring idlelib and gettext and I am very willing to pursue this and help you see it through. I compiled a list of technical difficulties to overcome from the posts you linked:
Compatibility of translations for each Windows/Mac/Unix/etc
Labels are scattered throughout codebase and other structural concerns
Distributing and organizing translations / .po and .mo files / release updates
Writing a bunch of tests and docs
Boolean flag and shortcut keys (! and _)
Regarding 2, I highly suggest using gettext the standard way rather than translating within idlelib.editor.EditorWindow.fill_menus. The latter would not be extensible for the translation of the rest of the IDLE. Also, gettext is already designed to minimize impact of i18n on program sources and makes it super easy for developers to add/remove translations. Furthermore, gettext translations would not make the code more messy, rather, it should make it easier to restructure the code, since it helps us explicitly keep track of all the labels. It is a very well established method for translating and deviating from it will probably introduce many more problems.
For 3 and 4, I have very limited experience in these but I am feeling enthusiastic to learn the processes. And regarding 1, I have access to each GNU/Linux, Windows and MacOS, so I can quickly have a feel for whether the changes I make has worked.
I have been playing around with 5 and currently working on a few solutions to consider. It doesn’t seem to be too huge of a problem.
After reading through all those links as well as many other idle-dev threads related to i18n and I really think this should be done once and for all. I was also reading some other really old posts and found it funny to see all the heated arguments about adding unicode idents, given that I grew up with a Python that had them from the start. I’m just really interested about the internationalization of software. I have made a pull request to cpython before, but have not really made a proper contribution and this seems like a perfect opportunity for me to learn. By the way, I am only halfway through the GNU gettext manual and I’m simply amazed at how they really thought everything through.
I started taking a look at this, but it is a little hard. Gettext was made for C on unix and the initial discussion assumes both. Is there a separate doc for gettext and python? It was made for national code pages. The Characters and Codesets paragraph of 1.3 Aspects seems a couple of decades out of date as there is no mention of Unicode, which should be used in all locales. It has errors. The Numbers paragraphs is wrong to say that ‘1,2345.67’ is used in ‘Asia’.
The {} format string paragraph only refers to the enabling PEP. It should instead refer to the doc. PEPs are frozen and may not even match the initial implementation.
There is no mention of f-strings. Does gettext work with them? I found the python-format and python-brace-format format flags but it is unclear to me how the latter would work properly with f-strings.
Jia, I leave it to you to follow up with gettext about Python Format entry.
About Menus: my concerns cannot just be wished away. Reading this manual has given me other ideas to think about.
