Page MenuHomePhabricator

Don't show conditionally included links on Whatlinkshere unless they're actually included
Closed, DeclinedPublic

Description

Author: ui2t5v002

Description:
If a template is conditionally included inside another template:

{{ #if: {{{nestedvalue|}}} | {{nested template}} }}

The "What links here" for the nested template will list every page its
containing template is in, even if the conditional for displaying the nested
template on that particular page was not met. For instance, if {{another
template}} contains the above line, and I use it in "Generic article" like so:

{{another template|nestedvalue=}}

The nested template is not actually called or included, but "Generic article"
will still show up in "What links here" for the nested template, and {{nested
template}} will still show up in "Pages transcluded onto the current version of
this page:" for "Generic article". It should only show up if the template is
actually called by the containing template (if the conditional is met).


Version: unspecified
Severity: normal
URL: http://en.wikipedia.org/wiki/Special:Whatlinkshere/User:Omegatron/nested_template

Details

Reference
bz8446

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 9:30 PM
bzimport set Reference to bz8446.
bzimport added a subscriber: Unknown Object (MLST).

ayg wrote:

Whatlinkshere is core, ParserFunctions are not. There's not really any way for
the core to know what a hook does with the stuff it's passed, at least not at
present.

robchur wrote:

I would class it as a pug (useful bug) - I can think of cases where it's useful.
For example, suppose the template was marked as deprecated? "What links here"
would be useful for tracing down all potential inclusions.

ui2t5v002 wrote:

(In reply to comment #2)

I would class it as a pug (useful bug) - I can think of cases where it's useful.
For example, suppose the template was marked as deprecated? "What links here"
would be useful for tracing down all potential inclusions.

I'm not sure I understand your example. Wouldn't you only need to be concerned
about the pages it was actually used on?

robchur wrote:

(In reply to comment #4)

I'm not sure I understand your example. Wouldn't you only need to be concerned
about the pages it was actually used on?

You'd want to remove all references to it, surely.

ui2t5v002 wrote:

(In reply to comment #5)

You'd want to remove all references to it, surely.

But there wouldn't be any references to it on pages it was not used on. Can you
explain your example in more detail?

This is about template A being conditionally nested inside Template B. When
template B is transcluded into a page, template A may or may not be called. But
the What links here for Template A lists every instance of template B instead,
whether it was called or not. If something happened to template A and you
wanted to see every instance of it, you'd only be interested in the instances of
B for which A was called.

ayg wrote:

But if no inclusion of template B happened to actually display template A,
template A wouldn't show up as being included in template B at all, and so if
you wanted to replace template A with template C, you would remove all other
references and then happily delete A. But then one day, someone calls B in such
a way as to call A . . . and A is deleted.

By the way, Rob, a useful bug is called a "feature". ;)

robchur wrote:

(In reply to comment #7)

By the way, Rob, a useful bug is called a "feature". ;)

Only if it's intentional. If it's unintentional, but actually produces a desired
or useful behaviour, then it's a pug.

ui2t5v002 wrote:

(In reply to comment #7)

But if no inclusion of template B happened to actually display template A,
template A wouldn't show up as being included in template B at all

A would still show up as being included in Template:B itself. But A should not
be listed for every page that includes B, unless that instance of B also
conditionally includes A.

(Sigh. This is fundamentally difficult to explain in words...)

references and then happily delete A. But then one day, someone calls B in such
a way as to call A . . . and A is deleted.

Even if that happened, I don't see a big problem. It would be immediately
obvious that A had been deleted.

A template's "What links here" should only lists pages that actually link there.
An article's "Pages transcluded onto the current version of this page" should
only contain templates that are actually transcluded onto the current version of
this page.

ayg wrote:

(In reply to comment #8)

(In reply to comment #7)

By the way, Rob, a useful bug is called a "feature". ;)

Only if it's intentional. If it's unintentional, but actually produces a desired
or useful behaviour, then it's a pug.

No, then it's a *retroactive* feature.

(In reply to comment #9)

A would still show up as being included in Template:B itself. But A should not
be listed for every page that includes B, unless that instance of B also
conditionally includes A.

So it would be conditional *indirect* inclusions only? Conditional *direct*
inclusions should still show up on whatlinkshere?

ui2t5v002 wrote:

(In reply to comment #10)

So it would be conditional *indirect* inclusions only? Conditional *direct*
inclusions should still show up on whatlinkshere?

Ummm.... I think? I lack a common language to discuss this. Let's be explicit.
Assume we have these pages/templates:

Template:Optionaltext
Template:Somebox
Article With Optional Text
Article Without Optional Text

Template:Somebox consists of something like this:
{{ #if: {{{testcondition|}}} | {{Optionaltext}} }}

In Article With Optional Text, {{Somebox}} is transcluded as such:
{{Somebox|testcondition=some text}}
{{Optionaltext}} is therefore also transcluded, because the conditional has been
met.

In Article Without Optional Text, {{Somebox}} is transcluded by itself:
{{Somebox}}
{{Optionaltext}} then does not appear anywhere in this article.

The Whatlinkshere for {{Somebox}} should list:
Article With Optional Text
Article Without Optional Text

The Whatlinkshere for {{Optionaltext}} should list:
Template:Somebox
Article With Optional Text

If you edit Article With Optional Text, it should list these templates as
transcluded:
Template:Somebox
Template:Optionaltext

If you edit Article Without Optional Text, it should list these templates as
transcluded:
Template:Somebox

ayg wrote:

That would be sensible, then, yes.

robchur wrote:

*** Bug 8524 has been marked as a duplicate of this bug. ***

To me as a user, the initially described bug seems to have gone away with the new parser and its short-circuit evaluation.

In comment #11, another issue was raised that "The Whatlinkshere for {{Optionaltext}} should list: Template:Somebox, Article With Optional Text". At the moment I believe it lists *only* "Article With Optional Text" and *not* "Template:Somebox" (cf. my sandbox at [[:de:Spezial:Linkliste/Benutzer:Tim.landscheidt/Template:Optionaltext]].

From a user's perspective, I would like to have "Template:Sandbox" listed there as well.

EN.WP.ST47 wrote:

The issue with what you're asking is that you want a template that transcludes (but has short-circuited out) another page to show up on the whatlinkshere, but you do /not/ want a page that transcludes that template (with the short-circuiting still in place) to show up on the whatlinkshere. The problem is that you want transclusions that are not evaluated are considered to be transclusions for the purposes of whatlinkshere only if the page actually includes the template call, and not if the template call is transcluded from somewhere else. One way to see this is that you are requesting different behavior based on whether Template:Somebox is or is not substituted in. While I see how your requested behavior could be useful in certain situations, it seems to me that it would break a few other bits, including that subst: does not alter how a page parses, and that two pages, both of which have a short-circuited call to a template, but one of which has that call via another template call, will behave differently with regards to that template. Since the initial bug was fixed with the new parser, I'm closing this worksforme.