Can’t evaluate field languageCode in type interface {}

I’ve been tasked to transfer a wordpress site, well out of wordpress, but since I’ll have to edit, I’ve decided to go at it the hard way and translate it into hugo.
Fun stuff. It’s the first time I deal with multilangual features, among other things.
But I spent so much time with my own config that I lost track of hugo’s default behavior.
I chose this tree:

 ├──􀀂  docs 
 │  ├──􀇱 
 │  └──􀇱 
 └──􀀂  glossaire

I get an endless list of
for writing things like

Error: error building site: render: failed to render pages: render of “page” failed: “/home/drm/Psychototal_hugo/layouts/_default/baseof.html:13:38”: execute of template failed: template: _default/single.html:13:38: executing “_default/single.html” at : can’t evaluate field languageCode in type interface {}

{{site.languageCode}}. Yes we normally surround them with if .Page or whatever. But it’s a language parameter, not a page’s. So what’s the problem ?

Entire baseof {.Title}} - {{.Params.subtitle}} {{ range .Translations}} {{end}} {{- with .Page.Params.images -}} {{ $resource := (resources.Get (index . 0)).RelPermalink}} {{- end }}

{{ range .AllTranslations }}

{{ end }}
{{ partial "docs/menu-hugo" site.Menus.TopMenu}} {{ range site.Home.AllTranslations }} ############## A VOIR: QUELLES SONT CES CLASSES ? différence entre page / page accueil ?
  • {{ . }}
  • {{end}}
    {{ block "main" .}}

    {{ .Title }}

    {{ site.Home.Permalink}} {{ time.Year }}

    You need to use LanguageCode (upper case first character).

    Gosh… I swear, sometimes the code is case-sensitive, sometimes it’s not ! When will it be consistently one or the other ? Is it the wish not to break legacy code ?
    At least I got the site vs .Site, but it’s still quite bad.

    • Hugo’s Go API is always on the form site.LanguageCode (which is how Go marks fields and methods as exported)
    • Hugo’s .Params are case insensitive.
    • Hugo’s template funcs aliases starts out with lower case, but their fully qualified version is in line with the first, e.g where vs collections.Where.

    Thanks for clarifying it. I found it always quite irritating. At least, there appears to be a system to it.

    Thanks too. It is still irritating and needlessly inconsistent though, in the sense that it would help everyone if Params (since I assume go’s api can’t be changed) were case-sensitive, to keep in line with the former. And the laslt rule, damn… Why is where different from collections.Where when they call on the same function ?