Add Fluent language functions

[alerque]

I have a need for a CLI tool tool that not only implements data templating but also gives access to localizations through Fluent. There are several tools for the Handlebars ecosystem (at least JS and Rust ones that I'm aware of) that make this possible but I would prefer to use Tera if possible. There doesn't seem to be anything out there yet, but the fluent_templates crate already has support for use as a Tera function, so it shouldn't be hard to bring the existing library functionality to a CLI.

Is this project interested in adding this functionality (either as a default feature or behind a feature flag), or should I consider forking or creating an all new project for this?

c.f. guangie88/tera-cli#31

[chevdor]

That sounds very interesting @alerque. I can imagine that not everyone will want/need this feature and the extra deps so we definitely want gate that behind a feature.

Currently, my main concern is related to the amount of breaking changes it would lead to (if any). If that does not affect the current usage, I would not mind adding this new feature to the cli.

If you are up for the PR, feel free and I am looking forward to testing it !

[alerque]

I would kindly request you reconsider whether this should be enabled by default. My opinion and reasoning go like this: the people who care about the compile time and binary size (which are admittedly both heftier with the expanded dependency chain) are the ones most likely to have the tooling at hand to run cargo build --no-default-features themselves and get exactly what they want. On the other hand the people who get this by some other means such as prebuilt binaries, or more notably via distro package managers, are the least likely to be able to easily spin up their own tooling to get the full feature set added in. I'm the one packaging for Arch Linux (and will likely promote this to the [community] repository soon) and will be adding the feature flag by default, but what about people that install via Homebrew or apt or whatever? Those people will not care about the build time at all since it doesn't affect them and are unlikely to care much about the binary size either. On the other hand they might care that their app doesn't have the full feature set.

I think having features off by default makes a lot more sense for Rust libraries where the downstream compile time might be a significant consideration and the users (i.e. projects that spec dependencies) can much more easily add the features they need. I don't think it makes much sense to have them off by default for CLI tooling that people are likely to get in binary form from channels that don't provide options.

[alerque]

@chevdor Did you see this comment above? Since it was at the same time as the PR that fell off your radar I thought I'd check.

Either way as long as this gets in a release I'll be able to make it work. I'm the packager for Arch and can make sure the feature gets in there, and I can also make sure Nix and others get it enabled. It will be awkward for folks in a few other distros that might not pick up on the change though. Again for libraries having few features by default makes sense, but for binaries I don't think it does.

[chevdor]

Happy to discuss that, let's make a separate issue to follow up.