Re: Translation of manuals (was: SES manual French translation)

[Jean-Christophe Helary]

> On Jan 4, 2024, at 15:34, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> My experience, while certainly smaller than yours, is the opposite.

I’m certainly not here to play an argument from authority game, so 
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 
by the hour. I can’t allow myself to give more to the client than what 
I am paid for. I need to assume that the source document is of 
reasonable quality and that its intent is clear.

When I translate or otherwise contribute to free software projects, the 
ethics are slightly different, but that does not profoundly change the 
way I work.

>>> @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.

In my current translation of the Emacs manual, I’m translating the 
nodes so that they make sense on their own. I agree their function is 
mostly to work as invisible keywords/link anchors, but if the 
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.
> 
>>> @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.

:) In all honesty, I’m not ready to contribute to developing such a 
system. Not that I don’t think it would not be beneficial, on the 
contrary, but because my skill set would not be of much help, and I’d 
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 
idea that a diff is what is going to help us find the parts to update, 
then the less decorations the better.

Decorations are irrelevant in OmegaT. Only the msgid contents is taken 
into account. Decorations are also not shown in the OmegaT editor. I 
just see the paragraphs, above, below, and I translate the text 
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.
>> 
>> 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.

Development of po4a is ongoing (I just received a mail this morning 
from the dev list). If it did not serve a practical and useful purpose 
for some users I’m not sure it would still be around.


-- 
Jean-Christophe Helary @jchelary@emacs.ch
https://traductaire-libre.org
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/