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

Inconsistency between .Translations and .Resources in a multilingual multi-host website #12333

Open
ov opened this issue Apr 2, 2024 · 4 comments

Comments

@ov
Copy link

ov commented Apr 2, 2024

See #12320 for the beginning of the discussion.

For a multilingual multi-host site the page resources are kept shared even if the pages are not considered the translations of each other. This started in 0.123 and is still a problem in the latest version.

See the repository here: https://github.com/ov/hugo-bundle-issue

It has two translations placed into different folders. Each translation has two folders bundled and not-bundled. The difference is that the pages in not-bundled have translationKey defined to be different for both languages, so they don't think they are the translations. The bundled pages don't have that key explicitly set, so are considered the translations of each other.

The code in layout/_default is the same for list and single and shows the translations and the resources of the page.

Now if you build a site and check the /bundled/ pages for both translations, you'll notice that both pages see each other as translations and have their resources shared. That's the expected behaviour of a page bundle, that's fine.

Now check the /not-bundled/ pages of both translations. You'll find that they don't see each other as translations (due to the different translationKey), but still share the resources. You can also see that all the resources are present in public/<lang>/not-bundled/ folders.

Expected behaviour: if the pages don't see each other as translations, their resources should not be shared, copied and mentioned in .Resources

Actual behaviour: the resources are shared, copied and mentioned, which looks inconsistent.

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

$ hugo version
hugo v0.124.1+extended darwin/arm64 BuildDate=unknown

Does this issue reproduce with the latest release?

yes

@jmooring
Copy link
Member

jmooring commented Apr 2, 2024

Before I look at this, if you haven't already done so, please build from HEAD and retest... #12320 was fixed this morning by #12331.

@ov
Copy link
Author

ov commented Apr 2, 2024

I've just tried it with:

hugo v0.125.0-DEV+extended darwin/arm64 BuildDate=unknown

and the problem is still there. It is somewhat different to #12320, though.

@bep bep added this to the v0.125.0 milestone Apr 3, 2024
@jmooring
Copy link
Member

jmooring commented Apr 4, 2024

This isn't a regression... v0.122.0 and v0.124.1 behave identically.

config

defaultContentLanguage = 'en'
defaultContentLanguageInSubdir = true

[languages.en]
baseURL = "https://en.example.org"
contentDir = "content/en"

[languages.fr]
baseURL = "https://fr.example.org"
contentDir = "content/fr"

content

content/
├── en/
│   └── p1/
│       ├── a.txt
│       └── index.md  <-- translationKey: en-p1
└── fr/
    └── p1/
        ├── b.txt
        └── index.md  <-- translationKey: fr-p1

published (v0.122.0)

public/
├── en/
│   └── p1/
│       ├── a.txt
│       ├── b.txt
│       └── index.html
└── fr/
    └── p1/
        ├── a.txt
        ├── b.txt
        └── index.html

published (v0.124.1) (same as above)

public/
├── en/
│   └── p1/
│       ├── a.txt
│       ├── b.txt
│       └── index.html
└── fr/
    └── p1/
        ├── a.txt
        ├── b.txt
        └── index.html

expected

public/
├── en/
│   └── p1/
│       ├── a.txt
│       └── index.html
└── fr/
    └── p1/
        ├── b.txt
        └── index.html

test site

git clone --single-branch -b hugo-github-issue-12333 https://github.com/jmooring/hugo-testing hugo-github-issue-12333
cd hugo-github-issue-12333
rm -rf public && hugo && tree public

test case

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

	files := `
-- hugo.toml --
disableKinds = ['home','section','rss','sitemap','taxonomy','term']
defaultContentLanguage = 'en'
defaultContentLanguageInSubdir = true

[languages.en]
baseURL = "https://en.example.org"
contentDir = "content/en"

[languages.fr]
baseURL = "https://fr.example.org"
contentDir = "content/fr"
-- layouts/_default/single.html --
{{ .Title }}
-- content/en/p1/index.md --
---
title: p1
translationKey: en-p1
---
-- content/fr/p1/index.md --
---
title: p1
translationKey: fr-p1
---
-- content/en/p1/a.txt --
a
-- content/fr/p1/b.txt --
b
`

	b := hugolib.Test(t, files)

	b.AssertFileExists("public/en/p1/a.txt", true)
	b.AssertFileExists("public/en/p1/b.txt", false) // failing test

	b.AssertFileExists("public/fr/p1/b.txt", true)
	b.AssertFileExists("public/fr/p1/a.txt", false) // failing test
}

@ov
Copy link
Author

ov commented Apr 5, 2024

After double-checking that, I agree that this might not be a regression.

I used to have a few resources belonging to the home directory in v0.122 which were not shared or bundled even without translationKey provided. That just worked (I mentioned that in #12320). However, after checking the bundling rules it seems that the behaviour was incorrect in v0.122.

You fixed that in v0.123 and the resources started getting bundled and copied which was not what I needed, so I tried to "unlink" them by providing different translationKey elements. This didn't help, so I filed the report. I still think this is an inconsistency bug, but instead of regression this looks like a partially working fix or so.

Let me know if you want a repo with that setup for v0.122. It is a little unrelated to this specific issue, so I didn't provide that initially.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants