GNU bug report logs - #75379
30.0.93; project-find-regexp expects "C" or "en" locale

Previous Next

Full log

Message #14 received at 75379 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 75379 <at> debbugs.gnu.org, orontee <at> gmail.com
Subject: Re: bug#75379: 30.0.93; project-find-regexp expects "C" or "en" locale
Date: Sun, 5 Jan 2025 21:35:56 +0200

On 05/01/2025 20:46, Eli Zaretskii wrote:
>> Date: Sun, 5 Jan 2025 20:03:34 +0200
>> From: Dmitry Gutov <dmitry <at> 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?

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

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.