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: Translation of manuals (was: SES manual French translation) Date: Thu, 04 Jan 2024 07:18:08 +0000 Message-ID: References: <5D3D13BC-E621-4C40-88D7-3E5805F631AB@traductaire-libre.org> <83sf3fzvk4.fsf@gnu.org> <835y0azhvo.fsf@gnu.org> <83wmsqy14p.fsf@gnu.org> <3E7CF23D-CE62-4581-80D6-E6266CEE4DF5@traductaire-libre.org> <83edexy5cy.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="17856"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Kangas , =?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 Thu Jan 04 09:22:08 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 1rLIzP-0004Hn-LZ for ged-emacs-devel@m.gmane-mx.org; Thu, 04 Jan 2024 09:22:08 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rLIyS-0001Qb-Qa; Thu, 04 Jan 2024 03:21:10 -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 1rLHzu-0003sj-Hh for emacs-devel@gnu.org; Thu, 04 Jan 2024 02:18:35 -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 1rLHzr-0002Zt-0h for emacs-devel@gnu.org; Thu, 04 Jan 2024 02:18:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=traductaire-libre.org; s=protonmail; t=1704352707; x=1704611907; bh=NTAtvdMv+5i/lpZ6f6PpKsx0wJjUyXxn7Ik6XzsghvA=; 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=Au597C7bdWBjtFel+GvIhWCSjvNquac9LcZuPv/o6JkR+8Fm3AfDcpoOc0eAcbgpP RNIfFWeqMCUvXcW21Q1v+FKjrmRovrGTyHcKy+7d1eiKKYOOl7AwAsqmA2UTLov2PB YCAOkRUEmQF++OJ4Uhs60R8yNxABJItbI4PlTT8BVZJK02RsfRYTTJMgqaFa5ZYeeq E+HsaLza5IbkhoBMyukW2NWVT/w/Ap6YW3qe3GzjfH9VszrpgY7YbBDuQE0q860tOG PVTmlXx+//2+CehzhavTXj3h76IGhe3qytIB/kwCLNxXIEl0HDWsLIJEOCuNnpEJak ZgEjiweeu06sg== In-Reply-To: <83edexy5cy.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: Thu, 04 Jan 2024 03:21:03 -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:314527 Archived-At: > On Jan 4, 2024, at 15:34, Eli Zaretskii wrote: >=20 > My experience, while certainly smaller than yours, is the opposite. I=E2=80=99m certainly not here to play an argument from authority game, so= =20 forget what I wrote. It is not relevant to the discussion at hand. > Perhaps it's because you implicitly assume that the original text was > structured and divided into sentences in the most optimal sense, More pragmatically, it is because I am a freelance worker who is paid=20 by the hour. I can=E2=80=99t allow myself to give more to the client than w= hat=20 I am paid for. I need to assume that the source document is of=20 reasonable quality and that its intent is clear. When I translate or otherwise contribute to free software projects, the=20 ethics are slightly different, but that does not profoundly change the=20 way I work. >>> @node Display Margins >>> @subsection Displaying in the Margins >>> @cindex display margins >>> @cindex margins, display >>=20 >> As long as the above strings are to be translated, they need an ID too. >=20 > Not necessarily. These present special issues in Texinfo, to be > resolved in some reasonable way. For example, if node names are > translated, pointers to them will stop working, so there's a problem > right there. In my current translation of the Emacs manual, I=E2=80=99m translating the= =20 nodes so that they make sense on their own. I agree their function is=20 mostly to work as invisible keywords/link anchors, but if the=20 translation is well done, that should not be an issue. > Index entries should be translated, of course, but they > are their own paragraph, I think, as they rarely change together. > Section names are also a paragraph of their own. >=20 >>> @c para 1234 >>>=20 >>> @c para 1235 >>>=20 >>> @c para 1236 >>=20 >> Is the numbering automatic? >=20 > If a tool exists that aids this process, then definitely. E.g., a > Lisp program. >=20 >> What if you add paragraphs in the middle, like Vincent did? Will the >> author have to check the IDs and add a number that=E2=80=99s not used al= ready? >=20 > The author or a tool, yes. >=20 >> There are plenty of issues with static IDing parts of a document. >=20 > Sure. We are in uncharted territory here, so issues are a legion. :) In all honesty, I=E2=80=99m not ready to contribute to developing such a= =20 system. Not that I don=E2=80=99t think it would not be beneficial, on the= =20 contrary, but because my skill set would not be of much help, and I= =E2=80=99d=20 rather discuss issues of already existing systems. > Translation is a human job, and translating a manual is more so, > because the context is much more important than when translating short > phrases. So it seems to me that seeing diffs in terms of paragraphs > using a format where the markers are only used to detect changes, and > the rest are text differences, is better than using the PO methods, > where the comparison with the previous version is much harder because > PO decorations are much more massive. Ok, I understand now what your issue is with PO. If we start from the=20 idea that a diff is what is going to help us find the parts to update,=20 then the less decorations the better. Decorations are irrelevant in OmegaT. Only the msgid contents is taken=20 into account. Decorations are also not shown in the OmegaT editor. I=20 just see the paragraphs, above, below, and I translate the text=20 contents without worrying about the decorations. > But we certainly should consider using PO as one possible alternative. At least until a robust system is implemented for Emacs/Texinfo. >>> When paragraph #1234 in the English original was modified, translators >>> will know that they need to update the translation of the >>> corresponding paragraph(s) (could be more than one) in their >>> translations, and nothing else. It should be easy to analyze the >>> diffs, look for the "@c para NNNN" marks, and present the translator >>> with the corresponding paragraph(s) from the translation. >>=20 >> I think po-mode already does that and all the "out of emacs" tools do >> too. >=20 > Maybe so. But I wouldn't assume that PO could be easily stretched to > this kind of jobs, since it wasn't originally designed for them. Development of po4a is ongoing (I just received a mail this morning=20 from the dev list). If it did not serve a practical and useful purpose=20 for some users I=E2=80=99m not sure it would still be around. --=20 Jean-Christophe Helary @jchelary@emacs.ch https://traductaire-libre.org https://mac4translators.blogspot.com https://sr.ht/~brandelune/omegat-as-a-book/