Hi, A similar development is currently going on as part of GNU gettext. gettext-0.15 shall have a library libglocale, that contains a data type 'locale_t' representing a locale. It comes with all locale dependent APIs known from POSIX or glibc, with an additional 'locale' parameter. You find the API in the attached set of include files. The CVS is known from http://savannah.gnu.org/projects/gettext/. The purpose of this library is to allow 1) different threads to use different locales, without need for inter- locking, 2) the same thread to use multiple locales, without need for switching the global locale, 3) the gl_gettext(), gl_ngettext() functions to work in user-defined locales that are not installed as system locales. The library is written in C. This library shall be LGPLed. It borrows a lot of source code from glibc. It is separate from glibc, because the glibc maintainer didn't acknowledge that having a 'locale_t' data type usable on its own was important. He argues that tying it to the current thread is better. It will have its own (binary) locale data format, so that locales can be loaded efficiently through mmap(). However, unlike glibc, this locale data format is not depedent on the locale's encoding. ------------ Could this glocale library be merged with your planned CLDR functionality? The two look complementary: libc-style API for the traditional (ISO C) functionalities, augmented with new API to cover features of CLDR locales. The benefits would be: - Not two different locale libraries outside glibc, one in gettext and one in GNOME. - CLDR locales available to applications outside GNOME. Bruno
Attachment:
glocale-api.tar.gz
Description: application/tgz