Re: [PATCH]: ls: do not show long iso time format for en_* locales

[Pádraig Brady]

Jim Meyering wrote:
> Pádraig Brady wrote:
> 
>> Paul Eggert wrote:
>>> Ondřej Vašík <address@hidden> 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 <address@hidden>
> 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.