Creating 'static' content that uses partials

On the intro page, Last revision: February 20, 2016, I do not see anything that explains this behavior.

I just pointed to “the documentation”, you would have to look it up yourself.

To sum up:

  1. Files in /layout are layout files, chosen by some rules by Hugo to render content. Putting static files in here is very unusual, and you should know the whats.
  2. HTML files in /static … is static, so what you put in the file is what gets published
  3. HTML files in /content:
    – if it has front matter (even only empty), it gets rendered as a content file with layout file, partials, shortcodes etc.
    – if it does not have front matter, it behaves as it was placed in /static
4 Likes

Can you please share your suggestions for multi language static landing pages? Right now I didn’t find an easy way to create a simple static html landing with easy supported translations. Example (which does not work now):

config.yaml
content/index.md
content/features.md
content/contact.md
i18n/en.yaml
i18n/ru.yaml
layouts/index.html
layouts/_default/single.html
layouts/partial/header.html
layouts/partial/footer.html

The problem here is that to make it work I need to create duplicates of content (index.ru.md, features.ru.md and contact.ru.md with complex html code which will be duplicated).
It also splits translations into different pieces (i18n folder + content folder) and makes translators job much harder (instead of translating one en.yaml file they need to copy/paste and translate every content file).

I suggest you put all the content into the i18n files and use the markdownify func to render the strings.

1 Like

But using your recommended approach I still need to create at least empty content/pagename.{language code}.md files.
And if I want to keep page titles translations in i18n/* files then I need to ignore the title in md file (probably, put a translation id there).

Yes, the world isn’t always perfect, but I don’t see the problem …?

For simple landing sites with every unique page (no similar “news” or “posts” content types) it’s much easier and convenient to have everything in one html page:

  • partials to include similar pieces of html
  • translation support (insert ids or default English text into the html and use translations from external i18n folder)
  • automatic generation of separate language pages (e.g. /en/page and /ru/page) if different translations are present in i18n (and used in the content source page, of course).

It will make hugo even more useful and easier for newbies.

I suppose it can be done relatively easy by having special extension for /content/ files, like /content/about.multilang or /content/about.html.

I suspect it would make Hugo into “some other product”, and I’m not sure about the “newbies” part. I think I understand what you’re talking about, but It is not on my list of things that I want to do in the near future, so any implementation/maintenance of such a feature will have to come from someone else.

There is another non-intuitive issue. If I create two content files:

content/test.md
content/test.ru.md

The following locations do not work:

layouts/test.html
layouts/test/index.html
layouts/test/single.html
layouts/_default/test.html
layouts/section/test.html

Hugo always uses template from _default/single.html. I suppose it would be intuitive to use layouts/test.html (like layouts/index.html).

Of course, the following works (but not very convenient):

content/test/index.md
content/test/index.ru.md
layouts/section/test.html

You have your intuition fixed strongly into your site model, which isn’t the main “Hugo use case”. There are no unambiguous cases on your list, i.e. no cases that, according to some other intuition, could be a section template, a taxonomy list template, …

Let’s summarize: hugo isn’t a convenient tool for simple multi-language landing web sites, because some additional and non-intuitive steps are necessary.

That is your wording. My conclusion is this: Hugo’s support for landing type of sites could be improved, but that will have to happen without messing with the main use case, and – in short term – will have to be implemented/maintained by someone other than me.

1 Like

No progress on that? So what the correct approach of creating static pages in Hugo in 2018?

4 Likes