Re: A system for localizing documentation strings

[Jean-Christophe Helary]

On 27 juil. 07, at 14:04, Richard Stallman wrote:

>     Because as soon as we have a system that allows for  
> localization we
>     can expect to have "native" code written and so we'll have to
>     reference the source language that _will_ be different from  
> English.
>
> We aim to discourage that.  The primary language of GNU implementation
> is English.  All functions should be documented in English, in  
> addition
> to whatever other languages are supported.
>
> If someone's English doc string is not well written, that's as if the
> code were not well written.  Someone will suggest an improvement.

I am sorry if what I wrote was unclear.

I understand that GNU software is English based, just like the GPL  
license is valid only in English.

I have no specific problem with that.


What I intended to propose was a generic system to localize elisp  
files/elisp systems.

Such a system would directly benefit emacs, of course, since emacs is  
the main provider of elisp code. And since emacs is English based it  
makes perfect sense to provide a system that is backward compatible  
with the current "English only" system.


But the system should not "hardcode" English=default into its  
behavior (ie by not identifying English with a language code etc). It  
is very conceivable that emacs extensions are created for a specific  
"market" that corresponds to a language community and the  
localization mechanism should provide developers with a way to use  
their language as their system's default.

> Jason had it right:
>
>     That is the way it must be for any globally used software.  
> Perhaps as a
>     Frenchman living in Japan you feel that is unfair, but the fact  
> is that
>     English is the most widely understood language there is.

Which assertion do you refer to ?

1) Since emacs started from an English speaking community (as a lot  
of major software packages, like MS Office for example) I suppose the  
practical way to deal with localization does involve starting from  
English. I have nothing against that.

2) As a Frenchman living in Japan and in Japanese, and having a fair  
command of English I don't think it is unfair at all, but in a number  
of cases there are practical considerations that make English  
centered processes a waste of time: some elisp code may be designed  
with a relatively limited scope and technically forcing the use of  
English because elisp=emacs=GNU seems a little far fetched.

3) Such a postulate shows little understanding of what "freedom"  
means, especially in the context of technology. It also shows little  
understanding of the necessity of native language computer literacy  
activities to reach the goals set by the FSF in particular.

Jean-Christophe Helary