Wikia

Community Central

Admin Forum:List of all pages requiring references tag

Talk0
89,452pages on
this wiki

This Forum has been archived

Forums: Admin Central Index Technical Help List of all pages requiring references tag
Wikia's forums are a place for the community to help other members.
To contact staff directly or to report bugs, please use Special:Contact.


If a page has a <ref> tag, but no <references /> tag, this message is shown at the bottom of the page:

Cite error: <ref> tags exist, but no <references /> tag was found

Is there a way to list all pages which show this error, so they can be easily found and fixed? -452 21:08, November 14, 2012 (UTC)

Something like this: http://en.wikipedia.org/wiki/Category:Pages_with_missing_references_list -452 21:29, November 14, 2012 (UTC)
Just to be clear, my response was not to answer my own question, I still don't have a solution to the problem. -452 23:10, November 22, 2012 (UTC)
Do you actually need a list, or do you just want to directly fix the problem? If I thought about it for a bit, I could probably figure out how to generate a list, but the fix is pretty easy using pywikipediabot. You'd just type
python noreferences.py -start:!
and that would add <references/> that didn't already have it. If your wiki doesn't have any templates that incorporate <references/> like {{reflist}}, then that's it. You're done.
If you do have {{reflist}}, then this bot run will add <references/> needlessly, and you'll have to make a couple more runs, in this order:
  1. Remove <references/> on those pages where {{reflist}} is transcluded
  2. Convert all remaining instances of <references/> to {{reflist}}.
