The recent update to allow custom 404 pages in localhost only shows the default language’s 404 page in translated sections. Is this by design?
The 404 redirects are working as desired with this site configuration:
config/_default/config.toml
baseURL = 'https://example.org/'
title = 'Hugo Forum Topic #40568'
defaultContentLanguageInSubdir = true
[languages.en]
contentDir = 'content/en'
languageCode = 'en-US'
languageName = 'English'
weight = 1
[languages.es]
contentDir = 'content/es'
languageCode = 'es-ES'
languageName = 'Espanol'
weight = 2
config/development/server.toml
[[redirects]]
from = '/en/**'
to = '/en/404.html'
status = 404
[[redirects]]
from = '/es/**'
to = '/es/404.html'
status = 404
Try it:
git clone --single-branch -b hugo-forum-topic-40568 https://github.com/jmooring/hugo-testing hugo-forum-topic-40568
cd hugo-forum-topic-40568
hugo server
1 Like
I don’t use this because the default language is at the root (hence no language prefix in URL)
Is this required for the redirect option to work per language?
Then change config/development/server.toml to
[[redirects]]
from = '/es/**'
to = '/es/404.html'
status = 404
[[redirects]] # Default lang, should be last.
from = '/**'
to = '/404.html'
status = 404
4 Likes
I am getting the “Page Not Found” page for the translating language, even with your example site above, not the translated page. I am translating the 404 page with i18n. (This works with Cloudflare Pages).
Please provide an minimal failing example. The example I provided behaves as expected.
Not on my end. Even clicking the link from the es page returns “page not found”
Sorry, but I am unable to reproduce the problem. I you need further assistance, please provide a complete, failing example.
As I said, I cloned your example, and I have not done any modifications to it.
I am cloning your example above and the screenshot is from it. So, technically, while it works for you, it fails for me.
$ hugo env
hugo v0.103.0-beebf2afb09a7be36cf12bdec8a99ae9286504e2+extended windows/amd64 BuildDate=2022-09-15T11:23:56Z VendorInfo=gohugoio
GOOS="windows"
GOARCH="amd64"
GOVERSION="go1.19"
Oh. Why is the font family and background color different?
I use dark mode on windows with Segoe UI font. I was showing you the URL for the broken link you have in your example. I even tested in three different browsers.
$ hugo serve
port 1313 already in use, attempting to use an available port
Start building sites …
hugo v0.103.0-beebf2afb09a7be36cf12bdec8a99ae9286504e2+extended windows/amd64 BuildDate=2022-09-15T11:23:56Z VendorInfo=gohugoio
| EN | ES
-------------------+----+-----
Pages | 7 | 7
Paginator pages | 0 | 0
Non-page files | 0 | 0
Static files | 0 | 0
Processed images | 0 | 0
Aliases | 1 | 0
Sitemaps | 2 | 1
Cleaned | 0 | 0
Built in 17 ms
Watching for changes in C:\Users\tut\Documents\hugo\hugo-forum-topic-40568\{archetypes,content,layouts}
Watching for config changes in C:\Users\tut\Documents\hugo\hugo-forum-topic-40568\config\_default, C:\Users\tut\Documents\hugo\hugo-forum-topic-40568\config\development
Environment: "development"
Serving pages from memory
Running in Fast Render Mode. For full rebuilds on change: hugo server --disableFastRender
Web Server is available at http://localhost:58537/ (bind address 127.0.0.1)
Press Ctrl+C to stop
Also, this is very strange that Hugo is building with an old date (15th while we are on the 19th). Is that supposed to happen?
That’s when the hugo binary was compiled. It is not the date that your site was built.
Maybe the problem is specific to Windows. I will have another look later today.
Good to know. It clears some confusions I had.
Could be. Coz I have run over 20 hugo server commands since I opened this topic to test this, with three different repos, and all failed.
Yes, the problem you are experiencing is specific to Windows. I’ll log a bug when I can come up with a simpler test case.
Alright. Thanks for taking the time to test it out.
Awesome! I bookmarked it. (I use GitLab). Though defaultContentLanguageInSubdir = true is not set in my repo as indicated earlier. Unless that has no bearing on the bug.
Yeah, that one.
Alright.