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: Fwd: A system for localizing documentation strings Date: Thu, 26 Jul 2007 12:29:19 +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=ISO-2022-JP; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1185420581 19366 80.91.229.12 (26 Jul 2007 03:29:41 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 26 Jul 2007 03:29:41 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 26 05:29:39 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 1IDu2k-0007t1-3F for ged-emacs-devel@m.gmane.org; Thu, 26 Jul 2007 05:29:38 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IDu2j-0000Kl-KQ for ged-emacs-devel@m.gmane.org; Wed, 25 Jul 2007 23:29:37 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IDu2f-0000H9-LH for emacs-devel@gnu.org; Wed, 25 Jul 2007 23:29:33 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IDu2f-0000FO-0J for emacs-devel@gnu.org; Wed, 25 Jul 2007 23:29:33 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IDu2e-0000Eu-MT for emacs-devel@gnu.org; Wed, 25 Jul 2007 23:29:32 -0400 Original-Received: from smtp10.tiki.ne.jp ([218.40.30.107]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IDu2d-0002zc-TV for emacs-devel@gnu.org; Wed, 25 Jul 2007 23:29:32 -0400 Original-Received: from [192.168.11.4] (pl223.nas933.takamatsu.nttpc.ne.jp [210.136.182.223]) (authenticated bits=0) by smtp10.tiki.ne.jp (8.13.8/8.13.8) with ESMTP id l6Q3TRDb091084 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 26 Jul 2007 12:29:28 +0900 (JST) (envelope-from fusion@mx6.tiki.ne.jp) 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:75551 Archived-At: I was told by Eli Zaretskii that such discussions should better take place here, hence my forward from help-gnu-emacs@gnu.org After I sent the mail this morning, I realized that obviously interactive output could/should be handled in similar ways. I think in the end, we need a way to encapsulate translatable strings in objects (functions ?) that will allow the strings to be available in a multiplicity of processes: display first, but of course translation. Keep in mind that I am only a translator and that I am only getting started with emacs, emacs lisp and emacs localization. Regards, Jean-Christophe Helary ============================================ Begin forwarded message: From: Jean-Christophe Helary Date: 26 juillet 2007 10:05:36 HNJ To: Emacs Mailing List Subject: A system for localizing documentation strings A function is written like this (per Robert Chassell's book, I'm currently only at chapter 3, sorry if all sounds a little too obvious): (defun function-name (arguments...) "optional-documentation..." (interactive argument-passing-info) ; optional body...) 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...") docfun would provide the data (language+string) to the display devices (help functions etc) that would need to be able to get the proper string based on the environment locale (or whatever locale data is available). In case the locale matching string is not available (not translated), a mechanism to display a prefered language, then the default language should be implemented. In the end, the template for a defun would be: Template 1: (defun function-name (arguments...) (docfun EN "optional-documentation in EN..." FR "documentation optionnelle en FR...") (interactive argument-passing-info) ; optional body...) To simplify the writing, in the case a lot of functions and documentation needs to be written (which is always a good thing) we could have a doclang function that takes one argument, the language in which the documentation has been written so that a typical .el file could look like: Template 2: (doclang JA) ; optional so keep backward compatibility with the current lack of framework (defun function-name1 (arguments...) "このファンクションのドキュメンテーションは日本語だ..." (interactive argument-passing-info) ; optional body...) (defun function-name2 (arguments...) "このファンクションのドキュメンテーションも日本語だ..." (interactive argument-passing-info) ; optional body...) Now, to offer a real framework for translating, since we _don't want to use intermediate formats (like PO etc), although those could be available for gettext fans, we'd need another function that takes a number of arguments and that could look like: (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 The target-language declares to which language the translator is working the reference-function-name declares which functions should be taken as reference for the current translation. the reference-file declares which files should be taken as reference (ideally, PO compendia, TMX files, CSV files etc) transfun would be a whole different business since it would actually provide a real dynamic fuzzy matching engine between the source- language strings and the source reference strings. _NOT_ something like the "fuzzy" thing gettext provides. In the case of Template 1 (a function that has already been translated to a number of languages), transfun would just add a line to the documentation function. In the case of Template 2 (a function that exists in only one language), transfun would also transform Template 2 into Template 1 to add the documentation at the proper location. If the doclang function is not documented, transfun asks what argument should doclang have and proceeds. Now, it would of course be possible to have translation tools support the defun template so that they output the target strings to the correct position. Of course, I am only talking about functions here (remember: chapter 3 of Chassell's book) but I am gessing that most of this "framework" could be extended to support _all_ the translatable strings emacs displays. As for the quality of the translation (and it seems it is mostly people who have never done translation work before who complain the most) I suggest you leave that to the localization groups that are used to the processes. 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. Jean-Christophe Helary ============================================