Re: [patch] Fixes and improvements in org-latex-language-alist

[Ihor Radchenko]

Juan Manuel Macías  writes:

> [1] I think also that in this function there was an unhappy decision:
> using a syntax that is not from polyglossia but from babel leaves the
> user with little freedom of action, since polyglossia has more 'keyval'
> options, not only language variants. For example, this (real polyglossia
> code):
>
> \usepackage{polyglossia}
> \setmainlanguage{spanish}
> \setotherlanguage[numerals=arabic]{chinese}
>
> cannot be translated from (fake polyglossia code):
>
> #+language: es
> #+LaTeX_Header: \usepackage[chinese,AUTO]{polyglossia}

Since we are up to extending #+language keyword in future, may as well
allow LANG [:key val ...] values.

I expressed similar idea in 
https://list.orgmode.org/orgmode/87fsc05hkl.fsf@localhost/

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

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

[Ihor Radchenko]

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.

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 .
Support Org development at ,
or support my work at 

Re: [patch] Fixes and improvements in org-latex-language-alist

[Juan Manuel Macías]

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.

I understand that org-latex-language-alist is a temporary patch waiting
for something better, and is very dependent on
org-latex-guess-babel-language and
org-latex-guess-polyglossia-language[1], two functions that (IMHO)
should be made obsolete in the future. Keep in mind that the old
org-latex-babel-language-alist was more focused on the old babel ldf
files, which is a limited number of languages. Polyglossia also has a
rather limited number of supported languages. The ini files system is
more extensive and more flexible. One can even define new "virtual"
languages using \babelprovide, or write new custom ini files. With this
scenario a closed list like org-latex-language-alist doesn't make much
sense. I actually think that there would be no need for any ad hoc list
of this type for latex, and everything should be delegated to a global
language name translation system like the one Ihor is developing. I
think that would be the first stone to build native Org multilingual
support.

[1] I think also that in this function there was an unhappy decision:
using a syntax that is not from polyglossia but from babel leaves the
user with little freedom of action, since polyglossia has more 'keyval'
options, not only language variants. For example, this (real polyglossia
code):

\usepackage{polyglossia}
\setmainlanguage{spanish}
\setotherlanguage[numerals=arabic]{chinese}

cannot be translated from (fake polyglossia code):

#+language: es
#+LaTeX_Header: \usepackage[chinese,AUTO]{polyglossia}

--
Juan Manuel Macías

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com

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

[Max Nikulin]

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.

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

[Ihor Radchenko]

Max Nikulin  writes:

>> It is already a public constant. And I see no strong reason to change
>> this (strong enough to justify breaking change).
>
> 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. To achieve consistent behavior it is better to 
> provide a helper function.

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.

Helper function is certainly a good idea. I did plan for it.

>>> I have a hope that properties may be generated from CLDR data, LaTeX
>>> babel .ini files, etc. However it should be possible to override
>>> specific properties.
>> 
>> For context, I plan to provide a global language-identifier alist that
>> will link human-readable language names to abbreviations like "de",
>> "de-de", etc.
>
> 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.

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

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

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.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

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

[Max Nikulin]

On 10/09/2023 23:52, Ihor Radchenko wrote:

Max Nikulin writes:


On 09/09/2023 16:11, Ihor Radchenko wrote:

I am not sure if making a breaking change to public constant is the best
approach.
What about simply adding an extra entry:
("de" )
("de-de" )


Ideally it should not be a public constant. Values should be accessed
using a helper that returns "de" value for "de-de", "de-ch", "de-it"
without copies, unless a more specific key is defined as it is done for
de-at.


It is already a public constant. And I see no strong reason to change
this (strong enough to justify breaking change).


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. To achieve consistent behavior it is better to 
provide a helper function.



I have a hope that properties may be generated from CLDR data, LaTeX
babel .ini files, etc. However it should be possible to override
specific properties.


For context, I plan to provide a global language-identifier alist that
will link human-readable language names to abbreviations like "de",
"de-de", etc.


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.



Thus, auto-generating the alist may be not reliable. At least some
manual overseeing may be needed.


Of course, some overrides may be necessary. E.g. it was decided to use 
French inner quotes different from CLDR.



Though I am not sure if we can easily handle tricky
cases like weird installation directory for TeXLive or MikTeX.


