Wikipedia talk:Template documentation/Archive 2

Archive 1

Archive 2

Bot request

Resolved

 – Long since cleaned up.

I have made a request over at Wikipedia:Bot requests#Template documentation that all occurrences of "{{/doc}}" should be changed to "{{documentation}}" on template pages. I also asked that "{{template doc}}" and "{{documentation, template}}" should be changed to "{{documentation}}".

--David Göthberg (talk) 18:14, 17 April 2008 (UTC)

The bot wrangler Dycedarg responded that there were only 157 templates using the code {{/doc}}, so instead he made a list of them so we can fix them by hand. (They probably need some other fixes too since they use that old method.) The list is available at Wikipedia:Template documentation/List.

--David Göthberg (talk) 10:37, 18 April 2008 (UTC)

Zoobox

Disregard

 – Off-topic; try WT:INFOBOX.

I am working on a project for WikiProject Animals-- a second infobox, which will feature statistical data about each species. Some of of think it would be beneficial, so I am taking the responsibility to provide a rough draft infobox. Unfortunately, there are a few issues with it. Could I get some help cleaning it up? I used the Taxobox as a foundation and have basically removed and added code to that. It is still rather messy and the graphic and audio aren't even appearing within the boundaries of the box like they should. User:Bob the Wikipedian/Zoobox

Thanks in advance, Bob the Wikipedian, the Tree of Life WikiDragon (talk) 22:27, 30 April 2008 (UTC)

Any standard for internal developer docs?

Resolved

 – Issue sorted itself out.

Is there is standard for documenting subtemplates not intended to be called alone... only used for subroutine-type purposes? Should these be on the main doc subpage, or should there be a separate subpaged named devdoc or such? Should they be documented in one place, even, or should each subtemplate have its own doc? – flamurai (t) 17:48, 14 May 2008 (UTC)

I assume you don't mean regular meta-templates that are used on many different templates, right? Instead you mean like there is a template {{Bigtemp}} that internally uses {{Bigtemp/header}} and {{Bigtemp/footer}}. And editors that use {{Bigtemp}} don't need to be aware of {{Bigtemp/header}} and {{Bigtemp/footer}}, right?

The only such case that comes to my mind was the old navbox that used a navbox/core. And the technical documentation were at navbox/core. Navbox just mentioned the navbox/core in one sentence on the usage documentation with a link to it. So most editors didn't have to be confronted with the technical documentation.

In the case where there are several subtemplates, like {{Bigtemp/header}} and {{Bigtemp/footer}} and so on, then I would do as I do in other cases where there are several templates that belong together, and what we already recommend at Wikipedia:Template documentation#Several templates, one documentation page: I would put the full technical documentation at one of the subtemplates, say {{Bigtemp/header/doc}} and then just put very short /doc pages at the others with links to the main documentation at that one subtemplate. So {{Bigtemp/footer/doc}} would say: "See full documentation at {{Bigtemp/header}}."

I would not put the technical documentation in a special /devdoc page directly under the main template. Since that page needs to be shown somewhere, so I think it is better to show the documentation with one of the subtemplates. I have been programming computers since 1982 and I quickly learnt that maximum one documentation file per source code file is a good idea. I also learnt the hard way here at Wikipedia that several templates should not show the same /doc file. Since then people start to put lots of weird if-cases in them to handle interwikis and categorisation and to differentiate the text depending on where they are shown. So it is better to use "soft redirects" like I described above.

Unfortunately the {{Documentation}} template does not automatically support this. It is currently "too smart" and instead of showing {{Bigtemp/header/doc}} on {{Bigtemp/header}} it shows {{Bigtemp/doc}} on {{Bigtemp/header}}. So in the noinclude area of {{Bigtemp/header}} one has to put this: {{Documentation|Template:Bigtemp/header/doc}}.

--David Göthberg (talk) 19:12, 14 May 2008 (UTC)

All right. I think what I will do is just put short doc pages on each template as quasi-function documentation. Really all that's needed is to list the parameters. I just have condensed a mess of 24 subtemplates down into 2 at {{ribbon devices}}, and I don't want the next person who wants to modify the template to go through the trouble I went through figuring out what's going on. – flamurai (t) 19:22, 14 May 2008 (UTC)

Categories and documentation

Resolved

 – Question answered.

