feat(intl): ignore script subtags when canonicalizing locale strings

[kszczek]

Locale strings with a script such as zh-Hans-CN are incorrectly canonicalized as zh instead of zh-CN. Update the canonicalizedLocale function to look for a script subtag and ignore it if found.

Closes: #945

---

• I’ve reviewed the contributor guide and applied the relevant portions to this PR.

Contribution guidelines:

• See our contributor guide for general expectations for PRs.
• Larger or significant changes should be discussed in an issue before creating a PR.
• Contributions to our repos should follow the Dart style guide and use dart format.
• Most changes should add an entry to the changelog and may need to rev the pubspec package version.
• Changes to packages require corresponding tests.

Note that many Dart repos have a weekly cadence for reviewing PRs - please allow for some latency before initial review feedback.

[mosuem]

A bit of a hacky solution, but the existing code is also quite hacky, so that's fine :)

[github-actions]

PR Health

Breaking changes ✔️

Package	Change	Current Version	New Version	Needed Version	Looking good?
intl	None	0.20.2	0.20.3-wip	0.20.2	✔️

Changelog Entry ✔️

Package	Changed Files

Changes to files need to be accounted for in their respective changelogs.

Coverage ✔️

File	Coverage
pkgs/intl/lib/intl.dart	💚 98 %
pkgs/intl/lib/src/intl_helpers.dart	💚 54 % ⬆️ 12 %

This check for test coverage is informational (issues shown here will not fail the PR).

API leaks ⚠️

The following packages contain symbols visible in the public API, but not exported by the library. Export these symbols or remove them from your publicly visible API.

Package	Leaked API symbols
intl	StringStack DateBuilder

This check can be disabled by tagging the PR with skip-leaking-check.

License Headers ✔️

// Copyright (c) 2025, the Dart project authors. Please see the AUTHORS file
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.

Files
no missing headers

All source files should start with a license header.

[mosuem]

This fails internal Google testing, which looks like this:

test('Recover locale from string', () {
      expect(
        Locale.tryParse(Intl.canonicalizedLocale('zh_Hant_TW')),
        Locale.fromSubtags(
          languageCode: 'zh',
          scriptCode: 'Hant',
          countryCode: 'TW',
        ),
      );
    });

Which made me think about what canonicalizedLocale promises vs does. The documentation states it turns a locale string into the form xx_YY, but also ... where it might possibly be in the wrong case or with a hyphen instead of an underscore..
So it seems it was interpreted as trying to do canonicalization, more precisely level 1 canonicalization.

It doesn't help that NumberFormat.currency can't handle scripts... I think we should remedy that instead. This would mean that at

i18n/pkgs/intl/lib/src/intl_helpers.dart

Line 188 in c6b911b

canonicalizedLocale,

, we insert another fallback after canonicalizedLocale but before shortLocale (which should be renamed to something like languageOnly), which returns what you implemented. This way, we would first try zh_Hant_CN, then zh_CN, then zh, etc. when running NumberFormat.currency.

What do you think?

[mosuem]

As detailed in comment

[mosuem]

I would also add something like

  test('Use script', () {
    expect(
      NumberFormat.currency(locale: 'zh_Hant_TW').format(12),
      'TWD12.00',
    );
    expect(
      NumberFormat.currency(locale: 'zh_Hant_CN').format(12),
      'CNY12.00',
    );
  });

to the tests.

[kszczek]

Thank you for your patience, I couldn't get back to this sooner.

we insert another fallback after canonicalizedLocale but before shortLocale (which should be renamed to something like languageOnly), which returns what you implemented. This way, we would first try zh_Hant_CN, then zh_CN, then zh, etc. when running NumberFormat.currency.

Sounds good to me, even though there is no script specific data for numbers nor dates as far as I know, we should still try looking them up in case they appear in the future.

Implemented your suggestions and modified tests, let me know if I should change anything else.