guile-devel
[Top][All Lists]
Advanced

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

Re: More i18n


From: Kevin Ryde
Subject: Re: More i18n
Date: Wed, 13 Dec 2006 06:43:25 +1100
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)

address@hidden (Ludovic Courtès) writes:
>
> My understanding is that, implicitly, Guile currently uses the current
> locale's encoding as its "internal representation".

Not really, I believe it's a case of encoding ignorance, or at best
agnosticism :-).  A few functions care, but on the whole there's
nothing uniformly applied.

No doubt this is set to change, but for now you can have different
strings with different encodings (as I've had the misfortune to be
doing lately).  If there were a single encoding enforced for strings
then you'd for instance like existing strings converted upon doing a
setlocale.

All changing in the perhaps near future, until then I'd suggest doing
as little as possible.  (Make sure it's 8-bit clean and leave it at
that.)

> Are there many systems that provide `localeconv' but not `nl_langinfo'?
> I guess Windows has the former but not the latter, in which case it
> might make sense to support it.

Supposedly there's a GetLocaleInfo or something on DOS, if anyone
cared.

> The issue is that (i) it is glibc-specific and (ii) it is not a desired
> behavior in many cases.

Yes, //translit is glibc, but putting question marks for bad chars is
possible everywhere, and would be a nice feature, eventually.




reply via email to

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