Re: lynx-dev strange interaction with gettext/anonymous/gz

[Nelson Henry Eric]

> > Just hitting the `=' key to get the info page will lock up the
> > keyboard except for ctrl codes when the environment variable is
> > set to LANG=japanese AND the user is in a captive account.  The
[...]
> I just visited your machine and saw the same thing... (also the lockups).

Apologies, everyone.  It was a very stupid oversight on my part.  I
had the new user "jlynx" sharing its $HOME with "lynx", but it was
not the owner.  The problem has nothing to do any of the conditions
mentioned in the subject.  The problem does NOT occur with LANG=ja
and anonymous, now that the permissions on the $HOME directory are
correct.  VERY sorry.
 
I was hoping to get an automatic switching of the languages at login.
Now the wrapper prompts for which of the two supported languages is
desired.  Anyway, those who want to get a feel for NLS are free to
test it out.  (Please avoid Wed and Fri afternoons, JST, however.)

> Unfortunately I don't know anything about gettext.

There wasn't really enough discussion on the pros and cons of going
to gettext.  In order to do it right, i.e., translaters will be able
to *simply* run xgettext to get a correct template to do the translations
on, will make it a must that at least some of the Lynx developers have
a fairly good knowledge of the gettext mechanism.  I fear the burden on
the programmers is going to be a pretty heavy, at least in the initial
stages.  For the non-programmer to be able to maintain the translation
part, without unwittingly introducing bugs of the type already mentioned
by Claude, will require that the programmer know how to efficiently use
keywords and comments, which xgettext, and subsequently, msgfmt know about.

__Henry

PS  I haven't said it yet, but a hearty `Welcome back'!

    Are you interested in reinstating your general HTmmdecode()?  I
    THINK the problem with it as far as Japanese was that you interpreted
    the allowed length of the string differently than from standard
    practice.  Although the number of characters between a =?iso-,=?= pair
    may be limited, the number of these delineated strings is not.  A
    real world example from a recent post to a jp news group:

Subject: =?ISO-2022-JP?B?GyRCPCslNSE8JVAbKEI=?=  
=?ISO-2022-JP?B?GyRCN1BNMyRHQj4lVyVtJVElJCVAJE4lYSE8JWsbKEI=?=  
=?ISO-2022-JP?B?GyRCPHU/LhsoQg==?=  

    Y. Sato's routines (at least recent ones, possibly not the ones in
    Lynx) will translate all three strings into the locale charset (euc-jp)
    and then concatenate them (of course you cannot see it as I do):

" $B<+%5!<%P7PM3$GB>address@hidden<%k<u?.(J "
 
    Individually they are:

Subject: =?ISO-2022-JP?B?GyRCPCslNSE8JVAbKEI=?=
X-Subject-EUC:  $B<+%5!<%P(J
Subject: =?ISO-2022-JP?B?GyRCN1BNMyRHQj4lVyVtJVElJCVAJE4lYSE8JWsbKEI=?=
X-Subject-EUC:  $B7PM3$GB>address@hidden<%k(J
Subject: =?ISO-2022-JP?B?GyRCPHU/LhsoQg==?=
X-Subject-EUC:  $B<u?.(J

This is in reference to CHANGES (1997-12-13)
* Restored the v2.7.1 HTmmdecode() that's specific for iso-2022-jp in
  HTMIME.c.  We still only call it when HTCJK == JAPANESE, and the
  generalized version reportedly has problems. - FM