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: Re: A system for localizing documentation strings Date: Fri, 27 Jul 2007 00:42:56 +0900 Message-ID: <3109E7EB-E5E2-49D2-988E-C919334945C1@mx6.tiki.ne.jp> 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 1185464609 29198 80.91.229.12 (26 Jul 2007 15:43:29 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 26 Jul 2007 15:43:29 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 26 17:43:28 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 1IE5Uo-0001Sw-3N for ged-emacs-devel@m.gmane.org; Thu, 26 Jul 2007 17:43:22 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IE5Un-0000AT-B8 for ged-emacs-devel@m.gmane.org; Thu, 26 Jul 2007 11:43:21 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IE5Uk-00009J-BD for emacs-devel@gnu.org; Thu, 26 Jul 2007 11:43:18 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IE5Uj-00008m-Kw for emacs-devel@gnu.org; Thu, 26 Jul 2007 11:43:17 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IE5Uj-00008j-EE for emacs-devel@gnu.org; Thu, 26 Jul 2007 11:43:17 -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 1IE5Uh-0004bs-9p for emacs-devel@gnu.org; Thu, 26 Jul 2007 11:43:17 -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 l6QFh723035041 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 27 Jul 2007 00:43:08 +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:75581 Archived-At: On 27 juil. 07, at 00:10, Eli Zaretskii wrote: > It's not that simple, because in practice many .el files that come > with Emacs are maintained by people who also offer the last version > from some Web site. So in practice, I think we do need to have the > translations on separate files even for bundled packages. And since > you agree that this should be supported anyway, for the benefit of > unbundled packages, there's no reason not to use this infrastructure > for bundled ones as well. There are only advantages to this, I don't > see any disadvantages. The fact that the code (.el) will only contain the English string defeats one of the purposes of the localization. If I read code and I need to check a separate file all the time to see what the French says then I loose a huge amount of time. I think (but I may be wrong) that you consider anything that is not English as "translations" and English as a gold standard. It is important to _not_ think that way to be able to offer the most flexible framework possible. The "literate programming" style that elisp/emacs has adopted _requires_ to be language agnostic as much as possible. >>> Why do we need the source language? >> >> Because as soon as we have a system that allows for localization we >> can expect to have "native" code written and so we'll have to >> reference the source language that _will_ be different from English. >> We don't want people who don't master English to produce weird >> English in their descriptions because the system implies >> source=English. > > I don't see a problem. Programmers who don't master English can > supply the documentation in their native language, and someone else > will provide the English equivalent to be installed in the .el file > before it is installed; after, all most maintainers who have write > access to the repository have good command of English. The original > (non-English) documentation gets installed as one of the translated > messages. Here again, you see the process as an English based process. If we are to provide a localization+translation framework we need to identify all the languages (including English and its different dialects if necessary, that is ISO 639) to provide the most flexibility possible. In fact, the biggest mistake of gettext and similar l10n processes was to imply that English was to be the gold standard of documentation from which everything should be translated. Massive l10n activities around the free world have proved that this paradigm was overly limiting and recent developments of gettext seem to include the possibility to have other languages in source. The fact that the "main" emacs is centered on English _currently_ does not say anything about the state of the code in 10 years from now. >>> 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. >> >> Could that part be concieved separatly ? > > It will be a separate solution, but it needs to be designed and > implemented together with the one for *.el files, since it doesn't > make sense to have a localized Emacs where all the primitives are > still documented only in English. I see. Thank you for your comments. Jean-Christophe Helary