Localization

Argum generates strings that are meant to be displayed to the user. While it ships with English only strings it makes it easy to add your own localizations, if desired, using whatever localization mechanisms you are using in your code.

All localizable strings in Argum are produced by Messages<Char> class template where Char can be char or wchar_t. Note that Messages<char> is used if you use narrow Parser and related classes and Messages<wchar_t> if you use WParser.

Messages must expose methods with pre-defined names that return something string-like: const char *, char (&)[N] or std::string as an output. By default, if you do nothing, Argum supplies definitions of Messages<char> and Messages<wchar_t> that return hard-coded English strings.

If you want to localize all you need to do is

• Define ARGUM_OVERRIDE_MESSAGES=1 for your compilation. This will suppress built-in definitions
• Make your own specialization of Messages<char> (or Messages<wchar_t>) to produce localized instead of hard-coded strings.

Refer to Argum's definition of Messages to see what strings are needed. Some of the messages use {1} etc. placeholders. These have the same semantics as those of std::format.

Some message methods take a numeric unsigned val parameter. These have number depending plurals (e.g. 1 error vs. 2 errors) that need to be treated differently for different languages. (Not all languages have only 2 forms). Talk to your localization expert about how to properly handle these. Most localization systems have special support for number dependent localization.

Note that due to templated nature of Argum's code not all strings present in its definition of Messages will actually be used by your code. To avoid localizing unused messages you might want to start with an empty Messages specialization and see which methods are not found by compiler. Then implement just those.