Allow "smart merging of config" for language specific configs.

[cmpute]

Choosing how the config is merged between user config and theme config is supported by #8633, but the merge between language specific config and base config seems to be not supported.

If I have a theme config

[params.comments]
color = "aaa"
title = "xxx"

then a language specific config

[[language.en]]
[language.en.params.comments]
title = "yyy"

then the color config will not be merged into the final config of that language. Maybe it's feasible but just I don't know how to.

[jmooring]

I think the current behavior is correct, and it makes sense to me. A language key has greater specificity than a root key (similar to the way CSS rules work). You can see how this works, even without a theme.

Without a language params table:

[params.comments]
title = 'root'

{{ site.Params.comments }} --> map[title:root]

With a language params table, but without any key/value pairs:

[params.comments]
title = 'root'

[languages.en.params.comments]

{{ site.Params.comments }} --> map[]

With a populated language params table:

[params.comments]
title = 'root'

[languages.en.params.comments]
title = 'en'

{{ site.Params.comments }} --> map[title:en]

[cmpute]

I understand that language config has higher priority than the normal config. To make it clearer, what I would like to see is the ability to set color = "aaa" for language en as well if I have the following lines in the config file:

[params.comments]
color = "aaa"
title = "xxx"
[[language.en]]
[language.en.params.comments]
title = "yyy"

In the current behavior, the color setting will just be discarded instead of being merged. So {{ site.Params.comments.color }} is empty. It will be great if we can also support a _merge option to opt-in the deep merging behavior.

[istr]

Might be related to #10208.

For both mediaTypes and outputFormats there is code in place to explicitly merge the language configuration with highest priority, see

hugo/hugolib/site.go

Line 443 in c4f3a46

// Add language last, if set, so it gets precedence.

But might be unrelated as well, as there is special handling for language based configuration in the merge logic:

hugo/config/defaultConfigProvider.go

Line 234 in c4f3a46

// Languages is currently a special case.

[bep]

@cmpute I agree that we should do this. As @istr has pointed out, the probable reason why this isn't working as you expect today is that we the params language merging isn't currently a part of the "total config merge", but a shallow merge done when you use this for a given language. I have a branch where I'm currently consolidating all config into one struct (mostly for documentation purposes), but it should also allow me to improve on this.

[CXwudi]

Huge thanks for solving this. Now I am ready to significant simplify my dual-language blog config files 😄

[istr]

Yes, thank you @bep . The rewrite / consolidation in 241b21b is really huge and a great step forwards.

[bep]

@istr thanks; fun story: Sunday when I was almost done I thought, I'm going to run some benchmarks just to make sure I haven't messed up ... Turned out everything was about 20% slower and more memory hungry. It, of course, had a simple explanation (reparsing of the Go templates for each site), but it was a moment there where I almost threw in the towel :-)

[istr]

a moment there where I almost threw in the towel

Oh yes, this kind of moment. I know it only too well...

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.