From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.help Subject: Re: Emacs localization (Re: Why emacs have not native language menu) Date: Tue, 24 Jul 2007 12:58:26 -0400 Message-ID: References: <46A49912.9030203@luxdo.jp> <7056BAE9-002B-46B7-A60A-9EDE375392EE@mx6.tiki.ne.jp> <18085.18857.593591.502885@kahikatea.snap.net.nz> <1185263310.787881.72970@57g2000hsv.googlegroups.com> <36CC139D-16DC-4D8E-B69A-D16BD3CE385E@mx6.tiki.ne.jp> <46A616A2.8040504@gmail.com> NNTP-Posting-Host: lo.gmane.org X-Trace: sea.gmane.org 1185296227 14302 80.91.229.12 (24 Jul 2007 16:57:07 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 24 Jul 2007 16:57:07 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Jul 24 18:57:05 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 1IDNh3-0001uK-4l for geh-help-gnu-emacs@m.gmane.org; Tue, 24 Jul 2007 18:57:05 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IDNh2-00062h-Ke for geh-help-gnu-emacs@m.gmane.org; Tue, 24 Jul 2007 12:57:04 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IDNgo-00062D-Dd for help-gnu-emacs@gnu.org; Tue, 24 Jul 2007 12:56:50 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IDNgn-000620-KF for help-gnu-emacs@gnu.org; Tue, 24 Jul 2007 12:56:49 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IDNgn-00061x-GW for help-gnu-emacs@gnu.org; Tue, 24 Jul 2007 12:56:49 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IDNgn-0003jR-3X for help-gnu-emacs@gnu.org; Tue, 24 Jul 2007 12:56:49 -0400 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.60) (envelope-from ) id 1IDNiM-0003Nl-Kn for help-gnu-emacs@gnu.org; Tue, 24 Jul 2007 12:58:26 -0400 In-reply-to: <46A616A2.8040504@gmail.com> (lennart.borgman@gmail.com) X-detected-kernel: Linux 2.6, seldom 2.4 (older, 4) 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:45988 Archived-At: > Date: Tue, 24 Jul 2007 17:11:30 +0200 > From: "Lennart Borgman (gmail)" > Cc: help-gnu-emacs@gnu.org > > There are a couple of things to translate: > - manuals > - help texts > - menus > - interactive commands - option names - tooltips - text of messages in the echo area - text of prompts in the minibuffer - text we insert into special-purpose buffers, like Dired and *Help* - text of customization widgets > * The help texts (shown in the help buffer) are the documentation that > are written together with the functions and variables etc, like this: > > (defun find-library (library) > "Find the elisp source of LIBRARY." > ;; body of function comes here > > When this texts are shown in the help buffer they could of course be > replaced with other texts from some table. Rather straight forward too > since not very much need to be changed in Emacs. I disagree. Consider a random example: tty-color-alist is a compiled Lisp function in lisp/term/tty-colors.elc'. (tty-color-alist &optional FRAME) Return an alist of colors supported by FRAME's terminal. FRAME defaults to the selected frame. [back] Notice how FRAME is generated automatically for the argument list, and then repeated in the doc string, where it was typed by a programmer who wrote that function. Note also the auto-generated "back" button. These are all parts of the display, but they originate from different places, some are literal strings, others are generated on the fly. And they all need to look and work together well eventually. As someone who is a TP team leader, I can tell you: this kind of stuff is a translator's nightmare! One of the first things we teach newbie translators is that translating text in pieces is an absolute no-no; you need to see the whole phrase to produce a valid translation. In text-based programs we convince programmers to modify their code so that messages are not constructed a piece at a time; however, such techniques are unimaginable in the Emacs help system without a complete redesign (which no one will dare to undertake). And then there's the sheer size. etc/DOC, the repository of Emacs doc strings, is 2MB, and that's only for built-in symbols (i.e. those defined in C) and packages preloaded at dump time. Add to that packages loaded at run time, and you'll probably get to 10MB of strings that need translating. Loading a message catalog for a single language would thus add several MBs to the footprint of a running session. It's possible to have separate catalogs for each Lisp package, but such a scheme needs to be designed and implemented first. > * menu texts? Ah, I would not even dream of translating them until menus > are defined in a more simple manner. Actually, given the appropriate infrastructure, this isn't as hard as you seem to think: the menu display code just needs to take the English string and look it up in a message catalog. The more fundamental problem is that only recently Emacs got Unicode support in most (if not all) of the GUI toolkits used to build it. But menus whose items are computed dynamically are still a hard problem.