The CommunityConfiguration extension makes it possible to define controls, which makes it possible to render certain form fields in a special way in the editor. We use this capability for MediaWiki page titles, for example. Each MediaWiki page title can be represented as a string, which is how it is represented in the underlying JSON file.

However, we wouldn't be happy if admins only had a textbox to enter their title into – we can provide much more support, such as autocompletion. To make that possible, we need to tell the editor this is a special string, which should be interpreted as a MediaWiki title. With that information, the editor can add the autocompletion interface (or anything else we want to offer for page titles).

This is even more visible with namespaces. There are places where we want admins to specify a list of namespaces (such as, where the Help panel should be enabled). Internally, namespaces are being represented as integers, but we do not want admins to remember that (for example) 4 means the Wikipedia namespace. Instead, we use controls to tell the editor that this particular list of integers represents a list of namespaces, which allows us to render a meaningful interface for the administrators to use.

We already have support for controls implemented, however, we currently do not have any support for parameters. This means that each control will always work in the same way, regardless of the context it is implemented. In particular, the MediaWikiPageTitle control will always assume a namespace-prefixed input, even though in some contexts, we might want to limit ourselves only to templates, because we are expecting a template, and in that case, the prefix is meaningless. Or alternatively, we might be only interested in talk namespaces (so Wikipedia talk, but not Template). This limitation came up in T367493: Suggested edits Community configuration: Autocompletion for the list of templates in template-based tasks is confusing, decide on a fix, where we expect templates.

Within this task, we should expand our support for controls to take in parameters. That way, schema authors will be able to specify more details about how they want the control to work like.