Re: Should you use test_i18ngrep or GIT_TEST_GETTEXT_POISON=false?

2 messages, 2 authors, 2021-01-12 · open the first message on its own page

Re: Should you use test_i18ngrep or GIT_TEST_GETTEXT_POISON=false?

From: Junio C Hamano <hidden>
Date: 2021-01-11 21:06:41

Ævar Arnfjörð Bjarmason [off-list ref] 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.

Re: Should you use test_i18ngrep or GIT_TEST_GETTEXT_POISON=false?

From: Jeff King <hidden>
Date: 2021-01-12 11:23:14

On Mon, Jan 11, 2021 at 01:05:37PM -0800, Junio C Hamano wrote:
Ævar Arnfjörð Bjarmason [off-list ref] writes:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help