lynx-dev Re: Lynx with GNU gettext NLS support

[Webmaster Jim]

On Sun, Aug 01, 1999 at 08:06:32AM -0500, Klaus Weide wrote:
> On 31 Jul 1999, François Pinard wrote:
> > Webmaster Jim <address@hidden> writes (on 1998-10-29):
> > > We have a French translation file I've been working with, but it will
> > > need disclaimers before it is included in the FSF sites.
> > Hello, Jim.  I'm never sure how I should call you, and am not much fond
> > on using nicknames to address people. :-)
> According to a message he sent to lynx-dev Jim is on vacation, so he
> may not be able to respond immediately.
> (I call him "Jim" and ignore the "Webmaster" in his address, and so far
> he has never complained. :) )

I'm now also responding to "lynx domain " <lynx-po at browser.org>,
which is the address for the coordinator of NLS for Lynx. This is a
long-running thread, so please forgive me if you have seen parts of it.
I am sending it to lynx-dev so that the development group can learn
what's happening with NLS (François: if you could forward this to
the team leaders I would appreciate it. Merci).

Background news -- I posted info about a Russian translation being
available now from the Free Translation Project (aka the project). A
Brazilian Portuguese translation has also been done through the project.
A German translation expanding on Klaus Weide's work is also in the
pipeline, but has not been posted on the project site. The first 2 are
now available on the Lynx http and ftp sites:

http://www.slcc.edu/lynx/po/
ftp://lynx.isc.org/po

Thanks to Rodrigo Stulzer Lopes and Dmitry S. Sivachenko!

For the Free Translation Project repository of Lynx translation files,
see: http://www.iro.umontreal.ca/contrib/po/HTML/domain-lynx.html The
project will maintain the translation files, while for now I will
manually copy them to our distribution sites. A full Lynx package with
the available translation files included will be my next project.

> > The quoted sentence, above, is probably the one that induced me
> > to think that `lynx' was requiring translation disclaimers by the
> > choice of its maintainer. This matter is resolved so far that I
> > know and for now in the Translation Project, Lynx is not requiring
> > translation disclaimers.
> > 
> > Let me try to interpret what I think was the source of the misunderstanding,
> > just as a kind of chat.  [ ... ]
> 
> I don't want to speak for Jim.  but my *impression* (from more or less 
> following the conversations on lynx-dev) is that your interpretation is
> right.

Speaking as Jim, none of the Lynx developers has required that
translation disclaimers be filed. On the contrary.

So we now have 2 "official" language files, and 2 more "unofficial."

> > Webmaster Jim <address@hidden> writes (on 1998-11-02):
> > 
> > > I'm using gettext() rather than _() since the latter gives a warning
> > > under BSD.  I don't consider this a bug, per se.
> > 
> > I never heard about this.  Could someone tell me more, maybe in a some
> > more formal report?  I'm rather curious about the matter.  Warnings are
> > never nice, and ideally, compilation should yield none...
> 
> I don't know about the problem with BSD; I would just like to throw in
> that IMO the lynx code should continue to use gettext() rather than
> _(), especially since that is how things are done now.  (Admittedly,
> one reason for my preference is that I would like to keep _ "reserved"
> for a different purpose - a macro trick for more convenient handling
> of TRACE output as it is done in the latest libwww from W3C - although
> I don't know now what the chances are that this will ever be used in
> the official lynx code.  I have used it in one point in some private
> code that combined some latest-libwww code with lynx.)

Likewise, Lynx will continue to use the gettext() function rather
than the shortcut _().  The reasons are in the lynx-dev archives.

> > > I have not touched the input message handling (i.e., Y/N).
> 
> This isn't true any more for the current code and lynx.pot.
> Generic Yes/No prompts now accept (and require) the first letter
> of the translation of
>    msgid "yes"
> and
>    msgid "no" (but other one-key prompts still require the hardwired
> letters derived from English).  This area should be considered still
> in flux, maybe as an attempt to gain the wisdom we are still
> lacking...  (To make localized lynx act as François suggests [below],
> i.e. not change the recognized keys for Y/N responses, an xx.po file
> could just leave "yes" and "no" untranslated for now.)
> 
> > > Likewise, the help screens and usage() function are not gettext'd.
> > 
> > It is still wise to postpone input handling, we do not collectively have
> > enough wisdom about this yet, in my opinion.  But I do not see why the
> > help screens and usage could not be translated.  Is there any reason?
> 
> Jim can probably better respond to this; I am not sure exactly what he
> meant.  But afaik, 
>  * -help output, and other sets of messages that are implemented as arrays
>    of constant strings (e.g. Key descriptions for 'K'eymap page) are not
>    yet internationalized because
>    * nobody has done it, and
>    * it would require a different approach than the existing gettext()
>      calls (probably either N_("string") in initializers, or gettext(variable)
>      instead of gettext("string").)
>  * "Help" pages are external HTML documents, so translating them is
>    a problem different from i18n / l10n of the program code. 

The Lynx code (2.8.2 and later) has input for yes/no that may be
modified for NLS support as Klaus states. Other inputs are not handled,
such as short menus asking for 'd'ownload. This is on the ToDo list.

Long messages, such as are found in help screens, the usage function,
and other areas are a problem for several reasons. One is that not all
of the printing is done by simple print statements, for example:

LyMain.c
/* NOTE: This table is sorted by name; the lookup relies on that. */
static Parse_Args_Type Arg_Table [] =
{
   PARSE_SET(
      "accept_all_cookies", SET_ARG,        &LYAcceptAllCookies,
      "\naccepts all cookies"
   ),
   PARSE_FUN(
      "anonymous",  FUNCTION_ARG,   anonymous_fun,
      "used to specify the anonymous account"
   ),
...

    Another is our tendency to revise the content of such messages to
improve the readability (at least in English). This action would make
the translated message not be displayed. Also, as Klaus says, no one has
done it. The keymap is also English oriented, for instance:

a           ADD_BOOKMARK  add to your personal bookmark list                    
b           PREV_PAGE     view the previous page of the document                
c           COMMENT       send a comment to the author of the current document
...

The keys were set up mnemonically by English speakers, so modifying
these involves quite a bit of work, including understanding the lynx.cfg
file where the defaults can be modified--

#KEYMAP:a:ADD_BOOKMARK  # Add current document to bookmark list
 
> > Klaus Weide <address@hidden> writes (on 1999-06-23):
> > > I did a German translation, which I'd like to regard as preliminary.  
> > > [...]
> > Erwin Dieterich <address@hidden> writes (on 1996-07-15):
>                                                     ^^^^ YM 1999?
> > > [...] attached you can find a German po-File for lynx.  [...]
> > From the English comments in that PO file, Erwin's work seems to be based
> > on Klaus' previous work, and I presume the transfer of responsibilities
> > was in the agreement of both parties.  However, past experience in the
> > Translation Project taught me how delicate such matters may be, at times.
> I already responded to this in another message to François et.al.;
> there is no problem here from my side.

I still haven't seen this file on the project's site, as mentioned.

The issue of Lynx version numbering was brought up in another message.
We are working on lynx-2.8.3, but the base English message file is from
the 2.8.2 release. Hopefully this won't be too big a problem.

------
<http://www.cs.indiana.edu/picons/db/users/us/md/lib/bcpl/jspath/face.xbm>
<http://www.altavista.com/cgi-bin/query?q=%22web+home+for+jim+spath%22>
Marvin the Paranoid Android says:

You're thinking along the wrong lines, You're failing to take into
account something fairly basic in the relationship between men and
robots.