lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev Re: Lynx with GNU gettext NLS support


From: Henry Nelson
Subject: Re: lynx-dev Re: Lynx with GNU gettext NLS support
Date: Tue, 10 Aug 1999 11:34:39 +0900 (JST)

> 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

Does this mean we can finally dump the /po subdirectory from the
distribution?

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

How does Lynx handle the msgid "yes" msgstr "????" pair?  About all
you can do is ^C, AFAICS.  There needs to be a warning to people doing
translations involving multi-byte characters.  Better yet is to back
this code out as I pleaded before.  It should not be assumed that
translaters know anything at all about c coding.

> > letters derived from English).  This area should be considered still
> > in flux, maybe as an attempt to gain the wisdom we are still
[...]
> > > 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
[...]
> 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.

I will express my opinion once again as strongly as I can that input
keys should NOT be NLSized.  Having "the first letter of the translation
of" the command be the input key means that virtually any key would
unpredictably do anything.  It would make debugging an absolute nightmare.
It would make giving simple instructions impossible.  Since lynx_help/
keystrokes/keystroke_help.html is not coupled to gettext(), and I sure hope
it stays that way, there is no guarantee that the description of the
keystrokes would match the action.  It's probably harder to get translators
to agree on a translation than it is for programmers to agree on an algorithm.
What is planned for multi-byte characters?

What's wrong with having a common base to work from?  Everyone and
their brother knows that the beauty of using key input is that it
becomes automatic, the muscles and the *concept* get tied together,
no thinking or reading is necessary -- no language is necessary.

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

No problem at all, but translators need to be informed that they should
create a lynx.pot file fresh from the latest development version of the
distribution _using the gettext tools installed on their system_.

__Henry

reply via email to

[Prev in Thread] Current Thread [Next in Thread]