Template talk:Reflist/Archive 23

Archive 20

Archive 21

Archive 22

Archive 23

Archive 24

Archive 25

→

Archive 30

Flowlist

See Wikipedia:Village pump (technical)/Archive 122#Problem with image formatting.

I added the flowlist class to the sandbox- this seems to have resolved the issue with IE11 at User:ProfReader/sandbox. --  Gadget850 ^talk 12:25, 1 January 2014 (UTC)

I would advice against it; it will cause the list to not flow properly around right-floating blocks as well, which is more common in articles. — Edokter (talk) — 12:59, 1 January 2014 (UTC)

And I was just testing that. I knew there would be something. --  Gadget850 ^talk 13:15, 1 January 2014 (UTC)

To fix issues like this (which are hopefully rare), should we recommend wrapping {{reflist}} in {{flowlist}} or add a parameter to enable the flowlist class only when needed? --  Gadget850 ^talk 13:59, 1 January 2014 (UTC)

I'd prefer a parameter (flow=1) that adds the flowlist class. Wrapping only results in more nested divs. — Edokter (talk) — 14:05, 1 January 2014 (UTC)

Agree. And you got there firstest. That works. --  Gadget850 ^talk 14:13, 1 January 2014 (UTC)

I will note that use of columns will result in the same behaviour as using flow=1. — Edokter (talk) — 14:17, 1 January 2014 (UTC)

Hadn't thought of that, but I understand why. --  Gadget850 ^talk 14:22, 1 January 2014 (UTC)

Makes me think... As {reflist|1} has the same effect, would a new parameter be needed? I feel it's parameter bloat (even tough I realize it has no effect in IE8/9). (EDIT: I could make flowlist class active only with columns enabled.) — Edokter (talk) — 14:35, 1 January 2014 (UTC)

How's that? Works as advertised in IE7/8 (can't test 9-11). No extra parameter needed, but need to adapt {{refbegin}} and {{div col}} as well. — Edokter (talk) — 14:51, 1 January 2014 (UTC)

Strike that. Using flowlist in any manner clashes in Firefox; overflow-x forces a singel column. I'm out of ideas. Let's just not put anything left from lists... — Edokter (talk) — 15:10, 1 January 2014 (UTC)

1 column works in IE11. This seems to be the simplest fix. When implementing for this fix, I suggest a comment be added so that follow on editors understand the use. --  Gadget850 ^talk 15:37, 1 January 2014 (UTC)

Documented. Tweak as needed. --  Gadget850 ^talk 16:09, 1 January 2014 (UTC)

List-defined refs in subpage

I was just fantasizing about being able to manage my LDR in a separate subpage of the article. Is this possible now (with or without hacks), and am I missing why it would be a bad idea? czar ♔ 06:42, 4 January 2014 (UTC)

For one thing articles can't have subpages (not sure why that was done -- see Wikipedia:Subpages). EEng (talk) 08:38, 4 January 2014 (UTC) Be careful about your fantasizing on WP topics -- it can become unsavory: User:EEng#.28thumbs_up.29

So we wouldn't have situations like Input/output being a subpage of Input, probably. And possibly so people wouldn't think they could create Foo/sandbox and not have it be considered an article in its own right by the software. Anomie⚔ 12:42, 4 January 2014 (UTC)

It's probably possible now, you should theoretically be able to shove the revs in a template and transclude that template into |refs=. But it would make it harder for people and bots to maintain those refs, and would run into the same sort of community opposition that makes it so infoboxes aren't more widely shoved into templates and transcluded (I think I've only seen that on some chemistry-related articles). Anomie⚔ 12:42, 4 January 2014 (UTC)

There was certainly a discussion on this exact matter in the last year or two, but I don't recall where (that's the problem with discussions about referencing - there are six or seven potential venues). IIRC the outcome was a definite No. --Redrose64 (talk) 15:01, 4 January 2014 (UTC)

