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

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

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


From: Tomohiro KUBOTA
Subject: Re: use of locale in "ls" again (Re: Japanese expression of date)
Date: Sat, 22 Dec 2001 21:35:03 +0900
User-agent: Wanderlust/2.8.0 (Something-pre) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (Unebigoryōmae) APEL/10.3 Emacs/20.7 (i386-debian-linux-gnu) MULE/4.1 (AOI)

Hi,

At Fri, 21 Dec 2001 14:35:35 -0800 (PST),
Paul Eggert wrote:

> Please let me try to explain that point.

Thank you for explaining your point.  However, I am not convinced.


> Ideally 'ls' would present output in a pleasant format to everybody.
> But this has maintenance costs, and documentation costs, and setup
> confusion costs, and these are all undesirable.  It is not entirely
> implausible to argue that a standard date format lowers the overall
> cost of using and maintaining the software -- so in that sense, it is
> "better" than using idiosyncratic formats.

Anyway 'ls' already has .po files.  The cost of small enough because
it means just adding one msgid.  For languages and countries who don't
have enough human resource for translating the msgid, of course the
.po file can be empty.  When a user (with enough skill) occasionally
comes across the GNU 'ls' and thinks that translation is needed, he/she
can do the job anytime.

On the other hand, if we want a single expression which satisfy people
from many countries, we needed a certain amount of discussion even for
only one language of German.  Each time a newcomer from a new country
complains, we will need discussion again.  When one of oldcomers is
occasionally absent for the new discussion, he/she will have enough
reason that the new single expression will be unpleasant for his/her
language.

If you really think the cost is the problem, abolish all .po files.

> Within Japan there are many plausible time stamp formats to choose
> from.  They include the conservative format used by the likes of the
> Imperial Household Agency, the ISO format used by the likes of
> Slashdot Japan, the intermediate format that you prefer, and some
> other variations as well.  So the question of a default is not simply
> a matter of Japan versus the rest of the world -- we can't please even
> just Japan with a single default.

Yes, I understand this point well.  I said most of Japanese people will
accept ISO format (without omitting year).  However, this is not the
point of my opinion.  Now my viewpoint is general i18n, not Japanese.


> And Japan is not unusual in this respect.  Most countries have
> multiple date and time formats.  We can spend time trying to specify
> defaults to cater to all these environments.  Or we can spend our (and
> our users') limited resources elsewhere.

Leave such discussions to the translation team.  Only native speakers
of the language who lives long years in the culture can judge which
expression is most likely to be accepted by most people.  Thus all
the core team member who received complain from users on translated
format is to forward the complain mail to the translator.  Of course
Japanese has various date expression, as you can watch various choice
in the user preference page in Slashdot Japan and the discussion in
Slashdot Japan I pointed.

On the other hand, if a person from some country complain about
'world standard expression' of 'ls', the core team (not the translator)
is responsible.  It is core team members who have to spend limited
resources to discuss about the expression.

> But GNU Emacs doesn't invoke 'ls' with LC_ALL=C.  It uses whatever
> date format 'ls' uses, and displays that format to the user.

GNU Emacs must invoke 'ls' with LC_ALL=C if needed.  In this case,
it is true that users cannot read their preferrable format.  However,
this is never worse than 'standard expression' everywhere.  And more,
GNU Emacs already has a solution for this problem by not using 'ls'.
If you say about possibility of other softwares, we will also need
to stop using gettext at all, because this problem is not limited
to date expression.

---
Tomohiro KUBOTA <address@hidden>
http://www.debian.or.jp/~kubota/
"Introduction to I18N"  http://www.debian.org/doc/manuals/intro-i18n/



reply via email to

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