Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[FEEDBACK] Interoperability concerns and normative-optional features #978

Open
@sffc

Description

@sffc

(split from #977)

I really want to avoid a situation where someone writes a message using some optional extensions, and the message works in ICU4C, and then when they go use an implementation that doesn't implement the same optional extensions (like ICU4X), their message doesn't work. Avoiding this kind of situation is, in my mind, the only job of a specification.

It would make me slightly happier if implementations with optional extensions required the client code to "opt in" to using them. For example, something like

let mf = new Intl.MessageFormat("de", { extensions: ["calendarOption"] })

And then messages with a :datetime calendar="..." option will work only if the stated extension is enabled. If someone tries building an ICU4X formatter with that extension, we'll know ahead of time in the constructor that the extension is not available, instead of waiting to see the message payloads.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Agenda+Requested for upcoming teleconferencePreview-FeedbackFeedback gathered during the technical preview

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions