Re: [patch] Fixes and improvements in org-latex-language-alist (was: ox-latex language handling in Org-9.5 vs 9.6)

[Max Nikulin <manikulin@gmail.com>]

On 12/09/2023 16:05, Ihor Radchenko wrote:
> Max Nikulin writes:
> 
>> Every piece of code accessing this public constant must implement
>> fallback from e.g. "de-ch" (or de_CH) to "de". Or to "en" for an
>> unsupported language.
> 
> Not necessarily. I mostly thought about some unconventional code that
> uses the constant for some reason unexpected to us. We do not want to
> break that.

My point is that direct usage of `org-latex-language-alist' should be 
discouraged.

>> This languange-region identifiers may be written in different way
>> (dash/underscore, case), but they are used specify POSIX locale LANG,
>> LC_* and extensions like LANGUAGE, so in some cases human friendly names
>> may be less convenient.
> 
> Sorry, but I do not follow you about the downsides of "human friendly" names.

I am not against them for the "#+language" keyword (however I am unsure 
concerning e.g. human variant for de_IT). In the code I would prefer 
ll_RR locale identifiers as a widely accepted practice.

>>> Though I am not sure if we can easily handle tricky
>>> cases like weird installation directory for TeXLive or MikTeX.
>>
>> kpsewhich babel-de.ini
> 
> which may not be in the PATH.

 From my point of view it is a call to trouble. E.g. I have no idea how 
to determine if LuaLaTeX is installed. Notice that in Debian the 
executable file is provided by

     texlive-latex-base: /usr/bin/lualatex

while actually texlive-luatex must be installed to make lualatex usable. 
Unsure if there is a better way than

     kpsewhich -engine luahbtex lualatex.fmt

and I am not sure that this particular command is reliable enough.

Moreover kpsewhich may help to detect if some packages are available for 
export or a fallback to less advanced ones should be used instead.

>> /usr/share/texlive/texmf-dist/tex/generic/babel/locale/de/babel-de.ini
> 
> which is not true on Guix, or when installed under /opt via make install.

It is the exact reason to use kpsewhich. Besides install paths it 
respects TEXMF environment variables that may additional user-specific 
directories to search path.

> I did not mean the conventional distros that follow conventional naming
> schemes, but the edge cases - I see no point adding automation just to
> fight various non-standard user installations later. It will not make
> maintenance any easier.

I am considering generating of some locale data on a developer machine 
that has all necessary packages installed. In general I am against 
storing of autogenerated files in git, but in this case it may have sense.