Re: Emacs i18n

[Eli Zaretskii <eliz@gnu.org>]

> From: Juri Linkov <juri@linkov.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  rms@gnu.org,  emacs-devel@gnu.org
> Date: Tue, 05 Mar 2019 23:58:25 +0200
> 
> One of the main decisions that has to be made is whether to wrap all
> user-facing translatable strings in all Lisp files using a macro/function
> 'gettext'

First, AFAIR the conclusion back when this was discussed was that we
might not need to mark the translatable strings, because almost all of
them should be translatable.  If anything, we might consider marking
strings that do NOT need to be translated, as they are a very small
minority.  Just look at the strings in a typical Emacs source file and
try to find strings that you wouldn't want translated.  Unlike some
other programs, Emacs almost never says something that is not meant to
be read and understood by the user.

Second, I don't understand why we are still talking about 'message'.
Most of the user interaction in Emacs that will benefit the most from
translation is not messages we show in the echo area: Emacs actually
doesn't chatter there too much.  Most of the stuff that IMO is much
more important to have translated are the doc strings.  It's no
coincidence that Emacs has around 5000 calls to 'message', but almost
50000 doc strings, 10 times more than echo-area messages.  So even if
we do decide to attack the 'message' part first, we should consider
the doc strings as well, so that whatever infrastructure we develop
for messages will work for doc strings as well.  And that adds more
issues that the basic design must solve or be capable of solving.

Then there are some seemingly minor technical issues, but I think
Emacs will force us to deal with them up front, because Emacs is so
much different from a typical localized text-mode program.  Some of
the issues that came up in the past:

 . Do we use a separate message catalog for each Lisp package, or a
   single catalog for all of Emacs?  Each alternative has its merits
   and demerits.  For example, if we go with separate catalogs, then
   how do we make the correct bindtextdomain call, given that packages
   call each other?  If we go for a single catalog, how do we support
   installing and loading a new package without exiting Emacs?

 . How to specify which target language to use?  The locale is not
   necessarily correct, e.g., when editing with Tramp.  Also, since
   translating all of Emacs is such a humongous job, it's quite
   possible that some languages will have little or no translations,
   and the respective users might want to use translations for a
   "fallback" language, which they prefer to English.

 . Many user-facing text messages include portions that we generate
   directly from symbol names, which are of course in English.  We
   should have some idea for how to deal with that.