[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev Re: lynx should respect LANG

From: Klaus Weide
Subject: Re: lynx-dev Re: lynx should respect LANG
Date: Thu, 1 Jun 2000 11:33:35 -0500 (CDT)

On Thu, 1 Jun 2000, Atsuhito Kohda wrote:
> I have some questions which, I guess, are not so important.
> > So, here is a concrete proposal, in the form of a draft for a lynx.cfg
> When lynx sets CHARACTER_SET and/or PREFERRED_LANGUAGE automatically, 
> can a user check what values are effective right now by, for example,
> 'O'ption menu?

Yes, that was the idea.  It would also follow automatically from the
most straightforward way of implementing it:
(lynx startup sequence)
   - read lynx.cfg file(s)
   * modify some variables based on env  # if enabled, without 'OVERRIDE'
   - read .lynxrc file
   * modify some variables based on env  # if enabled with 'OVERRIDE'
   - handle (most) command line options

> > 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.
> I think English is generally a good enough for second candidate

That depends on the sites - many sites (that do content negotiation on
language) will be set up to return the English version as default
anyway (it matches the '*'), but it's not necessarily so.  So we
shouldn't build such an English-centric assumption into a browser, in
this day and age.  Unless perhaps we find some sites where this is
actually necessary.

> From: Klaus Weide <address@hidden>
> Subject: Re: lynx-dev Re: lynx should respect LANG
> Date: Sun, 28 May 2000 17:15:31 -0500 (CDT)
> > > If LC_ALL, LC_CTYPE or LANG is set to ja*, I want ASSUME_LOCAL_CHARSET
> > > isn't set to euc-jp nor Shift_JIS but set to "iso-8859-1", otherwise
> > > the auto detect routine for Japanese is disabled.
> > 
> > Four possible answers; pick one or more. :)
> (snip)
> > 4.) If, for making best use of lynx, you have to set ASSUME_LOCAL_CHARSET
> > to "iso-8859-1" (rather than leaving it unset) - then that's a design bug 
> > in lynx.  Saying that your files are in iso-8859-1 when that's the last
> > thing they are is clearly not the right way to go.
> Well, I might misunderstand here but, as far as I know,
> ASSUME_LOCAL_CHARSET can be left unset.

Yes, normally.  There were actually some obscure bugs in HTML.c that could
be triggered when ASSUME_LOCAL_CHARSET was explicitly set (now fixed).

> I have unset ASSUME_LOCAL_CHARSET for a long time and have never 
> encountered the problems.

The effective ASSUME_LOCAL_CHARSET defaults to the effective ASSUME_CHARSET
which in turn depends on the explicit setting (from lynx.cfg or command
line flag or 'O'ptions screen) as well as the current CJK/Raw setting.
As long as you are browsing with a Japanese display character set and
CJK "on", there shouldn't be problems (I assume your local files are
in Japanese encoding).  But if you set CJK temporarily "off" (for example
with the '@' toggle), for browsing some non-Japanese sites, there would
be problems when going back and forth between local files and those
remote sites.  For that situation, setting ASSUME_LOCAL_CHARSET explicitly
should help.

Well that's the theory, it may well be that currently ASSUME_LOCAL_CHARSET
doesn't work right for Japanese character sets.  It should work right
though if you replace Japanese by Some-Other-Language/Encoding.
Not-too-unrealistic example: Russian UNIX user on KOI8-R system, with
convention that local files are in KOI8-R, wants to browse remote sites
that are Microsoft-encoded (windows-1251) without proper charset labelling,
so user needs to set Assumed document character set in 'O', but local
files should still be assumed as KOI8-R.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]