[Bug localedata/22848] ca_ES: update date definitions from CLDR

["rbuj at fedoraproject dot org" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=22848

--- Comment #16 from Robert Buj <rbuj at fedoraproject dot org> ---
(In reply to Egmont Koblinger from comment #10)
> (In reply to keld@keldix.com from comment #9)
> 
> > The abmon strings are made for posix utilities so they
> > can display aligned coloumns like in ls -l 
> 
> This pretty much contradicts bug 192, or at least, the fact that the string
> is abbreviated has per se nothing to do with alignment. A tool could, if it
> wanted to, align the full strings, or it could, if it wanted to, leave the
> abbreviated ones unaligned. There's nothing inherently aligned in the
> abbreviated names.
> 
> > Abmon strings should not be used for real language displays.
> > The long forms are intended for natural language display.
> 
> Could you define "real language display" or "natural language display"
> please, as it's not clear to me what you're trying to say. Is the output of
> an "ls" a real language display? What about the clock in the corner of my
> desktop which says "Sun Feb 18", is that okay this way? What about the
> output of "date" which for me is "2018. febr. 18., vasárnap, 23:43:06 CET",
> shall I submit a patch that changes it to "február" instead of "febr."?
> 
> > It was never the meaning of POSIX i18n that there should not be non-English
> > support for listings like ls -l
> 
> Did you mean this sentence this way, with 3 negations? As far as I
> understand, you're saying that it's absolutely okay for POSIX to show
> foreign strings in ls -l... but then:
> 
> > Unicode data was never intended for POSIX utilities.
> 
> Huh? I guess you meant "locale" instead of "Unicode", but still, I don't see
> where you're trying to get to.

I'm agree with you, ls constraint has a negative impact on glibc's LC_TIME
definition.

-- 
You are receiving this mail because:
You are on the CC list for the bug.