emacs-devel
[Top][All Lists]
Advanced

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

Re: i18n/gettext?


From: Paul Eggert
Subject: Re: i18n/gettext?
Date: Fri, 7 Dec 2001 11:30:41 -0800 (PST)

> From: "Eli Zaretskii" <address@hidden>
> Date: Fri, 07 Dec 2001 10:33:51 +0200
> 
>  - What will we do with packages which aren't distributed with
>    Emacs?  Do we require them to come with their own separate message
>    catalogs?

Yes.  That's the only sane way.  We can't maintain their catalogs for them.
We should specify where they should install their catalogs, though.


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


>  - 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.  If not, then see the first point above.


>  - 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.  I expect that translators
will typically choose an external encoding that is popular for their
language; in Japanese, for example, I'd normally expect EUC-JP though
I wouldn't be surprised if some translators choose SJIS.  (I _would_
be surprised if a Japanese translator chose Unicode right now.)

Assuming we use GNU gettext, the user can choose a different encoding
if they prefer; gettext will translate automatically.


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


>  - We need to think about some machinery to take care of too-long
>    translated strings which overflow fixed resources.

Yes, that is a real problem.



reply via email to

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