Peter, It unfortunately reveals my true semantics of "non-localized"... I am getting better at "internationalizing", though, which definitely should include your point, of "mundanizing".
In the argument about the "what()" between you, Dave and Bill, I must say that "what()" should reveal something according to my narrow semantics of non-localized, i.e., should be directly intelligible to most English-speaking developers. If it can *also* serve as a key to a localized (or, rather, an instance of an "internationalized") lookup table, the better. Such a key is good. It is no secret that the Boost community, as the rest of the C++ world, tacitly assumes the developer to be English-speaking, so that developer-focused messages are in English (even biased to American word choices and spelling...) should not incur any problem, or? This implies that system information targetted at either the developer (as in a program error or tracing) or the service technician (as in the logging) can actually be in (American) English. But, there should be a way to map that message to a (Unicode or other) message for the end user, although I think the system catching the exception would probably present something less granular than the information contained in the exception anyhow, such as "Could not read 'C:\Documents\Hello.txt'". Tackling the problem of localized messages in exceptions in a totally satisfying manner would most probably extend to the general problem of internationalizing, with resource files (explicit or embedded in the C++ code). That general problem is a big one (not very complex, but time-consuming...), and a Boost solution to that internationalizion, in order to be platform-independent, would have to interact with all the various predominant internationalization layers on the different platforms. What I am trying to say is that we should not try too hard to solve the internationalization of exception messages (I can see the worms...), an integer key is enough. The mechanism of getting the proper localized message is up to the developer (two applications of "std::map" or similar platform-specific mapping should do...) If we indeed add a "boost_exception", which I think is a bad idea (since then the developer would have to either use the "boost::boost_exception" subgraph or the "std::exception" subgraph when picking a base class for his exceptions, unless we are comfortable with multi-inherited user exceptions), it should definitely include a unique key as a separate property, such as "code()". /Tack för ordet/ David -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Peter Dimov Sent: Friday, November 22, 2002 7:12 AM To: Boost mailing list Subject: Re: [boost] Do we need a boost_exception class or idiom? From: "David Bergman" <[EMAIL PROTECTED]> > I have always interpreted "non-localized" as "comprehensible to some 60% > of scientifically inclined Americans" ;-) Looks like a joke but hides a relevant point. Sometimes you need to "localize" to plain (nontechnical) English, too. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost