bug-gettext
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gettext binaries for Cygwin


From: Bruno Haible
Subject: Re: gettext binaries for Cygwin
Date: Wed, 04 Dec 2024 21:34:01 +0100

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.

Bruno






reply via email to

[Prev in Thread] Current Thread [Next in Thread]