[Top][All Lists]

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

Re: lynx-dev Re: lynx should respect LANG

From: Klaus Weide
Subject: Re: lynx-dev Re: lynx should respect LANG
Date: Wed, 24 May 2000 12:31:36 -0500 (CDT)

On Wed, 24 May 2000, Henry Nelson wrote:

> > 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?"  

Most like, appropriate is what follows the system wide conventions on
the system in question.  The same string that makes other programs on the
same system switch so the desired behavior.

> 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?

Exactly which of the two?  Or both?  Or did you mean "LANG[not UAGE] = ja"?

According to my proposal, $LANGUAGE is ignored, while $LANG will be
handled by heuristics. Again I refer to
<>, have a look
at it.  Somebody has already done the hard work of taking existing
practice in numerous systems into account, this can easily be used.

Concretely, "LANG = ja" will be taken to mean EUC-JP, while
"LANG = japanese" will be taken to mean Shift_JIS.

> 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.

You'd probably not enable the new option then at all, but continue
to operate as you do now.

I know too little about your OS to say whether you are using it as
expected.  I would assume though that, if the system supports both
EUC and SJIS, then it supports them in the form of two different locales.
So one LANG string would be appropriate for one situation, and a different
one for the other.  Is that not the case?

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

Setting LANG cannot magically change the environment, but it can tell
the application what the environment *is*.  (And in 'common' situations,
it will even be right.)

> 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 assume many systems are installed with a system-default $LANG, the user
may not be aware of it at all.  That makes sense for systems that don't
have to serve a wide user base.  Including most personal UNIX workstations.

> 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.

Yes, still a good idea.

Or just install the program correctly, with environment variables, lynx
binary, and configuration files already "coordinated", if it's to serve
only one (or a few) local user(s), where requirements don't vary.

> 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.

That's a possibility if the $LANG value is taken to mean Shift_JIS while
the actual terminal or console wants something else.  Not a problem on
UNIX as long as "sane" $LANG values are used, AFAIK.  (Yes, "japanese"
as opposed to "ja" or "ja_JP.eucJP" or "ja_JP.ujis" is not sane in this
sense.)  The common character natively used on UNIX systems, including
ISO-* and EUC-*, don't include glyphs in the control character range,
so there should be no lockup possibility introduced by picking the
wrong one among those.

And, again, the default for this would be FALSE.  You - as an installer
or packager - change it only for a target system where "modern" locale
conventions ("ja", "ja_JP.*", "ja_JP.*" rather than "japanese") are the
norm.  I expect that includes all modern Linux and *BSD distributions
for example, am I wrong?


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

reply via email to

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