Re: Emacs localization (Re: Why emacs have not native language menu)

[Eli Zaretskii]

> Date: Tue, 24 Jul 2007 17:11:30 +0200
> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
> Cc: help-gnu-emacs@gnu.org
> 
> There are a couple of things to translate:
> - manuals
> - help texts
> - menus
> - interactive commands

 - option names
 - tooltips
 - text of messages in the echo area
 - text of prompts in the minibuffer
 - text we insert into special-purpose buffers, like Dired and *Help*
 - text of customization widgets

> * The help texts (shown in the help buffer) are the documentation that 
> are written together with the functions and variables etc, like this:
> 
>    (defun find-library (library)
>       "Find the elisp source of LIBRARY."
>      ;; body of function comes here
> 
> When this texts are shown in the help buffer they could of course be 
> replaced with other texts from some table. Rather straight forward too 
> since not very much need to be changed in Emacs.

I disagree.  Consider a random example:

    tty-color-alist is a compiled Lisp function in lisp/term/tty-colors.elc'.
    (tty-color-alist &optional FRAME)

    Return an alist of colors supported by FRAME's terminal.
    FRAME defaults to the selected frame.

    [back]

Notice how FRAME is generated automatically for the argument list,
and then repeated in the doc string, where it was typed by a
programmer who wrote that function.  Note also the auto-generated
"back" button.  These are all parts of the display, but they originate
from different places, some are literal strings, others are generated
on the fly.  And they all need to look and work together well
eventually.  As someone who is a TP team leader, I can tell you: this
kind of stuff is a translator's nightmare!  One of the first things we
teach newbie translators is that translating text in pieces is an
absolute no-no; you need to see the whole phrase to produce a valid
translation.  In text-based programs we convince programmers to modify
their code so that messages are not constructed a piece at a time;
however, such techniques are unimaginable in the Emacs help system
without a complete redesign (which no one will dare to undertake).

And then there's the sheer size.  etc/DOC, the repository of Emacs doc
strings, is 2MB, and that's only for built-in symbols (i.e. those
defined in C) and packages preloaded at dump time.  Add to that
packages loaded at run time, and you'll probably get to 10MB of
strings that need translating.  Loading a message catalog for a single
language would thus add several MBs to the footprint of a running
session.  It's possible to have separate catalogs for each Lisp
package, but such a scheme needs to be designed and implemented
first.

> * menu texts? Ah, I would not even dream of translating them until menus 
> are defined in a more simple manner.

Actually, given the appropriate infrastructure, this isn't as hard as
you seem to think: the menu display code just needs to take the
English string and look it up in a message catalog.  The more
fundamental problem is that only recently Emacs got Unicode support in
most (if not all) of the GUI toolkits used to build it.

But menus whose items are computed dynamically are still a hard
problem.