On Mon, Jul 20, 2026 at 02:14:12PM +0300, Eli Zaretskii wrote: > > From: Patrice Dumas <[email protected]> > > For two reasons, first, if there are many translated manuals, they will > > be a distraction in the main dir > > It is just a menu. It is very large even without translations, and no > one has yet complained. The reason, to my mind, is simple: users > rarely if ever look at that menu.
Still, if all the manuals are translated to many languages, this will be much worse. > And in any case, AFAIR the first thing that an Info reader does is > concatenate all of the DIR files it find into a single DIR node. So > the file might be smaller, but the menu in the Info reader will be of > the same length. Assuming, that is, that you are not suggesting to > also have separate INFOPATH_LL variables, and use just one of them at > a time. Which I don't think to be a good idea, because users will > likely need to consult at least some untranslated manuals. I do not think that using a separate INFOPATH_LL is good, more like * users can manually add the /usr/share/info/LL directory to their path to get the LL language specific dir that is in that directory concatenated * a command-line option, or a variable (or a special symbol in INFOPATH?) could trigger that a locale environment variable is read, which allows to get the LL language(s) specifier(s), could be LANGUAGES, for example, or similar, and based on that value, the /usr/share/info/LL directory would be added, which would contain the LL specific dir file. > > I also think (but I did not read the code), that restricting what is > > in the dir also restricts the scope of the Info commands that apply > > on all the manuals. > > It does? How? I'm probably missing something. My wild guess is that for the rare Info commands that apply to all the known manuals, such as ‘M-x index-apropos’, the concatenated dirs are used to read all the manuals. I may be wrong, the directories in INFOPATH may be scanned instead. -- Pat
