Hi all,
The current <ref>...</ref>...<references/> system produces nice references, but it is flawed--all the text contained in a given reference appears in the text that the reference is linked from. For example:
It was a sunny day on Wednesday<ref>David Smith. ''History of Wednesdays.'' History Magazine, 2019.</ref>. The next day, Thursday, was cloudy.
== References and notes ==
<references/>
(That's a very simple example, too. References start to become a lot larger once they start to include other information and/or are produced via a template.)
Once way I could conceive of correcting the problem is to have a reference tag that provides only a _link_ to the note via a label and another type of reference tag that actually _defines_ and _displays_ the note. For example:
It was a sunny day on Wednesday<ref id="smith"/>. The next day, Thursday, was cloudy.
== References and notes ==
<reference id="smith">David Smith. ''History of Wednesdays.'' History Magazine, 2019.</reference>
This makes the raw wikitext easier to read, since the text of the actual reference is in the _references_ section instead of in the page's primary content.
I think this could work ...
--Thomas Larsen
That's not a bad idea. I've had some troubles with this too. If we were to implement something like this though, we'd still have to accept the old version for a while, until it can change in each article.
On Dec 3, 2008, at 8:46 PM [Dec 3, 2008 ], Thomas Larsen wrote:
Hi all,
The current <ref>...</ref>...<references/> system produces nice references, but it is flawed--all the text contained in a given reference appears in the text that the reference is linked from. For example:
It was a sunny day on Wednesday<ref>David Smith. ''History of Wednesdays.'' History Magazine, 2019.</ref>. The next day, Thursday, was cloudy.
== References and notes ==
<references/>
(That's a very simple example, too. References start to become a lot larger once they start to include other information and/or are produced via a template.)
Once way I could conceive of correcting the problem is to have a reference tag that provides only a _link_ to the note via a label and another type of reference tag that actually _defines_ and _displays_ the note. For example:
It was a sunny day on Wednesday<ref id="smith"/>. The next day, Thursday, was cloudy.
== References and notes ==
<reference id="smith">David Smith. ''History of Wednesdays.'' History Magazine, 2019.</reference>
This makes the raw wikitext easier to read, since the text of the actual reference is in the _references_ section instead of in the page's primary content.
I think this could work ...
--Thomas Larsen
WikiEN-l mailing list [email protected] To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
I'm also forwarding this to the wikitech-l list.
On Dec 3, 2008, at 8:46 PM [Dec 3, 2008 ], Thomas Larsen wrote:
Hi all,
The current <ref>...</ref>...<references/> system produces nice references, but it is flawed--all the text contained in a given reference appears in the text that the reference is linked from. For example:
It was a sunny day on Wednesday<ref>David Smith. ''History of Wednesdays.'' History Magazine, 2019.</ref>. The next day, Thursday, was cloudy.
== References and notes ==
<references/>
(That's a very simple example, too. References start to become a lot larger once they start to include other information and/or are produced via a template.)
Once way I could conceive of correcting the problem is to have a reference tag that provides only a _link_ to the note via a label and another type of reference tag that actually _defines_ and _displays_ the note. For example:
It was a sunny day on Wednesday<ref id="smith"/>. The next day, Thursday, was cloudy.
== References and notes ==
<reference id="smith">David Smith. ''History of Wednesdays.'' History Magazine, 2019.</reference>
This makes the raw wikitext easier to read, since the text of the actual reference is in the _references_ section instead of in the page's primary content.
I think this could work ...
--Thomas Larsen
WikiEN-l mailing list [email protected] To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
I believe sometime we will go in this direction. But at the moment this would mean that the edit would be more complicated. The problem is if I edit a section, I put in <ref id="smith" />. But at the same time I cannot add <reference id="smith">...</reference> into the References and Notes section. I must do that either in two separate edits or I must edit the article as a whole. Also here we need a new technical solution.
Ting
Thomas Larsen wrote:
Hi all,
The current <ref>...</ref>...<references/> system produces nice references, but it is flawed--all the text contained in a given reference appears in the text that the reference is linked from. For example:
It was a sunny day on Wednesday<ref>David Smith. ''History of Wednesdays.'' History Magazine, 2019.</ref>. The next day, Thursday, was cloudy.
== References and notes ==
<references/>
(That's a very simple example, too. References start to become a lot larger once they start to include other information and/or are produced via a template.)
Once way I could conceive of correcting the problem is to have a reference tag that provides only a _link_ to the note via a label and another type of reference tag that actually _defines_ and _displays_ the note. For example:
It was a sunny day on Wednesday<ref id="smith"/>. The next day, Thursday, was cloudy.
== References and notes ==
<reference id="smith">David Smith. ''History of Wednesdays.'' History Magazine, 2019.</reference>
This makes the raw wikitext easier to read, since the text of the actual reference is in the _references_ section instead of in the page's primary content.
I think this could work ...
--Thomas Larsen
WikiEN-l mailing list [email protected] To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
Ting Chen wrote:
I believe sometime we will go in this direction. But at the moment this would mean that the edit would be more complicated. The problem is if I edit a section, I put in <ref id="smith" />. But at the same time I cannot add <reference id="smith">...</reference> into the References and Notes section. I must do that either in two separate edits or I must edit the article as a whole. Also here we need a new technical solution.
Worse, someday the section may be moved to another article, or to its own article, and then <ref id="smith" /> becomes meaningless.
Back before the cite extension was added to Wikipedia, references were done almost entirely using a set of templates that behaved just as this proposals described. When the cite extension was added I spent a lot of time converting articles over to use it, and in the process I found a lot of broken references - links in the text that had no associated footnote, footnotes that had no associated links. It was a mess. With the current system it's impossible for a mess like that to happen since references are entirely self-contained.
Personally, I prefer the current system. Much more robust. If we were to split references and links again it would need to have a lot of warnings in 18-point red letters appear whenever breaks like this occurred.
2008/12/4 Thomas Larsen [email protected]:
Once way I could conceive of correcting the problem is to have a reference tag that provides only a _link_ to the note via a label and another type of reference tag that actually _defines_ and _displays_ the note. For example:
A popular approach just now (and one I'm trying to convert to using) is:
It was a sunny day on Wednesday<ref>Smith, p.9</ref>. The next day, Thursday, was cloudy.<ref>Jones, p.40</ref>
==Notes==
<references/>
==References==
* David Smith. ''History of Wednesdays.'' History Magazine, 2019 * Susan Jones. ''History of Thursdays.'' History Magazine, 2020
This mostly implements what you're trying to do (ie, as little stuff in the body text as possible) and can be done without major change :-). It looks a little silly when you've only got three references, but works very well for thirty.
On Thu, Dec 4, 2008 at 1:32 PM, Andrew Gray [email protected] wrote:
2008/12/4 Thomas Larsen [email protected]:
Once way I could conceive of correcting the problem is to have a reference tag that provides only a _link_ to the note via a label and another type of reference tag that actually _defines_ and _displays_ the note. For example:
A popular approach just now (and one I'm trying to convert to using) is:
It was a sunny day on Wednesday<ref>Smith, p.9</ref>. The next day, Thursday, was cloudy.<ref>Jones, p.40</ref>
==Notes==
<references/>
==References==
- David Smith. ''History of Wednesdays.'' History Magazine, 2019
- Susan Jones. ''History of Thursdays.'' History Magazine, 2020
This mostly implements what you're trying to do (ie, as little stuff in the body text as possible) and can be done without major change :-). It looks a little silly when you've only got three references, but works very well for thirty.
A popular approach? No offense, but isn't this just the way it should have been done all along? It is certainly the way many journals and books do it, and it is common sense. There is also a way to set things up so that a second click from the specific reference (Smith, p7) will take you to the full source details in the bibliographic list of references - handy if there are lots of them and they are split up in various ways. But I can't remember an example right now. The best way to find out how referencing systems work in practice is to go to the featured articles page and click on one or two and just see how its been done before.
For example:
http://en.wikipedia.org/wiki/El_Lissitzky
http://en.wikipedia.org/wiki/Introduction_to_evolution http://en.wikipedia.org/wiki/Introduction_to_evolution#cite_note-34 http://en.wikipedia.org/wiki/Introduction_to_evolution#CITEREFCarrollGrenier...
The #CITEREF anchor is produced by and explained at the Citation template page:
http://en.wikipedia.org/wiki/Template:Citation
Plus lots of other stuff if you read around from there to other places.
In my view, the real problem with references is people coming along later and changing or moving the text, without reading the source. That can eventually lead to completely misleading statements disconnected from the original source. Adding references can stablise or ossify a piece of text, but when that piece of text goes back into flux, the sources often need to be redone or re-examined.
Carcharoth
2008/12/4 Carcharoth [email protected]:
A popular approach? No offense, but isn't this just the way it should have been done all along? It is certainly the way many journals and books do it, and it is common sense.
Yes, yes it is. :-)
In practice - as far as I've seen it - most referencing puts the refs directly into the text and then invokes them with <ref name="foo"/> every time they're later used, the practice originally objected to; this has a whole host of unfortunate side-effects, including the mess of backlinks at the bottom when a single reference is called twenty times, and the fact that it discourages specific citation by page number.
When I say the notes-then-refs is "popular", what I mean is that I seem to be seeing it more and more recently... anecdotally, I'd say it's becoming more common to do this from the start rather than when "formalising" the article for FA status. I've no idea how easily we can quantify this guess, though.
(One day, I really need to go through all the articles I've written and sort out their references...)
On Fri, Dec 5, 2008 at 2:41 AM, Andrew Gray [email protected] wrote: ...
and the fact that it discourages specific citation by page number.
It shouldn't:
https://bugzilla.wikimedia.org/show_bug.cgi?id=13127
The patch there has gone unreviewed since February so it may no longer be viable, but another (and probably a better) one could easily be written.
On Thursday 04 December 2008, Carcharoth wrote:
A popular approach? No offense, but isn't this just the way it should have been done all along? It is certainly the way many journals and books do it, and it is common sense.
By which standard? Short notes with bibliography is not that common from my experience and little covered in Chicago.
http://en.wikipedia.org/wiki/El_Lissitzky
This is a good example of the form, though the non-hypertextual short note is certainly inconvenient.
http://en.wikipedia.org/wiki/Introduction_to_evolution
This is a Frankenstein. A mixture of two styles: long notes and short notes + bibliography. I've never seen this in print and is poor practice.
On Thu, Dec 4, 2008 at 1:46 AM, Thomas Larsen [email protected]wrote:
Hi all,
The current <ref>...</ref>...<references/> system produces nice references, but it is flawed--all the text contained in a given reference appears in the text that the reference is linked from. For example:
It was a sunny day on Wednesday<ref>David Smith. ''History of Wednesdays.'' History Magazine, 2019.</ref>. The next day, Thursday, was cloudy.
== References and notes ==
<references/>
(That's a very simple example, too. References start to become a lot larger once they start to include other information and/or are produced via a template.)
Once way I could conceive of correcting the problem is to have a reference tag that provides only a _link_ to the note via a label and another type of reference tag that actually _defines_ and _displays_ the note. For example:
It was a sunny day on Wednesday<ref id="smith"/>. The next day, Thursday, was cloudy.
== References and notes ==
<reference id="smith">David Smith. ''History of Wednesdays.'' History Magazine, 2019.</reference>
This makes the raw wikitext easier to read, since the text of the actual reference is in the _references_ section instead of in the page's primary content.
I think this could work ...
--Thomas Larsen
I think stuff like this should be discussed on a village pump, not a mailing list.
Al Tally wrote:
On Thu, Dec 4, 2008 at 1:46 AM, Thomas Larsen wrote
Hi all,
The current <ref>...</ref>...<references/> system produces nice references, but it is flawed--all the text contained in a given reference appears in the text that the reference is linked from. For example:
...
I think stuff like this should be discussed on a village pump, not a mailing list.
Why not both?
Ec
On Wed, Dec 3, 2008 at 8:46 PM, Thomas Larsen [email protected] wrote:
Hi all,
The current <ref>...</ref>...<references/> system produces nice references, but it is flawed--all the text contained in a given reference appears in the text that the reference is linked from. For example:
[snip]
Once way I could conceive of correcting the problem is to have a reference tag that provides only a _link_ to the note via a label and another type of reference tag that actually _defines_ and _displays_ the note. For example:
[snip]
Thats a lot like what we used to do, the problem is that references were *constantly* orphaned, scrambled, etc. The references were often nonsense.
My view is that the current behavior is bad mostly because it makes it very hard to read the text in edit, you get this wall of meaningless markup.
Instead I propose: Have javascript mediate the edit box so that inline references are converted to little red [R] text, moving your cursor into the [R] area by clicking or arrowkeying causes it to expand to display the full reference. You can add references by simply typing them like normal and then they'll collapse when you navigate away, or you can press some "insert reference" button that pops up a dialog that asks for the relevant information which then types the completed reference for you.
This type of hiding could also be applied to other common inline markup and dramatically improve usability.
This type of edit box mediation has been done by other edit-helper userscripts, so it's certainly possible.
Thoughts?
2008/12/4 Gregory Maxwell [email protected]:
This type of edit box mediation has been done by other edit-helper userscripts, so it's certainly possible.
Thoughts?
While there are some theoretical risks (people making text changes without taking all the markup into account) I don't believe they would present a major problem. Colour choice may be an issue with the current red/green colorblindness prevalence. I'm also not sure how a screen reader would view it but that can be dealt with.
Your other problem is the potential amount of javascript required and the effect that will have on older computers.
2008/12/4 Gregory Maxwell [email protected]:
Instead I propose: Have javascript mediate the edit box so that inline references are converted to little red [R] text, moving your cursor into the [R] area by clicking or arrowkeying causes it to expand to display the full reference. You can add references by simply typing them like normal and then they'll collapse when you navigate away, or you can press some "insert reference" button that pops up a dialog that asks for the relevant information which then types the completed reference for you.
That's definitely the direction we're thinking in for the Stanton usability project (same basic principle can be applied to templates). If someone wants to create a prototype or mockup already, it would be more than welcome.
On Thu, Dec 4, 2008 at 12:15 PM, Gregory Maxwell [email protected] wrote:
On Wed, Dec 3, 2008 at 8:46 PM, Thomas Larsen [email protected] wrote:
Hi all,
The current <ref>...</ref>...<references/> system produces nice references, but it is flawed--all the text contained in a given reference appears in the text that the reference is linked from. For example:
[snip]
Once way I could conceive of correcting the problem is to have a reference tag that provides only a _link_ to the note via a label and another type of reference tag that actually _defines_ and _displays_ the note. For example:
[snip]
Thats a lot like what we used to do, the problem is that references were *constantly* orphaned, scrambled, etc. The references were often nonsense.
My view is that the current behavior is bad mostly because it makes it very hard to read the text in edit, you get this wall of meaningless markup.
Instead I propose: Have javascript mediate the edit box so that inline references are converted to little red [R] text, moving your cursor into the [R] area by clicking or arrowkeying causes it to expand to display the full reference. You can add references by simply typing them like normal and then they'll collapse when you navigate away, or you can press some "insert reference" button that pops up a dialog that asks for the relevant information which then types the completed reference for you.
This type of hiding could also be applied to other common inline markup and dramatically improve usability.
This type of edit box mediation has been done by other edit-helper userscripts, so it's certainly possible.
Thoughts?
Though it would be nice to also be able to see the whole raw wikitext if one wanted to, I like this idea a lot. I've had a great deal of trouble teaching people how to insert references in Wikipedia, but many internet users are perfectly familiar with the kinds of "click here to upload photos/insert text" boxes that are now becoming ubiquitous. If it was really a "put in your information and the reference is formatted for you" box, that would help both with ensuring that references are more complete and formatted correctly, and that fewer mistakes were made with syntax (the closing / is what always gets me). I'd say such a box should include two options: enter the information for formatting, or use a simple box to accept wikitext (for out of the ordinary or preformatted citations).
I'd put in a vote for applying the same thing to infoboxes, too! And then maybe an option for experienced users: turn off javascript and see the whole <s>mess as it is now</s> wikitext.
-- phoebe
On Thu, Dec 4, 2008 at 5:24 PM, phoebe ayers [email protected] wrote: [snip]
I'd put in a vote for applying the same thing to infoboxes, too! And then maybe an option for experienced users: turn off javascript and see the whole <s>mess as it is now</s> wikitext.
Or "reveal codes" button, a pretty obvious feature.
It took me a bit to remember the name, but check this out: http://en.wikipedia.org/wiki/User:Cacycle/wikEd
I used it for a while but felt that it was too heavy handed: All I really wanted was hiding and syntax highlighting, and I think at the time it didn't do the hiding, and the emacs mode for wikitext did a better highlighting job (plus flyspell).
On Thu, Dec 4, 2008 at 2:31 PM, Gregory Maxwell [email protected] wrote:
On Thu, Dec 4, 2008 at 5:24 PM, phoebe ayers [email protected] wrote: [snip]
I'd put in a vote for applying the same thing to infoboxes, too! And then maybe an option for experienced users: turn off javascript and see the whole <s>mess as it is now</s> wikitext.
Or "reveal codes" button, a pretty obvious feature.
It took me a bit to remember the name, but check this out: http://en.wikipedia.org/wiki/User:Cacycle/wikEd
I used it for a while but felt that it was too heavy handed: All I really wanted was hiding and syntax highlighting, and I think at the time it didn't do the hiding, and the emacs mode for wikitext did a better highlighting job (plus flyspell).
Right! It looks like it has gotten better than it was? It's enabled under "gadgets" now, at any rate, which makes it a lot easier to use/install. I turned it on just now and it looks like it could be useful for a new editor.
-- phoebe
On Thu, Dec 4, 2008 at 10:24 PM, phoebe ayers [email protected] wrote:
[Making markup less forbidding]
I'd put in a vote for applying the same thing to infoboxes, too! And then maybe an option for experienced users: turn off javascript and see the whole <s>mess as it is now</s> wikitext.
Not just infoboxes, but tables in general.
I'm slowly learning how to use tables, but it is very hard to write complex ones from scratch, even if you copy another one. I've had to resort to using Excel to update the table and then insert the wikimarkup around the data.
And when pressed for time with refs, just dumping a hastily formatted external link and brief description and date in some ref tags is the most I think people can cope with until they are organised enough to have some wikicode stored in their userspace to copy and paste from (or from various template documentations). The hope is always that someone else will come along and improve any poorly formatted references that you add.
The thing that all the more complex wiki-markup things have in common is (until you get proficient in their use, and sometimes not even then) is how time-consuming it is when compared to basic text editing. In some ways this is due to the results being complex - doing fiddly layout stuff will invariably take time because it is fiddly.
But there is no excuse for people coming along and wanting to improve existing articles to be put off by an unreadable wall of text mixed up with complex "ref" tags and "citation" template code. When correcting a spelling mistake, or wanting to reword one sentence, requires careful searching within the edit box, or several attempts to find the sentence in question in the edit box, then something has gone very wrong. It also means that reading the flow of an article is best done in "preview", but that's not a bad thing, actually, as people should be encouraged to use preview more. But I dread how many potentially new editors have clicked "edit this page" and given up if faced with a mess they don't understand head-or-tail of.
Carcharoth
Well, AFAIK we all agree that metadata like categories and interwiki links don't really belong into wikitext. Maybe we could find a general solution that also encompasses references (that is, the contents, not the position information within the wikitext). We could move these things into a separate table:
page_id INTEGER | data_type SHORTINT | text MEDIUMBLOB
The interface would then know how to present each data type: * categories as name and (optional) sortkey * interwiki links as target wiki and title * references as reference ID and text
All of these could be hidden by default and only open on request. For reference text, we would need a textarea, but the rest we could do with text input fields.
This would also be open for extension. E.g., we could think about moving header/footer templates into this schema. And how about the DEFAULTSORT key?
Just thinking aloud here.
Magnus
On Fri, Dec 5, 2008 at 9:08 AM, Carcharoth [email protected] wrote:
On Thu, Dec 4, 2008 at 10:24 PM, phoebe ayers [email protected] wrote:
[Making markup less forbidding]
I'd put in a vote for applying the same thing to infoboxes, too! And then maybe an option for experienced users: turn off javascript and see the whole <s>mess as it is now</s> wikitext.
Not just infoboxes, but tables in general.
I'm slowly learning how to use tables, but it is very hard to write complex ones from scratch, even if you copy another one. I've had to resort to using Excel to update the table and then insert the wikimarkup around the data.
And when pressed for time with refs, just dumping a hastily formatted external link and brief description and date in some ref tags is the most I think people can cope with until they are organised enough to have some wikicode stored in their userspace to copy and paste from (or from various template documentations). The hope is always that someone else will come along and improve any poorly formatted references that you add.
The thing that all the more complex wiki-markup things have in common is (until you get proficient in their use, and sometimes not even then) is how time-consuming it is when compared to basic text editing. In some ways this is due to the results being complex - doing fiddly layout stuff will invariably take time because it is fiddly.
But there is no excuse for people coming along and wanting to improve existing articles to be put off by an unreadable wall of text mixed up with complex "ref" tags and "citation" template code. When correcting a spelling mistake, or wanting to reword one sentence, requires careful searching within the edit box, or several attempts to find the sentence in question in the edit box, then something has gone very wrong. It also means that reading the flow of an article is best done in "preview", but that's not a bad thing, actually, as people should be encouraged to use preview more. But I dread how many potentially new editors have clicked "edit this page" and given up if faced with a mess they don't understand head-or-tail of.
Carcharoth
WikiEN-l mailing list [email protected] To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
On Fri, Dec 5, 2008 at 7:03 AM, Magnus Manske [email protected]wrote:
Well, AFAIK we all agree that metadata like categories and interwiki links don't really belong into wikitext. Maybe we could find a general solution that also encompasses references (that is, the contents, not the position information within the wikitext). We could move these things into a separate table:
Or just shove them all to the bottom, automatically upon hitting submit. So if you type in "blah blah <ref>http://whatever/</ref> blah" it automatically gets reformatted to "blah blah <ref id=2938 /> blah" and puts "<ref id=2938> http://whatever/</ref>" at the bottom.
Use globally unique IDs, and you can even handle automagic cut/paste copying from article to article.
2008/12/5 Carcharoth [email protected]:
Not just infoboxes, but tables in general. I'm slowly learning how to use tables, but it is very hard to write complex ones from scratch, even if you copy another one. I've had to resort to using Excel to update the table and then insert the wikimarkup around the data.
A bit of Javascript for a table editor would be just the thing for FCKEditor (which is the least-unpromising WYSIWYG wikitext editor so far).
(All noting, of course, http://en.wikipedia.org/wiki/SMOP ;-) )
- d.
Hi,
On 12/5/08, Gregory Maxwell [email protected] wrote: [snip]
Thats a lot like what we used to do, the problem is that references were *constantly* orphaned, scrambled, etc. The references were often nonsense.
[/snip]
That's probably one flaw with the system I propose. Nevertheless, as one might ask rhetorically: how many people _avoid_ inserting references altogether because they can't be bothered coping with the messy text flow? and how many people avoid editing a page, because the first few lines consist of nothing except reference text? I'd say the number is quite larger. Perhaps it's worth the cost of having a few orphaned refs to set up an easier-to-use system. (Of course, we could always have Special:OrphanedRefs :-).)
[snip]
Instead I propose: Have javascript mediate the edit box so that inline references are converted to little red [R] text, moving your cursor into the [R] area by clicking or arrowkeying causes it to expand to display the full reference. You can add references by simply typing them like normal and then they'll collapse when you navigate away, or you can press some "insert reference" button that pops up a dialog that asks for the relevant information which then types the completed reference for you.
[/snip]
This is a viable idea. The issue is, though, that not everybody has Javascript enabled in their web browsers. I feel that Wikipedia is JS-dependent enough as it is ... but then, I suppose, most people _do_ use JS.
Thanks everybody for your thoughts.
--Thomas Larsen
2008/12/4 Thomas Larsen [email protected]:
Perhaps it's worth the cost of having a few orphaned refs to set up an easier-to-use system. (Of course, we could always have Special:OrphanedRefs :-).)
It's not a few it tends to be rather a lot. Trying to keep two different sections of wikicode in sync is a fairly significant effort.
On Thu, Dec 4, 2008 at 3:22 PM, geni [email protected] wrote:
2008/12/4 Thomas Larsen [email protected]:
Perhaps it's worth the cost of having a few orphaned refs to set up an easier-to-use system. (Of course, we could always have Special:OrphanedRefs :-).)
It's not a few it tends to be rather a lot. Trying to keep two different sections of wikicode in sync is a fairly significant effort.
The problem with the prior methods of doing references was that they associated references with footnote numbers only by order of use in the text, which meant that any moving things around broke the system. A system which used named reference IDs in some form would be more robust.
-Matt
Hi,
On 12/5/08, Matthew Brown [email protected] wrote: [snip]
The problem with the prior methods of doing references was that they associated references with footnote numbers only by order of use in the text, which meant that any moving things around broke the system. A system which used named reference IDs in some form would be more robust.
[/snip]
I'm assuming that you mean that the old form of references used a syntax similar to {{note|1}}--I think I joined Wikipedia when the old reference form was phasing out (October 2006), although I've never really been _heavily_ involved in writing articles. If that's the case, then my syntax would correct this problem that you, Matthew, mention: instead of being identified only by a number, references would be identified by a unique textual ID.
Cheers,
--Thomas Larsen
On Fri, Dec 5, 2008 at 2:53 PM, Thomas Larsen [email protected] wrote:
I'm assuming that you mean that the old form of references used a syntax similar to {{note|1}}--I think I joined Wikipedia when the old reference form was phasing out (October 2006), although I've never really been _heavily_ involved in writing articles. If that's the case, then my syntax would correct this problem that you, Matthew, mention: instead of being identified only by a number, references would be identified by a unique textual ID.
That's the one.
-Matthew
On Wed, Dec 3, 2008 at 9:46 PM, Thomas Larsen[email protected] wrote:
Hi all,
The current <ref>...</ref>...<references/> system produces nice references, but it is flawed--all the text contained in a given reference appears in the text that the reference is linked from. For example:
It was a sunny day on Wednesday<ref>David Smith. ''History of Wednesdays.'' History Magazine, 2019.</ref>. The next day, Thursday, was cloudy.
== References and notes ==
<references/>
(That's a very simple example, too. References start to become a lot larger once they start to include other information and/or are produced via a template.)
Once way I could conceive of correcting the problem is to have a reference tag that provides only a _link_ to the note via a label and another type of reference tag that actually _defines_ and _displays_ the note. For example:
It was a sunny day on Wednesday<ref id="smith"/>. The next day, Thursday, was cloudy.
== References and notes ==
<reference id="smith">David Smith. ''History of Wednesdays.'' History Magazine, 2019.</reference>
This makes the raw wikitext easier to read, since the text of the actual reference is in the _references_ section instead of in the page's primary content.
I think this could work ...
--Thomas Larsen
If I may make a suggestion? That syntax is kind of clunky - maybe we could have a simpler syntax, something like '{{ref|foo}}' & '{{note|foo}: text'...
Gwern Branwen[email protected] wrote:
On Wed, Dec 3, 2008 at 9:46 PM, Thomas Larsen[email protected] wrote:
If I may make a suggestion? That syntax is kind of clunky - maybe we could have a simpler syntax, something like '{{ref|foo}}' & '{{note|foo}: text'...
Reviving a year-old thread? Hm. Related note: Bodnotbod dropped us a link:
http://strategy.wikimedia.org/wiki/Proposal:Move_references_out_of_the_code
-Stevertigo
On Fri, Sep 4, 2009 at 3:54 AM, stevertigo[email protected] wrote:
Gwern Branwen[email protected] wrote:
On Wed, Dec 3, 2008 at 9:46 PM, Thomas Larsen[email protected] wrote:
If I may make a suggestion? That syntax is kind of clunky - maybe we could have a simpler syntax, something like '{{ref|foo}}' & '{{note|foo}: text'...
Reviving a year-old thread? Hm. Related note: Bodnotbod dropped us a link:
http://strategy.wikimedia.org/wiki/Proposal:Move_references_out_of_the_code
-Stevertigo
That was actually the thread that reminded me; but I couldn't resist the chance to point out the irony of how recent referencing discontents have come full circle from the {{ref}} days.
It took about 3 years to put in place references ('01 to '04/'05), another 3 switch from {{ref}} to <ref> and grow weary of it ('05 to now), so I suppose in 2014 or 2015, people will be complaining about how opaque references in a different section are, how hard to keep in sync with the article text, and how in programming we put the docs right with the functions/methods and why-can't-we-do-that?, and suggest switching to this new referencing system...
Gwern Branwen[email protected] wrote:
That was actually the thread that reminded me; but I couldn't resist the chance to point out the irony of how recent referencing discontents have come full circle from the {{ref}} days.
Ah. Unusually enough, it also appears to have been a thread that stayed on topic for most of its duration. (I read click on too many interestingly-named threads with quite unrelated or uninteresting comment).
It took about 3 years to put in place references ('01 to '04/'05), another 3 switch from {{ref}} to <ref> and grow weary of it ('05 to now), so I suppose in 2014 or 2015, people will be complaining about how opaque references in a different section are, how hard to keep in sync with the article text, and how in programming we put the docs right with the functions/methods and why-can't-we-do-that?, and suggest switching to this new referencing system...
Yes, things on teh Interweb develop v e r y s l o w l y.
-Stevertigo PS: http://strategy.wikimedia.org/wiki/Proposal:Move_references_out_of_the_code