Last modified: 2014-06-20 18:08:45 UTC
Not sure if this is TemplateData or VisualEditor, please move it if I’m wrong. If I edit a page where a redirection to a template is used, I don’t see the available parameters and other data that TemplateData provides, but the redirection works like the real template, so it should use the same data.
*** Bug 51791 has been marked as a duplicate of this bug. ***
Note from bug 51791 fwiw: this issue is being discussed at http://en.wikipedia.org/wiki/Wikipedia_talk:VisualEditor/TemplateData#What_about_redirected_templates
Both VE and TemplateData should address this in their own way. Both parties need to do something. 1) Resolve redirects in API interaction: - TemplateData should have an option to resolve redirects in the given titles (like action=query). the mapping will be added similarly to how we normalise titles. - Then the VisualEditor needs to use this map as the API response will put the templatedata for the target title, not the title queried. We do this already with normalised titles, so we can extend that to include redirects in that "aliasing" logic for normalised titles. 2) Parsoid giving TemplateData the transcluded page name instead of the wikitext invocation. - Right now we sometimes get wikitext instead of a page name, or (in case of redirects) the sourced page name, not the one actually transcluded. - If/when Parsoid is able to know what the wikitext expands too etc. (not a blind call to the PHP parser as it is essentially now) this will make that a lot easier and also solve generated transclusion target page names (e.g. {{ {{foo}} }} ).
Should a new bug for the Parsoid part be filed, so that the Parsoid team to do their part of this? This is a very big issues as some of the most common templates like the iconic {{cn}} are redirect and was asked about again at http://en.wikipedia.org/w/index.php?title=Wikipedia%3AVisualEditor%2FFeedback&diff=575686867&oldid=575662727
This is a little tricky on the Parsoid end since Parsoid gets the PHP preprocessor to expand template source for us (which we then parse and process). So, Parsoid never sees the redirect that are embedded in templates (like {{cn}}). So, this will require us to instrument the PHP preprocessor to provide Parsoid with this information. Offhand, I cannot think of any efficient trick that will solve this. So, I think approach (1) above where TemplateData adds redirection info and VE uses that might work for the common case where the redirect target is not a function of template args.
We have been talking about returning more metadata like the list of used templates from the PHP preprocessor, and use that for dependency tracking. Even with that info I'm not convinced that we should attempt to directly skip redirects in Parsoid, as that would add a lot of complexity and unexpected behavior. It should not be that hard to handle this in TemplateData itself, and to me it looks like the best place to do it.
This is still a major usability issue with templatedata as template redirects are quite common. Any update?
(In reply to Krinkle from comment #3) > Both VE and TemplateData should address this in their own way. Both parties > need to do something. > > 1) Resolve redirects in API interaction: > - TemplateData should have an option to resolve redirects in the given > titles (like action=query). the mapping will be added similarly to how we > normalise titles. This is a built-in feature in ApiPageSet, which is used by ApiQuery modules, as well as by ApiTemplateData. When enabled, passing &redirects to the request resolves redirects.
Change 135064 had a related patch set uploaded by Alex Monk: Allow following of redirects via API https://gerrit.wikimedia.org/r/135064
Change 135065 had a related patch set uploaded by Alex Monk: Follow redirects when looking up template data https://gerrit.wikimedia.org/r/135065
Change 135064 merged by jenkins-bot: Allow following of redirects via API https://gerrit.wikimedia.org/r/135064
Change 135065 merged by jenkins-bot: Follow redirects when looking up template data https://gerrit.wikimedia.org/r/135065
Confirmed fixed in 1.24wmf7, yay :-)
Per report. ;-)
