1) gettext - mandating that it must use gettext is imho no good - even if
these days the situation is better for people with no resources to
re-implement it - is probably not a good idea. Those who just want to use
gettext can do so using a library binding, and it would imho be pretty
pointless to have that as a SRFI . gettext will also not be available or
appropriate in all places where scheme can be used.

2) not enough opaqueness - specificly, the whole part on creating bundles
from assoc lists isn't imho a good idea. Also, declare-bundle, being a
"global" mutator should probably be named differently.

3) one central locale - I think having a "one locale at a time" system
is fundamentaly broken, and its not just something i think. It is very
limiting and assumes just one use case. Once that use case no longer fits
(say you want to use threads and some threads want to use a different
locale  - oops!) you end up re-implementing the system.

4) the language/country system has its problems aswell (want to localise
to latin?), and these would more or less be resolved by using a string
instead. Also, having just language and country doesn't solve the problem
that the encoding may also need to be present - for example
fr_FR.ISO_8859-1 and fr_FR.UTF-8 will very probably need to be
distinguishable.

5) the process - I think its wrong to depend on another srfi (srfi 28 in
this case) that is not yet final.

---

	Sander

+++ Out of cheese error +++