Ready for Stage 2?
eemeli opened this issue · comments
Once #29 and #39 land, I think this proposal might be ready for Stage 2 advancement. The proposed API has been somewhat stable for a while, and the proposed spec is implemented as a polyfill.
The proposal was also discussed during a recent incubator call, which verified at least that group's agreement with the current API.
The underlying MF2 spec is also reaching a feature freeze next week, for its upcoming tech preview release.
The underlying MF2 spec is also reaching a feature freeze next week, for its upcoming tech preview release.
In my opinion, we should not add support for a DSL that isn't incredibly stable and time-tested. MF2 is not there and won't be there for a long time.
The underlying MF2 spec is also reaching a feature freeze next week, for its upcoming tech preview release.
In my opinion, we should not add support for a DSL that isn't incredibly stable and time-tested. MF2 is not there and won't be there for a long time.
I believe that the MF2 spec should be fully stable, implemented, and battle-tested ("Stage 4") as a prerequisite for the ECMAScript proposal reaching Stage 3. It doesn't feel right that we would need to wait for that before the ECMAScript proposal reaches Stage 2. Perhaps a way to look at this could be that the ECMAScript proposal should be one stage behind the MF2 proposal, so if MF2 is "Stage 3 equivalent" then that would be sufficient for the ECMAScript proposal to be Stage 2.
Stage 2 indicates that "The committee expects the feature to be developed and eventually included in the standard". I wouldn't have that expectation about support for any new DSL.
I don't think we can even define the general shape of a solution that is centered around a new DSL until that DSL is stable.
It sounds like we'll need to discuss this during tomorrow's TG2 call, where this issue was already on the agenda.
The development of the DSL in question here, MF2, is work that was originally initiated under TC39 TG2 back in 2019, specifically for eventual use in this API. From there, it was moved under Unicode CLDR to include an even wider range of stakeholders. TG2 has been tracking that work continuously, with progress reports during each monthly call.
I understand the concern about supporting a novel DSL in general, but at least thus far the sense has been that the MessageFormat work in these separate standards organizations might advance in parallel. However, if we do consider this untenable, then we do have one option that might not be immediately obvious: We can leave out the MF2 syntax from this proposal.
By this I mean that as a part of the MF2 work we've identified a minimal, JSON-friendly message data model that is universal, i.e. capable of representing all messages in all known current formats. The spec language introduced in #39 is written to operate with respect to that data model, rather than the source syntax.
This means that we could here define an Intl.MessageFormat that at least initially required the user to provide their own parser, or to otherwise deliver the message as data rather than syntax. We could even include the data model description directly in ECMA-402, to further reduce the dependence on an external standard. Doing so would let us initially leave out attributes, reserved statements, and reserved expressions, as the model is structured to allow for them to be added later.
To validate the universality of the model, I've thus far written JS tooling for ICU MessageFormat 1, Fluent, and MF2 to work with this data model, and would be happy to provide the same for other formats, should that prove necessary.
As @eemeli pointed out, while MFv2 is a newly designed format, thinking of it as a "new DSL" misses a lot of important context, since it's basically a result of the modernization and standardization of existing formats driven primarily for the express purpose of being supported by modern browsers and be flexible enough to remain powerful in the foreseeable future. Also while the TG2 has maintained track of the work both through the contributor overlap and the monthly reports, being done in Unicode has given the format exposure to more stakeholder feedback and implementation diversity, making it quite interoperable.
All-in-all, while MFv2 is a newer format than the old MF format, it's one that's more obviously designed with this proposal in mind and therefore discounting it just because it's newer doesn't sit right with me.
@ryzokuken Regardless of how new/old the format is or how many contributors it has, the churn is high. Judging by the commit history, the format appears (using generous terms) to not have reached stability. Unicode's stability policy doesn't apply yet to this draft standard. And the bar for adding support within JavaScript isn't just stability, it's long-term stability. Think JSON.
During the TG2 discussion today we determined that rather than asking for Stage 2, we should discuss some of the base assumptions of this proposal. I'll update the TC39 agenda PR accordingly.