Template talk:Documentation

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)

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)

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)

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)