Bug#748215: gettext(3) should special case both C and C.UTF-8 wrt LANGUAGE lookup

2022-08-04 Thread Vincent Lefevre 
On 2022-08-04 10:23:42 +0200, Aurelien Jarno wrote:
> On 2022-08-04 00:33, Vincent Lefevre wrote:
> > On 2014-05-19 00:33:00 +0200, Aurelien Jarno wrote:
> > > Until the C.UTF-8 locale is integrated directly into glibc instead of
> > > being provide like a standard locale, it's not going to be something
> > > easy to do.
> > 
> > Well, on the upstream side, the C.UTF-8 locale is now provided,
> > but the bug still occurs.
> 
> It is provided like a standard locale, but has not been integrated
> directly into glibc (like the built-in C locale), so it's expected that
> the bug stills occurs.

It seems that since upstream bug 17318 has been closed, upstream
won't do anything more concerning its integration (whatever this
means) and something special will be done to fix this bug (i.e.
upstream bug 16621). According to Florian Weimer, the main problem
(as opposed to the C locale) would be to handle aliases, and indeed,
while Debian currently provides only C.UTF-8, with glibc 2.35 C.utf8
and C.utf-8 also work as aliases and are also affected by this bug
(tested on an Ubuntu 22.04 LTS machine with libc6 2.35-0ubuntu3).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#748215: gettext(3) should special case both C and C.UTF-8 wrt LANGUAGE lookup

2022-08-04 Thread Aurelien Jarno 
On 2022-08-04 00:33, Vincent Lefevre wrote:
> On 2014-05-19 00:33:00 +0200, Aurelien Jarno wrote:
> > Until the C.UTF-8 locale is integrated directly into glibc instead of
> > being provide like a standard locale, it's not going to be something
> > easy to do.
> 
> Well, on the upstream side, the C.UTF-8 locale is now provided,
> but the bug still occurs.

It is provided like a standard locale, but has not been integrated
directly into glibc (like the built-in C locale), so it's expected that
the bug stills occurs.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#748215: gettext(3) should special case both C and C.UTF-8 wrt LANGUAGE lookup

2022-08-03 Thread Vincent Lefevre 
On 2014-05-19 00:33:00 +0200, Aurelien Jarno wrote:
> Until the C.UTF-8 locale is integrated directly into glibc instead of
> being provide like a standard locale, it's not going to be something
> easy to do.

Well, on the upstream side, the C.UTF-8 locale is now provided,
but the bug still occurs.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#748215: gettext(3) should special case both C and C.UTF-8 wrt LANGUAGE lookup

2014-06-02 Thread Dimitri John Ledkov 
On 26 May 2014 20:45, Jakub Wilk jw...@debian.org wrote:

 What I find unexpected is this:

 $ LANGUAGE=de LC_ALL=de_DE.UTF-8 stat /moo
 stat: cannot stat '/moo': No such file or directory


Above should be in German, no?! It is, at least, for me.

I am for special-casing C.UTF-8 as it's aimed to serve the same
purpose as C, but with a richer characterset. Otherwise, hunting down
every single case of LC_ALL and adding LANGUAGE to it, is just a lot
of unnecessary (albeit pedantically correct) work.

-- 
Regards,

Dimitri.


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/canbhluit-jt2qj1gnauot99wl9ucfgpp5wn_7l5qzbz0ihs...@mail.gmail.com

Bug#748215: gettext(3) should special case both C and C.UTF-8 wrt LANGUAGE lookup

2014-06-02 Thread Jakub Wilk 

* Dimitri John Ledkov x...@debian.org, 2014-06-02, 21:12:

What I find unexpected is this:

$ LANGUAGE=de LC_ALL=de_DE.UTF-8 stat /moo
stat: cannot stat '/moo': No such file or directory


Above should be in German, no?!


See, I was right when I said unexpected. :-P

The message is in German only if the de_DE.UTF-8 locale is installed, 
and it isn't on my system.


--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140602202406.ga9...@jwilk.net

Bug#748215: gettext(3) should special case both C and C.UTF-8 wrt LANGUAGE lookup

2014-06-02 Thread Dimitri John Ledkov 
On 2 June 2014 21:24, Jakub Wilk jw...@debian.org wrote:
 * Dimitri John Ledkov x...@debian.org, 2014-06-02, 21:12:

 What I find unexpected is this:

 $ LANGUAGE=de LC_ALL=de_DE.UTF-8 stat /moo
 stat: cannot stat '/moo': No such file or directory


 Above should be in German, no?!


 See, I was right when I said unexpected. :-P

 The message is in German only if the de_DE.UTF-8 locale is installed, and it
 isn't on my system.


