A follow-up to #368.

Originally posted by @aphillips in #368 (comment):

I'm very curious about the locales attribute--curious in this case is a euphemism for "nervous about". I would prefer if functions were mostly locale neutral (I can declare, for example, a number format in any message in any locale).

Originally posted by @eemeli in #368 (comment):

We should have some way to define at least locale-dependent option and match values. For example, the registry should allow for a way to note that while the whole set of CLDR categories is zero one two few many other, a specific locale such as en only uses one other.

One alternative could be for <matchSignature> and <formatSignature> to be able to contain an <override locales="en fr it"> section.

Originally posted by @stasm in #368 (comment)

For completeness of the example, my plan was to allow the overrides directly on the level of the matchSignature and formatSignature:

<function name="plural">
    <matchSignature locales="en">
        <input pattern="anyNumber"/>
        <option name="type" values="cardinal ordinal"/>
        <option .../>
        <match values="one other"/>                    ← English plurals
        <match pattern="anyNumber"/>
    </matchSignature>

    <matchSignature locales="pl">
        <input pattern="anyNumber"/>
        <option name="type" values="cardinal ordinal"/>
        <option .../>
        <match values="one few many other"/>           ← Polish plurals
        <match pattern="anyNumber"/>
    </formatSignature>
</function>

Originally posted by @aphillips in #368 (comment):

I am not a fan of this. I think that a plural selector should recognize all of the keywords and not depend on the registry to "allow" or "disallow" the enumerated values for a given locale (note that locales must be a "language range", otherwise you would need to list every possible language tag and is probably an extended language range, e.g. so that pl-PL matches pl-Latn-PL -- not that anyone would use that tag)

I think it is reasonable that (for example) the root locale message can contain keywords that do not fire for a specific locale but which fire in others, in case that message is used in one of those other locales. This is also why the * defaulting key exists (such as the case where an English-language resource with only one and * gets used in the pl locale).

In the case of plurals, CLDR provides the data about which keywords apply to which locale. In the case of some other formatter or selector that is not supplied by CLDR, the implementation should know what applies to each locale. If we want the registry to describe that relationship (for example to support exploding the matrix of keys in localization tools), I think I would prefer that it be separate from the signature, e.g.:

<function name="customPluralLikeSelector">
   <matchSignature>
      <input pattern="anyNumber"/>
      <option name="type" value="foo bar"/>
      <match value="zero one two few many other"/>
      <match pattern="anyNumber"/>
   </matchSignature>
   <validate comment="the naming is terrible and we wouldn't structure it exactly like this">
      <match type="values">
         <value lang="">one other</value>
         <value lang="pl">one few many other</value>
         <value lang="ja">other</value>
         <!-- etc. --->
      </match>
   </validate>