-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Maybe something like {{Special:ExpandTemplates}}. X! On Apr 19, 2009, at 2:29 PM [Apr 19, 2009 ], Aryeh Gregor wrote:

Hello, 2009/4/19 William Allen Simpson <william.allen.simpson(a)gmail.com>om>: I would disagree with trying to use a symbol combination to achieve what you want here, there are already so many and this will simply add to the confusion that currently exists. I think the earlier suggestion of substall would be satisfactory. Thanks, MinuteElectron

Casey Brown wrote: <sarcasm> Wow, I'm thinking, the edit box has gotten a lot more sophisticated than ever, parsing long URLs and all that.... So, I copied that link, pasted it into an edit box, hit preview, and I'm pretty sure that's not what folks expect to put into a user Talk page! Did you try that before posting? :-( When handling vandalism, the first step is to undo the problem, then copy the name of the article, then click the user talk link, then type some nice template shortcut, then paste the article name into the template, and then click save. Perhaps you could explain how this ExpandTemplates feature helps? You expect folks to type that long URL from memory? </sarcasm> And then take a look at AfD or CfD or RfD or TfD, noting that the subst: is required to make the date constant, but that other templates inside the XfD templates cannot be subst: at the same time, so substall: won't work.... Anyway, it appears that nobody here knows a feature that handles the issues cleanly, and I'll probably post a bug/RFE later this week.

Aryeh Gregor wrote: Yes, this might be the equivalent of "{{<substonly>subst:</substonly>". That RFE has been around for years, and I was aware of it. The problem is, interactions between two different kinds of markup parsing (<> and {{}}) are often unpredictable, and have changed. In the beginning, {{subst:# didn't work. It does now? Having thought about such issues on more than one occasion, I'm proposing clean markup that's easier and predictably parsable, and fits well with current practices and syntax: {{# function (existing) {{## substitute-only subst:, otherwise is transclude {{ {{### substitute-only subst: for function, otherwise is {{# Obviously, a lot easier to document and for editors to type! And I've given it a cute neologism. But it doesn't (or didn't) and it's already used as a hack, for example: {{#ifeq:{{NAMESPACE}}|{{<includeonly>subst:</includeonly>NAMESPACE}} | | {{error:not substituted|cfd}} }} To be honest, I'm not sure how that even works, but it does.... Obviously, <nosubst> would handle that more elegantly. Should <substonly> and <nosubst> become standard, we could use them. NB:I'd prefer <substituteonly> and <nosubstitute>, spelled out like include.

Aryeh Gregor wrote: That thinking would take us back to <b>, <bold>, etc. But I'll often take rough consensus and running code over "purity".... At least sometime in the past there was some running code. Yeah, I'm not too happy that keywords were sometimes chosen because they match the name of a function provided by the underlying software. How about allowing synonyms, "{{substitute:" => "{{subst:" => "{{::"?

On Wed, Apr 22, 2009 at 12:53 PM, William Allen Simpson &lt;william.allen.simpson(a)gmail.com&gt; wrote: Well, I already tried and he never responded, so maybe he already has. Ah, now that's a good question.

Thomas Dalton wrote: They add a named parameter {{{subst|}}} (defaults null) at strategic places. You can add it after any positional parameters. The "subst:" substitutes during transclusion. Look at http://en.wikipedia.org/wiki/Template:Uw-vandalism1 and its siblings for simple examples. The problem with {{substall: is that it substitutes everything, and {{subst: doesn't substitute enough. I'm proposing the template designer have more control, using {{## only at similar strategic places. This is needed for templates that make tables inside templates, and such. As I mentioned, the use of parser functions has exploded. Folks are getting *very* creative!