I know this is drifting offtopic, but perhaps someone can point me elsewhere or be inspired to figure out a solution. Once in a while it would be handy to have a special template just for one article e.g. in Malcolm X the idiom Malcolm X is used a zillion times. Would be helpful if {{MX}} could be defined to stand for that. Obviously such a template is useful only if its name is very short, and that immediately means naming conflicts if such templates shared the giant common template namespace.

If articles could have subpages then the template could be e.g. {{/MX}}. That gives it local scope and avoids the naming conflict problem -- and it's not an "overloaded" name so a "general" template {{MX}} is still available with no special attention. Just a thought I wanted to throw out. EEng (talk) 18:10, 4 January 2014 (UTC)

We have had at least one article where all the references were transcluded from a Wikiproject page. I need to look that up and see what happened. There was some controversy about that. As noted, subpages don't work in article space, but there has been at least one suggestion that a talk subpage be used. There are quite a few single-source citation templates extant. --  Gadget850 ^talk 19:58, 4 January 2014 (UTC)

I'm startled to hear that an article has been allowed (by humans -- I realize the machinery exists) to call anything outside article space + template space as a template, as it blurs the boundary between article content seen by naïve readers vs. all the messy machinery clanking around in the background that we sophisticates see.

By "single-source cite template" I take it you mean a special template just for e.g. the Bengazi Journal of Trauma Surgery or something like that with narrow application. If so, that's not analogous because if the template's main reason for being is to handle something that's hard to handle otherwise, it doesn't matter if that template has a long, highly qualified name. But in my example it's essential that the template have a 1- or 2-charater name, and thus the need for a per-article namespace.

For the same reason it wouldn't help to have the template be beneath the article's Talk, since at best the syntax would be {{Talk:Malcolm X/MX}} (or whatever -- I forget the syntax -- maybe another : in there somewhere).

This isn't worth too much trouble on your part but if you can point to the examples or discussions on these things, without too much effort, that would be appreciated. EEng (talk) 23:07, 4 January 2014 (UTC)

Was there a change here recently?

Did something about this template change recently? It used to be that, where you had two or more columns, the text of a footnote that began in one column would carry over into the next. Now, each column begins with a new footnote, so that we're left with a lot of white space. Example at the end of this Notes section. SlimVirgin ^(talk) 16:46, 24 November 2013 (UTC)

Yes. CSS was added in Common.css that would prevent breaking up a list item over two columns. In Chrome, this may sometimes result in some extra whitespace below the list. — Edokter (talk) — 17:05, 24 November 2013 (UTC)

It's the page-break-inside property.

In this specific case, I consider ref 94 to be of excessive size. First, that lengthy quote can be cut down - or dropped entirely; then, the four bullets can be made into separate refs. --Redrose64 (talk) 17:53, 24 November 2013 (UTC)

I appreciate the no-break-inside behavior - refs should generally not be split across columns. A little proper widowing (in the rightmost column only) way down at the bottom of the article is acceptable (to me). I concur about too-long quotes, though. IMHO, large quotes should be either shortened, moved to the article body, moved to a separate footnotes section, or a combination of shortened and moved. I've seen some egregiously massive footnotes, can't remember now. Will revisit. --Lexein (talk) 13:26, 25 November 2013 (UTC)

Looks like a widow may still appear under certain circumstances, such as a single reference formatted as two columns.[1] This is obviously a bad use of columns in this instance. --  Gadget850 ^talk 15:15, 29 December 2013 (UTC)

Over and over I see this: someone points out a problem, as here, and the techies' response is "Well, footnotes shouldn't want to do that". For crying out loud! We value your technogeek skills but, in general, you're not competent to make sweeping, lofty pronouncements about what is and is not acceptable article content or layout.

The new no-break-over-columns behavior looks awful, with the column lengths jaggedly uneven. Just put it back the old way. If you can put in widow/orphan protection that's fine, but even if not, put it back the old way so that the column lengths are even (or, if there is w/o protection, almost even).

