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: A system for localizing documentation strings Date: Thu, 26 Jul 2007 11:10:59 -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 1185462581 21179 80.91.229.12 (26 Jul 2007 15:09:41 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 26 Jul 2007 15:09:41 +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 17:09:38 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 1IE4y9-0003cJ-NZ for ged-emacs-devel@m.gmane.org; Thu, 26 Jul 2007 17:09:38 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IE4y7-0005ao-Ee for ged-emacs-devel@m.gmane.org; Thu, 26 Jul 2007 11:09:35 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IE4y4-0005ZO-5R for emacs-devel@gnu.org; Thu, 26 Jul 2007 11:09:32 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IE4y0-0005Wq-BR for emacs-devel@gnu.org; Thu, 26 Jul 2007 11:09:31 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IE4y0-0005WW-16 for emacs-devel@gnu.org; Thu, 26 Jul 2007 11:09:28 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IE4xn-0003B5-QG for emacs-devel@gnu.org; Thu, 26 Jul 2007 11:09:16 -0400 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.60) (envelope-from ) id 1IE4zT-00033d-Ee; Thu, 26 Jul 2007 11:10:59 -0400 In-reply-to: (message from Jean-Christophe Helary on Thu, 26 Jul 2007 22:51:54 +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:75576 Archived-At: > From: Jean-Christophe Helary > Date: Thu, 26 Jul 2007 22:51:54 +0900 > > I see 2 types of .el files. > > 1) Those that come with the emacs distribution. > > 2) Those that can be installed in user space. > > The distribution would come with the translated .el files and the > updates to the translation could be included in updates of the > distribution without requiring the user to build the distribution > when new translations come. Since the translations are in the code > there is little management necessary (unlike systems where the > localizations come in separate files). > > For the .el files in user space, the author would maintain the file's > translation and users would be able to compile the file without any > specific problem. 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. > > 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. > > I don't think it is a good idea because it would put a bigger load on > the coder who would then have to write keys in the code and then > values in a separate file. No, the idea is that Emacs will automatically recognize the strings for which it needs to look for translations. The programmers will need not do anything beyond what they do today: provide a single doc string. > > 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. > That would require the faulty English string to be > rewritten before proceeding to translation. We do it already anyway: grep the ChangeLog files for the string "doc fix", and you will see how many fixes like that are installed. > Also, we can expect to find translators who would be more familiar > with one source language than the other. If there is a Japanese > equivalent to an English description. I'd rather use the Japanese as > source and the English as reference to translate to French for exemple. You will be able to do that, by looking at the Japanese translation. > > 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.