Jump to content

WMDE Technical Wishes/Sub-referencing/Call for feedback (May 2018)

Add links
From Meta, a Wikimedia project coordination wiki

Welcome to this feedback round and thanks for taking the time to participate! Your input helps the Technical Wishes team find a good solution.

Background

[edit]

Currently, when I reference different parts of the same work in an article, I have to repeat all the information about this work in each reference. This is cumbersome, lengthens the wiki text, clutters the references section by repeated appearances of the same source, and it also obscures if many references actually come from the same work. The wish to solve this problem has existed in the community for more than 10 years now and was voted a top wish in the Technical Wishes surveys 2013 and 2015 and on #24 in the international Community Wishlist survey 2015.

After research on how references are being used, Wikimedia Germany’s Technical Wishes team conceptualized a possible solution and presented it to the German-speaking community and to an international audience. Still in the research phase, we want to find out if the suggested solution works for the different language projects. That's why we're inviting editors from all wikis to have a look at the proposed solution below and tell us what they think. More background info can be found on the page of the wish.

The feedback round is now closed. It was open from May 14th to June 10th.

The suggested solution

[edit]

The solution aims to reduce duplicate content both on the input side and on the output side:

Output: What would it look like on the rendered page?

[edit]
A mockup of what a rendered page could look like with book referencing
  • Refinements are shown as indentations below the main reference and get their own subordinate reference number. So e.g. when the work called "Pierson" is reference number 1, the refinement "p. 123-163" could be shown as 1.1.
    • The format 1.1, 1.2 is only one example of how this could look. We expect that each wiki will be able to decide individually how to format their refinements, like they already can with multiple uses of the same footnote.
    • There will be only one degree of indentation, meaning that e.g. 1.1.1. won’t exist because adding more degrees would cause a lot of complexity and create many edge cases.
  • The proposed solution doesn’t restrict how references are being refined. It can be used for page numbers just as well as verses, chapters etc.
  • This solution works independent of language, script and writing direction.

Input: What does this mean for referencing with …

[edit]

… wikitext / <ref> tags

[edit]
A mockup of how this solution could work in wikitext. Please note that yellow highlights are only here for demonstration, they are not part of the technical implementation.

If you’re using wikitext for references, the solution would look like this: You’re defining the work that is referenced multiple times once with a name attribute, e. g. name=Pierson. Then, each time a part of this work is referenced, you use the new attribute, refines*. So for example, <ref refines="Pierson">p. 123-163 </ref> would add the refinement “p. 123-163” in the references section under the reference with the name “Pierson”. In the screenshot, the main reference is defined in the reference section. The final version of the feature will also allow to define the main reference within the wikitext body without creating an unused jump mark. It’s on our to do list to come up with a syntax for it.

* The name of this attribute is still under discussion.

… templates

[edit]

You will be able to continue using the same templates. The suggested change would make it possible for template maintainers to adapt their template to the new format, which would allow a styling as described above. For template users nothing would change.

… the Visual Editor

[edit]
A first mock of what book referencing could look like in the Visual Editor

If you’re using the Visual Editor, you will be able to use the new model as well. For example, it could look like shown in this mock.

You don’t have to change your working mode, but you can.

[edit]

The suggested solution doesn’t force anyone to change their working mode. All previous methods for referencing are still possible without restriction.

Feedback

[edit]
  • Request: this a very significant topic. And as some of us only heard about this yesterday I ask that the comment period be exteneded one week for a better considered response. J. Johnson (talk) 01:06, 3 June 2018 (UTC)[reply]
Notes
  • Please elaborate your assessment in a few sentences, if possible.
  • Screenshots are always welcome.
  • If you have any remarks about this feedback round itself, please let us know on the talk page.
  • Don't forget to sign your comment. ~~~~

Would the proposed solution help you in your daily work?

[edit]

Description edited on 14:36, 15 May 2018 (UTC) Please indicate whether Support Support It would help you, Neutral Neutral You don’t know or Oppose Oppose It would disturb you, and elaborate a bit why. Also, please describe how you currently add references (via wikitext, templates or Visual Editor).

Oppose Oppose I would not use this. All of these features are already available in the existing sfn-style referencing system(s). That style is also more compact, and (this is IMHO) much easier to edit because the refs are all in one place, at the bottom where they should be. I rarely use the ref-style system any more. Maury Markowitz (talk) 18:24, 14 May 2018 (UTC)[reply]

  • I like it.
OT: What I would like to see is that references should not be so "visible", they should be more displayed when the user click on the footnote like [2] then a popup is shown. What we see in Sweden when 100 millions of documents are released from the Swedish National Archives is if we starts to do our homework and add primary sources to facts in Wikidata like birth death etc.. then we have a template that takes those references to Wikipedia ==> the note section gets way to big ==> 50% of an article is the note section. As some people has stated that references are the super power of Free Open Knowledge they should always be there but you don't need to use 50% of an article displaying them eg. — The preceding unsigned comment was added by Salgo60 (talk) 08:39, 15 May 2018 (UTC)[reply]
  • Some questions:
Could other location descriptions than page numbers be used, such as sections, chapters, etc?
How does one keep the citation style consistent within an article when different editors are using the feature? Would one have to go around fixing variations by hand? · · · Peter (Southwood) (talk): 15:36, 15 May 2018 (UTC)[reply]
  • Hi Peter, as for other location descriptions: Yes. The solution doesn’t restrict how references are being refined, be it pages, chapters, verses, sections, …. And concerning your question about keeping the citation style consistent: This problem is independent of the proposed solution, it already exists today.
    So would you say the proposed solution would be helpful for you? -- Best, Johanna Strodt (WMDE) (talk) 16:06, 15 May 2018 (UTC)[reply]
  • This is a solution in search of a problem. Such cases are already easily handled. Define the reference once as a named reference, while not including page or other location. Reuse it as often as needed. After each ref tag, use {{rp}} to indicate the page number(s) or other location. There is no need for new software development to handle this use case. DESiegel (talk) 00:10, 17 May 2018 (UTC)[reply]
Agree with Anomie: {{rp}} is definitely crappy. Putting page numbers after the note link number (e.g.: [11]87) is entirely upside-down. It's a Wikipedia peculiarity that tends to baffle the reader ("why are some of the note numbers not in brackets?"), specifying a detail of the source before the source is identified. In-source specifiers – page numbers, etc. – should be inferior (subordinate: below the level of) the full citation, not superior to it.
This usage actually implies that the note – the numbered element created with the <ref> tag – has a subordinate part. Which is essentially what this proposed feature does: Give notes an internal structure, with the intention of using "note + subnote" in parallel to "citation + in-source specifier". It would be immensely better to consider why some editors can't use "citaton + page number" directly. For that, please see #Proposed feature is the wrong solution, below.
I disagree with Jytdog that "rp works fine", but agree that we shouldn't proliferate citation styles. Especially one that is an overelaboration of a crappy "style". J. Johnson (talk) 20:43, 4 June 2018 (UTC)[reply]
User:J. Johnson I am glad you agree on not profilerating but I don't understand the "upside down" thing. You need the book before the page number in it... so you lost me. Jytdog (talk) 14:43, 6 June 2018 (UTC)[reply]
That's exactly what I mean: you need the book before the page number in it. That is, identifying the book should be superior to – come before – the page number. The way {rp} displays, the reader gets this number (not even identified as a page number) at the level of the note-number (e.g.: [11]87), before seeing what the book (source) is. Page number first is inverted from good usage. J. Johnson (talk) 22:59, 6 June 2018 (UTC)[reply]
I see what you are saying, kind of. But if you look at the two superscripts in order, the book is first and then the page. it is not reasonable to say that the page number somehow precedes the book. I have no wish to debate this, as it is silly. Jytdog (talk) 22:57, 9 June 2018 (UTC)[reply]
@Jytdog: I would hope to persuade you it is not at all silly, but a key element of why both the practice and discussion of citation is so difficult. To explain: what the superscripted-bracketed-number links to is not a "book" (which I take as an instance of the more general "source"), but a note (a.k.a. footnote, end-note). A note – created with the <ref>...</ref> tags – is a sort of container. Which may contain a full citation to a source (book). Or a short-cite, or commentary on the text or source, or multiple citations, or any combination thereof. There are systems of citation where each source is numbered (or given an alphanumeric identifier), where you could do an in-line citation like "(11:87)". However, this is not the same as the {rp} look-alike "[11]87" because our note-link numbering is of the notes, not the sources. It's the difference between the 11th source on some list, and the 11th note in the article. Which might contain a citation (full or short) to a source, but that is the next level down. I understand there are editors that seem to think "citations" can be done only within <ref> tags, but there are plenty of disproofs of that. It is that specific belief – of conflating "notes" as "references" – that is the logjam that creates this supposed problem of "reusing references". J. Johnson (talk) 20:35, 10 June 2018 (UTC)[reply]
  • Per User:Maury Markowitz above this does not add anything that the existing {{sfn}} referencing style gives and indeed introduces more confusion by bringing in a subsidiary numbering system. On en-wp where ref-style referencing is in a minority I would oppose it's introduction as being counter-productive. Nthep (talk) 14:03, 17 May 2018 (UTC)[reply]
    • "On en-wp where ref-style referencing is in a minority" [citation needed] And personally I'd find it more convenient as a reader for the sfn-like text to be adjacent to the full reference to the book rather than having to link to a separate section for it. Anomie (talk) 11:55, 18 May 2018 (UTC)[reply]
      • OK personal assessment but I come across very few articles with ref-style, most use inline citations or an sfn system. This proposal is edging back to ibid. Nthep (talk) 14:29, 18 May 2018 (UTC)[reply]

Support Support It would absolutely be beneficial, and greatly reduce the need for the god-awful / unintuitive / noob-unfriendly en:Template:sfb/en:Template:rp and en:template:Harv/en:template:Harvnb and similar. I would love, love, LOVE this. Headbomb (talk) 11:21, 18 May 2018 (UTC)[reply]

Neutral Neutral When I write or overhaul a complex article, I prefer to use short footnotes or parenthetical referencing. I often create all the citations in Zotero and copy them to the article, but that requires touch-ups to the Zotero-generated citation templates. Better Zotero integration would be more valuable to me than this work. Jc3s5h (talk) 13:13, 18 May 2018 (UTC)[reply]

Support Support I regularly use the {{rp}} format. I find that the inline form of the result, especially when referencing multi-millenarian technical manuals, is ugly and unwieldy. I like the proposed solution, grouping references to the same work, but by page. The [x.y] format also fits with our citation style, I feel. A suggestion, can the multiple references be expandable/collapsible? I feel like that will prevent highly used sources from creating clutter, especially on larger pages. Bellezzasolo (talk) 05:48, 21 May 2018 (UTC)[reply]

I note that some wikis discourage collapsible sections in articles, for example enwiki's en:MOS:DONTHIDE. I'd recommend the Cite extension simply add an appropriate class to the subreference HTML elements (i.e. the <ol> tag) to allow an on-wiki Gadget to collapse them if someone wants that. Anomie (talk) 14:55, 22 May 2018 (UTC)[reply]

Support Support I always found {{sfn}} notation clumsy for readers, since it breaks the ability to find the full citation by hovering over the citation in the text. If the mouseover text for this method includes both the full citation and the page number, it would be a major boon for readability. --Ahecht (TALK
PAGE) 15:53, 21 May 2018 (UTC)[reply]

Ahecht, this seems to be a different request... you seem to want changes to the tooltips on the anchors, which seems easily achieved with no changes to anything other than the tooltips on the anchors. Maury Markowitz (talk) 18:42, 28 May 2018 (UTC)[reply]

I like the idea, but there are a few things that I think should be considered:

  • the {{Rp}} template, which is currently being used to specify the page in some articles. The problem with it is that since it references the reference just before it, it cannot be easily converted to the proposed solution
  • the reference list and numbering look weird. Some wiki might want to use a different layout, such as the current one with full citations every time, and the software should provide this option. Strainu (talk) 17:55, 21 May 2018 (UTC)[reply]
If someone wants to use "the current one with full citations every time", they can continue to do so by simply ignoring the new feature. If a whole community wants to ignore the feature, they can write it into their policy just as they write other citation-style issues into their policy.

As for {{rp}}, chances are a bot could be run to replace it. Discussions about that would likely be better done on the specific wikis using the template once the new feature is available. Anomie (talk) 14:55, 22 May 2018 (UTC)[reply]

Oppose Oppose complete waste of resources. en:Template:sfn does this easier, nicer, cleaner, and better and already exists (and no tech people, your responses below don’t address any of this because they don’t actually focus on the purpose of referencing, which is making an article that people can easily read and verify information). This would also introduce even more confusion into our 1000 different ways to reference things, and would make it more difficult for people to figure out how to reference quality articles (I was confused as heck when I first started with all the different options.) Complete waste of time that only exists to make techies happy about making a new way to reference and won’t actually help build content. TonyBallioni (talk) 22:38, 21 May 2018 (UTC)[reply]

Support Support This looks promising. Repetitive variants of a ref can be ugly (both for editors and readers), and the available options for handling it seem less than ideal. I'm not enthusiastic about the "refines" word, the first alternative that popped into my mind was "subref". The syntax needs work. The example syntax appears incompatible with defining a named-ref and the refined-location at the same time. There should be a simple and obvious consistency in syntax between the named-ref-definition case and the named-ref-reuse case. Would the parser be happy with something like below?

  • <ref name=foo>BarBook<subref>Page 123</ref>

If that works, reusing a named ref might look like one of these two options:

  • <subref name=foo>Page 456</ref>
  • <ref name=foo><subref>Page 456</ref> (Slightly more consistent, but longer and less nice. The empty ref-definition implies reuse.)

Note: This may already be obvious, but don't overlook that refined and unrefined versions of a named ref may coexist. Your screenshots don't appear to show that case. Any unrefined versions of the named ref should probably attach to the first ref line in your examples (the base definition of the ref). Any refined versions appear below the base ref definition, same as the examples. Alsee (talk) 01:12, 22 May 2018 (UTC)[reply]

The only real issue, as far as I can tell, is the need for defining the "unrefined" reference when all uses in the article are to refined versions. It seems the initial plan is to do this using the ability to define named references inside the <references> tag, as described at mw:Extension:Cite#Separating references from text. There's also mention of later creating a syntax to do this in the main text of a page (which, personally, I don't see a need for except to handle cases where a template wants to define a refined reference).

I find the suggested syntax pretty clear: the name parameter always names a reference, whether it's the unrefined or refined version. The refines (or whatever) parameter references another reference's name in order to indicate that the current <ref> is creating a refined reference. I personally find your <subref> suggestion more confusing, both because that tag isn't balanced in your examples and because it changes the behavior of the enclosing <ref> if it happens to contain a <subref>. Anomie (talk) 14:55, 22 May 2018 (UTC)[reply]

Oppose Oppose, I like en:Template:Rp style. The current proposed style, if cite too much, will be too long--Shizhao (talk) 02:26, 22 May 2018 (UTC)[reply]

Support Support. Current templates that manage this part of Wikipedia code are nasty hacks and ugly workarounds and should be deprecated in favour of one machine-readable syntax. Editors that ‘prefer’ these templates just don’t see how bad their support level is for newcomers and non-tech-savvy users. stjn[ru] 13:26, 22 May 2018 (UTC)[reply]

Support Support. This is a much needed improvement. Speaking from the perspective of an en-wp user who almost exclusively uses {{sfn}}, I can say that the proposal is definitely not redundant to that template. Sfn is a wonderful tool, but it requires the sources themselves to be formatted using templates and its whole machinery is workable only if you've learned the ropes of wikipedia and you use a compatible reference manage software. The majority of editors don't go that far (sfn is used on less than 1.3% of all articles), so there is a need for a simple device within the basic system of <ref> tags. What we have at the moment – {{rp}} – is a bit inelegant, and it gets in the way of usability: if a user clicks on one of the ref numbers, they'll be taken to a footnote with several back-links to the text (see example) and there's no way to know which is the one they need (and it's not immediately obvious that they can use their browser's back button). Uanfala (talk) 13:22, 25 May 2018 (UTC)[reply]

Support Support I'm very much in favor. My only qualm is that I often use the url= parameter of {{Cite book}} to provide the URL for a pinpoint cite to the page, and this will force the external link to be written in the clumsier form of <ref refines="Pierson">[https://books.google.com/XXXXXXXX&pg=PA123 p. 123].</ref> Nevertheless, it's a huge net gain from my point of view, much better than {{sfn}} or {{rp}}. Lwarrenwiki (talk) 20:09, 25 May 2018 (UTC)[reply]

  • Strong oppose This is a bad solution to a problem that is absolutely non existing. It only makes things worse. Reference content is "repeated"? So what! I always teach students to insert the full reference in every footnote. Footnote 1 is followed by footnote 2, by footnote 3 etc., always with the full text. That is the easiest way for new (and old) contributors to add the information. It is the best way for a wiki in which different people collaborate. It is the most secure way for reuse of content, e.g., when you only copy a part of the article, maybe outside Wikipedia. You can easily change what others have written. Why do editors have to learn "refines" or what ever in order to write a Wikipedia article? Where is the need to "define" a name for the work? We need less wiki code, not more, no more complications and alternatives people can stumble over. Please think about the newbie who is already overwhelmed, and needs no more deviations from traditional referencing. Ziko (talk) 02:05, 26 May 2018 (UTC)[reply]

Support Support Although this proposal is similar to the Shortened Footnote Referencing and the Requested Page referencing this proposal actually organizes the references better than SFN or RP referencing do. With SFN referencing, references with the same page number are combined, but you still need a separate bibliography section, and there are multiple references to the same source in the {{reflist}}. With RP referencing, you may use the same source dozens of times because the page number is in the prose itself, and it is very hard to look up a page number from the reflist. On the other hand, in this proposal, the footnotes can be combined. The proposed solution combines the reference-combination functionality of RP referencing with the same-page-combination functionality of SFN referencing. Of course, there are many people who wouldn't use it because they prefer other variants of citations. However, it would be nice to have this option available. epicgenius (talk) 17:02, 28 May 2018 (UTC)[reply]

Oppose Oppose We make the wikitext clearer by making the output, the read-view of the article overwhelmed. The concept operates with some false assumptions, too, one of them is that we may only have only a handful of pages cited in one article. This is false. On the Hungarian wikipedia I demonstrated, how this solution would look on the example of one article where the same book is referenced throughout the wikitext with different pages. This is awful, and does not make the reader's life any easier, compared to the templates we in Huwiki already have to manage this (e.g. hu:Sablon:Refhely). Other concerns are that in this way, even if I just reference a book once and if I want to be consistent with my citations, then the note for that one single reference will also be 1.1. or 2.1 instead of a simple integer (this is again unnecessarily overwhelming the read view). And so on, too much problems I see with this. Pasztilla (talk) 09:40, 30 May 2018 (UTC)[reply]

Oppose Oppose Reluctantly per Ziko. I think this is just too much of a departure from traditional referencing. Wikipedia should mirror how referencing works in traditional academic sources (citations being a single number linking to a stand-alone reference) and not invent our own system no matter if it is better or not. Otherwise, I think we will be confusing both readers and editors. Kaldari (talk) 20:12, 31 May 2018 (UTC)[reply]

I note that, at least on enwiki, there are at least two common variations from "a single number linking to a stand-alone reference". Some articles use {{sfn}}, which causes the single number to link to something that is not a stand-alone reference, as a sort of hybrid between en:Parenthetical referencing and footnote/endnote referencing. And some articles use {{rp}}, which instead of a single number has something like [1]:23 leaving the reader to guess that it means page 23 in reference #1.

For that matter, academic footnote/endnote sourcing will make use of ibid. or op. cit. so their footnotes don't actually "link" to a stand-alone reference either. Enwiki, at least, forbids these abbreviations. Although the end result of this proposal is something like using ibid. except with nesting rather than that abbreviation.

Given the number of different academic styles used in different fields, I'm skeptical that readers will actually be confused by seeing [1.2] rather than just [1]. Anomie (talk) 13:44, 1 June 2018 (UTC)[reply]

Support Support This would be very helpful, and a much more tidy way and functional way to solve the problem I originally addressed in 2007 with w:en:Template:Rp (still the most-used supplemental citation template at English Wikipedia, despite being clunky and not well liked because it is clunky).

Most of the "oppose" comments here are effectively meaningless. They're "I won't use it because I like to pile up the refs at the bottom of the article". It's a false dichotomy. The various styles (LDR, Harvard, etc.) of page-bottom referencing are optional and are effective for certain kinds of articles (primarily Featured and otherwise very stable ones with infrequent new editing), but are a terrible idea in others, make adding and improving content more difficult, and also come with a steep learning curve and a higher error rate. Despite the pulpit-pounding of fans of those grouped, page-bottom styles, they're by far the minority citation approach even when added all up together.

The vast majority of citations are inserted fully inline, where they're easier to edit and to relate to the content being sourced (and are thus more easy to use for verifiability). Having the proposed new fine-tuned option for doing this will:

  • Improve article quality by resulting in more (and more specific) citations.
  • Avoid the page-bottom style being used in articles in which it's an impediment not a boon.
  • Have no effect on appropriate use of the page-bottom style.
  • Make desperate workaround approaches like w:en:Template:Rp obsolete.
  • Reduce the number of template calls and other "junk" in articles. For example, w:en:Glossary of cue sports terms heavily relies on {{Rp}} calls and has had to be re-coded in various ways several times (including some really kludgey stuff) to keep it under the transclusion limits. This wouldn't be necessary if MediaWiki itself could parse bare ref tags with a new feature like what's envisioned here.
  • Definitely reduce the amount of redundant citation detail in articles that reuse the same source at different page numbers and so on – regardless of which of the compatible citation styles is used.

The fact that this would be useful to, and is desired by, people who use fully-inline rather than page-bottom references (habitually or on an article-by-article basis) is reason enough to implement it. It is not necessary that people who don't use that style at all or only rarely say they won't use it. It's like people in Texas voting against a water reservoir in Mexico because it won't help them personally and perhaps because they have politicized reasons to want things to be worse on the other side. That is, the minority who detest fully-inline references have a biased reason to oppose any feature that makes that system more useful or attractive to any editor. So, those objections really don't pass the sniff test.

 — SMcCandlish ☺ ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  21:52, 1 June 2018 (UTC)[reply]

