Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Language-specific site parameters: location of definition and case-sensitivity #2615

Closed
anma opened this issue Oct 20, 2016 · 2 comments · Fixed by #2717 or #2630
Closed

Language-specific site parameters: location of definition and case-sensitivity #2615

anma opened this issue Oct 20, 2016 · 2 comments · Fixed by #2717 or #2630
Assignees
Milestone

Comments

@anma
Copy link

anma commented Oct 20, 2016

While playing around with Hugo's new multilingual mode, I've encountered the following problems:

  • According to the example configuration in the Multilingual Mode documentation language-specific parameters have to be nested under params. However, Hugo merges all variables in a language definition into the global site parameters. So languages.en.params.subtitle actually ends up as .Site.Params.params.subtitle.

  • The documentation states that "all Params are only accessible using all lowercase characters", but this is not enforced by the implementation:

    • Global parameter definitions preserve case.
    • Language-specific parameter definitions are mapped to lower-case.
    • Parameter access is always case-sensitive.

    So accidently using upper-case parameter names in your configuration (for example, you have not read the documentation) may give you a hard time. :-)

To see for yourself, you can use the following configuration:

baseurl = "http://localhost"
title = "Multilingual Demo"

defaultContentLanguage = "en"

aparam = "/AParam"
anotherParam = "/AnotherParam"

[Params]
aparam = "/params/AParam"
anotherParam = "/params/AnotherParam"
globalonly = "/globalonly"
globalOnly = "/GlobalOnly"

[Languages]
  [Languages.de]
  weight = 1
  languageName = "Deutsch"
  aparam = "/de/AParam"
  anotherParam = "/de/AnotherParam"
  langOnly = "/de/langOnly"

[Languages.de.Params]
aparam = "/de/params/AParam"
anotherParam = "/de/params/AnotherParam"

  [Languages.en]
  weight = 2
  languageName = "English"
  aparam = "/en/AParam"
  anotherParam = "/en/AnotherParam"
  langOnly = "/en/langOnly"

[Languages.en.Params]
aparam = "/en/params/AParam"
anotherParam = "/en/params/AnotherParam"

and this shortcode:

<pre>
globalonly = {{ .Site.Params.globalonly }}
globalOnly = {{ .Site.Params.globalOnly }}  
langOnly = {{ .Site.Params.langOnly }}
langonly = {{ .Site.Params.langonly }}
aparam = {{ .Site.Params.aparam }} 
aParam = {{ .Site.Params.aParam }} 
anotherparam = {{ .Site.Params.anotherparam }} 
anotherParam = {{ .Site.Params.anotherParam }}
</pre>

<hr>

<pre>
{{ range $key, $value := .Site.Params }}{{ $key }} = {{ $value }}
{{ end }}
</pre>

which will generate this result:

globalonly = /globalonly    // definition and access are both case-sensitive
globalOnly = /GlobalOnly
langOnly =                  
langonly = /en/langOnly     // language-specific definitions are mapped to lower-case
aparam = /en/AParam         // the definition in language.en, not language.en.params, is used
aParam =  
anotherparam = /en/AnotherParam      // language-specific is mapped to lower-case, ...
anotherParam = /params/AnotherParam  // so the global definition is not overridden 

----

anotherParam = /params/AnotherParam
anotherparam = /en/AnotherParam
aparam = /en/AParam
globalOnly = /GlobalOnly   
globalonly = /globalonly
langonly = /en/langOnly
languagename = English
params = map[anotherParam:/en/params/AnotherParam aparam:/en/params/AParam]   // language.en.params --> .Site.Params.params
weight = 2
@bep
Copy link
Member

bep commented Oct 20, 2016

Yes, we have several case issues that needs a proper solution.

bep added a commit that referenced this issue Oct 24, 2016
@bep bep self-assigned this Oct 24, 2016
@bep bep added this to the v0.18 milestone Oct 24, 2016
@bep bep added the Bug label Oct 24, 2016
bep added a commit to bep/hugo that referenced this issue Nov 22, 2016
There are currently several Params and case related issues floating around in Hugo.

This is very confusing for users and one of the most common support questions on the forum.

And while there have been done some great leg work in Viper etc., this is of limited value since this and similar doesn't work:

`Params.myCamelCasedParam`

Hugo has control over all the template method invocations, and can take care of all the lower-casing of the map lookup keys.

But that doesn't help with direct template lookups of type `Site.Params.TWITTER_CONFIG.USER_ID`.

This commit solves that by doing some carefully crafted modifications of the templates' AST -- lowercasing the params keys.

This is low-level work, but it's not like the template API wil change -- and this is important enough to defend such "bit fiddling".

Tests are added for all the template engines: Go templates, Ace and Amber.

Fixes gohugoio#2615
Fixes gohugoio#1129
Fixes gohugoio#2590
@bep bep closed this as completed in #2630 Nov 22, 2016
bep added a commit that referenced this issue Nov 22, 2016
There are currently several Params and case related issues floating around in Hugo.

This is very confusing for users and one of the most common support questions on the forum.

And while there have been done some great leg work in Viper etc., this is of limited value since this and similar doesn't work:

`Params.myCamelCasedParam`

Hugo has control over all the template method invocations, and can take care of all the lower-casing of the map lookup keys.

But that doesn't help with direct template lookups of type `Site.Params.TWITTER_CONFIG.USER_ID`.

This commit solves that by doing some carefully crafted modifications of the templates' AST -- lowercasing the params keys.

This is low-level work, but it's not like the template API wil change -- and this is important enough to defend such "bit fiddling".

Tests are added for all the template engines: Go templates, Ace and Amber.

Fixes #2615
Fixes #1129
Fixes #2590
bep added a commit to bep/hugo that referenced this issue Nov 22, 2016
There are currently several Params and case related issues floating around in Hugo.

This is very confusing for users and one of the most common support questions on the forum.

And while there have been done some great leg work in Viper etc., this is of limited value since this and similar doesn't work:

`Params.myCamelCasedParam`

Hugo has control over all the template method invocations, and can take care of all the lower-casing of the map lookup keys.

But that doesn't help with direct template lookups of type `Site.Params.TWITTER_CONFIG.USER_ID`.

This commit solves that by doing some carefully crafted modifications of the templates' AST -- lowercasing the params keys.

This is low-level work, but it's not like the template API wil change -- and this is important enough to defend such "bit fiddling".

Tests are added for all the template engines: Go templates, Ace and Amber.

Fixes gohugoio#2615
Fixes gohugoio#1129
Fixes gohugoio#2590
bep added a commit that referenced this issue Nov 22, 2016
There are currently several Params and case related issues floating around in Hugo.

This is very confusing for users and one of the most common support questions on the forum.

And while there have been done some great leg work in Viper etc., this is of limited value since this and similar doesn't work:

`Params.myCamelCasedParam`

Hugo has control over all the template method invocations, and can take care of all the lower-casing of the map lookup keys.

But that doesn't help with direct template lookups of type `Site.Params.TWITTER_CONFIG.USER_ID`.

This commit solves that by doing some carefully crafted modifications of the templates' AST -- lowercasing the params keys.

This is low-level work, but it's not like the template API wil change -- and this is important enough to defend such "bit fiddling".

Tests are added for all the template engines: Go templates, Ace and Amber.

Fixes #2615
Fixes #1129
Fixes #2590
tychoish pushed a commit to tychoish/hugo that referenced this issue Aug 13, 2017
@github-actions
Copy link

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 31, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants