fix: Format Locale objects scriptcode correctly

[d0gkiller87]

Pull Request Description

The existing logic for:

• Displaying settings: https://github.com/DonutWare/Fladder/blob/v0.9.0/lib/util/localization_helper.dart#L62
• Saving/loading settings: https://github.com/DonutWare/Fladder/blob/v0.9.0/lib/models/settings/client_settings_model.dart#L127

Doesn't take Locale.scriptCode into account during formatting/serialization, turning language codes like zh_Hant into zh. This PR addresses the issue and formats/parses language codes according to the pattern of BCP 47. (i.e. EN_US→en_US, ZH_HANT→zh_Hant)

Issue Being Fixed

Resolves #641

Checklist

• If a new package was added, did you ensure it works for all supported platforms? Is the package well maintained
• Check that any changes are related to the issue at hand.

[d0gkiller87]

One thing to note: since the original implementation already saves language codes in BCP 47's format, existing users' selected language won't be affected by this change as tested by migrating from version 9.0.

[PartyDonut]

Looks good to me, small change request just to make sure.

[d0gkiller87]

Another thing before merging:
Not sure how localeResolutionCallback (pointed out by @kikibase @ a0182ef) affects the locale loading process. In my test runs, taking care of scriptCode already mitigated the issue. Can someone check what localeResolutionCallback actually does in Fladder?

[d0gkiller87]

Another thing before merging: Not sure how localeResolutionCallback (pointed out by @kikibase @ a0182ef) affects the locale loading process. In my test runs, taking care of scriptCode already mitigated the issue. Can someone check what localeResolutionCallback actually does in Fladder?

Never mind, I understand it now.

For reference, the code in question:
https://github.com/DonutWare/Fladder/blob/v0.9.0/lib/main.dart#L321

It defines both locale and localeResolutionCallback. According to the Flutter documentation: https://api.flutter.dev/flutter/widgets/WidgetsApp/locale.html

localeResolutionCallback, which can override the default supportedLocales matching algorithm.

And given this block:

if (supportedLocales.contains(locale)) {
  return locale;
}

the (l) => l.languageCode == locale.languageCode check effectively serves as a fallback. It only runs when locale is not found in supportedLocales.

If we were changing it to (l) => l == locale, it would likely never match, since supportedLocales.contains(locale) has already failed at that point ...

If everything checks out, please feel free to merge the PR, thanks!