On Mon, Aug 03, 2026 at 09:48:18PM +0200, Patrice Dumas wrote:
> On Tue, Jul 21, 2026 at 02:25:47PM +0200, Patrice Dumas wrote:
> > 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.
>
> Do we have a consensus on that subject? Assuming that we do, here is a
> more detailed proposal for discussion and implementation:
>
> * we should settle on a representation of the @documentlanguage,
> @documentscript and @documentlanguagevariant, as a LL string that can
> be used as a subdirectory. The main choices could be a BCP47 language
> tag or an XPG locale. The BCP47 language tag tend to have my
> preference, for two reasons, one is that it is the most common way to
> specify languages, and second it can already represent all the
> languages, but an XPG locale would be ok too.
I strongly prefer an "XPG locale" (I understand this as a locale identifier
looking like "en_US") to a BCP47 language tag. We should use the same
identifiers used for gettext translations, e.g. pt and pt_BR. These
are the directory names under /usr/share/locale (on Debian-derived systems,
at least, and also specified in the Filesystem Hierarchy Standard).
Document scripts or language dialects will much less often be an issue,
but these can be accommodated in the "variant" suffix, if the identifier
is of the form LL[_CC]@VARIANT.
gettext documentation changed (in May 2026) to accommodate the possibility
of specifying a dialect with a variant suffix:
@@ -3895,13 +3895,26 @@ code serves to distinguish the dialects. See
@ref{Language Codes} and
@ref{Country Codes} for the lists of codes.
@item
-@samp{@var{ll}_@var{CC}@@@var{variant}}, where @samp{@var{ll}} is an
-@w{ISO 639} two-letter
-or three-letter
-language code (lowercase), @samp{@var{CC}} is an
-@w{ISO 3166} two-letter country code (uppercase), and @samp{@var{variant}}
is
-a variant designator. The variant designator (lowercase) can be a script
-designator, such as @samp{latin} or @samp{cyrillic}.
+@samp{@var{ll}@@@var{variant}} or @samp{@var{ll}_@var{CC}@@@var{variant}},
+where @samp{@var{ll}} is an
+@w{ISO 639} two-letter or three-letter language code (lowercase),
+@samp{@var{CC}} is an
+@w{ISO 3166} two-letter country code (uppercase),
+and @samp{@var{variant}} is a variant designator.
+The variant designator (lowercase) can be a script designator,
+such as @samp{latin} or @samp{cyrillic},
+or it can indicate a dialect.
+For example, the following language codes are in use:
+@itemize -
+@item
+@samp{be@@latin} and @samp{sr@@latin} for Belarusian and Serbian,
+written in Latin script.
+@item
+@samp{uz@@cyrillic} for Uzbek, written in Cyrillic script.
+@item
+@samp{ca@@valencia} for Catalan, as spoken in the region around Valencia
+(the southern Catalan dialect).
+@end itemize
@end itemize
https://gitweb.git.savannah.gnu.org/gitweb/?p=gettext.git;a=commitdiff;h=2cc9da4ee02a0da97429d72a72fed1e447ba1ad7
https://savannah.gnu.org/bugs/?68082
Script and language variant have been both described in the same suffix.
An example of this is "sr@ijekavianlatin" to represent the Serbian language,
written with the Latin script, Ijekavian dialect. I'm not sure if there
is any process for defining the sames of such variants, other than common
usage by a user community. Presumably the gnulib bcp47 module (which
we use) can be adapted if getting the locale name is ever a problem.
This is all assuming that we need to use such directories in Texinfo for
Info files with specified languages, for more on which see below.
> * The manuals are installed in a LL subdirectory by install-info, LL being
> based on @documentlanguage, @documentscript and
> @documentlanguagevariant as described in the previous point. The
> manual information is added to the dir file in this subdirectory.
>
> The user could add such directories to INFOPATH manually.
We need to be careful about compatibility between installation location
and Info-reading program. I don't see how we can install manuals under
LL subdirectories when existing Info readers don't know to look for them
there. This is among the points that Eli raised.
I think it is fine to have them all in the same infodir, with not much
downside if any.
In short, I see no benefit to the changes being proposed. It appears to
be creating a lot of work for no reason.
It is possible that GNU/Linux distributions could make changes to put the
Info files in subdirectories, or that Automake build systems would change
to make this happen. I don't think we should change the default behaviour
of install-info to read a language from the Info file to get the name of
a directory to install the file in, as this would be backwards incompatible
and would lead to users being unable to find Info manuals.
One idea is to add an option to install-info to enable such behaviour, which
could be used by users if they want it, although this would need further
consideration.
> * The Info readers should also have a way to add the LL subdirectory
> (semi-)automatically to merge the dir directory from there to search
> for manual names and perform other computations on merged dir files.
>
> Adding the LL subdirectory(ies) could be done with
> - a customization variable in the Info readers
> - an environment variable, like INFO_LANGUAGES=LL:OO::MM_mm-Latn
> - a way to signal that the LANGUAGE environment variable should be
> used, for example a directory consisting only in a special character
> in the INFOPATH, such as @ could be considered to signal to use
> LANGUAGE, or a customization variable in the Info reader could be
> set to trigger using LANGUAGE languages to set the list of
> info languages (possibly converting XPG locale to BCP47 language
> tag).
Using the contents of LANGUAGE could be a good idea in case Info manuals
start being installed in language directories in the future. But I don't
know how commonly used LANGUAGE is by users, or if they would be likely
to set it.
I was looking at how manpages translations are handled. On my system,
there are language directories under "/usr/share/man". (For example,
"/usr/share/man/de/man1/cups.1.gz" is the "cups(1)" man page in German.)
However, it doesn't appear to be possible to access them with the "man"
command without having the locale installed for that language, e.g. if
I run "LANG=de man cups" I get an error message:
man: can't set the locale; make sure $LC_* and $LANG are correct
- as I don't have a locale de_DE etc. installed.
Not sure if that is a model worth imitating or not. It would be useful
to find out what the experiences of readers of non-English manuals was.
> Changes to be done to texi2any:
>
> when generating the Info file, the @documentlanguage, @documentscript
> and @documentlanguagevariant information should be made available in the
> Info file. I propose to use the same method as the one used to convey
> that information to Info readers that output translated strings. Given
> the previous discussion:
> https://lists.gnu.org/archive/html/bug-texinfo/2026-05/msg00009.html
> this should be through variables, Info-documentlanguage,
> Info-documentscript (and Info-documentlanguagevariant for consistency).
I think it's fine to have these in the Info file Local Variables section.
> Changes to be done to install-info:
>
> read Info-documentlanguage, Info-documentscript and
> Info-documentlanguagevariant, generate a LL language name, install
> the manual in the LL subdirectory and put the manual in the LL/dir
> file.
Discussed above.
> Changes to be done to Info readers:
>
> Cf point above on adding some language subdirectories automatically to
> the INFOPATH.
Discussed above.
