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

Re: [RFR] templates://lynx-cur/{templates}

Atsuhito Kohda wrote:
> Hi, I'm a maintainer of lynx-cur and not sure if I was requested
> to anwer anything but short note.

Really, the more you can say about lynx-cur-wrapper the better; it's
hard to write a good package description when you can't see what
problem it's designed to solve.  It seems to be an elaborate
workaround for inadequate locale support, but the details are hazy.

> Justin B Rye wrote:
>> As far as I can see this package is far more about CJK support than
>> novice users.  For instance, if LANG=ko.EUC-KR, it sets Lynx's
>> CHARACTER_SET option to "euc-kr" and its PREFERRED_LANGUAGE option
>> to "ko,en".  For Japanese users it also checks TERM and COLORTERM to
>> see whether it's running in a fancy terminal, but otherwise that's
>> more or less it. 
>> This might be entitled to claim a position as a general-purpose
>> wrapper configuring "common settings" if only it supported other
>> legacy LANG values like fr.ISO-8859-15 or ru.KOI8 or zh_CN.GBK.  But
>> it doesn't - if LANG doesn't end in UTF-8 then ja* gets euc-jp, ko*
>> gets euc-kr, zh* gets big5 and everybody else gets iso-8859-1!
> You will read the followings in README.Debian;
>     But the current maintainer does not know about this issue so precisely 
>     so please let me know any deficiency if you find.
> I'm willing to refine any deficiency in a wrapper.

The ones I was hinting at there were:
 * Chinese is assigned a CHARACTER_SET value that's really only
	common in zh_TW;
 * Russian is given a lynx-ru.cfg file that enforces the wrong
 * many major languages are not given lynx-XX.cfg files at all
	(see /etc/locale.gen for candidates);
 * post-Sarge Debian packages should default to UTF-8, not legacy
 * even as a legacy characterset, iso-8859-1 is obsolescent - it
	doesn't include the Euro symbol (in iso-8859-15).

>> In fact I've just checked; if I'm on the console (the only situation
>> I can think of where a novice is likely to use Lynx rather than
>> Iceweasel) and LANG is "en-GB.UTF-8", it falls back to using
>> /etc/lynx-cur/lynx.cfg.dflt, which sets CHARACTER_SET=euc-jp and
>> That probably deserves a wave of bugreports, but meanwhile:
> Please visit 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509411

Ah, yes, fixed in Squeeze!  Sorry, I run a Stable desktop.  I did
read the changelog entry, but I didn't recognise that this was the
bug being closed.

Unfortunately closing it this way draws attention to another bug:
the _default_ lynx.cfg sets CHARACTER_SET to iso-8859-1.  It
should have switched to UTF-8 as a default a couple of releases ago.

In fact I don't really understand why you would do this via a
directory full of lynx-XX.cfg files.  Couldn't all this be done more
flexibly within the shellscript?  It just has to split LANG at the
dot, then "exec lynx -language=foo -charset=bar", or whatever.
Better yet, shouldn't Lynx do it automatically, without any need for
a separate wrapperscript in a separate package?  lynx.cfg refers to
a variable LOCALE_CHARSET which sounds as if it was intended to fix
all this, but it's set to FALSE.
JBR	with qualifications in linguistics, experience as a Debian
	sysadmin, and probably no clue about this particular package

Reply to: