From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alexandre Garreau Newsgroups: gmane.emacs.help Subject: Re: Emacs i18n Date: Sat, 17 Jul 2021 22:00:51 +0200 Message-ID: <2114291.0jFjTtfV1S@galex-713.eu> References: <874kctcb97.fsf@cock.li> <837dhp3uqg.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33762"; mail-complaints-to="usenet@ciao.gmane.io" To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jul 17 22:01:48 2021 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m4qVP-0008fA-Oy for geh-help-gnu-emacs@m.gmane-mx.org; Sat, 17 Jul 2021 22:01:47 +0200 Original-Received: from localhost ([::1]:60736 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m4qVO-0003bV-15 for geh-help-gnu-emacs@m.gmane-mx.org; Sat, 17 Jul 2021 16:01:46 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41476) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m4qUk-0003b5-Np for help-gnu-emacs@gnu.org; Sat, 17 Jul 2021 16:01:06 -0400 Original-Received: from portable.galex-713.eu ([2a00:5884:8305::1]:60352 helo=galex-713.eu) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m4qUi-0001n5-E7 for help-gnu-emacs@gnu.org; Sat, 17 Jul 2021 16:01:06 -0400 Original-Received: from gal by galex-713.eu with local (Exim 4.92) (envelope-from ) id 1m4qUV-00083x-Ov for help-gnu-emacs@gnu.org; Sat, 17 Jul 2021 22:00:51 +0200 In-Reply-To: <837dhp3uqg.fsf@gnu.org> Received-SPF: pass client-ip=2a00:5884:8305::1; envelope-from=galex-713@galex-713.eu; helo=galex-713.eu X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:131801 Archived-At: Le samedi 17 juillet 2021, 16:01:11 CEST Eli Zaretskii a =C3=A9crit : > > From: mrf > > Cc: help-gnu-emacs@gnu.org > > Date: Sat, 17 Jul 2021 16:32:08 +0300 > >=20 > > Is UI Strings in C code fully translatable >=20 > No. But those are indeed the minority; the vast majority is in Lisp. >=20 > > Do you talk about elisp part of code when you say It is limited? >=20 > It doesn't matter. What does matter is that the echo-area messages, > whether they come from C or Lisp, are a small part of the text that > Emacs presents to the user as part of the UI. We have special buffers > (like *Help* and *Apropos*) where we show information which won't fit > the echo-area, we have menus and dialogs, we have tooltips, etc. etc. > The names of commands and user options are all in English, and those > names have mnemonic value. >=20 > Let's face it: the classic i10n framework doesn't really work for a > program such as Emacs, which interacts with users via so many > different means. Translating emacs would require to translate many identifiers, it would=20 actually amount to translate a programming language, which has very rarely= =20 been done. It usually only has been done through keyword, and translation= =20 of standard library, and mostly for education purposes, while any other=20 use than educational is weirdly considered to be =E2=80=9Cprofessional=E2= =80=9D (while=20 education wouldn=E2=80=99t?) hence to enables international collaboration, = hence=20 english. I once heard from a friend called Jean-Philippe de Mengual aka Texou that=20 he wanted to translate emacs but couldn=E2=80=99t because he rightfully hea= rd that=20 would mean translate commands and identifiers and programs, etc.=20 It was a pity because he often runs a lot of accessibility-oriented work=20 especially about blindness (as he=E2=80=99s blind too), and emacs through=20 emacspeak is well reknown as a wonderful vocal desktop (it wouldn=E2=80=99t= =20 surprise me that it would be the most efficient and useful vocal interface= =20 in the world). This is likely to amount to emacs=E2=80=99 extensibility, w= hich=20 enables to freely, and without permission nor (to a limited extent)=20 coordination, implement new paradigms, such as advice-oriented programming= =20 (which emacspeak ubiquitously use, so that it keeps working while=20 modifying almost all emacs behavior, while staying in sync with mainline=20 emacs). Emacspeak is sort of wonderful and sooo complete I guess because of=20 dogfeeding, its dev uses it for everything=E2=80=A6 but dogfeeding has its = limits,=20 and afaik he=E2=80=99s amero-indian, so english is his native language=E2= =80=A6 and indeed=20 emacspeak is most likely the best UI for english-speaking people=E2=80=A6 a= s is=20 emacs. It is no new that english, on par (or even more) than technical skills, is= =20 a great bareer to user-friendliness of a program. So if emacs could be=20 translated, it could gain a loooot more users=E2=80=A6 on the other side, t= hat=20 would break compatibility between many user extensions which would be=20 divided between them because of language bareer=E2=80=A6 But what evolutio= n=20 theory teaches is that more barieer also means more diversity, more=20 mutations, hence more ideas. Plus that would represent programs written=20 by non-english-speakers, that wouldn=E2=80=99t have been written at all oth= erwise,=20 so no loss. But the greatest and first difficulty is that emacs is big and fast, so it= =20 should be done progressively, from the low level up, so APIs should be=20 clearly divided, and modular=E2=80=A6 while emacs lisp still lacks any prop= er=20 namespace system u.u Another further difficulty is that not only translation is hard, but it is= =20 also somewhat contextual=E2=80=A6 sometimes, in a .po file, you need to go = back to=20 the source to see the context (and sometimes even run the program! to see=20 the context of use) to understand how to translate=E2=80=A6 unfortunately,= =20 translating a program would require to understand even more context! So=20 it would need a special UI to fully see the original program while=20 translating, otherwise it would be a mess, because any inconsistent=20 translation would imply a bug A special would be even more needed so you only translate strings/ identifiers at their definition. So that when low-level API X and Y has=20 been translated, some high-level API Z that would use X and Y would=20 already have its =E2=80=9Cworking=E2=80=9D translated, and what would need = to be=20 translated would only be new defined identifiers: first and foremost=20 =E2=80=9Cexported=E2=80=9D ones (first prompts, menu bars, commands, docstr= ings) and then=20 the =E2=80=9Cless useful=E2=80=9D, =E2=80=9Csecondary=E2=80=9D, =E2=80=9Cre= quired to hack=E2=80=9D stuff (internal=20 functions, variable names, etc.). This has never been done anywhere, but I can see how the first place where= =20 that would be really needed would be emacs, and the place where it would=20 be the easiest to implement would also be emacs. And if emacs succeed, it= =20 would either be very difficult elsewhere and thus emacs (maybe other lisps= =20 in general) would have a significant advantage, either it would spread from= =20 emacs and gives emacs hackability great advertisement.