From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Emacs i18n Date: Thu, 7 Mar 2019 14:25:30 -0800 Organization: UCLA Computer Science Department Message-ID: <4ec46661-012d-1418-8401-0bd3d82037c1@cs.ucla.edu> References: <87o97aq6gz.fsf@jidanni.org> <87tvgoud56.fsf@mail.linkov.net> <83o96wk2mi.fsf@gnu.org> <87k1hjfvjd.fsf@mail.linkov.net> <871s3p0zdz.fsf@mail.linkov.net> <83h8ckezyt.fsf@gnu.org> <83o96qegv1.fsf@gnu.org> <32b1ab1b-bef4-629a-8830-b1dcc6915087@cs.ucla.edu> <83a7iae9va.fsf@gnu.org> <05ed2dec-2a84-f7dc-1af5-c9d923992785@cs.ucla.edu> <87bm2p56gu.fsf@mail.linkov.net> <837edbdg33.fsf@gnu.org> <83o96mbv4l.fsf@gnu.org> <83d0n2bfju.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="80737"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 Cc: juri@linkov.net, rms@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 07 23:26:19 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h21Sz-000Ksr-Jx for ged-emacs-devel@m.gmane.org; Thu, 07 Mar 2019 23:26:17 +0100 Original-Received: from localhost ([127.0.0.1]:60390 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h21Sy-0003CC-HZ for ged-emacs-devel@m.gmane.org; Thu, 07 Mar 2019 17:26:16 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:54793) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h21SO-0003Bz-Jh for emacs-devel@gnu.org; Thu, 07 Mar 2019 17:25:41 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h21SN-0002oJ-Bu for emacs-devel@gnu.org; Thu, 07 Mar 2019 17:25:40 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:52568) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1h21SH-0002Zb-P0; Thu, 07 Mar 2019 17:25:34 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id BBCB51614E5; Thu, 7 Mar 2019 14:25:31 -0800 (PST) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id xdBQiFZ8ID33; Thu, 7 Mar 2019 14:25:30 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id E0C1F1614E6; Thu, 7 Mar 2019 14:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id S_5TXYd4OJ2H; Thu, 7 Mar 2019 14:25:30 -0800 (PST) Original-Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id C352A161420; Thu, 7 Mar 2019 14:25:30 -0800 (PST) Openpgp: preference=signencrypt Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= xsFNBEyAcmQBEADAAyH2xoTu7ppG5D3a8FMZEon74dCvc4+q1XA2J2tBy2pwaTqfhpxxdGA9 Jj50UJ3PD4bSUEgN8tLZ0san47l5XTAFLi2456ciSl5m8sKaHlGdt9XmAAtmXqeZVIYX/UFS 96fDzf4xhEmm/y7LbYEPQdUdxu47xA5KhTYp5bltF3WYDz1Ygd7gx07Auwp7iw7eNvnoDTAl KAl8KYDZzbDNCQGEbpY3efZIvPdeI+FWQN4W+kghy+P6au6PrIIhYraeua7XDdb2LS1en3Ss mE3QjqfRqI/A2ue8JMwsvXe/WK38Ezs6x74iTaqI3AFH6ilAhDqpMnd/msSESNFt76DiO1ZK QMr9amVPknjfPmJISqdhgB1DlEdw34sROf6V8mZw0xfqT6PKE46LcFefzs0kbg4GORf8vjG2 Sf1tk5eU8MBiyN/bZ03bKNjNYMpODDQQwuP84kYLkX2wBxxMAhBxwbDVZudzxDZJ1C2VXujC OJVxq2kljBM9ETYuUGqd75AW2LXrLw6+MuIsHFAYAgRr7+KcwDgBAfwhPBYX34nSSiHlmLC+ KaHLeCLF5ZI2vKm3HEeCTtlOg7xZEONgwzL+fdKo+D6SoC8RRxJKs8a3sVfI4t6CnrQzvJbB n6gxdgCu5i29J1QCYrCYvql2UyFPAK+do99/1jOXT4m2836j1wARAQABzSBQYXVsIEVnZ2Vy dCA8ZWdnZXJ0QGNzLnVjbGEuZWR1PsLBfgQTAQIAKAUCTIByZAIbAwUJEswDAAYLCQgHAwIG FQgCCQoLBBYCAwECH In-Reply-To: <83d0n2bfju.fsf@gnu.org> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 131.179.128.68 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:233898 Archived-At: On 3/7/19 12:22 PM, Eli Zaretskii wrote: > > 'message' is just a representative of a class of such functions. > There are others: 'signal', 'error', 'user-error', 'princ', 'format', > and probably some more I'm missing. So the actual number of > occurrences is larger than the 40 you found. Yes, of course. And even for 'message', all I searched for was the string '(message (concat', which is just a fraction of the calls to 'message' that will need to be reworked. That search was not an attempt to count all the problems we'd run into; it merely was a sample of the problems. If the sample is representative then each individual problem should be relatively easy to solve. > whether we indeed > want to give up marking translatable strings and instead rely on some > functions always translating their argument strings. We could mark each translatable string by hand. But this would make for more churn to the source code and would be more work. It's hard to see why that would be a win, compared to the reasonably-common practice of marking some well-known functions as doing translations automatically. > Perhaps doing so > will impose restrictions on what a Lisp program can do, and we don't > want to live with such restrictions without some fire escape, in the > form of explicitly translated strings? One can easily work around any such restrictions by having a variant of 'message' that does not translate its format argument. We're already doing this for translation of '`', by having two functions 'format' and 'format-message': the former does not translate '`', the latter does. A similar approach can work for natural-language translation and 'message'. > we should not blindly accept any technique used > for localization, because Emacs is so much different from a typical > console program written in C. Of course we should not accept techniques blindly. We should use techniques with our eyes open, based on experience. That being said, this discussion suggests that Emacs is not really that much of a special case aside from its size. If so, there is little need to reinvent the i18n wheel just for Emacs, and there is a real advantage to reusing existing GNU technology in this area rather than trying to reinvent it.