relativeURLs=true with multilingual websites produces broken relative urls?

What version of Hugo are you using?

(v0.76.3)

Does this issue reproduce with the latest release?

yes

problem

My config file is:

languages:
  en-us:
    baseURL: https://example.com
    languageName: English (United States)
    title: Example US
  fr-fr:
    baseURL: https://example.fr
    languageName: Français (France)
    title: Example FR
defaultContentLanguage: en-us
defaultContentLanguageInSubdir: true
relativeURLs: true

When I run hugo, it creates these folders:

public
- en-us
   - css
- fr-fr
   - css

The relativeURLs:true flag rewrites the urls using public/ as the root and not the corresponding language folders. For instance, a template such as

<html>
<link href="/css/test.css">
</html>

will be rewriten, for a file in en-us, to:

<html>
<link href="../css/test.css">
</html>

however, the file is in <link href="css/test.css">. So none of the relativeUrls work!

this is correct! Read the Manual!

Of course, I have read the manual, and all other pages returned by google that may be relevant to this problem. How it is possibly correct or intended behavior that every relative URL is broken?? I am saying relativeURLs=true produces nothing but broken url when used in conjunction with multilanguage. Finally, when adding defaultContentLanguageInSubdir=true even the default language has broken relative urls.

Adding multilanguage shifts the content one folder up into language subfolders such as en and fr, but relativeURLs=true does not compensate for this shift and still point to the root folder. Every relative Url return 404.

look at the link above

Quote

Setting relativeURLs to true in your site configuration will cause Hugo to rewrite all relative URLs to be relative to the current content.

For example, if your /posts/first/ page contains a link to /about/ , Hugo will rewrite the URL to ../../about/ .

RelativeURLs are made for working with filesystems, not with HTTP servers!

is it intended behavior that relativeURLs rewrites to the parent folder of the file, instead of where the file actually is - thus producing a 404 error on every URL?

You seem to be answering that yes - 404 errors on every URL is correct, welcomed, and intended behavior.

Is it your official position that every relative url of a multilingual website should be 404?

1 Like