Template talk:Multiple issues

From Wikipedia, the free encyclopedia
Jump to: navigation, search

Fair use[edit]

Is there a fair use warning template I can use with this one? For articles that use too many non-free images (screenshots of video games). SharkD  Talk  02:31, 24 March 2017 (UTC)

@SharkD: Search for the best template for your concern at Wikipedia:Template messages or Wikipedia:Template messages/Examples.
Drilling down from that, I find Wikipedia:Template messages/Cleanup#Images and other media. Perhaps {{Too many photos}} is what you're looking for? – wbm1058 (talk) 22:43, 24 April 2017 (UTC)
None of those deal with the Non-Free issue specifically. Do you have any advice on creating one? I won't be using it often; is it worth the effort to make one? SharkD  Talk  08:43, 28 April 2017 (UTC)

Template-protected edit request on 24 April 2017[edit]

Create/Allow a parameter to take "lead" to be used instead of section.--Mr. Guye (talk) 22:02, 24 April 2017 (UTC) Mr. Guye (talk) 22:02, 24 April 2017 (UTC)

Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format. Izno (talk) 22:14, 24 April 2017 (UTC)
What I presume is meant is that a further option should be provided, which would render as "The lead section of this article has multiple issues". Am I right Mr. Guye? Note it would be better to say "lead section" not just "lead", because the following tags unless lead-specific would all begin "this section". I'm sceptical about value in relation to the effort of constructing this though, from the point of view that defective leads are often highly amenable to the fix-it-yourself approach: Noyster (talk), 09:40, 25 April 2017 (UTC)
Indeed, defective leads are (usually) easy to fix where the rest of the article is otherwise acceptable. I've tweaked the TER back to Y since we haven't heard from the user who made the request yet, and I'd like to understand explicitly what he wants. --Izno (talk) 12:01, 25 April 2017 (UTC)
@Noyster: yes, that is what I meant. --Mr. Guye (talk) 14:44, 25 April 2017 (UTC)
@Izno and Noyster: New proposal: Ok, I see your WP:SOFIXIT argument, but maybe we should allow custom options. So it could show "paragraph", "article's body", "article's references" etc. A lot of templates have this ability already. --Mr. Guye (talk) 14:49, 25 April 2017 (UTC)
Comment: before anything is implemented along these lines, please notify WT:Twinkle and WT:AutoWikiBrowser. I'm fairly sure that both would need software changes. -- John of Reading (talk) 15:13, 25 April 2017 (UTC)
  • Oppose. This kind of micromanagement of what the template says is counterproductive. Editors already are not using talk pages often enough to express their specific concerns. The primary purpose of article-space templates is to broadly state the problem, and direct editors to the talk page for detailed explanation of the issues and discussion about how to resolve them. This specific template is intended to be a wrapper for other templates, so if there are four issue templates on a page, this sort of proposal assumes the problems apply to all four of them... it makes no sense to say that the "article's references" have too many pictures, but that's the kind of scenario this proposal would set up. The main purpose of this template is to consolidate and reduce the size of the "template wall" at the top of articles, and this template is already complicated enough that too many novice editors don't understand how it's supposed to be used. wbm1058 (talk) 19:55, 25 April 2017 (UTC)
  • I suppose if this were placed at the top of an article, with section=yes that might be interpreted to mean the lead section, though I could see some getting confused, and wondering if section=yes was specified in error. Again, though, just clear up confusion by placing a note on the talk page. I don't believe the consensus at #RfC - Options so far was ever implemented. We need a Lua coder to do that. wbm1058 (talk) —Preceding undated comment added 20:07, 25 April 2017 (UTC)
Not done: please establish a consensus for this alteration before using the {{edit template-protected}} template. Seems to be some opposition to the proposal. I don't know if it will need a full RFC, but some sort of consensus would be good. Primefac (talk) 17:55, 26 April 2017 (UTC)


It looks to me like the vast majority of articles encountered by the linter are caused by this template's actions. The source for this template looks fine, so it might be in {{ambox}} that the issue is present in. --Izno (talk) 15:33, 23 August 2017 (UTC)

@Izno: only pinging because it was a while ago, and I'm not sure if you're following this page It actually seems to be in {{ambox}} only through Module:Documentation. If you opt to skip the documentation template, the lint errors (including both a stripped and a missing end SPAN tag) vanish. menaechmi (talk) 01:40, 14 September 2017 (UTC)
@Menaechmi: Not entirely sure what you mean by your response since it wouldn't affect articles if it was due to documentation. I agree, it's definitely in Ambox since it's not only affecting this template--it's impacting the {{expand language}} series of templates also. It probably has something to do with the expandability, since I know of no or few other ambox templates with expandability. --Izno (talk) 01:51, 14 September 2017 (UTC)
I realized it wasn't the best phrased message, blame it on the late night editing (sorry). What I was trying to say is that transclusion of {{documentation}} itself also causes both a Missing end tag and Stripped tag error for both Ambox and Multiple Issues (which is irrelevant here, because I was thinking that it might be causing downstream errors). I think the expandability makes sense, but I'm not sure how to remedy it. menaechmi (talk) 14:16, 14 September 2017 (UTC)

Template-protected edit request on 12 December 2017[edit]

To allow tracking, please add parameter |cat= to this template's {{Ambox}} as follows:

Where it now reads:

{{orphan}} messages in {{multiple issues}}-->
  | <includeonly>{{error|No issues specified. Please specify issues, or remove this template.}}</includeonly>

Change it to read:

{{orphan}} messages in {{multiple issues}}-->
  | <includeonly>{{error|No issues specified. Please specify issues, or remove this template.}}</includeonly>
|cat=Articles with multiple maintenance issues

Thank you.--John Cline (talk) 11:15, 12 December 2017 (UTC)

