From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jean-Christophe Helary Newsgroups: gmane.emacs.devel Subject: Re: Infrastructure proposal (Re: Translating Emacs manuals is of strategic importance) Date: Fri, 05 Jan 2024 14:07:12 +0000 Message-ID: References: <87r0iz3lx0.fsf@yahoo.com> <877ckqa6m5.fsf@yahoo.com> <71CE52FF-41E1-400F-8B2E-06570F6199EC@traductaire-libre.org> <88006F20-3C13-4E70-BD64-653D896F1DBD@traductaire-libre.org> <83plygue5q.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="4251"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Kangas , Po Lu , =?utf-8?Q?Vincent_Bela=C3=AFche?= , emacs-devel@gnu.org, rms@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jan 05 15:32:28 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 1rLlFM-0000uX-GF for ged-emacs-devel@m.gmane-mx.org; Fri, 05 Jan 2024 15:32:28 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rLlEH-0002Ch-ER; Fri, 05 Jan 2024 09:31:21 -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 1rLkrJ-0002LV-Is for emacs-devel@gnu.org; Fri, 05 Jan 2024 09:07:37 -0500 Original-Received: from mail-4317.proton.ch ([185.70.43.17]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rLkrG-0002ti-NZ; Fri, 05 Jan 2024 09:07:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=traductaire-libre.org; s=protonmail; t=1704463649; x=1704722849; bh=VU/2Tm5CGd1Lsy+ioU5AOOQshQ/Jo9NfPEDOojY8JPk=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=hkDIE/KEKJfEbzovHekaE/cyG+OyfF3Yf5wpsb3D8a20MKzIh+wFr3+37E4xbQMSk SXABz00QpG360GlaEawzCAtFVeeMWiGHNUn//Ask366GC5CfgRo0CW8LS+184qAAxV yjusr8LG/U+8hufl/0fr8ofsfs+UreKbt58Bp+rOAxsvVspitiFab2irLCFreoVkvC 7gaOUvWV/GtI84mbbl626wEWtHFkpKB3Ll8z/PoNSbIDy2QfkX6M0gIp5q9gBtIiRk m4j03EcXQmxMNBJEqnoqDnPccBdR5e+IemgXBuPpSWb4Isp9S1QvnK9PvbQMoj36oh Niw+Jm+kJN0nQ== In-Reply-To: <83plygue5q.fsf@gnu.org> Feedback-ID: 92162971:user:proton Received-SPF: pass client-ip=185.70.43.17; envelope-from=jean.christophe.helary@traductaire-libre.org; helo=mail-4317.proton.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Fri, 05 Jan 2024 09:31:12 -0500 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:314571 Archived-At: > On Jan 5, 2024, at 22:02, Eli Zaretskii wrote: >=20 >> Date: Fri, 05 Jan 2024 08:20:51 +0000 >> From: Jean-Christophe Helary >> Cc: Po Lu , Eli Zaretskii , Vincent Be= la=C3=AFche , emacs-devel@gnu.org, rms@gnu.org >>=20 >> * translation and proofreading/validation >>=20 >> Now that we have emacs/doc/lang/[lg], what do you think of having >> something like emacs/doc/lang/drafts/[lg], where people would commit >> draughts to be proofread/validated? >=20 > I prefer to use special Git branches for that. This is how we handle > any changes that are not yet ready to be landed on the master branch, > and I see no reason to invent special conventions for manual > translations. What would be the best way to name the branch? It would be nice to have=20 a standard way of naming branches that include documents that require=20 proofreading, because it is less easy to find a branch than to find a=20 folder. >> * version numbers >>=20 >> We=E2=80=99d need to have somewhere in the translation the base commit n= umber >> of the English original, so that when the file is in >> emacs/doc/lang/[lg] people know how recent the document is. >=20 > You assume the translations will be mostly outdated. No. I assume that there might be some discrepancy, sometimes, and a=20 commit number is a very easy way to see if there is, or not. > I'm not so sure, but if that indeed happens, we'll think of something. = =20 > I don't think this is a hard problem to solve. Indeed, it is not. Writing in the texi source the commit number on which=20 the translation is based is pretty easy. But whatever else works for you is fine. >> * reduction of redundant work >>=20 >> To make sure people don=E2=80=99t translate documents that are already w= orked >> on, we=E2=80=99d need a matrix where the files are assigned, and willing >> contributors could check the matrix and would also announce their >> willingness to work on such and such chapter here (pretty much like the >> W3C does for its translation process), for ex: >=20 > I'd worry about this when we have more than a couple translations. > Also, the translation matrix is maintained by TP, and I'm not sure we > should have our own copy; we could simply rely on TP in this aspect. I=E2=80=99m really not talking about the TP here. Since you insist (and it=E2=80=99s fair) on not delegating work to=20 external groups, there is going to be the need to coordinate things=20 from here. And a simple tabulated file should do the trick. >> * technical requirements >>=20 >> An extra step would be a technical requirement that the file was >> properly checked for spelling/grammar with the tools that Emacs >> provides and that it properly builds on the various systems where it >> was handled, to ensure that the lead does not have to do too much grunt >> work on the deliverables. >=20 > Every piece of documentation submitted to Emacs is expected to be > spell-checked, and Emacs supports spell-checking of every language for > which the available spell-checkers have dictionaries. So I don't see > any special problem here. It is not a technical problem. It is a human problem. This is a=20 proposal to explicitly require that all translations are thoroughly=20 spell/grammar checked with the tools that are provided by emacs,=20 because it is a fact that lots of people don=E2=80=99t spell/grammar check= =20 their work. And we can=E2=80=99t really say how Emacs translators will beha= ve=20 since Vincent is the first to commit a manual (and his commit to master=20 was full of errors, and I don=E2=80=99t mean that to disparage him or his w= ork,=20 I=E2=80=99m just stating that as a fact). >> * information >>=20 >> We=E2=80=99d need a readme file to make all that explicit. >=20 > Yes. Feel free to submit it. I will, when we have something to write. This mail is an attempt at=20 creating a first draft, in fact. So, when an agreement/vision is=20 reached it will not be hard to move all that to a readme file. >> * publication >>=20 >> For each emacs release, the texi files would be compiled into >> appropriate formats (minimally info) so that people can easily install >> them. >=20 > That's part of the release procedure, so there's no reason to consider > it specially. Maybe, but it=E2=80=99s a good thing that it is on paper so that translator= s=20 understand how their work is handled. We can=E2=80=99t expect translators t= o=20 understand the fine aspects of the Emacs release process. > We already have translated reference cards, for example > (see etc/refcards/ in the Emacs tree), from which we generate PDF when > a release tarball is prepared. Do you suggest that the manuals could also be published as PDF?