Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:
> diff --git a/po/README b/po/README
> index 07595d369b..b9b6c9cb24 100644
> --- a/po/README
> +++ b/po/README
> @@ -284,23 +284,27 @@ Perl:
> Testing marked strings
> ----------------------
>
> +Git's tests are run under LANG=C LC_ALL=C. So the tests do not need be
> +changed to account for translations as they're added.
After we told readers this ...
> +Testing whether marked strings are used by plumbing
> ...
> +It's still possible to do a one-off test of where a string might be
> +used in the tests by simply replacing the "some hardcoded string" with
> +something like "POISON ME" locally and running the tests, before
> +finally converting it to _("some hardcoded string").
... I do not see how this manual check can still be effective.
People rely on our tests running under C locale, and will add tests
to grep for error messages meant for humans in C locale. What does
it help to notice that a particular string you are contemplating to
translate _is_ being looked for in an existing test? The author of
such a test knew it was meant for humans, but trusted our promise to
run tests in the C locale and used grep for it, in which case it is
a fair game to be marked with _().
I think we should honestly admit that after this change it is no
longer possible for our tests to help catching strings that are
mistakenly marked for translation when they are meant for machine
consumption, and justify why it is still OK to apply this change.
> diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
> index 999982fe4a..c7b1d857c4 100644
> --- a/t/test-lib-functions.sh
> +++ b/t/test-lib-functions.sh
The changes to this file all look very attractive ;-) Not having to
worry about poison test certainly makes it easier to write tests.
I just do not know if the price we are paying for the easier life is
too high.
Thanks.
