`.Resources.GetMatch` issue in 0.123

On a multilingual site, I can have, say, index.md, index.en.md, and mydata.json in the same page leaf (English is not the primary language here). It works as expected: the data from JSON can be used in both languages (.Resources.GetMatch, then unmarshal).

However, if I remove index.md (i.e. there’s no page for default language in the bundle), .Resources.GetMatch gets nil for the other language, even though the actual resource file is there.

Looks like a bug to me. 0.122.0 works as expected (i.e. does not require default language to be present in the bundle for .Resources.GetMatch in other languages to work).

This is expected. The resource, without a language identifier, is associated with the default content language. Since you don’t publish the page in the default content language, the resource is not published.

If you only have index.en.md, rename the resource to mydata.en.json.

There are a couple of related issues/proposals, which will probably not be addressed:

Are you saying that the same goes for images, etc.?

I mean, how come image.jpg is language-wildcard, but data.json is not?

The same goes for images. And image.jpg is NOT a wild card. Without a lang identifier, it is tied to the default content language in the same way that index.md is tied to the default content language.

But that breaks the very basis of how Hugo’s multilingual feature works, doesn’t it?

“If a string does not have a translation for the current language, Hugo will use the value from the default language.”

The same was true for resources up until and including 0.122, and that was the logical way to do things.

Of course, Hugo doesn’t use resources that aren’t addressed in pages. But, in this case, the resource is explicitly addressed.

And that is why https://github.com/gohugoio/hugo/issues/12107 is still an open issue.

To summarize, if a resource is not language specific it is tied to the default content language, and if content in the default content language is not published, neither will the resource, so it cannot be “shared”.

Translation tables are obviously a bit different, because they are independent of content.

Yes, I’ve read that. I understand how it works. What I’m saying is that it’s the whole logic that’s broken here.

“No string in the language → fallback to default language → fallback to empty”, that’s how the multilingual Hugo works.

“No resource in the language → well, no resource it is”, that’s what 0.123 is doing in this case. Yes, there’s no page in default language, but the resource is there, it is provided, it is explicitly called.

Please respectfully make your case by commenting on the issue referenced above.

1 Like

In the interest of tracking forum topics tagged with v0-123-x that are not associated with a GitHub issue, I am marking this topic resolved.

Ref: https://github.com/gohugoio/hugo/issues/12107

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.