That’s brilliant! I really like this idea of language-specific extra configuration. It could make it easier to support different baseURL for every language. I have two questions about this proposal:
- I’m concerned about taxonomy translations. How can we link to translations for taxonomy pages like we do for content pages? Also, should the localized taxonomy name be used for output paths (URLs), for taxonomy frontmatter declarations, or both?
Maybe some people would like to have localized taxonomy names in their frontmatter. Personally, i would only like them in URLs, because it’s a less error-prone process when translating a single article (a taxonomy term may have different translations depending on who is doing the translation).
taxonomies = [
{ name = "author" }
]
[languages]
[languages.fr]
translate_taxonomies = "url"|"frontmatter"|"both"|"none"
taxonomies = [
{ name = "auteurice", id = "author" }
]
So i can write:
+++
title = "Ma traduction"
[taxonomies]
author="southerntofu"
+++
This way no need to worry if someone is translating author to “auteur”, “auteure”, or “auteurice” (gender variance). This approach would still enable to have language-specific taxonomies, by not specifying an id. The same translation strategy could be applied to taxonomy terms.
- I was already (mis)using the translations for this, but faced the problem that theme’s translations were not merged with site translations. If i understand your PR, this problem is fixed in add_theme_extra().
However, how does that work when the default language is not the same in the theme and in the site? Language-agnostic configuration will gladly be merged, but will a default-french site display default-english translation strings from the theme’s extra? I believe this could be a problem, maybe justifying to keep the translations field separate from extra?