Others may have bumped into the challenge of referring to taxonomies in templates, when running one separate set of taxonomies for each language.
So I did, anyway, when developing this bi-lingual website about open source and open standards.
The issue is described on GitHub #3014. And so is the solution, which might come in handy in this forum.
In my case it’s has been obvious to keep taxonomies completely separated for each language. The advantage being that the titles on the taxonomies-lists and taxonomies-terms-lists are generated correctly (in the correct language) right out of the box. However, on the templates, that in my case are shared across the different languages, have to capture values from taxonomy-keys, that change in front matter depending on the language in use.
In other words: {{ range .Params.authors }} on my single.html-template gets the authors all right on the english documents - but also misses the author-names on the danish documents, where authors resides in the skribenter-taxonomy (danish for authors).
A few if-statements will fix that for a bi-lingual website. But how about a website with 5 or even 10 languages?
As mentioned on GitHub I came up with the suggestion, that the i18n-setup in Hugo needed some changes on order to solve that elegantly. But in less than 5 minutes I was told othervise by bep. Another post also explains the point: #304.
Thank you to you both.
Bottomline is: It’s allready possible to reference variables/keys with different names by treating the key names just like the values allready in lace in your i18n-files.
Example - i18n/da.yaml:
- id: i18nAuthors
translation: skribenter
Example - i18n/en.yaml:
- id: i18nAuthors
translation: authors
The right translation is retrieved in the right language on the template with:
{{ range index .Params (i18n "i18nAuthors") }}
Multi-values also work. I just managed to stumble over a small naming-issue:
Having the same id- and translation-name seems to spoil the translation. That’s why the id has been named i18nAuthors instead of just authors. With this little workaraound everything works like a charm. At least in my case.
So no need to change Hugo… It’s possible to reference not only values, that change from language to language - but also dynamically changing variable names/keys - by using the string translation-feature on Hugo as a kind of switch.
This is just awesome, if anyone should ask me.