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: Translation of manuals (was: SES manual French translation) Date: Thu, 04 Jan 2024 08:34:05 +0200 Message-ID: <83edexy5cy.fsf@gnu.org> References: <8A22A273-11F5-449C-A2A4-2E8C68CCF1FE@traductaire-libre.org> <83ttnvzwlw.fsf@gnu.org> <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> 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="31440"; 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 Thu Jan 04 07:35:23 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 1rLHK6-0007uK-Qc for ged-emacs-devel@m.gmane-mx.org; Thu, 04 Jan 2024 07:35:23 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rLHJG-0007Qj-9N; Thu, 04 Jan 2024 01:34:30 -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 1rLHJE-0007Qa-6d for emacs-devel@gnu.org; Thu, 04 Jan 2024 01:34:28 -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 1rLHJC-0002sZ-T4; Thu, 04 Jan 2024 01:34:26 -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=qrxInNnbTtG9KW1bjANfL31LuMMfvMwYdGARgjg3H2o=; b=Js6YKEvxcaFG8I3ySN5S QD+tU3IXqF5LG8OMhpA2ogsQJQCcBaSd5qPV/uTcRx8cOYQMiDmMwgt3AN0X3eiDRCp26lyC3RxOl MlHSk0njlSI/ftGDLuo5prrdh0EsgvAk6DrRU0G1DIORpIVsdE1I2KXLr2zGpFcqbkUvuM21RpWHn /COovQJBQdEk3sYwdhBb+9spdx8UvFVShL9/Yh5+hBwPakMzGQt/5nYtFfEDqb7jdzMNm/XQBfmxO Lv0mLnA4tl/k8u98U0HJd4VOUtOwoAKFFvhYAvdqB/jqs1sGHgpFtMX3he1DVcoyh8ENyPzAaH8uM kX5H0WzZ38ualg==; In-Reply-To: <3E7CF23D-CE62-4581-80D6-E6266CEE4DF5@traductaire-libre.org> (message from Jean-Christophe Helary on Wed, 03 Jan 2024 23:14:13 +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:314521 Archived-At: > Date: Wed, 03 Jan 2024 23:14:13 +0000 > From: Jean-Christophe Helary > Cc: stefankangas@gmail.com, vincent.b.1@hotmail.fr, emacs-devel@gnu.org, rms@gnu.org > > > On Jan 3, 2024, at 22:53, Eli Zaretskii wrote: > > > > If context is important when translating technical documentation (and > > it is IME), then any change in a paragraph will in many cases affect > > more than the sentence corresponding to the one modified in English. > > > > Moreover, a good translation of a paragraph will in many cases produce > > a translated paragraph without 1:1 correspondence between sentences. > > So changes in the original will need to consider much more than a > > single sentence anyway. > > I’m not sure this is the place to discuss translation theory and as a > practitioner who pays my bills mostly with translation I can say with > confidence that over the millions of words I’ve translated in more than > 20 years (including published translations), there are only few cases > where I needed to fundamentally alter the structure of a paragraph. My experience, while certainly smaller than yours, is the opposite. Perhaps it's because you implicitly assume that the original text was structured and divided into sentences in the most optimal sense, whereas I many times find it not to be so, and my translations are therefore explain the subject better (IMO) than the original and their structure is more logical. And that's even before we consider the fact that the optimal structure in general depends on the language. > Working both from Japanese and English to French on contracts varying > for poetry to electronic circuitry, I think my experience is wide > enough that I can assert this: in a time of dehumanization of whatever > technology touches, it’s OK for translators to say that a good > translation often requires changing a lot of things. In practice, > though, paragraph structure is rarely where change happens. Simply > because it is easier to make a good translation by respecting paragraph > structure. Now experience may vary, and different language pairs may > require different arrangements. IME, I read a sizeable chunk of text first, and then express the ideas in that chunk the best I can. Sentence by sentence translation is something I frequently find to be inadequate. There are also specific difficulties with terminology: where some term sounds very differently, grammar-wise, in another language, there's no other way than to restructure the sentences to make the text sound natural in its language. Language grammar can also get in the way: some languages have 3 genders, other only 2; the use of construct state has different rules in different languages; etc. Catering to these differences alone will many times necessitate changes in sentence order and paragraph structure, to avoid text that reads like it was written in another language or translated by the likes of Google Translate. > > @node Display Margins > > @subsection Displaying in the Margins > > @cindex display margins > > @cindex margins, display > > As long as the above strings are to be translated, they need an ID too. 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. 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. > > @c para 1234 > > > > @c para 1235 > > > > @c para 1236 > > Is the numbering automatic? If a tool exists that aids this process, then definitely. E.g., a Lisp program. > What if you add paragraphs in the middle, like Vincent did? Will the > author have to check the IDs and add a number that’s not used already? The author or a tool, yes. > There are plenty of issues with static IDing parts of a document. Sure. We are in uncharted territory here, so issues are a legion. > The ID is the paragraph. Which makes sense, because translators can > know that a paragraph has not been translated because its ID is not > associated with contents. 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. But we certainly should consider using PO as one possible alternative. > > 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. > > I think po-mode already does that and all the "out of emacs" tools do > too. 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.