- Shane Carr - Google i18n (SFC), Co-Moderator
- Louis-Aimé de Fouquières - Invited Expert (LAF)
- Ujjwal Sharma - Igalia (USA), Co-Moderator
- Yusuke Suzuki - Apple (YSZ)
- Ben Allen - Igalia (BAN)
- Henri Sivonen - Mozilla (HJS)
- Eemeli Aro - Mozilla (EAO)
- Frank Yung-Fong Tang - Google i18n, V8 (FYT)
- Jesse Alama - Igalia (JMN)
- Richard Gibson - OpenJS Foundation (RGN)
- Discussion Board
- Status Wiki -- please update!
- Abbreviations
- MDN Tracking
- Meeting Calendar
- Matrix
BAN: It's been slow. Most merges have been related to Temporal syncing.
USA: ECMA-402 11th edition is approved!
https://402.ecma-international.org/11.0/index.html
USA: I feel BAN has been working as an editor for some time. I think Ben should officially join as a co-editor.
SFC: Ben has been an apprentice editor for 1 year, so this is a great time to give Ben the promotion!
USA: We'll formalize it in the next TG1 Plenary.
EAO: It has been relatively quiet. The most active thing is the open ballot in the working group about normative requirements involving error handling and fallbacking: whether to require these at all, and what are the specifics for what's happening. This impacts what we do in Intl.MessageFormat about error handling, following up from the discussion from the Helsinki discussion in June.
Voting thread: unicode-org/message-format-wg#830
Discussion thread: unicode-org/message-format-wg#831
EAO: The other thing is, Addison Phillips and I have been discussing what Bi-Di marks to allow for, or strongly recommend. For right-to-left content to appear without difficulty in the overall left-to-right syntax. I'm not familiar with this being implemented in other programming languages.
This is not necessarily appropriate for JavaScript, but it’s an interesting discussion in the MessageFormat working group. It’s not concluded yet, but is not controversial in any way.
SFC: Have you considered whether UTS 55 applies?
https://www.unicode.org/reports/tr55/
EAO: We're looking at it, but UTS 55 is not an all-in-one solution.
SFC: Bi-di is a key thing, and problems related to it are something that MessageFormat can leverage. One thing is making sure that the MessageFormat syntax are compatible with the constraints in UTS 55, which tries to indicate what’s an identifier character, what’s a syntax character.
EAO: We should be UTS 55 compatible.
FYT: I synced V8 to the latest DurationFormat spec. Some LocaleInfo changes needed, basically bug fixing. Currently staging DurationFormat to Chrome 128, which will be available generally to the public in end of August, and planning to ask for shipping DurationFormat for 129. Haven’t done it yet, but upcoming in September. Updating LocaleInfo to match current spec, removing getters in a separate cycle later.
BAN: Does that mean it's plausible to move to DurationFormat Stage 4 in Tokyo in October?
FYT: It's possible but a little early to talk about it.
SFC: It sounds like it will still be in time for ES 2025 / 12th edition.
SFC: HJS, did you have any updates?
HJS: Pending patch for non-ISO calendars in Temporal, done by Anba.
SFC: I believe Anba is using ICU4X calendars for that
HJS: Yes
SFC: That’s a very good development – I’m glad to see that.
YSZ: In JSC side we are updating Intl.DurationFormat and right now we’re working on the recently updated spec (?)
SFC: That’s wonderful.
YSZ: The good thing is that it is updated by the contributor who is working on this thing as an open-source project.
SFC: I’m happy to hear that, because I was slightly concerned that since we made that API change, was that going to be in JSC vs. V8. It sounds like they’ll be interoperable, so that we can go to stage 4.
BAN: The thing that's been most active is they have new working drafts for scripts. They have docs describing the diffs for Urdu, etc. There hasn't been any discussion of MessageFormat on that side from what I can see.
SFC: Question for W3C – TPAC meeting in Anaheim coming up soon, do you believe it will be productive for
EAO: My expectation for MessageFormat for W3C right now is relatively low, since there isn’t a W3C or WHATWG proposal activating at the moment. That’s essentially blocked by us not knowing when we can get Intl.MessageFormat to stage 2, so it doesn’t make sense to go ahead of things on W3C. I don’t have any expectation of this being considered there. Second point is that I am at least going to be at TPAC, and would be interested in any of us who will be around here.
USA: The ones of us who live in California will find it quite convenient.
SFC: One reason I brought this up is that we haven’t had an in-person TG2 meeting for four and half years. So I was also considering whether this would be something that we’d consider doing, if a lot of folks will be around at TPAC. There’s also UTW, the Unicode-specific meeting in Sunnyvale in October, so logistically that would be quite easy for me to set up an in-person TG2 meeting on a Thursday in October. But I want to see which event is likely to draw the most delegates.
EAO: Would be interested to get a determination of when an in-person thing could be happening as soon as possible, since I will be making transatlantic travel plans around it and will appreciate doing so as soon as possible.
SFC: I agree that we should figure this out soon. It could be the case that for our official meeting we continue to do on video, but also have an informal working meeting that’s not necessarily an official TG2 meeting.
USA: I don't think I'll be traveling to either event.
EAO: I’ll be at TPAC, I may be able to make UTW and possibly a TG2 meeting in association with that, but that’s dependent on other travel timings. TPAC, I am definitely coming.
HJS: I have plans that conflict with both of these, so unfortunately I won’t be attending either.
SFC: I certainly think UTW is a valuable event if you’re in the i18n space. ECMAScript is a huge part of this, but also in keyboards, localization, CLDR, ICU4X, talks about integrations, globalization, the business side of things.There’s basically everything in this space. It seems like EAO is the person I should be talking to about scheduling, because it doesn’t seem that others are considering traveling.
JMN: I can present briefly. This is my chance to rejoin this group, I discussed Decimal here a few months ago. Since then Intl has disappeared from my own radar, so to speak – I’ve been focusing on getting the spec right. As we get ready for plenary I wanted to push the turbo button on getting this ready. I’ve prepared a PR just yesterday – there’s nothing final there, but I can present it if you like. But my open question is whether I’m barking up the right tree here, or if I’m missing the ball. I can’t verify for myself that I’m doing the right thing. Consider this a grand ping that Decimal is still going. If there are things that I’m getting badly wrong, or things I’m completely missing – pieces of the contact surface between Decimal and Intl that I don’t know. The main contacts points are PluralRules, which is fairly small, and then the larger one is NumberFormat. I’m not asking for a live review, simply bringing the topic back to the table.
EAO: Sort of a side topic: what you said reminded me of the fact that Intl.PluralRules supports Number but not BigInt, whereas Intl.NumberFormat supports both. As you work through the Intl.PluralRules spec, the updates required to that to make it work with Decimal, it might be interesting to keep in mind that we’ll be adding a third type of input to PluralRules at some point, and then this is a bit of a question: if we were to add BigInt to PluralRules, would that be a fully qualified proposal, or could we do it as a smaller change in order to get that through. Or is there a specific reason that I’m not aware of that PluralRules isn’t and shouldn’t be supporting BigInt
JMN: When I initially got started with Decimal, Intl wasn’t on my radar – it came up on my radar late. The main thing on my mind is just implementer concerns about this stuff. Very good question. I don’t think it would be difficult, though, to add that support.
SFC: Two things: First, on EAO’s side topic, I thought I recalled that we had discussed this a few years ago and that it had already been resolved that we should have it. If we did do that it may have just gotten lost in the tracker. We should support the same shape of input in NumberFormat as in PluralRules. The second is about Decimal specifically. The other comment about Decimal is going back to JMN’s topic – I’ve reviewed your PR and left some feedback on it, and it looks like you commented during the nighttime in my timezone, and I haven’t seen it yet.
JMN: Yes, because of the time zone differences I didn’t expect you to look at it. Mostly I just want a sense check that I’m heading in the right direction, and whether we’re miles away from a solution or getting close.
SFC: The reason I asked this question is because it’s a little bit – well, I serve two roles reviewing this spec. One is to check if it’s correct. My other role is determining whether it achieves what we want it to achieve. As of right now, or as of yesterday when I reviewed the code, 173 does not achieve what we wanted to achieve with Intl integration with Decimal. If the goal of the PR is “I’m changing around data types to make another PR later”, that’s fine, but I want to be clear on what I’m actually reviewing.
JMN: There’s a lot of cleanup I’m doing in response to feedback we’ve gotten recently. My hope is that it’s a lot cleaner. I would say it’s not necessarily the final thing yet, but I guess it’s an honest effort to fix those open gaps that were identified a couple of months ago, as well as to see what is needed for PluralRules. My sense is that not that much is needed for PluralRules, since PluralRules for the things I’m doing just delegates a lot of the work to NumberFormat – not entirely, but largely – and so I’ve fallen back to polishing up the NumberFormat part. One task for me would be to take a look at some of these cases that you’ve given me, and see if I can convince myself that they go through. I can ping you separately to see if it’s ready. But also if there’s other big things for me to know, that would be helpful.
EAO: One thing that I believe I’ve mentioned previously is that in parallel to the discussion on Decimal and Decimal integration into NumberFormat, there is a discussion that at least I’ve seen SFC pushing for in the MessageFormat context, which is making more consideration for formatting values that contain not just a numerical value, but also additional things around that, so such as in the case of Decimal the information about fractional digits and how many of them there are, but also currencies, the currency units, and other units as well, where the question is what is this a unit of? This makes it interesting for us to consider whether the PluralRules integration of Decimal should be its own thing, or if we should instead design a protocol for input into NumberFormat and PluralRules be able to effectively encode not just a value but which we currently require as options to do the work – such as currency, minimum/maximumFractionDigits, and units. Is there interest, other than just my interest, in considering the design of what this protocol would look like that would also work for Decimal, and that Decimal could use to work with NumberFormat. Or should we consider Decimal specifically, how does this type of information get integrated with NumberFormat. The solutions we’re encountering might be very similar to each other, and we shouldn’t have multiple similar solutions that could be unified.
JMN: That sounds cool to me. If I recall correctly, BAN and a few other people discussed Decimal and units. Discussing numbers and scales, labeled numbers, also makes sense. TBD, but thank you for the insight.
USA: I want to second what SFC said earlier, and after that I agree that the PR you made, JMN, is a step in the right direction, but I slightly disagree – I hope this isn’t the last time we’re seeing you – it’s going to be a long time before we standardize all of Decimal. So I want to say it’s good enough in terms of being good enough. I’m wondering if what we have is sufficient for stage 2, which I think it is, and after stage 2 there’s a couple more stages, so we’ll have to keep iterating through the details. It’s the most crucial stage for most proposals in terms of solidifying the API and the options. If we go for something near-perfect right now, that near-perfect thing is going to be going through a lot of iterations anyway.
SFC: I have responses to these things. First to EAO’s comment, I think that Decimal is a numeric type, and Decimal is a type that should be formattable by Intl.NumberFormat. And that’s enough motivation for having it accepted in NumberFormat.prototype.format. I think there’s going to be an interesting discussion about currencies and other things, but I don’t think that discussion conflicts with just being able to format a Decimal in an Intl.NumberFormat. The second comment was about the trailing zeros and things, I’ve made the case for a long time that this is a justification for an integration of Decimal with NumberFormat and PluralRules. The third thing is that when I do look at the spec, one reason I find JMN’s PR a little hard to review is because I’m not clear on what they’re actually trying to do, and it’s hard for me to review it in terms of “does it do what it’s trying to do.” With code, if I send a PR just to refactor things, that’s fine. But with spec, when you refactor things, it’s a little hard to, out of context, understand the motivation. What anba does is stack normative commits on top of editorial commits, so that I can see what the motivation is for the editorial changes. When you refactor code, it’s mostly harmless, but when you refactor spec it’s not exactly free, because polyfills and such follow along line by line. So editorial changes should have some motivation, in terms of “this makes the normative change easier to make.” something you could consider doing is finish writing the normative change, and that would give me and other reviewers more context when reviewing it.
JMN: That’s just the feedback I’m looking for. I appreciate the comparison with normal code PRs, that’s very helpful.
EAO: A bit of procedural clarifying questions. One is that what I asked earlier, about adding BigInt support to PluralRules, is that something that needs to go through the whole staging process or is that something that could be PRed into the spec? It wasn’t clear to me at the beginning which way we’d go with that.
USA: I think that some people have – basically everyone has their own understanding of what that line is. So size might be one consideration, but for me personally I believe that the decision is mostly about the nature of arguments and discussions that we’re looking forward to. Given the nature of this, that it’s simply a question of completion and symmetry, and it’s fairly straightforward what needs to be done here, I think there’s a way we can get it through. There is a possibility though that if you put in a big normative PR, people will say they have concerns. But in this case I’d say we should do the “ask for forgiveness instead of permission” thing, because if we ask in advance we will absolutely end up with a proposal.
SFC: I agree with USA. The thing that’s worked the best has been to set the line based on the amount of controversy we expect, since one of the reasons for the staging process is to resolve conflicts/controversies. This is something that we should start as a pull request and bring both to TG1 and TG2, and if there are concerns that people bring up, we’ll then make it a proposal. The other reason is if it’s a large or intricate change, and we need more scrutiny in terms of looking at the corners of the spec. For example, JGT recent work on time zones I encouraged him to make a proposal out of it, even though it’s a fairly small PR. I would say with PluralRules BigInt it’s likely a pull request, but first we should file an issue as step one.
EAO: As you’re working on almost exactly this but for Decimal, would you be interested in a PR on fixing PluralRules for BigInt, or do you think it’s something someone else should take on?
JMN: I’m definitely interested, it seems to be a fairly small change, and I’ve been heads-down in this spec for some time.
EAO: Let’s sync about this offline, I’m very interested because it makes stuff in MessageFormat very complicated, because it’s handling NumberFormat and PluralRules behind a single number function. The other thing is if there’s interest in figuring out if there’s a common protocol we should be designing for, when numbers are coming to NumberFormat as a value rather than an option. Should I set up a call, or does anyone have a better thought for how to take this forward. It seems like it will be a proposal-scale thing.
SFC: I feel like there’s several items that may be bigger items that may be helpful to jam on together, to figure out what the shape of the proposal would be. StableFormatting’s another one, which has been stalled. And I’d put Intl.MessageFormat in the same bucket with that. That might be a good topic for an in-person TG2 meeting. Alternatively if someone wants to bring a proposal forward at this meeting, well, we mostly discuss proposals and []. I do meet with BAN about once a quarter, in terms of backlog issues and that sort of thing, but I’d like to do it more with other proposals as well.
JMN: I think I got what I came for. Thanks, everyone!
tc39/proposal-intl-messageformat#54
EAO: I added this to the agenda, so I figured I can present on it. In MessageFormat, we end up with a lot of functions for formatting numbers. [several things that call several other things]. But we’re going to lay out other [?]. And essentially we’re going to have an alternative formatting for calling these, because it’s important that we make these functions somehow available in JavaScript code so that people extending the core set of functions for formatting with their own [?] that may require calling our own formatters. Making the built-in formatters available makes the lives of extension implementers easier. Currently they’re available through creating a MessageFormat object, and then in the resolvedOptions of that there’s an object that you can use. But as FYT quite rightly pointed out, this API is too well-hidden, that it should be readily available. And my preference on this is to add static functions like MessageFormat.number and MessageFormat.dateTime, corresponding to each of the message formatting functions we provide. I wanted to highlight this, and get a discussion around it, and ask this group if this is a sensible way to proceed, or if there is some reason we should be more active in hiding these functions, because of caching or other concerns, that would make it such that we should provide a different interface for accessing these functions.
FYT: I think we should look at the thing as three different aspects. The first is that MessageFormat have the ability to pass in a custom function to formatters, which I think we is an ability we already have. I’m okay with having a function to override or customize the formatting, I’m okay with that. But the second thing, that I think EAO pointed out, in order for the caller to provide that function it would be easier if there’s a way to get the default implementation as a function and then do some preprocessing or post-processing to write that custom function, instead of the custom functions having to write everything from scratch. It is currently in the spec text, you create a MessageFormat first and then you do something else to get it. I think if you’re doing that, it’s better to define some static class function to hold onto it. I do have some concerns about the naming of the function, which we can discuss later. We need to name it very clearly as a formatting function, which we can talk about, but it needs to be attached to the class. The third thing is whether this thing should be returned by resolvedOptions, because resolveFunction in Intl objects is used to return when we have some complicated resolution of the locale and localedata. In this particular case, where we’re passing a function and returning it, in either case the caller has all the information, and I don’t want the MessageFormat object itself to be able to remember those. But in order to always have in the resolvedOptions some way to expose that, I have concerns. I don’t want resolvedOptions to return that item, that implementations don’t need to carry for an object base. It should be a static function on the class, that’s my opinion.
USA: I just wanted to say on the first topic, well, not on the first topic, but on the topic of the built-ins and the extensible built-ins, I can understand that it’s an interesting use case, but I didn’t feel very compelled about it already because I couldn’t use it like that so far. But I somewhat agree, and I think that in terms of this being a stage 1 proposal my understanding is that FYT and EAO’s opinions are in the same direction, they’re close enough for a stage 1 proposal to be considered, we have a degree of direction for what we’re doing here. In the case of resolvedOptions, in the 262 side of things we love talking about invariants. And I think in this group we talk about the various invariants in 402, we see resolvedOptions is a way to recreate the constructor (?) – being able to get the resolvedOptions and put them back into the constructor and create exactly the same thing.. If this is going to violate that…
EAO: Apologies if my signal is bad. So I was going to say the same thing that USA effectively said, about resolvedOptions, in that there is an expectation that you can take what you get from resolvedOptions and plug that back into the input of a format and get something that behaves the same. There are two ways we can handle this. 1) we could return the exact value that the user provided for the functions, compare in exactly the same way as the built-in functions. The way we currently do it, it has the user provided stuff as well as the built in stuff, and if you feed that into another MessageFormat constructor it works. But something I wanted to say that the resolvedOptions that provide the options for cformatting it, and two methods – toString and toParts, and possibly selectKeys that are used when formatting this, as a placeholder in MessageFormat, or selecting one of the options based on it when it is used as a selector in MessageFormat. I don’t think we should have a static message on the MessageFormat class itself that gets the function, rather than having a static function directly on the MessageFormat class (?)
FYT: For the last part we just have a misunderstanding, I’m not opposed to what you’re saying.
USA: I have a curiosity, I believe FYT may be able to answer this, or other implementers. If the spec says that it should return the same function that is provided by the user, does it have to have any weight, it doesn’t have to be a clone of the function on the implementation side, but can just be a pointer to the same function? Or am I understanding incorrectly?
FYT: I’m not that deep into understanding the thing so far, but I can say a couple of things. First, in the past, I don’t think any of the Intl objects take a function in the options bag. We never ever return a function from resolvedOptions, and I think in our implementation those default functions internally are implemented in C++, and so for me to return a resolvedOptions as a function I have to be able go through all the hoops to wrap (?) into a function. So I’m wondering whether that thing should be passed into the constructor or not. That we could discuss. The other thing, I think I’m a little more questioning, my understanding is that we take an Intl.MessageFormat and we have some options and the options may have various (?). Is that customization per type, or per variable?
EAO: The current spec requires a Message to explicitly call a function in order for that to be customizable from the outside. There is in the spec currently built-in behavior for Numbers and Strings using the built-in number and string methods, same for DateObject and BigInts as well. There is no way right now to add in new handlers. You can’t add in a custom function and somehow through that definition make it so that if you pass in a variable of a specific type then it gets special handing in MessageFormat, unless the MessageFormat syntax itself explicitly calls what you’re providing as a custom function.
FYT: Well, let’s say I have two numbers, one called frank, one called tang. Both are numbers. Can you format the default one using the customized one?
EAO: In the MessageFormat syntax, if they don’t have annotations they get handled the same way.
FYT: But one with, one without?
EAO: In the message syntax, yes, this is possible.
FYT: So you could have differing customizations for different variables, right?
EAO: So long as the customizations are overloading the [three functions]
FYT: My question is that is customization binding to a type, or is it binding to a variable? Because the way it seems in the current spec is that you’re binding to the type.
EAO: the binding is to a name of a function, and then there are types that end up calling functions of a specific range.
USA: But to clarify, the default ones cannot be written over and customized.
FYT: My question is if your message has two or three variables for the same type, if you only provide one would that solve that issue? There are ten data types, but three different variables. Would each one of those be able to customize differently? : No – name indicated type of name-indicated variable?
EAO: We might not be talking about the same thing, and I’d be interested in continuing this, but it seems like it’s a different discussion than where we started.
FYT: Well the resolvedOptions returns functions, and [?]. Are the key and the value tied to the type, or to the variable. Suppose you return a resolvedOptions that you can pass into the constructor to reconstruct everything. But I wonder if what you already put in the options is already powerful enough for you to that same thing. Because if you’re binding to a particular variable, you might not be able to do that in the current spec. If your passed-in thing is bound to a data type, you might not be able to do this.
SFC: One concern I have here is that returning functions from resolvedOptions – well, everything we return from resolvedOptions is a primitive, basically. Let’s say you’re returning a non-primitive, a function can change that behaviour, and that’s something we should not be comfortable with. If we really must return functions, we have to isolate it so that you can’t change it and change its behavior. That’s one of the concerns we have with returning a non-primitive with resolvedOptions. I understand the desire to have the same behavior when you pass the options back into the constructor, so we’re not completely consistent on this front. I think that – I can see the argument for why we should put the function there, but I also see the argument that this is an awkward way to access it. There’s a second question, we could add an additional function, either in the way that FYT proposed or how EAO proposed, having a static function. Another question is do we also return them on the resolvedOptions? I need to think about this for a little more before I can be confident in my recommendation one way or another.
USA: I’ll be super fast. FYT, relating to the playground that we set up fairly recently, it might be useful but it doesn’t support functions yet. But for now at least you can see how it’s doing with these and use the built-in number and date-time functions that could be illustrative of how these things are being used.
EAO: For me the important thing is finding an ergonomic way to make the function available, so that we can have a richer and more localized format experience for everyone. One thing we could consider – given all the other stuff we’ve done – we could simply remove resolvedOptions altogether. We only have two remaining. If functions are a problem, and we have access to the function otherwise, I’d be comfortable with removing resolvedOptions altogether.
SFC: That’s an interesting thought. There are good things to consider there.
tc39/proposal-intl-locale-info#82
FYT: The history of this is that Intl.LocaleInfo, we’re getting the first day of the week from an option, but also from -fw. We wanted it to be a string, but then a number, and we discovered that it’s possible for people to construct a locale with a random string. For the locale purpose we could construct and return a string. The problem is that after that there’s a bug in the thing that we store the value of the first day of the week in, and internally we have to access it to be able to use that information to impact the value in the getWeekInfo. And that part, I think the last time we had the PR, we missed that, and somehow it’s reading a string but should return a number, but the spec didn’t do the conversion part. So that’s the first issue, issue 82, we do need to do the conversion. Beside that, in PR 83 it includes that, but in the meantime it also necessarily there’s a different request made by anba earlier on, which is what’s the effect of having a calendar option that’s not ISO, the first day of the week should be Monday, except -fw should have priority. I’ve added that to this PR, but then other people pointed out during the review that we should have the, whenever we get the value we should only look at the language part to get information, because we currently do not handle u-rg regional override. Therefore, we should look only at the locale identifier part, so it will not respect -rg, and we can add it later because currently we don’t support it. Those are three changes related to how the weekInfo of Locale should return. One is [?], and 3rd is to make it tighter and not respect -rg until later we can add it. So we should get agreement on that so that we can take it to TC39. Any questions.
SFC: My recollection is that the date fields return an integer, and that firstDayOfWeek returns a string. So… what’s the problem? It’s a spec bug, is it hard to fix the spec bug?
FYT: It’s not, this is the PR to fix the spec bug. It combines three things: it has the spec bug fix, and also anba has mentioned the desire to make the impact of the calendar more explicitly. Initially I think, well, we look at a locale, 8601 has that information. And then he also wanted to make sure that -rg is explicitly not to be impacting this.
SFC: I’m looking at the PR and I’m a little confused why we do the thing with ISO 8601. So this is fixing an additional issue, not just the string/integer thing.
FYT: Yes, initially the spec says “I have a locale, I’ll just return a value. If it has ISO 8601, it’ll just return 1.” Anba wanted to make that explicit.
SFC: At what point does it say that it’s an ILD behavior? The line you’re removing doesn’t say anything about it being implementation and locale dependent.
FYT: Here, it’s in A. So we did have it as locale-dependent behavior.
SFC: This is a question for the editors, but: usually when we have this we explicitly say the word “ILD”. Now I understand what it’s doing.
RGN: One of the things I’d like to do is make it a definition so that the link is explicit. Implementation and locale defined, meaning this is not something where we specify deterministic behavior.
FYT: Where?
RGN: It’s literally the phrase “implementation and locale defined”
FYT: This is the first time I’ve noticed it. What should I do? Something I do in the spec, or something done later on?
SFC: It’s an editorial thing.
FYT: Originally what I have in mind is that I don’t need to make things explicit here, but Anba said that we need to make it explicit, so that’s why we’re adding these several lines, to make it explicit.
LAF: Let me be sure I understand. In ISO 8601 calendar, there is no choice, normally. The first day of week is monday, and the first week is the one with Thursday, something like that. It is defined by ISO, but together with you in several regions the week may begin on another day, and the first week of the year may be different. This is where you want to apply this. So is it linked to a calendar, or? I’m not sure I understand this perfectly.
FYT: UTS 35 already fixed this, so there is a priority. If nothing got specified in the locale, then the language, region, and script determines what is the first day of week, and what is the minimal day. If somehow there’s a calendar specified, and the calendar is explicitly saying it’s ISO 8601, we set it to Sunday regardless of the region code, and the minimum days for the first week need to be four days. And if the locale also has an -fw parameter, then it overrides that. So let’s say I say the first day of week is Wednesday, and it will always be Wednesday regardless of whether it’s UTS 35 (ISO 8601?) Then if there’s somehow a region override, -rg, then we have a priority somewhere, I forget the order, but we currently don’t have support for -rg. So that’s what this is. change is about. If a locale explicitly has -ca, and -fw, and iso8601, what do we do? Anba wanted to make this very explicitly.
SFC: I think that if we, I think what’s written is correct. I just opened the issue about using ILD more consistently. I think it works for what LAF said, and it’s not a normative change.
FYT: It’s arguable whether it’s a normative change, because anba could say “hey, originally it may not be that way.” Whenever you change something from implicitly defined it becomes normative.
SFC: Right now it says with values based on locale, we change that to “implemented in locale-defined values”
FYT: Arguably this is normative, because we have an explicit statement of ISO8601.
SFC: Technically this doesn’t allow locales to vary what they return, which is odd. I think we should decouple these. Actually – why did you change it to be based on language_id instead of locale?
FYT: That’s Anba’s patch – if I do that, then it will listen to -rg.
SFC: We want it to listen to -rg, but also -ca?
FYT: We don’t want it to listen to -rg until -rg is supported. It does listen to -ca
SFC: It doesn’t, though. If you have en-u-ca-hebrew, that doesn’t change that. I think LAF’s argument is that the calendar system can definitely have an effect on first day of week.
FYT: Does it? Which one?
LAF: Oh yes, ISO 8601 does, and Hebrew does. In Hebrew the first day of the week is Sunday. The way you express, Hebrew you express the first day as Sunday.
SFC: Even if you’re in a region, say France, and you have a gregorian calendar hanging on your wall it starts Monday, but if you have a Hebrew one it starts on Sunday.
LAF: And there can be some changes in the culture. Essentially the week may be defined with the calendar, in fact the week is not defined with the Gregorian calendar – but with ISO 8601 it is!
FYT: I currently do not believe – well, here’s another complication – I don’t think ICU’s implementation will change if you have ‘fr-u-ca-hebrew’.
SFC: It could be the case that ICU is buggy, but that doesn’t mean we should forbid it in the spec.
FYT: So we need to probably put this on hold if that is the case.
SFC: I think, FYT, you can, I think you should put on the TG1 agenda the version of the PR that doesn’t do the additional Anba change.
FYT: Let me do this: I will not change these several lines, I will only change the conversion lines.
SFC: And you can do the ISO 8601 check. There’s three changes in these seven lines of code: the fix about returning an integer, that’s good, there’s the fix about hard-coding ISO 8601, and then there’s the fix that we can only rely on language_id when determining the first day of week. But you can keep the ISO 8601 section.
FYT: I got it! Okay! So I’ll revert that last part.
BAN to add #780
BAN has added #908
BAN to update #839 to be a note
BAN to double-check if tc39/proposal-intl-duration-format#207 needs to be added
BAN has verified: tc39/proposal-intl-duration-format#198 was approved in June
FYT to add tc39/proposal-intl-locale-info#83 after it is updated
tc39/proposal-intl-eradisplay#9
(after meeting deep dive)