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

Clarify languageCode default in multilingual page #2564

Closed
wants to merge 1 commit into from

Conversation

chalin
Copy link
Contributor

@chalin chalin commented May 10, 2024

According to my tests, languageCode defaults to the active language's language key.

@jmooring
Copy link
Member

jmooring commented May 10, 2024

According to my tests, languageCode defaults to the active language's language key.

I'm not sure what you're referring to, but the opengraph template does this:

{{- with or .Params.locale site.Language.LanguageCode site.Language.Lang }}

So the template defaults to the language key, but .Language.LanguageCode has a default of "".

@chalin
Copy link
Contributor Author

chalin commented May 10, 2024

I have a setup where languageCode isn't explicitly set but .Site.Language.LanguageCode yields the (active) language key value. I can put together a simple repro if you'd like.

@jmooring
Copy link
Member

You're right. It looks like we changed the behavior in v0.112.0 and didn't update the docs.

@chalin
Copy link
Contributor Author

chalin commented May 10, 2024

We can also see this at work in https://github.com/gohugoio/hugo/blob/master/tpl/tplimpl/embedded/templates/alias.html, which uses site.Language.LanguageCode and (at least on my sites), that has the same value as the active language key rather than being "" when not explicitly set.

@jmooring
Copy link
Member

jmooring commented May 10, 2024

This is surprising (sort of)...

languageCode = 'foo'

[languages.en]
# languageCode = 'en-US'

[languages.de]
languageCode = 'de-DE'

The en site returns "en" instead of "foo". Something doesn't seem right here.

The above is true for monolingual sites as well. As soon as you define a language, the languageCode in the root config is ignored.

@jmooring
Copy link
Member

jmooring commented May 10, 2024

@chalin Technically the languageCode config does not have a default value. Instead, the PAGE.Language.LanguageCode and SITE.Language.LanguageCode methods fall back to PAGE.Language.Lang and SITE.Language.Lang respectively.

So I think it would be better to update those method descriptions:

Also, if you wouldn't mind, please update the description of languageCode here:
https://gohugo.io/getting-started/configuration/#languagecode

We should find a way to indicate that this value is ignored if a language key is present (or something to that effect).

And then we should go back through the embedded templates and remove the fallback logic since Hugo handles that with v0.112.0 and later. See gohugoio/hugo#12480 and gohugoio/hugo#12479.

I will fix various example in #2565.

@IUSR
Copy link

IUSR commented May 13, 2024

This is surprising (sort of)...

languageCode = 'foo'

[languages.en]
# languageCode = 'en-US'

[languages.de]
languageCode = 'de-DE'

The en site returns "en" instead of "foo". Something doesn't seem right here.

The above is true for monolingual sites as well. As soon as you define a language, the languageCode in the root config is ignored.

Sorry to hijack the discussion but I just want to confirm the TOML table name for individual languages: is it languages.en or Languages.en with a capital "L"? I spent 30 minutes trying to find the right language code for the non-English language I want to support, as Hugo kept on complaining config value "zh" for defaultContentLanguage does not match any language definition; then I saw some tutorial for earlier version of Hugo using the capitalized "languages" name and gave it a try, and it finally worked. I'm using Hugo version 0.125.7 extended under Arch Linux.

❯ hugo version
hugo v0.125.7+extended linux/amd64 BuildDate=unknown

@jmooring
Copy link
Member

@IUSR Keys are converted to lowercase internally, but you should get in the habit of using the case as shown in the documentation.

Please use the forum (https://discourse.gohugo.io/) for questions and troubleshooting.

jmooring added a commit to jmooring/hugo-docs that referenced this pull request May 13, 2024
Closes gohugoio#2564

Co-authored-by: chalin <chalin@users.noreply.github.com>
@chalin chalin deleted the patch-3 branch May 13, 2024 23:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants