help-gnu-emacs
[Top][All Lists]
Advanced

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

Re: Why emacs have not native language menu


From: Jean-Christophe Helary
Subject: Re: Why emacs have not native language menu
Date: Fri, 27 Jul 2007 20:52:50 +0900


On 27 juil. 07, at 19:47, Eli Zaretskii wrote:

From: Jean-Christophe Helary <address@hidden>
Date: Fri, 27 Jul 2007 09:23:45 +0900

I sincerely think the emacs documentation (manual, elisp reference,
elist introduction) is verbose. I think the structure is not explicit
enough. I think they don't provide an easy access to information.

You will have to back this up with explicit examples (more than one
for each category, preferably), to convince the maintainers to treat
these assertions seriously.  (The emacs-devel list is the right place
to post the examples and for any serious discussion of problems with
the Emacs documentation.)

I did not intend to discuss the issues because I have no solution to propose, but you asked me what I thought about the manuals and I replied.

There is a lot of talk about the necessity of learning English to be a programmer etc but the thing is that the utter mass of the thing and the way it is visually displayed does not facilitates reading _especially_ for non natives (and I am strictly writing from this point of view).

As for easy access to information (assuming I understood what you
mean), the index search command (`i' in Info mode) normally gets me to
the right place very quickly and efficiently.

I work with OSX and I have yet to find how to set the dictionary for the spell-buffer function. The code (not the manual) says that it is an interface to the UNIX spell program. "man spell" on OSX does not give anything, on the web I find that spell is mapped to ispell, but for some reason the dictionary spell uses in emacs is different from the dictionary set for ispell... The manual itself does not mention spell-buffer at all.

I think the real problem is that no one stepped forward and
volunteered.  It's true that the core maintainers generally have a
good command of English, and have too much on their plate to make this
their first priority, but that would not prevent them from welcoming
any work on localization--witness the proliferation of translations of
the tutorial and reference cards between Emacs 21.x and 22.1.

Considering that the last serious exchange on localization dates back from 2001 and that a number of the participants now are either of the "we don't need localization/localization is dangerous" type or of the "we don't need elisp for that let's use gettext" type I don't really wonder why things have not progressed in 6 years.

Emacs is a project run by volunteers on their free time, so features
that get implemented are those for which interested individuals have
enough motivation to sit down and code them.  There are other
important features that Emacs doesn't have because no one volunteered;
it is really silly to accuse the maintainers of being not interested
in all of them.

I am not accusing anybody. I am myself spending a lot of time on a free software by writing documentation and handling user support in a number of languages and I know _exactly_ what you are saying. But not being a coder myself the only thing I can do is suggest ways from experience as a translator who does that for a living and as a localization community participant and organizer.

It makes it difficult for translators to have their work advertised
properly (even though there are links to some translations), it makes
updating the translation a fantastic endeavor.

I don't understand what difficulties you have in mind.  It's not like
the Emacs maintainers are actively interfering with adding links or
advertisement.

Practically speaking it is difficult to translate a manual that refers to menu items and messages in a language that is different from the language used in the manual. That sometimes requires a lot of extra explanations. This is why most of the successfully localized software packages are localized from the ground up. Even though that looks like a more daunting tasks it is in fact much easier and straightforward.


Jean-Christophe Helary





reply via email to

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