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.
