Re: More i18n

[Kevin Ryde]

address@hidden (Ludovic Courtès) writes:
>
>   4. No attempt is made to convert to a different encoding the strings
>      returned by `nl_langinfo ()'.

Good.

>   5. High-level procedures for locale-dependent number output are
>      provided, namely `number->locale-string' and
>      `monetary-amount->locale-string'.  Both of them are implemented in
>      Scheme (which is relieving, really ;-)).

See how much nicer it is :-).

> +* i18n Introduction::             Introduction to Guile's i18n support.

"i18n" is a horrible geek-ish abbreviation, much better written in
full in the manual.

> address@hidden {Scheme Procedure} make-locale category-list locale-name 
> [base-locale]

Just a single category too will be good there.  Just LC_ALL is
probably be almost always what's wanted.

> address@hidden {Scheme Variable} %global-locale

I'm worried if that should be a variable, rather than a function.

>  These procedures allow to account for these differences.

Slightly ungrammatical there (I'm sure it reads better in french :-).

> +This function is based on the C library's @code{strtod} function

Not any more?  Or just in a broadly similar style?

> address@hidden {Scheme Procedure} locale-era [locale]
> address@hidden {Scheme Procedure} locale-era-year [locale]
> +These functions return, respectively, the era and the year of the
> +relevant era used in @var{locale} or the current locale.  Most locales
> +do not define this value.

What do the functions do in that case (ie. no era)?  Will my computer
explode?

> address@hidden {Scheme Procedure} locale-digit-grouping [locale]
> +Return a (potentially circular) list denoting how digits

You could rearrange the words to get "list of integers" somewhere near
the start, for maximum clarity.

> +(define us (make-locale (list LC_MONETARY) "en_US"))

That's an example of where I think having to say "list" is a bit
pesky.  Just (make-locale LC_MONETARY ...) will be good.

> +(locale-currency-symbol #f us)
> address@hidden "-$"

Is it actually "-$" there, or just "$"?

> address@hidden {Scheme Procedure} locale-yes-regexp [locale]
> address@hidden {Scheme Procedure} locale-no-regexp [locale]

These aren't gnu extensions are they?

> +Example uses of some of these functions are the implementation of the
> address@hidden>locale-string} and @code{monetary-amount->locale-string}
> +procedures (@pxref{Number Input and Output}), as well as that the
> +SRFI-19 date and time convertion to/from strings (@pxref{SRFI-19}).

I wouldn't worry about that bit.  A nice broad introduction at the
start of the node should be ok.



> +(define (locale-encoding . locale)
> +  (apply nl-langinfo CODESET locale))

I think you should implement almost all these basic bits in C, and not
have a big nl-langinfo.  It'll be easier for a future localeconv
conditionals, or some of the DOS apis.  It'll also be smaller and
faster to load and run.

> +(define-vector-langinfo-mapping locale-day-short
> +  (ABDAY_1 ABDAY_2 ABDAY_3 ABDAY_4 ABDAY_5 ABDAY_6 ABDAY_7)
> +  ("Sun" "Mon" "Tue" "Wed" "Thu" "Fri" "Sat"))

These in C too I think.

> number formatting ...
>
> +    (let loop ((index (- strlen 1))
> +               (grouping grouping)
> +               (since-separator 0)
> +               (result ""))

Consider breaking out of the loop when grouping is null, and in any
case going group by group instead of character by character.

The result could be built as a list of strings to be concatenated at
the end too (string-concatenate/reverse or whatever it is).

>  ;;; Local Variables:
>  ;;; coding: latin-1

The fallbacks are all ascii aren't they?

> nl-langinfo ...
> +      However, `scm_from_locale_string',
> +      which expects a Latin-1 string, won't be able to make much sense of the
> +      returned string.

No need to be too worried about that.  scm_from_locale_string is
little more than a placeholder until there's a notion of coding within
strings.  Almost every call to it will have to be reviewed for whether
it's actually the locale charset, another charset, or binary bytes.

> nl-langinfo ...
> +      switch (c_item)
> +     {
> +     case GROUPING:
> +     case MON_GROUPING:

Special cases like that will be cleaner in their own function I think.

> +  scm_syserror_msg (FUNC_NAME,
> +                 "`language-information' not supported on your system",

Still `language-information'?

I expect if each `locale-foo' is a separate func then they should be
able to return sensible defaults, avoiding such an error.


> +(define (priv:vector-find needle haystack-ref haystack-len comparator)

Does that still search a vector?  Could rename it if not.  Whatever it
does now, a func call int range searcher or whatever.

> +;;;
> +;;; `nl-langinfo'
> +;;;

Could make a separate section for each func exercised there
(irrespective what they do internally).


Apart from that it all looks good.