fix: Fix SSR support in I18nProvider

[avinashbot]

Description

Whoops. This one's on me. Thought optional chaining on document would save me here, but I would still need to explicitly check that the variable is even defined in SSR.

Related links, issue #, if available: n/a

How has this been tested?

Wrote an SSR test to make sure this doesn't break.

Review checklist

The following items are to be evaluated by the author(s) and the reviewer(s).

Correctness

• Changes include appropriate documentation updates.
• Changes are backward-compatible if not indicated, see CONTRIBUTING.md.
• Changes do not include unsupported browser features, see CONTRIBUTING.md.
• Changes were manually tested for accessibility, see accessibility guidelines.

Security

• If the code handles URLs: all URLs are validated through the checkSafeUrl function.

Testing

• Changes are covered with new/existing unit tests?
• Changes are covered with new/existing integration tests?

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[codecov]

Codecov Report

Patch coverage: 100.00% and no project coverage change.

Comparison is base (38079e7) 91.86% compared to head (9cdb044) 91.86%.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #861   +/-   ##
=======================================
  Coverage   91.86%   91.86%           
=======================================
  Files         582      582           
  Lines       14846    14849    +3     
  Branches     4758     4761    +3     
=======================================
+ Hits        13638    13641    +3     
  Misses       1126     1126           
  Partials       82       82           

Impacted Files	Coverage Δ
src/internal/i18n/provider.tsx	100.00% <100.00%> (ø)

... and 1 file with indirect coverage changes

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[just-boris]

Are you still sure you want to go your own hard way instead of reusing the existing code?
https://github.com/cloudscape-design/components/blob/main/src/internal/utils/locale/normalize-locale.ts

If not reusing, why not?

[avinashbot]

I'm a little cautious of partially using the file, because the date component logic is wrong for this.

I mentioned in the earlier PR that I think the best course of action would be to make this the definitive source of truth for internationalization and have the date components follow the provider instead. But you're right, maybe I can rename normalizeLocale to normalizeLocaleForDateComponents and have a nice global locale file for everything. On further thought... (see below)

[avinashbot]

To expand further: there would be very little shared code - just two similar use cases bunched up into a single file just making things confusing to understand. Philosophically, it's more important for the locales to be used to match the correct strings in the messages JSON than to be valid or accurate BCP47 locale strings.

The context:

• shouldn't "fix" underscore delimited locale strings (because they're used for key accesses)
• shouldn't "auto-expand" the provided locale with the current browser locale or html locale
• shouldn't fall back to the browser locale (cause that makes SSR mismatches even worse)

[avinashbot]

For posterity: this rabbit hole is deeper than first expected. Writing a proposal for that, but in the mean time, there's very little opportunity for code sharing. Merging this fix for now.