coreutils
[Top][All Lists]
Advanced

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

Re: [PATCH] ls: use right-aligned abbreviated month names


From: Daming Yang
Subject: Re: [PATCH] ls: use right-aligned abbreviated month names
Date: Mon, 18 Feb 2019 02:31:52 +0800

   How about adding a table in ls for those locales which should be
   right-alignment?
   I checked the full list of 293 locales official supported by glibc and
   I would like to explain more here.
   Many (about 200) locales have their own three-letter abmon.
   In the remaining about 90 locales, have 11 CJK locales which share the
   same Sino-xenic vocabulary "aeoe^, yuA", weol(e~), jyut6, getu,
   goat8/goeh8..." stand for "month". This word works like a ordinal
   numbers "6th-month, 12th-month". ** I would say it's a number with a
   unit likes 8 kilogram rather than a normal text.**
   I am a native speaker of Cantonese (yue_) and Mandarin (cmn_) using
   Chinese writing system (zh_). I watch the messy misaligned layout
   everyday especially in February and March when mtimes become a mixture
   of two-digit month and one-digit month.
   Vietnamese is the opposite. Vietnamese doesn't use Sino-Vietnamese
   vocabulary in month names. "ThA!ng" stands for month, "Thg 2" is
   literally "month 2". These should be left-aligned.
   Also there are about 60 other locales whose writing systems are
   generally phonetic, coming from names in mythology or natural objects
   and indubitably hard to abbreviate to fixed length abmon. They are
   texts and will not be benefited from using right-alignment.
   Although there are a lot of users from CJK, I am actually not sure how
   should we fix this. Because clearly, there is no such a hardcoded
   alignment settings works well for all locales. I do not consider the
   patch an appropriate fix.
   Rethinking the patch, I think adding a table in ls for those locales
   should work better, though it simultaneously adds complexity.
   As for the whitespaces for alignment in localedata, I agree with Brady,
   align the text in glibc locale database is the wrong way to do. ISO C
   Standard didn't mention anything about alignment. 7.27.3.5 (The
   strftime function) only says "%b is replaced by the locale's
   abbreviated month name. %B is replaced by the locale's full month name.
   %h is equivalent to %b." Adding leading spaces or trailing spaces to
   glibc may affect the whole system. A Japanese message  "a
   fa'DEGa-%ba<a' 0/00e"~eOE^2a o a'OEa|a"a 3/4a(TM)aEUR'" (Log has been
   recorded since %b.) ends up a weird "a fa'DEGa-_1aeoe^a<a'
   0/00e"~eOE^2a o a'OEa|a"a 3/4a(TM)aEUR'".
   2019/02/17 aa^aa 3/4OE0:51 PA!draig Brady <address@hidden>:

     On 15/02/19 10:03, Lion Yang wrote:
     > * src/ls.c: Use right-alignment for the list of months
     > to make it more visually aligned. Locales which have names
     > with fixed lengths will not be affected.
     > ---
     >   src/ls.c | 2 +-
     >   1 file changed, 1 insertion(+), 1 deletion(-)
     >
     > diff --git a/src/ls.c b/src/ls.c
     > index 243c186..e73e29a 100644
     > --- a/src/ls.c
     > +++ b/src/ls.c
     > @@ -1132,7 +1132,7 @@ abmon_init (char abmon[12][ABFORMAT_SIZE])
     >             if (strchr (abbr, '%'))
     >               return false;
     >             size_t req = mbsalign (abbr, abmon[i], ABFORMAT_SIZE,
     > -                                 &width, MBS_ALIGN_LEFT, 0);
     > +                                 &width, MBS_ALIGN_RIGHT, 0);
     >             if (! (req < ABFORMAT_SIZE))
     >               return false;
     >             required_mon_width = MAX (required_mon_width, width);
     >
     One generally wants to align text left and numbers right.
     So I don't think this would be an appropriate default.
     Though I see in some locales that numbers are used for months.
     I also see that the abbreviations can include alignment.
     (which is generally the wrong place to do that, but still we have to
     cater for it).
     So in summary numeric zh_CN is misaligned, while ja_JP is aligned
     (as it has the alignment included). Now our alignment code handles
     existing padding and so your change will work for all locates
     where the abmons starting with a number.
     So we should adjust the patch to select the alignment based on that.
     thanks!
     PA!draig


reply via email to

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