Both to and from MF1, to aid migration before localization tooling catches up

I have not yet found a use case for MF2 → MF1, but this has worked for MF1 → MF2 for quite a while already:

import { mf1ToMessageData } from '@messageformat/icu-messageformat-1';
import { parse } from '@messageformat/parser';
import { stringifyMessage } from 'messageformat';

const mf1Msg = 'You have {numBooks, plural, one {# book} other {# books}}';
const mf2Msg = mf1ToMessageData(parse(mf1Msg));
stringifyMessage(mf2Msg);

.input {$numBooks :mf1:number}
.match $numBooks
one {{You have {$numBooks} book}}
* {{You have {$numBooks} books}}

For Fluent '@messageformat/fluent' provides two-way transforms and uses the default MF2 functions, but at least for now I found it easier to implement a separate family of mf1: functions, as the option mapping is a bit complicated and MF1 includes e.g. duration formatting, for which there's no MF2 function (yet)

I have not yet found a use case for MF2 → MF1

My company is definitely interested in this. We're considering starting to write MF2 messages as we explore implementing it, but converting them back to MF1 either just for production or for the whole translation process. As mentioned, until "localization tooling catches up".

@bearfriend I would very much welcome your (or anyone else's) contributions towards that at https://github.com/messageformat/messageformat/tree/main/mf2/icu-messageformat-1.

I noted somewhere else:

--
I think the list would be something like:

• Stabilize remaining MF1.0 function support (:datetime, :date, :time)

• Stabilize additional MF2.0 functions or options currently in draft (:unit and u:locale)

• Create documentation, especially the user guide / messageformat.dev

• Develop function description format as Draft (this is the machine-readable function data)

I don't think the WG should specifically build migration utilities, localization support, etc. But we should encourage people to report on their efforts in these areas. We crave success stories!!

Other than the function maintenance process, I hope that we do NOT change the spec much. Of course there will be typos and editorial improvements and of course there will be goof-ups or useful feedback. But, absent compelling evidence to the contrary, we should maintain a high bar on changes to the core spec.

@bearfriend I would very much welcome your (or anyone else's) contributions towards that at
https://github.com/messageformat/messageformat/tree/main/mf2/icu-messageformat-1.

100% agree, but we need to find a good place.
Maybe in this repo, or somewhere related.
I am a bit reluctant about github.com/messageformat, which is a personal repo.

In the 2025-03-10 teleconference we agreed that I would create a PR to update goals.md.

Sounds like these two statements potentially conflict, and settling one will (mostly) settle both:

I don't think the WG should specifically build migration utilities

...we need to find a good place. Maybe in this repo...

Either way, I did start fiddling with converting back to MF1 with some success. Am I to understand datetime is potentially being added to the MF1 spec? I had done some fun but less-than-ideal conversion to separate date and time formatted args provided a template (e.g. {0} {1}).

I am a bit reluctant about github.com/messageformat, which is a personal repo.

To correct the above, messageformat is an OpenJS Foundation project. It is not a personal repo.