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: SES manual French translation (Re: Where to contribute manual translations ?) Date: Mon, 01 Jan 2024 18:00:28 +0200 Message-ID: <83mstp11sz.fsf@gnu.org> References: <837cky94rm.fsf@gnu.org> <83v88i77ui.fsf@gnu.org> <831qb45fog.fsf@gnu.org> <50A7AFED-DA37-4212-9ED1-7D906C34B6B2@traductaire-libre.org> <83o7e51bws.fsf@gnu.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="9010"; mail-complaints-to="usenet@ciao.gmane.io" Cc: vincent.b.1@hotmail.fr, stefankangas@gmail.com, 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 Mon Jan 01 17:01:55 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 1rKKjh-0001ou-PE for ged-emacs-devel@m.gmane-mx.org; Mon, 01 Jan 2024 17:01:53 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rKKie-00076K-9a; Mon, 01 Jan 2024 11:00:48 -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 1rKKic-000768-C1 for emacs-devel@gnu.org; Mon, 01 Jan 2024 11:00:46 -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 1rKKib-0006cH-De; Mon, 01 Jan 2024 11:00:45 -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=RhqvqA7nbeQlXpkkSVvlOSJRAGQic6vF60hKDM6mJBI=; b=abwqrGCzvP3WUsui6BSV 4AHLIb8C4vxqtM9vZfJ3h7V6WQSJSFIurY82MFa8on3oDRlIIqcPiZcgQECaxhagXeCPPa6yNRamh 5OfU9yf2JMkovNbmtYCT4eQDZ1NS1Abtfv//yT2Z7vKjA3bVpuT+1ElRenO2oYtWDywqBXVEKL26f vvoCqTGsThWUQdVd5kMlMnBcNnT3cFS1uJXWHjBmA1ocKqYkdcUewBHS/IARj66YGPIFVoMoPsXjV zUczGyZk/zmGU+qITxV59zwnTsVZtnELIOkN/qpry3Ee2jqH1n6KVAiKIo5maXlyDDF3unAP/VRoO JJM3N30dzahf8A==; In-Reply-To: (message from Jean-Christophe Helary on Mon, 01 Jan 2024 12:56:42 +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:314424 Archived-At: > Date: Mon, 01 Jan 2024 12:56:42 +0000 > From: Jean-Christophe Helary > Cc: Vincent Belaïche , stefankangas@gmail.com, emacs-devel@gnu.org, rms@gnu.org > > >> https://git.savannah.gnu.org/cgit/emacs.git/tree/doc/misc/ses.texi#n168 > >> > >> Even if they're tagged as @ignore, I'm not sure that's good practice > >> for potential translators to other languages. > > > > Those should be moved to ses-fr.texi, possibly together with the > > original English text and some references to it. Keeping those > > comments in ses.texi is not TRT. > > TRT? The right thing? Yes. > My opinion is that translators should not work directly in texi format, > for the reasons that I mentioned earlier in the thread, namely because > emacs documentation evolves quickly and all the problems identified in > such localization/translation processes have found solutions with PO > based translation processes. 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". > If we were to have a robust translation process within the emacs > repository (and there is no reason why we can’t, since all the major > free software endeavours around have one), we’d need an intermediate > 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). 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. > If we were to do that within the emacs repository/development process > that would mean adding a dependency to po4a, having an automated > process that triggers po4a when a documentation file is modified, > triggering po4a when a po has been committed to convert the file back > to texi, and copying the proper files to the emacs docs files hierarchy. > > Or maybe we could have that done manually (I could install the PO files > in a dedicated repository when I see modifications to a file). > > I’m talking about that when I say “other repository”. What I’m doing in > my repo is basically providing PO files semi-regularly to people who are > interested and I happen to translate the PO files in OmegaT (but that’s > not relevant to the process really since one could use po-mode in emacs). > It’s also the way other projects work. They “delegate” the process to > specialized localization groups and each group has a few committers > that handle the installation in the “mother” project. 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.