Last modified: 2014-10-14 16:02:09 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T50799, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 48799 - #property: calls for non-existent properties should add a tracking category
#property: calls for non-existent properties should add a tracking category
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
WikidataClient (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Wikidata bugs
https://test2.wikipedia.org/w/index.p...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-24 23:39 UTC by Kunal Mehta (Legoktm)
Modified: 2014-10-14 16:02 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Kunal Mehta (Legoktm) 2013-05-24 23:39:44 UTC
Currently if you add something like {{#property:p1234234234}}, it simply returns a empty string. (Example: https://test2.wikipedia.org/w/index.php?title=Germany&diff=53273&oldid=53030)
It would be nice if we could add a tracking category to find these instances.

Same with {{#property:label}}, where no property actually uses the specified label.
Comment 1 Daniel Kinzler 2013-12-13 16:26:03 UTC
Well, what should the parser function return in an error case? It would have to be some pre-defined, fixed string, right? But that's not good when shown to the user. So, rather, an HTML formatted error? 

The reason that it currently returns an empty string is to indicate "there's nothing here", so it can be used in conditionals. If you need more fine grained info, you can use Lua.

I'd actually like a nice way to return more detailed status/error info from a parser function, but I don't see a good way to do that.
Comment 2 Lydia Pintscher 2014-10-13 14:24:55 UTC
Kunal: *poke* about Daniel's question
Comment 3 Kunal Mehta (Legoktm) 2014-10-14 15:55:31 UTC
(In reply to Daniel Kinzler from comment #1)
> Well, what should the parser function return in an error case? It would have
> to be some pre-defined, fixed string, right? But that's not good when shown
> to the user. So, rather, an HTML formatted error? 

Sure, that's reasonable. But probably deserves another bug?

> The reason that it currently returns an empty string is to indicate "there's
> nothing here", so it can be used in conditionals. If you need more fine
> grained info, you can use Lua.

Adding a tracking category won't prevent that.
Comment 4 Daniel Kinzler 2014-10-14 16:02:09 UTC
Yea, I didn't know how the "magic" tracking category feature worked when I wrote this. I was assuming it would be returned as wikitext. Calling ParserOutput::addTrackingCategory() would be fine.

Also, by now, I'm convinced that in case of an error, the parser function should return a localized, html formatted string wrapped in a span or diff using class="error". Because that can be detected with the {{#iferror}} function.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links