Define if "ca" Unicode extensions have an effect on Intl.Locale.prototype.getWeekInfo() #30
Comments
I think we should keep the spec text AS IS so one day we may be able to provide such information from the locale data. @sffc @ryzokuken @zbraniecki - what do you think? |
|
I think the current spec text does not rule out the impact of any Unicode extension so it is clear any unicode extension may have impact to the weekInfo- I think this is by design. For example, some subdivision may observe different weekend . The fact CLDR and ICU currently does not havce those data should not be the reason we restrict the spec to allow that to happen one day. As you point out some state/province in some country observe different weekend practice and that would be needed to come from rg or sd unicode extension, or come from the ca extension one day. |
|
If any Unicode extension (the relevant ones are: "ca", "rg", "sd", or "fw") should have an effect, we should explicitly mention that instead of leaving this unspecified, because that way we can more easily guarantee compatible behaviour across different implementations. Is the "u-ca-iso8601" special case something specific to ICU, because I don't see it mentioned anywhere in https://unicode.org/reports/tr35/tr35-dates.html#Week_Data? Are there any other calendars where a user would expect different week-info data when a calendar is explicitly set through "u-ca"? For example if |
|
Reading the relevant ICU source code to check for additional issues, I've found that ICU respects the For example: > new Intl.DateTimeFormat("en-u-rg-afzzzz").resolvedOptions().calendar
"gregory"
> new Intl.Locale("en-US-u-rg-afzzzz").weekInfo
({firstDay:6, weekendStart:4, weekendEnd:5, minimalDays:1})
Week info data isn't really tied to a language, but instead is typically derived from a region. Also see Calendar::setWeekData and ulocimp_getRegionForSupplementalData in ICU. This makes the spec proposal somewhat inconsistent, because Should I create a separate issues for these two problems? |
# 2021-09-09 ECMA-402 Meeting ## Logistics ### Attendees - Shane Carr - Google i18n (SFC), Co-Moderator - Corey Roy - Salesforce (CJR) - Romulo Cintra - Igalia (RCA), MessageFormat Working Group Liaison - Thomas Steiner - Google (TOM) - Frank Yung-Fong Tang - Google i18n, V8 (FYT) - Long Ho - (LHO) - Zibi Braniecki - Mozilla (ZB) - Eemeli Aro - Mozilla (EAO) - Greg Tatum - Mozilla (GPT) - Yusuke Suzuki - Apple (YSZ) - Louis-Aimé de Fouquières - Invited Expert (LAF) - Richard Gibson - OpenJS Foundation (RGN) - Myles C. Maxfield - Apple (MCM) ### Standing items - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! - [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) - [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com) - [Matrix](https://matrix.to/#/#tc39-ecma402:matrix.org) ## Status Updates ### Editor's Update RGN: No updates. ### MessageFormat Working Group RCA: We are working on a middle-ground data model that I hope will unblock the situation. EAO is focused on it, with Stas, Mihai, etc. EAO also put together an initial spec proposal. EAO: I put together a spec outline, not a specific proposal. I think we will be able to merge it later this week. ### Proposal Status Changes https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking FYT: Some more Test262 coverage is done. But we still need help. RCA: I updated browser compat for locale info, documentation for hour cycle, etc. FYT: Do we have an instruction guide about how to update MDN? RCA: The process is moving quickly. It will be easier, though: you can just edit a Markdown file. ## Pull Requests ### Add changes to Annex A Implementation Dependent Behaviour tc39/proposal-intl-locale-info#43 FYT: We added some changes to Appendix A. Does this look good? Do we have consensus to report this to TC39? SFC: +1 RGN: +1 LAF: +1 #### Conclusion Approved ### Change weekInfo to express non-continouse [sic] weekend tc39/proposal-intl-locale-info#44 FYT: Some regions have a non-contiguous weekend. This PR changes the data model to reflect that. LAF: I wonder how this should be understood for all countries. In certain countries, the two "out of business" days may be not contiguous. Should we call it business day and non business day? Because "weekend" might not be the correct terminology. SFC: Is there precedent in CLDR for using "business day" instead of "weekend"? EAO: A quick Google search suggests that Brunei calls these days "weekend". SFC: LAF, please open an issue on the repository to discuss the option name change. SFC: Do we have consensus on the change? LAF: +1 SFC: +1 #### Conclusion Approved ## Proposals and Discussion Topics ### CollationsOfLocale() order tc39/proposal-intl-locale-info#33 SFC: I feel that lists should define their sort order. This is similar to the plural rule strings discussion from a couple of months ago. ZB: I represent the other side. I think developers should not be depending on the order. LAF: (inaudible) RGN: There is guaranteed to be an observable order. The question is whether that order is enforced across implementations, and if so, what should that order be? FYT: Could we return a Set? RGN: Sets also have observable order. SFC: I propose we bring the meta question to TC39-TG1 as a change to the style guide. LAF: +1 about order issue FYT: OK #### Conclusion SFC to make a presentation to TC39-TG1 to establish a best practice in the style guide. ### Define if "ca" Unicode extensions have an effect on Intl.Locale.prototype.weekInfo tc39/proposal-intl-locale-info#30 LAF: My opinion about ISO-8601 is that it is not connected to any locale. Something like Gregorian is connected to a locale, and could carry week info. But ISO-8601 is international. SFC: I think we should consult with CLDR. FYT: This is about the first day of the week and minimal days in the week, not the weekend days. I personally believe that we shouldn't limit the extension; for example, a subdivision could have legislation to change this info. LAF: In my opinion, the impact of saying whether Sunday or Monday is the first day of week, or on the minimal days, is to make a "week calendar": a calendar that lays out days in a week, dated by week number. I can imagine that some countries would like to distribute their own calendar, but I feel that there is a need among people to have the same week numbers. I don't know for sure where the correct place for this concept is. ZB: This is inspired by the mozIntl API. The reason I needed it was for a general calendrical widget, the HTML picker. I think date pickers in general need this, not just calendar layout. I think it is a high-importance API. SFC: I think the calendar subtag, or other subtags like the subdivision, should be taken into account. FYT: I think we should take the whole locale to influence the result. FYT: Do we need to make any changes to the proposal, and if so, what changes are needed? RCA: No strong opinion on that, but concerned by the possible conflict with Temporal #### Conclusion SFC, FYT, and LAF agree that the whole locale (including extension subtags) should influence the weekInfo. FYT to share these notes with Anba and wait for follow-up. ### JS Input Masking 🎭 - Presenter: TOM - Slides: https://goo.gle/ecma-402-js-input-masking - Explainer: https://github.com/tomayac/js-input-masking/blob/main/README.md - JS polyfill: https://github.com/tomayac/js-input-masking-polyfill FYT: Thanks for the discussion. (1) Some parts of what you proposed… if the formats are the same across different regions, it shouldn't be part of Intl. For example, if the ISBN format is the same across regions, it shouldn't be in Intl. (2) Is the name "input masking" correct? (3) A new item to consider is the postcode. That differs a lot around the world. The US has 5-4, India has 6 digits, Canada has special alphabetic rules. (4) It would be good to validate whether a string is a valid input. For example, maybe 13 digits is a valid ISBN, but not 14 digits. (5) A Googler on our team built libphonenumber, and it ended up being their full-time job for a while. TOM: Postcodes are interesting. For validation, that's interesting and useful. Thanks for confirming that it is useful. I think it would make sense to have it in the proposal. EAO: (1) Having built a library like this in the past, you start facing the issue of how to report errors on the input. So it becomes error reporting, but you need to do a best effort at the formatting while also reporting errors in a side channel. (2) Formatting while the string is being edited is just really hard; you should just wait until the field loses focus. TOM: I agree that live updating the field is challenging. What you said about error reporting is interesting. Verification needs a lot of thought. I think it's something most developers probably want. EAO: The biggest question is, how does the side-channel error reporting happen? Because that's an interesting question for a UI component like this. TOM: It seems like it could hook into the mechanism for email verification that we already have. And for on-the-fly formatting, hopefully you could write the formatter so that it can listen to whatever event the developer thinks is the right event. EAO: It's not just about a binary error. It's about providing more context to the error messages. TOM: I think many things can be done. I'm new to this area, so I don't know the precedent. I'm looking for more experience. ZB: Thanks TOM for the presentation. I've worked in this area before. I'm excited about the space, and I have a lot of questions. (1) Parsing is hard. There are a lot of questions here. What happens if they write LTR and RTL? What happens if they type in Arabic numerals? What if they use different kinds of separators? You quickly get into an uncanny valley. (2) You should also think about address formatting, which is like postcode and phone number. Where do you stop? (3) International placeholders is an interesting topic. How do you present a placeholder for a phone number? That really depends on the region. (4) I'm not sure that adding ??? is good for the scope of the spec. (5) About whether this belongs in a spec. It seems like a lot of UX teams will want to customize exactly what the output looks like: they agree on most of the format, but want to change a couple things. There's a good question about how much of this is i18n. (6) And finally, and this is the strongest point, if we were to specify what you are specifying, we would need to back it with a strong library. Because speccing it in ECMA-402 doesn't give us everything. So why not start with writing the foundational library, maybe one that can be used in many different programming languages, and then once you have the library, come back to ECMA-402 and ask whether we should bake it into the browser? That can then help us answer questions about whether the payload is sufficiently high such that it makes sense to ship it in the browser. So basically, I think we should start with a library. I think ECMA-402 is likely not the right place to start. TOM: We could build a library, but we run the risk of making the "15th way of doing things" (in reference to the XKCD comic). Temporal started by making a polyfill, and is now integrating it into the browser. We already have a lot of input masking libraries. RCA: I think this is really useful. (1) I'm concerned that the scope could be very large. (2) I'm concerned about what ZB said; organizations where I've worked have wanted to have their own way of doing things with slightly different interactions and so on. That formatter could be a custom thing for that institution. (3) Another thing is the interoperability with HTML. You could have an input credit card, the pattern, the validation, etc. (4) Highly interactive input fields could slow performance on low-resource devices. TOM: For performance, the obvious tweak would be to do validation on the server. YSZ: I think this is a super important part of the application. (1) Like FYT said, some of this data is not Intl data. (2) Phone validation is very complicated, like ZB said. We need to care about the UI; for example, inputting the credit card should trigger a numeric keyboard rather than an alphabetic keyboard. So it seems like we need <input type="phonenumber"/>. Did you consider starting there? TOM: I thought about that, and I put it in the explainer as an alternative. SFC: In order to avoid the "15th standard" issue, you should approach the industry leader in i18n standards, the Unicode Consortium, about making a working group to establish the industry canonical solution. ECMA-402 looks for prior art, and Unicode is the place we point to most often. This is similar in a way to the MessageFormat Working Group, which was chartered to resolve the competing standards for MessageFormat by bringing all the authors together. TOM: Yeah, reaching out to Unicode and seeing if this has come up before would be a good option. As I've said, I had this in the String prototype, and then realized that this should maybe be Intl. Credit card numbers are generally not Intl, but phone numbers are. So creating that prior art makes sense. ZB: I had discussed this a few years ago with Unicode. But with what SFC said, where there are multiple competing libraries, it means that we don't know what the answer is yet. Once we put it in ECMA-402, we won't be able to change it. When writing a library, we can make it and discard it with something better later. It makes sense that we need a place to assemble expertise from the many organizations. Maybe Unicode is the place. And only after we have that canonical implementation, we can evaluate whether it fits in ECMA-402. MCM: The question about new input forms was raised earlier. Did you list use cases where form input types would NOT be sufficient for, where you need the JS APIs? TOM: In a Node.js server, and you have a CSV file of unformatted phone numbers, you might want to format on the server. So it makes sense to have isomorphic Node and client-side behavior. MCM: Has Node.js said that they need a standard for this? Aren't there already Node modules for this? TOM: Deno is an interesting case. They've started implementing Web APIs like fetch. Programmers are used to the way Web APIs work, and they use them in Deno the way they expect them to work. ### LookupMatcher should retain Unicode extension keywords in DefaultLocale #608 GPT: Seems reasonable to me. EAO: +1 CJR: +1 #### Conclusion OK to move forward with this change; review the final spec text when ready. ### ships the entire payload requirement #588 #### Conclusion FYT to follow up with Anba's suggestions on the Intl Enumeration API to harden the locale data consistency. ### DateTimeFormat fractionalSecondDigits: conflict between MDN and spec #590 GPT: It seems reasonable to match the Temporal behavior. SFC: Do we want to add 4-9 now, or wait until Temporal is more stable? #### Conclusion Seems reasonable to move forward with a spec change. Still some open questions from Anba and SFC. ### Presumptive incompatible change in future edition erroneuosly listed #583 RGN: The spec version is immutable. FYT: Is there a way to publish errata? RGN: I don't think so… I do see some errata on ECMA International, but I don't see references to those errata. SFC: The PR in question is #471. It was merged in January. I don't know why the change to Annex B made it into the edition, but not the normative change to numberformat.html. FYT: The other issue is that we have long tables in the PDF that get cut off. RGN: We're trying to raise funding to generate the PDF by a better mechanism. #### Conclusion Ujjwal to investigate. ### Accept plural forms of unit in Intl.NumberFormat #564 CJR: If we accept the plurals in RelativeTimeFormat, I can see a case for doing that also in NumberFormat. SFC: There are basically 3 approaches. (1), we only accept singular units. (2), we accept plural forms for all units… stripping off the "s"? (3), only special-case duration units like days and hours. EAO: Pluralization for all units is challenging. "inches", "kilometers-per-hour" CJR: Having listened to your explanation, SFC, I agree with your assessment. Doing it on an ad-hoc basis is leading away from consistency. RCA: +1 for not allowing plurals. RGN: I share this opinion. Is there already a reference to CLDR, to prevent this from coming up again? #### Conclusion Stay consistent with CLDR, and add a normative reference to CLDR if there isn't already one.
|
Discussion from 2021-09-09 TC39-TG2: https://github.com/tc39/ecma402/blob/master/meetings/notes-2021-09-09.md#define-if-ca-unicode-extensions-have-an-effect-on-intllocaleprototypeweekinfo We did not reach a hard conclusion, except to establish that we do feel it is important to take subtags such as |
I do not believe the specification say it should NOT also change it, and that is the point, the specification should NOT say it won't ever change it. If ICU does not do so, or an implementation of this spec does not do so, or the CLDR include the wrong information or lack of information to implement the correct result, then those issue should be filed to ICU, CLDR and/or browser bug tracking system, instead of restrict this specification to do the right thing. |
agree - but why is this related to "u-ca"? |
It's not directly related to "u-ca", but instead about the ICU implementation, which in turn is related to "u-ca". And that's why I asked if the questions/issues around the region subtag and "u-rg" should be tracked in a different issue. 😄
|
As mentioned above, any relevant Unicode extension keys should be explicitly documented. Additionally, if Unicode extension keys have to be taken into account for any of |
But neither does the specification say that it should change anything.
But what exactly is the "correct result"? Can you point to a specification which describes this "correct result"? |
|
IMHO, from the user's point of view, Intl.Locale.prototype.weekInfo has to take the "ca" Unicode extension into account. |
https://tc39.es/proposal-intl-locale-info/#sec-week-info-of-locale in UTS35 https://unicode.org/reports/tr35/#Unicode_locale_identifier which include the extensions The weekday value indicating which day of the week is considered the 'first' day, for calendar purposes. |
It is ALREADY documented for Intl.Locale object Since these weekInfo is a method on Intl.Locale the RelevantExtensionKeys is already covered in the construction of the Intl.Locale object. For example, let's look at other pre-existing function in Intl.DateTimeFormat Spec text in In the same way, Intl.Locale.prototype.weekInfo behave only on the internal slot of Locale, which is loc.[[Locale]] |
|
I think we're still looking for some clarification on this issue, see this comment on the Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1693576#c27 |
|
@FrankYFTang @anba Is this issue still relevant? This proposal is up for discussion in next week's TC39 plenary and it would be great to sort this out before the meeting rather than discuss it in committee again. |
|
Note that the NumberFormat spec text explicitly states when items are "numbering system dependent" ( The situation here is slightly different since we're operating on a whole Intl.Locale object |
do you mean "-u-nu" (instead of "-u-ns"?) |
This comment was marked as resolved.
This comment was marked as resolved.
These are different |
|
I still like to see an explicit definition in the spec if any Unicode extensions are considered when computing Two options:
|
|
The current spec text said "based on locale." in https://tc39.es/proposal-intl-locale-info/#sec-week-info-of-locale which means all information in the unicode_locale_id could impact the resolution and this issue request us to clearly state "how that is based on" with specific algorithm. |
FrankYFTang
changed the title
|
Asking Mark Davis (Google) and Peter Edberg (Apple) from CLDR / UTS35 co-authors about this now. |
|
Per anba's comments in #30 (comment) We need to consider specifiying out the priority of information deciding the getWeekInfo from probably also |
|
ref upstream issue in https://unicode-org.atlassian.net/browse/CLDR-16866 |
|
CLDR 16866 is is now considering to specify the algorithm to determine firstDay of the weekData from the following information (and the priority) fw > rg > ca > sd (if no conflict with explicit region subtag) > region_subtag > likely_subtag region We will not change this proposal until UTS35 complete that specification change. |
|
@FrankYFTang This is on the TG2 agenda but it's not clear there is anything to discuss. We are just waiting on the CLDR change to land, right? If there is anything to discuss, please add it back to the agenda. |
|
Issues are solved vy pr 83 and 87 |
When passing a language tag which includes the "ca" Unicode extension to ICU, the calendar is taken into account when retrieving the week-info attributes from ICU's
UCalendar. Or more concretely, if and only if the calendar is "iso8601", it's taken into account.Because this makes only a difference when the calendar is "iso8601" and always only modifies
firstDayto Monday andminimalDaysto 4 days, I don't think providing this feature provides any real value and we should make it clear in the specification that "ca" Unicode extensions shouldn't be taken into account.Example when "iso8601" is passed to ICU:
The text was updated successfully, but these errors were encountered: