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,
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 reaso
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
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 th
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
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 const
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
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 fil
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 acces
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" v
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.
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/p
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
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
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
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 languag
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
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 lan
18 matches
Mail list logo
