[Top][All Lists]

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

Re: i18n/gettext?

From: Paul Eggert
Subject: Re: i18n/gettext?
Date: Sun, 9 Dec 2001 22:19:12 -0800 (PST)

> Date: Sun, 9 Dec 2001 20:01:24 -0700 (MST)
> From: Richard Stallman <address@hidden>
>     > 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.
> To make that assumption in general, for all GNU programs' translation
> files, might be undesirable, but to make it for Emacs's translation
> files seems acceptable to me.  Why would an Emacs user want to edit
> them with anything else?

They might not want to edit them, but they might want to (say) print
them, without using Emacs.  Or they may want to use 'grep' on them.
If the files use a private Emacs encoding, these other tools won't
work properly.

Here is another argument for letting translators choose the encoding:
translator teams have already chosen encodings, which they use for
lots of other GNU applications.  These choices are often the result of
a delicate balance of technical and political considerations.  If GNU
Emacs is a special case, it will cause confusion among the translation

> What exactly is iconv, and how does it relate to gettext?

iconv translates from one character encoding to another.  For example,
to convert a buffer from Shift-JIS to EUC-JP:

     #include <iconv.h>
     iconv_t conversion_descriptor = iconv_open ("EUC-JP", "SHIFT-JIS");
     size_t chars_converted = iconv (conversion_descriptor,
                                     &inbuf, &insize, &outbuf, &outsize);
     iconv_close (conversion_descriptor);

iconv is becoming the standard way to convert encodings on GNU and on
Unix systems.  It is specified by POSIX 1003.1-2001, which was just
approved last week.  Unfortunately, though, the POSIX standard is
incomplete, as the character encoding names themselves are not

GNU Emacs doesn't use iconv.  I assume this is at least partly because
its code predates iconv.  I suppose Emacs could use iconv's
translation capabilities if available, instead of redoing the
translation itself; this would probably speed up Emacs considerably,
at least on some platforms.  However, this would take some hacking.

With GNU gettext, the character set part of the locale (specified by
the environment variables LC_ALL, LC_CTYPE, etc.) causes gettext to
use iconv to convert the translations in the messages file to the
corresponding encoding.

reply via email to

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