I apologize if this has been answered somewhere, but I haven't been able to track it down. Let's say in my documentation I decide to create an example to show how the template is used, I do this by enclosing one example in <pre></pre> tags and then running the exact same example without the tags (thus executing it). This all works just fine, however the template is encoded with category tags and then tags the template docs and page itself into those categories. Is there any way to prevent this? To make it so that it can execute this template once while somehow ignoring the category calls within it? Any help would be appreciated, thanks. 75.68.115.240 (talk) 22:42, 7 July 2008 (UTC)

See m:Help:Category#Selective category inclusion (2nd part).--Patrick (talk) 22:47, 7 July 2008 (UTC)

Works beautifully! What a unique method. Thanks! 75.68.115.240 (talk) 23:18, 7 July 2008 (UTC)

'Template Documentation' Headings

Resolved

 – Fixed.

Please see Template talk:Documentation#Heading fix for a discussion regarding the accessibility or otherwise of headers in {{documentation}}. Thank you. Andy Mabbett (User:Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 10:53, 8 September 2008 (UTC)

Still unresolved. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:28, 23 August 2009 (UTC)

Fixed as of December 2011. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 01:17, 5 January 2012 (UTC)

Categories and interwiki links

Resolved

 – Question answered.

Hey, the Categories and interwiki links section says these should be placed on the /doc subpage ... why? Tks Ling.Nut ^{(talk—WP:3IAR)} 08:56, 15 October 2008 (UTC)

One of the main purposes of this documentation system is to separate the template code and the documentation from each other, so the template can be protected (if needed) but the documentation still can be edited by everyone. We also want that everyone should be able to help out to update the categories and the interwiki links, thus they should be placed in the <includeonly> </includeonly> section on the /doc page. Consider that often interwiki links are updated by users from other language Wikipedias. That is users who doesn't even have an account on the English Wikipedia, so they can not even update a semi-protected template.

--David Göthberg (talk) 12:27, 15 October 2008 (UTC)

Stub templates

FYI

 – Documentation was updated.

Hi all - I've added a short section explaining the reasons why stub templates generally don't have documentation (basically because the link to WP:STUB in all stub templates serves the same purpose but has additional benefits). Grutness...wha? 00:34, 11 February 2009 (UTC)

Shared documentation

Stale

 – No further progress in establishing a standard for this in over 2 years.

Is there a best practise where to place interwiki links and categories if a documentation page is shared? E.g., {{Wikinewscat}} should share the documentation of {{Wikinews}}, but has different interwiki links.
I was thinking about putting the categories and interwikis on seperate template subpages (for which I can't think of a good name) and transclude that one inside the includeonly area of the documentation page, using a relaibe path, so that it will transclude the matching interwiki/category subpage into each template.
Is there a better way to go about this? --Amalthea 11:44, 7 April 2009 (UTC)

Having anything else than a plain /doc subpage with the interwikis wreaks havoc with the interwiki bots. And even human editors have big problems with adding the interwikis and categories at the right place if you use the same /doc page in several places. (Since then you need a lot of if-cases checking what page the /doc is on.) Adding the interwikis even further away as you suggest will create even more problems. And remember, not all Wikipedias even use /doc pages, so our /doc page system is already pretty confusing for editors from other language versions that come here to put interwikis on our templates.

Instead there is a much simpler solution that we use in many templates:

Create a /doc page for each template in a template group. Decide that one of them is the "main" template. Write the long documentation at the /doc page for the main template. Then only have short /doc pages for the "sister" templates that link to the main template, by stating "See full documentation at {{main template}}." This means each template has its own /doc page where categories and interwikis can be put as usual.

See for instance the main template {{nowrap begin}}, with its helper templates {{nowrap end}}, {{·wrap}} and so on.

Or the main template {{shortcut}} with its sister templates {{shortcut-l}} and {{policy shortcut}}.

--David Göthberg (talk) 15:58, 7 April 2009 (UTC)

Eh, interwiki bots ... didn't realize they are working in template space, too.
Hmm, having only a soft redirect documentation page works around those problems, but isn't quite as neat for template users. I'd typically put readers' usability far above editors' usabiility.
I'm guessing that you also wouldn't like transcluding the actual documentation in both /doc pages from a /doc2 subpage of one of the templates? :) That would keep the interwiki bots and foreign language interwikians happy, and only is a hassle for people wanting to edit the documentation.
Amalthea 16:09, 7 April 2009 (UTC)

I think the soft redirects make things less confusing for those who read the documentation. Since I find it annoying and confusing to read the documentation of several similar templates, only to discover after a while that I am rereading the same documentation.

Or even worse, some template coders add if-cases in the documentation so it isn't exactly the same documentation, forcing you to actually read all the similar versions...

Soft redirects make it clear for the readers that there are several similar templates, and what documentation they are actually reading.

And when not using soft redirects I have many times seen questions like: "Why does the documentation say {{foo}} when the template's name is {{foo2}}?".

And I have seen editors "clean away" the info about the other templates, just because they didn't realise the /doc page was shared. Or they have made changes to the /doc that doesn't fit with how the other templates work that use the same /doc. Thus causing lots of confusing for those that read the documentation.

That is, if you click the [edit] link on the green doc box you come to the right /doc page, but there is not much that indicates that you are no longer under the same template name as where you started.

And regarding your other idea, to transclude a shared documentation onto the actual /doc pages: That works technically but I think it will be confusing for those that want to edit the documentation. But I admit we often do that partially, for instance we often use a template for the "See also" section since most of the see also links are usually the same for a group of templates. See for instance {{main other}} and its sister templates.

And here's a little rant for everyone else reading this (since I think Amalthea already knows this): An important thing to remember when coding and documenting templates here at Wikipedia is that you yourself will not be here forever to maintain your templates, others will have to maintain them after you or when you are on vacation. So try to keep things clear and if possible simple. And hey, if you are an old programmer like me, then you know the value of clear code and documentation when you yourself come back some years later when you have forgotten everything.

--David Göthberg (talk) 20:54, 7 April 2009 (UTC)

OK, I did it like you recommended.
I'm not quite convinced that this is the best way, though. I could see remedies for a number of your issues, like simply mentioning "This is the centralized documentation for {{template 1}} and {{template 2}}" or something at the top.
I totally agree on the branchend documentations, {{Db doc}} does that and is an absolute hell.
Cheers, Amalthea 09:17, 8 April 2009 (UTC)

Yes, you are right that if you add a proper lead in the shared documentation it probably reduces the confusion a lot. Note that you still need such a "This page is the documentation for the templates X and Y" lead, even if you use soft redirects. Since otherwise people will still do weird edits to the documentation. And it also makes it clear to people who arrived through the redirects that they have come to the right place.

Ouch! {{db doc}} is a scary example. Yeah, some coders don't understand that documentation is not code, it is text.

--David Göthberg (talk) 11:30, 8 April 2009 (UTC)

But I like code :D How else do you suggest we keep the documentation for 48 almost-identical templates up to date?? I do agree with you, {{db doc}} is a meta-template from hell, but there's no better way to do it IMO. Happy‑melon 14:23, 8 April 2009 (UTC)

Oh, that's simple: Put all the documentation in one place, then have "soft redirects" from the /doc pages of the other templates. And in the really complex cases you can do as I did with all the wrap templates, make a how-to guide covering it all: Wikipedia:Line break handling.

--David Göthberg (talk) 10:25, 30 November 2009 (UTC)

File pages

Resolved

 – Fixed.

I think we also should use /doc pages for protected images, for the exact same reasons that we use /doc pages for templates: We have a problem that non-admins can't update the descriptions of protected images. This means that such pages usually lack links to other similar images, and they lack categorization etc. That can also lock out the uploader himself from updating the description, which can be very frustrating and might discourage further image uploads.

I am doing a test with File:Ambox style.png, you can see how it looks there.

Using a subpage directly under the image page didn't work as well as I hoped, since there are tools that interferes with it. (The /doc page got listed as an image page lacking an image.) And the file namespace doesn't have the "subpage feature" enabled, thus there are some other issues. So I have now moved that /doc page to be under the image's talk page instead, I think that should fix it. We mostly access the /doc page using the links in the green doc box created by the {{documentation}} template, so it doesn't matter much where the /doc page actually is placed. And having it under the talk page means it still comes along when we do page moves.

So if/when we decide to use this, then I would like to update the logic in the {{documentation}} template so it places the /doc page under the talk page, when on a file page.

--David Göthberg (talk) 11:07, 30 November 2009 (UTC)

The two messages below are copied from my talk page. --David Göthberg (talk) 12:01, 30 November 2009 (UTC)

I heard that images can be protected while the file description page remains unprotected these days: bugzilla:6579. Doesn't appear to be live yet though. Amalthea 11:19, 30 November 2009 (UTC)

Oh, thanks for the link to the bugzilla bug. And right, it could be nice if they fix it in the software. But I hear people saying that it nowadays takes ages before they deploy fixes, even when the code has already been written for it. (But I don't know from personal experience, since the one time I asked for a fix some year ago, they fixed it and deployed it in 12 hours!!! :))

I think we should start using /doc pages for images, since we don't know when the fix will be deployed. And the /doc pages could still be useful in some cases, even after the fix has been deployed, if we admins want to protect parts of the image description.

--David Göthberg (talk) 11:55, 30 November 2009 (UTC)

End, messages copied from my talk page. --David Göthberg (talk) 12:01, 30 November 2009 (UTC)

I have updated the {{documentation}} template: It now automatically places the /doc page under the talkpage when in File space, and automatically shows the heading "Summary" instead of "Documentation". And when clicking the [create] link in an empty doc box it automatically preloads the right content for File pages.

Most license templates and other image related templates only categorize pages when in "File" space, thus the /doc pages in File talk space don't get categorized by the license templates.

This means all the technical stuff is in place. See File:Ambox style.png for a live example. I would like to start using and promote using {{documentation}} on protected images. I will announce this discussion in several image related places so people can come here and discuss.

--David Göthberg (talk) 19:45, 12 February 2010 (UTC)

I was coming here to point out what Amalthea did. The fix is already done in the software and the code has been reviewed. Its only waiting on deployment at this time. I'm really not too keen on the idea of implementing something like this that we know is going to be obsolete imminently. Mr.Z-man 23:25, 12 February 2010 (UTC)

If I remember right, when I started editing Wikipedia many years ago we already had this feature. But it was disabled since admins were confused by it and sometimes protected the description page instead of the image.

In 2006 bugzilla:6579 was opened with what amounts to a request to re-add the feature. The feature has since been discussed and code has been worked on. The last I can see in that discussion is that the bug has been reopened since it still does not work (more fixes needed). And even when all the code is in place we don't know if the sys-admins will deploy the code and enable the feature.

So for what we know it might never be enabled, or it might take another four years until it is enabled. And even if/when the feature is enabled, the /doc system won't conflict with it, it will still work fine.

The /doc system has been used for templates for years now, so we know it works well and people are familiar with it. The /doc system is ready to be used today, right now. Not some time far into the future.

--David Göthberg (talk) 00:09, 13 February 2010 (UTC)

The code currently does work, and as I noted, has been reviewed (which is the final step before deployment). At this point the only question is "when?". I don't know for sure when the next code update will be, but I would estimate this would be deployed within the next 2 months, likely sooner. Mr.Z-man 00:49, 13 February 2010 (UTC)

Short comment:

Our high-risk images are cascade protected, so I think we will still need the /doc system, even if/when r58537 has been deployed.

Long comment:

Well, I don't know much about bugzilla and such stuff. I see the fix was added in r58537, but Bryan Tong Minh and MZMcBride think it has been disabled in r59419, while you think it means it hasn't been disabled. I hope you are right.

But r58537 probably won't fix it for our high-risk images here at enwp. This is a bit comlicated, but here's why:

We have many trigger-happy admins that know very little about high-risk image handling, so they go around deleting protected images saying "there is a copy on Commons, so not needed here". They don't realise that high-risk images need to be locally uploaded and protected here, for a number of reasons. (Among other things since users and admins at Commons often do changes to the images there that doesn't fit our local needs, sometimes they even rename or delete the image there.) We try to educate our local admins, but we get new admins all the time, so some of the high-risk images are deleted here at enwp on an almost monthly basis.

When a local image is deleted it doesn't help if the image on Commons is protected, since any vandal can upload a rude image locally. To prevent that we have put our most high-risk images on some cascade protected pages so the local image page is protected, no matter if the image exists or is deleted. This helps both while the image is deleted, and if it is restored, since admins often forget to re-protect the images when they restore them.

So since several hundreds of our high-risk images are cascade protected, that means their image description pages are also cascade protected. I assume that will not change with r58537, or does that revision include changes to how cascade protection works? My guess is that those image pages won't be editable even when we can unprotect the pages themselves, since they will still be cascade protected. Thankfully the cascade protection doesn't go on to the /doc subpages. For an example of this, try to edit File:Ambox style.png and File talk:Ambox style.png/doc.

