Skip to content

Latest commit

 

History

History
243 lines (228 loc) · 23.6 KB

notes-2018-07-19.md

File metadata and controls

243 lines (228 loc) · 23.6 KB
Raw

July 19th, 2018, 16:00 UTC

Attendees

Eemeli Aro

Daniel Ehrenberg

Steven R. Loomis

Jack Horton

Jeff Genovy

Zeke Sikelianos

Felipe Balbontin

Shane Carr

Agenda and minutes

https://github.com/tc39/ecma402/blob/HEAD/meetings/agenda-2018-07-19.md

  1. PRs against ECMA-402
    1. Normative: Improve handling of non-Gregorian calendars
      1. Implementations?
        1. JH: I looked into the implementation in Chakra, and it turns out a needed ICU API is internal-only, so it will be hard to get into the next release of Windows. The number is likely to be stable, but we'd like to make a public API before landing.
        2. SL: Is this still internal as of tech preview?
        3. JH: Not sure, it's either draft or tech preview or internal.
        4. SL: One thing you can do is, if you know it's stable by version x of ICU, you can guard it by a version guard, and for a future version use another one. That way, your code can guard against the version changing.
        5. JH: ChakraCore doesn't necessarily know the ICU version it's using, since it's using the system ICU. And versions of ICU can change out during Windows development. The enum value is right in the middle; I'm pretty sure it won't change regardless.
        6. DE: Let's mark this as stable and, in parallel, make a draft implementation in ChakraCore.
        7. JH: That's feasible, but it won't land for a while. We're also stabilizing.
        8. DE: That's fine; I think a PR out for review will give us good evidence about this patch.
        9. SL: ICU moved to GitHub, so you can make a PR to make this public.
        10. JG: link: https://github.com/unicode-org/icu
        11. JG: Jack if you can point me to the ICU enum, I can try to help get it public (file tickets/PR/etc.) if you are busy.
      2. Tests?
        1. JH: I think this will depend on the locale tag
        2. DE: That's in
        3. JG: If you're busy, I can file this PR to propose getting it public.
    2. Normative: Permit "unknown" DateTimeFormat/NumberFormat fields
      1. Implementations?
        1. JH: I've added this in ChakraCore
        2. DE: OK, I'll land the patch (after proposing at TC39)
      2. (Impossible to write a test)
    3. Normative: Treat -0 as negative in NumberFormat
      1. Tests have landed
      2. Implementations?
        1. JH: Chakra has this
        2. DE: OK, sounds great, I'll land it then.
    4. Other issues to discuss in ECMA-402?
      1. Spec should be consistent about calling intrinsics
        1. DE: What would be the more clear alternative: Wording or calling the JS function?
        2. (someone): Doesn't this run into overriding issues?
        3. DE: No, since it always refers to the original
        4. JH: For our implementation, we'll be implementing it with the JS functions, so it maps more nicely to ours, but I'd prefer for it to be consistent; if I have to choose one, intrinsics map more closely.
        5. MM: Is the difference observable?
        6. DE: No, this is editorial
        7. OK, no strong opinions, so we'll keep this low priority on the backlog
  2. Stage 3 APIs
    1. Intl.Locale
      1. PRs out for review
        1. Normative: Cite UTS #35 for canonicalizing Unicode extension tags
          1. JH: Do these things ever default to true rather than false? I thought some locale somewhere would default to true. But, if the other spec is written this way, it's not an issue.
          2. SL: My recollection was that there were not valueless extensions in use. Anyway, the things which are in locales live in CLDR, not BCP47
          3. JG: Their usage in locale names is a bit esoteric
          4. DE: OK, I'll land the patch and we'll just reference the other specification.
          5. SL: We should have the right separation of duties; this is not trying to redefine BCP47. The RFC probably needs an update
        2. Normative: Define error recovery behavior for likely subtags
          1. SL: I think that's reasonable given the way error recover is supposed to work. Logically, the lookup algorithm is an error, but the JS algorithm can be different.
          2. DE: OK, I'll land the PR.
        3. Normative: Improve handling of grandfathered/private use tags
          1. DE: OK, sounds like no concerns, so I will land this.
      2. How are implementations coming?
        1. FB: In V8, the implementation is advanced, IIRC it's missing some of the latest additions like minimize, maximize, but I think it's going well.
        2. JW: I'll probably start reviewing the Intl.Locale implementation in SpiderMonkey today; it's been out for review.
        3. JH: Not started in ChakraCore, working on stabilization (ditto RelativeTimeFormat)
      3. Any issues with testing? (Should be pretty complete)
      4. Other Intl.Locale issues?
    2. Intl.RelativeTimeFormat
      1. PRs out for review
        1. Normative: Remove mistaken NumberFormat options
          1. DE: OK, I'll land it
      2. How are implementations coming?
        1. JW: Implemented several months ago in SpiderMonkey, pretty much in shape (w/exception of formatToParts).
        2. FB: Initial implementation is pretty much in shape. Missing formatToParts, depending on ICU, but almost there.
      3. Any issues with testing? (Test262 covers surface area; substantial tests on the way)
      4. Other Intl.RelativeTimeFormat issues?
    3. Intl.ListFormat
    4. Intl.Segmenter
      1. DE: There's a W3C Internationalization group; seeing a review of this feature.
      2. SL: The W3C has a line breaking proposal up; it's on my todo list to review (TODO: Find link)
  3. Newer proposals
    1. Intl.NumberFormat Unified Feature Proposal
      1. Rounding behaviors: #239; sffc/proposal-unified-intl-numberformat#9
        1. SC: Should rounding be minimal or expressive?
        2. SL: We should support currency rounding well.
        3. DE: What would be the practical impact?
        4. SC: In tc39/proposal-unified-intl-numberformat#9 (comment) , some users at Google have asked for one of the unsupported lower rows in the table. Regarding currencies, the spec doesn't currently support "increments" (nickel rounding). However, in ICU there are very few currencies that use nickel rounding for digital display (though it may be used for cash display). Not sure if that's a high priority issue.
        5. SL: Cash rounding is important, e.g., for a cash register.
        6. SC: I agree that cash rounding is good to have, but ECMA-402 doesn't have this and disabled nickel rounding. If we wanted to support cash rounding, we'd need to add it on. If I go down the road of adding more things, increments is something which would likely go into it. I don't see a reason to add increments but not other features.
        7. MM: I'm interested in the cash issue. Are there cash registers that run JS?
        8. SL: This is about prices that consumers would actually use. I think in Switzerland, it rounds to SFC 0.05. This is the normal price you'd see--bank statement value vs price tag.
        9. EL: I have seen a cash register in use running JS.
        10. SL: This is about consumer market-level prices.
        11. SC: This is coming a bit late in the design process. The semtiment seems to be, yeah, we should have more support for rounding modes. I'm thinking to move forward with the current proposal as it is, and either add it into the proposal later, or add it into a follow-on proposal.
        12. DE: Sounds like a good plan.
      2. New fields: sffc/proposal-unified-intl-numberformat#10
        1. Options: Space is a literal, or space gets lumped in with the type unit.
        2. JH: I prefer it to be part of the literal.
        3. EA: It would be surprising to be part of the meter.
        4. SC: OK, sounds like I should continue with the ICU change to make the distinction
        5. SC: What should the field name be for scientific notation, e.g., for the - in the exponent?
        6. SL: I think it'd be the clearest to have a separate field for - in a mantissa
        7. JH: Agreed
        8. JW: Agreed, definitely wrong to use the same thing.
        9. SC: OK, this seems clear and reasonable.
        10. SC: Compact notation: type: "compact" for the symbol? If there is a space involved, it will probably follow the precedent for units/currencies. This will be driven by a change in ICU.
        11. SL: compactSymbol might be better
        12. SC: Then should we call some things compactName?
        13. SL: What do we do for currency? Do we treat $ and "dollar" differently, or are they just currencies? Conceptually it's just a different symbol, just one happens to be longer.
        14. EA: You know whether it's narrow from the constructor object
        15. SC: OK, so we like the name "compact".
      3. Measurement unit fallback behavior: sffc/proposal-unified-intl-numberformat#11
        1. SC: My preference is 3.
        2. SL: What is ICU's behavior here?
        3. SC: ICU links against the units--their behavior is, throw a compiler error.
        4. SL: Can't you specify a type by name? Or not relevant?
        5. SC: There's no equivalent API.
        6. SL: Falling back to the unit name, and having resolvedOptions tell whether the unit is there.
        7. EA: I disagree. Falling back to the name of the unit would be surprising, maybe not noticeable, and not provide feedback to the developer. I'd suggest that there be some sort of safe unit list, with additional ones possible but which throw errors when not supported. This will be an error even if you don't see it.
        8. SL: We could do a list of supported units, just like we have a list of numbering systems. Would this be a reasonable compromise.
        9. EA: I like that.
        10. JW: I'm inclined to list everything in the spec. Throwing exceptions for unknown units is reasonable. If I don't recognize a particular unit, fallback to another unit of the same sort? Maybe not. Just throwing is not bad if you don't recognize the unit.
        11. DE: OK, sounds like we want option 2, but with a minimum list of supported units.
        12. SL: CLDR doesn't change in this aspect very much, so we can make good guarantees about a relatively stable list, and outside either throw an exception or return a fallback
        13. DE: We heard a bunch of support for an exception overa fallback.
        14. SC: Sounds like SL and I like a fallback string, and EA and JW like an exception. There's definitely an argument for an exception.
        15. SL: My concern about the exception is that the confirguration is likely to come from user data. An exception might be difficult for the application to handle.
        16. EA: If it would be a fallback, how would you detect that?
        17. SL: resolvedOptions
        18. EA: How do you fall back, do you have something for each type?
        19. SL: Fall back to the input value. Actually there's a transition in ICU for words like length.
        20. SC: I feel like anything that involves conversions is out of the scope of what this is aiming to do. There's intereting dessign space here. ICU and Ecma don't go there.
        21. DE: Let's revisit this at a future meeting.
        22. SL: Yeah, and we are all agreed that we want a minimum fixed list in the spec.
      4. Name of signDisplay and currencySignDisplay: sffc/proposal-unified-intl-numberformat#6
        1. JW: No option seems obviously wrong or obviously clearly right.
        2. SC: OK, let's continue discussion in this thread.
      5. Editorial comment from Daniel: is it a bad idea to use different terminology in the spec than in the API, as long as the spec's terminology does not leak out? For example, my spec uses "measure unit" internally to refer to what we decided to call just "unit" externally, and I use a key called "unit type" to refer to what we externally call "style".
        1. SL: Just calling it a unit will be more clear to users of the spec, as "measure unit" is just an ICU term, not a CLDR term. You can draw the parallels with ICU in footnotes, if this a helpful pointer, or even something outside of the spec. Style/Unit are two slightly overlapping things, which could maybe be made one space.
        2. SC: The way I had written this was to make a way for the API to communicate with the underlying implementation, so the spec is translating to a sort of virtual ICU. The other idea is to do the conversion by ICU. The conversion has to happen somewhere. If we bubble the name measure all the way through…the conversion from style to unit has to come from somewhere.
        3. SL: Could we merge unit and style?
        4. DE: Yes, this would just be choosing Style, as the only difference is that Unit merges percent and unit.
        5. SL: Could be worth doing for clarity.
        6. SC: I think we should optimize for clarity, as opposed for the implementation logic, so it sounds like style all the way through is more clear, so I'll change the spec.
        7. SL: Maybe there's a footnote that explains, these values turn into these values in implementations.
      6. Slides for TC39 (still in progress, but feel free to leave comments)
      7. Other helpful links: main repository; spec changes
    2. formatRange/formatRangeToParts (Felipe)
      1. slides
      2. Fell off the agenda at the May 2018 TC39 meeting
      3. Plan: Stage 2 at July 2018 TC39 meeting (presented by Felipe Balbontín)
      4. Issues:
        1. Default behavior when date parameter is undefined
          1. SC: We could choose whether you're providing beginning or end depending on whether the single parameter is past or future.
          2. FB: Interestingly, there's no general constraint that ranges go from earlier to later.
          3. SC: I'd say, definitely throw an exception if you have undefined as your first argument, and a date as your second argument. The more important case is calling the function with one argument.
          4. EA: What is the behavior when one date is invalid?
          5. FP: I think we throw a RangeError there.
          6. JW: I think we should just require two dates to be passed, and if they aren't, it's an error.
          7. FB: Continue discussion on GitHub?
          8. SC: This can be like substring, where you can call it with 1 or 2 arguments.
          9. EA: Equally valid would be "beginning of time" and "end of time"
          10. DE: I think we should follow JW's suggestion and just require both arguments explicitly.
          11. EA: I agree
          12. SL: Time moves as the computation happens, making implicit Date.now problematic.
          13. SC: Good point
          14. SL: ICU has convenience functions that default to now, and it can lead ot unexpected results. Not recommended.
          15. FB: OK, sounds like we prefer alternative 2.
        2. Throw a RangeError when startDate is greater than endDate
          1. FB: CLDR and ICU don't care. Should we restrict things, or just format whatever the user provides?
          2. SL: This sounds like a bug--there is expectation about directionality. I think this should be a range error, unless someone has a compelling use case.
          3. FB: Should we limit this? It's the responsibility of the API user to provide the dates the right way.
          4. DE: I agree with SL; some non-ICU implementation might have trouble correctly rendering the out of order dates.
          5. SL: There could be some linguistic information which indicates directionality; restricting it would give the implementation more invariants.
          6. SC: How about we sort the dates?
          7. SL: I like this idea; easy to implement and avoids an error condition.
          8. JW: I tend to think the substring API is wrong and I wouldn't follow it. If we can think of some reason for a negative range, represent it, but I can't think of any
          9. DE: I'd rather we avoid magic here
          10. SC: This seems like a useful feature, e.g., a countdown clock
          11. EA: If it's sorted by the implementation, the API is, give it two dates and display the range, which makes intuitive sense.
          12. SL: I'd go for either sorting or throwing an error.
          13. FB: OK, I'll write this on the issue and we can continue the discussion there.
    3. DisplayNames
      1. API shape issue
      2. Other issues
      3. Plan for TC39 stages? Present to TC39 in July?
        1. DE: Author absent, so we will discuss later
        2. EA: For motivation, I'm not convinced that this proposal addresses a data size issue in practice. This proposal is about adding data, and nothing but data, and being able to access this data, for names of languages, etc which seems weird. The use cases don't seem all too convincing about the data size penalty.
        3. FB: Have you seen that you need to bundle data if you're making, say, a language field? You need to bundle the name of each language. The size can easily increase a lot; we have seen this problem at Google. That's the motivation of this proposal.
        4. SL: For data size: For language names, you need to be able to determine whether there's a dialect situation, not just gluing together the language/script/region data, so some interesting fallback behavior to format names. For the size, in ISO 639 part 3, there are up to 7 language codes, hope that's helpful.
        5. JG: I don't see any mechanism for controlling options for the types of display names that would be returned. There can differences in what you might consider the "display name" for a locale, and some implementations have a notion for variants of display names, e.g., for “fr-CA” in “en” there might be the choice between "French Canada" and "Canadian French". I wonder if there might be a desire to control what the implementation gives you?
        6. SL: CLDR calls this "dialect control". There's also long vs short, e.g., "Macau, SAR China" vs "Macau".
        7. EA: What I'm curious about is, are there actual implementations where this [the data size] is an issue? My feeling is the data over the wire would not approach the theoretical maximum.
        8. SL: That is true, but in real applications the end up including a pretty good amount of data.
  4. July 2018 TC39 meeting
    1. Draft presentation
  5. Liaison relationship between the Intl group and Unicode/CLDR/ICU?
    1. SL: The Unicode Consortium could have a liaison relationship with Ecma/TC39/ECMA-402. This would provide a path for greater participation in CLDR/ICU for members of this organization. We could also have a person be an official liaison of ECMA-402 in various Unicode bodies. The feedback was positive in this direction. It's a matter of Ecma rules for how these work.
    2. DE: We can also work on this in the other direction; Ecma has procedures for registering people from other groups in a liaison capacity as well.
    3. SL: OK, interesting, we can pursue both sides here. Hopefully the way that ICU accepts pull requests will help things, e.g., long-standing patches will move forward faster. For CLDR, if there's anyone from this committee who would like to commit data to the survey tool, we can open that up. Anyone can sign up as a guest; if you are a Unicode member already, you already have people to contribute data. Sounds like we should look into this offline; if anyone has interest, contact DE or me.
  6. Future meetings
    1. Any topics to discuss at the next meeting?
    2. Is August 16, 2018 at 16:00 UTC a good next meeting time?
      1. Yes

Overflow

If we somehow have additional time, additional features to discuss (most likely to overflow into the next meeting)

  1. New proposals
    1. Additional Locale features
      1. Intl.getParentLocales
      2. Directionality of scripts
      3. First day of the week
    2. HTML proposals
      1. navigator.locale
      2. timezonechange
    3. API for reading Unicode properties
    4. Additional options
      1. dateStyle/timeStyle (Stage 1)
      2. Need "symbo-alt-narrow" for Int.NumberFormat options.currencyDisplay
      3. DateTimeFormat: add 'skeleton' support
      4. DateTimeFormat: add support options.raw (aka pattern)
      5. DateTimeFormat: consider adding more timezone display options
      6. [Proposal] Compact Decimal Format to abbreviate large numbers
      7. Expose ability to produce a base form of the word used by Collator
    5. case fold, title case
    6. Hyphenation
    7. What should we do about the specification's implementation-dependent behavior?