guile-devel
[Top][All Lists]
Advanced

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

Re: More i18n


From: Ludovic Courtès
Subject: Re: More i18n
Date: Wed, 31 Jan 2007 22:13:43 +0100
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)

Hi,

I finally went ahead and merged the new i18n module into HEAD for you to
test.  Hopefully nothing will break and the i18n API won't need to
changed (much).  ;-)

A few more notes...

Kevin Ryde <address@hidden> writes:

> Call the node just "Internationalization" and then call the sub nodes
> something else, that should fit fine.  There's a good chance people
> coming to such matters for the first time won't even know what "i18n"
> stands for.

Not possible, because "Internationalization" already names the parent
node, and "Introduction" alone probably isn't a good idea.

>>%global-locale
>> I wondered too.  My conclusion is that there's nothing to be afraid of:
>> after all, it's a special object and we have full control over it
>> (pretty much like the EOF object, for instance[*]).
>
> If someone sets the locale with setlocale from C, does it still work,
> or does %global-locale get out of sync.  Gtk likes to do that for
> instance.

Yes, it works.  `%global-locale' is just a locale SMOB whose value is
NULL instead of pointing to an actual `scm_locale_t' object.

>> I think the above Scheme constructs are easier to work
>> with (to maintain, to add `localeconv' support, etc.) than a C
>> equivalent.
>
> I think you'll find it's easier in C, especially if you have to worry
> about different combinations of fallbacks in different funcs.

At this point I'm not convinced about C being easier to deal with but
we'll see when we add `strftime' or `localeconv' support.

> If you can bring it to a high state of polish then you can put it all
> in 1.8.

Back in November or December, there was quite a consensus on this list
about having a strict policy for stable releases, where no new feature
would be added.  Back then, I advocated your approach, but a strict
policy has clear advantages, so we should probably stick to it.

>> I prefer to explicitly specify the encoding of non-ASCII files.
>
> But is it non-ascii?

The very presence of my family name in the file makes it non-ASCII.  :-)

Thanks,
Ludovic.





reply via email to

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