Re: lynx-dev Re: lynx should respect LANG

[Klaus Weide]

On Tue, 23 May 2000, Atsuhito Kohda wrote:

> You say it is not complete so it is doubtful it needs to belong 
> in lynx code but please think a bit realistic.  Compare lynx which
> can change its behavior corresponding to some environment variables
> and the present lynx which is set up only for English by default.
> 
> 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.

I think I have made my points that
 - LANG (and similar) variables can't control all aspects of localization
   (lynx already has more fine-grained mechanisms)
 - LANG etc. *shouldn't* override lynx's existing mechanisms, in general
   (that would just diminish functionality/configurability)
 - honoring LANG etc. is only useful in some situations
and you basically agree, so I won't belabo(u)r those points.

It remains that processing LANG can still be useful/helpful in some
situations and environments.  I think this is mostly limited to getting
a user started with lynx, in an environment where LANG (etc.) already
happen to be set appropriately (for the most "normal"/common case).
The user should still be able to - and is expected to - modify detailed
settings as necessary after becoming more familiar with the possibilities.

So, here is a concrete proposal, in the form of a draft for a lynx.cfg
option.  (If deemed necessary, equivalent userdefs.h and/or command line
options could also be provided.  But not .lynxrc/'O'ptions screen, it
should become obvious that that makes little sense and/or gets too
complicated to do in a reasonable way.)

# If USE_ENV_FOR_LOCALE is set to either TRUE or OVERRIDE, lynx processes
# several environment variables on startup to determine default values
# for several options that typically depend on the user's language and
# character set environment (locale).  Affected options, listed together
# with the environment variables in order of priority:
#   CHARACTER_SET          MM_CHARSET, LC_ALL, LC_CTYPE, LANG
#   PREFERRED_CHARSET      MM_CHARSET, LC_ALL, LC_CTYPE, LANG
#   ASSUME_LOCAL_CHARSET   LC_ALL, LC_CTYPE, LANG
#   PREFERRED_LANGUAGE     LC_ALL, LC_CTYPE, LANG
# Note that this mechanism doesn't depend on locale support by the OS or
# libraries; lynx only looks at the values for those variables as strings
# and uses heuristics for finding the charset and language that corresponds
# to a given locale name.  For display character set aspects, MM_CHARSET
# (a convention inherited from the metamail program) is preferred and takes
# precedence since it directly contains a charset in MIME form.
# Settings for the listed options that can be derived from environment
# variables override builtin defaults and values in lynx.cfg files.  If
# USE_ENV_FOR_LOCALE is set to OVERRIDE, they also override corresponding
# options from the user's .lynxrc file.
# This option is mainly intended for getting new users started quickly in
# common situations, on systems where using LANG etc. is an existing
# convention.  In slightly more complicated situations, for example when
# the terminal display character set differs from the charset used for
# files (e.g., because the user is remotely logged in in a heterogeneous
# environment), using individual lynx.cfg and .lynxrc options affords more
# detailed control; USE_ENV_FOR_LOCALE should be set to FALSE to ignore
# environment variables in that case.
#
# Note that some other aspects of lynx behavior may also be influenced by
# the L* variables listed (and maybe some others), depending on support by
# OS or installed libraries.  They include message localization (if lynx
# was built with NLS) and case mapping for WHEREIS searches (see also the
# FORCE_8BIT_TOUPPER option).  The effect of environment variables on 
# those aspects is independent of USE_ENV_FOR_CHARSETS, i.e. the relevant
# environment variables always take effect if supported by the underlying
# OS or library.
#
#USE_ENV_FOR_CHARSETS:FALSE


Additional notes:
1) Default is left to FALSE, to preserve previous behavior.
   I.e. lynx.cfg options are honored, regardless of what LANG etc. say.
   Packagers and distributors can easily change that, if they
   are building for an environment where that's more appropriate.
2) TRUE corresponds more or less to what's done in the Debian-JP wrapper.
   Adding OVERRIDE seem like a useful thing, to make LANG apply also
   after a user has saved options in .lynxrc once.
3) I assume that <ftp://ftp.ilog.fr/pub/Users/haible/utf8/locale_charset.c>
   or something very similar will be used to provide the mentioned
   [locale name] -> [charset MIME name] "heuristics".
4) The ( [locale name] -> ) [language tag] -> PREFERRED_LANGUAGE
   mapping should probably look similar to
       ( ja_JP.*       -> )    ja           ->   ja, en;q=0.9, *;q=0.5
       ( ja_JP.*       -> )    ja           ->   ja, *;q=0.5
   I prefer the second; there shouldnt really be a need to give English
   a special role.
5) The list of options affected is of course up for discussion.
   Atsuhito Kohda's wrapper only handled two of then, like
   #   CHARACTER_SET          LANG
   #   PREFERRED_LANGUAGE     LANG
   but I think my proposal makes more sense.
6) Existing extensions like LANGUAGE variable (only used by gettext?)
   blissfully ignored.  This isn't standard, and we'd have to deal with
   the possibility of multiple charsets and languages.
   (Well, a $LANGUAGE different from $LANG can still affect message
   translation - not handling it explicitly here can be regarded as a
   feature, it allows message catalog to be selected independently from
   CHARACTER_SET etc.).

Comments?  Implementations?

   Klaus


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