From: David Bergman (davidb_at_[hidden])
Date: 2002-11-22 13:26:13
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
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
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/
[mailto:boost-bounces_at_[hidden]] 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" <davidb_at_[hidden]>
> I have always interpreted "non-localized" as "comprehensible to some
> 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: