Talk:Cite/Cite.php

Problem installing

I put Cite.php in my extensions directory, and added the line "require_once("extensions/Cite.php"); to my LocalSettings.php, and now my wiki gives me this error:

Fatal error: Call to undefined function: wfmsgforcontentnotrans() in mediawiki-1.5.5/extensions/Cite.php on line 572

Any ideas? --69.237.153.190 06:34, 19 January 2006 (UTC)

Okay, I think I found out what was missing. includes/GlobalFunctions.php looks like it's old in mediawiki-1.5.5.tar.gz - I'm going to try grabbing just that function. --69.237.153.190 06:55, 19 January 2006 (UTC)

Well, it looks like it's harder than I thought to enable this on v1.5.5. I guess I'll wait till it is in the normal build. --69.237.153.190 07:15, 19 January 2006 (UTC)

It depends on changes in the parser itself, how hooks are added to the parser, hooks in the parser, behaviour in the sanitizer & parser all of which are in CVS HEAD and not in REL1_5 (that list if just of the top of my head), if you want to use it you'll either have to backport the needed changes or use CVS HEAD. I do work for hire if you need someone for the former;) —Ævar Arnfjörð Bjarmason 02:42, 21 January 2006 (UTC)

I have not understand. Same problem as above. Is the cite.php not for mediawiki 1.5.5 ? --Farm 04:13, 24 January 2006 (UTC)

No. —Ævar Arnfjörð Bjarmason 08:43, 29 January 2006 (UTC)

The CVS HEAD source code has not the endding code "?>", why? 14:00, 24 Jan 2006 (UTC).

I forgot to add it. —Ævar Arnfjörð Bjarmason 08:43, 29 January 2006 (UTC)

No response

I put the cite.php in the extensions directory and added the reuqired_one line in the localsettings.php and noting happens. No footnotes appear and the <ref... is shown in the article! Any suggestions? Thanks!

Multiple quotes from same source (<ref/> Wish)

I'd like to quote the same source multiple times. If there would be a <ref name=id />, it could only generate the citation, but use the inner part of a previous <ref name=id >blahblah</ref>. In the next step it would be great to use this for referencing definitions on other wiki pages, i.e. <ref name=/TheOtherArticle/id />. Additionally generating a printable version or PDF from a wikipedia article gets easier, too.
-- Herbert 19:40, 14 January 2006 (CET)

You obviously haven't tried doing that first part, because it works perfectly (and is used in the example here). I don't understand what you mean in the second part (sorry)… Jon Harald Søby 18:50, 14 January 2006 (UTC)

Wish

In my browser (IE and Firefox) in Win XP, I see:

Uranus's moons were observed to be declining in orbit[1], by the Hubble space telescope[2], the Martians were not avalible for comment on the matter[3]. The New York times[4] however reported[5] that ...

1. ^ NASA

2. ^ 1 2 December 2005 issue, page 12

3. ^ 1 2 January 2006 issue, page 16

Could it be

• ^ 1 NASA

• ^ 2 3 December 2005 issue, page 12

• ^ 4 5 January 2006 issue, page 16

,I mean, the number in the references should correspond to the number in the text?

Thanks193.52.24.125 13:29, 28 December 2005 (UTC)

You might want to reply on Ævar's English Wikipedia talk page, there's some discussion there about this right now: en:User talk:Ævar Arnfjörð Bjarmason. —Locke Cole • t • c 21:15, 28 December 2005 (UTC)

Second wish

It's long been said by people opposed to increased usage of inline citation that inline citations damage readability. I'm somewhat sympathetic to that, and the easy solution is to have a way for the people that want to to make inline citations invisible. Would that be hard to implement as a user preference for example? Or is there a better way to do that? Thanks - Taxman 16:35, 31 December 2005 (UTC)

It's already a user preference, you just have to add

span.reference { display: none; }

Or something like that to your user stylesheet. —Ævar Arnfjörð Bjarmason 17:43, 31 December 2005 (UTC)

A better method may be to add another parameter that allows individual citations to be hidden. This would allow for an article author to fully reference each paragraph, or even every sentence, and still keep the number of footnotes generated at a reasonable level. If this is impractical to implement, we can still use HTML comments. --Allen3 23:36, 31 December 2005 (UTC)

The whole point of the extension is to be able to maintain an automatically generated references table just like one can maintain an automatically generated table of contents in the software, if you're not going to use that (the only) feature and don't want display any references in the article at all then you're probably best off with a simple inline comment, unless I'm misunderstanding you. —Ævar Arnfjörð Bjarmason 15:25, 12 January 2006 (UTC)

I would restate this a different way. Is it possible to have a citation level variable. E.g. 0/1/2.. or none/default/all or none/few/default/lots/all where citations will be displayed according to the setting. The default level would be a sensible level which gives reasonable citations without going overboard. The "all" level would be something which makes fact checking very easy. Mozzerati 22:10, 17 February 2006 (UTC)

<ref> can't be used in image captions

Code of the form [[Image:Yagan.jpg|thumbnail|''Portrait of Yagan'' by [[George Cruikshank]].<ref name="Dale 1834">Dale 1834, p 1</ref>]] misrenders disastrously. Snottygobble 12:06, 2 January 2006 (UTC)

That's a known issue with the parser and doesn't have anything to do with this extension in particular, except that it affects it. I made a known issues section at Cite/Cite.php to track these. –Ævar Arnfjörð Bjarmason 07:02, 3 January 2006 (UTC)

Bugs? Or operator error?

I really like this new feature, but I'm having trouble getting it to work consistently. This is particularly a problem when a single reference is used more than once. The article I'm trying to fix is Dixie (song). As you can see, there are six page citations that repeat at least once (Notes 4, 17, 28, 58, 69, and 84). However, when you click on the reference links by these repeaters, nothing happens (the page does not pop up or down properly like it does with the page citations that are used only once). Secondly, Note 17 should read "Quoted in Abel 36.", but currently it says nothing. Likewise, Note 72 should read "Abel 49.", but it too is blank. Can someone tell me if I'm doing something wrong? Thanks . . . . — BrianSmithson 19:25, 6 January 2006 (UTC)

This was a known issue with MediaWiki which happened not because you were using references more than once but because you were using a character (0x20) that needed to be escaped. I've fixed the issue in MediaWiki that caused this.

As for your other issue that is indeed a user error, you can't recall a reference later in the text by its content, only by a key you provide, so <ref>foo</ref> <ref name=foo/> won't do what you seem to expect it should. But <ref name=foo>foo</ref> <ref name=foo/> probably will. —Ævar Arnfjörð Bjarmason 09:55, 7 January 2006 (UTC)

HTML format

This cite stuff is totally cool. But I have a few suggestions about the way the HTML code is formatted. —Michael Z.

Hi an thanks for the suggestions and sorry for the late reply, I saw this a few days ago but hadn't gotten around to replying. —Ævar Arnfjörð Bjarmason 14:44, 9 January 2006 (UTC)

<cite> element

Each note should be enclosed in an HTML <cite> element, since it is a citation. Since the in-text citation marker is linking to the citation, perhaps the note ID should be an attribute of the cite, rather than of the list item (<li>):

 <li><cite id="_note-NoteID">Note</cite><li>

—Michael Z.

If you check the history of the file you'll see that what you suggest used to be the default but after reading a bit more up on the element in the W3C standards (see links in the file) and after some comments on the English Wikipedia I changed it again.

The reason it's not in there is because the cite element should only ever be used for a direct citation, and since users are likely to do something like:

<ref>Page 52 of XYZ written by Foo, the only remaining copy of this book was lost in the great fire of Bar</ref>

I.e. include something that isn't directly relevant to the citation (the fate of the referenced work in this case). If the software were to automatically wrap things in the cite element you'd end up with a lot of mismarked text, so now users are expected to simply write:

<ref><cite>Page 52 of XYZ written by Foo</cite>, the only remaining copy of this book was lost in the great fire of Bar</ref>

—Ævar Arnfjörð Bjarmason 14:44, 9 January 2006 (UTC)

