I18n

[jhoobergs]

This (draft) PR gives an initial onset for localization (#202) by using fluent-templates to statically load all fluent translations.
It is based on code of @kazimuth

@djc Could you give some quick remarks / questions?

TODO

• Add with-i18n features
• Fix the test for invalid text_id's (the test fails, as it should, but we should assert that it fails instead of failing)
• Look into a better way to check if translations exist (currently catches a panic of fluent-templates, maybe they should use a Result?)
• Documentation
• Improve init_translations macro
• Go through all remaining TODO comments

[djc]

Looks like a good start! I wonder if we can simplify a bit, though. Can we make a template more like this?

#[derive(Template)]
#[template(path = "i18n.html")]
struct UsesI18n<'a> {
    #[locale]
    loc: unic_langid::LanguageIdentifier,
    name: &'a str,
    hours: f64,
}

Where the type of the field marked as locale must implement a Localize trait. Let's hard-code a directory name for now (what's the usual directory name that projects using Fluent use?), that can be customized through askama.toml. I'm also curious what other template solutions use to call Fluent-like messages. localize(greetingsss, name: name) looks okay to me, though it seems a little different from what we have so far (since we don't do named arguments in general). Does Fluent always require named arguments, or are positional arguments also used?

(Since a language identifier will seemingly always just be parsed from a &str, we may at some point also want to allow &str as #[locale] attribute, taking care to bubble up errors from parsing the language identifier.)

[djc]

Also, thanks for working on this! I'm very excited to get this in!

[jhoobergs]

Looks like a good start! I wonder if we can simplify a bit, though. Can we make a template more like this?

#[derive(Template)]
#[template(path = "i18n.html")]
struct UsesI18n<'a> {
    #[locale]
    loc: unic_langid::LanguageIdentifier,
    name: &'a str,
    hours: f64,
}

Where the type of the field marked as locale must implement a Localize trait. Let's hard-code a directory name for now (what's the usual directory name that projects using Fluent use?), that can be customized through askama.toml. I'm also curious what other template solutions use to call Fluent-like messages. localize(greetingsss, name: name) looks okay to me, though it seems a little different from what we have so far (since we don't do named arguments in general). Does Fluent always require named arguments, or are positional arguments also used?

(Since a language identifier will seemingly always just be parsed from a &str, we may at some point also want to allow &str as #[locale] attribute, taking care to bubble up errors from parsing the language identifier.)

How would we know to use MyLocalizer if it is not passed? Do you want to create a struct with a certain name that we can use? This would not allow having different Localizer's for different parts of the code. But this is probably not really a problem / not a valid use case. Allowing only once Localizer, does also allow using the toml file for the fluent-folder path. As far as I can see, there is not really a default folder name. i18n seems good to me.

Fluent does not allow positional arguments.

Allowing a &str for the localizer, is indeed useful.

[djc]

I guess my question is, what bits of state (other than the locale) does a Localizer need? And will most of these bits of state be per template or globally across a crate/project?

[jhoobergs]

Basically: We need to initialize a static loader (with fallback language) and somehow have access to that loader in different parts of the code.

[jhoobergs]

We need to be able to access this loader somehow. That's the reason for this struct.

[jhoobergs]

The fallback language can be added to the toml file.

[jhoobergs]

Here we need to be able to somehow access the static loader. Currently an object of the generated struct type is used for that.

[jhoobergs]

Here we need to be able to call the translate method. Currently it uses the Localizer object that has to be added to all Template structs.

[djc]

Huh, sorry I missed your responses on this -- are you still interested in working on this?

Having reviewed your code a bit more, how about having an Askama-provided type Locale, which is instantiated with a locale identifier and a reference to the StaticLoader. We then add a filter i18n(&str) which will expand to referencing the fields of the Locale?

[jhoobergs]

@djc I would certainly be interested in working on this. I'm not completely sure if I understand your solution with the Askama-provided Locale-type. Could you write a simple example of the code that a user would write to use the localization? I guess this would consist of a rust struct, a template string and maybe some extra setup code?

[djc]

Something like this:

#[derive(Template)]
#[template(source = "{{ localize(\"hello\", age: 37) }}")]
struct UsesI18n<'a> {
    #[locale]
    loc: askama::Locale::new(lang_id, &TEMPLATES),
}

with this

struct Locale {
   ...
}

impl Locale {
     fn new(lang: unic_langid::LanguageIdentifier, templates: &fluent_templates::StaticLoader) { ... }
}