On Thu, 2009-09-24 at 17:29 +0200, Ludovic Courtès wrote: > Hi Mike, > > "Michael Gran" <spk...@yahoo.com> writes: > > Language-specific case-conversion doesn't honor locale > > > > Libunistring uses a function uc_locale_language to extract the > > current language from the locale information. It does this by calling > > setlocale. This makes incompatible with Guile functions that use the > > locale_t thread-specific locale API, because the values returned by the > > call to setlocale ignore the locale set by uselocale. > > > > As a workaround, this patch extracts the language from the locale_t > > structure's __names field. > > Unfortunately this is not an option because it’s way too fragile, and > will not compile non-GNU systems that implement this API (such as > Darwin, and any POSIX 2008 system).
Yeah. I know it is a poor solution. I just wanted to throw something out there to explain the problem. > > How about reporting a bug against libunistring so that it uses > uselocale(3) instead of setlocale(3) to determine the current language > when uselocale(3) is available? I plan to. It would be a big change, though. Using POSIX 2008, there is apparently no way to get from a locale_t to the language part of the LC_CTYPE. Say I create a Mexican Spanish locale with makelocale(LC_CTYPE, "es_MX.utf8") I can then extract the 'utf8' part of the locale using nl_langinfo_l(loc, CODESET). But, I don't see any way to extract the "es_MX" part of the LC_CTYPE other than by accessing the locale_t structure directly. Unless I'm missing something obvious. Bruno's libunistring code relies on the ability to extract the language of the locale (the "es" part of "es_MX.utf8"), which is easy when calling setlocale. So he'd have to re-write a significant bit of code to work around it to make it work with uselocale. > > Furthermore, we could suggest that support for the ‘locale_t’ API would > be great. :-) Poor Bruno. > > Thanks, > Ludo’. Thanks, Mike
