Re: lynx-dev Re: lynx should respect LANG

[Henry Nelson]

> > > TEXTDOMAINDIR and TEXTDOMAIN are environment variables used by
[...]
> Actually, now that I have tried it - you must be talking about some
> other programs [1], not lynx. Or at least, not lynx at runtime (maybe

Seems I owe you and Mr. Kohda a deep apology. Those TEXTDOMAIN*
variables are a mystery to me, too. Some relic from some past age I
suppose.

> from mine; and I cannot see how that could be: the text domain and
> associated directory are hardcoded in LYMain.c, as

Hardcoded means it can be configured. Is LOCALEDIR what gets set with
the configure option --with-nls-datadir? I used to hand edit makefile
before the configure option. As to why my lynx might behave differently
from yours, perhaps those ifdef's make a difference. I configure with
--disable-included-msgs and --without-included-gettext, if it makes a
difference.

BTW, does Lynx do anything with NLSPATH?

> > > I disagree that LANG should be the major criterion for deciding
> > > the message catalogue to use.

The keyword is "major."

> Actually, according to my new findings, the L* env variables are the
> only way to select among catalogues at runtime - unless you resort to
> shuffling files or symlinks around, or modify the lynx code.
>
> Can you explain the difference?

No. Probably some mistaken notion I had; I've been away from gettext
for over a year. I do have two separate translations which are both
being used. I thought I was switching between them with those TEXTDOMAIN*
variables, but it must be because I compiled two versions of lynx, one
with the default GNU path (/usr/local/share, I _think_), and one in
my private account using the nls-datadir configure option. Maybe it's
because I use GNU libintl (see below)?

> [1] Actually, the gettext *program* (utility for shell scripts)
> observes those environment variables. BUt we were talking about

Maybe setting those variables was convenient at some past time for the
maintenance of the translation catalogue?

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

Should have been: "LANG is last in the order of priority."

> 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

You are correct. Since I use the GNU version, I can install two versions
of translations for every program, and then use LANGUAGE and LANG to
distinguish between systemwide and personal preferences to translations,
although not the intended use perhaps.

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

Well, probably mistaken, but I look at LANG as SJIS or EUC, i.e., some
character set, and I look at LANGUAGE as Japanese, i.e., some language.

> (and do it correctly). Realistically, who is going to write them, for
> all those new users on new systems?

"All those new users." Why take all the fun out of Un*x?

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

Actually, I wasn't talking about message catalogue selection here. I
was talking about the display character set. (That's what I thought
this thread was about originally. The NLS stuff came out later in the
thread, I believe.) I can set DCS to either EUC or SJIS, and Lynx will
[just] work, *IF* my terminal emulator is set to receive/send SJIS. The
only fatal combination is to have the DCS set to SJIS and the terminal
emulator set to EUC. Total speculation, but maybe this is why there's
all the barking about PC Un*x: the environment is a console that can
only do EUC, thus the absolute necessity to have DCS match LANG=EUC.

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

That is not the case at all. Lynx, quite frankly, is the least of my
worries. Paramount is that my terminal or console match LANG, whatever
happens after that is no big deal; I can handle it; I can fix it; I can
make it right if it's wrong. Get LANG out of wack in relation to how you
log in, and you can't do anything, period.

> 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

Sure. You could also give lynx the "right" $TERM anvironment variable
and screw lynx up to no end. I'd rather work on getting the curses
library, in my case Slang, (from what Hataguti implies, I've been doing
it wrong) compiled and installed correctly and the correct terminfo/termcap
description written _first_, then give TERM the right value.

Anyway, you are right on all accounts. All I'm saying is, "why do we
need all this automation?". How is anyone going to be able to anything
on their own if they're spoon fed all the time? We've got a setting in
lynx.cfg; we've got an option in the O)ptions menu (.lynxrc); we can
edit userdefs.h and compile in the DCS. IMHO, that's enough.

__Henry

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