Re: Accessing the environment's locale encoding settings

[Noah Lavine <noah.b.lavine@gmail.com>]

Hello,

It seems like the right thing to do might be to do setlocale(LC_ALL,
"") in Guile's main(). Let me argue that this accomplishes two goals
which we want to accomplish
  - it does the right thing by default: you want your program to be
able to talk to the user in the user's own language. This accomplishes
that, and also fixes the bug that has been discussed.
  - it lets the user customize Guile's behavior: the user has two
options for going back to the old behavior. First of all, they can do
setlocale(LC_ALL, "C") as soon as their program starts to get back the
default behavior. Second, if they really don't want any locale
changes, they can provide their own main function. We might even be
able to offer a configuration option, so that they could use Guile's
main except for the setlocale call.

However, it seems like in this case, setlocale(LC_ALL, "") is the
right thing in almost every case, and it should just be Guile's
default.

Noah

On Wed, Nov 16, 2011 at 2:35 AM, Ludovic Courtès <ludo@gnu.org> wrote:
> Hi Bruno,
>
> Thanks for your quick and insightful feedback.
>
> Bruno Haible <bruno@clisp.org> skribis:
>
>> That is precisely the point. Only in C, C++, Objective C, PHP, and Guile,
>> it is the user's responsibility to set the locale. Look at the many
>> internationalization samples ("hello world" samples) in GNU gettext:
>> In all other languages (and even many GUI toolkits based on C, C++, or
>> Objective C) the setlocale call is implicit.
>
> It seems to me that the implicit call is often desirable, but at the
> same time, it imposes a policy on the application.  In C, Guile, & co.,
> the application can choose to ignore the locale, or to just honor
> LC_CTYPE, or to set something different.  Perhaps this point is moot if
> the other languages allow the locale to be set afterward without any
> loss of functionality, though...
>
>> The user should *not* have to worry about conversion of strings from/to
>> locale encoding, because
>>   1) This is what people expect from a scripting language nowadays.
>>   2) In Guile strings are sequences of Unicode characters [1][2].
>
> Agreed.
>
> [...]
>
>> So my suggestion is to do (setlocale LC_ALL "") as part of the Guile
>> initialization, very early. Yes, this might lead to some complexity
>> in the Guile implementation if you have the concept of locale also at
>> the Guile level and need to make sure that the locale at the C level and
>> the locale at the Guile level are consistent as soon as the latter is
>> defined. But this is manageable.
>
> Are you suggesting that we could arrange to have Guile’s ‘main’ call
> setlocale(LC_ALL, "") while still giving Scheme code the impression that
> it’s started under the C locale as is currently the case?
>
> Just adding setlocale(LC_ALL, "") in Guile’s ‘main’ would be an
> incompatible change, which would break Scheme applications relying on
> the current behavior–e.g., applications intended to be all-English.
>
> A reasonable option would be to setlocale(LC_CTYPE, "") from Guile’s
> ‘main’, so that scm_from_locale_string & co. would DTRT.  But again that
> would change the value of %default-port-encoding, leading to potential
> application breakage.
>
> Thanks,
> Ludo’.
>
>