Last modified: 2010-05-18 21:51:57 UTC
I hope I have the component right - this relates to <ref> and <references> tags. There are two general types of problems: 1) This doesn't work: <ref name = "foo" />... <ref name = "foo">www.foo.com </ref> ... <references /> That is, the *definition* of the footnote absolutely has to be the first time the reference is used. This is particularly awkward when later adding more footnotes from the same source, particularly if one works backwards. Each time you want to refer to the source, you have to both locate the current first reference to that source, update it to the form without definition, then move the definition up. More likely, you end up just duplicating the reference all over the place. 2) Long citations in the body of the text make the code pretty much unreadable, especially compared to the previous template-based way of handling footnotes, where the definition of the footnote was at the bottom of the page in the footnotes section. General proposal: 1. Allow references to refer to undefined footnotes. 2. Allow some mechanism whereby a footnote can be solely a definition without actually displaying anything at that point. This would allow the following: <ref name="foo" /> <ref name = "bar" /> <ref name = "foo">www.foo.com</ref> ==References== <ref name = "bar" hide="true">Some really long citation that is best kept out of the body of the text to improve readability. Only one footnote reference [1] should be generated - up in the main body. <references /> <!-- should contain definition for foo (referenced twice) and bar (referenced once) -->
Apparently a solution to proposal 1. above exists: http://en.wikipedia.org/wiki/Wikipedia_talk:Footnotes#Fixing_non-1st_ref_content
Suggestion regarding the second point: ==References == <references> <ref name=foo>Define the foo reference in here. If there's a <nowiki><ref name=foo/></nowiki> then it will show up as a numbered reference linking up to the appropriate [#]. If not, then it will show up at the end of the list as an UNNUMBERED reference, no link required.</ref> </references> HTH HAND
Looks good. Thought you meant it actually already works (http://en.wikipedia.org/wiki/User:Stevage/reftest) but you must mean a proposal for new syntax. I like this overall - it's still quick and easy to make references for quick footnotes, but when you have a lot and they are quite substantial, there is a way of getting them out of the body of the article.
The suggestion in comment 2 sounds good to me. With the parser fixes in 1.7 it should be doable.
I provided a fix for this under bug 5885: --- Cite.php 2006-05-04 13:12:19.000000000 -0400 +++ Cite.php.new 2006-05-04 12:47:24.000000000 -0400 @@ -291,7 +291,12 @@ $this->mRefs[$key]['number'] ); } else - // We've been here before + // We've been here before + $found_text = $this->mRefs[$key]['text']; + if ( empty($found_text) and !empty($str)) { + // If no text found before, use this text + $this->mRefs[$key]['text'] = $str; + } return $this->linkRef( $key,
Please *do not* encourage people to avoid including the full contents of the <ref> at least once in an appropriate place until it's impossible to save invalid references (i.e., it refuses to save <ref name="name" /> if no <ref name="name">...</ref> has been defined). I've had to clean up multiple pages where someone used the old {{ref|...}} and it got disconnected from the accompanying {{note|...}}, and it's a nightmare: you have to dredge through tons of history to find where it got cut off.
Agree. Similar (extensive) talk and poll at http://en.wikipedia.org/wiki/Wikipedia_talk:Footnotes Suggestion was (among others) to NOT allow orphan refs, by red error in preview/save.
I would amend my previous suggestion slightly, however, by saying an error should be thrown up but the save should go through fine. That would allow the problem to be caught quickly and thus fixed easily, while still not losing submitted data in the event of a save-and-forget or something of the sort.
sure
It would be nice, and logical, if citations could go into a container tag: <ref name="Smith 2006" />... ... <references> <ref name="Smith 2006">Smith, John (2006) ''References''. London: Penguin.</ref> </references> This would allow some citations to be placed without a citation in the text. The order they appear in the references section could also be used to manually sort the list, with <references sort="manual"></references>.
Created attachment 2286 [details] Patch to extend the capabilities of Cite I sent this patch to Avar a while ago, but haven't heard anything. It extends Cite by doing the following: * Added <refdefine>. This can be used to define a reference in the same way as <ref>, but may appear anywhere in the file and outputs nothing. This is motivated by the complaint that the inline <ref> definitions can make heavily cited text hard to edit, so this provides the ability to collect all the ref definitions in some central part of the file. These would then be referred to by <ref name="foo"/> as with other indirect references. * Added 'text' argument to <ref> and "cite_reference_link_with_text" message. This allows one to pass an optional label that can be used with the reference link. By default, this translates [1] to [1 - some label]. This would allow one to use Harvard style notes in footnotes, e.g. "[1 - Dyurgerov and Meier 1999]" or to denote a specific section of the reference, e.g. "[3 - page 11]". By design, a 'text' attribute appearing in <refdefine> (or in the first <ref> if no <redefine> exists for that key) is applied to all references with the same key, unless they individually specify a different value of 'text'. 'text' appearing in subsequent calls to <ref> applies to that call only. * Modified "Cite::stack" so that the reference information need not be given in the first <ref> call, but can be placed in any <refdefine> or <ref> call within the same document. * Added error messages for <refdefine> used with no corresponding <ref> and for multiple attempts to define the same <ref> or <refdefine>. This latter case is the only situation that changes existing behavior. In the existing version, attempts to redefine a ref result in the new definition being ignored. I hope that you will review these modifications and consider adding them (or something similar) into the live version.
That sounds great, hope someone can have a look. Your "text" argument sounds very interesting - would it be possible to allow URLs? Allowing a footnote reference to generate HTML like this would be great: As John Smith said [<A HREF="#footnote1"1</A> <A HREF>URL</A>], fish are smelly. In other words, you could have *two* links within the text - one takes you to the full citation at the bottom of the page, and one takes you directly to the web page being cited. Note that the link to the webpage should always be some short text like "URL" or "Web" or whatever.
Part 1 of the bug has been fixed already, which alleviates the problem described in Part 2.
*** Bug 12765 has been marked as a duplicate of this bug. ***
Please see related bug 12796 which, among other things, addresses point 2 by allowing footnote text to be declared in a footnote-declaration block outside of the main body of the article prose.
*** Bug 12358 has been marked as a duplicate of this bug. ***
There are now a solution of the annoying situation with full reference definitions inside the text. This is partly described at comment #9. Instead of defining the text inside <ref> tags it is defined inside the <references> tags, yet also the previous form can be used. The description of the necessary changes is on the page http://www.mediawiki.org/wiki/Extension_talk:Cite/Cite.php#Variation_for_refs_in_the_final_references_block
That should be comment #11, not comment #9.
I like comment #11. It is further described by [[User:Saldan]]: [M]y suggestion would be; use of <source lang="xml"><references group="xyz"> <ref name="asdf">Easter bunny.</ref><ref name="qwer">Mooo</ref> <ref name="zxcv"/> </references> <references group="xyz"/></source>. In that example: :# any use of <code>ref</code> like <source lang="xml"> <references> <ref>...</ref> <!-- or --><ref/> <!-- inside an enclosing --> </references> </source> block ''removes'' a reference from the automatic list :# <source lang="xml"><references> <ref name="jkl">...</ref> <!-- inside an enclosing --> </references> </source> provides an in-place definition :# <source lang="xml"><references> <ref name="jkl"/> <!-- inside an enclosing --> </references> </source> expands a definition in-place. :# <source lang="xml"><references/></source> alone, expands all automatic references remaining. :Everything should to apply within its correct <code>group=""</code> scope. The result of that should allow bibliography styles: <source lang="xml"> Do it like this<ref name="mos-dates">Manual of Style<ref group="bib" name="mos"/>, Dates</ref> and that<ref name="mos-moo">Manual of Style<ref group="bib" name="mos"/><ref name="good-practice">lala</ref>, Transliteration of Bovine language</ref>. Remember to take care with negative dates!<ref name="mos-dates"/> ==References== {{reflist}} <!-- Expands default references group --> ==Bibliography== ;Ordered <references group="bib"> <ref name="mos">{{cite web|work=Wikifoo|title=Manual of Style|url=...}}</ref> <ref name="good-practice"/> <references> ;All the rest <references group="bib"/> <!-- Expands all non-manually listed --> </source> :The alternative to relying on overloading <code>ref</code> is to add a <code>refdef</code> tag that causes expansion, or definition, and always acts as the definition/endpoint. —[[User:Sladen|Sladen]] 14:44, 25 September 2008 (UTC)
Reformatting and slight rewording of previous post for readability and clarity: ------------------------------- [M]y suggestion would be; use of <references group="xyz"> <ref name="asdf">Easter bunny.</ref> <ref name="qwer">Mooo</ref> <ref name="zxcv"/> </references> [sic] <references group="xyz"/> In that example: <references> <ref>...</ref> </references> This removes a reference from the automatic list. <references> <ref name="jkl">...</ref> </references> This provides an in-place definition <references> <ref name="jkl"/> </references> This expands a definition in-place. <references/> alone expands all automatic references remaining. Everything should apply within its correct 'group=""' scope. The result of that should allow bibliography styles: ---- Do it like this<ref name="mos-dates">Manual of Style<ref group="bib" name="mos"/>, Dates</ref> and that<ref name="mos-moo">Manual of Style<ref group="bib" name="mos"/><ref name="good-practice">lala</ref>, Transliteration of Bovine language</ref>. Remember to take care with negative dates!<ref name="mos-dates"/> ==References== {{reflist}} <!-- Expands default references group --> ==Bibliography== ;Ordered <references group="bib"> <ref name="mos">{{cite web|work=Wikifoo|title=Manual of Style|url=...}}</ref> <ref name="good-practice"/> <references> ;All the rest <references group="bib"/> <!-- Expands all non-manually listed --> ---- The alternative to relying on overloading 'ref' is to add a 'refdef' tag that causes expansion, or definition, and always acts as the definition/endpoint.
Created attachment 5414 [details] Adds 'visible' attribute to 'ref' tag This works like this: ==Article== * AAA<ref name="aaa"/> * BBB<ref name="bbb">This is a ref for BBB</ref> * CCC<ref name="ccc" group="c"/> ==Refs== <ref visible="no" name="aaa">This is a ref for AAA</ref> <ref name="ccc" group="c" visible="no">This is a ref for CCC</ref> <ref name="ddd" visible="no">This is a ref for DDD</ref> <references/> <references group="c"/>
I suggest that we approach the problem in two phases: Phase 1, add 'visible' attribute to <ref>, as in attachment (id=5414). This is an easy change with low risk. Nevertheless, it provides an easy to use solution to the editors, where the citation body need not placed in the article text. Phase 2, enhance <references/> so that <ref> tags can be placed within it. This would imply that the visibility of the <ref>'s will be 'visible="no"', and that the group will be that of the parent tag, if specified. Further, 'group' and 'visible' attributes specified in the <ref> itself, will override that of the <references/>. This would work like this: ==Article== * AAA<ref name="aaa"/> * BBB<ref name="bbb">This is a ref for BBB</ref> * CCC<ref name="ccc" group="c"/> ==Refs== <references> <ref name="aaa">This is a ref for AAA</ref> <ref name="ddd" visible="yes">Force this into the list, even if it's not referenced in the article</ref> </references> <references group="c"> <ref name="ccc">This is a ref for CCC</ref> </references/>
I don't see any use of "visibility=no", and the final solution seems to be more of a solution for machines then humans. The main problem is that the overall solution already is to little readable, and because of this it is not a very good solution to increase the complexity and make it even less readable. What's the minimum necessary markup to get it working, and can it be simplified?
Agree that "visibility" flag is not needed: <ref name="foo">...</ref> - not within <references />, therefore should render as a [1]. <ref name="bar" /> - should render as a [2]. <references> <ref name="bar">...</ref> - foo (implicitly listed) and bar should render the same here. <ref name="baz">...</ref> - should render like foo and bar. <ref name="bort" /> - illegal, meaningless. <references /> The desired semantics seem pretty clear to me. I don't see any need for "visible" or "decl" (bug 12796) flags. Other features like grouping or "headers" (also 12796) might be useful, but they're not required to address the two major issues here. Open question: What is the correct ordering of: a) Implicitly listed refs (defined in text, not referred to in <references />) b) Explicitly listed refs (referred to in text, defined in <references />) c) Double-listed refs (defined in text, referred to in <references />, like if we added <ref name="foo" /> in the example above) Anyway, seems like the patch in 12796 does most of what we want, someone just needs to tweak it a bit and Make It Happen.
For a thumbnail description of an alternative approach which I believe would be simpler and cleaner, see [[http://en.wikipedia.org/wiki/User_talk:Wtmitchell#Bug_12796 this section]] on my talk page. I'm currently traveling, will be away from home for the next few weeks, and won't have the time or handy facilities to contribute much on this. -- ~~~~
It is a solution, but a solution for someone who writes xml-code. This is for a wiki written by humans, and because of this it has to be a lot simpler. As I see it, xml is nice for machines and people used to write code. It is not something to learn a 80 year old grandma. The wiki-code is even to complex, but it is way much easier than xml-code. Use of <ref name="foo" /> in the text should be _allowed_ but it should not be the primary method of referencing citations. Something like {{ref:foo}} or even {foo} should be sufficient. Under a heading ==Bar==, or any identifiable group, a reordering should be done and any identifiable references should be pulled into a group <references group="bar" />. One group should be default to all refs without a group, someting like ==References==. A reordering could be done by parsing the text and identifying certain aspects of the text. Probably there should be several such parsers and probably they should use some of the more common forms for citation. At least one should allow identified attributes. But the real solution is going one step further, if a declaration for a ref - no matter how its identified, can't be found, then he extension should use a mechanism for collecting those references from external sites. In Norway that could for example be http://www.bibsys.no. Wikimedia Norway has had talks with Bibsys about such use, and there are probably other similar sites for other countries. For web pages such data may be delivered as Dublin Core metadata or as RDF frameworks. Anyhow, first step is to make citations a lot easier to use, next step is to make it possible to only _identify_ the citation and let the rest come from external sites. Note that the actual use of citations within Wikipedia is very important for such sites as it builds subject references for them to use.
Re comment#27 above, if that is intended as a suggestion that the Ref & References tag pair which the Cite.php code supports, That is firmly entrenched. See [[Wikipedia:FOOT]]. The template {{Ref}} already exists at Wikipedia, and does something different from what comment#27 above describes. Some sort of template to turn, say {{Foot|foo}} into <Ref name=foo> and suchlike would be easy to write, once the template name is chosen, the template parameters and the desired wikitext output corresponding to various parameter combinations are defined, but that's another topic for another venue. It has little or nothing to do with the cite extension.
Its not about replacing <ref> with a template, its about smarter references. If a reference goes to a identifiable book, for example with an ISBN-number, then it is no reason why the user should manually enter the data. Likewise with an url. The whole extension as it is centers around a specific syntax that is difficult to use because it has to coope with unreadable templates and because they have to be filled in manually. The solution isn't to make it even more unreadable, it is to solve the main reason why it is unreadable, and that can best be done by reducing the use of the template and the necessity of doing the job altogether.
*** Bug 12538 has been marked as a duplicate of this bug. ***
This looks similar to functionality already implemented in [https://bugzilla.wikimedia.org/show_bug.cgi?id=18890 Bug 18890]. A test wiki for Bug 18890 is available [siteslot.com/testwiki2 here.
This looks similar to functionality already implemented in Bug 18890. A test wiki for Bug 18890 is available [http://siteslot.com/testwiki2 here].
The extended functionality to allow refs to be defined within the references block - described in comment 2 and others - has been implemented in r53790. In other words it will now be possible to use constructions of the form: <ref name="foo" /> <references> <ref name="foo">Bar bar bar</ref> </references> To define the content of the named reference.
Re comment #33 From Robert Rohde; Yes. As I said, similar to Bug# 18890, which implements similar functionality with syntax as follows: ---begin <ref name="foo" /> (probably more than one ref; probably several refs, having several different names.) <ref def name="foo">Bar bar bar</ref> (note the "def" element. probably a block of these; one for each name.) </references /> ---end Note that the order of the expanded refs can be controlled by the editor by situating the block of <ref def name=whatever>...</ref> defs ahead of the wikitext. The refs will then be expanded in the order in which they were invisibly defined. See the test wiki at http://www.siteslot.com/testwiki2/ Apologies for my terseness here; I am in an internet cafe and am hurrying because I need to be on an airplane later today.
(In reply to comment #34) > Re comment #33 From Robert Rohde; Yes. As I said, similar to Bug# 18890, which > implements similar functionality with syntax as follows: > > ---begin > <ref name="foo" /> (probably more than one ref; probably several refs, having > several different names.) > > > <ref def name="foo">Bar bar bar</ref> (note the "def" element. probably a block > of these; one for each name.) > > > </references /> > ---end As noted at http://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Citing_sources&oldid=304379503#Option_.232:_Allow_reference_content_to_be_defined_anywhere The enwiki editing community appears to be mostly opposed to a "def" or "hidden" syntax that would allow ref content to be defined at any arbitrary position in the text. They strongly supported the alternative of moving the definitions into the references block however, so that's the only version I implemented.
Re comment #35. I'm happy to go along with community consensus. I think adopting an implementation of a facility allowing hidden declaration of ref body content outside of the wikitext prose would be a good thing, whether done via the "ref def" syntax which I implemented in bug# 18890 or with an alternative implementation. As I understand it, the alternative implementation limits the location of hidden ref body declarations to the references block, and omits the optional ability of editor control over the ordering of the expanded footnotes which the "ref def" implementation which I have online at at http://siteslot.com/testwiki2 provides, but if the community consensus is to forego that optional editor control ver ordering of the expanded footnotes, then that is the community consensus.
Doesn't the [[Wikipedia:Citing_sources#List-defined references|List-defined references]] feature fix this bug?
I agree. I'm closing this as the main thrust is already addressed by the LDR features. (Some other features discussed in comments here that weren't implemented should probably be moved to new requests if people still want to pursue them.)
