Intl.js
Intl.js copied to clipboard
andyearnshaw
Support nominative case of month names
Many languages on the Earth have cases and particularly nominative and genitive ones. That's why CLDR locale data contains stand-alone month translations but Intl.js one doesn't. In result, we have wrong formatted strings.
| Locale | MMMM { month: 'long' } |
MMMMd { month: 'long', day: 'numeric' } |
|---|---|---|
| FI native | huhtikuu | 5. huhtikuuta |
| FI polyfill | huhtikuuta :boom: | 5. huhtikuuta |
| RU native | апрель | 5 апреля |
| RU polyfill | апреля :boom: | 5 апреля |
If we do it for month names then we probably ought to do it for weekdays too. It's probably best to only include this data where it differs from the standard format so as not to unnecessarily increase the JSON file sizes for most languages.
I will be happy to take this, but we need to run some tests to see how much data are we talking about here. As for the 402 spec, I think we are covered by https://tc39.github.io/ecma402/#sec-formatdatetime 12.1.6.13.a.ix, specifically, this sentence:
ix. Else if f is "narrow", "short", or "long", then ... If p is "month", then the String value may also depend on whether dateTimeFormat has a [[day]] internal slot. If p is "timeZoneName", then the String value may also depend on the value of the [[inDST]] field of tm, ...
It doesn't say anything about quarters or weekdays. Do you think we should include that in the specification? /cc @srl295 @JCEmmons
I am using [email protected] for client and server. Right now server-rendering (with Intl polyfill) differs from browser (build-in Intl).
@ericf I use something like this
<FormattedDate
value={new Date(exper.start)}
month="long"
year="numeric"
/>
So I think for isomorphic JS applications it is very important to have correct cases for months and weeks. Regardless to file sizes.
May be you can build second npm module with all cases? And give it name, something like intl-huge.
@nodkz checksum will always be a problem when rehydrating. in the past I remember some conversations with some react folks to allow holes in the checksum verification process for cases like this where the rehydration might attempt to change the value. I also remember something about the formatjs components opting out of the update for the first rehydration.
