lynx-dev
[Top][All Lists]
Advanced

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

lynx-dev message catalogs (was: corrections (minor))


From: Klaus Weide
Subject: lynx-dev message catalogs (was: corrections (minor))
Date: Sat, 1 Apr 2000 16:37:41 -0600 (CST)

On Sat, 1 Apr 2000, Henry Nelson wrote:
> > > 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,

I don't think there are many similar-enough-to-be-unified-but-not-identical
strings.  In any case, unifying them won't affect the size of the message
catalog noticeably.

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

Educating message translators about what they can/can't/should/shouldn't
do isn't really a lynx-specific problem.  This should probably better
discussed within the Translation Project.  (Not that I mind any
discussion here, but I think it doesn't reach the right people.)

> Needs to go into the lynx.pot file  --

Do you find the
  /*  NOTE TO TRANSLATORS: ...
text preserved in your lynx.pot file?  If yes, it shows that there is
a way to automatically get some comments into that file.

So, you could make a patch to get any advice you have in mind into the
hands of all future translators...

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

... and then comes back and attacks the problem with more vigour :) ...

> or translates
> 10 strings that contain WAIS in them before realizing he's never heard of
> WAIS.  

Well, some common sense is expected.  I'd expect that hypothetical
person to at least browse through the file once, and find something
that he *can* understand and translate.  If he's a lynx user (and it's
unlikely he'll want to translate messages otherwise), he'll encounter
messages that he has seen when using lynx.

> Anyway, what I said were just reflections I had on the subject of
> recruiting more translations.  No big deal.

Lynx _is_ a big project, at least when it comes to the size of the
message catalogs (compare with sizes of other programs that the Free
Translation Project keeps track off).  Nothing we do will change that
significantly, and we shouldn't try to change that significantly
anyway, IMO - it's a _good thing_ that it has been internationalised
as much as it has.  And that isn't quite complete yet - whenever it
becomes more complete, there will be still more strings to translate.
Compared to the overall size, I don't yhink that getting rid of a
few messages is very important (but of course you can attack that
problem anyway if you want to).

  Klaus


reply via email to

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