Finish the multilingual feature #2303

Implements: * support to render: * content/post/whatever.en.md to /en/2015/12/22/whatever/index.html * content/post/whatever.fr.md to /fr/2015/12/22/whatever/index.html * gets enabled when `Multilingual:` is specified in config. * support having language switchers in templates, that know where the translated page is (with .Page.Translations) (when you're on /en/about/, you can have a "Francais" link pointing to /fr/a-propos/) * all translations are in the `.Page.Translations` map, including the current one. * easily tweak themes to support Multilingual mode * renders in a single swift, no need for two config files. Adds a couple of variables useful for multilingual sites Adds documentation (content/multilingual.md) Added language prefixing for all URL generation/permalinking see in the code base. Implements i18n. Leverages the great github.com/nicksnyder/go-i18n lib.. thanks Nick. * Adds "i18n" and "T" template functions..

Will revisit Node later.

Having many *main* sites doesn't make much sense.

Also add all translations, including the current, to the slice. We filter later.

And a Hugo global variable which contains the site under build. This is really needed to get some level of control of the "multiple languages" in play. There are still work related to this scattered around, but that will come. With this commit, the multilingual feature is starting to work.

Setting the language to use when loading the language bundles just doesn't work. The template system is unfortanetely a global, and the last languate processed won ...

This commit also consolidates URLs on Node vs Page, so now .Permalink should be interoperable. Note that this implementations should be fairly short-livded, waiting for #2297, but the API should be stable.

It will get more involved in the build process in a minute. See #2309

See #2309

Work In Progress! This commit makes a rework of the build and rebuild process to better suit a multi-site setup. This also includes a complete overhaul of the site tests. Previous these were a messy mix that were testing just small parts of the build chain, some of it testing code-paths not even used in "real life". Now all tests that depends on a built site follows the same and real production code path. See #2309 Closes #2211 Closes #477 Closes #1744

This is needed to make shortcode users happy with the new multilanguage support, but it will also solve many other related posts about "stuff not available in the shortcode". We will have to revisit this re the handler chain at some point, but that will be easier now as the integration test story has improved so much. As part of this commit, the site-building tests in page_test.go is refreshed, they now tests for all the rendering engines (when available), and all of them now uses the same code-path as used in production. Fixes #1229 Fixes #2323 Fixes ##1076

And in the same go adjusted some minor parts of the language API: Add LanguagePrefix alias to Node and rename the Multilingual config section to Languages. See #2309

See #2312 See #2309

See #2309

This is needed to verify #2309, but it closes a big hole in Hugo's automated tests. The loading of the config is now moved to `hugolib` and the same default settings are now used in production and tests. As Viper now uses Afero as its filesystem, we now can write fairly complete integration tests with ease. See #2309

See #2312

This commit also unexports some Site methods, making it clear what the external build API really is. See #2312

See #2309

The current "rendering language" is needed outside of Site. This commit moves the Language type to the helpers package, and then used to get correct correct language configuration in the markdownify template func. This commit also adds two new template funcs: relLangURL and absLangURL. See #2309

See #2309

And clean up the test. See #2309

See #2309

Or: some more multilingual TODO-fixes. See #2309

And pull up common member vars like Tmpl and Multilinguage. Or: the final multilingual TODO-fixes. See #2309

Fixes #2312

* Fall back to default language on missing translation file * Add a i18n-warnings build flag * If that flag is set, print a parseable and greppable string on missing translation strings See #2303

See #2312

Makes the templates simpler. See #2309

See #2309

Updates ##2309

In a multi-language setup, before this commit the Node's Translations() method would return some "dummy nodes" that would point to the correct page (Permalink), but would not be the same as the node it points to -- it would not have the translated title etc. The node creation is, however, so mingled with rendering, whihc is too early to have any global state, so the nodes has to be split in a prepare and a render phase. This commits does that with as small a change as possible. This implementation is a temp solution until we fix #2297. Updates #2309

For people having trouble building this. Now `hugo version` should print something like: ``` Hugo Static Site Generator v0.17-MULTILINGUAL BuildDate: 2016-08-10T08:20:36+02:00 ```

Updates #2309

And some other minor fixes from code review. Updates #2309

Updates #2309

So the Permalink gets correct when listing translations. I have also checked the other relevant places to make sure we do not overwrite node values we need later. Pointers can be tricky, but lesson learned is: A copy is cheap. Updates #2309

After a visual inspection to make (pretty) sure it is correct re multiple languages. Updates #2309

We should get rid of these globals, but that is another month.

This commit also refines the partial rebuild logic, to make sure we do not do more work than needed. Updates #2309

Updates #2309

So we can do some benchmarking.

Updates #2309

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Finish the multilingual feature #2303

Finish the multilingual feature #2303

Commits on Aug 20, 2016