[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: |
Pádraig Brady |
Subject: |
[coreutils] Re: [PATCH]: ls: do not show long iso time format for en_* locales |
Date: |
Thu, 01 Jul 2010 01:23:59 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 |
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.