Or if there's a way (as I vaguely gather, from the above, may be the case) to add some magic parameters to control the splitting or not splitting, please document those.

EEng (talk) 21:56, 30 December 2013 (UTC)

No magic parameters, sorry. The main reason this was implemented is to increase readability; there is nothing more annoying then reading a ref in a long list of refs and then having to scroll up several pages to continue reading that same ref. — Edokter (talk) — 22:30, 30 December 2013 (UTC)

(edit conflict)

• The CSS rule that was added applies to all column layout, not just references.
• Please provide an example, as I haven't seen any issues, except where the reference is overly long.
• I do have Preferences → Beta features → Typography refresh enabled, which does seem to have some effect on column layout. You may want to give that a try and see what it looks like. --  Gadget850 ^talk 22:35, 30 December 2013 (UTC)

To be more precise: it applies to list items in columns. — Edokter (talk) — 22:56, 30 December 2013 (UTC)

It's incredible. I JUST SAID how offensive it is to dismiss problems by pontificating on how the user shouldn't want to do something, because articles ought to be this or that way, and your notes must be excessively long, or other stuff like that -- and here we are two posts later hearing the same thing again! It's OK if you don't agree with me, but it's not OK to repeat the same thing not even acknowledging what I said -- it gives the distinct impression that you don't read what other people are saying.

Look, I understand what Edokter is saying about scrolling back to continue reading the note that breaks over the column, but notice that the longer that annoying scrollback is, the smaller that one note is as a proportion of all notes e.g. if there are 5 notes, that's not far to scroll back (and anyway you only have to do it when reading the one note that's broken); while if there are 30 notes, yes that's a long way to scroll, but as before only one note will be broken, and (in a sense) when reading a random note you have only 1/30 chance of it being the one requiring scrollback. I would much prefer that occasional scrollback to seeing those two jagged uneven columns every time I pass over them to see the external links or whatever. EEng (talk) 00:44, 5 January 2014 (UTC)

You've stated how "awful" it looks, but you have not offered example articles to look at which starkly illustrate the issue you're describing. IMHO, breaking refs are bad. I could (again) explain what causes ragged no-break multicolumn reflists, and how proper authorship can fix them in a way which (IMHO) is superior to breaking refs, but that would be redundant, and would annoy you. Let's see your examples. --Lexein (talk) 02:56, 5 January 2014 (UTC)

No examples are needed -- we all know what we're talking about: break one note in the middle to keep columns equal, or wait until then end of the current note before starting the new column. It's an aesthetic choice. My point is that it's not acceptable to dismiss one point of view by preempting it with the statement that "you shouldn't be doing that anyway." Having said that I've decided this is too geekish an issue for me to get involved with. EEng (talk) 00:22, 7 January 2014 (UTC)

The general philosophy here is accessability over aesthetics, even though not everyone always agrees. We don't use columns for running text for obvious reasons; it's hard to read. We do use columns for references because they save space, but without the disadvatages of having to jump columns to read them. Even without this feature, columns may end up being 'jagged' if the total number of lines is uneven. — Edokter (talk) — 11:10, 7 January 2014 (UTC)

Welcome to engineers. When you drive a tank over their footbridge, they'll tell you not to do so. Even if you have already driven over the the bridge a hundred times before, we like to point out that the thing simply wasn't built to do that. If given enough space they might built you one that CAN be used to do that though. It just might not look the same and be in a different spot across the river and cost a fortune in comparison. Usually this ends up with the people continuing to drive the tank over the bridge and engineers unable to stop them and being amazed that it actually holds for over 30 years. Then 4 people die when the tank goes into the depths and the government demands the new bridge that the engineers had been suggesting all along, but it to be finished in an unreasonable time with unreasonable features. :D two worlds... —TheDJ (talk • contribs) 01:04, 7 January 2014 (UTC)

Proposed change to "Multiple uses" doc

