bug#75379: 30.0.93; project-find-regexp expects "C" or "en" locale

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 5 Jan 2025 21:35:56 +0200
> Cc: orontee@gmail.com, 75379@debbugs.gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 05/01/2025 20:46, Eli Zaretskii wrote:
> >> Date: Sun, 5 Jan 2025 20:03:34 +0200
> >> From: Dmitry Gutov <dmitry@gutov.dev>
> >>
> >> Overriding the language seems indeed the way to go here.
> >>
> >> About using LANG specifically, any chance that it might interfere with
> >> the system's configured encoding, e.g. UTF-8 vs other? In your example,
> >> does searching for accented characters work as well?
> >>
> >> IIUC we can try LC_MESSAGES as the more specialized var. Does
> >> LC_MESSAGES=en work as well?
> > 
> > Please note that this doesn't work on Windows.
> > 
> > First, the Windows locale-dependent routines don't heed environment
> > variables, so setting LANG etc. in the environment will only do what
> > you expect if the program in question was either explicitly programmed
> > to pay attention to those variables or was linked with Gnulib
> > replacements for locale functions.
> > 
> > And second LC_MESSAGES is not supported by Windows locales at all.
> 
> Okay, but first of all, do Grep or Ripgrep use different localizations 
> on Windows, not just English?

For Grep, it depends on how it was configured when building.  The
default configuration uses gettext to translate messages, and this
message is marked as translated.

For Ripgrep, I don't know.

> If yes, is there a way to force locale at least for these ports?

I'm not sure, and I don't have a port here that supports translations
which I could test.  The only hope is if recent versions of Grep are
built in a way that does honor the environment variables, because the
Unix trick of saying "locale=FOO grep ..." doesn't work on Windows:
the locale is a global user-level setting.

Does someone who uses Windows have Grep built with gettext, and could
try setting the various locale-related environment variables?

> > Can't we instead have a database of these messages, like we do with
> > the "password" prompts?
> 
> Like the one is 'password-word-equivalents'? It seems like the approach 
> of last resort. But if nothing else will work...

Agree.