-
-
Notifications
You must be signed in to change notification settings - Fork 7.5k
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
Comments
Yes, we have several case issues that needs a proper solution. |
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
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
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. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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. Solanguages.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:
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:
and this shortcode:
which will generate this result:
The text was updated successfully, but these errors were encountered: