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
alphabet;
* 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
charactersets;
* 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
>> PREFERRED_LANGUAGE=ja,en!
>>
>> 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: