Jump to content

Template talk:Reflist: Difference between revisions

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Content deleted Content added
Line 122: Line 122:
*+1 on this, regards <span class="vcard"><span class="fn">[[User:Widefox|Widefox]]</span>; [[User talk:Widefox|talk]]</span> 20:45, 10 July 2017 (UTC)
*+1 on this, regards <span class="vcard"><span class="fn">[[User:Widefox|Widefox]]</span>; [[User talk:Widefox|talk]]</span> 20:45, 10 July 2017 (UTC)
:::::This is genius.— [[User:TAnthony|TAnthony]]<sup>[[User Talk:TAnthony|Talk]]</sup> 17:44, 12 July 2017 (UTC)
:::::This is genius.— [[User:TAnthony|TAnthony]]<sup>[[User Talk:TAnthony|Talk]]</sup> 17:44, 12 July 2017 (UTC)
*Dito, ditto, ditto. I'm ''shocked'' that something this sensible and useful didn't meet with kamikaze-like opposition. '''[[User:EEng#s|<font color="red">E</font>]][[User talk:EEng#s|<font color="blue">Eng</font>]]''' 21:08, 12 July 2017 (UTC)

Revision as of 21:08, 12 July 2017


Not expanding

Hello. During a citation fixing session, I noticed that at the cities and towns during the Syrian Civil War article, the template does not seem to expand. A quick look shows that there are references in the article, however. Perhaps that there's a limit the article exceeds? There are duplicate reference tags there, but without the expansion and red warnings, it's difficult to track and fix. Thanks, PaleoNeonate (talk) 10:48, 1 April 2017 (UTC)[reply]

There are too many templates in that article. Here is the NewPP limit report (you can find this report by viewing the article's page source – it's located toward the bottom), specifically see Post-expand include size:
NewPP limit report
Parsed by mw1214
Cached time: 20170401103943
Cache expiry: 2592000
Dynamic content: false
CPU time usage: 10.720 seconds
Real time usage: 11.615 seconds
Preprocessor visited node count: 42191/1000000
Preprocessor generated node count: 0/1500000
Post‐expand include size: 2097152/2097152 bytes
Template argument size: 32920/2097152 bytes
Highest expansion depth: 12/40
Expensive parser function count: 13/500
Lua time usage: 2.612/10.000 seconds
Lua memory usage: 24.66 MB/50 MB


Transclusion expansion time report (%,ms,calls,template)
100.00% 3821.148      1 -total
 51.37% 1962.793      1 Template:Reflist
 19.27%  736.188    178 Template:Cite_news
 18.26%  697.735    170 Template:Cite_web
 11.98%  457.942     46 Template:Fix
 11.55%  441.430     33 Template:Citation_needed
  7.68%  293.536     34 Template:Delink
  6.19%  236.667    262 Template:Anchor
  3.72%  141.995     92 Template:Category_handler
  2.29%   87.356      1 Template:Syrian_Civil_War
Not the fault of {{reflist}}. The way forward is to address the issue at the article's talk page; consider splitting it into multiple smaller articles, substing some of the templates, etc.
Trappist the monk (talk) 11:06, 1 April 2017 (UTC)[reply]
That's great to know, thank you very much for the details. PaleoNeonate (talk) 11:45, 1 April 2017 (UTC)[reply]
@Trappist the monk: is there a category or template I should use to tag this page appropriately? I've looked at various categories and templates without necessarily finding the most appropriate one (i.e. in this case, a technical limitations reason for needing a split), that I don't really see at Wikipedia:Template_messages/Splitting. Perhaps that ultimately, what would be even better would be like for redundant citation tags, for the system to automatically add the article to a category when templates cannnot expand in reasonable time/space. Or is this already done, and I don't have to do anything? Thanks again, PaleoNeonate (talk) 06:45, 2 April 2017 (UTC)[reply]
The page is already a member of Category:Pages where template include size is exceeded.
Trappist the monk (talk) 10:14, 2 April 2017 (UTC)[reply]
Super, thanks again. I added a manual warning at the top of the page before posting the above question, I'm not sure if it was a good approach. I'll leave other editors reverse it if not, as the talk page was warned anyway. PaleoNeonate (talk) 10:42, 2 April 2017 (UTC)[reply]
I'm having the same problem on List of Australian treaties once I expanded the citations using refill with cite web. I have now turned off the cite web and it works. The page does not use many templates. The list is very large, and there are pros and cons with breaking it up (it is still work in progress), however, would be good if the template could handle it... gives us more options. Perhaps it is a problem with cite web? Thanks. Really appreciate your tireless work on this template.Supcmd (talk) 20:23, 15 April 2017 (UTC)[reply]
This is not the fault of {{reflist}} nor is it the fault of {{cite web}}; both templates are working as they should do. The problem occured because when you expanded the citations using refill, the size of the expansion exceeded the two megabyte limit that is enforced by MediaWiki. The list is too long. Fix that, and the problem is resolved. For more information, see WP:TLIMIT.
Trappist the monk (talk) 20:43, 15 April 2017 (UTC)[reply]

Number of columns in other reference templates

Does the consensus to deprecate fixing the number of columns for this template also extend to other reference templates such as {{reflist-talk}} or {{refbegin}}? The former may not ever be a real issue, but the later was just done here and I'm wondering if that needs to be tweaked for the same reasons. Template:Refbegin#Option 2: Multiple columns makes no mention of this. -- Marchjuly (talk) 02:33, 22 April 2017 (UTC)[reply]

@Marchjuly: Yes. The thing is, once you have more than one column, you have no idea exactly how many columns are most suitable for the situation, since you do not know how wide anybody else's screen is. Somebody using an iPhone or Andriod, with a screen three inches wide (or less), may find that even two columns is one too many. So by setting a minimum width for the columns, we give the browser the freedom to choose an appropriate number of columns - which might be just one. --Redrose64 🌹 (talk) 09:21, 22 April 2017 (UTC)[reply]
Thanks for the clarification Redrose64. It might be a good idea then to add something about this to those other template pages. -- Marchjuly (talk) 10:46, 22 April 2017 (UTC)[reply]

Layout issues with Portal template

Of interest may be Special:Permalink/782767419#Layout issues. I am wondering if it would make sense for {{reflist}} to include the equivalent of an implicit {{clear}} as prologue. Thanks, — PaleoNeonate — 01:52, 29 May 2017 (UTC)[reply]

Looking at this version of the Anna Nicole Smith article, you can see how the {{Portal bar}}, a floating element, extends into the References section. The {{Reflist}} template is a <div>...</div>, so it could incorporate style="clear:both;" to ensure that it begins below the Portal bar. Unfortunately, that would create a whitespace gap between the References heading and the start of the references, because the clear won't be applied to the heading. I think most readers would find that far worse than the issue as seen in that version of the Anna Nicole Smith article.
For that reason, I don't think that setting this template to style="clear:both;" would represent a solution. The style needs to be applied to an element placed at the bottom of {{Portal bar}} for it to have the desired effect. --RexxS (talk) 19:14, 29 May 2017 (UTC)[reply]
Thanks for your comment. This probably means that both my reverted edit, or this more recent one from another editor (moving the See also section), were the proper means to correct this? On the other hand a test edit placing {{clear}} just before {{reflist}} did look fine to me (I have no diff to this one as I had only previewed it). — PaleoNeonate — 20:38, 29 May 2017 (UTC)[reply]
You can actually edit this old version of Anna Nicole Smith (edit the whole page), and preview to see how it looks. Obviously, don't save. You can see how placing {{clear}} immediately before {{reflist}} creates a gap between the References heading and the references – imagine how it would look if there were more portals in the {{Portal}} bar. On the other hand, try placing {{clear}} just before the ==References==, which would be the preferred solution in general. Of course, moving the {{Portal}} bar into the External links section works nicely as well, as long as that section exists. --RexxS (talk) 21:49, 29 May 2017 (UTC)[reply]
I don't see the gap you are refering to personally, if adding {{clear}} just before {{reflist}} (after the section header), maybe that it is only obvious at certain resolutions. However, you are confirming that I can keep adding an explicit {{clear}} before the References section header where that is needed (as I used to do in these cases, although my attempt was reverted his time). So I'll simply keep doing that when needed and there's no better place to move the Portal template to. Thanks again, — PaleoNeonate — 02:01, 30 May 2017 (UTC)[reply]

Suppress groupname function

I'm developing a very long article and because there will be a load of references (literally hundreds) I would like to split them into groups based on major sections, a bit like the way a lot of historical book authors have their in-line references listed per chapter at the back rather than as one one long cumbersome list. I think it would be better for the article to have the references divided this way than a very long monotonous numbered list. However, I tested this by adding a group name to every <ref> tag (I'm not using reference templates as this causes a lot of overhead when parsing) and I notice the names are shown in the article body as [name 1][name 2] etc. It adds a lot of unnecessary bulk and is not very appealing. Is there a way, or can a way be incorporated, so that the groupname can be manually suppressed within the article by some argument in the reflist template, such as {{reflist|group="example"|grouphide="yes"}} so that you wouldn't get [example 1] as a citation link, just a standard [1] since the html for the link should still be able to function with or without the groupname actual being visible. By doing this I hope to demonstrate that lengthy articles with a lot of references can be customised to be more navigationable, but as it stands, by always displaying the group name in the article it can't be done at present without making the article look clunky. — Marcus(talk) 17:15, 31 May 2017 (UTC)[reply]

Can you (try to) take advantage of WP:CITESHORT? That seems like a better start. --Izno (talk) 18:20, 31 May 2017 (UTC)[reply]
I already do; I don't use any other way. There's still going to be hundreds of pages referenced throughout the article, which is why I want to group them more selectively. — Marcus(talk) 18:44, 31 May 2017 (UTC)[reply]
Could using the existing predefined groups work? There are not many of them, but these will show up with a small symbol: lower-alpha, upper-alpha, lower-roman, upper-roman, lower-greek (see Template:efn for the list); although alpha references are usually used for text notes, they can also serve for references... — PaleoNeonate — 19:01, 31 May 2017 (UTC)[reply]
No, there's not enough of those groups, as you say, and I want to avoid using reference templates as the wiki parser has a limit how many templates it can parse before the page fails to render; I'm reserving that for other things like tables and other display templates. Don't know if I'll reach that limit but it's a real potential. — Marcus(talk) 19:18, 31 May 2017 (UTC)[reply]
See this Notes section to see how I've grouped refs from sections, but then go up into the article text and see how daft it looks with the group name showing against every citation. If this could be supressed and leave just the [numbers] it would look good. — Marcus(talk) 20:36, 31 May 2017 (UTC)[reply]
That is quite an impressive work. I actually don't mind seeing the group names when looking at it, but I admit that it is uncommon. I was next to suggest possibly splitting the article, but I also see that there are main article links under sections already. Yet another possibility would be to name groups after letters (resulting in i.e. [e 1], but I don't really think that would be necessary... Since the notes are not much longer than the links, another possibility would be archaic inline harvard-style with brackets (also uncommon on Wikipedia now, I'm not sure if it's a good idea)... —PaleoNeonate· 21:34, 31 May 2017 (UTC)[reply]
It's got a long way to go. I'm only upto 1799 and have to reach 1815... so there are far more references, yet to come. Which is why I don't want a continuous reference section, rather a broken down one that makes it more academically formatted. That's why I'd have thought the group name argument which already exists in the template could be expanded so that it could be hidden. — Marcus(talk) 22:16, 31 May 2017 (UTC)[reply]
Wikipedia articles are still printed out quite often. Suppressing the groupname would make it impossible to ascertain which reference supported which piece of text. --RexxS (talk) 21:57, 31 May 2017 (UTC)[reply]
Well, it wouldn't, because I've listed them under the titles to match the sections, so the ref numbers would match [1] to [1] [2] to [2] [3] to [3], etc ... as I said originally, a lot of history texts do that by chapter. Also, it should be possible to make a template hidden on-screen but not in print... since they are two different mediums. e.g. Template:Print version — Marcus(talk) 22:16, 31 May 2017 (UTC)[reply]
Leaving the references to line up by trying to synchronise the section title to the sub-heading of the references section is incredibly fragile, as it assumes all subsequent editors will maintain the structure and labelling of the sections. History texts can do that because they are fixed, i.e. printed, and not susceptible to being modified indefinitely, as Wikipedia articles are. Yes, I know it's possible to change the display between the printed version and the screen version of an article, but I wanted you to understand that's another complication that would have to be dealt with by the developer who attempts to implement your request. --RexxS (talk) 22:44, 31 May 2017 (UTC)[reply]
Well, the only other though I had in mind was a whole new reflist template function which has a section number argument, e.g. {{reflist|section=2}} and only the ref tags in that section would be displayed for that template but wouldn't need any additional in-tag arguments, since every heading generates a section number automatically, it might be possible to generate references from a specific section or sections. That would make the matter less complicated for future editors or a long article, though it would still need some attention to maintain – but I believe in quality, and that some of the extremely long articles on Wiki, say like WW1 or WW2 that attempt to summarise a long and very important area of history, need special attention to keep them focused and prevent them becoming a mess, as often happens with long articles once a few dozen editors have pitched in here and there with scrappy additions that don't attempt to keep the whole together and presentational. Rather than act as a deterant, I would suggest that more complex formatting encourages more productive editing instead of drive-by nit-picking tweaks which achieve very little overall. — Marcus(talk) 23:03, 31 May 2017 (UTC)[reply]

