Re: lynx-dev Re: lynx should respect LANG

[Henry Nelson]

> It will be sufficient for me to modify userdefs.h appropriately 
> for Japanese users and to create lynx-ja package.

There is no need to touch userdefs.h at all just "for Japanese users."

> better if one lynx package can work well for peoples
> all over the world as far as we can.

It does AS IS, and always has.  Even Lynx2.3 works satisfactorily
for Japanese; Lynx2.4 will work WITHOUT ANY settings whatsoever.
It was only a brief period of the early Lynx2.5 series that Japanese
users were inconvenienced in any way.  After the total integration
of the Asada modifications, no Japanese has had to struggle in the
slightest.

> Unless a user set $LANG appropriately, Linux or *BSD is not usable 
> at all for Japanese users so it can be safely assumed that $LANG is

What is "appropriate?"  What happens in the case of the generic "LANG = 
japanese" or "LANGUAGE = ja," which, for example is the default on the
system I login to?  What do you do with "setterm -x" available on some
OSs?  On some systems I can use either EUC or SJIS at will, and set it
to one or the other or neither depending on what machine I login from.
The lynx binary is exactly the same no matter what $LANG is.

What about X?  Isn't it a matter of having the appropriate fonts
available and not what $LANG is?

> > settings from $LANG - at least as initial defaults.  But they will
> > still be wrong for some users and some situations, even if we can come
> > up with a meaningful answer to "What's $LANG supposed to mean".  So
> > I'm not sure how much of that really belongs in lynx code.

I agree.  If a user can't set $LANG, then he/she's got some studying to
do.  If a user can set $LANG, then setting up Lynx will be a piece of cake.

I don't understand the problems you are having, but I think creating a
wrapper for Lynx is the best way to get good coordination between
environment variables, lynx binary, and configuration files.  Log into
some of the public-access Lynxes to get an idea of the possibilities.

> I think we would get not so small benefit from lynx which can change 
> its behavior corresponding to some environment variables even if
> it is far from complete.

Incomplete means that Lynx could set up an incompatible combination which
would result in the "freeze-up" of a terminal, perhaps even a console.

__Henry

; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden