From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jean-Christophe Helary Newsgroups: gmane.emacs.devel Subject: Summary (Re: A system for localizing documentation strings) Date: Fri, 27 Jul 2007 11:16:31 +0900 Message-ID: References: <795F38F4-7253-47DC-97DD-53BED4F0AB97@mx6.tiki.ne.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1185502619 19100 80.91.229.12 (27 Jul 2007 02:16:59 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 27 Jul 2007 02:16:59 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 27 04:16:57 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 1IEFNu-0006LD-Id for ged-emacs-devel@m.gmane.org; Fri, 27 Jul 2007 04:16:54 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IEFNt-0005pn-Hu for ged-emacs-devel@m.gmane.org; Thu, 26 Jul 2007 22:16:53 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IEFNp-0005mJ-9j for emacs-devel@gnu.org; Thu, 26 Jul 2007 22:16:49 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IEFNn-0005iN-UX for emacs-devel@gnu.org; Thu, 26 Jul 2007 22:16:48 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IEFNn-0005hh-Lf for emacs-devel@gnu.org; Thu, 26 Jul 2007 22:16:47 -0400 Original-Received: from smtp9.tiki.ne.jp ([218.40.30.106]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IEFNm-0000AO-TZ for emacs-devel@gnu.org; Thu, 26 Jul 2007 22:16:47 -0400 Original-Received: from [192.168.11.4] (pl062.nas933.takamatsu.nttpc.ne.jp [210.136.182.62]) (authenticated bits=0) by smtp9.tiki.ne.jp (8.13.8/8.13.8) with ESMTP id l6R2GgE6047539 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 27 Jul 2007 11:16:43 +0900 (JST) (envelope-from fusion@mx6.tiki.ne.jp) In-Reply-To: X-Mailer: Apple Mail (2.752.3) X-detected-kernel: FreeBSD 5.3-5.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:75612 Archived-At: I will try here to make a short summary of the discussions. I'll start with quoting myself (with a modification in the 3rd requirement): > 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 way for users to have the localized strings displayed We have also identified another requirement: 4) a way for other coders to read the code without having unrelated documentation strings coming in the way This 4th requirement is a very valid one, but the implementation proposals (keep English there) seem to not be practical in the end. In fact, I see the 4th requirement as a subset of the 3rd. After all coders are "only" a subgroup of "users". Since the code comes in elisp, to meet the 4th requirement it would "only" be necessary to provide elisp-mode with a specialized "code folding" like function for localized strings, enabled by default. This function would take into account the user preferences (main languages, preferred languages, default language) This suppose that the strings are all inside the code, but a language preference handling function would work just as well for coders if the strings were in a separate file. Regarding the string data, as it is bound to be lisp lists, having them inside or outside the code is not a problem and as long as we find an elegant way to deal with the 4th requirement it is not even relevant to the discussion. Managing the code/strings -wherever they are- would be handled by the 2nd requirement: offer a translation function that properly handles the string lists. It looks like emacs primitives would have to be handled differently, but as is indicated i the manuals, the primitives are unlikely to change very much and it is generally not advised to extend emacs through such primitives. So we can consider strings from primitives an exception to the above requirements and handle them with processes that fit better the C code structure. As far as emacs extensions are concerned, and as long as we keep a strictly elisp perspective, the above requirements should be enough to satisfy any need. Jean-Christophe Helary