Re: Why emacs have not native language menu

[Pascal Bourguignon]

Giorgos Keramidas <keramida@ceid.upatras.gr> writes:

> On Tue, 24 Jul 2007 16:19:14 +0200, Hadron <hadronquark@googlemail.com> wrote:
>> We are talking the command names interfaces and help texts - not the
>> function names. e.g you dont see "find-file-at-point" in the
>> menu. No. You find "Open File" or similar.
>
> But then you have to write the manual for this localized menu,
> and all sorts of problems creep up.  For example it is _very_
> easy to explain to an English-speaking person that `M-x find-file
> RET path RET' is the same as `menu: File | Open ...', and the
> English-speaking person will quickly get used to the term
> `find-file'.  If you describe in an ISO 8859-7 Greek manual that
> the following are equivalent:
>
>     M-x find-file RET διαδρομή RET
>     μενού: Αρχείο | Άνοιγμα ...
>
> which are the localized versions, then it's not as easy to
> remember that the `random' name `find-file' maps easily to the
> Greek text for "Open..." :-(
>
> While I agree that localization *is* useful, it's also my
> understanding that it is not a particularly easy task, nor an
> effort that can always create the same mental `mappings' between
> menu entries, help text, tooltips, keyboard sequences, etc.

While theorically I wouldn't object to the translation of user
interface elements, in practice, and by my experience, I still think
it's not a good idea.  

lisp function:   find-file

emacs command:   find-file      ; on GNU emacs, command names are identical 
                                ; to the name of the function declared 
                                ; interactive. On some other emacs, 
                                ; find-file may give a command named:
                                ; Find File

menu:            File / Open...         ; in English
                 Fichier / Ouvrir...    ; in French
                 Archivos / Abrir...    ; in Spanish
                                        ; etc..

Ok, so the practical problem we have when we translate user interface
elements occurs in these kind of situation:

A French speaking user, using a French localized emacs, ask a support
question to somebody who use a Russian emacs.  The common language of
these two people is German.

Assume the French user doesn't know anything about lisp and English
and obviously Russian, and the Russian doesn't know anything about
French.
 

Well with their localized emacs they're stranded.  They cannot help
each other.  They can try, the Russian will try to translate File/Open
from Russian into German, and the French one will try to translate
from German to French, and the risk of errors in these double
translations is very big.

These situations happen everyday with MacOSX (and I assume
MS-Windows), and there is no way arround it, unless you can tell the
user to open the terminal window and give him commands to type in
"computer english" (unix shell).  Well, there is a way arround it,
it's to have the "support" person to use the same localization as the
supported user. But this increase cost.  You have to pay for
commercial support, that's why it's a good thing for commercial
vendors to localize.  But for free software, when you want to provide
free support on the Internet, or if you want to get expert support on
the Internet, localization will prevent you do interchange it.


If you stop the localization at the level of menus, you could still
indicate the user to type M-x find-file RET.  If you translate also
the command names, you will have to tell him to go to the *scratch*
buffer, and type (find-file "/some/file") C-x C-e.  If you also
translate the lisp language, you've won a battle against the free
software philosophy, totally preventing users to help each others.



-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

ATTENTION: Despite any other listing of product contents found
herein, the consumer is advised that, in actuality, this product
consists of 99.9999999999% empty space.