[CAL-1015] Booking date is always in english (booking/[uid])

[CarinaWolli]

Issue Summary

On the booking/[uid] page the date is always shown in English. The email confirmation shows the date of the booking in the correct language.

Date should be in german here:

_CAL-1015

[AaronPresley]

@PeerRich @CarinaWolli I've looked into this one, and it's a pretty simple fix from a technical perspective, but there are definitely some pros / cons to weigh from the business / design side.

Firstly, it seems DayJS does support i18n (source), however it requires the user's specific locale to be loaded. This would add some additional logic + data to be written each time the user changes their locale.

IMO this would also be overkill, because DayJS is likely simply loading CLDR data which is accessible natively within the browser by default. In this case that would be through the Intl.DateTimeFormat object which is supported by all major browsers (docs here).

The good news is that this means dates can be easily localized and translated into any locale supported by Unicode. The bad news is that you would lose a bit of control over how dates are formatted. Because correct date display varies so widely by any combination of language + region, proper localization means relying on Unicode's Intl.DateTimeFormat to control how and in what order months, dates, times, timezones are generated.

That's not to say we have NO control. You can review the Examples section of the docs to see what type of control they provide.

That brings us to a slight complication: duration. Currently Intl.DateTimeFormat only outputs a single date, and not a date range. Intl.DateTimeFormat does have a function called formatRange that allows for this, but browser support is much lower (source), and I would rely on the Cal.com team to decide whether that's an appropriate risk to take.

If formatRange() doesn't have enough support, I would suggest the UI to be slightly tweaked.

Currently this page has:

When:       $date
            $timeStart - $timeEnd ($timezone)

But I would suggest something more along the lines of:

When:       $date
Start Time: $timeStart ($timezone)
End Time:   $timeEnd ($timezone)

Splitting up each piece of data with a clear label would get closer to guaranteeing proper localization for every possible locale. Generally, relying on Javascript's built-in locale API's are strongly recommended, as the main browsers work directly with Unicode on these specifications and keeping them updated. This isn't necessarily true of third-party libraries.

Happy to work on this bug once the above decisions are made ☝️ Let me know if you'd like to discuss in further detail.

cal.com/aaronpresley

[CarinaWolli]

Hi @AaronPresley, thank you for taking a look at that 🙏

I am wondering, if we could format the date with Intl and leave the timeStart and timeEnd as it is (not sure how much difference there is between languages when it comes to showing the time in HH:MM format 🤔)? In general, I would prefer a solution that does not change anything in our current design

[AaronPresley]

@CarinaWolli that's certainly possible! Though since you can't use formatRange() I think the best approach would be to call Intl.DateTimeFormat for each of the individual piece of text (day month year + start time + end time + timezone).

I've thrown together this example on Codepen to demonstrate what I mean. This gets you close to the current output, but would be fully localized and translated as well.

Worth calling out that not all locales necessarily follow the pattern of $startTime - $endTime when displaying a range of time. However I agree that this seems like the best compromise until formatRange() gains more adoption.

[AaronPresley]

@CarinaWolli let me know if you'd like me to start on this fix. Not sure if you were planning to work on it?

[CarinaWolli]

@AaronPresley I like that, looks good 👍 You can work on that ticket, I'll assigned you :)