Okay, I see; this is also meant for footnotes, not just citations. But I don't see any harm in an HTML citation also containing a bit of explanatory text, like in your example. —Michael Z.

Back-link text

The back-link text is currently the single character ^ (U+005E CIRCUMFLEX ACCENT)—this is not an arrow, and doesn't really look like an arrow. It's a w:circumflex, a diacritic used in some languages, and on its own indicates mathematical exponentiation in primitive ASCII-only displays. For the sake of its meaningless semantics (therefore poor accessibility), as well as sheer graphical ugliness, let's change it to ↑ (U+2191 UPWARDS ARROW), or ← (U+2190 LEFTWARDS ARROW).

See also:

• Daring Fireball: About the Footnotes
• Daring Fireball: Notes on Notes
• Joe Clark: There’s no such thing as a footnote

I agree that a proper mark should be used, but the replacement you mentioned (↑) looks way too large and not as neat as ^, ← on the other hand doesn't convey anything meaningful, the link is up, not to the left. Do you have something like ↑ that doesn't look so big (a bit more like ^)? —Ævar Arnfjörð Bjarmason 14:44, 9 January 2006 (UTC)

I don't think there are any smaller arrows, although an arrow could be made smaller using CSS formatting. See en:Template talk:Ref#^ revisited for some of the others, but MSIE/Win has trouble rendering most of them, without extra help from CSS.

Putting the arrows at the end of the note will make them less prominent, because they won't be all lined up (see below). —Michael Z.

And the back-link text should definitely not be superscripted; typographers use that for in-text citations only, never for footnote labels. —Michael Z.

You're suggesting[1] stuff[2] like this instead (i.e. rendering it the same way as the surrounding text)? —Ævar Arnfjörð Bjarmason

Superscripts are appropriate for the in-text citation references, but footnote labels should not be superscripts. "Back-links" don't appear in standard typography, but it makes sense that they should not be confused with citation references, possibly leading readers to look for another notes section below. —Michael Z.

Back-link position

The back-link looks like a label at the beginning of each note. But the note already has a number label. The back-link is an interface feature attached to the note, and subordinate to it. It belongs at the end. Don't the examples 4 to 6 below look better? Or if the arrow alone seems like too small a mouse-click target, put it in brackets so it is graphically associated with the citation link, like example 7 and 8.

1. ^ Bloggins, Joe (2006). Old-fashioned carat back-links. Oldville: Tradition.
2. ^ Brown, Sam (2006). At the beginning of the line: look like labels. Oldville: Tradition.
3. ^ ^{3.1 3.2} Smith-Jones, John (2006). Attract attention and misalign authors. Oldville: Tradition.
4. The Great, El Borbah (2006). New-fangled back-links. Newtown: Innovation. ↑
5. Verne, Jules (2006). Citations start with authors name: just like in books. Newtown: Innovation. ↑
6. Who, Joe (2006). Back-links are visually subordinate to the note's content. Newtown: Innovation. ↑6.1 ↑6.2
7. Heinlein, Robert (2006). Brackets look like the in-text citations. Newtown: Innovation. [↑]
8. Asimov, Isaac (2006). Brackets help visually associate notes with back-links. Newtown: Innovation. [↑8.1] [↑8.2]

—Michael Z.

Mm, matter of taste really, I like having all the backlinks in the same row for quick jumping up & down in the article. If by "The back-link looks like a label at the beginning of each note. But the note already has a number label." you're referring to the rational numbers in #3 then you don't need to use numbers at all, the system allows for using custom labels (defined in cite_references_link_many_format_backlink_labels) in cite_references_link_many_format using the 3rd paramater ($3) so you could have something like this as well:

1. a b Text of citation

Regarding the different styling of arrows (again) I really don't like to put myself in the position of deciding what should be the default. I just used the styling that was being used in the Ref and Note templates in enwiki at the time and I think the manual of style talk page is a much better venue for discussing how it should look, if editors are generally happy with something else than the current default I'd be quite happy to change the default in the software. —Ævar Arnfjörð Bjarmason 14:49, 12 January 2006 (UTC)

