allow languagePrefix to be defined via config

[fnordfish]

In my multilingual project, I'd like to be able to have more control over the generated URLs.
I'd like to be able to define whichlanguagePrefix is used, instead of the language key.

As an example:
http://base/en/some-post -> http://base/questions/some-post
http://base/de/some-post -> http://base/fragen/some-post

I've tried to just use those translations as keys in the translations config, which produced the right document structure, but broke i18n, because the keys are no longer language codes.
I've also tired to just use hard-code the entire url as page params, which also worked for pages, but had no effect on the home page.

hugo/hugolib/site.go

Lines 1294 to 1297 in 04b8985

	languagePrefix := ""
	if s.multilingualEnabled() && (defaultContentInSubDir || lang.Lang != defaultContentLanguage) {
	languagePrefix = "/" + lang.Lang
	}

Instead of using lang.Lang, we could extend Language with a LanguagePrefix, which could default to Lang?

languages:
  de:
    languageName: Deutsch
    languagePrefix: "/fragen" # << purposed new config key
  en:
    languageName: English
    languagePrefix: "/questions"  # << purposed new config key

[davidsneighbour]

# config.yaml
defaultContentLanguageInSubdir: true

languages:
  fragen:
	languageName: Deutsch
  questions:
	languageName: English

Should do that. I could also think of a way where you use slug in the front matter of your list-files, but I don't know your content structure, so this might fail.

I can't find the place where it's written, but the language slug can be anything and is not covered by rules, you just need to be careful where you define language related things so that you are using fragen/questions instead of de/en.

[fnordfish]

Yes, that works but messes up i18n, since "fragen" and "questions" would be used as Lang identifiers. Even when languageCode is set manually

[fnordfish]

Sorry for my short on-the-phone answer earlier.

For me, it's a bit confusing, what Lang is depending on the context. I believe it's generally used as the language code, as per:

hugo/docs/content/en/variables/page.md

Lines 87 to 88 in 04b8985

	.Language
	: a language object that points to the language's definition in the site `config`. `.Language.Lang` gives you the language code.

But it seems that in some (most?) cases it's just the key used in the languages config (de/en, or fragen/questions).

I could work around that, by setting a languageCode in the languages configs, and changing templates like this:

- {{ .Site.Language.Lang }}
+ {{ .Site.LanguageCode }}

{{ range .Translations }}
- {{ .Lang }}
+ {{ .Language.Params.LanguageCode }}

But it still breaks for some hugo internals, like i18n, where I get errors, not unlike #7838, Failed to get translated string for language "art-x-questions".
When I rename my translation files form en.toml to questions.toml (etc) things get really weird, where it might use just the first translation file found for all the languages.

[pamubay]

I believe what you really want actually ability to let non-primary language generated without /<language_key>/ directory wrap.

as primary language default to be generated without language subdir, but also can be controlled via defaultContentLanguageInSubdir to put it inside /<language_key>/ directory.

meanwhile, secondary language always generated inside it's /<language_key>/

Example:

content/
├── de
│   └── fragen
│       ├── _index.md
│       └── fragen-1.md
└── en
    └── questions
        ├── _index.md
        └── question-1.md

Expected generated structure

public/
├── fragen/
│       └── index.html
│            └── fragen-1/
│                └── index.html
├── questions/
│       └── index.html
│            └── question-1/
│                └── index.html

[fnordfish]

@pamubay Yes, kind of. But wouldn't your content directory structure break the default translation mapping, and would require me to put a translationKey into each file?

It's all a bit confusing, that's why my initial thought was to just be able to define which language prefix to use and setting defaultContentLanguageInSubdir = true. That would keep all the sensible defaults (content structure, translation keys, language identifiers, etc) intact.

[jmooring]

@fnordfish

Setting a language prefix to a content type, if you could, would fail as soon as you added another content type.

Please try this site:

git clone --single-branch -b hugo-github-issue-8279 https://github.com/jmooring/hugo-testing hugo-github-issue-8279
cd hugo-github-issue-8279
hugo server

[fnordfish]

@jmooring Thanks for creating the sample.

I tried your sample and also adopting to my usecase. But it's not producing my desired result.
I need control over how the language directory is named. Your sample generates /de, /en, /es dirs and than renames the path for the content type (which is pretty cool, and I might that some time :)). But I need /de to be /fragen and /en to be /en/questions everything nested into them can be the default way. That's why one try was to simply rename the language keys (which again actually produces the exact directory structure I need, but messes with i18n)

So I don't want to set the "language prefix" to a content type but to the language itself.

I while back, I played around a bit and got a proof-of-concept "working" (it made some test fails if I remember correctly): https://gist.github.com/fnordfish/100564ed0190452dd7136c66bd600961

(Some background: I generate parts of a larger website using hugo. And that site already has some pretty pinned down URL schema - so I cannot simply go with the defaults)

[jmooring]

@fnordfish

I've update the test site to remove the lang code from section URLs.

diff

