[Top][All Lists]

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

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

From: Webmaster Jim
Subject: Re: lynx-dev proposed revisions for gettext (I)
Date: Sat, 28 Nov 1998 11:57:46 -0500

On Sat, Nov 28, 1998 at 11:09:14PM +0900, Nelson Henry Eric wrote:
> In the weeks (months?) to come, I hope to go through all of the
> gettext calls and look at:
>       1) Does this string really need to be translated?  Might
>          it better convey its meaning in the original English?
>          Is it worth being translated (especially when there is
>          only one or two calls in the whole file).

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

>       2) How is the English itself?  Is the meaning clear?  Is
>          there a more economical way to say it?

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

>       3) Could similar strings be simply stated in exactly the
>          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.
Leaving the messages in place may help translators decide the best
idioms based on context. Seeing the same message in many places would
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
cut-and-pasted in some modules (some of this was seen by others and
cleaned up during my work).

>       4) Has this string been cut or divided in such a way that
>          English syntax is being forced, i.e., does the translator
>          have enough working room?

At the risk of repeating myself, there are some messages with embedded
strings or numbers that may need re-work to be more language-independent
(see the CSuite notes in the file). Multi-line messages that
include formatted in them should be easy to find for revision

In addition to the INSTALLATION notes that Henry has modified,
I am interested in having the help pages be multi-lingual.
Since these are outside the code/gettext context, perhaps they
could by worked independently on by volunteers? I will be happy
to install them at SLCC. Suggestions for URL template (e.g.,

Marvin the Paranoid Android says:
I just thought I'd warn you - this will be a waste of time.

reply via email to

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