In C++, this is handled by the localization library. The
general approach used in C and C++ is that application
messages are written in one language, usually English, and are
looked up in a message catalog for a different language. If
found, the translated message string gets returned, otherwise
the application's native message string is returned by
default, so that the original message gets used.
Except that the standard library interface in locale takes an
int as the message id, with a separate parameter for the
default in case the message isn't found:-(.
Your C++ implementation should have some tool for extracting
application messages from the C++ source. Your application
messages probably need to be marked up with some syntactical
sugar so that your application message extraction tool picks
them up. You would then translate your application messages,
and create a message catalog file, using your C++
imlementation's tools.
Back in your C++ code, after instantiating a std::locale, you
use it to instantiate a std::messages<char> or
a std::messages<wchar_t> facets, then use the facet's open()
to open a message catalog, and get() to look up your
application message in the message catalog.
The C++ language standardizes only the message retrieval part,
the std::locale and std::messages facets. The creation of
message catalogs is out of scope, and is implementation
defined. On Unix and Linux, the GNU gettext package provides
the necessary tools. GNU gettext also offers an alternative
C API in place of the standard C++ classes. GNU gettext's
C API includes some nice enhanced functionality that's not
supported by the C++ library.
I wonder how implementations do map the int message identifier
to the string that the Unix interface expects.
In practice, it really doesn't matter, because just picking up
a different message is far from sufficient. In the old days,
people accepted messages like "1 Error(s) found", but today, one
rather expects something more "human". Which means respecting
the grammar when generating messages. And since each language
has a different grammar, you're pretty much stuck with writing
a separate dynamically linked module for each language, and
loading the appropriate one.
(A simple example of the sort of problems you'll encounter:
std::cerr << errorCount << " " << error[count == 1] << " found;
works well in English, provided that error is initialized:
char const* error[] = { "error", "errors" };
In French, however, "found" becomes "trouvée". Or "trouvées",
depending on the count---suddenly found also needs a table
lookup. In German, found must come before the noun (in this
case, at least), and found changes depending on the number,
whereas error ("Fehler") doesn't. And in Russian, from what
I've been told, numbers like 21 or 31 also take a singular.)
