Presumptive incompatible change in future edition erroneuosly listed #583
Assignees
Labels
c: spec
Component: spec editorial issues
editorial
Involves an editorial fix
s: in progress
Status: the issue has an active proposal
Projects
Comments
|
The 9th edition will exist next June, and anything landed in master since the 8th edition is already in it. |
|
I know. But it slipped into the standard published by Ecma. It either shouldn't mention the 9th edition or say that it's going to be corrected in it, not was corrected. |
sffc
added
c: spec
sffc
added a commit
that referenced
this issue
Sep 9, 2021
# 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#presumptive-incompatible-change-in-future-edition-erroneuosly-listed Conclusion: There is something odd going on; the original PR, #471, is where the text in question originated, but how did the text get into Annex B without the corresponding change in SetNumberFormatDigitOptions? @ryzokuken to investigate. |
sffc
added
s: in progress
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The last point in B Additions and Changes That Introduce Incompatibilities with Prior Editions mentions the 9th edition.
The text was updated successfully, but these errors were encountered: