tags 308853 + patch
thanks
On Mon, May 16, 2005 at 05:48:08PM +0200, Tomas Hoger wrote:
> Hi Denis!
>
> Thanks for your reply!
>
> On Sun, May 15, 2005 at 06:42:21PM +0200, Denis Barbier wrote:
>
> [...]
>
> > I cannot reproduce this behavior, I guess that you also set LANGUAGE to
> > sk_SK. You can perform similar checks with 'cp --help', and normally
> > you should see no differences between debconf and libc applications,
> > which demonstrates that there is no bug in debconf. Can you please
> > make these tests and report your conclusions?
>
> Yes, this was good guess. I do have LANGUAGE set to sk_SK. After
> unsetting LANGUAGE templates are displayed in English as expected.
>
> Regarding that 'cp --help' tests, when I have locale variables set as
> described in previous mail (LANG set to sk_SK; LC_TIME, LC_COLLATE and
> LC_MESSAGES set to C) and aslo LANGUAGE set to sk_SK, 'cp --help' is
> displayed in English. I get similar behavior for other programs (e.g. mc,
> mutt, vim, ...).
Hmmm, you are right, LANGUAGE environment variable is ignored when
LC_MESSAGES is set to C. I usually perform tests with locales different
from C ;)
GNU libc has this comment in dcigettext.c:
/* Ignore LANGUAGE and its system-dependent analogon if the locale is set
to "C" because
1. "C" locale usually uses the ASCII encoding, and most international
messages use non-ASCII characters. These characters get displayed
as question marks (if using glibc's iconv()) or as invalid 8-bit
characters (because other iconv()s refuse to convert most non-ASCII
characters to ASCII). In any case, the output is ugly.
2. The precise output of some programs in the "C" locale is specified
by POSIX and should not depend on environment variables like
"LANGUAGE" or system-dependent information. We allow such programs
to use gettext(). */
if (strcmp (locale, "C") == 0)
return locale;
The first item does not apply here because your LC_CTYPE is not ASCII,
and we do not care about standardized output. IMO there is no need for
debconf to implement this special casing, and my first intention was to
close this bug. Debconf maintainers, you can either close this bug
report or apply the attached patch to mimic glibc more closely.
> I did few more tests with debconf. I've unset all LC_* variables and also
> LANG and LANGUAGE to get clean environment. Then I tried following
> commands:
>
> LC_MESSAGES=sk_SK dpkg-reconfigure <pkg>
> -> Slovak "window" label and button labels, English template text
>
> LC_MESSAGES=sk_SK LC_CTYPE=sk_SK dpkg-reconfigure <pkg>
> -> labels and template text in Slovak
>
> I believe this test and its results should be easily reproducible. Hope I
> haven't made any mistake now ;).
>
> As you can see, there is not only difference in interpretation of locale
> settings among debconf and "other libc apps", but also among "parts of
> debconf".
See http://www.opengroup.org/onlinepubs/007908799/xbd/locale.html
If different character sets are used by the locale categories, the
results achieved by an application utilising these categories are
undefined.
So yes, there are some discrepancies here, but these are not bugs.
You will run into trouble whenever you set LC_MESSAGES to a locale
with an encoding different from LC_CTYPE. On the other hand, setting
LC_CTYPE=sk_SK and LC_MESSAGES=C is safe because iso-8859-2 is a
superset of ASCII.
Denis
--- Debconf.orig/Template.pm 2005-05-05 01:22:56.000000000 +0200
+++ Debconf/Template.pm 2005-05-16 21:38:08.704550568 +0200
@@ -408,7 +408,7 @@
my $language=setlocale(5); # LC_MESSAGES
my @langs = ();
# LANGUAGE has a higher precedence than LC_MESSAGES
- if (exists $ENV{LANGUAGE} && $ENV{LANGUAGE} ne '') {
+ if ($language ne 'C' && exists $ENV{LANGUAGE} && $ENV{LANGUAGE} ne '') {
foreach (split(/:/, $ENV{LANGUAGE})) {
push (@langs, _getlocalelist($_));
}
