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

[Pádraig Brady]

On 30/06/10 22:10, Paul Eggert wrote:
> [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.

True.
Translations will need to be provided if another default order is desired.

> 
> 
> 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?

right

> 
> 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.

I'm not a fan of verbose NEWS messages, but the above is correct
and more descriptive. I'll come up with something based on that.

thanks for the review,
Pádraig.