git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: Jiang Xin <worldhello.net@gmail.com>
Cc: "Junio C Hamano" <gitster@pobox.com>,
	"Git List" <git@vger.kernel.org>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>,
	"Stefano Lattarini" <stefano.lattarini@gmail.com>,
	"Martin von Zweigbergk" <martin.von.zweigbergk@gmail.com>
Subject: Re: [PATCH v4 2/7] i18n: rebase: mark strings for translation
Date: Tue, 24 Jul 2012 23:21:34 -0500	[thread overview]
Message-ID: <20120725042134.GA3055@burratino> (raw)
In-Reply-To: <915b2821410c2348817a469e7be05be497cf1d06.1343188013.git.worldhello.net@gmail.com>

(cc-ing Duy because of a mention of his nice GETTEXT_POISON tweak[*])
Hi,

Jiang Xin wrote:

> Mark strings in git-rebase.sh for translation. Jonathan offers a help
> for reorgnization of the resolvemsg variable in 'git-rebase.sh', since
> there is a likely message in git-am.sh, I update it in this commit for
> consistency. And so does to 't/t0201-gettext-fallbacks.sh'.

Ah.  Looks like I tweaked the comma usage and sentence structure a
little.  Sorry, force of habit --- I shouldn't have.

> Some test scripts are affected by this update, and would fail if tested
> with GETTEXT_POISON switch turned on. Using i18n-specific test
> functions, such as test_i18ngrep, in the related test scripts will fix
> these issues.

If we're going to keep the changes together, here's how I would phrase
the commit message:

	Mark messages in git-rebase.sh for translation.  While doing this
	it was noticed that the comma usage and sentence structure of the
	resolvemsg was not quite right, so correct that and its cousins in
	git-am.sh and t/t0201-gettext-fallbacks.sh at the same time.

	Some tests would start to fail with GETTEXT_POISON turned on after
	this update.  Use test_i18ncmp and test_i18ngrep where
	appropriate to mark strings that should only be checked in the C
	locale output to avoid such issues.

> Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
> Reviewed-by: Stefano Lattarini <stefano.lattarini@gmail.com>
> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>

I haven't tested or reviewed this patch in detail, so even though it
looks good, I'd prefer it not to have my Reviewed-by.  (See
Documentation/SubmittingPatches: '"Reviewed-by:", unlike the other
extra tags, can only be offered by the reviewer'.)  If you'd like to
credit my help, something like "With advice from Jonathan." would be
fine.

[...]
> --- a/t/t3406-rebase-message.sh
> +++ b/t/t3406-rebase-message.sh
> @@ -64,7 +64,7 @@ test_expect_success 'rebase -n overrides config rebase.stat config' '
>  
>  test_expect_success 'rebase --onto outputs the invalid ref' '
>  	test_must_fail git rebase --onto invalid-ref HEAD HEAD 2>err &&
> -	grep "invalid-ref" err
> +	test_i18ngrep "invalid-ref" err
>  '

Could we add a comment so others do not have to wonder what
human-readable message prompts the test_i18ngrep here?  e.g

	# "Does not point to a valid commit: invalid-ref"
	#
	# NEEDSWORK: This "grep" is fine in real non-C locales, but
	# GETTEXT_POISON poisons the refname along with the enclosing
	# error message.
	test_i18ngrep invalid-ref err

In the long run we may be able to turn this back to a "grep" again,
since any reasonable translation will keep the $onto_name somewhere
in the message.  But changing it to test_i18ngrep for now is the
right thing to do, until something like Duy's more sophisticated
version of GETTEXT_POISON arrives. (<-- [*])

Thanks,
Jonathan

  parent reply	other threads:[~2012-07-25  4:22 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-25  3:53 [PATCH v4 0/7] i18n for git-am, git-rebase and git-merge Jiang Xin
2012-07-25  3:53 ` [PATCH v4 1/7] i18n: New keywords for xgettext extraction from sh Jiang Xin
2012-07-25  3:53   ` [PATCH v4 2/7] i18n: rebase: mark strings for translation Jiang Xin
2012-07-25  3:53     ` [PATCH v4 3/7] i18n: Rewrite gettext messages start with dash Jiang Xin
2012-07-25  3:53       ` [PATCH v4 4/7] Remove obsolete LONG_USAGE which breaks xgettext Jiang Xin
2012-07-25  3:53         ` [PATCH v4 5/7] i18n: am: mark more strings for translation Jiang Xin
2012-07-25  3:53           ` [PATCH v4 6/7] Remove dead code which contains bad gettext block Jiang Xin
2012-07-25  3:53             ` [PATCH v4 7/7] i18n: merge-recursive: mark strings for translation Jiang Xin
2012-07-25  4:30             ` [PATCH v4 6/7] Remove dead code which contains bad gettext block Jonathan Nieder
2012-07-25  4:26           ` [PATCH v4 5/7] i18n: am: mark more strings for translation Jonathan Nieder
2012-07-25  9:59           ` Stefano Lattarini
2012-07-25 11:01             ` Jiang Xin
2012-07-25  4:21     ` Jonathan Nieder [this message]
2012-07-25  7:32       ` [PATCH v4 2/7] i18n: rebase: mark " Jiang Xin
2012-07-25  9:56         ` Jonathan Nieder

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=20120725042134.GA3055@burratino \
    --to=jrnieder@gmail.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=martin.von.zweigbergk@gmail.com \
    --cc=pclouds@gmail.com \
    --cc=stefano.lattarini@gmail.com \
    --cc=worldhello.net@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).