bug-gnulib
[Top][All Lists]
Advanced

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

[Bug-gnulib] Re: version-etc, AUTHORS, WRITTEN_BY


From: Paul Eggert
Subject: [Bug-gnulib] Re: version-etc, AUTHORS, WRITTEN_BY
Date: 01 Oct 2003 16:05:29 -0700
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3

Jim Meyering <address@hidden> writes:

> You did mention that some names would need to be translated,
> like that of Fran├žois, but can't we just do this?
> 
>   #define AUTHORS _("F. Pinard"), "Whoever Else"

Yes, that should work.  I suspect, though, that you'd want to wrap all
author names that way, in general.  For example, in some East Asian
languages they may want to translate English names into kana.  Or
perhaps they just want to use double-width Latin letters.  Or whatever.
It's easier just to translate them all.

My main worry here is that author's names will have to be translated
differently in different contexts, and that by removing the context
we're making translation harder.

For example, suppose the proper translation for "Written by Paul
Eggert." is

Eggert Paul-er do desu ka.

where "Eggert Paul-er" is the translation of "Paul Eggert", and the
"-er" suffix differs for different names.  When the translator sees
the msgid _("Paul Eggert"), he or she will have to know what context
it appears in.  This is a bit of a pain.

Now, suppose we want to use these names later, in a similar module
(say) to disclaim warranties.  And suppose the proper translation for
"Paul Eggert disclaims all warranty." is this:

Eggert Paul warrantier flughaven.

without the "-er" suffix.  Then we can't use _("Paul Eggert") for both
purposes.  So we'll have to tell translators that _("Paul Eggert") is
going to be used only in the context of a "Written by" sentence, and
we'll have to use some other technique in the warranty-disclaimer
sentence.

But the easiest way to do _that_ is to have people translate "Written
by Paul Eggert." and "Paul Eggert disclaims all warranty." as separate
msgids.  This gives translators context in both cases, and it avoids
these complicating issues.

> Nobody mentioned code size

I'm not worried about that either.  I merely think the current
proposal is over-engineering that in the long run will hassle
developers and translators more than the simple approach would.

> I thought there was an edict (legal reasons?) saying that we should not
> mark that string for translation.

Yes, sorry, my mistake.


Has anybody asked the translators about this issue?  Their views
should count some, I'd think.  Perhaps I'm wrong, but I suspect that
translators would prefer translating whole sentences to translating
bits and pieces.




reply via email to

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