Re: More i18n

[Kevin Ryde <user42@zip.com.au>]

ludo@chbouib.org (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?


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel