>>>>> "Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes:
Guido> I certainly didn't mean to rule that out.
Speaking for myself, that's all I really wanted to hear at this time.
As Bob Ippolito said, currently it's straightforward to
internationalize an application, and well worth the minimal overhead
if it's at all serious. It's just that it would be nice if quick and
dirty additions for i18n programs could be done as easily and with the
same facility as for mono-Euro-lingual programs. I also think that at
present Python is to the point where it's natural to write in a style
where i18n is nearly costless (I use unicode strings habitually, and
prefer %(var)s to positional %s anyway, because I find it easier to
read). It would be a shame to regress from that!
Why "mono-Euro-lingual"? Well, in teaching Python in Japan, one thing
that is really annoying about the current print statement is that
automatic spacing. Japanese doesn't use spaces to separate words, so
you basically have to start with the '%' operator when teaching
Japanese students output using variables. Several of them have said
"oh, another typical American software that breaks Japanese". Dunno
what to do about that, though, setting that based on the POSIX locale
would break my personal usage (when things are broken, I want to see
the debug output in English!)
Guido> But I doubt that the only text to be i18n'd will occur in
Guido> printf format strings. (In fact, I expect that few apps
Guido> requiring i18n will be so primitive as to use *any* printf
Guido> calls at all.)
Personally I don't write complex applications in native Python, I
write them for Zope or something like that. Then I don't have to
worry about generic Python facilities; I have to use whatever the
substrate is using. However, I do write simple CGIs that need to
produce English and Japanese pages (at least), and it's often enough
to write something like (this is from memory):
def addressWarningPage (formDict)
simplePageHeader (_("Address Warning"))
print _("""\
I'm sorry, %(user)s, but the address you submitted is %(address)s,
which appears to be a mobile phone address. Please use a real email
address, because the mailing list for %(course)s distributes large
attachments.""") % formDict
simplePageFooter ()
where the simplePageFunctions themselves have been inherited from old
code that simply 'print'ed to stdout, and formDict is constructed by
the underlying CGI handler, so it's always available. I write a fair
number of these pages, there are always new ways to go wrong....
This is very similar to what Bob Ippolito describes, and it's easy
enough to do. However, my translators _do_ confuse the "s" for
"string argument" with English pluralization (they're not native
English speakers, usually). It would be nice (for me) if we could
use notation that doesn't use stray format characters. It would be
nice to be able to lose the "_()" calls to gettext(). The function
would look to see if a message catalog was available for the current
output stream, and if not, do no translation. (I'm not sure this can
work, because it might conflict with things done automatically based
on environment settings of POSIX locale.)
It would be nice if a single function could support format strings
with positional arguments and those with named variable substitution.
(Not at the same time, though, that should be an error, I think.) If
not, a separate function would be easy enough to support in a
conversion script.
All that's still pretty abstract, I guess. But so far, I don't see
any reason why your proposal for the $1 positional syntax in printf()
hinders any of the above. I just wanted to make sure that asking for
them is OK.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
