I will update the documentation before the release, but it is described in details here:
This is really interesting if you want to do multihost with multiple languages (or whatever), but the “multiple static dirs” enhancement is really cool on its own.
If you know how to build from source, please take it for a spin on your site!
This falls into the “very good tested category”, but I’m always wary when I make changes that touch file handling and the development server …
Looking forward to it. My install script is still set up to use govendor, and it appears that’s now deprecated? I need to get rid of that and try again, so I will do this tomorrow.
Hi @bep, no problem upgrading hugo and using mage. I started to try this setup on an existing site, but am getting an “index out of range” error, that I am not sure where it is from.
I am using a customized config.toml for this site:
The config.toml and error I’m seeing are in this gist:
And I do have en.toml and ja.toml files in i18n, locally. The ja.toml is not present on the repo but, is present locally.
WARN 2017/11/19 19:43:30 No static directories found to sync
Which means, I guess, that none of your static dirs actually exists? I will fix the “crash”, but it should work if it actually found one or more of the static directories you specified.
OK; I have fixed it now. It was the use of string slices in staticDir. My unit test wasn’t perfect in this area … Now I should have proper tests for this …
ok @bep thanks, after a recompile, that indeed worked!
Now I get:
...
INFO 2017/11/20 05:51:36 syncing static files to /en
INFO 2017/11/20 05:51:36 syncing static files to /ja
...
Built site for language en:
0 draft content
0 future content
0 expired content
35 regular pages created
139 other pages created
0 non-page files copied
0 paginator pages created
135 tags created
Built site for language ja:
0 draft content
0 future content
0 expired content
0 regular pages created
3 other pages created
0 non-page files copied
0 paginator pages created
0 tags created
total in 91 ms
Watching for changes in /Users/rcogley/dev/Hugo-multihost-test/{data,content,i18n,layouts,static_en,static,static_ja}
Serving pages from memory
Running in Fast Render Mode. For full rebuilds on change: hugo server --disableFastRender
Web Server is available at 127.0.0.1:1317 (bind address 127.0.0.1)
Web Server is available at 127.0.0.1:1318 (bind address 127.0.0.1)
Press Ctrl+C to stop
The hugo server command even increments up from the port I specified as --port=1317.
Ok, it appears to basically be working! At first I was getting lots of 404’s for some reason, but it seems things were getting cached. Now it is ok after some clearing of caches and restarts and gnashing of teeth.
I was able to make a translation on the Japan side of one file, by copying it and renaming to whatever.ja.md. Things appear to be OK so far, even with the same slug in both. When I switch ports, I can see the Japanese I added to the Japanese file. So, it’s as expected.
Questions:
I did a hugo to generate the files in public, and, noticed that an alias I have, is under a year folder, at the same level as my language folders. I pasted output of the tree command into the gist so you can see @bep. When I deploy, is there anything I need to do with this, or is it something that still needs to be incorporated?
Also, where is hugo server putting its files that are served to localhost:NNNN, if you don’t tell it where? I did not see anything in tmp.
Thanks for your attention and help, although I’m not expecting anything since it is probably quite late in Europe.
For “regular multilingual” we kept the aliases (and also the similar url front matter field) as a literal value that we use as is. There is an ambiguity in the guessing of “should we add a language code to this path?”. It adds unwanted restrictions.
But the multihost case is different in this area. You would never want any files in the root folder, so we need to handle this slightly differently. I will fix this tomorrow.