Template talk:Multiple issues/Archive 12

Archive 5

←

Archive 10

Archive 11

Archive 12

Archive 13

Archive 14

Spelling error?

When you use the Multiple Issues template with the Copyedit tag, it says grammer instead of grammar. I do believe grammar is the correct spelling? On the standalone tag itself, it doesn't seem to have this problem. kikichugirl ^inquire 21:48, 24 July 2013 (UTC)

Which article do you see this problem in? --Redrose64 (talk) 22:52, 24 July 2013 (UTC)

Never mind! It was in Harold Hopkins Miranda, under the copyedit tag, with the for parameter. Whoever dropped the template must have spelled "grammar" wrong. I'll just quietly fix it now. My bad! --kikichugirl ^inquire 02:46, 25 July 2013 (UTC)

Collapsible feature

Merge from sandbox to make the list of issues collapsible. Default is expanded, can be overridden with collapsed=yes. What's sparked it: [1]. Inspiration: {{Expand language}}. Lfdder (talk) 16:25, 29 September 2013 (UTC)

Testcases all look good, so Done --Redrose64 (talk) 16:47, 29 September 2013 (UTC)

Testcases looks broken to me with one new test case. Please revert until fixed. Technical 13 (talk) 17:32, 29 September 2013 (UTC)

Expand <language> was never supported -- probably because it's not actually an issue. — Lfdder (talk) 18:30, 29 September 2013 (UTC)

In addition to which, the testcases which were added most recently showed no difference between live and sandbox, other than the collapsibility added at Lfdder's request. The new testcases did have some problems, all of which were exhibited by both live and sandbox versions: (i) all nested templates must be in the first positional parameter, but {{Expand Spanish}} was in positional parameter 2 - I removed the pipe which separated that from {{context}}; (ii) when {{Expand Spanish}} is used in template space, it displays documentation, which must be suppressed by using |nodoc=yes; (iii) nested subtemplates which recognise the |demospace= paramater (such as {{Expand Spanish}} but not {{context}}) should have that set to |demospace=main when being used for demo/test purposes. I made the appropriate amendments, and the only problem that I now see is a stray bullet emitted by {{Expand Spanish}} - but again, that happens for both live and sandbox. Therefore, Not done: --Redrose64 (talk) 19:09, 29 September 2013 (UTC)

• That's not what I'm seeing. commons:File:Multiple issues collapsing bug.png Technical 13 (talk) 19:26, 29 September 2013 (UTC)

  It looks fine for me in Firefox. Try turning your user scripts off. — Lfdder (talk) 19:37, 29 September 2013 (UTC)

Can I request a colon after "Issues"? DoctorKubla (talk) 21:10, 1 October 2013 (UTC)

Yes, Done --Redrose64 (talk) 22:03, 1 October 2013 (UTC)

Guys - WP:BOLD is all very well, but I would have liked to have the opprtunity to comment on this request before it was implemented (22 minutes - must be a record!) That said I support the initative but I am not keen on the extra line "Issues:" which this adds to every instance of the template. I've been working on an improvement in the sandbox, and invite comment on that. — Martin (MSGJ · talk) 13:14, 3 October 2013 (UTC)

I agree with you MSGJ, as you can see above; however, you have the advantage that you can WP:REVERT this change and I couldn't. I'm not opposed to the concept, I opposed to the current implementation and still think this should be reverted until fixed. Technical 13 (talk) 13:35, 3 October 2013 (UTC)

Well, the change should have been revertable on request, but you did not give any valid reasons for reverting, as Redrose64 explained. Anyway, if you could check the current sandbox and give your comments, we may be able to implement that and avoid the need to revert :) — Martin (MSGJ · talk) 13:42, 3 October 2013 (UTC)

That looks like a great start. The only section that has any issue is the bottom testcase where there is still the empty bullet. Implement what you have so far (as it is an improvement) and I'll work on the other issue some time. Technical 13 (talk) 13:52, 3 October 2013 (UTC)

A "great start"? A stray bullet makes it a start? — Lfdder (talk) 14:04, 3 October 2013 (UTC)

