Brian Inglis wrote:
The two patches
gettext-0.22.5-gettext-runtime-intl-gnulib-lib-localename-unsafe-c.patch
gettext-0.22.5-gettext-tools-gnulib-lib-localename-unsafe-c.patch
in my understanding have the effect that when a user
- has set their language preference in the Windows Control Panel,
- has not any LC_* or LANG environment variable set,
- uses a Cygwin program that makes use of gettext
(with the usual setlocale(LC_ALL,"") in main()),
no translations will be produced, thus ignoring the Windows Control Panel
setting.
Is my understanding correct?
Confirmed by Denis Excoffier in the other mail.
If so, why is this patch present? Is it considered to be a feature?
The three patches to {tools,runtime{,/intl}/gnulib/lib/localename_unsafe.c
remove the condition on Cygwin as locale is always set properly (unless users
work to do something bad!)
No, it is not always set properly.
I have a Cygwin 3.5.3 installation, with a ~/.profile and ~/.bashrc that
date from 2023-04-17, that carry the notice "# base-files version 4.3-3",
and that I have not modified myself.
I just changed my Windows 10 installation to use German (Germany) as locale
(in the Windows control panel), logged out, logged in again, started a Cygwin
window, and these are the values of the environment variables:
LC_CTYPE=de_DE.UTF-8
As a consequence, e.g. 'cp --help' produces English output, not German output.
For a properly working German environment, according to POSIX, there are one
of these three possibilities:
LC_ALL=de_DE.UTF-8
or
LANG=de_DE.UTF-8
or (only translations but not numbers or times localized):
LC_CTYPE=de_DE.UTF-8
LC_MESSAGES=de_DE.UTF-8
In any of these three cases, 'cp --help' would produce German output.
So, clearly, your assumption "locale is always set properly" is incorrect.
That's why it helps if the localename-unsafe.c patches are dropped.