Re: [PATCH v3 13/39] i18n: git-sh-setup.sh: mark strings for translation

[Junio C Hamano <gitster@pobox.com>]

Vasco Almeida <vascomalmeida@sapo.pt> writes:

> Positional arguments, such as $0, $1, etc, need to be stored on shell
> variables for use in translatable strings, according to gettext manual
> [1].
>
> Add git-sh-setup.sh to LOCALIZED_SH variable in Makefile to enable
> extraction of string marked for translation by xgettext.
>
> Although git-sh-setup.sh is a shell library to be sourced by other shell
> scripts, it is necessary to source git-sh-i18n at this point, because
> some scripts don't do it themselves. Not sourcing git-sh-i18n would lead
> to failure due to, for instance, gettextln not being found.

That is correct, but doesn't that hint that the current users of
git-sh-i18n no longer have to (and they probably do not want to)
dot-source it, as they are already dot-sourcing git-sh-setup?

Otherwise they will waste cycles reading the same thing twice
(assuming that git-sh-i18n is safely read twice, that is).

> Source "$(git --exec-path)"/git-sh-i18n instead of simply git-sh-i18n,

That is somewhat strange.  "git-rebase.sh" dot-sources both
git-sh-setup and git-sh-i18n with just ". $name".  What is so
special about sh-setup dot-sourcing sh-i18n your patch adds?

> because latter case would fail test t2300-cd-to-toplevel.sh.

What is the real cause of this?

". git-sh-setup" is supposed to work because we prepend the
$GIT_EXEC_PATH in "git" itself and git-sh-setup is installed there.
". git-sh-i18n" in "git-rebase.sh" works the same way.  If it is
because is t2300 doing something strange, then we should fix that,
not adding $(git --exec-path) on the dot-source line to paper things
over.