Is it possible to use translations in assets?

support
1

Hello,

Is it possible to use i18n translations in assets?
This is how I process my JS.

{{ $scriptJS := resources.Get "js/script.js" | resources.ExecuteAsTemplate "js/script.js" . | resources.Minify | fingerprint }}

And I’m using translations in an usual way:

{{T "translations_key"}}

I thought my assets would get translations when using ExecuteAsTemplate but I’m only getting my JS file with English translations.
I either got lost in documentation or it’s not possible to use translations in assets.

2

You can use resources as template. But I have seen it only with SCSS files up to now. Check this out:

3

@davidsneighbour yeah I’m already using this to inject config values to my JS files. But I can’t seem to get translations working in the way I was hoping to.

4

I’m guessing a little here, but my best guess would be that this is a caching/naming issue.

When you do resources.ExecuteAsTemplate "js/script.js"`` we create a resource with that relative URL: js/script.js`.

Which would effectively be shared between the languages.

Try:

{{ $scriptJS := resources.Get "js/script.js" | resources.ExecuteAsTemplate  (printf "%s/js/script.js" $.Site.Lang ) . | resources.Minify | fingerprint }}
5

@bep tried putting language prefix but still no success. I get JS files for every languages but only with one language translations. Will try to do more testing but I suspect this has something to do with how i18n works?

6

Hmm. Can you create a GitHub issue and I’ll look at it.

7

https://github.com/gohugoio/hugo/issues/6331

8

Hello,

thanks for the trick with printf and site lang, it works and solves our struggle.

I was wondering if the issue could be handled more elegantly - we have site that is multilangual and hosted on separate domains: example.com, example.de, example.cz and now I need to add language slug into assets’ name or path if I want to make ExecuteAsTemplate work, e.g. example.com/js/index.en.js, example.de/js/index.de.js, example.cz/js/index.cs.js. Even though hugo knows each site uses different i18n yaml and each js resource is processed by ExecuteAsTemplate, so it can be expected to be localized.

From my perspective this even could be considered as a cache bug, because it caches something that should be rendered for each language separately.

My feedback is that I expected that example.com/js/index.js, example.de/js/index.js, example.cz/js/index.js will “just work” when I started to use Hugo. And during debugging, I wasn’t able to find any mention in documentation.

9

The ExecuteAsTemplate vs i18n bug is fixed in Hugo 0.60, but you still need to make the URL to the resource it produces unique (by adding the language code to it or something), because even if you don’t want to publish that resource, that reference is used as part of the cache key.

1 Like
10

When Hugo 0.60 came out I was really excited about the fix. And thanks for that!

…but you still need to make the URL to the resource it produces unique (by adding the language code to it or something)…

This is clear for resources on a single domain. I was trying to say that the “confusing” behaviour (for me) was that a domain name is not part of the URL to the resource. So even though I have idependent websites generated to public/{lang}/js/some.js all some.js resources for each independent {lang} are effectively the same .js file - the one generated for the default language.

11

I see that, and I remember thinking long and hard about it when Implementing it. I think I, at least this part, got it right.