For a multi-lingual project with English as default, I’ve tried to use the new sites complements without much success. The use case is: “fill in” missing content in non-default languages from the default English one, so users can benefit from a “complete” site even though some bits are in English. F…

Summary If you plan to fill in missing translations with content from another language, translating by directory is the preferred approach . Feature Translating by directory Translating by file name Primary mechanism Creates logical pages by mirroring files Complements collections with exis…

[image] marcuspollio: The use case is: “fill in” missing content in non-default languages from the default English one How do you organize translations? By directory (e.g., content/en/ , content/de/) or by file name (e.g, content/example.en.md, content/example.de.md)?

[image] jmooring: How do you organize translations? We use page bundles with translation by file name. Here is an example tree: content/ ├── docs │ ├── api │ │ ├── index.en.md │ │ └── index.fr.md │ └── _index.en.md ├── help │ ├── bug │ │ └── index.en.md │ ├── _index.en.md…

Hi @jmooring Thank you very much for the thorough investigation! Once v0.157 (or v0.156.1) is out, I’ll have some tests to assess whether it is worth changing the translation approach. We want the behavior provided by the directory approach (never inadvertently cross language barriers), but the re…

The change from Translating by filename to Translating by directory was pretty quick actually. Here is a quick and rough test using the Translating by directory approach with: module: mounts: - source: content/<locale> target: content sites: matrix: languages: …

Thanks for closing the loop on this. It’s one thing to create test cases and projects, but seeing further evidence of it being used in the wild is great.

This is very interesting. I have one question (apologies if I missed this in the docs): let’s say I have it setup as above, translation by directory and missing pages in other locales “complemented” from the English version. Would the .Page.Language method on an English page in, for example, the Dut…

When you use Hugo’s mounts configuration to fill-in missing translations, you are effectively instructing Hugo to treat files from the English directory as a native part of the Dutch site’s file system. Consequently, Hugo processes these “borrowed” pages as members of the Dutch site object, meaning …

Okay, thank you, that’s good to know. As I’ve said, that may lead to accessibility issues. But I guess you could work around it with a custom frontmatter Param, cascaded from the index file. I’ll experiment with this feature over the weekend!

[image] kedara: : let’s say I have it setup as above, translation by directory and missing pages in other locales “complemented” from the English version. Would the .Page.Language method on an English page in, for example, the Dutch site return English or Dutch? My hope would be English, otherwi…

Using the multidimensional content model to fill-in missing translations

support

system Closed February 28, 2026, 7:44pm 13

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.

Topic		Replies	Views
Do all page bundles need localized copies once you add a new language? support i18n	15	2487	March 31, 2022
Fill in the missing translations support	5	938	March 8, 2025
Incremental translation with translation by file name support i18n	2	80	April 8, 2025
Content organization not working in multilingual site support	16	6012	January 5, 2017
Do I need to completely copy the default content directory to the new language translation directory when translating a site? support i18n	2	535	October 17, 2022

Using the multidimensional content model to fill-in missing translations

Related topics