Reported on Reddit by scott11x8.

The parser actually store variables in a HashSet, which has not a consistent and predictable order. This may cause tricky bugs, as order parameters of generated methods may differ across build.

This can be fixed by sorting parameters alphabetically. Furthermore, this will avoid silent bugs when changing order in source files.

• [x] Sort parameters alphabetically.
• [ ] Improve tests for keys with multiple variables.

I've found an issue when using multiple parameters, the ordering is incorrect and random.

Rust:

&lang.notification_post_reply_body(&person.name, &comment.content, &inbox_link)

JSON:

"notification_post_reply_body": "<h1>Post reply</h1><br><div>{username} - {comment_text}</div><br><a href=\"{inbox_link}\">inbox</ a>",

Yet when I do a hover / check the order, it shows:

pub fn notification_post_reply_body(&self, comment_text: impl ::std::fmt::Display, inbox_link: impl ::std::fmt::Display, username: impl ::std::fmt::Display) -> ::std::string::String

Somehow the order of name, comment content, inbox link, got changed to comment content, inbox link, username during the rosetta build process.

The current syntax is quite verbose for something that gets used a lot. It would be nice if there could be a helper macro like get_string!("en", "key", "param1", "param2", ...).

The macro could also automatically use fallback() if the requested language doesnt exist, so the whole usage would be much easier.

For example, mod.

--> /home/felix/workspace/lemmy/target/debug/build/lemmy_websocket-5c9ec7d2402ea26c/out/rosetta_output.rs:1:35802
|
1 | ...[allow (clippy :: match_single_binding)] pub fn mod (& self) -> & 'static str { match self { _ => "mod" } } # [allow (clippy :: match_...
|                                                    ^^^ expected identifier, found keyword
|
help: you can escape reserved keywords to use them as identifiers

Would be good if identifiers could be escaped, as suggested by the help message. Syntax is like let r#mod = 123;.

Thank you for this library! There are very few options for using json localization files in Rust, and this looks like the best one. There are some things which are unclear though, and I hope you can explain them to me:

• How can i select the language dynamically? The examples only show Lang::En.hello(), but i need something like get_string("en", "hello") in order to select the language at runtime.
• Can errors about unused arguments be disabled? We are using the same translation files across multiple projects, so its normal that some of them are unused.

  error: named argument never used
  --> /home/felix/workspace/lemmy/target/debug/build/lemmy_websocket-5c9ec7d2402ea26c/out/rosetta_output.rs:1:1957
  |
  1 | ...tring { match self { _ => format ! ("{{count}} Abonnés" , count = count) } } # [allow (clippy :: match_single_binding)] pub fn select_...
  |                                        -------------------           ^^^^^ named argument never used
  |                                        |
  |                                        formatting specifier missing
  

• When enabling translations for en and fr from these files, it gives another error. Maybe its because we dont follow your string formatting rules, or because the variable has a different name in both language files?

  Compiling lemmy_websocket v0.15.1 (/home/felix/workspace/lemmy/crates/websocket)
  error: failed to run custom build command for `lemmy_websocket v0.15.1 (/home/felix/workspace/lemmy/crates/websocket)`
  
  Caused by:
  process didn't exit successfully: `/home/felix/workspace/lemmy/target/debug/build/lemmy_websocket-d9289556ed2bb147/build-script-build` (exit status: 1)
  --- stdout
  cargo:rerun-if-changed=translations/translations/en.json
  
  --- stderr
  Error: Parse(InvalidType { key: "number_online_plural", expected: "string" })
  

Thanks in advance :)

Detecting user preferred language from environment variable or system configuration seems to be a common use case, so it could be great to provide a ready-to-use function to do that. It will probably be hidden behind a feature to avoid unnecessary additional dependencies.

The current_locale crate can be used to detect user preferred language.

Suggestion from Reddit by tlgman.

The library actually uses ISO 693-1 languages identifiers, which are very simple languages identifiers (2-letters code), but does allow for precise identifiers. For example, en-US is not a valid ISO 693-1 identifier.

IETF BCP 47 is a standardized code used by many standards such as HTTP and HTML. This format is compatible with ISO 693-1 identifiers. As for actual identifiers, the library will not provide a way to validate if a specific language tag exists, but will rather focus on parsing and canonization.