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:37:08 +0200 Message-ID: <837ed9byvv.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> <838sxrdgco.fsf@gnu.org> <83mum6bv11.fsf@gnu.org> <87zhq6nwsi.fsf@mail.linkov.net> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="199478"; mail-complaints-to="usenet@blaine.gmane.org" Cc: eggert@cs.ucla.edu, rms@gnu.org, emacs-devel@gnu.org To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 08 08:37:44 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 1h2A4e-000pnG-EL for ged-emacs-devel@m.gmane.org; Fri, 08 Mar 2019 08:37:44 +0100 Original-Received: from localhost ([127.0.0.1]:38566 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h2A4d-00065O-Cf for ged-emacs-devel@m.gmane.org; Fri, 08 Mar 2019 02:37:43 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:43992) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h2A4X-00065J-3e for emacs-devel@gnu.org; Fri, 08 Mar 2019 02:37:37 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:50030) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h2A4V-0006og-Ri; Fri, 08 Mar 2019 02:37:35 -0500 Original-Received: from [176.228.60.248] (port=2933 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1h2A4M-0001iv-8O; Fri, 08 Mar 2019 02:37:27 -0500 In-reply-to: <87zhq6nwsi.fsf@mail.linkov.net> (message from Juri Linkov on Fri, 08 Mar 2019 00:29:17 +0200) 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:233920 Archived-At: > From: Juri Linkov > Cc: rms@gnu.org, eggert@cs.ucla.edu, emacs-devel@gnu.org > Date: Fri, 08 Mar 2019 00:29:17 +0200 > > > We still should try to use .po files for them, if at all possible, > > and perhaps also the gettext code that supports looking up strings > > in .gmo catalogs generated from .po. > > The PO format is best suited for translation of one-liners like > messages and menu items, but I doubt that the PO format would be > the most efficient implementation for multi-line doc strings since > gettext uses the whole text of the doc string as a key to translation. I'm not sure I understand why the length of the string is an important factor here. Can you explain? If the problem is with the efficiency of gettext implementation of indexing, then we could have our own indexing method. > Whereas more efficient would be to use a Lisp symbol (function or > variable name) as a translation key. A key other than the original string would mean abandoning the PO format. Any deviation from PO would mean major PITA for translation teams, so we should make sure the reason for such a deviation is a very good reason. I'm not yet sure we have such a good reason.