[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Guile-commits] GNU Guile branch, master, updated. release_1-9-3-34-
From: |
Mike Gran |
Subject: |
Re: [Guile-commits] GNU Guile branch, master, updated. release_1-9-3-34-gaafb506 |
Date: |
Thu, 24 Sep 2009 09:25:31 -0700 |
On Thu, 2009-09-24 at 17:29 +0200, Ludovic Courtès wrote:
> Hi Mike,
>
> "Michael Gran" <address@hidden> 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