It's quiet in here ...</LURK>  Sorry, this is longer than I intended.

I thought it would be interesting to compare your SRFI with the Forth
equivalent - both it and Scheme are fairly minimal languages, and just a
little outside the mainstream.  The Forth standards proposal is at the
end of http://www.mpeltd.demon.co.uk/arena.htm#papers

I'll try to limit this to the SRFI's scope (e.g. no wide characters).

1.  current-locale:
------------------
Instead of returning a list, Forth provides two words get-language and
get-country.  These deal with the ISO codes (e.g. en, de, us, ie),
apparently in the equivalent of symbol form (words).

Note that set-language and set-country are provided also.  Arguably,
this is nice for symmetry, but I think it's better to leave locale
selection up to the user (e.g. using environment variables).

2.  declare-bundle and localized-template:
-----------------------------------------
Instead of a high-level data structure, Forth just defines a method to
store references to language-dependent strings in memory - L".  Thus its
dictionaries have string keys like GNU gettext, rather than the (int,
int) tuples of XPG4 or your own '(package msg-sym).  Presumably then
there is an auxiliary file like an XPG4 message catalogue which holds
the text for different languages - this is left up to the implementation.

Interestingly, they include a simple string macro expander as an
integral part, similar to SRFI-28.

----------

Overall, well done on actually bothering to write an SRFI.  I had been
daydreaming about doing something similar for months.  But now, here's
my feedback:

*  I'm worried about performance and/or fitting in with the host OS.  I
know almost all software runs "fast enough", but XPG4 implementations
can go to some lengths (on-disk hashes mmapped into RAM) for speed.  I
would guess that this isn't for nothing.

Even if nobody does, I'd like to allow implementors the latitude to do
something like this, or better, just interface to the system libraries
with an FFI.  So I'd suggest defining declare-bundle as a sublanguage,
somewhat like SRFI-7.  The sample implementation could remain the same
and you could just load these files, but at least people would then be
able to use a different scheme, say generating a message catalogue from
the source.

All this really needs is a statement saying that declare-bundle needn't
necessarily be full Scheme and that you should put the declare-bundles
for each language in a separate source file.

I'd almost consider the ability to implement this SRFI in terms of the
native OS facilities (which for me is XPG4) a requirement.

*  localized-template is a lot of typing.  For comparison, one Forth
equivalent of

    (display (format (localized-template 'package 'hello-msg))) is
    L" Hello World!" xxxxxx@ PAD 84 SUBSTITUTE TYPE CR

Hmm.  Maybe you should just ignore that.

*  One advantage of using strings as keys into the dictionary instead of
integers/symbols is that the string can be the default message if no
local translation is found.  XPG4 doesn't do this, and has to have
another parameter to catgets for the default (although you could always
just pass NULL).

However, having said that, I prefer things the way they are.

Just thought I'd get the ball rolling ...

----------

   REFERENCES

ANS Forth Internationalisation proposal
(http://www.mpeltd.demon.co.uk/arena/i18n.propose.v7.PDF)
gencat(1)
(http://www.openbsd.org/cgi-bin/man.cgi?query=gencat&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html)
catopen(3)
(http://www.openbsd.org/cgi-bin/man.cgi?query=catopen&sektion=3&apropos=0&manpath=OpenBSD+Current)
catgets(3)
(http://www.openbsd.org/cgi-bin/man.cgi?query=catgets&sektion=3&apropos=0&manpath=OpenBSD+Current)
catclose(3)
(http://www.openbsd.org/cgi-bin/man.cgi?query=catclose&sektion=3&apropos=0&manpath=OpenBSD+Current)
gettext(3) (http://www.gnu.org/manual/gettext/html_chapter/gettext_toc.html)
--
Darren Bane