On Tue, Jul 21, 2026 at 11:52:31AM +0100, Gavin Smith wrote:
> On Sun, Jul 19, 2026 at 05:30:42PM +0200, Patrice Dumas wrote:
> > Hello,
> >
> > I propose
> > main_manual_name-LL or main_manual_name_LL
> > if the manual name is not translatable. If the manual name is
> > translatable, it could be possible to translate the manual name, using:
> > translated_manual_name
> > or
> > translated_manual_name-LL
> > but it seems somewhat more complex to me for tools like gendoc.sh that
> > could process automatically translated manuals.
> >
> > Other options could have been main_manual_name.LL, but . is usually used
> > for extensions, and LL/main_manual_name but it requires some changes in
> > the converters and Info readers, which I would like to avoid.
>
> help2man seems to use help2man-LL, e.g. help2man-es for Spanish. help2man
> is one project with several translated manuals, for some reason.
>
> I think this should be left to the writers of the manual. texi2any
> certainly should not add a suffix to the output file name (I'm not sure
> if you were proposing this) as this would conflict with existing uses.
I did not propose that texi2any add the suffix, my proposal is also what
you say just below, to have the suffix in the Texinfo source manual name.
> We could suggest/recommend using such a suffix in the source file name,
> e.g. help2man-es.texi.
That is my proposal.
> > All the output manuals could be installed in the same directory in the
> > the default case.
>
> This appears to contradict your recommendation in the other thread to
> use a separate dir file for manuals in a particular language, in a separate
> directory.
I already answered in the other thread, if we install manuals in LL, it
means that we need to add the LL information in the Info file and
process it with install-info, and have /usr/share/info/LL added to the
INFOPATH, either manually by the user, or automatically based on
LANGUAGE or something like that. This is possible, but requires some
changes to the commands, in contrast with installing all the files in
the same directory. Since that kind of change is needed for dir anyway,
this is not such an issue, however.
> > For htmlxref, it could be possible to have some automatic
> > generalisation when there is no existing entry, ie, when there is a
> > language in the output file name like mymanual-LL, possibly with a check
> > of matching @documentl* in the tree and there is
> >
> > mymanual node ${GS}/something/mymanual/mymanual
> >
> > occurences of mymanual in the path would become mymanual-LL. Also we
> > could extend htmlxref with list of languages with translations for a
> > manual.
> >
>
> I can't follow your explanation here. What do you mean by "occurences of
> mymanual in the path"?
>
> The mymanual htmlxref entry is for links to the mymanual manual, but you
> are talking about the output file name being mymanual-LL, which is unlikely
> to contain cross-references to itself.
I will use an example. Suppose there is this entry in htmlxref:
mymanual node ${GS}/something/mymanual/mymanual
and a new possibility in htmlxref to specify the languages like
mymanual lang fr,fr_FR,sv@latin1
then the HTML converter would automatically consider that, for a manual
that has:
@documentlanguage fr_FR
there is, in this manual (which is not mymanual* but a manual that
refers to mymanual*) for cross-references to mymanual-fr_FR, the
following autogenerated entry in htmlxref:
mymanual-fr_FR node ${GS}/something/mymanual-fr_FR/mymanual-fr_FR
Similar for a manual having @documentlanguage fr and @documentlanguage
sv plus @documentscript Latn.
This mandates using - (for example), but if it is not the case, it
should be possible to manually add the entry, like
mymanual_fr_FR node ${GS}/something/mymanual_fr_FR/mymanual_fr_FR
--
Pat
