On Wed, Jan 4, 2017 at 8:25 PM, Duy Nguyen <pclouds@xxxxxxxxx> wrote: > On Wed, Jan 4, 2017 at 2:45 AM, Stefan Beller <sbeller@xxxxxxxxxx> wrote: >>> In this implementation, the gettext call for the header and the body are done >>> in different places (error function vs. caller) but this call pattern seems to >>> be the easiest variant for the caller, because the message body has to be marked >>> for localisation in any case, and N_() requires more letters than _(), an extra >>> argument to die() etc. even more than the extra "_" in the function name. >> >> I see. We have to markup the strings to be translatable such that the .po files >> are complete. It would be really handy if there was a way to say "anything that >> is fed to this function (die_) needs to be marked for translation. >> >> Looking through >> https://www.gnu.org/software/gettext/manual/html_node/xgettext-Invocation.html >> such a thing doesn't seem to exist. > > I think --keyword is exactly for that purpose: marking more text for > translations besides standard markers like _() or N_(). Yes we need to > call gettext() explicitly in die_() later on. We already do that for > parse-options. We just need to N_() the strings, without actually > spelling it out. > >> >> So in that case die_(_(...)) seems to be the easiest way forward. > > I still prefer changing the die_routine though since die() in many > cases could be used in both plumbing and porcelain contexts. And we > have tried to keep plumbing output (and behavior) as stable as > possible. The approach has some similarity to unpack_trees() which > shares the same porcelain/plumbing problem. On the other hand, making die(), not die_(), translatable means the translators will have to translate them _all_ even if only some will end up being displayed. That's 2000+ strings according to git-grep. And some of them, like die("BUG:..") should definitely not be translated. So +1 to die_(), unless we decide all strings are safe to translate. -- Duy