I18n runtime #237
I18n runtime #237
Conversation
|
Let's start without logging? We can add it later before we release this thing. Linking to the Fluent issue on hashmap allocations again: projectfluent/fluent-rs#94. I would argue we should do without TLS for now, we can add it later. |
askama_shared/src/i18n_runtime.rs
Outdated
|
|
||
| pub use lazy_static::lazy_static; | ||
|
|
||
| /// An I18n argument value. Instantiated only by the `{ localize() }` filter. |
There was a problem hiding this comment.
I prefer to have code ordered the other way around: high-level complex dependent API up top, simple private types that don't depend on anything somewhere down the bottom. It's explained a bit more here:
There was a problem hiding this comment.
Huh, I never thought about this. Can do.
askama_shared/src/i18n_runtime.rs
Outdated
| /// This type is initialized in a lazy_static! in impl_localize!, | ||
| /// because FluentBundle can only take FluentResources by reference; | ||
| /// we have to store them somewhere to reference them. | ||
| /// This can go away once https://github.com/projectfluent/fluent-rs/issues/103 lands. |
There was a problem hiding this comment.
So that issue mentions some apparently newly available features/crates -- have you looked into their applicability yet? From looking over the code here, I'm mostly worried about the finer details of fallback chains. (For example, I would say that en should prefer en_US over en_AU in most projects -- though I'm not sure if the Fluent code handles it like this?)
There was a problem hiding this comment.
Those crates don't really buy us anything, honestly. fluent-resmgr is designed for loading from the filesystem, which we don't do, and fluent-fallback does a bunch of unnecessary allocation -- re-building parts of the localization system for every call, which isn't necessary. (It's also only 50 lines of code, so i don't think it's bad to re-implement it more efficiently.)
...On the other hand, https://crates.io/crates/fluent-locale does exactly what we want here! It wasn't used in the examples before, i didn't realize it existed. Will switch to using it now :)
|
Comments addressed 🙂 |
|
Update: I wanna switch the runtime from concat'ing source files to including them separately, one minute... |
forgive some errors
|
Okay, I've just had a thought. I'm looking through the rest of my i18n code, and it's occurred to me that the runtime + codegen for It might make sense to move most of this to its own crate, and add it to askama as a dependency. |
|
Hah, that sounds like it might make a lot of sense! I'd probably prefer for someone else to maintain that, anyway. 👍 |
|
Closing in favor of https://github.com/kazimuth/baked_fluent/ 🙂 |
This PR adds an I18n runtime to
askama_shared. There's no codegen yet, though.This is a little wacky because we're reimplementing some features provided by fluent. (See discussion here).
Open questions:
logorslogto register errors? Fluent is designed to degrade gracefully when errors are present.HashMapof arguments for every call (that takes arguments). Should we instead add athread_local!HashMapand transparently re-use it for each call? In my benchmarks this takes ~250ns off of every call tolocalize(which takes ~500ns on average). However, it's a little weird for Rust.