Last modified: 2014-01-15 22:19:08 UTC
Any call to the API with action=query, prop=revisions, rvprop=content, and rvexpandtemplates=true does not have expanded templates in the content when that template is contained within <ref></ref> tags. To reproduce, just make any such call to the API. For example: http://en.wikipedia.org/w/api.php?action=query&prop=revisions&titles=Train&rvlimit=1&rvprop=content&redirects=true&rvexpandtemplates=true Note that the templates within <ref> tags are not expanded: <ref>{{cite web | title = Train (noun) | work = (definition - Compact OED) | publisher = Oxford University Press | url = http://www.askoxford.com/concise_oed/train?view=uk | accessdate = 2008-03-18}}</ref> It should instead expand the template like this: <ref><span class="citation web" >[http://www.askoxford.com/concise_oed/train?view=uk "Train (noun)"]. ''<nowiki />(definition - Compact OED)<nowiki />''. Oxford University Press<span class="printonly">. http://www.askoxford.com/concise_oed/train?view=uk</span><span class="reference-accessdate">. Retrieved 2008-03-18</span>.</span><span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.btitle=Train+%28noun%29&rft.atitle=%28definition+-+Compact+OED%29&rft.pub=Oxford+University+Press&rft_id=http%3A%2F%2Fwww.askoxford.com%2Fconcise_oed%2Ftrain%3Fview%3Duk&rfr_id=info:sid/en.wikipedia.org:API"><span style="display: none;"> </span></span></ref> This has no good workaround; the best I can find is to grab all of the unexpanded templates and feed them into another call to the API with action=expandtemplates and text=(the templates), which is not very good not only because it's extra hassle, but also because it requires twice as many calls to the API, which inevitably slows things down considerably. Build 2010-08-12 on Windows 7 Enterprise (though it being the result of an API call, I would imagine it reproduces anywhere)
*** This bug has been marked as a duplicate of bug 2257 ***
Perhaps I'm missing something, but I don't really see how this is a duplicate of bug 2257, since that bug is about letting the template parameters be expanded when rendering the tag extensions, where this bug is about the templates inside <tag> extensions aren't expanded by the rvexpandtemplates parameter of the api. Arguably i don't think they should be expanded, but i don't think the bugs are the same.
I definitely would not call this a duplicate of bug 2257. The problem in this bug is not that I *can't* expand the templates between <tag> extensions; the problem is that it requires two calls to the API for me to do so, which for large pages slows things down considerably. The workaround described in bug 2257 doesn't help with this problem at all, since the wiki markup in your standard wiki page does not make use of the {{#tag:ref|...}} template. I suppose the question does then present itself regarding whether or not one would expect those templates to be expanded, but intuitively if I tell the API to "expand templates", it seems to me that *all* templates should be expanded - that's what I'm looking for when I pass in that argument, after all.
See also https://bugzilla.wikimedia.org/show_bug.cgi?id=2700
This is a duplicate of bug 2257 because both are caused by the same underlying issue, which is that template calls inside <ref> tags are not expanded in the template expansion (preprocessor) phase, which happens before the <ref> expansion (parser) phase. &rvexpandtemplates=true runs wikitext through the preprocessor but not through the parser. *** This bug has been marked as a duplicate of bug 2257 ***
(In reply to comment #5) > This is a duplicate of bug 2257 because (...) This is definitively not a duplicate. While bug 2257 is RESOLVED FIXED, this bug remains. See for example: https://en.wikipedia.org/w/api.php?action=query&prop=revisions&titles=Wikipedia&rvprop=content&rvexpandtemplates All templates are expanded, except those inside <ref></ref> tags. I think it may be dependent of bug 2700, so fixing 2700 may also fix this. But let's give this bug open since it's a consequence of 2700, not *the same* bug
