Re: Should you use test_i18ngrep or GIT_TEST_GETTEXT_POISON=false?

From: Jeff King <peff@peff.net>
Date: Jan 12, 2021, 11:22 UTC
Message-ID: <X/2Gd9J/zWqK2wLn@coredump.intra.peff.net>
In-Reply-To: <xmqqim836v6m.fsf@gitster.c.googlers.com>

On Mon, Jan 11, 2021 at 01:05:37PM -0800, Junio C Hamano wrote:

Show 12 quoted lines

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> 
> > What do you think about just removing it? I.e. make setting it a noop?
> 
> I have been seeing occasional CI job failures from new tests that
> forget to use test_i18ngrep.  I actually think marking such a grep
> as "this is looking for a string that is meant for humans" a good
> way to document the interface and expected end-user interaction,
> so I am not sure about just removing it.
> 
> So after all, test_i18ngrep may make more sense than setting
> GIT_TEST_GETTEXT_POISON to false.  I dunno.

I agree that test_i18ngrep is preferable to setting GIT_TEST_GETTEXT_POISON. Since it's tied to the comparison itself, I think it's easier to see which messages we're expecting as human-readable. It's also shorter and more readable IMHO (you'd already be calling grep or test_cmp, so it is only a little longer).

I am on the fence on whether the presence of something like test_i18ngrep in the test suite is really serving as a useful indication of what was meant to be translated and what wasn't. It's such an incomplete coverage of the total set of messages we generate that I wouldn't trust it. I'd be more likely to look at the source to see if a message is actually translated, or just assume we follow some basic rules (in general, things to stderr are translatable; I think the plumbing outputs from unpack_trees() were really the exception).

So I'm open to the idea that the whole poison mechanism has just outlived its usefulness.

-Peff