TemplateData: Allow hinting to specify auto-numbered parameter names in some fashion
OpenPublic

Assigned To
None
Priority
Low
Author
NicoV
Subscribers
Jdforrester-WMF, matmarex, Whatamidoing-WMF and 9 others
Projects
Tokens
"Like" token, awarded by Ricordisamoa.
Reference
bz52582
Description

Some templates use numbered arguments (see for example http://en.wikipedia.org/wiki/Module:Citation/CS1/Whitelist in the numbered_arguments list). For example, you can use author1, author2, ... (no limit).

Currently, there's no way to define such parameters in TemplateData, and the VE interface is not also optimal for them.

Would it be possible to handle numbered arguments in TemplateData: a parameter named author# would define a numbered parameter named author with a numerical suffix. It should be possible to define lower bound (1 by default) and upper bound (no limit by default).

Then VE should handle them accordingly: only propose the first parameter available in the list of parameters than can be added.


Version: unspecified
Severity: major
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51740

bzimport added a project: TemplateData.Via ConduitNov 22 2014, 1:55 AM
bzimport set Reference to bz52582.
NicoV created this task.Via LegacyAug 6 2013, 4:08 PM
matmarex added a comment.Via ConduitAug 6 2013, 4:14 PM

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.

SalixAlba added a comment.Via ConduitAug 6 2013, 9:07 PM

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

Whatamidoing-WMF added a comment.Via ConduitAug 8 2013, 5:34 PM

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.

Krinkle added a comment.Via ConduitOct 6 2013, 5:17 PM

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.

NicoV added a comment.Via ConduitFeb 19 2014, 7:38 AM

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

MrStradivarius added a comment.Via ConduitSep 7 2014, 2:10 PM

(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 = {{authorlast=Smithfirst=John}}, {{authorlast=Doefirst=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{{authorlast=Smithfirst=John}}{{authorlast=Doefirst=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=Smithfirst=John}}{{#data:last=Doefirst=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=Smithfirst=John}}{{#data:last=Doefirst=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.

MrStradivarius added a comment.Via ConduitSep 7 2014, 3:08 PM

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? :)

Ricordisamoa added a subscriber: Ricordisamoa.Via WebJan 12 2015, 9:47 PM

Would be very useful also for, e.g., https://www.mediawiki.org/wiki/Template:Extension#TemplateData (up to hook48!)

Ricordisamoa awarded a token.Via WebJan 12 2015, 9:47 PM

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.