Re: i18n/gettext?

[Paul Eggert]

> From: Eli Zaretskii <address@hidden>
> Date: Tue, 11 Dec 2001 10:06:59 +0200 (IST)
> 
> Emacs is different: most of its Lisp packages are loaded on demand,

That doesn't matter from the point of view of translations.  Whether a
string needs to be translated is independent of whether a package is
dynamically loaded.

> quite a few are maintained by people whose release schedule is not 
> synchronized with Emacs releases, even for packages that are bundled.

That's OK.  The translation templates will be generated automatically
from whatever source code is bundled.

> Emacs is also much larger than most other packages which use gettext.  

I don't think the size by itself is enough to disqualify a single
catalog.  If we were talking of a translation file containing over 2
GB of data, then we'd need to be concerned about catalog size.  But
it's relatively small compared to that.  I'd be surprised if it's much
more than 1 MB per translation file, for all of Emacs.

We're only talking a few thousand message-IDs here.  That's not small,
but it's not that big either.


> As yet another reason, consider the fact that Lisp files are much easier 
> to modify on the user level than it is with a typical C program.

True, I don't see why this is relevant.  A user who wants to modify a
message string in a bundled Lisp program will need to modify the
corresponding translations to get it to work with other languages.
This work can't be avoided, no matter what method we use.  And this
work is about the same for Lisp as it is for C.

I don't see why packaging the translations in small catalogs,
presumably to be "nearer" the source files, will help the translators
much.  Translators already use tools that let them easily jump back
and forth between source files and translation catalogs, even if
there's just one master catalog in a package with hundreds of source
files.

> I think we should try to make this as modular as reasonably possible.

Yes, but the issue is what is "reasonable".  I think we would all
agree that it's overkill to have a separate translation catalog for
each source string.  I think that having a separate translation
catalog per source file is overkill too.

Your arguments do hold some water, and it may make sense to have more
than one translation catalog for Emacs, but we shouldn't go overboard
and have hundreds of catalogs.  And I'm still somewhat dubious that we
need more than one.  There are some advantages to having more than one
catalog, but there are some real disadvantages too.


> >  Also, different Lisp files within Emacs will often use
> > common strings
> 
> The same problem exists today with many GNU packages: for example,
> they all use getopt, and many of them use GNU regexp....  If we want
> to address this problem, fine; but it isn't specific to Emacs.

The problem can be addressed by copying translations, or (more
methodically) by using translation compendiums.  But this is a hassle,
and it's nice to avoid the hassle if possible.