Re: A system for localizing documentation strings

[Eli Zaretskii]

> From: Jean-Christophe Helary <address@hidden>
> Date: Fri, 27 Jul 2007 00:42:56 +0900
> 
> The fact that the code (.el) will only contain the English string  
> defeats one of the purposes of the localization.

The code is read by programmers, and programmers know English well
enough to cope with that.  More about this later.

> If I read code and I need to check a separate file all the time to  
> see what the French says then I loose a huge amount of time.

I suspect that ``huge amount of time'' is quite an exaggeration.

> I think (but I may be wrong) that you consider anything that is not  
> English as "translations" and English as a gold standard.
> 
> It is important to _not_ think that way to be able to offer the most  
> flexible framework possible.

FWIW, I don't think being dogmatic about these issues will help.  My
considerations are pragmatic: what I suggested is a smaller change,
both in the Emacs infrastructure and in the code.  If we keep adding
requirements that are not necessary to get this feature off the
ground, things will never change for the better, IMO.

So we will have to disagree.  The differing opinions are clear to the
readers, so they can make up their minds; it's no use to continue
reiterating the same arguments time and again.  Eventually, whoever
steps forward to do the actual work will decide on the design and
implementation that he/she likes best, because those who do the job
get to choose the tools and methods.

> The "literate programming" style that elisp/emacs has adopted  
> _requires_ to be language agnostic as much as possible.

Richard will tell for sure, but IMO, Emacs does not try to use the
literate programming paradigm.  A doc string is not documentation of
the code, it is documentation of the _interface_.

What Emacs did, in my view, is provide a way to keep user-level
documentation (user-level, not programmer-level) together with the
code, and provide means for presenting that documentation given the
symbol name.  There are other projects that do similar things (e.g.,
GDB), and they are nowhere near literate programming, either.

> Here again, you see the process as an English based process.

Yes, but only because it's convenient and more practical.

> The fact that the "main" emacs is centered on English _currently_  
> does not say anything about the state of the code in 10 years from now.

Does the fact that we two (and then some), both of us non-native
English speakers, discuss this issue in English -- does this fact tell
you something?  Or do you expect us to converse in Japanese 10 years
from now?  (My Japanese, as Handa-san can witness, is currently
limited to reading Katakana and Hiragana -- but no Kanji! -- at a rate
of 1 word/minute using a dictionary where Japanese words are
transliterated using Latin letters.)

Let's face it: for programmers, English is the most close to the ideal
of the universal language.