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

[Klaus Weide]

On Wed, 18 Nov 1998, Nelson Henry Eric wrote:

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

Well, I haven't even looked at the dev.n code yet; but since there aren't
many alternatives AFAIK, and gettext seems to be the GNU way, in principle
I'm all for it.  I just prefer to look at other things now, and leave the
gettext stuff to those already more familiar with it.  As long as I don't
introduce or change user-visible strings, there shouldn't be a problem,
right?
 
> PS  I haven't said it yet, but a hearty `Welcome back'!

Thank you, and the others.

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

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

What were those problems?  Does anyone remember, or would I find them
in the archives?

If the problem was only that it was too restrictive with respect to length,
that could be easily changed by bumping up that number, but I somehow
doubt that that was the only problem.

Are you asking for the other HTmmdecode() because it also treated 
non-Japanese strings, or for some other reason?

How does the current Lynx show that Subject line?

   Klaus