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 19:30:31 +0200 Message-ID: <83a7i7di6g.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="77976"; 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 18:31:36 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 1h1aOF-000KCR-Vo for ged-emacs-devel@m.gmane.org; Wed, 06 Mar 2019 18:31:36 +0100 Original-Received: from localhost ([127.0.0.1]:36697 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h1aOF-0008PY-06 for ged-emacs-devel@m.gmane.org; Wed, 06 Mar 2019 12:31:35 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:52488) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h1aNI-0008NT-Tt for emacs-devel@gnu.org; Wed, 06 Mar 2019 12:30:37 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:45752) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h1aNI-0005O0-7W; Wed, 06 Mar 2019 12:30:36 -0500 Original-Received: from [176.228.60.248] (port=1148 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1h1aNB-0006ei-Rt; Wed, 06 Mar 2019 12:30:30 -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:233864 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' (alias '_') explicitly like is implemented in XEmacs' I18N3 > that would help to extract translations from the source code, or to use > a low-level implicit translation without changing the existing code like > is implemented for handling text-quoting-style in format strings. > The latter will even allow translation of strings that a package author > forgot to mark with '_'. I'd encourage people who want or consider working on this to read past discussions about related topics. Some very important conclusions and ideas came out of those discussions, and it would be a pity if we'd need to reiterate all of what was already said and argued time and again, instead of starting from where those past discussions ended. Significant discussions of this happened in Dec 2001, in July 2007, and lately in Apr 2017. Some of those are quite long, but please do read them, even if you were part of those discussions. This current discussion will be much more fruitful if we first recollect what we already talked over. > Depending on this decision a translation file format has to be selected, > be it flat Gettext PO format files or even some YAML-like hierarchical > Lisp structures with scopes. The first alternative we should consider is to use the PO format, because that's what translation teams out there are used to work with. If it turns out that we cannot use the PO format for some good reasons (which will have to be very good), we can consider other formats, but translation teams will be in general very unhappy about that. And I think these technicalities are not the first, let alone main, decisions we must make. They are important, but there are more important and complex problems we need to address first. I will talk about this separately. Thanks.