Change 263655 had a related patch set uploaded (by Alex Monk):
[WIP] Add a parameter key to limit possible valid values to a given set

https://gerrit.wikimedia.org/r/263655

Change 263655 abandoned by Alex Monk:
[WIP] Add a parameter key to limit possible valid values to a given set

https://gerrit.wikimedia.org/r/263655

That's something which would be extremely useful.

I'm currently working on a proposal for ease Wikitionary contribution through templatedata. Such a feature would for example allow to select word category (verb, adjective…).

It would also be useful to be able to use a set of possible values provided by some template/module.

Is this still on the docket? It's vital. Is there some other way of specifying valid string values in TemplateData (TD)? If not, that would appear to be a large oversight if TD is supposed to help users easily interact with template params

Change 263655 restored by Krinkle:
[WIP] Add a parameter key to limit possible valid values to a given set

https://gerrit.wikimedia.org/r/263655

A suggestion from https://www.mediawiki.org/wiki/Topic:Ve06hyihctm4p86n is to allow labels different from the actual value. It can be stored for example with:

"params": {
	"key": {
		"type": ...,
		"values": [
			{"label": ..., "value": ...},
			...
		]
	}
}

Maybe plain strings should also be allowed for convenience, which could be transformed by the extension to

{"label": null, "value": ...}

form. (I’d also suggest to always display the actual value in addition to the label, but that’s up to the consumers, of course.)

In T53375#5769182, @Tacsipacsi wrote:

			{"label": ..., "value": ...},

where the label should be an InterfaceText (i.e. localizable) or null; like all other InterfaceTexts, plain string input should be accepted and transformed by the extension. The value is a plain string, of course.

If I have a template that accepts three values for foo and renders an error if given anything else, would the user be able to enter a disallowed value using the "suggested values" user interface in such a way that they will not be surprised or dissapointed to see an error in the rendering – after they have saved their changes in the template dialog?

If I understand correctly, the "suggested value" feature is about autocompleting and/or recommending values in a free-form input field, and does not intend to add friction, make impossible, or "power-user only" to enter other free-form values, e.g. a basic HTML select field with no easy way to break out of it, unless the page had a pre-existing unexpected value that VE would need to accomodate for roundtrip. That is what an "options" or "ENUM" feature would be like in the end, I think.

Having said that, implementing suggested values first is fine of course. And depending on the kind of user experience you want to deliver, it might even make sense to provide both of these as part of the same single input type, with a toggleable restriction for free-form values (allowOther: false?). There are many ways to implement these two features differently and I don't think it's obvious that they'll be similar in logic and look, but it is also possible to make them similar/shared. Whether that's the best UX, I don't know. Something to consider I suppose :)

we should distinguish between visualeditor and templatedata.
templatedata provides a syntax to describe the template behavior, and is used not just by visualeditor, but other tools too.

whatever VE decides to do with "illegal" values is an interesting question, but TD itself should allow distinction between "suggested values" and "legal values", because the template syntax itself makes this distinction. VE can ignore this distinction or not, but TD should provide this information.

suggestedvalues serves templates that use {{#switch, and there are several different behaviors when param value is not present as one of the options:

• the switch may have #default, which does something useful - IOW, an "unsuggested" value is still legal
• it can have no #default, practically ignoring the value
• the #default can trigger an error.

TD syntax should allow better description of the behavior, so, e.g., "template linting" tools can detect and flag pages where a template with "suggested values" is used with "unsuggested" value: it can be an error worth flagging (2nd and 3rd cases above, where suggested values really means legal values), and not flag it for parameters whose behavior match the 1st case.

this is not a theoretical/hypothetical issue - such tools exist, and are used on several projects (see, e.g., Module:ParamValidator on hewiki and yiwiki).

peace.