Skip to content

Latest commit

 

History

History
201 lines (186 loc) · 18.8 KB

notes-2018-03-16.md

File metadata and controls

201 lines (186 loc) · 18.8 KB

Agenda link: https://github.com/tc39/ecma402/blob/HEAD/meetings/agenda-2018-03-16.md

Attendees:

Daniel Ehrenberg

Steven Loomis (SL)

Jeff Genovy

Zibi Braniecki (ZB)

Craig Cornelius

Eemeli Aro

Jack Horton

Nebojsa Ciric (NC)

Jungshik Shin (JS)

Felipe Balbontin (FB)

Agenda and minutes (take notes inline)

  1. TC39 summary
    1. Non-members who contribute to ECMA 402 (either PRs or in this call): Sign this form to license contributions to Ecma
  2. Questions/issues with existing advanced proposals and APIs
    1. Normative: Add calendar and numberingSystem options
      • Resolution from the last meeting: We should validate the shape, but not the actual contents.
      • Dan working on a test262, V8, spec patches for this.
      • Notes: Yes, continue with this
    2. Segmenter: Should we add all the options (lw, ss), or just lb?
      • Data size?
      • Notes:
        • Jungshik: Supporting lw supports a lot of things, and ICU doesn’t actually support it. It doesn’t make sense. You need the part of speech marker, etc, not so it’s not so useful for Chinese and Japanese.
        • Dan: And ss?
        • Jungshik: Maybe, not sure, but I’m against lw. There are only some exceptions there. There are only 30 entries per language. So it should be pretty small.
        • Steven Loomis: This would be useful
        • Steven: For counting sentences for translation or split up for other purposes, we make use of sentence suppressions to make sure the sentences aren’t split incorrectly.
        • Jungshik: Examples are ‘Dr.’, ‘Mr.’, ‘Mrs.’, ‘i.e.’, and so forth.
        • Ciric: It’s not the greatest system, it’s driven by exceptions, and it’s mostly English.
        • Steven: Actually it’s statistical
        • Jungshik: Maybe just turn it on all the time?
        • Steven: If you turn it off, you don’t have heuristic, so it may be faster, be guaranteed by Unicode rules.
        • Dan: But we don’t even specify the break algorithm when it’s off
        • Ciric: How would you know whether to turn it on?
        • Steven: See the docs. For our own processing, we use it by default. For general use in ICU segmenter, there’s a concern that the performance could be improved. And it does take time, since it has to look at the exceptions, so you can’t just go through the existing finite tree. We’re thinking about JS, but there are discussions here at several levels. So, it can be important to make sure we’re having the discussion at the right levels. What’s the purpose of the ECMA 402 spec? It’s not to describe it.
        • Jungshik: My concern is that this is too implementation-specific.
        • Steven: This is a question of whether we want to pass down all the keys.
        • Dan: We’ve never passed down all the keys in Intl
        • Zibi: What’s the problem with adding it later?
        • Steven: OK, sounds like that’s the path forward
    3. Locale:
      • Consider performing complete Unicode extension canonicalization per RFC6067
        • Conclusion was to do the full canonicalization?
        • Notes: Yes
        • Jungshik: Are we going to drop an unrecognized value if it is well-formed? No
      • Return DefaultLocale() when calling Intl.Locale() with an absent/undefined tag argument?

        • Conclusion was to not make this change and require an argument?

        • Ciric: The discussion is between making undefined lead to the root locale, or throw an exception. We agreed that we don’t want to expose the default locale here.

        • Zibi: Intl.Locale is a way of processing locales, not

        • Steven: It’d be a convenience, but it might not add much value and blur the distinction between a class responsible for processing data. The Locale should be an identifier, not a service

        • Dan: Does anyone have a problem with throwing an exception here?

        • (everyone is OK with it)

        • Ciric: What happens when you pass something not well-formed, like "1", 2? - throws, not well formatted

        • Conclusion - keep spec as is (throw, don’t return defaults)

      • Spec questions/errors
        • Do we want to carry forward the optionality of kf and kn?
          1. Jack: caseFirst isn’t supported in Windows globalization, as an example of why we may want to leave this as optional. (Also relative time format).
        • ZB: Raises a larger question of what is mandatory vs what is optional in order to be spec compliant. 2. Some impl. may not full set of data and will fall back to ‘en’ for everything. This should (?) still be fully spec compliant. 3. Steven asks if Segmenter’s ss is an example of something that could be optional 1. Dan says that we shouldn’t increase the surface of optionality if possible 4. Dan points out that optionality of hourCycle vs caseFirst uses different mechanisms. 5. We’re going to continue the conversation offline
        • How are we handling regular and irregular grandfathered tags? (also for the main specification) 6. Ciric: Are these just for historical reasons? 7. Steven: There are a number of these; they are used. For compatibility, we could replace grandfathered tags. We could not bend over backwards, just support them. We should just map the grandfathered tags into new-style tags. 8. Daniel: Seems like this should be added to the Intl.Locale specification if we want to do the mapping. 9. Zibi: Grandfathered tags add a lot of complexity to the SpiderMonkey locale implementation. Could we switch to a very simple mapping that takes place at the first step? 10. Steven: Historically, grandfathered tags have been used for underserved communities. Java does this forcibly in its constructor, where it forcibly maps locale IDs to something else. I think that’s a bit too aggressive, but just in processing, it’s treated as if the other value were used. 11. Ciric: What do we expect in the canonicalized version, that it’ll never be grandfathered? Yes 12. Steven: we can vet this list and make it hard-coded. There are a number of sources, but the master is IANA subtag registry 13. Dan: Would apply to all locations that locale is input. We also need test262 tests. 14. Steven: I’ll take the lead on this project. Should we do those for deprecated locales also? 15. Zibi: Android uses the wrong locale for Hebrew, so this comes up. 16. Steven: Java forcibly changes he to iw. So you’ll see iw in Java-related things--that’s Java’s code for it. 17. Jungshik: it should be as transparent as possible to customers of the API. 18. Sounds like we should handle deprecated tags in the same way
        • Missing notes from last time
    4. Intl updates for the Kangax compatibility table? (Zibi)
  3. ICU tickets to support existing advanced proposals and APIs
    1. Add RelativeDateTimeFormatter.format(FieldPositionIterator)?
      • icu-design proposal resent; any feedback? Next steps?
      • ICU patch wanted
      • Notes:
      • Steven: We’ll have to get this into the meeting to get consideration. I’ll get in touch with Yoshido.
      • Myles: Why have this feature?
      • Zibi: For all new formatters, we add this way to get out the parts, so that it’s possible to format different things differently,
      • Jungshik: people often try to parse and piece things to without parsing and trying to guess the parts, which is often broken.
    2. RelativeDateTimeFormatter doesn't handle -0 well
      • ICU patch wanted
      • Ciric: Unfortunately the ICU team has limited bandwidth.
      • Steven: You added a control for +0,-0?
      • Shane: That doesn’t have to do with this; we’re talking about NumberFormatting
      • Zibi: Is this the same problem or a differnet one
      • Shane: Probably RelativeDateTimeFormatter is using < inappropriately, probably a 2-3 line change
      • Steven: Is there someone willing to make a patch for this?
      • We are pinged the owner
      • Steven: Will add an ECMA bug label/keyword for JS-related things
    3. TimeZone::getOffset() : add two params to control repeated/skipped wall time
      • Jungshik wrote a patch, anyone want to review?
      • Was a proposal sent to icu-design?
      • No. Jungshik will propose.
      • Jungshik: Not blocked by this issue, (v8 implementation is pending review)
    4. Get locales with PluralRules support
      • Should we close as will-not-fix because all locales will always be considered supported?
      • Zibi: PluralRules is part of the seed of any locale
      • Steven: It’s expected that all locale support PluralRules before being accepted into CLDR
      • Eemeli: Ordinal too, or just cardinal?
    5. Are there any remaining APIs that need to be marked as "stable" or ported to C?
    6. Any other support needed from ICU for Intl proposals?
  4. New proposals
    1. NumberFormat changes, including (a) restructuring the spec, (b) minor changes to behavior, (c) support for measure units, and (d) support for scientific and compact notation.
      • Status update for this proposal?
      • How is the C API coming (necessary for ChakraCore and SpiderMonkey, and JSC)
      • Overall thoughts?
      • What to do with the style option: "deprecate" it (Option 1) or keep it as a first-class citizen (Option 2)?
      • Where to put the modifiers for units, like the width and compound units: as a top-level setting (Option A) or as a nested object literal on the unit key (Option B)?
      • Notes:
        • People generally like top-level better (A)
        • Dan: Are there any cases where omitting style is ambiguous? Anyone remember why we put it in earlier?
        • Shane: No ambiguity
        • Eemeli: As a library developer, it seems easier and cleaner to have the style argument. The semantics are more like, when I pass a currency, that means, "if a currency is needed, that is X", etc. Otherwise, I’d need to maintain different objects depend on what thing is being formatted, so it’s messier.
        • Dan: Oh, this seems analogous to Intl.Locale, which might specify more of these kinds of options, e.g., from navigator.locale giving a currency.
        • Zibi: not doing style would require a lot of diligence
        • Shane: I don’t know if it’s so bad; including the field is the toggle. If you don’t want to use it, you leave it as undefined.
        • Zibi: Maybe I want to specify a preference without having a particular choice. With your API, I’d have to actually go and remove some of them.
        • Jungshik: A better example is distance in meter and currency in USD
        • Caridy: In TC39, the tendency is, if there’s not a signficant improvement, in ergonomics or technical things, we should stick to the status quo. Does this change bring anything that’s considerably better than what we have right now?
        • Shane: It’s unintuitive how, right now, if you specify a currency and no style, it’s ignored.
        • Caridy: It’s not possible to change that behavior today. Going forward, we can decide what we want to do on new features. In addition to being inconsistent, it makes a problem for library authors. Library authors are our target audience, as these APIs are relatively low-level
        • Shane: In a strict sense, it’s a compatibility issue, but I’m not sure if anyone is running into it. Anyway, I can see how keeping the style attribute makes sense. Here at Google, we have design meetups every couple weeks, and the consensus there was against the style attribute. However, those people don’t have background in ECMA 402 and the history and needs of JS users.
        • Eemeli: I don’t dislike style. It certainly has good uses for library developers. What is the expected thing to happen when you include currency without style? A middle ground would be to relax what happens when style is undefined.
        • Dan: I don’t think we can change style: currency due to web compat.
        • Caridy: I definitely know of several cases that would break
        • Shane: If we have to keep style: currency, I’d want to do style: measure
        • Jack: Also, for percent, it’s only indicated by style.
        • Jungshik: Now we don’t have to worry about any sort of priority
        • Conclusion: Keep style
        • A 2
        • Follow up on details about naming once we have a specific draft of the spec
    2. IntervalFormat (Felipe)
      • Status update
      • Which should be the structure of .formatRangeToParts()'s return value?
      • Any trouble creating a repository? Feel free to contact Dan for help.
      • Notes:
        • Felipe: One question is how to formatRangeToParts should represent tokens which are shared between multiple dates (‘start’ and ‘end’ dates). The current thought is at the top level.
        • Caridy: When specifying the initial set of formatToParts was that you could do a very simple process to zip through the parts and produce the same output as you get from format. If we do a nested object, it could be a lot more difficult to do the same process.
        • Felipe: I had the same feeling, so the other option is to not have nesting, and add an additional tag which indicates whether something is one date or the other. People can just ignore that if they don’t care.
        • Zibi: I can see us doing something similar in NumberFormat, so I’d like to create a pattern we can follow in the future. I’d much rather create an additional field than nesting.
        • Caridy: This was the original intent. We also need to bikeshed on the name.
        • Conclusion: Use the second approach with a flat array, and a new attribute
        • Felipe: Additional formatter vs a second method to DateFormat? The set of options for one are valid for others. And this could be a nice pattern for the future (e.g., NumberFormat). So, we talked about it and settled on formatRange.
        • Shane: I like formatRange as a pattern. Better to keep the number of options smaller.
    3. UnitFormat (bug) (Stage 1)
      • Still relevant with Shane's proposal? : No except for list format.
      • API suggestions for compound units (e.g. 9.8 m/s^2) ? Numberformat supports it.
      • Conclusion: folded to be a part of new "unified" Number format
      • ** "list number format" (e.g. 10 meters and 35 centimeters): Introduce a list format**
    4. BigInt.prototype.toLocaleString
      • Dan: overload ‘format’ method with NumberFormat? ‘String’ is coerced to Number instead of BigInt.
  5. Future meetings
    1. Does the two-hour, once a month format still work well?
    2. Feedback about prioritization, running meeting, etc
    3. Is April 20th at 17:15 UTC a good next meeting time? (Note: DST may shift the effective time by an hour)
      • Are we missing out on participation from Asia with these meeting times?
      • Standing request: Find a time which is not Friday evening in some time zones
  6. Other
    1. Steven: FYI: Node.js considering including full data by default (not English-only). nodejs/node#19214 Feedback wanted, but relevant to discussion here about data size impact implementations.
    2. Steven: Q: seprate C++/C library for common implementation of ecma402 related operations (on top of ICU or ported)? (locale/option bag handling might be interesting) Pro: common code FTW, don't need to wait for Ecma402-focussed API improvements in ICU. Con: many implementations are already a thin wrapper on ICU. Jeff: What would be the Licensing of such a library? What language(s) for implementation?
      • Rust? (serious proposal: C/C++ FFI, compiles to WASM and JS)
      • Steven: It could be proposed as an ICU subproject (MIT/X)