Re: Translating Emacs manuals is of strategic importance

[Jean-Christophe Helary]

> On Jan 5, 2024, at 9:34, Stefan Kangas <stefankangas@gmail.com> wrote:
> 
>>> We could perhaps consider having several "tiers" of manuals: one
>>> "nursery" for those are not yet meaningfully ready for distribution, one
>>> "attic" for those that are no longer reasonably maintained, and one for
>>> those that we actually do consider up to scratch.  The decision for what
>>> goes where could be based on a dialogue between the maintainers and the
>>> translators of various manuals.
>> 
>> This scheme is far too complicated for the number of translations or
>> translators on the horizon.

We have little translations and translators on the horizons not because 
they do not potentially exist, but because Emacs was always seen as a 
closed English-only system.

Emacs is *the* free software movement flagship. There is no equivalent 
in the history of the movement. Still, it is the one that has 
historically shown the least interest in, or practical commitment to, 
translation and localization.

The fact that most consequent free software projects have full-fledge 
translation (and translation quality) support says a lot about the sad 
state of Emacs in that regard. And translation/localization projects 
already existed pre-utf-8, so it’s not so much the lack of interest on 
the Emacs side than the passive dismissal of anything that smells like 
translation related (I’ve read a number of very silly things here, and 
not so long ago, about the fact that people who needed to work in Emacs 
should be able to read English, etc.)

I’m really glad that Vincent’s commit has actually started to stir the 
pot, because the mere fact that we did not have a location within the 
Emacs sources to put our translations was probably one of the major 
show stoppers for all translation endeavours.

Now that we have that, we can, and should, consider how to deal with 
the new situation. Right after Vincent’s first commit, I did a rough 
check and found dozens of trivial mistakes. I mentioned them here and 
Vincent was quick to fix them (I did not check the fixes).

So we need some sort of QA process. The discussion is, does the QA take 
place here, on devel, or in other places where translation “teams” do 
all the things they need to do before a final commit.

The Translation Project has a solution. Free software maintainers send 
(po) files to the TP, the files are handled by the various teams and 
sent back to the TP (after appropriate QA and validation) to be 
included in the final builds. Major gnu/linux distributions too have 
solutions. Each distribution has a translation team with all the 
committed languages represented, they have deadlines, QA checks, 
proofreading, etc. And things work and distributions (including their 
manuals) are published as multilingual systems.

Emacs and TexInfo being what they are, it is fair to suggest that we 
should have a system that only relies on the two for translation, hence 
the discussion about IDing texi chunks and so forth, instead of relying 
on yet another dependency (po4a) and a format that’s not easy on the 
eyes (po).

But the thing is that all existing free software multilingual 
communities work with PO already, so offering a temporary bridge to PO 
would ensure that we get the best expertise from already existing teams 
and that would give us the time to elaborate on what part we want to 
have Emacs and TexInfo play in the process.


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