Bullshit!
I have no idea what you mean by "fully-inline" references (are you thinking of parenthetical referencing??). The requirement for in-line citations applies to all editors, so I can only wonder what, or who, you mean by "people who don't use that style".
As to "page-bottom refernces": unless this is an atavistic reference to footnotes (strictly defined) at the bottom of a paper page, I would take this to refer to end-notes at (or at least near) the end of the article. As that is the universal practice – "style" – across Wikipedia, your comment seems to apply to some apparently non-existent strawmen.
I also object to your introduction of "politicized reasons to want things to be worse on the other side." As I have said (below), I agree there are problems. But I strongly disagree with the imputation that opposing this proposed feature is tantamount to a "a biased reason to oppose any feature that makes that system more useful or attractive to any editor." That is entirely unwarranted. ~ J. Johnson (talk) 23:47, 6 June 2018 (UTC)[reply]
All drama aside, the SFN templates don't exist on all wikis, and for all we know the output they produce might even be against the policies or layout guidelines of some wikis. So "We can't have this extended <ref> syntax because {{sfn}} already does it" isn't an applicable argument.  — SMcCandlish ☺ ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  00:53, 9 June 2018 (UTC)[reply]
You have yet to explain just what you mean by "fully-inline ... references". And your characterization of my position as "We can't have this extended <ref> syntax because..." is a misrepresentation. I am saying: it "fixes" (ha ha) the wrong problem. Furthermore: I have no where advocated the use of {sfn} (I actually disfavor {sfn}), and ABSOLUTELY NO WHERE have I argued that {sfn} makes "extended <ref> syntax" unnecessary. (Others have argued that, but I don't.) I am arguing short-cites (or shortend citations), however done, make it unecessary to "repeat all the information about this work in each reference", which is the starting point of this entire discussion. I also argue that much of the problem with citations is conceptual, due to incomplete, ambiguous, or even meaningless terms. Such as "fully-inline references".
"All drama aside", I still object to your imputation of bad-faith, that I (or any of the opponents here) have biased and politicized reasons for not wanting this very dubious feature. J. Johnson (talk) 22:35, 9 June 2018 (UTC)[reply]


Support Support This type of feature has been needed for a long time and should be an integrated system as proposed instead of a bunch of disconnected template calls. --Struthious Bandersnatch 05:29, 2 June 2018 (UTC)[reply]

Strong oppose. "Would the proposed solution help you in your daily work?" Absolutely not. Even if I did not use this feature, it's use by other editors would complicate any article I work on. There is a fundamental problem in how the <ref> entities are used, and the invention of named-refs was a step in the wrong direction. This feature would only dig a deeper hole, making matters more complicated, and more difficult. I fully agree this "reuse of references" is a major issue, but the feature proposed here is not the solution. J. Johnson (talk) 02:04, 3 June 2018 (UTC)[reply]

Neutral Neutral - I see this as an alternative to <ref name=a>A</ref>{{rp|1}} {{r|a|p=2}} which would now look like <ref name="A">A</ref>{{rp|1}} <ref refines="A">p. 2</ref>. Your sample looks like you're hoping writers will put the full citation in the article footer, but that seems contrary to bring us toward {{sfn}} & co. I like the output display, but I think we need a plan that allows writers to put the full citation inline while not disconnecting the citation from the page number, because it's hard to convert <ref name=a>A</ref>{{rp|1}} into your desired output. Daask (talk) 22:19, 4 June 2018 (UTC) Daask (talk) 22:19, 4 June 2018 (UTC)[reply]

Support Support: This proposal does appear promising and I can see how beneficial it can be, for both editors and readers, and how much less confusing it can be for both compared to {{rp}} and {{sfn}}. I think this proposal is less cumbersome and complicated than both the aforementioned, including (I suspect) for new editors. It would also be more intuitive a citation superscript, since {{rp}} baffled me until I figured it out while editing and it gives no clear indication what it means; and {{sfn}} would only be immediately familiar to those who are familiar with parenthetical referencing formats, which are generally used in academic literature. My experience is that {{sfn}} is also generally used only for books and journals, so many articles end up with mixed referencing types, which add to the confusion. The latter issue is somewhat beyond the scope of this proposal, though it would provide a much better alternative than {{rp}} does to {{sfn}} that would be useful for articles which do not already use parenthetical referencing or whose citations are overwhelmingly inconsistent with such a referencing style.

I frequently use {{rp}} in articles—and consider this proposal to be more intuitive and stylistically consistent than {{sfn}}—so deprecating {{rp}} with an improved MediaWiki extension would benefit my editing personally. This is especially so given that the |quote= parameter in {{rp}} (and {{r}} and any other templates implementing quotes in this way) violates the English Wikipedia Manual of Style's accessibility guidelines on text (permanent link), specifically:

Do not use techniques that require interaction to provide information, such as tooltips or any other "hover" text. Abbreviations are exempt from these requirements, so the {{abbr}} template may be used to indicate the long form of a word.
— English Wikipedia Manual of Style: Accessibility § Text

I do have three issues with this proposal in its current form, though:

  1. I am concerned that the refines attribute is somewhat intuitively unclear, unlike name. Although I would still use this proposal if implemented and I understand the markup rather clearly, it might be needlessly unclear for new editors and especially non-English ones. A different attribute name may be preferable for those reasons.
  2. Although I am seeing nothing that would necessarily preclude adding quotes to refined references in this proposal, there would be no semantic HTML markup indicating that it is a quote, such as <q>...</q>. The latter markup is generated when using Citation Style 1 templates, such as {{cite journal}}, via the |quote= parameter. Without manually adding the HTML during citation, the quotes will not be marked as such. If we want to provide consistent accessibility in our inline citations, then this issue may be worth considering. Unfortunately, the only way I can think of easily solving this would be to either extend the CS1 family with new templates, perhaps with |quote=, |page=, and other parameters; or to create a new template, like {{quote}}, which inserts the equivalent <q>...</q> markup ({{quote-inline}}?).
  3. How would this proposal work with popup previews such as Page Previews and Navigation popups? Would the base reference be shown with the indented refinement beneath it? Or would only the refinement show? Page Previews are now available for all readers, including logged-out ones, and navigation popups are both popular and extremely useful for editors. I think it is important that any citation popup shows both the full citation and the refinement, since otherwise the same problem of providing citation details before the citation persists and users would still be jumping to the bottom of the page, thereby negating the functionality of both features with regard to citations.

Despite these issues, this proposal would be an improvement over {{rp}} even if these issues remain unaddressed. Although some editors may prefer {{sfn}}, that does not change the fact that {{rp}} has nearly 30,000 transclusions on the English Wikipedia and so its replacement with a better implementation should be endorsed regardless of one's preferences. This proposal is moreover not comparable to {{sfn}}, neither in form nor in appearance, so I think it would benefit those of us who use {{rp}} because of its utility in circumstances in which {{sfn}} is inappropriate.

For the record, I edit exclusively via wikitext using the CS1 templates. I briefly used the visual editor when it first came out, but I had returned to exclusively editing wikitext, especially now with the Syntax Highlighting beta feature. Additionally, my response here does not imply any evaluation of alternative proposals, including any preference for this proposal in its current form. I am only commenting on the latter. —Nøkkenbuer (talk • contribs) 05:38, 7 June 2018 (UTC)[reply]

FYI: (1) See #For wikitext users: Which name do you prefer for the attribute within the <ref> tag? below for comments about potential parameter names. (2) Metadata in the wikitext/HTML inside the reference is outside the scope of this proposal, IMO. It will be up to the editor communities on each wiki to decide if and how they want to handle that sort of thing. (3) That too isn't really in scope for this discussion, although I expect those scripts would be updated to display both the unrefined and refined reference since just the refinement is less likely to be useful to readers. Anomie (talk) 13:19, 7 June 2018 (UTC)[reply]

Support Support, but only if Visual Editor is upgraded to support named references. It is very frustrating to have an inexperienced editor using VE and changing all the carefully chosen reference names to :0, :1, :2, etc. I correct articles with reference problems, so I work with all the available reference templates as well as references hand-coded with <cite>...</cite>. Adding support for pages would be very helpful. However Visual Editor cannot add or edit reference names or other tags. Your example above uses the "Re-use" tab to show working with VE and adding a page. There must also be a way to add and edit meaningful reference names and group tags without having to go to the source editor. This has been on the Wish List for a while. The method you are proposing cannot be done with the current state of Visual Editor. StarryGrandma (talk) 17:22, 9 June 2018 (UTC)[reply]

Other remarks

[edit]

Can you think of anything else to consider for the implementation? E.g. special cases from the wikis you’re active in, …

  • The example is a list-defined reference, but most articles I edit (en.wp) have references defined on-the-fly where used in the article body. Somehow we need a way to distinguish what is the main ref content vs is the refinement detail, and to supress a non-refined footnote marker. Brainstorming...
<ref name="Pierson">{{Literatur|...}}<ref refines name="Pierson131">S. 131</ref></ref>
has only one <ref>...</ref> tag at the level of the article, so only one footnote would be generated. The inner <ref>...</ref> is a subdetail that has an implicit refines=$parent. DMacks (talk) 08:17, 14 May 2018 (UTC)[reply]
  • @DMacks: It will definitely be possible to define references on the fly in the wikitext. It’s on our to do list to come up with a syntax for it. For complexity reasons, we left it out of the proposal, but you’re right, we should have put it in. This is now fixed.
    Apart from that, we edited the description of the solution to make the concept as a whole clearer. Would you mind looking at it again and adding your assessment to the first feedback question? That would help us a lot. -- Thanks, Johanna Strodt (WMDE) (talk) 15:02, 15 May 2018 (UTC)[reply]
  • I use a bibliography and a references section. When I cite a book, I only have to reference the author's last name and page number. See for an example
Best Regards, Barbara (WVS) (talk) 08:32, 14 May 2018 (UTC)[reply]
  • Sometimes you do not use a source without page number at all. For example "good book, page 10", and "good book, page 30", but no "good book". To use this feature, there should be a way to create a code <ref name=goodbook>good book</ref> in references parameter of <references>...</references> without an error "the reference is not used anywhere". But not remove the check totally, only in the case of this feature. Thank you. IKhitron (talk) 15:02, 14 May 2018 (UTC)[reply]
  • Support Support. How about <ref location="page 10" name="foo">good book</ref>? -- JakobVoss (talk) 07:10, 15 May 2018 (UTC)[reply]
  • Hey IKhitron, I was referring to "The final version of the feature will also allow to define the main reference within the wikitext body without creating an unused jump mark. It’s on our to do list to come up with a syntax for it." Maybe I misunderstood your remark. If so, could you paraphrase it? -- Thanks,
  • This proposal looks good from within the current MediaWiki infrastructure but I'd like to look further: The most relevant standard for referencing nowadays is CSL. It's cite item supports fields "id" (equivalent to "name" in MediaWiki references), "label", "locator", "prefix", and "suffix". The proposal roughly covers "label" (locator term such as "page" or "chapter") and "locator" (e.g. a number). The locator term must come from a predefined list but its values have been localized. In Pandoc Markdown locator terms are recognized automatically. Please see the bigger picture and aim compatiility with standards outside of MediaWiki! -- JakobVoss (talk) 07:10, 15 May 2018 (UTC)[reply]
  • I’m sorry, I have to wonder whether you have even tested this in the wild before proposing. Default MediaWiki implementation of Cite extension looks like this. The 1.1, 1.2, 1.3 demarkation would obviously bring immense confusion to readers outside of projects with letter numbering because it will duplicate already used style of references. What exactly should reader expect when they come across [1.1] in text? It is not obvious at all.
    Other than this, something that could deprecate sfn is probably needed, so idea itself is noble as usual, but the proposed implementation is very strange to anyone who knows anything about MediaWiki. stjn[ru] 16:14, 15 May 2018 (UTC)[reply]
    • Hi stjn, the format of footnotes can be very different from one wiki to another as each wiki can choose how they want to do this – see English and Bengali Wikipedia for example. The format we proposed for refinements (1.1, 1.2 etc.) is only one example of how this could look. We expect that each wiki will be able to decide individually how they want their refinements formatted, like they already can with multiple uses of the same footnote. Thanks for the reminder – I added this information in the description of our proposal above. If you have any idea for a good default format, we’re happy to hear it. Also, your assessment if the proposed solution could help you in your work would be very much appreciated. -- Thanks, Johanna Strodt (WMDE) (talk) 10:35, 16 May 2018 (UTC)[reply]
      • Well, I’m just voicing my concern about a most obvious issue. Something like a b c, by the way, is also used by article comments, so there is very little room for some syntax. Maybe a real solution could be to copy Rp template look users talk about above, since it won’t interfere with anything potentially. stjn[ru] 13:26, 22 May 2018 (UTC)[reply]

The feature will be quite useful. Two points though:

  1. I wonder how it would work out with multiple columns. See for instance this usage of mine from 2010 with De Sacy, p. NNN referring to the following section "مصادر".
  2. Can we think of expanding this feature to automatically put urls under their main base url? Recently, I've been citing the same "work" (actually a dictionaries site) in many articles. Here is an example where the main url is lisaan.net and its cited urls are all like lisaan.net/*.

Thanks! Zack (talk) 01:14, 23 May 2018 (UTC)[reply]

IMO trying to automatically regroup URLs is beyond the scope of this change. You could do it manually, if you wanted to. Anomie (talk) 14:34, 23 May 2018 (UTC)[reply]
@Anomie and زكريا: Automatically grouping URLs is probably difficult and not always helpful. I think it's probably best to give editors discretion on when to group references. However, I think this could be included in the scope of problems this proposal would solve. Specifically, I could imagine writing this:
<ref refines="Pierson">Article: ''Nirvana''</ref><ref refines="Pierson">Article: ''Housing''</ref>
That would allow book chapters and encyclopedia articles in the same larger work to be cited together. I've wondered the best way to do this and sometimes repeat the entire book citation, which this could avoid. That said, this is a relatively minor problem compared with the everyday common use of repeated citations which this discussion is meant to address. Daask (talk) 03:39, 9 June 2018 (UTC)[reply]

Proposed feature is the wrong solution

[edit]

The feature being proposed here is the wrong solution.

First: I fully agree that the practice of citation is one of the most troublesome issues – arguably even the most troublesome issue – across the English Wikipedia, and I understand that to be the case generally. It is also one of the most contentious issues, which I attribute to the experience of learning the details of how to do minimally adequate citation being generally so difficult, and even painful, that many editors, having finally grasped a useable concept of doing citation, are very sensitive about all this.

Second: I argue that underlying problem is conceptual, and that the problems editors have – such as "resusing references" without having to (as stated above) "repeat all the information about this work in each reference" – arises entirely from certain widespread but incorrect concepts. Among these are: a) a failure to distinguish full citations (containing the full bibliographic details of a source, as created with the {citation} or {cite} templates) from short (or shortened) citations (such as inserted in the wikitext by the {sfn} and {harv} templates); b) a failure to understand that in-line citation does not require full citations, and c) a failure to understand that the notes created using the <ref>...</ref> tags are NOT citations.