Per this discussion I'm proposing changing the the Multiple uses section to

If a single page contains multiple invocations of {{reflist}} (or variants such as {{Notelist}}), each invocation should specify |close=1 e.g.

• {{reflist|close=1}}
• {{reflist|close=1|group=Note}}
• {{notelist|close=1|35em}}

Otherwise unpredictable behavior, which may change in the future, will result/ Such behavior may include appearance of the message

MediaWiki:Cite error refs without references

or duplicate output of references.

I know the error message "quote" isn't quite right. Can someone remember how to trigger it? EEng (talk) 22:27, 30 December 2013 (UTC)

What quote? If you mean the Cite error refs without references error, then it is transcluding properly. --  Gadget850 ^talk 13:18, 1 January 2014 (UTC)

I don't know what I was thinking. EEng (talk) 13:37, 1 January 2014 (UTC)

<bump> If I don't hear anything soon I'll install this new text live. EEng (talk) 00:21, 5 January 2014 (UTC)

No, please don't: as noted at Wikipedia:Village pump (technical)#Special:ExpandTemplates gives different page preview, advocating the use of |close=1 is unnecessary and likely to cause confusion. There is no need to give complicated advice when it can be simpler. --Redrose64 (talk) 00:32, 5 January 2014 (UTC)

Well, thanks for remaining silent until the last possible moment. Here's the last part of the discussion from Village Pump. Too bad no one responded there at the end -- maybe you will now.

[Proposed text by Gadget]:

If {{Reflist}} is used multiple times without a parameter, each subsequent use will repeat the output of the first instance due to template caching. This may also result in a misleading error message:

MediaWiki:Cite error refs without references

Where a page include multiple uses of {{Reflist}}, each subsequent use should include at least one parameter, such as refs or group. If these parameters are not appropriate, then the practice is to use {{Reflist|close=1}}. Do not use close without the =1, as it will be parsed into the column-width.

--  Gadget850 ^talk 14:14, 26 December 2013 (UTC)

Again, here's my proposed wording from a few posts back, slightly modified:

If {{reflist}} is used multiple times on the same page, each invocation must specify |close=1 e.g.

*{{reflist|close=1}}

*{{reflist|close=1|group=Note}}

*{{reflist|close=1|35em}}

Otherwise unpredictable behavior, which may change in the future, will result. (Symptom of not doing this are sometimes the message MediaWiki:Cite error refs without references, or the same list of references output twice.)

Gadget, what in the world is the point of all that complex explanation? Why tell the user about caching, and document the repetition of the reflist contents as if it's a feature to be supported in future??? If we're gonna warn them "do not use close without the =1", then why not warn them "do not use the German Schließen instead of close", or "do not misspell Reflist"? I'm serious. What's all that stuff get us? Please explain. (I suppose we could put a footnote -- no kidding -- giving a technical explanation for those interested.) EEng (talk) 20:35, 26 December 2013 (UTC)

I have no better wording. And I don't know why the Mediawiki page isn't rendering for you, but the way you modified it certainly breaks it. --  Gadget850 ^talk 02:02, 27 December 2013 (UTC)

You have no better wording than what??? Which wording are you talking about -- yours or mine? Are you saying mine is OK, or you prefer yours? And if the latter, why? Can you please give a straight answer so we can be done with this? EEng (talk) 14:26, 27 December 2013 (UTC) P.S. Not that it's a big deal, but the errmsg as you had coded it didn't show up at all on both IE and Chrome (whether I was logged in or not).

<bump> EEng (talk) 15:38, 29 December 2013 (UTC)

I added "confusingly" to the current documentation. --  Gadget850 ^talk 16:43, 7 January 2014 (UTC)

30em versus 2

I am very much involved with translating medical articles into other languages. 30em is not support while 2 is. Thus I typically use the later. Is there any preference? Doc James (talk · contribs · email) (if I write on your page reply on mine) 03:18, 11 January 2014 (UTC)

