This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.

### 708. Locales need to be per thread and updated for POSIX changes

Section: 28 [localization] Status: NAD Submitter: Peter Dimov Opened: 2007-07-28 Last modified: 2019-02-26

Priority: Not Prioritized

View all other issues in [localization].

View all issues with NAD status.

Discussion:

The POSIX "Extended API Set Part 4,"

> http://www.opengroup.org/sib/details.tpl?id=C065

introduces extensions to the C locale mechanism that allow multiple concurrent locales to be used in the same application by introducing a type `locale_t` that is very similar to `std::locale`, and a number of `_l` functions that make use of it.

The global locale (set by setlocale) is now specified to be per- process. If a thread does not call `uselocale`, the global locale is in effect for that thread. It can install a per-thread locale by using `uselocale`.

There is also a nice `querylocale` mechanism by which one can obtain the name (such as "de_DE") for a specific `facet`, even for combined locales, with no `std::locale` equivalent.

`std::locale` should be harmonized with the new POSIX `locale_t` mechanism and provide equivalents for `uselocale` and `querylocale`.

[ Kona (2007): Bill and Nick to provide wording. ]

[ San Francisco: Bill and Nick still intend to provide wording, but this is a part of the task to be addressed by the group that will look into issue 860. ]

[ 2009-07 Frankfurt: ]

> It's our intention to stay in sync with WG14. If WG14 makes a decision that requires a change in WG21 the issue will be reopened.

> Move to NAD Future.

[LEWG Kona 2017]

Recommend NAD: `uselocale()` is bad; pass locales around as objects

[Kona 2019]

Jonathan points out: The standard already allows per-thread locales, see [locale] p9.

Proposed resolution: