CultureNotFoundException ("ku") on Xamarin for Android

[ktos]

When trying to run Humanizer 2.9.9 embedded into .NET Standard 2.0 library used by the Xamarin.Forms app running on Android I got the exception:

System.Globalization.CultureNotFoundException
  Message=Culture name ku is not supported.
Parameter name: name

As I understand the culture "ku" (Kurdish?) is not supported on Xamarin.Android and this is why I got the error, but I even not wanted to use "ku", but run a code like:

date.Text = 1.ToWords(GrammaticalGender.Feminine, new CultureInfo("pl"));

The same app runs fine with Xamarin.Forms on UWP.

Should this issue be forwarded to Xamarin.Android (please add "ku" culture support), or maybe there should be a check and if a culture is not supported on the target platform, it should be discarded?

(workaround is to use 2.8.26 temporarily, as Kurdish support was added in #1044)

[jtorvald]

Same on iOS with 2.9.9.

[clairernovotny]

This should be reported to Android. This package is simply providing resources, issues with languages beyond what the runtime supports are the runtime's bug.

[JustArchi]

I'm seeing the same error on Windows 7:

System.TypeInitializationException: The type initializer for 'Humanizer.Configuration.Configurator' threw an exception.
---> System.Globalization.CultureNotFoundException: Culture is not supported. (Parameter 'name')
ku is an invalid culture identifier.

While "This should be reported to somebody else" sounds cool, because indeed Windows 7 is lacking the language, I don't believe it solves the problem. Should I fix the Humanizer version to 2.8.26 because 2.9.9 and newer do not support Windows 7 anymore?

[jtorvald]

@clairernovotny that is interesting. This is also on iOS and I'm not using the ku culture. Besides that, it does not happen in 2.8.26.

[JustArchi]

The interesting part of my stacktrace looks like that:

OnUnhandledException() System.TypeInitializationException: The type initializer for 'Humanizer.Configuration.Configurator' threw an exception.
 ---> System.Globalization.CultureNotFoundException: Culture is not supported. (Parameter 'name')
ku is an invalid culture identifier.
   at System.Globalization.CultureInfo..ctor(String name, Boolean useUserOverride)
   at System.Globalization.CultureInfo..ctor(String name)
   at Humanizer.Localisation.Formatters.DefaultFormatter..ctor(String localeCode)
   at Humanizer.Configuration.FormatterRegistry.RegisterDefaultFormatter(String localeCode)
   at Humanizer.Configuration.FormatterRegistry..ctor()
   at Humanizer.Configuration.Configurator..cctor()
   --- End of inner exception stack trace ---
   at Humanizer.TimeSpanHumanizeExtensions.CreateTheTimePartsWithUpperAndLowerLimits(TimeSpan timespan, CultureInfo culture, TimeUnit maxUnit, TimeUnit minUnit, Boolean toWords)
   at Humanizer.TimeSpanHumanizeExtensions.Humanize(TimeSpan timeSpan, Int32 precision, Boolean countEmptyUnits, CultureInfo culture, TimeUnit maxUnit, TimeUnit minUnit, String collectionSeparator, Boolean toWords)
   at Humanizer.TimeSpanHumanizeExtensions.Humanize(TimeSpan timeSpan, Int32 precision, CultureInfo culture, TimeUnit maxUnit, TimeUnit minUnit, String collectionSeparator, Boolean toWords)
   at ArchiSteamFarm.Utilities.ToHumanReadable(TimeSpan timeSpan)
(...)

The problem is not with the consumer trying to use the ku culture, but the sole fact that it exists and is unsupported on the target machine. As been reported, this includes (at least) Xamarin, iOS and Windows 7. The machine above is running en-US locale, not trying to use ku at all.

I don't know Humanizer code well enough, but to me it looks like ku is being registered on the machine despite not being supported. Either it shouldn't be registered in advance, or if that's not possible, in some kind try/catched and skipped on machines that do not support given locale.

As it is right now, the Humanizer 2.9.9 is entirely broken on Windows 7 for me and can't be used at all, despite the machine not trying to deal with ku in any way.

[jtorvald]

Hi @clairernovotny thanks for fixing this issue.

I guess this bug was a result of:
253e692#diff-9c9c8fb8cfbee1e028313dba123f456c874e740f34b501808323a3e52aa3a096R50

Do I understand it correctly that all the number to word converters get registered even if you don't want to support all those locales? Since I didn't register nor used "ku" anywhere.
https://github.com/Humanizr/Humanizer/blob/253e692f8fd1e2d1cde4d1b72b41b42735578382/src/Humanizer/Configuration/NumberToWordsConverterRegistry.cs

Is that intentional? And can it be avoided?

[clairernovotny]

Those converters are in the static init and cannot be avoided. I'll get this fix published in the next day or two.

[jtorvald]

Thanks