guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MinGW vs. setlocale


From: Eli Zaretskii
Subject: Re: MinGW vs. setlocale
Date: Wed, 11 Jun 2014 18:33:26 +0300

> From: address@hidden (Ludovic Courtès)
> Cc: address@hidden
> Date: Wed, 11 Jun 2014 15:13:58 +0200
> 
> > First, make-locale threw an exception, because it tried to call
> > 'setlocale' with LC_MESSAGES, which the Windows runtime doesn't
> > support.  locale-categories.h tried to avoid that by conditioning that
> > call by LC_MESSAGES being defined, but the oh-so-helpful libintl.h
> > header file just happens to define it to some arbitrary large
> > constant.  So the ifdef didn't work, and setlocale barfed.  Here's the
> > suggested solution:
> 
> Pushed as c84f25b.
> 
> > The next problem is that i18n.test uses Posix locale strings, whereas
> > the Windows runtime names the same locales by different names.
> > Moreover, Windows 'setlocale' doesn't support UTF-8 encoding (even
> > though a Windows UTF-8 codepage exists).  So every test for a locale
> > other than "C" was failing, because setlocale failed.  I replaced
> > Posix locales with similar Windows ones; see the following patch, in
> > which I also emoved all but one LC_MESSAGES, because these always fail
> > on Windows:
> 
> Ditto.

Thanks.

> > 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.

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?)

> ‘under-locale-or-unresolved’ catches any failure to install the French,
> Greek, etc. locale (which can happens if the locale is missing on the
> system), and throws 'unresolved when that happens.

Well, after I solved the problem with LC_MESSAGES, make-locale no
longer throws 'unresolved.  The problem is now with the comparison
routines themselves, see above.

> So presumably, those UNRESOLVED mean that (setlocale LC_ALL "fra_FRA.850")
> and similar calls just fail.

No, that one works, I tested it manually.

> >   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?

> (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?
These don't work on Windows.

Thanks.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]