Re: Emacs i18n

[Alexandre Garreau]

Le samedi 17 juillet 2021, 16:01:11 CEST Eli Zaretskii a écrit :
> > From: mrf <joinlaw@cock.li>
> > Cc: help-gnu-emacs@gnu.org
> > Date: Sat, 17 Jul 2021 16:32:08 +0300
> > 
> > Is UI Strings in C code fully translatable
> 
> No.  But those are indeed the minority; the vast majority is in Lisp.
> 
> > Do you talk about elisp part of code when you say It is limited?
> 
> It doesn't matter.  What does matter is that the echo-area messages,
> whether they come from C or Lisp, are a small part of the text that
> Emacs presents to the user as part of the UI.  We have special buffers
> (like *Help* and *Apropos*) where we show information which won't fit
> the echo-area, we have menus and dialogs, we have tooltips, etc. etc.
> The names of commands and user options are all in English, and those
> names have mnemonic value.
> 
> Let's face it: the classic i10n framework doesn't really work for a
> program such as Emacs, which interacts with users via so many
> different means.

Translating emacs would require to translate many identifiers, it would 
actually amount to translate a programming language, which has very rarely 
been done.  It usually only has been done through keyword, and translation 
of standard library, and mostly for education purposes, while any other 
use than educational is weirdly considered to be “professional” (while 
education wouldn’t?) hence to enables international collaboration, hence 
english.

I once heard from a friend called Jean-Philippe de Mengual aka Texou that 
he wanted to translate emacs but couldn’t because he rightfully heard that 
would mean translate commands and identifiers and programs, etc. 

It was a pity because he often runs a lot of accessibility-oriented work 
especially about blindness (as he’s blind too), and emacs through 
emacspeak is well reknown as a wonderful vocal desktop (it wouldn’t 
surprise me that it would be the most efficient and useful vocal interface 
in the world).  This is likely to amount to emacs’ extensibility, which 
enables to freely, and without permission nor (to a limited extent) 
coordination, implement new paradigms, such as advice-oriented programming 
(which emacspeak ubiquitously use, so that it keeps working while 
modifying almost all emacs behavior, while staying in sync with mainline 
emacs).

Emacspeak is sort of wonderful and sooo complete I guess because of 
dogfeeding, its dev uses it for everything… but dogfeeding has its limits, 
and afaik he’s amero-indian, so english is his native language… and indeed 
emacspeak is most likely the best UI for english-speaking people… as is 
emacs.

It is no new that english, on par (or even more) than technical skills, is 
a great bareer to user-friendliness of a program.  So if emacs could be 
translated, it could gain a loooot more users… on the other side, that 
would break compatibility between many user extensions which would be 
divided between them because of language bareer…  But what evolution 
theory teaches is that more barieer also means more diversity, more 
mutations, hence more ideas.  Plus that would represent programs written 
by non-english-speakers, that wouldn’t have been written at all otherwise, 
so no loss.

But the greatest and first difficulty is that emacs is big and fast, so it 
should be done progressively, from the low level up, so APIs should be 
clearly divided, and modular… while emacs lisp still lacks any proper 
namespace system u.u

Another further difficulty is that not only translation is hard, but it is 
also somewhat contextual… sometimes, in a .po file, you need to go back to 
the source to see the context (and sometimes even run the program! to see 
the context of use) to understand how to translate… unfortunately, 
translating a program would require to understand even more context!  So 
it would need a special UI to fully see the original program while 
translating, otherwise it would be a mess, because any inconsistent 
translation would imply a bug

A special would be even more needed so you only translate strings/
identifiers at their definition.  So that when low-level API X and Y has 
been translated, some high-level API Z that would use X and Y would 
already have its “working” translated, and what would need to be 
translated would only be new defined identifiers: first and foremost 
“exported” ones (first prompts, menu bars, commands, docstrings) and then 
the “less useful”, “secondary”, “required to hack” stuff (internal 
functions, variable names, etc.).

This has never been done anywhere, but I can see how the first place where 
that would be really needed would be emacs, and the place where it would 
be the easiest to implement would also be emacs.  And if emacs succeed, it 
would either be very difficult elsewhere and thus emacs (maybe other lisps 
in general) would have a significant advantage, either it would spread from 
emacs and gives emacs hackability great advertisement.