Re: [PATCH 03/72] t/test-lib.sh: add always-set NO_GETTEXT_POISON prerequisite

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Feb 20, 2011, 22:31 UTC
Message-ID: <AANLkTikRv9BGWXrf5u7xptgZ9hajeju-QU7WS9Zj3sYP@mail.gmail.com>
In-Reply-To: <20110220221033.GD32142@elie>

On Sun, Feb 20, 2011 at 23:10, Jonathan Nieder <jrnieder@gmail.com> wrote:

Show 16 quoted lines

> Ævar Arnfjörð Bjarmason wrote:
>
>> Well, the feature I have is to inject garbage into the gettext strings
>> in an effort to smoke out when I break the plumbing. So I think given
>> that functionality calling it NO_GETTEXT_POISON makes sense.
>>
>> But I plan to add something to smoke other languages etc. later. Then
>> I might name that other prerequisite something else.
>
> On second thought, another possibility would be _two_ prerequisites,
> one NO_GETTEXT_POISON one and one ENGLISH one.  The weird edge cases
> could require NO_GETTEXT_POISON, causing the reader to look to
> t/README to figure out what is going on.  The others would just use
> ENGLISH.
>
> Does that sound reasonable?

Yes, I suggested implementing that in the "enter the commit message" patch, but since we don't have a 100% translation yet I was going to wait until then.

It's also a very low priority, the point of these tests is to make sure I don't make a plumbing message translatable. The things that start failing under a testing mode like ENGLISH are by definition a subset of the things that'll start failing under NO_GETTEXT_POISON. So there's not a lot of incentive for me to implement that.

The only reason I can think of to have it is to make sure that messages like the "enter the commit message" ones have the correct newlines in all languages, but msgfmt --check catches that anyway, or to somehow test Git's output in different languages, but I'd rather do that differently (not test output, but behavior).

So given all of the above I might never get around to implementing it.