Re: i18n/gettext?

[Eli Zaretskii]

> From: Paul Eggert <address@hidden>
> Date: Fri, 7 Dec 2001 11:30:41 -0800 (PST)
> 
> >  - 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.  It also avoids the lack of symmetry, as far
as translations are concerned, between bundled and unbundled Lisp
packages.  Special cases are a nuisance to program for.

> >  - 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.  (I assume here that some part of the
catalog gets loaded into Emacs, but perhaps that is not true, in
which case this is a moot point.)

> >  - What encoding will we use in the catalogs?  Do we use emacs-mule
> >    (or the future Unicode-based internal representation), or do we
> >    use one of the external encodings (a.k.a. coding systems)?
> 
> 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.  This is a cost we probably will want to
avoid.

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.

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

> >  - Some complications will raise their ugly heads because Emacs itself
> >    takes care of the display of non-ASCII characters
> 
> Yes, but this is an orthogonal issue, isn't it?  Emacs has the same
> problem with characters that come from a file.

It's not clear to me that this is the case.  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.  In particular, "emacs -batch" works differently, so the
display of translated messages will have to work for both -batch and
interactive operation, which might mean some conflicts.