@Esanders @matmarex We're discussing how to implement this feature and are stuck on a question that I hope you can answer. Would it be acceptable if we modify (or fork) one of the content-linked models, in this case ve.dm.MWTransclusionModel, to include parts which have no wikitext representation? Specifically, we would like to include all of the potential parameters listed in a template's TemplateData to simplify some of the synchronization between the panes of a BookletLayout (probably forking this class as well).

In other words, for a newly created template transclusion like Infobox book we would create all of the parameters like name, author, ..., native_external_host, etc. but these would be invisible until actually added to the template invocation. The implementation of methods like MWTransclusionModel.getPlainObject and .getWikitext would check for the "actually used" flag, and skip over any invisible parts.

Does this break the content model on a conceptual level? Would it be better if we introduce an abstraction above the content, to hold actual and potential content, and then synchronize from this model to actual content at the end of the workflow?

Sure, I think that's a good idea!

In fact we've recently done something similar (but more hacky and less thought out) for parameters marked as "suggested" in TemplateData, which are always added to the template, and which will now disappear if not filled out (T101075#6780815). It sounds like your approach would allow handling that better (we're definitely not attached to the current implementation of it).

Please make sure though that you don't lose the ability to add parameters to the template transclusion after it's created, for parameters not listed in TemplateData.

We need some specification for how to handle parameter aliases. Here's my best guess:

• When a template spec includes parameter aliases
  • Do not show aliases in the sidebar
  • Do not show aliases in the parameter placeholder
• When a template invocation uses aliases
  • Show in the sidebar by checking the canonical parameter
  • Show in the content pane with the canonical label or machine name
• If both a canonical and aliased parameter are present, or two aliased parameters
  • Let's say this is ambiguous, and we're okay with losing one of the two values after saving with Visual Editor.

And another detail: Currently, if a parameter is transcluded using an alias, that alias is preserved when saving the page. Do we want to keep this behavior? Otherwise, we cause "dirty diffs" when saving a template invocation, parameter names will change from alias to canonical just because the template dialog was used.

We discussed this in the daily today and I did a bit of further exploration on the UI side. Documenting the decisions here. Broadly, we are following the existing behavior. There are two situations to consider:

Parameter is not currently part of this template invocation / is not in the wikitext yet
Show Label from TemplateData. If no documented user-facing label, then show machine name/canonical label. In this situation, the alias is never displayed (though if the parameter search is used in the dialog, implemented in T272481, then searching for the alias will show the parameter in the results list under the label or machine name).

Parameter is already part of the template invocation / is visible in existing wikitext
Show Label from TemplateData. If no documented user-facing label, then show whichever name is used in the wikitext, including if an alias is used. On save the parameter name in the wikitext should remain the same (no dirty diffs).

All situations
There is never more than one label shown at a time next to the checkbox or in the main area.

I'm not sure I understand this piece of it though. Is it covered with the above direction or not?

• If both a canonical and aliased parameter are present, or two aliased parameters
  • Let's say this is ambiguous, and we're okay with losing one of the two values after saving with Visual Editor.

In the old sidebar view parameters without a value are displayed in grey (see bottom "fooalias" in the screenshot). Do we want to keep this behaviour in the current version as well or leave as is (see "fooalias" in the green area)?