Re: MinGW vs. setlocale

[Ludovic Courtès]

Eli Zaretskii <address@hidden> skribis:

>> From: address@hidden (Ludovic Courtès)
>> Cc: address@hidden
>> Date: Wed, 11 Jun 2014 15:13:58 +0200

[...]

>> > After all these changes, some tests still fail or throw exceptions:
>> >
>> >   UNRESOLVED: i18n.test: text collation (French): string-locale-ci=?
>> >   UNRESOLVED: i18n.test: text collation (French): string-locale-ci=? (2 
>> > args, wide strings)
>> >   UNRESOLVED: i18n.test: text collation (French): string-locale-ci=? (3 
>> > args, wide strings)
>> >   UNRESOLVED: i18n.test: text collation (French): string-locale-ci<>?
>> >   UNRESOLVED: i18n.test: text collation (French): string-locale-ci<>? 
>> > (wide strings)
>> >   UNRESOLVED: i18n.test: text collation (French): string-locale-ci<>? 
>> > (wide and narrow strings)
>> >   UNRESOLVED: i18n.test: text collation (French): char-locale-ci<>?
>> >   UNRESOLVED: i18n.test: text collation (French): char-locale-ci<>? (wide)
>> >   UNRESOLVED: i18n.test: text collation (Greek): string-locale-ci=?
>> >   UNRESOLVED: i18n.test: character mapping: char-locale-upcase Turkish
>> >   UNRESOLVED: i18n.test: character mapping: char-locale-downcase Turkish
>> >   UNRESOLVED: i18n.test: string mapping: string-locale-upcase Greek
>> >   UNRESOLVED: i18n.test: string mapping: string-locale-upcase Greek (two 
>> > sigmas)
>> >   UNRESOLVED: i18n.test: string mapping: string-locale-downcase Greek
>> >   UNRESOLVED: i18n.test: string mapping: string-locale-downcase Greek (two 
>> > sigmas)
>> >   UNRESOLVED: i18n.test: string mapping: string-locale-upcase Turkish
>> >   UNRESOLVED: i18n.test: string mapping: string-locale-downcase Turkish
>> >
>> > I don't know why these fail.
>> 
>> Note that “UNRESOLVED” is not a failure; it means “we can’t run this
>> test here, so skip it.”
>
> Yes, I understand that.  But "can't run" usually means the test threw
> some kind of exception, and I didn't understand why, especially since
> _some_ of the text collation tests did work (compare the above with
> the full list).
>
> I now know what is the reason for that, and I cannot say that I'm
> happier: it's libunistring's fault.  All these tests call libunistring
> functions that require the locale's language as an argument.  Problem
> is, libunistring doesn't support languages such as "fra" or "trk", it
> only supports "fr" and "tr".  In general, it only supports 3-letter
> language codes for those languages for which a 2-letter code doesn't
> exist.  By contrast, Windows _always_ uses 3-letter codes in valid
> locale names.
>
> So what happens is that locale_language always returns an empty
> string, and Guile calls u32_casecoll etc. with that empty string,
> which only works in the "C" locale.  In any other locale, the
> comparison fails with EILSEQ, and Guile throws the appropriate
> exception.

OK.  (It would be nice if someone would take over maintainership of
libunistring...)

> IOW, libunistring's port to Windows is not really useful.
>
> I will have to find some way around this issue, because otherwise
> Guile will be crippled in any locale but en_US.
>
> (Btw, why does Guile use libunistring instead of the ANSI functions
> for locale-dependent string comparison and collation?)

Because strings are internally either Latin-1 or UTF-32 (UCS-4).

[...]

>> >   FAIL: i18n.test: number->locale-string: French: integer
>> >   FAIL: i18n.test: number->locale-string: French: fraction
>> >   FAIL: i18n.test: number->locale-string: French: fraction, 1 digit
>> >   FAIL: i18n.test: monetary-amount->locale-string: French: integer
>> >   FAIL: i18n.test: monetary-amount->locale-string: French: fraction
>> >
>> > There's no blank after the 7th digit, where the test expects it.  Not
>> > sure what kind of problem is that, perhaps again due to gnulib's
>> > nl_langinfo.
>> 
>> You could try this:
>> 
>> --8<---------------cut here---------------start------------->8---
>> scheme@(guile-user)> ,m (ice-9 i18n)
>> scheme@(ice-9 i18n)> (locale-decimal-point (make-locale LC_ALL "fr_FR"))
>> $2 = ","
>> scheme@(ice-9 i18n)> (locale-thousands-separator (make-locale LC_ALL 
>> "fr_FR"))
>> $3 = " "
>> --8<---------------cut here---------------end--------------->8---
>
> I did try that, and saw a strange thing: the thousands separator is
> displayed as "\xa0".  That is very strange, because nl_langinfo does
> return " " for the French locale, as expected.  Why would the blank be
> translated into NBSP?  Can this also be due to libunistring problems?

NBSP is actually a better answer than just space, because it’d be unwise
to introduce a break in the middle of a number.

So does ‘number->locale-string’ return "123\xa0456" for you?

>> (Using the right locale name.)
>> 
>> >   UNRESOLVED: i18n.test: format ~h: French: 12345.5678
>> >   UNRESOLVED: i18n.test: format ~h: English: 12345.5678
>> >
>> > ~h is not supported on Windows.
>> 
>> ~h is implemented using ‘number->locale-string’.
>
> Maybe I'm confused, but isn't ~h about position directive in formats?

Yes, but that’s implemented in Scheme, in ice-9/format.scm.

> These don't work on Windows.

What doesn’t work?  ‘format’ doesn’t rely on any non-portable OS
facility.

Thanks,
Ludo’.