If it's not too difficult to implement, it would be useful for the tracking to distinguish between parser functions/tags added by a template or module, and those added directly to pages. Some wikis may prefer certain tags only be added in one way or another, and currently, even with Wikia's Special:TagsReport, there is no easy way to make this distinction. This would also provide a concrete use for this tracking, at least for those wikis with such a policy.
Talk:Requests for comment/Parser function and tag tracking
I'm not sure if this is really possible. Consider {{1x|<code>foobar</code>}}. The code tag is being output by the template, but in reality it's coming directly from the page.
I think your use case of ensuring tags aren't used in the source is best implemented by wikitext search (insource operator).
I thought that might be the case, but was hoping there might at least be a partial solution that would suffice for the majority of the time. Of course, it's not like I'm any more a fan of partial solutions than anyone else...
It would probably require adding depth tracking to PPFrame and logging when a parser function with depth = 0 is expanded. It does not seem that hard.
OTOH something like <tag/> in {{#if:<!--false-->|<tag/>}} would not be tracked since the parser never even processes it as it's on a dead branch.
The linter extension can be leveraged for this functionality -- since the real use case seems to be for managing upgrades / deprecation, etc. Is there a reason not to go down that route?
Mostly a conceptual one - Linter tracks errors, and these aren't errors.
Right .. but, that is just a naming issue for the extension and special page? For example, for migrating templates to new syntax or for balanced usage, we need to track pages that use that. So, technically those are not errors, and we want to use the parsoid - linter combination. So, if these were renamed appropriately, would that address it?
To be clear, I am not saying you shouldn't create that new special page .. but, asking the question if there is a way to consolidate these where possible.
Or, to put it differently, barring that deprecation / maintenance use case, what value is there in knowing what pages use which tags? It just seems to create another SpecialPage that is mostly not useful day-to-day. Aggregate statistics followed by linter categories would probably do the trick in the common case?
> what value is there in knowing what pages use which tags? It just seems to create another SpecialPage that is mostly not useful day-to-day.
It is valuable to track if certain tags are used in certain namespaces. For instance, despite being discouraged, even on big wikis such as english wikipedia there are users adding stuff like {{#if within the main namespace. There are also use-cases that aren't covered here, for example, tracking whether a new page has <ref> / <references>. If available in page props this could probably be simple to add to recentchanges / special:newpages, etc. Currently, pagetriage seems to use a hacky approach of parsing the whole page, and can't detect those included by modules or templates.
It seems like this is case where one should have the best of both worlds. Track tags using page props, and use a white list of parser functions / tag functions in the linter extension that could be nuked ( e.g. easytimeline -.> ext:graph).
Of course Special:PagesWithProp would still need several improvements. Currently it can't filter namespaces, nor can it display more than 10000 items. Its items are also not indexed by the search engine (unlike tracking categories). Generally speaking though, if page props is improved then tracking categories should probably be fully removed from mediawiki itself and its functionality added to pageswithprops / linter . Rather duplicating functionality, e.g. "category:pages with graph" <-> graph_specs (page props), category:pages with self closing tags< -> self closed tags(linter).
Having this functionality also track parser functions/tags that aren't actually supported (and thus are just output as plaintext by the parser) would aid in day-to-day wiki maintenance. If this can be and is added, it would probably be a natural fit for Linter.
I think this makes sense for Linter, in the sense that unrecognized tags are an error, but I would not want to implement this as part of this RfC, which is just limited to parser functions and tags that exist.
There are no older topics