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