Template talk:Multiple issues/Archive 14
![]() | This is an archive of past discussions. 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 10 | ← | Archive 12 | Archive 13 | Archive 14 |
Request to add talksection parameter
![]() | This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
The following cleanup message templates have optional parameters to link to a specific section in a talk page:
- {{Cleanup}}:
|talksection=
- {{Expert needed}}:
|talk=
However these links are not shown in the abbreviated rendering when wrapped inside {{Multiple issues}} (see for example Acetone peroxide). Hence I would like to add an optional |talksection=
to {{Multiple issues}} so that it is still possible to link to a specific section of the talk page where a centralized discussion about the issues raised by the attention banners can take place.
I have prototyped the link in the sandbox and tested it here. (Note that I have temporarily used the sandbox version in the Acetone peroxide example so the talk page link now points to the appropriate talk page section.) Thanks. Boghog (talk) 10:03, 26 March 2016 (UTC)
![]() | I've undone the demo on the live article. Please use sandboxes for demonstrations and/or testing. Link to demo version |
- The edit to Acetone peroxide was not a demo but rather a temporary fix to an active dispute. The sandbox demonstration was tested here. Boghog (talk) 16:11, 26 March 2016 (UTC)
Question: Is linking to a single specific section for one of multiple issues (which could be resolved independently) really a good idea? Linking to a section dedicated to only one of the issues is potentially confusing for users wishing to discuss one of the other issues, and directs traffic away from the correct section in that case. fredgandt 15:23, 26 March 2016 (UTC)
- I disagree with the approach. In the example there are separate talk sections for each issue. Creating a redundant general link to a third section, or selected link to one, but not the other section, are not ideal solutions. Better would be to modify each individual template which has talk-link parameters, to include the talk link in the "brief" version of the problem messages which are shown in multiple issues. – wbm1058 (talk) 15:48, 26 March 2016 (UTC)
- I agree that it would also be useful modify the individual templates so that the talk page link is displayed in the individual templates and I would very much welcome suggestions on how to do this. However it is often the case that an editor that is introducing multiple templates might also want to have the discussion in one location optionally separated by sub headings. Right now there is no way to link to a specific talk page section if {{Multiple issues}} is used and we need at least a fall back solution. Boghog (talk) 16:20, 26 March 2016 (UTC)
- That's a good point; I guess I can go along with that, though I'm not sure how necessary it is or how much it would be used. It would be nice if editors dropping three or four (or five or six) issues on an article all at once would also initiate talk about the issues. Seems to me that they rarely do that. Typically this happens on newly created pages, and finding specific discussions on virgin talk pages is not a problem. wbm1058 (talk) 16:31, 26 March 2016 (UTC)
- I agree that including
|talksection=
is theoretically a problem since several of the sub templates may point to different sections of the talk page. However as it now stands, none of these talk page section links would be shown if wrapped in {{Multiple issues}}. In addition, as far as I can tell, the only two attention banner templates that contain|talk=
or|talksection=
parameters are {{Cleanup}} and {{Expert needed}}. Currently there are only 16 articles that contain both of these templates and also|talk(page)=
. In many of these articles, the|talk=
is blank and there is a single example (Carnitine) where there is more than one non-blank|talk=
parameter and in this example, all parameters point to the same section of the talk page. Hence currently there is not a single live example where adding|talksection=
to {{Multiple issues}} would cause a conflict. Hence based on current usage, a conflict in talk page links is extremely unlikely. Boghog (talk) 10:04, 27 March 2016 (UTC)
- I agree that including
- That's a good point; I guess I can go along with that, though I'm not sure how necessary it is or how much it would be used. It would be nice if editors dropping three or four (or five or six) issues on an article all at once would also initiate talk about the issues. Seems to me that they rarely do that. Typically this happens on newly created pages, and finding specific discussions on virgin talk pages is not a problem. wbm1058 (talk) 16:31, 26 March 2016 (UTC)
- I agree that it would also be useful modify the individual templates so that the talk page link is displayed in the individual templates and I would very much welcome suggestions on how to do this. However it is often the case that an editor that is introducing multiple templates might also want to have the discussion in one location optionally separated by sub headings. Right now there is no way to link to a specific talk page section if {{Multiple issues}} is used and we need at least a fall back solution. Boghog (talk) 16:20, 26 March 2016 (UTC)
Not done: please establish a consensus for this alteration before using the
{{edit template-protected}}
template. --Redrose64 (talk) 16:48, 26 March 2016 (UTC)
- Regarding how to modify individual issue templates to show links to talk page sections in both the more verbose standalone version, and the briefer "multiple issues version", see this diff for an example of how I modified {{orphan}} to still include the "find links" tool link in the "multiple issues version" of the message. See Template:Ambox#issue and fix for documentation. I suppose the solution here would be to make the link generated by the
talk
parameter still get displayed in the "compact" version of the Ambox message. wbm1058 (talk) 17:17, 26 March 2016 (UTC)
- Thanks for the tip. It is easy enough to modify {{Expert needed}} to show the talk page link even if it is wrapped in {{Multiple issues}} (see this diff). However this somewhat defeats the purpose of the {{Multiple issues}} which is to show condensed versions of the wrapped templates. Hence I am really not sure that is the best solution either. Boghog (talk) 08:39, 27 March 2016 (UTC)
- One additional thought. Having a general talk page link in the {{Multiple issues}} and a section link in {{Expert needed}} is both redundant and confusing. It is better to give editors an option to specify a link to a centralized discussion. Also please keep in mind that any editor using
|talksection=
would be making a conscious decision to do so and therefore is more likely than not to use it appropriately. Of course, this parameter might be misused, but the same could be said about most any parameter. Boghog (talk) 10:17, 27 March 2016 (UTC)
- When linking to an article's talk page for multiple issues, it is impractical, confusing and potentially disruptive to link to only one section. I agree that where a talk section can be and is specified for an individual issue, the smaller version of that issue (when displayed via Multiple issues) should include that link as it does in its larger stand-alone condition. This then becomes the responsibility of {{Ambox}} and its Module:Message box with no changes to
{{multiple issues}}
required, and as such, I propose moving this discussion to those talk pages, where it be suggested for deliberation, that the smaller versions of any issue message with a talk section link displays that link. fredgandt 10:57, 27 March 2016 (UTC)
- How is this impractical? One could equally argue that having redundant talk page links in the banner shell and in the individual banners is confusing. Also including the talk page links increases the size of the small version of the templates and somewhat defeats the purpose of using {{Multiple issues}}. Furthermore there may be legitimate reasons to link to a centralized discussion if that is how the editor that placed these banners decided to organize the discussion. Hence this is a very practical proposal. The only way the use of
|talksection=
could possibly be disruptive is there were more than one talk section being linked. As pointed out above, there are currently zero live examples of this, so this is likely to be a very rare event. Boghog (talk) 11:20, 27 March 2016 (UTC) - The documentation can be written to further reduce the already unlikely possibility of misuse, for example:
|talksection=
: the section of the talk page explaining what needs to be done. This parameter should only be used if there is a single centralized discussion concerning the type and extent of clean-up required. If there is more than one talk page section linked from different article message boxes, it is better to place these outside the {{Multiple issues}} template.
- Boghog (talk) 12:43, 27 March 2016 (UTC)
- How is this impractical? One could equally argue that having redundant talk page links in the banner shell and in the individual banners is confusing. Also including the talk page links increases the size of the small version of the templates and somewhat defeats the purpose of using {{Multiple issues}}. Furthermore there may be legitimate reasons to link to a centralized discussion if that is how the editor that placed these banners decided to organize the discussion. Hence this is a very practical proposal. The only way the use of
- Boghog - you've just made an argument against your own implementation of your bulldozed sidestepping {{Multiple issues 2}} with "This parameter should only be used if there is a single centralized discussion concerning the type and extent of clean-up required". This is exactly my point; the main link to the talk page is biased in favour of one of the multiple issues which is potentially confusing and likely in widespread use to cause conflict.
- Appending a simple and short "Discuss" link to each of the multiple issues where that parameter is specified will not greatly increase the size, and maintaining a general link to the article's talk page is correct when referring to the discussion of all the multiple issues. Arguing that a link to an article's talk page is ever "redundant" is frankly ridiculous.
- I would consider it perfectly clear if viewing a multiple issues template with individual "Discuss" links appending each issue, and a general "Talk page" link at the top for discussions, which is appropriate for what. Right now, your live kludge (methodology 3 editors have expressed objection to) shows only one link to the talk page which targets discussion about only one of the multiple issues. fredgandt 13:33, 27 March 2016 (UTC)
- Quite to the contrary, a centralized discussion is a good thing that will lead to less, not more confusion. And how exactly will this to lead to conflict? I don't follow your logic. It is more important to consider how templates actually are used rather than theoretically could be used. The hypothetical problems that you raised are grossly exaggerated. Concerning your second point, too many links in close proximity is called overlinking that equally applies to the contents of rendered templates as it does to prose. Finally
3 editors have expressed objection
– false. Only one has. wbm1058 above, while not completely agreeing with me at least acknowledged the point I was trying to make. GoingBatty in this edit was probably objecting to using a sandboxed template in mainspace and so far has expressed no opinion on the actual template proposal. Boghog (talk) 14:10, 27 March 2016 (UTC) - Acetone peroxide currently has two attention banners, {{Expert needed}} and {{Refimprove science}} and only the first supports a talk page parameter. Refimprove is self explanatory and generally does not need to be discussed. If someone does have a question about the sourcing, it would not hurt to add this to the expert needed section as a subheading since these two issues are interrelated. And to reiterate what I have already stated above, there are only two attention banner templates that support talk page parameters which minimizes the chance of conflict and confusion. Boghog (talk) 14:25, 27 March 2016 (UTC)
- In the interest of completeness, scanning this list I found a number of additional attention banners (see below) that support a talk parameter. Searching these for potentially conflicting talk page parameters did not find a single case confirming that the probability of conflicts is very low. The other remarkable statistic is that these talk parameters are not widely used (total template transclusions and number of which have a talk page parameter are listed below) confirming wbm1058's suspicions.
- Quite to the contrary, a centralized discussion is a good thing that will lead to less, not more confusion. And how exactly will this to lead to conflict? I don't follow your logic. It is more important to consider how templates actually are used rather than theoretically could be used. The hypothetical problems that you raised are grossly exaggerated. Concerning your second point, too many links in close proximity is called overlinking that equally applies to the contents of rendered templates as it does to prose. Finally
List of attention banners supporting talk parameters
|
---|
Searches for potential
|
RfC - Options so far
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The discussion above suggests 4 possible routes:
- Do nothing.
- Allow the current "Talk" link to be manipulated to a specific associated talk page section.
- Allow the talk link option in the child issues templates to show.
- As #3, but also remove the main "Talk" link.
A fifth option not yet discussed (above) is to rethink the layout/presentation of multiple issues altogether; rather than effectively crippling the normal functionality of the child issues templates, we could collapse them to little more than a list of issues i.e. "Expert attention, cleanup and citations needed", then allow the reader to expand the whole template to show the full versions of the children, including their associated links where provided. fredgandt 17:14, 2 April 2016 (UTC)
- Options #2 and #3 are not mutually exclusive. One could do both thereby providing editors with the option to link to either one centralized discussion or one or more issue specific discussions. I have implemented #3 for {{Expert needed/sandbox}} in this edit and added some test cases wrapped in the {{Multiple issues}} template here. The disadvantage of only implementing
#2#3 is there would be two talk page links, one to the top of the talk page and second to a specific section. This is somewhat confusing. The fifth option to suppress the talk page link combined with #3 I think might be useful. Collapsing the daughter templates IMHO is a non starter. These templates need to be displayed in an abbreviated form. Boghog (talk) 17:53, 2 April 2016 (UTC) - I have no problem adding a general link to a specific section, but I would also be interested to explore other options for a compact link for each individual issue. This could be a single word ("discuss") or perhaps an icon. — Martin (MSGJ · talk) 17:56, 2 April 2016 (UTC)
RfC option #3 - Option to show links in compact child templates
Myself, wbm1058, MSGJ and Boghog seem to agree that having each child template's talk link (if used) show in the multiple issues format would be either nice to have or at least better than nothing. If we could all please state our agreement or disagreement (as appropriate), regarding just this one possible course of action, simply and clearly for the record, we may at least have a workable place to start.
- Support fredgandt 23:33, 4 April 2016 (UTC)
- Support. I don't believe this should be controversial. Implementation discussion below. wbm1058 (talk) 01:59, 5 April 2016 (UTC)
- Comment. I would support this option if an additional option that suppresses the talk link in the parent were provided. If the child templates contain section specific talk page links, then the generic parent link becomes redundant and potentially distracting. Why display a link to the top of the talk page if section specific link(s) are provided? Boghog (talk) 05:35, 5 April 2016 (UTC)
- I don't like the idea of suppressing specific links to talk-page sections, which could lead to overlooking a forked discussion. Which is why I think the "compact" version of the message should still show a link. wbm1058 (talk) 12:59, 5 April 2016 (UTC)
- I completely agree with you that the child template should show a link if specified. What I am requesting is that the editor be given the option of suppressing the generic link in the parent template precisely so the child link is not overlooked. In summary, my proposal is absolutely not to suppress specific links, but rather to optionally suppress the generic link to the top of the talk page. One last note. As a practical matter, overlooking a forked discussion based on present usage is unlikely. There are presently zero examples of attention banners pointing to different sections of a talk page. Boghog (talk) 18:45, 5 April 2016 (UTC)
- @Boghog: - Do you oppose child template talk section links (when provided) showing if your condition is not met? fredgandt 16:29, 5 April 2016 (UTC)
- No, but see my comment directly above. Boghog (talk) 18:45, 5 April 2016 (UTC)
- I don't like the idea of suppressing specific links to talk-page sections, which could lead to overlooking a forked discussion. Which is why I think the "compact" version of the message should still show a link. wbm1058 (talk) 12:59, 5 April 2016 (UTC)
The {{Ambox}} talk parameter is implemented in the Lua Module:Message box. The standard verbose message is "Relevant discussion may be found on the talk page." The compact (collapsed) version inside {{multiple issues}}, as suggested by Martin above, can just be the single linked word ("discuss"). Pinging Mr. Stradivarius, the primary author of that module. Would you like to implement this? wbm1058 (talk) 01:59, 5 April 2016 (UTC)
- Slow down - this discussion has only been open a couple of days. Let's wait for consensus before rushing off to change the template. I will note however that although we have a means to hide certain content on the compact version, we do not yet have any means to add additional content (such as parentheses). But let the technical discussion take a back seat for now. — Martin (MSGJ · talk) 08:37, 5 April 2016 (UTC)
- I'm going to be busy for the next couple of weeks, so I might not get round to it until after then, but I can take a look, certainly. — Mr. Stradivarius ♪ talk ♪ 09:24, 5 April 2016 (UTC)
RfC option #2 - Option to link to centralized discussion
An editor that is adding several attention banners at the same time may prefer to link to a centralized discussion. This option would a allow an editor to create such a link in the parent template.
- Support as proposer. Boghog (talk) 05:34, 5 April 2016 (UTC)
- Ambivalent: this may be useful occasionally but I'm not sure it is a good idea to encourage it. When someone comes and adds another issue to the template, you can be sure that they won't update or remove the talk page link, and then there will be a link to an irrelevant discussion. — Martin (MSGJ · talk) 09:12, 5 April 2016 (UTC)
- The search links in the collapsed box above show there is not a single example of two attention banners in the same article pointing to different sections of the talk page. Based on current usage at least, the probability of such an occurrence would appear highly unlikely. Boghog (talk) 10:17, 5 April 2016 (UTC)
- Ambivalent, given the limited times that discussions are even initiated. If a centralized discussion link is implemented, then all discussion links should be shown in the {{multiple issues}} messages, and when there are both a generic discussion and one or more specific discussions, then the specific discussion sections should be refactored to be sub-sections of the generic discussion. – wbm1058 (talk) 13:10, 5 April 2016 (UTC)
- Oppose allowing manual manipulation of the primary talk link, and oppose subduing it under any circumstances. The current use of {{Multiple issues 2}} (>.<) demonstrates perfectly how the ability to manipulate the primary talk link leads to bias. Arguing that it should only be used to link to a centralised discussion with subsections for each child issue, is fair enough, but that is proven to not be the case in the one improper utilisation of this functionality; the one time this feature is used, it's used to do the very thing it's not supposed to be doing. That's not a good track record, or indication that it's likely to work out better if widespread implementation were possible. In the case of subduing/hiding the primary talk link, each child issue would HAVE TO HAVE an associated talk section shown, or a default to what? To the standard talk page link - which we have already? Why recode a template to move a perfectly well understood feature to be stated multiple times elsewhere? Summary: A primary link to the associated talk page will never be wrong, but changing it or removing it can be. fredgandt 16:22, 5 April 2016 (UTC)
- Exactly what bias is {{Multiple issues 2}} introducing? All the attention banners in Acetone peroxide were introduced by one editor. Hence it makes sense to direct all links to the same talk page section. I agree with you that the primary link to the to the talk page will never be wrong, but it could make it more difficult to find the one and only one discussion that based on present usage is likely to exist. Please allow editors that introduced the attention banners in the first place the flexibility to direct the discussion to the relevant talk page section. And please don't underestimate editors intelligence. Boghog (talk) 19:27, 5 April 2016 (UTC)
- There are multiple issues with a talk link pointing to a section devoted to only one of them; how much more biased could it be? I take things as I find them, and my estimate of most editors intelligence is quite high. Please don't assume to know anything about how I estimate anything, ever. fredgandt 20:10, 5 April 2016 (UTC)
- Bias is impossible if there are no other talk page discussions. Certainly there were no other discussion in the Acetone peroxide article. More importantly, there are zero examples of attention banners pointing to different talk page sections in the same article. It might happen, but current usage suggests that this would be a rare event. Most importantly, editors that introduce these attention banners should be allowed the flexibility to direct talk page links to a centralized discussion. Boghog (talk) 20:22, 5 April 2016 (UTC)
- There are multiple issues with a talk link pointing to a section devoted to only one of them; how much more biased could it be? I take things as I find them, and my estimate of most editors intelligence is quite high. Please don't assume to know anything about how I estimate anything, ever. fredgandt 20:10, 5 April 2016 (UTC)
- Exactly what bias is {{Multiple issues 2}} introducing? All the attention banners in Acetone peroxide were introduced by one editor. Hence it makes sense to direct all links to the same talk page section. I agree with you that the primary link to the to the talk page will never be wrong, but it could make it more difficult to find the one and only one discussion that based on present usage is likely to exist. Please allow editors that introduced the attention banners in the first place the flexibility to direct the discussion to the relevant talk page section. And please don't underestimate editors intelligence. Boghog (talk) 19:27, 5 April 2016 (UTC)
Add section parameter
Look at this section of Kalmar Union, it says "This article has multiple issues", it should say "This section has multiple issues". ∼∼∼∼ Eric0928Talk
04:50, 11 January 2017 (UTC)
- @Eric0928: It already has
|section=
. See Kalmar Union change. — JJMC89 (T·C) 06:30, 11 January 2017 (UTC)
Template-protected edit request on 24 April 2017
![]() | This edit request to Template:Multiple issues has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
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)
- 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)
- 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)
- 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 ifsection=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)
Fair use
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)
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)
- @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)
Template-protected edit request on 12 December 2017
![]() | This edit request to Template:Multiple issues has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
To allow tracking, please add parameter |cat= to this template's {{Ambox}} as follows:
Where it now reads:
{{orphan}} messages in {{multiple issues}}--> </div> | <includeonly>{{error|No issues specified. Please specify issues, or remove this template.}}</includeonly> }} </div>
Change it to read:
{{orphan}} messages in {{multiple issues}}--> </div> | <includeonly>{{error|No issues specified. Please specify issues, or remove this template.}}</includeonly> |cat=Articles with multiple maintenance issues }} </div>
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)
- Agreed,
- 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)
- I don't think it will work. You're adding an unrecognised fourth parameter to an
- 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)
Should this template render its content in a collapsed state by default?
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;">
- When
- I see the template as collapsible, not collapsed by default; am I wrong?--John Cline (talk) 17:27, 12 December 2017 (UTC)
- 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)
Rename and reword template to "Multiple problems"
Rationale:
- "Issues" is a euphemism for "problems". This is even discouraged in the Wikipedia manual of style (WP:EUPHEMISM), which states "Do not use issue for problem or dispute."
- We should be clear and direct. "Problems" makes clear that, well, the article has problems. If that's what we mean, then we should say it. Popcornduff (talk) 09:23, 16 February 2018 (UTC)
- I'm with you in preferring "problem" to "issue" to refer to a problem. In this case, though, so many of the tags included in a "multiple issues" box are expressed as maybe's. "The neutrality of this article has been disputed", "this article appears to contradict itself", "this article may require copyediting"... implying "The question of whether there is or is not a problem here is an issue calling for further investigation and discussion", a process we don't want to pre-empt with a heading "Multiple problems": Noyster (talk), 10:34, 16 February 2018 (UTC)
- Makes sense. Thanks for the reply. Popcornduff (talk) 15:36, 16 February 2018 (UTC)
Bug with UDP/undisclosed paid editing tag?
I've used multiple issues before and don't recall this: On Racine Art Museum, when I included UDP in the multiple issues, UDP retained its own borders and messed up the formatting. I'm unfamiliar with template language and can't diagnose the problem. Any ideas? BlackcurrantTea (talk) 12:51, 20 April 2018 (UTC)
- @BlackcurrantTea: The
{{multiple issues}}
template only works properly with banners that are built around the{{ambox}}
template; but Template:Undisclosed paid uses raw HTML - a one-row two-column<table>...</table>
. --Redrose64 🌹 (talk) 19:25, 20 April 2018 (UTC)- Thanks, Redrose64. It's good to know there's an explanation other than sunspots, gremlins, or bad luck. BlackcurrantTea (talk) 03:44, 21 April 2018 (UTC)
Template-protected edit request on 26 December 2018
![]() | This edit request to Template:Multiple issues has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
(Creativeevilatwork (talk) 12:01, 26 December 2018 (UTC)) There is an issue with an article which I am not able to sort. What is missing in The Wikimedia page is actress Neyha Sharma, need help to improve Creativeevilatwork (talk) 12:01, 26 December 2018 (UTC)
Not done: That's not a matter concerning the template. Take it to the article's talk page. Cabayi (talk) 12:41, 26 December 2018 (UTC)
Template-protected edit request on 26 November 2019
![]() | This edit request to Template:Multiple issues has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
This template is used on pages to group notices that shouldn't be described as "issues". I would like a parameter to be added to change the word(s) "issues" to "notices", e.g. {{{multiple issues|notices=y …
. Nixinova T C 22:38, 26 November 2019 (UTC)
- Please provide an example of what you are describing, ideally by linking to a real article. The documentation clearly states that the template should be used only for maintenance issues:
This template tags articles or sections for multiple maintenance issues...
– Jonesey95 (talk) 23:42, 26 November 2019 (UTC) Not done: please make your requested changes to the template's sandbox first; see WP:TESTCASES. Primefac (talk) 17:37, 27 November 2019 (UTC)
German version of "Multiple issues"?
I'd like to mark a German-language article (Rolf Tschierschky , if you're interested) with multiple issues, but can't find a German version of this template. Could anyone help? Thanks in advance. -- HeighHo talk 15:54, 28 November 2019 (UTC)
- They might not have one. They don't seem to have many maintenance templates really, see de:Kategorie:Vorlage:Wartungsbaustein. The page de:Wikipedia:Bewertungsbausteine may help. --Redrose64 🌹 (talk) 09:38, 29 November 2019 (UTC)
- I wouldn't rely on Wikidata as a sole source, but the page for the template's item supports Redrose64's theory that there isn't a German version. BlackcurrantTea (talk) 00:29, 30 November 2019 (UTC)
Template-protected edit request on 12 August 2020
![]() | This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
[{{fullurl:{{FULLPAGENAME}}|action=edit}} improve it]
→ [[Special:EditPage/{{FULLPAGENAME}}|action=edit}}|improve it]]
217.117.125.72 (talk) 16:19, 12 August 2020 (UTC)
- I assume the desired result is to change the improve it link from an html link to https://en.wikipedia.org/w/index.php?title=Template:Multiple_issues/testcases&action=edit into a wikilink to Special:EditPage/Template:Multiple_issues/testcases, using Template:Multiple issues/testcases as an example.
- I tested your change in the sandbox and fixed a bug: The
|action=edit
needed to be removed. - It works. This change would result in some very minor efficiency gains and some very minor savings to the Preprocessor visited node count and Post-expand include size.
- In short, this change is safe to make. However I don't think this should be the only template changed. There are several cleanup templates listed at Wikipedia:Template index/Cleanup that use the html link for improve it. Either change them all or leave them all alone, for the sake of consistency. I have not tested this change on the other templates, but I expect the results will be similar: I expect that the changes will all be safe and they all will have a very minor, probably negligible, improvement on speed and slight reductions to Preprocessor visited node count and Post-expand include size.
- I recommend declining this edit request for now due to the large number of templates affected and lack of discussion of the merits of the proposed change. The requesting editor did not log in, so I can't reach him directly. If there is interest in doing this, I recommend first opening an informal discussion at Wikipedia talk:Template index/Cleanup to gain consensus, posting a link to the discussion on Wikipedia talk:WikiProject Templates and on the talk pages of all affected templates. davidwr/(talk)/(contribs) 20:51, 22 August 2020 (UTC)
- OK,
Not done for now: please establish a consensus for this alteration before using the
{{edit template-protected}}
template. --Redrose64 🌹 (talk) 22:22, 22 August 2020 (UTC)
- OK,
{{Update-EB}}
I raised an issue about that template's appearance when used within this one at Template talk:Update-EB, but understandably there's been no response, so asking here in case anyone would like to take a look (to be honest I'm not sure which template needs to be edited). The issue is that {{update-EB}}, when used within {{multiple issues}}, just says that the article is based on the Britannica 11th edition, but not why that's a problem or what ought to be done about it. Something like "and so is likely to be outdated" should be added. – Arms & Hearts (talk) 19:12, 10 October 2020 (UTC)
- I answered the query at Template talk:Update-EB. There is no need to change {{Multiple issues}}. davidwr/(talk)/(contribs) 22:09, 10 October 2020 (UTC)
Specifying section of Talk page
The {{multiple issues}} template directs readers to see a discussion on the tagged article's talk page, but I didn't see any instructions for directing to a specific section within the talk page. In lieu of this, I made the new section on the article's talk page obvious with "Unreliable sources [dmy date]". Is there a way to set the "discuss these issues on the talk page" link to the specific section that discusses the issues named by the template? I know it exists for other templates.
Christopher, Sheridan, OR (talk) 04:38, 12 October 2020 (UTC)
- I think you need to ask for a
|talk=
parameter at Template talk:Unreliable sources, but I am not sure. – Jonesey95 (talk) 05:03, 12 October 2020 (UTC)- Thank you, but that has already been done by someone else (see § talksection parameter). Christopher, Sheridan, OR (talk) 16:23, 12 October 2020 (UTC)
Template-protected edit request on 22 February 2021
![]() | This edit request to Template:Multiple issues has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
I am the creator, director and joint producer of the Mr Men Films from 1973 until 2004. The information above is almost all incorrect.2A00:23C5:FD85:3500:B069:5100:567E:B130 (talk) 17:05, 22 February 2021 (UTC)
Not done: this is the talk page for discussing improvements to the template
{{Multiple issues}}
. Please make your request at the talk page for the article concerned. --Redrose64 🌹 (talk) 18:53, 22 February 2021 (UTC)
Please help
How do I add WP:COI in {{template:Multiple issues}} Infinitepeace (talk) 01:48, 14 March 2021 (UTC)
- Here's an example usage:
{{multiple issues|{{COI}}{{copy edit}}{{unreferenced}}}}
- Remember to start a talk page discussion to explain the COI, as instructed at {{COI}}. – Jonesey95 (talk) 15:44, 14 March 2021 (UTC)
- @Jonesey95: Also asked at Wikipedia:Teahouse. The requesting user has been blocked. GoingBatty (talk) 01:06, 16 March 2021 (UTC)
Getting rid of show/hide option, to fix autocollapse of navboxes
It appears that whenever this template is loaded onto a page that also has navboxes, it will cause the navboxes to collapse. Example. A simple way to solve this might be to remove the show/hide option from this template. This template appears to default to show. And also the contents of the template aren't very dense, so in my opinion no need to give the option to collapse. Thoughts? –Novem Linguae (talk) 02:59, 28 May 2021 (UTC)
- For those coming in cold, see Template talk:Navbox#Autocollapse. --Redrose64 🌹 (talk) 07:58, 28 May 2021 (UTC)
Problems when merging {{context}} tag
Hi,
I'm finding that this doesn't work properly with {{context|details=}}
. The standalone version displays the details
as it should, but they disappear in the merged version. This is in contrast to tags like {{expert needed|reason=}}
which do still display the information. An example can be seen in this revision and this one of Fluctuation spectrum (before and after merging the Context tag respectively). I've also left a comment on the {{context}}
talk page. Musiconeologist (talk) 17:13, 10 September 2021 (UTC)
- @Musiconeologist: Hi there! The templates {{context}} and {{expert needed}} (and many other maintenance templates) use {{ambox}}. When the maintenance templates are used on their own, they display both the
|issue=
and|fix=
parameters from {{ambox}}. However, when the maintenance templates are wrapped by {{multiple issues}}, it only displays the|issue=
parameter from {{ambox}}. The {{expert needed}} template contains|reason=
within {{ambox}}'s|issue=
parameter, so the reason is shown in {{multiple issues}}. However, the {{context}} template contains|details=
within {{ambox}}'s|fix=
parameter, so the details are not shown in {{multiple issues}}. Hope this helps! GoingBatty (talk) 17:59, 10 September 2021 (UTC)- So the way to correct this behaviour would be to use the
|issue=
parameter for|details=
in {{context}}? ~~~~
User:1234qwer1234qwer4 (talk) 18:17, 10 September 2021 (UTC)- @1234qwer1234qwer4: Yes, the way to correct the behavior (presuming there's consensus to do so) is for
|details=
to be in the|issue=
parameter in {{context}}. GoingBatty (talk) 18:28, 10 September 2021 (UTC)
- @1234qwer1234qwer4: Yes, the way to correct the behavior (presuming there's consensus to do so) is for
- So the way to correct this behaviour would be to use the
- @GoingBatty: Am I right in thinking this would simply entail moving
{{#if:{{{details|}}}|, especially: {{{details}}}}}
from its current location in|fix=
to the point in|issue=
where the details should appear? (With any necessary adjustment to the text.) Musiconeologist (talk) 19:54, 10 September 2021 (UTC)- @Musiconeologist: You got it! Someone may want to first try it out in Template:Context/sandbox and set up some Template:Context/testcases. GoingBatty (talk) 20:00, 10 September 2021 (UTC)
- @GoingBatty: Am I right in thinking this would simply entail moving
Help improve / help to improve
An infinitesimal nitpick, since I can't edit this template myself. It's one I might draw attention to if I was editing something for an author. I think the change of wording in today's edit from Please help improve it to Please help to improve it is bordering on incorrect. It seems to me there's a subtle difference in usage. Examples:
- A big trolley will help you to carry the bags.
- I will help you carry the bags.
- Good proofreading will help to improve the article.
- I will help improve the article.
For me, help improve is more appropriate fr a helpful person, and help to improve is more appropriate for a helpful situation or inanimate object. At the very least help to improve is slightly more formal in tone, which I dislike in this context.
It's a tiny and subtle difference, but I think the original was better. —Musiconeologist (talk) 22:26, 26 September 2021 (UTC)
- @Tony1 Pinging who made the edit. ~~~~
User:1234qwer1234qwer4 (talk) 22:28, 26 September 2021 (UTC)- I agree with the OP and with the original language. Please revert. – Jonesey95 (talk) 23:07, 26 September 2021 (UTC)
- "Bordering on incorrect"? Why? Tony (talk) 00:12, 27 September 2021 (UTC)
- I expressed that more strongly than I meant. I'm not suggesting either version breaks any grammatical rule. For me it's no more than a slight awkwardness: a sense that there are two slightly different meanings (being a means versus being an agent) and that the words lean towards the wrong one. But obviously it depends very much on whether other readers perceive it that way too. It's the sort of thing that varies between countries and between age groups. —Musiconeologist (talk) 02:09, 27 September 2021 (UTC)
- Musiconeologist – you wrote: "For me, help improve is more appropriate fr a helpful person, and help to improve is more appropriate for a helpful situation or inanimate object. At the very least help to improve is slightly more formal in tone, which I dislike in this context." First, I'm not on board with the distinction you proposed on the basis of person vs non-person. I partly agree with your point about formality; but I'd put it differently: "help improve" is less appropriate in a formal register, especially in written mode—and this is surely such a register. "Help improve" might be just fine in oral mode, depending on the context; but the "to" makes things a little clearer (and non-native speakers are likely to read the template too); and I'd say that "help to improve" is fine throughout the formal–informal spectrum. What first prompted me to add the word is that "help improve" is a bit gummy with its two neighbouring clusters of consonants, both containing "p". I find it easier to say and to listen to when they're separated by "to", which adds a nicer rhythm. It's really no big deal, and I do think it's a slight improvement in a very widely used text. Tony (talk) 12:24, 27 September 2021 (UTC)
- I think that this is an ENGVAR situation - "help to improve" is correct British English; "help improve" seems American to me. --Redrose64 🌹 (talk) 21:22, 27 September 2021 (UTC)
- Redrose, I don't believe this is the case. Do you have any evidence? Tony (talk) 03:23, 28 September 2021 (UTC)
- I think that this is an ENGVAR situation - "help to improve" is correct British English; "help improve" seems American to me. --Redrose64 🌹 (talk) 21:22, 27 September 2021 (UTC)
- Musiconeologist – you wrote: "For me, help improve is more appropriate fr a helpful person, and help to improve is more appropriate for a helpful situation or inanimate object. At the very least help to improve is slightly more formal in tone, which I dislike in this context." First, I'm not on board with the distinction you proposed on the basis of person vs non-person. I partly agree with your point about formality; but I'd put it differently: "help improve" is less appropriate in a formal register, especially in written mode—and this is surely such a register. "Help improve" might be just fine in oral mode, depending on the context; but the "to" makes things a little clearer (and non-native speakers are likely to read the template too); and I'd say that "help to improve" is fine throughout the formal–informal spectrum. What first prompted me to add the word is that "help improve" is a bit gummy with its two neighbouring clusters of consonants, both containing "p". I find it easier to say and to listen to when they're separated by "to", which adds a nicer rhythm. It's really no big deal, and I do think it's a slight improvement in a very widely used text. Tony (talk) 12:24, 27 September 2021 (UTC)
- I expressed that more strongly than I meant. I'm not suggesting either version breaks any grammatical rule. For me it's no more than a slight awkwardness: a sense that there are two slightly different meanings (being a means versus being an agent) and that the words lean towards the wrong one. But obviously it depends very much on whether other readers perceive it that way too. It's the sort of thing that varies between countries and between age groups. —Musiconeologist (talk) 02:09, 27 September 2021 (UTC)
- "Bordering on incorrect"? Why? Tony (talk) 00:12, 27 September 2021 (UTC)
- I agree with the OP and with the original language. Please revert. – Jonesey95 (talk) 23:07, 26 September 2021 (UTC)
- To help is neither a modal verb (I can swim) nor a perception verb (I see him go). Yecril71pl (talk) 18:38, 6 August 2022 (UTC)
Data is sparse, but help improve it appears to be more frequently used than help to improve it (ngrams). Switching the language corpus choice to American English, then to British English, shows a differential with BE historically preferring to improve, although that has flipped recently. Both AE and BE now prefer the version without to. Running the three tests with the instead of it, shows similar results; as does your and their. Mathglot (talk) 19:04, 5 November 2021 (UTC)