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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 05 Jan 2024 08:20:51 +0000
> From: Jean-Christophe Helary <jean.christophe.helary@traductaire-libre.org>
> Cc: Po Lu <luangruo@yahoo.com>, Eli Zaretskii <eliz@gnu.org>, Vincent Belaïche <vincent.b.1@hotmail.fr>, emacs-devel@gnu.org, rms@gnu.org
> 
> * 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?

I prefer to use special Git branches for that.  This is how we handle
any changes that are not yet ready to be landed on the master branch,
and I see no reason to invent special conventions for manual
translations.

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

You assume the translations will be mostly outdated.  I'm not so sure,
but if that indeed happens, we'll think of something.  I don't think
this is a hard problem to solve.

> * 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:

I'd worry about this when we have more than a couple translations.
Also, the translation matrix is maintained by TP, and I'm not sure we
should have our own copy; we could simply rely on TP in this aspect.

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

Every piece of documentation submitted to Emacs is expected to be
spell-checked, and Emacs supports spell-checking of every language for
which the available spell-checkers have dictionaries.  So I don't see
any special problem here.

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

Yes.  Feel free to submit it.

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

That's part of the release procedure, so there's no reason to consider
it specially.  We already have translated reference cards, for example
(see etc/refcards/ in the Emacs tree), from which we generate PDF when
a release tarball is prepared.