On Thu, Jun 28, 2001 at 07:12:31PM +0200, Bruno Haible wrote:
> Jarkko Hietaniemi writes:
>
> > No, we don't call nl_langinfo(CODESET). We still need to figure out
> > the correct policy and place for doing that.
>
> For robust CGI processing sometimes it makes sense to not use
> locales, that's clear.
>
> But for programs interacting with the user setting the locale should
> be a one-liner. In C you write
>
> setlocale(LC_ALL, "");
Well, that's exactly what we write in Perl, too :-)
(modulo importing the setlocale() and LC_ALL from the POSIX module,
and using the locale pragma to turn on locale awareness, so it's not really
a oneliner, but neither is the C version, the locale.h header is needed)
> In X11 you write
>
> XtSetLanguageProc(NULL,NULL,NULL);
>
> In Java it is automatic.
>
> It would be nice if in Perl it would be a one-liner as well.
>
> > > http://clisp.cons.org/~haible/packages-libcharset.html
> >
> > Alas, IIUC, LGPL is currently slightly incompatible for inclusion
> > into Perl, for something as central piece of a code as locale
> > handling.
>
> The LGPL wrapper is only needed for non-glibc systems (those without
> nl_langinfo, like DOS and FreeBSD, and those where nl_langinfo returns
> non-standardized strings, like Solaris). All we Linuxers really care
> about is that on glibc systems, you call nl_langinfo(CODESET).
As I said, LGPL as such won't work with Perl's licensing, but of
course it would be nice to have the "non-standard-locale-name-fixup"
code.
> > I will certainly give some thought to the matter.
>
> Thanks!
>
> Bruno
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