kpsewhich babel-de.ini
/usr/share/texlive/texmf-dist/tex/generic/babel/locale/de/babel-de.ini

Re: [patch] Fixes and improvements in org-latex-language-alist

[Ihor Radchenko]

Juan Manuel Macías  writes:

> Ihor Radchenko writes:
>
>> For context, I plan to provide a global language-identifier alist that
>> will link human-readable language names to abbreviations like "de",
>> "de-de", etc. These abbreviations are not unique to LaTeX, but also used
>> elsewhere, so there is no guarantee that babel .ini files will always
>> use a consistent set of language abbreviations.
>
> Is the code you're working on in a public repository, to keep an eye
> on?

Not really. The story starts from the previous discussion of
translations in your French quote patch:
https://list.orgmode.org/orgmode/87pm3e6qx3.fsf@localhost/

I started writing it and realized that the current situation with all
the translations scattered all over the place (at least, ox libraries,
column view, and org-clock) is not ideal. So, I plan to factor out all
the translations into a separate file (say, org-translate). That file
will also define common interfaces to work with language codes and
translating phrases.

> As I mentioned in previous messages, that seems like a great improvement
> to me. I think it was not a happy decision at the time to use languages
> codes to declare the language of the document in Org. Language codes can
> be useful at a low level (although they can also lead to confusion), but
> I think that for a user level it is more practical to use human-readable
> names, as is done in babel or polyglossia, and in general, any user
> interface outside of LaTeX. Although babel also allows language codes as
> a value for some \babelprovide options (for example, I can define a new
> "virtual" language, importing the Greek captions:
> \babelprovide[captions=el]{mylanguage}).

That's very LaTeX-specific and will be limited to LaTeX export.
I do not see any problem since we have to support languages defined by
language code anyway, for backwards compatibility.

> In case it helps you, on page. 19 of the Babel manual there is an
> exhaustive list of all the languages codes, and on p. 22 a list of
> supported (human readable) language names for loading ini files. The
> language names of the old ldf files are on p. 49:
>
> https://CTAN/macros/latex/required/babel/base/babel.pdf

Thanks!

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [patch] Fixes and improvements in org-latex-language-alist

[Juan Manuel Macías]

Ihor Radchenko writes:

> For context, I plan to provide a global language-identifier alist that
> will link human-readable language names to abbreviations like "de",
> "de-de", etc. These abbreviations are not unique to LaTeX, but also used
> elsewhere, so there is no guarantee that babel .ini files will always
> use a consistent set of language abbreviations.

Is the code you're working on in a public repository, to keep an eye on?
As I mentioned in previous messages, that seems like a great improvement
to me. I think it was not a happy decision at the time to use languages
codes to declare the language of the document in Org. Language codes can
be useful at a low level (although they can also lead to confusion), but
I think that for a user level it is more practical to use human-readable
names, as is done in babel or polyglossia, and in general, any user
interface outside of LaTeX. Although babel also allows language codes as
a value for some \babelprovide options (for example, I can define a new
"virtual" language, importing the Greek captions:
\babelprovide[captions=el]{mylanguage}).

In case it helps you, on page. 19 of the Babel manual there is an
exhaustive list of all the languages codes, and on p. 22 a list of
supported (human readable) language names for loading ini files. The
language names of the old ldf files are on p. 49:

https://CTAN/macros/latex/required/babel/base/babel.pdf

-- 
Juan Manuel Macías

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com

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

[Ihor Radchenko]

Max Nikulin  writes:

> On 09/09/2023 16:11, Ihor Radchenko wrote:
>> I am not sure if making a breaking change to public constant is the best
>> approach.
>> What about simply adding an extra entry:
>> ("de" )
>> ("de-de" )
>
> Ideally it should not be a public constant. Values should be accessed 
> using a helper that returns "de" value for "de-de", "de-ch", "de-it" 
> without copies, unless a more specific key is defined as it is done for 
> de-at.

It is already a public constant. And I see no strong reason to change
this (strong enough to justify breaking change).

> I have a hope that properties may be generated from CLDR data, LaTeX 
> babel .ini files, etc. However it should be possible to override 
> specific properties.

For context, I plan to provide a global language-identifier alist that
will link human-readable language names to abbreviations like "de",
"de-de", etc. These abbreviations are not unique to LaTeX, but also used
elsewhere, so there is no guarantee that babel .ini files will always
use a consistent set of language abbreviations.

