Page MenuHomePhabricator

TemplateData support for specifying parameters that are allowed to be empty
Open, Needs TriagePublic

Description

After the changes from T101075, when you add a template parameter in VisualEditor but leave its value empty, that parameter will be removed from the template transclusion. This is good in most cases, but some wikitext templates make a distinction between parameters that are not present at all, and parameters that are present but empty.

For those parameters we should be able to specify the desired behavior in TemplateData:

  • Allow empty parameter
  • Remove empty parameter
  • Unspecified (which would use the current behavior: remove empty parameter when it's newly added, otherwise allow)

Also, this needs to interact sensibly with required parameters: (I realize that these combinations are confusing, perhaps there's a better way to word this?)

  • When a required parameter is also allowed to be empty, VisualEditor should only ensure that it's present, but allow it to be empty
  • When a required parameter is supposed to be removed when empty, VisualEditor should allow it to be missing, but not allow it to be empty
  • When a required parameter's behavior when empty is unspecified, VisualEditor behave like it does now (ensure it's present, not allow it to be empty)

I'm not sure how this actually should be represented in the TemplateData JSON. Opinions welcome.

Use cases:

  • 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
  • Various templates on English Wikipedia and Wikisource (discussed in T101075#6859819), where empty parameter values are used to disable/suppress some parts of the output

Event Timeline

(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.

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.

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.