So for our high-risk images we will still need the /doc system, even after r58537 has been deployed.

--David Göthberg (talk) 03:19, 13 February 2010 (UTC)

I do not think that when a local image is deleted it doesn't help if the image on Commons is protected, since any vandal can upload a rude image locally., because only administrators have 'reupload-shared' userright. Ruslik_Zero 08:59, 14 February 2010 (UTC)

Putting things on a cascade protected page to protect them like that has been deprecated for a long time (since we got the ability to protect pages from creation). Suggesting we augment an obsolete system with one that's about to become obsolete isn't especially persuasive. Mr.Z-man 06:12, 13 February 2010 (UTC)

I take it you might not be aware of the fairly new Wikipedia:Cascade-protected items, or perhaps don't understand why we need it?

I just explained in my previous message why it doesn't help that we got the ability to create-protect images. Since (new) admins who doesn't know better go deleting protected high-risk images and don't create-protect the image after the deletion. And if we create-protect it, then when an admin add the image it looses its protection. I consider that a bug, a protected image or page should not become unprotected just because it is deleted or added. It should take an extra manual choice to remove the protection.

The only way we have to work around that bug is to add the image to a cascade-protected page, so it continues to be protected no matter what.

Also, as far as I remember when one deletes a protected image one doesn't get any indication or warning. So some of those admins don't even notice that they are deleting protected images. It seems they don't even see the protection box on the image page or read the image description, since they use tools that delete images from category listings or so.

And have you ever tried to go through the 1000 most used images and protecting them one by one? It was much faster to simply add them to a cascade page. And as I said, it really doesn't help to protect them by one by one, since the protection isn't persistent.

--David Göthberg (talk) 07:55, 13 February 2010 (UTC)

It's fairly obvious to me that cascade-protecting an image by inlining it on a cascade-protected page, should protect the image, not the description page. I've filed that as T24521. That would resolve the lingering issues here.

The protect-file-only code is live on the latest version of MW, and will appear on WMF wikis at the next scap, which hopefully will be before the end of the month. Happy‑melon 20:01, 14 February 2010 (UTC)

Template:Documentation

FYI

 – New features have been added to {{Documentation}}.

We are planning to do some changes to the {{documentation}} template. We are planning to add (create) links for the /sandbox and /testcases pages when they don't exist. And we are perhaps going to move the sandbox and testcases links and the "This documentation is transcluded from..." line to a small box below the big doc box, instead of as now inside at the top of the big doc box. See more about this and discuss it at Template talk:Documentation#Documentation/links.

--David Göthberg (talk) 07:11, 4 February 2010 (UTC)

Y Done - And I have updated and reworked its documentation. --David Göthberg (talk) 19:47, 12 February 2010 (UTC)

Template documentation and debugging

Stale

 – There is no automated fix for this as of 12/2011; request at MW Bugzilla as a ParserFunctions "magic word" feature?

Hi there, I have created {{IPAlink}} and its documentation.

In the documentation, I would like to have a table like this

Template invocation	Returned code	Rendered as
{{IPAlink|m}}	[[Bilabial nasal|m]]	m
{{IPAlink|ɡ͡b}}	[[Voiced labial-velar plosive|ɡ͡b]]	ɡ͡b
{{IPAlink|pʰɪk}}	[[IPA|pʰɪk]]	pʰɪk

Here I have hard-coded the central column, but I would really like to have it auto-populated with whatever the template returns. Is there a way to do that? It would seem strange if not, because how are people debugging more complex templates otherwise? Thanks. 222.145.134.103 (talk) 09:15, 13 June 2010 (UTC)

