Infrastructure proposal (Re: Translating Emacs manuals is of strategic importance)

[Jean-Christophe Helary]

> On Jan 5, 2024, at 9:35, Stefan Kangas <stefankangas@gmail.com> wrote:
> 
> Jean-Christophe Helary <jean.christophe.helary@traductaire-libre.org>
> writes:
> 
>> Using PO for the manuals will bring to the Emacs community a
>> considerable number of qualified and experienced free software
>> translator teams.
>> 
>> It will also have the benefit of allowing the easy conversion of
>> already existing translations so that they can be provided to teams who
>> want to update them.
> 
> At the very least, it should be well worth our time to open the door.
> Then we will see what type of interest and contributions we can garner.
> Maybe it will take some time.
> 
> This is why I think it would make sense to get our basic processes in
> place.


* translation and proofreading/validation

Now that we have emacs/doc/lang/[lg], what do you think of having 
something like emacs/doc/lang/drafts/[lg], where people would commit 
draughts to be proofread/validated?

Let’s say that we’d have a committer per language (what’s called a 
“language lead”). Contributors would send her the draughts they have 
worked on. The lead would commit the file to /drafts/[lg] and make a 
call here for proofreaders, for ex:


```
Subject: [FR] emacs-gnutls.texi ready for proofreading

emacs-gnutls.texi est prêt pour la révision. Utilisez cette liste pour 
échanger sur les problèmes importants et pour envoyer vos patches.
```

or something similar.

And interested parties would do their things: discuss issues here, in 
French, or Japanese, or Chinese, depending on the target language or 
send patches, etc.

For some manuals, there could be groups that already have an 
infrastructure for translation, like what is emerging for org-mode. In 
such cases, the group could send a final document right away for 
committing, considering that all the validation has taken place 
upstream.


* version numbers

We’d need to have somewhere in the translation the base commit number 
of the English original, so that when the file is in 
emacs/doc/lang/[lg] people know how recent the document is.


* reduction of redundant work

To make sure people don’t translate documents that are already worked 
on, we’d need a matrix where the files are assigned, and willing 
contributors could check the matrix and would also announce their 
willingness to work on such and such chapter here (pretty much like the 
W3C does for its translation process), for ex:


```
Subject: [FR] quelqu’un travaille sur ido.texi ?

J’ai vérifié la table des assignations et on dirait que personne ne 
travaille sur ido.texi. Je peux le prendre ?
```


* technical requirements

An extra step would be a technical requirement that the file was 
properly checked for spelling/grammar with the tools that Emacs 
provides and that it properly builds on the various systems where it 
was handled, to ensure that the lead does not have to do too much grunt 
work on the deliverables.


* information

We’d need a readme file to make all that explicit.


* publication

For each emacs release, the texi files would be compiled into 
appropriate formats (minimally info) so that people can easily install 
them.



I think we basically only need these “steps” here (besides for the 
copyright assignment). All the rest would grow “organically” behind the 
scenes. Have I missed something?

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