The first time you did this, depending on your wiki's size, and how widespread the error was, it'd probably take something on the order of hours to do a complete run. After that, it would be something you could run once a quarter in well under an hour. czechout@Wikia    fly tardis 16:58: Fri 23 Nov 2012
Actually that last bit is a lie. If you're using {{reflist}}, it'll take longer to run this method every time you run it because it'll add <references/> on an increasing number of pages, and you'll have to strip it away on even more pages. So it'll take longer each time you run it, according to this method. What's decreasing is the number of pages that actually need the fix. Still, it's really mindless bot work that runs in the background of what you're doing and that needs zero monitoring. There's almost certainly a way to tweak the code for references.py so that it will allow for {{reflist}}, and thereby eliminate this two-step correction process. But I've not looked at the code. czechout@Wikia    fly tardis 17:05: Fri 23 Nov 2012
Yeah, you can definitely modify noreferences.py so that it looks for {{reflist}} or <references />, and then adds just {{reflist}} directly on the page, which completely obviates the need for the two-step run. So basically you can, with slight modification, make it so that you have to just type
python noreferences.py -start:!
and that's it. It'll just go through every page, add {{reflist}} to every page that doesn't have it or <references /> — and that's the end of the story. The initial run will take some time, but then after that, it'll only target the pages that actually need the fix. Easy. Again, I've not got list generation for you, but if you need a copy of the modified no references.py file, lemme know, and I'll happily post it. czechout@Wikia    fly tardis 18:34: Fri 23 Nov 2012
Thanks for the replies! I agree that adding the references tag to all articles is probably a good idea, but it would be handy to have a list just in case the references tag ever gets removed from an article, without having the run that script again. (And I'm just using <references />, btw)
I can think of one way that generating a list that might work, I was really hoping someone had already done it - no sense in reinventing the wheel. -452 18:53, November 23, 2012 (UTC)
Now you mention it, if I used {{reflist}}, it would be really easy to list pages with DPL: notuses=Template:reflist would be all I needed. Maybe it's worth switching over to that. Thanks for the idea! -452 19:14, November 23, 2012 (UTC)
Yah, no matter if you just create a list or you actually directly run a fix script once a quarter, there's no doubt that {{tlx|reflist}] gives you more control than <references />. Not to mention the far greater formatting options inherent in using templates. Oh, and wikipedia now officially calls the HTML tag deprecated. czechout@Wikia    fly tardis 22:18: Fri 23 Nov 2012
Do you know of a way to solve the problem of odd-numbered or long references at the end of the first column flowing into the top of the second column when using reflist|2 ? (w:c:tardis:Eleventh Doctor has this problem too.)
  • Setting .references li to display:inline-block; removes the return arrow.
  • Setting .reference-text to display:inline-block; moves the reference to the line below the return arrow. (edit: and to the next column in some cases - similar to tardis:Eleventh Doctor)
  • Setting .reference-text to have a fixed width works for single use references, but pushes the text to the next line if the reference is referenced more than once.
  • It's possible that using javascript to wrap the contents of .references li in a display:inline-block; container will fix it, but I haven't tried that yet.
-452 16:13, November 25, 2012 (UTC)
Well, I've never honestly seen it as a "problem". It's just column wrapping. The issue at tardis:Eleventh Doctor is that ref notes 2-4 are raw URLs, rather than properly-formatted citations. Because they're raw URLs, there's no place for the reference to break, so you get the up arrow link in column 1 and the whole URL in column two. If you look at tardis:George Entwistle, you'll see a better example of a 2-column footnote section. Certainly, if you do "proper" citation, you create natural word breaks that don't make the occasional split-column reference note at all problematic. czechout@Wikia    fly tardis 16:47: Sun 25 Nov 2012
tardis:George Entwistle does not show the problem. Remove the 5th reference from that page and you will see what I mean. (Works in preview)
With only 6 references, no, there's no much of a problem since it's on the same page, but I'm looking at a page with an entire page of references and the top of the second column is not in view when looking at the bottom of the first. I guess I should see how wikipedia deals with it. (edit: Wikipedia doesn't deal with it, problem occurs there too 17:33, November 25, 2012 (UTC))
-452 17:02, November 25, 2012 (UTC)
I know tardis:George Entwistle doesn't demonstrate the problem. That's my point. The way you defeat the problem is to actually cite properly, or even with anything other than a naked URL, and the worst that will happen is that the reference will flow from the bottom of one column to the top of the next. That's not a typographical "problem" — that's just the definition of column flow.
It has nothing, really, to do with the number of references. If you have only one reference, and that ref is of sufficient length, {{reflist|2}} will stretch it across two columns. Play around with it and put in an impossibly long ref and you'll see what I mean. Also, take a look at tardis:List of stories recorded at BBC Television Centre. This one's split into four columns and there's plenty of column flow there. But it works because there are plenty of individual words (well, spaces, really) in the references, so the template knows how to break the reference in a readable way. czechout@Wikia    fly tardis 18:58: Sun 25 Nov 2012
Entwhistle6

6 refs - equal length = no overflow

Entwhistle5

5 refs - unequal length = overflow

Entwhistle1

1 ref - overflow to balance columns

Entwhistle2

2 refs, 1 long - overflow to balance columns

Then I do not understand your point. Unless your point is to illustrate that the problem does not always occur. To which I concur. As I originally said, it only happens with an odd number or with long references.
"and the worst that will happen is that the reference will flow from the bottom of one column to the top of the next."
Yes, this is the definition of the problem I am wanting to fix.
"If you have only one reference, and that ref is of sufficient length, {{reflist|2}} will stretch it across two columns."
Yes, one is an odd number.
To the right are a range of images displaying the problem under different circumstances. Citing properly has nothing to do with it. The problem is caused by having an odd number of the same sized reference, or an even number of differently sized references.
I've successfully solved the problem using javascript now, although a CSS solution would still be better. -452 20:21, November 25, 2012 (UTC)
Of course, they show the short version, here's a page effected by the long version. -452 21:31, November 25, 2012 (UTC)

What I'm saying is that I don't see your illustrations as problems. I see them as examples of proper column wrapping.

Normal wrapping has little to do with whether there are an odd or even number of citations. As can be seen at this diff, you get wrapping whether there are 12 or 13 citations.

