Future of Fluent, MessageFormat 2, etc

[waywardmonkeys]

I work in Rust, so this may have a different answer than if I worked in JavaScript or Python (or maybe not).

Work on MF2 moves forward, but it feels like not much is happening with Fluent. This partially looks like it is because several people are involved in both and focusing on MF2, and partially because some people have simply moved on.

If I'm starting a new project in Rust now, it seems like the best option is to use Fluent (since there's no MF2 implementation in Rust yet). But it also looks like there isn't much development happening with it and none of the PRs that I've filed has seen any attention over the last 3-4 months.

Also, it seems like some of the existing crates used to provide data (like intl_pluralrules are being replaced or superseded by crates from icu4x (like icu_plurals).

• Is there work underway somewhere for MF2 in Rust?
• Should people use Fluent in the short term?
• What sort for interop or migration might be planned or considered?
• Is there a need for new or additional maintainers for any of the Project Fluent repositories?
• Would there be an interest in changes to fluent-rs that migrate to using the newer icu4x libraries?

I didn't know if I should open this discussion here or in an issue in fluent-rs or elsewhere but figured that not all of it is Rust specific, and it is Fluent-specific, so perhaps here was a good spot.

[alerque]

I've been wondering the same things. A couple points:

• With no Rust MF2 implementation yet, this is the defacto best thing to use today. Besides being the best, the conversion from Fluent to MF2 should be easier than from other systems in the future if that's where all development momentum goes.
• If there was a path to join this org I'd be interested in helping with issue triage and PR management to keep things maintained well and maybe even moving forward.
• I for one think migrating to icu4x would probably be a good move.

[eemeli]

I work in Rust, so this may have a different answer than if I worked in JavaScript or Python (or maybe not).
[...]
I didn't know if I should open this discussion here or in an issue in fluent-rs or elsewhere but figured that not all of it is Rust specific, and it is Fluent-specific, so perhaps here was a good spot.

Hi, I maintain the JS and Python implementations but I'm a bit further out of my depth still in Rust. This is probably a decent place for this conversation.

Work on MF2 moves forward, but it feels like not much is happening with Fluent. This partially looks like it is because several people are involved in both and focusing on MF2, and partially because some people have simply moved on.

That would be my assessment as well.

Is there work underway somewhere for MF2 in Rust?

@zbraniecki started on something like that in unicode-org/icu4x#2272, but I don't think he's had the bandwidth for it for a year now.

Should people use Fluent in the short term?

I still tell people that. If you want a state-of-the-art system that's production-ready now, Fluent is a really good choice. It's still the target to which we're driving our use at Mozilla. New feature development within Fluent is rather slow now, but that's honestly mostly because it works. But also because we don't want to introduce potential incompatibilities with MF2.

What sort for interop or migration might be planned or considered?

I've been mostly working in JS for this, with @messageformat/fluent providing two-way conversion between Fluent and MF2 messages and resources. I've been trying to keep that up to date with the MF2 spec changes, so it's usually at most a couple months out of date.

Is there a need for new or additional maintainers for any of the Project Fluent repositories?

Clearly, yes. In particular fluent-rs.

Would there be an interest in changes to fluent-rs that migrate to using the newer icu4x libraries?

Probably, yes. I think this particular question is best raised in its repo, for which I'd need to defer to @gregtatum and @zbraniecki to answer with more authority.

[waywardmonkeys]

TLDR:

• At least one other person and I seem willing to step up and help with fluent-rs.
• I'll file an issue about icu4x integration in the fluent-rs repo.

Details and other stuff below.

Is there work underway somewhere for MF2 in Rust?

@zbraniecki started on something like that in unicode-org/icu4x#2272, but I don't think he's had the bandwidth for it for a year now.

That's interesting to see, thanks.

Should people use Fluent in the short term?

I still tell people that. If you want a state-of-the-art system that's production-ready now, Fluent is a really good choice. It's still the target to which we're driving our use at Mozilla. New feature development within Fluent is rather slow now, but that's honestly mostly because it works. But also because we don't want to introduce potential incompatibilities with MF2.

That seems to be what I was thinking given the current state of things.

What sort for interop or migration might be planned or considered?

I've been mostly working in JS for this, with @messageformat/fluent providing two-way conversion between Fluent and MF2 messages and resources. I've been trying to keep that up to date with the MF2 spec changes, so it's usually at most a couple months out of date.

Is there a need for new or additional maintainers for any of the Project Fluent repositories?

Clearly, yes. In particular fluent-rs.

Seems like we have 2 volunteers (me and @alerque). I've been helping to maintain https://github.com/servo/rust-harfbuzz/ among other things. I can at least review PRs and merge them to keep things flowing, should anything happen. I'm not looking to change things a ton, just keep them working and reduce the distance from ICU stuff so that the eventual migration goes easier (and reduce the maintenance burden).

What needs to happen to make something happen?

Most of my PRs are pretty easy to rubberstamp approve. But I suspect that getting some other stuff in place, like using GitHub merge queues would be good.

Would there be an interest in changes to fluent-rs that migrate to using the newer icu4x libraries?

Probably, yes. I think this particular question is best raised in its repo, for which I'd need to defer to @gregtatum and @zbraniecki to answer with more authority.

I will file an issue over there for that part of this.

Thanks for the response!

[waywardmonkeys]

@eemeli What's a good next step to make forward progress?

[eemeli]

@waywardmonkeys Hang tight for a short bit still? I'm chasing up some approvals within Mozilla, and that's taking a bit longer than I would've liked.

The core issue from our PoV is that fluent-rs is currently a wholly Mozilla-maintained library that we rely on for Firefox, and bringing in outside maintainers means that we need adjust internally a bit how we relate to it. Which requires some negotiations that are still ongoing.

[waywardmonkeys]

@eemeli Understood. I just didn’t know if anything was happening.

I am also looking at what might be involved in seeing mf2 support in icu4x.

[waywardmonkeys]

(I view getting mf2 in icu4x as a parallel thing, not a replacement for the short term.)

[waywardmonkeys]

@eemeli Just checking in on this again.

[waywardmonkeys]

@eemeli Checking in on this again as it has been about six weeks now.

[alerque]

Just a gentle poke. I know this is a paradigm shift for Mozilla, but I don't want to see Project Fluent die a slow death just because Firefox is afraid of it taking on a life of its own.

I'll point out that Firefox (and probably almost everything else that uses Fluent) is already dependent on plenty of 3rd party code—including some code that is already in my hands. Take for example HarfBuzz, a project to which I've contributed a bit including a lot of the release tooling back in the day. I've cut some of the releases that end up getting linked into Firefox and used to shape the text strings that Fluent provides.

Best case scenario: somebody doing dev work over there keeps an eye on things and does some code review on upstream libraries and checks what changes between releases. Just like you presumably screen what's going on between Harfbuzz releases you can screen anything in Fluent.

Absolute worst case scenario you don't have time to review or somehow end up distrusting a change: don't bump your dependencies or use a fork from a version you trust until things are resolved. But seriously I don't think either @waywardmonkeys or myself are going to guide the project off a cliff.

We are (or at least I am) just interested in cleaning up some of the broken windows that are creeping in and giving it some room to breath and grow. Right now contributions have been ignored and issues aren't getting triaged and there seems to be no path to cleanup or improvement.

[waywardmonkeys]

I skipped pinging about this in November. It is now December.

@eemeli Any progress?

[heyakyra]

What will MessageFormat 2 actually provide that Fluent doesn't / can't / won't? There's a page on the wiki for GNU gettext, ICU MessageFormat, etc, but not MF2.

Also, since something like this would've been useful when we were evaluating options at my current company (though I did manage to convince them to go with Fluent over vue-i18n), I put together this list: https://github.com/heyakyra/fluent-companies

[alerque]

Endorsement is a major factor I think. MF2 is likely to get an adoption boost just because of who is signing off on it—not that it doesn't have merit too (it does) but being "standardized" by a recognized body will have an effect. That being said it isn't a viable alternative yet. There are some technical differences between Fluent and MF2 but functionally/conceptually they are much more similar than different (very different syntax but that's just sugar around the concepts and easily converted), and both stand completely apart from the rest of the field in a class of their own.

[heyakyra]

There are some technical differences between Fluent and MF2 but functionally/conceptually they are much more similar than different (very different syntax but that's just sugar around the concepts and easily converted)

Thanks, would be very much interested in an additional wiki page explaining this, and it might be a good spot to recommend Fluent to those waiting for something like MF2 to be ready/viable.

[alerque]

On behalf of @waywardmonkeys and myself, this is a makup January ping. Not trying to be impatient here, but I keep seeing chatter around the FOSS world about not adopting Fluent specifically because it is starting to look unmaintained. Some of us know that isn't really the case under the hood but I can see why it looks that way.

[flodolo]

I know this is not the answer you'd like to hear, but we need a bit more time to figure things out.

Long story short: a mix of people leaving Mozilla or moving to different projects made the ownership of Fluent Rust unclear. That's far from ideal, considering its use within Firefox, and it's also unfair for people who want to contribute.

I'm trying to understand if there are internal resources that can take over ownership, either to keep up with maintenance (e.g. take care of updating dependencies, reviewing PRs) or to onboard external contributors. This will take a few more weeks.

Given its role in Firefox, just giving access to external contributors as maintainers is not an option without a clear ownership model, it doesn't matter at this point how active or experienced they are in Rust (which most of the contributors waiting for reviews are).

I will try to provide updates as soon as I can.

[zbraniecki]

As one of the authors of this crate - I'm continuously involved in the work, but I do not have cycles to successfully maintain it beyond KTLO.

I am working on migration of Fluent to ICU4X, but the rest of the features and decisions are directly linked to MF2 and I'm lightly involved in that work, but don't have cycles to adapt MF2 decisions onto Fluent evolution.

I'd be happy to see Mozilla stepping in further, and in the absence of that, the puck stops on me. Which may mean slow responses.

[eemeli]

It's taken an age and a half, for which I apologise, but we've finally reached this conclusion at Mozilla:

At this time we're allowing community to take over more management of the fluent-rs package. For our purposes the codebase is on maintenance mode since it's working well for Firefox's needs, and the localization system is fairly stable for our needs.

See the linked bug for some more Mozilla-specific details.

@waywardmonkeys and @alerque, I've sent you both invites to join projectfluent/fluent-rs and projectfluent/fluent-langneg-rs on GitHub as maintainers; @gregtatum or @nordzilla should be able to get you access to the fluent crate; for fluent-langneg it looks like @zbraniecki is the only one with current access.

[alerque]

Hey @gregtatum / @nordzilla / @zbraniecki my handle on crates.io is the same as on GitHub and also cross-linked back here. I'd like to get a safe-harbor release out soon so that we are then free to start working forward. Likewise @WaywardMonkey's account seems to match. Is there anything else you need from us to get setup with publish permissions on the fluent-* crates (the fluent-rs workspace members plus fluent-langneg)?

[alerque]

I see a couple invites on Crates.io, but not to all the workspace members yet.

• fluent-bundle
• fluent-fallback
• fluent-langneg
• fluent-pseudo
• fluent-resmgr
• fluent-syntax
• fluent-testing
• fluent
• intl-memoizer

[nordzilla]

Hi @alerque,

Sorry for the delay.

I've just sent invitations for all of the crates that I am able to.

The missing one is fluent-langneg, for which only @zbraniecki is a crate owner.

[gregtatum]

I sent the invites out, let me know if there is any other action on my part. I think fluent-langneg is blocked on Zibi.

[alerque]

Hand-off to additional community maintainers of all the Rust crates (both in the fluent-rs repo and fluent-langneg-rs) is complete. Safe-harbor releases have been cut for all crates coming the last 3 years of small contributions that did get reviewed, and now we're working through the backlog of contributions and needed maintenance that hadn't gotten reviewed.

That means of the original question here points №2, 4, and 5 are addressed. Points №1 and 3 have also been at least partially addressed but remain open questions for at least the near future. Should we keep this open for discussion or close it? Or (my recommendation) close it but get it pinned at the top of the issue tracker because the MF2 question is probably a relevant thing to surface for people just starting their investigations...

[eemeli]

Closing and pinning sounds like exactly the right move here.