[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Pádraig Brady
Subject: Re: [PATCH]: ls: do not show long iso time format for en_* locales
Date: Wed, 30 Sep 2009 10:54:22 +0100
User-agent: Thunderbird (X11/20071008)

Paul Eggert wrote:
> Jim Meyering <address@hidden> writes:
>> However, I'm a little reluctant to change back.
>> Let's wait a day or two, in case Paul Eggert has an objection.
> Here are some objections to the change, under the assumption that
> we're in a poorly-configured environment (as the behavior is
> unaffected in well-configured ones):
> * The change will cause column-alignment problems in non-English
>   locales where %b generates different numbers of columns for
>   different months.

Good point, but a separate issue which is already handled:

> * There are more users in non-English locales than in non-"C" English
>   locales, and the harm in the non-English case (incomprehensible
>   dates) is much greater than the harm in the English case
>   (comprehensible but ugly dates).

Yes this is the crux of the question.

With the patch we have:
no_coreutils_style_translation && wrong_sys_abmon => English month shown

While currently we have:
no_coreutils_style_translation => ISO date shown (4 chars wider)

A quick check on my system shows the first condition where
abmon is wrong, triggers for 3 locales. We've no control over
abmon so one could argue that we should not worry about it.
It might even help get these fixed up?

  locale -a | sed -n 's/\(.*utf8.*\)/\1/p' | sort -u |
  while read LANG; do
    printf "$LANG\t"; locale abmon
  done |
  grep "Jan;Feb;Mar;Apr;May;Jun;Jul;Aug;Sep;Oct;Nov;Dec" |
  cut -f1 | grep -v ^en_


On the other hand we'll display ISO dates for languages
for which we've no translations, which on my system is:

   locale -a | cut -s -d_ -f1 | sort -u | sort -u

   cd ~/git/coreutils/po && printf "%s\n" *.po |
   sed 's/\([^._]*\).*/\1/' | sort -u
  ) |
  sort | uniq -u | wc -l


> * The existing code is better for the poorly-configured case where
>   only one of the two translations is missing.

Very unlikely, but a valid point.

> Unless I'm missing something, I'd leave it alone, as it sounds like
> the change will cause more trouble than it'll cure.

Ok, I'm fine to hold off to see if there are any more
objections from the 108 languages above (we've only
had 1 objection in 4 years for english at present).


On a related note, I notice that we don't check the return
from setlocale() and so will use english months
when there is no system locale installed at all.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]