| 8 Apr 2024 |
 ryzokuken | possibly | 12:06:14 |
| ryzokuken | https://www.loc.gov/standards/iso639-2/php/code_list.php | 12:06:42 |
| ryzokuken | apparently all the codes are consistent with this scheme! | 12:07:26 |
| ryzokuken | worse than the two letter codes we use but hey, it's a standard | 12:07:43 |
 littledan | oh cool I was right | 12:23:14 |
|  Eric Meyer changed their display name from Eric Meyer to Eric Meyer (brb eclipse). | 17:21:30 |
| Eric Meyer changed their display name from Eric Meyer (brb eclipse) to Eric Meyer. | 19:41:01 |
| 11 Apr 2024 |
|  trueadm joined the room. | 18:49:34 |
| 14 Apr 2024 |
|  Jedel set a profile picture. | 17:30:39 |
| 17 Apr 2024 |
|  Nguyễn Trọng Cường joined the room. | 15:18:21 |
| 18 Apr 2024 |
 sffc | Syntax issues aside, I think it would be a very good use of time to continue diving into the design of the rest of the Intl.MF proposal. There are a lot of interesting questions that we haven't started discussing. This is also the most concrete way that we could start getting feedback from implementers on things that could potentially influence the direction of the proposal. littledan | 00:46:37 |
| sffc | * Syntax issues aside, I think it would be a very good use of time to continue diving into the design of the rest of the Intl.MF proposal. There are a lot of interesting questions that we haven't started discussing. This is also the most concrete way that we could start getting feedback from implementers on things that could potentially influence the direction of the proposal. eemeli | 00:46:59 |
| sffc | * Syntax issues aside, I think it would be a very good use of time to continue diving into the design of the rest of the Intl.MF proposal. There are a lot of interesting questions that we haven't started discussing. This is also the most concrete way that we could start getting feedback from implementers on things that could potentially influence the direction of the proposal. littledan:
eemeli | 00:47:20 |
 eemeli | Did you have anything in particular in mind? | 07:08:38 |
| littledan | In reply to @sffc:mozilla.org
Syntax issues aside, I think it would be a very good use of time to continue diving into the design of the rest of the Intl.MF proposal. There are a lot of interesting questions that we haven't started discussing. This is also the most concrete way that we could start getting feedback from implementers on things that could potentially influence the direction of the proposal. littledan: eemeli I agree. We can continue to explore it while in Stage 1, both in TG2 and in TC39 plenary | 18:24:56 |
| littledan | with signals, my plan is to have several presentations exploring the space, while it remains at Stage 1 for a while during ongoing development | 18:25:26 |
| littledan | there's just a lot to teach the committee about the topics | 18:25:42 |
| littledan | and meanwhile, you have a place for more early design input | 18:25:58 |
| littledan | this can include a detailed explanation of the current MessageFormat v2 syntax design, for example. People may feel more comfortable if they really understand what's behind everything | 18:37:05 |
| littledan | IMO the most important thing to move Intl.MessageFormat forward will be to facilitate its prototyping in various projects/companies. I think this could be done through individual outreach to particular teams that might have the energy to do so, and walking them through how they can deploy existing implementations of it (e.g., messageformat@latest). This is what I'm doing inside of Bloomberg, at least. | 18:38:26 |
| sffc | In reply to @eemeli:mozilla.org
Did you have anything in particular in mind? There are 12 open issues and many of them look like good discussion material. There will be more when we get more people to look at the proposal. | 19:02:09 |
| eemeli | littledan: Note that the polyfill is available on npm as messageformat@next, not as messageformat@latest. | 19:28:06 |
| littledan | * IMO the most important thing to move Intl.MessageFormat forward will be to facilitate its prototyping in various projects/companies. I think this could be done through individual outreach to particular teams that might have the energy to do so, and walking them through how they can deploy existing implementations of it (e.g., messageformat@next). This is what I'm doing inside of Bloomberg, at least. | 19:28:23 |
| littledan | oops, no idea why I wrote that, am too tired | 19:28:30 |
| eemeli | I'd be very happy for the discussions around Intl.MF to become multi-pronged, and for others beyond myself to present about it to TC39 and elsewhere. My own focus at least for the next little while will be reaching out to relevant open source developers about supporting the format. | 19:34:50 |
| littledan | In reply to @eemeli:mozilla.org
I'd be very happy for the discussions around Intl.MF to become multi-pronged, and for others beyond myself to present about it to TC39 and elsewhere. My own focus at least for the next little while will be reaching out to relevant open source developers about supporting the format. just curious, which sorts of integrations are you focused on there? | 19:38:17 |
| eemeli | Initially, introducing MF2 support in localization libraries and ecosystems that are already widely used, like i18next, Format.js and Lingui in JS and Babel in Python. | 19:47:08 |
| eemeli | I figure that making the format available within whatever context people already localize in will make all the next steps easier. | 19:47:56 |
| 19 Apr 2024 |
| littledan | Yes, this seems like a great idea | 14:03:07 |
| littledan | And there are some more high level integrations, eg several in the Next.js space | 14:04:10 |
