As an avid writer on the wiki, I am always frustrated by the current system for REFs (et all). They have little expressive power, break easily, and made editing _extremely_ difficult in certain circumstances. I consider this to be one of the biggest problems with the current MediaWiki software, it costs me perhaps as much as 15% wasted time on every article -- and a check over my contributions list should let you calculate what sort of real-world time that represents!
The good news is that I don't think any of these problems aren't fixable. For argument's sake, here's some of the problems I'd like to see fixed:
1) CITE tags are _extremely_ large. Since the REF system requires them to be embedded in-line in the article body, they can make editing of the articles very difficult. For instance, look at the article at:
http://en.wikipedia.org/wiki/Water_memory
Now click edit. Even trying to figure out what is part of the body, as opposed to the REFs, can be very difficult. Of course one can mitigate this problem, slightly, by removing the vertical white space, but that doesn't _really_ help the issue as much as you would like, and has the side-effect of making the CITEs themselves harder to edit.
2) REFs should be _represented_ as footnotes, REFs, however, are _not footnotes_. It seems whoever built the REF system seems to have forgotten this fact. Footnotes can be used for all sorts of different purposes, but with the current REF system the two become synonymous. I like to add notes about pronunciation and "trivial" links to other articles using footnotes, but there's simply no way to do this with the current system.
3) There's no way to reference different page numbers! This is a _serious_ problem, because it means if you want to use different portions of a single work, like a book, you have to put in a different CITE for each one. In reality, people just don't bother.
4) I can't fold hand-edited refs into the REFLIST. For instance, let's say I used a book for most of the body of an article, so I didn't bother putting lots of REFs inline. I did, however, add a half dozen different REFs inlined to support specific facts. Now how do I make the REFLIST look right? I can't! I end up with some numbered ones, and some bulleted, and due to the default styles, they look different. Uggg.
5) REF should not be picky about position. Right now if you want to use the same REF in more than one place, you can use a named ref. Generally the idea is good. However, this system demands that the body of the named ref be placed in the very first place that ref is used. This works great until you want to actually edit the article, at which point it because terribly easy to break _all_ the references with something as simple as a cut-n-paste.
Here's my suggested solutions:
1) named refs should work no matter where the body of the reference is placed. That would immediately fix most of these problems. I could, optionally, place only <ref name=x/> into the body, and remove all of the ref bodies to the ==References== section of the article. This would even allow me to fold "non-inlines" into the references list, using exactly the same mechanism.
2) there should be another, similar, tag for "real" footnotes. <note> would be great. They would operate identically to (1).
3) named REFs can have another parameter, "page=". These would be collected into the references at the bottom, with each lettered reference appearing.
How would I use this? Well using the water memory article as an example, I would...
1) remove all the CITEs into the ==References== section, surrounded in REF tags with a name.
2) place name ref placeholders in the body of the article, some of these may optionally include page numbers
3) some of the comments would be surrounded with <note> tags, and optionally removed to a new ==Notes== section.
Is there anything technically impossible here?
Maury
Maury Markowitz wrote:
- named REFs can have another parameter, "page=". These would be
collected into the references at the bottom, with each lettered reference appearing.
I don't understand this part. Are you saying that we could have separate <references/> lists for each section?
-- Tim Starling
On 16/09/2007, Tim Starling tstarling@wikimedia.org wrote:
Maury Markowitz wrote:
- named REFs can have another parameter, "page=". These would be
collected into the references at the bottom, with each lettered reference appearing.
I don't understand this part. Are you saying that we could have separate <references/> lists for each section?
No, he's saying that if I cite a book 3 times, I can give the details of the book once, but give the relevant page number for each citation.
On 9/16/07, Thomas Dalton thomas.dalton@gmail.com wrote:
No, he's saying that if I cite a book 3 times, I can give the details of the book once, but give the relevant page number for each citation.
Exactly. This would likely require a little tweaking of the formatting... right now named refs are labeled at the front of the reference with letters. If this includes the page number, it might have to be moved.
Another possibility, one that some editors might prefer, is to use a separate line in the references list for each page. This would eliminate the letters entirely, and instead list them out below with a "ibid, pg 3" sort of style, with the "ibid" being replaced by the name of the link itself. For instance...
dflkafk <ref name="NASA TN.1262" page=23/> sdfkhskjhf <ref name="NASA TN.1262" page=31/> kjhf....
==References== <references> <ref name="NASA TN.1262"> a big CITE tag here </ref>
When rendered this would come out like...
==References== 1. NASA TN.126, contents of the big CITE tag here 1a. NASA TN.126, pg. 23 1b. NASA TN.126, pg. 31
Hello,
Cite tags are already location-agnostic; you can use <ref name="foo" /> before defining reference foo. You could define them in the 'References' section, though that leads to formatting problems such as a list of [x] links in that section.
Yours cordially, Jesse Martin (Pathoschild)
On 9/16/07, Maury Markowitz maury.markowitz@gmail.com wrote:
- named refs should work no matter where the body of the reference is
placed. That would immediately fix most of these problems. I could, optionally, place only <ref name=x/> into the body, and remove all of the ref bodies to the ==References== section of the article.
On 9/16/07, Jesse Martin (Pathoschild) pathoschild@gmail.com wrote:
Cite tags are already location-agnostic; you can use <ref name="foo" /> before defining reference foo.
Uhhh, not in my experience. Perhaps I am doing something wrong, but when I try this the ref in the {{reflist}} ends up blank.
Maury
Cite tags are location-agnostic in my test at < http://meta.wikimedia.org/wiki/User:Pathoschild/Sandbox >.
Yours cordially, Jesse Martin (Pathoschild)
On 9/17/07, Maury Markowitz maury.markowitz@gmail.com wrote:
On 9/16/07, Jesse Martin (Pathoschild) pathoschild@gmail.com wrote:
Cite tags are already location-agnostic; you can use <ref name="foo" /> before defining reference foo.
Uhhh, not in my experience. Perhaps I am doing something wrong, but when I try this the ref in the {{reflist}} ends up blank.
Maury
On 17/09/2007, Jesse Martin (Pathoschild) pathoschild@gmail.com wrote:
Cite tags are location-agnostic in my test at < http://meta.wikimedia.org/wiki/User:Pathoschild/Sandbox >.
Likewise, to my surprise. Has it been fixed recently? I'm sure it didn't used to work.
On 9/17/07, Thomas Dalton thomas.dalton@gmail.com wrote:
Cite tags are location-agnostic in my test at < http://meta.wikimedia.org/wiki/User:Pathoschild/Sandbox >.
Likewise, to my surprise. Has it been fixed recently? I'm sure it didn't used to work.
Me too, and "recently" must be something like "one week" because I ruined an article in just this fashion within that time frame.
Maury
On 9/17/07, Thomas Dalton thomas.dalton@gmail.com wrote:
On 17/09/2007, Jesse Martin (Pathoschild) pathoschild@gmail.com wrote:
Cite tags are location-agnostic in my test at < http://meta.wikimedia.org/wiki/User:Pathoschild/Sandbox >.
Likewise, to my surprise. Has it been fixed recently? I'm sure it didn't used to work.
I have a vague recollection it was fixed several months ago.
On 9/17/07, George Herbert george.herbert@gmail.com wrote:
On 9/17/07, Ævar Arnfjörð Bjarmason avarab@gmail.com wrote:
Do you just want the ability to make two citation-like lists per article whereas you can make one now? If that's the case wouldn't a system where you can make and flush an arbitrary number of lists be better?
How many are we likely to want? Enough that general-purposing the mechanism (rather than a second instance) makes sense?
Yes. Someone might want per-section notes for some reason, for instance (this is common on enwiki "Comparison of X" pages right now, in my experience).
On 9/17/07, Ævar Arnfjörð Bjarmason avarab@gmail.com wrote:
If that's the case I think *implementation wise* it would be a neat idea to support reference groups, so the above could be written as:
""" Some statement<ref group="references" name="ref name">This is a reference</ref> and something to note<ref group="notes" name="note name">This is a note</ref>.
== References ==
<references group="references"/>
== Notes ==
<references group="notes"/> """
Before I got commit access, I wrote up and submitted a patch implementing exactly that syntax. I do plan on revisiting it someday, cleaning it up and committing it.
On 9/17/07, Jesse Martin (Pathoschild) pathoschild@gmail.com wrote:
Cite tags are location-agnostic in my test at < http://meta.wikimedia.org/wiki/User:Pathoschild/Sandbox >.
Ohhh, it's got a problem I just noticed. The reference has an (a) (b), because there's one reference in the body and another in the references section itself.
Bummer. Easily fixable?
Maury
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
In my opinion, a BibTeX like system would work quite well for citations. Rather than have all citations be inline, or even stuffed in the References section, there should be a bibliography database with a zingy interface that'll let users quickly add citations and then quickly reference them in the article. (Extra points if it's centralized, but doing it on a per-article basis still would work). On the other hand, I think footnotes should probably stay inline.
Edward Z. Yang wrote:
In my opinion, a BibTeX like system would work quite well for citations. Rather than have all citations be inline, or even stuffed in the References section, there should be a bibliography database with a zingy interface that'll let users quickly add citations and then quickly
And this brings us back to Wikicat!
(see http://meta.wikimedia.org/wiki/Wikicat)
Or maybe not. (That project idea has been dead for a while, as far as I know.)
On 9/16/07, Edward Z. Yang edwardzyang@thewritingpot.com wrote:
In my opinion, a BibTeX like system would work quite well for citations.
Yes and no. Although it might make things easier to use and include, there's something to be said for having the whole CITE tag there to examine. A mix of the two approaches might be useful, as would a real tool for making CITEs out of web pages. The tools I've seen to date are not really useful.
Maury
I'm a bit confused. Are cite and ref tags two different things? I recognize ref tags from the Cite.php extension. I thought cite tags were used by the Biblio extension, which isn't running on en.wikipedia or meta.
Jim
On Sep 17, 2007, at 10:31 AM, Maury Markowitz wrote:
On 9/16/07, Edward Z. Yang edwardzyang@thewritingpot.com wrote:
In my opinion, a BibTeX like system would work quite well for citations.
Yes and no. Although it might make things easier to use and include, there's something to be said for having the whole CITE tag there to examine. A mix of the two approaches might be useful, as would a real tool for making CITEs out of web pages. The tools I've seen to date are not really useful.
Maury
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
===================================== Jim Hu Associate Professor Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054
On 9/17/07, Jim Hu jimhu@tamu.edu wrote:
I'm a bit confused. Are cite and ref tags two different things? I recognize ref tags from the Cite.php extension.
This is part of the confusion. There are three different things being discussed, but editors have used the terminology interchangeably, greatly confusing matters.
"FOOTNOTE": a stylistic solution to inserting small amounts of text that would otherwise break up the flow of a statement. Other solutions include the sidebar, callouts, and pop-up text. In the case of the wiki, we don't really have anything that represents these directly.
"REFERENCE": any link to another work. in the case of the wiki, we expect these to be the set of resources that are used to build the article.
"CITATION": a somewhat formal system for including a reference to another work, typically a journal or similar. In the case of the wiki, these
Now why do I complain they are confused? Well for one, go visit the wiki page on footnotes. Note that the entire article is about references! And where is the REF tag defined? In CITE.PHP!
Maury
On 9/17/07, Maury Markowitz maury.markowitz@gmail.com wrote:
On 9/17/07, Jim Hu jimhu@tamu.edu wrote:
I'm a bit confused. Are cite and ref tags two different things? I recognize ref tags from the Cite.php extension.
This is part of the confusion. There are three different things being discussed, but editors have used the terminology interchangeably, greatly confusing matters.
"FOOTNOTE": a stylistic solution to inserting small amounts of text that would otherwise break up the flow of a statement. Other solutions include the sidebar, callouts, and pop-up text. In the case of the wiki, we don't really have anything that represents these directly.
"REFERENCE": any link to another work. in the case of the wiki, we expect these to be the set of resources that are used to build the article.
"CITATION": a somewhat formal system for including a reference to another work, typically a journal or similar. In the case of the wiki, these
Now why do I complain they are confused? Well for one, go visit the wiki page on footnotes. Note that the entire article is about references! And where is the REF tag defined? In CITE.PHP!
Maury
The terminology stuff is only irritating; it might be worth coding to fix it, might not.
Footnotes... stylistically, many forms of reference work never include any. Some do. Usage is completely inconsistent field to field. We have some alternative notation methods, but can probably do without them.
That said; one could cheat and duplicate the <ref> system with new keywords <footnote> and <footnotes>, or generalize cite.php a bit and have it auto-handle both types (say, <ref name="foobar" type=footnote>In most Elven languages, the pluperfect form is used only in drinking songs and sagas</ref>, and have the <references/> generate subsections for both "references" and "footnotes" if present. These would both be easy hacks.
OK, so... is the following correct?
On Sep 17, 2007, at 1:38 PM, Maury Markowitz wrote:
On 9/17/07, Jim Hu jimhu@tamu.edu wrote:
I'm a bit confused. Are cite and ref tags two different things? I recognize ref tags from the Cite.php extension.
This is part of the confusion. There are three different things being discussed, but editors have used the terminology interchangeably, greatly confusing matters.
"FOOTNOTE": a stylistic solution to inserting small amounts of text that would otherwise break up the flow of a statement. Other solutions include the sidebar, callouts, and pop-up text. In the case of the wiki, we don't really have anything that represents these directly.
In the case of a non-paginated wiki page (or most other web pages), it seems to me that it makes more sense to discuss these as ENDNOTES instead of footnotes. Operationally, Cite.php is the main mechanism for putting in endnotes, some of which are references, while others may be free text. The other mechanism being manual editing of the text inline and at the end of a wiki page.
Using Cite, endnotes/footnotes are what gets built around the <references/> tag.
"REFERENCE": any link to another work. in the case of the wiki, we expect these to be the set of resources that are used to build the article.
If I understand this correctly, the reference per se doesn't exist in the display. Reference is a combination of work, expression, and manifestation in WikiCat? I fear that WikiCat and WikiTextrose are much too grandiose for my brain to wrap around.
Handling the reference is a combination of how the endnote and the citation are handled. In some systems (not Cite.php), the reference information is stored in a database or in a non-displaying block on the page (I think that's how Biblio handles it).
When I use EndNote to do references in a word document, the references are in my EndNote database, and only a subset that are cited get applied to a particular document.
With a wiki, one has to figure out whether to store reference information internally or externally. With the current implementation of Cite, it's all internal and it's potentially redundant in ways that make relational db people shrink in horror. For EcoliWiki, I've added my ProcessCite.php extenstion on top of Cite.php and delegated some of the storage to PubMed for that class of references. This is not very useful for fields outside of biology, and doesn't provide good coverage in all areas of biology. But at least every time a user adds <ref name="PMID:number"/>, the endnote looks the same. I also have the ability to store a page of references as a reference library for things not in PubMed, but I don't think this is a good solution as the library gets large.
Is that approach extensible? Maybe this is related to what WikiCat was about, but could Cite/ProcessCite be modified to pull reference info as if it was a interwiki link? i.e. <ref name='WikiCat:PageName/>
"CITATION": a somewhat formal system for including a reference to another work, typically a journal or similar. In the case of the wiki, these
Citation is operationally the inline marker for the reference. Cite.php handles these as superscripted letters or numbers, but alternatives are things like (Doe et al., 2007) or [1]. Using Cite.php, the ref tag is used for citations.
What if Cite.php was modified to append text between ref tags to anything that is provided by the name=x information? This would allow different page ranges for the same source. This would only work if the name=x refers to an external source, not a different instance of the same ref name elsewhere on the page.
But, for example, if we modified Cite to recognize ISBN numbers, one could do <ref name='ISBN:number'>pp 200-210</ref> or something like that.
Or perhaps the ref tag needs more kinds of attributes besides name. What I just wrote above probably breaks backward compatibility horribly. So it would be better to build something like: <ref isbn='number'>pp 200-210</ref>
With more attributes, you could build lists of frequently cited works that are field specific as wiki pages in a reference list namespace, e.g. <ref list='biology' name='Selfish Gene'/>, which would be much more readable than ISBN numbers.
Jim
Now why do I complain they are confused? Well for one, go visit the wiki page on footnotes. Note that the entire article is about references! And where is the REF tag defined? In CITE.PHP!
Maury
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
===================================== Jim Hu Associate Professor Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054
On 9/17/07, Edward Z. Yang edwardzyang@thewritingpot.com wrote:
In my opinion, a BibTeX like system would work quite well for citations. Rather than have all citations be inline, or even stuffed in the References section, there should be a bibliography database with a zingy interface that'll let users quickly add citations and then quickly reference them in the article. (Extra points if it's centralized, but
I agree. It can't be part of the main article text, though, or it will break whenever you edit by section.
How about two edit boxes: The first one containing article text, and location-specific material (including pointers to references, links, images etc), and the second one containing meta data (reference bodies, categories, GPS coordinates...)
Steve
On Sep 17, 2007, at 10:42 PM, Steve Bennett wrote:
On 9/17/07, Edward Z. Yang edwardzyang@thewritingpot.com wrote:
In my opinion, a BibTeX like system would work quite well for citations. Rather than have all citations be inline, or even stuffed in the References section, there should be a bibliography database with a zingy interface that'll let users quickly add citations and then quickly reference them in the article. (Extra points if it's centralized, but
I agree. It can't be part of the main article text, though, or it will break whenever you edit by section.
How about two edit boxes: The first one containing article text, and location-specific material (including pointers to references, links, images etc), and the second one containing meta data (reference bodies, categories, GPS coordinates...)
I don't like this (but I may be in the minority). Wouldn't it be simpler to implement template expansion inside ref tags in Cite?
Steve
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
===================================== Jim Hu Associate Professor Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054
How about two edit boxes: The first one containing article text, and location-specific material (including pointers to references, links, images etc), and the second one containing meta data (reference bodies, categories, GPS coordinates...)
I don't like this (but I may be in the minority). Wouldn't it be simpler to implement template expansion inside ref tags in Cite?
Templates are expanded inside ref tags... enwiki has dozens of {{cite}} templates.
I'm not sure two edit boxes is a good idea, but some kind of <meta> tag (probably need a different name to avoid confusing with the HTML meta tag) which can contain all the meta info would be good. Keep it in the main source code, but separate from the content. It would make it very easy to modify section editing to allow the meta info to be edited separately to the rest of the page.
Nothing inbetween <meta> tags would be displayed on the page, which could simplify things like having to prefix links to categories with a colon to get them to display. If the category link is in the <meta> section, it would add the page to the category, if its anywhere else, it just displays a link (although that would break backwards compatibility, so might not be worth it).
On Sep 18, 2007, at 10:17 AM, Thomas Dalton wrote:
How about two edit boxes: The first one containing article text, and location-specific material (including pointers to references, links, images etc), and the second one containing meta data (reference bodies, categories, GPS coordinates...)
I don't like this (but I may be in the minority). Wouldn't it be simpler to implement template expansion inside ref tags in Cite?
Templates are expanded inside ref tags... enwiki has dozens of {{cite}} templates.
Doh. I think I am confusing myself with a different issue regarding ref tags and templates. Perhaps it's the other way around?
So... the cite templates could be made even more granular to do templates for every reference (I'd put these in a different namespace). The "second edit window" would be invoked by clicking a link from the list of included templates.
I'm not sure two edit boxes is a good idea, but some kind of <meta> tag (probably need a different name to avoid confusing with the HTML meta tag) which can contain all the meta info would be good. Keep it in the main source code, but separate from the content. It would make it very easy to modify section editing to allow the meta info to be edited separately to the rest of the page.
Nothing inbetween <meta> tags would be displayed on the page, which could simplify things like having to prefix links to categories with a colon to get them to display. If the category link is in the <meta> section, it would add the page to the category, if its anywhere else, it just displays a link (although that would break backwards compatibility, so might not be worth it).
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
===================================== Jim Hu Associate Professor Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054
So... the cite templates could be made even more granular to do templates for every reference (I'd put these in a different namespace). The "second edit window" would be invoked by clicking a link from the list of included templates.
A references namespace has been suggested before. It's worth considering.
On 9/18/07, Thomas Dalton thomas.dalton@gmail.com wrote:
A references namespace has been suggested before. It's worth considering.
I think I may be missing the point here... what would this do?
Maury
Each wiki page in the namespace would be like an entry in your EndNote database.
Each of those pages would be a cite template filled in with appropriate values.
So you might write <ref>{{refs:Markowitz_2007|pages=1-10}}</ref>
Which is a lot more readable and compact than
<ref>{{Citation | last=Markowitz | first=Maury | author-link= | publication-date=20070918 | date= | year=2007 | title=A workable ref/note/cite system for wikipedia | periodical=J. wikipedia sci. | series= | publication-place=Cyberspace | place= | publisher=Foobar press | volume=1 | issue=1 | pages=1-1- | url= | issn= | doi= | oclc= | accessdate= }}.
The "template" on the refs page would have all that.
On Sep 18, 2007, at 12:47 PM, Maury Markowitz wrote:
On 9/18/07, Thomas Dalton thomas.dalton@gmail.com wrote:
A references namespace has been suggested before. It's worth considering.
I think I may be missing the point here... what would this do?
Maury
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
===================================== Jim Hu Associate Professor Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054
On 9/18/07, Jim Hu jimhu@tamu.edu wrote:
So you might write <ref>{{refs:Markowitz_2007|pages=1-10}}</ref>
Which is a lot more readable and compact than
<ref>{{Citation | last=Markowitz | first=Maury | author-link= . . .
It's also not equivalent, unless there's only one Markowitz in the world and he only wrote one thing in 2007. {{refs:A workable ref/note/cite system for wikipedia}} or {{refs:Maury Markowitz/A workable ref/note/cite system for wikipedia}}, maybe. Still a lot better, though. :)
On 18/09/2007, Simetrical Simetrical+wikilist@gmail.com wrote:
On 9/18/07, Jim Hu jimhu@tamu.edu wrote:
So you might write <ref>{{refs:Markowitz_2007|pages=1-10}}</ref>
Which is a lot more readable and compact than
<ref>{{Citation | last=Markowitz | first=Maury | author-link= . . .
It's also not equivalent, unless there's only one Markowitz in the world and he only wrote one thing in 2007. {{refs:A workable ref/note/cite system for wikipedia}} or {{refs:Maury Markowitz/A workable ref/note/cite system for wikipedia}}, maybe. Still a lot better, though. :)
What the pages are called isn't really important at this stage.
On Sep 18, 2007, at 1:46 PM, Simetrical wrote:
On 9/18/07, Jim Hu jimhu@tamu.edu wrote:
So you might write <ref>{{refs:Markowitz_2007|pages=1-10}}</ref>
Which is a lot more readable and compact than
<ref>{{Citation | last=Markowitz | first=Maury | author-link= . . .
It's also not equivalent, unless there's only one Markowitz in the world and he only wrote one thing in 2007. {{refs:A workable ref/note/cite system for wikipedia}} or {{refs:Maury Markowitz/A workable ref/note/cite system for wikipedia}}, maybe. Still a lot better, though. :)
I agree. I'm actually leaning toward the terse but totally uninformative {{refs:uid}} and let the editor have another window/tab open to get uid from searching. Disambiguating based on content inside the ref tag rapidly runs into "what if he published two papers in 2007 with the same title in different journals?" etc. Pretty soon you're back to the whole thing inside the ref tag.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
===================================== Jim Hu Associate Professor Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054
On 9/18/07, Jim Hu jimhu@tamu.edu wrote:
I agree. I'm actually leaning toward the terse but totally uninformative {{refs:uid}} and let the editor have another window/tab open to get uid from searching. Disambiguating based on content inside the ref tag rapidly runs into "what if he published two papers in 2007 with the same title in different journals?" etc. Pretty soon you're back to the whole thing inside the ref tag.
On the other hand, being able to type {{refs:The Origin of Species|page=246}} has a certain appeal to it. Although you'd have to specify the edition . . . still, that kind of relatively verbose format seems like a better idea to me, overall.
Maury Markowitz wrote:
- REF should not be picky about position.
I haven't had a problem with this. If you do, maybe it's a bug under certain conditions rather than a general problem.
Here's my suggested solutions:
I like your ideas and think they'd be useful.
The only thing I would like is to have in addition is a central pool of references. I have put together several pages recently, all on related topics and all using some common refs. However, I have to put them into each article separately. Since I copied and pasted from one page to the next, when I found an error in the original ref, I had to find all the others to correct.
If refs had a status comparable to images, they could be inserted in any article with minimal effort. One could have a "where used" function - "show all articles that reference this author" etc. I realize this is not a trivial effort, but I like to dream.
On my own wiki, I created a "References" category with sub-categories of "Book", "Video", "Journal" etc. Instead of refs as on Wikipedia, I use links like [[Roget's Thesaurus|Roget]]. No numbers in a list of refs at the bottom, but a click on the ref opens the details from the book's page (which has title, author, publisher, ISBN , review, etc.). Hmm... if I wrote an extension, I could pull a transclusion from the book page to generate a ref at the bottom of the page...
Mike
On 17/09/2007, Michael Daly michaeldaly@kayakwiki.org wrote:
The only thing I would like is to have in addition is a central pool of references. I have put together several pages recently, all on related topics and all using some common refs. However, I have to put them into each article separately. Since I copied and pasted from one page to the next, when I found an error in the original ref, I had to find all the others to correct. If refs had a status comparable to images, they could be inserted in any article with minimal effort. One could have a "where used" function - "show all articles that reference this author" etc. I realize this is not a trivial effort, but I like to dream.
If someone can write code for this, English Wikipedia would dive upon it with great glee.
I mean, I love the <ref> and {{cite}} tags. They're just the right thing for showing your working when you're trying to write a halfway robust referenced article.
- d.
On 9/18/07, David Gerard dgerard@gmail.com wrote:
On 17/09/2007, Michael Daly michaeldaly@kayakwiki.org wrote:
The only thing I would like is to have in addition is a central pool of references. I have put together several pages recently, all on related topics and all using some common refs. However, I have to put them into each article separately. Since I copied and pasted from one page to the next, when I found an error in the original ref, I had to find all the others to correct. If refs had a status comparable to images, they could be inserted in any article with minimal effort. One could have a "where used" function - "show all articles that reference this author" etc. I realize this is not a trivial effort, but I like to dream.
If someone can write code for this, English Wikipedia would dive upon it with great glee.
As far as I understand the proposal, it's perfectly possible to implement immediately with no code changes. Just create a page, say Wikipedia:Refs, and make a subpage for each reference you want. Later, if it catches on, you can convert it to a proper namespace.
If someone can write code for this, English Wikipedia would dive upon it with great glee.
As far as I understand the proposal, it's perfectly possible to implement immediately with no code changes. Just create a page, say Wikipedia:Refs, and make a subpage for each reference you want. Later, if it catches on, you can convert it to a proper namespace.
Well, I'd make them subpages of Template:Refs, to make the code shorter, but otherwise, it's not a bad idea.
Thomas Dalton wrote:
If someone can write code for this, English Wikipedia would dive upon it with great glee.
As far as I understand the proposal, it's perfectly possible to implement immediately with no code changes. Just create a page, say Wikipedia:Refs, and make a subpage for each reference you want. Later, if it catches on, you can convert it to a proper namespace.
Well, I'd make them subpages of Template:Refs, to make the code shorter, but otherwise, it's not a bad idea.
Is this actually seriously being considered? Because I just picked up a great book with 600 pages of timelines of scientific and technological discoveries that I could use as a reference for literally thousands and thousands of articles, and it would be nice to have a {{refs/Timetables of Science 1988|pages=}} template available right now before I start using it extensively rather than having to go back and retrofit them later. If we start it out in a badly named manner that's not such a big deal because redirects work okay, the important thing is just to _start._
Bryan Derksen wrote:
Thomas Dalton wrote:
If someone can write code for this, English Wikipedia would dive upon it with great glee.
As far as I understand the proposal, it's perfectly possible to implement immediately with no code changes. Just create a page, say Wikipedia:Refs, and make a subpage for each reference you want. Later, if it catches on, you can convert it to a proper namespace.
Well, I'd make them subpages of Template:Refs, to make the code shorter, but otherwise, it's not a bad idea.
Is this actually seriously being considered? Because I just picked up a great book with 600 pages of timelines of scientific and technological discoveries that I could use as a reference for literally thousands and thousands of articles, and it would be nice to have a {{refs/Timetables of Science 1988|pages=}} template available right now before I start using it extensively rather than having to go back and retrofit them later. If we start it out in a badly named manner that's not such a big deal because redirects work okay, the important thing is just to _start._
As a followup, I've just randomly encountered the following template:
http://en.wikipedia.org/wiki/Template:GardinerReference
So it looks like others have also had this idea and have got started in small ways already. I'll go ahead with my own reference template too, then.
David Gerard wrote:
On 17/09/2007, Michael Daly michaeldaly@kayakwiki.org wrote:
The only thing I would like is to have in addition is a central pool of references. [...]
If someone can write code for this, English Wikipedia would dive upon it with great glee.
I mean, I love the <ref> and {{cite}} tags. They're just the right thing for showing your working when you're trying to write a halfway robust referenced article.
For short and medium length articles with less than 10 footnotes, I personally think that it works fine to put the {{cite book|...}} inside the <ref> tags. I guess this is how they were intended when they were introduced.
For longer articles, it works better to put the {{cite book|...}} under a ==Literature== heading and then to just use a very brief <ref>Johnson (2007), pp. 207-208</ref> in combination with the compact {{reflist|3}} (that renders <references/> in 3 columns.
Some long articles with 50+ footnotes repeat the identical call to {{cite book|...}} inside <ref> tags even though they cite the same work in ten different places. I've stumbled across such cases when I was looking for ISBNs with bad checksums in the Swedish, Finnish and Lithuanian Wikipedia. This means the bad ISBN needs to be corrected in several places inside the same article. That is quite far from optimal.
A "central pool" of (the most commonly used) references is something that can be extracted from existing database dumps. It doesn't have to be established by introducing new wiki syntax. If this pool then goes into Wikicat (the project suggested on meta long ago) or a new ref: namespace or an external project such as the new demo.openlibrary.org, is a matter of what is the best implementation. I personally think that a central pool (how central? Should it be common to all languages of Wikipedia, almost like the Wikimedia Commons?) is a subproject too big to be implemented inside Wikipedia. For example, in some cases this pool needs to link to works digitized in Wikisource or in external digitization projects. And at least Wikiquote and Wikinews should benefit from using the same "central pool" as Wikipedia. And if "Wikicat" is set up as a new, separate project, the people who should be involved there are already considering the global need (inside and outside of Wikimedia Foundation projects) for new bibliographic resources. My current guess is that the demo.openlibrary.org, which runs under the Open Content Alliance and/or Internet Archive, would be the best place for this.
I personally think that a central pool (how central? Should it be common to all languages of Wikipedia, almost like the Wikimedia Commons?) is a subproject too big to be implemented inside Wikipedia. For example, in some cases this pool needs to link to works digitized in Wikisource or in external digitization projects. And at least Wikiquote and Wikinews should benefit from using the same "central pool" as Wikipedia. And if "Wikicat" is set up as a new, separate project, the people who should be involved there are already considering the global need (inside and outside of Wikimedia Foundation projects) for new bibliographic resources. My current guess is that the demo.openlibrary.org, which runs under the Open Content Alliance and/or Internet Archive, would be the best place for this.
Wikimedia's answer to Google Scholar? Sounds good. I imagine we could get quite a lot of websites to use it for all their citations.
Lars Aronsson wrote:
I personally think that a central pool (how central? Should it be common to all languages of Wikipedia, almost like the Wikimedia Commons?) is a subproject too big to be implemented inside Wikipedia.
I think it should be central to all languages. I've seen several articles that reference, say, Portuguese documents, on the English Wikipedia. I don't see how a unique document should be avoided just because it's a different language - in some domains, the other language's document may be the only one on the topic of interest.
I don't know that it's too big for Wikipedia. If it can be done for one wiki, it can be done for a family with minimal change, unless someone designed a monster.
Mike
I have to say I'm happy to see such a great discussion on this. To answer my own question: yes, it seems there's _quite_ a bit of interest in the topic!
There's already been some good news... refs are now location agnostic! With a little work you can implement CITEs "out of band" with only a minor side effect. I used Jesse's method in the water memory article and the effect was fantastic, the article is much easier to edit now. Can anyone think of an easy way to eliminate the "b" links that point into the hidden DIV? Maybe without any changes to cite.php? And a later discussion about using REFs to point into a separate "sources" section containing the CITE bodies is a great solution too, although it does spread the cite bodies out. I'm not sure if that is ever a problem in practice though, I'll just have to try it out on a few articles and see how it feels.
It seems like the idea of being able to have separate "references" and "notes" struck a chord. After reading over the posts again, I think I've come around to the "section=" line of thought, instead of the separate <note>. Steve's message was particularly well taken. You just have to see one example to "get it", and you'd have to for a new "notes" tag too. There's been lots of good discussion both ways though.
We still have the problem of referring to different pages. There's two lines of thought here, one is to have a "page=" or similar, and another just to allow the "pointer" refs also contain text. Maybe both? The discussion was particularly interesting because other editors had different ideas on how to use the whole concept that I hadn't thought of. I'm more convinced than ever that this is really something that would help a lot of editors out.
And then there's the whole discussion of templated CITEs pointing to a central repository so they can be re-used in multiple pages. Definitely useful. I have a mining book that I will be referring to in a bunch of different articles. If I could make a single template CITE for this book on my userpage somewhere, then linking to it with an added page number, that would be seriously nice.
So has anything sent up any red flags yet? Ævar, in your opinion, does anything here seem too difficult to develop to be worthwhile?
Maury
On 9/19/07, Maury Markowitz maury.markowitz@gmail.com wrote:
So has anything sent up any red flags yet? Ævar, in your opinion, does anything here seem too difficult to develop to be worthwhile?
Grouped references is definitely not, since there's a mostly-working patch that does it and just needs to be cleaned up. A backlink="none" attribute would be quite easy to implement. I'm not fully convinced of the necessity of page=, which makes <ref> considerably more usage-specific, but if it were a matter of appending text to the end of the ref I guess that wouldn't be too hard. I just wish there would be a more elegant solution.
On 9/19/07, Simetrical Simetrical+wikilist@gmail.com wrote:
Grouped references is definitely not, since there's a mostly-working patch that does it and just needs to be cleaned up.
Are you referring to the ability to group references into subgroups for a notes section? If so, I think I missed part of the discussion, there's already a patch for this?
A backlink="none" attribute would be quite easy to implement.
This would be to implement the "hidden cite", removing the "b"?
I'm not fully convinced of the necessity of page=, which makes <ref> considerably more usage-specific
Oh I agree, in retrospect I would like to have something more flexible as well. But was the technical issue with using the text between the tags solved? Didn't a basic implementation break backwards compatibility? Or was there some other message about this I missed, a more generic tag for instance?
Maury
On 9/19/07, Maury Markowitz maury.markowitz@gmail.com wrote:
Are you referring to the ability to group references into subgroups for a notes section? If so, I think I missed part of the discussion, there's already a patch for this?
Yes, there's been one for over a year. It doesn't apply cleanly to trunk, however, so it will have to be manually applied.
This would be to implement the "hidden cite", removing the "b"?
Yes.
Oh I agree, in retrospect I would like to have something more flexible as well. But was the technical issue with using the text between the tags solved? Didn't a basic implementation break backwards compatibility? Or was there some other message about this I missed, a more generic tag for instance?
What do you mean, using the text within the tags? Like <ref name="foo">Text to append</ref>? That strikes me as inevitably ambiguous, unless order becomes important again.
On 9/19/07, Simetrical Simetrical+wikilist@gmail.com wrote:
Yes, there's been one for over a year. It doesn't apply cleanly to trunk, however, so it will have to be manually applied.
Oh excellent. What is the basic syntax?
This would be to implement the "hidden cite", removing the "b"?
Yes.
Well I would argue for somewhat more "obvious" syntax. backlink="none" strikes me as a bit opaque.
What do you mean, using the text within the tags? Like <ref name="foo">Text to append</ref>? That strikes me as inevitably ambiguous, unless order becomes important again.
Yes, that was the suggestion, and the problem with it. I was wondering if someone had solved the problem and I simply missed the message.
So any thoughts on the syntax here? "section="?
Maury
On 9/20/07, Maury Markowitz maury.markowitz@gmail.com wrote:
On 9/19/07, Simetrical Simetrical+wikilist@gmail.com wrote:
Yes, there's been one for over a year. It doesn't apply cleanly to trunk, however, so it will have to be manually applied.
Oh excellent. What is the basic syntax?
<ref group="foo">...</ref> <ref group="bar">...</ref> <ref group="foo">...</ref>
<references group="foo" /> <references group="bar" />
This would be to implement the "hidden cite", removing the "b"?
Yes.
Well I would argue for somewhat more "obvious" syntax. backlink="none" strikes me as a bit opaque.
What would you recommend?
What do you mean, using the text within the tags? Like <ref name="foo">Text to append</ref>? That strikes me as inevitably ambiguous, unless order becomes important again.
Yes, that was the suggestion, and the problem with it. I was wondering if someone had solved the problem and I simply missed the message.
It's impossible, unless I'm really missing something. If the only two refs with name "name" in a document are
<ref name="name">Foo</ref> <ref name="name">Bar</ref>
would the ref text be FooBar or BarFoo? Which is the base and which is appended? You presumably don't want to make order important again.
On 9/20/07, Simetrical Simetrical+wikilist@gmail.com wrote:
<references group="foo" /> <references group="bar" />
Out of curiosity, how is {{reflist}} templated in? If I were to do {{reflist|group="foo"}}, would that work? I tend to use reflist these days because it also applies nice styling.
What would you recommend?
Let me think about it, hopefully I can come up with something.
would the ref text be FooBar or BarFoo? Which is the base and which is appended? You presumably don't want to make order important again.
Well I prefer just the general "note=" or "section=" inside the tag itself. Then the syntax doesn't change in any gross manner, and it should be more compatible.
Maury
On 9/21/07, Maury Markowitz maury.markowitz@gmail.com wrote:
On 9/20/07, Simetrical Simetrical+wikilist@gmail.com wrote:
<references group="foo" /> <references group="bar" />
Out of curiosity, how is {{reflist}} templated in? If I were to do {{reflist|group="foo"}}, would that work?
Someone would need to update {{reflist}}.
I tend to use reflist these days because it also applies nice styling.
The nice styling should be applied via CSS to all <references>, not just {{reflist}} ones. But that's not a software issue.
On 9/21/07, Maury Markowitz maury.markowitz@gmail.com wrote:
On 9/21/07, Thomas Dalton thomas.dalton@gmail.com wrote:
But using <ref> for the "body ref" results in an unwanted [1] at the end of the article
Oh yes, this is true currently, but if you scroll back a few messages, Simetrical has noted that a fix for this is already in the works.
I said it wouldn't be hard to fix. That's different from saying that someone plans to fix it in the near future.
On 9/21/07, Michael Daly michaeldaly@kayakwiki.org wrote:
How about:
<ref name="name">The Best Book Ever Written</xref>
<ref name="name" append="pp 1-7" /> <ref name="name" append="pp 8-14" />
Backward compatible, consistent with tag formats and no new tags.
This is what I favor.
On 9/21/07, Maury Markowitz maury.markowitz@gmail.com wrote:
<ref section="page 22-23" backlink="3a" />
seems pretty damb handy.
Why?
On 9/21/07, Thomas Dalton thomas.dalton@gmail.com wrote:
One thing I haven't seen discussed - how will we distinguish between different groups with the inline links? If I see <sup>1</sup> in an article, how am I to know if it's a note or a ref?
Being able to change the superscript progression for a given group would be a separate request. Implementing groups alone would only really be useful for per-section refs or similar, not for separate refs/notes (since the numbers would conflict).
Being able to change the superscript progression for a given group would be a separate request. Implementing groups alone would only really be useful for per-section refs or similar, not for separate refs/notes (since the numbers would conflict).
But separate refs/notes is the most important use of it. We could go with something as simple as using numbers for refs and letters for notes.
On 9/21/07, Thomas Dalton thomas.dalton@gmail.com wrote:
But separate refs/notes is the most important use of it. We could go with something as simple as using numbers for refs and letters for notes.
Yes, of course. It's still a separate feature request in terms of implementing it.
On 21/09/2007, Simetrical Simetrical+wikilist@gmail.com wrote:
On 9/21/07, Thomas Dalton thomas.dalton@gmail.com wrote:
But separate refs/notes is the most important use of it. We could go with something as simple as using numbers for refs and letters for notes.
Yes, of course. It's still a separate feature request in terms of implementing it.
I don't see how. If someone's implementing groups, they should implement the whole lot. Groups that don't display differently in the article are completely useless.
On 9/21/07, Thomas Dalton thomas.dalton@gmail.com wrote:
I don't see how. If someone's implementing groups, they should implement the whole lot. Groups that don't display differently in the article are completely useless.
Not completely. Witness http://en.wikipedia.org/wiki/Comparison_of_operating_systems. In fact, I don't like notes, and think footnotes should probably be reserved for references only, not general-purpose notes. Those cause you to have to jump back and forth constantly if you want to read the whole article properly.
On 21/09/2007, Simetrical Simetrical+wikilist@gmail.com wrote:
On 9/21/07, Thomas Dalton thomas.dalton@gmail.com wrote:
I don't see how. If someone's implementing groups, they should implement the whole lot. Groups that don't display differently in the article are completely useless.
Not completely. Witness http://en.wikipedia.org/wiki/Comparison_of_operating_systems. In fact, I don't like notes, and think footnotes should probably be reserved for references only, not general-purpose notes. Those cause you to have to jump back and forth constantly if you want to read the whole article properly.
Ok, not completely useless. They have one use, separate notes for each section.
It is easy to overuse footnotes, and then it gets annoying having to jump back and forth, but they do have their uses. Information that most people won't be interested in can go in a footnote where the few people that care can find it and those than don't can ignore it. If it were done as a parenthetical aside, people would have to waste their time reading it and determining that it could be ignored.
On 9/21/07, Thomas Dalton thomas.dalton@gmail.com wrote:
Information that most people won't be interested in can go in a footnote where the few people that care can find it and those than don't can ignore it. If it were done as a parenthetical aside, people would have to waste their time reading it and determining that it could be ignored.
Except that they have to do that *anyway*, since they don't know whether they're interested in the contents of the footnote until they read it. If most of your readers aren't interested in the material, maybe it belongs in a different article.
But anyway, that's a content issue.
Simetrical wrote:
On 9/21/07, Maury Markowitz maury.markowitz@gmail.com wrote:
On 9/20/07, Simetrical Simetrical+wikilist@gmail.com wrote:
<references group="foo" /> <references group="bar" />
Out of curiosity, how is {{reflist}} templated in? If I were to do {{reflist|group="foo"}}, would that work?
Someone would need to update {{reflist}}.
Or create a different template entirely, since the very name "reflist" implies that it displays a list of references. We could have {{reflist}}, {{notelist}}, etc, and each one could evolve its own style and conventions more easily.
What do you mean, using the text within the tags? Like <ref name="foo">Text to append</ref>? That strikes me as inevitably ambiguous, unless order becomes important again.
Yes, that was the suggestion, and the problem with it. I was wondering if someone had solved the problem and I simply missed the message.
It's impossible, unless I'm really missing something. If the only two refs with name "name" in a document are
<ref name="name">Foo</ref> <ref name="name">Bar</ref>
would the ref text be FooBar or BarFoo? Which is the base and which is appended? You presumably don't want to make order important again.
The idea requires an additional tag containing the information common to each citation.
<ref name="name">pp 1-7</ref> <ref name="name">pp 8-14</ref> <xref name="name">The Best Book Ever Written</xref>
This would produce two lines in the references section:
The Best Book Ever Written pp 1-7 The Best Book Ever Written pp 8-14
It might be better not to use <ref> and come up with a new name in order to keep backwards compatibility.
On 9/21/07, Thomas Dalton thomas.dalton@gmail.com wrote:
The idea requires an additional tag containing the information common to each citation.
<ref name="name">pp 1-7</ref> <ref name="name">pp 8-14</ref> <xref name="name">The Best Book Ever Written</xref>
This would produce two lines in the references section:
The Best Book Ever Written pp 1-7 The Best Book Ever Written pp 8-14
It might be better not to use <ref> and come up with a new name in order to keep backwards compatibility.
I think I'm sliding to the "nay" side on this one again.
If we simply use <REF> and demand that only one of them have the body (which is true today), then we eliminate the need for another tag. Editors could take advantage of the feature simply by adding "section=" (or whatever) params to existing REFs with no other changes. And there's nothing saying you couldn't add one of these params to the "body ref" either.
Maury
I think I'm sliding to the "nay" side on this one again.
If we simply use <REF> and demand that only one of them have the body (which is true today), then we eliminate the need for another tag. Editors could take advantage of the feature simply by adding "section=" (or whatever) params to existing REFs with no other changes. And there's nothing saying you couldn't add one of these params to the "body ref" either.
But using <ref> for the "body ref" results in an unwanted [1] at the end of the article, and an unwanted extra letter in the references section linking to it. If people are going to be able to put all the references at the end so they don't clutter the article (something people seem quite keen on), there has to be a difference between how you give the body of a ref and how you create an inline citation. That can be different tags, or different parameters, either would work. Personally, I prefer different tags, since they are doing different jobs (and it's shorter that way).
On 9/21/07, Thomas Dalton thomas.dalton@gmail.com wrote:
But using <ref> for the "body ref" results in an unwanted [1] at the end of the article
Oh yes, this is true currently, but if you scroll back a few messages, Simetrical has noted that a fix for this is already in the works.
Personally, I prefer different tags, since they are doing different jobs (and it's shorter that way).
I generally prefer separate tags for this sort of thing too. I think that a separate <note> tag vs. <ref group=notes> is an example, because I think it adds semantic content for other editors. That said, I'm pretty happy to see these changes going in as-is, and I fully understand the need for backwards compatibility at this point.
Now if only I could up with a better name than "backlink=", but so far I've failed.
Maury
Now if only I could up with a better name than "backlink=", but so far I've failed.
For what? Determining whether or not to display the backlink? How about "inline=false", meaning the <ref> tag isn't intended to describe an inline citation?
We seem to be agreed on what we want to do, it's just a matter of settling on a particular syntax now, and that isn't a big deal - all the suggestions given so far would work at least reasonably well.
"Thomas Dalton" thomas.dalton@gmail.com wrote in message news:a4359dff0709210755s43a44530y9f2b4b69edeb25c9@mail.gmail.com...
Now if only I could up with a better name than "backlink=", but so far I've failed.
For what? Determining whether or not to display the backlink? How about "inline=false", meaning the <ref> tag isn't intended to describe an inline citation?
We seem to be agreed on what we want to do, it's just a matter of settling on a particular syntax now, and that isn't a big deal - all the suggestions given so far would work at least reasonably well.
I pefer the <xref> syntax mentioned earlier.
Basically, <ref> continues to work as it does now (with the added 'section' parameter), except that if an <xref> exists with the same name (and section, if specified) then the contents are treated as something to be appended to the reference (e.g. "p110-115").
<xref> is therefore the same as <ref> except that (a) it is not displayed on the page and (b) it changes the way any <ref> tags with matching name (and section) are displayed, as described above.
It also makes a clearer semantic distinction between the two uses.
- Mark Clements (HappyDog)
On 9/21/07, Thomas Dalton thomas.dalton@gmail.com wrote:
For what? Determining whether or not to display the backlink?
Yes, exactly.
about "inline=false", meaning the <ref> tag isn't intended to describe an inline citation?
Well the more I think about this, the more "backlink=" starts to make sense...
<ref section="page 22-23" backlink="3a" />
seems pretty damb handy.
We seem to be agreed on what we want to do, it's just a matter of settling on a particular syntax now, and that isn't a big deal - all the suggestions given so far would work at least reasonably well.
Yes, I think there's been some amazing brainstorming here. I'm glad I brought the topic up, and I can't wait to start using these features!
Maury
Maury Markowitz wrote:
On 9/21/07, Thomas Dalton thomas.dalton@gmail.com wrote:
For what? Determining whether or not to display the backlink?
Yes, exactly.
about "inline=false", meaning the <ref> tag isn't intended to describe an inline citation?
Well the more I think about this, the more "backlink=" starts to make sense...
<ref section="page 22-23" backlink="3a" />
seems pretty damb handy.
One potentially limiting factor, though; what sort of formatting can be done inside an attribute like that? For example, if the reference is to a website one might want to include a link to a specific page or anchor in that "section" text. Or one might conceivably want to get fancy with styling for some reason. I'm not too familiar with the general conventions of XML but I'd expect that nesting tags inside of attributes is bad form.
On 9/22/07, Bryan Derksen bryan.derksen@shaw.ca wrote:
One potentially limiting factor, though; what sort of formatting can be done inside an attribute like that? For example, if the reference is to a website one might want to include a link to a specific page or anchor in that "section" text. Or one might conceivably want to get fancy with styling for some reason. I'm not too familiar with the general conventions of XML but I'd expect that nesting tags inside of attributes is bad form.
Wikilinks should work!
Maury
Maury Markowitz wrote:
On 9/22/07, Bryan Derksen bryan.derksen@shaw.ca wrote:
One potentially limiting factor, though; what sort of formatting can be done inside an attribute like that? For example, if the reference is to a website one might want to include a link to a specific page or anchor in that "section" text. Or one might conceivably want to get fancy with styling for some reason. I'm not too familiar with the general conventions of XML but I'd expect that nesting tags inside of attributes is bad form.
Wikilinks should work!
But would a <span> tag work? I can't think of a reason to use one offhand, but this is a matter of fundamental architecture that could be with us for a long time so IMO it's good to allow as much flexibility for future ideas as possible.
Thomas Dalton wrote:
If people are going to be able to put all the references at the end so they don't clutter the article (something people seem quite keen on),
Not everyone. I'm still leery of the notion ever since spending a while converting old {{ref}} templates (which worked that way) into the new <ref> format and finding a lot of orphaned or broken references that had been produced by unnoticed typos or subsequent editing. Sometimes I had to go back through many months worth of previous versions trying to find ones with unbroken references to salvage. I'd only support switching back to such a system if it were coded in a far more robust manner that made it obvious at a glance when something had gone wrong. What I'd like to see:
*A <ref/> tag with no body anywhere in the article should have some sort of glaring red warning to that effect, in the same sort of manner as we see when a <math> tag is fed badly formatted TeX. The current system produces a blank reference, which is better than nothing but still kind of easy to overlook. *A <ref> tag whose body is defined but not actually used anywhere in the article should still appear in the <references/>-generated list, with a bullet instead of a number. This is already done manually in a lot of cases when people add references directly to the references section.
This way nothing would ever get "lost" and broken stuff would get spotted and corrected more quickly and easily.
*A <ref/> tag with no body anywhere in the article should have some sort of glaring red warning to that effect, in the same sort of manner as we see when a <math> tag is fed badly formatted TeX. The current system produces a blank reference, which is better than nothing but still kind of easy to overlook. *A <ref> tag whose body is defined but not actually used anywhere in the article should still appear in the <references/>-generated list, with a bullet instead of a number. This is already done manually in a lot of cases when people add references directly to the references section.
Both good ideas.
On 23/09/2007, Thomas Dalton thomas.dalton@gmail.com wrote:
*A <ref/> tag with no body anywhere in the article should have some sort of glaring red warning to that effect, in the same sort of manner as we see when a <math> tag is fed badly formatted TeX. The current system produces a blank reference, which is better than nothing but still kind of easy to overlook. *A <ref> tag whose body is defined but not actually used anywhere in the article should still appear in the <references/>-generated list, with a bullet instead of a number. This is already done manually in a lot of cases when people add references directly to the references section.
Both good ideas.
BugZilla them, please.
Rob Church
On 23/09/2007, Rob Church robchur@gmail.com wrote:
On 23/09/2007, Thomas Dalton thomas.dalton@gmail.com wrote:
*A <ref/> tag with no body anywhere in the article should have some sort of glaring red warning to that effect, in the same sort of manner as we see when a <math> tag is fed badly formatted TeX. The current system produces a blank reference, which is better than nothing but still kind of easy to overlook. *A <ref> tag whose body is defined but not actually used anywhere in the article should still appear in the <references/>-generated list, with a bullet instead of a number. This is already done manually in a lot of cases when people add references directly to the references section.
Both good ideas.
BugZilla them, please.
Only the first is worth putting on BugZilla - the 2nd would be pointless with the current ref system, so it's best just to consider it part of the suggestion for a new system.
Only the first is worth putting on BugZilla - the 2nd would be pointless with the current ref system, so it's best just to consider it part of the suggestion for a new system.
I've put it on bugzilla, with a patch which should do it. The error goes at the bottom with the <references/>, since there is no way while parsing the <ref>s if text will be supplied later. See http://bugzilla.wikimedia.org/show_bug.cgi?id=11426
On 9/22/07, Bryan Derksen bryan.derksen@shaw.ca wrote:
*A <ref/> tag with no body anywhere in the article should have some sort of glaring red warning to that effect
Absolutely!
*A <ref> tag whose body is defined but not actually used anywhere in the article should still appear in the <references/>-generated list, with a bullet instead of a number.
Good idea. Additionally I'd propose a modification of Simetrical's idea, and perhaps a link="my link style" might be useful sometimes.
Maury
Thomas Dalton wrote:
<ref name="name">pp 1-7</ref> <ref name="name">pp 8-14</ref> <xref name="name">The Best Book Ever Written</xref>
How about:
<ref name="name">The Best Book Ever Written</xref> <ref name="name" append="pp 1-7" /> <ref name="name" append="pp 8-14" />
Backward compatible, consistent with tag formats and no new tags.
Mike
On 9/21/07, Michael Daly michaeldaly@kayakwiki.org wrote:
<ref name="name">The Best Book Ever Written</xref>
<ref name="name" append="pp 1-7" /> <ref name="name" append="pp 8-14" />
Works for me, but _one_ comment: if we want to be able to combine the section reference into the display somehow, we might want to have a specific para for this, "section=" or such. To see what I'm getting at, I'll paraphrase a ref from a recent article (actually, it's on the front page right now)...
<ref name="Soviets">[ link to a web page ] </ref> <ref name="Soviets" section="pp. 25-27" /> <ref name="Soviets" append="It should be noted that other sources disagree with this claim." />
In the second case we're saying we absolutely want to add a note to the end of the reference. In the first case, however, we're only specifying a section, we don't really care how it's displayed. It might simply be appended, but maybe someone else comes up with a better way to do this.
I'm not saying this is a must-have by any means, I'm of two minds whether the two would ever be different in practice.
Maury
On 21/09/2007, Maury Markowitz maury.markowitz@gmail.com wrote:
On 9/21/07, Michael Daly michaeldaly@kayakwiki.org wrote:
<ref name="name">The Best Book Ever Written</xref>
<ref name="name" append="pp 1-7" /> <ref name="name" append="pp 8-14" />
Works for me, but _one_ comment: if we want to be able to combine the section reference into the display somehow, we might want to have a specific para for this, "section=" or such. To see what I'm getting at, I'll paraphrase a ref from a recent article (actually, it's on the front page right now)...
<ref name="Soviets">[ link to a web page ] </ref>
<ref name="Soviets" section="pp. 25-27" /> <ref name="Soviets" append="It should be noted that other sources disagree with this claim." />
In the second case we're saying we absolutely want to add a note to the end of the reference. In the first case, however, we're only specifying a section, we don't really care how it's displayed. It might simply be appended, but maybe someone else comes up with a better way to do this.
I'm not saying this is a must-have by any means, I'm of two minds whether the two would ever be different in practice.
That kind of note should be a separate footnote. Having it as part of the reference means people no interested in references will miss it. It should be a footnote in the appropriate part of the article. The proposed group parameter makes that easily done.
One thing I haven't seen discussed - how will we distinguish between different groups with the inline links? If I see <sup>1</sup> in an article, how am I to know if it's a note or a ref?
On 9/21/07, Thomas Dalton thomas.dalton@gmail.com wrote:
One thing I haven't seen discussed - how will we distinguish between different groups with the inline links? If I see <sup>1</sup> in an article, how am I to know if it's a note or a ref?
Which does seem to argue a little for the original idea I proposed, a separate <note> tag that simply maps into <ref group="notes"> This would provide the casual editor with more information as to the purpose of the entry. But again, I'm not sure it really helps *that* much unless the original editor goes out of their way to make their entries opaque.
Maury
On 21/09/2007, Maury Markowitz maury.markowitz@gmail.com wrote:
On 9/21/07, Thomas Dalton thomas.dalton@gmail.com wrote:
One thing I haven't seen discussed - how will we distinguish between different groups with the inline links? If I see <sup>1</sup> in an article, how am I to know if it's a note or a ref?
Which does seem to argue a little for the original idea I proposed, a separate <note> tag that simply maps into <ref group="notes"> This would provide the casual editor with more information as to the purpose of the entry. But again, I'm not sure it really helps *that* much unless the original editor goes out of their way to make their entries opaque.
A difference in tag would only be useful for someone reading the wikitext, not viewing the HTML in a web browser, which is how people generally read articles.
On 9/21/07, Thomas Dalton thomas.dalton@gmail.com wrote:
A difference in tag would only be useful for someone reading the wikitext
But that's exactly what this thread is about...
With enough work you can abuse the existing ref system to do all of the things we're talking about here. But it's simply too much work. I know I would use more CITEs, in particular, if they weren't so hard to use.
<ref section="page 22-23" backlink="3a" /> seems pretty damb handy.
Why?
For all the same reasons as any of the ideas here... flexibility in order to allow editors to do things we might not imagine in this thread.
It's more likely they would want to change the notation of the reference instead, ie, "Bab97" instead of "1", but I don't see any reason to deliberately introduce inflexibility. Also the idea of introducing a param with only one possible value makes my stomach grumble.
Maury
Maury Markowitz wrote:
<ref name="Soviets">[ link to a web page ] </ref>
<ref name="Soviets" section="pp. 25-27" /> <ref name="Soviets" append="It should be noted that other sources disagree with this claim." />
We can do almost _anything_ with this format. Just keep adding keyword="value" and provide the appropriate processing for the keyword.
Also I agree that the append text should be supported. It is consistent with what The Chicago Manual of Style recommends.
Mike PS - now, having quickly flipped through my old copy of CMS, I should fix all those refs I've done recently to make them proper.
On 9/16/07, Maury Markowitz maury.markowitz@gmail.com wrote:
As an avid writer on the wiki, I am always frustrated by the current system for REFs (et all). They have little expressive power, break easily, and made editing _extremely_ difficult in certain circumstances. I consider this to be one of the biggest problems with the current MediaWiki software, it costs me perhaps as much as 15% wasted time on every article -- and a check over my contributions list should let you calculate what sort of real-world time that represents!
The good news is that I don't think any of these problems aren't fixable. For argument's sake, here's some of the problems I'd like to see fixed:
- CITE tags are _extremely_ large. Since the REF system requires them
to be embedded in-line in the article body, they can make editing of the articles very difficult. For instance, look at the article at:
http://en.wikipedia.org/wiki/Water_memory
Now click edit. Even trying to figure out what is part of the body, as opposed to the REFs, can be very difficult. Of course one can mitigate this problem, slightly, by removing the vertical white space, but that doesn't _really_ help the issue as much as you would like, and has the side-effect of making the CITEs themselves harder to edit.
- REFs should be _represented_ as footnotes, REFs, however, are _not
footnotes_. It seems whoever built the REF system seems to have forgotten this fact. Footnotes can be used for all sorts of different purposes, but with the current REF system the two become synonymous. I like to add notes about pronunciation and "trivial" links to other articles using footnotes, but there's simply no way to do this with the current system.
- There's no way to reference different page numbers! This is a
_serious_ problem, because it means if you want to use different portions of a single work, like a book, you have to put in a different CITE for each one. In reality, people just don't bother.
- I can't fold hand-edited refs into the REFLIST. For instance, let's
say I used a book for most of the body of an article, so I didn't bother putting lots of REFs inline. I did, however, add a half dozen different REFs inlined to support specific facts. Now how do I make the REFLIST look right? I can't! I end up with some numbered ones, and some bulleted, and due to the default styles, they look different. Uggg.
- REF should not be picky about position. Right now if you want to
use the same REF in more than one place, you can use a named ref. Generally the idea is good. However, this system demands that the body of the named ref be placed in the very first place that ref is used. This works great until you want to actually edit the article, at which point it because terribly easy to break _all_ the references with something as simple as a cut-n-paste.
Here's my suggested solutions:
- named refs should work no matter where the body of the reference is
placed. That would immediately fix most of these problems. I could, optionally, place only <ref name=x/> into the body, and remove all of the ref bodies to the ==References== section of the article. This would even allow me to fold "non-inlines" into the references list, using exactly the same mechanism.
I don't remember whether this causes any specific problems. The extension mechanism only gives you one tag at a time in the order they're presented in the article.
- there should be another, similar, tag for "real" footnotes. <note>
would be great. They would operate identically to (1).
Do you just want the ability to make two citation-like lists per article whereas you can make one now? If that's the case wouldn't a system where you can make and flush an arbitrary number of lists be better?
- named REFs can have another parameter, "page=". These would be
collected into the references at the bottom, with each lettered reference appearing.
A variation of this has already been suggested and I believe there's an open bug for it. "category" or "section" is more agnostic to the format being cited than "page" although I guess all could be provided.
How would I use this? Well using the water memory article as an example, I would...
- remove all the CITEs into the ==References== section, surrounded in
REF tags with a name.
- place name ref placeholders in the body of the article, some of
these may optionally include page numbers
- some of the comments would be surrounded with <note> tags, and
optionally removed to a new ==Notes== section.
Is there anything technically impossible here?
Not really. It really was a "worse is better" thing when I wrote it at the time and still is. Numerous people (yourself included) have pointed out various hairy bits and made some sound suggestions. But so far there haven't been any major upgrades to it.
Glad to see the original author chiming in!! Whatever the suggestions/criticisms, I for one, am very grateful for the work you put into Cite.
I would like to see more hooks in it, though.... ; )
On Sep 17, 2007, at 3:28 PM, Ævar Arnfjörð Bjarmason wrote:
<snip>
Not really. It really was a "worse is better" thing when I wrote it at the time and still is. Numerous people (yourself included) have pointed out various hairy bits and made some sound suggestions. But so far there haven't been any major upgrades to it.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
===================================== Jim Hu Associate Professor Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054
On 9/17/07, Ævar Arnfjörð Bjarmason avarab@gmail.com wrote:
- there should be another, similar, tag for "real" footnotes. <note>
would be great. They would operate identically to (1).
Do you just want the ability to make two citation-like lists per article whereas you can make one now? If that's the case wouldn't a system where you can make and flush an arbitrary number of lists be better?
How many are we likely to want? Enough that general-purposing the mechanism (rather than a second instance) makes sense?
- named REFs can have another parameter, "page=". These would be
collected into the references at the bottom, with each lettered reference appearing.
A variation of this has already been suggested and I believe there's an open bug for it. "category" or "section" is more agnostic to the format being cited than "page" although I guess all could be provided.
How about 'specific="page 45-47"'; that way you can put in whatever internal location specification makes contextual sense given the media being referred to...
How about 'specific="page 45-47"'; that way you can put in whatever internal location specification makes contextual sense given the media being referred to...
If the actual contents of the refs is put at the bottom, with a different tag, the specific part can just be the contents of the ref tag: <ref name="foo">page 10</ref>
On 9/17/07, Thomas Dalton thomas.dalton@gmail.com wrote:
How about 'specific="page 45-47"'; that way you can put in whatever internal location specification makes contextual sense given the media being referred to...
If the actual contents of the refs is put at the bottom, with a different tag, the specific part can just be the contents of the ref tag: <ref name="foo">page 10</ref>
Not backwards compatible... You might be able to code a bot to fix that, but...
On 17/09/2007, George Herbert george.herbert@gmail.com wrote:
On 9/17/07, Thomas Dalton thomas.dalton@gmail.com wrote:
How about 'specific="page 45-47"'; that way you can put in whatever internal location specification makes contextual sense given the media being referred to...
If the actual contents of the refs is put at the bottom, with a different tag, the specific part can just be the contents of the ref tag: <ref name="foo">page 10</ref>
Not backwards compatible... You might be able to code a bot to fix that, but...
If could be implemented is a backwards compatible way - if there is a tag containing the general details of the ref on the page, then assume it's using the new system, otherwise assume it's using the old system. The general details would need to be in something other than a <ref> tag anyway for any of this to work.
On 9/17/07, Thomas Dalton thomas.dalton@gmail.com wrote:
If the actual contents of the refs is put at the bottom, with a different tag, the specific part can just be the contents of the ref tag: <ref name="foo">page 10</ref>
Well I would personally like something a little more styled. When you make multiple references to a single document now, you get a number followed by a list of superscripted letters for each reference. I would like (I think) to keep that style, but allow the letters to also have a page number associated with them.
I'm definitely not married to the idea though. A list of "ibid, page 5" might be even better, and would match journal referencing styles more closely. But of course we need to consider whether or not we want to match dead-tree styles or do something "better".
Maury
On 18/09/2007, Maury Markowitz maury.markowitz@gmail.com wrote:
On 9/17/07, Thomas Dalton thomas.dalton@gmail.com wrote:
If the actual contents of the refs is put at the bottom, with a different tag, the specific part can just be the contents of the ref tag: <ref name="foo">page 10</ref>
Well I would personally like something a little more styled. When you make multiple references to a single document now, you get a number followed by a list of superscripted letters for each reference. I would like (I think) to keep that style, but allow the letters to also have a page number associated with them.
I'm definitely not married to the idea though. A list of "ibid, page 5" might be even better, and would match journal referencing styles more closely. But of course we need to consider whether or not we want to match dead-tree styles or do something "better".
My suggestion is just for how to include the info in the wikitext - how its displayed when parsed is a completely separate issue.
On 9/18/07, Thomas Dalton thomas.dalton@gmail.com wrote:
My suggestion is just for how to include the info in the wikitext - how its displayed when parsed is a completely separate issue.
Oh I know, I'm just thinking that we might want to "formalize" the information in order to make rendering easy. For instance, if you put text into the body of the ref tag, as you note, the parser would likely have a hard time deciding how to render it -- is it just some text that should be placed after the ref, or a page number that becomes part of it? I'm guessing it would need more meta-information in order to decide. That's, of course, assuming we want it to!
Maury
On 18/09/2007, Maury Markowitz maury.markowitz@gmail.com wrote:
On 9/18/07, Thomas Dalton thomas.dalton@gmail.com wrote:
My suggestion is just for how to include the info in the wikitext - how its displayed when parsed is a completely separate issue.
Oh I know, I'm just thinking that we might want to "formalize" the information in order to make rendering easy. For instance, if you put text into the body of the ref tag, as you note, the parser would likely have a hard time deciding how to render it -- is it just some text that should be placed after the ref, or a page number that becomes part of it? I'm guessing it would need more meta-information in order to decide. That's, of course, assuming we want it to!
There is an argument for including more semantic information in the reference, but the argument against it is that it restricts how people can use the feature. I think just adding text to the end of the reference would work fine, and could be used for far more than just page numbers.
On 9/17/07, George Herbert george.herbert@gmail.com wrote:
On 9/17/07, Ævar Arnfjörð Bjarmason avarab@gmail.com wrote:
- there should be another, similar, tag for "real" footnotes. <note>
would be great. They would operate identically to (1).
Do you just want the ability to make two citation-like lists per article whereas you can make one now? If that's the case wouldn't a system where you can make and flush an arbitrary number of lists be better?
How many are we likely to want? Enough that general-purposing the mechanism (rather than a second instance) makes sense?
What I've gathered from the people that want footnotes is that they want another list per-article they can flush with a different tag, i.e.:
""" Some statement<ref name="ref name">This is a reference</ref> and something to note<note name="note name">This is a note</note>.
== References == <references/>
== Notes == <notes/> """
If that's the case I think *implementation wise* it would be a neat idea to support reference groups, so the above could be written as:
""" Some statement<ref group="references" name="ref name">This is a reference</ref> and something to note<ref group="notes" name="note name">This is a note</ref>.
== References == <references group="references"/>
== Notes == <references group="notes"/> """
And since that's a bit more verbose the <note> and <notes> tags could be provided anyway, they'd just be exactly equivalent to providing a group=notes (or some other name) to the ref/references pair.
The reason I mention that is that although I'm wont to design crappy stuff I at least like to make it crappy in a general way so people can hammer things I hadn't thought of out of it.
Would that cover the notes use case in your (and other list members) opinion?
- named REFs can have another parameter, "page=". These would be
collected into the references at the bottom, with each lettered reference appearing.
A variation of this has already been suggested and I believe there's an open bug for it. "category" or "section" is more agnostic to the format being cited than "page" although I guess all could be provided.
How about 'specific="page 45-47"'; that way you can put in whatever internal location specification makes contextual sense given the media being referred to...
Something like that, I really don't feel like taking a stance on specific interfaces given my obviously flawed track record in designing something people are happy with. But element names should in my opinion:
1. Be easy to type and remember for an international audience (which extensions inherently fail at since you can't localize them, but I digress) 2. Be general enough to apply to pages/chapters/whatever 3. Something else I'm forgetting :)
On 9/17/07, Ævar Arnfjörð Bjarmason avarab@gmail.com wrote:
I don't remember whether this causes any specific problems. The extension mechanism only gives you one tag at a time in the order they're presented in the article.
It definitely _used to_, but as others have pointed out, this is no longer the case. Yippy!
Do you just want the ability to make two citation-like lists per article whereas you can make one now? If that's the case wouldn't a system where you can make and flush an arbitrary number of lists be better?
Yes. However the mainline uses of "the lists at the bottom" will be references and "real" footnotes. Having a custom tag for the later doesn't seem too much to ask. I mean, you can make an entire web site using nothing more than SPAN and various class tags, yet most people prefer using P tags :-)
A variation of this has already been suggested and I believe there's an open bug for it. "category" or "section" is more agnostic to the format being cited than "page" although I guess all could be provided.
Do you happen to have a page link to this thread?
Again, a general solution to this problem is excellent, but adding tags for specific common cases would also be a good thing.
Not really. It really was a "worse is better" thing when I wrote it at the time and still is. Numerous people (yourself included) have pointed out various hairy bits and made some sound suggestions. But so far there haven't been any major upgrades to it.
Well then it's time to put my mad development skillz to the test: would you mind e-mailing me a copy of the current cite.php?
Maury
On 9/18/07, Maury Markowitz maury.markowitz@gmail.com wrote:
On 9/17/07, Ævar Arnfjörð Bjarmason avarab@gmail.com wrote:
I don't remember whether this causes any specific problems. The extension mechanism only gives you one tag at a time in the order they're presented in the article.
It definitely _used to_, but as others have pointed out, this is no longer the case. Yippy!
Do you just want the ability to make two citation-like lists per article whereas you can make one now? If that's the case wouldn't a system where you can make and flush an arbitrary number of lists be better?
Yes. However the mainline uses of "the lists at the bottom" will be references and "real" footnotes. Having a custom tag for the later doesn't seem too much to ask. I mean, you can make an entire web site using nothing more than SPAN and various class tags, yet most people prefer using P tags :-)
A variation of this has already been suggested and I believe there's an open bug for it. "category" or "section" is more agnostic to the format being cited than "page" although I guess all could be provided.
Do you happen to have a page link to this thread?
Again, a general solution to this problem is excellent, but adding tags for specific common cases would also be a good thing.
Not really. It really was a "worse is better" thing when I wrote it at the time and still is. Numerous people (yourself included) have pointed out various hairy bits and made some sound suggestions. But so far there haven't been any major upgrades to it.
Well then it's time to put my mad development skillz to the test: would you mind e-mailing me a copy of the current cite.php?
The latest version is in SVN under extensions
On 9/18/07, Ævar Arnfjörð Bjarmason avarab@gmail.com wrote:
The latest version is in SVN under extensions
Got it. Where do I find the css?
Maury
On Tue, 18 Sep 2007 09:58:44 -0400, Maury Markowitz wrote:
On 9/17/07, Ævar Arnfjörð Bjarmason
Again, a general solution to this problem is excellent, but adding tags for specific common cases would also be a good thing.
That seems a bit non-intuitive to me. I'd think if someone knows what <ref> is, then <ref group=footnote> should be fairly obvious. It would be less obvious that <note> is the same thing.
IMHO, changing the behavior so that reference list is cleared when rendered, and adding the group parameter would accomplish a lot.
That seems a bit non-intuitive to me. I'd think if someone knows what <ref> is, then <ref group=footnote> should be fairly obvious. It would be less obvious that <note> is the same thing.
It's quite a lot longer, though. An alias for commonly used groups would make life much simpler.
On 18/09/2007, Maury Markowitz maury.markowitz@gmail.com wrote:
Well then it's time to put my mad development skillz to the test: would you mind e-mailing me a copy of the current cite.php?
http://www.mediawiki.org/wiki/Subversion
Rob Church
wikitech-l@lists.wikimedia.org