Scripts external to git could source $(git --exec-path)/git-sh-setup (as we document in Documentation/git-sh-setup.txt). This will in turn source git-sh-i18n, which will setup some handy internationalization infrastructure. However, git-sh-i18n hardcodes the TEXTDOMAIN, meaning that anyone using this infrastructure will only get translations that are shipped with git. Allow the external scripts to specify their own translation domain but otherwise use our infrastructure for accessing translations.
My original plan was to have git-filter-branch be the first testcase using this feature, with a goal of minimizing the number of changes that needed to be made to it when I moved it out of git.git. However, I realized after creating this patch that no strings in git-filter-branch are translated. However, the generalization could be useful if we move other tools from git.git to an external location. Signed-off-by: Elijah Newren <new...@gmail.com> --- git-sh-i18n.sh | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/git-sh-i18n.sh b/git-sh-i18n.sh index 8eef60b43f..3d04d5d515 100644 --- a/git-sh-i18n.sh +++ b/git-sh-i18n.sh @@ -5,7 +5,12 @@ # # Export the TEXTDOMAIN* data that we need for Git -TEXTDOMAIN=git +if test -z "$TEXTDOMAIN_OVERRIDE" +then + TEXTDOMAIN=git +else + TEXTDOMAIN="$TEXTDOMAIN_OVERRIDE" +fi export TEXTDOMAIN if test -z "$GIT_TEXTDOMAINDIR" then -- 2.23.0.5.g775ebaa2a0