Title attribute for the back-link

The back-link currently contains an empty title attribute, which prevents it from showing a pop-up 'tooltip'.

 title=""

Readers are used to looking for tool-tips in puzzling interface elements. Why not put some meaningful information there, which would help users figure out what this is? How about something like:

 title="Jump back to footnote 1 in the text"

—Michael Z.

This is actually a "feature" of wikitext rather than this extension, and since it's basically just a macro that generates wikitext (from a final output point of view) the extension itself doesn't have control over the title attribute, it just sends wikitext to the parser for rendering. You'll notice that the same thing happens when you put code like [[#foo|bar]] on a normal page. I've added this to the issues list so that people are aware of this. —Ævar Arnfjörð Bjarmason 14:57, 12 January 2006 (UTC)

Parsable ID, using hyphens

If the ID assigned to the notes used the hyphen as a separator (instead of underscore), then it could be parsed using the CSS2 Hyphen Attribute Value Selector. [1] The current format is like the following:

 <li id="_note_NoteID">Note<li>

If it instead used a hyphen to separate the parts:

 <li id="_note-NoteID">Note<li>

Then all notes could be formatted using a CSS selector like this (in a modern browser; MSIE/Win doesn't support this):

 li[id|="_note"] { . . . }

—Michael Z.

I didn't know you could do that, I've fixed it. —Ævar Arnfjörð Bjarmason 15:21, 12 January 2006 (UTC)

The hyphen-attribute selector is CSS2; supported by Firefox, Safari, Opera, but not MSIE. Thanks for changing it. —Michael Z.

Order of references

Is there any way to control the order in which the references appear at the end ? In Maharajkumar of Vizianagram for instance, references 2-5 are in the different parts of the article but since they are all from the same book, they are listed together at the end. Will I be able to do the same with this scheme ? 208.246.215.5 00:04, 11 January 2006 (UTC)

Flushing of previously-used references

One nice feature to have would be a flush attribute to <references />, so that using <references flush="yes" /> would delete all of the previously-used citations. This would be useful in en:Comparison of operating systems, for example, where each section has footnotes. æle ✆ 20:53, 13 January 2006 (UTC)

That would actually be pretty neat, although it's hard to do because you can't guarantee top-down parsing (and it being consistent with other tags) when you have multiple tags. —Ævar Arnfjörð Bjarmason 21:27, 14 January 2006 (UTC)

Maybe you could have "types" of references, so that you could have <ref type=book>{{Book reference…</ref> and <ref type=web>{{Web reference…</ref>, then display them with <references type="book"/> and <references type="web"/>. You could then have <references type="all"/> display absolutely everything, and <references/> display those without a specified type. HTH HAND —Phil | Talk 12:19, 17 January 2006 (UTC)

Wikitext is not HTML

This reference style is contrary to the spirit of w:wikitext, which is supposed to be free of such line noise. It renders pages uneditable (by novices and experienced editors alike) and unmaintainable. Is there a poll somewhere where this abomination can be opposed?

chocolateboy 05:30, 21 January 2006 (UTC)

Er.. well, a Wikitext way of handling this wasn't obvious, and there are other HTML/XML style tags in use in Wikipedia (see <charinsert> for example, or <gallery>, etc). I strongly disagree with your assertion that it makes pages "uneditable and unmaintable". HTML is well known, and it made more sense to use an HTML-like syntax than to use some "abomination" that was non-obvious or difficult to use/type. Using HTML-style markup also makes it easy to extend the syntax (add additional attributes to the psuedo-tags). —Locke Cole • t • c 08:55, 21 January 2006 (UTC)

Can you cite some specific issues you have with it? "contrary to the spirit of wikitext", "line noise", "uneditable" and "unmaintainable" are all big statements but you fail to provide anything to back them up. What exactly do you have an issue with and how should that be fixed? —Ævar Arnfjörð Bjarmason 01:40, 22 January 2006 (UTC)

---

a Wikitext way of handling this wasn't obvious

What's wrong with plain old {{ref|foo}} and {{note|foo}}?

Which flavour of footnote did you actually have in mind?

This and this (and also this and this which describe obsolete systems which apparently are still operational even though deprecated) show no less than five tags for creating a reference (and I might have missed one):

1. {{Template:ref}}
2. {{Template:ref label}}
3. {{Template:fn}}
4. {{Template:an}}
5. {{Template:mn}}

each of which must be coupled with the correct corresponding tag for the footnote to work properly.

There are also various systems in place for renumbering footnotes; it is unlear which of the above tags each system will sort properly.

Replacing this lot with a single uniform method would seem to be an excellent idea. HTH HAND —Phil | Talk 12:48, 23 January 2006 (UTC)

What exactly do you have an issue with and how should that be fixed?

Isn't it obvious? See the debate over HTML entities for endash and emdash on w:Wikipedia talk:Manual of Style (dashes) for long prior discussion of this issue. Wiki means "quick", and wikitext is supposed to be quick and easy to edit by nontechnical users. This solution betrays both of those principles. Sure, we could all write markup in XML, which would provide the ultimate in flexibility and expressiveness, but that's not the Wiki way:

The source format, sometimes known as "wikitext", is augmented with a simplified markup language to indicate various structural and visual conventions.

The reasoning behind this design is that HTML, with its many cryptic tags, is not especially human-readable. Making typical HTML source visible makes the actual text content very hard to read and edit for most users. It is therefore better to promote plain-text editing with a few simple conventions for structure and style.

&c.

Also, I don't understand why this is being discussed here rather than on Wikipedia.

Because "Wikipedia" (I'll presume you're meaning enwiki) is one of approx. 800 Wikimedia projects that use this and this is also used outside Wikimedia, the metawiki is an appropriate place to discuss issues relating to more than one project. —Ævar Arnfjörð Bjarmason 16:44, 22 January 2006 (UTC)

chocolateboy 05:24, 22 January 2006 (UTC)

Chocolateboy - please see the comparison between ref/note and Cite.php style I just added to the page. In fact, Cite.php is about as close to ref/note style as is possible, and it provides a number of advantages(which I can list, or you can just look at the page). I suppose a syntax like {{ref|name of note}}text of note{{endref}} and {{references}} could be used, but really, is that so much more evil than <ref name="name of note">text of note</ref> and <references/>? And others can probably provide reasons why even that syntax would have problems(i.e. it would look like a template, but actually be MediaWiki code, and probably some more subtle ones, too). What was your objection, again? JesseW 08:21, 22 January 2006 (UTC)

The comparison only demonstrates that this solution is redundant as well as contrary to the spirit of wikitext, which is supposed to be easy to edit. And yes, it is much more evil for the reasons outlined above, which is presumably why it's been snuck in without discussion.

No it does not, the purpose of this tool is to provide a way to automatically generate a table of references, something you'd have to do manually with the tools you suggest. And as a general note could you please avoid snide comments like "snuck in without discussion." (you'll find there has been plenty of discussion and announcements if you do some searching) as well as accusing me of some conspiracy to make people use Dreamweaver (below), please stay on topic. —Ævar Arnfjörð Bjarmason 16:44, 22 January 2006 (UTC)

What was your objection, again?

See Wiki and Wikitext:

MediaWiki, the software that runs Wikipedia, has a wiki markup language that allows many common HTML tags, but provides a simple, readable syntax that is intended to allow users to use it without knowing HTML. A description can be found at How to edit a page.

I look forward to your overhaul of these pages to reflect this clandestine campaign to turn Wikipedians into Dreamweaver customers.

The syntax that's used for this is not HTML, any more than any other wikitext construct is HTML. Just because it uses angle brackets and not curly brackets or square brackets does not make it HTML. —Ævar Arnfjörð Bjarmason 16:44, 22 January 2006 (UTC)

If you want a specific example, please scroll down to the last paragraph here, and explain how that is more readable, maintainable, or useful than this, and how it squares with the Wiki tenets of quick and easy editing.

chocolateboy 13:49, 22 January 2006 (UTC)

Ævar, could you "please" avoid dismembering comments with interlineations. The civil way to reply is to quote. I have searched, and have found only a "this is a fait accompli" announcement, rather than a "should we violate the principles of wikitext?" discussion. As for your other "objection", please see the HTML format comments above.

(I'm not flaming your coding. And I think the comments on your homepage are, frankly, adorable, so stop licking your "wounds".)

The topic, by the way, is Wiki and Wikitext...

chocolateboy 00:48, 31 January 2006 (UTC)

Uh...Johnleemk's comment

Frankly, this discussion is very confusing, so I thought I'd break off into my own section and avoid any dismembering of my remarks. (It would probably help if chocolateboy didn't constantly break his comments into short paragraphs, which become ugly after several comments.) Anyway, I think chocolateboy is misreading policy here. As Ævar said, something that uses angle brackets isn't automatically HTML any more than it's automatically Cold Fusion. It resembles HTML, but it's plainly not. There's no such thing as a ref tag in HTML, AFAIK. This seems rather pedantic to me - would things suddenly be alright if we used [ref]foo[/ref] instead? While I agree this is rather messy when it comes to editing, it's not really as daunting as it might seem if enough spacing is used. Since I don't use the preformatted templates to cite sources, the footnotes I use are rather easy reading, even in edit mode (see, say, en:ketuanan Melayu or en:Article 153 of the Constitution of Malaysia). Furthermore, this format beats the old templates flat when it comes to previewing (c'mon, don't tell me you haven't been pissed off just once by losing your edits after accidentally clicking a footnote in preview mode), section editing (I don't need to perform mental gymnastics to footnote properly, which is a real pain on long articles), etc. Johnleemk 09:36, 4 February 2006 (UTC)

BUG?

There seems to be a problem with cite.php at the moment. See: En:Wikipedia:Village pump (technical) 150.203.178.30 04:33, 27 January 2006 (UTC)

Another example of an issue with Cite - see en:List of temples of The Church of Jesus Christ of Latter-day Saints. The first cite was not working so I put a null cite in so that the rest would work fine as a workaround. Trodel 17:58, 29 January 2006 (UTC)

Example text

I get the following for the reference list in the example text

Uranus's moons were observed to be declining in orbit[1], by the Hubble space telescope[2], the Martians were not available for comment on the matter[2]. The New York times[3] however reported[3] that ...

^ NASA

^ 2.1 2.2 December 2005 issue, page 12

^ 3.1 3.2 January 2006 issue, page 16

Is that what's meant to appear? If it were real text, how would the person know that source number 2 was "Popular Science"? Thanks, Andjam 09:50, 5 February 2006 (UTC)</ref>

Is the example better now? encephalon 01:26, 13 February 2006 (UTC)

Awesome work

Ævar, I just wanted to say thanks for doing this: it's a very compelling solution to some of the problems we've had with the earlier systems (FN1-4). One concern is the inline references cluttering the source text; editing articles can become very daunting, especially if cite.php is used in conjunction with a "prompter" template for reference styles. See for example en:Template talk:Cite journal#Cite.php compatibility. Is implementing Splash's suggestion feasible? I've just noticed that Taxman raises the same concern above. I'm not sure I understand your suggestion correctly. If I placed span.reference { display: none; } in my css, what exactly happens? Will I be able to see the inline refs in the edit box? Regards encephalon 00:34, 13 February 2006 (UTC)

Suppressing a citation

A big problem with using Cite in a real wikipedia article is that when the citations are large, it makes editing the article difficult.

One workaround is having the ability to suppress printing the number of a citation. That way, an individual can put all the references for an article at the top, cite them in the article, and flush them at the bottom.

I was thinking of something along the lines of <ref name="one" suppress="true">This is a long reference</ref>

The above should be rendered as a space or not at all (some sort of hidden attribute). In this way, all the references can be placed at the top of the article (maybe with a comment in the HTML saying that they should all go there, not get rendered at the top, get cited in the text, and flushed (shown) at the bottom.

Ksheka 13:21, 21 February 2006 (UTC)