Re: lynx-dev Re: lynx should respect LANG

[Klaus Weide]

On Thu, 25 May 2000, Henry Nelson wrote:

> > Because with NLS, LANG is already used for selecting the message catalog.
> 
> I don't believe this is true.

It's certainly true for me.  Linux, lynx using the gettext in
(Debian-packaged) libc6 2.1.2-11.

There is a standard order of precedence in which relevant environment
variables should be used.  For the LC_CTYPE 'category' (character
classification and conversion aspects),
     LC_ALL  >  LC_CTYPE     >  LANG,
for the LC_MESSAGES category (localized messages),
     LC_ALL  >  LC_MESSAGES  >  LANG,
and equivalent for other possible categories (setlocale(3) should tell
you about other categories).  The first environment variable that is
set and non-empty is used in each case.

Well, at least that's how programs normally are expected to behave if
they are locale-aware at all (in the "normal" way - i.e. program calls
'setlocale(LC_ALL, "")' at the beginning.)

For messages, GNU gettext adds a non-standard extension, the LANGUAGE
variable, so the precedence becomes

     LANGUAGE  >  LC_ALL  >  LC_MESSAGES  >  LANG

Try it - you *should* see this behavior in your lynx, as far as message
catalogue selection is concerned.

In the simplest case, just LANG will be set, which should then affect
all aspects (categories).  I certainly thing that that's the normal
way that will be used by most systems/users that need a localized
environment.

You do things differently - I am curious, why?  Did some documentation
suggest that you use (non-standard) LANGUAGE rather than LANG?

> I don't see any great advantage of a coded mechanism over a wrapper mechanism.

It will (would) be there, without anyone having to write those wrappers
(and do it correctly).  Realistically, who is going to write them, for
all those new users on new systems?

> > Because with a uniform mechanism, lynx-dev can deal better with problems
> > that users report. E.g., we will have to ask "What is $LANG set to", rather
> 
> And a wrapper using sh is not a "uniform mechanism?"
>                                          ^^^^^^^^^

Not in the sense that I meant...

> I can set LANG to pretty much whatever I want, and Lynx still works.  If
> I set my terminal emulator to the wrong kanji encoding then I'm in real
> trouble.  But if it's worth it to you, go ahead.

It appears (from your other messages) that you are setting either LANGUAGE
or LC_MESSAGES.  Both have precedence over LANG.  So no surprise if LANG
has no effect on message catalogue selection.

You regard it as an advantage that lynx doesn't react to $LANG at all.
Because you can't mess up lynx, no matter how wrong you set LANG.
Let me try an analogy: lynx reacts to the $TERM anvironment variable.
You *can* scree up lynx by giving TERM the wrong value (i.e. wrong for
the specific situation).  By extension of your logic, it would be a
"feature" if lynx didn't react to $TERM at all.  I hope you agree
that that's not desirable.  (Although for some people, in some situations
- probably with TERM set the wrong way out of ignorance or to accomodate
some other broken software - ignoring $TERM (and using some hardwired
assumptions instead) would actually *appear* as an improvement.)


    Klaus


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