[ On Wednesday, September 11, 2002 at 01:47:45 (+0900), SUNAGAWA Keiki wrote: ]
> Subject: Re: finger
>
> > From: Kimmo Suominen <kim@tac.nyc.ny.us>
> > Date: Mon, 09 Sep 2002 23:40:58 -0400
> > > Ok, I put in code to only enable 8-bit display for ISO8859-* codesets.
> > > Are there other single-byte 8-bit codesets?
> > 
> > please don't make daemons locale-sensitive.
> > and please don't hard-code codeset's name.
> 
> This thread reminds me that locale-sensitive ftpd and ls of
> several commercial Unix (e.g. Solaris, HP-UX) made emacs
> dired package unusable.  It is one of my reason why I
> dislike such systems.

Whoa now!  Hold on just a minute there!!!

The failures with emacs dired vs. locale-sensitive ftpd and ls are
_NOT_, repeat _NOT_, a problem with use of locales in those utilities.
The bug is _entirely_ and _only_ in 'dired' not also being locale-
sensitive.


> Kim, I think that I understand your desire to extend finger
> to grock your language, but it should not the way to go.
> 
> Suppose that my passport is written in my native language,
> Japanese.  A Custom officer of foreign contry may not read
> it.  That makes a Custom formalities more uncomfortable or
> even inpossible once in a while.  So unless there is
> particular agreement, my passport should be written in
> English, which has smallest charcter sets.
> 
> It's a good example of "localisation != internalisation".

Perhaps, but that's not really a good analogy for "finger", be it used
over the network or just locally.

It is perfectly fine to localize "finger" output, even when it crosses
the network.  It's all a matter of the end user's expectations.  The
protocol need not get involved -- it only needs to stand well out of the
way and pass the data the user asked to be passed without munging or
dropping even one bit of it.

Indeed the network need not even be invovled for this issue to arise.
The local 'finger' program may read data from someone's ~/.plan that is
not intended for the same locale as the terminal that data is about to
be displayed upon.

Of course on the receiving end the client program must take care to
ensure that the data received will not adversely affect the user's
terminal (and it must live with the assumption that the client user has
correctly set his or her locale to match the capabilities of the
terminal).  This same rule must applie regardless of whether the data
has been transfered over a network or just sucked from a local file.

If the end user cannot make sense of the displayed data then it is up to
them to try to figure out how to adjust their terminal and locale
settings to show it in the intended way.  The sender may, or may not,
try to make this easy to do by embedding within the data some indication
of what encoding was used to store it.

Meanwhile the 'finger' client program should be prepared to display its
own prompts and error messages in the current locale of the user.
Perhaps it hasn't been internationalized yet, but this must be taken
into account in this discussion.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>