Refactor registry locale overrides #534
Conversation
| <match locales="en" values="one two few other" validationRule="anyNumber"/> | ||
| <match values="zero one two few many other" validationRule="anyNumber"/> |
There was a problem hiding this comment.
other or *?
locales="en" looks odd. Can locales contain multiple values? Space separated, I guess?
This has always struck me as a wobbly mechanism. Many locales have identical plural rules to English. Are we going to list them? Why do we need to repeat CLDR data here? Perhaps we should have a referencing mechanism to CLDR instead of replicating data. Note that other things besides plurals depend on CLDR data, such as date patterns and such.
There was a problem hiding this comment.
Explicitly other, because these are literal values and * would in source need to be matched as |*|. Also, explicitly included because a selector could differentiate the other and * cases so that the former deals with numeric input matching the other category, while * handles non-numeric inputs. Furthermore, other must be supported in general because if it's left out then we can't properly deal with Eastern European languages like Polish which would prefer to default to many instead of other.
locales is NMTOKENS, so it may include a space-separated list of locale identifiers.
I agree that specifically for cardinal plurals & ordinals the CLDR includes data that we would like to refer to. This PR is not providing a solution for that; it's about providing a friendlier way to define local locale-specific overrides.
Co-authored-by: Addison Phillips <[email protected]>
Co-authored-by: Addison Phillips <[email protected]>
Co-authored-by: Addison Phillips <[email protected]>
Co-authored-by: Eemeli Aro <[email protected]>
|
I'm sorry that I missed this conversation when it happened. I hope we can still reconsider the design choices made in this PR. Or at least better substantiate it.
@eemeli Can you elaborate why you think these are two different concerns? In my mind, they are a single concern -- the selector function will be called in the context of a specific locale which impacts the function's input and output types, i.e. the function's signature. I'd much prefer to build as flat a registry as possible, and then separately define how the data modelled by it should be used. So rather than nest overrides inside <function name="number">
<!-- A generic signature, common for all locales. -->
<matchSignature>
<input validationRule="anyNumber"/>
<option name="type" values="cardinal ordinal"/>
<option name="minimumIntegerDigits" validationRule="positiveInteger"/>
<option name="minimumSignificantDigits" validationRule="positiveInteger"/>
<option name="maximumSignificantDigits" validationRule="positiveInteger"/>
<!-- Two match elements, because it's a union. -->
<match validationRule="anyNumber"/>
<match values="zero one two few many other"/>
</matchSignature>
<matchSignature locales="en">
<!-- Narrow down the possible keys for the en locale. -->
<match values="one other"/>
</matchSignature>
<matchSignature locales="pl">
<!-- Narrow down the possible keys for the pl locale. -->
<match values="one few many other"/>
</matchSignature>
</function> |
Closes #410
At the moment, locale-specific overrides work via the
localesattribute list of identifiers on<formatSignature>and<matchSignature>. This is a bit clumsy, because it's mixing together two different concerns:So I propose separating the two. Let's remove the
localesattribute from the signatures, and rather:<override locales="...">within a signature that may include rules for inputs and options that override any set generally for the formatter.<match>and<match locales="...">, and specify that only one such rule (first matching one) is used at a time.This should make it easier to implement and manage locale-specific overrides, as there's much less need for repetition.
If #532 is accepted,
<alias>elements should also be allowed to include<override>s.