conrad.irwin wrote:

A patch to provide this

I have attached a patch which implements the proposed change by adding another special-cased magic word to Parser::braceSubstitution.

There is some thought on MediaWiki-General that instead of hacking it in like this, a more general framework should allow for any magic word to take specific action at this point in the parse. The process by which this might be done, and the concrete benefits of such an approach are not immediately obvious to me.

Attached:

conrad.irwin wrote:

Same as previous patch with subst-if-substed: instead of safesubst:

This patch incorporates the suggestion that subst-if-substed: it a better prefix than safesubst:. I have no opinion on which is better, it would likely be more consistent to chose a name that doesn't quite mean anything :).

Attached:

MediaWiki wrote:

(In reply to comment #1)

Created an attachment (id=7043) [details]
A patch to provide this

I have attached a patch which implements the proposed change by adding another
special-cased magic word to Parser::braceSubstitution.

There is some thought on MediaWiki-General that instead of hacking it in like this, a
more general framework should allow for any magic word to take specific action
at this point in the parse. The process by which this might be done, and the
concrete benefits of such an approach are not immediately obvious to me.

Adding a hook at this point in the parse would be similar to WordPress' "shortcode" system, the way I see it. That system has proven to be useful for many, many plugins and I'm sure MediaWiki extension developers would find such a hook useful, too.

conrad.irwin wrote:

(In reply to comment #3)

Adding a hook at this point in the parse would be similar to WordPress'
"shortcode" system, the way I see it. That system has proven to be useful for
many, many plugins and I'm sure MediaWiki extension developers would find such
a hook useful, too.

As a feature requst, I think this belongs in a separate bug. The shortcode system looks more like normal tag extensions/parser functions/templates to me, which people can {{subst:#tag: if they wish.

At the moment the five "transclusion modifiers" (subst:, safesubst:, msg:, msgnw:, raw:), are fairly orthogonal, though it would not be impossible to create a new MagicWordArray to handle them all.

MediaWiki wrote:

(In reply to comment #4)

As a feature requst, I think this belongs in a separate bug. The shortcode
system looks more like normal tag extensions/parser functions/templates to me,
which people can {{subst:#tag: if they wish.

At the moment the five "transclusion modifiers" (subst:, safesubst:, msg:,
msgnw:, raw:), are fairly orthogonal, though it would not be impossible to
create a new MagicWordArray to handle them all.

I think I've been misunderstood. I was reacting to the suggestion of a more general framework for any magic word to hook in at this point in the parse and giving what I thought was a good example implementation. Obviously the shortcodes themselves are more like tag extensions or templates, but the concept of the parser acting on hooks registered by different magic words is what I was presenting. Hopefully that clears it up. I'm not entering a feature request. :)

conrad.irwin wrote:

A "for interest" patch implementing {{subst}}

This is an alternative solution, instead of having subst: and safesubst:, we have subst: and {{subst}}.

{{subst}} is a magic word that is automatically substituted (i.e. {{subst:subst}} == {{subst}}) and which returns "subst:" during the PST and "" thereafter. The problem with this is that it feels too "magic"; I don't expect things to substitute themselves unless they are prefixed by subst: (obviously if the patch were changed to require {{subst:subst}} to be used intstead of {{subst}}, the "magic" happens in the other direction). - maybe this isn't so much of a problem?

<includeonly>{{{{subst}}#if:{{subst}}||Please substitute this template}}</includeonly>

may be clearer than

<includeonly>{{safesubst:#if:{{subst:ns:0}}||Please substitute this template}}
</includeonly>

In the examples above, "safesubst:" may be replaced directly by "{{subst}}" and preserve the intended meaning; however I feel sticking to an alternative prefix is more consistent.

(Sorry Voyagerfan, I'll just let it lie)

Attached:

conrad.irwin wrote:

I applied a patch that adds "safesubst:" in r61710.

The syntax was retained as alternative suggestions are (to my mind) no more clear in purpose, and in the case of {{subst}} (above) or <nosubst>, <substonly> bug 4484, have their own problems. Alternative names for the prefix "trysubst:", "subst-if-substed:" are not noticably improvements.

smjg wrote:

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

conrad.irwin wrote:

Reverted by Tim in r62689. Branched to
http://www.mediawiki.org/w/index.php?title=Special:Code/MediaWiki/path&path=%2Fbranches%2Fconrad

conrad.irwin wrote:

Sorry, this particular change was not reverted by Tim, and is in 1.16beta.