add localization support for DateRange

[aleksarad]

Story: https://vimeo.github.io/iris/sb/translate-daterange/?path=/docs/components-dates-daterange--controls

What this PR does

Adds localization support for DateRange component based on this lucidchart

How it does that

• Adds a new optional prop locale to DateRange and Calendar (days of the week and months are handled inside the Calendar component)
• The default value of locale is en, so any existing instances of DateRange in use will remain unchanged
• Manually adds translations for strings used in the DateRange component
• Strings and dates are localized based on the locale prop

[juliewongbandue]

lgtm

[tylerthegrove]

I spoke with @aleksarad about this on Slack, but I'll relay the conversation.

I see two problems with this approach:

1. Tying the language to the locale
   This change restricts the locale for the date / time to only the 8 language options. This means that where 'en-GB' date format was supported based on a user's system setting, it will now be converted to 'en' format month-day-year.

See when I set my computer to en-GB the current Iris behavior

vs the changes

2. Restricting the languages that can be used
   Although 7 may be the base Vimeo set of translated languages, this change doesn't allow adding any more languages without adding them into Iris. Long term I think we'd like to take an approach similar to Shopify where translations are passed into a provider. Using a translation prop would be more along those lines.

My proposal is to:

1. remove the locale prop completely and go back to defaulting to the user's system settings for date / time.
2. using a prop translation where an engineer would pass in key / value pairs for the component strings. eg(
   { apply: 'Apply', clear: 'Clear', startDate: 'Start Date}` )

We can have a translations file with keys for our base languages. Then it can be used like
import { translations } from @vimeo/iris/DateRange <DateRange translation={translations['en']} />

translations['en'] would be the default prop value.

[aleksarad]

Made the changes mentioned above^

Something I want to draw attention to is the potential mismatch between browser locale and translated strings.

For example, if the component is translated to es, but the browser remains in en:

Any date related values will remain unlocalized.

vs. translated to es and browser locale set to es, which looks consistent:

I am unsure of how common the first scenario is (as in, do users ever change the language on Vimeo but not their browser), but just wanted to surface in case it is something we'd want to account for.

[juliewongbandue]

Made the changes mentioned above^

Something I want to draw attention to is the potential mismatch between browser locale and translated strings.

For example, if the component is translated to es, but the browser remains in en:

Any date related values will remain unlocalized.

vs. translated to es and browser locale set to es, which looks consistent:

I am unsure of how common the first scenario is (as in, do users ever change the language on Vimeo but not their browser), but just wanted to surface in case it is something we'd want to account for.

Hey @aleksarad , this is a good catch and a great question. I'm not sure if users change the language on Vimeo but not in their browser... 🤔

Aside from that, this PR looks good to me.

[tylerthegrove]

Made the changes mentioned above^

Something I want to draw attention to is the potential mismatch between browser locale and translated strings.

For example, if the component is translated to es, but the browser remains in en:

Any date related values will remain unlocalized.

vs. translated to es and browser locale set to es, which looks consistent:

I am unsure of how common the first scenario is (as in, do users ever change the language on Vimeo but not their browser), but just wanted to surface in case it is something we'd want to account for.

So let's include those Month and Day abbreviation strings in the translation. Similar to how Shopify handles it here. We can just add "months" and "daysAbbreviated" keys. We can always fallback to the browser if we want to.