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: Wed, 06 Mar 2019 20:09:59 +0200 Message-ID: <838sxrdgco.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> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="248745"; 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 Wed Mar 06 19:10:46 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 1h1b0A-0012b5-79 for ged-emacs-devel@m.gmane.org; Wed, 06 Mar 2019 19:10:46 +0100 Original-Received: from localhost ([127.0.0.1]:37147 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h1b09-0003Vn-42 for ged-emacs-devel@m.gmane.org; Wed, 06 Mar 2019 13:10:45 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:59120) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h1aza-0003Vh-7j for emacs-devel@gnu.org; Wed, 06 Mar 2019 13:10:11 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:46599) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h1azW-0004s8-8P; Wed, 06 Mar 2019 13:10:07 -0500 Original-Received: from [176.228.60.248] (port=3577 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1h1azQ-0003dx-0Y; Wed, 06 Mar 2019 13:10:00 -0500 In-reply-to: <87bm2p56gu.fsf@mail.linkov.net> (message from Juri Linkov on Tue, 05 Mar 2019 23:58:25 +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:233865 Archived-At: > From: Juri Linkov > Cc: Eli Zaretskii , rms@gnu.org, emacs-devel@gnu.org > Date: Tue, 05 Mar 2019 23:58:25 +0200 > > One of the main decisions that has to be made is whether to wrap all > user-facing translatable strings in all Lisp files using a macro/function > 'gettext' First, AFAIR the conclusion back when this was discussed was that we might not need to mark the translatable strings, because almost all of them should be translatable. If anything, we might consider marking strings that do NOT need to be translated, as they are a very small minority. Just look at the strings in a typical Emacs source file and try to find strings that you wouldn't want translated. Unlike some other programs, Emacs almost never says something that is not meant to be read and understood by the user. Second, I don't understand why we are still talking about 'message'. Most of the user interaction in Emacs that will benefit the most from translation is not messages we show in the echo area: Emacs actually doesn't chatter there too much. Most of the stuff that IMO is much more important to have translated are the doc strings. It's no coincidence that Emacs has around 5000 calls to 'message', but almost 50000 doc strings, 10 times more than echo-area messages. So even if we do decide to attack the 'message' part first, we should consider the doc strings as well, so that whatever infrastructure we develop for messages will work for doc strings as well. And that adds more issues that the basic design must solve or be capable of solving. Then there are some seemingly minor technical issues, but I think Emacs will force us to deal with them up front, because Emacs is so much different from a typical localized text-mode program. Some of the issues that came up in the past: . Do we use a separate message catalog for each Lisp package, or a single catalog for all of Emacs? Each alternative has its merits and demerits. For example, if we go with separate catalogs, then how do we make the correct bindtextdomain call, given that packages call each other? If we go for a single catalog, how do we support installing and loading a new package without exiting Emacs? . 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. . 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.