Internationalization/localization (i18n/l10n)

[Roardom]

Is there any possibility of adding internationalization support to rinja?

In the blog post https://blog.guillaume-gomez.fr/articles/2024-07-31+docs.rs+switching+jinja+template+framework+from+tera+to+rinja, I noticed:

Many things like i18n support will arrive in the future as well.

I'd be delighted in seeing such support added. Has there been any discussion yet as to the desired syntax and api for it to be implemented?

[GuillaumeGomez]

No discussion about it yet. I never used i18n/l10n so I don't know what API users expect, etc. Maybe @Kijewski has some ideas already?

In any case, if you have suggestions, it's very welcome.

[Kijewski]

The problem I have is that I don't quite like any of the existing i18n libraries. Fluent-bundle is very useful, but it's evaluated at runtime, which is not a good fit for rinja, IMO. Also, any solution should be "HTML-aware", so any variables get escaped, but only variables, not the whole string. And mentioning "string", the result should not be collected into a "String" first, but be rendered into its destination directly.

The crazy idea I had was to use fluent-syntax to parse a language file, convert it to a rinja_parser::Ast, to turn a language file into a Template, which then can be used in other templates. But I daresay implementing that solution would take ages.

[Roardom]

Sure, I can definitely expand on this.

In my case, I maintain a large foss Laravel application (framework docs are here: https://laravel.com/docs/localization) containing ~49k lines of html templates across 400 files. The way it works is the following:

1. Middleware extracts the desired language in the following order of priority:
   1. If user is signed in, use the language saved in their user settings from the database
   2. Use the language saved in cookies
   3. Use the language specified in the lang http header
   4. Fallback to en_US (configurable)
2. I maintain language files such as /lang/en_US/category.php which each contain a dict, with the translated string being the dict value and having a unique string as key to reference it.
3. In the template files, I call the function __('category.unique-string') which fetches the correct translated string from the extracted language. I can also do __('category.unique-string', ['variableName' => 'variableValue']) in case the translated strings have variables. There exist IDE plugins that autocomplete the unique-strings inside the templates.

There are a few things done here that aren't really idiomatic to rust:

1. I really enjoy not having to pass the extracted language through the entire flow of the http request and passing it into the __() function.
2. Message Format 2.0 should be used for the translation string syntax (it's currently still in draft though).
3. Not containing a matching unique string in /lang/ that's specified in __() will return an empty string instead of a compile time error

I have tried a few rust i18n libraries in the past, and haven't yet found one that stuck with me that offers a similar level of convenience, but that also offers the compile-time guarantee of rust.

[m4tx]

Askama had numerous i18n pull requests over time, none of which were ever merged. They might be some source of inspiration – they all are based on Fluent templates, I think, so not necessarily what rinja is looking for.

• Fluent integration askama#211
• I18n runtime askama#237
• I18n askama#434
• I18n askama#700
• i18n askama#841
• Derive i18n support askama#844
• Askama base crate i18n support askama#845
• I18n testing askama#846

There's also a discussion here:

• Internationalization (i18n) askama#202

From my side, this feature would be great to have – I'm also willing to contribute when we know what we're looking for.