Template talk:Documentation/Archive 9

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

Change to new logo

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

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

To

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

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. Van Isaac_WS^cont 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

Moved from User talk:Funandtrvl#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<aside>and by the same token as above</aside>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)

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:

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