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

I'm not sure, if the {{{0}}} in redirected template should show the redirect origin rather than redirect target.

Shouldn't we rather then have two ways, how to obtain the caller name? One for "give me, what is written on page in wikitext", second for "give me, the real template name"...

I suspect introducing something like this will break existing stuff and require a lot of work when a template really is renamed.

Suppose you have this Template A situation and Template B redirects to A. Now you wanna move or rename A to "C", you'd have to do a lot of work because all existing transclusions still call "A".

Redirects are redirects, should not change behaviour. One can use an extra parameter for that.

ie. {{Template|this}} or {{Template|that}}, or {{Redirect|that}}.

(In reply to comment #3)

I suspect introducing something like this will break existing stuff and require
a lot of work when a template really is renamed.

Suppose you have this Template A situation and Template B redirects to A. Now
you wanna move or rename A to "C", you'd have to do a lot of work because all
existing transclusions still call "A".

Redirects are redirects, should not change behaviour. One can use an extra
parameter for that.

ie. {{Template|this}} or {{Template|that}}, or {{Redirect|that}}.

I don't really think so. Currently {{{0}}} isn't used for anything, so it cannot possibly break existing stuff (unless someone puts a {{{0}}} in the page just because. I highly doubt anyone is doing that.). If a template was re-named, it might require some changes (assuming its not a meta-template, depending at what depth the {{{0}}} is processed. I assumed {{{0}}} = name of initial template used regardless of the depth at which the {{{0}}} is placed, but the request is ambiguous) but the template author should be aware of the potential of moving the page before using the feature.

OTOH, I don't really see a convincing example where this would make things easier. But it would be cool.

darklama wrote:

{{{0}}} should not have the initial template name all the way through in my opinion, just as the other numbered arguments are not the same all the way through.

Given A:

Hello {{B|foobar}} and {{{0}}}

Given B:

Hello {{{0}}} {{{1}}}

Given C as a redirect to A.

{{A}} should expand to:

Hello B foobar and A

{{C}} should expand to:

Hello B foobar and C

Off hand I'm thinking template families like ambox, tmbox, imbox, etc. or wikibooks, wikipedia, wikisource, etc. could be simplified and maintaining consistency could be made easier having a feature like this available to give an example.

#switch: {{{0}}}

I noticed in the bug by Danny that was marked as a duplicate of this one, that Danny mentions Bash. I was thinking of Bash and other programs too. When a soft link is created to a bash script or program and you call that script or program using the soft redirect the name of the soft redirect is used, some scripts and programs have used this to provide subtle differences. Some versions of grep do this when called with soft links named fgrep or egrep for example.

When would the real template name be useful? I can only think of one possible use to make sure a template is called directly and not through a redirect. A template's real name is static and isn't something that would be hard to hardcode by hand and as Bawolff says update should the template be renamed.

In Template:Foobar

#ifeq: {{{0}}} | foobar | called directly | called indirectly

van.de.bugger wrote:

Hi all,

I have implemented it (or something very similar). My implementation cannot distinguish actual template from redirection and always returns actual name, but to me it is not important because behaviour variations can be easily introduced by a parameter, as Krinkle said.

However, I found 2 *real* use cases where {{{0}}} is very convenient. A short introduction: I run MediaWiki site with Semantic MediaWiki (SMW) extension, so using templates is a must. Moreover, templates often complex and big. A;so, for namespace Template I enabled subpages.

1. Subtemplates. ----------------

In SMW it is rather common that page is generated by one template. For manageability I like split it to subtemplates, or sections, so main template body looks like a series of calls to subtemplates:

<!-- Template region -->
{{ Region/Territory }}
{{ Region/Population }}
{{ Region/Industry }}
...

With pseudo-parameter {{{0}}} it could be written as:

<!-- Template region -->
{{ {{{0}}}/Territory }}
{{ {{{0}}}/Population }}
{{ {{{0}}}/Industry }}
...

Benefits:
(a) I do not have type template name each time.
(b) If I rename template page, all the subpages are renamed automatically and I should not edit template code. Without {{{0}}} I would have to edit template code to replace old template name with new one.

2. Template "local" variables. ------------------------------

For optimization purposes, I save result of semantic request in a variable for later use, e. g.:

{{ #vardefine: r | {{ #show: ...Page selection... | ...Printout... }} }}

And then use it few times:

{{ #var: r }} ... {{ #var: r }}

The problem is: scope of variable definition is an article, not template. Variable `r' defined in one template is accessible in another template included (transcluded) into the same article. One template may accidentally reset variable which is in use by another template, so names of variables should be carefully chosen. Usually I use template name as a prefix for variable name. It leads to hardly readable code, for example: {{ #var: Template:Region/Industry_r }}. ("Template:Region/Industry" is not the longest template name in my wiki.)

Again, renaming a template requires fixing its code to replace old template name to new one. {{{0}}} helps much. Template-specific variable looks like: {{ #var: {{{0}}}_r }}}. It is short and does not require maintenance when template is renamed.

Conclusion: I vote for {{{0}}}, it is really helps.

Patch will be committed soon. It is very small and simple: 3 lines of code × 2 files.

van.de.bugger wrote:

{{{0}}} implementation.

Simple {{{0}}} implementation.

Attached:

I don't like the idea of overriding user parameters, or attaching special
meaning to redirects.

The other issues aside (I to don't see this as a proper thing to add to the
template system) if you are going to do something like this please DO NOT
modify the user specified variables, instead implement it as something like
{{TEMPLATECALLNAME}}.

Additionally the first example 'Van de Bugger' gives does not apply here.
That's not asking for a 'called-by' {{{0}}} that's asking for a PAGENAME like
magic word that returns the current name always even when transcluded. What's
actually being requested in this bug is one that returns the name it was called
by, which in the case of redirects can be different than the current name. 'Van
de Bugger's case would actually potentially break in that situation, if he
moved the templates he wouldn't actually be calling the subpages directly, if
there was a call that still used the old name left over {{{0}}} would return
the OLD name, and he wouldn't be calling the template's subtemplates, he'd
still be calling the same redirect he would have been if he had hardcoded the
name.

van.de.bugger wrote:

(In reply to comment #8)

The other issues aside (I to don't see this as a proper thing to add to the
template system) if you are going to do something like this please DO NOT
modify the user specified variables, instead implement it as something like
{{TEMPLATECALLNAME}}.

I do not see principal difference between {{{0}}} and {{TEMPLATECALLNAME}}. In the first case we use one name from template parameter namespace. Yes, this could break existing code if somebody uses a template with parameter named "0". In the second case we use one name from template name namespace. It also could break existing code if someone uses a template named "TEMPLATECALLNAME".

So, to me {{{0}}} or {{TEMPLATECALLNAME}} is just a matter of taste. {{{0}}} is not so bad because it mimics (to some extent) shell parameter $0.

I would agree with either {{{0}}} or {{TEMPLATECALLNAME}}, but I would prefer shorter one. At least, {{TEMPLATECALLNAME}} should be reduced to {{TEMPLATENAME}}.

Another aspect is implementation. I am not familiar with MediaWiki code, but I am able to implement new magic word (thanks to help and examples at MediaWiki site). However, I have no idea how to get template name from within magic word implementation. I looked into MediaWiki sources and found a place where template name is known so implementation would be trivial, but it dictates a template argument, not a magic word.

I do not object if someone with enough MediaWiki coding skills will implement it as a magic word {{TEMPLATENAME}}.

(In reply to comment #9)

(In reply to comment #8)

The other issues aside (I to don't see this as a proper thing to add to the
template system) if you are going to do something like this please DO NOT
modify the user specified variables, instead implement it as something like
{{TEMPLATECALLNAME}}.

I do not see principal difference between {{{0}}} and {{TEMPLATECALLNAME}}. In
the first case we use one name from template parameter namespace. Yes, this
could break existing code if somebody uses a template with parameter named "0".
In the second case we use one name from template name namespace. It also could
break existing code if someone uses a template named "TEMPLATECALLNAME".

So, to me {{{0}}} or {{TEMPLATECALLNAME}} is just a matter of taste. {{{0}}} is
not so bad because it mimics (to some extent) shell parameter $0.

I would agree with either {{{0}}} or {{TEMPLATECALLNAME}}, but I would prefer
shorter one. At least, {{TEMPLATECALLNAME}} should be reduced to
{{TEMPLATENAME}}.

Another aspect is implementation. I am not familiar with MediaWiki code, but I
am able to implement new magic word (thanks to help and examples at MediaWiki
site). However, I have no idea how to get template name from within magic word
implementation. I looked into MediaWiki sources and found a place where
template name is known so implementation would be trivial, but it dictates a
template argument, not a magic word.

I do not object if someone with enough MediaWiki coding skills will implement
it as a magic word {{TEMPLATENAME}}.

We already have things like {{PAGENAME}}, and so on... we already have an established pattern that {{MAGICWORDS}} and {{TEMPLATES}} are squashed together, and anyone trying to use an UPPERCASE template name expects they may collide with a magic word. However we don't do any modifications to {{{variables}}}. So it's not a matter of taste, it's a matter of something that was previously untouched suddenly being modified to not do what the user specified.

Using SFH_OBJECT_ARGS should give you access to the $frame. You should easily be able to get the same thing you were grabbing before.

Frankly there are a number of things wrong with the patch you implemented:

• It's a hack to a method that is supposed to just return the data that is stored in the frame. If that data is accessed in another way your code breaks.
• I'm not sure what the behaviour of $frame->title is, whether it's the canonical title of the template, or the title it was called in. It's behaviour will change whether you're actually implementing this bug, or if you're implementing what I said your first example would be better off with.
• Last I checked ->title is supposed to be a Title instance, you're relying on the caller to do something that converts that to a string at some point and has an implicit tostring call made on it. That's bad enough practice to get the commit reverted.

van.de.bugger wrote:

(In reply to comment #10)

We already have things like {{PAGENAME}}, and so on... we already have an
established pattern that {{MAGICWORDS}} and {{TEMPLATES}} are squashed
together, <...>

Using SFH_OBJECT_ARGS should give you access to the $frame. You should easily
be able to get the same thing you were grabbing before.

Frankly there are a number of things wrong with the patch you implemented:

• It's a hack to a method that is supposed to just return the data that is

stored in the frame. If that data is accessed in another way your code breaks.

• I'm not sure what the behaviour of $frame->title is, whether it's the

canonical title of the template, or the title it was called in. It's behaviour
will change whether you're actually implementing this bug, or if you're
implementing what I said your first example would be better off with.

• Last I checked ->title is supposed to be a Title instance, you're relying on

the caller to do something that converts that to a string at some point and has
an implicit tostring call made on it. That's bad enough practice to get the
commit reverted.

As I said to me there is no big difference between double and triple braces. If there is a way to implement it using double braces -- good.

With your help I see it is possible to create a MediaWiki extension (not a patch) which has access to frame object. That's also good, because extension has many advantages over a patch -- it can be published and used without changing MediaWiki code. But... Having a frame is not enough -- title is a private (?) member of PPFrame_DOM, and so, cannot/should not be accessed from outside of frame. ?

(In reply to comment #11)

(In reply to comment #10)

We already have things like {{PAGENAME}}, and so on... we already have an
established pattern that {{MAGICWORDS}} and {{TEMPLATES}} are squashed
together, <...>

Using SFH_OBJECT_ARGS should give you access to the $frame. You should easily
be able to get the same thing you were grabbing before.

Frankly there are a number of things wrong with the patch you implemented:

• It's a hack to a method that is supposed to just return the data that is

stored in the frame. If that data is accessed in another way your code breaks.

• I'm not sure what the behaviour of $frame->title is, whether it's the

canonical title of the template, or the title it was called in. It's behaviour
will change whether you're actually implementing this bug, or if you're
implementing what I said your first example would be better off with.

• Last I checked ->title is supposed to be a Title instance, you're relying on

the caller to do something that converts that to a string at some point and has
an implicit tostring call made on it. That's bad enough practice to get the
commit reverted.

As I said to me there is no big difference between double and triple braces. If
there is a way to implement it using double braces -- good.

With your help I see it is possible to create a MediaWiki extension (not a
patch) which has access to frame object. That's also good, because extension
has many advantages over a patch -- it can be published and used without
changing MediaWiki code. But... Having a frame is not enough -- title is a
private (?) member of PPFrame_DOM, and so, cannot/should not be accessed from
outside of frame. ?

Then we'd make it a core function and provide a proper interface to the title on the frame.

van.de.bugger wrote:

{{TEMPLATENAME}} anf {{FULLTEMPLATENAME}} magic words implementation.

Includes: (1) a patch for MediaWiki; (2) an extension providing magic words implementation.

The extension will not work if the patch is not applied; however, it will not cause errors -- magic words will have empty values.

{{TEMPLATENAME}} returns template page name without namespace name; {{FULLTEMPLATENAME}} returns template page name with namespace.

In case of redirection, both magic words return the name of target page, not a name of redirecting page.

Attached:

van.de.bugger wrote:

Any comments so far? May I hope the fix will be applied to MediaWiki some day?

BTW, I think {{SOURCENAME}} and {{FULLSOURCENAME}} (or even {{SRCNAME}}) are better. A bit shorter and a bit less confusing, because they works for any page, not for templates, because any page may be transcluded, "Template:" is just a default namespace.

Why not {{SELFNAME}} then?

van.de.bugger wrote:

I am ok with almost any name, either {{{SELFNAME}} or {{SRCNAME}}.

The most interesting question for me is a patch for MediaWiki. With the patch it is possible to implement any name as an extension.

Who is maintainer of parser? How to attract his/her attention to this patch?

sumanah wrote:

Van de Bugger, thanks for the patch. To signal to developers that there's a patch here waiting to be reviewed, I've added the "patch" and "need-review" keywords. Please feel free to do that yourself in the future when you attach a patch to a bug in Bugzilla. Thanks again.

A while ago I have written the extension 'Parser Fun' which has a feature for displaying the templates name via {{THIS}}, also works with other site information related variables like {{THIS:NAMESPACE}} or {{THIS:PAGENAMEE}} and offers a hook to make it work with any other extensions variables.

I also like the idea of knowing the caller templates name, even though I don't really have any idea where I would use it right now.

Please see http://www.mediawiki.org/wiki/Extension:Parser_Fun for details on my {{THIS}} implementation.

sumanah wrote:

Van de Bugger, now that we have moved to Git as a source control system, you're welcome to use developer access https://www.mediawiki.org/wiki/Developer_access to put this & future patches directly into Git. That will get them reviewed faster, too!