[snip/]
The point if you use Japanese - inline then you don't need to translate strings, and if you do translate then write source code with ASCII strings that would work with any encoding and would be understandable for any software)
This is how all translation systems I know work.
Having original text strings in Japanese and translating them to French or Hebrew is very-very-bad idea as it is much simpler to find somebody to be able to translate the text from English to Hebrew then from Japanese to Hebrew.
This is just plain silly. Telling someone who uses language X that in order to translate their code to language Y they need to first translate their code to English and then translate English to language Y, and that this is somehow superior, is just inane reasoning. Supporting such reasoning by saying that "everyone" does it that way is equally inane for many obvious reasons. It is much better to admit that the "translate" part of a locale library may be flawed, or limited, than to have to justify such illogical nonsense.
This is, however, basically the only reasonable thing to do, with the current state of things and the whole string literal encoding mess in C++. One of the alternatives that people who don't speak English can use, is to transliterate the strings to plain Latin alphabet (7-bit ASCII) i.e. for example instead of doing translate( "Пожалуйста") you do translate("pa-zhal-sta");
I am not saying that your following the way that gnu Gettext does translation is not understandable, in that you chose to follow a popular way ot doing something. But I am saying that trying to justify it in the illogical way that you do, given a perfectly reasonable objection, is completely wrong.
What other options do you see, the support for UTF-8 character literals being as it is ? BR, Matus