bug-gnu-utils
[Top][All Lists]
Advanced

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

Re: Japanese expression of date (Re: use of locale in "ls")


From: Paul Eggert
Subject: Re: Japanese expression of date (Re: use of locale in "ls")
Date: Wed, 19 Dec 2001 15:03:08 -0800 (PST)

> From: Bruno Haible <address@hidden>
> Date: Wed, 19 Dec 2001 19:03:42 +0100 (CET)
> 
>        msgid "%b %e  %Y"
>        msgstr "%YNEN %mGATSU %dNICHI"
> 
>        msgid "%b %e %H:%M"
>        msgstr "%mGATSU %dNICHI %H:%M"

With this, the columns don't line up, and there are unnecessary spaces.
Surely here's a better choice:

  $ ls -l --time-style='locale' .plan .profile
  -r--r--r--    1 eggert   eggert        386 1981年 7月14日    .plan
  -r--r--r--    1 eggert   eggert       4012 11月20日 11時03分 .profile
  $ ls -l --time-style='posix-iso' .plan .profile
  -r--r--r--    1 eggert   eggert        386 1981-07-14  .plan
  -r--r--r--    1 eggert   eggert       4012 11-20 11:03 .profile

(I've written this in Japanese, as the issue about lining up columns
gets lost with the NEN etc. metanotation.  I've also used the
traditional Japanese time stamp format instead of the ISO format.)

This isn't "right" either, as the Japanese style typically omits
spaces within dates, but we have to do something to make the columns
line up.  The HH:MM notation is popular in Japan as well, and is
traditional for Unix 'ls', so it is a quite reasonable alternative.
(As far as I know, there is no real standard here: one can easily find
major Japanese timetables that use HH:MM, HHMM, HMM, etc.)

Here are translations to implement the above format:

  msgid "%b %e  %Y"
  msgstr "%Y年%b%e日   "

  msgid "%b %e %H:%M"
  msgstr "%b%e日 %H時%M分"


While we're on the subject, a more-traditional Japanese date format
uses imperial years (e.g., 平成13年12月19日 rather than 2001年12月19日),
and more-traditional Japanese times use Japanese AM/PM rather than a
24-hour clock.  These formats are what I see on the Imperial Household
Agency's web site, for example.  No doubt some Japanese users would
prefer this format to the Gregorian one.  But they consume even more
columns and may be difficult to do correctly in a portable way (e.g.,
to make the columns line up).


> don't force on them a display that contains only numbers and no
> ideograms.

We're not forcing them; they have an option to display localized dates.
The only question is what will be the default.


>   1) Improve the translator comment for these two strings. Currently
>      it just says
> 
>      "strftime formats for non-recent and recent files, respectively,
>      in -l output."
> 
>      Write down all concerns about order, number of columns and so on
>      in this comment.
> 
>   2) Let the translators groups decide what is best for their locale,
>      according to the description in the translator comment.

These are good suggestions; (2) goes without saying.  But I'm still
not sure I agree with your suggestion (3) about making 'locale' the
default time-style.  We've already spent a lot of time on this issue,
and it's still not fixed for Japanese, nor is there likely to be an
ideal or even a "good" solution.

I'm not sure it's worth all this hassle.  Most Japanese users won't
care much about this issue one way or another.  The ISO style format
will be OK for them.  They're already used to similar formats, and to
variation in time stamp formats.  And, of the exceptional users who do
care passionately about Japanese date formats, most will probably be
unhappy about some detail of whatever 'locale' solution we choose.

So here are two more suggestions, to help cater to these exceptional users:

4) Allow the user to specify the two time stamp formats using strftime
   strings.

5) Arrange for 'ls' to make the columns line up even if the translated
   time stamps have differing number of columns.

(5) will make (4) a bit easier to use.  At least the overall 'ls'
columns will line up, even if the internal columns within the time
stamp column don't line up.  Making the internal columns line up would
be another task -- let's call it task (6) -- but I am perhaps gilding
the lily here.

A hassle with implementing (4)-(6) is avoiding undefined behavior when
users submit malicious strings.



reply via email to

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