[PATCH] help: report on whether or not gettext is enabled

[PATCH] help: report on whether or not gettext is enabled

[Jiang Xin]

From: Jiang Xin <zhiyou.jx@alibaba-inc.com>

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 <zhiyou.jx@alibaba-inc.com>
---
 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

Re: [PATCH] help: report on whether or not gettext is enabled

[Junio C Hamano]

Jiang Xin <worldhello.net@gmail.com> writes:

> From: Jiang Xin <zhiyou.jx@alibaba-inc.com>
>
> 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 <zhiyou.jx@alibaba-inc.com>
> ---
>  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).

[PATCH v2] help: report on whether or not gettext is enabled

[Jiang Xin]

From: Jiang Xin <zhiyou.jx@alibaba-inc.com>

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 <zhiyou.jx@alibaba-inc.com>
---
 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

Re: [PATCH] help: report on whether or not gettext is enabled

[Patrick Steinhardt]

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

Re: [PATCH] help: report on whether or not gettext is enabled

[Jiang Xin]

On Mon, Jan 19, 2026 at 3:03 PM Patrick Steinhardt <ps@pks.im> 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

Re: [PATCH] help: report on whether or not gettext is enabled

[Junio C Hamano]

Patrick Steinhardt <ps@pks.im> 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?

Re: [PATCH] help: report on whether or not gettext is enabled

[Patrick Steinhardt]

On Mon, Jan 19, 2026 at 04:15:14PM -0800, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> 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