Help with Tera view i18n (internationalization) language switching

[askor]

Hi, I'm trying to figure out how to use the i18n functionality, because to me it seems like it does not make sense, or its not explained.

Obviously from the example, you can do

{{ t(key="hello-world", lang="en-US") }}

but then I'm providing the language each place, so then I could just as well type it out, and I would have to make one template per language.

The point of a t() function is that the lang should be set somewhere else, so I don't have to make duplicates for each language. So what am I missing? Is there a way to set the language with some Tera magic?

[schungx]

Use a Tera variable in place of the hard wired language code.

[askor]

Ah ok thanks! :) Do you have a suggestion for what is best practice when it comes to setting this variable? I'm on the HTMX stack.

From my research you can maybe get the Accept-Language header from the request, so I could make an extractor that gets that header and passes it's value. Maybe the extractor can even pass the value to the ViewEngine so I don't have to set the variable for each endpoint?

[schungx]

Accept-Language header is more techy. However, for simple coding just use a cookie variable.

If you're using JWT or cookie-based auth then you already get this for free.

[askor]

Ok. Sorry, but I'm not exactly sure how I get this for free?

Currently im doing this to set auth cookie:

    jar.add(
        Cookie::build((AUTH_TOKEN, token.to_string()))
            .path("/")
            .http_only(true)
            .build(),
    ),

Are you saying I can save the users preferred language on signup as an example, then extend this cookie or something?

I thought you could only have one name and value for a cookie?

[askor]

OK did some digging, and I found the JWT struct UserClaims, has a field called claims, that is a Map<String, Value>. So you mean I can put a value pair in this map and get it like this?

    &auth.claims.claims.get("lang")

[schungx]

Although claims are usually for credentials, not preference settings. Nevertheless there is no stopping you from putting the language code there.

The pitfall is that you'd need to refresh your token if the user changes language.