Invalid locale "se_SE"

[meowofficial]

I got this error in Crashlytics. The error occurred after attempt to format a price.

Stack Trace:

ArgumentError: Invalid argument(s): Invalid locale "se_SE"
  File "intl_helpers.dart", line 204, in _throwLocaleError
  File "intl_helpers.dart", line 198, in verifiedLocale
  File "number_format.dart", line 366, in new NumberFormat._forPattern
  File "number_format.dart", line 299, in new NumberFormat.currency

Package version: 0.18.1

[mosuem]

The Sami locale se is not supported by package:intl at the moment.

[chadpav]

I'm getting a similar error with multiple locales and Date formatting as well. If we zoom out a bit, is there a helper method that lets us test whether a locale is invalid so that we don't have to wrap every format call to the intl package in a try/catch?

[mosuem]

If we zoom out a bit, is there a helper method that lets us test whether a locale is invalid so that we don't have to wrap every format call to the intl package in a try/catch?

There are two underlying issues here, the lack of a good fallback mechanism, and the lack of a method similar to https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/NumberFormat/supportedLocalesOf. Both should be fixed with the upcoming package:intl4x.

[chadpav]

I read through the source code of the package and found a static helper method on the DateFormat and NumberFormat classes. I don't think it was ever mentioned in the docs and I didn't notice that the package would throw if it didn't recognize the format.

For example, in intl>number_format.dart @ L474:

  /// Return true if the locale exists, or if it is null. The null case
  /// is interpreted to mean that we use the default locale.
  static bool localeExists(String? localeName) {
    if (localeName == null) return false;
    return numberFormatSymbols.containsKey(localeName);
  }

For anyone finding this, if your app is widely deployed you will see odd locales getting passed in. For example, I have several devices trying to use la-US which is Latin in US. There are several more across the world like this. I didn't know it was possible but you don't want to crash the app because of it.

I wrote an extension that always checks the helper method and falls back to en-US if it's not supported. That fallback makes sense for my app.

String getExceptionSafeNumberFormatLocale(String localeIdentifier) {
  return NumberFormat.localeExists(localeIdentifier) ? localeIdentifier : 'en_US';
}

String getExceptionSafeDateFormatLocale(String localeIdentifier) {
  return DateFormat.localeExists(localeIdentifier) ? localeIdentifier : 'en_US';
}

My other feedback would be that it would be nice to have a global helper method because I'm assuming the INTL package supports a locale and that it's going to return the same result for either type of formatter? The way it's written now, I wanted to be safe and assume that a locale could be supported on Dates but not on Numbers.

[mosuem]

Please file a new issue for these feature requests!

[EhabSalah]

Same with me.

Invalid locale "ars_EG"

[mosuem]

Invalid locale "ars_EG"

Do you mean ar_EG?

[karimSalahx]

I have the same issue
Invalid locale "ars_SA", I didn't specify the locale though, it is happening with some of the app users

[mosuem]

Invalid locale "ars_SA"

I believe this is a clone of #745