monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] [Program Options] cannot use Boost.Program_Options with


From: Nathaniel Smith
Subject: [Monotone-devel] [Program Options] cannot use Boost.Program_Options with an i18nized program
Date: Wed, 23 Aug 2006 04:46:55 -0700
User-agent: Mutt/1.5.12-2006-07-14

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]