The locale module opens access to the POSIX locale database and functionality. The POSIX locale mechanism allows programmers to deal with certain cultural issues in an application, without requiring the programmer to know all the specifics of each country where the software is executed.
The locale module is implemented on top of the _locale module, which in turn uses an ANSI C locale implementation if available.
The locale module defines the following exception and functions:
If locale is specified, it may be a string, a tuple of the form (language code, encoding), or None. If it is a tuple, it is converted to a string using the locale aliasing engine. If locale is given and not None, setlocale() modifies the locale setting for the category. The available categories are listed in the data description below. The value is the name of a locale. An empty string specifies the user’s default settings. If the modification of the locale fails, the exception Error is raised. If successful, the new locale setting is returned.
If locale is omitted or None, the current setting for category is returned.
setlocale() is not thread safe on most systems. Applications typically start with a call of
import locale
locale.setlocale(locale.LC_ALL, '')
This sets the locale for all categories to the user’s default setting (typically specified in the LANG environment variable). If the locale is not changed thereafter, using multithreading should not cause problems.
Changed in version 2.0: Added support for tuple values of the locale parameter.
Returns the database of the local conventions as a dictionary. This dictionary has the following strings as keys:
| Category | Key | Meaning |
|---|---|---|
| LC_NUMERIC | 'decimal_point' | Decimal point character. |
| 'grouping' | Sequence of numbers specifying which relative positions the 'thousands_sep' is expected. If the sequence is terminated with CHAR_MAX, no further grouping is performed. If the sequence terminates with a 0, the last group size is repeatedly used. | |
| 'thousands_sep' | Character used between groups. | |
| LC_MONETARY | 'int_curr_symbol' | International currency symbol. |
| 'currency_symbol' | Local currency symbol. | |
| 'p_cs_precedes/n_cs_precedes' | Whether the currency symbol precedes the value (for positive resp. negative values). | |
| 'p_sep_by_space/n_sep_by_space' | Whether the currency symbol is separated from the value by a space (for positive resp. negative values). | |
| 'mon_decimal_point' | Decimal point used for monetary values. | |
| 'frac_digits' | Number of fractional digits used in local formatting of monetary values. | |
| 'int_frac_digits' | Number of fractional digits used in international formatting of monetary values. | |
| 'mon_thousands_sep' | Group separator used for monetary values. | |
| 'mon_grouping' | Equivalent to 'grouping', used for monetary values. | |
| 'positive_sign' | Symbol used to annotate a positive monetary value. | |
| 'negative_sign' | Symbol used to annotate a negative monetary value. | |
| 'p_sign_posn/n_sign_posn' | The position of the sign (for positive resp. negative values), see below. |
All numeric values can be set to CHAR_MAX to indicate that there is no value specified in this locale.
The possible values for 'p_sign_posn' and 'n_sign_posn' are given below.
| Value | Explanation |
|---|---|
| 0 | Currency and value are surrounded by parentheses. |
| 1 | The sign should precede the value and currency symbol. |
| 2 | The sign should follow the value and currency symbol. |
| 3 | The sign should immediately precede the value. |
| 4 | The sign should immediately follow the value. |
| CHAR_MAX | Nothing is specified in this locale. |
Tries to determine the default locale settings and returns them as a tuple of the form (language code, encoding).
According to POSIX, a program which has not called setlocale(LC_ALL, '') runs using the portable 'C' locale. Calling setlocale(LC_ALL, '') lets it use the default locale as defined by the LANG variable. Since we do not want to interfere with the current locale setting we thus emulate the behavior in the way described above.
To maintain compatibility with other platforms, not only the LANG variable is tested, but a list of variables given as envvars parameter. The first found to be defined will be used. envvars defaults to the search path used in GNU gettext; it must always contain the variable name LANG. The GNU gettext search path contains 'LANGUAGE', 'LC_ALL', 'LC_CTYPE', and 'LANG', in that order.
Except for the code 'C', the language code corresponds to RFC 1766. language code and encoding may be None if their values cannot be determined.
New in version 2.0.
Returns the current setting for the given locale category as sequence containing language code, encoding. category may be one of the LC_* values except LC_ALL. It defaults to LC_CTYPE.
Except for the code 'C', the language code corresponds to RFC 1766. language code and encoding may be None if their values cannot be determined.
New in version 2.0.
Return the encoding used for text data, according to user preferences. User preferences are expressed differently on different systems, and might not be available programmatically on some systems, so this function only returns a guess.
On some systems, it is necessary to invoke setlocale() to obtain the user preferences, so this function is not thread-safe. If invoking setlocale is not necessary or desired, do_setlocale should be set to False.
New in version 2.3.
Returns a normalized locale code for the given locale name. The returned locale code is formatted for use with setlocale(). If normalization fails, the original name is returned unchanged.
If the given encoding is not known, the function defaults to the default encoding for the locale code just like setlocale().
New in version 2.0.
Sets the locale for category to the default setting.
The default setting is determined by calling getdefaultlocale(). category defaults to LC_ALL.
New in version 2.0.
Transforms a string to one that can be used for the built-in function cmp(), and still returns locale-aware results. This function can be used when the same string is compared repeatedly, e.g. when collating a sequence of strings.
Formats a number val according to the current LC_NUMERIC setting. The format follows the conventions of the % operator. For floating point values, the decimal point is modified if appropriate. If grouping is true, also takes the grouping into account.
If monetary is true, the conversion uses monetary thousands separator and grouping strings.
Please note that this function will only work for exactly one %char specifier. For whole format strings, use format_string().
Changed in version 2.5: Added the monetary parameter.
Processes formatting specifiers as in format % val, but takes the current locale settings into account.
New in version 2.5.
Formats a number val according to the current LC_MONETARY settings.
The returned string includes the currency symbol if symbol is true, which is the default. If grouping is true (which is not the default), grouping is done with the value. If international is true (which is not the default), the international currency symbol is used.
Note that this function will not work with the ‘C’ locale, so you have to set a locale via setlocale() first.
New in version 2.5.
Locale category for the character type functions. Depending on the settings of this category, the functions of module string dealing with case change their behaviour.
The nl_langinfo() function accepts one of the following keys. Most descriptions are taken from the corresponding description in the GNU C library.
Return name of the n-th day of the week.
Note
This follows the US convention of DAY_1 being Sunday, not the international convention (ISO 8601) that Monday is the first day of the week.
Return a regular expression that can be used with the regex function to recognize a positive response to a yes/no question.
Note
The expression is in the syntax suitable for the regex() function from the C library, which might differ from the syntax used in re.
The return value represents the era used in the current locale.
Most locales do not define this value. An example of a locale which does define this value is the Japanese one. In Japan, the traditional representation of dates includes the name of the era corresponding to the then-emperor’s reign.
Normally it should not be necessary to use this value directly. Specifying the E modifier in their format strings causes the strftime() function to use this information. The format of the returned string is not specified, and therefore you should not assume knowledge of it on different systems.
Example:
>>> import locale
>>> loc = locale.getlocale() # get current locale
>>> locale.setlocale(locale.LC_ALL, 'de_DE') # use German locale; name might vary with platform
>>> locale.strcoll('f\xe4n', 'foo') # compare a string containing an umlaut
>>> locale.setlocale(locale.LC_ALL, '') # use user's preferred locale
>>> locale.setlocale(locale.LC_ALL, 'C') # use default (C) locale
>>> locale.setlocale(locale.LC_ALL, loc) # restore saved locale
The C standard defines the locale as a program-wide property that may be relatively expensive to change. On top of that, some implementation 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. The program must explicitly say that it wants the user’s preferred locale settings 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 string.lower(), or 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 case conversion functions in the string module are affected by the locale settings. When a call to the setlocale() function changes the LC_CTYPE settings, the variables string.lowercase, string.uppercase and string.letters are recalculated. Note that code that uses these variable through ‘from ... import ...’, e.g. from string import letters, is not affected by subsequent setlocale() calls.
The only way to perform numeric operations according to the locale is to use the special functions defined by this module: atof(), atoi(), format(), str().
Extension modules should never call 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.
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(), and 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 use additional C libraries which internally invoke 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.