[Python-3000] gettext

Torsten Bronger bronger at physik.rwth-aachen.de
Wed Apr 30 20:41:55 CEST 2008


Hallöchen!

Barry Warsaw writes:

> On Apr 24, 2008, at 6:18 PM, Guido van Rossum wrote:
>
>> [...]
>>
>> ---------- Forwarded message ----------
>> From: Benjamin Peterson <musiccomposition at gmail.com>
>> Date: Wed, Apr 23, 2008 at 7:32 AM
>> Subject: [Python-3000] gettext
>> To: Python 3000 <python-3000 at python.org>
>>
>> [...]
>>
>> Are we going to want to keep the "u" variants of the gettext APIs
>> around in 3.0? Also, the unicode parameters (for .install
>> methods) don't make much sense in 3.0.
>>
>> I don't see how we could remove them in 3.0, but perhaps rename
>> then to their non-"u" variants and deprecate?
>
> I wonder if it makes more sense to keep a unicode version and a
> bytes version.  The simplest solution then would be to change
> gettext() to return an encoded bytes and leave ugettext() to
> return the unicode string.  I don't have a sense for how useful an
> encoded translated bytes will be in the real world, and I do think
> that the unicode translation will be far more likely.

Indeed.  From today's perspective, I see no use case for getting
human text snippets in byte strings encoded with the same encoding
that just happened to be used in the .mo file, or with the
"preferred system encoding".

So it is only about the question how much hassle a
renaming/deprecation generates for existing code.

> That might argue for renaming ugettext() to gettext() and adding
> something like a egettext() or bgettext() method.

Okay.  But I think its not much advantage to have the "encoded"
functions under new names, given that instead of renaming, you can
also easily use ugettext to mimic their behaviour.

> OTOH, the current names are inspired from GNU gettext so it seems
> to me there's not much value in renaming our methods, except to
> increase confusion and break backward compatibility <wink>.

Well, this is hard to evaluate.  However, I think that if there is
no danger of getting silent errors, then the module should switch to
unicode, possibly even unicode-only.  After all, the results of
gettext are likely to be passed to higher-level functions that use
(or will switch to) unicode, too.

As for "gettext" returning a unicode string: If clearly documented,
I see not too much harm in using a different type scheme than C
gettext; this should be acceptable in a reimplementation in another
language.

Just my 2c.

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
                                      Jabber ID: bronger at jabber.org
               (See http://ime.webhop.org for further contact info.)



More information about the Python-3000 mailing list