Template talk:Documentation/Archive 10

This is an archive of past discussions about Template:Documentation. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 5

←

Archive 8

Archive 9

Archive 10

Subpages

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:

--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)

"documentation" headline isn't classed as .mw-headline

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)

Floating weirdness on mobile site

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

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)

Generating documentation for code point name modules

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)

Green box shows on Template pages but not on Module pages even though the Doc does show

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

Documentation edits

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)

Moving CSS

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:

Add the line .thermometer-bulb { background-color:blue; } to Special:MyPage/common.css and purge the page.
Look at page Template:Thermometer and purge the page. The bulb should now be blue, but it isn't.
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.

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.
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)

Module documentation

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/testcases2 (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)

5 failing tests

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)

Custom view/edit/history links?

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)

Wrong doc page transcluded

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)

This edit request to Module:Wd/testcases has been answered. Set the |answered= parameter to no to reactivate your request.

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)

Nicer design

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)

Detecting module usages

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)

Incorrect message when doc subpage exists but is not transcluded

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)