gettext dropping locale.alias support and file except under glibc

[Jon Turney]

On 01/08/2025 15:57, 
brian.inglis-STZedVC82Zm4kSqn+l8+D7Dks+cytr/Z@public.gmane.org wrote:
> On 2025-07-31 13:59, Corinna Vinschen wrote:
>> On Jul 31 12:55, Brian Inglis wrote:
>>> Heads up that next release of gettext will drop support for locale.alias
>>> except under glibc, which also provides the file
>>> /usr/share/locale/locale.alias (content not updated since 2015).
>>>
>>> https://gitweb.git.savannah.gnu.org/gitweb/? 
>>> p=gettext.git;a=commit;h=e0caff
>>>
>>> I have requested more information from maintainer Bruno Haible about the
>>> exact limitations of gettext without glibc, as well as support of
>>> /etc/locale.alias.
>>>
>>> It appears it may be up to our newlib/Cygwin libc to provide or 
>>> source any
>>> locale.alias to map to our supported locales, and our Cygwin locale
>>> interface already does its best to match then convert the info.
>>
>> The NLS in the Cygwin DLL already supports /usr/share/locale/locale.alias
>> and I don't think it makes sense to change that.  For backward 
>> compatibility,
>> we should continue to ship it, for instance, in a gettext-locale.alias
>> package or something like that.
>>
>> There's also no good reason to add to this file.  Its only reason for
>> existence is maintaining backward compatibility with pre-existing locale
>> aliases like "french", "japanese.euc" or "no_NO" (albeit support for
>> the latter is builtin to the DLL).
> 
> Hi Corinna,
> 
> Same for libX11 which is a *maintained* superset, compatible with more 
> legacy locales and systems, and could make support and results more 
> compatible between console and X, as well as other systems!
> 
> I just wondered if it would make sense to filter out those libX11 
> locales not in our supported MS Windows locales:

No. I think you should probably ignore this.

It is (was?) possible to build libX11 with it's own locale support for 
systems which didn't have it. But we haven't done that for quite some 
time (so libX11 should be using the native locale support rather than 
it's own).