@asashour do you think it's worth doing a similar test for plurals ?

Why not. However the plurals use a different mechanism as I thought before raising the PR.

Anyhow, test to be shortly added.

A test case was added to ensure we don'tfail. However I am not sure if we should throw an exception instead?

I am not sure@asashour. For example. Intl.plural eventually has a check like this:

    ArgumentError.checkNotNull(other, 'other');    ArgumentError.checkNotNull(howMany, 'howMany');

So we can assume that a invalid input like{count, plural,} really IS an error, except when it means thatother is set to''. (I think this is unlikely but don't know).

For Intl.selectsomething has be to be defined, like shown in the code:

  /// Internal: Implements the logic for select - use [select] for  /// normal messages.  static T selectLogic<T>(Object choice, Map<Object, T> cases) {    // This will work if choice is a string, or if it's e.g. an    // enum and the map uses the enum values as choices.    var exact = cases[choice];    if (exact != null) return exact;    // If it didn't match exactly, take the toString and    // take the part after the period. We need to do this    // because enums print as 'EnumType.enumName' and periods    // aren't acceptable in ICU select choices.    var stringChoice = '$choice'.split('.').last;    var stringMatch = cases[stringChoice];    if (stringMatch != null) return stringMatch;    var other = cases['other'];    if (other == null) {      throw ArgumentError("The 'other' case must be specified");    }    return other;  }

So I think that failing meaningfully in both cases is acceptable.

@jmagman WDYT

I don't have familiarity with this code,@HansMuller may have opinions.

Looking ....

According to our documentation - flutter.dev/go/i18n-user-guide, "Messages With Plurals" - theother variation is required. As@enedpointed out,Intl.plural may accept this and assume thatother is an empty string, however that seems likely to mask an error.

It might be best to leave the plural test out for now, since this PR was really about fixing upselect.

Also: a more ambitious update to select/plurals has been proposed:#86906