From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Emacs i18n Date: Fri, 08 Mar 2019 09:29:19 +0200 Message-ID: <838sxpbz8w.fsf@gnu.org> 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> <4ec46661-012d-1418-8401-0bd3d82037c1@cs.ucla.edu> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="166728"; mail-complaints-to="usenet@blaine.gmane.org" Cc: juri@linkov.net, rms@gnu.org, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 08 08:30:29 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 1h29xa-000hBZ-7F for ged-emacs-devel@m.gmane.org; Fri, 08 Mar 2019 08:30:26 +0100 Original-Received: from localhost ([127.0.0.1]:38486 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h29xZ-00043k-9B for ged-emacs-devel@m.gmane.org; Fri, 08 Mar 2019 02:30:25 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:42711) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h29wx-00043f-Ip for emacs-devel@gnu.org; Fri, 08 Mar 2019 02:29:48 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:49963) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h29ww-0000fZ-SC; Fri, 08 Mar 2019 02:29:46 -0500 Original-Received: from [176.228.60.248] (port=2422 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1h29wn-0008E1-6v; Fri, 08 Mar 2019 02:29:37 -0500 In-reply-to: <4ec46661-012d-1418-8401-0bd3d82037c1@cs.ucla.edu> (message from Paul Eggert on Thu, 7 Mar 2019 14:25:30 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:233919 Archived-At: > Cc: rms@gnu.org, emacs-devel@gnu.org, juri@linkov.net > From: Paul Eggert > Date: Thu, 7 Mar 2019 14:25:30 -0800 > > > 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. No, I didn't mean "each", I meant just some, hopefully a small minority. Because most of the use cases are probably easy enough to change so that strings could be collected by a tool, and 'message' and its ilk could then translate them automatically. Having an explicit translation function would then be that "fire escape" for when converting code not to compute strings would be too painful. > > 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 could, but I don't see how that would help. If a string is not found in the catalog(s), it will be output untranslated anyway, so why do we need a separate function? > this discussion suggests that Emacs is not really that much of a special > case aside from its size. I'm not sure I agree. I think the fact that Emacs is written mostly in Lisp and not in a procedural compiled language will make another qualitative difference. > there is a real advantage to reusing existing GNU technology in this > area rather than trying to reinvent it. Where it fits, sure. Especially we should strive hard to use the PO files for catalogs, because that affects the translation teams.