As I don't know just how soon the comment period closes I will say for now only that "references" – in the sense of a full citation – do not have to be "reused". Once a full citation for a source has been introduced, further "references" to a source can be done with short cites. Which can also be customized in all kind ways that completely obviate any need for the feature proposed here. J. Johnson (talk)

I don't like "short citations" for two reasons. First, logistically in terms of reading and digging into sources, I like the ease of clicking on the citation and being led to the actual reference instead of the bibliography section where i have to find the ref and click again. Second, the "refname + rp" system makes it much more obvious to see how refs are used (if the page relies on one or two sources, overwhelmingly). Jytdog (talk) 14:52, 6 June 2018 (UTC)[reply]
There is some difficulty in understanding what you mean because of the ambiguity of your terms. E.g.: when you refer to "clicking on a citation and being led to the actual reference instead of the bibliography section", I can't follow what you mean because of the ambiguity of "reference", and even "bibliography section". I would take "bibliography" to be the list of full citations of the sources, with full bibliographic details, and the only reason to "click again" would be if you wanted to a follow some link (such as a download link). Possibly you mean "clicking on the note-link number", which takes you to (or, if you have Tooltips enabled, displays) the contents of the note, which could be the full citation itself, or a short-cite. In the latter case, clicking on the short-cite (if created with a harv template) takes you to the full citation in a bibliography (or "sources") section. Either way, I don't know what you mean by "i have to find the ref and click again", so I can't adequately respond to your comment.
By "refname + rp" I presume you mean what I call "named-refs" with the use of the {rp} template. (Right?) But {rp} is horrible, and named-refs have other problems not fully delved into here. And I don't see how that "makes it much more obvious to see how refs are used". If, say, an article relied mostly on "Smith and Jones, 2000", and that source had a full citation in, say, note #12, then seeing "[12]" every where would certainly indicate that the article relies heavily on that source. But if each use of that source had its own note, each containing "Smith and Jones, 2000, p.xxx", then seeing that short cite through out the "References" (or "Notes") section would be just as good an indication of heavy usage. Even better, the distribution of said notes would indicate the distribution, whereas with named-refs the single "12.abcdefghij" provides no indication of where those instances are. I do not see how "refnamed + {rp}" would be "more obvious".
I suspect your dislike of short citations arises from an underappreciation of how they can be used. J. Johnson (talk) 22:43, 6 June 2018 (UTC)[reply]
But I've been editing en.WP for 12 years and am familiar with all these citation systems, and I agree entirely with Jytdog (nor do I find anything he said vague or hard to follow). "You disagree just because you're ignorant" isn't a valid argument, J. J.  — SMcCandlish ☺ ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  23:42, 8 June 2018 (UTC)[reply]
That isn't my argument; I have made no argument on the basis of anyone being ignorant. Even where I said Jytdog may underapprciate short citations, I allow his dislike might be due not to any lack of facts or knowledge, but possibly to subjective evaluation or personal preferences.
As to "vague and hard to follow": I would like to know what @Jytdog means by "clicking on the actual citation" (what kind of citation has he in mind?), being led to "the actual reference" (huh?? wouldn't that be the citation?), distinguished from "going to" (linking to?) to the "bibliography section" (?) where "I have to find the ref and click again." J. Johnson (talk) 22:55, 9 June 2018 (UTC)[reply]

For wikitext users: Which name do you prefer for the attribute within the <ref> tag?

[edit]

Please add a Support Support to the suggestion you like. Multiple pros are possible. If you don’t like a name, please explain why.

"refines"

[edit]

e.g. <ref refines="Pierson">p. 123-163 </ref>

  • Support Support - seems logical, it's refining the detail of a reference. Bellezzasolo (talk) 05:50, 21 May 2018 (UTC)[reply]
  • Oppose Oppose - unclear meaning, see below. JAn Dudík (talk) 19:25, 21 May 2018 (UTC)[reply]
  • Oppose Oppose for multiple reasons. I've made a more practical suggestion below (including the rationales for it and against this).  — SMcCandlish ☺ ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  03:28, 2 June 2018 (UTC)[reply]
  • Oppose Oppose, also for mulitple reasons, but at this point probably no time to explain. As a quick gloss of part of my oppose: this proposal does not "refine" anything, and so this term would engender incorrect misleading notions of what is intended. J. Johnson (talk) 01:48, 3 June 2018 (UTC)[reply]
  • Oppose Oppose: Although I understand it just fine, I suspect it will be confusing for new editors and especially non-English ones. This is compounded by the fact that both "reference" and "refine(ment)" can be abbreviated to "ref". This attribute name might be intuitive for a native English speaker with a penchant for Latinates like me, but what about someone whose native language is not Romanic and who has only a basic grasp on English vocabulary? I would rather this proposal be implemented with this attribute name than not at all, but I think a better attribute name is due. —Nøkkenbuer (talk • contribs) 06:29, 7 June 2018 (UTC)[reply]

"extends"

[edit]

e.g. <ref extends="Pierson">p. 123-163 </ref>

another suggestion

[edit]

If you have another suggestion, please add it here. If you like suggestions from the discussion on T171581, feel free to add them here!

I think this is the opposite of the intuitive meaning. It seems to be using the name= to be the parent (for inheritance purposes) rather than the name of the more-refined ref (for reuse purposes). How would you tag "Pierson123" to use elsewhere? DMacks (talk) 02:29, 16 May 2018 (UTC)[reply]
You may be right, but it seemed logical at the time. Locating the specific page/s in the reference. Further use of all options is not at all clear. Is this actually a thing that would be defined once and reused, or something that specifies the location each time it is used? The latter makes more sense to me, after all, how many times will you re-use a ref for the same page in one article? More likely you will reuse the same reference document with a different page each time. Sometimes you may use the same page twice or three times, but not as a general rule. · · · Peter (Southwood) (talk): 06:37, 16 May 2018 (UTC)[reply]
Oppose Oppose: Sometimes, non-location content might be added, such as a verse or quote, in which case the semantics of this suggestion may be technically correct but—given the |at= parameter in CS1 templates—misleading for editors. Editors using this markup might assume that it is only for specifying the location, as you also seem to believe, and that renders this whole proposal generally useless for adding non-location content for a given citation. I think ensuring that this proposal also clearly allows non-location content is important since it would then fully obsolesce templates like {{r}} and {{rp}}, expand the versatility of this extension, and assist further with verifiability (especially with offline sources). —Nøkkenbuer (talk • contribs) 09:33, 7 June 2018 (UTC)[reply]
@Nøkkenbuer: What if SMcCandlish's proposal were accepted, eg. <ref name="Pierson" at="pp. 123–132" />, but instead of <ref name="Pierson" at=enclosed>whatever you want here</ref> we used <ref name="Pierson" refine>whatever you want here</ref> to the same effect? Daask (talk) 02:48, 9 June 2018 (UTC)[reply]
Assuming it is accepted and implemented, Daask, I would prefer it to involve only one syntax whatever it may be for simplicity and accessibility. The at=enclosed implementation would resolve the edge case problem I described below, but it somewhat defeats the purpose of the alternative proposal compared to the original proposal above. Using refine in the way you described honestly seems like a more verbose implementation of the original proposal whose benefit over the latter is that it follows the current syntax more closely. I would still support it if it means implementing some form of the original proposal, but I'm not sure if it is an improvement over the latter and returns us to the same issues stated above and below about the latter, especially the use of refine as the attribute name. —Nøkkenbuer (talk • contribs) 03:52, 9 June 2018 (UTC)[reply]
  • <ref subref="Pierson">p123</ref>. Reference is international word, name is interlanguage understandable, but refines? I am not sure, how to translate (which meaning) to my language (and I had to see dictionary, because I didn't know this word). JAn Dudík (talk) 19:23, 21 May 2018 (UTC)[reply]
    Support Support I also suggested "subref" in the main response section, before I saw it suggested here. Grin. Alsee (talk) 01:16, 22 May 2018 (UTC)[reply]
    On the other hand, "subref" could be misread as pointing to a subreference rather than defining a subreference. "subref-of" could avoid that. Anomie (talk) 14:55, 22 May 2018 (UTC)[reply]
    Support Support I am fine with this suggestion. epicgenius (talk) 17:07, 28 May 2018 (UTC)[reply]
    Neutral Neutral: I understand the rationale for this, but my immediate concern is that *-of constructions are not used at all as far as I'm aware and it may not be well-understood in other languages. So long as the latter at least would not be a problem, the unconventional construction does not concern me much. —Nøkkenbuer (talk • contribs) 09:33, 7 June 2018 (UTC)[reply]
    Oppose Oppose this and all of the above variants, and the one immediately below, for multiple reasons. I've made a more practical suggestion below (including the rationales for it and against these).  — SMcCandlish ☺ ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  03:33, 2 June 2018 (UTC)[reply]
    Support Support: This seems to be the most internationalized option suggested thus far. Even the options I just listed might be more difficult to understand. —Nøkkenbuer (talk • contribs) 09:33, 7 June 2018 (UTC)[reply]
    MW's wikimarkup isn't internationalized at all. If we want to that to happen (and it sounds like a good idea) it would probably be a parser pre-processing layer, so that you could enter things like <neinwiki> instead of <nowiki> at a German site, and have it converted on-the-fly to the underlying markup before it hits the main parser. Similar to the way PHP works, and various extensions to or wrappers around CSS. Someone may have already done something like this for HTML itself; worth looking for open-source code that could be adapted to MW's non-HTML tags.

    That said, I don't have an objection to something that's both concise and in agreement with the existing syntax (see separate proposal below), e.g.: <ref name="Pierson" sub="p. 123" />.  — SMcCandlish ☺ ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  23:38, 8 June 2018 (UTC)[reply]

    I understand that internationalized markup is unfortunately not generally the case and I agree that such internationalization would be better handled in the way you described, SMcCandlish. Nonetheless, so long as we are not sacrificing the semantic content of the markup, we might as well opt for an attribute name that is most likely to be understood by the largest international audience, if only to not contribute further to this problem and avoid its effects here as well. In the above subref(-of) suggestion, I think that is accomplished in a way that still has semantic markup. What is most important to me, however, is the implementation of something like the current proposal which obsolesces workaround templates like {{r}} and {{rp}} (and {{sfn}}?). The exact attribute name is secondary to that. As for the alternative you just suggested, I would support that, though see my comment below at your alternative proposal since I may support your alternative proposal altogether pending your input. —Nøkkenbuer (talk • contribs) 01:27, 9 June 2018 (UTC)[reply]
    Fair enough. I incorporated "loc" or "sub" as concise alternatives to "at" in the combo proposal I added to the bottom of the page. Agree that the central idea here is a unified approach, which could replace some templates, though I think {{sfn}} would continue. It has a large fan club, and en.WP is weirdly averse to citation standardization.  — SMcCandlish ☺ ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  07:18, 9 June 2018 (UTC)[reply]
  • <ref def = "Pierson" >p123</ref> epicgenius (talk) 17:04, 28 May 2018 (UTC)[reply]
    Support Support: I support this as a comparable alternative to the subref suggestion above, though my concern would be that users may mistake def for the functionality of name given that "define(s)" and "definition" are semantically ambiguous in this context, especially for anyone unfamiliar with HTML markup. I suspect it would be a minor learning curve and would otherwise internationalize well, though. —Nøkkenbuer (talk • contribs) 09:33, 7 June 2018 (UTC)[reply]

Suggestion by Headbomb

[edit]

I like the general idea, but I think a syntax like <ref name="Name#SubsectionName"> would be simpler/more easily understood.

Used, this would look something like 

Jim is big.<ref name="Pierson">Main reference<ref> But Jim is also tall,<ref name="Pierson#1">p. 24</ref> and some people<ref name="Pierson#1"> claim he's not that big.<ref name="Pierson#2">p. 25</ref>

Giving

Jim is big.[1] But Jim is also tall,[1.1] and some people[1.1] claim he's not that big.[1.2]

1. ^ Main reference

1.1. ^^ p. 24
1.2. ^ p. 25

However, I don't know if it's HTML legal to have that sort of syntax. Headbomb (talk) 14:18, 17 May 2018 (UTC)[reply]

IMO a separate parameter would be preferable to magic names. Particularly since currently names might contain the '#' character, and would be broken by this scheme. Anomie (talk) 12:03, 18 May 2018 (UTC)[reply]
Some might get broken yes, but those wouldn't be very many, and would be easily cleaned up. It's just one option, but its an option that would easily allow reuse of a refined reference, and I don't see the current scheme allow reuse of refinements.Headbomb (talk) 18:05, 18 May 2018 (UTC)[reply]
Err, the example on this page includes an example of reuse: it has <ref refines=Pierson name=Pierson131>p. 131</ref> and then reuses it with <ref name=Pierson131/>. Anomie (talk) 08:10, 19 May 2018 (UTC)[reply]
Hmmm... Well I don't see that example anywhere on the page. DMacks suggested something similar, but with very different syntax. But taken on its own, <ref name="Pierson131" refines="Pierson"> seems both rather lengthy / with lots of potential for collisions compared to something simpler like <ref name="Pierson#p131">. Maybe this could be solved with clearer label names, like <ref name="Pierson" subref="p131">, so they wouldn't clash with <ref name="Polanksi" subref="p131">. Headbomb (talk) 11:57, 20 May 2018 (UTC)[reply]
This could have worked if it was introduced when <ref> was first drafted. Implementing it now would break any existing citation the name= of which contained the "#" character.  — SMcCandlish ☺ ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  03:41, 2 June 2018 (UTC)[reply]
@SMcCandlish:It strikes me as pretty easy to replace all uses of "#" in existing names. HTML4 didn't allow "#" in ids, whereas HTML5 allows anything but spaces.[1] Regardless of what's allowable, nobody who knows HTML would use a # character in an id because of its use in CSS and Javascript libraries. It seems unlikely to me that non-techies would use this character and I don't recall seeing it on English Wikipedia. Daask (talk) 18:20, 8 June 2018 (UTC)[reply]
I don't have any objection the character being present in the name= attribute. The problem is that this won't work for any cases where that character is already present. North Americans and some others regularly use "#" as equivalent to "No.", so we already have citations like <ref name="Pearson#1" /> or <ref name="Pearson #2" /> referring to different source documents. The only way this proposal could work is if these were systematically replaced before the change was installed.  — SMcCandlish ☺ ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  23:08, 8 June 2018 (UTC)[reply]

Alt suggestion / Best implementation?

[edit]

Anomie (talk · contribs) above suggests

<ref refines="Pierson" name="Piersonp131">p. 131</ref>

as a structure. This has, IMO, important drawbacks from a usability perspective. The first is this is long, and people want short when possible. So people will naturally be inclined to write

<ref refines="Pierson" name="p131">p. 131</ref>

However, this could easily clash with a different reference

<ref refines="Smith" name="p131">p. 131</ref>

The second issue is humans think more in terms of "First get Pierson, then look at page 131", rather "First get page 131, and BTW we mean in Pierson". We are better structuring this as General > Specific, rather than Specific > General. Also, the new parameter (refines) of the specific reference is used for the old/existing information (name) of the general reference. That's very counterintuitive.

If we can't use <ref name="Name#SubsectionName">, then I instead suggest

<ref name="Pierson" subref="p131">p. 131</ref>

or

<ref name="Pierson" subname="p131">p. 131</ref>

This clearly marks this as belonging to the original reference Pierson, and cannot clash with a second reference with the subref/subname of p131. Headbomb (talk) 14:09, 20 May 2018 (UTC)[reply]

Going to @Johanna Strodt (WMDE): as well. Headbomb (talk) 14:10, 20 May 2018 (UTC)[reply]
Reusing name to mean two different things (creating a named ref, or pointing to the ref to refine) is a bad idea, IMO. You'd also have to make sure that the anchors produced didn't conflict between Pierson subref p131 and if someone makes a reference named "Piersonp131" (or "Pierson_p131", or whatever you wind up using to combine them when making the anchors). Anomie (talk) 17:38, 20 May 2018 (UTC)[reply]
Well name here wouldn't mean two different things, it means the same thing: the primary reference named name. subname would be the the refined instances of name, so gets grouped with name. As for avoiding collisions, you could either just live with the risk (would be pretty unlikely to have a <ref name="Piersonp131"> alongside a <ref name="Pierson" subname"p131"> in the same article), or use an unusual joiner, like Pierson§p131 or Pierson↦p131. Headbomb (talk) 17:55, 20 May 2018 (UTC)[reply]

This is just redundant, though. Why on earth would we want to wrap something like "p. 131" in two tags, then encode the same information again in "subname" or "#subname" or whatever? There's no reason to do this. Please see #Follow existing syntax as much as possible for a solution that doesn't have this problem.  — SMcCandlish ☺ ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  03:39, 2 June 2018 (UTC)[reply]

Follow existing syntax as much as possible

[edit]
This proposal has been superseded by #Combining features of several proposals into one, below.  — SMcCandlish ☺ ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  07:59, 9 June 2018 (UTC)[reply]
  • <ref name="Pierson" at="pp. 123–132" />
    Support Support This would be concise, would be more consistent with other uses of the ref stuff (especially simpler secondary references to the same source, as in <ref name="Pierson" />), would not confusingly suggest that something like "pp. 123–132" is being marked up and will appear inline in the prose as regular text at the insertion point, and would permit exact and correct input, like not wrongly using "p." or multiple pages, and not using "p." or "pp." for things that are not pages, such as a database entry, timestamp in a recording, the back cover of something, etc. And it preserves the same name="Pierson" ID. Oh, it also avoids using long and potentially confusing words with debatable meanings like "refines", "locates", "subref", and so on.  — SMcCandlish ☺ ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  03:26, 2 June 2018 (UTC)[reply]
    Oppose Contra Putting wikitext inside a tag attribute is likely to confuse people, particularly with the extra quoting necessary. Your syntax here also doesn't provide any way to reuse the reference, and confusingly looks like it is reusing something from somewhere.. Anomie (talk) 17:06, 2 June 2018 (UTC)[reply]
    The format, quotes and all, is already used by the ref system for everything, e.g. <ref group="journals" name="Pierson" />. (The quotes are optional if the values do not contain any spaces, but if you try to do something like <ref group=peer-reviewed journals name=Pierson 2009 />, then you get breakage.)

    If we actually want the content I've put in the at= attribute to be wikimarkup-capable, then an alternative format of <ref name="Pierson" at=enclosed>whatever you want here</ref> could maybe be viable, but it shouldn't be required, since in most cases no markup will be necessary or desirable.
     — SMcCandlish ☺ ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  08:53, 4 June 2018 (UTC)[reply]

    You seem to have missed the point with respect to quoting. I mean quoting as in <ref name="Pierson" at="chapter &quot;Foo's &lt;3&quot;" />. As for your "at=enclosed", why have two different syntaxes? The "enclosed" version will work fine for all cases and non-enclosed format saves you nothing. Anomie (talk) 13:34, 4 June 2018 (UTC)[reply]
    @Anomie: I've addressed this at #Discussion of combo idea.  — SMcCandlish ☺ ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  08:13, 9 June 2018 (UTC)[reply]
    Oppose Contra: My immediate problem with this is the same I had with the first and second suggestions in § another suggestion, namely that if this proposal is intended to handle non-location content, then the use of at is very likely to be misleading and confusing for editors due to the |at= in CS1 templates and the fact that "at" usually refers to a location rather than a quote excerpt. I think it is crucial to preserve the greater functionality of any proposal like this to accommodate non-location content such as quotes, especially in cases of offline sources, and I am worried that an attribute like at will generally fail to do that. Yes, it could still be used that way and workarounds such as at=enclosed could be implemented, but I strongly suspect that most editors using this markup will either assume or tend to treat this markup as only for specifying locations. —Nøkkenbuer (talk • contribs) 09:50, 7 June 2018 (UTC)[reply]
    I don't follow. The CS1 templates code |at= as an free-form alternative to |page= and |pages=; it's already fine to do something like |at=Fig. 5 in "Illustrations" section of unnumbered pages, or |at=Table 42, "Nairobi Livestock", entry 4 under "Landraces of Nairobi", or even |at=Back cover of DVD box; note that the director's name is misspelled as "Shcoen", or whatever. The current proposal is primarily for location-in-source data. The fact that additional text can be included makes it more, not less, similar to |at=. Not that the simple wording similarity of <ref ... at="..."> to {{cite book ... |at=...}} would have any implications for "preserv[ing] the greater functionality of any proposal like this"; even if it could, it does not in this case.  — SMcCandlish ☺ ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  23:21, 8 June 2018 (UTC)[reply]
    I suppose you are right, though my personal experience with both using |at= and seeing it (rarely) used by others is that it is always used to specify a location of some sort, even one that is not numeric such as the examples you provided. This is unsurprising, given that the CS1 documentation lists |at= under "In-source locations". Moreover, the parameter is never used for quotes and for good reason, since that is the function of the |quote= parameter. It is due to this experience, the CS1 template documentation, and what appears to be conventional usage of |at= that I derive the above concerns.
    With that said, I will change my position from "Contra" to "Neutral" given that my concerns about at= may be excessive and I was not comfortable with my initial "Contra" anyway; however, before doing so, I would like your input on a suggestion, since I may support your alternative proposal after all. By the way, the sub attribute name alternative you suggested above also works, especially if this proposal's extension would also be used for quotes; but I understand why you might prefer at given it "[f]ollow[s] existing syntax as much as possible", particularly when considering CS1 template syntax. Even if quotes are used, the location information should be given anyway.
    My present rationale for not supporting this alternative proposal is that at=enclosed may be either superfluous or the only necessary input, as I realized when typing the last sentence of the previous paragraph. This is my suggestion: even if non-location content is included, even content with wikimarkup, the location ought to be specified anyway. Therefore, your proposal can be simplified to either always requiring at=enclosed with whatever location and content being specified between the tags or always specifying the at=location with the option of expanding the tag from its self-closing state to enclosing whatever content (including wikimarkup).
    This suggested simplification would not only fully resolve whatever concerns I have and ensure they are unlikely to occur, but also resolve them even if Daask's loc attribute name were used. In the latter scenario, I would honestly prefer at for the same reasons you specified above and because it may internationalize better than loc or subref(-of). Moreover, it would resolve (or apply) Anomie's complaints above and below about having two different syntaxes. After seeing the content of § Combining features of several proposals into one (which did not exist when I began typing this and had this idea), however, I suspect that this is a case of convergent evolution between you, me, Headbomb, and Daask. So long you three agree with my suggestion, or I am otherwise restating what you three already basically suggested, I have no issue with supporting this "combo idea". —Nøkkenbuer (talk • contribs) 01:27, 9 June 2018 (UTC)[reply]
    Yeah, I think I buy all that. I've marked the proposal superseded by #Combining features of several proposals into one, below, which would reserve the at= (or loc= or sub= or whatever name) attribute of the <ref> tag for location-in-source, and put other notes or excerpts inside <ref>...</ref> as wrapped and markup-able content.  — SMcCandlish ☺ ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  08:05, 9 June 2018 (UTC)[reply]

Alternative proposal by Daask

[edit]

As an alternative to the current proposal while trying to accomplish similar goals, how about this:

Text<ref name="Smith 2008" loc="p. 28">Smith ''Book'' 2008</ref> More text<ref name="Smith 2008" loc="p. 50" />

This could initially be implemented to be identical to this:

Text<ref name="Smith 2008">Smith ''Book'' 2008</ref>{{rp|28}} More text<ref name="Smith 2008" />{{rp|50}}

And could then be implemented to produce output identical to this proposal, like this:

Text<ref refines="Smith 2008">p. 28</ref> More text<ref refines="Smith 2008">p. 50</ref>
<references><ref name="Smith 2008">Smith ''Book'' 2008</ref></references>

I think this proposal is better than any of the existing or proposed alternatives on this page because:

  1. It allows fully inline referencing (unlike {{sfn}} or the current ref refines proposal)
  2. It incorporates the page number in the citation, allowing easier machine processing and different output forms (unlike {{rp}})
  3. It allows different kinds of locations, like "Chapter 4", "p. 5", or "Section 4a"

What do y'all think? Daask (talk) 15:06, 8 June 2018 (UTC)[reply]

This seems to be basically the same as the proposal at #Follow existing syntax as much as possible, which already has some discussion. Anomie (talk) 16:10, 8 June 2018 (UTC)[reply]
Nøkkenbuer's arguably invalid objection to that proposal is actually valid for this one, because "loc" would imply location only, without anything to contradict that implication. Using "at" might give that implication to someone new to our citation system, but |at= in citation templates has long been used for more than strictly location data.  — SMcCandlish ☺ ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  23:26, 8 June 2018 (UTC)[reply]
@SMcCandlish: I'm happy to accept |at= instead, as more generic per Nøkkenbuer's concerns and because it also probably requires less English proficiency. Daask (talk) 02:52, 9 June 2018 (UTC)[reply]
BTW, aspects of this alternative have been merged into #Combining features of several proposals into one, below.  — SMcCandlish ☺ ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  08:05, 9 June 2018 (UTC)[reply]

We already have this!

[edit]

Once again I feel the need to point this out: the feature in this suggestion has been in production for years. The {{sfn}} does all of this, and more, in a much simpler and more compact format. It is already widely used, including most FAs.

It appears (to me) that this suggestion is based on an unfamiliarity with the modern wiki software. Let's not start modifying the software when the real problem is RTFM.

Maury Markowitz (talk) 11:04, 18 May 2018 (UTC)[reply]

en:Template:sfn appears as a separate footnote, and how well it works depends on editing another citation template (putting |ref=harv in {{cite journal}} for instance). Nothing that exists does was is proposed here, which is consolidate multiple references to the same work under one main citation, and subcitations, e.g.

1. Smith, J. (2006). Book of Things, Penguin Books, ISBN 978-3-16-148410-0

1.1.^ p. 25

1.2.^^ p. 39

1.3.^ Figure 2

1.4.^ p. 40. Note that Smith uses the −+++ metric signature rather than the +−−− signature used in this article.

2. Pierson, P. (2001). "The substance of things", Journal of Foobarology 34:1–15 DOI:10.1203/10.1234doi:10.1203/10.1234

3. Schnellmann, P. (2081). About Stuff, World Science Publishers, ISBN 978-3-16-148410-0

3.1.^ See chapter 3
3.2.^ p. 34-38
3.3.^ Foreword, pp. ii–iv
Headbomb (talk) 11:15, 18 May 2018 (UTC)[reply]
en:Template:sfn does not do all of this. As in the example Headbomb posted just above, this puts the refinements directly with the main reference, instead of requiring the reader to cross reference from the reference to a separate section with the full references. Anomie (talk) 12:01, 18 May 2018 (UTC)[reply]
You're missing my point. The improvement being discussed is in the text at the bottom of the page. Yet, somehow, the suggested solution is more markup in the body? Huh?! If you want the display at the bottom of the page to change, you change the display at the bottom of the page.
The sfn tag does have all the data needed to do this already. {{sfn|Bob|1986}} will link to line 1 while {{sfn|Bob|1986|p=25}} will link to line 1.1, and {{sfn|Bob|1986|loc=Figure 2}} will link to 1.4. If you really think this change is needed (and really, this is the problem we need to be working on?) figure out how to get the reflist template parser to do it.
The absolute last thing we need is yet another change to the markup. We've made a system that is practically impossible for new users to pick up, and in a little tiny effort to improve that we've been telling people for the better part of a decade to use sfn. SO USE SFN. Maury Markowitz (talk)
But some would consider it better to have line 1 be the actual reference rather than just "Bob (1986)" that has to link elsewhere to see the details. Anomie (talk) 08:14, 19 May 2018 (UTC)[reply]
@Maury Markowitz: This suggestion does not need to be seen in opposition to sfn. With this functionality implemented, maintainers of sfn could change their template to make use of it. Everybody using sfn would just keep on doing the same thing they were always doing, only the output could look bundled and indented. We were not very clear about that in our description above, so I'm going to update that as well. Best Lea Voget (WMDE) (talk) 09:40, 19 May 2018 (UTC)[reply]
Anomie: you mean it makes it more difficult for the reader to figure out what is cited to what by taking up more space and not having an easily identifiable way of reading the citation with an actual name rather than a number? This seems like a major step backwards towards a less reader-friendly referencing system. TonyBallioni (talk) 22:50, 21 May 2018 (UTC)[reply]
@TonyBallioni: I'm not sure. I personally tend to use Reference Tooltips, and in doing so, I like to see the full reference, without having to change my place in the text. With this new system, that's certainly feasible. SFN is just not capable of doing that sort of thing. There are so many ways for this to be implemented. It could even be made to produce an SFN style references section, as opposed to the nested format, while still maintaining full tooltips. Bellezzasolo (talk) 01:08, 22 May 2018 (UTC)[reply]
Which is kinda my point in my oppose above: the only people who seem enthusiastic about it are people who are competent with how technology on Wikipedia works, which is great, but the overwhelming majority of people are just going to be reading the article are just going to look at the footnotes.
From that perspective, it is much easier to have a simple citation format with just the last name and year that can be cross-referenced to a reference list (and no, Headbomb's examples above are not easier to read: they are more cluttered, which is poor design, even if they are closer together.) It is easier to simply glance at a last name, and compare to a short list of references a couple of times than it is to constantly be glancing up to see what the reference number means.
If what people are saying is that this could be used to make a sfn style reference section by making the formatting more complex with writing, I ask: what's the point of that? This seems designed to make people who understand how MediaWiki works like our reference system. It doesn't seem designed to help people who are reading and have never edited a page or who write articles but aren't familiar with MediaWiki, it's tools, or it's extensions. TonyBallioni (talk) 01:18, 22 May 2018 (UTC)[reply]
@TonyBallioni: I have no idea how you can say that it's easier to read something like Special:PermaLink/18082445#sfn status quo than something like Special:PermaLink/18082445#Proposed subref style, particularly if you scale it up to an article with hundreds of references instead of only a few. The new style has advantages in text in that you know every [1.x] is to the same work, and in the references list because all references to the same work are grouped together, and in the references list because you have the reference to the full work right there instead of in a separate section. If you're concerned that you might link to subreference 1.42 and not be able to see at a glance that it's "Smith 2006" because the full version is scrolled off the top of the screen, that's easily enough remedied too by simply including that when you define the subref: Special:Permalink/18082445#Proposed subref style, alternative. Anomie (talk) 15:32, 22 May 2018 (UTC)[reply]
@Anomie: I think both of the proposed permalinks you suggested look much worse than the typical sfn article and are more difficult to read for humans. The advantage to this that everyone seems to be pointing out is that it’s easuer for computers to read. I don’t really care about that. TonyBallioni (talk) 15:43, 22 May 2018 (UTC)[reply]
And the examples are farcically misleading, engineered to make SFN look good. What you'd really see in a typical article with Harvard referencing is a huge block of partial citations (including one for every work that's only cited once) with all those for works cited multiple times redundantly repeating themselves for most of their content (e.g. saying "Smith and Jones (2002)" over and over again, differing only in a page number), and not organized in any way but just showing up in the order they're triggered in the article, followed by a shorter block of longer-form citations, making the reader have to go back and forth between these two sections to try to actually identify who is being cited for what. It's one of the worst imaginable citation system devisable, especially in a medium not constrained to paper. Under the new system envisaged here, for any article not using that Harvard or derived citation style, but using the more typical fully-inline citation coding most editors use, and also having some sources cited more that once for different page references, you'd have a single section of rendered references, and a few places where repeat citations to the same work are grouped together under that's work's citation information. The latter is an order of magnitude more reader-friendly, for multiple reasons. (I don't think machine reading would actually care - MW itself has no trouble figuring out which ref tag is a call to what citation, then rendering it, and linking to it, then providing a backlink to the citation point in the main content.)  — SMcCandlish ☺ ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  04:12, 2 June 2018 (UTC)[reply]
  • The current sfn syntax is godawful from technical side, causes massive issues in the article and is uneditable from tools like visual editor. Sfn is a workaround, not a working solution, so it shouldn’t be even considered as some working alternative to the proposed syntax. stjn[ru] 13:26, 22 May 2018 (UTC)[reply]

@Anomie: said "But some would consider it better to have line 1 be the actual reference rather than just "Bob (1986)" that has to link elsewhere to see the details."
Once again, you're talking about the display at the bottom of the page. Ok, but what does that have to do with the markup in the body?
In order to produce the display you're advocating, you need two pieces of information, (A) a link to the reference, and (B), a page number (or loc). Well, SFN (and r, of course) already has all that typed in. So if you make a system that just renders {{reflist}} differently, you get everything you want and it immediately works in millions of articles.
In contrast, the proposed solution would still require changes to {{reflist}} to render the new format, and would work in exactly zero existing articles. And on top of that, it proposes modifying a format we actively discourage.
Now normally when I think something is so utterly off-side, I'm the one that's missing something. So what am I missing? Is there some piece of information needed to implement this that is not included in existing SFN/r tags? Maury Markowitz (talk) 18:56, 26 May 2018 (UTC)[reply]

  • @Maury Markowitz: You're correct that existing invocations of {{sfn}} could potentially be used to generate a <ref name="..." refines="..."> (although actually changing en:Template:sfn itself in that way would break existing articles that use it). The enwiki template {{reflist}} itself would need no changes, contrary to your claim.

    The actual use of {{reflist}} in an article would, however, need to supply the "unrefined" references (i.e. the full references to the sources, without the page numbers) by passing them to the |refs= parameter (which already exists!) of {{reflist}} instead of putting them in a separate section as a bulleted list as is done now. Yes, "exactly zero existing articles" currently do that, but we can't be beholden to some chicken and egg dilemma preventing us from implementing new features because no article uses a feature that doesn't exist until we implement it.

    I have absolutely no idea what you're talking about with And on top of that, it proposes modifying a format we actively discourage. You also seem to be under the misapprehension that you could somehow achieve this with just some unspecified modification to {{sfn}}, without having to change how the "unrefined" references are specified in an article. Anomie (talk) 20:33, 26 May 2018 (UTC)[reply]

No @Anomie:, this is precisely the opposite of what I am saying. To be clear: I believe every single bit of information needed to generate the output being discussed is already present in pages using the SFN/R. And to make this clear too: I will actively discourage any proposal that requires changes to SFN or the REF format.
You introduce the concept of "unrefined references" as a potential problem. It appears you are referring to the full reference that normally appears at the bottom of the page? In pages using SFN as intended, this already has a link back to the reference though the CITEREF system.
So I ask again: what piece of information is missing that would be needed to produce this output? Maury Markowitz (talk) 16:25, 28 May 2018 (UTC)[reply]
I've already explained it. I have no idea why you seem to be ignoring the explanations I already provided, but I'm not going to waste further time playing word games here. Anomie (talk) 23:57, 28 May 2018 (UTC)[reply]

Having a template for such a features (which en.wp seems to have already) rather than a wikisyntax functionality is usually not a good solution as it in forces editors to learn templates in addition to the wikisyntax and those template usually don't exist across all the different language WPs. The latter is in particular a pain for editors working across several language wikipedias and the reason I usually avoid templates like that.--Kmhkmh (talk) 00:32, 2 June 2018 (UTC)[reply]

It also increases the server's parsing load, and on a template- and parserfunction-heavy pages, such templates can make the page hit the maximum number of parser calls, and fail to render properly. That actually happening is among the main reasons I support this page's proposal (though in a particular, lean, consistent implementation).  — SMcCandlish ☺ ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  04:01, 2 June 2018 (UTC)[reply]

"We already have this!" — sorry to disappoint you, but enwiki isn't the only wiki in the world. IKhitron (talk) 14:23, 2 June 2018 (UTC)[reply]

Nor is that citation system the majority-preferred on those that have it available.  — SMcCandlish ☺ ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  23:27, 8 June 2018 (UTC)[reply]

Reference to different pages for a same reference in one article

[edit]
In 2014 I wrote a module and a template to reuse a reference and add to it page or any other detail.
The Module:RefDetail and the Template:RefDetail display the link to the reference and the text of detail. --Rical (talk) 09:58, 22 May 2018 (UTC)[reply]
That appears to be similar in appearance to enwiki's {{r}} template when used with its p parameter, with the "detail" bit being similar to the enwiki {{rp}} template discussed in several of the comments above. Anomie (talk) 15:38, 22 May 2018 (UTC)[reply]
It actually seems to be effectively a wrapper for <ref name="{{{1}}}"/>{{Rp|1={{{2}}}}} (in effect if not in exact code; I didn't even look at its code, but what it does can be put into that short of a code string unless I'm missing something.) For a typical case, doing <ref name=Foo/>{{rp|9}} versus {{RefDetail|Foo|9}} only saves 4 characters (and less, even zero, if you're a "template spacer" who prefers {{RefDetail |Foo |9}} or {{RefDetail | Foo | 9 }}.  — SMcCandlish ☺ ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  03:49, 2 June 2018 (UTC)[reply]

Here it is

[edit]

I have made an edit to the article on Magnetized target fusion. If you care to scroll down and examine the end of the reference section, I believe 10 and 11 are in the format being considered here, using only REF, SFN and REFLIST. The cite in question does not have a date or pages, so the "refines" SFNs lack those, but feel free to add it to your own examples. To make all of this automated, the REFLIST parser needs sorting, and perhaps some indenting. Now, will someone please tell me why I'm so completely wrong, without implying that I'm an idiot or a troll? Thanks. Maury Markowitz (talk) 17:40, 5 June 2018 (UTC)[reply]

It's a little hard to clarify with the example you chose there that has nothing more than a name, title, and publisher. In practice I'd (and, I think, most editors would) just reuse reference 10 instead of having the pointlessly confusing reference 11 at all. But to use the example, in the format being proposed here those two references would look more like
  1. ^ Seimon, R. "Magnetized Target Fusion". UCSD.
    1. ^ a b Seimon.
And in the body the two [11] would be [10.1] instead.
Yes, "the REFLIST parser needs sorting, and [...] some indenting", but that's the point of the proposal here. More specifically it needs the data from the "refines" (or whatever name) parameter to know which references are to be sorted and indented under which other references. Anomie (talk) 16:22, 6 June 2018 (UTC)[reply]
Right. If not one of the exact proposals on this page, then something very like them, is needed to get there.  — SMcCandlish ☺ ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  08:09, 9 June 2018 (UTC)[reply]

Combining features of several proposals into one

[edit]

After re-reviewing all of the above, I think that a combined proposal would work to sort out all the kinks:

  • <ref name="Pierson" at="p. 123" /> – for just identifying the location in the source. Some other short string could be used instead of at, such as sub or loc.
  • <ref name="Pierson" at="p. 123">[free-form text here]</ref> – for also including additional text, such as an excerpt or an annotation.

The parser would have to be clever enough to understand that <ref name="Pierson" at="p. 123">[free-form text here]</ref> is a "refinement" of <ref name="Pierson">[citation data]</ref>, not a replacement of it.
 — SMcCandlish ☺ ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  23:49, 8 June 2018 (UTC)[reply]

Discussion of combo idea

[edit]
Mass ping – @Karmela, J. Johnson, Johanna Strodt (WMDE), Maury Markowitz, Salgo60, Pbsouthwood, DESiegel, JAn Dudík, Jytdog, Anomie, Nthep, Bellezzasolo, Ahecht, TonyBallioni, Alsee, Shizhao, Saint Johann, Bellezzasolo, Kmhkmh, Daask, Uanfala, Lwarrenwiki, Ziko, Headbomb, Mathglot, Epicgenius, Strainu, Pasztilla, Kaldari, DMacks, Galobtter, زكريا, IKhitron, JakobVoss, Struthious Bandersnatch, Daask, Nøkkenbuer, and SMcCandlish: I think that's everyone who's commented on all the above so far.
  • The idea here (and it could be refined further) is to provide:
    1. A short, convenient syntax for just doing page numbers and the like, basically a replacement for {{Rp}} and its equivalents on various wikis, and similar to |at= in citation templates.
    2. An extended syntax for when editors want to include excerpts and other annotations, that aren't location-in-source info.
This semantically separates the two functions, while preserving a structure similar to the extant ref system, without introducing anything confusing like having to change name="Pierson 1997" to something_else="Pierson 1997".

Both syntaxes are already familiar is general form, from (respectively) doing secondary and later citations, and from doing full cites with the source-detail content. Each is a smaller learning leap that many of the prior proposals.

And, of course, the goal is to integrate ideas above into a single proposal people will congregate toward instead of a dozen or more competing but often very similar proposals.

PS: Please address the proposal with regard to <ref> syntax and features, not from a "But on my main wiki, I prefer to use some particular template we have" perspective.
 — SMcCandlish ☺ ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  00:34, 9 June 2018 (UTC)[reply]

  • This is pretty much the same thing I proposed above. Only thing different is what we call the subref name, and I'm not really fussy on that. Headbomb (talk) 00:41, 9 June 2018 (UTC)[reply]
    Sorry if I misunderstood something about your idea; not trying to steal thunder! Hopefully regrouping everyone with a mass ping will at least get us somewhere instead of stalled. :-)  — SMcCandlish ☺ ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  00:59, 9 June 2018 (UTC)[reply]
  • You don't see to have changed anything too interesting since your earlier proposal. You're still proposing a confusing dual syntax where content is sometimes in an attribute (where it potentially needs escaping) and sometimes in the text. The syntax used in the original proposal seems more straightforward to me. Anomie (talk) 00:51, 9 June 2018 (UTC)[reply]
    • It's different content. No one needs to escape something like pp. 12–14 or Frontispiece or whatever. That's the location-in-source data. And using a wrapper at all was something I initially opposed; this is a compromise (I see that trying to put something like quoted excerpts into an XML attribute value might require too much character-escaping, and would also not be wikilinkable, etc.  — SMcCandlish ☺ ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  00:59, 9 June 2018 (UTC)[reply]

      PS: I'm not too concerned about the loc= or sub= or at= (whatever we'd call it) value very occasionally needing a quote-mark escape (e.g. for something like at="p. 2 of the insert included in the &quot;Special Fan Club Edition&quot;", because 1) we already have to use the same quote-escaping in all other attribute values of all tags (so, it's already familiar); 2) we'd document that it needs to be done in such an odd case; 3) the frequency of such cases would be very rare; and 4) very few of them would actually need the quote marks anyway – it's often going to be extraneous, optional stylization as in the example I just gave.  — SMcCandlish ☺ ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  07:55, 9 June 2018 (UTC)[reply]

  • how would these display? Some of the fuss here is over what the citation looks like and what the notes or bibliography looks like, and what the superscript note number actually links to... Jytdog (talk) 01:38, 9 June 2018 (UTC)[reply]
