From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Pascal Bourguignon Newsgroups: gmane.emacs.help Subject: Re: Why emacs have not native language menu Date: Thu, 26 Jul 2007 17:03:37 +0200 Organization: Informatimago Message-ID: <877ion6wc6.fsf@voyager.informatimago.com> References: <46A49912.9030203@luxdo.jp> <877ioqdoq9.fsf@voyager.informatimago.com> <87hcnuc6hz.fsf@voyager.informatimago.com> <878x95dhne.fsf@voyager.informatimago.com> <52sl7dopel.fsf@googlemail.com> <87vec84075.fsf@kobe.laptop> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1185464438 28598 80.91.229.12 (26 Jul 2007 15:40:38 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 26 Jul 2007 15:40:38 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Jul 26 17:40:37 2007 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IE5S2-0000K9-NF for geh-help-gnu-emacs@m.gmane.org; Thu, 26 Jul 2007 17:40:31 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IE5S2-0003XL-AT for geh-help-gnu-emacs@m.gmane.org; Thu, 26 Jul 2007 11:40:30 -0400 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!news.tele.dk!news.tele.dk!small.news.tele.dk!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 89 Original-X-Trace: individual.net CNmC7joDB/da/3z3i+mD7AmTz69nvcnUjh43NNuzTN88qv8jam Cancel-Lock: sha1:bbKJ5ANGbCX6+SBYS0kY4pXN4SU= sha1:rRE3fTcSSNop5K2pQaF6RpMhxTE= Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAQMAAABtzGvEAAAABlBMVEUAAAD///+l2Z/dAAAA oElEQVR4nK3OsRHCMAwF0O8YQufUNIQRGIAja9CxSA55AxZgFO4coMgYrEDDQZWPIlNAjwq9 033pbOBPtbXuB6PKNBn5gZkhGa86Z4x2wE67O+06WxGD/HCOGR0deY3f9Ijwwt7rNGNf6Oac l/GuZTF1wFGKiYYHKSFAkjIo1b6sCYS1sVmFhhhahKQssRjRT90ITWUk6vvK3RsPGs+M1RuR mV+hO/VvFAAAAABJRU5ErkJggg== X-Accept-Language: fr, es, en X-Disabled: X-No-Archive: no User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.94 (gnu/linux) Original-Xref: shelby.stanford.edu gnu.emacs.help:150516 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:46097 Archived-At: Giorgos Keramidas writes: > On Tue, 24 Jul 2007 16:19:14 +0200, Hadron 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.