Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discussion Issue for the Approval Ballot #954

Closed
aphillips opened this issue Nov 20, 2024 · 7 comments
Closed

Discussion Issue for the Approval Ballot #954

aphillips opened this issue Nov 20, 2024 · 7 comments
Labels
LDML46.1 MF2.0 Draft Candidate meta

Comments

@aphillips
Copy link
Member

aphillips commented Nov 20, 2024

This issue is for the discussion of the Working Group Ballot of the MF2.0 approval found in #955

  • This is the place to explain your "Approve" or "Disapprove" vote.
  • File individual issues for technical problems, editorial issues (such as spelling), or other topics orthogonal to whether we should approve the specification.
@eemeli
Copy link
Collaborator

eemeli commented Nov 21, 2024

For those of you playing along at home, the latest prerelease version of the JS messageformat library implements the current version of the spec, including everything except for :unit.

npm install --save-exact messageformat@next
import { MessageFormat } from 'messageformat'

const msg = new MessageFormat('en', '{$cost :currency u:locale=fi}');
const cost = { valueOf: () => 42, options: { currency: 'EUR' } };
msg.format({ cost });  // '42,00 €'

msg.format({ cost: 42 });  // '{$cost}'
// Warning: A currency code is required for :currency

msg.formatToParts({ cost });  // see below
[
  {
    type: 'number',
    source: '$cost',
    dir: 'ltr',
    locale: 'fi',
    parts: [
      { type: 'integer', value: '42' },
      { type: 'decimal', value: ',' },
      { type: 'fraction', value: '00' },
      { type: 'literal', value: ' ' },
      { type: 'currency', value: '€' }
    ]
  }
]

@gibson042

This comment was marked as off-topic.

@sffc

This comment was marked as resolved.

@gibson042

This comment was marked as off-topic.

@sffc
Copy link
Member

sffc commented Nov 25, 2024

I have a question about the file "registry.md"

It says:

This section defines the REQUIRED functions which are REQUIRED for conformance with this specification, along with RECOMMENDED functions that SHOULD be implemented to support additional functionality.

However, I do not see a list of which functions are required and which are recommended.

I also submitted concerns about certain functions in registry.md:

And there is still the section entitled "Field Options". I have been under the impression since early in the year that these would be implementation-specific options but not in the main registry. Their status in registry.md is unclear.

In any case, I was told that concerns involving registry.md do NOT impact readiness for 46.1, so this does not impact a "vote". If these are things that cannot be easily changed after 46.1, however, I would be quite concerned.

@aphillips
Copy link
Member Author

@sffc: Thanks for your comments and careful read-through.

I have a question about the file "registry.md"

All of the functions currently in registry.md are REQUIRED. There is one RECOMMENDED function being considered (it is :unit). See #922 for what that currently looks like.

And there is still the section entitled "Field Options". I have been under the impression since early in the year that these would be implementation-specific options but not in the main registry. Their status in registry.md is unclear.

These are not implementation-specific options. They are required on :datetime (they do not exist on :date or :time) and cannot be used in combination with style options. I know you have an interest in our replacing these "option bag" style options with semantic skeletons at a later date. That can be done by future additions to the registry, possibly accompanied by deprecation of these options.

The registry is separate in some ways from the rest of the message format specification, but we normatively require the REQUIRED functions in it. MF2 is not very useful without functions, so they were an important part of our deliverables. We have normative language around the functions and their options. We also have a stability policy that will come into effect in 47 (not 46.1), but which we really want to try to live by starting with 46.1. This policy makes promises about what can be changed in the function sets/registry.

@aphillips
Copy link
Member Author

Balloting having been completed, closing this issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
LDML46.1 MF2.0 Draft Candidate meta
Projects
None yet
Development

No branches or pull requests

4 participants