Terry J. Reedy added the comment:
Whether and how much to internationalize Idle is being discussed on idle-dev
thread "I18n of IDLE's interface ?". I was going to suggest there that the menu
system would be the first place to start. A prime concern for me is that we not
break anything (hence some of the questions below), and the menu labels seem
relatively safe (compared to format strings -- see post on thread).
While locale is used to format dates and times, I believe this would be the
first use of gettext within the stdlib itself. To me it is a plausible to do
because the idlelib modules are used to write and run code rather than being
imported into code. I still have this concern: if a beginner can manage to
handle 'English' keywords, builtin names, and exception names and messages*,
does having translated menu labels give enough benefit to be worth the bother?
I am open to the answer being yes, but before I were to commit this patch to
the CPython repository, I would like to see a working example translation and a
report of a field test with real students.
(* I an not including stdlib because many beginners programs make little use of
imports.)
As for the patch: It looks good as far as it goes, but I have little knowledge
of locale and gettext beyond the bare bones and no experience with either. The
gettext doc is not all that clear to me, and it seems exclusively unix-focused,
whereas I am on Windows. My questions:
1. Does it actually work on Windows (and Mac), without bugs?
(I could sometime look as test_gettext and try it on Windows, but not on the
machine I am on at the moment.)
2. +gettext.bindtextdomain('idlelib')
What does this actually do. Where do .mo files go on the various OSes. This
sort of doc has to be part of a patch.
3. Does the gettext machinery look at an environmental locale variable behind
the scenes? Is that how it decides on the translation language, if any?
4. +_ = gettext.gettext
Leave aside the issue of doing the binding in builtins versus each module, as
in the patch (this seems safer). The doc is skimpier than I would like: "Return
the localized translation of message, based on the current global domain,
language, and locale directory." The latter part is part of my question above.
As for the first part: is the default behavior to simply echo the text passed
in? If Idle executes in a non-default environment/locale, but there is no
translation file, does it echo the original string (English) or raise an
exception? Same question if there is an appropriate translation file but no
entry for the particular string? Overall, does gettext *ever* raise an
exception, or does it *always* return a string of the correct type, or might it
return bytes when unicode is expected (in 3.x)? In other words, can replacing a
string literal with a gettext call cause Idle to crash?
5. Focusing only on the menus, do you expect anything more applied to the
repository than a patch like this and a doc patch? Who do you see as running
Tools/i18n/pygettext.py, a core dev, one other person, or each translator? What
do you see happening with the .pot file for each release? Include it with the
release? Distribute on pypi? or regenerate it by each translator? And what
about .mo files? It would seem silly to have multiple French .mo files,
although I can imaging that different teachers might disagree on the best
translation for their students ;-).
Let me put is another way. The patch by itself is useless. In fact, even if it
is completely transparent to users, it will *not* be transparent to Idle
developers working on the code. It will actually be a detriment* unless there
is additional work done. Who do you two, or any other advocates of IdleIl8n
envision as doing the various tasks needed to make it useful?
Perhaps there should be an IdleIl8n project on PyPI. In fact, such a project
could be done without 'official' cooperation. If indeed there is no such
project, I would wonder whether such absence indicates an absence of need. Or
is it knowledge of how? Testing something as a 3rd party distribution and
getting community acceptance is one normal way for things to get added to the
stdlib.
(6, Suppose English speaking teachers or user might want to customize the menu
labels. Can that also be done with .gettext?)
* Besides uglifying the code a bit, this patch will break any existing patches
on the tracker that target the same lines and make tracing the history of any
patched line through hg annotate harder.
Thought also needs to be given to the extension mechanism. As I understand it,
pygettest.py will not pick up menu entries dynamically added by extensions.
Roger, the extension expert, might comment on this.
----------
stage: patch review -> test needed
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue17776>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
