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.
Description
Description
Details
Details
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Final wiring for the new {{#statements|…}} parser function | mediawiki/extensions/Wikibase | master | +82 -21 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | thiemowmde | T142940 Create client functionality for getting human readable wikitext from Wikibase statements | |||
| Resolved | thiemowmde | T142941 Create a {{#statements:…}} parser function for human readable access to statements | |||
| Resolved | hoo | T147568 Create regression tests for the output of client data access functionality | |||
| Resolved | hoo | T147580 Use SnakFormatter::FORMAT_PLAIN for the current output of client data access functionality |
Event Timeline
Comment Actions
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!
Comment Actions
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.
Suggestions:
- {{#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.
Comment Actions
Change 316790 had a related patch set uploaded (by Thiemo Mättig (WMDE)):
Final wiring for the new {{#statementvalues|…}} parser function
Comment Actions
Change 316790 merged by jenkins-bot:
Final wiring for the new {{#statements|…}} parser function