Jump to content

Template talk:Reflist/Archive 32

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 25←Archive 30Archive 31Archive 32Archive 33Archive 34

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)

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)
@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 (talk • contribs) 20:59, 23 June 2017 (UTC)
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)
@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 (talk • contribs) 12:43, 27 June 2017 (UTC)

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 (talk • contribs) 13:21, 27 June 2017 (UTC)

ping RexxS. I'd love your feedback. —TheDJ (talk • contribs) 14:26, 3 July 2017 (UTC)
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)
I have just deployed this. —TheDJ (talk • contribs) 08:04, 8 July 2017 (UTC)
@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)
I noticed this doesn't work with <references /> or <references/>. Not sure if anybody is aware.--Jennica✿ / talk 07:01, 9 July 2017 (UTC)
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)

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)

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 (talk • contribs) 13:43, 9 July 2017 (UTC)

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)

Thie is excellent, elegant ... but the documentation needs updating! — Stanning (talk) 14:47, 10 July 2017 (UTC)
Was wondering myself if the new default is 25 or 30em?  Paine Ellsworth  put'r there  15:05, 10 July 2017 (UTC)
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 (talk • contribs) 15:31, 10 July 2017 (UTC)
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)
@TheDJ: phab:T160497 changes it to default to 25em to sync with mobile, presumably to-be-deployed Soon. --Izno (talk) 21:32, 12 July 2017 (UTC)
With a 25em default, hell may break loose! —PaleoNeonate - 21:57, 12 July 2017 (UTC)
Hopefully not that much. 25em still displays 3 columns on my screen. 20em does 4. --Jennica✿ / talk 22:06, 12 July 2017 (UTC)
25em is only for mobile. That ticket still had an older description, which made it kind of confusing. —TheDJ (talk • contribs) 22:29, 12 July 2017 (UTC)
  • @TheDJ: Hi, I'm noticing some unsightliness on this page. What is recommended in such situations? Thanks.--Cpt.a.haddock (talk) (please ping when replying) 11:52, 14 July 2017 (UTC)
    Avoid using <blockquote> for quotations in references. It really doesn't apply. --Izno (talk) 12:31, 14 July 2017 (UTC)
    @Izno: Removing the quote tag hasn't really helped. Besides, is there a rule in the manual of style somewhere that states that footnotes should not use the quote template? It's quite possible that there are a number of other articles that do the same thing. (And it's curious that talk pages have an inline quote template but articles do not.)--Cpt.a.haddock (talk) (please ping when replying) 13:54, 14 July 2017 (UTC)
    @Cpt.a.haddock: Blockquotes are for long quotes--which are typically defined using paper media (your standard 8.5 in × 11 in) as 3-4 lines or greater in length after (before?) indenting to indicate a blockquote. Our MOS at WP:Blockquote indicates 40 words or greater. A single sentence is not a blockquote. If you're quoting that much in a citation, you've also probably missed the point of a citation (which is to identify where your information is presented, not the information itself). I can guarantee there are other uses of blockquotes as I've fixed others. I don't know what you mean by "talk pages have an inline quote template but articles do not". --Izno (talk) 15:37, 14 July 2017 (UTC)
Well, I do know what he meant by talk pages have an inline quote template but articles do not. EEng 18:03, 14 July 2017 (UTC)
Yes, that's what I meant :) Anyhow, that's a discussion for elsewhere. Thanks.--Cpt.a.haddock (talk) (please ping when replying) 18:27, 14 July 2017 (UTC)
  • Anyway, the display issue in the article is now due to how long the quote is (without the blockquote formatting). There is essentially no way to get around this without removing or lessening the length of the quotation, because of how browsers work. You'll either need to specify a width to the columns you want using a {{reflist}} rather than <references> tag, add more citations (and content) to "balance" the citation content, or accept the display as-is. --Izno (talk) 15:40, 14 July 2017 (UTC)
@Izno: Thank you. I treat citations on WP the same way as I treat footnotes in books. Footnotes in print can run across many pages. But I see that there's a {{efn}} alternative that might be more suitable for that. While a word count for blockquotes makes sense, I'm not sure that having a requirement of x lines does. In any event, my issue appears to be resolved. Thanks :)--Cpt.a.haddock (talk) (please ping when replying) 17:38, 14 July 2017 (UTC)
Considering that this is not only a quote, but also a note ("Assuming that the total strength ..."), {{efn}} could be used for this one and a Notes section with a {{notelist}} would allow to isolate that one outside of the shortened footnotes. —PaleoNeonate - 15:46, 14 July 2017 (UTC)
@PaleoNeonate: While I'd been aware of the existence of this option, I'd never actually seen it in action (which is unsurprising as it's only been used 36190 times). This is very neat. Thank you! And from the looks of it, {{notelist}} is not automagically responsive as of yet.--Cpt.a.haddock (talk) (please ping when replying) 17:38, 14 July 2017 (UTC)
You're welcome; {{notelist}} is the equivalent of {{reflist|group=lower-alpha}} and it defers to reflist, so I think that it is responsive, but that columns would only be used if there were enough notes to require them (I could be mistaken). —PaleoNeonate - 18:09, 14 July 2017 (UTC)
@PaleoNeonate: I can confirm that {{notelist}} is responsive too. It appears that you have to have greater than 10 items to trigger the multi-column feature which I didn't the last time I tried.--Cpt.a.haddock (talk) (please ping when replying) 18:35, 14 July 2017 (UTC)

Proposal to switch default for references element

Now that Reflist sets an explicit responsive setting, I have started a proposal to switch the default behaviour of <references /> to automatic column mode. —TheDJ (talk • contribs) 09:18, 13 July 2017 (UTC)

The village pump discussion about modifying <references /> into columns is still ongoing. I invite you to comment there. --George Ho (talk) 09:53, 14 August 2017 (UTC)

Default number of columns

AFAICT This edit (Revision as of 08:03, 8 July 2017) by user:TheDJ made a fundamental change in the default format of this template. Previous to this edit if no width parameter was given then the number of columns was set to one, now it is set to 25em and while that is desirable for some formats (such as short citations that only contain, one author, year and page number it is not a desired format for full citations.

So I am going to remove set the default back to what it has been for years (one column), and if a change to multi columns is to be made it needs to be done through the consensus to change as shown throught a well attended RfC. @user:TheDJ if you initiate such an RfC please let me know by leaving a message on my talk page. -- PBS (talk) 11:46, 8 August 2017 (UTC)

It appears that you didn't understand what you did after all. The changes you made in these edits are only changing the behavior of the template in case of a specified number of columns where that number is greater than 2 (i.e. {{reflist|3}}, {{reflist|4}}, and so on). Your edits have no effect on what you're apparently complaining about here, which are the changes made per #Using .3Creferences responsive/> to manage number of columns and the in-progress Wikipedia:Village pump (proposals)#Automatic column mode for references element. Please, PBS, don't fool around with live edits to heavily-used templates. At the very least use a sandbox to check your edits before making them. Anomie⚔ 12:10, 8 August 2017 (UTC)
Regardless, DJ's edit had consensus on this talk page. Your edit was completely unwarranted without further discussion. --Izno (talk) 12:20, 8 August 2017 (UTC)
@Izno This is a very widely used template, consensus among a few editors who watch this talk page is not a broad consensus. Until there is a broad consensus, there is not consensus for such a large change (defaulting to multicolumn instead of one). Besides if you follow my argument below you will see that the current behaviour is probably a bug/error in the coding.
@Anomie The fix I put in place fixed my problem, but I had not considered the issue of an editor putting in more than two columns (as I have never seen it), and I have edited thousands of different pages. However on looking at the issue further I think that there is a bug in the following code. here is the snippet
  • {{#tag:references|{{{refs|}}}|group={{{group|}}}|responsive={{#if:{{{1|}}}{{{colwidth|}}}|0|1}}}}
The issue is {{{1|}}} see mw:Help:Parser functions in templates, so that test needs to be changed to {{{1}}}
  • {{#tag:references|{{{refs|}}}|group={{{group|}}}|responsive={{#if:{{{1}}}{{{colwidth|}}}|0|1}}}}
at the moment if {{reflist}} is called like that, it defaults the width to 25em rather than usual default of behaving like {{reflist|1}}.
- PBS (talk) 13:56, 8 August 2017 (UTC)
The effects of this change have now been seen widely. If there had been opposition, we can be sure it would have been voiced. When I noticed it, I agreed, but didn't register my support formally here. For the record, I now do. -- Michael Bednarek (talk) 14:05, 8 August 2017 (UTC)
I can't see how the "fix" you tried to put in place actually fixed your issue, especially when you claim to have never considered someone specifying more than three columns. The bit of code you were messing with only takes effect in that situation. Your claim that the test needs to change to {{{1}}} is not correct either, the test is working as intended (just not as you'd like it). Also, BTW, the default width is 30em on the desktop site, not 25em.
Again, see #Using .3Creferences responsive/> to manage number of columns above where several people commented in support of the change after it was made a month ago. It might, maybe, have made sense to revert it when the change was made a month ago. At this point, after it has been live for some time and praised by several other editors, it's a bit late to try to do so. Anomie⚔ 19:36, 8 August 2017 (UTC)

I disagree with making width 30em or 25em or getting four columns if first parameter is set to 2. This means users wanted 2 columns. Only if number is greater than 5 or 10, then it might be ignored and set to 25em because there are no that much wide normal screens that would properly display 10 columns of references nor article with that much references that needs more than 5 or 10 columns. --Obsuser (talk) 04:52, 13 August 2017 (UTC)

Selecting a fixed number of columns had been deprecated a long time ago. Given the wide range of screen widths, this selection was never a good idea, and overriding it is a good thing. -- Michael Bednarek (talk) 09:37, 13 August 2017 (UTC)
I agree. —PaleoNeonate – 23:47, 13 August 2017 (UTC)
Streisand-effect collapse box
===EEng's faultless crystal ball===

I said, "I'm shocked that something this sensible and useful didn't meet with kamikaze-like opposition" [1], and sure enough PBS has come along to fulfill the prophecy! EEng 21:54, 8 August 2017 (UTC)

Guilty. Whilst we might not achieve full support for the usual tarring and feathering for doing something necessary and useful, would you prefer the Welsh not or the sambenito? Andy Dingley (talk) 10:25, 14 August 2017 (UTC)

Having no columns has been the default since the project started, and I do not see a broad consensus for change. -- PBS (talk) 09:20, 15 August 2017 (UTC)

There seems to be a lot you don't see, such as how ensconcing criticism of oneself in a big green collapse box merely draws more attention to it. EEng 10:46, 15 August 2017 (UTC)
@PBS: did you follow the earlier discussion above which noted the recommendation at mw:Contributors/Projects/Columns for references? I believe we are merely falling in line here, not doing something controversial with this template.— TAnthonyTalk 14:51, 15 August 2017 (UTC)

Template size limit?

Is there a limit on the number of citations an article may use? The article List of 2017 albums seems to have hit a size limit. It currently has 1,284 citations. There are at least two articles with more citations, List of cult films with 1,610 citations, and List of Australian treaties with 2,136 citations, and both these article show all the references below, but 'List of 2017 albums' is currently showing Template:Reflist and no citations. When I make an edit and look at the preview, a warning is listed that states"Warning: Template include size is too large. Some templates will not be included." The article currently calls out the reflist by stating {{reflist|30em}}. If I change the call-out to {{reflist}}, the size warning is still there, but it will show all but the last three references. For those last three references, instead of the citation, it shows #invoke:citation/CS1.

Note: (To invoke the reflist template, the double '<' would be replaced with a double '{', but I cannot use the double '{' in the talk page without activating the template).

If there is a size limit for reference citations, can it be increased? If there is a size limit, why does 'List of cult films' manage to list 326 more citations without running into a listing error?

I think this is a problem for the programmers rather than administration, but I think this talk page is the appropriate place to raise the issue. I hope someone can help. Thank you. Mburrell (talk) 00:58, 28 August 2017 (UTC)

@Mburrell: This isn't an issue of this template really, but more of templates generally. See WP:TLIMIT. Nikkimaria (talk) 01:03, 28 August 2017 (UTC)
@Mburrell: I agree with Nikkimaria, it's a template limit problem. The article List of cult films contains a significant proportion of references that are bare urls, i.e. those particular references don't use citation templates, so that article falls short of hitting the limit on number of templates. Similarly, List of Australian treaties uses hardly any templates, so doesn't encounter the problem. If someone attempted to update those articles to use citation templates (to ease maintenance and help guard against WP:Linkrot), those articles would hit the same limit that you've encountered. HTH. --RexxS (talk) 02:10, 28 August 2017 (UTC)
Thanks for the responses. I suggested to my article users that we split up our article due to the template limitations. This looks like a constant rather than variable limit and I guess we just bounced into the limit ceiling. Thanks for pointing to the right definition page. Mburrell (talk) 05:30, 28 August 2017 (UTC)
@Mburrell: To name a template in a talk page without activating the template, use the {{tlx}} template. --Redrose64 🌹 (talk) 11:29, 28 August 2017 (UTC)

Not displaying at United States House of Representatives elections, 2018

At United States House of Representatives elections, 2018 the references aren't showing but it's not clear why. Timrollpickering 13:28, 20 December 2017 (UTC)

Not the fault of this template. That article uses too many templates and has exceeded the template include size. There is a red error message display when the page is previewed. A discussion at the article's talk page about how editors there can rework the article somehow to reduce the number of templates, to split the page, perhaps other solutions, is in order.
—Trappist the monk (talk) 13:51, 20 December 2017 (UTC)

HELP ME

I'm pullling my hair out why isnt it working https://simple.wikipedia.org/wiki/User:Hjk321/Advent_calendar — Preceding unsigned comment added by Hjk321 (talk • contribs) 17:53, 7 December 2017 (UTC)

@Hjk321: Hi, I fixed the error, you were just missing a slash ;) — TAnthonyTalk 17:59, 7 December 2017 (UTC)
@TAnthony: Thanks, I feel really stupid. Shame there's no syntax highlighting in that wikipedia...
@Hjk321:, please look at w:simple:Special:Preferences#mw-prefsection-betafeatures and consider testing the syntax highlighting feature. Whatamidoing (WMF) (talk) 18:38, 12 January 2018 (UTC)

Feedback requested at Template talk:Div col

There is a discussion at Template talk:Div col about changing the default from two columns to a specified width, as was previously discussed and implemented here. The talk page has only 38 watchers. Feedback from technical folks who lurk is welcome. – Jonesey95 (talk) 21:24, 12 January 2018 (UTC)

More specifically, Template talk:Div col#Default setting. --Redrose64 🌹 (talk) 00:31, 17 January 2018 (UTC)

Columns

Why does it seem like the default nr of columns has changed again? Now it's 4 in a lof of places and you can't even use the em form to change it if it would be better with more or less.

I have no idea what the point in any of this is. All it does is make people have to change their habits and everyone has to waste time and fix the old articles and implement the new changes. It's changed from 2 to 30em to whatever it is at the moment even though nothing seemd to be wrong with the previous ones. Now it's changed to being like 4 columns, why? Why aren't projects informed of these kinds of changed also? Few people I've met seem to have known that old standards have become outdated. It's making me pretty confused.★Trekker (talk) 10:54, 26 January 2018 (UTC)

@*Treker: Please give an example article where you see this problem. --Redrose64 🌹 (talk) 12:36, 26 January 2018 (UTC)
The article here has four columns now for example and I don't seem to be able to do anything about it despite trying to use the em format. The problem is also why this stuff changes without explanation and no one seems to get to find out about it beforehand.★Trekker (talk) 13:01, 26 January 2018 (UTC)
@*Treker: That has 2 columns on my monitor. This is the point of using "em"s--that different size monitors (and zoom levels/resolutions) will cause a different number of columns. Maybe you changed the zoom level or resolution on your computer? --Izno (talk) 13:30, 26 January 2018 (UTC)
(edit conflict) The "desktop" default is 30em which can be changed with a parameter; In this case, at a width I consider decent for reading (1024px) I see two columns, or four if extending the window to 1920px width (probably confirming what you see). Explicit column numbers are indeed deprecated (with different behaviors, documented at {{Reflist}}). However, these also had the problem of not scaling properly with window width... —PaleoNeonate – 13:35, 26 January 2018 (UTC)
I think I get why the columns looked weird on my computer but why is it that the no one seems to be informed of these changes, there was an issue before with the Harv citations as well, I had to go to the teahouse to figure out what it was.★Trekker (talk) 13:44, 26 January 2018 (UTC)
(edit conflict) I see three columns, that's using the current version of the article where {{Reflist}} has no parameters. Inspecting the HTML source and associated style sheets, I find that this is equivalent to {{Reflist|30em}}. If I edit the page to add a parameter and preview it without saving, I see a different number of columns, for example: {{Reflist|18em}} - 5 columns; {{Reflist|19em}} to |22em - 4 columns; |23em to |30em - 3 columns; |31em to |46em - 2 columns; |47em or more - 1 column. You may see different amounts, since your system setup is not likely to be the same as mine. What we should be aiming for is not a particular number of columns but an optimum balance between text and blank space, where the main consideration should be that longer refs should not wrap excessively. If most refs are short, as with the Gärdestad & Liimatainen 2005 refs, a narrower column is desirable; but where most refs are long, a wider column would be more suitable. For an article like this which has a 50/50 (nearly) split between the two, a compromise between narrow and wide is in order. Generally I would not specify a column width to greater precision than 5em. --Redrose64 🌹 (talk) 13:50, 26 January 2018 (UTC)
@*Treker: I've just edited Ted Gärdestad to specify {{Reflist|colwidth=40em}}. I think that looks better on a range of monitor widths up to 2560px. However, please feel free to alter that to what you feel is best, but please keep the |colwidth= now, even if you reduce it back down to 30em.
@Redrose64 and PaleoNeonate: This is an example of the issue that the default carries less information that the parameter explicitly set to the default value. There's a difference between no parameter and |colwidth=30em – the latter implying a deliberate decision to set 30em, rather than a laissez-faire reliance on the default value. Hope that makes sense. --RexxS (talk) 14:16, 26 January 2018 (UTC)
Hmm yes... There various articles I've set to use default as there seemed to be no reason to use a custom value; but I guess that 40 for the above article is decent considering the long harv notes (just as 25 or 20 is common for short harv-only). —PaleoNeonate – 14:51, 26 January 2018 (UTC)

oh for goodness' sake

I switched from using <references /> to {{reflist}} because in some articles I saw the benefit to using {{reflist|2}} to columnize some lists of references. At some point, that was changed to allow for dynamic columns based on width. That made sense. Now, however, apparently, I am unable to use either method (HTML references tag or {{reflist}}) to produce a plain list of references? They now both impose multiple columns regardless of editor's original intent? What's going on? — fourthords | =Λ= | 17:34, 12 February 2018 (UTC)

If you do not specify a width, {{reflist}} will automatically columnize the references (at a 30em width) if there are more than 10 references. <references /> will likely do the same at some point in the future, though I'm fairly certain it does not do so now. If you set a number of columns (say, 1), that is converted to a width by the template (because setting a column count is deprecated due to suboptimal behavior broadly). Both behaviors can be worked around by using {{reflist}} and setting a large width (say, 50em+), though that behavior may not continue in perpetuity. Broadly, multiple columns better fit most pages than a single column of text will. Why are you attempting to use only a single column? (Where?) There may be an alternative available. --Izno (talk) 17:50, 12 February 2018 (UTC)
I've only just today realized the new reflist behavior. Using <references /> does automatically generate multiple columns. I realize that {{reflist|1}} would do what I wanted, but it's not an approved-of method. I worried that {{reflist|2000em}} would do something weird and unexpected if I did. — fourthords | =Λ= | 18:19, 12 February 2018 (UTC)
You can also use <references responsive="0"/> to disable columns. Columns have generally been preferred by almost all editors, so having them as the default behaviour is the 'sane' way to do it. I've yet to see a situation where a list without columns had significant benefits and where it does, it is likely an exception. Exceptions should be harder to achieve than sane defaults. —TheDJ (talk • contribs) 17:59, 12 February 2018 (UTC)
A-ha, <references responsive="0"/> may be just what I was looking for. Why isn't its functionality documented at template:reflist/doc? I don't have anything to say regarding the sanity of any given decision, but (a) changing the default behavior of a template used on over 4.2 million pages, (b) not making it extremely-widely known, and then (c) not documenting how to actually get the otherwise expected behavior, isn't playing well with others. Thank you for the work-around; you might want to put it somewhere easily-found. — fourthords | =Λ= | 18:19, 12 February 2018 (UTC)
The functionality isn't mentioned because no unpaid volunteer, including yourself, has found the time to document it. The change was made in the MediaWiki software, so it affected several hundred projects, not just ours. {{Reflist|1}} works perfectly well for the one-page-in-a-million where we actually need to force a single column (remembering that {{Reflist}} alone will give one column if there are fewer than 11 references). It is also intuitive and has the advantage that it matches the bottom margin spacing of most other block elements used in wikitext, whereas <references /> does not. --RexxS (talk) 20:45, 12 February 2018 (UTC)

Template v. tag references

I can not understand why column widths are different using this template or using the tag references. See my sandbox. Different number of columns with smaller width is provoked by class reflist. --Vriullop (talk) 11:01, 3 March 2018 (UTC)

@Vriullop: When you use the reflist class, it becomes the outer container for that content. Because reflist sets fontsize: 90%, when the following div sets its column width in ems, those ems are 90% smaller in absolute terms than for the same content without the reflist class. If you use your browser's inspect function, you can see that happening. In Monobook, 'references' columns are never narrower than about 345px, but 'reflist' columns can be as narrow as approximately 306px, which is the expected ratio of 90%. Hope that makes sense. --RexxS (talk) 11:54, 3 March 2018 (UTC)
@RexxS: Oh, I see. But is this behavior intended or unexpected? --Vriullop (talk) 12:24, 3 March 2018 (UTC)
It's unintended, but expected from the way the template was originally created. In any given article, there really shouldn't be a problem, because you're unlikely to be mixing the two styles. Nevertheless, simply setting colwidth=33em in {{reflist}} should make it behave closer to the way <references /> does. You might want to test that and see. --RexxS (talk) 12:33, 3 March 2018 (UTC)
I can only think it as an unlikely problem if someone uses both {{notelist}} and references tag. The issue has arisen when a user changed the tag for the template and found it confusing that the number of columns changes suspecting of some bug somewhere. Let me reword the question, without any parameter shouldn't both render the same columns? Just for consistency, without prejudging which one is better and without having tested how to achieve it. --Vriullop (talk) 14:06, 3 March 2018 (UTC)
To answer your question: in my humble opinion, without any parameters both should render the same number of columns at the same screen size. And with my ancient and gradually worsening eyesight, I would much prefer it if reflist simply didn't make the font size smaller, which would solve both problems. But the tyranny of the majority ensures that some folks' idea of what "looks good" triumphs over functionality, accessibility and consistency every time. --RexxS (talk) 21:49, 3 March 2018 (UTC)
On the other hand, if |colwidth= is specified as some number of ems, it refers to the width of letters, so one would expect it to vary with the font size. So should the default be some number of pixels instead of 30em? Kanguole 00:08, 4 March 2018 (UTC)
No, because then it wouldn't react properly if someone adjusts their browser to display the page with a larger font size. Anomie⚔ 05:12, 4 March 2018 (UTC)

The default is 30em

I suggest that the documentation should mention that 30em is the default, in two places i.e.:

  • "Syntax (for example, the default) |30em with no space"
  • "Automatic columns (default, of 30em, when no width is specified)"

Shall I change it as above? -Lopifalko (talk) 07:51, 4 July 2018 (UTC)

This needs to changed/clarified.
  • Since 30em is the default, it should not be mentioned under "Optional parameters". Instead, use a different width: "Syntax (for example) |20em with no space (i.e. not |20 em)".
  • Same for "Columns" section: "Reflist|20em (for example) instructs the browser to create as many columns as possible (of width at least 20 em, in this example). Also, "Automatic columns (the default is 30em when no width is specified)" and remove the "30em: Where there are many ..." example.
H:REFCOLS should also be changed to reflect that the default is 30em and remove the "Reflist|30em: Where there are many footnotes ..." and change the "For example: Using Reflist|30em..." and further mentions of 30em to a different width, such as 20em.
—Ojorojo (talk) 14:34, 4 July 2018 (UTC)
Whatever documentation is provided, it needs to recognise that there is a difference between (1) {{reflist}} and (2) {{reflist|30em}} (or {{reflist|colwidth=30em}}). In the second cases, there is a clear indication that the editor is aware of the parameter that determines column width and has chosen an appropriate value for it. In the first case we don't know whether the editor has made any determination of what column width would be best, or if they have simply added the template without any further consideration. The parameterless template should be an invitation for others to check whether the default 30em is optimal; hence specifying 30em can save repetitive checking of the same article. --RexxS (talk) 16:11, 4 July 2018 (UTC)
Though people are removing this from templates indiscriminately. 18:59, 4 July 2018 (UTC)
Huh? Removing what from what templates? EEng 19:09, 4 July 2018 (UTC)
Removing the 30em from the {{reflist}} template. Keith D (talk) 20:46, 4 July 2018 (UTC)
That will at least be me. I have learned to do otherwise today. -Lopifalko (talk) 20:48, 4 July 2018 (UTC)
Albeit only manually and when making other changes.-Lopifalko (talk) 06:14, 5 July 2018 (UTC)
Ditto. —PaleoNeonate – 06:57, 5 July 2018 (UTC)
Will look but there was someone running a bot last month that removed 30em from thousands of articles. I just assumed this was ok. ...will research some more.--Moxy (talk) 21:16, 4 July 2018 (UTC)
Jesus Christ, why do people do idiot stuff like that? Even if you don't realize, as Redrose explains above, that that's a negative change, it's at best a zero-value change, so how in the world can that seem like something worth clogging up watchlists and histories for? How could something like that get BAG approval? Please let us know what you find out. I'm in the mood to kick some butt and take some names today. EEng 21:45, 4 July 2018 (UTC)
On reflist, versus on see also div? (I did see a bot editing those lately.) —PaleoNeonate – 02:52, 5 July 2018 (UTC)
I would suggest not saying that 30em is the default without adding further explanation. This will lead people to think that {{reflist}} and {{reflist|30em}} have the same behavior. 30em is in fact not the default; the default is "automatic", and the documentation currently says that. And the absence of a colwidth does not necessarily mean no one has thought about what the optimum colwidth should be; it's possible someone thought about it and decided that automatic was appropriate. Kendall-K1 (talk) 03:21, 12 July 2018 (UTC)
The "someone" will be the various people who contributed to discussions on this matter over the last four years. See most of the threads at Archive 25, Archive 26, Archive 27, Archive 28, Archive 29, Archive 30, Archive 31, Archive 32. --Redrose64 🌹 (talk) 11:52, 12 July 2018 (UTC)

Rows of whitespace between references

Recently I noticed several rows of whitespace, each no wider than a column, randomly appearing both between and within numbered references. It seems to occur when asterisks are used to create bullet-point lists within grouped references (by "grouped references", I mean listing more than one citation template within a single reference). Here is one example (both before and within reference 4). Am I missing something here? I know that certain parameters regarding width are now deprecated, or at least I think that's the case, but I don't think that's the problem here. Levdr1lp / talk 07:09, 26 July 2018 (UTC)

No such problem here with Safari, but I do note that such lists are inside spans, which is not allowed in HTML (See also phab:T49544), so combined with the columnbreaking CSS statements, it might cause some weird effect in some browsers perhaps.. This behavior possibly also changed, because Tidy used to attempt to correct such constructs, where RemexHTML likely leaves it alone and leaves it up to the browser to interpret. —TheDJ (talk • contribs) 07:48, 26 July 2018 (UTC)
Thanks. Firefox appears to be the culprit, at least in part-- no whitespace *within* reference 4 on either Safari or Chrome. However, whitespace is still present *before* reference 4 regardless of browser. It would seem that "grouped references" (again, by this I mean more than one citation template within a single numbered reference) must now remain within a single column. I don't think this was always the case. If a single numbered reference had a bullet-point list of multiple citations and it appeared near the bottom of a reflist column, sometimes the reference would be split in two, with leftover bullet-point citations overflowing into the next column. Am I remembering correctly? Are "grouped references" limited to a single column now? (By the way, what do we call "grouped references" with bullet points as I have described in this thread? I am *not* referring to WP:REFGROUP.) Levdr1lp / talk 09:11, 26 July 2018 (UTC)
@Levdr1lp: I usually see them referred to as "bundled citations" and I generally think of them as a poor idea, introducing a lot of extra complexity for no real gain, and making a mess of the wiki-text with a new line for each bullet. If those same set of citations were to be used again elsewhere in the article, I could see a case for bundling them and naming them as a bundle, but otherwise I can't discern any improvement over unbundling them into separate references, especially when they are re-used individually in the article. Others will have different opinions. --RexxS (talk) 13:19, 26 July 2018 (UTC)

Examples

The "Examples" section here doesn't actually show examples. It just shows an overview of the syntax. An example would show, you know, an example of the text you'd actually type. IAmNitpicking (talk) 13:07, 29 July 2018 (UTC)

Where? I see two sections titled "Example" (no "s") and both have what I would call examples in them. Kendall-K1 (talk) 13:30, 29 July 2018 (UTC)
An "example" would be <ref name="NiklasKutschera2010">{{Citation |last=Niklas |first=K.J. |last2=Kutschera |first2=U. |year=2010 |title=The evolution of the land plant life cycle |journal=New Phytologist |volume=185 |issue=1 |pages=27–41 |doi=10.1111/j.1469-8137.2009.03054.x |pmid=19863728 |postscript=. }}</ref>. (I had the Embryophyte article open in another tab.) Examples have actual values. A list of possible types of things you can include is a syntax illustration or something. An example could actually be put in an article and work. Note that my example above is a valid example of "example".IAmNitpicking (talk) 17:25, 30 July 2018 (UTC)
That would be an example for Template:Citation; this template merely shows the list at the bottom of the page, and is not for generating a citation Galobtter (pingó mió) 17:28, 30 July 2018 (UTC)

column default

I do not see how introducing columns, by default, improves their display in digital documents (or print, fwiw). Would someone here be able to point out the advantage, or the discussion where some sort of consensus was reached, because using the parameter to force a single column feels belligerent. Otherwise, I am a big fan, and appreciate the functionality it allows. cygnis insignis 12:25, 31 October 2018 (UTC)

@Cygnis insignis: There is plenty on this talk page, and in its archives. See for example my comment of 11:52, 12 July 2018 (UTC) at the bottom of #The default is 30em above. --Redrose64 🌹 (talk) 12:45, 31 October 2018 (UTC)
I appreciate the time taken to quickly respond to my query. which I hoped would be seen by someone active on this page. I would prefer to have received a succinct, or nutshell, a reference to the quintessence of the decision, because while the course of that decision that overrides my own preference to follow the convention of reading from left to right—without the need to rescroll to find the next column—may well be punctuated with the missives and well informed opinions of my colleagues here, I am inclined instead to refocus on improving the content of our document. Sincerely yours, cygnis insignis 13:45, 31 October 2018 (UTC)
Feel free to write such a summary if you think it will benefit other editors in the future. Kendall-K1 (talk) 14:30, 31 October 2018 (UTC)
@Kendall-K1: Hi. Is that intended to be a helpful suggestion? If the reason is made known I would add it to the template documentation and propose that the MOS be altered to guide those who have the same concerns. Please enlighten me and others if this is obvious, or your response may be misconstrued. — cygnis insignis 14:57, 31 October 2018 (UTC)
The gist of the discussion is that "we don't know what kind of device each reader is using, so we will let that user's browser or printer decide how many columns to display". --Izno (talk) 14:41, 31 October 2018 (UTC)
@Izno: Hi, and … Thanks. My understanding is that the device may elect to render pagination in various ways, forcing columns would not be helpful when that occurs, the output seems to be related to the page layout here and is probably ignored when the content is scraped out or rendered elsewhere. This doesn't address the issue of two or three columns rendered by the template here, in mainspace, or I fail to see how that relates to the concern raised. — cygnis insignis 14:57, 31 October 2018 (UTC)
@Cygnis insignis: Research shows – and experience, such as in newspapers, demonstrates – that for most people reading is hampered by columns that contain too many words because then the eye loses its ability to scan from the end of one line to the beginning of the next. Since citations are of indeterminate length and browser windows are of indeterminate width, we cannot guarantee that no citation will wrap onto multiple lines no matter how long we try to make the lines. Once we have accepted that we have to cope with multiple lines, the only outstanding question is how wide should we make them, and most editors seem to have agreed that somewhere around 30em to 40em makes for the most comfortable experience. The result is that what you see for the column default has considerable consensus. --RexxS (talk) 19:17, 31 October 2018 (UTC)
@RexxS: Thank you for the response, however, the part of the rationale that was posted as "we cannot guarantee that no citation will wrap onto multiple lines no matter how long we try to make the lines" is not understood by me, or at least what the relevance of it is. I am not able to understand the transition from 'people cant read long pieces of text' to 'forcing columns', and it may be that the assumption was made that I thought there ought be any columns, instead of none, and the width was to be determined by some means. If there is some research to indicate that breaking the text assists with reader attention, and it is not impolite to request a citation be included in those sort of assertions at our document, then a sort of paragraphing would surely be less disruptive than navigating to the continuation of the text at some point in the part of the page just past. Again, if a RS states something contrary to this, then please allow me to verify that. Or if I am personally unable to comprehend this rationale, to exclude any other possibilities in this discussion, then at least add it to the documentation to allow others to appreciate the decision that was made by the community … somewhere. —cygnis insignis 15:44, 1 November 2018 (UTC)
I'm not sure what's so difficult to comprehend about "we don't know how long a citation might be" and "we don't know how narrow a reader's screen might be". Taken together, I'm at a loss to see how you can fail to grasp the point that we have to accommodate the possibility that lines may need to wrap. You can either take my word for it that long lines that wrap are less comfortable to read than some optimum line length around 30-40 characters, or you can do your own research. --RexxS (talk) 15:58, 1 November 2018 (UTC)
Thanks RexxS and EEng. Cygnis insignis: forced but dynamic columns were implemented awhile back after lengthy discussions, so there isn't one succinct paragraph that can inform you of how the decisions were made. If you are desiring to change the way Wikipedia displays citations, you should probably open up a discussion in a larger forum than this template talk page, but I don't foresee it getting much traction at this point. In any case, I should point out that if an article has 10 or less citations, they are currently not broken into columns. Part of the rationale for columns was that they save a lot of vertical space, which is believed to improve readability. Further, the assumption can be made that we typically read citations individually, not as a group, so the only times you'd have to rescroll is when the citation you are looking at is broken across 2 columns.— TAnthonyTalk 18:09, 1 November 2018 (UTC)
Ideally the consensus following someone's desire to "change the way Wikipedia displays citations" was also conducted in a different forum than this talk page, with broader consultation and a formulation of consensus by the closer (even if that ran to three paragraphs). Did that not happen? Have I overlooked the links to something other than another users own comments here? If such a discussion is available to be skimmed, I have read many similar opinions on layout and markup so should be able to sift out the substance of the rationale and produce a formulation if nobody has done that already. An obvious objection would be that the column format (albeit in the next to smaller size of whatever the readers regular font size is set to) follows text that is not in column format, like printed newspapers in the example given above of what readers prefer, and strings out—in who knows how long a sentence—to be wrapped to the readers preferred layout with their other respective preferences or default. If there is a preference to 'display all text as columns' in any device or app's rendering, and I have never noticed one, then that would likely fouled by the rendering of columns in the markup here (resolvable, if it is the case that others apply that functionality, but which I doubt is sought or provided). — cygnis insignis 06:13, 2 November 2018 (UTC)
Well, how about Wikipedia:Village pump (proposals)/Archive 141#Automatic column mode for references element? --Redrose64 🌹 (talk) 10:51, 2 November 2018 (UTC)
I would have preferred a link that that discussion at the outset, but understand that a shabby totalling of "I like it" and "I support guy above who is supporting it" by the team who wanted to make a big splat in main space with the tweakers who believe CAN equals MUST apply every naff complication without a rationale or interest in its utility. The only points of legitimate discussion were smothered after it was presented as a fait accompli! So thanks, after being presented with "research shows" statements that mainspace editors recognise as weaselish bluff, and blatant assertions that this is obviously better and I'm a fool not to see that, I'll continue doing what I'm doing until the same mob make it compulsory in discussions on this page. At no point did the points raised there or here become addressed, so average. cygnis insignis 14:08, 2 November 2018 (UTC)
I'm not sure how you believe the discussion should have occurred, and I'm sorry the result goes against your personal preferences. You seem to be annoyed by it, so by all means reopen the topic if you think a significant number of people agree with you. I don't really appreciate your condescending "show me the consensus you nitwits" attitude and obvious belief that you are a shining beacon opposed by a mentally-challenged mob, but you're entitled to your delusions. Thanks.— TAnthonyTalk 15:09, 2 November 2018 (UTC)
Project much? Thanks? Really? That is the standard recourse of people who make bluff assertions and pile on to make, as you say, condescending responses instead of responding a simple and polite request, a rationale or a link to the discussion. If they don't exist then the option is to exhaust anyone who questions your preference, give them the run around and imply heavily they are being odd not to see the advantage. This was implemented as I pointed out, by those who are focused on naff features as a fait accompli, collecting anything that seems to support the thing that was going to happen, like it not. Address the points I raised or go get your jollies elsewhere, we are supposed to working toward something in discussions. cygnis insignis 18:40, 2 November 2018 (UTC)
Excuse me, though you have made good points about why you disagree with fixed columns, you've been subtly obnoxious during this entire discussion. No one here (except me, apparently) has been rude or dismissive to you. I'm sorry no one was able to whip up a link to a consensus discussion fast enough for you, but it is really not the responsibility of other editors to do so under some deadline. No single person made a unilateral change, so there's no need to condescend to everyone reading this page, you can get over it now.— TAnthonyTalk 19:46, 2 November 2018 (UTC)
And by the way, you did more than raise some points. You are within your rights to ask for explanations, but all you did when you got them was dismiss or dare-I-say mock other editors' comments, and malign the integrity of the Village pump discussion as well as basically any editor that voted in favor. That's not "working toward something in discussions", that's the opposite.— TAnthonyTalk 19:59, 2 November 2018 (UTC)
@Cygnis insignis: (edit conflict) I shouldn't have to do this, but I'm now sick of your tendentious whining simply because the facts don't fit your pet theories that nobody else agrees with. If you'd taken even a couple of minutes to do a search on the issue of line length and readability, you'd have found dozens of results with slightly differing opinions on optimum characters-per-line, but all agreeing that an optimum exists. You don't even have to look very far as we even have a Wikipedia article, Line length, that discusses the issues and provides 10 references. The other editors here are not your gophers, and I for one am uninterested in trying to convince you to change your mind, because the standard procedure of cynics is to continually demand that others have to provide more and more evidence. That evidence is freely available and understood by most editors. And that is the reason why we have consensus on a default column width for reflist. --RexxS (talk) 20:07, 2 November 2018 (UTC)

The OP needs to do his own research, review past discussions, then if he or she has something new to offer that hasn't been considered before bring it up here. EEng 22:19, 2 November 2018 (UTC)

The OP can also customize the view so that he does not need to see columns. Ever. Or 2. Or 80em-wide columns. Or 5em-wide. This is tendentious at this point. --Izno (talk) 02:06, 3 November 2018 (UTC)
Nice.
Bullet points
  • Why does the line length 'problem' not also apply to the main body of text?
  • What evidence is there that a mix of formats, none and some columns, is assisting the reader? Newspapers only use one, unless they are using to push the attention of the reader.
  • The convention, citation not needed, is to read from left to right then return to left margin. Introducing a new format to a page is avoided without a good reason, ten times better than not doing it, because this also disrupts the ingrained expectation of those who read texts.
  • How does reducing the amount of white space improve readability, I thought the opposite was generally true.
It is not tendentious to make these points when the are responded to with none answers and deflection from the same concerns that others have raised in the past, likewise, without responses that address that creepiness of this abrupt and nigh compulsory change. — cygnis insignis 12:01, 3 November 2018 (UTC)
compulsory change – It's just been explained to you where you can find instructions on overriding the default behavior. Your approach is very unpleasant, and I suggest to my esteemed fellow editors that there izno need to engage further on this. EEng 13:11, 3 November 2018 (UTC)
References are not article text. Article text consists of sentences organised into paragraphs, which suit a wide layout, and online newspapers do the same. Printed newspapers historically used narrow columns because it suited the pre-computer age which used blocks of certain standard widths in order to match the slugs prepared by Linotype machines.
In our articles, references are typically short, they suit a multi-column layout - imagine if these references were not organised into columns, there would be a large blank space in the article. --Redrose64 🌹 (talk) 13:45, 3 November 2018 (UTC)
EEng, noted, now that I thought to look again. Simple solution: add the rationale to the template documentation. Response here to that suggestion: a pile on of helpfulness and insinuation, not a team sport I'll remind everyone. The consensus is said to have been formed here, not an inappropriate to raise the concern again. So what if there is white space, it is a good thing, we are not running out of paper here. cygnis insignis 08:19, 5 December 2018 (UTC)

Percentile width

For modern behavior, this really needs to support percentage widths: {{Reflist|50%}} like, well, everything else on the modern web. Specifying anything in fixed units is generally foolhardy. This has been a vexing issue for some time now.  — SMcCandlish ☏ ¢ 😼  07:56, 5 December 2018 (UTC)

I smothered this new section with a reply to an old post, apologies, and good luck with that sensible suggestion. cygnis insignis 08:34, 5 December 2018 (UTC)
SMcCandlish, does this mean that you want the Reflist to take up 50% of the screen width, or do you want each column to take up 50% of the allotted space for the reflist? In either case, I would not recommend using an unnamed parameter, but instead using something like |colwidth= or |total-width=. – Jonesey95 (talk) 10:31, 5 December 2018 (UTC)
Any "CSS thing" specified as (say) 50% in CSS should take up 50% of the available space for the element; that's just how it works. We can't have things taking up literally 50% of the screen width without taking them out of the normal document flow and imposing them as overlays or other awfulness, that would break in a lot of browsers, and no one would expect that. I.e., this should work like 50% (or whatever) does in all other contexts on this site. Since the parameter accepts every other valid CSS measurement value, then we obviously don't need a separate parameter for this. There isn't anything magically special about % vs em or whatever.  — SMcCandlish ☏ ¢ 😼  11:28, 5 December 2018 (UTC)
Thanks for the answer, and see below for why I was confused. A column width of 50% is the same as two columns, which is no longer supported. Perhaps this talk page or the template's documentation should have an explanation answering this perennial question or a permalink to the discussion that led to the removal of support for a fixed number of columns. – Jonesey95 (talk) 23:46, 5 December 2018 (UTC)
This is because "percentage values are also invalid" for setting column-width. Galobtter (pingó mió) 11:44, 5 December 2018 (UTC)
  • Perhaps I'm dense, but how would "each column is 50%" be any different from saying "2 columns"? EEng 12:20, 5 December 2018 (UTC)
  • Specifying anything in fixed units is generally foolhardy. No, it's not. Quite often some interface elements are intended to be a specific size relative to the font (typically "em" units), leaving the remaining space for the main content and using @media rules to handle the case where the device is too small for that "remaining space" to be enough. Anomie⚔ 12:39, 6 December 2018 (UTC)
    Anomie, @media rules sez i can haz colums? cygnis insignis 12:57, 6 December 2018 (UTC)
    We're not saying that you can't have columns. What we're saying is that if you use columns, you should specify their widths using known quantities (like em, ex, px etc.) rather than as a fraction of the available width. --Redrose64 🌹 (talk) 21:47, 6 December 2018 (UTC)

Reflist needed

Somewhere there is a maintenance catalog showing errors where {{Reflist|group=N}} where N is parameter in the inline citation, and providing a Notes line is needed, but a red message exists instead, but I do not know where. Advice, anyone?--Dthomsen8 (talk) 02:08, 9 February 2019 (UTC)

Possibly Category:Pages with missing references list (37) and Category:Pages with reference errors (2,773). – Jonesey95 (talk) 05:42, 9 February 2019 (UTC)

Template:RE listed at Redirects for discussion

An editor has asked for a discussion to address the redirect Template:RE. Please participate in the redirect discussion if you wish to do so. Headbomb {t · c · p · b} 16:20, 3 April 2019 (UTC)

Retrieved from "https://wiki.riteme.site/w/index.php?title=Template_talk:Reflist/Archive_32&oldid=1091981689"