On Sun, Feb 20, 2011 at 22:55, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > Ãvar ArnfjÃrà Bjarmason wrote: > >> It's explicitly about tests that can't deal with poison, not >> non-English. See this comment in patch Â28/72: >> >>   gettextize: git-commit "enter the commit message" message >> >>   Gettextize the "# Please enter the commit message for your changes." >>   message. Several tests in t7500-commit.sh and t7502-commit.sh assume >>   that this message starts with a newline. Change the tests to to skip >>   under GETTEXT_POISON=YesPlease. > > Shouldn't the functional part (the starting newline, opening # marks) > be untranslatable then, to avoid making a trap for translators? ÂSuch > a fix could happen at any time, and until then, we could skip those > tests in the non-English case. I'm aiming to make this as minimal as possible, so I'm not going to change the code to start constructing string buffers where we previously had literals in this iteration. And the trap is minimimal, sinc msgfmt --check will warn if the structure of the newlines in the translation is different. > Since that codepath requires human intervention anyway (which is > generally slow), I can't imagine doing that would hurt runtime > performance enough to matter. > > But I do get your point --- perhaps in some other circumstance we have > to rely on some intelligence by the translator for correct behavior. > So maybe it means something along the lines of > >    Âtest_set_prereq SANE_TRANSLATION 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html