I am translating some pages and for those with one tag only, Hugo returns no related pages. My expectation was the indices should fall back to the secondary one? Configure related content
[related]
includeNewer = true
threshold = 80
toLower = true
[[related.indices]]
name = 'tags'
weight = 100
[[related.indices]]
name = 'categories'
weight = 80
Hugo’s related content does not use a “fallback” logic.
It uses a score system. Each index (tags, categories, etc) has points when values overlap. If a page’s total score is above the threshold, it is related.
If a page has a unique tag, and its category is missing or also unique, then it will get a score of 0, so no related pages to show.
Also a translated tag or category counts as a different value, even if it has the same meaning. So translations will not match unless they share the exact same string.
As I said, the weight is for tags, then categories. So, if Hugo finds no tags, it should fall back to pages in the same category. This is not happening in my case. cc @jmooring
Lets say Page A your translated page and Page B a page you expect to be related:
I think you are missing my point.
foo and a tag bar. All posts have category foo but only a few in foo have the tag bar.The translated page with tag bar what category has? It is foo?
If the page has the tag but not the category, Hugo will never use foo, it only scores actual overlaps.
I know where the problem is.
{{ $n := (site.Params.relatedPostsNum | int) | default 6 }}
{{ $p := site.Regular.Related . }}
{{ range collections.D (hash.FNV32a (print $.Path time.Now.YearDay)) $n ($pc | len) }}
{{ with (index $p .) }}
<li><a href="{{ .RelPermalink }}">{{ .LinkTitle }}</a></li>
{{ end }}
{{ end }}
If you do that, if a category or a tag has posts less than $n, it returns nil. It seems like a severe limitation of collections.D . Doing {{- $actualN := cond (lt ($pc | len) $n) ($pc | len) $n }} and replacing $n in the range with $actualN seems to solve the issue and the category fallback works. So basically.
IF (we have fewer posts than we want to show)
THEN use the number of posts we have
ELSE use the number we want to show
What should it do, or what do you expect it to do, under that condition?
(I will use the answer that Claude AI generated since it might be more weighty than what I could come up with.)
"Here’s what I’d expect:
Expected behavior: When n > hi (requesting more items than available), collections.D should return all available items (equivalent to returning indices [0, 1, 2, ..., hi-1]).
Current behavior: Returns nil when n > hi
Why this matters:
The primary use case for collections.D (as shown in the docs) is selecting random pages from a collection:
{{ range collections.D seed $n ($pages | len) }}
In real-world usage with .Related, the number of related pages varies per post. Some posts have 10 related pages, others have 3. Currently, I need this workaround:
{{- $actualN := cond (lt ($p | len) $n) ($p | len) $n }}
{{ range collections.D seed $actualN ($p | len) }}
This defeats the purpose of having a configurable $n parameter.
Comparison with shuffle:
shuffle handles this gracefully - if you request 6 items from a 3-item collection, you get all 3 items. This is the standard behavior users expect from random selection functions.
Suggested fix:
In the code you shared, this condition:
if key.n <= 0 || key.hi <= 0 || key.n > key.hi {
return nil
}
Could become:
if key.n <= 0 || key.hi <= 0 {
return nil
}
if key.n > key.hi {
key.n = key.hi // Cap n to available items
}
This would make collections.D more user-friendly and align with common expectations from random sampling functions."
This sounds like a reasonable enhancement:
if key.n > key.hi {
key.n = key.hi
}
And while the body’s open we should consider throwing errors when key.n <= 0 or when key.hi <= 0.
Please create a proposal on GitHub.
Solved by
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.