Re: Translating Emacs manuals is of strategic importance

[Eli Zaretskii]

> Date: Fri, 05 Jan 2024 02:36:29 +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
> 
> 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.

This is at least inaccurate, and quite a bit unfair, I must say.  The
fact that Emacs does not yet support localized translated messages is
correct, of course, but explaining that by lack of interest and
practical commitment is not.  I think even the response of the
maintainers to Vincent's submission speaks volumes about the level of
our interest and commitment.

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

Silly things people sometimes say here aside (and everyone who reads
this list should be able to distinguish between wrong or even silly
opinions of some and the official POV of the Emacs maintainers), the
projects that have translations all do it using gettext and the
related infrastructure.  All they need is to wrap strings in the
various printf's with _(), and the rest is a matter of having a
message catalog translated to the target language.  So it is quite
simple for those programs to provide localized messages.  (Though even
with that problem solved by gettext, some languages cannot be
adequately supported -- for example, gettext is abysmally inadequate
for R2L languages, and it is no accident that most projects have no
translations for such languages.)

By contrast, the few discussions of this we had here clearly show that
gettext is not enough for Emacs.  We need more elaborate and more
flexible infrastructure that suits the unique requirements of Emacs,
where the line dividing code from documentation is so blurred that the
gettext's model is no longer applicable.  In addition, gettext is not
suited well to a project where most of the code is loaded at run time
as needed, and the documentation strings and messages to the user are
read from several sources, instead of being hard-coded in the code --
how do you package message catalogs in this situation?

Last, but not least: most of meaningful messages in Emacs are not
printf-style phrases, but doc strings, and gettext doesn't handle
those.  (The only other GNU project I know of which has similar doc
strings -- GDB -- doesn't translate those doc strings, although the
GDB messages are translated, and that is not a coincidence, IMO.)
There are also other non-trivial issues, as discussed in the past.

So before you accuse the project as a whole in being "passively
dismissive" wrt translations, a reality check is in order.  The real
reasons are not the lack of interest or us being lazy.

The real reason is that no one has yet stepped forward to take this
job upon themselves, let alone saw through that the job is done to the
degree that it can be used project-wide.  And since no significant
development in Emacs ever happens without someone volunteering for the
job and then seeing it through, this job still awaits its volunteers.
All of the similar significant additions to Emacs in the related areas
happened only because we were lucky enough to have volunteers.  Some
examples:

  . the Unicode support
  . the support for bidirectional editing and R2L languages
  . the support for modern complex text-shaping

If we were not lucky, Emacs could have been lacking these important
features.  For example, we could still be devoid or supporting R2L
languages, which are spoken by hundreds of millions of people.  Then
someone else could perhaps accuse us of being "passively dismissive"
about bidi.

What this means is that serious translation of doc strings and
messages in Emacs will not happen unless someone starts working on it,
and working seriously.  Working, not talking.  And since no one
stepped forward for such a long time, one possible explanation of that
could be that the Emacs community, as a whole, doesn't consider this a
significant problem.  The community, not the project management.  (If
this is what people think, I personally disagree with them, but then
Emacs is a community-driven project, and it is hard to take it in
directions that the community doesn't support, let alone supports
enthusiastically.)

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

Nothing is farther from the truth.  There was no need to "stir the
pot": as soon as Vincent came up with his translation, he was
immediately asked whether adding that to Emacs would be possible.
That alone should speak volumes of the attitude of the current (and
past) maintainers wrt making Emacs friendlier to people whose first
language is not English.

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

We could create a translation team for Emacs, but the TP
infrastructure is IMNSHO inappropriate for translating large manuals.
(In case you didn't know, I'm one of the TP team leaders, so I know
something about that.)  As with many other aspects of i18n, Emacs
needs its own special solutions here, or at least the Texinfo project
should come up with a solution for the GNU Project as a whole, since
we are not the only GNU project that uses Texinfo.  It is unreasonable
to expect the Emacs project to solve problems that are common to all
the GNU projects, and accuse us of lack of interest because those
problems are not yet solved satisfactorily.

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

See above: the existing communities don't need to solve the problems
that are central to Emacs in this area, they don't even come close.
So, while PO is definitely one alternative we should consider, it is
not necessarily the right one for our purposes, certainly when
translation of large and frequently-changing manuals is concerned.