Using <references responsive/> to manage number of columns

We have begun getting MediaWiki's new reference column manager in use, with edits replacing {{reflist}} as in this edit. The responsive parameter automatically displays columns depending on the width of the viewer's screen. mw:Contributors/Projects/Columns for references recommends changing local templates such as reflist to take advantage of this feature. Can we do this? StarryGrandma (talk) 16:36, 23 June 2017 (UTC)[reply]

We began some time ago. I implemented a version in Template:Reflist/sandbox3 on 17 March 2017, (as well as an earlier version in Template:Reflist/sandbox2 to deal with the deprecated |2 and |3 parameters). Unfortunately, or perhaps fortunately, I'm not trusted to update Template:Reflist, and nobody who has the permissions to do so has shown any interest in implementing any of the sandbox versions I provided. The discussion therefore tailed off (as usual) and it got archived into Template talk:Reflist/Archive 29 where you can see what was discussed and demonstrated. So the answer to your question is "Yes we can do this" ("but we'd rather debate the niceties than actually implement a solution"). --RexxS (talk) 20:58, 23 June 2017 (UTC)[reply]
@StarryGrandma: We need to be a bit careful with this, because of how widely this template is used. I figure we should start small, and I converted the sandbox version, to use the automatic responsive mode (use columns if using more than 10 references) when no columns have been specified. This also should give this template a defined setting for the responsive option, and then maybe we can later switch the default for when responsive option is unspecified. That would be beneficial, for the cases where no reflist template is being used. I'm willing to take this stuff forward. —TheDJ (talkcontribs) 20:59, 23 June 2017 (UTC)[reply]
I've been experimenting with {{Reflist/sandbox2}} and {{Reflist/sandbox3}}. What about creating a "reflistR" template to get some experience with it on a small scale? It could be used instead of <references responsive />. The issue with such a template has two parts: 1) Adding automagically wrapping. 2) Removing features such as specifying number of columns and width of columns. Editors have been doing bulk edits replacing number of columns with column width in recent years, so that seems to be going away. I would be opposed to not letting editors specify column width however. 20em, for example, is very useful for shortened footnotes and would cause quite a stir if it went away. "responsive" seems to have chosen a single column width a bit wider than our standard 30em or 32 em. Has there been any talk on the WikiMedia side about allowing the user to specify column width for "responsive"? StarryGrandma (talk) 16:27, 24 June 2017 (UTC)[reply]
@StarryGrandma: Removing fixed columns seems to be pretty uncontroversial, and can easily be done using the work of RexxS. I think that would be reasonably uncontroversial by now (as having been deprecated for some time now). Adding width specification however is something that is a bit more way out (which is why I implemented my sandbox changes the way that I did). There is some discussion on that topic in phab:T160498, but I don't think we should wait for that, it can still take quite some time. Incremental steps are good, let's not try to solve every problem at once. —TheDJ (talkcontribs) 12:43, 27 June 2017 (UTC)[reply]

