[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: More i18n
From: |
Kevin Ryde |
Subject: |
Re: More i18n |
Date: |
Thu, 25 Jan 2007 07:58:12 +1100 |
User-agent: |
Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) |
address@hidden (Ludovic Courtès) writes:
>
> Agreed, but that's only the name of the Info node. Changing it here
> would make the line too long for Info.
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.
>%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.
> 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.
> (Besides, I don't think it's very high priority, especially since it
> doesn't have any impact on the API itself.)
If you can bring it to a high state of polish then you can put it all
in 1.8.
> What does it buy us to apply `string-append' at the end rather than
> `string-append' at each step?
string-append at each step means O(n^2) worth of copying (in the
string length). That afflicted output string ports until recently.
Of course whether anyone should be using a big number there is
debatable, but at least we can ensure performance doesn't prevent one
from doing so.
> I prefer to explicitly specify the encoding of non-ASCII files.
But is it non-ascii?
Re: More i18n, Kevin Ryde, 2007/01/24