Gotcha! That bit is indeed, true. *fun*

-- 
Regards,

Dimitri.


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CANBHLUi7RTj=pvxujvj3hvmgogcar3d1vq1fq6k-arvhj8s...@mail.gmail.com

Bug#748215: gettext(3) should special case both C and C.UTF-8 wrt LANGUAGE lookup

2014-05-26 Thread Jakub Wilk 

[I'm not (e)glibc maintainer, just a random gettext user.]

* Zygmunt Krynicki zygmunt.kryni...@canonical.com, 2014-05-15, 12:57:
If the LANGUAGE environment variable is set to a nonempty value, and 
the locale is not the C locale, the value of LANGUAGE is assumed to 
contain a colon separated list of locale names. The functions will 
attempt to look up a translation of msgid in each of the locales in 
turn. This is a GNU extension.


This semantics of LANGUAGE is confusing and error-prone (it overrides 
LC_ALL... except when it doesn't). The exception for C was needed not 
to break existing software that set LC_ALL=C with the expectation that 
it resets all internationalization settings.


But the C.UTF-8 locale is newer invention that the LANGUAGE variable, so 
there is no need to add such exception.


This part works as expected. I would like to propose that the same 
special-case behavior is used when the locale is C.UTF-8 as it is 
becoming the de-facto better C and it is unexpected to see, for 
example, translated gettext messages when using such locale.


What I find unexpected is this:

$ LANGUAGE=de LC_ALL=de_DE.UTF-8 stat /moo
stat: cannot stat '/moo': No such file or directory

$ LANGUAGE=de LC_ALL=pl_PL.UTF-8 stat /moo
stat: der Aufruf von stat für „/moo“ ist nicht möglich: Datei oder Verzeichnis 
nicht gefunden

At least with the advent of C.UTF-8, I don't have to hunt for an 
installed locale, and just use:


$ LANGUAGE=de LC_ALL=C.UTF-8 stat /moo
stat: der Aufruf von stat für „/moo“ ist nicht möglich: Datei oder Verzeichnis 
nicht gefunden

which works everywhere.

--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140526194236.ga3...@jwilk.net

Bug#748215: gettext(3) should special case both C and C.UTF-8 wrt LANGUAGE lookup

2014-05-18 Thread Aurelien Jarno 
On Thu, May 15, 2014 at 12:57:04PM +0200, Zygmunt Krynicki wrote:
 Package: src:eglibc
 Severity: wishlist
 Tags: l10n
 
 Reading the gettext(3) man page I see the following fragment:
 
If the LANGUAGE environment variable is set to a nonempty value,
and the locale is not the C locale, the value of LANGUAGE is
assumed to contain a colon separated list of locale names. The
functions will attempt to look up a translation of msgid in each
of the locales in turn. This is a GNU extension.
 
 This part works as expected. I would like to propose that the same
 special-case behavior is used when the locale is C.UTF-8 as it is
 becoming the de-facto better C and it is unexpected to see, for
 example, translated gettext messages when using such locale.

Until the C.UTF-8 locale is integrated directly into glibc instead of
being provide like a standard locale, it's not going to be something
easy to do.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140518223300.gc5...@hall.aurel32.net

Bug#748215: gettext(3) should special case both C and C.UTF-8 wrt LANGUAGE lookup

2014-05-15 Thread Zygmunt Krynicki 
Package: src:eglibc
Severity: wishlist
Tags: l10n

Reading the gettext(3) man page I see the following fragment:

   If the LANGUAGE environment variable is set to a nonempty value,
   and the locale is not the C locale, the value of LANGUAGE is
   assumed to contain a colon separated list of locale names. The
   functions will attempt to look up a translation of msgid in each
   of the locales in turn. This is a GNU extension.

This part works as expected. I would like to propose that the same
special-case behavior is used when the locale is C.UTF-8 as it is
becoming the de-facto better C and it is unexpected to see, for
example, translated gettext messages when using such locale.

-- System Information:
Debian Release: jessie/sid
  APT prefers utopic-updates
  APT policy: (500, 'utopic-updates'), (500, 'utopic-security'), (500, 
'utopic'), (100, 'utopic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.13.0-24-generic (SMP w/8 CPU cores)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140515105704.17923.81069.reportbug@silverblade