Without this feature, every page param has to be duplicated in each page translation file (a mess to maintain). It would be great if the page translation files inherited the default language values so each translation would contain what actually changes only.
For example having post.en.md and post.es.md with default lang en.
post.en.md content:
---
title: My Post Title
param1: Value1
param2: Value2
...
paramN: ValueN
---
My Post Content
post.es.md content:
---
title: Título de mi entrada
---
Contenido de mi entrada
With this feature, post.es.md would override .Title and .Content and inheriting param1, param2 … paramN
I like this feature. Many Parameters are often duplicated between translations.
@butaca, it would be interesting to pounder this with possible code/break unwanted side effect.
The one side effect I see is that current Hugo project testing if a Param is set in a language with isset or with will now test it positive no matter what and return the value of the param set in one of the translations.
Also any projects used to use .Param to fallback to the .Site.Param value when the Front Matter param is not set will also find it set but with one of the translations’ value which may not be what they want.
As for which Param value to retrieve when current translation has not param set but more than one of its translations have a competing param set, I think it should return the param whose language has more weight. Same rule already applies to merged Page Resources.
I don’t think all of this would affect too many installs, but this means putting a warning during build and possible noise in the discourse.
If this feature is optional and disabled by default it wouldn’t break existing projects.
I proposed to inherit from the default language, but could be something different. As long as the user has control over the “inheritance” process is fine I guess.
Another option that could work is setting the params in another file not tied to a specific language and “importing” those values explicitly in each content file or something similar.
Sure, but how do you merge two params maps? Even in multilanguage sites you would have cases where English needs 4 params, but Swedish only needs 3. Adding the “missing” 4th to the Swedish page would not be good, and it’s impossible to know.
I think this is a hard problem, and whatever we do, it should not involve adding some “extra metadata” files to the mix.
What I have seen in the wild, is mostly a need to pull in “missing content files”. We have lang.Merge, but that isn’t ideal for many cases (you want an URL in your own language).
And if you have many languages, you will also want to control which languages you pull from (Norwegian is close to Swedish, so I prefer that before English).
So, you would end up with some “rule set” where you should describe how things should be merged.
Why adding an extra file is not desired? Because of the added complexity I guess?
I agree, something like this would be flexible enough to cover most use cases. Not sure where to put those rule sets though, because I guess some users would like to have different rules per page others would want a global rule set. Maybe having both global and specific would work.
Rereading the thread and thinking a little more about this, we are describing different issues. You are referring to missing content pulled from other languages and a rule set to define how that works and I’m talking about language independent params that should be shared by all languages to avoid duplication. For example weight or dates.
With this in mind I propose possible solutions ideas to continue the discussion:
Having a new file containing the shared params (and maybe default content) along the languages serving as a master/template/baseclass (could be post.shared.md or any other convention). The data defined in the languages files override what is defined in the master file. This solution is by definition optional and disabled by default.
The same as #1 but instead of having a new file, use the default language file as master. Same as #1, the language files override what is defined in the default language. This behavior should be optional and disabled by default to keep compatibility.
I feel like this suggestion was not read or ignored. Sorry for my prying, but I’ll detail it once and shut up if nobody cares.
First I think introducing a new method is code break free and avoid having to educate current user a new merging system they may not need and yet may disagree with. Only the ones needing it will have to care. Plus you may only need this logic at certain location in your templates, not always.
What I propose .LangParam or other name would be similar to .Param but this is how it would try and get the value:
Try and get the current translation front matter and use it
If not found try and find the next language (by weight) translation front matter and use it
If not found goes to next language until no more language
If not found follow the same logic but with .Site language param.
They are connected indeed but are conceptually different issues. If you find an abstraction that cover both of them (or even more scenarios) it makes sense to make a single solution. If not, I don’t see a problem in implementing different solutions.
So, as I said before, IMHO we are talking about conceptually different issues here. One is about language independent parameters and the other is about content in different languages and how to manage missing translations automatically with some rules.
If you consider the issue to be more abstract, the solutions suggested by @regis (btw, I read it, I care and it’s great) and me basically don’t make sense.
So, to continue the discussion and lead it somewhere, we should first agree on this. Are we talking about different issues or not? If not, how would you abstract both issues into one? What is your proposed solution considering this abstraction?
If you make a parameter called Content in some front matter, it is content in a content file which also is a parameter. So conceptually exactly the same as I’m talking about, if I understand you correctly.
The language logic is already hard to understand. Adding some other magic files or special params maps and methods to the mix isn’t helping. I think.
I suspect it helps if you think about this at some scale. If you have 1000 content pages and want to translate it to 10 languages. You really don’t want to mess around with some additional files that you somehow handle.
Suppose I have a site in three languages: English (en), Spanish (es) and Portuguese (pt). So each post has three files, one for each language: post.en.md, post.es.md and post.pt.md. Each post has a title, weight, an icon (url) and the content.
I want to change the order of the posts (weight) or the icon of a specific post. That leads me to problem A: in order to change the weight or the icon of a post, I need to update each post language file duplicating the values in the process.
Now, the content is different for each language, so each file defines its own content. No problems there. However the title is the same in Spanish and Portuguese (a common scenario) but different from the English title. That leads me to problem B: I have some content in a language that want to reuse somehow from other language but I have to update both files duplicating the values.
Problem A is related to parameters that are common for all languages, but don’t contain text, they are independent from the languages.
Problem B is related to language content. It has text, it is language dependent.
That’s why in my opinion problem A and B conceptually different and need different solutions, because they are different things. If you think they are the same problem, I would love to hear your opinion, the consequent abstraction and a ideally a solution suggestion.
