macro `t!`

[sectore]

to simplify/improve i18n rendering.

Example

// Given following translation
// T::title => "Any Title",
// T::Hello => "Hello {$name}",

// No extra args (default)
<div>{t!(cx, T::Title)}</div> // Output: "Any Title"

// Additional args
<h2>{move || {
  let name = "World".to_string();
  t!(cx, T::Hello, { "name" = name })
</h2> // Output: "Hello World"

Highly inspired by Perseus' Internationalization approach - code: macro t! , t_macro_backend, t_macro_backend_with_args, translate_checked - but more simplified for our use case.

In addition: Extract I18nContext (no change here, just to reduce "complexity" in providers) 403fb3b6faaec06c23fb423ddbbcdf232e832a62 - we might do it similar for other providers.

[FelixWeis]

syntax looks useful. taking a deeper look at perseus its use of project fluent, its been a while since I took a deeper dive into i18n but learning again is fun.

[fjahr]

I think it's fine to do it this way. I haven't implemented i18n in Rust yet, but this seems to be a fairly common pattern, similar to _() in core.

But for the project, I would always first ask myself how important translations really are. In the current phase, you might spend too much time on this before the product is even running properly. The thing is, if you add a language, the translations must be correct, good, and complete, otherwise, you might achieve the opposite effect. And you want to iterate as quickly as possible now, it can quickly become extremely annoying if you have to gather translations for 5 languages. All outside contributions have to be reviewed as well, to prevent spammers from adding malicious messages.

Granted, machine translations are much better now, but you have to accept that it might still come off as odd to some people, similar to the emails we get from the Arabian oil prince. Also, if translations are really important, I would first get an integration with a translation management UI so you can manage it better, probably Transifex for you guys as it's free for open source. This makes it easier to bring in people who can contribute translations if they can work within it. I supposed this structure here will work with that but it may be interesting to check first.

[sectore]

I think it's fine to do it this way. I haven't implemented i18n in Rust yet, but this seems to be a fairly common pattern, similar to _() in core.

But for the project, I would always first ask myself how important translations really are. In the current phase, you might spend too much time on this before the product is even running properly. The thing is, if you add a language, the translations must be correct, good, and complete, otherwise, you might achieve the opposite effect. And you want to iterate as quickly as possible now, it can quickly become extremely annoying if you have to gather translations for 5 languages. All outside contributions have to be reviewed as well, to prevent spammers from adding malicious messages.

Granted, machine translations are much better now, but you have to accept that it might still come off as odd to some people, similar to the emails we get from the Arabian oil prince. Also, if translations are really important, I would first get an integration with a translation management UI so you can manage it better, probably Transifex for you guys as it's free for open source. This makes it easier to bring in people who can contribute translations if they can work within it. I supposed this structure here will work with that but it may be interesting to check first.

See your concerns and agree with most of them. However, here is another point of view: Leptos is still new and has unknown areas. That's why we need to figure out constantly how to implement and structure things. If we know how to implement localization in Leptos, we can learn from it to use similar "patterns" (providers, context, macros etc) for next features in code.

Another good thing: For current languages we have native speaker in the team and we can easily switch off any language if we want.

From my perspective a missing plan or milestones for next steps/features in general is more an issue we have right now. Without that, nobody really knows what's next or to focus on.