Internationalization (i18n)

[Deedasmi]

I'm loving askama so far, but I'm trying to build my first real web app 'the right way', and support localization from the start. I've never worked on localization before, nor with a parser.

The three main approaches I've come across are:

1. Static pages for each language. Would need multiple-path support in Askama. Not the most elegant.
2. String replacement, ala gettext. Jinja appears to best support this style: http://jinja.pocoo.org/docs/2.10/extensions/.
3. Project fluent, with all it's fancy terms, attributes, functions, etc. Probably out of scope?

2 is probably the most reasonable solution, and staying jinja-like would probably be beneficial. Would it make sense for askama to support some type gettext like function?

[djc]

As far as I knew Fluent represents some really advanced thinking about localization and also has a Rust implementation. So to me doing localization "the right way" in Askama would imply at least knowing what a Fluent integration would look like, and how much complexity it would take to do (and how hard it would be for our users).

From what I've seen, gettext may look simpler but also gets complex in the end.

[kazimuth]

Fluent actually has quite a simple rust API, most of the complexity is in the implementation: https://docs.rs/fluent-bundle/0.5.0/fluent_bundle/

Essentially, you create a FluentBundle, which represents a set of known translations + a locale, and initialize it by passing in strings in the FTL language; these strings can be loaded from a file or embedded in the executable. Then, you can call bundle.format("message-name", parameters) to get a translated string. parameters can be None or Some(HashMap<&str, FluentValue> { ... }). FluentValue is a simple Number / String enum.

You can also do bundle.format("message-name.attribute", parameters) to access fluent's attributes, which basically just function as little namespaces.

The main impedance mismatch here is that fluent operates at runtime and not compile-time. I could imagine doing some compile-time verification -- checking that the input FTL files parse, maybe even type-checking the messages used in templates -- but you'll still need to actually load and execute the templates at runtime.

Ideally there could be an i18n(locale, message[.attribute], params...) filter + some way to point askama at a directory of localizations, which would be compiled into the target executable. Maybe a proc macro you call in your application crate, similar to #[derive(Template)]?

I'd be happy to work on this in the next few weeks, although I'd need some help since I don't know askama very well :)

[djc]

Sounds great! Happy to answer questions and provide guidance/feedback on design and implementation.

Having such a filter sounds good to me, the directory also make sense. We could take a similar approach to the templates dir, in that we could have a sane default (i18n?) and a way to change that in configuration.

Not sure yet what you'd need the proc macro for.

[kazimuth]

Proc macro would let you run compile-time instead of runtime checks on the fluent files. Could be overkill, but I've always thought there's no such thing as too much safety in Rust :)

[kazimuth]

My PR adds initial support for i18n using Fluent but the Fluent API currently has some issues. Once:

• Reduce allocation projectfluent/fluent-rs#94
• Simple ResourceManager projectfluent/fluent-rs#88

are addressed, it'll be worth doing another pass. I don't think the i18n API will need to change on askama's end, but it should give users better performance and more support for locale fallback chains.

[kazimuth]

Most of the relevant code's been moved over here to its own crate, which is almost ready to release. I just want to get askama and rocket working first.

@djc, we can do the integration from either end: we could re-export baked_fluent from askama + add custom codegen to support it, or expose add a filter compatible with askama to baked_fluent. The only thing is that we'd need support for some sort of keyword arguments in filters if we wanted to do it that way.

[djc]

Do you have a preference? Either way is fine, really, though my intuitive preference is to have the filter living in askama, since it is an important feature to me.

[kazimuth]

I'll open a PR to add support on this end.

Only real issue I see is making sure people can find the docs; I can just duplicate them in the rustdoc over here though.

[djc]

@kazimuth what's the status on this? Have you got it working for your own application?

[kazimuth]

Ah, some life stuff came up. Plus the job I was going to be using this for fell through, so I haven't been working on it much :/

baked_fluent is nearly ready for release, I just wanna get Rocket support working then i'll throw it on crates.io.

All that's needed on this end is the parser + codegen changes from my previous PR, and a reexport of the impl_localize! macro from baked_fluent, plus some doc additions. I may have some time to work on that later this week.

[Weasy666]

@kazimuth did you have time to work on this?

[kazimuth]

Baked_fluent is pretty much functional, i think i'll release it soon. I don't have the bandwidth for an askama integration, unfortunately; if someone's interested in writing that i can provide some tips.

[Weasy666]

Ah...cool. Thanks for the info.

[jhoobergs]

@djc Do you have an overview of the current status of this?
I have found following PR's / repo's:

• Fluent integration #211 (seemed good, but needed rebasing etc?, Talks about new PR's, only found 1?)
• I18n runtime #237 (talks about a new repo)
• https://github.com/kazimuth/baked_fluent (has never really finished?)

I am right if I say that the localization feature has not been finished yet?
What would be the best way forward for this, in your opinion?