emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: @dircategory (Re: Translating Emacs manuals is of strategic importan


From: Eli Zaretskii
Subject: Re: @dircategory (Re: Translating Emacs manuals is of strategic importance)
Date: Sat, 06 Jan 2024 22:37:28 +0200

> From: Gavin Smith <gavinsmith0123@gmail.com>
> Date: Sat, 6 Jan 2024 20:02:32 +0000
> Cc: Eli Zaretskii <eliz@gnu.org>,
>       Jean-Christophe Helary <jean.christophe.helary@traductaire-libre.org>,
>       vincent.b.1@hotmail.fr, emacs-devel@gnu.org, rms@gnu.org,
>       help-texinfo@gnu.org
> 
> > I'd probably take it a step further and completely hide translations (by
> > default at least) outside of relevant locales.  We already do basically
> > that for the tutorial.
> 
> I think it would be a good idea to hide them.  This could be dealt with
> by installing translated manuals in a different location.

This would be un-Emacsy, I think.  Emacs does not obey the locale so
completely, it changes the defaults to follow the locale, but allows
the user to request variants that are not the locale's defaults.  For
example, the command to show the tutorial by default shows the
tutorial for the locale's language, but it can optionally be requested
to show the tutorial in any other language specified by the user.

I would prefer to have something similar for translated manuals.

> For example, in my top-level dir node, which I see by running "info",
> I have the following lines:
> 
> Развој програма
> * help2man-sr: (help2man-sr).   Самостално стварање 
>                                   странице упутства.
> 
> Розробка програмного забезпечення
> * help2man-uk: (help2man-uk).   Програма для 
>                                   автоматичного створення сторінок 
>                                   підручника (man).
> 
> 软件开发
> * help2man-zh_CN: (help2man-zh_CN).
>                                 自动手册页生成。
> 
> These are of no interest to me as I can't read the languages.  This
> could potentially get worse if more manuals were translated and the
> translations installed by default in the default Info directories.

Whether to actually install those is a separate issue.  A downstream
distro could, for example, have separate installible components for
each language.  But if these _are_ installed, then why shouldn't they
be available?

> - Support installation of manuals in different languages, along these lines:
>   . support a LINGUAS file or variable saying which subdirs LL in the
>     source to descend into (under doc/).
>   . within each subdir LL, install the info files into $infodir/LL,
>     and run install-info on $infodir/LL/dir.
>   . info (both emacs and standalone) should read $infodir/$LANG/dir
>     as the first dir file, and likewise read info files first from
>     $infodir/$LANG, before falling back to $infodir.
>   . consider ways to avoid installing images in both places.
>     In fact, images probably need to be installed in a subdir
>     $infodir/MANUAL/ in the first place, to avoid conflicts of having
>     the same image name in different manuals.

I think this implicitly assumes that only a single LANG plus the
English manuals are ever installed.  If a user installs manuals for
many languages, this kind of arrangement will make INFOPATH have too
many directories, which will eventually slow down the search for
manuals.

I think a flat directory with FOO-LL.info files for language LL is a
better idea.

> The $infodir/LL and $infodir/LL/dir part of this seem like a good idea
> to me.  This would require changes in package build and installation
> systems (Automake), not necessarily in Texinfo itself.  Since users
> can set INFOPATH (or Emacs equivalent) themselves, it is not urgent to
> implement special support for language directories per se in 'info'
> or 'install-info'.  This could be done once it is clear that people
> are actually using installation directories that way.

Actually, the Emacs Info reader is designed to work OOTB without any
tweaking of its INFOPATH equivalent.  So asking users to add the LL
directories would be a nuisance, I think.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]