[Bug locale/20184] New: API for language priority list
ueno at gnu dot org
sourceware-bugzilla@sourceware.org
Tue May 31 09:15:00 GMT 2016
https://sourceware.org/bugzilla/show_bug.cgi?id=20184
Bug ID: 20184
Summary: API for language priority list
Product: glibc
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: locale
Assignee: unassigned at sourceware dot org
Reporter: ueno at gnu dot org
Target Milestone: ---
While discussing on potentially thread-unsafe getenv() call in gettext() for
LANGUAGE, Bruno Haible suggested to add an API that is equivalent to the envvar
setting, in a lower layer than gettext():
https://lists.gnu.org/archive/html/bug-gettext/2016-05/msg00009.html
At first it seems a bit overkill to me though (because the only user is
currently gettext()), the concept itself seems not uncommon: W3C ltli[1]
defines the term "language priority list" and ICU4J provides a class
LocalePriorityList[2] so multilingual applications might benefit from the API.
My current suggestion is to add the following two functions to
<locale.h> as a GNU extension:
/* Sets the language priority list for the calling thread to LANGUAGES.
LANGUAGES may be a colon-separated list of language codes.
If LANGUAGES is NULL, use the one inferred from the environment
variable 'LANGUAGE'.
The effect of the language priority list is application
dependent. However, supporting applications should give
priority to the language priority list over the locale
settings.
This returns an opaque string that corresponds to the current
language priority list. */
const char *
set_language_priority_list (const char *languages);
/* Returns the language priority list for the calling thread.
This returns NULL if the list is not set yet, or an opaque string
that corresponds to the current language priority list. */
const char *
get_language_priority_list (void);
[1] https://www.w3.org/TR/ltli/
[2]
http://icu-project.org/apiref/icu4j/com/ibm/icu/util/LocalePriorityList.html
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the Glibc-bugs
mailing list