All of lore.kernel.org
 help / color / mirror / Atom feed
From: Duy Nguyen <pclouds@gmail.com>
To: Stefan Beller <sbeller@google.com>
Cc: Michael J Gruber <git@drmicha.warpmail.net>,
	"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [RFC PATCH 0/5] Localise error headers
Date: Wed, 4 Jan 2017 20:25:25 +0700	[thread overview]
Message-ID: <CACsJy8B0UT4_CF=qu081ep6nzdBXxnnNbma-wCYeajAuXaKg5w@mail.gmail.com> (raw)
In-Reply-To: <CAGZ79ka-FXfFN8ZqE6+v06o3nKa7ad0iWttn99Y2wf5m6wfs8A@mail.gmail.com>

On Wed, Jan 4, 2017 at 2:45 AM, Stefan Beller <sbeller@google.com> 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.
-- 
Duy

  reply	other threads:[~2017-01-04 13:26 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-02 11:14 [RFC PATCH 0/5] Localise error headers Michael J Gruber
2017-01-02 11:14 ` [RFC PATCH 1/5] error/warning framework: prepare for l10n Michael J Gruber
2017-01-02 11:14 ` [RFC PATCH 2/5] error/warn framework: provide localized variants Michael J Gruber
2017-01-02 11:14 ` [RFC PATCH 3/5] error/warning framework framework: coccinelli rules Michael J Gruber
2017-01-03 12:26 ` [RFC PATCH 0/5] Localise error headers Duy Nguyen
2017-01-03 19:45 ` Stefan Beller
2017-01-04 13:25   ` Duy Nguyen [this message]
2017-01-07  9:34     ` Duy Nguyen
2017-01-04  7:05 ` Jeff King
2017-01-09 12:43   ` Michael J Gruber
2017-01-10  9:04     ` Jeff King
2017-01-10 18:28       ` Stefan Beller
2017-01-11 11:37         ` Jeff King
2017-01-11 17:15           ` Stefan Beller
2017-01-21 14:24             ` Jeff King
2017-01-11 18:08           ` Junio C Hamano
2017-01-20 13:08             ` Duy Nguyen
2017-01-21 14:19               ` Jeff King
2017-01-21 14:20             ` Jeff King
2017-03-30 15:18               ` Michael J Gruber
2017-04-01  8:12                 ` Jeff King
2017-04-01 17:38                   ` Junio C Hamano
2017-01-20 13:23           ` Duy Nguyen
2017-01-20 13:31             ` Duy Nguyen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CACsJy8B0UT4_CF=qu081ep6nzdBXxnnNbma-wCYeajAuXaKg5w@mail.gmail.com' \
    --to=pclouds@gmail.com \
    --cc=git@drmicha.warpmail.net \
    --cc=git@vger.kernel.org \
    --cc=sbeller@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.