[Python-Dev] Small issues in gettext support (original) (raw)
Gustavo Niemeyer niemeyer at conectiva.com
Tue Apr 27 17:26:43 EDT 2004
- Previous message: [Python-Dev] Small issues in gettext support
- Next message: [Python-Dev] Small issues in gettext support
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
That shouldn't be sys.getdefaultencoding(), but locale.getpreferredencoding().
Agreed.
However, I agree with Barry that the current behaviour should not be changed. People may already rely on gettext returning byte strings as-is.
Barry also said:
""" Any sane app is going to use the class-based API an the ugettext() method anyway, so maybe it does make sense to simply be API compatible with GNU gettext for the old-style interface. """
>- Change the default codeset used by gettext.py in functions > returning an encoded string to match the system encoding.
No. Explicit is better that implicit; users desiring that feature should write [...]
You belive that returning a string in some unpredictable encoding used by the translator is explicit? I have to disagree. We have something named 'gettext' with a different behavior than the original project, in a way that breaks the concepts used to decide the behavior of the classical implementation.
I advocate never to use gettext.install, in which case you have a custom implementation anyway, which would then [...]
"You shouldn't be using it" is not a point I'm taking into account.
>- Introduce bindtextdomaincodeset() in locale. >- Introduce bindtextdomaincodeset() in gettext.py implementing > an equivalent functionality.
That is ok. You could also try to provide that feature consistently, e.g. inside .install.
Agreed.
-- Gustavo Niemeyer http://niemeyer.net
- Previous message: [Python-Dev] Small issues in gettext support
- Next message: [Python-Dev] Small issues in gettext support
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]