coreutils
[Top][All Lists]
Advanced

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

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


From: Paul Eggert
Subject: [coreutils] Re: [PATCH]: ls: do not show long iso time format for en_* locales
Date: Wed, 30 Jun 2010 14:10:34 -0700
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4

[Sorry if this is a duplicate; my first attempt to send this flopped I think.]

>>> * 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.
> ...
> Note Fedora 13 has got the inadvertent format change
> ...
> I estimate at least 50K en_ people have run `ls -l` and not complained:
>   
> https://bugzilla.redhat.com/buglist.cgi?query_format=advanced&version=13&component=coreutils&product=Fedora&classification=Fedora

But this doesn't address the crux of the question, as it doesn't
measure either the harm in the non-English case, or the harm in the
English case.  Instead, it indirectly measures only the people who
prefer the harmful English behavior, and it (quite understandably)
reports that there are no such people.

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

The damage is not just that the English month is shown.  It's also that the
English-style order is used for year, month, day, and time.  This
order is not appropriate for all languages.

>> A quick check on my system shows the first condition where
>> abmon is wrong, triggers for 3 locales.

On my host (Ubuntu 10.04), it triggers for 6 locales: ar_SA, hy_AM,
la_AU, sid_ET, tlh_GB, and ug_CN.  But I don't think this info is all
that important, as it doesn't address the order-of-elements issue.


On thinking about it further, I guess the main problem is that the
current behavior really irritates maintainers who have to deal with
poorly-maintained English locales all too often.  In contrast, people
who have to deal with poorly-maintained non-English locales are less
vociferous (in English, anyway :-) and perhaps less typical, and so do
not matter so much.  On those grounds, I will reluctantly admit that
the change is OK.  However, it needs to be documented better, in
two ways.

First, there should be a change to coreutils.texi that talks about
this stuff.  For example, the current text says "Most locales use a
timestamp like @samp{2002-03-30 23:45}." which will certainly not be
true after this change.  Can you please prepare something along
those lines?

Also, the NEWS entry doesn't explain the change well.  I suggest
the following NEWS item instead:

  ls -l now uses traditional rather than ISO-style date formats in
  poorly-configured locales that do not specify date formats.  For
  example, in a poorly-configured French locale, previous versions of
  ls -l would output a date in this ISO-style format:

    2009-05-01 12:34

  but newer versions will probably output one of the following:

    May  1  2009
    mai  1  2009
    mai    1  2009

  depending on how poorly the locale is configured.  (A
  properly-configured French locale would output "1 mai 2009".)  The
  new approach has nicer behavior in poorly-configured English
  locales; this advantage was judged to outweigh the disadvantage of
  generating less-predictable and often worse output in
  poorly-configured non-English locales.  The behavior is not changed
  in properly-configured locales, including the default C locale.

Does this sound OK?




reply via email to

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