[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
A native XPG4 implementation (kind-of)
I wanted to implement the latest SRFI-29 draft on top
of the standard
XPG4 UNIX i18n support. However, I ended up
slightly different. The (Scheme 48) code is at
Here are the main differences:
* The test code did everything - creating the message
then reading them and printing the messages. I
split this into
make-vsrfi-29-cat to actually build the message
Then a Makefile can compile this into binary
vsrfi-29 can read these and print the messages.
I know that Scheme is supposed to be written
interactively, but I
wouldn't like to exclude users of the likes of
Stalin or Bigloo
either. They'll be using offline compilation, and
code like above is the best way I can see to
support this. I'd
like this behaviour to be explicitly allowed in an
* I don't implement store-bundle. declare-bundle!
catalogue source (i.e. not readable by load-bundle!
processing) as well. If load-bundle! fails, it IS
Again, this is motivated by the same concerns.
* Instead of taking a symbol message ID,
localized-template takes an
integer. It's most likely my inexperience with
Scheme, but I had
to put in an (evil :-)) eval to convert from one to
inside the SRFI-29 implementation itself.
* current-language and current-country don't actually
messages used. The way to specify this in XPG4
under OpenBSD is
the NLSPATH environment variable (e.g. mine is
$HOME/scm/nls/$LC_MESSAGES). Still, I implemented
it, as programs
might find it useful.
One other point which I thought was badly specified
current-locale-details. I think implementers are
given so much
latitude as to make it useless. I'd suggest making it
alist instead of a list of symbols, and have the same
keys as fields in
the C struct lconv (see the localeconv or setlocale
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts