Re: i18n/gettext?

[Paul Eggert]

> From: "Eli Zaretskii" <address@hidden>
> Date: Sat, 08 Dec 2001 10:23:04 +0200
> 
> > >  - For that matter, will every one of the *.el files in the standard
> > >    distribution have its own catalog, or do we go with a single huge
> > >    one for the entire Emacs?
> > 
> > A single one.  There's little point to having multiple translation
> > files, and having a single one is simpler for installers.
> 
> OTOH, having separate catalogs means that installing a newer version
> of the same package (in site-lisp, for example) will automatically
> update its translations.

If an *.el file is in the standard distribution, then you should
upgrade it by upgrading your copy of the standard distribution and
then installing your copy of the standard distribution.  If you use
some other method to upgrade, you'll have to know what you're doing.
That's already true (for reasons other than translation catalogs), so
translation catalogs aren't much of an extra burden here.


> > >  - What happens when a package is loaded or autoloaded?  How will its
> > >    catalog be read and added to the data base?
> > 
> > If the package is part of the standard distribution, the catalog will
> > already be in the database.
> 
> This sounds like a disadvantage, doesn't it?  It means memory is used
> for something that Emacs might never need in this particular session
> for this particular user.

Normally the message catalog is mmapped in, so if big chunks aren't
used then they won't be pulled into main memory.  Admittedly this
isn't quite as good as carefully pruning the catalog, but we have
better things to do these days than to carefully prune message
catalogs.

(If I recall correctly, GNU gettext has a 2 GB limit on message
catalog sizes.  Or maybe it's 4 GB.  Either way, eventually it will
have to be increased.  :-)


> > >  - What encoding will we use in the catalogs?
> > 
> > For the English strings to be translated, we use ASCII.  For the
> > translations, it's up to the translator.
> 
> Leaving it up to the translator means that Emacs will have to convert
> the strings at run time.

The cost of conversion should be small, relative to the cost of
everything else Emacs does.  If this really is a problem, I suppose we
can store the translations in Emacs's internal encoding; the simplest
way to do that is to insist to translators that the use Emacs's
internal encoding.  However, I wouldn't bother doing that unless it's
an important performance win.


> Why should it matter to translators what encoding to use for the
> translated strings?  If Emacs can display the text to the user, they
> shouldn't mind, I think.

This assumes that only Emacs is used to edit translation files.  I'd
rather not make that assumption.


> > Assuming we use GNU gettext, the user can choose a different encoding
> > if they prefer; gettext will translate automatically.
> 
> Which means you will have to link against iconv, and bloat Emacs's
> memory footprint.  Since Emacs already has the code-conversion
> machinery, isn't that an unnecessary overhead?

I suppose we could do it in Emacs too, if you like.  I suspect that
we'll eventually need to link against iconv anyway, though, for other
reasons (e.g. efficiency on some platforms).  So I don't think the
memory-footprint argument is a strong one in the long run.


> Since gettext is mostly used in text-mode applications, it is quite
> possible that its code and/or translations assume something about
> the output device, and that some of those assumptions are wrong for
> Emacs; see the examples I mentioned.

Sorry, I still don't follow this.  The output of gettext is plain
text; it's independent of output device.

It's true that translations of short strings might be long strings,
and this might cause layout problems.  But that's a separate issue.
That problem would occur even we limited ourselves to ASCII
(translating English to Hawaiian, say).