Localization of Dates, Times, and Timezones using Intl.DateTimeFormat

[AaronPresley]

What does this PR do?

Fixes #6951

Previously, the Booking page is fully translated except for the dates, times, and timezone. Below are relevant screenshots

Production (English)	Production (German)

This PR does the following:

• Created new functions in the @calcom/lib/date-fns package which allow for simple localization / translation of any date within the codebase
• Updated the Booking page to use these new functions to achieve translation

This Branch (English)	This Branch (German)

Approach

This codebase makes heavy use of DayJS, which does have i18n functionality (source). However this feature requires an additional import of the given locale's data. That means there would be an additional file loaded each time the user changes pages / changed languages.

This approach is likely overkill, because the DayJS locale data is likely CLDR data, which is available to use natively within Javascript through Intl.DateTimeFormat which is supported by all major browsers. Additionally, relying on native Javascript means we are almost guaranteed to be using data from Unicode, which isn't necessarily the case with a third party library.

Therefore, this code adds very simple wrappers around the native Intl.DateTimeFormat function. The use of wrappers are recommended because in the future there will likely be a scenario in which we want to override the default. Putting this code within a few wrappers now will vastly simplify things for our future selves.

FAQ

• Who did the translations? The translations are part of Common Locale Data Repository (CLDR), which is maintained by the Unicode Consortium (view some of this data here). CLDR is the source used by all major Operating Systems, Browsers, and everything in between. Under the hood, Intl.DateTimeFormat is referencing this data not only to get the translated value for "December" but also to know in which order the de locale expects a given date or time to be generated
• Why did the English output change? Since the correct date localization varies so widely by any combination of language + region, proper localization means giving up a bit of control to Unicode's CLDR. The difference output is a result of the Unicode Consortium determining that value is likely the least-bad output for the given lang + region. It's an imperfect approach, which is why I've embedded this code into a simple wrapper so the Cal.com team can overwrite the Unicode defaults should the need arise.
• How does this code determine which language to show? The localization will target any authenticated user's preferred language, otherwise it falls back to the locale set by the browser.

Environment: Production

Type of change

• [X] Bug fix (non-breaking change which fixes an issue)
• [X] Chore (refactoring code, technical debt, workflow improvements)

How should this be tested?

1. Book a meeting for any given event, in any given language
2. Observe the Date, Time, and Timezone output of the confirmation page
3. If authenticated, change your preferred language and observe the Date, Time, and Timezone are now translated into the desired language
4. If unauthenticated, change your browser's preferred language then observe the Date, Time, and Timezone are now translated into the desired language

Checklist

• No tests fail as a result of this change

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated
cal	✅ Ready (Inspect)	Visit Preview	💬 Add your feedback	Feb 10, 2023 at 6:25PM (UTC)

1 Ignored Deployment

Name	Status	Preview	Comments	Updated
ui	⬜️ Ignored (Inspect)			Feb 10, 2023 at 6:25PM (UTC)

[vercel[bot]]

@AaronPresley is attempting to deploy a commit to the cal Team on Vercel.

A member of the Team first needs to authorize it.

[AaronPresley]

@CarinaWolli ready for your review ☝️

[AaronPresley]

@CarinaWolli Attempting to get the E2E checks to pass by closing / reopening. Let me know if there's something else I should attempt here

[PeerRich]

rerunning now!

[PeerRich]

why was this closed?

[AaronPresley]

@PeerRich ah, my apologies - I switched from using the forked repo when you gave me access to the calcom team on GitHub, and hadn't realized this PR wasn't yet closed. Will fix it today 👍