Page MenuHomePhabricator

There should be syntax for substitution that doesn't break normal transclusion
Closed, ResolvedPublic

Description

Author: conrad.irwin

Description:
At the moment it is not possible to create a template that substitutes the results of parser functions when substituted and that also works when the template is not substitued.

For example of current status:

Template:X {{<includeonly>subst:</includeonly>#if:{{{1|}}}|1|2}}

{{subst:X}} is transformed into "2" as expected, but
{{X}} generates "{{subst:#if:|1|2}}" - ooops.

This feature can be used to good advantage, and some templates use a conditional around something that subst:s to nothing to warn users that they must substitute the template.

I would like to propose an additional prefix "safesubst:" or words to that effect, which gives the same result in both cases above.

Template:X {{<includeonly>safesubst:</includeonly>#if:{{{1|}}}|1|2}}

{{subst:X}} is transformed into "2", as before
{{X}} generates "2" when it is rendered, as expected, and
{{safesubst:X}} works exactly like {{subst:X}}


Version: unspecified
Severity: enhancement

Details

Reference
bz22297

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:57 PM
bzimport set Reference to bz22297.
bzimport added a subscriber: Unknown Object (MLST).

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:

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