From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Translating Emacs manuals is of strategic importance Date: Fri, 05 Jan 2024 14:53:26 +0200 Message-ID: <83r0iwuek9.fsf@gnu.org> References: <91D00B9D-0057-4748-8C83-50E749FE3961@traductaire-libre.org> <835y0b29rk.fsf@gnu.org> <87r0iz3lx0.fsf@yahoo.com> <877ckqa6m5.fsf@yahoo.com> <8734vda9kz.fsf@yahoo.com> <5EC9A02F-DB34-48B6-BD2D-CB9E89A385D0@traductaire-libre.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16127"; mail-complaints-to="usenet@ciao.gmane.io" Cc: stefankangas@gmail.com, vincent.b.1@hotmail.fr, emacs-devel@gnu.org, rms@gnu.org To: Jean-Christophe Helary Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jan 05 13:55:00 2024 Return-path: Envelope-to: ged-emacs-devel@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 1rLjj1-0003vF-L2 for ged-emacs-devel@m.gmane-mx.org; Fri, 05 Jan 2024 13:54:59 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rLjhr-0001n2-LW; Fri, 05 Jan 2024 07:53:47 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rLjhp-0001mU-MR for emacs-devel@gnu.org; Fri, 05 Jan 2024 07:53:45 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rLjho-0008Oj-Q8; Fri, 05 Jan 2024 07:53:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=hh9SD6W9w5BCB9/+8dOxHorhGfXyAXlUXBIJutDLvqk=; b=YX3qAGEKH3ifcBVoHVkR K9uyuMSnpHH72NYTbs42xphkmWKRcCkclGy85sTE/bErWEKbjGs4eKU15EbfctN6AMWLIAdehpxyv ZcQho2tT/RzymbJ3LEo0fuma3GpXmruWolB7SB+k0Ly1ZYK1brTdecApSPQ025qPnBE7tpgogvHlu VvwenubVijMZX2AfNtEVpTiKLKiZLycA5BPyQBKmU3ctxTuUxt1bN4V/6+kxe3euBXhVQkRiZQBMx cPorQVCeJ79u+m3Doj4SbSWxiTSMM6+qRl/Z3Rsr/z/GHwOyh3pQ9RKX/JJj3ZB3/tJrnYGgs9iEP 5aA3fk3JiHA0Kg==; In-Reply-To: <5EC9A02F-DB34-48B6-BD2D-CB9E89A385D0@traductaire-libre.org> (message from Jean-Christophe Helary on Fri, 05 Jan 2024 02:36:29 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:314565 Archived-At: > Date: Fri, 05 Jan 2024 02:36:29 +0000 > From: Jean-Christophe Helary > Cc: Po Lu , Eli Zaretskii , Vincent Belaïche , emacs-devel@gnu.org, rms@gnu.org > > We have little translations and translators on the horizons not because > they do not potentially exist, but because Emacs was always seen as a > closed English-only system. > > Emacs is *the* free software movement flagship. There is no equivalent > in the history of the movement. Still, it is the one that has > historically shown the least interest in, or practical commitment to, > translation and localization. This is at least inaccurate, and quite a bit unfair, I must say. The fact that Emacs does not yet support localized translated messages is correct, of course, but explaining that by lack of interest and practical commitment is not. I think even the response of the maintainers to Vincent's submission speaks volumes about the level of our interest and commitment. > The fact that most consequent free software projects have full-fledge > translation (and translation quality) support says a lot about the sad > state of Emacs in that regard. And translation/localization projects > already existed pre-utf-8, so it’s not so much the lack of interest on > the Emacs side than the passive dismissal of anything that smells like > translation related (I’ve read a number of very silly things here, and > not so long ago, about the fact that people who needed to work in Emacs > should be able to read English, etc.) Silly things people sometimes say here aside (and everyone who reads this list should be able to distinguish between wrong or even silly opinions of some and the official POV of the Emacs maintainers), the projects that have translations all do it using gettext and the related infrastructure. All they need is to wrap strings in the various printf's with _(), and the rest is a matter of having a message catalog translated to the target language. So it is quite simple for those programs to provide localized messages. (Though even with that problem solved by gettext, some languages cannot be adequately supported -- for example, gettext is abysmally inadequate for R2L languages, and it is no accident that most projects have no translations for such languages.) By contrast, the few discussions of this we had here clearly show that gettext is not enough for Emacs. We need more elaborate and more flexible infrastructure that suits the unique requirements of Emacs, where the line dividing code from documentation is so blurred that the gettext's model is no longer applicable. In addition, gettext is not suited well to a project where most of the code is loaded at run time as needed, and the documentation strings and messages to the user are read from several sources, instead of being hard-coded in the code -- how do you package message catalogs in this situation? Last, but not least: most of meaningful messages in Emacs are not printf-style phrases, but doc strings, and gettext doesn't handle those. (The only other GNU project I know of which has similar doc strings -- GDB -- doesn't translate those doc strings, although the GDB messages are translated, and that is not a coincidence, IMO.) There are also other non-trivial issues, as discussed in the past. So before you accuse the project as a whole in being "passively dismissive" wrt translations, a reality check is in order. The real reasons are not the lack of interest or us being lazy. The real reason is that no one has yet stepped forward to take this job upon themselves, let alone saw through that the job is done to the degree that it can be used project-wide. And since no significant development in Emacs ever happens without someone volunteering for the job and then seeing it through, this job still awaits its volunteers. All of the similar significant additions to Emacs in the related areas happened only because we were lucky enough to have volunteers. Some examples: . the Unicode support . the support for bidirectional editing and R2L languages . the support for modern complex text-shaping If we were not lucky, Emacs could have been lacking these important features. For example, we could still be devoid or supporting R2L languages, which are spoken by hundreds of millions of people. Then someone else could perhaps accuse us of being "passively dismissive" about bidi. What this means is that serious translation of doc strings and messages in Emacs will not happen unless someone starts working on it, and working seriously. Working, not talking. And since no one stepped forward for such a long time, one possible explanation of that could be that the Emacs community, as a whole, doesn't consider this a significant problem. The community, not the project management. (If this is what people think, I personally disagree with them, but then Emacs is a community-driven project, and it is hard to take it in directions that the community doesn't support, let alone supports enthusiastically.) > I’m really glad that Vincent’s commit has actually started to stir the > pot, because the mere fact that we did not have a location within the > Emacs sources to put our translations was probably one of the major > show stoppers for all translation endeavours. Nothing is farther from the truth. There was no need to "stir the pot": as soon as Vincent came up with his translation, he was immediately asked whether adding that to Emacs would be possible. That alone should speak volumes of the attitude of the current (and past) maintainers wrt making Emacs friendlier to people whose first language is not English. > The Translation Project has a solution. Free software maintainers send > (po) files to the TP, the files are handled by the various teams and > sent back to the TP (after appropriate QA and validation) to be > included in the final builds. Major gnu/linux distributions too have > solutions. Each distribution has a translation team with all the > committed languages represented, they have deadlines, QA checks, > proofreading, etc. And things work and distributions (including their > manuals) are published as multilingual systems. We could create a translation team for Emacs, but the TP infrastructure is IMNSHO inappropriate for translating large manuals. (In case you didn't know, I'm one of the TP team leaders, so I know something about that.) As with many other aspects of i18n, Emacs needs its own special solutions here, or at least the Texinfo project should come up with a solution for the GNU Project as a whole, since we are not the only GNU project that uses Texinfo. It is unreasonable to expect the Emacs project to solve problems that are common to all the GNU projects, and accuse us of lack of interest because those problems are not yet solved satisfactorily. > But the thing is that all existing free software multilingual > communities work with PO already, so offering a temporary bridge to PO > would ensure that we get the best expertise from already existing teams > and that would give us the time to elaborate on what part we want to > have Emacs and TexInfo play in the process. See above: the existing communities don't need to solve the problems that are central to Emacs in this area, they don't even come close. So, while PO is definitely one alternative we should consider, it is not necessarily the right one for our purposes, certainly when translation of large and frequently-changing manuals is concerned.