This page is part of the web mail archives of SRFI 29 from before July 7th, 2015. The new archives for SRFI 29 contain all messages, not just those from before July 7th, 2015.
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!" LOCALE@ 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 ... ---------- REFERENCESANS 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