Other language Wikipedias may not have a version of Reflist that has all the features of the one here. What language are you using? --  Gadget850 ^talk 11:02, 11 January 2014 (UTC)

I am working on the 60 languages listed here.[2] So far we have translated more than 3 million words of text. Will stick with the simplier format than. Some in fact only accept the even more basic <references /> Doc James (talk · contribs · email) (if I write on your page reply on mine) 14:18, 11 January 2014 (UTC)

Just glancing at the versions of Reflist:

• German does not exist
• French, Chinese, Hindi, Indonesian, Macedonian, Tagalog seem to have most of the features
• Persian uses formatnum ro rationalize column-width and column-count and has a font size feature
• Swedish has a very basic version

And I know there is at least one version that includes the heading. And then there is the supporting CSS which would vary. --  Gadget850 ^talk 14:53, 11 January 2014 (UTC)

Yes Wikipedia very much would be easier if there was greater consistency in markup across languages. I know however that some want great inconsistency to prevent translation. This however is unfortunate IMO. Doc James (talk · contribs · email) (if I write on your page reply on mine) 15:52, 11 January 2014 (UTC)

To return to your question "is there any preference?": the policies, guidelines and practices of English Wikipedia have no bearing over what is preferred at Wikipedia in other languages; indeed, some of our preferred practices are contrary to the preferred practices elsewhere. You would need to find out at those other Wikipedias if they have any preference of their own. --Redrose64 (talk) 16:32, 11 January 2014 (UTC)

Sure I am trying to keep what we do within Wikiproject Medicine in English compatible with other languages. Am not suggesting any change in formatting in those other languages. Doc James (talk · contribs · email) (if I write on your page reply on mine) 17:11, 11 January 2014 (UTC)

Surely if a target width is available (i.e. on en-wp) it should be preferred over a fixed number of columns, because it produces better results on a range of viewing devices. Kanguole 15:50, 20 January 2014 (UTC)

Ref style is determined by discussion on the talk page. Translation is of greater importance and we should keep thing simple. Doc James (talk · contribs · email) (if I write on your page reply on mine) 00:26, 21 January 2014 (UTC)

Doc James, as Reflist isn't portable, restricting to "|2" instead of "|30em" doesn't seem to gain much portability, at the cost of better layout on en.wiki due to fixing a manual number of columns instead of automatic. Widefox; talk 00:33, 28 January 2014 (UTC)

As there is no consensus that "|30em" is prefered, which is used should be left to the primary editors of the article. Doc James (talk · contribs · email) (if I write on your page reply on mine) 00:36, 28 January 2014 (UTC)

Absolutely. There's a column feature request for <references /> [3] which (if implemented) will be portable across all wikis. Widefox; talk 03:00, 28 January 2014 (UTC)

Great. That would be excellent. Doc James (talk · contribs · email) (if I write on your page reply on mine) 03:45, 28 January 2014 (UTC)

Capitalized <ref> causes extra backlink

When using List-defined references and {{reflist}}, if the <ref> tag is capitalized in any manner (Ref, REF, reF, etc.) then an extra backlink is created that does not have a matching anchor:

Markup	Renders as
<ref name=foo/> {{reflist|refs= <Ref name=foo>Reference 1</ref> }}

But if <references> is used, then the extra backlink does not occur:

Markup	Renders as
<ref name=foo /> <references> <Ref name=foo>Reference 1</ref> </references> }}

--  Gadget850 ^talk 15:34, 6 March 2014 (UTC)

My best guess is a bug in how #tag:references is handled. — Edokter (talk) — 16:11, 6 March 2014 (UTC)

That's it. Filed T64335 - Using capitalized <ref> inside reference list creates extra backlink

Markup	Renders as
<ref name=foo/> {{#tag:references|<Ref name=foo>Reference 1</ref>}}

--  Gadget850 ^talk 18:03, 6 March 2014 (UTC)