Template talk:Documentation/Archive 9

From WikiProjectMed
Jump to navigation Jump to search
Archive 5 ← Archive 7 Archive 8 Archive 9 Archive 10

Help with some codes for other wikis

Hi how can I force background colour and the outside box like ja:Template:Documentation/start box please because I would like to add 


<div class="template-documentation" style="background-color:#ecfcf4; border:1px solid #aaa; padding:12px;">

This type of bit to a module because some wikis doint have template in there main css so how can I add it to module please. what I means is how can I get it to show the green box to show if the wiki doesent have the css codes for it. 86.135.255.226 (talk) 15:09, 29 March 2014 (UTC)

I had a look into this, and there isn't an easy way to do it right now, as it would require changing both Module:Documentation and Module:Message box. This would be a good feature to develop for the next releases of these modules, but until then the only way of doing this is by copying the relevant parts of MediaWiki:Common.css into your common.css file. — Mr. Stradivarius ♪ talk ♪ 15:59, 29 March 2014 (UTC)
oh ok 86.135.248.121 (talk) 15:38, 6 April 2014 (UTC)

Watching documentation templates

It's irritating that, if I watch a template, I don't automatically watch the related /documentation page. To help alleviate this, would it be possible to add a "watch" link to the existing [view] [edit] [history] [purge] set? Or is there a better solution? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:44, 21 April 2014 (UTC)

When I want to watch a page like that I use popups; you can hover over the link and then click the "watch" link under the "actions" menu. Also, I'm not sure a watch link would be useful for most users, but perhaps someone better at CSS/JavaScript than I could tell you how to a customised link to your personal .js or .css pages? — Mr. Stradivarius ♪ talk ♪ 13:01, 21 April 2014 (UTC)
@Pigsonthewing: try this one. it's a bit hackish, but seems to work. you may also be interested in the infoboxgap.js script, which automates the procedure of inserting a numerical gap in an infobox before adding a new field (creates a link to 'infobox gap' in the tools section on the left side). Frietjes (talk) 17:04, 21 April 2014 (UTC)
Thank you. I asked about a script for infobox numbering a while ago and was told there wasn't one; I didn't know that had changed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:53, 21 April 2014 (UTC)

Duplicate "sandbox" and "testcases" links, please

Could duplicates of the sandbox/testcases links from the...

Editors can experiment in this template's sandbox (edit | diff) and testcases (edit) pages.

...line added at the bottom of the template be included in the title line at the top, please – e.g.

 .... Template documentation   [view] [edit] [history] [purge] [sandbox] [testcases]

...? I think I'd find it convenient and imagine others might too. Sardanaphalus (talk) 10:46, 24 April 2014 (UTC)

I like the idea of having it at the top, but not next to the doc page links. I put an idea of what I want in the sandbox. Mine should probably be made to look prettier, but I like the general concept better. Jackmcbarn (talk) 23:41, 24 April 2014 (UTC)
I also think having links at the top would be useful, as I often find myself scrolling down to find those particular links. If we're going to have something above the heading, though, it shouldn't be a sentence, as that looks out of place to me. Maybe we could add some navigation links to the top right, or maybe we could add a notice completely above the documentation box. More ideas are welcome. :) — Mr. Stradivarius ♪ talk ♪ 07:04, 25 April 2014 (UTC)
FYI, when originally designing these things, we intentionally did not place those links there. The reason was: Better to not confuse 1000s of people with meaningless links and to let the few dozen who actually use them take the effort of scrolling to a consistent easily findable spot in the page. I still feel that way —TheDJ (talk • contribs) 07:21, 25 April 2014 (UTC)
Also, the documentation page itself can be shared amongst templates, in which the particular suggestion is hardly possible/logical (though with lua, a lot can become possible). Those links are always page specific. It's also the reason of having the separate box for the links. Part 1 is the documentation, Part 2 is the Template generics. —TheDJ (talk • contribs) 07:25, 25 April 2014 (UTC)
This is also why i hate stuff like: {{lua}}. That stuff is a technical detail that we should not bother users of the template with. It belongs at the very bottom. —TheDJ (talk • contribs) 07:27, 25 April 2014 (UTC)
These are good points. In light of this, perhaps sandbox and test cases links at the top would be better implemented as custom user JS/CSS, rather than being added to Module:Documentation. Also, I do kind of agree about {{lua}}, even though I was the one who made it into the monstrosity it is today. :) Let's discuss changing that at Template talk:Lua. — Mr. Stradivarius ♪ talk ♪ 08:00, 25 April 2014 (UTC)
I would be in support of a sysop default enabled gadget that does this. —TheDJ (talk • contribs) 12:04, 25 April 2014 (UTC)
Template-editor default enabled, too.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  10:00, 5 May 2014 (UTC)
  • Sorry not to've returned here sooner. I'm not keen on Jackmcbarn's version – but appreciate the suggestion – and, unfortunately, as I don't know Lua, someone else will need to code whatever might be added. Adding the links is merely for convenience, but each time I find myself needing to scroll/page down, I'm reminded that it seems to be a convenience missed among all the others supplied. For simplicity's sake, I'd try to get the Documentation template, from wherever it'd been transcluded, to test whether or not the subpages /sandbox and /testcases existed and add or omit the links accordingly. I don't imagine a couple more links after [purge] on the title line would then risk confusing people, even if/when noticed, as they'd only appear if/when the adjacent /sandbox and /testcases pages existed.
Any chance something like the above might happen? Sardanaphalus (talk) 09:32, 5 May 2014 (UTC)

remove Module:HtmlBuilder

hi what about removing the dependacy on this Module:HtmlBuilder module because it is not longer avilible nor updated. what about using this which is basically what the module is http://www.mediawiki.org/wiki/Extension:Scribunto/Lua_reference_manual#HTML_library 94.197.122.87 (talk) 13:37, 7 May 2014 (UTC)

See Wikipedia talk:Lua/Archive 2#mw.html library nil behaviour. — Mr. Stradivarius ♪ talk ♪ 13:43, 7 May 2014 (UTC)

Error in module:documentation/sandbox

Hi there's an error in module:documentation/sandbox because when visiting template:documentation/sandbox it shows this error

Lua error in mw.html.lua at line 345: Tag name must be a string. Backtrace: [C]: in function "error" mw.html.lua:345: in function "create" Module:Documentation/sandbox:129: ? (tail call): ? mw.lua:571: ? — Preceding unsigned comment added by 94.9.136.59 (talk) 15:09, 8 May 2014 (UTC)

It's a sandbox. Who cares? Besides, Darklama is actively editing it right now. Jackmcbarn (talk) 15:14, 8 May 2014 (UTC)
ok sorry 94.9.136.59 (talk) 15:37, 8 May 2014 (UTC)

Please revert from the old logo to the new one please change this

-- 'documentation-icon-wikitext' --> 'Documentation icon'

To

-- 'documentation-icon-wikitext' --> 'Documentation icon'

Because the latest edit revert to the old logo use in template documentation 2.218.227.206 (talk) 16:19, 3 June 2014 (UTC)

Why? The new one is better. Jackmcbarn (talk) 16:20, 3 June 2014 (UTC)
we had the logo a while back and then we switchtched to the png one because that one looks much better. 2.218.227.206 (talk) 16:26, 3 June 2014 (UTC)
Can you point me to a diff? Also, the PNG one looks terrible on high-DPI screens, since it doesn't scale up. Jackmcbarn (talk) 16:33, 3 June 2014 (UTC)
What if we used File:Test Template Info-Icon.svg or File:Test Template Info-Icon - Version (2).svg? Jackmcbarn (talk) 16:37, 3 June 2014 (UTC)
ok could we use this [[File:Test Template Info-Icon - Version (2).svg]] please. 86.135.251.100 (talk) 18:25, 3 June 2014 (UTC)
 Done Jackmcbarn (talk) 22:38, 3 June 2014 (UTC)
Thanks. 86.135.251.100 (talk) 06:43, 4 June 2014 (UTC)

Big gap at bottom

Hi there is now a big gap at the bottom of documentation. 2.124.129.220 (talk) 10:37, 6 June 2014 (UTC)

