Re: lynx-dev Re: lynx should respect LANG

[Atsuhito Kohda]

From: Klaus Weide <address@hidden>
Subject: Re: lynx-dev Re: lynx should respect LANG
Date: Tue, 23 May 2000 15:06:57 -0500 (CDT)

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

Yes, I agreed.

> 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

Great!  I think this is much more than I requested in a very
rough manner.  Thanks for your great efforts.

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

I understand now that I was thinking in a very simple 
fashion ;-)  On the contrary, you think very carefully
for every possible cases.

Thanks again and I hope this is realized in fact.

Best Regards,                   2000.5.24

--
 Debian JP Developer - much more I18N of Debian
 Atsuhito Kohda <address@hidden>
 Department of Math., Tokushima Univ.

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