Hugo Bug Report: Language Assignment Failure in Multilingual ContentDir Setup

- Autor: Maciej Lesiak - 3 minutes read - 515 words

What's in this article

What version of Hugo are you using (hugo version)?

hugo v0.148.2-40c3d8233d4b123eff74725e5766fc6272f0a84d+extended linux/amd64 BuildDate=2025-07-27T12:43:24Z VendorInfo=snap:0.148.2

Does this issue reproduce with the latest release?

Yes. I was noticing that bug for last year… tested/debugged on v0.148.2. This appears to be related to GitHub Issue #13881 which affects the same version range and involves similar language assignment failures in multilingual configurations.

Description of the Bug

In a multilingual setup where the default language (pl) resides in the root content/ directory and a secondary language (en) is configured to use a subdirectory (contentDir = "content/en"), the Hugo engine incorrectly assigns the default language parameter to all pages, including those from the secondary language directory.

Diagnostic tests show that for any content file located at content/en/**/*.md, the .Language.Lang variable within templates incorrectly returns pl instead of the expected en. This occurs even if the content’s frontmatter explicitly contains language: "en".

This core issue leads to a cascade failure of language-dependent template functions, most notably .Site.RegularPages.Related and any where clause filtering by .Language.Lang, both of which return mixed-language results. This renders multilingual content filtering impossible with built-in functions.

Steps to Reproduce

  1. Configure hugo.toml for multilingual content:

    • Set the default language (e.g., pl) to use the root content directory (defaultContentLanguageInSubdir = false).
    • Set a secondary language (e.g., en) to use a subdirectory via contentDir = "content/en".
    # hugo.toml
defaultContentLanguage = "pl"
[languages.pl]
  languageName = "Polski"
  weight = 1
  contentDir = "content"
[languages.en]
  languageName = "English"
  weight = 2
  contentDir = "content/en"

  2. Create content files:

    • content/posts/post-1.md (a Polish post with language: "pl" in frontmatter).
    • content/en/posts/post-2.md (an English post with language: "en" in frontmatter).

  3. Add a diagnostic partial to a layout (e.g., layouts/_default/single.html):

    <div style="border: 2px solid red; padding: 10px; margin: 20px;">
    <h3>Debug Info</h3>
    <p>File Path: <strong>{{ .File.Path }}</strong></p>
    <p>Expected Language: (based on path and frontmatter)</p>
    <p>Actual .Language.Lang: <strong>{{ .Language.Lang }}</strong></p>
</div>

  4. Run hugo server and navigate to the English post (/en/posts/post-2/).

Expected Behavior

The diagnostic partial for the English post (content/en/posts/post-2.md) should display:

Actual .Language.Lang: en

Actual Behavior

The diagnostic partial for the English post incorrectly displays:

Actual .Language.Lang: pl

This indicates that the language context is being incorrectly assigned at a fundamental level, breaking multilingual functionality. This behavior is highly similar to GitHub Issue #13881 which documents that language-dependent configuration statements are ignored if not placed at the top of hugo.toml in v0.148.0.

Additional context from related issues:

The issue forces a manual workaround that filters content based on .File.Path instead of the malfunctioning .Language.Lang parameter.

Diagnostic steps attempted:

  • Verified hugo.toml syntax and language configuration
  • Confirmed basic multilingual functionality works (site generates in correct directories)
  • Isolated the problem to template functions that query global page collections
  • TODO: Test moving language configuration to top of hugo.toml (per GitHub Issue #13881)
  • TODO: Test with config.yaml instead of hugo.toml (per discourse findings)