Eli Zaretskii <e...@gnu.org> skribis: >> From: l...@gnu.org (Ludovic Courtès) >> Cc: guile-devel@gnu.org >> 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’.