Yes. What do those note numbers link to? J. Johnson (talk) 20:41, 10 June 2018 (UTC)[reply]
  • I don't have a strong opinion on it, and care (for now) more about the syntax and the reasoning for it. Overall, I like the idea that these would appear under the main ref and indented (at least flush with the start of the content of the main ref), though whether to use bullets or whatever isn't important to me. So, I would think of the value of at=p. 27 (or loc=p. 27 or sub=p. 27, whatever we'd decide) being on a line under the main ref (and under any previous sub-ref), and being preceded by a ^ reference-return link like the main ref entry has. The version where there's also content wrapped inside might thus look something like "x.y.^ p. 27: Blah blah blah whatever the wrapped sub-reference's content is here." but another one that did not have such wrapped conent might just appear as a "x.z.^ pp. 38–39." line. — SMcCandlish ☺ ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  07:55, 9 June 2018 (UTC)[reply]
  • Although uncommon, how would this proposal handle edge cases in which the at= (or whatever) parameter is defined multiple times, such as with "p. 123", but the content enclosed between the tags are different? For example:
    1. <ref name="Pierson" at="p. 123">"This is a quote from paragraph 1."</ref>
    2. <ref name="Pierson" at="p. 123">"This is a quote from paragraph 4."</ref>
I assume that this would cause an error, especially if the reference is then called with <ref name="Pierson" at="p. 123" />. Is there a solution that permits such edge cases? Or should all such instances be defined within the same subreference to avoid it altogether, such as with <ref name="Pierson" at="p. 123">"This is a quote from paragraph 1. [...] This is a quote from paragraph 4."</ref>? Assuming we are going to transclude the content of at= (or whatever) into the subreference text, which I think we should, then disambiguating them with "p. 123a" and "p. 123b" would be inappropriate. Perhaps at="p. 123, para. 1" and so on? What about with content that is not a quote, such as one being a quote and the other being an annotation or something else, or both being something else?
I understand that this may be beyond the scope of this proposal and more so something decided by each community or otherwise on a case-by-case basis, but I might as well ask anyway, especially since this edge case problem would not be present in the original proposal and the latter appears to better handle such cases. Even if this edge case is never addressed, I do not at all consider that grounds for opposing this alternative proposal. There would be very few instances in which this would be a problem and ad-hoc solutions could probably be found then. If our intent is to put an end to ad-hoc solutions and other workarounds like {{rp}}, however, then we probably should not be introducing a significant case in which more would occur, however seldom they may. —Nøkkenbuer (talk • contribs) 02:44, 9 June 2018 (UTC)[reply]
Yeah, the parsing would have to be clever enough to understand that <ref name="A" at="B" />, and <ref name="A" at="B">C</ref> are separate sub-citations from <ref name="A" at="B">D</ref>, just as it would need to treat <ref name="A" at="B">C</ref> as not a replacement for or collision with <ref name="A">Main cite data</ref>, but a "refinement" (why are we using that confusing word?), a separate sub-entry. The at/loc/sub= attribute would not have to be a unique ID. This is a much easier parsing job than much of what MW does. And it would actually need to be done, since for dictionary citations in particular one might be citing several related definitions on the same page of a dictionary. So, it would need to be accounted for. We just make the system smart enough to not explode. PS: Doing at="p. 123, para. 1" would certainly work, but it's best not to assume people will do it, because people won't always do what makes sense. Anything relating to the web needs to be pretty fault-tolerant. :-)  — SMcCandlish ☺ ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  07:55, 9 June 2018 (UTC)[reply]
If this edge case would be a non-issue (pending proper parsing), SMcCandlish, then I see nothing that distinguishes the original proposal as superior to this one. So long as something resembling these proposals passes (with consensus), solves this perennial problem, and obsolesces workarounds like {{r}} and {{rp}}, I will very likely support it. I have no strong preference between this proposal and the original one—at least, at this time—and I currently support both. As for whether any larger consensus will be established, though, that seems less clear, especially given today is currently the last day of this feedback round (if it didn't just end a couple hours ago). —Nøkkenbuer (talk • contribs) 02:13, 10 June 2018 (UTC)[reply]
  • I think the idea to put any sort of output in the parameters would be quite atrocious to use and a total P.I.T.A. to support. I don’t think this is the most logical syntax we should use, since inevitably people would put something that won’t work in there (stuff like " symbols that were mentioned above). We should not require any hacks from users, in my opinion. stjn[ru] 21:42, 11 June 2018 (UTC)[reply]
  • Oppose This doesn't allow fully inline referencing (if every citation references a specific page, then the named citation must be in the references section rather than inline), and uses tag contents for two different purposes (full citation and refinements), which is confusing. I still prefer my proposal. Daask (talk) 19:46, 4 December 2019 (UTC)[reply]

Summary and conclusion have been published

[edit]

A big thanks to everyone who took the time to participate in this call for feedback! A summary of the feedback and the conclusion and next steps for this wish have now been published on its project page. Unfortunately, this took much longer than expected. @Ahecht, Alsee, Anomie, Barbara (WVS), Bellezzasolo, Daask, DESiegel, DMacks, Effeietsanders, Epicgenius, Galobtter, Headbomb, IKhitron, J. Johnson, JakobVoss, JAn Dudík, Jc3s5h, Jytdog, Kaldari, Kmhkmh, Lwarrenwiki, Mathglot, Maury Markowitz, Nøkkenbuer, Nthep, Pasztilla, Pbsouthwood, Rical, Saint Johann, Salgo60, Shizhao, SMcCandlish, StarryGrandma, Strainu, Struthious Bandersnatch, TonyBallioni, Uanfala, Ziko, and زكريا: — The preceding unsigned comment was added by Johanna Strodt (WMDE) (talk) 09:17, 1 October 2018 (UTC)[reply]

@Johanna Strodt (WMDE) and Max Klemm (WMDE): I'm a little disappointed that the concerns and design goals discussed above and the alternate proposals weren't included in the WMDE_Technical Wishes/Book referencing#User feedback summary, which seems mostly focused on support or opposition to the initial proposal. I hope they were considered. Daask (talk) 19:38, 4 December 2019 (UTC)[reply]
@Daask: Thanks for your feedback. We always try to consider all feedback given. We take this feedback as a reminder to so even more consciously in the future. -- For the TechWish Team: Max Klemm (WMDE) (talk) 10:32, 10 December 2019 (UTC)[reply]

This feature can now be tested on the beta cluster

[edit]
Example Refined Book Referencing

The feature is now available on the beta cluster (example article) in an early stage. We invite everyone to test it and give feedback on our central feedback page. We plan to deploy the feature to first wikis in January-February. If your wiki wants to be among the first wikis to have the feature, please let us know. Thanks for your time.
-- For the TechWish Team: Max Klemm (WMDE) (talk) 14:33, 3 December 2019 (UTC)[reply]
@Ahecht, Alsee, Anomie, Barbara (WVS), and Bellezzasolo: @Daask, DESiegel, DMacks, Effeietsanders, and Epicgenius: @Galobtter, Headbomb, IKhitron, J. Johnson, and JakobVoss: @JAn Dudík, Jc3s5h, Jytdog, Kaldari, and Kmhkmh: @Lwarrenwiki, Mathglot, Maury Markowitz, Nøkkenbuer, and Nthep: @Pasztilla, Pbsouthwood, Rical, Saint Johann, and Salgo60: @Shizhao, SMcCandlish, StarryGrandma, Strainu, and Struthious Bandersnatch:@TonyBallioni, Uanfala, Ziko, and زكريا:

I like how it looks on the example article, great work! I'd like to see it on "my" wiki (enwiki), but I'm not going to be the one to start an RFC there to propose early adoption. Anomie (talk) 15:07, 3 December 2019 (UTC)[reply]
I like how it looks and the syntax makes sense, but the tooltip just showing the page number isn't helpful. It should either show the main reference and the sub reference (e.g. show 1 and 1.1) or, if that's not feasible, the entire parent reference (e.g. 1, 1.1, 1.2, 1.3, and 1.4). --Ahecht (TALK
PAGE) 16:27, 3 December 2019 (UTC)[reply]
I totally second that! Uanfala (talk) 23:49, 3 December 2019 (UTC)[reply]
I am not getting a tooltip at all. If I was, I would want to see the full main reference and the location details in the tooltip. The full main reference alone would be more useful than the location within the main reference alone, (just the page number or whatever) which would be pretty useless. Cheers, · · · Peter (Southwood) (talk): 08:12, 4 December 2019 (UTC)[reply]

Tracked in Phabricator:
Task T239785 @Ahecht: Thanks for your feedback. We have created a Phabricator Ticket covering your feedback and will see what is possible. -- For the TechWish Team: Max Klemm (WMDE) (talk) 09:23, 4 December 2019 (UTC)[reply]

Max Klemm (WMDE) first and most importantly, your team needs to be sure to watch this page. When you ping people to here they will typically reply here. As you can see by the other posts here, people have glossed over your link for central feedback. Second, there's a problem with your example page and I couldn't figure out how to fix it using your syntax. The refs which define ref name="Louder" and ref name="Gilbert" are pretty bad - they don't include the page numbers where the info can be found. How do I write a ref with name=X source=Y to include extends=Z??? Lastly, I agree with the other replies that ref tooltip needs to be updated to show the source and page. Alsee (talk) 01:23, 4 December 2019 (UTC)[reply]
@Alsee: If you're asking what I think you're asking, probably something like this? Anomie (talk) 03:25, 4 December 2019 (UTC)[reply]
@Anomie:, That would work fine for me and anyone else who likes keeping the ref definitions in the ref list, but there are some people who will edit war to keep ref definitions in the text. They would probably work hard to try to prevent a feature like this on principle for that reason. Cheers, · · · Peter (Southwood) (talk): 08:12, 4 December 2019 (UTC)[reply]
@Anomie: I wouldn't editwar if you made a ref like that (per Peter's comment), however I don't think I've ever done a ref like that and in general I would consider it a bit weird. Do you (or anyone) know how to define a normal inline named ref that includes a page number? And to staff have you considered syntax like <ref name="refname" at="pagenumber">Source definition</ref>, and the reuse would look like <ref name="refname" at="pagenumber"/>. I think that kind of syntax would be much easier for new users (and even experienced editors) to figure out our usual way (i.e. we primarily learn by looking at and copying how other editors do it on other pages). Alsee (talk) 22:52, 4 December 2019 (UTC)[reply]
@Alsee: Sorry, that it took me some time to response. Thanks for the hint to check this page for feedback as well. We will keep an eye on it. My excuses if the example references are not very good. Their main purpose is to give a first impression of what the book referencing feature might look like, not to be scientifically correct. We have considered several wordings for the feature ('at' was one of them), and decided that 'extends' was the easiest and clearest to use. (Task 171581) -- For the TechWish Team: Max Klemm (WMDE) (talk) 08:29, 10 December 2019 (UTC)[reply]
@Pbsouthwood: Again, thanks for your remark and I am sorry for my late response. I have been talking to our developers and they said that it will for now not be possible to define refs and to extend them at the same time. However, of course we take your feedback (as all feedback) into consideration in the next development steps of this feature. -- For the TechWish Team: Max Klemm (WMDE) (talk) 10:37, 10 December 2019 (UTC)[reply]
@Max Klemm (WMDE):. As I said, not a problem to me, I prefer listed ref definitions anyway. I just hope this does not turn out to be a blocker. · · · Peter (Southwood) (talk): 13:57, 10 December 2019 (UTC)[reply]
Max Klemm (WMDE) oops, I didn't intend to criticize the example refs, chuckle. Examples don't need to be good or fancy. When I said the refs were "bad" I was actually trying to emphasize my use case. I feel it's (usually) important to add a page number to a ref definition.
I understand the issue is being considered. I just want to emphasize that this particular question needs to be decided early in the process. I don't see how this issue can be resolved with the current syntax, and it would be painful to change syntax after deployment. Thanks. Alsee (talk) 15:50, 10 December 2019 (UTC)[reply]

Tracked in Phabricator:
Task T239788 @Pbsouthwood: Thanks for your feedback. Here too, we have created a Phabricator Ticket covering your feedback and will see what might be possible in the future. -- For the TechWish Team: Max Klemm (WMDE) (talk) 09:52, 4 December 2019 (UTC)[reply]

@Max Klemm (WMDE): I gave it a try here and found two issues, which I filed as T239809 and T239810. Anomie (talk) 13:10, 4 December 2019 (UTC)[reply]
@Max Klemm (WMDE):, will this be supported in Visual Editor? When I switched into VE in the example the page references lost their connection to their main references and I could not add new ones. We already have difficulty with VE users trying to work on pages in en.wiki since VE's mechanism of supporting references can't handle many of our existing ways of referencing. I would suggest waiting for VE support before introducing it. StarryGrandma (talk) 20:57, 4 December 2019 (UTC)[reply]
@StarryGrandma: Thanks for your perspective. Our general approach at TechWishes is to deploy features gradually, so we can profit from what we have learned at an earlier deployment for the next implementation phase. This is why it is planned to make the [1] feature available for wiki text first and integrate it into VE later next year. -- For the TechWish Team: Max Klemm (WMDE) (talk) 10:37, 10 December 2019 (UTC)[reply]

@Max Klemm (WMDE): I'm a year late in taking a look at it but I like the way it's designed. --Struthious Bandersnatch 08:53, 30 September 2020 (UTC)[reply]

No help

[edit]

Hello, thank you for putting a note on my de.WP user talk page. I am sorry I have to say that I totally dislike this feature, and that it does not help me with anything. (Maybe I don't have the full overview, please correct me if I am factually wrong.)

First, I want footnotes that are numerated 1, 2, 3, 4... n, in the normal order. I absolutely dislike footnote signs with letters etc. Every footnote in my opinion should have exactly one single and individual number. Just the same as I and most people know it from books. I also want to see the complete information about the book in every footnote there it is used, no abbreviation nor just the page number. This has also to do with the fact that it is a wiki - the source code is altered from time to time by different people.

Second, I need a place to "store" "my" books. There is a couple of books that I use quite often. I "store" the source text in a Google Doc, for example:

<ref>Hans-Ulrich Wehler: ''Deutsche Gesellschaftsgeschichte 1849–1914''. C. H. Beck: München 1995, S. 316.</ref>

I have the Google Doc open and then, when needed, I copy this line in the source code of a Wikipedia article. Copy-and-paste, as simply as it can. And then I adjust the page number.

The least thing I would like to do is to type (or copy) every bit of the information in a form (author, title, year etc.). Certainly not for every book. It would be nice if I could "store" this information somewhere in Wikipedia, and then have a simple way to relate to it in an article. I would even type it in a form, but only once. At the moment, if I understand correctly, I can only "reuse" a "source" within the same article. That does not support my work flow.

I also don't want to learn more wiki code. "ref extend" ... ? I already hate the current "ref name".

Sorry, but I have nothing more positive to say about this feature. Ziko (talk) 15:48, 3 December 2019 (UTC)[reply]

@Ziko:,
  1. Why would you want the full citation in every footnote? This gadget as far as I can tell keeps all the extensions listed directly below the main citation, which to me is far more legible, comprehensible and easy to use, though it does produce a bit of white space, which I can live with as a by-product of utility.
  2. This gadget is not intended to bring in ref definitions from elswhere, that is out of scope. However, you could make a bunch of user sub-pages with your often-used references as content and insert them into the articles as subddtituted transclusions as a way of storing and re-using them from inside Wikipedia. (I have not actually tried this, It has never seemed worth the effort, as I never know which references I will use often enough, but it should work. I just keep a list on my user page and cut/paste from there). Cheers, · · · Peter (Southwood) (talk): 08:29, 4 December 2019 (UTC)[reply]
@Ziko: Thanks for your feedback. I am sorry to hear that you dislike the feature. I just want to highlight that the new feature will be purely optional to use and current ways of working (such as your copy+past method) will still work as they did before. -- For the TechWish Team: Max Klemm (WMDE) (talk) 10:14, 4 December 2019 (UTC)[reply]
  1. ↑ extends
Retrieved from "https://meta.wikimedia.org/w/index.php?title=WMDE_Technical_Wishes/Sub-referencing/Call_for_feedback_(May_2018)&oldid=27519946"