hugo
hugo copied to clipboard
Create TranslationBaseName from filename only
I'm in the last leg of some improvements in Hugo which requires some simplification in the content path logic . This is also looking a little to the future where content will not just be files, and the task of finding the cannonical path of a piece of content should be a simple task.
Given this content:
content
├── foo.en.md
├── foo.jp.md
└── foo.no.md
Currently, the value of .Page.File.TranslationBaseName
, depends on the language configuration. If only en
is configured, then TranslationBaseName
for foo.jp.md
will be foo.jp
.
In the new setup, every part of the base filename after the first "." separator will be considered identifiers:
foo.no.md => foo + IDENTIFIER_LANGUAGE + IDENTIFIER_EXTENSION
Note that the Page
backed by a foo.unknownlanguage.md
will still be assigned the defaultContentLanguage
.
I'm sure there will be some subtle site breakage in the above, but I'm also sure that we need to do this.
Shout if you disagree.
Currently, with hugo new content/foo.bar.baz.de.md
, .File.TranslationBaseName
is foo.bar.baz
. Will this change? I have seen several sites where the "." separator is used... abundantly.
Will this change? I have seen several sites where the "." separator is used... abundantly.
No, your example will still be foo.bar.baz
(if that is how it is today). But, we will treat de
as a language identifier even if it's not defined as a language in config.toml
.
That said, I would not recommend using the "." ... abundantly.
That said, I would not recommend using the "." ... abundantly.
That said, I don't see us ever adding more identifiers to the filename itself. I have at least one more idea for a "partition" type of identifier -- role based partition (RBAC), but that fits much better in a mount configuration.
No, this is not happening.
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.