Re: @dircategory (Re: Translating Emacs manuals is of strategic importance)

[Patrice Dumas]

On Thu, Jan 11, 2024 at 08:09:28AM +0200, Eli Zaretskii wrote:
> > Date: Wed, 10 Jan 2024 21:52:23 +0100
> > From: Patrice Dumas <pertusus@free.fr>
> > Cc: Eli Zaretskii <eliz@gnu.org>, Stefan Kangas <stefankangas@gmail.com>,
> >     Vincent Belaïche <vincent.b.1@hotmail.fr>,
> >     emacs-devel@gnu.org, rms@gnu.org, help-texinfo@gnu.org
> > 
> > In any case, if a target manual is not yet translated, to me it is the
> > responsibility of the translator of amnual linking to it to either link
> > to the english manual, or to translate the node name in @ref even though
> > it won't lead to an existing manual and the name may need to be changed
> > later on to match with the actual name used in the translated manual.
> > To me both case could make sense depending on many criteria, such as
> > whether readers are likely to read english, whether manuals are
> > being translated...
> 
> The translator doesn't always know whether a translated manual exists
> when the translation is being written.  And even if a translated
> manual does exist, there's no reason to be sure it will be installed
> on the end-user's system.

Having nodes linking to non installed manuals is, in general, an issue.
But I do not think that defaulting to the english manual for non english
manuals is a good thing to do.  Instead, it could be confusing,
especially if the missing translated manual is not shown prominently and
an english manual is substituted without much information and would not
convey the intention of the manual writer.

In my opinion, it would be much better to design a way to help with
installing a manual that is not already installed but exists and is
linked to irrespective of the issue of translations and still leave the
responsibility to setup the cross reference to the translator.  Having
some way to check node links in Info through automatic downloading of
manuals and check of all the referencecs could be nice too, but without
any special treatments of manuals not in english.

> So it would be good to have some Texinfo feature that would make the
> behavior of Info readers more user-friendly in these cases.  Right
> now, the Texinfo features that can help are @documentlanguage and the
> suggestion by Gavin to have in the translated manual an @anchor for
> each @node with the original English name of that @node.

Having @anchor indeed can help if the translator wants to link to the
english manual with translated node names.  Still, in my opinion, it
should only happen if the translator has setup the @ref to link to the
english manual by using the english manual name as @ref manual argument.

> > In any case, I don't see any reason to do any automatic redirection in
> > the Info reader, it should remain simple and be the translators/writers
> > responsibilities.
> 
> I don't think I agree, because leaving this completely to the
> responsibilities of the translator could easily produce sub-optimal
> results.

On the contrary, I think that having translators be responsible of cross
manual references is the best possible solution.  It could mean a link
to an english or translated manual based on a choice and not on an
automatic rule.  In that case, a choice seems to be better to me.

It is different from gettext, I think.  When we use gettext having
something in english is, in most cases, better than having nothing.
For cross references between manuals I think that it is not true. Having
the information that the link does not point to an installed manual is
better than substituting an english manual. As I said above, even better
could be to have information on existing manuals (and node in them ?)
and propose to install the manual, but it is a separate issue.

> > Another reason is that it would not be possible to do the same in
> > HTML, as in HTML it is not possible to check if the target exists.
> 
> Even if this cannot possibly be done in HTML (and I'm not yet sure),
> it shouldn't stop us from doing that in Info.  After all, HTML output
> lacks several features of Info output already, and it doesn't stop us.

If we follow up the long term plan to have HTML on par with Info output
as outlined in TODO.HTML, we should think about that kind of feature and
its adaptation to HTML as early as possible in the design phase to make
things easier later on.

-- 
Pat