How is this different from gettext or ICU MessageFormat? Those look texts up at run time from catalogs, by a string key, with untyped arguments. mstring generates a C++ function per message: the arguments are typed and checked by the compiler, the texts are compiled in, there is nothing to install next to the program. The price: a new translation means a rebuild. For the messages of a library or tool — errors, exceptions, logs — that is usually the right trade; for the user interface of an application translated by a team, a catalog system fits better.

Can I add a language without recompiling? No. The texts are code.

Plural forms? Not yet — {$n} file(s) is up to you. It is on the roadmap.

Which encoding must the message file be in? Any; the text bytes are copied as they are (as octal escapes in the generated literals). UTF-8 is the obvious choice.

Which C++ standard does the generated code need? C++17 or later. It compiles warning-free with -Wall -Wextra -Wpedantic under C++17 and C++20.

Does the generated code depend on anything? Only the standard library, and <syslog.h> when $SYSLOG is used.

Why does std::locale( "tr_TR.UTF-8" ) throw? The locale is not installed (locale -a lists what is). See Languages & Locales.

Can one message file produce several modules? One run makes one module; share settings between files with $IMPORT.

Where did flex and bison go? Since 1.1 the parser is written with cparse — see the blog.