commit 0d27800b0bcc9372b3438d8563acccdfef7ba5b8
Author: Joe Mooring <joe.mooring@veriphor.com>
Date:   Thu Nov 4 12:38:47 2021 -0700

    Remove lang code from section URLs

diff --git a/content/books/_index.de.md b/content/books/_index.de.md
index 6260afc87..68e5d74ab 100644
--- a/content/books/_index.de.md
+++ b/content/books/_index.de.md
@@ -2,6 +2,6 @@
 title = 'Bücher'
 date = 2021-11-04T09:49:05-07:00
 draft = false
-url = '/de/bücher/'
+url = '/bücher/'
 +++
 This is content/books/_index.de.md
diff --git a/content/books/_index.en.md b/content/books/_index.en.md
index 7428a2fdc..b692b4335 100644
--- a/content/books/_index.en.md
+++ b/content/books/_index.en.md
@@ -2,5 +2,6 @@
 title = 'Books'
 date = 2021-11-04T09:48:59-07:00
 draft = false
+url = '/books/'
 +++
 This is content/books/_index.en.md
diff --git a/content/books/_index.es.md b/content/books/_index.es.md
index 910a33fb7..86c5cb68d 100644
--- a/content/books/_index.es.md
+++ b/content/books/_index.es.md
@@ -2,6 +2,6 @@
 title = 'Libros'
 date = 2021-11-04T10:01:30-07:00
 draft = false
-url = '/es/libros/'
+url = '/libros/'
 +++
 This is content/books/_index.es.md
diff --git a/content/questions/_index.de.md b/content/questions/_index.de.md
index bca45b752..8b2449907 100644
--- a/content/questions/_index.de.md
+++ b/content/questions/_index.de.md
@@ -2,6 +2,6 @@
 title = 'Fragen'
 date = 2021-11-04T09:49:05-07:00
 draft = false
-url = '/de/fragen/'
+url = '/fragen/'
 +++
 This is content/questions/_index.de.md
diff --git a/content/questions/_index.en.md b/content/questions/_index.en.md
index 9dac5a0c5..2fd269849 100644
--- a/content/questions/_index.en.md
+++ b/content/questions/_index.en.md
@@ -2,5 +2,6 @@
 title = 'Questions'
 date = 2021-11-04T09:48:59-07:00
 draft = false
+url = '/questions/'
 +++
 This is content/questions/_index.en.md
diff --git a/content/questions/_index.es.md b/content/questions/_index.es.md
index 426855edc..48605d6c0 100644
--- a/content/questions/_index.es.md
+++ b/content/questions/_index.es.md
@@ -2,6 +2,6 @@
 title = 'Preguntas'
 date = 2021-11-04T10:01:30-07:00
 draft = false
-url = '/es/preguntas/'
+url = '/preguntas/'
 +++
 This is content/questions/_index.es.md

This gets you most of the way there, I think. However, the pages within each section still have the language code. Will that work? Please pull changes and test again.

I'm spending time on this because, if we're going to propose a change, I want to make sure we understand what we're trying to change and why.

[jmooring]

I think this issue is mostly about permalinks and ease-of-use.

You can achieve the desired results by:

1. Not setting permalinks in the site configuration
2. Setting the url in section page front matter (use site-relative path starting with /)
3. Setting the url in content page front matter (use site-relative path starting with /)

But this is a lot of error-prone data entry, and is probably fragile over time.

We could also achieve the desired results by:

1. Interpret permalink configuration paths in the same way we interpret front matter url paths. If it starts with a / omit the language code from the generated URL. If it does not start with a / prepend the language code. The way we interpret front matter url paths was changed in hugolib: Allow relative URLs in front matter #5805. We would need to make a similar change to permalink interpretation. This would be a breaking change; needs some thought.
2. Provide a way to configure section page permalinks in the site configuration. See Add Permalink option for section pages #8523.

[fnordfish]

@jmooring Thanks again, happy to test anything.

I think that's kind of what I'm doing as my current workaround. I put an explicit url on each content page. Which leaves everything "auto generated", like lang-home, 404, sitemap, taxonomy index etc. in the "wrong" place.
I could find a way to disable taxonomy index pages (b/c we don't use them currently) or to move those other pages.

[fnordfish]

Just to add: Taxonomy stuff should also be nested under the common prefix. eg: /fragen/tags/foo and /en/questions/tags/foo

[jmooring]

Taxonomy stuff should also be nested

This would be addressed by #8279 (comment).

[fnordfish]

@jmooring

Just to make sure we're on the same page, I've applied my patch to hugo-HEAD and adapted your sample project to use the new config.

Not saying that it has to be done that way, but that's the outcome I'm looking for:

fnordfish/hugo-testing@44922b2#commitcomment-59488119

Another sample with permalinks:

fnordfish/hugo-testing@7a63db0#commitcomment-59488572

[bep]

I'm closing this. The proposal as defined the title is not something we're going to do.

[fnordfish]

@bep Fair enough. Do you think it's something that could eventually be done using Permalink options? Or is this setup not a thing hugo will support in the foreseeable future?

[github-actions]

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.