Re: lynx-dev Re: lynx should respect LANG

[Klaus Weide]

On Wed, 24 May 2000, Henry Nelson wrote:

> > Comments?
> 
> PLEASE, DON'T do it.  

Well... comments by others?  Like, on the specifics?

Henry, I hear you, but I'm not convinced by your objections so far.

> A VERY complex and intelligent wrapper that
> would handle the four or so environment variables concerning encoding
> and NLS, set paths to specific help/doc files, and be sure terminal
> and console settings are sane could be written with less words than
> the explanation you proposed for lynx.cfg alone, 

I doubt that very much.  If you want to uphold that claim, prove it. :)

Note that that "intelligent wrapper" should deal with more than just
two languages (not just ja vs en), and should be system independent
(not depend on specific install locations), in order to provide similar
functionality.

> not even considering
> the extra parsing of lynx.cfg and coding for lynx.
>
> Why do it?

Because LANG (etc.) is an existing convention on existing systems, and
there is an existing (and not unreasonable) expectation that locale-
aware programs honor that convention without requiring additional
wrappers.

Because with NLS, LANG is already used for selecting the message catalog.
It's reasonable to expect that it also affects the 'display character set'
to agree with the catalog's charset - otherwise the catalog will in
general be useless (since currently messages have to be in the same charset
as the display, to work correctly).

Because is is a generic mechanisms, can deal with a wide range of locale
names, even new ones not foreseen by a local script wrapper writer.

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
than "Check whether lynx is actually a wrapper shell script, and if yes
what does that script do".


I agree with you on all of the following:

This doesn't solve most of the problems involved in providing localized
lynx to non-English-speaking users.

Intelligent wrapper scripts will still be useful or even necessary.

Providing customized and translated help files is still a good idea.

This mechanism is not a magic bullet, it only addresses a small part of
the problem (and only in some environments).

And yes, it may even go wrong (therefore it's disabled by default).

> I mean lynx.cfg is way too big.  (And don't give me that "use includes"
> jive; 50 x 2.6k still equals 130k.)  Is any end to come to this madness?

I do not agree that lynx.cfg bytes are so precious that we should not
add any new options, and that adding any new options that are useless
to you are "madness".

   Klaus


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