feat: allow setting calendar for i18n date formatting

[Josh-Cena]

Motivation

Close #5440

Have you read the Contributing Guidelines on pull requests?

Yes

Test Plan

None...yet

[Josh-Cena]

Let me think about it first... 🤔 We probably want to allow something like dateFormat: 'en-GB' as well to solve the need for DD/MM/YYYY

[netlify]

✅ [V2]

Name	Link
🔨 Latest commit	0084e71
🔍 Latest deploy log	https://app.netlify.com/sites/docusaurus-2/deploys/62503fa80a437f00082aed00
😎 Deploy Preview	https://deploy-preview-6430--docusaurus-2.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[github-actions]

⚡️ Lighthouse report for the changes in this PR:

Category	Score
🟠 Performance	55
🟢 Accessibility	100
🟢 Best practices	92
🟢 SEO	100
🟢 PWA	90

Lighthouse ran on https://deploy-preview-6430--docusaurus-2.netlify.app/

[github-actions]

Size Change: +261 B (0%)

Total Size: 806 kB

Filename	Size	Change
website/build/assets/css/styles.********.css	105 kB	+100 B (0%)
website/build/assets/js/main.********.js	612 kB	+161 B (0%)

ℹ️ View Unchanged

Filename	Size
website/.docusaurus/globalData.json	49.9 kB
website/build/index.html	38.6 kB

_{compressed-size-action}

[slorber]

Let me think about it first... 🤔 We probably want to allow something like dateFormat: 'en-GB' as well to solve the need for DD/MM/YYYY

I don't know, that API would look weird to me and maybe too specific?

What are we trying to solve in the first place? I don't remember precisely

Are there any 'en-GB' users that do not want to format dates as DD/MM/YYYY?

If some user wants to use locale key en (or anything else) and still format dates as en-GB, maybe the solution would be to consider the key is not BPC47, and allow them to provide the BCP47 locale as attribute?

const i18n = {
  defaultLocale: "en",
  locales: ["en"],
  localeConfigs: {
    en: {
      localeCode: "en-GB"
    }
  }
};

[Josh-Cena]

Yes, maybe we want to merge this with htmlLang? i.e. use a short code for the base URL and the FS path, but the full BPC47 code for everything else in the code?

[slorber]

We can probably add this implementation for now, looks good enough 👍

[slorber]

maybe add a test case for this? Using something like ar-u-ca-islamicc ?

and a test case for an invalid locale, ensuring it falls back and fail-safe instead of crashing

[Josh-Cena]

We use new Intl.DisplayNames to construct the label, which is gonna crash on terribly malformed locale names anyways. new Intl.Locale is more resilient than new Intl.DisplayNames

[slorber]

This currently works fine: yarn start:website --locale "My-weird-locale"

But anything more fancy will crash: yarn start:website --locale "My weird locale"

But ok we can implement that later, considering we don't have anything setup to accept properly an invalid locale name