lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev proposed revisions for gettext (I)


From: Nelson Henry Eric
Subject: Re: lynx-dev proposed revisions for gettext (I)
Date: Mon, 30 Nov 1998 09:49:47 +0900 (JST)

Before I start on anything, I just want you to know, Jim, that I
appreciate and respect your efforts tremendously.  I'm also grateful to
Tom for working so hard to polish things up.  This whole idea of gettext
and NLS is big!

> I agree half-heartedly.  When that rare message appears, how would a
> non-English speaker deal with it?

I was thinking about words(?) like "WAIS", "gopher", etc., but there may
be other cases.  A non-English speaker probably would have no trouble,
but I will of course run all of my proposals across the list first.
Anyway, Tom and you will have the last say.

> Definitely, except let's not make translator's work obsolete by
> changing dozens of lines for the heck of it.

Do I know about that (I've already hand edited ja.po about three times
:)!  I test all of the changes I make in both English and Japanese, and
try to find a best-for-both solution.  I'm not the type of person who
does things "for the heck of it."

> >        same way so that we can have one "msgid"?  Also, when the
> >        string is found in more than one file, let's make it a define
> >        in LYMessages.
>
> Yes, and no. The tools will automagically merge messages from
> different modules. I disagree with having #defines except as bug
> workarounds.

I agree in principle, but Tom has indicated that he would like to get
Solaris's gettext to work with Lynx.  Not being a programmer I can't say
either way, but for now I really think it would behoove Sun to do some
work to make their implementation more robust.  Anyway since Tom said he
only needs to cut off a few hundred bytes from the command line (what is
that for, xgettext?), so I thought I would at least give it a try.

> Leaving the messages in place may help translators decide the best
> idioms based on context. Seeing the same message in many places would

Only some translators will be able to do this.

> tell me that the *code* could be combined into subroutines (this
> should please you Henry if we shave some more bytes off the source and
> executables :-). I noticed in my work the same code had been

Oh, yes!  Do I feel good when one more line goes into the trash :-)  I'm
the programmer's worst enemy perhaps.

> Since these are outside the code/gettext context, perhaps they could
> by worked independently on by volunteers? I will be happy

I didn't discuss this yet, being a bit swamped at work.  I VERY much
hope that the help files will be kept completely separate from the
statusline prompts and messages in Lynx.  I am particularly unhappy with
how some of the .cfg stuff has crept into the code.  I will be looking
at a lot of those multi-paragraph messages that have been gettexted, and
will try to find a way to have them serviced from the help or doc file
sets.  I'm NOT saying I favor them being thrown away; I'm saying I would
prefer that they be in a text/html file rather than hardcoded in the
source.

Having huge blocks for translation really bogs one down, especially when
it's a spare-time-only job.  Some of the internally created pages CAN be
made less formidable from the translator's point of view.

__Henry

reply via email to

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