1. 17 Jun, 2016 1 commit
    • Vasco Almeida's avatar
      i18n: rebase-interactive: mark here-doc strings for translation · b8fc9e43
      Vasco Almeida authored
      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
      t3404: adapt test to the strings newly marked for translation
      Test t3404-rebase-interactive.sh 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: default avatarVasco Almeida <vascomalmeida@sapo.pt>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  2. 26 Nov, 2013 1 commit
    • Jonathan Nieder's avatar
      remove #!interpreter line from shell libraries · 11d62145
      Jonathan Nieder authored
      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
      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
      		read line <"$file"
      		case $line in
      			echo "$file"
      The only remaining scripts found are templates for shell scripts
      (unimplemented.sh, wrap-for-bin.sh) and sample input used in tests
      Signed-off-by: default avatarJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  3. 12 Mar, 2012 1 commit
  4. 23 Jan, 2012 2 commits
  5. 06 Dec, 2011 1 commit
    • Ævar Arnfjörð Bjarmason's avatar
      i18n: add infrastructure for translating Git with gettext · 5e9637c6
      Ævar Arnfjörð Bjarmason authored
      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
      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
      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
      See <AANLkTilYD_NyIZMyj9dHtVk-ylVBfvyxpCC7982LWnVd@mail.gmail.com> 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 gettext.sh.
      If gettext.sh 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
      = 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()
      This patch is based on work by Jeff Epler <jepler@unpythonic.net> 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
      [jc: squashed a small Makefile fix from Ramsay]
      Signed-off-by: Ævar Arnfjörð Bjarmason's avatarÆvar Arnfjörð Bjarmason <avarab@gmail.com>
      Signed-off-by: default avatarRamsay Jones <ramsay@ramsay1.demon.co.uk>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  6. 08 Aug, 2011 1 commit
    • Jon Seymour's avatar
      gettext: add gettextln, eval_gettextln to encode common idiom · 3da5c543
      Jon Seymour authored
      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"
      			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.)" &&
      		) >&2
      to be expressed more concisely as:
      	if test -s "$GIT_DIR/BISECT_START"
      		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
      Acked-by: Ævar Arnfjörð Bjarmason's avatarÆvar Arnfjörð Bjarmason <avarab@gmail.com>
      Signed-off-by: Jon Seymour's avatarJon Seymour <jon.seymour@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  7. 15 May, 2011 2 commits