I don't see a big gap. What page is it on? Jackmcbarn (talk) 13:58, 6 June 2014 (UTC)
My guess: extra whitespace is being introduced by the category code at the bottom of whichever /doc page is being displayed. — Mr. Stradivarius ♪ talk ♪ 15:36, 6 June 2014 (UTC)
it is at the bottom. It is between the end box and categories. 2.124.129.220 (talk) 23:22, 6 June 2014 (UTC)
I see a relatively large gap before the categories in Template:Periodic table, but not in Template:History of Japan. note that switching to the old version of the template removes the gap. checking the HTML source, it looks like tidy (or something) is adding an extra <p><br></p> at the end, which is usually a sign of spurious newlines. Frietjes (talk) 23:41, 6 June 2014 (UTC)
Ah, yes, you're right. A little playing with Special:ExpandTemplates shows that Module:Documentation is adding an extra newline right at the end of the output. It doesn't appear to be a problem with Module:Message box, but in Module:Documentation itself. — Mr. Stradivarius ♪ talk ♪ 00:43, 7 June 2014 (UTC)
And now fixed. It was an extra .newline() before the tracking category function. — Mr. Stradivarius ♪ talk ♪ 00:49, 7 June 2014 (UTC)
thanks 86.135.251.100 (talk) 16:11, 7 June 2014 (UTC)

Logo for module

Hi could we add a logo for module so it is not using the one for if it was on a template or something else please. 86.135.251.100 (talk) 16:18, 7 June 2014 (UTC)

Why? You still use curly braces when calling modules from wikitext, and the logo signifies "documentation" more than "template" anyway. Jackmcbarn (talk) 16:30, 7 June 2014 (UTC)
ok 86.135.251.100 (talk) 19:24, 7 June 2014 (UTC)

Mobile view

Hi when visiting a page with template documentation for example Template:infobox it does not show it correctly meaning the background is not shown and the edit button is to close to the name of the template. On the iPad it does not look so good. 86.135.249.133 (talk) 19:48, 18 June 2014 (UTC)

Found a way of adding background colour

Hi I had found a way of adding background colour by using this code 

	local root = htmlBuilder.create()
	root
		.wikitext(p.protectionTemplate(env))
		.wikitext(p.sandboxNotice(args, env))
		 -- This div tag is from {{documentation/start box}}, but moving it here
		 -- so that we don't have to worry about unclosed tags.
		.tag('div')
			.attr('id', message('main-div-id'))
			.addClass(message('main-div-classes'))
                        .css('background-color', '#ecfcf4')
                        .css('border', '1px solid #aaa')
                        .css('padding', '12px')
			.newline()
			.wikitext(p._startBox(args, env))
			.wikitext(p._content(args, env))
			.tag('div')
				.css('clear', 'both') -- So right or left floating items don't stick out of the doc box.
				.newline()
				.done()
			.done()
		.wikitext(p._endBox(args, env))
		.wikitext(p.addTrackingCategories(env))
	return tostring(root)
end

So wikis that doint have the colour set in mediawiki.common.css. Can set background colour now. 86.135.249.133 (talk) 18:46, 21 June 2014 (UTC)

We build our templates for Wikipedia. We're not going to add extra complexity to them so they work on non-WMF wikis. Jackmcbarn (talk) 18:50, 21 June 2014 (UTC)

Debate by edit summary

Would Technical 13 please explain the purpose of the proposed edits, and allow time for others to respond. WP:TPE was not intended for playing ping-pong. Johnuniq (talk) 04:09, 3 July 2014 (UTC)

  • Short version, WP:EDITCONSENSUS; long version on my talk page as I'm unable to expand from my mobile at this time. — {{U|Technical 13}} (e • t • c) 11:32, 3 July 2014 (UTC)

Module:Documentation/config still uses "docusage"

This parameter was removed from Template:Pp-template in 2010, but is still present in Module:Documentation/config. Shouldn't it be removed from the module as well? Helder.wiki 17:17, 7 July 2014 (UTC)

Module:Documentation: allow parameter aliases

Hi!

I finally had the time to try to replicate the migration of the template to Lua on Portuguese Wikipedia, since the module is intented to be portable, but the parameter "conteúdo" ("content") did not work. Could this be implemented in the configs? Helder.wiki 22:12, 3 July 2014 (UTC)

