Jump to: navigation, search
Information icon.svg This template employs intricate features of template syntax.
You are encouraged to familiarise yourself with its setup and parser functions before editing the template. If your edit causes unexpected problems, please undo it quickly, as this template may appear on a large number of pages.
Remember that you can conduct experiments, and should test all improvements, in either the general Template sandbox or your user space before changing anything here.

Notice to users who may have arrived here mistakenly

If you came here after clicking "Edit" on a header, someone failed to use template substitution appropriately. Ask an experienced editor to help you use Wikipedia:Template substitution on the template that directed you here (if you don't know how to do it yourself). A good choice would be whoever put the header on your talk page, if it was on your talk page; go to that user's talk page and ask what to do.


This template outputs whatever was inputted to it—that is, it performs the identity function. Why is this valuable? Well, consider a template with the following text:

==Header for [[Template:Example]]==
This is just to inform you that you broke Wikipedia policy unknowingly.  You will be shot at dawn.

Now, someone goes and uses that template on someone's talk page. The accused then clicks on Edit . . . and is now editing the template, not the section it's created on his userpage. He may add responses to the comments or, if he's offended by the intrusion, just blank it or vandalize it. This means that, in all probability, the template will have to be protected, which is bad.

But on the other hand, what if the first line is replaced with the following text:

{{identity|==Header for [[Template:Example]]==}}

Now he clicks the edit button, and arrives . . . here, at Template:Identity. Now, this is protected, but it contains no text or functionality that could be improved upon beyond maybe some categories. So, the example template doesn't have to be protected, which is good, because then people can tweak its wording endlessly and improve it to perfection.

Of course, other uses may be possible. Document them here as you come up with them.


  • You can't embed templates that use parameters. Pipes that are passed in are passed back escaped, and will not be treated as pipes for the purposes of, e.g., table or template syntax.
  • The parameter to be returned cannot contain a | (pipe) character that is followed by zero or more nonpipe characters and then an equals sign. For instance, "abc|def=ghi" is bad; so is "abc|=def". If you do this, chunks of your input will go missing and/or be moved to other places.
  • Any ending | characters will not show up in the output.
  • Spaces that are adjacent to | characters might or might not be preserved.
  • If more than 10 | characters are in the input, a portion of the input adjacent to the end will disappear. (Unlike all other limitations, this one isn't really inherent; it can be expanded, within reason. If you don't know how to do it, ask someone.)
  • All pipe-related limitations can probably be circumvented by using {{!}}. Failing that, the character entity reference | will always work.

Technical stuff

Using Template:Pf, an initial equals sign works fine (since {{{}}} is a valid parameter). Up to 10 pipes are possible using a long chain of Template:Pfs, but not if any are followed by an equals sign, because then that's a named parameter and we a) have no idea what it's named plus b) have no idea where in the input string it actually is. Multiple sequential pipes are possible to handle, because from the fact that something later was defined we can infer that there were a bunch of null parameters earlier on rather than nothing at all. If a sequence of one or more pipes ends the input, however, that's indistinguishable from not being added to the end at all.