Attendees:
- Shane Carr - Google i18n (SFC), Moderator
- Myles C. Maxfield - Apple (MCM)
- Daniel Ehrenberg - Igalia (DE)
- Ujjwal Sharma - Igalia (USA)
- Philip Chimento - Igalia (PFC)
- Leo Balter - Bocoup (LEO)
- Jeff Walden - Spidermonkey (JSW)
- Younies Mahmoud - Google i18n (YMD)
- Zibi Braniecki - Mozilla (ZB)
- Richard Gibson - OpenJSF and Oracle (RGN)
- Frank Yung-Fong Tang - Google i18n, V8 (FYT)
Standing items:
- Discussion Board
- Status Wiki -- please update!
- Abbreviations
- MDN Tracking
May 21, 10am PDT (5pm GMT)
SFC: Romulo couldn't make it today. We have made the relevant decisions. We now have a new chair group, and this group will work on proposals internally and then share them to the larger committee. It’s analogous to the champions group and plenary model. This will go into Unicode, so it’s going to be a while before this has substantial effects on 402. Don’t expect anything immediately, but Q3-Q4 is a more realistic timeline.
SFC: PFC has been working a lot on Temporal lately, there were few issues that need to be discussed with this group. Would you like to pitch temporal to the group?
PFC: pitches temporal
SFC: I’ll filter out the calendar specific issues and find one that should interest this body of individuals. How Temporal interacts with Intl is an important discussion to be had.
SFC: opens tc39/proposal-polyfill#262 and explains it
SFC: which calendar should take precedence, is the question?
DE: we had much the same dilemma with TimeZones when we had a compound ZonedDateTime type (of course such a dilemma no longer exists).
PFC: I would like to go with the principle of least surprise here, siding with the Intl.DateTimeFormat calendar.
SFC: In the issue tracker, PDL suggested that we side with Intl.DateTimeFormat here.
USA: If we prefer using the Intl calendar, then you get the same calendar as if you call toLocaleString on a legacy Date.
DE: So, what do we do with MonthDay and YearMonth?
SFC: Two days ago, I posted an example of MonthDay that demonstrates this. demonstrates MonthDay issue
DE: didn’t we get rid of that particular API?
PFC: that might have been before I got involved, but it wasn’t removed recently.
DE: that’s a separate issue, then.
SFC: it doesn’t matter. The question is, do we pass in the Calendar explicitly? Another option is to avoid toLocaleString on MonthDay at all, but it would be a shame to disallow that because of an arcane issue.
US: What about RefISOYear?
SFC: that’s a Temporal-internal thing, I don’t think it should be exposed or used externally.
DE: what about just using the Temporal calendar always?
SFC: I’d be happy with that, as long as the default calendar on Temporal is set to the regional preferences instead of ISO.
SFC: Maybe we should move on to NumberFormat v3.
SFC: opens up and talks about first issue
SFC: so the question is, what settings do include or should we just stick to defaults? The hope is that “auto” will be reflected in CLDR data, for now it’s just a heuristic. I’ve been hacking away at this on the ICU side of things.
SFC: another option is to selectively expose these options when people ask for them.
DE: has anyone asked for them yet?
SFC: we’ve discussed these options with UX teams, but these are very subjective decisions, so I have no data regarding this (I could get some).
ZB: Do you have any gut feeling which we could build off of? We could start from a small API surface and build from there.
SFC: my gut feeling is that collapse: auto would cover <>% of the cases.
ZB: In that case, let's start with small. And we could add more options later.
SFC: I’d like to go with that default as well.
FYT: I agree with that as well.
ZB: this seems to be a good strategy to me, moving forwards. Let’s increase the API surface gradually.
ZB and SFC: discuss the specific options of the API.
ZB: single value seems like something that could be done in a client library.
SFC: they could check that before rounding gets applied. The exact magnitude of rounding isn’t known unless you’re deep inside Intl
ZB: I was brainstorming if it was possible to simply this set by cutting down on some of these options for the time-beings. But this seems to be potentially leaning towards making the default “range”.
SFC: I don’t think the default should be range because it’s rather weird.
ZB: I’m not weirded out by that. I understand it looks odd, but I’d say it’s weird to pass two equal values to a range. What if we throw?
MCM:
FYT: we also have DateFormat range right now, how will this interact with that. If there is a "~5 miles" why not "approximately May 2019". What will be the effects on Date formatRange?
SFC: I’d say single value would be the best default here, since I’m uneasy about the quality of locale data backing the approximately option. I made some suggestions to CLDR regarding that, and we can add it once CLDR catches up.
FYT: we should default to single value. Date range is also using single value currently, so that would be more coherent.
JSW: it’s different about dates. Something is on or not on a date. It’s not the same with numbers.
FYT: there’s still rounding involved. It’s just that it is clearer.
SFC: what jeff said was one of the reasons that I had advocated for approximately in ICU. That said, if users will want this feature, they would opt-in to it later, but single value is a good default.
JSW: did they choose approximately because it exposes more information?
SFC: that and also in order to put it in front of as many users as possible. Single value is a reasonable default. FYT: approximately isn’t a format option, it’s a different kind of format. This is a sort of a different feature presented in a different format. We could deal with it separately but not now.
SFC: we could expose it separately, true. We can think of approximately as a new feature that could be exposed API-wide instead of isolating it here.
FYT: I agree. We should either deal with it separately or not deal with it at all. But it shouldn’t be stashed away here, it should be a higher level construct.
SFC: default “auto on collapse” and exposing these options gradually when needed.
FYT: it is very ambiguous.
SFC: that is by design, it is locale-dependent.
FYT: is it only dependent on locales?
SFC: no, it is not locale-deterministic. For example, if you have a $, then you should repeat it, but don’t repeat CHF because it’s too long (this is based on feedback from UX designers).
FYT: that would be hard to spec.
SFC: you don’t need to spec that. You should wave your hand and say it’s ILD.
ZB: I am concerned about that, because that makes ICU the standard. So that means that someone who wants to implement without ICU will have to copy ICU, line by line, including bugs. I won’t block, but we should seek to minimize that.
ZB: we have a few places in ICU where we have very complicated behavior and we haven’t specified it.
FYT: we should look at two camps: spec and no spec.
DE: we have discussed this in detail in the past.
FYT: we could defer to CLDR and still have tailoring inside the spec.
DE: what we’re doing is working parallel to CLDR. I don’t see why that approach wouldn’t work. We have decided not to normatively reference CLDR because we want to permit engines to use their own data tailorings.
SFC: this behavior isn’t speced in CLDR.
FYT: I just want to see which condition we’re in. This seems to be completely unspecced.
DE: In the case of ListFormat, we devised a schema in the schema.
FYT: then we can spec it out.
DE: but we still speced it in a manner that was implementation dependent.
FYT: I agree with Zibi that we need to avoid unspeced behavior.
DE: I concur with Shane here.
ZB: do you not see the concern?
DE: I see the concern overall, that expanding Intl is risky, but not how it is especially relevant in this case. We have a strategy for dealing with this, and we can deal with this in a similar way, to the extent that this makes sense.
ZB: correct me if I’m wrong, but this is more so of that as opposed to when we dealt with this previously. …
SFC: the algorithm isn’t that complex, but it’s simple, we can spec that. describes the algorithm Data should be in CLDR, but it hasn’t been specified yet, so we use a simple algorithm for now.
ZB: I thought it would be much more complicated.
DE: NumberFormat gives a lot of leeway in terms of what patterns can be provided, and I’m not convinced that we should take a different approach than what we’ve seen in the past.
ZB: I was more scared that the algorithm would be very sophisticated.
SFC: it is simple because it should ideally be specced, but it hasn’t been.
FYT: In this case, we could fix it in CLDR before fixing it in the specification.
DE: the data model of the specification doesn’t always match that of CLDR. We have freedom to specify a schema where things may otherwise be in ICU logic. For example, in Intl.ListFormat, we have a schema for data in the spec, although CLDR doesn't have it yet.
FYT: as long as we spec it, someone else can implement it.
DE: in the future, we can have a pattern in CLDR; this doesn't have to block.
SFC: let me propose a recipe: the algorithm would be specified, but toggle switch would keep the decision ILD. It is perfectly reasonable to be diverse. All these are valid outputs according to the spec. It’s just that ICU dependents would do X, but Y would be not incorrect. This problem goes away if browsers use CLDR as the data source.
ZB: I’m satisfied with this.
SFC: let’s move ahead with grouping indicators.
SFC: ICU has several different grouping strategies. Right now we just have true and false, and auto is really buggy. For Mexican Spanish, you just default to min2. It’s called min2 because the locale dependent grouping separator occurs only when there are at least 2 digits in the group it's separating.
Waldemaar asked the same question as DE, and the answer is that it only affects numbers from 1 to 9999. In terms of the Western bias, it’s unclear that it’s a good option as opposed to the alternative. USA had a comment here as well, in en_IN the correct thing is to do a grouping of 3 and 2 digits, where 3 and 3 is not okay. I'll give a little background on why this is here in ICU. There were a couple examples of people who were doing the override manually but it wasn't clear if that was correct for them to do. It wasn't clear that it was a best practice, but in 402 we are more in favour of best practices, so I don't think it needs to be included in 402 even if it's in ICU.
FYT: which one did you propose that we shouldn’t include?
SFC: thousands. It is so bad that I didn’t even want to propose that.
FYT: I see, that’s bad, I agree.
SFC: what do people think about what I proposed here? describes proposal on the issue. True could map to 'always' or 'auto', but there have been bug reports coming in from people who find the behaviour of true mapping to 'auto' surprising.
FYT: I’m lost about true and false here.
SFC: I am propose that we use the useGrouping option and that we expand that to take strings as well
FYT: and the default should be auto. True should map to always and False should map to never. What is the default right now.
SFC: currently the default is true, and V8 defaults to auto because ICU makes it the default as well. I propose we specify this a bit better on the 402 side of things, and this could be a normative change. It's an observable change, so maybe we should be concerned about it.
FYT: I am concerned about it. If the user doesn't want 'auto', then they can specify 'always'.
SFC: OK, we can move true to mean 'auto', and the default is still true.
FYT: talking of resolved options, once we implement this proposal, it will never output true or false, it will just return this string.
SFC: If we don't want to make any observable changes to existing code, then it could still return true or false. But that's weird if you specify 'never'.
FYT: I’m not contesting the normative change, I’m just trying to understand it a little better. We should discuss this and understand the consequences before it. We don't want to break existing code. Maybe it wouldn't be breaking that badly, though.
SFC: We can open up a separate issue for that.
SFC: does anyone have a problem with auto implying behavior that doesn’t otherwise exist (like min3 for Hungarian)
FYT: The intervals at which we display the grouping separators?
SFC: No, those are locale-dependent. This is about whether we display them or not.
FYT: I see.
SFC: If nobody has an issue with auto exhibiting behavior which is otherwise unavailable, that would be doable.
ZB: I know it goes a bit against what ICU is doing, but is there a reason to have 'never', 'min', and 'auto', where 'min' is not 'min2' but the number is locale-dependent?
SFC: I could open this question to CLDR, they might be able to agree to that.
FYT: I’m not quite sure about this. If we only ever support auto never and always, what would we lack?
SFC: There are UX people who opt into min2 even when it’s not a locale default.
FYT: I see.
SFC: it’s like when you’re displaying prices for plane tickets, some UX people prefer not to have a separator when showing a price in 4 digits if the environment is space-constrained.
SFC: I like ZB’s idea, I’ll go back to CLDR with that.
ZB: I don’t think it has to be blocking. We should consider min in 402 and kick off discussion in CLDR simultaneously. I don’t think ICU or CLDR need to block us here.
tc39/proposal-intl-numberformat-v3#1
SFC: (Presenting the issue) I think it might more sense to put the scale into the options bag.
ZB: I prefer version 1 independently of the topic, because I prefer the options bag to always be the last parameter.
FYT: why do we need a scale option inside? We can’t we scale on the user side of things?
SFC: we want to be able to handle bigint micros and it’s awkward to handle that. I tried to pitch for this, but we can still decide to ax this feature.
ZB: The way I understood the pitch for this feature, is that for very small numbers, it becomes tricky to do calculations without losing precision. What scale does, is say "here's the scale I want to adjust the formatted number for", and make sure that it doesn't end up as 3.1999999 or something.
SFC: That's accurate. It's especially relevant if you have a bigint input and you want to do math on it, but you'd lose precision if you converted it to a double.
DE: I've been doing a user survey for the BigDecimal proposal, and people doing currency calculations want to use bigint cents, but then for toLocaleString they need to convert it to a double, and lose precision. I can give more details if people are interested.
FYT: I see.
JSW: As for decimal, would people ever not use decimal for money? (as opposed to using this option)
DE: I think using decimal would take longer. This scale in Intl.NumberFormat can be polyfilled, but BigDecimal can't be polyfilled. Legacy code would also continue to use Number.
JSW: So they're concerned significantly about transition time? Fair enough.
SFC: so a sidenote about that. If we take notation for example, it’s not implemented in Safari yet, which is still correct. In this case, it would be less nice if any environments lag behind.
DE: One thing you could do is construct an Intl.NumberFormat, check that resolvedOptions includes the scale, and throw up your hands and scream if it doesn't.
JSW: We could also have an entirely separate format function. I don't think this is necessarily a good idea, but we could.
DE: I don’t know if we want people to use toLocaleString with two different APIs. (?)
SFC: Sure, I agree that it is a minor factor but it’s not a decisive one.
JSW: Are we absolutely sure that scale should be interpreted as a power of 10?
SFC: I'd strongly advocate for that, otherwise we're turning into math.
DE: I agree with Shane. The case here is to be made specifically for decimals.
FYT: What JSW pointed out is interesting, but I do think we should stick to powers of 10. Maybe the name of 'scale' should be changed, though.
SFC: Let's make a separate issue for the name.
DE: what about JSW's idea after all of a different method for formatting a number and providing a scale? Because you format this in parts and it would be more testable.
FYT: I agree with DE and JSW. It will help more than it hurts.
SFC: I have a problem with adding more methods. We have a combinatorial problem, because we already have format and formatRange and this would just start getting unreasonable, with formatScaleToParts, etc.
DE: I see.
SFC: For the problem with different browsers giving different results, version 2 would be better because the object as parameter 1 just wouldn't be accepted. I don't want bug reports like, "In Safari the car costs 1000 dollars but in Chrome only 100 dollars!"
DE: I can imagine adding a second parameter to format as a per-call options bag. But this isn’t a pattern we use in ECMAScript.
SFC: I'm actually fairly concerned about the bug reports that I just mentioned. another option here i
FYT: I'm nervous about putting it in the constructor or option 1.
DE: if we put it in the constructor, but we focus on educating developers to use resolvedOptions, would that work? There are efforts to improve Intl educational materials but they're still a bit thin.
SFC: we could agree that it’s an educational problem, but it won’t be solved 100%.
ZB: There’s also websites deployed who ignore this. My concern is deteriorated trust in ECMA-402, the feeling among web developers that you have to do it yourself if you want it to be accurate.
DE: we might have that deteriorated trust when people have mismatched data. Have you heard about any deteriorated trust?
ZB: I’ve seen it in bits and pieces in misguided situations. For example, if you want to get a pixel-perfect format, they would try to implement it themselves. Not understanding that they're not doing internationalization anymore in that case because their UX design was thinking in en_US.
SFC: I've changed my mind about this. We can still move the proposal forward without this, and put it on pause. We can revisit it in the future.
DE: That makes me really disappointed. I see how there are real issues, but I hope we can come up with a good solution within a few months.
SFC: (Presenting 4 options in issue)... Any opinions on this?
DE: seems like there are several decent options, it seems to be the opposite of the last issue.
FYT: Is it true that it's not an option to do nothing?
SFC: the way to impl the correct behavior is to educate about resolvedOptions.
FYT: So the status quo is doing nothing. The problem is that the correct way is a bit difficult to figure out.
SFC: right, that’s the problem.
FYT: and all the other 4 proposals are making this easier. But are they adding any extra features than what we currently have?
SFC: None of them add anything that doesn't exist, it just takes the feature we have already and make it easier to use. I’ve observed this issue, this isn’t a theoretical fix.
FYT: It's difficult to find the way to do the right thing, I see.
ZB: not discarding what you’re proposing here, but does it make sense to file an issue in MDN as well, to make sure this is documented in NumberFormat and PluralRules?
DE: A good place to file that issue is in our ECMA-402 MDN repository.
SFC: since it doesn’t increase our API surface, we can try to fix this through education right now, and decide later if we still need it or not.
FYT: No matter which option we pick, developers still need to read the documentation to figure out how to use it. Therefore there's not much reason to add additional API.
SFC: do we agree with that conclusion? It makes the proposal a tad bit smaller.
MCM: It's a bit scary to say we'll solve it in documentation. We can't control what some tutorial online tells developers to do.
DE: Some members of this group have been active in writing MDN documentation.
FYT: my point is that we’re not adding a feature here, we’re just adding an API to force someone to write about it.
SFC: Even if we add more APIs, it's still an education problem.
FYT: this isn’t a unique issue, it will increase the API surface and still not address the actual issue.
SFC: Myles, any updates on JSC?
MCM: Not really.
DE: There's been upstream JSC work by Ross Kirsling.
FYT: Should we invite him to this meeting?
SFC: I'll make sure he's on the delegates list.
Any updates on stage 3 proposals, Intl.ListFormat / Intl.DateTimeStyle?
ZB: No updates, I'm planning to look at it next week.
FYT: For ListFormat there's a blocking issue in Spanish.
DE: is this issue currently blocking? I thought it was solved on the spec and ICU level...
SFC: I think we still need to review the pull request at the spec level.
DE: can people review that PR offline so that I could merge it?
SFC: ZB will look into it soon.
DE: I will land it in a few weeks once I get feedback.
SFC: Any updates on DisplayName?
FYT: ???
SFC: Can Richard talk about ???
(RGN had left)
SFC: I don't think there are any other blocking issues here.