Feature Request: Take front matter fallback from default language

[raphaelmenges]

Hello @untra!

I am working on a project overview for my institute and would like to have each project as "projectxyz.en.md" with an English description etc. and "projectxyz.de.md" with a German description etc. This works fine so far, however, there are general variables like project duration, which i would like to define once for each project. I have read about the approach to put such general variables into the _data folder. This separation of information for each project might be counter-intuitive. It would be nice either to have a "projectxyz.md" in the same folder as the translations which front matter is taken as fallback in both translations or to take the default language markdown as fallback.

Or am I missing another way to handle this issue?

[untra]

Hello @raphaelmenges 👋

If you look at how I use the _data directory, I made separate folders for each language, and then access the sample data like so.

But you are looking for specifying these variables once (ideally in the default_lang data directory), and then having each translation access it from there.

I believe you should be able to specify a yaml file in the _data directory, not under a language folder, and then access those values from there. You should then be able to access those variables regardless of what language they're for. I don't have an example of this right now, but I should have time later to put a sample example up. Give that a try!

[raphaelmenges]

First of all, this sounds like a feasible solution 👍

However, I am trying to keep related information together in the same folder. Therefore, I have placed the markdown files with localized information about one project into the same folder and distinguish between the localizations via the file extension (en.md and de.md) and the front matter language variable. This works fine so far when defining all variables in both localizations. But defining language-independent variables like project duration in both localizations is redundant and error-prone, as discussed above.

When using your approach for language independent variables, there would be a separation between the markdown files with the localized project information (e.g., _projects/projectxyz.en.md, _projects/projectxyz.de.md) and that .yaml file with general project information in the _data directory.

This might be an issue for maintainability as I would have to put a note like: Ok you can add and edit projects in the _projects folder but some variables must be set and edited in the _data .yaml file. I know this sounds like a minor issue, but I am working on a Web site for my institute where frequently people join and leave the group. Thus, it would be nice to have the language-independent front matter variables somehow in the same folder as the markdowns with the localized project information or to put the variables in only one of the markdowns with localized project information. Otherwise people with mess stuff up, I am sure 🙈

I do not know whether the approach "front matter variable in the markdown of that language is not defined, take a look at the front matter of the markdown file of the default language and take that value as fallback" is practial with how Jekyll is designed.