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