From: Junio C Hamano Date: Wed, 01 Jun 2016 18:20:41 GMT Subject: Re: [PATCH v3 13/39] i18n: git-sh-setup.sh: mark strings for translation Message-ID: In-Reply-To: <1464799289-7639-14-git-send-email-vascomalmeida@sapo.pt> Vasco Almeida 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.