[Top][All Lists]
[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.
Re: More i18n, Kevin Ryde, 2007/01/24