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: SES manual French translation (Re: Where to contribute manual translations ?) Date: Mon, 01 Jan 2024 23:11:19 +0000 Message-ID: <91D00B9D-0057-4748-8C83-50E749FE3961@traductaire-libre.org> References: <831qb45fog.fsf@gnu.org> <50A7AFED-DA37-4212-9ED1-7D906C34B6B2@traductaire-libre.org> <83o7e51bws.fsf@gnu.org> <83mstp11sz.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="27210"; mail-complaints-to="usenet@ciao.gmane.io" Cc: vincent.b.1@hotmail.fr, stefankangas@gmail.com, 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 Tue Jan 02 04:21:19 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 1rKVLC-0006ri-O4 for ged-emacs-devel@m.gmane-mx.org; Tue, 02 Jan 2024 04:21:18 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rKVKe-0000Pn-3w; Mon, 01 Jan 2024 22:20:44 -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 1rKRRV-0003fk-St for emacs-devel@gnu.org; Mon, 01 Jan 2024 18:11:33 -0500 Original-Received: from mail-4323.proton.ch ([185.70.43.23]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rKRRT-0001VQ-0j; Mon, 01 Jan 2024 18:11:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=traductaire-libre.org; s=protonmail; t=1704150687; x=1704409887; bh=ICjgikal0qXgOLmyGK30yofnNbIlqEESxI/XxMkVg0I=; 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=aziHbkVxADWkDgDmTXBPu5fh8PV2ODGOrFF9UabCKx0SpbxNzT3D8EPWgqeeZ3JoD VWG/CejdX7sRAcx2zYTSVhjPeHq64skxi4A42Nd1aE2PK/QsGRjWyduwk/m+dykbEs prOca1GQjb2ptbzOS1/w4Du2+JIDcjs+1urL2xK6T9q8Wlg2VXWoPRnYKIhuceLWkO FSO1HtcvIY9ivKT3nt1fNmi9iqiiS/cLrsBA8xlNyzeQjWgnchaQKerIgheDDhFEd5 7qQVBWYhNZ8ChT+8zkgcqUYcFMMRZI15P45+F70C2Blrp98vh0C3e2qujrNMWx9XLa D8z9i/3rPQvcQ== In-Reply-To: <83mstp11sz.fsf@gnu.org> Feedback-ID: 92162971:user:proton Received-SPF: pass client-ip=185.70.43.23; envelope-from=jean.christophe.helary@traductaire-libre.org; helo=mail-4323.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: Mon, 01 Jan 2024 22:20:42 -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:314440 Archived-At: > On Jan 2, 2024, at 1:00, Eli Zaretskii wrote: >=20 > Finding an efficient way of updating translations of the manuals is a > worthy goal, but it's a separate issue. At least in the case of > ses.texi (and many other manuals in doc/misc) the rate of changes is > quite low, as you can see from "git log". It=E2=80=99s an issue I=E2=80=99m discussing here because you suggested tha= t we discuss=20 translation issues here :) >> If we were to have a robust translation process within the emacs >> repository (and there is no reason why we can=E2=80=99t, since all the m= ajor >> free software endeavours around have one), we=E2=80=99d need an intermed= iate >> location where PO files are generated (with po4a) as the documentation >> evolves. And translators would update the translations found there, and >> there would be a process that converts back the translations to texi >> and puts them in the proper location (the one that was decided upon >> here). >=20 > If and when you decide on doing that, I'm guessing that we will need > to keep the original "source" files for the translations in the Git > repository, and find a suitable way of producing *.texi from them. > I'm not sure po4a is the best alternative; we should probably consider > others as well and find what is best for us. Do you have other alternatives in mind? I personally don=E2=80=99t have a= =20 preference for PO/po4a either but po4a is probably the best solution=20 around for handling texi files at the moment. If the Emacs/TextInfo=20 projects manage to provide a robust solution for translating the=20 documentation that does not depend on po4a, that would be awesome,=20 though. What matters is that we have an intermediate format with bilingual=20 chunks. The 2 main formats in the area are PO and XLIFF and for=20 historical reasons the free software community is using PO. XLIFF is better at associating reference data (previous similar=20 translations, terminology) and works with associated XML standards (the=20 =E2=80=9Cchunks=E2=80=9D are based on SRX, terminology uses TBX, reference = translations=20 use TMX, etc.) but requires translation tools that understand all the=20 underlying XML structure. Both formats require a process similar to what gettext does with code=20 files. If we were not to use an intermediate format and directly use texi,=20 we=E2=80=99d need a translation reference format, like TMX, but it could be= =20 translated PO files, since they share a similar structure. The=20 translators would translate chunk by chunk and need a tool that=20 identifies already translated chunks from the reference format and use=20 them instead. If we want a robust translation process, there is no way around using=20 bilingual chunks at one point in the process, but I=E2=80=99m biased becaus= e=20 translating is my job and the current processes revolve around that so=20 maybe I=E2=80=99m not seeing things that are more obvious. > I think we cannot "delegate" anyone else to keep the sources for us. > GNU projects must keep all the sources as part of their tree, and the > release tarballs must include all the sources required to produce the > final products. So keeping this in a separate repository as the means > of avoiding a dependency on some tool is not an acceptable solution > for us. Oh. I had not thought about it that way. Interesting. Thank you. My point was not about delegating to avoid a dependency on some tool so=20 much as letting translator groups do things the way that=E2=80=99s best for= =20 them. That=E2=80=99s why I understand that there is a need to keep technica= l=20 discussions here, but for obvious reasons most translations-related=20 discussions should not take place here (and that=E2=80=99s also the reason = why=20 there is a user list for emacs). I=E2=80=99d rather see all the infrastructure hosted within the Emacs proje= ct. --=20 Jean-Christophe Helary @jchelary@emacs.ch https://traductaire-libre.org https://mac4translators.blogspot.com https://sr.ht/~brandelune/omegat-as-a-book/