Template talk:Documentation/Archive 10

I've just redirected a number of subpages of Template:Documentation, to the template itself or to its /doc, /sandbox, or /testcases page as appropriate. In all cases these were components of historical versions of the template that haven't been used for years (except on some user sandboxes and the like in a few cases), or their /doc pages or assorted sandbox/test pages. If anyone is interested in investigating deletion of any of these redirects, I have no objections, but I don't intend to pursue deletion of any of them myself.

Note that there are several subpages I did not redirect, since I'm not sure what's going on with them: Template:Documentation/Metapage, Template:Documentation/ruler, and Template:Documentation/start box appear to be used by other templates, and the /testcases subpages and some of the preload pages might be unused and unneeded, but I didn't investigate them. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 07:36, 14 June 2018 (UTC)

I undid your redirection of Template:Documentation/mirror. That template was the preload when you clicked on the "mirror" option when creating a new sandbox. I would suggest that you carefully review your other mass redirects to make sure that you didn't break anything else.

Below is a list of the pages that were redirected:

• Template:Documentation/core/doc
• Template:Documentation/core/sandbox
• Template:Documentation/core2
• Template:Documentation/core2/doc
• Template:Documentation/core2/sandbox
• Template:Documentation/data box
• Template:Documentation/data box2
• Template:Documentation/docname
• Template:Template doc/docname
• Template:Documentation/docspace
• Template:Documentation/docspace/sandbox
• Template:Documentation/end box
• Template:Documentation/end box/testcases
• Template:Documentation/end box/sandbox
• Template:Documentation/end box2
• Template:Documentation/end box2/sandbox
• Template:Documentation/link box
• Template:Documentation/start box2
• Template:Documentation/start box2/doc
• Template:Documentation/template page
• Template:Documentation/template page/sandbox
• Template:Documentation/sandbox2
• Template:Documentation/test1
• Template:Documentation/test1/core
• Template:Documentation/test1/core/doc
• Template:Documentation/test1/core2
• Template:Documentation/mirror
• Template:Create mirror

--Ahecht (TALK
PAGE) 13:42, 14 June 2018 (UTC)

Documentation/mirror is not transcluded anywhere and undocumented (it's not even mentioned on Documentation/doc), so I think I can be forgiven in thinking it was no longer used, given the large number of other subtemplates that were similarly unused and mostly poorly documented or undocumented. I didn't redirect Documentation/doc; I'm not sure why you listed it, so I removed it from the list. All the other templates you listed are as I explained above - components of historical versions of Documentation that were superseded and deprecated by Module:Documentation, along with an array of attendant documentation, sandbox, and test pages (in the case of the Documentation/core subpages, Documentation/core has been a redirect since 2013, but none of its subpages had been redirected until I did it, just to give an example of the state of most of these subpages). That being said, I've reorganized the list (and removed a duplicate entry) to allow others to more easily review my changes. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 17:11, 14 June 2018 (UTC)

You have broken many old versions, we often look through page history particularly with templates, in order to find out how they worked prior to being Luaised. What was the reasoning behind this change? Why was it not noted in the edit summary? Did you seek consensus for these changes? I see no reason why I should not revert every single one of these edits. --Redrose64 🌹 (talk) 19:40, 14 June 2018 (UTC)

The only old versions of anything I "broke" would be old versions of {{Documentation}}; old versions of templates are always rendered using the current versions of any transcluded templates, so old versions of other templates use the current version of {{Documentation}} instead of any of these old subtemplates. In addition, I'm not aware of any widely-accepted recommendations to preserve unused templates that were formerly widely used just to prevent old revisions from being displayed brokenly; otherwise, any time a formerly widely-used template came up at TfD, or a formerly widely-used redirect to a template at RfD, it would be snowball kept, and that's definitely not the case. I also don't appreciate you threatening to revert all my edits here, and then immediately doing so while claiming in every single revert summary that I didn't explain my edits - I left a detailed explanation here, and if you'd like me to individually explain any specific edit, I'd be more than happy to. Honestly, I'm surprised and disappointed at just how controversial this set of changes apparently is, given these pages have been unused and largely untouched for years (at least since Module:Documentation was written and deployed, and in many cases even prior to that). 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 20:13, 14 June 2018 (UTC)

I'm not aware of any widely-accepted recommendations to redirect unused templates. What harm were they doing as non-redirects? You left no edit summaries. You did not discuss before making such big changes. You have not even left any justification, then or now, for redirecting all those pages, that doesn't boil down to "I did it because I wanted to".

Now, I do quite a bit of work with templates, and have done so for several years. Sometimes, a template gets converted to Lua, and its behaviour usually changes. To compare, I will copy the pre-Lua version over the current one, and preview an appropriate article (without saving the template). If the pre-Lua template had subtemplates, as Template:Documentation does, such a preview is useless if all the subtemplates have been mangled. --Redrose64 🌹 (talk) 23:10, 14 June 2018 (UTC)

Agreed. It is very useful to be able to check what an old version of a template did and there would need to be a good reason to complicate that functionality. To look at it another way, what possible benefit would there be from replacing Template:Documentation/core/doc with a redirect to some unrelated stuff? Johnuniq (talk) 02:04, 15 June 2018 (UTC)

For starters, because Template:Documentation/core was redirected to Template:Documentation years ago, and yet neither of you, nor anyone else that I've seen, have once complained about that redirect, even though that subtemplate was just as widely used as the others. But it's clear that I'm not going to make any headway here, so by all means let's leave these useless pages lying around because a small number of users likes to look at them once in a blue moon. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 07:14, 15 June 2018 (UTC)

this causes custom written css styles to not work very well. I'm using one that sets headlines in a serif font, but that does not apply to the "documentation" headline in the template, since css does not recognise it as a headline.

basically, to make it consistent with standard headlines across the wiki, I'd have to add class="mw-headline" to the span tag. I'm unsure as to how and where to change this, though, and I don't want to break anything. could anyone help me out here? —mountainhead / ? 16:18, 9 September 2018 (UTC)

So I noticed floated templates can look weird on the mobile site if viewed in a browser that supports floating. Inserting {{clear}} before the documentation template fixes it, but the clearing should probably not have to be put on every template page. Looking at the generated HTML, I spotted this:

<div id="template-documentation" class="template-documentation iezoomfix">

It would get solved if we used the following instead:

<div id="template-documentation" class="template-documentation iezoomfix" style="clear:both;">

But that's the HTML. To get it we would probably have make some change Module:Documentation, where I found this:

:addClass(message('main-div-classes'))

A bit later, I found this:

:css('clear', 'both') -- So right or left floating items don't stick out of the doc box.

Maybe making a copy of that line right after the other one would solve this? I don't know for sure, but I did think of another way to solve this: applying the following CSS to the mobile site:

.template-documentation{
    clear: both;
}

That's saying floated stuff can't be to the left or right of anything of the class template-documentation. Which should push the heading down.

This issue also affects any floated templates, though it looks more distracting if they're floated to the left. – Pretended leer {talk} 12:52, 24 October 2018 (UTC)

Make it like a documentation box because it's weird when looked with mobile view, just like Indonesian Wikipedia. For example, see id:Templat:Dokumentasi
Rayhan6726 (talk) 11:36, 2 February 2019 (UTC)

@Rayhan6726: Make what like a documentation box? This is the talk page for Template:Documentation, which is the documentation box. --Redrose64 🌹 (talk) 17:05, 2 February 2019 (UTC)

@Redrose64: the example is on id:Templat:Dokumentasi

Here's some better links for comparison: en and id. -- WOSlinker (talk) 08:30, 3 February 2019 (UTC)

Mobile doesn’t show a green documentation box. Apparently on Indonesian Wikipedia mobile, it shows a box? PorkchopGMX (talk with me - what i've done) 21:48, 10 February 2019 (UTC)

@PorkchopGMX: yes, it's like a green box on mobile view. For example, see id:Templat:Infobox pengguna. Rayhan6726     07:25, 4 March 2019 (UTC)

I recently added a bunch of Unicode data modules containing the names of ranges of code points, such as Module:Unicode data/names/000 (see a table listing all the name data modules at Module:Unicode data/doc § Data modules), based on the ones on Wiktionary. Ideally they should all have some text describing the range of code points that they apply to and be placed in Category:Unicode data modules. On Wiktionary the documentation of these modules is generated automatically by wikt:Module:documentation (so they do not have documentation pages). Could the same thing be done in Module:Documentation here on Wikipedia? I'm not very familiar with how the module works, and maybe it would be irregular to do it this way. I could also create a documentation template and add it to all the documentation pages of the modules. — Eru·tuon 21:00, 28 March 2019 (UTC)

With no response I decided to remove it from here and try somewhere else.--WikimeSteve (talk) 17:21, 18 July 2019 (UTC)

It's no secret to most of us that /doc pages are usually unprotected even if their template pages are protected. Just read a conversation here that tells us that inexperienced editors might see a padlock on a template page and assume the whole page, including documentation, is protected from their editing. Shouldn't we place a brief note near the top of the /doc page that explicitly says that the documentation can usually be edited even if the template cannot be edited? or something to that effect? Paine Ellsworth, ed. ^put'r there  17:22, 29 July 2019 (UTC)

That's a good idea. It's worth noting that Module:Documentation already reads the protection levels for the template page, so wouldn't take much tweaking to also read the protection levels for the documentation subpage. It would be a little more expensive, but nowhere near any limits, and would allow the documentation text to accurately state the protection level for the documentation page separately. --RexxS (talk) 18:00, 29 July 2019 (UTC)

Actually, /doc pages with their own separate padlocks might work even better than a textual note that might be missed. Even better! Pinging Mr. Stradivarius and Jackmcbarn for help with this. Paine Ellsworth, ed. ^put'r there  02:28, 30 July 2019 (UTC)

Currently, the CSS styling for this template is added in MediaWiki:Common.css based on the css class added by cfg['main-div-classes'] = 'template-documentation iezoomfix'. Rather than being specified in common.css, the css should be specified locally in the module. As seen in User:DannyS712/template sandbox 2, the current versions of the sandbox (Special:Permalink/905739909) and config sandbox (Special:Permalink/729280654) include the css locally within the template (demo: using safemode, sitewide css is ignored, but the css added by the module isn't) I propose that these changes be implemented:

• Change to module: [1] (without the first line that uses the sandbox config) (and potentially leaving the class, rather than replacing it)
• Change to config: [2]

This could be done without removing the html class currently used, even while removing the css from common.css, so as to remain compatable with current user scripts that may rely on the class. In time, it could be removed, but I see no hard in leaving it for now. Thoughts? --DannyS712 (talk) 17:58, 11 July 2019 (UTC)

Given the lack of comments, in a few days (unless there are objections) I will: add the css code to the config, add it to the module while leaving the current class declaration in case it is used by scripts, and then request that it be removed from the common.css. --DannyS712 (talk) 19:58, 14 July 2019 (UTC)

  Doing... DannyS712 (talk) 15:14, 19 July 2019 (UTC)

  Done - Special:Diff/906971056 and Special:Diff/906970692 --DannyS712 (talk) 15:20, 19 July 2019 (UTC)

I don't watchlist this page and didn't see the original request, but I'm opposed to moving CSS from classes to inline styles. It's exactly the opposite of what we should be trying to do. Adding styles inside module code is even more problematical, given the paucity of module editors. Inline styles make it difficult for editors who require modified styles because of visual impairments to override those styles. It is far better to move styling out of content and into style sheets, which allows a user style-sheet to override it. I think those edits should be reverted. --RexxS (talk) 16:56, 19 July 2019 (UTC)

@RexxS: I intentionally left the class declaration included, so that it can still be overridden by user style-sheets. Would it be better to use template styles? --DannyS712 (talk) 17:03, 19 July 2019 (UTC)

Yes. See the implementation of Module:Citation/CS1 or the bit of code at mediawikiwiki:Help:TemplateStyles#Calling from a Lua module. The styles in question should be at Module:Documentation/styles.css. --Izno (talk) 18:56, 19 July 2019 (UTC)

@Izno: Good to know - reverting --DannyS712 (talk) 20:26, 19 July 2019 (UTC)

  reverted --DannyS712 (talk) 20:31, 19 July 2019 (UTC)

Besides the RexxS concerns, I have a separate concern, which is that Lua pages automatically include the documentation styling, and I don't know how those get the template-documentation class--whether that's a class that's in Extension:Scribunto itself or whether we somehow call Template:Documentation somewhere on some interface page. Anomie? --Izno (talk) 18:56, 19 July 2019 (UTC)

@DannyS712: It doesn't help to leave the class in place. The way that cascading style sheets work is that each style that is processed overwrites any previous definitions of that style. So classes are processed first from the (global) MediaWiki software, then from mw:common.css, then from user common.css, next from user skin.css, and finally styles from any inline definitions are processed. That means that normally, any inline definitions will override all earlier ones, preventing a visually impaired user from setting colours to high-contrast ones, for example, for that class in their user stylesheets. TemplateStyles fit somewhere in that sequence, probably quite late on, so we'd have to do a test to determine whether we can still override them from user stylesheets. --RexxS (talk) 19:53, 19 July 2019 (UTC)

@RexxS: we should run that test then. I'm reverting myself, but per above templatestyles is better, and we have been migrating styles out of common.css so that they aren't always loaded when they aren't needed --DannyS712 (talk) 20:28, 19 July 2019 (UTC)

@DannyS712: I very much encourage shifting from common.css to TemplateStyles and I wrote some of the initial workflows and provided examples to encourage the take-up, so I'm on your side in that. Unfortunately I've just done the test and it's disappointing. You can do the test yourself:

1. Add the line .thermometer-bulb { background-color:blue; } to Special:MyPage/common.css and purge the page.
2. Look at page Template:Thermometer and purge the page. The bulb should now be blue, but it isn't.
3. Use the Inspector in your browser to check the styles for the div containing the bulb. You can confirm that your user css sets the bulb blue, but then the TemplateStyles overwrites it.

That's a bad mistake in the implementation of TemplateStyles, which need to be applied before user css. I suppose we need to thrash that out in Phabricator. For now, it's possible to work around it by using user css like .thermometer-bulb { background-color:blue !important; } (which does work), but that's a poor solution to a systemic problem. --RexxS (talk) 01:26, 20 July 2019 (UTC)

@RexxS: in that case, is there any difference in the result between using TemplateStyles and using this inline style, at least for now? --DannyS712 (talk) 01:28, 20 July 2019 (UTC)

@DannyS712: Yes, if we can get TemplateStyles to cascade in the correct place, then a visually impaired user can use their own stylesheet to modify the appearance of the content without any further action. If we use inline styles, that will never be possible without also moving all of the inline styles to TemplateStyles. Google "why inline styles are bad" for more opinions, or check this blog for a good description. IMHO, we should never apply static inline styles in a module; the only good reason for applying css in the module is when the style is dynamic, i.e. the module computes a value for the declaration or the style is conditional on other module content/parameters. --RexxS (talk) 01:57, 20 July 2019 (UTC)

@RexxS: would you object to moving this to templatestyles? DannyS712 (talk) 22:14, 23 July 2019 (UTC)

@DannyS712: I wouldn't object. It does mean that we still have some work to do in meeting best practice for accessibility, but moving from Common.css or from inline styles to TemplateStyles is a move in the right direction. Cheers --RexxS (talk) 18:50, 24 July 2019 (UTC)

@RexxS: There are a few reasons why you were unable to change the color.

1. The first is that the extension 'hoists' each of the selectors to .mw-parser-output, which really means the selectors in the TemplateStyles CSS page are actually .mw-parser-output .thermometer-bulb rather than your suggestion, .thermometer-bulb.
2. The second is that the styles are injected into each page inside of a <style> element much later than the <link> elements which invoke your mw.common.css, common.css, and skin.css files, which means that those styles apply after your common.css sheet does (the last CSS at a certain specificity is king). @Anomie: I do not know if it was intended for TemplateStyles to win over user-personal styles at the same specificity; if it was, was there an engineering tradeoff? We should perhaps document this in mediawikiwiki:Extension:TemplateStyles if so.

(On an aside, this problem might explain a previous problem that Headbomb was having--I will have to go poke and see if the below workaround fixes that one as well.)

Regardless of the above, this is a matter of specificity to override. In the former case, assuming the content was added before rather than after your personal css files, you would be able to override the bulb color with just .mw-parser-output .thermometer-bulb { background-color:blue; }. In the latter case, since that is not presently a true assumption, you can trivially increase the specificity by adding some other selector, such as .mw-parser-output div.thermometer-bulb { background-color:blue; } (nevermind that !important will also work and as the sheets are user-specific, !important probably isn't a big deal). --Izno (talk) 19:57, 3 August 2019 (UTC)

@Izno: I don't recall that order of TemplateStyles CSS versus user CSS was specifically discussed, and I don't see anything along those lines on T155813. The positioning of the TemplateStyles-generated <style> within the page was dictated mainly by performance concerns, specifically that including the styles in the HTML "above the fold" would slow down time to first paint on slow connections.

As you noted, it's not very hard to adjust your user CSS specificity so the ordering doesn't matter. Anomie⚔ 18:02, 4 August 2019 (UTC)

@Izno: Its specified at MediaWiki:Scribunto-doc-page-show --DannyS712 (talk) 20:30, 19 July 2019 (UTC)

Ok, that makes me more confident that we won't break anything from that perspective. Let's get the remaining invocations of template-documentation cleaned up in the various spaces that would otherwise break (i.e. add inline styling where appropriate) and then we should look at incorporating a TStyles page into the module. --Izno (talk) 19:16, 3 August 2019 (UTC)

I've taken care of the remaining invocations in the wild of template-documentation and I think I've successfully moved the various styles to the styles sandbox. Now I need to modify the main sandbox module for invoking the TemplateStyles page. I'm a little confused on why the metadata box invokes the message box module, but that's an aside. --Izno (talk) 18:23, 4 August 2019 (UTC)

So, I have an implementation that kind of works. It's breaking Template:Documentation/sandbox at the current revision (it works at my 'what does this do' revision previously) with an output of <p>{{ Template:Documentation/doc<style data-mw-deduplicate="TemplateStyles:r909327506">styles elided</style>}} </p>. Help is appreciated to get this over the hump. --Izno (talk) 19:58, 4 August 2019 (UTC)

There were also two tests broken as a result of this implementation in addition to the other five noted below; see testNoTrailingWhitespace and testSandboxImageBug. --Izno (talk) 20:00, 4 August 2019 (UTC)

In documentations for modules, we see the notice Editors can experiment in this module's sandbox (edit | diff) and testcases (create) pages. Note that the testcases link directs to the "/testcases" page (e.g. the testcases page for Module:Television ratings graph links to Module:Television ratings graph/testcases, which is a non-existent page), but most testcases for modules actually exist on the testcases talk page (e.g. Module talk:Television ratings graph/testcases). I haven't had a look at Module:Documentation's code much myself, but could we modify the testcases (create) pages text/link to appear as testcases (create | talk) pages for easy access to the module testcases talk page? Would this be possible? Cheers. -- /Alex/₂₁ 11:53, 10 October 2019 (UTC)

There are test suites we have here on Wikipedia for which it is reasonable to link to the module page instead. We really should be testing modules with those tools, not with outputs to HTML (which should live on Template:Documentation/testcases or similar). --Izno (talk) 13:34, 10 October 2019 (UTC)

Testcases for modules shouldn't exist in the talk namespace, because they aren't discussion. I've moved Module talk:Television ratings graph/testcases to Module:Television ratings graph/testcases. * Pppery * _{it has begun...} 21:46, 13 October 2019 (UTC)

So, there is now standard wikicode in the module namespace? Why? This is clearly incorrect; if I give another example, such as this, there is an edit warning that clearly states "The purpose of this page is to run the testcases stored at Module:Series overview/testcases." -- /Alex/₂₁ 22:52, 13 October 2019 (UTC)

So, there is now avoidable standard non-discussion content in the talk namespace. Why? The "Module talk:XXX/testcases" page title system is an outdated kludge. That warning itself is also wrong, because Module:Series overview/testcases does not exist, and Module talk:Series overview/testcases stores the testcases. * Pppery * _{it has begun...} 23:26, 13 October 2019 (UTC)

Lua code belongs in the Module space. Wikicode does not. It may be "outdated" to you personally, but it is still a widespread practice. You say the warning is wrong, but you have nothing to back it up. -- /Alex/₂₁ 23:41, 13 October 2019 (UTC)

It's going to be hard to get standardisation on these sort of issues because different folks work in different ways. From a purist point of view, I want to see Lua code in module space and wiki code in module talk space, but that's just my sense of "neatness". From a practical point of view, when somebody asks me to knock up a module to do a job, I'll usually get it working first in Module:Sandbox/RexxS/modulename and test its html output in Module talk:Sandbox/RexxS/modulename because it's convenient and keeps the two pages together so they are easy to find later on. It saves me remembering whether I called the test pages /testcases or /testing or whatever, and it's obvious from the module page whether I created a test page. I really don't get much in the way of discussion on the sandbox talk pages, so I console myself with the thought that talk pages in general are intended to be used not for discussion per se, but for discussing improvements to the corresponding page (and of course I tell myself that testing the module is the first step in improving it).

Anyway, my preference ends up being for (mis)using the related talk page to hold tests as well as discussion, but I'm not going to try to push my preferences onto others. When I've got loads of spare time, I'll convert all my testing pages to use the tools that Izno recommends, just as soon as I've found the link to the documentation for them. --RexxS (talk) 00:53, 14 October 2019 (UTC)

@RexxS: The two I've looked at previously are Module:ScribuntoUnit and Module:UnitTests. UnitTests I've used at Module:Citation/CS1/testcases/errors (though just by invoking a pair of templates since the module isn't particularly testable today, and just starting from basic expectations), and the other I started toying with at Module:Sandbox/Izno/citationTests. There's apparently also Module:Lua-mock, though unused. (Category:Modules for test tools on that note.) --Izno (talk) 01:26, 14 October 2019 (UTC)

There's also Module:Citation/CS1/testcases but that doesn't start from first principles. --Izno (talk) 01:34, 14 October 2019 (UTC)

And for anyone wanting more choice there is the quirky but super-efficient procedure at Template:Convert/testcases/sandbox1 (and 2/3/4). Sandbox1 has 1178 tests and that would be hard to achieve with some of the other test systems, and would be very difficult to update after a change affecting many results. The magic sauce which makes Wikipedia successful is the fact that people can work autonomously in an area of interest and competence so long as what they do is useful. Imposing pointless rules such as specifying the prefix (Template/Module/whatever) to be used for tests is unhelpful. Johnuniq (talk) 03:07, 14 October 2019 (UTC)

Right now there are 5 failing tests and I do not know how to fix them. I do not think they are related to recent changes, but I could just be blind. --Izno (talk) 19:26, 4 August 2019 (UTC)

I fixed three of the seven I saw failing. The remaining four failing tests seem to fail in the same ways with the current version of Module:Documentation too.

testEndBoxCategoriesBlurb

It's because _endBox returns nil for missing pages in the Wikipedia namespace, while the test is looking for a string.

testExperimentBlurbSandboxDoesntExist

Looks like it's testing for incorrect output, while the module is producing correct output.

testProtectionTemplateUnprotectedModule

Module:Bananas was protected in June 2019, the test should probably be updated to use some other module.

testRenderStartBoxLinksExists

Template:!/doc was deleted in January 2015, I guess this one has been failing for a long time.

HTH. Anomie⚔ 22:24, 4 August 2019 (UTC)

Down to one failing test, which is testEndBoxCategoriesBlurb. --Izno (talk) 00:28, 5 August 2019 (UTC)

Thanks for fixing all of these. Four years is a long time for a test to be broken... — Mr. Stradivarius ^{♪ talk ♪} 14:09, 28 October 2019 (UTC)

How would people feel about adding the ability to specify custom view/edit/history links? The use case is for templates like Template:Uw-autobiography. This template transcludes its documentation from {{single notice}} instead of from a /doc subpage, with the consequence that it doesn't have any links to where the documentation content is defined. If we could specify custom view/edit/history links then it would make it a lot easier for people to edit the documentation; at the moment, you have to be quite well-versed in template programming just to work out which page to edit. (See also the thread about this at Template talk:Single notice#Missing edit link when transcluded.) — Mr. Stradivarius ^{♪ talk ♪} 14:28, 28 October 2019 (UTC)

Just stopping by to see if there's been any progress on this. Do feel free to simply say "no, won't happen" if that's the case. Thanks, CapnZapp (talk) 22:32, 8 November 2019 (UTC)

Hi. I've created a doc page for Module:Wd/testcases, but for some reason the doc page of the parent module Module:Wd/doc is transcluded instead of Module:Wd/testcases/doc (while it actually does say "The above documentation is transcluded from Module:Wd/testcases/doc" at the bottom). Is there someone who could have a look at this please? Thayts ••• 15:18, 10 November 2019 (UTC)

Thayts the logic for which page to transclude as the doc page is controlled by MediaWiki:Scribunto-doc-page-show which does call Module:Documentation, but I haven't investigated beyond that point. @Mr. Stradivarius:? Frietjes (talk) 16:37, 10 November 2019 (UTC)

@Thayts: Without comment on the general feature request here (which would be useful for me too when I try to CSD an orphan testcases subpage that an admin forgot to delete) wouldn't it be better to just have the page Module:Wd/testcases be a wikitext page in this case rather than hackily relying on transclusion of /doc subpages. * Pppery * _{it has begun...} 01:36, 11 November 2019 (UTC)

@Pppery: I did not know that would be possible, but that would indeed be cleaner. Do you know how to get that done, without affecting its submodules? Thayts ••• 08:25, 11 November 2019 (UTC)

@Thatys: Yes. * Pppery * _{it has begun...} 15:47, 11 November 2019 (UTC)

Change content model to Wikitext, per discussion above. * Pppery * _{it has begun...} 15:47, 11 November 2019 (UTC)

  Done — xaosflux ^Talk 16:26, 11 November 2019 (UTC)

mw:Template:Documentation subpage has a much nicer design than this template. Could we steal some or all of it? Kaldari (talk) 18:48, 11 November 2019 (UTC)

Hey, I was pointed to this module on a recent bot request I made, and this made much more sense. {{Lua}} is used by some editors on the documentation page of their modules. Why this is good? Module code cannot be used as live links, so having a link on the documentation page helps other editors follow more easily to other modules without needing to use the search bar. Additionally, as far as I know (and correct me if I'm wrong), the "What links here" page does not recognize module usage, so adding the link to the documentation page, creates these links, which are far more user-friendly then using a search query.

How this should work? If the module is called in the Module namespace, it checks the module code for module dependencies in require() and mw.loadData(). If modules are found, it calls {{Lua}} and adds the module names to the list. This could also probably be used in the template namespace /doc pages.

Is this something that is possible? --Gonnym (talk) 13:06, 10 November 2019 (UTC)

It's definitely possible, albeit not in a 100% foolproof way. * Pppery * _{it has begun...} 19:29, 11 November 2019 (UTC)

The template appears to display a message like The above documentation is transcluded from Template:Example/doc whenever a doc subpage exists, whether it's actually transcluded or not. Apparently, if the documentation is supplied via the |content= parameter, then the subpage is ignored, but the message still says it's being transcluded. – Uanfala (talk) 12:02, 26 May 2020 (UTC)

This module transclude the doc page for the base page, not the subpage, for testcases and sandboxes (e.g., Module:Example/testcases will transclude Module:Example/doc, not Module:Example/testcases/doc). However, the blurb at the bottom will say The above documentation is transcluded from Module:Example/testcases/doc. You can see an example of this at Module:WikidataIB/testcases.

The template only shows up at all if Module:Example/testcases/doc exists, so it is obviously looking for that page, but it doesn't actually transclude it. Which is the intended behavior? --Ahecht (TALK
PAGE) 14:49, 21 July 2020 (UTC)

What is the process for updating the documentation for the sandbox version of a template? Can I copy the existing doc to /sandbox/doc and invoke that page? Jmar67 (talk) 09:53, 3 March 2020 (UTC)

Do you need a different documentation for the sandbox template? If so, why? --Gonnym (talk) 18:00, 3 March 2020 (UTC)

Six years ago (am I that old!?) I raised this issue regarding modules here. That concerns the fact that viewing Module:Convert/sandbox should show Module:Convert/sandbox/doc but it in fact shows Module:Convert/doc. Johnuniq (talk) 22:09, 3 March 2020 (UTC)

Surely we only need documentation for templates and modules that editors will use in articles? I don't see any reason for using sandbox versions of templates or modules in articles, other than for short periods while testing in a very restricted set of pages, so why would we need different documentation? If a fork of a template is justified, then it should be created as a separate template, which can then have its own documentation. Here are the 23 articles currently using sandbox versions of infobox templates. Should we change the behaviour of documentation to accommodate those, or should we fix the 23 articles to use the main infobox template or a proper fork? --RexxS (talk) 00:41, 4 March 2020 (UTC)

Depending on the situation, we may need to adapt the doc to the sandbox changes and then commit (implement) both at the same time. A good and current example is Template:infobox book. The doc should be loaded (transcluded) from the /doc subdirectory in the respective template directory (main or sandbox). Jmar67 (talk) 00:56, 4 March 2020 (UTC)

I can't see any reason to adapt the doc to sandbox changes. Who would it be for, and who will go to the trouble of revising documentation before there is any consensus for changing the main template? Once consensus for the change has been achieved, that's the time to update both the template and its documentation. In the unlikely event that somebody wants to go to the effort of revising the documentation ahead of consensus just to get it ready, then it can be done as a draft in Xyz/sandbox/doc (obviously it doesn't matter if that isn't transcluded). --RexxS (talk) 01:27, 4 March 2020 (UTC)

What is the next step concerning the IB book update? Assuming there will be consensus to implement your changes, the doc will have to be updated. When will that be done? It can't be done before the code goes live and also should not be done afterwards. I am talking about syncing the code and documentation. The logical way to do that is in "infobox book/sandbox/doc". Then implement both the code and doc at the time. I hope there is just a misunderstanding here. I was going to offer to update the doc in sandbox/doc but wanted confirmation that that was the correct procedure. (I also did not doubt that a consensus would be forthcoming.) But when I do that, I would expect the revised version to be transcluded when I am looking at the sandbox template. Jmar67 (talk) 01:56, 4 March 2020 (UTC)

If there is no consensus – and only two people have offered support for any changes at Template talk:Infobox book #Italic title, then there is no point in anyone else wasting their time. The template is in use on over 40,000 articles and we ought to establish a proper consensus to implement any changes. On the other hand, if a consensus is reached, then the template and documentation can be updated immediately. In the meantime, if you think that consensus is likely, then by all means draft revised documentation at Template:Infobox book/sandbox/doc and it can be copied over the existing Template:Infobox book/doc when consensus is reached. There is no "correct" or "incorrect" procedure; this is a wiki and we use it as needed. What I can't understand, though, is why you want or expect Template:Infobox book/sandbox/doc to be transcluded elsewhere. --RexxS (talk) 13:57, 4 March 2020 (UTC)

If I am looking at the live template, the documentation will be transcluded from /doc. If I am looking at the sandbox template, why do you need to see documentation for it. It's not as though , the documentation for it should be expected in, and transcluded from, /sandbox/doc (as noted above by Johnuniq). My concern is that, given consensus, the documentation needs to be reviewed before the code is implemented (unless you accept that the live documentation can then be iteratively updated until it is correct: I do not agree with that approach, but maybe it is acceptable). Secondary question: What constitutes consensus? How many editors need to support? Jmar67 (talk) 08:35, 5 March 2020 (UTC)

If you are looking at the sandbox template, why do you need to see documentation for it? It's not as though anybody is going to use it in an article. Sandboxes can change regularly and features added and removed far more often than the main template, and that puts an unnecessary burden on the sandbox editor to update documentation that nobody is going to use. It's far better to just transclude the main documentation, which is then updated after the main template has been changed. Updating the main documentation as needed is a job that can be done by anyone, as befits a crowd-sourced endeavour, and doing so as and when needed seems to work for all the other templates. --RexxS (talk) 16:09, 5 March 2020 (UTC)

It doesn't matter and I'm no longer concerned, but there is an example of why different documentation for the sandbox might be useful at my 22:09, 3 March 2020 comment above. Johnuniq (talk) 22:43, 5 March 2020 (UTC)

One can also implement the documentation changes in parallel and then revert them until the actual template is changed. --Izno (talk) 01:57, 4 March 2020 (UTC)

Yes, I would also like this feature. I have created Template:Dablinks/sandbox/doc to document changes in the sandbox, and if and when the sandbox is released, so should the doc page be. But the /doc page isn't visible anywhere, not even in the sandbox, which pulls in the main Template doc; that makes no sense. If a sandbox/doc page is available, then that should be transcluded. How else is someone looking at testcases for a sandbox change that may be complex, supposed to know what the changes are all about? Where else should documentation go, if not in a /doc page? Mathglot (talk) 07:10, 15 July 2020 (UTC)

There are many cases in which it would be useful to have a separate documentation page for the /sandbox and /testcases subpages. For example, the documentation often contains examples, a previewing the module page with the documentation can be easier than creating a separate test page. Similarly, the /doc page of the /testcases subpage can be used to display wikitext-based testcases (for example, a module that produced table rows might need to be wrapped in wikitext so the table displays correctly). Also, as pointed out below, while /sandbox/doc and /testcases/doc pages aren't displayed, the message at the bottom misleadingly says that is is being transcluded (e.g. Module:Example/sandbox will display The above documentation is transcluded from Module:Example/sandbox/doc despite actually being transcluded from Module:Example/doc. --Ahecht (TALK
PAGE) 15:06, 21 July 2020 (UTC)

I would also like this feature. An example is the Infobox lighthouse: the sandbox is being used to implement getting data from wikidata. I think Template:Infobox_lighthouse/sandbox/doc should be transcluded in Template:Infobox_lighthouse/sandbox, instead of Template:Infobox_lighthouse/doc currently. simon (talk) 11:50, 28 March 2021 (UTC)

Several minor corrections:

• Line 67: Please change lang=moin to lang="xml+smarty".
• Line 75: Please change lang=moin to lang="xml+smarty".
• Line 81: Please change {{tag|noinclude to {{tag|includeonly.

Olivier Ph. (talk) 10:56, 30 September 2020 (UTC)

Pursuant to Template talk:Documentation/Archive 10#Moving CSS, I've completed integration of TemplateStyles into the module sandboxes. Along with TemplateStyles integration, I've done some of the following (and diffs provided):

• Main diff from live
  • Added TemplateStyles integration
  • Minor refactorings
  • Instead of creating an fmbox for the bottom box, now is self-contained (the bottom box isn't an fmbox, lots of extra HTML, etc.)
  • Gave module space the same heading style as template space
  • Removed iezoomfix (obsoleted because we don't serve IE < 9 any more; related styles long gone from site Javascript)
• Config diff from live
  • Added TemplateStyles integration
  • Removed fmbox config per above
• Styles (new)
• Module testcases (all passing now)
  • Fix tests to pass with TemplateStyles
  • Removed/refactor invalid tests per main refactorings
  • Cleaned up test broken prior to working
• Template testcases
  • no change

One thing I did not change (and have no personal intent to, though you may if you please), is the addition of messages at the beginning of functions in the main module to match the addition of the templatestyles classes. In general, it is a bit uncertain to me whether all the HTML IDs/classes need to be in the config file, but I don't feel the need to press it.

I had a question or two for consensus before rollout (changes not yet made). I ask questions 1 and 2 primarily because of wide use of CSS (and some Javascript uses too) to Do Stuff to these selectors.:

1. There are HTML IDs in Config. This module could be invoked more than once on a page, which would cause an HTML validator to throw an error. Should these be removed? (From WP:TemplateStyles, Avoid using #id per the conventions. HTML IDs are supposed to be unique on a page. Templates are rarely used uniquely, and those that are initially single-use-per-page are often later used in unanticipated ways. Use classes instead of IDs for styling.)
   • #template-documentation can be targeted by CSS selector .template-documentation
   • #doc_editlinks can (now) be targeted by CSS selector .template-documentation-startbox .mw-editsection-like
2. I'd like to remove from the titles "template" so the class names would be .documentation-*. What do you think?
3. Right now there are two different styles for module/template spaces and everywhere else this template might be used. Does that make sense to retain? I don't notice the difference myself on a regular basis. I generally favor the style used in template/module space.

If there are other questions, please let me know. Feel free to edit the sandboxes of course if you see they need tweaking. --Izno (talk) 07:48, 12 November 2020 (UTC)

Re: In general, it is a bit uncertain to me whether all the HTML IDs/classes need to be in the config file, but I don't feel the need to press it. Looking at several Wikipedias, there are three different approaches (translated by Google translate):

1. Only English:
   • ru:MediaWiki:Common.css, ru:Шаблон:Doc/styles.css
   • sr:Медијавики:Common.css
2. Only local language:
   • it:MediaWiki:Common.css, it:Template:Man/styles.css
3. Mix of English and local language:
   • es:MediaWiki:Common.css – see also .template-documentation at the very bottom
   • fr:MediaWiki:Common.css, fr:Modèle:Méta documentation de modèle/styles.css
   • nl:MediaWiki:Common.css – e.g. "lijst" is Dutch for "list"
   • tr:MediaWiki:Common.css – e.g. "verd" is Turkish for "green", note CSS class name .template-documentation, tr:Modül:Belgeleme/config – see cfg['main-div-classes']
   • ar:ميدياويكي:Common.css – e.g. "طلب"‎ is Arabic for "order"

So it might make sense to allow localization of IDs/classes. —⁠andrybak (talk) 10:44, 12 November 2020 (UTC)

Support removing HTML IDs to avoid duplicates on the same page. There a bunch of usages of 'template-documentation', "template-documentation", and links to the anchor #template-documentation. Ouf of these, there are several usages of the id in CSS and JS user pages, which should be easy for fix. JS is often the snippet copied from Template_talk:Documentation/Archive_5#Documentation/links. The CSS is often for removing the green background (examples: 1, 2, 3), which seems to be copied from one source. —⁠andrybak (talk) 14:13, 12 November 2020 (UTC)

Removed the IDs. Did some other tweaks here and there. That snippet is interesting. I might add another div around the two there presently to allow users to define CSS flex/grid properties. --Izno (talk) 22:30, 12 November 2020 (UTC)

In fact, done. People can set flex or grid properties to change the order using class template-documentation-container, instead of using Javascript to rearrange. I haven't decided if it makes sense to wrap the other elements that can show up on the page, e.g. in case someone wants the sandbox notice to show up below the main elements. --Izno (talk) 18:24, 13 November 2020 (UTC)

Also added messages inline with where they are invoked. --Izno (talk) 16:45, 13 November 2020 (UTC)

I've removed the "other heading" CSS and code path. --Izno (talk) 21:41, 14 November 2020 (UTC)

And finally I've removed the 'template-' from the CSS names now. --Izno (talk) 18:01, 16 November 2020 (UTC)

Final steps:

1. Adjust Common.css to apply CSS to .documentation.
2. Move modules live.
3. Adjust user CSS for the following:
   • .template-documentation to .mw-parser-output .documentation
   • #template-documentation to .mw-parser-output .documentation
   • .documentation-meta-data to .mw-parser-output .documentation-metadata
   • #doc_editlinks can probably be switched over to .mw-parser-output .documentation-startbox .mw-editsection-like
4. Alert (active) Javascript users of the above classes.

   Not going to do this; the ones who need it will see it. --Izno (talk) 20:04, 19 November 2020 (UTC)

5. Remove CSS from Common.css

--Izno (talk) 02:55, 18 November 2020 (UTC)

Going live shortly. This should be fun. --Izno (talk) 17:30, 19 November 2020 (UTC)

Live and user CSS adjusted. As a note for the future, I saw a lot of the table[style*="background-color: #ecfcf4;"] pattern which looks like it may be there from before the anchor and now class was added for documentation-metadata.

Users who see this note can clean that by changing that selector to .mw-parser-output div.documentation-metadata. --Izno (talk) 18:50, 19 November 2020 (UTC)

@Izno: it appears this work removed the ability to link to a template's documentation as a section on the template's page (as opposed to linking directly to the documentation page), e.g. before this it was possible to link to Template:Documentation#template-documentation, and upon following that link, be deposited directly at the top of the documentation as though it was a section. (Obviously this isn't a big deal in the vast majority of cases: either the template output is insignificant or suppressed entirely when viewing the template page, or a link directly to the template's documentation subpage is sufficient, but there are still cases where the ability to link the documentation on the template's page is handy, and retaining an anchor to allow such links is insignificant compared to the rest of the module.) 「ディノ奴千？！」^{☎ Dinoguy1000} 12:31, 17 December 2020 (UTC)

Dinoguy1000, yes, as I discussed above. Its use was too few and likely in some cases to be duplicated. I do not see sufficient reason to return it. It is simple enough anyway for a person to scroll down these days. Anyway, often enough there is another header that can be linked on the same page, one guaranteed to be unique. --Izno (talk) 14:13, 17 December 2020 (UTC)

For context, it was used a total of 14 times. Total. And 5 of those are false positives for someone using it to link. Sometimes convenient? I am skeptical. If a link is truely needed, I have pointed out at least one alternative. --Izno (talk) 14:21, 17 December 2020 (UTC)

Please note that these previous instructions were incorrect, because on the /doc subpage to categorize the template itself, the categories are placed into includeonly tags, not noinclude tags.

"Categories that apply to the template itself should be added to the bottom of the /doc subpage, inside <noinclude>{{Sandbox other||...}}</noinclude>." Funandtrvl (talk) 22:12, 28 December 2020 (UTC)

I'd like to revive Template_talk:Documentation/Archive_10#Sandbox_documentation.

I would also like this feature. An example is the Infobox lighthouse: the sandbox is being used to implement getting data from wikidata. I think Template:Infobox_lighthouse/sandbox/doc should be transcluded in Template:Infobox_lighthouse/sandbox, instead of Template:Infobox_lighthouse/doc currently. simon (talk) 11:55, 28 March 2021 (UTC)

Tl;dr: Please modify Module:Documentation to allow addition of pass-thru params destined for a named template.

What I'm looking for, is to allow something like this:

• {{Documentation|Template:Welcome-foreign/doc|lang=es}}     # |lang=es to be passed through to the /doc page

so that the template doc page is transcluded with the passed parameter(s) given. I.e., in this example, passing through the |lang=es param, and effectively doing this:

• {{Welcome-foreign/doc|lang=es}}

The reason for this, is to allow a single /doc template to provide variable output, especially in the case of a tesselation of similar templates that may make more sense using a single, common /doc page, instead of a set of highly similar ones.

Background and use case

Members of the WP:Welcoming committee welcome new users by placing a friendly message on a new user's talk page. Several dozen welcome templates are available for this purpose, including about twenty aimed at users with poor English who appear to speak another language. For example, we have Template:welcomeen-zh for users who appear to speak Chinese, Template:welcommen-pt for Portuguese speakers, and so on (view complete list here). Most of these templates have their own /doc page, such as Template:welcomeen-zh/doc, Template:welcommen-pt/doc (some have very brief doc <noinclude>d right on the template page). These doc pages are mostly highly similar; for example, this diff: (compare Chinese /doc::Portuguese /doc), with the differences mostly constrained to the language name itself.

We recently consolidated these twenty similar templates into one, called {{welcome-foreign}}, with /doc page {{welcome-foreign/doc}}. The twenty or so legacy templates have been turned into wrappers (e.g., {{welcomeen-zh}}, {{welcomeen-pt}}). One downside of the consolidation, is that the consolidated /doc page no longer refers specifically to the language name, in the case of someone using one of the wrappers. That is, all the wrapper /doc pages now render exactly the same, regardless whether you're coming in from Chinese, Portuguese, or any other language wrapper. That is a loss of function from what the legacy templates provided.

Proposal and param handling

It seems like this problem could be remedied, by allowing the {{Documentation}} module to support pass-thru params. I can foresee a technical issue in possible confusion/collision of params, i.e., what if the template in question has a param called |heading= or |content= and so on. I see several possible solutions:

• disallow the four params already used by {{Documentation}} – not ideal, but probably okay for almost all templates
• disallow positional params – acceptable; in the case of {{welcome-foreign}}, positional param |1= is already aliased by named param |lang=; any template that wanted to take advantage of the new feature could simply add named aliases where needed.
• specify a conventional param naming adjustment, e.g. add a prefix token, like, say, underscore, or passthru_, so that:
  • coding {{Documentation|Template:Welcome-foreign/doc|passthru_fr}} would invoke: {{Welcome-foreign/doc|fr}}, or:
  • coding {{Documentation|Template:Welcome-foreign/doc|passthru_lang=de}} would invoke: {{Welcome-foreign/doc|lang=de}}, or simply:
  • coding {{Documentation|Template:Welcome-foreign/doc|heading=Doc page title|_heading=foo}} would invoke: {{Welcome-foreign/doc|heading=foo}}.

Justification

Template doc subpages are in the template space, and it seems somewhat artificial to cripple the utility of a doc page by not allowing it to use parser functions that might increase its usefulness, provide a better user experience (in this case, by including the correct language name), and ease the workload of template writers by having one /doc page to maintain, instead of twenty or more, every time something changes.

Template {{Welcome-foreign/doc}} currently contains a bit of code to substitute in the language name corresponding to the passed lang code, but it never gets invoked, because the code isn't passed to the /doc page by the {{Documentation}} module. (Only one of the legacy wrappers passes the code; see testing note.)

Testing note

One of the legacy templates, namely the Spanish one, {{welcomeen-es}} has been coded to pass thru the |es= parameter to the /doc page as positional param 1 (coded as: {{ {{{|safesubst:}}}welcome-foreign|es}}). It's when I noticed that this wasn't working, that I followed the breadcrumbs and ended up here. I've cloned this to {{welcomeen-es/sandbox}} specifically for anyone who wants to take this on, and needs something to test with. Note that I've changed the positional param |(1=)esto named param |lang=es in the sandbox version, because I presume that will be technically easier for the module to process, but feel free to change the sandbox version to whatever you like, to facilitate testing.

These templates are substed. It's not clear to me whether that plays a role in any of this.

One other possible wrinkle: all of the legacy templates (the wrappers) are included in the Twinkle installation, and are being used there. I'm unfamiliar with technical details of Twinkle, so just thought I'd mention it, in case it's relevant.

Summary

Thanks for reading this far; I tried to make this as clear as possible, sorry it is rather long. If {{Documentation}} could be modified to handle pass-through params, I think it could be useful beyond just this one situation. Thanks! Mathglot (talk) 21:41, 4 June 2021 (UTC)

  Not done for now: please establish a consensus for this alteration before using the {{edit template-protected}} template. Addition of arbitrary parameters to the module is probably not in the cards. You can maybe sell me on passthrough special-named parameters as in the 3rd bullet. However, probably the easiest way to do all this is simply {{documentation|content={{Welcome-foreign/doc|lang=es}}}} and then add some custom {{navbar}} to the specific doc page. Have you tried that? Izno (talk) 01:21, 5 June 2021 (UTC)

@Izno:, thanks for your response. That's an interesting idea, I'll look into that. Maybe a custom navbar can replicate the background color and other features of the {{Documentation}} template, so that's a good suggestion. Thanks again. Mathglot (talk) 22:06, 6 June 2021 (UTC)

@Mathglot: in addition to what Izno has described, another approach is what Template:Barnstar documentation does. You could create a separate template (e.g. Template:Welcome-foreign documentation) with its own parameters which contains the transclusion of {{Documentation}}. —⁠andrybak (talk) 14:21, 7 June 2021 (UTC)

@⁠Andrybak:, thank you, that's another good idea! I feel a bit sheepish that I didn't think of either one of these, before starting this discussion section, and I appreciate Izno's feedback and yours. I wonder if adding a "how-to" section to the /doc page of {{Documentation}} describing both of these ideas briefly might be of benefit to others who fall into this situation in the future? They are both really useful ideas, and may help speed a solution as well as reduce further questions like this one after this section gets archived. Mathglot (talk) 17:59, 7 June 2021 (UTC)

Ping correction: User:andrybak Mathglot (talk) 18:06, 7 June 2021 (UTC)

The use is (almost) described at #Usage in this template's documentation at the last item. It probably just needs a "if you realllly need it, you can call the specific doc's content via template in |content= as well as list it in the first parameter".

I do think that template documentation should shoot to describe the most common cases first (or only), so I'm not totally certain it needs to be present in the guidelines from that perspective.

As for pass-through template documentation, I'm not a fan. Trying to find cases where this template are used becomes quite difficult. Izno (talk) 18:17, 7 June 2021 (UTC)

I agree (most common first/only); this is admittedly an edge case. What I sometimes do in that case, is add a brief explanatory note, so the regular flow of the documentation narrative is not interrupted by verbiage from the edge case, but the detail is available (in small font, at the bottom somewhere) for those who are interested enough to click down and read it. Might work here. Mathglot (talk) 02:56, 8 June 2021 (UTC)

Go for it. Izno (talk) 03:22, 9 June 2021 (UTC)

Occasionally editors accidently use this template in the Article namespace, often because they simply copy the raw template code instead of invoking it. This generates a ugly empty green box which has no value. As I can't see a reasonable use for having a working {{documentation}} inside article namespace I would like to propose that the templates code be changed to suppress displaying inside the Article namespace. -- Asartea ^{Talk | Contribs} 17:31, 26 June 2021 (UTC)

This was mentioned on Discord and we found several cases where this occurred in the mainspace. I think the template shouldn't display at all in the mainspace, but rather place the page in Category:Pages with templates in the wrong namespace which should serve to making other related issues spotted more quickly as well. --Trialpears (talk) 17:42, 26 June 2021 (UTC)

I'd support this. A namespace detection wrapper is trivial to implement, and as Trialpears says we can then add a category to track them. There is absolutely no reason to display {{documentation}} in mainspace. firefly ( t · c ) 07:59, 30 June 2021 (UTC)

I've sandboxed a version that hides any transclusions in mainspace and instead adds Pages with templates in the wrong namespace. Would like to get a second opinion on implementation given localization concerns and such though (especially since the module has code indirectly dealing with doc pages for articles). Otherwise I will implement it in a week anyway. --Trialpears (talk) 11:20, 8 July 2021 (UTC)

When this template has been added to a page but there appears to be no subpage, the only button displayed is [create]. Often in this situation, the subpage actually does exist but the template page just needs to be purged, so it'd be nice if the purge button was displayed, just as it is when the documentation has been found. {{u|Sdkb}} ^talk 00:17, 11 February 2021 (UTC)

Mr. Stradivarius, I'm not overly comfortable with Lua. As you seem to be the primary editor of the module, could you help implement this? {{u|Sdkb}} ^talk 23:06, 11 October 2021 (UTC)

Code-wise this should be enough: Special:Diff/1035088965/1049459408. See also the new test failure of testRenderStartBoxLinksDoesntExist at Module talk:Documentation/testcases.
Is there a consensus for such a change? —⁠andrybak (talk) 23:35, 11 October 2021 (UTC)

@Andrybak, there's WP:SILENT consensus, given that it's not too huge a change. I'll be happy to make it myself if we're confident the technical aspect is sound. I haven't seen that test failure thing before—does that indicate that the technical aspect of the change is sound? {{u|Sdkb}} ^talk 02:24, 12 October 2021 (UTC)

Sdkb, sorry, I wasn't clear. The test failure is expected – the new sandbox version is outputting the new link, for which a testcase update would be needed.

The change in the output is also visible on the page Template:Documentation/testcases: for Template:Documentation/testcases/nodoc (second box above Template:Documentation/testcases#Notest), the sandbox output has the [purge] link, while the live template (for the same "nodoc" subpage) does not. —⁠andrybak (talk) 03:26, 12 October 2021 (UTC)

As for consensus for this, I don't mind either way. This use case is rare (editors could use Preferences → Gadgets → Appearance →   Add a "Purge" option to the top of the page [...] with keyboard shortcut for purging), but the cost is negligible. —⁠andrybak (talk) 03:32, 12 October 2021 (UTC)

Okay, implemented; thanks for the help! {{u|Sdkb}} ^talk 04:09, 12 October 2021 (UTC)

  You are invited to join the discussion at Wikipedia talk:Template documentation § Including TemplateData. I suggest there that TemplateData should be included in the documentation prefill content. SWinxy (talk) 06:12, 23 November 2021 (UTC)

On Module:Documentation/config#L-329 Template:Documentation/preload-filespace gets called but that page doesn't exist. Should it be created? What should its content be? - Klein Muçi (talk) 00:11, 20 December 2021 (UTC)

Deleted a decade ago. I've removed it. Izno (talk) 19:38, 21 December 2021 (UTC)

Please can Template:XXXX/sandbox2 and Module:XXXX/sandbox2 be recognised as sandboxes by this template? At the moment it is prompting me to create Module:XXXX/sandbox2/sandbox which is bizarre. Thanks — Martin (MSGJ · talk) 16:35, 13 January 2022 (UTC)

I would not be a fan of such a change. Non-sandbox numbered sandboxes should generally be temporary. Izno (talk) 16:42, 16 January 2022 (UTC)

When the /doc subpage exists, the template normally removes the doc links and replaces it with a [create] button.

However, there is one line that still shows even when the /doc does not exist:

Add categories to the /doc subpage.

The above message should be hidden when the doc does not exist.

Original code:

	local docTitle = env.docTitle
	if not docTitle then
		return nil
	end
	local docPathLink = makeWikilink(docTitle.prefixedText, message('doc-link-display'))
	return message('add-categories-blurb', {docPathLink})

It could be changed to:

	local docTitle = env.docTitle
	if not docTitle or not docTitle.exists then
		return nil
	end
	local docPathLink = makeWikilink(docTitle.prefixedText, message('doc-link-display'))
	return message('add-categories-blurb', {docPathLink})

Thanks! SuperDragonXD (talk) 01:50, 15 February 2022 (UTC)

Well, since no one replied (it's uncontroversial), I guess I'll send in an edit request? SuperDragonXD (talk) 06:47, 4 March 2022 (UTC)

Change

(although this is a cosmetic edit, it's better practice, especially for a high-use template). Qwerfjkltalk 16:34, 16 April 2022 (UTC)

  Done * Pppery * _{it has begun...} 17:07, 16 April 2022 (UTC)

When the documentation is placed on the template page itself (rather than on a subpage), then the entire contents of the documentation will reside inside the |content= parameter. That can lead to problems; for example, if someone attempts to add table syntax to the documentation, then the template will break.

So, I'm wondering: for documentation that's not transcluded from a subpage, it will be better practice to use a pair of framing templates instead: something like {{documentation top}} and {{documentation bottom}}, similar to how things are done with {{collapse top}} and {{collapse bottom}}, or {{archive top}} and {{archive bottom}}. – Uanfala (talk) 15:52, 3 March 2022 (UTC)

In my opinion, if the documentation section is more than a single line, then a /doc page should be created. Gonnym (talk) 15:56, 3 March 2022 (UTC)

If that was implemented, how about protected templates that have inline documentation? How can one edit that?

Also, as said above, I think big documentation should be added at a /doc subpage, for performance reasons, seperation of template content + documentation etc.

(Actually, the above was possible when you manually transclude the /start box and /end box of the old wikitext version (now deleted).) SuperDragonXD (talk) 00:51, 4 March 2022 (UTC)

If that was implemented, how about protected templates that have inline documentation? How can one edit that? This can be achieved by an filing an edit request after creating /doc subpage. Example: Template talk:Former Tor#Template-protected edit request on 3 July 2020. —⁠andrybak (talk) 18:28, 16 April 2022 (UTC)

  An editor has identified a potential problem with the redirect Template:Dokumentation and has thus listed it for discussion. This discussion will occur at Wikipedia:Redirects for discussion/Log/2022 July 15#Template:Dokumentation until a consensus is reached, and readers of this page are welcome to contribute to the discussion. Q𝟤𝟪 09:42, 15 July 2022 (UTC)

Please see Template talk:High-use § Different wording?.

—Trappist the monk (talk) 14:40, 24 November 2022 (UTC)

Would it be a good idea to add a link to set the sandbox's content to that of the main template? It could probably be done via {{#invoke:page|getContent|as=raw|page={{FULLROOTPAGENAME}}}}. — Qwerfjkltalk 18:55, 17 January 2023 (UTC)

This already exists if the sandbox doesn't exist (using {{documentation/mirror}}). If the sandbox does exist, then AFAIK there's no way for a link to replace the content of an existing page. * Pppery * _{it has begun...} 05:22, 21 January 2023 (UTC)

@Pppery, I'll see if I can do this in the sandbox. — Qwerfjkltalk 07:42, 21 January 2023 (UTC)

Nevermind, you're correct. — Qwerfjkltalk 07:46, 21 January 2023 (UTC)

Please see the discussion I started, about this template's Lua modules, at Wikipedia:Village pump (technical)/Archive 202#Standardising very popular template modules across projects. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:49, 24 January 2023 (UTC)

This edit request changes the generation of links to edit, view history, and purge. Instead of using fullurl to generate the link, it uses plain wikilinks via special pages for edit, history, and purge. The code is available in Module:Documentation/sandbox (diff). Testcases will need to be adjusted because they expect fullurls instead of wikilinks. SWinxy (talk) 22:37, 28 May 2023 (UTC)

I am getting a script error on Template:Documentation/sandbox, please check? This will need testing properly being deploying so do update the testcases as needed. Thanks. — Martin (MSGJ · talk) 07:21, 6 June 2023 (UTC)

Module:Documentation/config/sandbox probably needs resyncing to live (though im unable to do this right now since im on phone and the editor keeps fighting me) Aidan9382 _(talk) 07:53, 6 June 2023 (UTC)

I've done that and it seems to be working properly now — Martin (MSGJ · talk) 14:26, 6 June 2023 (UTC)

  Done Izno (talk) 01:24, 17 June 2023 (UTC)

@SWinxy, you can adjust the test cases yourself so far as I know. :) Izno (talk) 01:26, 17 June 2023 (UTC)

  You are invited to join the discussion at Wikipedia talk:Template documentation § Heading level: 2 or 3?. {{u|Sdkb}} ^talk 20:34, 22 July 2023 (UTC)

I'd like to implement two protected edits to the main module and /config submodule:

• add cfg['infobox-template-namespace-heading'] = 'Infobox documentation' to module:documentation/config on line 98.
• Implement this sandbox diff.

This code automatically detects if a transcluding page in the template namespace begins with "Infobox" and alters the header message to read "Infobox documentation" instead of "Template documentation" if that is the case. VanIsaac, GHTV ^cont_WpWS 02:19, 23 July 2023 (UTC)

Is there some consensus this should be done? It seems unnecessary to me, since all infoboxes are templates. * Pppery * _{it has begun...} 02:35, 23 July 2023 (UTC)

Well if you take a look at WP:Consensus, Bold Revert Discuss is a pretty prominent part of that policy. So yes, the BOLDness of this edit was unequivocally consensus. I happen to think there is a qualitative difference in development process and editor implementation with infoboxes that makes them unique enough from most "normal" templates to make recognizing those differences justifiable. I think calling them a template was up to this point just a convenience based on how that functionality was originally implemented, but given that I figured a mechanism for distinguishing them, I would call it unnecessary pedantry going forward to recognize only technical distinctions when we can do better. VanIsaac, GHTV ^cont_WpWS 05:50, 23 July 2023 (UTC)

The bold-revert-discuss cycle works differently with protected templates. Besides, I wasn't just procedurally objecting to this request as needing consensus, but also providing my own opinion on it. And I'm still not convinced that infoboxes are anything more than another type of template.

Anyway, I'll let another template editor handle this request - if they think it makes sense then feel free to go ahead. * Pppery * _{it has begun...} 13:42, 23 July 2023 (UTC)

Yeah, I'm not sure how TPEBOLD - a warning about bypassing BRD by advance permissions letting an editor impose their preferred version - remotely applies to someone making an edit request. Someone who wanted to revert would have at bare minimum the same functional permissions as I do to edit this module. — Preceding unsigned comment added by Vanisaac (talk • contribs) 06:13, 24 July 2023 (UTC)

That doesn't mean your request should get blindly applied either. You should expect admins to ask questions so someone else doesn't have to come along and ask for a revert. Anomie⚔ 10:29, 24 July 2023 (UTC)

And I think you'll find that I answered those substantive questions in the same edit I first questioned the procedural problem. I didn't stay with this line of concern over a single edit request, but rather I think the original insinuation of pre-clearance somehow being necessary is chilling to positive development on these kinds of templates and a direct violation of the principles behind the BRD cycle. It is that chilling effect that I want to nip in the bud. Edit protection is supposed to protect high-visibility templates from edit wars, vandalism, and technical problems, not to stifle their continued development. That has nothing to do with my innocuous edit request, and everything to do with the next one, ten, and three dozen edit requests that might not happen if less experienced editors perceive that they will be shut out of the process a priori. This is the last I will respond to this procedural concern here, but if you think there is an appropriate venue and you'd like to get larger participation for this discussion, please more it there. — Preceding unsigned comment added by Vanisaac (talk • contribs) 19:55, 24 July 2023 (UTC)

I support the change. SWinxy (talk) 02:34, 24 July 2023 (UTC)

I think technically that the documentation is not for the infobox but for the template that produces the infobox — Martin (MSGJ · talk) 19:06, 24 July 2023 (UTC)

I would respectfully disagree with that assertion. Documentation is primarily for editors who are implementing the template/module/infobox/etc. on project pages, while template and module editors are a decidedly secondary audience. Those article editors don't care about the technical implementation, they just care about presenting the content they want to add. Having guideposts that point to that content-aware mentality helps reassure those editors that they are in the right place. This is exactly the sort of thing that wayfinding designers do in the physical world to help people navigate unfamiliar environments, and that's exactly what may of our editors are facing here. VanIsaac, GHTV ^cont_WpWS 20:17, 24 July 2023 (UTC)

Any chance of an example (a link) with a description of what text would be different as a result of the proposed change? Johnuniq (talk) 23:41, 24 July 2023 (UTC)

Uh, sure. You can compare template:Infobox Unicode block to template:Infobox Unicode block/sandbox, as long as no one edits either of the sandboxes in the meantime. The heading right at the start of the documentation is the only thing that changes, from   Template documentation to   Infobox documentation. VanIsaac, GHTV ^cont_WpWS 05:06, 25 July 2023 (UTC)

Thank you. However, looking at those pages shows Template:Infobox Unicode block prominently as the title so having "Template documentation" as the subheading makes sense. Johnuniq (talk) 05:47, 25 July 2023 (UTC)

• Oppose – Who is the intended beneficiary of this edit request? Not readers of the encyclopedia, surely, because it's unlikely they'll ever be on a template page for an Infobox, reading the documentation. Then, who? Template:Infobox users, i.e., editors who want to know what the parameters are for a particular Infobox? Well, hiding the fact that an Infobox is, in fact, a template can only have a deleterious effect on those users if they are new; it *is* a template, and the parameters are template parameters; why confuse anyone and label the template as anything else but what it is? And if they're not new, it won't matter what you call it, and it's just a waste of time. Mathglot (talk) 08:58, 25 July 2023 (UTC)

  Not done: I'm aligned with the several above who think this is an unnecessary change, and a generally undesirable one from my point of view. Standard titles are desirable. There is also a slippery slope that this opens up to several different customizations that all ultimately become "template documentation". Izno (talk) 23:03, 25 July 2023 (UTC)

Izno, did your recent change to the module break the purge function? I ask because now when I go to [purge] a template, it takes me to the purge verification page for the /doc (not the template itself). Primefac (talk) 10:55, 31 July 2023 (UTC)

Testing shows that it's not that edit, it was the 17 June 2023 change. I don't have time to investigate further at the moment. Johnuniq (talk) 11:17, 31 July 2023 (UTC)

Oh good, glad it's not my fault. I think that part can be more or less trivially reverted. Izno (talk) 16:48, 31 July 2023 (UTC)

Should be fixed. Izno (talk) 17:21, 31 July 2023 (UTC)

o shoot it was my fault. Sorry! SWinxy (talk) 17:49, 31 July 2023 (UTC)

Hello, over at :species:Module:Documentation, as on :species:Template:BHL page, we are encountering the error message: "Lua error in Module:Documentation at line 144: message: type error in message cfg.container (string expected, got nil)."; is anyone who knows what this means able to fix it? Thank you very much, Maculosae tegmine lyncis (talk) 07:36, 27 August 2023 (UTC)

@Maculosae tegmine lyncis: This seems to be caused by Koavf importing the latest version of Module:Documentation to species:Module:Documentation, but not also importing the latest version of Module:Documentation/config to species:Module:Documentation/config. This has resulted in several necessary config fields being missing, among them cfg.container, the one shown in the error message on species:Template:BHL page. The way to fix it is either to revert the main module or update the config module. — Mr. Stradivarius ^{♪ talk ♪} 10:56, 27 August 2023 (UTC)

This is why I hate importing. :/ ―Justin (koavf)❤T☮C☺M☯ 19:05, 27 August 2023 (UTC)

  Done species:Special:Log/Koavf. ―Justin (koavf)❤T☮C☺M☯ 19:07, 27 August 2023 (UTC)

@Koavf: Almost - you imported to species:Module:Documentation/config/doc, but the correct page to import to is species:Module:Documentation/config. At the moment, species:Template:BHL page is still showing an error. — Mr. Stradivarius ^{♪ talk ♪} 00:11, 28 August 2023 (UTC)

  Done?????? All of them were "No revisions imported (all were either already present, or skipped due to errors)." This is why I hate importing. ―Justin (koavf)❤T☮C☺M☯ 04:42, 28 August 2023 (UTC)

Hello, I really don't know how the modules work, I added some codes to see if adding [info] (link to see the information of a page) next to [view] [edit] [history] and [purge] was worked but I get an error, can it be repaired? thanks 67.90.43.34 (talk) 02:29, 29 September 2023 (UTC)

Description of suggested change: Hello, please move it to subcategory Category:Documentation templates (Category:Template documentation is for doc templates and doc pages). Thx and best Regards.

Diff:

W like wiki ^{good to know} 00:23, 14 February 2024 (UTC)

  Completed. P.I. Ellsworth , ed. ^{put'er there} 02:53, 14 February 2024 (UTC)