# [PATCH] help: report on whether or not gettext is enabled 7 messages from 2026-01-16 to 2026-01-20. Participants: Jiang Xin, Junio C Hamano, Patrick Steinhardt. Thread: https://gitlist.dev/t/64817 ## Jiang Xin, 2026-01-16 02:29 Subject: [PATCH] help: report on whether or not gettext is enabled Message-ID: URL: https://gitlist.dev/e/f3500e698fd40297d2e2634785529b76d49ca470.1768530514.git.zhiyou.jx%40alibaba-inc.com ``` From: Jiang Xin When users report that Git has no localized output, we need to check not only their locale settings, but also whether Git was built with GETTEXT support in the first place. Expose this information via the existing build info output by adding a "gettext: enabled|disabled" line to `git version --build-options` (and therefore also to `git bugreport`). The status is derived from whether `NO_GETTEXT` is defined at build time. Signed-off-by: Jiang Xin --- help.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/help.c b/help.c index 20e114432d..96d70d8e6c 100644 --- a/help.c +++ b/help.c @@ -799,6 +799,11 @@ void get_version_info(struct strbuf *buf, int show_build_options) if (fsmonitor_ipc__is_supported()) strbuf_addstr(buf, "feature: fsmonitor--daemon\n"); +#if defined NO_GETTEXT + strbuf_addstr(buf, "gettext: disabled\n"); +#else + strbuf_addstr(buf, "gettext: enabled\n"); +#endif #if defined LIBCURL_VERSION strbuf_addf(buf, "libcurl: %s\n", LIBCURL_VERSION); #endif -- 2.52.0.435.g8745eae506 ``` ## Junio C Hamano, 2026-01-16 15:46 Subject: Re: [PATCH] help: report on whether or not gettext is enabled Message-ID: URL: https://gitlist.dev/e/xmqqo6mta7bg.fsf%40gitster.g In-Reply-To: ``` Jiang Xin writes: > From: Jiang Xin > > When users report that Git has no localized output, we need to check not > only their locale settings, but also whether Git was built with GETTEXT > support in the first place. > > Expose this information via the existing build info output by adding a > "gettext: enabled|disabled" line to `git version --build-options` (and > therefore also to `git bugreport`). The status is derived from whether > `NO_GETTEXT` is defined at build time. > > Signed-off-by: Jiang Xin > --- > help.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/help.c b/help.c > index 20e114432d..96d70d8e6c 100644 > --- a/help.c > +++ b/help.c > @@ -799,6 +799,11 @@ void get_version_info(struct strbuf *buf, int show_build_options) > > if (fsmonitor_ipc__is_supported()) > strbuf_addstr(buf, "feature: fsmonitor--daemon\n"); > +#if defined NO_GETTEXT > + strbuf_addstr(buf, "gettext: disabled\n"); > +#else > + strbuf_addstr(buf, "gettext: enabled\n"); > +#endif Presumably, we do not care too much about the version of this thing unlike ... > #if defined LIBCURL_VERSION > strbuf_addf(buf, "libcurl: %s\n", LIBCURL_VERSION); > #endif ... we do for the curl library, so only reporting "enabled" does feel perfectly OK to me. I would prefer not to see the "disabled" entry myself, by the way. Combined with the vintage of Git binary that had these help text, the fact that an "enabled" line is missing is enough clue to diagnose. I know you mimicked the Rust entry before this point (just above the precontext of the hunk), but I think we should fix it to drop the "disabled" entry from there. Cc'ed the author of cb2badb4 (help: report on whether or not Rust is enabled, 2025-10-02). ``` ## Jiang Xin, 2026-01-17 13:59 Subject: [PATCH v2] help: report on whether or not gettext is enabled Message-ID: <251e1b533ca2e38a9bedae44360ce636cdea4bc3.1768657640.git.zhiyou.jx@alibaba-inc.com> URL: https://gitlist.dev/e/251e1b533ca2e38a9bedae44360ce636cdea4bc3.1768657640.git.zhiyou.jx%40alibaba-inc.com In-Reply-To: ``` From: Jiang Xin When users report that Git has no localized output, we need to check not only their locale settings, but also whether Git was built with GETTEXT support in the first place. Expose this information via the existing build info output by adding a "gettext: enabled" line to `git version --build-options` (and therefore also to `git bugreport`) when `NO_GETTEXT` is not defined at build time. Signed-off-by: Jiang Xin --- help.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/help.c b/help.c index 20e114432d..3c36d9c218 100644 --- a/help.c +++ b/help.c @@ -799,6 +799,9 @@ void get_version_info(struct strbuf *buf, int show_build_options) if (fsmonitor_ipc__is_supported()) strbuf_addstr(buf, "feature: fsmonitor--daemon\n"); +#if !defined NO_GETTEXT + strbuf_addstr(buf, "gettext: enabled\n"); +#endif #if defined LIBCURL_VERSION strbuf_addf(buf, "libcurl: %s\n", LIBCURL_VERSION); #endif -- 2.52.0.435.g8745eae506 ``` ## Patrick Steinhardt, 2026-01-19 07:03 Subject: Re: [PATCH] help: report on whether or not gettext is enabled Message-ID: URL: https://gitlist.dev/e/aW3XUxaomqGbtpEj%40pks.im In-Reply-To: ``` On Fri, Jan 16, 2026 at 07:46:59AM -0800, Junio C Hamano wrote: > > diff --git a/help.c b/help.c > > index 20e114432d..96d70d8e6c 100644 > > --- a/help.c > > +++ b/help.c > > @@ -799,6 +799,11 @@ void get_version_info(struct strbuf *buf, int show_build_options) > > > > if (fsmonitor_ipc__is_supported()) > > strbuf_addstr(buf, "feature: fsmonitor--daemon\n"); > > +#if defined NO_GETTEXT > > + strbuf_addstr(buf, "gettext: disabled\n"); > > +#else > > + strbuf_addstr(buf, "gettext: enabled\n"); > > +#endif > > Presumably, we do not care too much about the version of this thing > unlike ... > > > #if defined LIBCURL_VERSION > > strbuf_addf(buf, "libcurl: %s\n", LIBCURL_VERSION); > > #endif > > ... we do for the curl library, so only reporting "enabled" does > feel perfectly OK to me. > > I would prefer not to see the "disabled" entry myself, by the way. > Combined with the vintage of Git binary that had these help text, > the fact that an "enabled" line is missing is enough clue to > diagnose. I know you mimicked the Rust entry before this point > (just above the precontext of the hunk), but I think we should fix > it to drop the "disabled" entry from there. > > Cc'ed the author of cb2badb4 (help: report on whether or not Rust is > enabled, 2025-10-02). One reason why I personally prefer to have enabled/disabled is that it allows you to discern the following two cases: - You have a modern version of Git that doesn't have gettext. - You have an old version of Git that doesn't know to print information about whether or not gettext is enabled. If we don't print the info at all when gettext is disabled then it's impossible to tell these two cases apart. That argument in my mind also extends to libcurl, where it would be more helpful to print "libcurl: disabled" if it's not used. I don't feel particularly strong about this though. Patrick ``` ## Jiang Xin, 2026-01-19 10:17 Subject: Re: [PATCH] help: report on whether or not gettext is enabled Message-ID: URL: https://gitlist.dev/e/CANYiYbGn-ANF4jT2Lef%2BuL%3DsfcVWukBH7J71VaapGkaDaYHFZA%40mail.gmail.com In-Reply-To: ``` On Mon, Jan 19, 2026 at 3:03 PM Patrick Steinhardt wrote: > > ... we do for the curl library, so only reporting "enabled" does > > feel perfectly OK to me. > > > > I would prefer not to see the "disabled" entry myself, by the way. > > Combined with the vintage of Git binary that had these help text, > > the fact that an "enabled" line is missing is enough clue to > > diagnose. I know you mimicked the Rust entry before this point > > (just above the precontext of the hunk), but I think we should fix > > it to drop the "disabled" entry from there. > > > > Cc'ed the author of cb2badb4 (help: report on whether or not Rust is > > enabled, 2025-10-02). > > One reason why I personally prefer to have enabled/disabled is that it > allows you to discern the following two cases: > > - You have a modern version of Git that doesn't have gettext. > > - You have an old version of Git that doesn't know to print > information about whether or not gettext is enabled. > > If we don't print the info at all when gettext is disabled then it's > impossible to tell these two cases apart. That argument in my mind also Both `git version --build-options` and `git bugreport` display the Git version number. This allows us to identify whether we're looking at an old version that predates the gettext feature, or a modern version where we can expect gettext status to be explicitly reported (even if disabled). In reroll v2, I considered outputting GIT_LOCALE_PATH instead of "enabled" for gettext, but that would have required refactoring git_setup_gettext() in gettext.c. The benefit didn't seem worth the effort, so I dropped it. -- Jiang Xin ``` ## Junio C Hamano, 2026-01-20 00:15 Subject: Re: [PATCH] help: report on whether or not gettext is enabled Message-ID: URL: https://gitlist.dev/e/xmqqsec13zsd.fsf%40gitster.g In-Reply-To: ``` Patrick Steinhardt writes: >> Combined with the vintage of Git binary that had these help text, >> the fact that an "enabled" line is missing is enough clue to >> diagnose. >> ... > > One reason why I personally prefer to have enabled/disabled is that it > allows you to discern the following two cases: > > - You have a modern version of Git that doesn't have gettext. > > - You have an old version of Git that doesn't know to print > information about whether or not gettext is enabled. When you see no "gettext:" line in the report, you can tell between the above two cases by looking at what the first entry in the same report "git version --build-options" produced, which is the Git version, can't you? ``` ## Patrick Steinhardt, 2026-01-20 05:47 Subject: Re: [PATCH] help: report on whether or not gettext is enabled Message-ID: URL: https://gitlist.dev/e/aW8W-SzorzDC8-rg%40pks.im In-Reply-To: ``` On Mon, Jan 19, 2026 at 04:15:14PM -0800, Junio C Hamano wrote: > Patrick Steinhardt writes: > > >> Combined with the vintage of Git binary that had these help text, > >> the fact that an "enabled" line is missing is enough clue to > >> diagnose. > >> ... > > > > One reason why I personally prefer to have enabled/disabled is that it > > allows you to discern the following two cases: > > > > - You have a modern version of Git that doesn't have gettext. > > > > - You have an old version of Git that doesn't know to print > > information about whether or not gettext is enabled. > > When you see no "gettext:" line in the report, you can tell between > the above two cases by looking at what the first entry in the same > report "git version --build-options" produced, which is the Git > version, can't you? Fair, that's possible. It still feels roundabout though as now the user also needs to know when this feature was implemented. That's why I lean towards just adding the info in both enabled and disabled cases: it gives you the information unconditionally. We don't really lose anything on our side, and the end user has an easier job to figure out whether the feature is enabled or not. But as I said, I don't feel strongly enough about this to request any changes. Thanks! Patrick ```