Hugo Multilingual Multihost and Netlify

Thanks @bep. I had been pointed to this workaround but AFAIK the URL in the browser will always be my primary domain, is this right? I’d prefer my users to have a better experience, so that each language has its own site, but they’re all connected thanks to Hugo magic

That’s what he is talking about with domain aliases. Add all your domains to point to that Hugo installation. Then rewrite.

So that solution should work with my old installation (without setting a baseURL for each language), right? I need to try it, as I don’t really understand yet that 200 redirect :thinking:

So, with this, if a user navigates to it will be redirected (still showing the physichemically domain) to Only issue that I see is that if a user navigates to my original domain, for example, then it will stay there (and showing exactly that in the address bar). Am I right?

In my head:

  • You set up Hugo in multihost mode, so each language gets its own domain (that way all permalinks will point to the correct domain)
  • You set up 1 redirect rule per language (including your main language)
  • If a user navigates directly to “” that will translate to “/en/en/example-page/” … which is a page that does not exist (and that is the behaviour you want, I guess)

What I’d really want is to have a working multihost setup, having each language in its own domain, and then configure redirects (301 I guess) so that all my current multilingual links still work (redirecting to their respective sites/domains). For that I should be able to create a Netlify site for each domain, all sites pulling from the same repo but using a different publish directory (public/es, public/en and so on). I’ve already set that up in Netlify but it’s not working presumably due to a Netlify Large Media permissions issue (I’m able to successfully link my sites to the same GitHub repo but I get an error 128 when trying to deploy them, actually when cloning them). As soon as I disable Netlify LM I’ll try again and report back.

Thank you all for your time

Hi all, after disabling Netlify Large Media from my original site I’ve been able to successfully deploy my multihost setup using three different Netlify sites all connected to the same repo but with a different publish directory, specifying each language folder. Everything works great except some small things that I need to investigate (probably related to the theme I’m using, Wowchemy). You can check it out live here (Spanish), here (English) and here (Catalan). I’ve even configured Netlify redirects so my existing links point to the right domain now.

Thanks for everything.

Just in case this could be related to Hugo itself. The issues I’m seeing are related to JavaScript not being correctly loaded, although that only happens in production (I can’t reproduce them locally, where everything works as expected)

Right click > Inspect > Console > Check the red messages. Blackbox guess is CSP :slight_smile:

Not CSP related but almost:

[Error] Failed to load resource: the server responded with a status of 404 () (wowchemy.min.0e1dc40e07de343ba83181ae07edc3bd.js, line 0)
[Error] Refused to execute as script because "X-Content-Type-Options: nosniff" was given and its Content-Type is not a script MIME type.

I guess something needs to be fixed in Wowchemy. Thank you very much!

The thing is that JavaScript is trying to be loaded from the /en/ folder even though using a different baseURL

This line seems to be the culprit:

{{ $js_academic := resources.Get "js/wowchemy.js" | js.Build (dict "targetPath" (printf "%s/js/wow-core.js" .Lang ) "params" $js_params) }}

Yes/No. The problem is, that wowchemy.min.0e1dc40e07de343ba83181ae07edc3bd.js can’t be found so Netlify is sending a 404 error page (text/html, which is not text/javascript).

I would try different “hacks” (without knowing the complete layout:

{{ $js_academic := resources.Get "js/wowchemy.js" | js.Build (dict "targetPath" "js/wow-core.js" "params" $js_params) }}


{{ $js_academic := resources.Get "/js/wowchemy.js" | js.Build (dict "targetPath" (printf "/%s/js/wow-core.js" .Lang ) "params" $js_params) }}

The thing is, that you don’t have /en/ directories, because you have your own custom domain, right? so you won’t need to separate by language for the scripts. This is most probably some form of bug in the wowchemy (not a fan :wink: very complicated setup) theme. Try removing anything that looks like a language directory.

Sometimes (on the other side) there are some issues with missing slashes at the beginning of the path. That however is only the second thing to check out. Subfolders are probably the culprit.

Thanks a lot @davidsneighbour. Apparently that specific line was a workaround proposed by @bep to allow importing page resources in js.Build for multilingual sites. I’ve tried both solutions as well as this other option:

{{ $js_academic := resources.Get "js/wowchemy.js" | js.Build (dict "params" $js_params) }}

It’d be great if we could check whether a site is using a multihost setup or not (something like a .IsMultiHost variable. Is that possible @bep?

That’s right, and that’s where that .IsMultiHost variable would be very welcome.

I agree that the initial setup may be a bit involved, but at the same time it gives users great versatility for creating a lot of different sites. George Cushen (the author) is also making great efforts to keep it up-to-date with the latest best practices and available libraries and Hugo features. I admit that my personal opinion here is quite biased, as:

  1. I’m using Wowchemy to build/publish my site and I’m quite happy with it.
  2. I’m one of the moderators of the Wowchemy Discord server built around the community using it.

I’ll report back as soon as I have it fixed. Thanks for all the help received, really appreciate it.

Just to be 100% clear (hopefully): keep the subdirectories, but the resulting domains do not have the subdirectory path due to the redirect, so links in your layouts should not have subdirectories in the pathname.

Do you have the repository somewhere public? If so we can take a look into it. Getting that working would probably be a very helpful use case for a deep dive into Hugos language abilities.

I’m not sure if I understand what you’re saying here. As I’m using a multihost configuration, each language is generated with its own root, and since I have defaultContentLanguageInSubdir: false, that means my URLs do not have any language subfolder. The problem with that Wowchemy line is that is trying to get wowchemy.js from an URL containing a language subfolder (which doesn’t exist). The only thing I need is, when using a multihost configuration, change the URL so that the language subfolder is not included.

My repo is here and Wowchemy’s repo is here.

So, that is a bug within wowchemy in my opinion. It should not use printf "%s/js/wow-core.js" .Lang, it should use the available language path functions:

1 Like

Thanks. As I said, that line was modified after @bep suggested it as a workaround in another thread (not sure but probably this one). Probably in that case it was being suggested for conventional multilingual sites, but in the case of a multihost configuration it needs fixing. The creator of Wowchemy is already aware of this so hopefully he’ll be able to provide a fix using the available language path functions (which should work for both configurations, multihost or not) :soon:.

1 Like

One thing I still don’t get @davidsneighbour. Why am I not able to reproduce that locally (with hugo server). Is there any way I can test/debug it locally? Thanks!

I can confirm that reverting these changes works in my case (multihost configuration), although not in a conventional multilingual setup (hence the changes introduced). I’ll try next to test the relLangURL approach, which should work in both configurations.