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

[Ihor Radchenko <yantar92@posteo.net>]

Max Nikulin <manikulin@gmail.com> 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.

I doubt that code using `org-latex-language-alist' is common.
But in any case, before trying to discourage the usage, we need to have
alternative API.

> 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.

Either way should work. Because we have to support ll_RR/de_IT/etc for
backwards compatibility anyway. This is a minor detail, IMHO.

>>>> 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.

We do not yet have a mechanism for fallback packages.
The idea is reasonable. Not for now though.

>>> /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.

Makes sense.

>> 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.

This sounds like an extra maintenance burden. I'd prefer not to add it.

What can be done is defining a constant in the code and adding a comment
how to generate its value in case one needs to update the babel language
info in future.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>