Taxonomy translations

support
,
1

Is there a way for theme authors to provide translations for both default taxonomies of tags and categories to be used as titles on their taxonomy page?

In my case those taxonomies are meant to be set by their English name in frontmater even if the page is non English.

page.en.md

+++
title: "New Page 1"
tags: ["hugo"]
+++

page.de.md

+++
title: "Neue Seite 1"
tags: ["hugo"]
+++

On the according /tags taxonomy page I want to have the title “Tags” for the English translation and “Stichworte” for the German translation.

I know this can be achieved by providing _index.en.md and _index.de.md files with translated titles for each taxonomy. But from a theme authors perspective this isn’t a solution that would work for all users, as it makes assumptions about their multilang setup (files vs. directories).

2

Save translations on i18n folder, and fallback to page title if no translation found.

// i18n/en.toml
[tags]
other = "Tags"

// i18n/de.toml
[tags]
other = "Stichworte"

{{ i18n "tags" | default .Title }}
3

There’s a clever way to do this in the next release (v0.123.0), where content becomes multi-dimensional. To give you an idea…

themes/mytheme/content/
├── bar.md
└── foo.md

Yeah, so, how does that have any relationship to the section titles that are automatically generated for taxonomy pages?

themes/mytheme/content/bar.md

title = 'Tags (en)'
path = '/tags'
lang = 'en'
kind = 'taxonomy'

themes/mytheme/content/baz.md

title = 'Tags (de)'
path = '/tags'
lang = 'de'
kind = 'taxonomy'

I’m still trying to wrap my head around this a bit, but where you place content and how you name it are now a bit more flexible.

And, of course, since this content is in the theme’s content directory, if/when a site owner creates taxonomy section pages of their own, those pages take precedence over what I’ve done above. And that’s true regardless of whether they translate by directory or by file.

@bep Comments?

1 Like
4

Usually, you want it the other way around, to allow he user to override the translation by the frontmatter title.

5

Sounds like it doesn’t matter were those kind of files need to reside in the directory tree.

A bit sad as this will cause translations to be littered in multiple files instead of a single i18n translation. This makes it a bit more difficult for translators.

Nevertheless thanks! Seems like a viable solution.

6

The approach above is about providing content in different languages. The title is part of that content… it resides in the content file.

If you want to translate a string, use translation tables.
If you want to translate content you have to… translate content.

To say that “this will cause translations to be littered in multiple files” is just… wrong.

7

Yea, it would work, but I’m not sure it would improve the situation.

v0.123.0 is about many things, one of those it to prepare the grounds for content pages from other data sources.

I have not read the entire thread in here, but I suspect the main gripe of it is that the translations gets spread out into multiple files.

This is a little sketchy, but the idea is that you soon enough should be able to do content/tags/_content.json (at any level in the tree) (or TOML/YAML, I guess) where the data inside _content.json is either:

  • Page metadata and content.
  • A reference to a plugin configuration (that pulls content from … wherever…)
8
9

I went a different route as I wanted to maintain compatiblity for older versions, too and also want it to work with the upcoming 0.123.0:

{{- $taxTitle = .Params.Title | default (i18n .Data.Plural) | default .Data.Plural }}

The “trick” is, to get the taxonomy title from .Params.Title, as the .Title may be prepopulated by Hugo without taking any translation into consideration.

10

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