Last modified: 2014-09-23 23:43:48 UTC
Hallo! at FiverAlpha "Template:This_version" is a nested template containing {{this_version/version}} {{this_version/installed}} {{this_version/last_update}}<br /> because the content of "Template:This_version/installed", "Template:This_version/version" and "Template:This_version/last_update" is used in another context two. {{subst:this_version}} will generate {{this_version/version}} {{this_version/installed}} {{this_version/last_update}}<br /> *The requested:* {{subst:this_version}} should be equivalent to {{subst:this_version/version}} {{subst:this_version/installed}} {{subst:this_version/last_update}}<br /> in this particular example. This would be used to reference to the configuration valid at a certain time. As a general request *{{substall:foo}}* should make a general substitution at *all* levels. It should be possible to the user to use either {{substall:foo}} *or* {{subst:bar}} depending on the context and of the used templates. Best regards Reinhardt [[user:gangleri]]
Another example is at [[id:template_talk:Userbox]] where double substitution was required to see / understand the code. {{substall:foo}} would realy help to save some time.
Templates that use [[m:ParserFunctions]] would benefit a lot from {{substall:...}}, as with subst, #if & Co. are not evaluated and inserted verbatim into the subst target location. See for example [[en:template:afd]] which is regularly substed on a lot of pages. Another example is [[en:template:cite book]] which leaves an unmaintainable mess of #if constructs when users subst that. OTOH it might be possible to just "subst" #if & Co without the introduction of that new "substall". It makes not that much sense to insert a #if into the subst target location if that could be eliminated entirely (i.e. optimized away at subst time).
I would suggest that {{subst:subst:...subst:This version}} would be a better way to format it. It gives the user more control. Either way, it makes sense that if Parserfunctions aren't dealing with variables (e.g., {{CURRENTYEAR}}), they should subst automatically when their including template is substed.
Apparently "substall" could work for "switch" and "ifdef", but not "ifndef" (and therefore also not "qif"). I'm not sure about "#if:", see [[mediazilla:5678]].
(In reply to comment #4) > Apparently "substall" could work for "switch" and "ifdef", but not "ifndef" (and therefore also not "qif"). I'm not sure about "#if:", see [[mediazilla:5678]]. Could you give an example that would prove your claim about [[en:template:qif]]? Why should substall not work for "#if:"? If I feed constants into templates, then these are also fed into #if: et al. So all expressions are known and can be evaluated and thus can be replaced with their results. Example: "{{subst:#if:bla|green|blue}}" *is* replaced with "green" and "{{subastall:#if:bla|{{#if:|yellow|pink}}}}" *could* be replaced with "pink".
(In reply to comment #3) > I would suggest that {{subst:subst:...subst:This version}} would be a better way > to format it. It gives the user more control. That would require too much knowledge of how the template works. It would be a nice feature in addition to {{substall:}}, though. > Either way, it makes sense that if Parserfunctions aren't dealing with variables > (e.g., {{CURRENTYEAR}}), they should subst automatically when their including > template is substed. Variables are also capable of being subst'd. Anything subst'd is generally expected to remain constant, so not subst'ing variables is not that great of an idea in my opinion.
(In reply to comment #6) > Anything subst'd is generally expected to remain constant Not necessarily. If, for instance, I subst a template containing something like "All works first published in the United States whose authors died before {{#expr: {{CURRENTYEAR}} - 70}} are in the public domain.", I'd want the year to update. It wouldn't update anyway unless the page's cache were cleared, and it might be better as a matter of policy to transclude, but you can't make the assumptions that people would never want to do something like that. If the argument is constant, however, you'd always want to just print the result, unless you intend to modify the argument or conditional after editing (which is probably a rare enough case that it can be put aside; almost always in such a case you could edit the result as easily as the function itself).
(In reply to comment #7) > (In reply to comment #6) > > Anything subst'd is generally expected to remain constant > > Not necessarily. If, for instance, I subst a template containing something like > "All works first published in the United States whose authors died before > {{#expr: {{CURRENTYEAR}} - 70}} are in the public domain.", I'd want the year to > update. It wouldn't update anyway unless the page's cache were cleared, and it > might be better as a matter of policy to transclude, but you can't make the > assumptions that people would never want to do something like that. > > If the argument is constant, however, you'd always want to just print the > result, unless you intend to modify the argument or conditional after editing > (which is probably a rare enough case that it can be put aside; almost always in > such a case you could edit the result as easily as the function itself). (In reply to comment #7) > (In reply to comment #6) > > Anything subst'd is generally expected to remain constant > > Not necessarily. If, for instance, I subst a template containing something like > "All works first published in the United States whose authors died before > {{#expr: {{CURRENTYEAR}} - 70}} are in the public domain.", I'd want the year to > update. It wouldn't update anyway unless the page's cache were cleared, and it > might be better as a matter of policy to transclude, but you can't make the > assumptions that people would never want to do something like that. > > If the argument is constant, however, you'd always want to just print the > result, unless you intend to modify the argument or conditional after editing > (which is probably a rare enough case that it can be put aside; almost always in > such a case you could edit the result as easily as the function itself). (In reply to comment #7) > (In reply to comment #6) > > Anything subst'd is generally expected to remain constant > > Not necessarily. If, for instance, I subst a template containing something like > "All works first published in the United States whose authors died before > {{#expr: {{CURRENTYEAR}} - 70}} are in the public domain.", I'd want the year to > update. It wouldn't update anyway unless the page's cache were cleared, and it > might be better as a matter of policy to transclude, but you can't make the > assumptions that people would never want to do something like that. > > If the argument is constant, however, you'd always want to just print the > result, unless you intend to modify the argument or conditional after editing > (which is probably a rare enough case that it can be put aside; almost always in > such a case you could edit the result as easily as the function itself). Of course, I don't mean to say that {{substall:foo}} or {{subst:subst:...foo}} shouldn't subst variables. I'm saying that {{subst:foo}} should *not* automatically subst all variables within the substed text, but it probably *should* subst all parserfunctions in the substed text that have constant articles.
The "optional recursive substitution" explained on [[Help:Substitution]] (use the Meta version) can emulate "substall" in some cases where it doesn't collide with [[mediazilla:5678]]. It's tricky, for a good solution 2777 might depend on 5678.
> The "optional recursive substitution" explained on > [[Help:Substitution]] (use the Meta version) can > emulate "substall" in some cases where it doesn't > collide with [[mediazilla:5678]]. It's tricky, for > a good solution 2777 might depend on 5678. I'm afraid this solution is not good enough, as we need to modify a lot of templates. Plus, if the substall is coded, we'll have to revert those templates. I hope you guys can make it.
*** Bug 8081 has been marked as a duplicate of this bug. ***
You can now use the ExpandTemplates extension to perform the requested recursive substitution.
*** Bug 9470 has been marked as a duplicate of this bug. ***
*** Bug 9499 has been marked as a duplicate of this bug. ***
See also #2003, which would make resolving this bug much easier.
Extension:SubstAll committed in r38054
Dear friends; innocentkiller has marked this bug as fixed : https://bugzilla.wikimedia.org/show_activity.cgi?id=2777 [[testwiki:template:bugzilla/002777]] shows that there is no {{substall:foo}} beside {{subst:bar}} . Please provide some syntax exmples about the usage at WikiMedia Foundation wikis. Thanks in advance! REOPENing this bug. refference link: http://www.mediawiki.org/w/index.php?title=Special%3ASearch&search=SubstAll&fulltext=Search
(In reply to comment #18) > Dear friends; > > innocentkiller has marked this bug as fixed : > https://bugzilla.wikimedia.org/show_activity.cgi?id=2777 > > [[testwiki:template:bugzilla/002777]] shows that there is no {{substall:foo}} > beside {{subst:bar}} . > > Please provide some syntax exmples about the usage at WikiMedia Foundation > wikis. > > Thanks in advance! REOPENing this bug. > He closed the bug because he wrote an extension that provides {{substall:}}. If you want this extension to be enabled on Wikimedia wikis, file a separate bug for that. Reclosing.
I don't know why I ever thought that was a viable solution, deleted the extension in r61588. Should be done (if at all) as part of PST, not some crappy hook on ArticleSave. REOPENING.
Drop the idea of {{substall:}} and introduce {{substthis:}} instead. That would allow you to specify what templates inside a template should be be subst'ed when subst'ed, otherwise, do not subst. Why? Imagine you having a template inside this template situation that you do NOT wish to subst. That would make this feat pointless, this is a much better solution.
Created attachment 7259 [details] A (hacky) patch I've attached a patch showing how it might be possible to implement this currently. This patch is NOT well tested, and NOT complete, but should give an idea, and works for simple cases. <Technical> The problem, as can be seen, is that there is no provision for statefulness in ther Parse on a level higher than the Preprocessor. While one could add these as properties of the Frame objects, (even for this simple case as yet another flag) it would be compounding the two levels of parsing. Adding provision for higher level state is also blocking other similar bugs. (Like int: not tracking language, being able to act based on template call stack from wikitext etc.) The price for this of course means more work for the parser, it also reduces (albeit slightly for this particular case) caching opportunities. While I think something like this is the way forward, it needs a lot of care and attention before it can be implemented. </Technical> For this bug itself, I am not convinced it should be fixed. A much nicer solution would be to use {{{|safesubst:}}} at strategic points in your templates http://en.wikipedia.org/wiki/Help:Subst#safesubst:
I was rather unplesently surprised that subst: stopped at the first level I always assumed the saved text would be the same as what I get from Special:ExpandTemplates. Hopefully substall: would fix it. The {{{|safesubst:}}} solution, as far as I understand it, works only if you alter all the sub-templates used by your main one. Because of that it is not very practical in a lot of cases.
*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*
Adding the "need-review" keyword for patches that need review by developers. Conrad, thank you for your patch, and sorry it's taken so long for a response on this!
(In reply to comment #25) > Adding the "need-review" keyword for patches that need review by developers. > Conrad, thank you for your patch, and sorry it's taken so long for a response > on this! From what I remember, Conrad and I weren't even convinced this should be committed. Reading back over it, I am inclined to agree. Maybe we could ask Gabriel or Brion to weigh in how they think PST-type magic like this would be handled in the new parser, but as it stands I'm inclined to say WONTFIX.
(In reply to comment #26) > Maybe we could ask Gabriel or Brion to weigh in how they think PST-type magic > like this would be handled in the new parser, but as it stands I'm inclined to > say WONTFIX. Now that we have Parsoid, I'm cc'ing Subbu & Gabriel to ask.
If a template wants itself to be substed all the way, it can do so by putting {{{|safesubst:}}} before all of its template calls. I see no reason to complicate things by letting this work for templates that aren't set up for it.
