Page resource published to wrong path with multilingual multi-site project

[myOmikron]

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

hugo v0.134.0+extended linux/amd64 BuildDate=unknown

Does this issue reproduce with the latest release?

Yes

Description

Hugo creates subdirectories that do not correspond with the structure of the content directory.

Example:

In en-us, the file foobar (linked from each of content/blog/test/index.md and content/blog/test/index.en-US.md) is located on a different subdirectory.

The corresponding HTML output does not reflect that (content of public/en-us/blog/test/index.html):

<p><a href="foobar">foobar</a></p>

Reproduction

Clone https://github.com/myOmikron/hugo-example
Run hugo

[jmooring]

@myOmikron This is obviously a bug, but you can work around it by using a lowercase language identifier when naming your content files.

For example, use index.en-us.md instead of index.en-US.md.

[jmooring]

Failing test:

func TestFoo(t *testing.T) {
	t.Parallel()

	files := `
-- hugo.toml --
defaultContentLanguage = "de-DE"
disableKinds = ['home','section','rss','sitemap','taxonomy','term']
[languages.de-DE]
weight = 1
baseURL = "https://example.de"
[languages.en-US]
weight = 2
baseURL = "https://example.en"
-- layouts/_default/single.html --
{{ T "foo" }}
 -- i18n/de-DE.toml --
foo = 'foo (de-DE)'
 -- i18n/de-US.toml --
foo = 'foo (en-US)'
-- content/p1/a.txt --
a
-- content/p1/index.en-US.md --
---
title: p1 (en-US)
---
-- content/p1/index.md --
---
title: p1 (de-DE)
---
`

	b := hugolib.Test(t, files)

	b.AssertFileContent("public/de-de/p1/index.html", "foo (de-DE)")
	b.AssertFileContent("public/en-us/p1/index.html", "foo (en-US)")

	b.AssertFileExists("public/de-de/p1/a.txt", true)
	b.AssertFileExists("public/en-us/p1/a.txt", true) // failing test
}

The last assertion fails because the page resource is published to public/en-us/p1/p1/a.txt instead
of public/en-us/p1/a.txt.

The test will pass if you rename content/p1/index.en-US.md to content/p1/index.en-us.md.

[myOmikron]

Thanks, the workaround helped by out a lot!

[bep]

I have looked at this, and while the test case above can certainly be made to pass, I don't think we're going down that route, because it will certainly bite us behind later on. This is a lesson learned, I guess: If you have a user define key that you want in a specific format (e.g. lowercase), don't just magically do it, add some validation and have the user correct it.

I think the best route going forward is to add some validation and WARN about a configured lang that's not how Hugo wants it.