0.123.8 TranslationKey does not connect term pages

support
,
1

Since 0.123.0 onwards, translationKey doesn’t work as before. Before I could just put a value like presentation in two files and they would be linked together, getting .IsTranslated as true, a list of .Translations etc. With 0.123.x, I can’t see how to make it work.

I see this happening in term pages, with one of the translations having diacritics (for example, “music” in en and “música” in pt). I didn’t test in other kinds of pages.

Inspecting translationKey value, I saw that for pages with no such field in frontmatter .TranslationKey returns the page’s logical path, always beginning with a /. So I tried to put / in my translation keys, as a test, and it worked, but only while the Hugo server was running. Stopping and starting it again breaks again the translation linking.

I discovered it because something I don’t know whether is a bug or by-design: starting with 0.123.0, taxonomy terms that have diacritics (like “música”) need to have that diacritics when creating a custom content file (like, categories/música/index.pt.md). Before 0.123.0 that was not the case, it was mandatory to not have any diacritics (so I had categories/musica/index.pt.md, attention to the lack of diacritics here). Even if it is by-design (perhaps it has to do with the new logical .Path), it would be nice to document this behaviour.

2

With the test site below, setting translationKey in front matter behaves as expected for all markdown files:

git clone --single-branch -b hugo-forum-topic-48829 https://github.com/jmooring/hugo-testing hugo-forum-topic-48829
cd hugo-forum-topic-48829
hugo server

content structure

content/
├── categories/
│   ├── music/
│   │   ├── _index.en.md
│   │   └── cover.en.jpg
│   └── música/
│       ├── _index.pt.md
│       └── cover.pt.jpg
├── _index.en.md
├── _index.pt.md
├── p1-foo.pt.md
└── p1.en.md

That is correct, and makes much more sense.

See https://github.com/gohugoio/hugoDocs/issues/2465

3

In fact, no, it doesn’t — in term pages. I’ve run your test site, and yes, it correctly behaves in post pages. But in term pages (in this case, either /pt/categories/música/ or /en/categories/music/), it doesn’t find any translations, and it’s possible to see it from the rendered page: there’s no “English Portuguese” links to alternate between languages in those term pages.

4

Sorry, I’m missing something.

  1. music and música are two different terms (they might as well be “foo” and “bar”)
  2. music is assigned to content/p1.en.md
  3. música is assigned to content/p1-foo.pt.md

If I understand correctly, you want to connect two completely different objects via translation. Is that right?

5

Strictly speaking, yes, but in your test site, p1-foo.pt.md and p1.en.md are also two different objects (again, strictly speaking). Because conceptually, music and música are not different terms, but translations of a same term.

And again, although you’ve put a translationKey both in music and música content files, that key is ignored. I can’t see a rationale behind translationKey other than cases like this: connecting objects that are different from Hugo’s POV, but translations of a same object from user’s POV.

6

I guess I am more accustomed to seeing the same term used across all languages, then translated.

Regardless, you could do what you wanted in v0.122.0, but not in v0.123.x… so I’ll log an issue.

1 Like
7

Thank you!

How I’d do that? Using title in term content file?

8

Yes.

And when displaying terms on content pages, never do this:

{{ range .Params.categories }}

Always use .Page.GetTerms. This makes life so simple, yet I still see site theme authors doing it the hard (wrong) way.

1 Like
9

Yeah, I already use this approach (also because I have other taxonomies beyond tags and categories), but thank you to pointing it out!

10

See https://github.com/gohugoio/hugo/issues/12261

In the interest of tracking forum topics related to v0.123.x that do not have a corresponding GitHub issue, I am marking this resolved.

1 Like
11

Initial response from bep indicates that you should do the above instead.

1 Like
12

A fix for this will be available in the next release, but I still recommend using a single term across all languages, and translate via the term’s branch bundle titles.

13

Thank you!

Yes, it seems more elegant and simpler. I don’t exactly remember why I’ve chosen the other way, as it’s a side project in which I work from time to time and that decision was took by me-from-two-years-ago haha.

1 Like
14

In fact I now remember why I’ve chosen the other way: to get correct URLs. In the “música/music” example this is a minor problem, but with “comunicação/presentation” this is much worse (these are academic terms, changing them in my site would be wrong).

Can I accomplish correct URLs with the recommended way, so “/musica” and “/music”, “/comunicacao” and “/presentation” linked to each other?

(I’ve already configured the taxonomy translation itself. And sorry for asking, I’m in a travel now and only will be able to experiment and test by myself in next Thursday, but I didn’t want to lose the momentum of this question…)

16

content/categories/music/_index.en.md

---
title: music
---

content/categories/music/_index.pt.md

---
title: música
url: categories/música
---

Notice that the url does NOT begin with a slash. This is important.

https://gohugo.io/content-management/urls/#url

In a multilingual site:

  • A url value with a leading slash is relative to the baseURL.
  • A url value without a leading slash is relative to the baseURL plus the language prefix.
3 Likes
17

Thank you!

18

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