This doesn't seem like it needs access to the template frame stack (which is why we initially filed it under missing functionality) -- the {{ptag}} template is just:

<indicator name="phabricator-project">{{Badge|content=<translate><!--T:1--> [[<tvar name=1>Special:MyLanguage/Phabricator</tvar>|Issue tracker]]:</translate> [[phab:tag/{{lc:{{{1}}}}}/|'''#{{{1}}}''']]
}}</indicator>

And it seems that we're not fully recursing into that complex wikitext. We're parsing *some* of it, since the [[Issue tracker]] link is coming out, but the [[phab:tag/...]] business isn't.

That's probably just a plain-old parsing error of some sort.

While this feels related to T347507: ParsoidExtensionAPI: Provide a new method for extensions to access enclosing template parameters, I don't think that is the problem.

The issue is that the preprocessor should have processed the contents of indicator, but the preprocessor doesn't know to do that because it doesn't know that indicator content is wikitext.

@cscott yes .. we both landed on the same conclusion. :)

The thing is, this seems to work fine on enwiki, at least in my sandbox:
https://en.wikipedia.org/wiki/User:Cscott/T348722?useparsoid=1

The only thing I haven't copied here is the <translate> tags of the original, so I'm suspecting some interaction between annotations and the link parsing.

Odder still: in https://www.mediawiki.org/wiki/User:Cscott/T348722?useparsoid=1 the entire indicator disappears.

A small reproduction for this issue can be made by creating a template with the content

<span><indicator name="ptag">{{{1}}}</indicator></span>

(and then calling it with an arbitrary argument).

The problem is that, when we render an indicator, we parse the content of the extension as an independent document via $extApi->extTagToDOM, where the template frame and template arguments are not available anymore.

Hence, fixing T347507 might actually resolve this issue (and at least solve the issue of the availability of the frame arguments - which could then be passed somehow as a context to extTagToDOM).

Another solution/workaround would be to add a config option to tell the preprocessor to preprocess extension source recursively, so that it's already resolved when arriving in the extension.

In T348722#9246987, @ihurbain wrote:

A small reproduction for this issue can be made by creating a template with the content

<span><indicator name="ptag">{{{1}}}</indicator></span>

(and then calling it with an arbitrary argument).

We could also add support for <indicator ... contents="{{{1}}}"> which would also solve the problem? For that matter, {{#tag:indicator|{{{1}}}|name=ptag}} should also work. The issue is that extension tag contents are explicitly "not wikitext" and so (in a purely formal sense) we shouldn't "expect" argument expansion to work inside there.

This also affects a template on wikivoyage; @ihurbain knows the details.

In T348722#9246523, @cscott wrote:

The thing is, this seems to work fine on enwiki, at least in my sandbox:
https://en.wikipedia.org/wiki/User:Cscott/T348722?useparsoid=1

The reported issue does show up on en.wp at AIV: