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: Sat, 09 Mar 2019 08:40:30 +0200 Message-ID: <83mum48s9t.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> <8336nxbxfi.fsf@gnu.org> <2539FAB2-2D71-44F5-B8D9-2C4AFE52ACEC@gmail.com> <83wol986to.fsf@gnu.org> <75275F9B-D257-4C9E-85A0-A7F57C93FD64@gmail.com> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="87955"; 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 Sat Mar 09 07:40:57 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 1h2VfD-000Mmt-RK for ged-emacs-devel@m.gmane.org; Sat, 09 Mar 2019 07:40:55 +0100 Original-Received: from localhost ([127.0.0.1]:54754 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h2VfC-0002uF-KO for ged-emacs-devel@m.gmane.org; Sat, 09 Mar 2019 01:40:54 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:40093) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h2Vf3-0002sA-V4 for emacs-devel@gnu.org; Sat, 09 Mar 2019 01:40:46 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:54034) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h2Vf3-0005g2-RP; Sat, 09 Mar 2019 01:40:45 -0500 Original-Received: from [176.228.60.248] (port=1480 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1h2Vf3-00016k-AY; Sat, 09 Mar 2019 01:40:45 -0500 In-reply-to: <75275F9B-D257-4C9E-85A0-A7F57C93FD64@gmail.com> (message from Jean-Christophe Helary on Sat, 9 Mar 2019 11:44:09 +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:233945 Archived-At: > From: Jean-Christophe Helary > Date: Sat, 9 Mar 2019 11:44:09 +0900 > > >> Sure. I just meant that l10n issues (is PO "efficiency", etc.) are already solved, but i18n in general has to be implemented from scratch. > > > > No sure I understand: what part(s) we would need to implement from scratch? We already have the capability of inserting arbitrary non-ASCII text into any buffer and displaying such text as echo area messages. > > What I mean by "from scratch" is that we have the possibility to extract text and insert text, but i18n is inexistant in emacs. So we have to build an i18n system that works for emacs and that does not exist yet, at all. I don't see how we can start implementing before deciding what and how to implement. This discussion hopefully will eventually lead to such decisions. > Also, the "how to load catalogs on demand" point that you mention below is part of i18n and as you seem to say has to be developed from scratch. If we decide that the gettext way is not entirely appropriate, yes. But we didn't make that decision yet. > > Also, how to merge several catalogs (the need for this might disappear if, for example, we decide that each .el file will have its own catalog), > > Won't this depend on the extracting tool's options ? Not directly, no. It's actually the other way around: we should first decide how to arrange the catalogs, and only after that see what tools/options to use for that. > And wouldn't that be more practical in the first place to not merge anything but have one catalog per .el file ? (practical in terms of translation/testing/management, as far as I can tell from experience, etc.) If you are following the discussion, you know that not everyone agrees with that. There are advantages in having just one catalog or a small number of large ones. > > and how to load catalogs on demand when the corresponding code is loaded/executed. > > I guess you mean the technicalities involved in the obvious (?) "we check the user preferred locale and display the catalog corresponding to that locale" ? I said "load", not "display". If you have one catalog per .el file, when do you load it into memory and when, if ever, do you unload it? Loading everything at the start would be un-economical, to say the least. > >> Can't we start with a survey of the strings we want extracted in a given number of emacs core packages ? > > > > How would such a survey help us? We generally want all of the strings that are displayed to the user translated. We don't need any survey for that decision. > > Of course, but a survey (sorry, I don't have a better word) of a few packages can help us see the workload, build prototypes, test them, establish best practices for developers, etc. I don't think we have reached the point where building prototypes is useful, since we don't yet have the basic design decisions for prototyping.