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 · 1 comment

Comments

Projects
None yet
2 participants
@anma

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

This comment has been minimized.

Show comment
Hide comment
@bep

bep Oct 20, 2016

Member

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

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

Fix case issues with Params
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 bep closed this in #2630 Nov 22, 2016

bep added a commit that referenced this issue Nov 22, 2016

Fix case issues with Params
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

Fix case issues with Params
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 that referenced this issue Nov 22, 2016

Fix case issues with Params
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 added a commit to tychoish/hugo that referenced this issue Aug 13, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment