Last modified: 2013-08-26 23:29:45 UTC
Currently TemplateData support a Default Value in its specification, but it would be convenient to amend this with a set of suggested values. These values could be served to the user trough a combobox (Input + Dropdown) where one could either type a value, or select one from the dropdown list. Rationale for this: Many templates a small set of accepted values for a single parameter. For example, [[Template:Coord]] contains the "Display" parameter that accepts the values "Inline", "Title" and "Inline+Title". Having these in a dropdown would be more convenient then having to type them (Which would require browsing to the documentation as well). The same applies to the "Type" parameter in that template, which has multiple values as well. I suppose this could use three parameters: * ParameterName (The name of the parameter) * Alias (The non cryptic name of the parameter, displayed in the dropdown) * Description (A help text that displays what the parameter value does / is intended for)
Would we want to do this as an enumerated type? E.g. type: "type": "enumerated", "values": ["one","two","three","four","five"] Values could possibly be used as example values for other types as well.
*** Bug 51074 has been marked as a duplicate of this bug. ***
From bug 51074 comment 0: | A lot of templates have arguments that are effectively enumeration types. | Using the singlechart template from English Wikipedia as an example, the | first argument has a limited range of actual values: things like UKrock, | UKdance, UKdownload, Billboardhot100, etc. The template is structured as a | switch statement that only does anything useful if it recognises the chart | name. Otherwise, it just spits out a big red error message. | | It would be good if I could encode that in the template data, something | like | | "1": | { | "label": "Chart identifier", | "description": "Chart name: recognized values are listed at", | "type": "enum", | "values": | { | "UKrock", "UKdance", "UKdownload", "Billboardhot100" | } | "required": true | } | | The template edit should then not allow freeform text entry while entering | the template. Instead, it should provide a menu selection that only allows | the editor to enter one of the recognized values.
I suppose it may be a good idea to add an alias field as well. Some templates use short or numerical notations that would be difficult to understand without a different label. For example: [[Template:Icon]]. The parameter list would be something akin to this: { "FLRC", "FLR", "FFLC", "ACC", "GAH", "GAR" } This would already be rather messy to work with (Not even considering what new editors might think when they saw this). However, if i had a template that stated {1,2,3,4,5} while these values represented "Accepted", "Rejected", "Fixed", "Unresolved", "New" a dropdown containing these numbers would only be confusing. Instead, i suppose one would want: { "1", "New" "2", "Accepted" "3", "Resolved" "4", "Fixed" "5", "Rejected" } The right column would be the value displayed in the dropdown, the left column would be what the Visual Editor would pass to the template as the parameter.
At this time I don't think we include a system for "suggested" value in the TemplateData specification. There are various other new features coming soon. Remember that we can always add more, but removing is very hard. Let's get some of that other stuff done first and we can revisit the use cases and need for this later, once there are some alternatives that themselves have more pressing use cases.
I don't understand why you think this a low priority feature. A large number of templates support enumeration types, and there's no reason for an editor designed to aid inexperienced editors to allow them to enter data into a template that the template will simply reject.
*** This bug has been marked as a duplicate of bug 51375 ***
@kwwilliams: I'm saying the principle of *suggesting* values (while still being able to provide a custom value) is low priority. The principle of a fixed number of options (e.g. a select dropdown) is not low priority. However due to wikitext legacy, we'll never be able to fully restrict selection, so I'm marking this as duplicate of bug 51375, which is not low priority.
