Should `site.DefaultContentLanguage` be readable?

support
1

This returns the unknown field in Interface error. I found another post that seems to say that the defaultContentLanguage config setting is not accessible to templates.

2

No, it should not.

3

Thanks.

My use-case is interfacing with external systems. Specifically: fixing Giscus forum integration in the Hextra theme.

Problem: Giscus crashes when given a requested language/locale doesn’t have a configuration.

My Solution: Check if the site language is supported by Giscus. If not, pass Giscus the default language.

^^ That last part is where accessing DefaultContentLanguage makes sense.

{{/*
  Giscus crashes if the language is not supported.
  https://github.com/giscus/giscus/issues/1358
  List of supported languages: Updated 2024-04-15.
  */}}
{{ $available_langs := slice "ar" "ca" "da" "de" "en" "eo" "es" "fa" "fr" "gr" "he" "hu" "id" "it" "ja" "kh" "ko" "nl" "pl" "pt" "ro" "ru" "th" "tr" "uk" "uz" "vi" "zh-CN" "zh-TW"}}

// ... set $giscus_lang ...

{{/* 
  Fall back to the default if the language is not supported by Giscus.
  */}}
{{ if not (in $available_langs $giscus_lang) }}
  {{/* $giscus_lang = site.DefaultContentLanguage | default "en" */}}
  {{ $giscus_lang = "en"}}
{{ end }}
4 
{{ .Site.Sites.First.Language.Lang }}

See the last two examples here:

http://localhost:1313/methods/site/sites/

5

I saw that. But I don’t think that will work for me. (?)

en is my default, but I follow the common convention of listing languages in order of two-letter code:

  de:
    languageCode: de-DE
    languageName: Deutsch
    weight: 1
    
  en:
    languageCode: en
    languageName: English
    weight: 2

So the “first” language will not be the default.

6

http://localhost:1313/methods/site/sites/

Returns a collection of all Site objects, one for each language, ordered by default content language then by language weight.

7

Ah hah, thank you: I didn’t realize it has that extra feature.

Which leads to a second issue: for me, making some config values inaccessible doesn’t follow the “principle of least surprise”. The sites workaround kinda does the same thing: it’s a special case, not merely a sorted list.

(I spun my wheels for a while on this, wondering what the error meant.)

Is there an implementation or design reason why the entire Hugo config isn’t accessible?

8

We expose settings as needed. If we open the entire config we are promising a stable API for all config settings… that’s just dumb.

9

@jmooring is right. We often make changes to the configuration, e.g. rename config options, make bool flags into structs when we figure out we need more settings for a feature. It’s fairly straight forward to maintain backwards compatibility for these changes. If we exposed the entire config to the users, that would be impossible, and we could just as well close down the project.