Add support for "content root" per language

[bep]

For bigger multilingual documentation sites etc., having all the translated version in the same folder can be a little hard to administer, even if you split into sections/sub folders.

You can, currently, somehow get around this by setting a translationKey, but you will still have to put the language code in the file name.

I suggest that we introduce a "content root" setting per language:

content
├── en
│   └── docs
│       ├── some-doc-1.md
│       ├── some-doc-2.md
│       ├── some-doc-3.md
│       └── some-doc-4.md
└── jp
    └── docs
        ├── some-doc-1.md
        ├── some-doc-2.md
        ├── some-doc-3.md
        └── some-doc-4.md

The simple rule being: All content without a language identifier in the filename will fallback to the "root 's language".

[bep]

@RickCogley any thoughts/objections?

[RickCogley]

No, that looks clean to me. I assume Hugo would be able to determine a file's translation status by comparing the file names, and matching ones that are the same from lang to lang?

[bep]

Hugo would be able to determine a file's translation status by comparing the file names, and matching ones that are the same from lang to lang?

Yes.

[RickCogley]

It begs the question though, about bundled assets. I think currently you can put any language-shared images in the bundle, and access them from both files, say, index.md and index.en.md in my case, where index.md is Japanese. I'd have to copy the shared asset to the second bundle folder, no?

[bep]

I'm not sure -- but logically they should work the same, it is just another way of "setting the language identifier". But note that you don't have to use this and you can mix and match. This is mostly targeted at "big and content heavy" sites.

[bep]

@RickCogley I have pondered a little about how to implement this, but now I think I know:

So, given this:

content
├── en
│   └── docs
│       ├── some-doc-1.md
│       ├── some-doc-2.md
│       ├── some-doc-3.md
│       └── some-doc-4.md
└── jp
    └── docs
        ├── some-doc-1.md
        ├── some-doc-2.md
        ├── some-doc-3.md
        └── some-doc-4.md

Will when looked at as "one tree" (logically) look like this:

content
└── docs
    ├── some-doc-1.jp.md
    ├── some-doc-1.md
    ├── some-doc-2.jp.md
    ├── some-doc-2.md
    ├── some-doc-3.jp.md
    ├── some-doc-3.md
    ├── some-doc-4.jp.md
    └── some-doc-4.md

Which would effectively solve all the shared bundle issues you mention. Will have to think about this, but I suspect the above merge should be doable with some Afero FS magic.

[RickCogley]

@bep works the magic as usual 👍

[bep]

@bep works the magic as usual 👍

@RickCogley I just tested the conceptual technical part and it looks beautiful. Note that I would not have thought of the simple solution without your input.

[vinniejames]

Would this improvment still allow still allow a folder structure in the form of:

en/
  Index.MD
  Page.MD
JP/
  Index.MD
  Page.MD 

Scoping this out as a possible framework, our current setup uses the organization above. With 3,000+ source files * 6+ languages, a flat folder structure feels like a regression. Does Hugo support browser accept-languge switching our-of-the-box?

Edit: read that wrong, sounds like the above structure is the proposal. So what is it preventing a dev from setting up the folder structure described above as of now?

[bep]

Would this improvment still allow still allow a folder structure in the form of

Yes, indeed. For general questions, see https://discourse.gohugo.io/

[vinniejames]

Yes, per my edit what is preventing this proposed folder structure now?

[bep]

Yes, per my edit what is preventing this proposed folder structure now?

Read my edit.

[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.