Normative: Take language subtag into account in locale hour cycle and calendar lookup - #1086
Conversation
|
Open question is whether we should rewrite the other preference lookup operations to work like this. As far as I can tell, hour cycles is the only data source where it matters. (Aside from |
gibson042
left a comment
gibson042
left a comment
There was a problem hiding this comment.
Open question is whether we should rewrite the other preference lookup operations to work like this. As far as I can tell, hour cycles is the only data source where it matters. (Aside from
<weekOfPreference>data, which we don't expose in JS.)
It definitely makes sense for CalendarsOfLocale, which also already uses RegionPreference and is specifically covered by rgScope.xml, and probably is not appropriate for TimeZonesOfLocale.
I'd like to just completely defer to <rgScope> per UTS #35 Part 6 Supplemental, but that'll be a bigger effort.
5c22c44 to
16b92c1
Compare
|
I've made the same change for CalendarsOfLocale, although there are not currently any language-region entries in CLDR's calendar preference data. Note interactions with other open PRs:
|
Some of CLDR's hour cycle preference data is indexed by language and
region, not just by region.
For example, Francophone Canada is listed as preferring a 24-hour clock
while Anglophone Canada is listed as preferring a 12-hour clock. As of
the current version of the spec text, it is not possible to return a
value that takes these preferences into account, because only the
region (Canada) is used for looking up the hour cycle preference.
This observably affects code such as
new Intl.Locale("fr-CA").getHourCycles()
which, after this change, will return an array where element 0 is "h23",
instead of "h12".
Closes: tc39#1056
16b92c1 to
0093c46
Compare
|
Tests in tc39/test262#5091 (which V8 and JSC already pass) |
sffc
changed the title
This test is for the normative PR tc39/ecma402#1086, where getHourCycles() and getCalendars() are changing to use language-region data if available, instead of just region-specific. It is not possible to write a test for getCalendars() since currently there are no known implementations where language-region-specific calendar preferences exist. LLM disclosure: I used a bot to search for suitable input locale candidates. I also used the same bot for a first draft of the test file, although I basically discarded the result.
This test is for the normative PR tc39/ecma402#1086, where getHourCycles() and getCalendars() are changing to use language-region data if available, instead of just region-specific. It is not possible to write a test for getCalendars() since currently there are no known implementations where language-region-specific calendar preferences exist. LLM disclosure: I used a bot to search for suitable input locale candidates. I also used the same bot for a first draft of the test file, although I basically discarded the result.
3 participants
Some of CLDR's hour cycle preference data is indexed by language and region, not just by region.
For example, Francophone Canada is listed as preferring a 24-hour clock while Anglophone Canada is listed as preferring a 12-hour clock. As of the current version of the spec text, it is not possible to return a value that takes these preferences into account, because only the region (Canada) is used for looking up the hour cycle preference.
This observably affects code such as
which, after this change, will return an array where element 0 is "h23", instead of "h12".
Closes: #1056