To be clear, is this the change that you want? It's always better to sandbox your proposed changes, instead of dropping code blobs into a talk page. --Redrose64 🌹 (talk) 11:58, 12 December 2017 (UTC)
Yes, thank you (you are correct). I understand your admonition, and primarily agree. I will adopt its counsel.--John Cline (talk) 12:20, 12 December 2017 (UTC)
I don't think it will work. You're adding an unrecognised fourth parameter to an {{#if: ... | ... | ... }}. --Redrose64 🌹 (talk) 13:40, 12 December 2017 (UTC)
You are correct Redrose64, thank you for your diligence. I worked up an example at Template:Multiple issues/sandbox which I have tested and affirm to be functional as shown there. Thank you again.--John Cline (talk) 14:33, 12 December 2017 (UTC)
Agreed, Done. --Redrose64 🌹 (talk) 14:38, 12 December 2017 (UTC)

Should this template render its content in a collapsed state by default?[edit]

In my opinion, this template should be collapsed by default. I believe the reasons are obvious and welcome others to append their regards in agreement or otherwise. Thank you.--John Cline (talk) 15:33, 12 December 2017 (UTC)

I would like to have the reasoning spelt out. Bearing in mind that if only one issue with an article is identified and tagged, the tag is visible to the reader, it is not obvious to me why the tags should be hidden if there is more than one of them: Noyster (talk), 15:53, 12 December 2017 (UTC)
In my opinion, the underlying reason for "shell templates", like this one, is to contain the sprawling tendency that comes with a series of templates, in succession, and built of repetitive verbiage. The benefit of such containment is nearly lost if the content is fully expanded by default.
The nature of this template ensures that it will predominately be transcluded atop the article, and therefor: the article's lead is most vulnerable to the effects of such sprawling as earlier described.
I have seen, and participated in, enough discussions to know that a considerable contingent of editors dislike (in good faith) the detracting effect of maintenance tags that will, at times, squeeze and bunch content until it literally falls completely out of view (until scrolled). These alone are sufficient for me to believe the correct answer here is obvious; although, perhaps, not assured.--John Cline (talk) 17:27, 12 December 2017 (UTC)
The template already "collapses" or "abbreviates" the templates that are sandwiched inside of it. – wbm1058 (talk) 16:06, 12 December 2017 (UTC)
I see the template as collapsible, not collapsed by default; am I wrong?--John Cline (talk) 17:27, 12 December 2017 (UTC)
When {{Multiple issues}} is not used, a template like {{refimprove}} displays "This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed." but when wrapped in {{Multiple issues}}, the message is shorter: "This article needs additional citations for verification.". If you look inside a template like {{refimprove}}, you will see that it uses the {{ambox}} template, which has an |issue= parameter and a |fix= parameter; the two together produce the long message and the |issue= parameter produces the short one. This is the extent of the collapsing. --Redrose64 🌹 (talk) 18:40, 12 December 2017 (UTC)
Right. But if we collapse the whole thing, that kind of makes the internal collapsing described by Redrose64 rather pointless. – wbm1058 (talk) 20:41, 12 December 2017 (UTC)
If you're going to collapse this one, then you may as well collapse all of them, or move them to the talk page (as at least one editor has long pushed for), or just not bother reporting maintenance issues any more... wbm1058 (talk) 20:46, 12 December 2017 (UTC)
... or make them all invisible, as Template:Orphan is when it's more than a month or two old. wbm1058 (talk) 20:48, 12 December 2017 (UTC)
Redrose64, the {{ambox}} will collapse one step further than the extent you described by changing the <div> in this template where it says:
<div {{#if:{{{1|}}}|class="mw-collapsible {{#ifeq:{{{collapsed}}}|yes|mw-collapsed}}"}} style="width:95%; margin: 0.2em 0;">
to instead say:
<div {{#if:{{{1|}}}|class="mw-collapsible {{#ifeq:{{{collapsed|}}}||mw-collapsed|}}"}} style="width:95%; margin: 0.2em 0;">
I've tested this from template:Multiple issues/sandbox and believe it is an improvement, overall. I do not believe a change like this will moot the importance of doing article maintenance nor decrease the effectiveness of its doing.--John Cline (talk) 23:43, 12 December 2017 (UTC)

I'll admit that I hadn't even noticed that this template was collapsible, as I have no reason for wanting to collapse it. The idea that multiple issues templates could actually push the lead down so far a reader would need to scroll to see the lead is something that didn't occur to me either. But then I just don't get why people read Wikipedia on smart phones. I could see the point if nice monitors cost over $1000, as I recall lusting after a 17- or 19-inch monitor when I was confined by cost considerations to working on a 13- or 14-inch monitor, back in the day.

This 29 September 2013 edit first implemented the collapsible feature, per this discussion. This 16 February 2016 edit changed the <table class> from collapsible to mw-collapsible, per this request to use the built-in collapse method.

Template:Orphan#Visibility documents the technique used to override the default hiding of this template when it's older-dated, and always show the template. What will be the equivalent technique to always expand the template for the convenience of maintenance-oriented editors? wbm1058 (talk) 15:44, 13 December 2017 (UTC)

Thank you for the informative links you've given above. I'll review them further as time permits. I do not speak here of mobile web viewing as I rarely view Wikipedia on handheld devices. I do, however, understand the constraints of viewing Wikipedia on smaller screens, and also with how these will increase for someone moved to enlarge their own text. Mine, for example, is set to render at 170% of the default size. I am not aware of an existing script that forces collapsible tables to always open in their expanded form but am fairly sure that one could easily be written. Nevertheless, I should say that I do not consider the one click needed to expand a collapsed table as being much of an inconvenience at all. Thank you again.--John Cline (talk) 18:59, 15 December 2017 (UTC)