From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Fwd: A system for localizing documentation strings Date: Thu, 26 Jul 2007 08:13:32 -0400 Message-ID: References: <795F38F4-7253-47DC-97DD-53BED4F0AB97@mx6.tiki.ne.jp> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: sea.gmane.org 1185451917 13025 80.91.229.12 (26 Jul 2007 12:11:57 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 26 Jul 2007 12:11:57 +0000 (UTC) Cc: emacs-devel@gnu.org To: Jean-Christophe Helary Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 26 14:11:56 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IE2C9-0001aN-Jl for ged-emacs-devel@m.gmane.org; Thu, 26 Jul 2007 14:11:53 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IE2C8-0008VH-R3 for ged-emacs-devel@m.gmane.org; Thu, 26 Jul 2007 08:11:52 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IE2C4-0008QO-RF for emacs-devel@gnu.org; Thu, 26 Jul 2007 08:11:48 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IE2C2-0008HR-4j for emacs-devel@gnu.org; Thu, 26 Jul 2007 08:11:47 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IE2C1-0008Gw-Vf for emacs-devel@gnu.org; Thu, 26 Jul 2007 08:11:46 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IE2C1-0002fa-OF for emacs-devel@gnu.org; Thu, 26 Jul 2007 08:11:45 -0400 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.60) (envelope-from ) id 1IE2Dk-0001Tu-Gx; Thu, 26 Jul 2007 08:13:32 -0400 In-reply-to: (message from Jean-Christophe Helary on Thu, 26 Jul 2007 12:29:19 +0900) X-detected-kernel: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:75561 Archived-At: > From: Jean-Christophe Helary > Date: Thu, 26 Jul 2007 12:29:19 +0900 > > I was told by Eli Zaretskii that such discussions should better take > place here, hence my forward from help-gnu-emacs@gnu.org Thanks. > To offer a practical possibility for interactive localization we'd > need a function that dynamically generates output instead of the > "optional-documentation..." string. This function would take a number > of paired arguments: > > (docfun > source-language-1 source-language-1-documentation-string > source-language-2 source-language-2-documentation-string > etc ...) > > for ex: > > (docfun > EN "optional-documentation in EN..." > FR "documentation optionnelle en FR...") I don't like this implementation idea, because it would require the user to byte-compile Lisp files whenever a translation to another language is added. This would be very inconvenient, especially for *.el files that are preloaded when Emacs is built, because that would mean one must have the sources available nearby, and must run the build procedure and "make install". The latter step requires sysadmin privileges on many platforms, another inconvenience. I think it's much better to have a separate translation file for each .el file. Such a translation file would be loaded on demand when documentation for symbols defined on that file is requested by the user. The translation file needs include only the names of the symbols and their doc strings for supported languages. (We could also have separate translation files for each language, but I think it won't be necessary, as the number of symbols on a single .el file is quite small.) > (transfun function-name > source-language > target-language > reference-function-name ; should be a list > reference-file ; should be a list) > > The function-name declares which function has to be translated > The source-language declares from which language string the source > should be displayed Why do we need the source language? > What we need is provide 1) a way for coders to identify the necessary > strings for the translation 2) a way for translators to add > translated strings "the emacs way" 3) a modification of the display > procedures to take the new strings into account. Your number 3) is not described correctly: it's not the display that needs to be modified, it's the Emacs documentation commands. The documentation commands don't display anything, they just insert the doc text into a buffer, whether *Help* or minibuffer or something else. The Emacs redisplay engine then displays that buffer; however, if the text in the buffer to be displayed is already in French (say), that is what you will see after it is displayed. So what is needed is to modify the documentation commands so that they will look up the translated text and display that text instead of the original English doc string. Also, we should keep in mind that Lisp primitives (those implemented in C) have their doc strings as C comments, not as C strings. The infrastructure developed for Emacs l10n should provide solution for the primitives as well, and the solution will have to be different both from your suggestion above and from the traditional gettext-style message catalog.