On Wed, Apr 15, 2026 at 04:24:53PM +0100, Gavin Smith wrote: > en-boont represents Boontling which doesn't appear to be a very important > phenonemon, based on: https://en.wikipedia.org/wiki/Boontling
Indeed, I read this one, it does not seems to clearly be a variant worth registering. > It just seems that the task of dialect classification is very susceptible > to low quality information and even hoaxes. > > Now I'm not saying that there is anything wrong with how the IANA is > allocating > codes, but we should be aware of the potential for issues and controversies. I agree, but to me it is not a reason to avoid all the variants. > My concern is there has been very little apparent problems with the > current way of naming a language, in Texinfo, in POSIX locales, or in > the gettext translation framework. Hence I'm cautious about complicating > the system used by opening up to this system for classifying dialects. Not being able to specify important variants is an issue. In my opinion, the fact that it has not been an issue shows more the lack of diversity in the Texinfo users than the lack of a need to design a system that allows to specify all the languages, including variants. > I think it's okay to add a command for specifying language sub-variant, > as long as the complexity of referencing the language is limited to that > one language. As before: > > @documentlanguage sr > @documentlanguagevariant ekavsk > @documentscript latin > > Only the "@documentlanguagevariant" command would need to be defined in > terms of BCP 47 or the IANA language subtag registry. Not in term of BCP 47, but in term of IANA language variants subtag registry. We also use the IANA registry for @documentlanguage as it is consolidated here and up to date, the ISO standards are not open standards and harder to get updated and in a format easy to parse. > Then in the future, if there is any issue about the definition of language > variants, or other systems become more prominent, we would just need > to change the documented usage of this one command. Not even the usage, only the source of data. > ISO language code would continue to be within the @documentlanguage line, > as in "@documentlanguage fr_CA". Indeed. > If there was a need for more than one variant, this could be given as > a comma-separated list on the @documentlanguagevariant line: like the > argument to @example. There is such a need. What you propose seems good to me, quite Texinfo-ish. > Script, as you say is less specific than language dialect (if I understand > correctly) so can be given in a separate command. (First you specify > the spoken language, then the script for writing it down.) I think we > can avoid the use of @modifier suffixes to language identifiers. Indeed. They are emitted, but in the strings used by gettext only. -- Pat