I've added a limited version of RexxS changes (without narrow and wide keywords) to the the primary sandbox. I've removed the narrow and wide keywords, as I felt that we had not seen enough discussion on that front to truly determine if that was going to be useful and uncontroversial. Results can be evaluated on Template:Reflist/testcases. Feedback welcome. —TheDJ (talkcontribs) 13:21, 27 June 2017 (UTC)[reply]

ping RexxS. I'd love your feedback. —TheDJ (talkcontribs) 14:26, 3 July 2017 (UTC)[reply]
Apologies, TheDJ, I've intended to look through it and leave you some feedback, but Mike Peel has been keeping me busy with Lua/Wikidata for the last few days. Anyway, it seems to me that your sandbox code does just what we wanted: it picks up all the deprecated |2, |3, etc. and gives them sensible column-widths; it turns on responsive when there are no parameters (and I believe you can still force non-responsive by using |1). Colwidth, the groups and lower-alphas, etc, all seem to work as expected. I agree about the narrow and wide keywords, but I originally wrote the code anyway so that it would be easy enough to re-instate them if consensus were established. If nobody else comments and objects in the next day or so, I'd recommend that you go ahead and update the main template from the sandbox. I'll look out for the change and try to catch any issues after deployment if you don't get there first. Nice work! --RexxS (talk) 16:00, 3 July 2017 (UTC)[reply]
I have just deployed this. —TheDJ (talkcontribs) 08:04, 8 July 2017 (UTC)[reply]
@TheDJ: I just noticed that it's working and came here to search. Sort of a dream come true for me, haha. Reflist|2 now displays 3 columns and it was sorta weird to me, heh. So what now? Is there going to be a bot to remove all instances of reflist|2, 3 and 4? --Jennica / talk 19:00, 8 July 2017 (UTC)[reply]
I noticed this doesn't work with <references /> or <references/>. Not sure if anybody is aware.--Jennica / talk 07:01, 9 July 2017 (UTC)[reply]
It does if you use <references responsive /> or <references responsive=1 />. That's the point of this thread - the new responsive attribute needs to be present, but not as responsive=0. --Redrose64 🌹 (talk) 08:00, 9 July 2017 (UTC)[reply]

So is reflist going to be phased out and replaced with this down the road? Why not just change <references /> to reflist since it will display columns that way? Sorry for all the questions. --Jennica / talk 11:45, 9 July 2017 (UTC)[reply]

Because {{reflist} is just a complicate wrapper around <references />, with additional features (variable column width, alternate list styles etc). We also want to switch the default for <references /> to have columns, but that required doing this work first, because the two column systems are not compatible, so we need to have it disabled here first. —TheDJ (talkcontribs) 13:43, 9 July 2017 (UTC)[reply]

Just came across this, well, for lack of a better word, awe - some! upgrade while editing an article (did a double take on a Reflist template with no params and a two-column display). Thank you all beyond words!  Paine Ellsworth  put'r there  14:36, 10 July 2017 (UTC)[reply]

Thie is excellent, elegant ... but the documentation needs updating! — Stanning (talk) 14:47, 10 July 2017 (UTC)[reply]
Was wondering myself if the new default is 25 or 30em?  Paine Ellsworth  put'r there  15:05, 10 July 2017 (UTC)[reply]
Automatic columns uses 30em (and only works if you don't specify an explicit width). I've update the documentation a bit to reflect this. The long term plan is to make it possible to also have automatic column mode be able to handle other column sizes, but for now, we fallback to our previous behaviour, of creating columns regardless of the amount of references. —TheDJ (talkcontribs) 15:31, 10 July 2017 (UTC)[reply]
30em is a good default. Probably that automatic arbitrary column sizes are mostly unnecessary, except perhaps for 20em which is very useful when most footnotes are short (i.e. for sfn/harvnb), or no columns at all if the notes are really long (i.e. can occur with efn/non-source notes)... And thanks for working on this. —PaleoNeonate - 16:00, 10 July 2017 (UTC)[reply]
This is genius.— TAnthonyTalk 17:44, 12 July 2017 (UTC)[reply]