From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Before l10n, better practices for (message) ? Date: Fri, 26 May 2017 17:44:58 +0300 Message-ID: <83bmqfk785.fsf@gnu.org> References: <2623E5C5-4D40-4C9F-BFF6-181D2E69F984@gmail.com> <831srgnuyc.fsf@gnu.org> <83vaormn2x.fsf@gnu.org> <1B4DE39C-E293-4370-9E76-82E1B7385C00@gmail.com> <83o9ugjaqd.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1495809926 11382 195.159.176.226 (26 May 2017 14:45:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 26 May 2017 14:45:26 +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 Fri May 26 16:45:20 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dEGUP-0002j1-9e for ged-emacs-devel@m.gmane.org; Fri, 26 May 2017 16:45:17 +0200 Original-Received: from localhost ([::1]:37127 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dEGUU-0006AR-Sr for ged-emacs-devel@m.gmane.org; Fri, 26 May 2017 10:45:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35775) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dEGUO-0006AK-Ne for emacs-devel@gnu.org; Fri, 26 May 2017 10:45:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dEGUL-0003hJ-JV for emacs-devel@gnu.org; Fri, 26 May 2017 10:45:16 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:44616) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dEGUL-0003gZ-GX; Fri, 26 May 2017 10:45:13 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1161 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dEGUJ-0001GL-Tc; Fri, 26 May 2017 10:45:13 -0400 In-reply-to: (message from Jean-Christophe Helary on Fri, 26 May 2017 23:21:59 +0900) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:215219 Archived-At: > From: Jean-Christophe Helary > Date: Fri, 26 May 2017 23:21:59 +0900 > > > (setq key1 "string1" > > key2 "string2") > > > >> (message key1) > >> (message key2) > > > > One problem with this approach is that the programmer who writes the > > original code and provides the messages in English will have to > > manually create the English message catalog. > > It just occurred to me that in gettext, "key" *is* the English string... Yes. But then you cannot use setq on literal strings. > > Another problem is how to combine such catalogs from different source > > files, and/or make sure the "keyN" names from different files don't > > clash. > > Is it very different from global variables clashing or not between packages? No. But the need to name messages with package qualifiers is a significant nuisance, and will fill the "namespace" of a file with many symbols. > > IOW, the question of suitable infrastructure is still there, with any > > approach. That's why it is better to start by using whatever relevant > > infrastructure is provided by gettext, because at least some of these > > issues are already solved there, and because the package itself is > > widely available. > > Yes, but to me it looks like gettext works like it does this because C is not an interpreted language and forcing Lisp code to use the full gettext process does look a bit unnatural. I didn't say we should use all of the capabilities of gettext. We just need to use what suits us. > I can see that we use gettext to extract strings and create POTs to get POs. But once the POs are there, do we need to create binary MO blobs ? I'm not sure at all. So in the end gettext would be used only for string extraction and a few checks. But I may be missing something important here... Figuring out which parts of gettext should be used is part of the job. Whatever we find useful will be net win, since we will not need to develop and maintain that. Also, even if we don't use some part, it could provide ideas for similar infrastructure tailored to our needs.