Re: SES manual French translation (Re: Where to contribute manual translations ?)

[Jean-Christophe Helary]

> On Jan 2, 2024, at 1:00, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> 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’s an issue I’m discussing here because you suggested that we discuss 
translation issues here :)

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

Do you have other alternatives in mind? I personally don’t have a 
preference for PO/po4a either but po4a is probably the best solution 
around for handling texi files at the moment. If the Emacs/TextInfo 
projects manage to provide a robust solution for translating the 
documentation that does not depend on po4a, that would be awesome, 
though.

What matters is that we have an intermediate format with bilingual 
chunks. The 2 main formats in the area are PO and XLIFF and for 
historical reasons the free software community is using PO.

XLIFF is better at associating reference data (previous similar 
translations, terminology) and works with associated XML standards (the 
“chunks” are based on SRX, terminology uses TBX, reference translations 
use TMX, etc.) but requires translation tools that understand all the 
underlying XML structure.

Both formats require a process similar to what gettext does with code 
files.

If we were not to use an intermediate format and directly use texi, 
we’d need a translation reference format, like TMX, but it could be 
translated PO files, since they share a similar structure. The 
translators would translate chunk by chunk and need a tool that 
identifies already translated chunks from the reference format and use 
them instead.

If we want a robust translation process, there is no way around using 
bilingual chunks at one point in the process, but I’m biased because 
translating is my job and the current processes revolve around that so 
maybe I’m 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 
much as letting translator groups do things the way that’s best for 
them. That’s why I understand that there is a need to keep technical 
discussions here, but for obvious reasons most translations-related 
discussions should not take place here (and that’s also the reason why 
there is a user list for emacs).

I’d rather see all the infrastructure hosted within the Emacs project.



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