named locale error checking

[Nathan Myers]

On Thu, Jun 28, 2001 at 03:29:02PM -0700, Benjamin Kosnik wrote:
> I've a question about how to handle error checking in named
> locales. Under linux, available locales can be found by doing `locale
> -a` at shell prompt. 
> 
> However, these available locales are not necessarily complete. 
>  ... 
> In this case, nump_de is "mostly complete" in that everything except
> for _M_truename/_M_falsename is correct. (Getting correct true/false
> is not possible, only yes/no strings are localized.)
> 
> However, nump_fr isn't complete: _M_grouping isn't set, for one. 
> 
> Currently, v3 doesn't do error checking, but I think it should.
> ... 
> I'm thinking that even though "FR_fr" is a valid name, runtime_error
> should be thrown in the creation of the numpunct facet, because the
> info isn't complete (say runtime_error("numpunct facet incomplete")). 
> 
> In essence, this clarifies "valid name" to mean "we can construct a
> useful facet from the underlying OS" instead of "something by the name
> of that locale exists in the underlying OS"

The locales supplied are part of the "implementation".  If they are
not complete, that seeems like the implementation's problem; what is 
the user supposed to do about it?  To me, if the implemention comes 
with incomplete locales, then the implementation should tolerate 
incomplete locales gracefully.  That means the implementation should 
provide reasonable defaults for values not supplied.

This would also make things easier on locale composers, because they only 
have to specify differences from the defaults.

It is a separate issue that the set of locales supplied doesn't include 
versions with nicer number formats.

Nathan Myers
ncm at cantrip dot org