"i18n not initialized" using new Multilingual feature

I know that the multilingual feature has just been merged and isn’t part of an official release yet, but I wanted to give it a shot and test it out.

I’ve installed the master branch from source and tested out with an updated config as described in the documentation.

    weight = 1
    title = "English"

    weight = 2
    title = "Deutsch"

First, this works well in the sense that if I add /de to my base url, I get the title translated.

Now I wanted to try the translation of strings but couldn’t get it to work.

Here is the setup I have:

  1. at the root of my project, I have a /i18n folder which contains 2 files with the following content

     # i18n/en-US.yaml
     - id: nav_home
       translation: "Home"
     # i18n/de.yaml
     - id: nav_home
       translation: "Startseite"
  2. I have tried to place the {{ i18n "nav_home" }} in the index.html page as well as in a template (in layouts folder) however I get the following error output from the Hugo server

ERROR: 2016/09/08 07:52:23 general.go:212: Error while rendering homepage: template: index.html:18:4: executing "index.html" at <i18n "nav_home">: error calling i18n: i18n not initialized, have you configured everything properly?

I was wondering if I have missed an option to configure/initialize i18n?

Thanks for testing this. I and others have tested this pretty intensively, but I’m not surprised if there are corner cases/issues.

Your config looks fine, the only thing I see that should work, but … Could you try to rename the en-US.yaml to en.yaml?

I will check this case once I get back from my trip abroad.

OK, I believe I see what is happening here. We might get some clever RFC 5646 inheritance support in the future, but the current behavior is this:

For your site with language en it looks for a i81n file with that base name. If a language file doesn’t exist for a given language code, it tries to fall back to the DefaultLanugageCode (en if not set). In your case the language in the i18n is more specific than the site definition and there is also no default file to fall back on.

@abourget may have some thoughts on this, but currently en-US and en-BR (or whatever) must be considered as two totally separate languages.

I’m not sure if we should of how we could improve this, but I’m open to suggestions.

Thanks for the tip @bep, it does work now with the en.yaml file.

If you are going to update the documentation, there is a small typo in row 109 of multilingual.md :wink:
i8n -> i18n

Should I open a bug in GitHub to track this issue and add a reference here?

It would save me some work if you could just “edit it in place” and GitHub will create a pull request for it. I will also make the error message mentioned above more clear as what to expect.

Done - https://github.com/spf13/hugo/pull/2416