Thus, auto-generating the alist may be not reliable. At least some
manual overseeing may be needed.

But the general idea of auto-generating this alist is not bad. Patches
welcome, I think. Though I am not sure if we can easily handle tricky
cases like weird installation directory for TeXLive or MikTeX.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

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

[Max Nikulin]

On 09/09/2023 16:11, Ihor Radchenko wrote:

I am not sure if making a breaking change to public constant is the best
approach.
What about simply adding an extra entry:
("de" )
("de-de" )


Ideally it should not be a public constant. Values should be accessed 
using a helper that returns "de" value for "de-de", "de-ch", "de-it" 
without copies, unless a more specific key is defined as it is done for 
de-at.


I have a hope that properties may be generated from CLDR data, LaTeX 
babel .ini files, etc. However it should be possible to override 
specific properties.

Re: [patch] Fixes and improvements in org-latex-language-alist

[Ihor Radchenko]

Juan Manuel Macías  writes:

> The fact of avoiding copy/paste is already an advantage. New patch
> attached with your suggestions.

Thanks!
Applied, onto main.
I amended the commit message, removing the statement about list of
language identifiers and adding a link to this discussion.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=893c5d085

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [patch] Fixes and improvements in org-latex-language-alist

[Juan Manuel Macías]

Ihor Radchenko writes:

> It is not that complex, really. I suggested the above approach because:
> 1. It is easy to read - clearly, ,@de-plist and ,@de-plist are the same
>thing.
> 2. If we ever need to change de-plist, we should only do it in a single
>place.


The fact of avoiding copy/paste is already an advantage. New patch
attached with your suggestions. I have simply modified the variable name
a little. de-plist may seem a bit confusing, because there is also de-at
(Austrian German). I have set de-default-plist, since for babel and
polyglossia German (de) and German from Germany (de-de) are the default
variant. The same with the case of the Chinese (Chinese = Chinese
Simplified).

-- 
Juan Manuel Macías

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com

>From 73057fc06990f861468c397c94b7076d025acbc8 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias 
Date: Fri, 8 Sep 2023 19:33:25 +0200
Subject: [PATCH] ox-latex.el: Fixes and improvements in
 `org-latex-language-alist'.

* (org-latex-language-alist): Fix a language code (`de-de') removed
when `org-latex-babel-language-alist' and
`org-latex-polyglossia-language-alist' were merged.  To allow language
codes that can have a similar translation in `babel' or `polyglossia'
now in each element of `org-latex-language-alist' car can also be a
list of language codes.  New admitted properties: `:babel-ini-alt',
`:script' and `:script-tag'.  Add language code for ancient Greek.
Fix Afrikaans (was previously removed).  New languages: Chinese
Simplified and Traditional.  Correction of some typos, errors and
inaccuracies.  `let' bindings suggested by Ihor Radchenko.

* (org-latex-guess-babel-language): Some necessary modifications.
---
 lisp/ox-latex.el | 197 ++-
 1 file changed, 109 insertions(+), 88 deletions(-)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 241ef603a..14105c7cc 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -177,94 +177,105 @@
 ;;; Internal Variables
 
 (defconst org-latex-language-alist
-  '(("am" :babel-ini-only "amharic" :polyglossia "amharic" :lang-name "Amharic")
-("ar" :babel "arabic" :polyglossia "arabic" :lang-name "Arabic")
-("ast" :babel-ini-only "asturian" :polyglossia "asturian" :lang-name "Asturian")
-("bg"  :babel "bulgarian" :polyglossia "bulgarian" :lang-name "Bulgarian")
-("bn"  :babel-ini-only "bengali" :polyglossia "bengali" :lang-name "Bengali")
-("bo"  :babel-ini-only "tibetan" :polyglossia "tibetan" :lang-name "Tibetan")
-("br"  :babel "breton" :polyglossia "breton" :lang-name "Breton")
-("ca"  :babel "catalan" :polyglossia "catalan" :lang-name "Catalan")
-("cop"  :babel-ini-only "coptic" :polyglossia "coptic" :lang-name "Coptic")
-("cs"  :babel "czech" :polyglossia "czech" :lang-name "Czech")
-("cy"  :babel "welsh" :polyglossia "welsh" :lang-name "Welsh")
-("da"  :babel "danish" :polyglossia "danish" :lang-name "Danish")
-("de"  :babel "ngerman" :polyglossia "german" :polyglossia-variant "german" :lang-name "German")
-("de-at"  :babel "naustrian" :polyglossia "german" :polyglossia-variant "austrian" :lang-name "German")
-("dsb"  :babel "lsorbian" :polyglossia "sorbian" :polyglossia-variant "lower" :lang-name "Lower Sorbian")
-("dv"  :babel-ini-only "divehi" :polyglossia "divehi" :lang-name "Divehi")
-("el"  :babel "greek" :polyglossia "greek" :lang-name "Greek")
-("el-polyton"  :babel "polutonikogreek" :polyglossia "greek" :polyglossia-variant "polytonic" :lang-name "Polytonic Greek")
-("en"  :babel "american" :polyglossia "english" :polyglossia-variant "usmax" :lang-name "English")
-("en-au"  :babel "australian" :polyglossia "english" :polyglossia-variant "australian" :lang-name "English")
-("en-gb"  :babel "british" :polyglossia "english" :polyglossia-variant "uk" :lang-name "English")
-("en-nz"  :babel "newzealand" :polyglossia "english" :polyglossia-variant "newzealand" :lang-name "English")
-("en-us"  :babel "american" :polyglossia "english" :polyglossia-variant "usmax" :lang-name "English")
-("eo"  :babel "esperanto" :polyglossia "esperanto" :lang-name "Esperanto")
-("es"  :babel "spanish" :polyglossia "spanish" :lang-name "Spanish")
-("es-mx"  :babel "spanishmx" :polyglossia "spanish" :polyglossia-variant "mexican" :lang-name "Spanish")
-("et"  :babel "estonian" :polyglossia "estonian" :lang-name "Estonian")
-("eu"  :babel "basque" :polyglossia "basque" :lang-name "Basque")
-("fa"  :babel "farsi" :polyglossia "farsi" :lang-name "Farsi")
-("fi"  :babel "finnish" :polyglossia "finnish" :lang-name "Finnish")
-("fr"  :babel "french" :polyglossia "french" :lang-name "French")
-("fr-ca"  :babel "canadien" :polyglossia "french" :polyglossia-variant "canadian" :lang-name "French")
-("fur"  :babel "friulan" :polyglossia "friulan" :lang-name "Friulian")
-("ga"  :babel 

Re: [patch] Fixes and improvements in org-latex-language-alist

[Ihor Radchenko]

Juan Manuel Macías  writes:

>> (let ((de-plist '(...)))
>>  `(...
>>("de" ,@de-plist)
>>("de-de" ,@de-plist)
>>...))
>>
>> This is copy-paste-proof and does not require breaking changes in the
>> value structure.
>
> I like the idea because it avoids errors, but I don't know if
> it's worth it, there being only two cases (at the moment).

It is not that complex, really. I suggested the above approach because:
1. It is easy to read - clearly, ,@de-plist and ,@de-plist are the same
   thing.
2. If we ever need to change de-plist, we should only do it in a single
   place.