The stray bullet appears whether you use the version prior to 29 September 2013, the version as currently live, or the version currently sandboxed. It is not a problem in {{multiple issues}} but in one of the subtemplates of {{Expand Spanish}} (the stray bullet is somewhere inside {{hidden}}, I think that it's associated with the </div></div> or the {{#if:}} immediately following those); but {{Expand Spanish}} and similar templates are not intended to be wrapped in {{multiple issues}}. Take it out of the testcases, and the stray bullet will disappear. --Redrose64 (talk) 14:52, 3 October 2013 (UTC)

Yeah, I think it looks better this way. I don't see why we should've waited for you to comment. If this template wasn't protected, I would've not even posted here. Templates get protected to prevent vandalism; not so that we can have a little chat before every change we make. — Lfdder (talk) 14:02, 3 October 2013 (UTC)

Who is "you"? --Redrose64 (talk) 14:52, 3 October 2013 (UTC)

Martin. — Lfdder (talk) 15:31, 3 October 2013 (UTC)

You did not need to wait for me to comment, but you should allow some time for other editors to comment on your proposal before applying {{editprotected}}. Templates are not only protected to prevent vandalism, but also to prevent the disruption that a poorly thought out change can cause. (I'm talking generally and not necessarily saying that applies in this case.) Anyway, enough already. Back to work ... — Martin (MSGJ · talk) 19:42, 3 October 2013 (UTC)

Talk reference link

I think I understand why the Talk link for this tage only links to the whole of the Talk page rather than to a specific section of it, but this is furstrating. I have used the tag for articles, identifying several issues, but by using the Multiple Issues tag anyone looking for the discussion on the Talk page that refers to it would be frustrated, for instance is there are many sections on the Talk page and/or if sections are added to the Talk page after the section that relates to the tag. Is there any way this could be changed to allow the Talk link to be anchored to a specifc section of the Talk page as happens with other Talk page links? LookingGlass (talk) 10:34, 7 October 2013 (UTC)

If there are multiple issues with an article, there is likely to be a separate thread for each issue. So it would probably not make sense to link to one particular thread. The only logical way to include sections links would be alongside each separate issue. This was not done due to desire to make these templates smaller when used inside {{multiple issues}}. (The only way I could think of would be a single word linked, e.g. (discuss), after the text.) — Martin (MSGJ · talk) 10:54, 7 October 2013 (UTC)

Hi Martin, yes this is what I figured the logic was the first time I encountered the problem. However the question would seem to be most aptly addressed with regard to users of the tag. Is the predominant use of this tag considered to be by those who are "only" house-keeping articles, or by those who are editing them? In other words is its use by those who want to tidy and consolidate the tags, because if they do so currently then they delete any references to discussions on the talk page. IMO there is a growing problem of people not identifying the reasoning behind their edits already, so despite any additional complexity, which on the face of it would appear quite minor, deleting the links is imo a really big negative. Or is this tag imagined as for use by those who identify problems with an article, which they find fall under or between a number of categories? If so then the fact that there is simply no effective way to have and maintain a discussion on the Talk page is also imo a big negative. Is there a user type that I have missed? If not then the negatives of the decision to make the tag "simpler" would appear to far outweigh the positives. I think I will revert to adding multiple tags, each with a link to relevant Talk section, rather than the more elegant Multiple Issue tag. LookingGlass (talk) 13:55, 8 October 2013 (UTC)

Style parameter

Here is the edit screen. In some browsers the [hide] link is just off the right edge of the box. This can be fixed by decreasing the width in the following line of code:

|text  = <table class="collapsible  {{#ifeq:{{{collapsed}}}|yes|collapsed}}" style="width:100%; background:transparent;">

A suggested decrease can be found in the sandbox and visualized on the testcases page. Either the sandbox can be copied/pasted to the live page, or the width can be decreased as follows:

|text  = <table class="collapsible  {{#ifeq:{{{collapsed}}}|yes|collapsed}}" style="width:95%; background:transparent;">

Thank you in advance for your consideration! – Paine Ellsworth ^CLIMAX! 13:51, 2 December 2013 (UTC)

In which browser(s) does the link go off the edge? — Martin (MSGJ · talk) 14:16, 2 December 2013 (UTC)

Hi, Martin! I first noticed it in IE10 and only in "Compatibility View". It looks okay in Firefox and in IE when not in Compatibility View. When in CV and when viewing it in either "Medium" or "Largest" size, the hide link is off the right edge just a bit. – Paine Ellsworth ^CLIMAX! 14:24, 2 December 2013 (UTC)

I used http://browsershots.org and I couldn't see any issues with any of the browsers. But I don't mind to make the change, because it shouldn't have any side effects. Any comments from anyone else about this? — Martin (MSGJ · talk) 10:35, 3 December 2013 (UTC)

I notice the protection of this template has been lowered, so you can make this change yourself. — Martin (MSGJ · talk) 12:33, 3 December 2013 (UTC)

 Done – and  Thank you very much! – Martin (MSGJ) – Paine Ellsworth ^CLIMAX! 16:42, 3 December 2013 (UTC)

Lua rewrite

Hi all! I spent some time working on a Lua rewrite of {{Multiple issues}} yesterday, which can now be seen at Module:Multiple issues (with testcases at Template:Multiple issues/testcases lua). It's still a work in progress, and I've only been writing Lua for a few days, so any and all feedback is welcome (maybe there are more efficient ways to do things? or weird Lua quirks I'm missing? or a way to avoid having to use pcall(), which just feels ugly?). Thanks in advance! Theopolisme (talk) 01:39, 10 December 2013 (UTC)

• Looks better than the original in most of the testcases. I have a couple questions. Is my observation that the lua version seems to list all of the issues in order of the oldest issue at the top and newest at the bottom correct, or is it just coincidence they are entered in the testcases that way? Also I noticed that the new and old parameter options have been coded into the Lua version, since the older parameters have been deprecated (and there is talk about removing them altogether which I am for), do these really need to be added in the Lua version and would removing them make it's footprint any visibly smaller? Technical 13 (talk) 02:11, 10 December 2013 (UTC)

@Theopolisme: - Nice work! I also noticed you included support for the old style parameters and new style templates. Are you able to estimate if there would be a significant time savings if we stopped supporting the old style parameters in Lua? Thanks! GoingBatty (talk) 02:13, 10 December 2013 (UTC)

In order? Hmm, I didn't write anything to do that... ;)

Supporting the old parameters is indeed a bit of a drag -- both literally and on performance -- however, since we only look for them if there are additional arguments besides those already parsed at the beginning, it should not be too significant performance-wise, because the conversion/checking is only done conditionally (ln 213). Over 12,000 pages use this depreciated style, so a bot would need to be written to convert them to use the new format before they could be removed from the template/module. Theopolisme (talk) 03:29, 10 December 2013 (UTC)

I just happen to know a "bot guy" that could write just such a bot... Here, let me ping him... Theopolisme, do you think you could write a bot to update all of the deprecated uses of the old style parameters to the new ones per consensus in this section and the above section. Running such a bot as part of a process to convert the template to Lua I believe falls out of the scope of just "cosmetic", and I Support doing this. Technical 13 (talk) 04:04, 10 December 2013 (UTC)

I've already written this, so I'll file the BFRA. Just was waiting for consensus. Thanks! GoingBatty (talk) 04:22, 10 December 2013 (UTC)

See Wikipedia:Bots/Requests for approval/BattyBot 26. GoingBatty (talk) 04:38, 10 December 2013 (UTC)

I'm wondering why this template should be rewritten in Lua at all. Is it particularly slow? It's not very complex after removing the deprecated parameter support, such that Lua doesn't give us a major improvement in readability, and I don't see anything being done in the Lua code that can't be easily done in wikitext. Anomie⚔ 12:28, 10 December 2013 (UTC)

Personally I would say not. In its present form, it is a wrapper for cleanup templates and adds little to rendering time compared to the templates that it is intended to enclose. I see no need to change {{multiple issues}} into a form which is much more difficult to maintain for very little performance gain. I don't see anything above about advantages of a Lua version (other than "looks better than the original", which is subjective). --Redrose64 (talk) 14:18, 10 December 2013 (UTC)

I'd like to see this conversion from template to Lua take place so that things like sorting the issues (more important and older to the top automatically instead of having to move things around in the template call on the page) can be easily added later. I would find that a valuable feature. If I only have 10 minutes to work on something waiting for the bus, I'd like to get the most important thing worked on instead of wasting my time figuring out what is most important. Technical 13 (talk) 23:40, 13 December 2013 (UTC)

{{multiple issues}}, if used per the present documentation, has exactly one parameter, being an unsorted collection of templates. It is not even a list, but a string: the only mandatory delimiters between the templates are the }} which closes one template and the {{ which opens the next (newlines between the templates are recommended, but definitely optional), which are not part of the {{multiple issues}} syntax. Are you saying that Lua can take this string, split it up into individual templates, and sort these into some other order? --Redrose64 (talk) 00:21, 14 December 2013 (UTC)

I don't see why it would be unable to parse such a string into a usable associative array sorted by classification of template (red, orange, blue, etc), then sort said array by date for each classification. Seems like a fairly straight forward task for any programming language to me. Technical 13 (talk) 00:39, 14 December 2013 (UTC)

Actually, Lua sees the expanded wikitext, so there wouldn't be any curly braces unless those braces are supposed to be visible in the output. Basically, you would get the same thing as calling Special:ExpandTemplates on the first positional parameter. — Mr. Stradivarius ^{♪ talk ♪} 01:11, 14 December 2013 (UTC)

@Mr. Stradivarius: Could you shed some light on why this was listed originally? Theopolisme (talk) 23:23, 13 December 2013 (UTC)

It was because I noticed a few efficiencies that could be made by using Lua for the deprecated parameter code. The template checks the |section= parameter each time Template:Multiple issues/message is called, but in Lua that can be done just once. Also, all the calls to Template:Multiple issues/message can be reduced down to a table of data and a for loop. This means the module uses less code - after removing comments, it is already 2000 characters shorter than the template. That said, if we can finally fix all the transclusions to use the new system and get rid of the deprecated parameter code, a standard template is probably better. Also, Redrose, I didn't find Theo's code difficult to understand at all. I can appreciate that it will be hard to understand if you don't know any Lua, but on the other hand you shouldn't underestimate the amount of time and effort that you have put into learning template code. To someone new to both Lua and template coding, the Lua and the template versions might not appear so different in difficulty. — Mr. Stradivarius ^{♪ talk ♪} 01:06, 14 December 2013 (UTC)

The main problem that I have in Lua templates is the difficulty in tracing the progress of a parameter. You can't look for {{{1}}} or {{{section|}}} - or even their obvious equivalents like name.1 or name.section but must instead analyse how something called name.args is processed; and that processing might happen in a different module without there being any indication of that. Consider {{cite book}}: that has dozens of parameters, and invokes Module:Citation/CS1, but I simply cannot see how that module processes a single parameter. I can see that there are two variables frame.args and pframe.args - one of these is the "real" .args (presumably containing arguments as delimited name/value pairs) - but which one? Let's say that I'm interested in what has happened to a commonly-used parameter, like |title=A Book - I can see that there is a variable data.Title but how does the data get from frame.args or pframe.args (whichever) into data.Title, how does data.Title get put into the output stream, and what happens to it along the way? I look for it in Module:Citation/CS1/Arguments and the only uses of title are six times on four lines: I can work out that it's a local variable, of type string, and that it can be either "Module:Citation/CS1/sandbox" or "Module:Citation/CS1/Configuration/sandbox". What have the names of two sandbox modules got to do with the title of a book? I find that there is Module:Citation/CS1/Whitelist, where there are no variables with title in their identifiers. I see a string of value 'title', in the enigmatic line ['title'] = true, but that doesn't help either.

No, Lua is, as C++ (another enigma) has been described to me, "write-only code": only modifiable by the original author, and that within a few weeks or days of being written. Hand it over to somebody else to maintain, and they'll introduce more bugs than they fix - they might as well start afresh. --Redrose64 (talk) 09:15, 14 December 2013 (UTC)

That's a bit scary. Oh, for the "good ol' days"? (Even I understood BASIC ;>) – Paine Ellsworth ^CLIMAX! 19:48, 14 December 2013 (UTC)

FYI - my bot request was denied. GoingBatty (talk) 00:55, 31 December 2013 (UTC)

The fact that loading time increases is a big drawback. But I guess is the cost we have to pay for simplicity. -- Magioladitis (talk) 01:02, 31 December 2013 (UTC)

Convert deprecated parameters to templates?

It's been quite a while since the Multiple issues template was modified to take full templates instead of parameters (e.g. using {{orphan}} instead of |orphan=). Is it time to convert all the old style parameters to the new format, and then remove the deprecated functionality from the template? (This would also allow the AWB developers to remove code on their side.) If so, would it be possible to create a temporary tracking category that would show all the articles that still user the deprecated parameters, so we could convert them to the full templates? (Note that I'm looking for consensus before using the {{edit protected}} template.) Thanks! GoingBatty (talk) 05:11, 3 December 2013 (UTC)

Yes, this makes sense to me. Editors have had long enough to get used to the new syntax. — Martin (MSGJ · talk) 10:36, 3 December 2013 (UTC)

Simplifying the template will also decrease rendering time for pages. This is certainly useful. -- Magioladitis (talk) 12:30, 3 December 2013 (UTC)

• The problem I see with this is that there are still literally thousands of pages out there using the old syntax. I've seen requests on WP:AutoWikiBrowser/Tasks to update some of these to the new format, and someone usually starts them and then gets yelled at by someone else citing COSMETICBOT saying that it's not a visible change and is disallowed. If this is something that everyone agrees needs to be done, there needs to be an addendum to that guideline saying that per X consensus, updating {{Multiple issues}} parameters is excluded from the cosmetic bot crud. Technical 13 (talk) 13:03, 3 December 2013 (UTC)

If there's consensus here to convert them, then I suggest we request to do a one-time bot run to remove them and ensure the edit summary links to the consensus here. GoingBatty (talk) 06:23, 4 December 2013 (UTC)

• Tracking category created, so we can see how many pages we are talking about. (0 and counting ...) — Martin (MSGJ · talk) 11:43, 5 December 2013 (UTC)

  As there didn't seem to be consensus for this, at this time, I've removed the tracking category. For the record: the population of the category, just prior to disabling it was 31,565. — Martin (MSGJ · talk) 12:50, 29 January 2014 (UTC)

  MSGJ, I don't see any opposition here. That would imply there is a consensus to get this done. There are four users saying this is a good idea and none saying "no"... Please restore the tracking category and GoingBatty let's get moving on getting this done. Thanks all for your hard work on the project! Technical 13 (talk) 14:37, 29 January 2014 (UTC)

  See Wikipedia:Bots/Requests for approval/BattyBot 26 — Martin (MSGJ · talk) 14:41, 29 January 2014 (UTC)

• I see. So, there was one oppose. Okay, thank you. Technical 13 (talk) 15:01, 29 January 2014 (UTC)

@MSGJ: would it be possible to re-enable the tracking category so editors can target those pages and make the change to {{multiple issues}} alongside other non-cosmetic changes? @Magioladitis: I might have missed something in one of the discussions but why is this not included in AWBs general fixes? Jamesmcmahon0 (talk) 08:00, 8 April 2014 (UTC)

Jamesmcmahon0 some editors disagree with us changing from old to new style since there is no gain in page's rendering time. -- Magioladitis (talk) 08:12, 8 April 2014 (UTC)

I just did a very quick test using webpagetest.org and a version of the template with the depreciated para code stripped out({{User:Jamesmcmahon0/sandbox/mireduced}}. I had {{multiple issues}} with 2 issue notices and my stripped down version with the same two and got page load improvements of 0.2s. Would appreciate if someone more knowledgeable about the template code and page load times could do some tests. Repeat tests with different/different amounts of params would be needed . Jamesmcmahon0 (talk) 09:04, 8 April 2014 (UTC)

Default to collapsed?

OK, what's the point in a multiple problems template if it's longer than nearly as long as just listing the multiple problems? But it makes sense if it defaults collapsed though.

So I think it should default to collapsed, if the people are interested in helping or want to know what specifically are the problems, they can always expand it to find out.

And if it needs to be expanded in a particular article you can always set |expanded=false, but that doesn't seem to be the most sensible default.

Comments?GliderMaven (talk) 00:26, 28 January 2014 (UTC)

• I could possibly see it defaulting to a collapsed state if there were more than five issues possibly. But not for just a few... Technical 13 (talk) 01:04, 28 January 2014 (UTC)

• No, any time, ever. If the readers need to know what the problems are for any reason at all, they can push the 'show' button. Very, very often, one of the problems is the article is under referenced, which is blatantly obvious anyway, and very often somebody else has claimed that the article is incomplete and/or biased, but these are things which in every case would be fixed if the article was to go FA. In every case, virtually all the article tags are really telling you as a reader is that the article isn't FA, and should be read with caution. Big deal, I can see that. And the tagging often takes up literally half the screen (depending on screen size, zoom factor, fonts etc.) which is a layout disaster, it's way too much.GliderMaven (talk) 02:28, 28 January 2014 (UTC)

• I disagree with that assessment, I'm sure many other disagree with it also. On the flip side, there are a fair number of editors that think there shouldn't be any tags on the articles at all, and would agree with you. I can see that you are unwilling to give and discuss it, you simply want it your way, don't want to talk about a middle ground, and that's all there is to it. Well, all I can say in that regard is good luck. That being said, I formally oppose this proposal to have all multiple issue template fully collapsed by default for all of the reasons brought out in the multiple consensus forming discussion in the past that have led up to its placement on the article page as is. Technical 13 (talk) 02:44, 28 January 2014 (UTC)

• I can only assume that you have no actual way of rebutting any of my points, since you haven't come up with a single reason why it shouldn't default to collapsed. You're supposed to come up with sensible reasons, not 'vote'.GliderMaven (talk) 03:19, 28 January 2014 (UTC)
• Where has this ever been discussed before? The collapsible feature seems to have been done last October, and there was no discussion here about the default.GliderMaven (talk) 03:28, 28 January 2014 (UTC)

• I agree with GliderMaven. It makes sense that it should be collapsed to save space. Why only leave it open when there are up to five issues taking up space? They're all one click away for the interested reader/editor. —sroc 💬 03:50, 28 January 2014 (UTC)
• I have no problem with collapsing being an "option", but it shouldn't be the default. If they are collapsed by default they will be too small, all exactly identical, become too familiar and no-one will notice them. If they are expanded with a [hide] link for 2-5 (or even 2-3 issues), there will be enough change in each one to be noticed each time and are less likely to become familiar. There of course would be exceptions like on stubs or start class articles that only have a handful of lines of prose. Technical 13 (talk) 04:59, 28 January 2014 (UTC)

To return to the original point, "what's the point in a multiple problems template if it's longer than just listing the multiple problems", it isn't always longer, and in fact is normally shorter. See Template:Multiple issues/testcases#Wrapped vs not wrapped. This is because those templates that are designed to be wrapped in {{multiple issues}} always display less text when wrapped than when not wrapped, and they also display a bullet instead of the image. Consider {{unreferenced}}: if this is not wrapped, it shows "This article does not cite any references or sources. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed." plus a date. But if wrapped, it shows only the first sentence and the date, see Template:Multiple issues/testcases#One issue. Generally speaking, when there are three or more cleanup templates, wrapping them in {{multiple issues}} will always reduce the total height; for two cleanup templates, it may reduce or it may increase; for a single cleanup template, height is always increased by wrapping - but there's no point in wrapping if there's just one, since this template is called "multiple issues", not "single issue". --Redrose64 (talk) 11:54, 28 January 2014 (UTC)

Popular maintenance templates such as {{unreferenced}} have been set up to show less text when they're wrapped in {{multiple issues}}. I occasionally see templates that have their complete text inside multiple issues, and tweak the template code accordingly. GoingBatty (talk) 19:00, 29 January 2014 (UTC)

Actually, the original point is that it's always smaller collapsed. And I just checked, it's always collapsed for mobiles; and so far as I know nobody has ever complained about that.GliderMaven (talk) 17:47, 28 January 2014 (UTC)

• GM, are you really trying to compare grapefruits to raisins? On a mobile device, you don't have any screen to spare and ti is reasonable to collapse those things; however, on a full resolution PC, there is no reason to hide those things. Let me ask you a question, if someone manually puts all of the tags into the {{Multiple issues}} wrapper template and puts the }} at the bottom of the page (I've seen it), wouldn't it being collapsed by default be against WP:COLLAPSE as ALL of the page content would be hidden? Even worse, what happens if the closing }} aren't on the page at all? These two scenarios would be impossible for the average reader and difficult for the "average" editor to figure out and fix. Technical 13 (talk) 19:22, 29 January 2014 (UTC)

• Even a child could handle that. They'd simply notice that the article had vanished and undo the edit.GliderMaven (talk) 22:45, 29 January 2014 (UTC)

• My "full resolution PC" is an 11-inch laptop. This rubbish is ghastly to look at and a waste of (valuable) space. In fact, I find it more comfortable to read Wikipedia on my phone. In addition to collapsing this tpl by default, I've suggested making {{Ambox}} smaller before. Neither is gonna happen. — Lfdder (talk) 02:24, 30 January 2014 (UTC)

screenshot of Business cycle with uncollapsed tag.

For the sake of argument, I've uploaded an example screenshot from the laptop I'm currently running on. The font size and general layout was just what it happened to be at the time:

The issue I have with it is that just two issues are taking up 8 horizontal lines of screen real estate, and the article text is actually only taking up 4. It's notable that the article has been tagged for over 3 years with one of the issues and 2 years with the other; so the tag is clearly not working particularly well.

It seems to me that 'multiple issues' are being given undue weight in screen real estate here; 8 lines for 2 issues is much, much too much. Collapsing it helps a great deal, that's down by half to 4 lines. I think even that is a bit too much, but I could live with 3 or 4 lines; 8 is obscene.GliderMaven (talk) 04:33, 30 January 2014 (UTC)

In your screendump, I count six lines of text within {{Multiple issues}}, not eight: the first item of text wraps once; the first issue doesn't wrap at all, and the second issue wraps twice; but it shouldn't be wrapping that often. There's something about your setup that's putting a large white area to the right of the infobox. This white area is probably the full height of the page, since the {{Multiple issues}} seems to be centred between the left sidebar and an upward projection of the right-hand edge of the infobox, which compresses it sideways, causing the extra wrapping.

When I visit Business cycle the infobox is close to the right-hand scrollbar, and the white gap between the two is small (just 1 em wide); so projecting the right-hand edge of the infobox upwards, there is more sideways space for {{Multiple issues}}, which is centred between the left sidebar and the right scrollbar. This extra width allows the first item of text and the first issue to fit on one line each; the second issue wraps onto a second line (between "subject" and "as") and so the whole box takes up less height - four lines of text in total. --Redrose64 (talk) 12:48, 30 January 2014 (UTC)

The multiple issues box itself takes 2 lines of space, because the box edge itself consumes two lines of text, and then there's 4-6 lines of text on top of that. That's far too much. The problem goes away (mostly) if we collapse by default.

It doesn't seem particularly specific to my account, I tried logging out, and got similar results.

This is clearly a case where the mobile version is doing the right thing, it's very wrong to assume that everyone is reading wikipedia on a very large screen. In effect this is saying that the tag at the top is always far more important than the article itself, particularly on small screen or with bigger text sizes.

In practice, these are virtually always minor issues, if they were really serious issues of life-threatening importance the text would have been edited already more specifically instead of being tagged.GliderMaven (talk) 14:26, 30 January 2014 (UTC)

• Rose, in response to your comment above, I agree that some of the "issue"s are too wordy and too long causing unneeded word-wrap. As such, I've BOLDly made a couple of edits to a couple of the issue templates themselves. I'd like to be able to see the wording of the BLP version of {{Undue}} trimmed down at least a little, but did not want to change that wording at all without some discussion first. Anyone that wants to give me a list of "issue" templates that are too wordy and have excessive word-wrap, I would be happy to continue trying to trim them a little to reduce the wrap issue. This will by default shorten the box. I still am opposed to collapsing all by default for everyone (although I could probably write a userscript for those that really want it) because I strongly believe that it will reduce participation in fixing the issues that caused the articles to be tagged in the first place. Technical 13 (talk) 14:49, 30 January 2014 (UTC)

I didn't say that the text was too long or too wordy. I said that there's a great big white area down the right-hand side of that screenshot, which is causing lateral compression and so forcing unnecessary word wrapping at Business cycle. If the white area could be eliminated, there would be more space. I believe that this is a user setting.

On my screen, the uncollapsed {{Multiple issues}} on Business cycle is 86px high; if {{Refimprove|date=June 2010}} and {{Undue|date=January 2011}} are not so wrapped, they're each 52px high for a total of 114px. Therefore, {{Multiple issues}} reduces the space occupied by these notices by 28px. --Redrose64 (talk) 15:50, 30 January 2014 (UTC)

I get the same behaviour when I'm logged in or not. The point is that collapsed gives reasonable behavior in all cases. It's also clear from the screenshot that the uncollapsed behavior very definitely does not. The layout should be sensible over the widest possible screen and font sizes; but it clearly isn't working well.

It's also highly questionable as to why the multiple issues box uses bullet points and separate lines for each of the issues, and why they are so verbose, you could potentially just have a single word or much shorter phrase, and hyperlink it for each issue.

These tags shouldn't be a punishment to the reader for daring to open a page in Wikipedia! It seems to me that that's exactly how it's being looked at; you're apparently trying to punish the users into editing the page.GliderMaven (talk) 23:58, 30 January 2014 (UTC)

GliderMaven, considering that Rose and I get the same numbers for box heights (and I get the same number son two totally different machines; one a PC with Win7 home using Firefox 26 and the other a laptop with Win Vista using Opera 12), it is obviously an issue on your end. There is no consensus to collapse this template by default, and a page with only two issues on it shouldn't be forced collapsed either, especially since I've gone through the two specific issue tags on that page and shortened them so there would be no word wrapping. Let me ask you a question, are you viewing that page on a computer (what size screen), tablet, or mobile device in desktop mode? Perhaps some code can be added to the template for people with especially narrow displays so that the template renders, but collapses itself after 3-5 seconds. Technical 13 (talk) 00:08, 31 January 2014 (UTC)

I don't get that big white space, and it's obviously the cause of this problem, so I've left a note at WP:VPT#Wasted space on right-hand side constraining width. --Redrose64 (talk) 09:56, 31 January 2014 (UTC)

How do I use "|section=y"?

So I am trying to use the Multiple Issues tag in to hopefully consolidate the multiple tags scattered in the Graphene article over different sections due to over-zealous drive-by tagging. Such drive-by tagging is why many of the issues in the article have gone on unresolved and the quality of article has deteriorated to C rank since its nomination in 2011. However I need help, because I am not sure how to use this "|section=y" command. Could one of the experts of wikipedia help me? Physics16 (talk) 00:09, 3 March 2014 (UTC)

@Physics16: {{Multiple issues}} is used with |section=y when one section of an article has more than one maintenance template, such as Boomerang#Throwing technique. While the Graphene article has several maintenance templates, I don't see any section that has more than one, so I don't think using {{Multiple issues}} would be appropriate. Happy editing! GoingBatty (talk) 03:20, 3 March 2014 (UTC)

@GoingBatty: Thank you for your insight ^_^ Physics16 (talk) 21:17, 1 April 2014 (UTC)

Rewriting 'section' parameter for presence instead of boolean

I am a long-time fan of the template for articles, but after using it on a section of puppet state earlier, think it may be a little more efficient and intuitive for the 'section' parameter to work simply on presence, like with {{refimprove}}. Since it's always the penultimate parameter (and the templates are always templates and the ultimate parameter), I imagine it should be relatively straightforward. So essentially the used template for sections would be {{multiple issues | section | [templates]}} rather than {{multiple issues | section=y | [templates]}}. — Sasuke Sarutobi (talk) 11:30, 1 June 2014 (UTC)

Note: in {{multiple issues|section=y|{{refimprove}}}} parameters |section= and |1= are used. In {{multiple issues|section|{{refimprove}}}} "section" is not |section=, but |1=section, and {{refimprove}} is content of |2=, not |1=, so this change is not as straight forward as it may seem. It can be easily implemented with a couple of simple checks, but that would mandate the use of parser functions, which are expensive in terms of performance. — Dmitrij D. Czarkoff (talk•track) 14:42, 1 June 2014 (UTC)

Another way of putting it is that in the present syntax, {{multiple issues|section=y|{{refimprove}}}} and {{multiple issues|{{refimprove}}|section=y}} are exactly equivalent - since |section=y is a named parameter, its position is irrelevant. It therefore need not be the penultimate parameter - it works just as well as the ultimate parameter. By contrast, the list of templates must currently be placed in the first positional parameter, which may or may not be the ultimate parameter. --Redrose64 (talk) 16:59, 1 June 2014 (UTC)

Ah, so the current form is essentially positionally agnostic to whether it is a section parameter or a contained template, since the section parameter is specified and the template one isn't? If it's not practicable, don't worry about it; just a thought. — Sasuke Sarutobi (talk) 17:41, 1 June 2014 (UTC)

The unnamed parameter approach might seem simpler, but in fact the current approach is probably more robust and less likely to confuse. It's only two characters which are saved after all. The |section= could also be included empty on the documentation, and copy/pasted into an article so that "y" can be inserted. — Martin (MSGJ · talk) 19:40, 1 June 2014 (UTC)

Template-protected edit request on 1 July 2014

Hi there, I am the Managing Editor in the Marketing and Advancement department at Victoria University in Melbourne, Australia. I have been given the task of updating the University's entry (Victoria_University,_Australia). Someone has added a list of 'issues' at the top of the entry, and I want to delete this list as part of the copy update but do not know how. Any guidance would be much appreciated. Below is the 'issues' copy I would like to delete:

This article has multiple issues. Please help improve it or discuss these issues on the talk page. 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. (November 2013) This article relies largely or entirely upon a single source. Relevant discussion may be found on the talk page. Please help improve this article by introducing citations to additional sources. (November 2013) This article appears to be written like an advertisement. Please help improve it by rewriting promotional content from a neutral point of view and removing any inappropriate external links. (November 2013)

Thank you

140.159.2.245 (talk) 08:12, 1 July 2014 (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. The article's talk page is Talk:Victoria University, Australia.

Since you state "I am the Managing Editor in the Marketing and Advancement department at Victoria University in Melbourne, Australia", it's likely that you have a conflict of interest, and so should refrain from editing the article. This does not prevent you from posting comments at its talk page, however.

Considering your primary question: if you click the "Edit" tab at the top of the page, you will see that at the very top of the editing box is the line

{{Multiple issues |one source = November 2013 |refimprove = November 2013 |advert = November 2013}}

That is the line which produces those messages, and so is the line that should be removed in order to remove the messages. But before doing that, you should not just consider the conflict of interest, but also consider whether any of the listed issues still apply: if there is any doubt, it's best to discuss on the article's talk page. --Redrose64 (talk) 10:23, 1 July 2014 (UTC)

Template move request

This template should be moved/renamed to something similar to "There are problems with this page", for reasons of clarity and common sense. To highlight but one aspect of the growing use of the word issues to refer to what used to be called problems, it degrades the word's unique meaning, which Merriam-Webster defines simply as "something that people are talking about, thinking about, etc.: an important subject or topic". For instance, "The economy", "The weather", and "What is up with Donald Trump's hair?" can all be issues, and we do not have another word that expresses the same meaning quite so well; to dilute its meaning for the sake of euphemism merely obliges us to find another word to replace it. According to Wikipedia's five pillars, the site exists to "characterize information and issues"; therefore, to say that a given page "has issues" is somewhat meaningless.

The sense of issue as "a point to be decided", such as the issue of whether to wear a yellow shirt or a blue shirt, for example, dates from the early 1800s. In this usual sense, not all issues imply that there are deficiencies or things in need of remediation. But this Wikipedia template does identify a need for improvements to a page, not just a general discussion or a selection between equally valid alternatives. In this context, the word problems is the most concise and unambiguous term.

There seems to be a growing belief that to simply call something a problem somehow evinces negativity, which is itself viewed as a problem. Issue is therefore often selected as a less offensive term. However, this is to place a subjective judgement or feeling ahead of clarity of meaning; in this context, "issues" is simply a euphemism and does not enhance the reader's understanding.

Coconutporkpie (talk) 02:24, 31 October 2014 (UTC)

References

Requested move 31 December 2014

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review. No further edits should be made to this section.

The result of the move request was: page not moved Arbitrarily0 ^(talk) 04:14, 9 January 2015 (UTC)

---

Template:Multiple issues → Template:Multiple problems –

• WP:EUPHEMISM: 'Some words that are proper in many contexts also have euphemistic senses that should be avoided: do not use issue for problem or dispute.'
• WP:COMMONALITY: 'Universally used terms are often preferable to less widely distributed terms, especially in article titles.'

This template refers specifically to 'problems'. The word 'issues', on the other hand, very often refers to matters that are not 'problems' at all. Using 'issues' as a euphemism for 'problems' is a relatively recent phenomenon, especially in the United States, and has the potential to cause confusion or annoyance, particularly for foreign readers (see here, for example). Whilst the word 'issue' sometimes works for some people, we should use the term that is clear and unambiguous to all. 86.170.130.156 (talk) 03:12, 31 December 2014 (UTC)

• Oppose. This isn't an encyclopedia article, so euphemism doesn't apply. As for commonality, the Cambridge dictionary defines an issue as "a subject or problem." -- Calidum 03:21, 31 December 2014 (UTC)

The definition cited is actually 'a subject or problem that people are thinking and talking about'. Would it make sense for the template to say 'This article has multiple subjects that people are thinking about'? Or should it say (using the same dictionary's definition for 'problem') 'This article has multiple subjects that need attention and need to be dealt with'? This is a subtle, but important, difference between problem and issue (essentially, that 'problems' are 'issues' that need a solution, whilst 'issues' are very vague topics of discussion). Of course, many ignore this and use 'issue' to mean the same as 'problem', but very many do not. 86.170.130.156 (talk) 03:28, 31 December 2014 (UTC)

No offense, but this is really a solution in search of an issue. I'm not sure anyone has had any issue with the current wording of the template until you brought it up. There is no good cause to move it. -- Calidum 03:43, 31 December 2014 (UTC)

No offense taken. It is something that has troubled me whenever I have seen it used on articles, especially being someone who has grown up being taught not to use issues in this way. I am surprised because Wikipedia is usually good at spotting these types of things. The very previous comment was from a dissatisfied user. Here is a list of comments I have found from a quick search: 86.170.130.156 (talk) 03:46, 31 December 2014 (UTC)

• http://en.wikipedia.org/wiki/Template_talk:Multiple_issues#Template_move_request
• http://en.wikipedia.org/wiki/Template_talk:Multiple_issues/Archive_11#Multiple_problems
• http://en.wikipedia.org/wiki/Template_talk:Multiple_issues/Archive_10#Problems
• http://en.wikipedia.org/wiki/Template_talk:Multiple_issues/Archive_6#Word_.22issues.22_could_be_improved_.28.22problems.22.29
• http://en.wikipedia.org/wiki/Template_talk:Multiple_issues/Archive_4#Saying_issues_when_we_mean_problems

• Weak oppose. I understand where the nominator is coming from, but the euphemism actually has value here; it removes a potential moral obstacle to using the template appropriately, since the tagger isn't accusing the article of having anything more serious than "issues". Since the template name is rarely rad directly, mealy-mouthedness isn't a big issue. I'd suggest that the proposed title is a perfectly acceptable template redirect, however, for those who have no issue with calling a problem a problem. 209.211.131.181 (talk) 05:25, 31 December 2014 (UTC)

• Strong oppose. Template name is well-established, it's not visible on pages, no need to change names. -- Magioladitis (talk) 12:03, 31 December 2014 (UTC)

• Oppose. Usage of "issues" does present a scholarly dilemma and yet is far better than "problems". I was brought up to avoid the use of "problem" and replace it with "challenge". Hmm, "Multiple challenges"?... Nah! – Paine Ellsworth ^CLIMAX! 23:44, 31 December 2014 (UTC)
• Oppose. I'm afraid of the potential for such a change to cause technical "issues" for no good reason. Feel free to suggest changes in the wording of the message that is actually displayed to readers. Wbm1058 (talk) 23:49, 31 December 2014 (UTC)
• SNOW oppose: Out of 6,823,056 on the English Wikipedia, less than 22% of them are not redirects or DAB pages. This template is used on 8% of the remaining 1,534,204 articles. Moving this template for any reason would cause a massive technical debt and tie up the job queue for months and months on end if it didn't lock up the servers all together (kind of like deleting the main page would and has). On top of that, this template is relied upon at its current name by both Twinkle and AWB. — {{U|Technical 13}} ^{(e • t • c)} 00:41, 1 January 2015 (UTC)
• Oppose per WP:SNOW. I agree with User:Technical 13. It would cause pandemonium in Wikipedia's servers. Pages would shatter apart. Lists would be blanked entirely. Formatting error messages would litter the streets of mainspacelandia. Every category would start an deletion discussion. Editors would be confused and make countless errors. Robots assigned to clean up the articles would make mistakes and ruin Wikipedia beyond control. No one would be able to help articles with multiple issues. I'm not being sarcastic. It would suck. It would take a long time to make Wikipeia normal again. And at what cost? Your two articles that you used in your argument are not that proving per other editors arguments in this section. EMachine03 (talk) 23:20, 1 January 2015 (UTC)

---

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.