As in: the template should understand non-English parameter names? No. I think non-English template/parameter names should not be allowed. See lengthy discussion here. -- [[User:Edokter]] {{talk}} 09:48, 4 July 2014 (UTC)
You need to port the template over to pt.wikipedia. Once it's been copied there, you can rename all the parameters whatever you want. But en.wiki does not support non-English parameters, and will not add them. VanIsaacWScont 10:33, 4 July 2014 (UTC)
Sorry, I was talking about the module but now I see that Module talk:Documentation redirects here...
Anyway, what I need is something like Mr. Stradivarius did for Module talk:Namespace detect#Allow parameter aliases, to reduce the maintenance of a fork of the Module:Documentation. Helder.wiki 12:38, 4 July 2014 (UTC)
@Helder.wiki: Would a simple one-to-one switch be enough? As in, you set the "content-parameter" message to "conteúdo", and then the |conteúdo= parameter works but the |content= parameter doesn't? Or do you really need a solution like Module:Namespace detect's, where the default English parameter names are always available, and a table of aliases for each parameter can be specified in the config? — Mr. Stradivarius ♪ talk ♪ 13:55, 4 July 2014 (UTC)
@Mr. Stradivarius:: from what I see in the current ParserFunctions-based code, both "content" and "conteúdo" are available, so it would be better to keep both working. Helder.wiki 14:24, 4 July 2014 (UTC)
@Mr. Stradivarius: Do you think the module would work as expected if I make this change in pt:Template:Documentação?
- {{#invoke:documentação|main|_content={{ {{#invoke:documentação|contentTitle}}}}}}
+ {{#invoke:documentação|main|_content={{ {{#invoke:documentação|contentTitle}}}}|content={{{conteúdo|{{{content|}}}}}}}}
Helder.wiki 18:21, 4 July 2014 (UTC)
@Helder.wiki: Yes, I think it would work, but you don't need to do that now. I've added code to allow multiple parameters in Module:Documentation/sandbox and Module:Documentation/config/sandbox. Would anyone object to me updating the main module with this code? — Mr. Stradivarius ♪ talk ♪ 01:35, 5 July 2014 (UTC)
Nice! I didn't test, but the code looks good to me. Helder.wiki 02:42, 5 July 2014 (UTC)
I implemented the new version in Portuguese Wikipedia. It seems to be working fine. Helder.wiki 14:51, 8 July 2014 (UTC)

Do we support a "/Print" page version this way?

I stumbled upon a /Print subpage. It appears to show extra text in the Link box. This is where: {{Infobox element}} (with its /doc) has Template:Infobox element/Print, named in the /doc link box way below. I assume it has an "#ifexist" switch.

I wonder if that is still the right way to go. Shouldn't all "print" options (aka "print version"?) be controlled through HTML classes &tc.?

Unless I learn more from this, I'll put that single example page up for speedy. And I note that, in template ns, one cannot even get a (wiki) "printable version" a page (as in mainspace, userspace, most talkspaces). -DePiep (talk) 16:51, 17 July 2014 (UTC)

A /Print subpage, whilst not common, is recognised as a normal feature. If you look at the bottom of Template:Infobox element, the bottom documentation box (beginning "The above documentation is transcluded from Template:Infobox element/doc") has four lines instead of the usual three. The extra line reads "A print version of this template exists at /Print. If you make a change to this template, please update the print version as well." --Redrose64 (talk) 19:05, 17 July 2014 (UTC)
Are those /Print templates even working? See bugzilla:48052. Helder.wiki 19:12, 17 July 2014 (UTC)
re Redrose64: yes, that was what I am pointing at ("Link box" is used to refer to the bottom box of a doc page, where /sandbox links are).
So my question is: what is is good for, nowadays? A "normal feature"?, I have not met it ever. It also looks like one has to change the transcluding page code (article?) to consume its effect. No more background? -DePiep (talk) 21:22, 17 July 2014 (UTC)

Links beside the "Template documentation" heading

Hello again. How do I edit the module to add "[sandbox]" and "[testcases]" links after the "[view] [edit] [history] [purge]" links that currently appear beside the "Template documentation" heading? Sardanaphalus (talk) 11:47, 8 September 2014 (UTC)

The first step would be to get agreement that such a change was desirable. You know that those links are already in the "The above documentation is transcluded from..." box at the bottom? Johnuniq (talk) 12:27, 8 September 2014 (UTC)
  • Yes, which is where I keep finding myself scrolling/jumping to find them – hence the request. Sardanaphalus (talk) 00:23, 9 September 2014 (UTC)
or try User:Frietjes/docsandboxtestcaseslinks.js by (a) copying it to 'User:YourName/docsandboxtestcaseslinks.js' and (b) adding importScript('User:YourName/docsandboxtestcaseslinks.js'); to your personal common.js file. the name of the script is probably not the best, so feel free to call it whatever you want. also, feel free to modifying it to do whatever you want. Frietjes (talk) 15:38, 8 September 2014 (UTC)
  • Copied and activated the script per your instructions and it seems to be working well. Thank you very much. The righthand side of the script looks the most goobledygooky I've seen for a while – making it the more impressive and leaving me hoping that creating/checking/testing it didn't lead to a headache. Thanks again, Sardanaphalus (talk) 00:23, 9 September 2014 (UTC)

Bugged display

At Module:Related changes, which does have a functional Module:Related changes/doc page, I'm getting a script error instead of the doc page due to a nil concatenation in line 728. This is from the result of p.makeExperimentBlurb returning a nil at line 828 if there is an error with one of several variables. I haven't tried to figure out why one of those would be missing (I think it is a bit involved), but I think it makes sense to return a text that says which variable is nil (or at least that one of them is) rather than letting it go to a script error. (This was due to a proliferation of expensive function calls on the documentation page, which contained an example; nonetheless, this module shouldn't be left to break) Wnt (talk) 01:32, 9 September 2014 (UTC)

When the parser goes over its limits, logic breaks down. The only way we could handle this would be to have code essentially equivalent to assert(2+2==4) all over the place (and even that wouldn't fix it, just make the error a little more informative). Jackmcbarn (talk) 01:35, 9 September 2014 (UTC)
It was just the one place that was missing the nil check, so I've added it, and the page is no longer displaying a script error. Seeing as I've already added checks all over the place it seems a shame to let just one missing check spoil the effect. @Wnt: By the way, the variable was missing because Module:Related changes/doc is over the expensive parser function limit, so you might want to fix that. — Mr. Stradivarius ♪ talk ♪ 07:10, 9 September 2014 (UTC)

Similar color scheme for template statistics

In the /color scheme I have described the color scheme as used for this documentation page. Basically it is has the pattern from Help:color (note the HSV basics, and that {{Documentation}} has slightly off-colors). All OK so far.

For {{Track gauge}} (10k tc's) I have made an automated documentation (to present a module data page by template; see /doc and {{Track gauge/doc/input options}}). Then, I have added statistics about the data page. For these statistics, I used the followiung color scheme: (more shortly) -DePiep (talk) 22:40, 10 September 2014 (UTC)

Template:Documentation/preload

 – Better venue for discussion. Funandtrvl (talk) 16:39, 14 August 2014 (UTC)

Hello – I think I understand your intention here, but, given that it means {{#ifeq:}}'s opening and closing braces are no longer aligned, I'm wondering if the result is wise..? Sardanaphalus (talk) 10:40, 14 August 2014 (UTC)

Yes, of course, but I'm concerned about newlines causing whitespace breaks. I'll ask about it, as I'm not an expert! Funandtrvl (talk) 16:06, 14 August 2014 (UTC)
Yes, we should avoid excess line breaks, as they will show up in the documentation output. — Mr. Stradivarius ♪ talk ♪ 17:27, 14 August 2014 (UTC)
The edit in question was fine, it did nothing apart from remove a few unnecessary (and possibly undesirable) newlines. It's often forgotten that if whitespace occurs on either side of a <includeonly> or a </includeonly>, that whitespace is kept after the processing is complete and those includeonlys are no longer there. --Redrose64 (talk) 19:49, 14 August 2014 (UTC)
  • It removes some whitespace at the end of a page, but it's at the cost of the code's presentation – not at a great cost, but if it encourages editors to do the same elsewhere... Perhaps a more aligned version with whitespace removed by comment tags..? Sardanaphalus (talk) 21:49, 15 August 2014 (UTC)
No. I see too many templates as it is that hide the newlines in comments. In some cases, every single line begins with --> and ends with <!--. These make it more difficult to find the real template code; often they are completely unnecessary, in the few cases where they are apparently needed, a simple repositioning of the code following the comment marker also renders them superfluous. --Redrose64 (talk) 22:08, 15 August 2014 (UTC)
  • And no to a little whitespace (in this case, at the end of a page) that aligns the starts/parts/ends of functions/templates/etc..? Sardanaphalus (talk) 08:16, 16 August 2014 (UTC)
No indeed. After all, this {{#if:...}} is paired with the tags, and this way shows nicely together with them (while not sdistracting me from the lines between I and supposed to take care of. And to be clear: the <includeonly> tags also should be used end-of-line, not newline, to prevent whitespace. That page-effect really trumps the editors-overview. (To be complete, I find the current layout ideally to keep sandboxes out of categories &tc.). -DePiep (talk) 09:52, 16 August 2014 (UTC)
  • On further reflection – and by the same token as above – I can see that leaving whitespace around includeonly/noinclude/etc tags may encourage editors to do the same elsewhere, so, yes, in this situation where these tags are mixed with functions, it's probably best to sacrifice alignment etc in the code's presentation. Thanks to all for their contributions. Sardanaphalus (talk) 08:35, 17 August 2014 (UTC)

Categories

Why does this boilerplate (that is, the preload text) suggest that the documentation page is the appropriate place for categories? It seems to me that, e.g. {{[[Template:|]]}} should be put in categories directly, not via its /doc page... Is there a logic do doing it via the /doc page? See here where I was confused. Wondering whether to put Template:PD-MAGov into Category:US State PD templates or not.--{{U|Elvey}} (t•c) 07:24, 11 September 2014 (UTC)

@Elvey: It's because the category that a template belongs to is not part of the template proper, but is additional information. The documentation for the template is similarly not part of the template proper but additional information. By splitting this additional information out to a subpage (the /doc page), we can have the template proper given a high level of protection, whilst the /doc page is almost always unprotected. Furthermore, if the template proper is edited, every page which transcludes that template will need to be re-parsed (which for a high-use template can take a long time), but if the /doc page is edited, only three pages need to be re-parsed: the /doc page, the template itself, and the template's /sandbox. --Redrose64 (talk) 07:46, 11 September 2014 (UTC)
@Redrose64: Thanks! Makes sense. Works as long as the goal is NOT to put files using the template into a new category, but is rather just to put the template itself into a new category. --{{U|Elvey}} (t•c) 15:09, 11 September 2014 (UTC)

Incorrect categorisation

Template:Chinese calendar is in Category:Wikipedia pages with incorrect protection templates. It shouldn't be, because all it contains is {{documentation}}. Before it was Lua-ised, Template:Documentation worked out what the prot level of the transcluding template was, and if the page was protected, it would display an appropriate padlock icon; if it wasn't protected, it did nothing. Either way, a template could only end up in Category:Wikipedia pages with incorrect protection templates if it had a prot template like {{pp-template}} in addition - like this. Sometimes, that unnecessary template was put on the /doc page inside <includeonly>...</includeonly> (like this), but that's not the case with Template:Chinese calendar/doc. What's going on here? --Redrose64 (talk) 18:00, 17 September 2014 (UTC)

Well this template is certainly transclusing {{pp-template}} so that's why we're getting the error. The question is where is this template coming from? I suspect it might have something to do with Module:Documentation or perhaps Module:Effective protection level which was edited yesterday. I note also that this template is move-protected so perhaps that is affecting something it shouldn't. — Martin (MSGJ · talk) 21:28, 17 September 2014 (UTC)
I have removed the move-protection and the category has disappeared. So this suggests to me that Module:Documentation is incorrectly detecting the protection level of the templates. — Martin (MSGJ · talk) 21:37, 17 September 2014 (UTC)
Here seems to be the relevant code:
	local editLevels = protectionLevels.edit
	local moveLevels = protectionLevels.move
	if moveLevels and moveLevels[1] == 'sysop' or editLevels and editLevels[1] then
		-- The page is full-move protected, or full, template, or semi-protected.
		local frame = mw.getCurrentFrame()
		return frame:expandTemplate{title = protectionTemplate, args = message('protection-template-args', nil, 'table')}
	else
		return nil
	end
What padlock should be shown if the template is move-protected but not edit-protected? — Martin (MSGJ · talk) 21:42, 17 September 2014 (UTC)
In general, none. That's why {{pp-move-indef}} doesn't use Module:Protection banner. @Mr. Stradivarius: This needs to be made to use {{pp-move-indef}} rather than {{pp-template}} in this case. Jackmcbarn (talk) 22:46, 17 September 2014 (UTC)
The padlock for move protection is green. This is displayed by {{pp-move}} - which is mainly used for fixed-duration move protection - but not by {{pp-move-indef}}. There's a bug in {{pp-move-indef}} in that if the page is move protected, but at template-prot level instead of full, it categorises into Category:Wikipedia pages with incorrect protection templates. But this was not the case here, because Template:Chinese calendar had full move prot.
The thing is, having a page that is move-prot but not edit-prot is quite common, and the old {{documentation}} handled it perfectly well. I'm sure that of the many templates where I've removed an improper {{pp-template}} (or similar), in those cases where the page was move-protected, my edit removed the page from Category:Wikipedia pages with incorrect protection templates in every case. Template:Chinese calendar was the only one where I couldn't do that - mainly because I couldn't find anything to actually remove. --Redrose64 (talk) 23:11, 17 September 2014 (UTC)
@Redrose64: There's no bug in Template:Pp-move-indef. The bug is in Module:Documentation. Jackmcbarn (talk) 23:14, 17 September 2014 (UTC)
No, I wasn't saying that the Template:Chinese calendar problem was due to a bug in {{pp-move-indef}}. I was describing a separate issue - by putting it on a different paragraph - and in that I'm saying that {{pp-move-indef}} has a bug for any page that is move protected but not fully move protected. See for example User talk:Redrose64/Sandbox2. --Redrose64 (talk) 23:33, 17 September 2014 (UTC)
@Redrose64: Oh, I see. It doesn't like move=templateeditor. If you want to fix that, apply the changes from Special:Diff/626012732 to it. By the way, for move=autoconfirmed, its behavior is correct, since move=autoconfirmed is the same as no move protection at all. Jackmcbarn (talk) 23:39, 17 September 2014 (UTC)
Yes, I know - you've mentioned this before; perhaps I should have linked to Template talk:Pp-meta#Move protection, but not admin-only. --Redrose64 (talk) 06:50, 18 September 2014 (UTC)
The Chinese calendar problem is also showing at Template:Fact-now. --Redrose64 (talk) 20:15, 20 September 2014 (UTC) Also at Template:Infobox aluminium, Template:Infobox Olympic games, Template:Infobox OS, Template:IPAc-cmn. --Redrose64 (talk) 11:04, 26 September 2014 (UTC)
@Mr. Stradivarius: could you help debug this please as it appears it may be your module code at fault? — Martin (MSGJ · talk) 09:14, 24 September 2014 (UTC)

Sorry for the delay in addressing this. With respect to move protection, Module:Documentation does essentially the same thing as the old Template:Documentation did. Here's the relevant snippet from the old template code: 

{{template other
| {{#ifeq: {{PROTECTIONLEVEL:move}} | sysop
  | {{pp-template|docusage=yes}}
  | {{#if: {{PROTECTIONLEVEL:edit}}
    | {{pp-template|docusage=yes}}
    | <!--Not protected, or only semi-move-protected-->
    }}
  }}
}}

That is the same logic as the module snippet Martin included above. The difference is that the functionality of {{pp-template}} has changed after the switch to Module:Protection banner. It now only detects edit protection, whereas before it detected edit and move protection. This was a design decision in Module:Protection banner - writing that module forced Jackmcbarn and I to consolidate {{pp-meta}} and its daughter templates into one coherent framework, which was not so easy given the amount that the various daughter templates had been extended with parser functions. One way that we simplified things was to only consider one protection action when generating the output. While this was fine for most of the existing protection templates, it has turned out not to be fine for pp-template. There are a few ways this could be fixed:

  1. Fix Module:Protection banner to allow detection of multiple protection actions. This would require a rethink of the protection template syntax: at the moment you can specify an action with the |action= parameter, but that would need to be changed somehow to account for multiple actions. It would also require rewriting a sizeable chunk of the module, which would take some time.
  2. Make a separate Module:Pp-template that extends Module:Protection banner. This would be easier than #1, but it is a bit of a hack. I'm reluctant to add extra protection detection code onto Module:Protection banner, as this kind of hack is just what we were trying to fix by writing that module in the first place. It may also require some changes to the protection banner module, depending on exactly how hacky we're willing to be.
  3. Detect the protection action inside Module:Documentation, and call Module:Protection banner with whatever action we detected. This would be the easiest to do, and I've been meaning to update Module:Documentation to call Module:Protection banner directly anyway. The drawback with this approach is that {{pp-template}} would not be fixed to detect move protection. Instances of pp-template on move-protected pages would have to be changed to something else, either {{documentation}}, {{pp-move}}, or a new {{pp-template-move}} template. (Making pp-template-move would just be a matter of changing the settings in Module:Protection banner/config and invoking the module from the template page.)

Of the above choices, I would prefer #3, followed by #1. What does everyone else think? — Mr. Stradivarius ♪ talk ♪ 10:50, 24 September 2014 (UTC)

@Redrose64: About the new templates you listed above: the errors will go away if we make one of the three fixes that I've outlined here. Which one would you prefer? — Mr. Stradivarius ♪ talk ♪ 14:32, 26 September 2014 (UTC)
I have no idea. Modules - and the Lua that is inside them - are a total black box to me. I have no idea how they do what they do, and I don't see why it is so often "necessary" to take templates that were not only working properly, but were also understandable to me, and convert them to Lua, breaking them in the process. --Redrose64 (talk) 14:51, 26 September 2014 (UTC)
@Redrose64: What's so difficult to understand? #3 means that we can fix the categorisation problem easily, but that pp-template won't work on move-protected templates. #1 means that pp-template can work as before, but that we will need to rewrite Module:Protection banner, which will be difficult. And #2 means that we can fix pp-template without rewriting the module (much), but that it would be an ugly hack. And I suppose we could add #4, which is to revert back to the old pp-template code that used pp-meta. The disadvantage with #4 is that it's slower and harder to read than the Lua code. Even if you know template code well, it's hard to understand pp-meta without a text editor that does bracket matching (I know this through personal experience). Although to be fair, the code in Module:Protection banner might be a overly complex for the job it's doing - I wouldn't recommend trying to read it unless you've read and understood the code in a few other modules first. If you do want to read the code, you should start with Module:Protection banner/config, as that's where the actual text is stored and the explanation at the top should make things clearer. — Mr. Stradivarius ♪ talk ♪ 07:21, 27 September 2014 (UTC)
Template markup is no different from regular Wiki markup, which we all use every day. It has constructs like {{{1}}} which are placeholders for parameters, yes; but those aren't difficult to understand. Processing starts at the top, so you can follow it through from there; or you can look for the parameter placeholders and say "ah, here is where such-a-value is received, so what happens to it is this then this then it's passed on to a subtemplate". Lua is difficult to understand. It is damn-near impossible to trace the code through. I cannot work out what the received parameters are, nor where they are put (there are lines like local getArgs = require('Module:Arguments').getArgs but that doesn't tell me what the valid names for arguments might be, nor what variables they get stored in), so there is absolutely no hope of working out what happens to a parameter on its way through the code.
What I want is the previous behaviour - or something equivalent - restored. It should always be possible to add {{documentation}} to a template (sandboxes included), without it putting the template in Category:Wikipedia pages with incorrect protection templates. If the page is protected, it should add an appropriate padlock icon and put the page in a suitable category: Category:Wikipedia protected pages or if appropriate, one or more of its subcats. If the page is not protected, it should do nothing. --Redrose64 (talk) 09:06, 27 September 2014 (UTC)
@Redrose64: For a template and module of equivalent complexity, the module is basically always easier to understand. Compare the pre-Lua Template:Vgrtbl (and its subtemplate Template:Vgrtbl/text) with Module:Vgrtbl for a concrete example. I'll admit that if you don't know Lua, then modules seem impossible to understand, but the same is true of templates if you don't know the parser syntax. Also, I noticed that Mr. Stradivarius is working on (maybe finished?) a solution to the problem described in this thread. Jackmcbarn (talk) 15:48, 27 September 2014 (UTC)
I haven't started work on a fix for the categorisation problem yet - I was hoping to get a consensus on what fixes should be made before doing anything. Any fixes to Module:Documentation won't take long to code up. The hard problem would be adjusting Module:Protection banner to work with multiple actions. When you say I'm working on a fix, I assume that you're talking about Module:Pp-move-indef, which was brought up in a related thread on Module talk:Protection banner. That's now finished, and I put it up live a few days ago. I converted it to Lua because I thought that it might need to be called from Module:Documentation to solve the problem mentioned in this thread, but judging from Martin's comment above I think we would need a new pp-template-move template for this purpose instead. That is, assuming that we want to fix the categorisation problem with option #3, and not #1 or #2. — Mr. Stradivarius ♪ talk ♪ 16:19, 27 September 2014 (UTC)
@Mr. Stradivarius: Yes, Module:Pp-move-indef is what I was referring to. Now that I look at this closer, though, I think #1 is the right way to fix this. If gerrit:155691 gets merged, then we won't have to worry about expiry as a parameter anymore, and we could use a syntax like {{pp|edit=vandalism|move=dispute}}. Jackmcbarn (talk) 16:31, 27 September 2014 (UTC)
You may find modules easier to understand. I do not. I don't see why I should choose between incomprehensible options concerning a template which I did not break.
I'm sorry to have to lay it down, but here it is: you've got 24 hours to get Template:Fact-now, Template:Infobox aluminium, Template:Infobox Olympic games, Template:Infobox OS, and Template:IPAc-cmn (plus any other templates which I shall list here over the next few hours) out of Category:Wikipedia pages with incorrect protection templates without editing these templates or altering their prot settings. If any template named here is still in that cat at 18:00, 28 September 2014 (UTC) I shall need a very good reason not to revert Template:Documentation to its pre-Lua version, together with any subtemplates that may also be necessary to get those pages out of that cat. --Redrose64 (talk) 18:15, 27 September 2014 (UTC)
Right, here are five more templates for the list: Template:Lang-ang; Template:Nickelodeon; Template:Non-free seal; Template:Talk page of redirect; Template:Too few opinions. --Redrose64 (talk) 23:01, 27 September 2014 (UTC)
Four more: Template:Di-replaceable fair use disputed; Template:US-bridge-struct-stub; Template:User undelete; Template:WikiProject Mississippi. --Redrose64 (talk) 00:04, 28 September 2014 (UTC)
@Redrose64: Reverting Template:Documentation to the pre-Lua version won't fix the problem. From my earlier post: With respect to move protection, Module:Documentation does essentially the same thing as the old Template:Documentation did. ... The difference is that the functionality of {{pp-template}} has changed after the switch to Module:Protection banner. It now only detects edit protection, whereas before it detected edit and move protection. Before handing out ultimatums, you could at least read what I've written. From what Jackmcbarn said above, it looks like the best solution is #1, which will also take the most time. So until that is ready, I'll add a stopgap fix to Module:Documentation so that move-protected templates aren't incorrectly categorised. Again, this will only fix templates adding the protection banner through {{documentation}}, not templates using {{pp-template}} directly. — Mr. Stradivarius ♪ talk ♪ 04:29, 28 September 2014 (UTC)
The stopgap fix is now in place, and the templates listed above are no longer in Category:Wikipedia pages with incorrect protection templates. — Mr. Stradivarius ♪ talk ♪ 05:28, 28 September 2014 (UTC)
OK, Thank you --Redrose64 (talk) 11:48, 28 September 2014 (UTC)

Option to hide the testcases/sandbox links?

Over at Template:My sandbox, this template displays the usual line "Editors can experiment in this template's sandbox (edit | diff) and testcases (edit) pages". This is confusing for new editors who are looking for their own sandbox, as they end up editing the shared template sandbox instead.

How about an option for the {{Documentation}} template to omit this line? -- John of Reading (talk) 07:36, 27 October 2014 (UTC)

@John of Reading: You can always write a whole custom end box. If this is only going to be used on a handful of templates I'd say that's the best way of doing things. You could even put a big enticing link to the user sandbox there with a smaller link to the actual template sandbox next to it for people who really do want the template sandbox. — Mr. Stradivarius on tour ♪ talk ♪ 09:20, 27 October 2014 (UTC)
I've used {{Replace}} on the output from {{Documentation}} to chop out one line. -- John of Reading (talk) 10:09, 27 October 2014 (UTC)

mw.html

I've updated Module:Documentation/sandbox to use mw.html instead of htmlBuilder. Just wondering if someone could check to see if it's ok before it's made live. Thanks. -- WOSlinker (talk) 16:44, 30 October 2014 (UTC)

@WOSlinker: Looks good to me. Jackmcbarn (talk) 20:42, 30 October 2014 (UTC)
Thanks. I've gone and applied the change. -- WOSlinker (talk) 22:38, 30 October 2014 (UTC)

Lua error in mw.html.lua at line 345: Tag name must be a string.

Tracked in Phabricator
Task T74880

On a version 1.23.6, I've just imported Wikipedia templates: reflist, infobox and navbox, along with other templates they transclude. On many of these pages is the red "Script error" with "Lua error in mw.html.lua at line 345: Tag name must be a string." {{reflist}} and {{navbox}} seem to work ok but on a page where infobox is supposed to appear is the red Script Error instead. -- Rob Kam (talk) 12:41, 2 November 2014 (UTC)

Try an older revision of infobox from 19 Jun that uses Module:HtmlBuilder instead of mw.html -- WOSlinker (talk) 13:17, 2 November 2014 (UTC)
Thanks but no. I've already been using older and self-written templates that worked okay but were a lot of work to maintain. Now I'm trying to simplify things by using up-to-date and (should be) debugged templates from Wikipedia. Except it's not working. -- Rob Kam (talk) 13:59, 2 November 2014 (UTC)
@Rob Kam: Many Wikipedia templates and modules use features from the very latest version of MediaWiki (and extensions), so they won't work right with older versions (including the latest stable version). To make them work, you need to either use a newer version of MediaWiki (and extensions), or use older versions of the templates and modules. Jackmcbarn (talk) 01:55, 3 November 2014 (UTC)
@Jackmcbarn: The manual doesn't warn to not use latest stable version and matching extensions or the wiki might break. Rob Kam (talk) 08:17, 3 November 2014 (UTC)
Fixed by changing Scribunto to 1.24, as advised to by Jackmcbarn. Rob Kam (talk) 17:26, 3 November 2014 (UTC)

Missing [view] - [edit] - [history] - [purge] links for Module Documentation

I've copied the Template:Documentation and Module:Documentation templates to my own Wiki a while ago. It works fine with templates. When I view a module (e.g. Module:Documentation) I see the documentation of it above the LUA code, but I don't see it in the greenish box with the above mentioned links like on Wikipedia. I've tried updating all the needed templates and modules but I can't get it to work. Any idea what I might be missing? Richie765 (talk) 19:49, 7 December 2014 (UTC)

@Richie765: Probably some snippets from MediaWiki:Common.css. Jackmcbarn (talk) 20:55, 7 December 2014 (UTC)
Other relevant pages that needs to be created or modified for it to work on module namespace
@Lam-ang: Copying those 3 MediaWiki:* pages did the trick. Thanks! Richie765 (talk) 01:11, 8 December 2014 (UTC)

Template sandbox notice has no "diff" link

Normally, when I'm on a template's /sandbox page, one that has documentation, the documentation shows a box at the top ("This is the template sandbox page for Template:...") which contains a "diff" link, as it does at Template:StateAbbr2/sandbox. However, although the box is present at Template:Please see/sandbox, the diff link is not. Why is that? --Redrose64 (talk) 12:22, 1 February 2015 (UTC)

I've fixed it with a purge. Odd though, that the test "Does the sandbox exist?" returned false when the sandbox was being created. -- John of Reading (talk) 12:39, 1 February 2015 (UTC)
Pre-Lua, {{documentation}} would test to see if it was being used on the /sandbox subpage, and only display {{template sandbox notice}} if it was. The latter template doesn't check for an existing sandbox page, it always displays the diff link (unless {{REVISIONID}} is missing, i.e. when previewing before save). Since the {{documentation}} has been Lua-ised, I can't see how it works. But going by your comment 'the test "Does the sandbox exist?" returned false', there is now an extra test which wasn't in the pre-Lua version. Since the module must still be detecting whether it's used on a sandbox or not (in order to decide whether to show that box or not), why is it then necessary to test for the existence of a sandbox? the sandbox must by definition exist if it's appropriate to show that box. --Redrose64 (talk) 13:36, 1 February 2015 (UTC)
@Redrose64: Before I did the purge, there was a "create" link. The code for this seems to be in Module:Documentation in the function "makeExperimentBlurb". I don't know how the LUA runtime implements the test "if sandboxTitle.exists". -- John of Reading (talk) 14:17, 1 February 2015 (UTC)
I think this week's software update will fix this problem. Jackmcbarn (talk) 23:40, 1 February 2015 (UTC)
Sorry if my comment is unrelated, but for a long time I have been meaning to investigate why the Lua documentation version blocks display of the doc page for a sandbox. Prior to the Lua rewrite, visiting Module:Convert/sandbox would show the small-and-specific Module:Convert/sandbox/doc, but now it shows Module:Convert/doc although the "[view] [edit] [history]" links at the top refer to the sandbox doc page. I'm not fussed, but if someone is thinking about related issues, please consider whether a doc page for the sandbox should be shown, if it exists. Johnuniq (talk) 00:11, 2 February 2015 (UTC)

Template:Documentation/start box

why are we still transcluding Template:Documentation/start box and Template:Documentation/end box? Frietjes (talk) 19:16, 22 February 2015 (UTC)

My guess is because some templates still use inline documentation that use these. -- [[User:Edokter]] {{talk}} 21:47, 22 February 2015 (UTC)
I seem to remember I allowed access points for both of these from Module:Documentation, but I never got around to implementing them. I'll take a look at this later. — Mr. Stradivarius ♪ talk ♪ 23:47, 22 February 2015 (UTC)

Preloading template documentation with copy of transclusion syntax

I have created Module:Parameters, and its template counterpart, {{Parameters}}; in conjunction, the two (attempt to) extract parameters from template source code and offer to format them in several ways, one of which is the transclusion syntax. The module's robustness is yet to be determined. I'll try to get some unit tests up and running over the next couple of days; I do expect the regex to fail in some instances. On to my question - would it be a good idea to add <includeonly>{{subst:#tag:pre|{{subst:Parameters|code|base={{subst:BASEPAGENAME}}}}}}</includeonly> right underneath "Usage" in Template:Documentation/preload, once the module has matured? What this beaut does is retrieve the name of the template; pass it on to {{Parameters}}; and wrap the latter's output, the transclusion syntax, inside a <pre> element. Its utility should be obvious. Alakzi (talk) 23:04, 5 June 2015 (UTC)

That looks incredibly useful - thank you - and I support using it in {{Documentation}}. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:44, 5 June 2015 (UTC)

Edit request

Please add parameters to specify the location of the template testcases page and template sandbox page, if they are not in the expected /sandbox and /testcases pages. (both {{template sandbox notice}} and {{template test cases notice}} support specifying the location of the pages, so this should as well) -- 70.51.202.183 (talk) 11:24, 14 June 2015 (UTC)

I think it probably better if they are in the standard locations. What is the advantage of allowing them to be anywhere else? — Martin (MSGJ · talk) 20:06, 14 June 2015 (UTC)
Not done: please establish a consensus for this alteration before using the {{edit protected}} template. --Redrose64 (talk) 23:12, 14 June 2015 (UTC)
If you check their contrib history, they're actually having trouble with the namespace, not paths. When {{Documentation}} is placed in the Draft namespace, the sandbox and testcases links are not shown. Alakzi (talk) 23:14, 14 June 2015 (UTC)
"template test cases notice" and "template sandbox notice" support alternate locations because they exist in such a manner in Templatespace, not because of Draftspace. Especially, with unified testcases for multiple templates, just as documentation template supports a source for where the documentation comes from which can be shared between multiple templates. -- 70.51.203.69 (talk) 06:40, 16 June 2015 (UTC)

Incorrect protection icon

Jackmcbarn. Mr. Stradivarius: When a template has {{Documentation}} and is protected, the {{Documentation}} displays any prot icon that may be appropriate. This normally works well.

However, there appears to be a problem in the way that Module:Documentation decides whether to show the icon when the |page= parameter is used. Consider User:Cpiral/sandbox/B: this version has {{documentation|page=Template:Convert}} and is in Category:Wikipedia pages with incorrect protection templates whereas this version does not have {{documentation|page=Template:Convert}} and is not in Category:Wikipedia pages with incorrect protection templates. If I remove that |page=Template:Convert and preview, the Category:Wikipedia pages with incorrect protection templates does not appear. So the presence of the page in that error cat is something to do with {{documentation|page=Template:Convert}}. As I understand it, the purpose of the |page= parameter is to pull in the doc subpage for a different template, so in this case it brings in Template:Convert/doc. It appears to be deciding whether to display a protection icon based on the current protection level of Template:Convert when it should be testing the current protection level of the page where the {{documentation}} actually appears - in this case User:Cpiral/sandbox/B, which is not protected (and never has been). --Redrose64 (talk) 22:25, 1 August 2015 (UTC)

"Mirror" link is broken and misleading

It's been brought up a few times over the past four years, but the "mirror" link to create a sandbox doesn't actually mirror the main template. Instead, because it just preloads the main template, it strips out anything in <noinclude> tags. This has the effect of not only removing documentation, but it also breaks any statements such as {{safesubst<noinclude />:. This is not the expected behavior of a link that is labeled "mirror". I can't think of an obvious way to fix this without creating a gadget or an external tool on toollabs, but unless there is a way to fix it in Lua, the link should probably be removed as it has the potential to do more harm than good. --Ahecht (TALK
PAGE) 14:34, 26 August 2015 (UTC)

We could preload a page containing <includeonly>{{subst:msgnw:{{subst:BASEPAGENAME}}}}</includeonly>, which would then require saving before it takes effect. This could also be achieved in Lua with mw.title:getContent(). Alakzi (talk) 15:14, 26 August 2015 (UTC)
@Alakzi: Ooh, I didn't know about msgnw, that's handy. I had to modify that string to include the namespace and created Template:Documentation/mirror, which seems to work in my sandbox tests. I've implemented it in {{Documentation/sandbox}}. Can someone check my work before it goes into the main version of the module? --Ahecht (TALK
PAGE) 16:56, 26 August 2015 (UTC)
The namespace check is probably redundant: ":Article" is the same as "Article". Alakzi (talk) 17:04, 26 August 2015 (UTC)
@Alakzi: Good point. The double colons had looked wrong, but they seem to work. --Ahecht (TALK
PAGE) 17:58, 26 August 2015 (UTC)
Well, it all looks good to me now. Alakzi (talk) 18:04, 26 August 2015 (UTC)

That's probably been enough time for feedback. Shall we? Alakzi (talk) 16:26, 28 August 2015 (UTC)

Good idea. I made the changes live. --Ahecht (TALK
PAGE) 16:35, 28 August 2015 (UTC)

Not Working on a local Wikipedia

Hi, I was wondering why it doesnt display a blue box containing documentation on modules on my wikipedia dv:Module:Documentation. However, it works on Template Documents. Could anyone help me on it? Thanks.--Glacious (talk) 05:43, 2 September 2015 (UTC)

Probably something missing from your site's CSS. --Redrose64 (talk) 09:52, 2 September 2015 (UTC)
@Glacious: Take a look at this archived topic. --Lam-ang (talk) 01:26, 5 September 2015 (UTC)
@Glacious: I saw you copied the MediaWiki:* pages but this line of code {{$1}} <hr /> needs to be removed at dv:MediaWiki:Scribunto-doc-page-show so the documentation will only be shown once. --Lam-ang (talk) 16:30, 7 September 2015 (UTC)
@Lam-ang:, Thanks a lot for ur help! Works like a charm. Any chance you could help me on this template? --Glacious (talk) 23:49, 7 September 2015 (UTC)

remove interwiki

Please remove Template talk:Documentation/docspace's local interwikisYamaha5 (talk) 07:08, 4 September 2015 (UTC)

@Yamaha5: Can you be more specific about exactly what you want removed and why? I don't see any interwikis on that redirect. --Ahecht (TALK
PAGE) 14:34, 8 September 2015 (UTC)

Preload code: the sandbox check

In {{Documentation/preload}} I have changed the code into using {{sandbox other}}. That template has same functionality (by design). We could consider expanding it (eg, broaden the scope to also fire in "Template:Foo/sandbox/documentation", or add the |demo= parameter to it). -DePiep (talk) 08:41, 7 April 2016 (UTC)

Adding "run" links to module space documentation

I'm about to add a "run" button to module-space documentation (ease of navigation).

If [[Module talk:{module}/testcases]] exists, add a "run" button to the documentation. See User:Andy M. Wang/sandbox for the output of what I mean. The changes that went into effect are at Module:Documentation/config/sandbox (diff) and Module:Documentation/sandbox (diff).

Thanks — Andy W. (talk · contrib) 20:30, 27 April 2016 (UTC)

Sounds good - I've been meaning to get round to adding a link like that for a while now. And the code looks good to me too. Thanks for putting this together! — Mr. Stradivarius ♪ talk ♪ 05:22, 28 April 2016 (UTC)
Can't see anything at User:Andy M. Wang/sandbox relevant. Can you explain what this would actually do? — Martin (MSGJ · talk) 08:10, 28 April 2016 (UTC)
@Mr. Stradivarius: no problem! There were several times when I thought that button would help me navigate more quickly. @MSGJ: see Special:Permalink/717455024 for a sample Module documentation. At the bottom left, "Editors can experiment in this module's sandbox (edit | diff) and testcases (edit | run) pages." The "run" button is new.
This has already gone live on all module doc pages. For example, see the big green documentation on the page Module:Math or Module:Roman. At the bottom left of this green documentation box, the run button is already visible. If this was the issue you were referring to (about too hastily making changes), sorry... I thought that this one only helped and was a no-brainer. I'll keep that in mind and establish consensus. — Andy W. (talk · contrib) 15:23, 28 April 2016 (UTC)
I agree this one was more of a feature that was obviously missing rather than something that you would need to wait to get consensus for, so I don't think it was too hasty. — Mr. Stradivarius ♪ talk ♪ 00:16, 29 April 2016 (UTC)
Why is it called "run" when all it is is a talk page link? The usual name for such links is either "talk" or "discuss". --Redrose64 (talk) 10:07, 29 April 2016 (UTC)
Convention seems to be to use testcases talk page for the actual tests, because the module page has to contain lua code. — Martin (MSGJ · talk) 10:35, 29 April 2016 (UTC)

Suggesting another change to Documentation

I've noticed some long documentation pages that sometimes take longer to navigate to find the sandbox or testcases links in the endbox. This is particularly true for Modules, where a piece of documentation ends mid-page, and you have to scroll up to find the end of the doc to find the links to the sandbox and testcases. In the sandbox, I've moved this endBox up under the startBox, which puts it in a more easily-found spot.

  • The output for a page like Module:Math would be something like this.
  • The output for a page like Template:FlagIOCmedalist would be something like this. Edit: see afterthought. Template docs can remain unchanged in appearance.

Thoughts? — Andy W. (talk · ctb) 00:58, 13 May 2016 (UTC)

Afterthought. This is more of an issue with module scrolling only. Perhaps we can implement this change for the module space only. — Andy W. (talk · ctb) 01:06, 13 May 2016 (UTC)
They used to be at the top. They were moved to a separate box at the bottom in February 2010, see Template talk:Documentation/Archive 5#Documentation/links. That section also describes some JavaScript which will exchange the two green boxes. --Redrose64 (talk) 07:35, 13 May 2016 (UTC)
Very interesting, thanks for pointing that out. I'm becoming indifferent about whether this changes goes in. I'll leave it in the sandbox in case anyone else wanted to comment. Please ping if there are any direct replies, thanks. — Andy W. (talk · ctb) 14:53, 13 May 2016 (UTC)

Suggesting param "notest"

I would like to apply this change (-sandbox) to Module:Documentation. Sample output is at User:Andy M. Wang/prototyping (see bottom of the page).

If the new |notest=yes AND there's no sandbox AND there's no testcases, then we hide "Editors can experiment in the sandbox (create) and testcases (create) pages." Else, no change whatsoever. This may be useful for low-risk templates that don't have a strong need for sandbox/testcases.

Thoughts? I won't take action yet. — Andy W. (talk · ctb) 00:17, 22 May 2016 (UTC)

I don't think this is a good idea. Apart from the very simplest changes (typos, etc.) template changes should always be tested first. Per WP:TESTCASES, the template sandbox is the best place for putting your proposed new version: besides allowing side-by-side testing a testcases subpage, it also allows direct comparison of the two template versions. By comparison, change requests such as this recent example (showed up on my watchlist, and which I was going to decline {{subst:ETp|sand}} except that somebody actioned it before I had the chance) don't permit either easy comparison or direct testing. --Redrose64 (talk) 08:02, 22 May 2016 (UTC)
@Redrose64: I've moved my tests to the bottom of Template:Documentation/testcases. This is a Module change that I already implemented in its sandbox. I didn't expect my initial post to suggest that I haven't done testing either (with calls to the template sandbox). — Andy W. (talk · ctb) 15:33, 22 May 2016 (UTC)
 Suggestion withdrawn I decided that hiding sandbox/testcases in the end box is probably a bit fussy. I'll leave the change in the Module sandbox in case anyone else wanted to comment though. Thanks — Andy W. (talk · ctb) 15:42, 22 May 2016 (UTC)
My comment "template changes should always be tested first" had a double meaning; the other one was "we should not hide the means by which people can test their propsed changes to templates". --Redrose64 (talk) 20:30, 22 May 2016 (UTC)
Oops! Thanks for the clarification. And yes, makes sense. Cheers, — Andy W. (talk · ctb) 20:49, 22 May 2016 (UTC)

Module sandbox mirror link fix

Implemented a fix for the module sandbox "mirror" link. ("Editors can experiment in this module's sandbox (create | mirror) and testcases (create) pages.") Previously, the preload was Template:Documentation/mirror for both templates and modules, which did not allow the module sandbox mirror link to work properly. The error I got was: Script error: Lua error at line 1: unexpected symbol near '{'. I tested this with Special:Permalink/725294632, and it looks good now. Ping if there are any issues. — Andy W. (talk · ctb) 20:10, 14 June 2016 (UTC)

Since I just created the sandbox for Module mentioned in the permalink above, Module:Location map/data/New York would be a good place to see the mirror link in effect. — Andy W. (talk · ctb) 20:21, 14 June 2016 (UTC)

Need a passed parameter

 – There's already a work-around.

Need to be able to pass a parameter, like |version= or |passed= so that documentation flexibly written for multiple similar templates can do something like {{#ifeq:{{{variant}}}|someKeyword | specialVersionOfAnInstruction | defaultVersionOfAnInstruction }}. While such customization is already possible, it presently requires creating a virtually empty /doc page for every variant template and transcluding {{basicTemplateName/doc|someKeyword}} in it, and this is inefficient. It would be better to have no /doc page for the derived templates that share the main template's documentation, and just call the documentation directly from those templates with {{Documentation|basicTemplateName|version=someKeyword}}. I'm assuming that the module can pass this parameter to the transcluded documentation as a parameter, the way the call from the near-empty /doc page does.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  10:55, 23 June 2016 (UTC)

SMcCandlish, if you explicitly pass the documentation page ({{documentation|content={{Template:Any page/doc|parameters}}}}), instead of implicitly passing it ({{documentation}} or {{documentation|Template:Any page/doc}}), you can overcome this limitation. this is covered in the documentation for this template/module. Frietjes (talk) 22:33, 23 June 2016 (UTC)
Ah! Thanks. I missed that, since it was in among a bunch of stuff about [edit] [purge] links.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  07:52, 24 June 2016 (UTC)

Link box / edit / purge not appearing with |1= and |content=

This mmterial in the documentation no longer appears to be accurate:

Note that if the /doc page exists, a link to it is still shown in the link box below the doc box.

Parameter |1= and the |content= parameter can also be combined, like this:

...

Then the pagename fed as parameter 1 is used for the [edit] [purge] links and for the /doc link in the link box below the doc box

No link box, [edit] or [purge] seem to be appearing. E.g., there is no difference in display between this version of a template [1], using the |1= and |content= features together, and this version [2], using |content= without |1=.

Also, the template's instructions to use |content={{Template:Any page/doc |parameters}} is redundant, and can be pared down to |content={{Any page/doc |parameters}} as I did at the example template above.
 — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  08:37, 24 June 2016 (UTC)

I see a link box for both. As for {{Template:...}}, per WP:TRANS, the namespace is redundant when it is Template. I thought that this was a well-known fact - we pretty much always write {{citation needed}} and not {{Template:citation needed}}. --Redrose64 (talk) 09:46, 24 June 2016 (UTC)

Empty alt text edit request

Empties the alt attribute on the documentation icon. The adjacent text, "Template documentation" or "Module documentation", is sufficient alternative text, so a non-empty alt attribute repeats information.

Matt Fitzpatrick (talk) 06:31, 10 July 2016 (UTC)

Done here and here. Please ping if there are any issues — Andy W. (talk · ctb) 04:33, 11 July 2016 (UTC)

Protected edit request on 25 January 2017

Remove inter-wiki links (i.e. the Japanese wiki links). 219.79.227.79 (talk) 14:25, 25 January 2017 (UTC)

Only 7 transclusions. This seems more like a case for removing protection altogether. Is /docname even in use anymore? Jo-Jo Eumerus (talk, contributions) 14:39, 25 January 2017 (UTC)
I've removed the protection on Template:Documentation/docname. -- WOSlinker (talk) 15:22, 25 January 2017 (UTC)

Add a line to Template:Documentation/preload

I suggest that we add the following line to Template:Documentation/preload directly above the <include<includeonly></includeonly>only>{{sandbox other|| line. 

For help with this template, please post a comment on the [[Template_talk:{{ROOTPAGENAME}}|template talk page]].

This will help novice users get assistance. Yours aye,  Buaidh  04:14, 10 March 2017 (UTC)

But a similar notice would be needed on every page at Wikipedia (other than talk pages). People who do not know that questions should be on the talk page are very unlikely to see any messages in the documentation (banner blindness). Presumably the proposal arises from this TfD. Johnuniq (talk) 04:29, 10 March 2017 (UTC)

Suggestion: Add "Purge" suggestion to the "Create" link

At Wikipedia:Village pump (technical)#Template doc isn't transcluding, Mathglot (talk · contribs) has suggested that the "Create the missing documentation" link should be followed by something like "[Have a doc page but not seeing it? Try a purge.]" - with "purge" linked to do the action. This seems reasonable to me. -- John of Reading (talk) 19:29, 28 May 2017 (UTC)

  • I'd be ok with it. Many editors may not know that they need to purge a template page when creating or updating its documentation to see the most recent version of the /doc subpage. Matter of fact, it may be useful to update the [Purge] link on templates with created /doc subpages with something similar so editors actually know what the button does. — Gestrid (talk) 19:39, 28 May 2017 (UTC)
  • And I'd appreciate it, as on the surface, it's a light-weight fix, but so annoying to track down on your own when you don't know what's going on. (I was trying this and trying that at home, changing cache, browsers, wondering about content distribution networks, all sorts of rabbit holes, not wanting to bother the good folks at Village Pump before making a reasonable effort to solve it on my own, finally giving up and getting the answer in a flash from John and Gestrid.) In retrospect, just a link would have been enough to short-circuit all that. Thanks again to both of you for responding and being proactive on this, and thanks in advance to unknown contributor who I hope can fix this! Mathglot (talk) 19:49, 28 May 2017 (UTC)
    At one time, making such a change would indeed have been a light-weight fix (example). But in January 2014, the whole documentation system was altered to Lua, and is now in Module:Documentation. Now, RexxS (talk · contribs) told me that when confronted with a Lua module, you start with the lines return p (at the bottom) and local p = {} (near the top). These apparently declare a table, named p, and send it back to the caller. But what fills in this table? At least in C, you have a fair chance of finding a function named main, from where you can start tracing it through. But there isn't an equivalent in Lua. This is why I state that it is unmaintainable (and indeed incomprehensible) to anybody outside the cabal. --Redrose64 🌹 (talk) 23:29, 28 May 2017 (UTC)
    @Redrose64: Well, the difference between what we think of as conventional C functions and Lua as implemented via Scribunto is that a single Lua module can contain an unlimited number of "main" functions. The table (often called 'p') is just a list of these functions, which is why it's returned. To find these functions, you have to read through the Lua module looking for 'public' function declarations that contain something that looks like this: p.some_name = or function p.some_name (assuming that the module returns 'p'). Then you've got the name of a function, "some_name", that can be invoked from wiki-text.
    In the case of Module:Documentation, the public functions are called message, makeWikilink, makeCategoryLink, makeUrlLink, makeToolbar, main, getEnvironment, sandboxNotice, protectionTemplate, startBox, makeStartBoxLinksData, renderStartBoxLinks, makeStartBoxData, renderStartBox, content, contentTitle, endBox, makeDocPageBlurb, makeExperimentBlurb, makeCategoriesBlurb, makeSubpagesBlurb, makePrintBlurb, addTrackingCategories
    Not that that's much help as Module:Documentation ironically has very little documentation in its /doc page. However, the comments in the module code are helpful. The section dealing with creating a /doc subpage is in function makeStartBoxLinksData, starting at line 495. I'll see if I can track down where the actual text is stored tomorrow, as it's by no means obvious (and it's getting a bit late here). --RexxS (talk) 00:30, 29 May 2017 (UTC)

Green box

Hello, I'm trying to localize the Module to Hebrew Wikipedia but I'm having troubles. I understand that I shall only edit the Module:Documentation/config. However when I try to test case it the green background don't appear. However, the green box below is working fine. How can I fix it? What shall I check? (Please tag me) Sokuya (talk) 18:51, 14 June 2017 (UTC)

Sokuya, the styling is set in the main site css. see MediaWiki:Common.css and search for the "template-documentation" class definition. so, you probably want to add the same thing to he:MediaWiki:Common.css. Frietjes (talk) 00:53, 15 June 2017 (UTC)

Module:Documentation

@Mr. Stradivarius: could you port your changes (discussed in 2014 at Template talk:Documentation/Archive 9#Module:Documentation: allow parameter aliases) to the current version of the module?. Looks like they were never merged in the "master" version. Helder 16:36, 28 December 2017 (UTC)

Retrieved from "https://mdwiki.org/wiki/Template_talk:Documentation/Archive_9"