compilation time checks on fluent args.

[Sk7Str1p3]

Currently if you won't pass arguments to fl! macro, it won't panic. E.G. if you have ftl like this:

hello = Hello, ${user}! 

and didn't set args, it will print Hello, ${user} literally. I believe this also should be checked while compilation.

[aleksanderkrauze]

Hi. I encountered the same issue today and also found this very unintuitive. I would be glad to contribute a patch fixing this. Can some maintainer confirm if this would be accepted, please?

[lucasbasquerotto]

Yes, this is the only issue I found so far with this library. The weird thing is that the library knows the parameters defined in the ftl, so that when you provide an argument that does not exist, it complains with a compiler error and shows the possible parameters that can be used, so a validation of arguments not provided should be something trivial to do.

Update:

This seems like a bug that happens when no args are provided. If the message accept several args, and you provide some, but not all, it correctly shows an error about arguments not provided. The issue only happens when no arguments at all are provided (the validation is not done).

It seems the issue happens at:

cargo-i18n/i18n-embed-fl/src/lib.rs

Line 553 in 659b53c

FlArgs::KeyValuePairs { specified_args } => {

that is called only when at least one argument is provided, validating at:

cargo-i18n/i18n-embed-fl/src/lib.rs

Line 567 in 659b53c

check_message_args(message, bundle, &specified_args);

while the case in which no argument is provided do no validation about unspecified args:

cargo-i18n/i18n-embed-fl/src/lib.rs

Line 542 in 659b53c

FlArgs::None => {

The FlArgs::None branch should also call check_message_args with an empty specified_args, which would cause arguments not provided to appear in unspecified_args and trigger the error.

I applied a patch locally:

FlArgs::None => {
    let empty_args: HashMap<syn::LitStr, Box<syn::Expr>> = HashMap::new();
    if attr_lit.is_none() {
        if let Some(message_id_str) = &message_id_string {
            checked_loader_has_message = domain_data
                .loader
                .with_fluent_message_and_bundle(message_id_str, |message, bundle| {
                    check_message_args(message, bundle, &empty_args);
                })
                .is_some();
        }
        quote! {
            (#fluent_loader).get(#message_id)
        }
    } else {
        if let Some(message_id_str) = &message_id_string {
            if let Some(attr_id_str) = &attr_str {
                let attr_res = domain_data.loader.with_fluent_message_and_bundle(
                    message_id_str,
                    |message, bundle| match message.get_attribute(attr_id_str) {
                        Some(attr) => {
                            check_attribute_args(attr, bundle, &empty_args);
                            true
                        }
                        None => false,
                    },
                );
                checked_loader_has_message = attr_res.is_some();
                checked_message_has_attribute = attr_res.unwrap_or(false);
            }
        }
        quote! {
            (#fluent_loader).get_attr(#message_id, #attr_lit)
        }
    }
}

I expect that a new version with such a fix is released (I can do a PR), but it seems there's no commit in the last 9 months, and this issue had no answer from the maintainers after almost a year, so I'm not too optimistic that such a fix will be released anytime soon.

[Amzd]

Would still be nice to open a PR so people can use it @lucasbasquerotto

[lucasbasquerotto]

@Amzd Done! I opened the PR #170

In your Cargo.toml file you can add:

[patch.crates-io]
i18n-embed-fl = { git = "https://github.com/lucasbasquerotto/cargo-i18n", rev = "67b6d03" }

It should now correctly validate messages that require arguments, while also allowing messages without arguments.