On Fri, Aug 07, 2026 at 08:37:26AM +0300, Eli Zaretskii wrote: > > From: Gavin Smith <[email protected]> > > Date: Thu, 6 Aug 2026 21:35:19 +0100 > > > > 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. > > At least for us the maintainers of GNU packages, the above model would > be a significant annoyance, because it makes it hard to read and > modify a manual for an arbitrary language. Installing a locale, > especially if it is some special or exotic one, and turning it on is > not always possible, let alone easy. What if I want to read the > manual translated into some language because someone reports a mistake > there, or just because I'm interested or maintain manuals in several > languages? why should I need to install and turn on a locale for these > cases?
I agree completely. > More generally, IMO the time where internationalization was identical > to localization has long passed. We live in a multilingual world, > where several different languages and scripts are routinely used on > the same computer at the same time, and frequently in the same > program. Selection of a document written in a certain language should > no longer be tightly coupled to the locale, only the default might be > derived from it. A locale defines many other settings that are truly > system-wide and should be obeyed, but the language of the documents > that I can easily choose should not depend on it. So maybe a better question than asking where translated manuals should be installed is what an ideal user experience of accessing translated manuals would be? With the "man" command, "man -L de cups" works better than "LANG=de man cups" to access the "cups(1)" page in German. This is with man-db. (A side point, but Info can display man pages as well, but doesn't handle getting translated man pages.) So one possibility is to have a command line option to Info that tries to get a translated manual. We could also have a command inside Info that looks for translated versions of the manual currently being displayed, e.g. if the user is reading "help2man" then the command would display a menu allowing the user to select among: help2man-de.info.gz help2man-es.info.gz help2man-fr.info.gz help2man.info.gz help2man-pl.info.gz help2man-pt_BR.info.gz help2man-ro.info.gz help2man-sr.info.gz help2man-sv.info.gz help2man-uk.info.gz help2man-zh_CN.info.gz (they are the translations of help2man that are installed on my system). The rule would be something like, append a hyphen to the current base manual name, so from "help2man.info.gz" the base name is "help2man", and then look for Info files starting with that prefix. If the manual already has a hyphen in the name, then we remove the part of the string after the last hyphen in the name, check if the removed part up to the file extension is in a valid format, and if so use the rest of the manual name as the prefix. Otherwise the part after the hyphen is kept. For example, if the file name is "lzip-compressor.info.gz", we check if "compressor" is a valid language locale code, which it is not, as "compressor" is not two or three characters long. So the prefix for looking for a translated manual is "lzip-compressor-". There may be false matches occasionally, like "recipe-for-cabbage-pie.info" where the "pie" should not be stripped off: so the Italian translation would be "recipe-for-cabbage-pie-it.info" and not "recipe-for-cabbage-it.info". So we could look for manuals with and without the suffix to be on the safe side. Then we could also support looking for translated manuals in other places, such as under subdirectories of the infodir. However, one concern is excessive disk access on slow file systems. (Info is the kind of program that should work on old, slow computers, or unusual use cases like accessing a remote server from the bottom of the ocean or from outer space.) If we just have one directory, or a few directories, all that is required is to load each directory listing from disk, and then scan each directory listing for a file matching the pattern. If there are language directories potentially many more directories need to be loaded: for example, if there are three infodirs each of which has 15 subdirectories, the number of directories to be loaded increases from 3 to 48 (3 * (15 + 1)) - that could impact the user's experience negatively due to an increase in control latency.
