Jim Meyering wrote:
> Pádraig Brady wrote:
>
>> Paul Eggert wrote:
>>> Ondřej Vašík writes:
>>>
as reported in https://bugzilla.redhat.com/show_bug.cgi?id=525134 by
Daniel Qarras, ls -l shows iso long format for en_* locales.
>>> I just now read that Bugzilla report, and the diagnosis and the
>>> patch do not seem correct. The diagnosis says:
>>>
In ls.c (case locale_time_style) is dcgettext (NULL, long_time_format[i],
LC_TIME); ... that translates the string, but the translation is THE SAME
as
the default - as the format is the same for en_* locales.
>>> But that is not what the ls.c source code does. The code does this:
>>>
>>> char const *locale_format =
>>> dcgettext (NULL, long_time_format[i], LC_TIME);
>>> if (locale_format == long_time_format[i])
>>> goto case_long_iso_time_style;
>>>
>>> The "==" test returns true when dcgettext returns the msgid (its 2nd
>>> argument) because it finds no translation.
>> Right. We don't have any translations for "en".
>
> This is key.
>
> Looking at Makefile.in.in, you can see that
> the file /usr/share/locale/en/LC_TIME/coreutils.mo is never installed,
> and neither is .../LC_MESSAGES/coreutils.mo, because coreutils has
> no po/en.po file. Pre-optimizers might argue that not installing the
> latter is a good thing, because gettext will then not waste time with the
> fstat+mmap+close that it normally performs after each successful .mo file
> open. Not to mention the cost of each subsequent failed message lookup.
>
> I try not to pre-optimize, so question whether the Makefile.in.in patch
> is worthwhile, but from an aesthetics point of view, I prefer not to
> install the LC_MESSAGES/coreutils.mo file. The core of the patch
> is this two-line addition:
>
> ++lang=en; for lc in '' $(EXTRA_LOCALE_CATEGORIES); do \
> ++ test -n "$$lc" && mv -f $(message_mo) $(lc_mo_file); done
>
> All of the rest is factoring. I'm leaning towards rewriting it to
> insert the non-factored equivalent. However, one advantage of using the
> patch is that it records the context: if we update to a newer gettext
> that changes the body of that rule, the patch will no longer apply,
> and that will make bootstrap fail. One alternative that could be used
> with the 3-line-insertion approach is to record (and always cross-check)
> a checksum of the rule contents.
>
> With this patch, in an en* locale, ls -l now uses the conventional
> date formats.
>
> Here's an incomplete patch.
> It needs a test and a NEWS entry.
> Ondřej, can you adjust your test to work (or skip)
> if there is no en* locale?
>
>>From 53c88d531d88e5d4ef393a61758bc3fee4894e48 Mon Sep 17 00:00:00 2001
> From: Jim Meyering
> Date: Sat, 26 Sep 2009 14:59:05 +0200
> Subject: [PATCH] ls: use conventional date format in long listing for en*
> locales
>
> * bootstrap.conf: Generate po/en.po with identity translations for
> the two LC_TIME strings required by ls.c.
> * configure.ac: Require gettext version 0.17.
> * po/Makefile.in.in-patch: Patch autopoint-provided file so that
> it provides the LC_TIME .mo file, but not the LC_MESSAGES one.
> * po/.gitattributes: Allow space-before-TAB in the patch.
> ---
> bootstrap.conf | 41 +
> configure.ac|2 +-
> po/.gitattributes |1 +
> po/Makefile.in.in-patch | 65
> +++
So that will apply generate an en.po with the
traditional unix format to apply to en_* for e.g.
$ locale -a | sed -n 's/\(en_..\).*/\1/p' | sort -u |
> while read LANG; do echo $LANG $(locale territory); done
en_AG Antigua and Barbuda
en_AU Australia
en_BW Botswana
en_CA Canada
en_DK Denmark
en_GB Great Britain
en_HK Hong Kong
en_IE Ireland
en_IN India
en_NG Nigeria
en_NZ New Zealand
en_PH Philippines
en_SG Singapore
en_US USA
en_ZA South Africa
en_ZW Zimbabwe
Is that not functionally equivalent to Ondřej's patch
which is much simpler and probably more efficient?
His patch will also use an en_ translation if supplied
(say if en_HK wanted a different format).
cheers,
Pádraig.
