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: Wed, 6 Mar 2019 11:47:18 -0800 Organization: UCLA Computer Science Department Message-ID: <862b9eb2-0662-41c5-fd17-3fa09fe2c1fe@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> <838sxrdgco.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="132722"; 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: rms@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii , Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 06 20:49:22 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 1h1cXX-000YOl-M9 for ged-emacs-devel@m.gmane.org; Wed, 06 Mar 2019 20:49:19 +0100 Original-Received: from localhost ([127.0.0.1]:38674 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h1cXW-00075u-LP for ged-emacs-devel@m.gmane.org; Wed, 06 Mar 2019 14:49:18 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:60979) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h1cWR-00074O-E8 for emacs-devel@gnu.org; Wed, 06 Mar 2019 14:48:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h1cWN-00014h-Ti for emacs-devel@gnu.org; Wed, 06 Mar 2019 14:48:09 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:36310) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1h1cWI-0008Kt-7G; Wed, 06 Mar 2019 14:48:02 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 81386161502; Wed, 6 Mar 2019 11:47:19 -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 a8SU4E6AGqhz; Wed, 6 Mar 2019 11:47:18 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id AD2FF1614E2; Wed, 6 Mar 2019 11:47:18 -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 5DBq0zeY_WSk; Wed, 6 Mar 2019 11:47:18 -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 91B0316145F; Wed, 6 Mar 2019 11:47:18 -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: <838sxrdgco.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:233869 Archived-At: On 3/6/19 10:09 AM, Eli Zaretskii wrote: > even if > we do decide to attack the 'message' part first, we should consider > the doc strings as well Absolutely. In some sense doc strings should be easier, since we shouldn't need to make changes to existing code; all we need to do is add some infrastructure that puts doc strings into a .po file and that translates them when people ask for documentation. > . Do we use a separate message catalog for each Lisp package, or a > single catalog for all of Emacs? We can start with a single catalog that handles core Emacs; we'll need to do that anyway. We can deal with packages later. > . How to specify which target language to use? The locale is not > necessarily correct, e.g., when editing with Tramp. Also, since > translating all of Emacs is such a humongous job, it's quite > possible that some languages will have little or no translations, > and the respective users might want to use translations for a > "fallback" language, which they prefer to English. It should be easy for Emacs users to specify a preferred locale for messages, independently of what the system locale. Similarly, they can specify a preferred fallback locale. All this is relatively easy to do at the C level. > . Many user-facing text messages include portions that we generate > directly from symbol names, which are of course in English. We > should have some idea for how to deal with that. We start by leaving them as English, as that's easier. We can get fancier later, if there's need. The bottom line is that we don't need to have a complete solution in order to start working on this.