We discovered this issue when we recently switched the program monotone[1] over to using program_options instead of popt -- one of our translators pointed out that he had started getting command line syntax errors reported in English, regardless of the setting of his locale. The problem lies in program_options/errors.hpp: http://boost.cvs.sourceforge.net/boost/boost/boost/program_options/errors.hpp?revision=1.8&view=markup Most exceptions defined in this file construct their full error message as an opaque string, and do not provide the calling program equivalent information in any other form. For instance, the 'unknown_option' exception on line 45 simply does: : error(std::string("unknown option ").append(name)) and there is no way to extract 'name' from the exception object, except by parsing this string (ugh). If there is a 'syntax_error', then member variables are provided to access the pieces used to construct the error string, but one of these member variables is simply 'msg', again an opaque English string. I can think of two approaches to make this library usable in programs that are not monolingual English -- there may be others. The first is to design and write a portable, cross-platform method to deploy and access message catalogs, and then ship Boost with translations of all such strings into every language. While this might be a diverting way to spend a few years, it doesn't seem like an immediately practicable solution[2], so let's move on to door two... which is to give the calling program enough information on whatever errors have occurred that it can do its own error reporting. This does mean that the sorts of errors that could occur would become part of the public API (no more opaque "msg" strings), but ATM these errors are part of any program using this library's _U_I, and this API exposure is the inevitable cost to be paid if Boost isn't prepared to provide translations internally. So, would it be possible to make the interface exposed by errors.hpp considerably more fine-grained? -- Nathaniel (Reply-to-all appreciated.) [1] http://venge.net/monotone [2] Well, unless we just decided to declare gettext to be a Boost library, but I get the impression that the process is a bit more complicated than that :-). -- So let us espouse a less contested notion of truth and falsehood, even if it is philosophically debatable (if we listen to philosophers, we must debate everything, and there would be no end to the discussion). -- Serendipities, Umberto Eco