背景、细节、提示、技巧和告诫
¶
The C standard defines the locale as a program-wide property that may be relatively expensive to change. On top of that, some implementations are broken in such a way that frequent locale changes may cause core dumps. This makes the locale somewhat painful to use correctly.
Initially, when a program is started, the locale is the
C
locale, no matter what the user’s preferred locale is. There is one exception: the
LC_CTYPE
category is changed at startup to set the current locale encoding to the user’s preferred locale encoding. The program must explicitly say that it wants the user’s preferred locale settings for other categories by calling
setlocale(LC_ALL, '')
.
It is generally a bad idea to call
setlocale()
in some library routine, since as a side effect it affects the entire program. Saving and restoring it is almost as bad: it is expensive and affects other threads that happen to run before the settings have been restored.
If, when coding a module for general use, you need a locale independent version of an operation that is affected by the locale (such as certain formats used with
time.strftime()
), you will have to find a way to do it without using the standard library routine. Even better is convincing yourself that using locale settings is okay. Only as a last resort should you document that your module is not compatible with non-
C
locale settings.
The only way to perform numeric operations according to the locale is to use the special functions defined by this module:
atof()
,
atoi()
,
format_string()
,
str()
.
There is no way to perform case conversions and character classifications according to the locale. For (Unicode) text strings these are done according to the character value only, while for byte strings, the conversions and classifications are done according to the ASCII value of the byte, and bytes whose high bit is set (i.e., non-ASCII bytes) are never converted or considered part of a character class such as letter or whitespace.
用于嵌入 Python 的扩展写入器和程序
¶
扩展模块从不应调用
setlocale()
, except to find out what the current locale is. But since the return value can only be used portably to restore it, that is not very useful (except perhaps to find out whether or not the locale is
C
).
When Python code uses the
locale
module to change the locale, this also affects the embedding application. If the embedding application doesn’t want this to happen, it should remove the
_locale
extension module (which does all the work) from the table of built-in modules in the
config.c
file, and make sure that the
_locale
module is not accessible as a shared library.
访问消息分类
¶
-
区域设置。
gettext
(
msg
)
¶
-
区域设置。
dgettext
(
domain
,
msg
)
¶
-
区域设置。
dcgettext
(
domain
,
msg
,
category
)
¶
-
区域设置。
textdomain
(
domain
)
¶
-
区域设置。
bindtextdomain
(
domain
,
dir
)
¶
-
区域设置。
bind_textdomain_codeset
(
domain
,
codeset
)
¶
The locale module exposes the C library’s gettext interface on systems that provide this interface. It consists of the functions
gettext()
,
dgettext()
,
dcgettext()
,
textdomain()
,
bindtextdomain()
，和
bind_textdomain_codeset()
. These are similar to the same functions in the
gettext
module, but use the C library’s binary format for message catalogs, and the C library’s search algorithms for locating message catalogs.
Python applications should normally find no need to invoke these functions, and should use
gettext
instead. A known exception to this rule are applications that link with additional C libraries which internally invoke C functions
gettext
or
dcgettext
. For these applications, it may be necessary to bind the text domain, so that the libraries can properly locate their message catalogs.
