emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: character sets as they relate to “Raw” string literals for elisp


From: Richard Stallman
Subject: Re: character sets as they relate to “Raw” string literals for elisp
Date: Tue, 05 Oct 2021 17:20:40 -0400

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Suppose this hypothetical contribution were a language mode for a
  > Japanese programming language, and thus had the same support profile?

I have to guess what a "Japanese programming language" would mean, but
I think you're talking about a mode for editing programs written in a
language whose symbols are meaningful in Japanese and perhaps written
in kana and kanji.

If so, this is a different issue from the one I thought we were
talking about.  What I said is that a GNU program must be written in
English, including its symbol names and comments.

The reason to require writing GNU programs in English is so that the
program can be clear to many programmers in every country in the
world.  In every country, a substantial fraction of programmers can
read English.  No other human language comes close.

We could conceivsably add to Emacs a library which implements a mode
to edit a "Japanese programming language", but its symbols and
comments should be written in English.  And we would need the comments
to explain in English what it does and how it works.  That would
follow our rules.

We could conceivably add such a program to Emacs, but should we?  I
think it is not worth the trouble; I'd say, let's not.

You can write and destribute the program, and people could run it.
But we should not distribute programs we can't read.

  > I think that if I read between the lines, you are saying that the Emacs
  > project _could_ grow to become multi–lingual at all levels, with a
  > sufficient number of invested contributors who could each review and
  > maintain different parts of the code.

It would be an enormous effort -- just consider translating the
manuals.  And updating the translations for each Emacs version.  It
would be a big burden.  We should urge volunteers to work on
other areas of improvement

What might be worth doing is to implement multilingual output
messages.  Many GNU packages support that, and Emacs could too.  With
GNU gettext, the program's developers don't need to get involved in
the translation, so it would not be a burden on us.

The hard part of this is to develop a way for Emacs to use gettext
and support translations of non-preloaded libraries.  This would
require gettext to be extensible in a new way.  But I am sure that
can be done, with some work.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]