patchhelp: report on whether or not gettext is enabled

> 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

> > 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).

> > ... 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

>> 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.

> 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?