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: Fri, 27 Jul 2007 14:12:42 +0300 Message-ID: References: <795F38F4-7253-47DC-97DD-53BED4F0AB97@mx6.tiki.ne.jp> <871weuk228.fsf@uwakimon.sk.tsukuba.ac.jp> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: sea.gmane.org 1185534783 7080 80.91.229.12 (27 Jul 2007 11:13:03 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 27 Jul 2007 11:13:03 +0000 (UTC) Cc: schwab@suse.de, fusion@mx6.tiki.ne.jp, emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 27 13:12: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 1IENkc-0007Lg-Jz for ged-emacs-devel@m.gmane.org; Fri, 27 Jul 2007 13:12:54 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IENkc-0007CR-0H for ged-emacs-devel@m.gmane.org; Fri, 27 Jul 2007 07:12:54 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IENkY-0007CK-0T for emacs-devel@gnu.org; Fri, 27 Jul 2007 07:12:50 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IENkV-0007C4-Hr for emacs-devel@gnu.org; Fri, 27 Jul 2007 07:12:49 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IENkV-0007C1-CF for emacs-devel@gnu.org; Fri, 27 Jul 2007 07:12:47 -0400 Original-Received: from nitzan.inter.net.il ([213.8.233.22]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IENkV-0008N9-0m for emacs-devel@gnu.org; Fri, 27 Jul 2007 07:12:47 -0400 Original-Received: from HOME-C4E4A596F7 (IGLD-83-130-3-118.inter.net.il [83.130.3.118]) by nitzan.inter.net.il (MOS 3.7.3a-GA) with ESMTP id HJL74891 (AUTH halo1); Fri, 27 Jul 2007 14:12:53 +0300 (IDT) In-reply-to: <871weuk228.fsf@uwakimon.sk.tsukuba.ac.jp> (stephen@xemacs.org) X-detected-kernel: FreeBSD 4.7-5.2 (or MacOS X 10.2-10.4) (2) 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:75654 Archived-At: > From: "Stephen J. Turnbull" > Cc: Andreas Schwab , > fusion@mx6.tiki.ne.jp, > emacs-devel@gnu.org > Date: Fri, 27 Jul 2007 11:33:51 +0900 > > > If it does, how does the problem of marking the strings with _() in > > C/C++ (or rather lack thereof), to get their translations looked up, > > get solved? > > You mark them as dummies so that the extraction tool (typically > xgettext but Emacs may need a special tool) will put them in the pot > file. Then you arrange that they get gettextized at the point of use, > as usual: > > /* This work is fiction; any resemblance to real Emacs identifiers > is a pure coincidence. Except `gettext' plays itself. */ > docstring = gettext (fetch_docstring_from_DOC (index, docfile)) > > or > > (let ((docstring (gettext (documentation-property symbol)))) > ;; format for display > ) Sorry, I'm probably too dumb this morning, because I don't think I follow. Or maybe I just don't know enough about the latest developments in gettext. Here's how the declaration of an Emacs primitive looks in current Emacs sources: DEFUN ("face-attribute-relative-p", Fface_attribute_relative_p, Sface_attribute_relative_p, 2, 2, 0, doc: /* Check whether a face attribute value is relative. Specifically, this function returns t if the attribute ATTRIBUTE with the value VALUE is relative. A relative value is one that doesn't entirely override whatever is inherited from another face. For most possible attributes, the only relative value that users see is `unspecified'. However, for :height, floating point values are also relative. */) (attribute, value) Lisp_Object attribute, value; { As you see, the doc string is just a C comment; after preprocessing, it is completely gone. The make-docfile command gathers these comments and puts them into etc/DOC, but there's no trace of them in the binary, as you point out. I would imagine that we can tweak make-docfile to generate a POT file, as Andreas suggests, but the other part of gettext is to call some function to replace the original string with its translation, when that string needs to be presented to the user. How does one do that, if the original string is not there to begin with? What am I missing here?