Re: i18n

[Sam S. <sd...@gn...>]

> * Bruno Haible <oe...@py...> [2011-08-24 09:16:11 +0200]:
>
> Sam wrote:
>> setlocale(5, "fr_FR")                            = NULL
> This explains it.

what's inexplicable is that the error is silently ignored.

>> Apparently because "locale -a" does not list fr_FR.
>
> But it will likely have the locale "fr_FR.UTF-8" (or "fr_FR.utf8"
> which is the name under which it is stored on disk)?

no, all I have is C, POSIX and a bunch of en_* locales (I am an
English-only bigot, remember? ;-)

> I think the code in spvw_language.d lines 137..140 should be
> changed from
>   setenv (LC_MESSAGES, locale, 1);
>   setlocale (LC_MESSAGES, locale);
> to
>   char locale_utf8[32];
>   strcpy (locale_utf8, locale);
>   strcat (locale_utf8, ".UTF-8");
>   setenv (LC_MESSAGES, locale_utf8, 1);
>   if (setlocale (LC_MESSAGES, locale_utf8) == NULL) {
>     setenv (LC_MESSAGES, locale, 1);
>     setlocale (LC_MESSAGES, locale);
>   }
> so that it tries first fr_FR.UTF-8 and then, if that fails, fr_FR.

is it possible to have fr_FR.UTF-8 and not fr_FR?
let's see, on a machine with many locales:
$ locale -a | wc
    650     650    6924
$ locale -a | egrep '\.' | cut -d. -f1 | sort -u > with-dot
$ locale -a | egrep -v '[.@]' | sort > no-dot
$ comm -23 with-dot no-dot 
as_IN
az_AZ
tt_RU
$ locale -a | grep tt_RU
tt_RU.utf8
$ locale -a | grep as_IN
as_IN.utf8
$ locale -a | grep az_AZ
az_AZ.utf8
$

interesting.
so it is possible.
fine, but since both locale and locale_utf8 are known constants,
I will do it without strcpy et al.
thanks for the suggestion!

> By the way, in line 132, the Danish locale is "da_DK", not "da_DA",

fixed, thanks.

>> Does setlocale set errno? (the man page is silent).
>
> No, setlocale simply returns NULL when it fails.
>
>> I think init_language is called too early - before the memory is
>> initialized, so we cannot signal lisp errors yet.
>> I think it should be called via C_set_current_language after the memory
>> is initialized and it should raise lisp errors on any failure
>
> This is debatable. The usual approach with missing translations and
> missing locales is to be lenient. If you signal an error, clisp will
> not start up at all, and that is not useful for the user.

Okay, so when called during startup it will be a warning, not an error.
My point is that ignoring errors is always wrong.
If setting locale fails, the user should be notified about it and not
left wondering why (sys::test "Bye.") returns "Bye." - is it because the
word was not translated or something else?

At any rate, apparently you do not object to moving init_language past
initmem and letting it indicate a failure as long as it does not prevent
clisp from starting up.

Now, what _is_ a failure?

1. setlocale --> NULL

2. textdomain --> NULL ==> errno

3. bindtextdomain --> NULL ==> errno

4. bind_textdomain_codeset --> errno != 0 (may return NULL on success!)

is this right?

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 11.0.60900031
http://pmw.org.il http://truepeace.org http://openvotingconsortium.org
http://iris.org.il http://www.PetitionOnline.com/tap12009/
Experience comes with debts.