I integrated X/Open compatible message catalog functions before the
1.0 code freeze; and have added support for strerror(), strsignal(),
perror(), and psignal() since then.  I know any foreign languages, so
I haven't translated any of the messages.  But it works well with the
"Pig" message catalog I whipped up by munging the C locale message
catalog with pig(6).

Like YP, libc NLS support can be enabled by defining a preprocessor
macro; in this case -DNLS.  The question is: Should this macro be
added to CFLAGS by default in libc's toplevel Makefile?

Reasons for:
	1. It ensure that NLS support is available to all users.

	2. It would tell the world that NetBSD is at least somewhat
	   aware of the real world.  Perhaps it would convince some
	   non-north-american to contribute the appropriate
	   localization tables and/or message catalogs.

Reasons against:
	1. It makes statically linked executables that use any of the
	   above mentioned functions that much bigger & slower.

	2. If __strerror() & __strsignal() (The functions that
	   implement the "guts" of the above mentioned functions) call
	   the NLS functions, it takes the C library farther from the
	   goal of strict ANSI compliance.  This is because cat* is in
	   the user's namespace.

Rebuttal of for position:
	1. Most NetBSD users are from english speaking countries; thus
	   NLS is useless to most of our user base.

Rebuttal of against position:
	1. It's not that much bigger or that much slower that it
	   matters.  In fact, I have versions of the NLS functions
	   that sit atop BSD's DB instead of their own database format
	   that would make the differences even smaller.

	2. It's not that difficult to change NLS to have __cat*
	   functions that are called from within the library; and cat*
	   functions that call the __cat* functions to supply the
	   X/Open NLS API.  We could even weak symbols and linker
	   magic to do this, so there would be no overhead.

I hope you realize that I've thought quite a bit about this issue.
I'd like to enable -DNLS, but I thought I'd ask a larger user base
before I do.

	--jtc