> ... This other
> possibility occurred to me, just to make it easier to read and not have
> to navigate to the list of variables:
>
> (let* ((basic-code)
>(shared-plist (lambda ( plist)
>(setq basic-code plist
>   `(...
> ("de" ,(funcall shared-plist :babel "ngerman" :babel-ini-alt "german" 
> :polyglossia "german" :polyglossia-variant "german" :lang-name "German" 
> :script "latin" :script-tag "latn"))
> ("de-de" ,@basic-code)
> ...
> ("zh" ,(funcall shared-plist :babel-ini-only "chinese" :polyglossia 
> "chinese" :lang-name "Chinese Simplified" :script "hans" :script-tag "hans"))
> ("zh-cn" ,@basic-code)))

This is less readable compared to having ",@de-plist" - ",@de-plist".
One would need to put extra effort to understand the equality of
(funcall shared-plist ...) and ,@basic-code.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [patch] Fixes and improvements in org-latex-language-alist

[Juan Manuel Macías]

Ihor Radchenko writes:

> I am thinking about something like
>
> (let ((de-plist '(...)))
>  `(...
>("de" ,@de-plist)
>("de-de" ,@de-plist)
>...))
>
> This is copy-paste-proof and does not require breaking changes in the
> value structure.

I like the idea because it avoids errors, but I don't know if
it's worth it, there being only two cases (at the moment). This other
possibility occurred to me, just to make it easier to read and not have
to navigate to the list of variables:

(let* ((basic-code)
   (shared-plist (lambda ( plist)
 (setq basic-code plist
  `(...
("de" ,(funcall shared-plist :babel "ngerman" :babel-ini-alt "german" 
:polyglossia "german" :polyglossia-variant "german" :lang-name "German" :script 
"latin" :script-tag "latn"))
("de-de" ,@basic-code)
...
("zh" ,(funcall shared-plist :babel-ini-only "chinese" :polyglossia 
"chinese" :lang-name "Chinese Simplified" :script "hans" :script-tag "hans"))
("zh-cn" ,@basic-code)))

Likewise, there being two cases (even in the case of Chinese you could
perfectly omit zh-cn, because it is a new language and there is no
danger of regression), I would say that it is not worth complicating the
code so much.

-- 
Juan Manuel Macías

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com

Re: [patch] Fixes and improvements in org-latex-language-alist

[Ihor Radchenko]

Juan Manuel Macías  writes:

>> I am not sure if making a breaking change to public constant is the best
>> approach.
>> What about simply adding an extra entry:
>> ("de" )
>> ("de-de" )
>> ?
>
> At first I had done it with extra entries, but I was wondering if there
> wasn't a more "economical" way... If you don't mind having extra entries
> with identical plists, then I do it that way. After all, there are only
> two cases (Chinese and German).

I am thinking about something like

(let ((de-plist '(...)))
 `(...
   ("de" ,@de-plist)
   ("de-de" ,@de-plist)
   ...))

This is copy-paste-proof and does not require breaking changes in the
value structure.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [patch] Fixes and improvements in org-latex-language-alist

[Juan Manuel Macías]

Ihor Radchenko writes:

>> I don't know if it's a valid path to allow the car of each element to
>> also be a list of languages codes, but I couldn't think of a better
>> solution for the "de"/"de-de" cases. A similar case is in Chinese
>> Simplified (new language added), where the possible language codes are
>> zh and zh-cn, if I'm not wrong.
>
> I am not sure if making a breaking change to public constant is the best
> approach.
> What about simply adding an extra entry:
> ("de" )
> ("de-de" )
> ?

At first I had done it with extra entries, but I was wondering if there
wasn't a more "economical" way... If you don't mind having extra entries
with identical plists, then I do it that way. After all, there are only
two cases (Chinese and German).

-- 
Juan Manuel Macías

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com

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

[Ihor Radchenko]

Juan Manuel Macías  writes:

> I think that with this patch the possible regressions are removed. I
> took the opportunity to add some improvements (the :babel-ini-alt,
> :script and :script-tag properties) and correct some errors and typos.
>
> I don't know if it's a valid path to allow the car of each element to
> also be a list of languages codes, but I couldn't think of a better
> solution for the "de"/"de-de" cases. A similar case is in Chinese
> Simplified (new language added), where the possible language codes are
> zh and zh-cn, if I'm not wrong.

I am not sure if making a breaking change to public constant is the best
approach.
What about simply adding an extra entry:
("de" )
("de-de" )
?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

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

[Juan Manuel Macías]

I think that with this patch the possible regressions are removed. I
took the opportunity to add some improvements (the :babel-ini-alt,
:script and :script-tag properties) and correct some errors and typos.

I don't know if it's a valid path to allow the car of each element to
also be a list of languages codes, but I couldn't think of a better
solution for the "de"/"de-de" cases. A similar case is in Chinese
Simplified (new language added), where the possible language codes are
zh and zh-cn, if I'm not wrong.

--
Juan Manuel Macías

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com

>From 52f17bc841241562a52e91159cb1531dbe5684e1 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias 
Date: Fri, 8 Sep 2023 19:33:25 +0200
Subject: [PATCH] ox-latex.el: Fixes and improvements in
 `org-latex-language-alist'.

* (org-latex-language-alist): Fix a language code (`de-de') removed
when `org-latex-babel-language-alist' and
`org-latex-polyglossia-language-alist' were merged.  To allow language
codes that can have a similar translation in `babel' or `polyglossia'
now in each element of `org-latex-language-alist' car can also be a
list of language codes.  New admitted properties: `:babel-ini-alt',
`:script' and `:script-tag'.  Add language code for ancient Greek.
Fix Afrikaans (was previously removed).  New languages: Chinese
Simplified and Traditional.  Correction of some typos, errors and
inaccuracies.

* (org-latex-guess-babel-language): Some necessary modifications.

* (org-latex-guess-polyglossia-language): Some necessary modifications.
---
 lisp/ox-latex.el | 208 +++
 1 file changed, 118 insertions(+), 90 deletions(-)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 241ef603a..d6790ea27 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -177,94 +177,102 @@
 ;;; Internal Variables
 
 (defconst org-latex-language-alist
-  '(("am" :babel-ini-only "amharic" :polyglossia "amharic" :lang-name "Amharic")
-("ar" :babel "arabic" :polyglossia "arabic" :lang-name "Arabic")
-("ast" :babel-ini-only "asturian" :polyglossia "asturian" :lang-name "Asturian")
-("bg"  :babel "bulgarian" :polyglossia "bulgarian" :lang-name "Bulgarian")
-("bn"  :babel-ini-only "bengali" :polyglossia "bengali" :lang-name "Bengali")
-("bo"  :babel-ini-only "tibetan" :polyglossia "tibetan" :lang-name "Tibetan")
-("br"  :babel "breton" :polyglossia "breton" :lang-name "Breton")
-("ca"  :babel "catalan" :polyglossia "catalan" :lang-name "Catalan")
-("cop"  :babel-ini-only "coptic" :polyglossia "coptic" :lang-name "Coptic")
-("cs"  :babel "czech" :polyglossia "czech" :lang-name "Czech")
-("cy"  :babel "welsh" :polyglossia "welsh" :lang-name "Welsh")
-("da"  :babel "danish" :polyglossia "danish" :lang-name "Danish")
-("de"  :babel "ngerman" :polyglossia "german" :polyglossia-variant "german" :lang-name "German")
-("de-at"  :babel "naustrian" :polyglossia "german" :polyglossia-variant "austrian" :lang-name "German")
-("dsb"  :babel "lsorbian" :polyglossia "sorbian" :polyglossia-variant "lower" :lang-name "Lower Sorbian")
-("dv"  :babel-ini-only "divehi" :polyglossia "divehi" :lang-name "Divehi")
-("el"  :babel "greek" :polyglossia "greek" :lang-name "Greek")
-("el-polyton"  :babel "polutonikogreek" :polyglossia "greek" :polyglossia-variant "polytonic" :lang-name "Polytonic Greek")
-("en"  :babel "american" :polyglossia "english" :polyglossia-variant "usmax" :lang-name "English")
-("en-au"  :babel "australian" :polyglossia "english" :polyglossia-variant "australian" :lang-name "English")
-("en-gb"  :babel "british" :polyglossia "english" :polyglossia-variant "uk" :lang-name "English")
-("en-nz"  :babel "newzealand" :polyglossia "english" :polyglossia-variant "newzealand" :lang-name "English")
-("en-us"  :babel "american" :polyglossia "english" :polyglossia-variant "usmax" :lang-name "English")
-("eo"  :babel "esperanto" :polyglossia "esperanto" :lang-name "Esperanto")
-("es"  :babel "spanish" :polyglossia "spanish" :lang-name "Spanish")
-("es-mx"  :babel "spanishmx" :polyglossia "spanish" :polyglossia-variant "mexican" :lang-name "Spanish")
-("et"  :babel "estonian" :polyglossia "estonian" :lang-name "Estonian")
-("eu"  :babel "basque" :polyglossia "basque" :lang-name "Basque")
-("fa"  :babel "farsi" :polyglossia "farsi" :lang-name "Farsi")
-("fi"  :babel "finnish" :polyglossia "finnish" :lang-name "Finnish")
-("fr"  :babel "french" :polyglossia "french" :lang-name "French")
-("fr-ca"  :babel "canadien" :polyglossia "french" :polyglossia-variant "canadian" :lang-name "French")
-("fur"  :babel "friulan" :polyglossia "friulan" :lang-name "Friulian")
-("ga"  :babel "irish" :polyglossia "irish" :lang-name "Irish")
-("gd"  :babel "scottish" :polyglossia "scottish" :lang-name "Scottish Gaelic")
-("gl"  :babel "galician"