Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > Notes on the implementation: > > * The only reason we need a new "git-sh-i18n--helper" and the > corresponding "test-tool gettext-poison" is to expose > git_env_bool() to shellscripts, since git-sh-i18n and friends need > to inspect the $GIT_TEST_GETTEXT_POISON variable. > > We only call these if $GIT_TEST_GETTEXT_POISON is set, or in the > test suite, and this code can go away for non-test code once the > last i18n-using shellscript is rewritten in C. Makes me wonder if we want to teach "git config" a new "--env-bool" option that can be used by third-party scripts. Or would it be just the matter of writing git config --default=false --type=bool "$GIT_WHATEVER_ENV" in these third-party scripts and we do not need to add such a thing? > * The reason for not doing: > > test_lazy_prereq GETTEXT_POISON 'test-tool gettext-poison' > test_lazy_prereq C_LOCALE_OUTPUT '! test-tool gettext-poison' > > In test-lib.sh is because there's some interpolation problem with > that syntax which makes t6040-tracking-info.sh fail. Hence using > the simpler test_set_prereq. s/In/in/, as you haven't finished the sentence yet. But more importantly, what is this "some interpolation problem"? Are you saying that test_lazy_prereq implementation is somehow broken and cannot take certain strings? If so, perhaps we want to fix that, and people other than you can help to do so, once you let them know what the problem is. > See also > https://public-inbox.org/git/871s8gd32p.fsf@xxxxxxxxxxxxxxxxxxx/ for > more discussion. "See also [*1*] for more discussion" as you've already have reference below. > > 1. https://public-inbox.org/git/871s8gd32p.fsf@xxxxxxxxxxxxxxxxxxx/ > > Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> > --- > > Here's a polished version of that. I think it makes sense to queue > this up before any other refactoring of GETTEXT_POISON, and some patch > to unconditionally preserve format specifiers as I suggested upthread > could go on top of this. > ... > +int cmd_sh_i18n__helper(int argc, const char **argv, const char *prefix) > +{ > + int poison = -1; > + struct option options[] = { > + OPT_BOOL(0, "git-test-gettext-poison", &poison, > + N_("is GIT_TEST_GETTEXT_POISON in effect?")), > + OPT_END() > + }; > + > + argc = parse_options(argc, argv, NULL, options, > + builtin_sh_i18n_helper_usage, PARSE_OPT_KEEP_ARGV0); > + > + if (poison != -1) > + return !git_env_bool("GIT_TEST_GETTEXT_POISON", 0); Hmm? If "--[no-]git-test-gettext-poison" is given, poison is either 0 or 1, and we return the value we read from the environment? What convoluted way to implement the option is that, or is there anything subtle that I am not getting? If the "default" parameter to git_env_bool() were poison, and then the option was renamed to "--get-git-text-gettext-poison", then I sort of understand the code, though (it's like "git config" with "--default" option). But if there is nothing subtle, it may make sense to implement this as an opt-cmdmode instead. > diff --git a/po/README b/po/README > index fef4c0f0b5..dba46c4a40 100644 > --- a/po/README > +++ b/po/README > @@ -289,16 +289,11 @@ something in the test suite might still depend on the US English > version of the strings, e.g. to grep some error message or other > output. > > -To smoke out issues like these Git can be compiled with gettext poison > -support, at the top-level: > +To smoke out issues like these Git tested with a translation mode that > +emits gibberish on every call to gettext. To use it run the test suite > +with it, e.g.: s/these Git tested/these, Git can be tested/; even though the comma is not a new issue you introduced.
