> The SRFI doesn't discuss any existing localization APIs.
> I suggest it might be a better to come up with an API
> that can work with existing tools and standards.  Specifically,
> I would recommend an API that can be implemented using the
> GNU gettext package.
>
> I suggest these two functions:
>
> (textdomain 'PACKAGE-NAME [LOCALE-DIR])
>    Look for translations for the package named PACKAGE-NAME.
>    The translation files are in LOCALE-DIR, which has an
>    implemengtation-specific default.
>
> (gettext "MESSAGE")
>    Look for a translation for "MESSAGE".  If one is found,
>    return it; otehrwise return "MESSAGE" unchanged.
>
> Example:
>    (textdomain 'hello-program)
>    (display (format (gettext "Hello, ~a!") myname))
>
> A trivial no-op implementation:
> (define (textdomain . args) 'ignore)
> (define (gettext msg) msg)

I think that this approach may be too specific to gettext.  I'd rather
modify the SRFI in such a way that it allowed bundles to be
stored/retrieved to a system-provided localization service, but that it
still accept association lists to create bundles from within Scheme.  An
implementation that uses gettext as a backend then need only implement
declare-bundle to store to a gettext compatible format.

This may not be sufficient, but in general my concern is that the SRFI
is supposed to allow portable, local independent messages to be
displayed, but if it requires translations into a bunch of system
dependent localization formats, then its a failure.

	Scott