fluent-fallback 0.0.4 crate depends on fluent-bundle 0.12

[alerque]

I'm having trouble updating to fluent 0.13.x, and it seems part of the issue is a circle of dependencies that pulls in older versions. In particular fluent-fallback seems to depend on fluent-bundle 0.12, dragging both 0.12 and 0.13 into my app and fouling up the works.

   --> src/i18n.rs:134:19
    |
134 |         let loc = Localization::new(
    |                   ^^^^^^^^^^^^^^^^^ expected struct `fluent::bundle::FluentBundleBase`, found struct `fluent_bundle::bundle::FluentBundleBase`
    |
   ::: /home/caleb/.cargo/registry/src/github.com-1ecc6299db9ec823/fluent-fallback-0.0.4/src/lib.rs:28:17
    |
28  |     I: Iterator<Item = FluentBundle<R>> + 'loc,
    |                 ---------------------- required by this bound in `fluent_fallback::Localization`
    |
    = note: expected enum `std::option::Option<fluent::bundle::FluentBundleBase<fluent::FluentResource, intl_memoizer::IntlLangMemoizer>>`
               found enum `std::option::Option<fluent_bundle::bundle::FluentBundleBase<_, intl_memoizer::IntlLangMemoizer>>`
    = note: perhaps two different versions of crate `fluent_bundle` are being used?
    = note: required because of the requirements on the impl of `std::iter::Iterator` for `std::iter::FromFn<[closure@src/i18n.rs:111:27: 130:14 resolved_locales:_, res_path_scheme:_, res_ids:_]>`

I looked at the current sources in this repo and they look okay, I'm guessing the crate just needs a new release to reflect the current state of the sources.

[zbraniecki]

Ah, yes. We're currently working on a major update to fluent-fallback to pull it into Firefox. It will take a couple more weeks after which we should have a much more complete higher level experience.

Can you wait or would you prefer a quick 0.0.5 release to unblock you now?

[alerque]

I could wait (or pull in Git sources) but if the release process is easy I'd suggest it's a good experience to leave the current stable release in known-broken state if the problem is also known to be fixed just by bumping the dependency to the proper version. I haven't gone down the rabbit hole to see if everything else is in a working state, but if it is I would suggest a release just so others don't wander into this problem and waste as much time as I did trying to figure out what gives.

[zbraniecki]

Do you also use fluent-resmgr or l10nregistry or do you provide custom resource management?

[alerque]

I provide custom resource management. I started with code for some of the functions in fluent-resmgr for parsing locales, but extended it with some more advanced fallback stuff, then bolted it onto a home-grown solution using rust-embeded to feed it actual data.

At the time I implemented this fluent-templates didn't exist, but having recently run across @XAMPPRocky's project I'm kind of bummed I didn't start extracting and generalizing my code earlier because it's clearly a very similar concept. On the other hand I'm glad somebody else did the work and took it farther that I would have and am looking forward to maybe refactoring out my home-grown stuff and going with that.

As for l10nregistry, I literally hadn't heard of it until just now.

[zbraniecki]

@alerque the new fluent-fallback has been released! Can you try?

[alerque]

Will do...

[alerque]

@zbraniecki I feel kind of silly saying this, but I just sat down to review this and I can't find a new release of fluent-fallback.

[zbraniecki]

It's not on crates.io because we depend on pin-cell which didn't get a release in a year - https://github.com/withoutboats/pin-cell/issues/6

I'm considering forking it into fluent-fallback for now, but to test, you can do:

fluent-fallback = { git = "https://github.com/projectfluent/fluent-rs", tag = "fluent-fallback@0.1.0" }

[alerque]

Thanks. With that of course I found the crate. I bumped my my deps up from Fluent 0.12.0 to 0.14.0 and of course this update. Unfortunately this lands me in pretty deep water and I clearly need to do quite a lot of refactoring. Comparing my current code to the current example code in the fallback module suggests that almost all the cheese has moved. Also unfortunate I had a look a the docs for the fallback functions and structs and found --- they don't seem to be documented at all. Having taking a few stabs at refactoring, I'm going to take a break and look into jumping ship to fluent-templates instead because it looks like it's engineered to do roughly the same work I was doing manually and if I have to practically rewrite from scratch anyway I suspect it's going to be less painful to use that.

That's a long winded way to say I won't be giving this much of a test drive unless the experiment with fluent-templates suggests it isn't right for the job.

[zbraniecki]

Yes, I agree.

Higher level Fluent APIs are not yet stable (as the version suggests). I'm iterating over them and the FluentBundle is mostly stable, while fluent-fallback is getting stable as we speak. I expect the situation to cool down within a month or two and we'll start talking about using fluent-fallback for actual bindings to libraries such as druid and other plug&play use cases.

I'm sorry for the hassle - getting localization set up correctly for both simple and complex (long-lived, live language switching, and dynamic resource loading) scenarios is non-trivial and I much prefer to be in the storming phase now, and end up with a stable model for years to come (as we did with JS implementation!).

So, fluent-templates may be a good mid-point and I hope that fluent-templates will rebase on top of fluent-fallback eventually once we stabilize! :)

I'll close this issue for now, please reopen if needed!