Math break
Imagine you have a page where each citation is 2 lines long, but you're trying to decide between using five or six citations.

12 lines
÷ 2 columns
6 lines/column
10 lines
÷ 2 columns
5 lines/column

If you go with 5 citations, column wrap is going to be necessary. The first column can contain only the first two citations fully, equalling 4 lines, and the first line of ref#3. A split is necessary, but not because there are five references. The actual reason for the split is that you have five references of two lines each.

Now imagine that you had one ref that was 4 lines long, three that were one line long and one that was 3 lines long. You'd still have 10 total lines, so the math is exactly the same. You end up needing 5 lines/column.

But the result is totally different.

You would have ref#1 (4 lines) and ref#2 (1 line) completely on column#1, and the remaining refs would fit completely in column#2. So, in this case, an odd number of refs does not result in column wrapping.

The goal of {{reflist}} is to produce columns of equal height, so odd numbers of citations produce split columns only when the citations are all of the same number of lines. All the citations at tardis:George Entwistle are two lines long, so an odd number does throw things out of whack.

And odd numbers of refs would always produce split columns — if and only if you have an even number of lines in each ref. But {{reflist}} is simply doing basic math: #lines/#columns. If that quotient is odd, then you get column wrap. If it's even, you don't. So that's not a "problem". That's how it's supposed to work — and that bit of typographical math has been going on since the Gutenberg Bible. It really can't work any other way — unless you're prepared to accept columns that are not of equal height. But most designers would probably be wary of breaking with centuries-old typographic tradition unless there were some deliberate attempt to generally go with some sort of "jagged" bottom-of-page effect.

(As an aside, the very first example you gave of tardis:Eleventh Doctor is a problem, because the URL is defeating the proper operation of {{reflist}}. But the solution is in the individual editor using proper citation, not in fixing the js/css.) czechout@Wikia    fly tardis 23:24: Sun 25 Nov 2012
Thanks, but I already knew why it happens, I'm not sure why you think I didn't.
"What I'm saying is that I don't see your illustrations as problems."
Then that's all you had to say. (edit: oh, you did say, but I misunderstood because you linked a page that did not show the effect, so I thought you didn't understand what I was talking about. 00:00, November 26, 2012 (UTC)) The fact that you do not personally view it as a problem is irrelevant and does not help me, as I clearly outlined that I viewed this behaviour as undesirable, and wished to change it. During my google searches, I found many other people attempting to "fix" the same effect in different situations, and the answer was invariably to "wrap the content you do not wish to flow within a inline-block container", which is what I have done. (There is supposed to be a CSS property that deals with it directly, but it's not widely supported by browsers)
"unless you're prepared to accept columns that are not of equal height."
Yes, I am. I would rather have columns of slightly uneven height than have to scroll up to read the rest of the citation. I tested my fix on a copy of tardis:List of stories recorded at BBC Television Centre, and it works, and produces columns of wildly different widths, but I still think it looks better. -452 23:44, November 25, 2012 (UTC)
Yanno, until this post I never took it that you thought {{reflist}}'s behavior was merely "undesirable". When you kept referring to its default behaviour as a "problem", I thought you meant that you thought there was some kind of bug — some kind of actual error in the code. The little trip through the math was, I thought, useful because it demonstrated that there was no error. I thought it might have been helpful because your earlier posts had seemed to advance an almost-but-not-quite-right idea about the underlying arithmetic. I also thought it might address your earlier point where you seemed to think that Wikipedia might have addressed this issue. That indicated, to me, that you thought it was such an obvious error that the very Wikipedians who created {{reflist}} in the first place would have tackled it.
However, it turns out that you didn't think there was a bug. You were simply making a design choice. That's obviously a totally different thing. But it wasn't clear to me that you were simply electing a different design ethos until your latest post. I apologise for hugely wasting your time. czechout@Wikia    fly tardis 22:38: Mon 26 Nov 2012

Around Wikia's network

Random Wiki