Page MenuHomePhabricator

Create a {{#statements:…}} parser function for human readable access to statements
Closed, ResolvedPublic


Invocation should be identical to the {{#property:…}} parser function, but the output format differs, so that for example external ids are outputted as linked wikitext.

Event Timeline

hoo created this task.Aug 14 2016, 5:20 PM
hoo updated the task description. (Show Details)
hoo renamed this task from Create a {{#statement:…}} parser function for human readable access to statements to Create a {{#statements:…}} parser function for human readable access to statements.Aug 24 2016, 7:07 PM
thiemowmde triaged this task as Medium priority.Sep 5 2016, 3:19 PM
thiemowmde added a subscriber: thiemowmde.

I wonder what this ticket is about, what's not already covered and discussed in the parent task T142940 and the subtasks T58763 and T99897? I believe the dependency chain is a bit derailed: The new parser function must be implemented first before we can teach it specific things. So it must be a blocker for T58763, for example.

Note that discussion about the name of this new parser function is not here but on T142940!

thiemowmde added a comment.EditedOct 19 2016, 12:42 PM

Discussing the name for the new parser function. Note that it should be similar to the corresponding Lua function, see T142942.

  • {{#property:…}} is the existing sibling of the existing formatPropertyValues Lua function.


  • {{#statement:…}} (singular)
  • {{#statements:…}} (plural)
  • {{#dataValue:…}}
  • {{#dataValues:…}}
  • {{#formatPropertyValue:…}} (singular)
  • {{#formatPropertyValues:…}} (plural) sounds nice, but can be heavily confusing because it is identical with the opposite (!) Lua function.
  • {{#formatted:…}}
  • {{#formattedProperty:…}}
  • {{#formattedValue:…}}
  • {{#propertyHTML:…}}
  • {{#propertyOutput:…}}
  • {{#propertyText:…}}
  • {{#propertyValue:…}}

Discussed with @Lydia_Pintscher today. Arguments to consider:

  • The new function lives in a context with other parser functions by other extensions. It must be obvious that our function is related to Wikidata. This is achieved by using a Wikidata-specific term.
    • Candidates are: "claim", "data", "datavalue", "entity", "item", "property", "snak", "statement", "value", "wikibase", "wikidata".
    • "item" is out, because the function is not limited to items.
    • "wikidata" is out, because the function will be used on installations that have no connection to Wikidata.
    • "wikibase" may be confusing for users expecting "wikidata".
    • "data", "datavalue" and "value" are, when used alone, not Wikidata-specific enough.
    • "snak" is out, because a snak does not contain the rank, but picking the "best" statements by rank is a crucial feature of both the old and the new function.
    • We tend to avoid "claim" nowadays.
  • The new function should be named like it is the default.
    • The name should not sound like it's something special, and not create the impression that you should prefer the existing (more generic) function.
    • The new name must not be consistent with the existing one. We are allowed to make a decision like the other function does not exist.
  • It should be plural to make it obvious that you may get multiple values (currently comma-separated).
  • Other parser functions neither use dashes nor CamelCase.

This leaves me with {{#statementvalues|…}} and formatStatementValues.

Further discussed with @hoo and @Lydia_Pintscher. Decided for {{#statements|…}} and formatStatements.

Change 316790 had a related patch set uploaded (by Thiemo Mättig (WMDE)):
Final wiring for the new {{#statementvalues|…}} parser function

thiemowmde moved this task from Backlog to Review on the Wikidata-Sprint-2016-10-12 board.

Change 316790 merged by jenkins-bot:
Final wiring for the new {{#statements|…}} parser function

thiemowmde closed this task as Resolved.Oct 24 2016, 2:44 PM
thiemowmde removed a project: Patch-For-Review.
thiemowmde moved this task from Review to Done on the Wikidata-Sprint-2016-10-12 board.