> > be made, i.e., strings will have to rewritten to be more inclusive, but of
> > course not to the point that they become ambiguous.
>
> Strings should contain whole sentences or messages as far as possible,
> not sentence parts. (I don't see how that would leed to ambiguity.)
I meant combining similar strings. They would be complete sentences, just
more general in meaning. I was referring specifically to this kind of
situation, quoting from your Wed, 23 Feb 2000 14:50:36 -0600 (CST) message:
|| > msgid "Out of memory reading jump file!"
|| > msgid "Out of memory reading jump table!"
|| > msgid "Memory exhausted! Aborting..."
|| > msgid "Memory exhausted! Program aborted!"
||
|| The difference between (3) and (4) may not be useful, although it seems
|| that at one point it was supposed to convey a different meaning.
|| I still find it useful to know that it's a jump file that causes a problem,
> Did you complain at the point when the messages were changed?
No. Only when I noticed them. Quite easily a few months lag. Yes, it's
my fault.
> Just make it clear that a translator doesn't have to translate everything,
I would go along with this wholeheartedly, but where do we do it. Needs
to go into the lynx.pot file -- but I am of the opinion that anyone
actively working on a translation should make his own catalogue fresh using
the specific breakout he is translating for, and using his own gettext tools.
> These are mostly strings that appear in antiquated protocol modules;
> just leave them untranslated if you want to, or provide the English
Of course I know to do that, but what about the guy who says wouldn't it
be nice to have a Vietnamese translation. This guy's native language isn't
Vietnamese, but he loves the people and their language. Then he looks at
the size of the file, and decides to go have a beer instead, or translates
10 strings that contain WAIS in them before realizing he's never heard of
WAIS. Anyway, what I said were just reflections I had on the subject of
recruiting more translations. No big deal.
__Henry