You can use {{#tag:nowiki|{{IPAlink|m}}}}. By the way, it gives the span tags too.--Patrick (talk) 09:55, 13 June 2010 (UTC)

Cool, thanks! So here's the output

Template invocation	Returned code	Rendered as
{{IPAlink|m}}	<span class="IPA" lang="und-Latn-fonipa">[[:Voiced bilabial nasal|m]]</span>	m
{{IPAlink|ɡ͡b}}	<span class="IPA" lang="und-Latn-fonipa">[[:Voiced labial–velar plosive|ɡ͡b]]</span>	ɡ͡b
{{IPAlink|pʰɪk}}	<span class="IPA" lang="und-Latn-fonipa">[[:Aspirated consonant|pʰ]]</span><span class="IPA" lang="und-Latn-fonipa">[[:Near-close near-front unrounded vowel|ɪ]]</span><span class="IPA" lang="und-Latn-fonipa">[[:Voiceless velar plosive|k]]</span>	pʰɪk

Now, wouldn't this be useful for many template docs? I would like to take this to the next natural level and create a couple of templates that do just that. Basically, the template documentation writer would just write:

{{begin_template_doc_example_table}}
{{template_doc_example|{{IPAlink|m}}}}
{{template_doc_example|{{IPAlink|ɡ͡b}}}}
{{template_doc_example|{{IPAlink|pʰ}}{{IPAlink|ɪ}}{{IPAlink|k}}}}
{{end_template_doc_example_table}}

No more repetitions, everyone happy, the end. What do you think, is it possible? Or would the arguments to template_doc_example be evaluated before the template is invoked? 222.145.134.103 (talk) 11:09, 13 June 2010 (UTC)

Yes, the arguments to template_doc_example are evaluated before the template is invoked, but instead you can use the name of the template (here IPAlink) and its parameter as parameters of template_doc_example.

We have already Template:xpdop3c (backlinks edit) producing:

Template:Xpdop3c

or for use in a table

Template:Xpdop3c

See also m:Help:Expansion demo templates.--Patrick (talk) 22:53, 14 June 2010 (UTC)

There is no way to get exactly what you were after automatically. You just have to hand code using {{tlx}} and the like. The {{#tag:nowiki|{{template_name|parameter1=value...}}}} method is useless in template documentation because of all the <span>...</span> output that will hopelessly confuse matters for most people trying to follow the docs, and the {{xpdop3c}} output also confusing, with weird links no one needs or expects. This is probably something good to request (after doing a bunch of searches to make sure it's not already been requested) at the MediaWiki Bugzilla as a feature to add to MediaWiki's stable of ParserFunction "magic word" features. It would be very, very helpful if we had something like <noparse>{{template_name|parameter1=value....}}</noparse> or {{noparse:template_name|parameter1=value...}}, that would transclude a specified template with the given parameters and values without parsing its output, as if transcluding into an on-the-fly <nowiki>...</nowiki> that doesn't exist in the code. I can think of quite a few uses for that... — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 22:51, 18 December 2011 (UTC)

Help for less experienced user

Resolved

 – Question answered.

For a beginner, it's very hard to find a template in thousands of them. Is it possible to have a category "Most used templates", so that if one is simply looking for a way to say "this section requires better documentation" or "this page should be split" can find the right templates? --GianniG46 (talk) 15:11, 15 June 2010 (UTC)

What you are looking for is Wikipedia:Template messages. That page and its subpages are better than a category, since it also shows the templates and have some explanations.

I often forget the name of that page, but it is easy to find: In the menu to the left of all Wikipedia pages click "Help", then "Resources and lists" (or "Editing Wikipedia"), then "List of templates".

--David Göthberg (talk) 08:36, 30 December 2010 (UTC)

Remembering the W:TEMP shortcut is also easy for some people. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 21:51, 18 December 2011 (UTC)

Prefer no SHOUTING

Resolved

 – Moot.

I propose this template should do no shouting.
As per Wiki-MOS, innit. -DePiep (talk) 01:14, 19 August 2010 (UTC) It doesn't.

The formatting that {{Documentation}} has had for a long time makes no use of ALL-CAPS, manually nor via {{allcaps}} markup. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 21:48, 18 December 2011 (UTC)

How about sub-template /pages in a Template?

Resolved

 – Question answered.

The current do & don't list says about Templates: "subpage for documentation allowed". What does this mean for sub-pages that are templates? Examples: Category:Extended Convert subtemplates and {{ambox/core}}? -DePiep (talk) 07:47, 6 September 2010 (UTC)

Nothing. There wasn't anything exclusive implied, and it's probably a reference to the fact that /subpages are not allowed in mainspace (in Wikipedia, where this means articles; they are permitted in many other wikis, including Meta). Sub-templates on /subpages are common practice for any templates that get excessively complex, or where multiple templates need to re-use the same code. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 21:46, 18 December 2011 (UTC)