(Adding folks who commented in the discussion on the previous tasks, I'd appreciate your thoughts on how this should work. If we all agree that this is a good idea, I'll convince the Editing team to spend some time on this ;), or work on it myself.)

when you add a template parameter in VisualEditor but leave its value empty, that parameter will be removed from the template transclusion.

This seems like the main problem to me, and that seems uncontroversial to me to fix? Afaik there's no significant benefit to removing these. I do agree that there's a minor edge case where perhaps if a template really falls apart if you give it an empty parameter that encoding this in TemplateData could help us to remind the user (or do automatically) to remove empty parameters they intentionally added but left empty, but overall it seems like it's not worth the effort to do anything about.

From reading T101075, I thought what we changed was that if VisualEditor automatically "suggested" a new or required parameter, to not save them if they were left empty. That's different from a parameter the user themselves added. Although that does of course leave the case unhandled where I want to add a parameter and also VE added it for me.

My original suggestion was for VisualEditor to solve this problem by actually distinguishing in its state and visual representation between a suggested field ("slug parameter"?) and an actual field that the user has interacted with and did something with. That seems like it solves all of the problems in this space, and seems to me like a general UX improvement, and it would also not need any kind of TemplateData encoding for "supporting empty values". I don't oppose that, but it seems like it might not be right for this particular problem we're facing, and would require a fair amount of work to existing templates to opt-in and I think it still wouldn't really address the UX problem and confusion, only solve it partly, it seems kind of orthogonal.

Just thinking out loud, but this slug would be literally the embodiment of a suggested parameter how I originally intended it. It's suggested for you to accept, it's not actually added. E.g. promoted in the template dialog sidebar and in the scrollable form field but muted/slugged in some way for you to activate. The difference between required and suggested would be that, like today, required ones ask the user "Are you sure" if left unactivated (if they had a sensible default, like staying empty, they wouldn't be required. And we already have default:"" if that's all we wanted to do). If you "trash" a parameter that was suggested/required, it would turn back into a slug.

Infoboxes on Polish Wikipedia (discussed in T276989), where the convention is to include all parameters in the wikitext (even when empty) to make them easier to fill in in the wikitext editors

We have the same recommendation on French Wikipedia for many templates.

Empty suggested parameters should indeed be removed, but parameters which were already present in wikitext should not be removed (this will cause many dirty diffs, too).

Thanks for the heads-up! I have pinged some folks on our side for awareness so they can look into what would be the best approach from our perspective.

In T280078#6996297, @Krinkle wrote:

My original suggestion was for VisualEditor to solve this problem by actually distinguishing in its state and visual representation between a suggested field ("slug parameter"?) and an actual field that the user has interacted with and did something with. That seems like it solves all of the problems in this space, and seems to me like a general UX improvement, and it would also not need any kind of TemplateData encoding for "supporting empty values". I don't oppose that, but it seems like it might not be right for this particular problem we're facing, and would require a fair amount of work to existing templates to opt-in and I think it still wouldn't really address the UX problem and confusion, only solve it partly, it seems kind of orthogonal.

I don't think that solves the problem though. We still need to distinguish two kinds of suggested parameters – those that should be added to the wikitext even with no value, and those that should not.

In T280078#7051257, @matmarex wrote:

I don't think that solves the problem though. We still need to distinguish two kinds of suggested parameters – those that should be added to the wikitext even with no value, and those that should not.

Maybe you could add "initial" type of parameter? They would initially work as suggested parameters used to work. So shown when adding a template. But, contrary to "suggested", they would be removed if not filled initially. So basically the same like "suggested" worked after T101075.

Anyone come in here? T101075 broke the well-functioning suggested parameter mechanism. Some errors (concerning required parameters) have been corrected by T276989. The rest are lying and still waiting to be repaired. Maybe, as part of the repair, simply roll back the T101075 fix, which apparently generated more problems than the ones it fixed.

Hi. Following a vote, I made a patch/override to keep empty parameters for infoboxes on plwiki. This is now live on plwiki (also for IPs).

Not a general (global) patch, but I think I have an idea how to make this more generic. Two ideas:

1. Use existing "format" property of the template data to figure if this is a multiline template. Not sure if this is a global thing, but our infoboxes has a format like "format": "{{_\n |_______________________ = _\n}}\n". This part |... = _\n basically makes it multiline.
2. Add new TD property like keepParameters (for short) or keepEmptyParameters (to be clear on what it does).

More on keepEmptyParameters

• keepEmptyParameters=level -- this would be the new parameter syntax. It would mean --keep parameters of level and higher.
• keepEmptyParameters=required would be the default. And would mean keeping up to required parameters. So current implementation.
• level is one of: required, suggested, optional, all, true.
• Level order is: required > suggested > optional > all (or true). So keepEmptyParameters=all is the same as keepEmptyParameters=true. And e.g. keepEmptyParameters=suggested would mean keeping suggested and above (so also required).

I can implement this in VE serialization and write tests. Not sure where to add new TD property, but if pointed in the right direction I can implement that as well. I understand there might be bigger problems to deal with in a global Wikimedia field. So I would be happy to help 🙂

In an case I would be grateful for a heads up before you rollout drastic changes in ve.dm.MWTemplateModel. That would allow me/us to prepare our override for the changes (or to disable the patch).

@Nux, while I like this proposal very much, I feel like this will cover only a fraction of the use-cases. What about situations where I want only some parameters to behave like this, but not necessarily bind it to the "suggested" flag? In other words: What if I still want to use "suggested" for the initial set of parameters that shows up when a template is created, but only keep some of them as empty parameters on save? That would require a flag per parameter.

@thiemowmde Yeah, I can understand that need, but that would require much more work from wikimedians (reconfiguring templates manually). There are also more complicated cases were parameters e.g. for images should actually be grouped and both removed as a group and added as a group... So maybe something for a different task? Both mechanism could work together.

I would prefer to keep this task/request simple. So just solve the immediate problem for code editors that came from resolving T101075 request. Which was when behaviour of suggested parameters changed. This immediately resulted in braces like "{{{location}}}" showing up for readers of Polish Wikipedia in infoboxes. As you might know this showed up when a parameter could be empty, but were expected to be present in the wiki-code. Also wiki-code users reported this is bad for their editing UX because popular parameters are not in the code (and so it is not easy to fill an infobox without going to template description for available parameters). This, in turn, caused tension between VE and wiki-code users -- wiki-code users added required flag to parameters, but then VE-users would get a message that they have to fill location, or in a worse case - requirement to fill date of death for a living actor 😉...

I did a quick patch to resolve this conundrum, but I'm afraid it will brake in case of any big changes. And I heard you want to refactor template forms in near future. So I would like to have a more stable solution to these problems sooner rather than later.

I agree. What I like so much about your proposal is that it's so simple and powerful the same time. Unfortunately my team is currently not able to invest resources into this.

Not to start these discussions again – I know all of this was certainly discussed a lot – but it sounds like at least some of the issues you mention should be solvable:

• When something like {{{location}}} shows up in an article that's a mistake in the template's code, in my humble opinion. It should be {{{location|}}}.
• Wikitext users can briefly switch to VisualEditor to add parameters. This will become even easier with the changes to the template dialog we are going to deploy soon.
• A possible workaround is to mark a parameter with required="true" autovalue="-" and teach the template to ignore that specific auto-value. In case of the date of death it would be required="true" autovalue="not yet". 😉

Thank you for doing that @Nux. I'm sorry I haven't found the time to work on this from the TemplateData side :/