Multilingual branch merged into master

I know many have waited for this, and now it is merged into master.

This is a fairly big change in Hugo, more than 50 commits, and while it is also my best tested contribution to date, I suspect you will find some quirks while taking it for a spin.

So please do and report back.

Big credits to @abourget for laying the foundation for this great new feature.

It isn’t in a Hugo release yet, so you’ll have to build it yourself (it’s simple).

Doc about this feature can be found here:

https://github.com/spf13/hugo/blob/master/docs/content/content/multilingual.md

5 Likes

Thanks and kudos for taking the last mile to finish this long awaited feature. I created a small sample site to test this feature and I might noticed a bug. Maybe your are able to reprocude it.

  1. Let’s say I want to translate the string Featured in. Inside the template I replace the string with {{ i18n "featured-in" }}.

  2. Within i18n/en.yaml I add the id featured-in:

- id: featured-in
  translation: Featured in

Now, Hugo recognizes this change and reloads the page. But instead of displaying the actual translation Hugo shows me the id of the string (featured-in). I’ve have to manually restart the server. After manually reloading the website as well I see the expected translation.

I cannot reproduce this, and I doubt this is a platform issue (I’m on Mac) I just added a commit that makes it more clear in the returned string that it is a placeholder when no translation could be found (for the language or the default).

To check if there is a concurrency/order issue: What happens if you do another random change to a file?

This time I used a the string for the comment section for a post. I added the template function as well as the id + translation. Now, I changed the content of the post. A rebuild happens but your new indicator is still visible. I changed the translation file as well to enforce a rebuid - but with no success.

PS: I use (Manjaro) Linux on my maschine in case this is a platform issue and somebody wants to try it on their own.

Do you have this project on GitHub for others to test?

OK, I have now tested this on Ubuntu 16.04, and this all works as expected there, too. Which means you must do something “special” or there is something unusual with Manjaro … A good start would be if you could add a small reproduce repo with exact steps. Then I can test that on Ubuntu and see.

My observations are based on the demo repository that I linked below. It contains a theme that I try to release with the next version of Hugo as first theme with i18n support.

Today, I tested thus feature with a much simpler setup with just a few words to translate. Here it worked as expected. The id’s were replaced immediately with the translations once they were added on the next live-reload.

However, maybe it’s something special about my local setup. You can find the demo setup of the theme here. The instructions a listed in the README.

Yes, I can reproduce that on OSX now, and I have a suspicion, will investigate and fix. Thanks for the heads up:

1 Like

I choose the translation example for a reason: would it make sense to add a LanguageName field to Hugo?

The reason is that users might want to preserve short url prefixes like en/ or de/. But instead of showing this shortcuts in the “language toggle” I would like to print the full language name “English” and “Deutsch”.

Proposal for the config file:

[languages.en]
     weight = 0
     LanguageName = "English"

[languages.de]
     weight = 10
     LanguageName = "Deutsch"

Yes, that is a good idea … but it should be named … Name.

I have pushed a fix for your problem. Seems there were some issues with reload in themes. I will add some tests another day, but it should work.

1 Like

Can menus be defined for each language independently? Let’s say I want to link the homepage. The English menu should contain a link called “Home”, the German menu one called “Startseite”.

I added the menu entries to my test setup. But the links aren’t shown in both translations.

It should, but I guess someone forgot …

I fixed your two issues (languageName and menus).

Thanks, the fixes work great.

But I’ve found another issue with the template func absLangURL. I use it to link menu items with the correct language prefix in the url.

In the German version / links as expected to /de. But I if I add links to content pages via their frontmatter in the menu (look at the about page) the language prefix is added twice.

The menu entry for the German about page links to /de/de/about instead of /de/about

Furthermore, absLangURL has no effect on .Site.BaseURL. The site name in the header should link to the homepage. But the German version still links to / instead of /de.

It would also be nice if I don’t have to convert the base url into a string before piping it to absLangURL.

Please file issues at GH.