Re: [RFC PATCH 0/5] Localise error headers

From: Duy Nguyen <pclouds@gmail.com>
Date: Jan 4, 2017, 13:25 UTC
Message-ID: <CACsJy8B0UT4_CF=qu081ep6nzdBXxnnNbma-wCYeajAuXaKg5w@mail.gmail.com>
In-Reply-To: <CAGZ79ka-FXfFN8ZqE6+v06o3nKa7ad0iWttn99Y2wf5m6wfs8A@mail.gmail.com>

On Wed, Jan 4, 2017 at 2:45 AM, Stefan Beller <sbeller@google.com> wrote:

Show 13 quoted lines

>> 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.

-- 
Duy