Template talk:Reflist/Archive 6

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1 ← Archive 4 Archive 5 Archive 6 Archive 7 Archive 8 → Archive 10

Long URLs

Issues with long URLS have been mentioned, so I have investigated this. As noted, proper references should not show a bare URL, but the URL does show when selecting the printable version: see Harry S. Truman printable version. Take a look at reference 64 and note that the URL does not wrap well. --—— Gadget850 (Ed) talk - 19:48, 7 August 2008 (UTC)

Ick. Well-noticed. For the benefit of those without Firefox, see the screenshot Image:Wikipediareflistoverlap.gif which shows the 2 column references (overlapping at #9 and #12, and many others) in print-preview mode. -- Quiddity 20:26, 7 August 2008 (UTC)
Thanks for the screenshot- I did not consider that. I'm using FF3 and refs 9 and 12 are fine. Only 64 is mangled. --—— Gadget850 (Ed) talk - 20:32, 7 August 2008 (UTC)
Anyone know how the printable references are rendered? --—— Gadget850 (Ed) talk - 21:06, 7 August 2008 (UTC)
Here is the printable version at one column:[1] Ref 64 isn't pretty, but it isn't mangled. --—— Gadget850 (Ed) talk - 21:09, 7 August 2008 (UTC)

Template:reflist: Multiple columns

Template:Reflist (talk · history · transclusions · logs · subpages)

(I got pulled into this "wikipolitics act" holding my nose decision via a post on WP:VPT (see archived discussion)--User:Ceyockey (talk to me) ... and the template talk. This seems the proper course of duty)

    • This is not a nomination for outright deletion, but for "defanging-for-a-few-years" a template that was a good idea way ahead of it's time.

    • See the discussion on Need_another_template_that_works_with_2_columns_in_all_browsers

   and prior discussions on Multiple_columns_deemed_bad (archived prematurely) -- FrankB 18:34, 1 August 2008 (UTC)


Rationale, recommendations:
  • As I noted on the talk, the problem with the template is it relies on "relatively proprietary"
    (Mozilla's for Firefox) 'technology not available' on most web browsers

I hearby move the template be rewritten: 

From:
<div class="references-small" {{#if: {{{colwidth|}}}
| style="-moz-column-width:{{{colwidth}}};
 -webkit-column-width:{{{colwidth}}};
 column-width:{{{colwidth}}};" 
| {{#if: {{{1|}}}| style="-moz-column-count:{{{1}}};
 -webkit-column-count:{{{1}}};
 column-count:{{{1}}};" }} }}>
{{#tag:references||group={{{group|}}}}}</div><noinclude>{{pp-template|small=yes}}{{documentation}}</noinclude>
TO
<ref>
<div class="references-small" >
{{#tag:references||group={{{group|}}} }}</div><noinclude>{{pp-template|small=yes}}{{documentation}}</noinclude>
</ref>
OR
the equivalent... (not being sure what that {{#tag:references||group={{{group|}}} }} does besides break {{lts}}. <shrug>

    • If I have this straight, the next result should be (expanded)
<small><references/></small> 
— FrankB 18:43, 1 August 2008 (UTC)
  • Comment: Yes, there is a problem, but TFD is not the proper way to draw attention to making a revision. --—— Gadget850 (Ed) talk - 20:21, 1 August 2008 (UTC)
  • Personally, I'm in favor of getting rid of the column-count and font-size nonsense and using consistent references throughout the site. The smaller font size causes issues with certain browsers, as do the multiple columns. --MZMcBride (talk) 21:17, 1 August 2008 (UTC)


As far as I can tell, there are two issues here:
  • Many browsers don't support multicolumn reflists ({{reflist|2}}). I would hope that they just show a single-column list; correct me if I'm wrong. There may be a slight increase in HTML size, but it's presumably negligible, and brion didn't state that it's a problem.
  • In those that do support them, there may be issues with display if there's a long URL. As brion says here:
    • "I strongly agree that multicolumn layout is a Bad Bad Thing for reference lists. Quite independent of any speed or browser compatibility issues, they cause a lot of problems with narrow screens, printing, line wrapping, and output of long items such as URLs -- which are really common in reference lists! Just say no to multicolumn. :)"
  • Now, since he's not saying anything about server speed, this is just his informed opinion rather than the opinion of a sysadmin. It does seem to make sense, but it was my understanding that properly-formatted references are not supposed to have bare URLs.
One possible alternative would be to add a sitewide preference for the number of columns in a reference section. --NE2 22:24, 1 August 2008 (UTC)
  • Worse problems with reflist|3 and relist|4, discussed elsewhere; I can find the links if needed. I'd like to see the columns go away, for all the issues raised. SandyGeorgia (Talk) 22:35, 1 August 2008 (UTC)
Safari on WinXP displays the multiple columns, but the little letters get displaced, and the link between a reference number in the text and the reference itself gets broken. Here is a screenshot of an example (reference 7 illustrates the displaced little letters). Image:Safariscreenshot.PNG. DuncanHill (talk) 22:36, 1 August 2008 (UTC)
OK, that seems to be a problem. Though we shouldn't necessarily be worrying about browsers' ability to comply with standards, I don't believe this actually is an official standard (yet?). I would have no problem with removing it from this template and optionally making it a sitewide preference (the latter would require developer intervention), at least until it's added to the official specs. (By the way, I just found out about Wikipedia:Footnotes#Separating reference lists and explanatory notes - pretty cool.) --NE2 22:53, 1 August 2008 (UTC)
I think there was a suggestion of having a pref setting for this in one of the previous discussions. Given Brion's stated less-than-happiness with multi-columns, maybe he could help with this? (And, yes, the notes/ref thingy you linked looks pretty cool - will have to have a go at that!) DuncanHill (talk) 23:01, 1 August 2008 (UTC)
I'd strongly support both the removal of multicolumns from here, and an increase to the .references-small class in common.css (from current 90%, increase it to 95%). Just tell us where to voice our concerns, if anything more is needed before a decision gets made. -- Quiddity (talk) 23:14, 1 August 2008 (UTC)
I would support removing the columns, or at the least, removing the option to add any more than 2 columns. I can't imagine a 3+ column reflist looks good on an 800x600 monitor. I don't think we should remove the small font though, on pages with many dozens, or sometimes hundreds of references, it really makes a difference. Mr.Z-man 23:19, 1 August 2008 (UTC)
I have a 1024x768 screen, but I keep my browser sized at 800x600 unless I'm having to use a site that requires more width. 3 columns usually looks OK to me, especially when short references are used. Anomie⚔ 23:39, 1 August 2008 (UTC)

What a lot of misconceptions here

It looks like someone has decided to make a crusade over the multicolumn support in this template. It's almost funny how bad some of the claims above are.

  • column-count and column-width are both proposed for inclusion in version 3 of the CSS standard. Hardly "proprietary Mozilla technology" as is claimed.



    • So shoot me for knowing it was developed by mozilla??? Hey, I'm not a CS type, but The issue is whether it should be used at all, if it doesn't have 80-90% browsers support. It clearly does not... and WP:CRYSTAL to pending possible standards... Sorry. I've posted Brion's talk, so let's see what the issues are. As a rule, stylistically I don't care... I'm not acting out of anything here but concern 'per Brion's feedback'... which was cavalierly ignored... from what I saw. // FrankB 23:59, 1 August 2008 (UTC)



  • I fail to see how multiple columns impose any extra load on the servers. The way this feature works is by adding three extra CSS declarations (which to the server are so much plain text) which instruct the browser to format the contents of the references list in multiple columns. In other words, the server does absolutely nothing to format the references in columns.
    • There is the fact that output of the template is not cached when {{reflist|2}} is specified instead of {{reflist}}, but as this template should not be used more than once on a page without the group parameter (any parameter disables the caching) that is completely moot.
  • It does in fact degrade gracefully on all versions of IE: the references list displays exactly as it would if multiple columns were not specified because IE completely ignores the column-count instruction.
  • The "bug" in Image:Safariscreenshot.PNG spammed all over the place has been fixed in versions of Safari that have been out for a good while now. There is still the bug with Safari not calculating the position of the anchor correctly; why not simply remove the "-webkit-*" parameters? That has been suggested before, but it has been ignored as the complainers really want to eliminate multi-column references entirely.
  • Sure, brion is the one who can tell us to worry about performance related to the servers. But this has nothing to do with the servers, so why is his personal opinion so important that it also needs to be spammed all over the place? Classic appeal to authority fallacy.



  • No, couldn't be classic ignoring the authority fallacy, could it. Grow up! If there is a performance issue, then this is SHIT. If you know twin columns aren't "Cached aggressively" as Brion has asserted is true for all pages, then you have cost the foundation and millions of users (AND ME PERSONALLY) "time unaccountable" with that feature alone. THAT is why I "Spammed the community" (How does two posts and a dispute count as spamming? Can't add very well, me thinks! <g>) 'But those uncached pages add up... count on THAT!' (YOU OUGHT to be holding your head down in shame if you know that was true! Use some common sense... This is a big multiple! )// FrankB 00:15, 2 August 2008 (UTC)

  • Since when do we wait to implement features that work well on some browsers and degrade gracefully on the rest until Microsoft decides to support it? This is Wikipedia, not Microsoftpedia.

       No it's common sense. You talk like we're in the business of being cutting edge instead of servicing the most needs. That might work for computer game designers resorting the latest-greatest video standards, but I sincerely doubt those idiots aren't killing their own companies profit margin. At least they can argue the Internet buzz and gamer attitudes offset the lost sales from people that don't upgrade, or can't afford to, but what counter argument can you justify for costing people time?

        • If I had my way, References would be invisible without a toggle... so is that feasible... something like the collapsible show/hide features on Navbox (navigational) templates? I'd rather see that than know something is costing people time.     // FrankB 00:27, 2 August 2008 (UTC)

  • MZMcBride claims there are "issues" with the smaller font sizes. I have yet to see any explanation of these issues besides some people complaining that they end up looking different on different browsers. Oh noes! This can easily be overridden with a gadget, BTW, if someone cares that much to write one.
  • As NE2 pointed out, "long urls" is a red herring as a properly formatted reference should never have a bare URL.

I personally could support reworking the template to use CSS classes for the cases of {{reflist|2}} and {{reflist|3}} and removing support for larger numbers of columns; this way a gadget can easily be written to customize the display of multi-column references. I strongly oppose removing multiple column support completely, as IMO (besides fallacies and the one Safari bug, all anyone has posted so far is opinion) it makes the article look better and makes the list easier to read. I also oppose removing the smaller font size for the same reason. Anomie⚔ 23:38, 1 August 2008 (UTC)

"Spammed all over the place" - no, added in response to editors requesting it (or not noticing it in linked archived discussions). Fixed in versions of Safari that have been out for a good while now? No it hasn't, not in the latest release for WinXP at least. Issues with smaller font sizes? Yes, they make it harder for people with vision impairments to read Wikipedia (as mentioned in the Accessibility project). "it has been ignored as the complainers really want to eliminate multi-column references entirely" - I have indicated my support for a user preference to enable users to choos whetheer or not multi-columns display, as have other editors, so I can only assume you made that comment without bothering to actually read what was posted (if you had read it, you would, acting in good faith as you are, never have said it). DuncanHill (talk) 23:47, 1 August 2008 (UTC)
I saw the same brion quote or reference to it in basically every post FrankB posted; I also saw the image in several places claimed as a current bug. Safari 3.1.2 is currently available for download, and does not have the bug. I previously tested on 3.1.1, and that didn't have the bug either. So unless the bug is only on XP and not Vista or Wine pretending to be XP, the bug is fixed. The thing that was ignored was "remove the '-webkit-*' properties until Safari gets the other bug fixed", not "create a user preference"; please work on your reading comprehension. Thanks. As for people with trouble seeing, I note that WP:ACCESS#Style and markup recomends <small> tags, which (at least here) actually render smaller than <span class="references-small"> (this may well differ on different browsers: SSSSSS). Anomie⚔ 00:22, 2 August 2008 (UTC)
I am using Safari 3.1.2, it has the bug. 3.1.1 also had the bug (and as I have always made clear, I use it on WinXP). I do not know why you are falsely claiming that it does not have the bug. I was also objecting to your incorrect claim that "the complainers really want to eliminate multi-column references entirely", which the comments in the previous debates clearly shew not to be the case - please work on your honesty. DuncanHill (talk) 01:01, 2 August 2008 (UTC)
Whoa whoa whoa, chill. He said he's using it in Wine, which may be why. Just to make sure, on [2], you see no "a b" next to 6, right? --NE2 01:03, 2 August 2008 (UTC)
Quite right, they are displaced and partially obscured by the text of the first "External Link", as in the screenshot I posted. I am (surprising as it may seem to some) not so stupid or dishonest as to post a screenshot like that without checking that the problem still occurs now I have the latest version of my browser. DuncanHill (talk) 01:07, 2 August 2008 (UTC)
Something more than just a simple bug is apparently going on here. I just rebooted into the XP Home that came preinstalled on this computer, installed Safari 3.1.2, and went to the page NE2 linked above, and saw no bug. I do see on [3] that it may also have something to do with the width of the window. Does anyone else feel like downloading and installing Safari 3.1.2 to give us more datapoints? Anomie⚔ 02:52, 2 August 2008 (UTC)
Maybe you could provide a screenshot of your experience with Safari 3.1.2 on WinXP. DuncanHill (talk) 08:33, 2 August 2008 (UTC)
Image:Safariscreenshot2.PNG. Anomie⚔ 15:08, 2 August 2008 (UTC)
Image:Safariscreenshot3.JPG is what I get with 3.1.2 DuncanHill (talk) 15:25, 2 August 2008 (UTC)
The bug thing you linked is for Safari on MacOS. DuncanHill (talk) 08:57, 2 August 2008 (UTC)
It's also the bug linked from Wikipedia:Village pump (technical)/Archive 11#reflist.7C2 problem where this bug was first discussed. Anomie⚔ 13:13, 2 August 2008 (UTC)
Reply to FrankB: Please, if you have only baseless accusations, references to policies that don't apply, and completely mistaken insanity to contribute instead of anything useful to say, please don't bother. You are of course free to ignore my advice, as I am free to ignore you if you do. Anomie⚔ 00:27, 2 August 2008 (UTC)
Replied on here, but if anything, the above discussion with DuncanHill and myself indicates your ego is engaged and you need to mature some. WP:AGF dude! If I'm wrong on this, it won't be the first time in 54 years nor today, and I'll ACTUALLY BE GRATEFUL. So mind your manners! // FrankB 02:01, 2 August 2008 (UTC)

If column-count and column-width are proposed for inclusion in the CSS standard, shouldn't we use those and not moz- and webkit-? --NE2 00:50, 2 August 2008 (UTC)

In FF2 and FF3.0.1, the feature is still "experimental" and is only supported with the -moz- prefix. It seems to work fine in practice. I don't know whether Safari recognizes it without the -webkit- prefix or not. Anomie⚔ 02:52, 2 August 2008 (UTC)

Just wondering, since the CSS degrades gracefully on Internet Explore why remove the the feature from other browsers? Nothing will change for IE users. BJTalk 00:54, 2 August 2008 (UTC)

(edit conflicted)
What is ultimately used is a side issue since the feature is currently implemented by a template. The template can easily be loaded with a dummy category statement to find and locate any occurrences of when |{{{1}}} is actually used and have a BOT change those pages alone if necessary. ::
My concern is and was whether their really is a systems performance issue behind Brion's quote. (Several sections up for any late-comers).

   That is and was the sole concern I have for starting this discussion.

  I have opined elsewhere that this "FEATURE" is perhaps best implemented as a magic word[4][5], and if that method makes sense, then the template can code it. If " column-count and column-width are proposed for inclusion in the CSS standard" versus purple-people eaters, is moot... since it's by template, those refinements can be handled by the technically cognizant.

  'This discussion' is being monitored by the 'larger body of general lay-editors' from the VPP link, not script and CSS and browser experts, so I'd suggest you keep the current discussion in terms "WE WHO OUTNUMBER YOU!" <g> can reasonably follow. I don't know, Don't know, so I called the question... hoping the community and not just one or two contributors could shed light on the issue or non-issue of performance. Whew! // FrankB 02:01, 2 August 2008 (UTC)



I'm still not understanding CSS is "frontend" in that it is processed by the users browser. The extra code amounts to an extra div and some CSS, how could that possibly cause extra server load? BJTalk 02:05, 2 August 2008 (UTC)


I have no clue... I'm not asserting that it does, but am asserting that THAT was what Brion seemed to be saying, AS I READ IT[6]... now... far too long ago. I have no idea of what is handled by CSS, personal scripts, and so forth, or how the HTML is generated for that fact save some fuzzy conjecture, BUT DO have a working knowledge of what I see on a browser source page... sometimes that's the only way to see why a template is misbehaving...

  After writing the foregoing, and revisiting the Brion QUOTE[7]... It looks to me that I morphed the concept of caching and 'took Brion's actual words out of context. In short it appears I read the wrong thing into what he said. Taken together with a related side discussion with Anomie, I think I owe the community an apology for misinterpreting Brion's comments into a blanket dislike of the two columns for performance reasons... when on re-reading he doesn't like them for other reasons. So rephrase things like this:


Are you all sure this template isn't affecting the caching and degrading performance if used only once as Anomie implies on his talk? And if so, then I suggest the discussion here be terminated on performance, the link on the VPP be changed to a new section debating whether two columns have any business on enwiki... or none... per the original discussion: Template_talk:Reflist/Archive_2008#Multiple_columns_deemed_bad. I have no opinion on that outside a wish we didn't have them visible at any time, except to other editors. In my ideal world, they'd be on an seperate automatically generated reference page that could be toggled on and off... what other encyclopedia cites footnotes ad nauseum? Cheers! // FrankB 04:10, 2 August 2008 (UTC)

FrankB, you're not helping. You got us here to discuss this, but now you're just yelling at us. --NE2 09:36, 2 August 2008 (UTC)

For screen viewing, a smaller font (let alone multiple columns) strikes me as a non-solution to a non-existent problem. Unlike the situation with dead trees, additional square centimetres of screen space do not cost additional money. (Neither do they contribute to deforestation, etc., but let's not labor the point.) Scrolling within the footnote area will be minimal as footnotes are seldom long and people seldom read them successively; reducing the font size won't "help" with this either. I've set my font size the way I want it; why should I have it further reduced and thus have additional trouble with the occasional dense Chinese character, etc., that finds its way into a footnote? And why should I experience an uncomfortably high number of saccades per line of longish note?

Having two or more columns is a handy way to get around the latter problem (introduced by the smaller font). Avoid the smaller font and there's no more reason to have two or more columns.

For printout it's a different matter. For print, by all means let's waste less paper by specifying a smaller font and multiple columns. -- Hoary (talk) 11:29, 4 August 2008 (UTC)

Bottom line?

Is the bottom line here that the conservative approach (i.e. aiming for high viewing consistency, matching between browser and print outputs, and reducing potential server load) to the use of the template would be to avoid using the multi-column option? Personally, I do use the 2-column option frequently, but this thread leads me to reconsider that style. --User:Ceyockey (talk to me) 11:11, 9 August 2008 (UTC)

The bottom line, IMO: There is one bug with Safari that should probably result in Safari's multi-column support not being used, and the stylesheet for the printable version should possibly force one column because the printable version includes long URLs. Also, there are a bunch of people who like to complain about font sizes and multiple columns but don't want to actually discuss any real solution. The "server load" thing was completely bogus and seems to have been due to a major misunderstanding (which AFAICT has been cleared up). So go ahead and keep on using the 2-column option. Anomie⚔ 00:17, 11 August 2008 (UTC)

Features/browsers

So we can understand the issues, I have tested the following browsers:

FireFox 3

Windows/Linux		 Internet Explorer
7, 8B1
Windows		 Opera 9.5

Windows		 Safari 3.1.2

Windows
Font size 90% Green tickY ☒N Green tickY Green tickY
Columns Green tickY ☒N ☒N Green tickY
Links
after column break		 Green tickY NA NA flag 
Groups Green tickY Green tickY Green tickY Green tickY

Please update for other browsers. --—— Gadget850 (Ed) talk - 14:12, 2 August 2008 (UTC)

Browser share

Usage share of web browsers shows the market share; I'm still looking for the actual usage on Wikipedia.

Bug in Safari

(Forgive me for making this a specific topic) ---- CharlesGillingham (talk) 04:51, 4 August 2008 (UTC)

Are you finding that the little letters are correctly placed, and that they link correctly from the reference in the text, in Safari 3.1.2 on WinXP? DuncanHill (talk) 14:19, 2 August 2008 (UTC)
The superscript letters in the references section are properly placed. If a reference link in the article links to a reference after the first column, then it pops down near the bottom of the article, not to the proper reference. --—— Gadget850 (Ed) talk - 14:32, 2 August 2008 (UTC)
OK, I still find that the little letters (do they have a name?) are misplaced in columns 2 onwards (they appear where they would be if there was a single column). I use Safari 3.1.2 (525.21). DuncanHill (talk) 14:42, 2 August 2008 (UTC)
The backlink letters look OK to me. I'm looking at Harry Truman. --—— Gadget850 (Ed) talk - 14:49, 2 August 2008 (UTC)
Very odd - they are misplaced for me (e.g. references 86, 87, 88). DuncanHill (talk) 14:53, 2 August 2008 (UTC)
Windows or Mac? --—— Gadget850 (Ed) talk - 15:38, 2 August 2008 (UTC)
Windows XP. DuncanHill (talk) 15:39, 2 August 2008 (UTC)
That is what I'm running— I just installed Safari. What article is Image:Safariscreenshot.PNG from? --—— Gadget850 (Ed) talk - 15:46, 2 August 2008 (UTC)
It is from an old revision of John Rogers (divine), the diff is [8]. DuncanHill (talk) 15:49, 2 August 2008 (UTC)
Still don't see it. As noted, this is a clean install of Safari. --—— Gadget850 (Ed) talk - 15:55, 2 August 2008 (UTC)
Mine was automatically updated a couple of days ago. DuncanHill (talk) 16:05, 2 August 2008 (UTC)

As a Safari user, I would really like to see this bug fixed. (I also tend to write articles with 100+ footnotes. It's a pain in the ass when you click on a footnote like [147] and get thrown past the end of the page. It makes the second half of the footnotes useless.) Is it possible for the template to detect what browser is displaying it? So that it could ignore the column number it's being displayed by Safari? ---- CharlesGillingham (talk) 04:51, 4 August 2008 (UTC)

An idea: could this bug be related to monobook.css is some way? I modified mine to make the footnotes smaller, at one point. I've reverted my monobook.css to blank, but, my footnotes are still small and the bug is still happening. Ring any bells?----- CharlesGillingham (talk) 07:04, 11 August 2008 (UTC)
As best I see, this is a bug in Safari. I don't know if this has been reported to Apple. --—— Gadget850 (Ed) talk - 10:20, 11 August 2008 (UTC)
I reported it some time ago using the "report bugs" feature of Safari. DuncanHill (talk) 11:37, 11 August 2008 (UTC)

IE, Opera and other issues

(Forgive me for creating a sub-topic here) ---- CharlesGillingham (talk) 04:51, 4 August 2008 (UTC)

Nothing can be done to make the columns work in IE or Opera. It is a CSS3 module (an Opera employee is the editor of the spec). When the browsers add support for the module then it will Just Work™, until then it degrades gracefully so there is no problem. BJTalk 17:50, 2 August 2008 (UTC)

I changed the table to reflect this. The only real bug so far is with the Safari links. --—— Gadget850 (Ed) talk -

Making 2 columns the maximum, would alleviate some of the problems associated with the inconsistencies (in display at different screen sizes). Could we at least do that somewhat soon? -- Quiddity (talk) 18:42, 2 August 2008 (UTC)

It's pretty trivial to add code to the template that would either detect anything greater than 2 and ignore it, or it could put all pages that use more than 2 columns in a category and a bot could make the changes. --MZMcBride (talk) 06:15, 3 August 2008 (UTC)
(Comment moved above) ---- CharlesGillingham (talk) 04:51, 4 August 2008 (UTC)

I just tried Internet Explorer 8 Beta 1 and it has the same issues. It does not show multiple columns and it does not change the font size, but it does fail gracefully. --—— Gadget850 (Ed) talk - 11:02, 4 August 2008 (UTC)

I don't know about you, but the 90% font size works just fine for me in IE7 (see image). What problems are you having with it exactly? SharkD (talk) 20:55, 4 August 2008 (UTC)

It has been reported that 90% displays at the same size as 100%, at least in some versions of IE with some fonts. As with seemingly everything else about this template, that bugs some people. Anomie⚔ 11:52, 5 August 2008 (UTC)
According to Microsoft, IE8 will not support CSS3 column layout.[9]. --—— Gadget850 (Ed) talk - 13:29, 11 August 2008 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Reflist/Archive_6&oldid=1141951964"