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 10:08:33 +0200 Message-ID: <8336nxbxfi.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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="58378"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: Jean-Christophe Helary Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 08 09:08:59 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 1h2AYs-000F4x-NG for ged-emacs-devel@m.gmane.org; Fri, 08 Mar 2019 09:08:58 +0100 Original-Received: from localhost ([127.0.0.1]:38845 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h2AYr-0004hv-LK for ged-emacs-devel@m.gmane.org; Fri, 08 Mar 2019 03:08:57 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:50396) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h2AYm-0004hp-2K for emacs-devel@gnu.org; Fri, 08 Mar 2019 03:08:52 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:50374) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h2AYm-0007Uj-0P; Fri, 08 Mar 2019 03:08:52 -0500 Original-Received: from [176.228.60.248] (port=4865 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1h2AYl-0005ym-8e; Fri, 08 Mar 2019 03:08:51 -0500 In-reply-to: (message from Jean-Christophe Helary on Fri, 8 Mar 2019 10:48:46 +0900) 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:233922 Archived-At: > From: Jean-Christophe Helary > Date: Fri, 8 Mar 2019 10:48:46 +0900 > > I think what really needs to be discussed is: > > • which strings do we extract > • how to rewrite the mix of code and strings > • how to extract the resulting strings > • how to process the translations for display in emacs Extraction is just a technicality, it can be done in either of several possible ways. We could use xgettext, or we could use a modification of make-docfile (the latter is probably a must for collecting do strings from C sources), or we could use po4a or something similar. As long as the catalogs are PO files, we could even use a mix of tools, if, for example, some of the tools is more convenient for Lisp, but not for C. And I don't understand what problems you see in the last item: what should be done there other than display the translated string with 'message' or insert it into the *Help* buffer? So I think you are bothered by stuff that is largely non-issues. The most important issues IMO are different: (a) what methodology of extracting/marking translatable strings to choose so that this job doesn't become infeasible; and (b) how to arrange the message catalogs so that they will be easy to maintain and update, given the modular nature of Emacs. I think we should also take a better look at how the built-in help facilities generate documentation and other displayable strings from symbol names. Macros such as define-minor-mode should also be scrutinized to see if there are some special problems there. Once this is done, the methodology decided, and the necessary tools are available, the rest is just more or less mechanical work to convert more and more parts of Emacs.