Not making it compile if the translation is not found would be nice - feature request

[patrik-cihal]

Maybe if one uses the include-str you could directly within the macro check if the translation for key exists, and not compile otherwise.

[patrik-cihal]

Tho it may significantly slow down compile times not sure.

[patrik-cihal]

Meaning rust analyzer.

[nigeleke]

@patrik-cihal - yes that would be possible, though it assumes the "key" to look up the message is also static. This isn't always the case.

There has been discussion about utilities that do that check for you as best they can. I think a separate utility would be the way to go here...

[patrik-cihal]

Yes I know but then at least allow compile time checks for static strings. Even a utility wouldn't allow you to check non static ones.

Maybe I'm missing some intuition here but compile time checks seem much better.

[nigeleke]

Yes I know but then at least allow compile time checks for static strings. Even a utility wouldn't allow you to check non static ones.

Maybe I'm missing some intuition here but compile time checks seem much better.

I don't think you're missing anything. I prefer to pick out errors as early as possible too - and if it can be done during compilation then that'd be great.

My comments are driven from one of "responsibilities", where dioxus-i18n (the library) is "responsible for" selecting the best translation for a given language, and some utility (dioxus-i18n-cli ?? ;) ) "responsible for" compile time checks.

AFAICS the static analysis may well be pretty complex to introduce. In dioxus-i18n the macro, bundling and config are quite distinct functions. The config is "runtime" despite that fact that the sources are static. Also the config drives the key/value that are loaded and they may not all be from static include_str!. Because of the (perceived) complexity my feeling is that it's better pushed into a utility that can be run separately. (There may well be common code).

I can't find the conversation now, but the same / similar issue has been discussed before, where a user had written something to do just what you're requesting. Our discussion went down the path of making dioxus-i18n into a mutli-project repo and add that as a utility... though I don't think that utility's code has ever been released.

I actually think the idea is great and I'd mentally put it on a todo list to have a look at myself. I'm sure @marc2332 would welcome PRs if you wish to give it a go... and I'm sure he'd consider either of these approaches.

[marc2332]

AFAICS the static analysis may well be pretty complex to introduce.

Agree

I'm sure @marc2332 would welcome PRs if you wish to give it a go...

Yep

The idea is good, but the implementation must be good as well, I am open to ideas :)

[nigeleke]

Just noting another curve-ball: Not all files contain all keys. For example:

Config:
locale en-GB -> include_str en-GB.ftl
locale en -> include_str en-GB.ftl
locale en-US -> include_str en-US.ftl

en-GB:
key1 = something
key2 = colour
key3 = something else

en-US:
key2 = color

If en-US is the preferred language, then the "graceful fallback" would end up using locale en for translations for key1 and key3.

[zoechi]

Sounds like https://crates.io/crates/fluent-static, https://crates.io/crates/fluent-typed