Wikimedia Bugzilla is closed!

When implemented, this should also accept an empty string as the "base" ("author" in original example above) to apply to unnamed (positional) parameters. Would be useful for some templates like [[pl:Template:Dopracować]] which currently can't be properly described using TemplateData.

In the module code they use # to represent a number placeholder.
numbered_arguments = {
    ['author#'] = true,
    ['Author#'] = true,
    ['author-first#'] = true,
    ['author#-first'] = true,
    ['author-last#'] = true,
    ['author#-last'] = true,
...
}
As you can see the number can be in various places.

http://en.wikipedia.org/wiki/Module:Citation/CS1/Whitelist

This proposal is based mostly on the idea that if TemplateData exists for a template, then editors should not be permitted to add any parameters that are not already in TemplateData.  

Rather than coding a variety of flexible naming/numbering schemes, it might make more sense to have a way to specify that a given template accepts (or does not accept) whatever parameters the editor chooses to name, regardless of what's in TemplateData.  If the TemplateData is complete and no unlisted parameters are useable, then editors could not add others.  If the TemplateData is incomplete, or if the number of parameters is unbounded, then editors could add whatever they wanted.

The foo1, foo2, foo3 etc. model exists in many templates, however in most cases the limit is quite low (when converted to Lua a user might have dropped the limit, no sure that is a good pattern). Only in cases where the value is for e.g. a table row do they have a high limit (up to 500 seems common).

e.g. 

{{Something
|row1=..
|row2=..
|row3=..
|=..

such as {{TemplateBox@commons.wikimedia.org
|p1=..
|p2=..
|p3=..
|..

However both for VisualEditor, TemplateData and any other modern program or programming language it is very visible that such dynamically named parameters are an unwanted pattern that should not be encouraged. It is hard to work with and only has downsides over alternatives (e.g. hard to re-order, requires hacks to implement in wikitext and lua, hard to document, hard to use).

Especially now that we have Lua, specifying a parameter as taking a list seems more sensible (e.g. comma separated, line-break separated, whatever). Even if a template isn't converted to Lua yet, it could make use of a generic Lua module to do the string split and iteration.

Also, in the interest of not implementing too soon and get stuck in a corner, I'd like to wait for VisualEditor to catch up with the features we've already recently added to TemplateData and see how those work out.

(In reply to Krinkle from comment #4)
> Especially now that we have Lua, specifying a parameter as taking a list
> seems more sensible (e.g. comma separated, line-break separated, whatever).
> Even if a template isn't converted to Lua yet, it could make use of a
> generic Lua module to do the string split and iteration.

This solution would be awkward when several parameters are related one to each other. For example, on the cite templates, you usually have several fields for each author (first name, last name, page link, ...) and they are easier to manage for a user if they are grouped.
With lists, users would have to be careful and to be sure that several lists are coherent between each other.

(In reply to NicoV from comment #5)
> This solution would be awkward when several parameters are related one to
> each other. For example, on the cite templates, you usually have several
> fields for each author (first name, last name, page link, ...) and they are
> easier to manage for a user if they are grouped.
> With lists, users would have to be careful and to be sure that several lists
> are coherent between each other.

One way to deal with this could be to pass JSON blobs into template parameters. So you could have:

{{cite web
| authors = { "last": "Smith", "first": "John" }, { "last": "Doe", "first": "Jane" }
}}

This is nice from a Lua perspective, but it would be confusing for users. Mixing template syntax with JSON syntax seems ugly, and probably only a select few editors will be capable of entering syntactically correct JSON into template parameters.

The established way of doing something like this is to use a sub-template. So we would have something like:

{{cite web
| authors = {{author|last=Smith|first=John}}, {{author|last=Doe|first=Jane}}
}}

One problem with this is that the {{author}} templates are expanded before they are passed to Lua, so we lose data granularity. To solve this, we can use Lua to make the {{author}} templates output JSON and then read that JSON from the Lua module implementing {{cite web}}. But then to guarantee that we get clean JSON code we would need to make a template structure like this:

{{cite web
| authors = {{author list | {{author|last=Smith|first=John}} | {{author|last=Doe|first=Jane}} }}
}}

With this we have data grouping that can be reliably processed by Lua and that editors used to using wikitext will find intuitive. However, this would be hard for VisualEditor etc. to process and display to users in a meaningful way, as there is no guarantee how the {{author list}} and {{author}} templates will be implemented on any given wiki. So, instead of using Lua to create the JSON, we could do it in PHP using a new parser function. (I suggest "#data".) That would give us the following: 

{{cite web
| authors = {{#data: {{#data:last=Smith|first=John}} | {{#data:last=Doe|first=Jane}} }}
}}

This would give us a data structure that could be reliably parsed from VisualEditor, as well as the other benefits mentioned above. Perhaps it could displayed as a dynamically generated data tree (I'm thinking about something like json2html, but editable).

http://visualizer.json2html.com/

We would need to be careful about bad input:

{{cite web
| authors = foo {{#data: bar {{#data:last=Smith|first=John}} | {{#data:last=Doe|first=Jane}} baz }}
}}

To sanitise this, we could make the #data implementation throw an error (perhaps like a cite.php error) for "bar" and "baz" in this example. For "foo", we could leave it to the Lua module to properly validate the input.

We would also have to think carefully about what to do with templates etc. inside #data parser functions. If template expansion inside #data parser functions worked the same way that it did in normal wikitext, it would be difficult to make #data work well in VisualEditor. But perhaps it can be made to work in the same way that VE handles other instances of templates in template parameters.

Hmm, I've messed up the JSON in the first example. Should be:

{{cite web
| authors = [{ "last": "Smith", "first": "John" }, { "last": "Doe", "first": "Jane" }]
}}

Perhaps this proves my point about users not being able to input JSON manually? :)