path: root/
AgeCommit message (Collapse)Author
2021-10-21git-sh-i18n: remove unused eval_ngettext()Ævar Arnfjörð Bjarmason
The "eval_ngettext()" function has been orphaned since its last user was removed in a74b35081c5 (rebase: drop support for `--preserve-merges`, 2021-09-07). See b8fc9e43a7d (i18n: rebase-interactive: mark here-doc strings for translation, 2016-06-17) for the commit that added these eval_ngettext() wrappers. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2021-01-21tests: remove support for GIT_TEST_GETTEXT_POISONÆvar Arnfjörð Bjarmason
This removes the ability to inject "poison" gettext() messages via the GIT_TEST_GETTEXT_POISON special test setup. I initially added this as a compile-time option in bb946bba761 (i18n: add GETTEXT_POISON to simulate unfriendly translator, 2011-02-22), and most recently modified to be toggleable at runtime in 6cdccfce1e0 (i18n: make GETTEXT_POISON a runtime option, 2018-11-08).. The reason for its removal is that the trade-off of maintaining it v.s. what it's getting us has long since flipped. When gettext was integrated in 5e9637c6297 (i18n: add infrastructure for translating Git with gettext, 2011-11-18) there was understandable concern on the Git ML that in marking messages for translation en-masse we'd inadvertently mark plumbing messages. The GETTEXT_POISON facility was a way to smoke those out via our test suite. Nowadays however we're done (or almost entirely done) with any marking of messages for translation. New messages are usually marked by their authors, who'll know whether it makes sense to translate them or not. If not any errors in marking the messages are much more likely to be spotted in review than in the the initial deluge of i18n patches in the 2011-2012 era. So let's just remove this. This leaves the test suite in a state where we still have a lot of test_i18n, C_LOCALE_OUTPUT etc. uses. Subsequent commits will remove those too. The change to t/ is a selective revert of the relevant part of f2d17068fd (i18n: rebase-interactive: mark comments of squash for translation, 2016-06-17), and the comment in t/ is from c7108bf9ed (i18n: rebase: mark messages for translation, 2012-07-25). Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2019-06-21tests: make GIT_TEST_GETTEXT_POISON a booleanÆvar Arnfjörð Bjarmason
Change the GIT_TEST_GETTEXT_POISON variable from being "non-empty?" to being a more standard boolean variable. Since it needed to be checked in both C code and shellscript (via test -n) it was one of the remaining shellscript-like variables. Now that we have "env--helper" we can change that. There's a couple of tricky edge cases that arise because we're using git_env_bool() early, and the config-reading "env--helper". If GIT_TEST_GETTEXT_POISON is set to an invalid value die_bad_number() will die, but to do so it would usually call gettext(). Let's detect the special case of GIT_TEST_GETTEXT_POISON and always emit that message in the C locale, lest we infinitely loop. As seen in the updated tests in there's also a caveat related to "env--helper" needing to read the config for trace2 purposes. Since the C_LOCALE_OUTPUT prerequisite is lazy and relies on "env--helper" we could get invalid results if we failed to read the config (e.g. because we'd loop on includes) when combined with e.g. "test_i18ngrep" wanting to check with "env--helper" if GIT_TEST_GETTEXT_POISON was true or not. I'm crossing my fingers and hoping that a test similar to the one I removed in the earlier "config tests: simplify include cycle test" change in this series won't happen again, and testing for this explicitly in "env--helper"'s own tests. This change breaks existing uses of e.g. GIT_TEST_GETTEXT_POISON=YesPlease, which we've documented in po/README and other places. As noted in [1] we might want to consider also accepting "YesPlease" in "env--helper" as a special-case. But as the lack of uproar over 6cdccfce1e ("i18n: make GETTEXT_POISON a runtime option", 2018-11-08) demonstrates the audience for this option is a really narrow set of git developers, who shouldn't have much trouble modifying their test scripts, so I think it's better to deal with that minor headache now and make all the relevant GIT_TEST_* variables boolean in the same way than carry the "YesPlease" special-case forward. 1. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2018-11-09i18n: make GETTEXT_POISON a runtime optionÆvar Arnfjörð Bjarmason
Change the GETTEXT_POISON compile-time + runtime GIT_GETTEXT_POISON test parameter to only be a GIT_TEST_GETTEXT_POISON=<non-empty?> runtime parameter, to be consistent with other parameters documented in "Running tests with special setups" in t/README. When I added GETTEXT_POISON in bb946bba76 ("i18n: add GETTEXT_POISON to simulate unfriendly translator", 2011-02-22) I was concerned with ensuring that the _() function would get constant folded if NO_GETTEXT was defined, and likewise that GETTEXT_POISON would be compiled out unless it was defined. But as the benchmark in my [1] shows doing a one-off runtime getenv("GIT_TEST_[...]") is trivial, and since GETTEXT_POISON was originally added the GIT_TEST_* env variables have become the common idiom for turning on special test setups. So change GETTEXT_POISON to work the same way. Now the GETTEXT_POISON=YesPlease compile-time option is gone, and running the tests with GIT_TEST_GETTEXT_POISON=[YesPlease|] can be toggled on/off without recompiling. This allows for conditionally amending tests to test with/without poison, similar to what 859fdc0c3c ("commit-graph: define GIT_TEST_COMMIT_GRAPH", 2018-08-29) did for GIT_TEST_COMMIT_GRAPH. Do some of that, now we e.g. always run the test. I did enough there to remove the GETTEXT_POISON prerequisite, but its inverse C_LOCALE_OUTPUT is still around, and surely some tests using it can be converted to e.g. always set GIT_TEST_GETTEXT_POISON=. Notes on the implementation: * We still compile a dedicated GETTEXT_POISON build in Travis CI. Perhaps this should be revisited and integrated into the "linux-gcc" build, see ae59a4e44f ("travis: run tests with GIT_TEST_SPLIT_INDEX", 2018-01-07) for prior art in that area. Then again maybe not, see [2]. * We now skip a test in under GIT_TEST_GETTEXT_POISON=YesPlease that wasn't skipped before. This test relies on C locale output, but due to an edge case in how the previous implementation of GETTEXT_POISON worked (reading it from GIT-BUILD-OPTIONS) wasn't enabling poison correctly. Now it does, and needs to be skipped. * The getenv() function is not reentrant, so out of paranoia about code of the form: printf(_("%s"), getenv("some-env")); call use_gettext_poison() in our early setup in git_setup_gettext() so we populate the "poison_requested" variable in a codepath that's won't suffer from that race condition. * We error out in the Makefile if you're still saying GETTEXT_POISON=YesPlease to prompt users to change their invocation. * We should not print out poisoned messages during the test initialization itself to keep it more readable, so the test library hides the variable if set in $GIT_TEST_GETTEXT_POISON_ORIG during setup. See [3]. See also [4] for more on the motivation behind this patch, and the history of the GETTEXT_POISON facility. 1. 2. 3. 4. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2018-02-08git-sh-i18n: check GETTEXT_POISON before USE_GETTEXT_SCHEMEJeff King
Running "make NO_GETTEXT=1 GETTEXT_POISON=1" currently fails t0205. While it might seem nonsensical at first glance to both poison and disable gettext, it's useful to be able to do a poison test-run on a system that doesn't have gettext at all. And it works fine for C programs; the problem is only with the shell code. The issue is that we check the baked-in USE_GETTEXT_SCHEME value before GETTEXT_POISON. And when NO_GETTEXT is set, the Makefile sets USE_GETTEXT_SCHEME to "fallthrough". So one fix would be to have the Makefile just set USE_GETTEXT_SCHEME to "poison" if GETTEXT_POISON is set. But there are two problems with that: 1. USE_GETTEXT_SCHEME is actually a user-facing knob, so conceivably somebody could override it with: make USE_GETTEXT_SCHEME=gnu GETTEXT_POISON=1 which would do the wrong thing (though that's much less likely than them having the variable set in their config.mak and just overriding GETTEXT_POISON on the command-line for a one-off test). 2. We don't actually bake GETTEXT_POISON in to the shell library like we do for the C code. It checks $GIT_GETTEXT_POISON at runtime, which is set up by the test suite. So it makes sense to put the fix in the runtime code, too, which would cover something like: GIT_GETTEXT_POISON=foo git foo It's not likely that people use the poison code outside of running the test suite, but it's easy enough to make this case work. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2016-06-17i18n: rebase-interactive: mark here-doc strings for translationVasco Almeida
Use pipe to send gettext output to git stripspace instead of the original method of using shell here-document, because command substitution '$(...)' would not take place inside the here-documents. The exception is the case of the last here-document redirecting to cat, in which commands substitution works and, thus, is preserved in this commit. t3404: adapt test to the strings newly marked for translation Test would fail under GETTEXT_POISON unless using test_i18ngrep. Add eval_ngettext fallback functions to be called when running, for instance, under GETTEXT_POISON. Otherwise, tests would fail under GETTEXT_POISON, or other build that doesn't support the GNU gettext, because that function could not be found. Signed-off-by: Vasco Almeida <> Signed-off-by: Junio C Hamano <>
2013-11-26remove #!interpreter line from shell librariesJonathan Nieder
In a shell snippet meant to be sourced by other shell scripts, an opening #! line does more harm than good. The harm: - When the shell library is sourced, the interpreter and options from the #! line are not used. Specifying a particular shell can confuse the reader into thinking it is safe for the shell library to rely on idiosyncrasies of that shell. - Using #! instead of a plain comment drops a helpful visual clue that this is a shell library and not a self-contained script. - Tools such as lintian can use a #! line to tell when an installation script has failed by forgetting to set a script executable. This check does not work if shell libraries also start with a #! line. The good: - Text editors notice the #! line and use it for syntax highlighting if you try to edit the installed scripts (without ".sh" suffix) in place. The use of the #! for file type detection is not needed because Git's shell libraries are meant to be edited in source form (with ".sh" suffix). Replace the opening #! lines with comments. This involves tweaking the test harness's valgrind support to find shell libraries by looking for "# " in the first line instead of "#!" (see v1.7.6-rc3~7, 2011-06-17). Suggested by Russ Allbery through lintian. Thanks to Jeff King and Clemens Buchacher for further analysis. Tested by searching for non-executable scripts with #! line: find . -name .git -prune -o -type f -not -executable | while read file do read line <"$file" case $line in '#!'*) echo "$file" ;; esac done The only remaining scripts found are templates for shell scripts (, and sample input used in tests (t/t4034/perl/{pre,post}). Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2012-03-12i18n: fix auto detection of gettext scheme for shell scriptsJunio C Hamano
A new code added by ad17ea7 (add a Makefile switch to avoid gettext translation in shell scripts, 2012-01-23) tried to optionally force a gettext scheme to "fallthrough", but ended up forcing it to everybody. Signed-off-by: Junio C Hamano <>
2012-01-23add a Makefile switch to avoid gettext translation in shell scriptsAlex Riesen
Some systems have (GNU gettext) installed, but it is either broken or misconfigured in such a way so its output is not usable. In case the users of these systems are unable or not interested in fixing them, setting the new Makefile switch should help: make USE_GETTEXT_SCHEME=fallthrough This will replace the translation routines with fallthrough versions, that does not use gettext from the platform. Signed-off-by: Alex Riesen <> Signed-off-by: Junio C Hamano <>
2012-01-23git-sh-i18n: restructure the logic to compute schemeJunio C Hamano
Instead of having a single long and complex chain of commands to decide what to do and carry out the decision, split the code so that we first decide which scheme to use, and in the second section define what exactly is done by the chosen scheme. It makes the code much easier to follow and update. Signed-off-by: Junio C Hamano <>
2011-12-06i18n: add infrastructure for translating Git with gettextÆvar Arnfjörð Bjarmason
Change the skeleton implementation of i18n in Git to one that can show localized strings to users for our C, Shell and Perl programs using either GNU libintl or the Solaris gettext implementation. This new internationalization support is enabled by default. If gettext isn't available, or if Git is compiled with NO_GETTEXT=YesPlease, Git falls back on its current behavior of showing interface messages in English. When using the autoconf script we'll auto-detect if the gettext libraries are installed and act appropriately. This change is somewhat large because as well as adding a C, Shell and Perl i18n interface we're adding a lot of tests for them, and for those tests to work we need a skeleton PO file to actually test translations. A minimal Icelandic translation is included for this purpose. Icelandic includes multi-byte characters which makes it easy to test various edge cases, and it's a language I happen to understand. The rest of the commit message goes into detail about various sub-parts of this commit. = Installation Gettext .mo files will be installed and looked for in the standard $(prefix)/share/locale path. GIT_TEXTDOMAINDIR can also be set to override that, but that's only intended to be used to test Git itself. = Perl Perl code that's to be localized should use the new Git::I18n module. It imports a __ function into the caller's package by default. Instead of using the high level Locale::TextDomain interface I've opted to use the low-level (equivalent to the C interface) Locale::Messages module, which Locale::TextDomain itself uses. Locale::TextDomain does a lot of redundant work we don't need, and some of it would potentially introduce bugs. It tries to set the $TEXTDOMAIN based on package of the caller, and has its own hardcoded paths where it'll search for messages. I found it easier just to completely avoid it rather than try to circumvent its behavior. In any case, this is an issue wholly internal Git::I18N. Its guts can be changed later if that's deemed necessary. See <> for a further elaboration on this topic. = Shell Shell code that's to be localized should use the git-sh-i18n library. It's basically just a wrapper for the system's If isn't available we'll fall back on gettext(1) if it's available. The latter is available without the former on Solaris, which has its own non-GNU gettext implementation. We also need to emulate eval_gettext() there. If neither are present we'll use a dumb printf(1) fall-through wrapper. = About libcharset.h and langinfo.h We use libcharset to query the character set of the current locale if it's available. I.e. we'll use it instead of nl_langinfo if HAVE_LIBCHARSET_H is set. The GNU gettext manual recommends using langinfo.h's nl_langinfo(CODESET) to acquire the current character set, but on systems that have libcharset.h's locale_charset() using the latter is either saner, or the only option on those systems. GNU and Solaris have a nl_langinfo(CODESET), FreeBSD can use either, but MinGW and some others need to use libcharset.h's locale_charset() instead. =Credits This patch is based on work by Jeff Epler <> who did the initial Makefile / C work, and a lot of comments from the Git mailing list, including Jonathan Nieder, Jakub Narebski, Johannes Sixt, Erik Faye-Lund, Peter Krefting, Junio C Hamano, Thomas Rast and others. [jc: squashed a small Makefile fix from Ramsay] Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Ramsay Jones <> Signed-off-by: Junio C Hamano <>
2011-08-08gettext: add gettextln, eval_gettextln to encode common idiomJon Seymour
Currently, if you want to use gettext or eval_gettext to format a message you may have to add a separate echo statement and a surrounding subshell in order to interpolate the required trailing new line. This patch introduces two new helper functions, gettextln and eval_gettextln which append a trailing newline to the gettext output. This allows constructions of the form: if test -s "$GIT_DIR/BISECT_START" then ( gettext "You need to give me at least one good and one bad revisions. (You can use \"git bisect bad\" and \"git bisect good\" for that.)" && echo ) >&2 else ... to be expressed more concisely as: if test -s "$GIT_DIR/BISECT_START" then gettextln "You need to give me at least one good and one bad revisions. (You can use \"git bisect bad\" and \"git bisect good\" for that.)" >&2 else ... Acked-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Jon Seymour <> Signed-off-by: Junio C Hamano <> add GIT_GETTEXT_POISON supportÆvar Arnfjörð Bjarmason
Change to support the GIT_GETTEXT_POISON environment variable like gettext.c does, this ensures that tests that use will fail under GETTEXT_POISON=YesPlease if they rely on Git's C locale messages without declaring that they do. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <> add no-op gettext() and eval_gettext() wrappersÆvar Arnfjörð Bjarmason
Add a no-op wrapper library for Git's shell scripts. To split up the gettext series I'm first submitting patches to gettextize the source tree before I add any of the Makefile and Shell library changes needed to actually use them. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>